SQS 메시지 필터링 및 SNS와 SQS 통합

필터링이 없는 팬아웃 아키텍처에서는 모든 SQS 구독자가 모든 SNS 메시지를 받습니다. 토픽이 10가지 제품 범주의 주문 이벤트를 게시하지만 구독자는 전자 제품 주문만 처리한다고 가정해 보겠습니다. 이 경우에도 구독자는 식품 및 의류 메시지를 받아 폐기해야 합니다. 이는 컴퓨팅 리소스를 낭비하고 비용을 증가시키며 소비자에 불필요한 부하를 추가합니다. SNS 구독 필터 정책을 사용하면 SNS 자체가 적절한 구독자에게만 메시지를 라우팅하므로 이 문제를 해결할 수 있습니다.

필터 정책은 SQS 또는 람다 구독에 적용되는 JSON 객체입니다. SNS는 전달하기 전에 각 메시지의 메시지 속성을 정책과 비교합니다. 메시지 속성이 필터 정책과 일치하면 메시지가 전달되고, 일치하지 않으면 SNS가 해당 구독자를 조용히 건너뜁니다. 필터 정책은 문자열 일치, 숫자 범위, 접두사 일치와 속성의 존재 여부를 확인하는 exists 연산자를 지원합니다.

기본적으로 필터 정책은 메시지 속성(메타데이터)을 기준으로 일치 여부를 판단합니다. 2023년부터 SNS는 필터 정책 범위를 MessageBody로 설정하여 페이로드 기반(본문) 필터링도 지원합니다. 이를 사용하면 게시자가 속성을 추가하지 않아도 메시지 본문에 직접 JSON 경로 기반 필터링을 적용할 수 있습니다. 본문 필터링은 더 유연하지만 메시지 본문이 유효한 JSON이어야 합니다. 항상 게시자의 출력 형식에 맞는 범위를 선택했는지 확인하십시오.

필터 정책은 단순한 문자열 동등성 비교 외에도 여러 일치 연산자를 지원합니다.

• 숫자: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• 접두사: {"prefix": "order-"}는 해당 접두사로 시작하는 모든 문자열과 일치합니다.
• 제외: {"anything-but": ["CANCELLED"]}는 나열된 값을 제외한 모든 값과 일치합니다.
• 존재 여부: {"exists": true}는 속성이 있으면 일치하고, false는 속성이 없으면 일치합니다.

필터링이 작동하려면 게시자가 SNS에 게시할 때 메시지 속성을 포함해야 합니다. 속성은 데이터 유형(String, Number, Binary)을 가진 키-값 쌍입니다. 게시자는 어떤 구독자가 어떤 필터 정책을 사용하는지 알 필요가 없습니다. 이벤트를 설명하는 속성으로 메시지를 보강하기만 하면 SNS가 자동으로 라우팅합니다. 따라서 게시자는 구독자별 로직과 완전히 분리된 상태를 유지할 수 있습니다.

정교한 팬아웃 토폴로지에서는 SNS가 여러 수준의 세분화로 SQS 대기열에 라우팅할 수 있습니다. 한 대기열은 감사 목적으로 모든 주문을 필터 없이 받고, 다른 대기열은 사기 검토를 위해 HIGH_VALUE 주문(amount >= 1000)만 받으며, 세 번째 대기열은 전자 제품 창고를 위해 ELECTRONICS 주문만 받습니다. 각 SQS 대기열에는 자체 람다 소비자가 있습니다. 이 패턴을 사용하면 각 처리 계층을 독립적으로 확장하고, 기존 계층이나 게시자를 수정하지 않고 새 소비자를 추가할 수 있습니다.

SNS는 다른 AWS 계정에 있는 SQS 대기열로 전달할 수 있습니다. SQS 대기열의 리소스 기반 정책은 게시 계정의 SNS 토픽 ARN에서 sqs:SendMessage를 호출할 수 있도록 SNS 서비스 주체를 허용해야 합니다. 이를 통해 자격 증명을 공유하지 않고 중앙 집중식 이벤트 게시(한 계정이 게시하고 여러 계정 팀이 구독)가 가능합니다. 계정 간 팬아웃은 여러 계정으로 구성된 AWS Organizations 환경에서 일반적으로 사용되는 패턴입니다.

이벤트 볼륨이 급증하면 SNS에서 람다를 직접 호출할 때 람다가 즉시 확장되어 다운스트림 데이터베이스나 API에 과부하를 일으킬 수 있습니다. SNS와 람다 사이에 SQS를 추가하면 버퍼가 생성됩니다. SNS가 SQS로 전달하고 람다가 제어된 배치 크기로 SQS를 폴링합니다. 따라서 람다는 지속 가능한 속도로 처리하고 SQS는 트래픽 급증을 흡수할 수 있습니다. 대기열의 깊이는 백프레셔 메커니즘으로 작동하므로 이를 모니터링하고 소비자 지연을 나타내는 임계값을 초과해 증가하면 알림을 보낼 수 있습니다.

SNS → 람다(직접): 지연 시간이 가장 짧고 버퍼링이 없으며 람다가 즉시 확장됩니다. 1초 미만의 지연 시간이 중요한 실시간 알림이나 긴급 알림에 적합합니다. SNS → SQS → 람다: DLQ 지원, 제어된 처리량, 가시성 제한 시간을 사용한 재시도, 대기열 깊이 모니터링을 추가합니다. 트랜잭션 처리, 재고 업데이트, 다운스트림 제한을 준수해야 하는 모든 시나리오에 적합합니다. 시험 문제에서는 내구성과 속도 제어가 언급될 때마다 SQS 버퍼링을 선택하십시오.

SNS 콘솔의 필터 정책 편집기를 사용하면 배포하기 전에 샘플 메시지가 필터 정책과 일치하는지 테스트할 수 있습니다. 또한 SNS 샌드박스를 사용해 메시지 전달을 시뮬레이션하고 라우팅을 확인할 수 있습니다. 코드에서는 알려진 속성이 포함된 테스트 메시지를 게시하고 각 구독의 CloudWatch 지표를 확인하여 필터 정책을 검증할 수 있습니다. NumberOfMessagesFiltered 지표에는 필터에 의해 차단된 메시지 수가 표시되므로, 실제 운영 이벤트를 기다리지 않고도 정책을 조정할 수 있습니다.

완전한 SNS + SQS 통합은 다음과 같이 구성됩니다. (1) 애플리케이션이 메시지 속성과 함께 SNS Standard 주제에 이벤트를 게시합니다. (2) SNS가 각 구독의 필터 정책을 평가하고 일치하는 메시지만 각 SQS 대기열로 전달합니다. (3) Lambda가 구성된 일괄 처리 크기로 각 SQS 대기열을 폴링하고 메시지를 처리합니다. (4) 처리에 실패한 메시지는 maxReceiveCount에 도달한 후 대기열의 DLQ로 이동합니다. (5) DLQ의 메시지 수에 설정한 CloudWatch 경보가 팀에 알립니다. 이처럼 완전히 결합이 분리되고 복원력이 높은 패턴은 모범적인 SAA-C03 아키텍처입니다.

이 레슨에서 다룬 AWS 솔루션스 아키텍트(SAA-C03) 개념에 대한 이해도를 확인해 보세요.

이 레슨에서는 다음을 배웠습니다. SNS 필터 정책은 SNS 수준에서 메시지 속성 또는 본문 내용을 기준으로 메시지를 라우팅하므로 다운스트림 소비자의 불필요한 처리를 줄입니다. SNS→SQS→Lambda 패턴은 팬아웃 브로드캐스트와 처리 사이에 내구성 있는 버퍼링과 속도 제어를 추가합니다. 또한 교차 계정 SQS 전달을 사용하면 대기열 리소스 정책을 통해 여러 계정 환경에서 중앙 집중식 게시/구독을 구현할 수 있습니다. 다음으로 Amazon API 게이트웨이의 REST, HTTP, WebSocket API를 살펴보겠습니다.