AWS 메시징 서비스 비교 (Kinesis vs SQS vs SNS vs MQ)

Kinesis (https://aws.amazon.com/ko/kinesis)
Simple Queue Service (https://aws.amazon.com/ko/sqs/)
SNS (https://aws.amazon.com/ko/sns/)
Amazon MQ (https://aws.amazon.com/ko/amazon-mq)

 

• Amazon Kinesis Stream
  • Kafka의 AWS 버전 
  • 빅데이터 스트리밍을 실시간으로 처리
  • 여러 Amazon Kinesis Application 의 레코드 읽고 응답 가능
  • Amazon Kinesis Client LIbrary(KCL) 을 이용하여 파티션 키에 대한 모든 레코드를 동일한 레코드 프로세서에 제공
    • 스트림에서 계산, 집계, 필터링 수행 가능
  • pub/sub 모델의 특징으로, 데이터의 consume 여부와 관계없이 지정한 retention time만큼 데이터를 저장한다. 

• SQS: Simple Queue Service
  • 가벼운 관리형 메시지 대기열
  • pull(polling) 기반으로 메시지 처리 (즉, 메시지 가져오기 방식)
  • standard 방식과 fifo 방식이 있다.
    standard 방식은 scale out이 무한대로 가능한 대신, 메시지의 전달이 exactly once가 아닌 at least once 까지만 보장 된다. 또한 메시지의 순서도 best effort로, 보장되지는 않는다.
    fifo 방식은 TPS 제한이 있는 대신, 메시지 전달이 exactly once로 보장되며 메시지의 순서가 보장된다. 
• SNS
  • Fan-out architecture
  • 메시지를 Push 방식으로 처리한다.
  • 여러 Subscriber에게 메시지를 전송할 수 있다.
    특징은, 한 토픽 안에서도 Filter 기능을 제공해서 Subscriber별로 원하는 메시지를 보낼 수 있다.
• Amazon MQ 
  • On-Promise에서 사용하던 Message Queue 를 이관시 유리
  • MOM 기반의 서비스 표준은 어떠한 것이라도 Amazon MQ로 이관 가능
  • 신규로 클라우드 베이스 서비스 개발을 할때는 고려할 필요 없음.

 

Rabbit MQ vs SQS : SQS → 더 간단하게 구현 가능. https://www.educba.com/rabbitmq-vs-sqs/

Amazon MQ vs SQS :  SQS  https://veluxer62.github.io/explanation/amazon-mq-vs-sqs/

SQS vs SNS vs Kinesis

Kinesis vs SQS

• Kinesis는 로그, 클릭스트림 데이터 등의 실시간 분석 목적에 적합하다. 또는 여러 Application이 하나의 스트림을 동시에 사용하고자 할 때 적합하다.
• SQS는 Application 통합, 분산 시스템 연계에 적합하다.

Amazon MQ란

AWS에서 메시지 브로커를 쉽게 설정하고 운영할 수 있도록 지원하는 Apache ActiveMQ 및 RabbitMQ용 관리형 메시지 브로커 서비스입니다. Amazon MQ는 메시지 브로커의 프로비저닝, 설정, 유지보수를 대신 관리하여 운영 부담을 덜어줍니다. Amazon MQ는 산업 표준 API 및 프로토콜을 사용하여 기존 애플리케이션에 연결하기 때문에 코드를 다시 쓰지 않고도 AWS로 쉽게 옮길 수 있습니다.

SQS(Simple Queue Service)란

SQS는 AWS(Amazon Web Service)에서 제공하는 Simple Queue Service의 약자로 분산 큐(Distributed Queues) Saas 서비스입니다. SQS의 요소에는 3가지가 있습니다. 사용하는 서버와 분산 큐(SQS)와 주고받는 메시지입니댜. 아래 이미지를 보시겠습니다. 기본적으로 SQS와 사용자간에 주고받는 메시지의 흐름을 나타낸 것입니다.

 

sqs-basic-architecture, 출처 : https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html

 

1. 메시지를 생산하는 서버(위의 Component 1)에서 메시지를 SQS에 전송합니다. 그리고 이 메시지는 SQS에 동일한 값이 여러곳에 중복으로 저장됩니다.
2. 메시지를 소비하는 서버(위의 Component 2)에서 메시지를 처리할 준비가되면 큐에서 메시지를 가져옵니다. 메시지가 한 서버에 의해서 처리될 동안 SQS에서는 메시지가 없어지지않고 그대로 남아있습니다. 한 서버에서 처리 중일 때 다른 서버에서 중복으로 읽지 못하게 하기 위해 visibility timeout을 사용합니다. 해당 설정은 어떤 것인지 아래에서 자세히 보겠습니다.
3. 메시지를 소비하던 서버에서 sqs에 delete 메시지를 전달합니다. 이렇게 하면 SQS에 있는 중복 분산되어있던 해당 메시지가 삭제되게 됩니다.

Queue 관리하기

위에서는 시스템적인 관점에서 SQS에 대해서 알아보았습니다. 이번에는 메시지의 관점에서 한번 알아보도록 하겠습니다. 메시지는 아래와 같은 라이프사이클을 가지게 됩니다. 각 단계에 대해서 이미지 아래에 자세히 설명하도록 하겠습니다.

 

sqs_visibility_timeout, 출처 : https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html

 

1. 프로듀싱서버에서 SQS로 메시지를 전달하는 단계입니다.
   • Delivery Delay를 설정할 수 있습니다.
2. 메시지가 SQS에 머무르는 단계입니다.
   • 메시지가 머무르는 시간(Retention)을 설정할 수 있습니다.
   • 최대 메시지의 사이즈를 정할 수 있습니다.
3. 컨슈밍서버에서 SQS의 서버를 가져가는 단계입니다.
   • Visibility Timeout을 설정할 수 있습니다.
   • 컨슈밍서버에서 Polling Message Count를 정할 수 있습니다.
   • Long Time Polling과 Short Time Polling을 정할 수 있습니다.

SQS에서 사용하는 용어에 대해서 한번 정리하고 가겠습니다.

• Delivery Delay라는 것은 프로듀싱서버에서 SQS로 메시지를 전달했을 때 Queue에 바로 넣을지 아니면 조금 시간을 두고 넣을지를 정하는 설정입니다. sync 등의 이유로 Queue의 메시지를 바로 컨슘하면 안될 때 사용할 수 있습니다.
• Retention이라는 것은 SQS에 메시지가 머무를 수 있는 최대시간을 말합니다. 해당 시간이 지나면 메시지는 삭제됩니다.
• Visibility Timeout이란 중복 처리를 막기위해 컨슈밍서버 한대가 컨슘했을 때 다른 서버들은 컨슘할 수 없게하는 대기시간을 말합니다. 다른 서버에서 컨슘하기 위해서는 Visibility Timeout을 기다릴 수 밖에 없습니다.
• Polling Message Count란 컨슈밍서버에서 한번의 요청으로 SQS에 있는 데이터를 가져올 수 있는 숫자입니다.
• Long Time Polling과 Short Time Polling은 컨슈밍서버에서 컨슘했을 때 만약 queue가 비어있다면 얼마나 대기할 건지에 대한 부분입니다. Short Time Polling은 Receive message wait time이 0초이며 나머지는 Long Time Polling으로 정의하고 있습니다.

Polling Message Count를 제외하고는 SQS Console을 통하여 각각 설정할 수 있습니다. 설정을 저장하게 되면 다음으로 오는 메시지부터 변경된 설정으로 적용되게됩니다. 아래는 SQS Console에 나와있는 설정화면입니다. 대부분 설정 내용과 설정 이름이 동일합니다.

 

sqs_console, configuration

 

FIFO Queue

AWS에서 제공하는 SQS 타입에는 2가지가 있습니다. standard와 fifo입니다. standard는 속도가 빠른 대신 중복 처리 및 선입선출에 대한 부분에 대해서 단점을 가지고 있습니다. 그래서 AWS에서는 선입선출을 반드시 지킬 수 있고 중복제거도 제공해주는 타입의 FIFO라는 타입의 SQS를 제공하고있습니다. 단점으로는 SQS 기준으로 요청을 300 TPS 정도밖에 처리할 수 없다고 합니다. 본인이 구축하고 있는 시스템의 구성에 맞춰 구성할 필요가 있을것 같습니다. 

 

TPS : Transaction per second, 초당 트랜잭션의 개수. 일정기간동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경하여 계산합니다.

 

위 그림에 두번째 행을 보면 5개의 트랜잭션이 실행완료된 것을 볼 수 있습니다. 이런 경우 TPS를 구하는 방법은 5 transaction / 5 sec 이므로 결과값은 1 TPS가 됩니다. https://brunch.co.kr/@leedongins/27

 

 

sqs_console, create queue

 

과금 방법

SQS의 과금은 2가지를 합산하여 계산됩니다.

• 요청 1백만 건당 비용
  • 요청이라함은 enqueue와 dequeue를 모두 포함합니다.
• 네트워크 비용
  • 기본적으로 AWS의 모든 서비스는 네트워크 비용이 별도로 청구됩니다.