Amazon SQS

결제 후 영수증 발송, 재고 반영, 추천 업데이트를 모두 바로 호출하면 느린 하위 시스템 하나가 전체 요청을 붙잡습니다. 트래픽이 몰릴 때 작업을 안전하게 쌓아두지 못하면 실패가 연쇄적으로 번집니다.

초기 시스템은 API가 후속 작업을 동기 호출로 이어 붙이는 구조가 많았습니다. 주문 API가 결제 서비스를 호출하고, 결제 서비스가 재고 서비스를 호출하고, 재고 서비스가 알림 서비스를 호출하는 식입니다. 이 체인에서 하위 서비스 하나가 응답을 2초 늦게 보내면, 그 지연이 상위 호출 전체에 전파됩니다. 최종 사용자가 보는 응답 시간은 체인 속 가장 느린 서비스의 합산이 됩니다. 하위 서비스가 타임아웃으로 실패하면 상위에서 재시도가 발생하고, 재시도가 또 하위로 내려가면서 장애 중인 서비스에 요청이 몰리는 재시도 폭풍이 일어났습니다. 하나의 느린 서비스가 전체 호출 체인을 멈추고, 결국 사용자에게까지 에러가 도달하는 일이 반복됐습니다. 이런 동기 체인의 취약함을 끊기 위해, 작업을 큐에 쌓아두고 소비자가 자기 속도로 꺼내 처리하는 비동기 분리 계층이 필요해졌고, 그 역할을 SQS가 맡게 됐습니다.

SQS는 메시지를 큐에 저장하고 소비자가 poll해서 처리하게 합니다. 가시성 제한, 재시도, DLQ(여러 번 실패한 메시지를 따로 격리해 원인 분석하게 하는 대기열)를 통해 실패를 격리하고, 처리량 급증도 흡수합니다. Standard 큐는 높은 처리량과 at-least-once 전달에 맞고, FIFO 큐는 순서와 정확히 한 번 처리 요구가 강한 흐름에 맞습니다.

SQS와 SNS는 둘 다 메시징이지만 처리 방식이 다릅니다. SQS는 메시지를 개별 작업 단위로 쌓아두고 소비자가 처리할 때까지 기다리는 큐이고, SNS는 한 이벤트를 여러 대상으로 즉시 퍼뜨리는 채널입니다. 처리 속도 차이를 흡수하고 재시도를 관리해야 하면 SQS를 보고, 같은 사건을 동시에 전파해야 하면 SNS를 보면 됩니다.

백그라운드 작업, 주문 후 비동기 처리, 이메일 발송, 버퍼링, 재시도가 필요한 파이프라인에 적합합니다. 한 이벤트를 여러 소비자에게 동시에 뿌려야 하는 브로드캐스트에는 맞지 않습니다.