Simple Queue Service(SQS)란 ?
분산 시스템를 구성할때 시스템간 메세지를 주고 받을 수 있는 메세지 큐
SQS는 전송,수신,삭제 3가지 기능을 제공한다.
SQS의 기본적인 아키텍처
- Producer가 메시지 전송을 하면 Queue가 수신한다.
- 수신된 메시지를 Consumer가 전달받아 처리한다.
- Consumer에서 수신된 메시지를 처리완료하면 방금 수신받은 메시지를 삭제해달라는 요청을 날린다.
위와 같이 요청 받은 Server가 바로 성공 실패 여부를 알려줄 필요가 없을때 위와 같은 아키텍쳐로 서버를 구성할 수 있다.
SQS Queue
SQS서비스에는 2가지 종류의 Queue가 존재한다.
Standard Queue(표준 대기열)
장점
- 초당 무제한에 가까운 TPS를 지원한다.
- 메시지 유실 가능성이 있지만 SNS와 사용할 경우 메시지 유실 가능성은 없다.
단점
- 메세지의 순차성을 보장해 주지 않는다.
- 동시에 메시지를 읽을 경우 하나의 메시지를 중복으로 수신할 수 있다.
FIFO Queue(순차 대기열)
장점
- 메시지의 순차성을 보장해 준다.
- 메시지 중복수신 가능성이 없다.
단점
- Standard Queue(표준 대기열) 보다 느리다. (초당 300개의 메시지 전송,수신,삭제)
- Standard Queue(표준 대기열) 보다 비싸다.
일반적으로 저렴한 가격과 높은 트래픽을 받을 수 있다는 장점때문에 Standard Queue(표준 대기열)을 많이 활용한다.
SQS Queue 옵션
표시 제한 시간
- 큐에 들어있는 메시지를 가져가면 최대 몇초동안 다른곳에 수신되지 않도록 안보이게 할건지에 대한 설정이다.
메시지 보존 기간
- 큐에 들어온 메시지를 언제까지 보관할 건지에 대한 설정이다.
- 설정한 일자만큼만 보관하고, 기간이 지나면 메시지를 삭제한다.
전송지연
- 큐에 추가된 메시지가 얼마동안 다른곳에 전송되지 못하도록 할건지에 대한 설정이다.
최대 메시지 크기
- 전송할 수 있는 메시지의 최대 크기를 설정합니다.
메세지 수신 대기 시간
- SQS에 수신메시지를 가져올 때 얼마동안 SQS에 수신대기를 할지 결정하는 설정이다.
- 해당 설정은 java SDK AmazonSQS 클래스에서 런타임에도 설정 가능하다. (메시지 별 waitTime을 런타임에 변경가능)
DLQ란?
Queue를 생성하면 DLQ라는 전송실패에 대한 실패큐가 같이 생성된다.
메시지를 받아서 처리후 큐에 해당 메시지를 잘 처리했고 이 메시지는 삭제해 주세요라는 요청을 날려야 한다.
메세지를 가져간 흔적은 있는데 삭제에 대한 요청이 오지 않는다면, DLQ로 해당 메세지는 빠지게된다.
최대 수신 수
- 어플리케이션에서 최대 몇번 동안 수신가능하도록 할건지에 대한 설정
- 예를들어 최대 수신수를 3으로 지정한다면, Worker에서 3번 메시지를 수신했는데 3번 전부 처리 실패하여 삭제요청을 안 날린 경우 해당 메시지는 DLQ에 저장된다.
SQS는 이러한 옵션으로 사용하기 쉽고 실시간으로 응답할 필요가 없는 작업들을 Queue에 넣어두고 처리 가능한 양만큼 꺼내서 처리하므로, 더 많은 트래픽을 받을 수 있는 비동기 모델을 완성 시킬 수 있다.
Short Polling & Long Polling
Short Polling은 메시지 받기 요청을 하면 결과를 바로 받는다.
메시지가 있으면 메시지를 가져오고 없으면 그냥 빠져나온다.
- ReceiveMessage 요청에서 WaitTimeSeconds를 0으로 설정했을 때
- 큐 설정의 ReceiveMessageWaitTimeSeconds를 0으로 설정했을 때
Long Polling은 메시지가 있으면 바로 가져오고, 메시지가 없으면 메시지를 제한 시간까지 기다린다.
기본 제한시간은 20초이며 1초부터 최대 20초까지 설정할 수 있다.
- ReceiveMessage요청의 WaitTimeSeconds가 0보다 크면 큐 설정의 ReceiveMessageWaitTimeSeconds 값보다 우선순위가 높다.
SQS에서는 기본적으로 Short Polling을 사용한다.
비용을 생각해서는 Long Polling으로 운영하는 것이 좋다.
SQS와 MQ의 차이점
SQS는 말그대로 간단한 Queue 서비스이므로 다른 MQ에서 지원하는 message routing, fan-out, distribution lists를 지원하지 않는다.
전송하는 메시지의 양이 많다면 SQS 대신 다른 MQ 서비스를 사용하는 것이 바람직하다.
만약 복잡한 요구사항을 구현해야 한다면 SQS 대신 Amazon MQ를 사용하면 유용하다.
Amazon MQ는 AMQT나 MQTT처럼 표준화 된 여러 broadcast 프로토콜을 완벽히 지원하는 fully managed 서비스이다.
AWS 외부에 존재하는 메시지 브로커를 AWS로 마이그레이션 하는데 사용하기도 한다.
다음 편에서는 직접 구현해서 정리해보겠다.
'AWS' 카테고리의 다른 글
Simple Queue Service 소개 및 사용법(3/3) (0) | 2021.10.26 |
---|---|
Simple Queue Service 소개 및 사용법(2/3) (0) | 2021.10.26 |
GitHub Action + S3 + CodeDeploy를 이용한 CI/CD (2/2) (2) | 2021.10.08 |
GitHub Action + S3 + CodeDeploy를 이용한 CI/CD (1/2) (0) | 2021.10.08 |
AWS S3 생성 및 설정, Spring Boot 적용 (0) | 2021.09.27 |