What is AWS? _3

이번 시간에는 AWS에서 제공하는 Message Queue에 대해 알아보도록 하자

🤔 Message Queue 란?

• 분산 시스템에서 비동기적으로 메시지를 주고받기 위한 기술
• Producer(메시지 발행자)가 메시지를 Queue에 쓰고, Consumer(메시지 수신자)가 해당 Queue에 메시지를 읽어서 처리하는 구조
• Producer와 Consumer는 비동기적으로 동작하기 때문에 메세지를 발행하고 해당 메세지를 처리하는 시간이 다르더라도 큰 문제가 없다.
• Queue에 쌓인 메세지를 저장하는 스토리지 역할을 하기도 한다. : 시스템 장애로 인한 손실 최소화
• 분산시스템에서 확장성과 유연성을 높이기 위해 자주 사용되며, 비동기적으로 메시지를 처리함으로써 시스템의 응답성과 처리량을 높일 수 있다.
• ex. RabbitMQ, Apache Kafka, Aws SQS
  
  
  

1) AWS SQS

출처 : https://tkssharma.com/aws-serverless-difference-between-sns-sqs-event-bridge/

• MSA, 분산 시스템 및 서버리스 애플리케이션을 위한 완전관리형 메시지 대기열

• 표준 대기열

  • 무제한 처리량
  • 최소한 한 번 전달 == 여러번 전달 될 수 있음
  • 최선 노력 순서
  • 순서가 보장되지 않음
  • 무조건 순서가 보장되지 않아도 되는 서비스와 로그 서비스에서 주로 사용

• FIFO

  • 초당 300개 이상의 메시지
  • 정확히 한 번 처리
  • 선입선출 = 순서가 지켜진다.

• dead letter queue

  • SQS에서 메세지를 전달했을 때, 제대로 전달되지 않은 경우, dead letter queue에 해당 오류를 기록하고 다시 retry 시킨다.

• 보통 SQS는 FIFO로 사용한다.

• SQS에 잔존되는 데이터 보존 기간을 정할 수 있다.

• Visibilty timeout(가시성 제한시간)

  • SQS는 분산 시스템이므로 연결 문제나 consumer의 애플리케이션 문제로 인하여 메시지를 제대로 수신 하지 못하는 경우가 발생한다.
  • 그러므로 consumer는 메세지를 정성적으로 수신하고 처리한 후 대기열에서 메세지를 삭제해야한다.
  • 특정 메세지를 특정 consumer가 메세지를 받으면 해당 consumer가 처리하는 시간동안 다른 consumer가 해당 메세지를 처리하지 못하도록 하는 기간을 visibility timeout라고 한다.

• SQS 생명주기

  1) produser 는 메세지A를 대기열로 보내고 메세지는 SQS 서버에 중복으로 배포된다.
  2) consumer가 메세지 처리할 준비가 되면 대기열에서 메세지를 소비하고 메세지A가 반환된다. 대기열에는 메세지A가 남아 있으나 가시성 제한 시간 동안 반환되지 않는다.
  3) consumer는 메세지A를 대기열에서 삭제하여 가시성 제한 시간이 만료되면 메세지가 다시 수신 되지 않도록 처리한다.
  

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

2) AWS Kinesis

출처 : https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html#shard

• 유연한 메세지 큐
• 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리할 수 있는 핵심 기능과 애플리케이션 요구 사항에 가장 적합한 도구를 선택할 수 있는 유연성을 제공
• SQS보다 더 많은 처리량을 가지고 있다.
• 샤드(shard) 라는 구조를 가지고 있다.
  • stream에서 고유하게 식별되는 데이터 레코드 시퀀스
  • stream은 하나 이상의 샤드로 구성되며, 각 샤드는 고정된 용량단위를 제공
  • stream의 총 용량은 샤드 용량의 합
• 메세지A를 받았을 때, 해당 메세지가 샤드를 통해 consumer에게 전달된다.
• 샤드가 여러개라면 순서를 지키기 어렵다. 샤드가 하나인 경우에만 순서를 지킬 수 있다.
• 그러므로 순서를 지키는 것이 중요한 서비스(ex. 은행 서비스, 예약 서비스)라면, SQS를 사용하는 것이 바람직하다.
• 들어오는 메세지의 양이 예측이 된다면 프로비저닝, 그렇지 않으면 온디맨드 형식을 사용하는것이 낫다.
  • 온디맨드가 좀 더 비싸다.
• S3에 로그가 남는다.

3) SQS vs Kinesis

• Kinesis는 빅데이터 스트림의 실시간 처리에 적합하고 SQS는 분산 시스템 간의 메세지 전송에 적합
• Kinesis는 dead letter queue가 없기 때문에 이벤트가 실패하면 다시 재시도 할 방법이 없다. 그러므로 따로 예외처리를 해주어야 한다.
• SQS는 메세지의 순서와 보장이 잘 되어야 하는 서비스에서 사용하는 것이 좋다.
• 메세지 용량의 차이가 있다.
  • Kinesis : 1MB
  • SQS : 256KB
• 오토 스케일링
  • Kinesis : 따로 설정을 해줘야 함
  • SQS : 자동으로 됨
• retention : 메세지가 queue에 남아있는 기간
  • Kinesis : 필요할 때 마다 샤드에서 꺼내 사용할 수 있다.
    • 샤드에 꺼내서 사용해도 보존기간 동안 잔존하기 때문에 기간안에는 언제든지 사용 가능
  • SQS : 한번 사용하면 다시 사용할 수 없다.

출처 및 참고
https://docs.aws.amazon.com/streams/latest/dev/introduction.html
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
https://docs.aws.amazon.com/index.html
원티트 프리온보딩 5월 백엔드 과정