Amazon SQS
SQS는 작업 메시지를 안전하게 잠시 쌓아 두었다가 소비자가 꺼내 처리하게 하는 대기열입니다. 생산자와 소비자의 속도를 분리하고 재시도와 실패 격리를 통해 비동기 작업을 안정화합니다.
▶아키텍처 다이어그램
📊 데이터 흐름 다이어그램점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다
결제 후 영수증 발송, 재고 반영, 추천 업데이트를 모두 바로 호출하면 느린 하위 시스템 하나가 전체 요청을 붙잡습니다. 트래픽이 몰릴 때 작업을 안전하게 쌓아두지 못하면 실패가 연쇄적으로 번집니다.
초기 시스템은 API가 후속 작업을 바로 호출하는 경우가 많았지만, 부하가 오르면 연쇄 실패가 쉽게 일어났습니다. 그래서 생산자와 소비자를 분리하고 작업을 흡수하는 큐 기반 아키텍처가 중요해졌습니다.
SQS는 메시지를 큐에 저장하고 소비자가 poll해서 처리하게 합니다. 가시성 제한, 재시도, DLQ(여러 번 실패한 메시지를 따로 격리해 원인 분석하게 하는 대기열)를 통해 실패를 격리하고, 처리량 급증도 흡수합니다. Standard 큐는 높은 처리량과 at-least-once 전달에 맞고, FIFO 큐는 순서와 정확히 한 번 처리 요구가 강한 흐름에 맞습니다.
SQS와 SNS는 둘 다 메시징이지만 처리 방식이 다릅니다. SQS는 메시지를 개별 작업 단위로 쌓아두고 소비자가 처리할 때까지 기다리는 큐이고, SNS는 한 이벤트를 여러 대상으로 즉시 퍼뜨리는 채널입니다. 처리 속도 차이를 흡수하고 재시도를 관리해야 하면 SQS를 보고, 같은 사건을 동시에 전파해야 하면 SNS를 보면 됩니다.
SNS
푸시 알림 및 메시징
둘 다 메시징 도구지만 SQS는 작업을 안전하게 옮기는 큐잉 계층이고, SNS는 이벤트를 여러 소비자로 즉시 확장 전파하는 팬아웃 채널입니다.
Step Functions
서버리스 워크플로 오케스트레이션
둘 다 이벤트 흐름을 다루지만, SQS는 작업 메시지를 버퍼링하고 전달 대상을 기다리는 큐이고 Step Functions는 상태 기반 다단계 절차를 오케스트레이션하는 엔진입니다.
Kinesis
실시간 스트리밍 데이터 처리
둘 다 비동기 데이터 흐름에 쓰이지만, SQS는 개별 작업을 안전하게 소비하는 큐이고 Kinesis는 시간 순서가 중요한 연속 스트림 처리에 강합니다.
백그라운드 작업, 주문 후 비동기 처리, 이메일 발송, 버퍼링, 재시도가 필요한 파이프라인에 적합합니다. 한 이벤트를 여러 소비자에게 동시에 뿌려야 하는 브로드캐스트에는 맞지 않습니다.