[AWS] 메시징서비스 비교 : Kinesis, SQS, SNS

6 min readOct 10, 2020

AWS에서 제공하는 메시징 서비스인 Kinesis, SQS, SNS, MQ.
어떤 상황에 어떤 메시징 서비스를 쓰는 것이 좋을까? 각각 무슨 차이가 있으며 어떤 장단점이 있는지 간단히 정리해보았다.

엔터프라이즈 어플리케이션을 위한 효과적인 이벤트 프로세싱 전략 — 문종민 솔루션즈 아키텍트(AWS) (2018)의 내용을 정리하였습니다.

Messaging Broker를 두는 구조가 왜 필요한가?

Tightly Coupled System의 구조에서는 한 시스템이 장애가 발생했을 때 그 장애가 연결된 다른 시스템들에 영향을 미치기 쉽다.
대표적인 케이스로, 서버1 -> 서버2 -> DB2의 이벤트 플로우에서, 서버2에 장애가 발생해서 필요한 이벤트를 받아내지 못했을 때, 그 이벤트와 관련된 데이터가 모두 유실되어 버릴 가능성이 있는 것이다.

장애 발생 시 Server1 -> Server2 -> DB2로 들어가는 데이터가 유실될 것이다.

그러나 중간에 messaging broker를 둠을 통해 Loosely Coupled System를 구성하면, 한 시스템의 장애가 다른 시스템에 미치는 영향을 줄일 수 있다. 즉, 장애로부터 상대적으로 강건한 fault tolerant한 시스템을 구성할 수 있다.
위의 예시와 동일한 서버1 -> 서버2 -> DB2 의 이벤트 플로우에서 서버2의 장애가 발생하더라도, 이벤트 스토어의 리텐션 기간 안에만 서버2의 장애가 복구된다면 이전에 받아왔던 메시지에 이어서 계속 메시지를 받아올 수 있을 것이다.

일시적으로 장애가 발생하더라도 event store에 저장되어 있는 데이터를 다시 활용할 수 있다.

Loosely Coupled System의 장점

The looser they are coupled,
the bigger they will scale,
the more fault tolerant they will be,
the less dependencies they will have,
the faster you will innovate.

Messaging Broker: Queue 방식과 Topic 방식

Queue 방식 : 메시지 큐에 넣어둔 메시지를 한번 consume하면 queue에서 삭제된다. point-to-point 방식이라고도 불린다.

Topic 방식 : pub/sub 방식.
Producer는 메시지를 publish한 이후, 그 데이터를 누가 얼마나 뽑아쓰든 신경쓰지 않는다. 많은 Consumer(Subscriber)가 붙어서 동시에 해당 데이터를 소비할 수 있다.

SQS : SNS : Kinesis 차이

AWS re:Invent 2018: Choosing the Right Messaging Service for Your Distributed App (API305)

SQS ( Simple Queue Service)

Queue 서비스.
메시지를 Pull형으로 처리한다.
standard 방식과 fifo 방식이 있다.
standard 방식은 scale out이 무한대로 가능한 대신, 메시지의 전달이 exactly once가 아닌 at least once 까지만 보장 된다. 또한 메시지의 순서도 best effort로, 보장되지는 않는다.
fifo 방식은 TPS 제한이 있는 대신, 메시지 전달이 exactly once로 보장되며 메시지의 순서가 보장된다.