Amazon SQS 20주년: 지난 20년간 대규모 안정적 메시징 기능 제공

2006년 7월 13일, Amazon EC2 및 Amazon S3와 함께 고객이 사용할 수 있는 최초의 세 가지 서비스 중 하나로 Amazon Simple Queue Service(Amazon SQS)를 출시했습니다. 분산 시스템에서 구성 요소 간의 결합도를 높이지 않으면서 메시지를 전달할 수 있는 안정적인 방법이 필요하다는 것을 직접 알게 되었습니다. 한 서비스가 다른 서비스를 직접적으로 호출했는데 해당 서비스가 느리거나 사용할 수 없는 경우 전체 시스템에 장애가 연쇄적으로 발생했습니다. 메시지 대기열은 서비스들이 비동기적으로 통신할 수 있도록 하여 이 문제를 해결했습니다. 즉, 생산자는 메시지를 대기열에 놓고 작업을 계속 할 수 있으며 소비자는 준비가 되었을 때 메시지를 가져가는 방식이었습니다. 이러한 접근 방식은 개별 서비스의 장애가 시스템의 나머지 부분에 영향을 미치는 것을 방지했습니다.

2006년 7월에 Amazon SQS가 공식 출시되면서, 모든 AWS 고객이 이 패턴을 사용할 수 있게 되었습니다. 20년이 지난 지금도 생산자와 소비자를 분리한다는 그 핵심 기능은 고객들이 여전히 SQS를 사용하는 이유로 남아 있습니다. 하지만 그 주변의 규모, 성능, 운영 제어 기능은 지금과 많이 달라졌습니다.

Jeff Barr는 SQS의 15주년 기념 게시물에서 2006년 당시 8KB였던 메시지 제한부터 FIFO 대기열, 서버 측 암호화, Lambda 통합에 이르기까지, SQS가 걸어온 지난 15년간의 주요 이정표를 다루었습니다. 지난 5년 동안 SQS의 규모를 지속적으로 확장하고, 보안 기본값을 강화했으며, 점점 더 복잡해지는 워크로드 패턴을 해결하는 새로운 기능을 도입했습니다.

2021년과 2026년 사이의 주요 이정표
FIFO 대기열의 높은 처리량 모드(2021): 2021년 5월에 FIFO 대기열을 위한 고처리량 모드를 정식 출시했습니다. 이 모드는 API 작업당 초당 최대 3,000건의 트랜잭션(TPS)을 지원하며, 이는 이전 제한 대비 10배 증가한 수치입니다. 그리고 이후 2년 동안 이 상한선을 계속 높여갔습니다. 2022년 10월에는 6,000 TPS로, 2023년 8월에는 9,000 TPS로, 2023년 10월에는 18,000 TPS로 상향했으며, 2023년 11월에는 특정 리전에서 API 작업당 7만 TPS에 도달했습니다.

SSE-SQS를 이용한 서버 측 암호화(2021년): 2021년 11월에 Amazon SQS 관리형 암호화 키(SSE-SQS)를 이용한 서버 측 암호화를 도입하여, 고객이 키 관리를 직접 할 필요가 없는 암호화 옵션을 제공하기 시작했습니다. 2022년 10월에 새로 생성되는 모든 대기열에 SSE-SQS가 기본적으로 적용되도록 변경하여, 고객이 더 이상 이를 별도로 활성화할 필요가 없게 되었습니다.

Dead Letter Queue(DLQ) 재처리 기능 개선(2021년): 고객이 Dead Letter Queue(DLQ)에서 소비되지 않은 메시지를 복구하는 방식을 점진적으로 확장했습니다. 2021년 12월에는 SQS 콘솔에서 DLQ의 메시지를 원본 대기열로 직접 재처리할 수 있는 기능을 추가했습니다. 2023년 6월에 StartMessageMoveTask, CancelMessageMoveTask, ListMessageMoveTasks와 같은 새로운 API를 통해 이 기능을 AWS SDK 및 CLI로 확장했습니다. 2023년 11월에는 FIFO 대기열에 대한 재처리 지원 기능을 추가했습니다.

속성 기반 액세스 제어(ABAC)(2022년): 2022년 11월에 ABAC를 도입하여 고객이 리소스가 확장됨에 따라 정적 정책을 유지하는 대신 대기열 태그를 기반으로 액세스 권한을 구성할 수 있게 되었습니다.

JSON 프로토콜 지원(2023년): 2023년 11월에 AWS SDK에서 JSON 프로토콜 지원을 추가했습니다. 이를 통해 5KB 페이로드 기준으로 종단 간 메시지 처리 지연 시간을 최대 23%까지 줄였으며, 클라이언트 측의 CPU 및 메모리 사용량을 낮췄습니다.

Amazon EventBridge Pipes 콘솔 통합(2023년): SQS 콘솔에서 대기열을 EventBridge Pipes에 직접 연결하는 기능을 추가하여, 별도의 사용자 지정 통합 코드 작성 없이도 메시지를 다양한 AWS 서비스 대상으로 라우팅할 수 있게 되었습니다.

Python용 확장 클라이언트 라이브러리(2024년): 기존에 Java에서만 사용할 수 있었던 확장 클라이언트 라이브러리를 Python 개발자들에게도 제공하게 되었습니다. 이를 통해 페이로드를 Amazon S3에 저장하고 대기열을 통해 참조를 전달하는 방식으로, 최대 2GB 크기의 메시지를 SQS로 전송할 수 있게 되었습니다.

FIFO 인플라이트 메시지 제한 상향(2024년): FIFO 대기열의 인플라이트 메시지 제한을 기존 2만 개에서 12만 개로 상향 조정했습니다. 이를 통해 소비자는 이전 제한에 구애받지 않고 훨씬 더 많은 메시지를 동시에 처리할 수 있게 되었습니다.

다중 테넌트 워크로드를 위한 공정한 대기열(2025년): 다중 테넌트 표준 대기열에서 발생하는 노이지 네이버 문제를 완화하기 위해 공정한 대기열 기능을 도입했습니다. 메시지를 보낼 때 메시지 그룹 ID를 포함하면, 소비자 측에서 별도의 변경 사항 없이도 특정 테넌트가 다른 테넌트의 메시지 전달을 지연시키는 것을 방지할 수 있습니다.

최대 1 MiB 메시지 페이로드 크기 지원(2025년): 표준 대기열과 FIFO 대기열 모두에서 최대 메시지 페이로드 크기를 기존 256KiB에서 1MiB로 상향했습니다. 이를 통해 고객은 데이터를 외부 저장소로 옮길 필요 없이 더 큰 메시지를 직접 전송할 수 있게 되었습니다. SQS용 AWS Lambda 이벤트 소스 매핑이 새 페이로드 크기를 지원하도록 병렬로 업데이트되었습니다.

변화 이면의 상수
지난 20년간 수많은 기능이 추가되었음에도 불구하고, SQS의 근본적인 사용 사례는 변하지 않았습니다. 고객은 SQS를 사용하여 서비스를 분리하고, 트래픽 폭발을 완충하고, 개별 구성 요소에 장애가 발생해도 복원력을 유지하는 시스템을 구축합니다. 이제 동일한 패턴이 AI 워크로드로 확장됩니다. 고객은 SQS 대기열을 사용하여 요청을 대규모 언어 모델에 버퍼링하고, 추론 처리량을 관리하고, 독립 서비스로 작동하는 자율 AI 에이전트 간의 통신을 조정합니다. 이 아키텍처가 실제로 적용된 사례를 보려면, Creating asynchronous AI agents with Amazon Bedrock 문서를 읽어보세요.

Amazon SQS에 대해 자세히 알아보려면 Amazon SQS 제품 페이지를 방문하거나 개발자 안내서를 검토하거나 AWS Blog에서 최신 업데이트를 살펴보세요.

— Esra