message-queuing

2 개의 포스트

aws4분 읽기큐레이션 요약

Amazon SQS 20주년: 대규모 환경에서 20년간 이어온 안정적인 메시징 | Amazon Web Services

Amazon SQS는 서비스 간 결합도를 낮추고 장애 전파를 막기 위해 메시지를 비동기적으로 전달하는 AWS의 관리형 메시지 큐 서비스다. 출시 20년 동안 FIFO 고처리량, 암호화 기본 적용, DLQ 복구, 대규모 메시지 처리 등 기능이 크게 발전했지만, 서비스 간 분리·트래픽 버퍼링·장애 격리라는 핵심 역할은 변하지 않았다. 최근에는 멀티테넌트 시스템과 AI 에이전트·추론 워크로드에도 활용 범위가 확대되고 있다. ## 비동기 메시징을 통한 서비스 결합도 완화 - 서비스가 서로 직접 호출하면 호출 대상의 지연이나 장애가 연쇄적으로 전체 시스템에 영향을 줄 수 있다. - SQS를 사용하면 생산자는 메시지를 큐에 저장한 뒤 작업을 계속하고, 소비자는 처리 가능한 시점에 메시지를 가져갈 수 있다. - 이를 통해 다음과 같은 효과를 얻는다. - 서비스 간 의존성 및 결합도 감소 - 트래픽 급증 시 메시지 큐를 버퍼로 활용 - 특정 서비스 장애가 전체 시스템으로 확산되는 것을 방지 - 소비자의 처리 속도에 맞춘 안정적인 작업 처리 ## FIFO 큐의 처리량과 동시성 향상 - 2021년 FIFO 큐 고처리량 모드가 출시되며 API 작업당 초당 3,000건(TPS)을 지원했다. - 이후 처리량이 단계적으로 증가했다. - 2022년: 6,000 TPS - 2023년 8월: 9,000 TPS - 2023년 10월: 18,000 TPS - 2023년 11월: 일부 리전에서 최대 70,000 TPS - 2024년에는 FIFO 큐의 인플라이트 메시지 한도가 20,000개에서 120,000개로 증가했다. - 소비자가 동시에 처리할 수 있는 메시지가 늘어나 대규모 순서 보장 처리에 유리해졌다. ## 암호화와 세분화된 접근 제어 - 2021년 SQS 관리형 키를 사용하는 서버 측 암호화 방식인 SSE-SQS가 도입됐다. - 2022년 10월부터 새로 생성되는 큐에는 SSE-SQS가 기본 적용됐다. - 고객이 직접 암호화 키를 생성하고 관리하지 않아도 메시지를 보호할 수 있다. - 2022년에는 ABAC(Attribute-Based Access Control)가 추가됐다. - 큐의 고정된 리소스 정책 대신 태그를 기준으로 권한을 부여할 수 있다. - 큐와 환경이 늘어나는 대규모 시스템에서 권한 정책 관리 부담을 줄인다. ## DLQ 메시지 복구 기능 강화 - 처리에 실패한 메시지를 보관하는 Dead-Letter Queue(DLQ)에서 원래 큐로 메시지를 되돌리는 기능이 단계적으로 확대됐다. - 2021년에는 SQS 콘솔에서 DLQ 메시지를 소스 큐로 직접 재전송할 수 있게 됐다. - 2023년에는 SDK와 CLI에서도 다음 API를 사용할 수 있게 됐다. - `StartMessageMoveTask`: 메시지 이동 작업 시작 - `CancelMessageMoveTask`: 이동 작업 취소 - `ListMessageMoveTasks`: 이동 작업 목록 조회 - 같은 해 FIFO 큐에도 redrive 기능이 지원됐다. - 운영 중 실패한 메시지를 수동으로 재처리하거나 별도 개발 없이 복구할 수 있다. ## 메시지 처리 성능과 연동성 개선 - 2023년 AWS SDK에 JSON 프로토콜 지원이 추가됐다. - 5KB 페이로드 기준 종단 간 처리 지연을 최대 23% 줄이고, 클라이언트의 CPU·메모리 사용량도 낮췄다. - SQS 콘솔에서 EventBridge Pipes와 큐를 직접 연결할 수 있게 됐다. - 별도의 통합 코드를 작성하지 않고도 큐 메시지를 다양한 AWS 서비스 대상으로 라우팅할 수 있다. ## 대용량 메시지와 페이로드 확장 - 2024년 Python용 Extended Client Library가 제공됐다. - 최대 2GB 크기의 메시지를 Amazon S3에 저장하고, SQS에는 해당 데이터의 참조 정보만 전달할 수 있다. - 2025년에는 표준 큐와 FIFO 큐의 최대 메시지 크기가 256KiB에서 1MiB로 증가했다. - AWS Lambda의 SQS 이벤트 소스 매핑도 이 새로운 페이로드 크기를 지원하도록 업데이트됐다. ## 멀티테넌트 환경을 위한 공정한 처리 - 2025년 표준 큐에 fair queues가 도입됐다. - 메시지를 보낼 때 메시지 그룹 ID를 포함하면 특정 테넌트가 큐를 독점하는 ‘시끄러운 이웃(noisy neighbor)’ 문제를 완화할 수 있다. - 소비자 측 코드를 변경하지 않고도 한 테넌트의 대량 메시지가 다른 테넌트의 처리 지연을 유발하는 상황을 줄일 수 있다. ## AI 시스템으로 확장되는 SQS의 활용 - SQS의 기본 패턴은 AI 워크로드에도 적용된다. - 활용 사례는 다음과 같다. - 대규모 언어 모델 요청을 큐에 저장해 추론 요청량 조절 - 추론 처리량을 소비자 수와 처리 속도에 맞춰 관리 - 독립적으로 동작하는 AI 에이전트 간 작업과 통신 조정 - AI 서비스가 일시적으로 느려지거나 중단돼도 요청을 큐에 보관해 전체 시스템의 안정성을 유지할 수 있다. 실무에서는 서비스 간 직접 호출이 장애 전파나 트래픽 급증 문제를 일으키는 경우 SQS를 우선 검토할 수 있다. 순서 보장과 중복 처리 방지가 필요하면 FIFO 큐를, 실패 메시지 복구가 중요하면 DLQ와 redrive 기능을 함께 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)
datadog원문

신뢰할 수 있는 분산 시스템을 설계하기 위해 형식 모델링, 경량 시뮬레이션, 카오스 테스트를 활용하는 방법 (새 탭에서 열림)

분산 시스템의 복잡성으로 인해 발생하는 시스템 수준의 설계 오류를 해결하기 위해, 데이터독(Datadog)은 차세대 메시지 큐 서비스인 'Courier'의 설계 과정에서 포멀 모델링(Formal Modeling)과 경량 시뮬레이션을 도입했습니다. 이 방식은 전통적인 단위 테스트나 카오스 테스트가 발견하기 어려운 고차원적인 설계 결함을 설계 단계에서 미리 검증하고, 시스템의 성능 특성을 통계적으로 예측할 수 있게 해줍니다. 결과적으로 이러한 접근법은 가용성과 신뢰성이 필수적인 핵심 인프라 서비스가 복잡한 실패 모드에서도 안정적으로 동작함을 확인하는 강력한 도구가 되었습니다. **포멀 모델링과 경량 시뮬레이션의 도입** - **포멀 모델링(Formal Modeling):** 고수준의 명세 언어를 사용해 시스템의 속성을 기술하고, 모델 체커를 통해 발생 가능한 모든 상태를 전수 조사함으로써 설계상의 논리적 결함이 없는지 검증합니다. - **경량 시뮬레이션(Lightweight Simulation):** 포멀 모델링이 확인하기 어려운 지연 시간(Latency), 비용, 확장성 등의 통계적 성능 지표를 실제 부하 환경과 유사한 조건에서 실행하여 분석합니다. - **도입 배경 및 트레이드오프:** 구현 자체를 검증하지는 못하고 모델 유지 보수의 오버헤드가 발생하지만, 대규모 장애(2023년 3월 사례)를 방지하고 설계의 정확성을 보장하기 위해 도입되었습니다. **차세대 메시지 큐 서비스: Courier** - **배경:** 기존 Redis 기반 시스템의 처리량 및 확장성 한계를 극복하기 위해 설계된 멀티테넌트 메시지 큐 서비스입니다. - **최소 1회 전달(At-least-once delivery):** 메시지 손실 없이 전송을 보장하며, 실패 시 데드 레터 큐(DLQ)로 이동하여 알림 누락을 방지합니다. - **점진적 성능 저하(Graceful Degradation):** 가용 컴퓨팅 자원이 줄어들더라도 처리량이 급격히 추락하지 않고 선형적으로 감소하도록 설계하여 전체 서비스 마비를 방지합니다. - **수평적 확장성:** 컴퓨팅 자원 추가에 따라 처리량이 선형적으로 증가하는 구조를 목표로 합니다. **멀티테넌시 및 고가용성을 위한 아키텍처** - **FoundationDB 기반 샤딩:** 여러 개의 FoundationDB 클러스터를 구축하고, 각 테넌트를 특정 클러스터 조합(예: 8개 중 4개 선택)에 샤딩하여 테넌트 간 간섭을 최소화합니다. - **폭발 반경(Blast Radius) 제어:** 특정 테넌트가 4개의 클러스터에 부하를 주더라도, 다른 테넌트는 최소 25% 이상의 가용 용량을 확보할 수 있도록 격리 수준을 높였습니다. - **브로커 레이어(Broker Layer):** gRPC API를 통해 샤딩 로직을 처리하고, 백엔드 클러스터의 상태 점검(Health Check)을 수행하며 3개의 가용 영역(AZ)에 분산 배치되어 고가용성을 유지합니다. 이러한 포멀 모델링과 시뮬레이션 기법은 복잡한 분산 시스템을 구축할 때 직관에 의존하는 대신 수학적·통계적 근거를 바탕으로 의사결정을 내릴 수 있게 합니다. 특히 Courier와 같이 신뢰성이 최우선인 기반 시스템을 설계할 때, 초기 단계에서의 철저한 검증은 추후 발생할 수 있는 막대한 수정 비용과 대규모 장애 위험을 줄이는 데 매우 효과적인 투자입니다.