AWS Certified Developer - Associate (DVA-C02) #5 Domain 1-4 AWS 서비스로 개발: 메시징과 이벤트
#4 DynamoDB까지 데이터를 정리했으니, 이번에는 컴포넌트를 느슨하게 잇는 비동기 메시징을 살펴봅니다. 서버리스 아키텍처는 동기 호출만으로는 확장에 한계가 있습니다. 시험은 “SQS,SNS,EventBridge,Step Functions 중 무엇을 골라야 하는가"를 시나리오로 반복해서 묻습니다. 네 서비스의 역할을 한 문장으로 먼저 잡겠습니다.
| 서비스 | 한 줄 정의 |
|---|---|
| SQS | 작업을 큐에 쌓아 한 소비자가 당겨 처리(point-to-point) |
| SNS | 메시지를 여러 구독자에게 동시에 발행(발행/구독, 푸시) |
| EventBridge | 이벤트를 규칙으로 라우팅하는 이벤트 버스(SaaS,스케줄 통합) |
| Step Functions | 여러 단계를 상태 머신으로 오케스트레이션 |
SQS: 큐 #
SQS는 생산자가 메시지를 큐에 넣고, 소비자가 폴링해서 가져가는 완전 관리형 큐입니다. 컴포넌트를 분리(decouple)하고, 처리량을 평탄화(버퍼링)합니다.
표준 큐 vs FIFO 큐 #
| 구분 | 표준(Standard) | FIFO |
|---|---|---|
| 순서 | 보장 안 됨(best-effort) | 엄격한 순서 |
| 전달 | at-least-once(중복 가능) | 정확히 한 번(중복 제거) |
| 처리량 | 사실상 무제한 | 제한적(배치로 높임) |
“순서가 중요하다 / 중복을 막아야 한다"면 FIFO, 처리량이 최우선이면 표준입니다. 표준 큐는 중복이 가능하므로 소비자는 멱등해야 합니다.
가시성 시간 초과(Visibility Timeout) #
소비자가 메시지를 가져가면, 그 메시지는 가시성 시간 초과 동안 다른 소비자에게 보이지 않습니다. 이 시간 안에 처리하고 삭제하면 끝이고, 삭제하지 못하면 메시지가 다시 큐에 나타나 재처리됩니다.
시험 함정: 처리에 오래 걸리는데 가시성 시간 초과가 짧으면, 아직 처리 중인 메시지가 다시 보여 중복 처리됩니다. 답은 가시성 시간 초과를 늘리거나
ChangeMessageVisibility로 연장하는 것입니다.
롱 폴링과 DLQ #
- 롱 폴링(Long Polling). 빈 응답을 줄이려고 메시지가 올 때까지(최대 20초) 기다립니다. 빈 수신 비용을 줄이는 권장 설정입니다.
- DLQ.
maxReceiveCount만큼 처리에 실패한 메시지를 별도 큐로 보내 격리합니다. 독성 메시지(poison pill)가 큐를 막는 것을 방지합니다.
SNS: 발행/구독 #
SNS는 하나의 메시지를 여러 구독자에게 동시에 푸시합니다. 구독자는 Lambda, SQS, HTTP/S, 이메일, SMS 등입니다. SQS가 “한 소비자가 당겨간다(pull)“라면, SNS는 “모든 구독자에게 민다(push)“입니다.
팬아웃 패턴(SNS + SQS) #
시험 단골 패턴입니다. SNS 토픽에 여러 SQS 큐를 구독시키면, 한 번 발행한 메시지가 여러 큐로 동시에 들어가고 각 큐의 소비자가 독립적으로 처리합니다.
- 각 소비자가 자기 속도로 처리(버퍼링).
- 한 소비자의 장애가 다른 소비자에 영향을 주지 않음.
- 나중에 새 구독자(큐)를 추가하기 쉬움.
“하나의 이벤트를 여러 시스템이 각자 처리해야 하고, 각 처리의 내구성과 재시도가 필요하다"의 답이 SNS + SQS 팬아웃입니다. SNS만 쓰면 구독자가 실패했을 때 메시지를 버퍼링,재처리하기 어렵습니다.
EventBridge: 이벤트 버스 #
EventBridge는 이벤트를 규칙(rule)으로 필터링해 대상(target)으로 라우팅하는 이벤트 버스입니다. SNS와 비슷해 보이지만 결이 다릅니다.
| 관점 | SNS | EventBridge |
|---|---|---|
| 모델 | 토픽 구독, 단순,고처리량 | 이벤트 패턴 매칭, 풍부한 라우팅 |
| 필터링 | 메시지 속성 필터 | 이벤트 내용 기반 패턴 매칭 |
| 소스 | 직접 발행 | AWS 서비스 이벤트,SaaS 파트너,커스텀 |
| 스케줄 | 없음 | 크론/레이트 스케줄 내장 |
| 스키마 | 없음 | 스키마 레지스트리 |
핵심 구분: 단순 고속 팬아웃은 SNS, 다양한 소스의 이벤트를 내용 기반으로 라우팅하거나 스케줄이 필요하면 EventBridge입니다. “매일 정해진 시각에 Lambda 실행"의 답은 EventBridge 스케줄 규칙입니다(과거 CloudWatch Events).
Step Functions: 오케스트레이션 #
여러 단계를 가진 워크플로를 상태 머신으로 조정합니다. 분기,병렬,재시도,대기,에러 처리를 코드가 아니라 정의(ASL, Amazon States Language)로 표현합니다.
| 유형 | 적합한 경우 |
|---|---|
| Standard | 길게(최대 1년) 실행, 정확히 한 번, 감사 이력 필요 |
| Express | 짧고(최대 5분) 대량,고빈도 이벤트 처리 |
“여러 Lambda를 순서대로,조건부로 호출하고 실패 시 재시도/보상 처리"가 필요하면, Lambda 안에서 직접 호출하지 말고 Step Functions로 오케스트레이션하는 것이 정답입니다. 상태 전이가 한눈에 보이고 각 단계의 재시도,에러 처리를 선언적으로 다룰 수 있습니다.
서비스 선택 빠른 표 #
| 요구사항 키워드 | 정답 |
|---|---|
| 작업 분리,버퍼링, 한 소비자 | SQS |
| 순서,중복 제거 | SQS FIFO |
| 하나를 여러 구독자에게 푸시 | SNS |
| 하나의 이벤트 → 여러 시스템 각자 내구성 처리 | SNS + SQS 팬아웃 |
| 내용 기반 라우팅,SaaS 이벤트 | EventBridge |
| 정해진 시각/주기 실행 | EventBridge 스케줄 |
| 다단계 워크플로 조정,재시도,분기 | Step Functions |
시험 출제 패턴 #
- “처리량이 폭증할 때 백엔드를 보호하며 작업을 평탄화.” → SQS(버퍼).
- “주문은 받은 순서대로, 중복 없이 처리.” → SQS FIFO.
- “한 이벤트를 결제,알림,분석 시스템이 각각 처리.” → SNS + SQS 팬아웃.
- “GitHub/Datadog 같은 SaaS 이벤트에 반응.” → EventBridge.
- “매일 자정에 정리 작업 실행.” → EventBridge 스케줄 규칙.
- “5단계 승인 워크플로를 재시도,분기와 함께.” → Step Functions.
- “메시지가 처리 중인데 또 소비됐다.” → 가시성 시간 초과 연장.
정리 #
이번 글에서 잡은 것:
- SQS 큐(분리,버퍼), 표준(at-least-once) vs FIFO(순서,중복 제거)
- 가시성 시간 초과,롱 폴링,DLQ는 SQS 운영의 핵심
- SNS 발행/구독, SNS + SQS 팬아웃으로 내구성 있는 다중 소비
- EventBridge. 내용 기반 라우팅,SaaS,스케줄
- Step Functions. 다단계 워크플로 오케스트레이션(Standard vs Express)
다음: Domain 1-5 SDK 개발 패턴 #
서비스를 코드로 호출할 때 반복되는 공통 패턴이 있습니다. #6 SDK 개발 패턴에서는 페이지네이션, 스로틀링 대응을 위한 지수 백오프와 지터, 멱등성 구현, S3 멀티파트 업로드와 presigned URL, 그리고 SDK 자격 증명 공급 체인까지 정리하겠습니다.