AWS DVA 메시징 — SQS·SNS·Kinesis

이 글은 AWS DVA-C02 마스터 노트 시리즈의 여섯 번째 편입니다. 5편(네트워킹)까지 동기 통신을 잡았다면, 이번엔 비동기 — SQS·SNS·Kinesis·EventBridge 4가지 메시징.

이 영역은 시나리오 키워드 매핑이 핵심이에요. "느슨한 결합" → SQS, "팬아웃" → SNS, "실시간 스트림" → Kinesis, "스케줄·규칙 기반" → EventBridge.

SQS — 메시지 큐

회사 비유 — 우체통. 보낸 사람이 메시지 넣고, 받는 사람이 꺼내감. 비동기·디커플링.

표준 vs FIFO — 결정적 차이

구분	표준 (Standard)	FIFO
처리량	무제한	300 메시지/s (배치 시 3000)
순서	베스트 에포트	순서 보장
중복	가능 (재전달)	단일 처리 (5분 중복 제거)
큐 이름	MyQueue	MyQueue.fifo

여기서 정말 중요한 시험 함정 — FIFO는 처리량이 제한적입니다. 순서가 정말 중요한 자리(주문 처리·은행 거래)만 FIFO. 일반 워크로드는 표준 사용.

Visibility Timeout

메시지를 받은 컨슈머가 처리 완료 시까지 다른 컨슈머에게 안 보이는 시간.

Producer → 큐에 메시지 PUT
Consumer A → ReceiveMessage (메시지 보임, Visibility Timeout 시작)
                ↓ 30초 (기본)
Consumer A 처리 중...
  성공 → DeleteMessage (영구 삭제)
  실패 → 30초 후 다시 보이게 됨 → 다른 컨슈머가 처리

기본 30초, 0~12시간.

여기서 시험 함정이 하나 있어요. 처리 시간 > Visibility Timeout 이면 같은 메시지가 다른 컨슈머에게도 갑니다(중복 처리). ChangeMessageVisibility API로 동적 연장.

DLQ (Dead Letter Queue)

처리 실패한 메시지를 별도 큐로 이동.

원본 큐 → maxReceiveCount = 3 → DLQ
        (3번 처리 실패한 메시지가 DLQ로)

DLQ에서 분석·재처리 가능. 운영 모니터링 핵심.

Long Polling

Short Polling — 빈 큐도 즉시 응답 (비용 ↑)
Long Polling — 메시지 도착까지 최대 20초 대기 (비용 ↓)

Long Polling 권장. 빈 응답 줄여 비용 절약.

메시지 한도

• 256KB (메시지 본문)
• 14일 보존 (기본 4일)

S3로 큰 메시지(2GB) 저장 후 SQS는 참조만 — Extended Client Library.

SNS — 알림 서비스

회사 비유 — 방송국·메일링 리스트. 한 메시지를 여러 구독자에게 동시 전달.

Fan-out 패턴

Publisher → SNS Topic → SQS Queue 1
                     → SQS Queue 2
                     → Lambda
                     → Email
                     → SMS
                     → HTTP/HTTPS

한 메시지를 여러 시스템에 동시 전달. 디커플링의 표준.

구독자 (Subscribers)

종류	비고
SQS	큐로 전달 (Fan-out 표준)
Lambda	즉시 트리거
Email/SMS	사용자 알림
HTTP/HTTPS	외부 webhook
Kinesis Data Firehose	S3·Redshift 적재
Mobile Push	iOS·Android 푸시

Message Filtering

구독자가 특정 속성 메시지만 받음.

{
  "store": ["seoul"],
  "event": [{"prefix": "ORDER_"}]
}

Topic의 메시지 중 조건 매칭만 구독자에게 전달. 한 토픽에 여러 비즈니스 흐름.

FIFO Topic

SQS FIFO와 결합. 순서 보장.

여기서 정말 중요한 시험 함정 — SNS + SQS Fan-out 패턴은 시험 단골입니다. 새 주문 → SNS → 결제 SQS + 배송 SQS + 분석 SQS + 이메일 Lambda.

Kinesis — 실시간 스트림

회사 비유 — 실시간 컨베이어 벨트. IoT·로그·게임 이벤트 등 대용량 실시간 스트림.

4가지 서비스

서비스	용도
Data Streams	저지연 스트림 (수집·소비)
Data Firehose	S3·Redshift·OpenSearch 자동 적재
Data Analytics	SQL·Apache Flink로 실시간 분석
Video Streams	비디오 실시간

Kinesis Data Streams

항목	값
Shard	처리 단위 (1MB/s 입력, 2MB/s 출력)
보존	1~365일 (기본 24시간)
Producer	SDK·KPL·Agent
Consumer	KCL·Lambda·Firehose

여기서 시험 함정이 하나 있어요. Shard 수 = 병렬 처리량. 트래픽 증가 시 Shard 추가(resharding) 필요. 자동 스케일은 On-Demand 모드.

Partition Key

같은 Partition Key는 같은 Shard로. 사용자 ID·기기 ID 등으로 균등 분산.

Kinesis Data Firehose

S3·Redshift·OpenSearch·HTTP 엔드포인트로 자동 적재.

Producer → Firehose → (Buffer 60s/5MB) → S3
                   → 변환 Lambda (선택)
                   → 압축·암호화

여기서 정말 중요한 시험 함정 — Firehose는 거의 실시간(60초 버퍼). 진짜 실시간(ms)이면 Data Streams. Firehose는 데이터 적재 자동화에 적합.

Data Streams vs Firehose

구분	Data Streams	Firehose
지연	ms	60초
보존	1~365일	즉시 적재 (보존 X)
Consumer	직접 (KCL·Lambda)	자동 (S3·Redshift)
비용	Shard 시간당	데이터량
스케일	수동 또는 On-Demand	자동

EventBridge — 이벤트 버스

회사 비유 — 사내 알림 게시판. AWS 서비스·SaaS·내부 앱 이벤트를 규칙·스케줄로 라우팅.

핵심 기능

Default Event Bus

AWS 서비스 이벤트 자동 수집(EC2 시작·S3 업로드 등).

Custom Event Bus

사용자 이벤트.

Partner Event Bus

SaaS 통합 (Datadog·Auth0 등).

Schedule Expression

Cron Expression — cron(0 18 ? * MON-FRI *)  매일 오후 6시 (월~금)
Rate Expression — rate(5 minutes)             5분마다

EventBridge Scheduler로 1억 개 스케줄 가능. CloudWatch Events 후속.

Pattern Matching

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": { "state": ["terminated"] }
}

특정 패턴 일치 시 Target 호출.

Targets

Lambda·SQS·SNS·Kinesis·Step Functions·ECS Task 등 20+ 서비스.

Schema Registry

이벤트 스키마 자동 검색·코드 자동 생성.

SQS·SNS·Kinesis·EventBridge 비교

구분	SQS	SNS	Kinesis	EventBridge
모델	큐 (1:1)	토픽 (1:N)	스트림 (병렬)	이벤트 버스
보존	14일	즉시	1~365일	즉시
적합	비동기 작업	Fan-out	실시간 분석	라우팅·스케줄
키워드	"느슨한 결합"	"여러 구독자"	"실시간 스트림"	"스케줄·규칙"

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 6편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• SQS 표준 vs FIFO — 처리량 무제한 vs 300/s, 순서 보장
• FIFO 큐 이름은 .fifo 접미사
• 표준 = 베스트 에포트 / FIFO = 단일 처리·순서
• Visibility Timeout = 처리 중 다른 컨슈머에게 안 보임
• 기본 30초 / 0~12시간 / ChangeMessageVisibility 동적 연장
• DLQ = maxReceiveCount 초과 메시지 별도 큐
• 운영 모니터링 핵심
• Long Polling 권장 (최대 20초 대기, 비용 ↓)
• 메시지 본문 256KB / 14일 보존 / 큰 메시지 = S3 + Extended Client
• SNS = Fan-out 1:N 표준
• 구독자 — SQS / Lambda / Email·SMS / HTTP·HTTPS / Kinesis Firehose / Push
• Message Filtering = 속성 매칭 메시지만 전달
• FIFO Topic = SNS+SQS 순서 보장
• SNS + SQS Fan-out = 시험 단골
• Kinesis 4종 — Data Streams / Firehose / Analytics / Video
• Shard 1MB/s 입력·2MB/s 출력
• 보존 1~365일 (기본 24h)
• Resharding 필요 / 자동은 On-Demand
• Partition Key = 같은 Shard 보장 (사용자 ID 등)
• Firehose = S3·Redshift·OpenSearch 자동 적재
• 거의 실시간 (60초 버퍼) / 진짜 실시간은 Data Streams
• Data Streams vs Firehose — ms vs 60초 / 보존 vs 적재
• EventBridge = 이벤트 버스, Default·Custom·Partner
• Cron / Rate Expression
• 1억 개 스케줄 (Scheduler)
• Pattern Matching → 20+ Target
• Schema Registry = 자동 코드 생성
• 키워드 매핑 — 큐(SQS) / 팬아웃(SNS) / 스트림(Kinesis) / 이벤트(EventBridge)

시리즈 다른 편

• 1편 — IAM
• 2편 — 컴퓨팅
• 3편 — 스토리지
• 4편 — 데이터베이스
• 5편 — 네트워킹
• 6편 — 메시징 (현재 글)
• 7편 — 서버리스
• 8편 — CI/CD
• 9편 — 모니터링
• 10편 — 보안·암호화
• 11편 — 컨테이너
• 12편 — 개발자 도구

공식 문서: AWS Messaging에서 더 깊이 갈 수 있어요.

다음 글(7편)에서는 서버리스 본격 — Lambda 동시성·Provisioned Concurrency, SAM 템플릿, Step Functions 상태 머신, AppSync GraphQL까지 풀어 갑니다.