1. 애플리케이션 통신 패턴
동기 vs 비동기 통신
| 패턴 | 구조 | 문제점 |
|---|---|---|
| 동기 (Synchronous) | App → App | 트래픽 급증 시 문제 |
| 비동기 (Asynchronous) | App → Queue → App | 디커플링, 확장성 |
비동기 통신 서비스
| 서비스 | 모델 | 용도 |
|---|---|---|
| Amazon SQS | Queue | 메시지 대기열 |
| Amazon SNS | Pub/Sub | 여러 수신자에게 발행 |
| Amazon Kinesis | Real-time Streaming | 실시간 데이터 스트리밍 |
예시: 동기 방식의 문제
평소: 비디오 인코딩 10개/일 → 문제 없음
급증: 비디오 인코딩 1000개/일 → 시스템 과부하! 💥
해결: SQS Queue로 디커플링 → 독립적으로 스케일링Part 1: Amazon SQS
2. SQS 개요
Queue 개념
┌──────────┐ ┌──────────┐
│ Producer │──┐ ┌────│ Consumer │
├──────────┤ │ ┌───────────┐ │ ├──────────┤
│ Producer │──┼──▶│ SQS Queue │───┼────│ Consumer │
├──────────┤ │ └───────────┘ │ ├──────────┤
│ Producer │──┘ Send Poll │ │ Consumer │
└──────────┘ └────│ Consumer │
└──────────┘SQS Standard Queue 특징
| 항목 | 값 |
|---|---|
| 처리량 | 무제한 |
| 메시지 수 | 무제한 |
| 메시지 보존 | 기본 4일, 최대 14일 |
| 지연시간 | < 10ms |
| 메시지 크기 | 최대 256KB |
| 중복 | 가능 (At least once delivery) |
| 순서 | 보장 안 됨 (Best effort ordering) |
3. SQS 메시지 생성/소비
메시지 생성 (Producer)
# SendMessage API 사용
import boto3
sqs = boto3.client('sqs')
sqs.send_message(
QueueUrl='https://sqs.region.amazonaws.com/123456789/my-queue',
MessageBody='Order: 12345, Customer: John'
)- SDK의
SendMessageAPI 사용 - 메시지는 Consumer가 삭제할 때까지 유지
메시지 소비 (Consumer)
1. SQS에서 메시지 Poll (최대 10개씩)
↓
2. 메시지 처리 (예: RDS에 저장)
↓
3. DeleteMessage API로 삭제다중 Consumer
┌─→ Consumer 1 (Poll)
│
SQS Queue ──────────┼─→ Consumer 2 (Poll)
│
└─→ Consumer 3 (Poll)
• 병렬 처리
• At least once delivery
• Best-effort ordering
• Consumer 수평 확장 가능4. SQS + Auto Scaling Group
아키텍처
┌───────────────────────────────────────────────────────┐
│ CloudWatch │
│ │
│ Metric: ApproximateNumberOfMessages │
│ │ │
│ CloudWatch Alarm │
│ │ scale │
└─────────────────────┼──────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ Auto Scaling Group │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ EC2 │ │ EC2 │ │ EC2 │ │ EC2 │ │
│ └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘ │
│ │ │ │ │ │
│ └───────────┴─────┬─────┴───────────┘ │
│ │ Poll │
└──────────────────────────┼──────────────────────────┘
↓
┌─────────────┐
│ SQS Queue │
└─────────────┘- Queue 길이 기반 Auto Scaling
ApproximateNumberOfMessages메트릭 사용
5. SQS 보안
암호화
| 유형 | 설명 |
|---|---|
| 전송 중 암호화 | HTTPS API |
| 저장 시 암호화 | KMS 키 |
| 클라이언트 측 암호화 | 직접 암/복호화 |
접근 제어
| 방식 | 용도 |
|---|---|
| IAM Policies | SQS API 접근 제어 |
| SQS Access Policies | Cross-account 접근, 다른 서비스(S3, SNS) 쓰기 허용 |
SQS Access Policy 예시
Cross-Account Access:
{
"Effect": "Allow",
"Principal": { "AWS": ["111122223333"] },
"Action": ["sqs:ReceiveMessage"],
"Resource": "arn:aws:sqs:us-east-1:444455556666:queue1"
}S3 Event → SQS:
{
"Effect": "Allow",
"Principal": { "AWS": "*" },
"Action": ["sqs:SendMessage"],
"Resource": "arn:aws:sqs:...",
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:::bucket1" }
}
}6. Message Visibility Timeout
개념
Time ─────────────────────────────────────────────────────▶
Consumer A: ReceiveMessage
│
▼
[Message 반환]
│
│←── Visibility Timeout (기본 30초) ──→│
│ │
Consumer B: │ ReceiveMessage │
│ │ │
│ [Not Returned] (메시지 안 보임) │
│ │
Consumer B: │ ReceiveMessage │
│ │ │
│ [Message 반환] (다시 보임!)핵심 포인트
| 항목 | 설명 |
|---|---|
| 기본값 | 30초 |
| 동작 | Poll 후 다른 Consumer에게 안 보임 |
| 타임아웃 후 | 메시지 다시 보임 → 중복 처리 가능 |
| API | ChangeMessageVisibility (시간 연장) |
설정 가이드
| 설정 | 문제점 |
|---|---|
| 너무 높음 (시간 단위) | Consumer 장애 시 재처리 지연 |
| 너무 낮음 (초 단위) | 중복 처리 발생 |
7. Dead Letter Queue (DLQ)
개념
┌──────────────────────────────────────────────────────┐
│ │
│ Consumer 처리 실패 │
│ ↓ │
│ 메시지 → Queue로 복귀 │
│ ↓ │
│ MaximumReceives 초과 시 │
│ ↓ │
│ Dead Letter Queue로 이동 │
│ │
└──────────────────────────────────────────────────────┘
┌─────────────┐ 실패 반복 ┌─────────────────┐
│ SQS Queue │ ─────────────────▶ │ Dead Letter Queue│
└─────────────┘ (MaxReceives) └─────────────────┘특징
| 항목 | 설명 |
|---|---|
| 용도 | 디버깅 |
| 조건 | MaximumReceives 초과 |
| DLQ 타입 | Standard Queue → Standard DLQ, FIFO → FIFO DLQ |
| 보존 기간 | 14일 권장 |
Redrive to Source
- DLQ 메시지를 원본 Queue로 다시 전송
- 코드 수정 후 재처리 가능
- 커스텀 코드 없이 배치 처리
8. SQS 추가 기능
Delay Queue (지연 큐)
| 항목 | 값 |
|---|---|
| 최대 지연 | 15분 |
| 기본값 | 0초 (즉시 사용 가능) |
| 설정 | Queue 레벨 또는 메시지별 (DelaySeconds) |
Long Polling
| 항목 | 설명 |
|---|---|
| 개념 | 메시지 없으면 대기 |
| 장점 | API 호출 감소, 효율성/지연시간 개선 |
| 대기 시간 | 1~20초 (20초 권장) |
| 설정 | ReceiveMessageWaitTimeSeconds |
Short Polling: 메시지 없음 → 즉시 빈 응답 → 다시 호출 → ...
Long Polling: 메시지 없음 → 대기 → 메시지 도착 → 응답💡 Long Polling이 Short Polling보다 권장됨!
쉽게 이해하기: Long Polling에서 대기하는 주체는?
Consumer(소비자)가 대기합니다.
┌──────────────┐ ┌───────────┐ │ Consumer │ ── ReceiveMessage ─→│ SQS Queue │ │ (EC2, Lambda)│ │ │ │ │ ←── 메시지 없으면 │ (비어있음) │ │ [대기 중] │ 최대 20초 대기 │ │ │ │ ←── 메시지 도착 시 │ [메시지!] │ │ │ 즉시 응답 │ │ └──────────────┘ └───────────┘Consumer가 SQS에 "메시지 줘"라고 요청하고 기다리는 것입니다.
쉽게 이해하기: Consumer는 어떻게 정하는가?
SQS는 Consumer를 "정하지 않습니다" - Consumer가 스스로 메시지를 가져가는(Pull) 방식입니다.
┌─────────────────────────────────────────────────────────┐ │ SQS Queue │ │ 메시지들: [msg1] [msg2] [msg3] [msg4] [msg5] │ │ "누가 가져가든 상관없음, 먼저 Poll한 놈이 임자" │ └─────────────────────────────────────────────────────────┘ ↑ ↑ ↑ │ Poll │ Poll │ Poll ┌────┴────┐ ┌─────┴─────┐ ┌─────┴─────┐ │Consumer A│ │Consumer B │ │Consumer C │ └──────────┘ └───────────┘ └───────────┘
질문 답변 Consumer 등록 필요? 아니요, 그냥 Poll하면 됨 누가 Consumer? EC2, Lambda, ECS 등 아무나 메시지 배분? 먼저 Poll한 Consumer가 가져감
쉽게 이해하기: Producer A→Consumer AA, B→BB처럼 1:1 매칭하려면?
Queue를 분리하는 것이 정답입니다. (메시지 내용으로 필터링 ❌)
┌───────────┐ ┌───────────┐ ┌───────────┐ │ Producer A│ │ Producer B│ │ Producer C│ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ Queue-A │ │ Queue-B │ │ Queue-C │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │Consumer AA│ │Consumer BB│ │Consumer CC│ └───────────┘ └───────────┘ └───────────┘
상황 해결 방법 A→AA, B→BB (1:1) Queue 분리 (권장) A→AA,BB,CC (1:N) SNS + SQS Fan-Out
Extended Client (대용량 메시지)
- 메시지 제한: 256KB (Extended Client로 1GB까지)
- S3에 큰 메시지 저장, SQS에는 메타데이터만
Producer → [큰 메시지] → S3 Bucket
→ [메타데이터] → SQS Queue
Consumer ← [메타데이터] ← SQS Queue
← [큰 메시지] ← S3 Bucket9. SQS 필수 API
| API | 설명 |
|---|---|
CreateQueue | 큐 생성 (MessageRetentionPeriod 설정) |
DeleteQueue | 큐 삭제 |
PurgeQueue | 모든 메시지 삭제 |
SendMessage | 메시지 전송 (DelaySeconds) |
ReceiveMessage | 메시지 수신 (MaxNumberOfMessages: 1~10) |
DeleteMessage | 메시지 삭제 |
ChangeMessageVisibility | 가시성 타임아웃 변경 |
💡 Batch API (SendMessage, DeleteMessage, ChangeMessageVisibility) 사용 시 비용 절감
10. SQS FIFO Queue
특징
| 항목 | Standard | FIFO |
|---|---|---|
| 순서 | Best effort | 보장 (First In First Out) |
| 중복 | 가능 | Exactly-once (중복 제거) |
| 처리량 | 무제한 | 300 msg/s (배치: 3000 msg/s) |
| 큐 이름 | 제한 없음 | .fifo 접미사 필수 |
Deduplication (중복 제거)
| 방식 | 설명 |
|---|---|
| Content-based | 메시지 본문 SHA-256 해시 |
| Deduplication ID | 명시적 ID 지정 |
- 중복 제거 간격: 5분
Message Grouping
SQS FIFO Queue:
┌─────────────────────────────────────────┐
│ │
│ Group A: [A3] [A2] [A1] → Consumer A │
│ Group B: [B4] [B3] [B2] [B1] → Consumer B │
│ Group C: [C2] [C1] → Consumer C │
│ │
└─────────────────────────────────────────┘
• 같은 MessageGroupID → 순서 보장, 단일 Consumer
• 다른 MessageGroupID → 병렬 처리 가능
• 그룹 간 순서는 보장 안 됨Part 2: Amazon SNS
11. SNS 개요
쉽게 이해하기: SQS와 SNS 약자
서비스 약자 전체 이름 핵심 SQS Simple Queue Service 간단한 대기열 서비스 메시지 저장 후 Consumer가 가져감 SNS Simple Notification Service 간단한 알림 서비스 메시지 즉시 전달 (발행-구독)
Pub/Sub 모델
┌──────── Direct Integration ────────┐
│ │
│ Buying Service │
│ │ │
│ ├──→ Email notification │
│ ├──→ Fraud Service │
│ ├──→ Shipping Service │
│ └──→ SQS Queue │
│ │
│ ❌ 각 서비스에 직접 연결 (복잡!) │
└────────────────────────────────────┘
┌──────── Pub/Sub (SNS) ─────────────┐
│ │
│ Buying Service │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │SNS Topic│ │
│ └────┬────┘ │
│ │ │
│ ├──→ Email notification │
│ ├──→ Fraud Service │
│ ├──→ Shipping Service │
│ └──→ SQS Queue │
│ │
│ ✅ Topic 하나에 발행 → 모두 수신 │
└────────────────────────────────────┘SNS 특징
| 항목 | 값 |
|---|---|
| Topic 수 | 최대 100,000 |
| 구독자 수/Topic | 최대 12,500,000 |
| 메시지 | 모든 구독자가 수신 (필터 가능) |
지원 Subscribers
| Subscriber | 용도 |
|---|---|
| SQS | Queue로 전달 |
| Lambda | 서버리스 처리 |
| Kinesis Data Firehose | 스트리밍 |
| HTTP(S) Endpoints | 웹훅 |
| Email / SMS | 알림 |
| Mobile Push | 모바일 알림 |
SNS와 통합되는 AWS 서비스
- CloudWatch Alarms
- S3 Bucket Events
- Auto Scaling Group Notifications
- CloudFormation State Changes
- AWS Budgets
- Lambda
- DynamoDB
- RDS Events
- 등...
12. SNS 보안
암호화
| 유형 | 설명 |
|---|---|
| 전송 중 | HTTPS API |
| 저장 시 | KMS |
| 클라이언트 측 | 직접 암/복호화 |
접근 제어
| 방식 | 용도 |
|---|---|
| IAM Policies | SNS API 접근 |
| SNS Access Policies | Cross-account, S3 등 다른 서비스 쓰기 허용 |
13. SNS + SQS: Fan-Out 패턴
개념
┌─────────────┐
│ SQS Queue │ → Fraud Service
│ (Subscriber)│
└─────────────┘
↑
Buying Service → SNS Topic
↓
┌─────────────┐
│ SQS Queue │ → Shipping Service
│ (Subscriber)│
└─────────────┘장점
| 장점 | 설명 |
|---|---|
| 완전 디커플링 | 서비스 간 직접 연결 없음 |
| 데이터 손실 없음 | SQS가 메시지 보존 |
| 데이터 지속성 | SQS로 지연 처리, 재시도 가능 |
| 확장성 | 구독자 추가 용이 |
| Cross-Region | 다른 리전 SQS Queue도 가능 |
사용 사례: S3 Events → 다중 Queue
S3 Bucket (Object Created)
│
▼
SNS Topic ─────┬──→ SQS Queue 1
(Fan-out) ├──→ SQS Queue 2
└──→ Lambda Function⚠️ 같은 이벤트 타입 + 접두사 조합에는 하나의 S3 Event Rule만 가능
→ Fan-out 패턴 사용!
14. SNS FIFO Topic
특징
| 항목 | 설명 |
|---|---|
| 순서 | 보장 (MessageGroupID) |
| 중복 제거 | Deduplication ID 또는 Content-based |
| 구독자 | SQS Standard, SQS FIFO |
| 처리량 | SQS FIFO와 동일 (제한적) |
SNS FIFO + SQS FIFO Fan-Out
Fan-out + 순서 보장 + 중복 제거가 모두 필요한 경우:
Buying Service → SNS FIFO Topic ─┬──→ SQS FIFO Queue → Fraud Service
└──→ SQS FIFO Queue → Shipping Service15. SNS Message Filtering
개념
- JSON 정책으로 메시지 필터링
- 필터 정책 없으면 모든 메시지 수신
예시
SNS Topic (New Transaction)
{
"Order": 1036,
"Product": "Pencil",
"Qty": 4,
"State": "Placed"
}
│
├──→ SQS Queue (Placed) ←── Filter: {"State": ["Placed"]}
├──→ SQS Queue (Declined) ←── Filter: {"State": ["Declined"]}
├──→ Email (Cancelled) ←── Filter: {"State": ["Cancelled"]}
└──→ SQS Queue (All) ←── No Filter (모든 메시지)Part 3: Amazon Kinesis
16. Kinesis Data Streams
개요
- 실시간 스트리밍 데이터 수집 및 저장
아키텍처
┌─────────────────┐
│ Producers │
├─────────────────┤
│ - Click Streams │ ┌────────────────────┐
│ - IoT devices │───────▶│ Kinesis Data │
│ - Metrics & Logs│ │ Streams │
│ - Applications │ └─────────┬──────────┘
│ - Kinesis Agent │ │
└─────────────────┘ ▼
┌────────────────────┐
│ Consumers │
├────────────────────┤
│ - Lambda │
│ - Applications │
│ - Data Firehose │
│ - Managed Flink │
└────────────────────┘특징
| 항목 | 설명 |
|---|---|
| 보존 기간 | 최대 365일 |
| 데이터 재처리 | 가능 (Replay) |
| 데이터 삭제 | 불가 (만료될 때까지) |
| 메시지 크기 | 최대 1MB |
| 순서 | 같은 Partition ID 내에서 보장 |
| 암호화 | KMS (저장), HTTPS (전송) |
| 라이브러리 | KPL (Producer), KCL (Consumer) |
Capacity Modes
| 모드 | 설명 |
|---|---|
| Provisioned | Shard 수 수동 지정, Shard당 과금 |
| On-demand | 자동 스케일링, 사용량 기반 과금 |
Provisioned Mode:
- 1 Shard = 1MB/s 입력 (1000 records/s)
- 1 Shard = 2MB/s 출력
On-demand Mode:
- 기본: 4MB/s 입력 (4000 records/s)
- 최근 30일 피크 기준 자동 확장
17. Amazon Data Firehose
개요 (구 Kinesis Data Firehose)
- 완전 관리형 데이터 전송 서비스
- Near Real-Time (버퍼링 기반)
아키텍처
┌─────────────────┐
│ Producers │
├─────────────────┤
│ - Applications │
│ - Kinesis Agent │
│ - SDK │ ┌────────────────────┐
│ - Kinesis Data │───────▶│ Amazon Data │
│ Streams │ │ Firehose │
│ - CloudWatch │ └─────────┬──────────┘
│ - AWS IoT │ │
└─────────────────┘ │
▼
┌─────────────────────────────────┐
│ Destinations │
├─────────────────────────────────┤
│ AWS: S3, Redshift, OpenSearch │
│ 3rd Party: Splunk, Datadog, etc │
│ Custom: HTTP Endpoint │
└─────────────────────────────────┘특징
| 항목 | 설명 |
|---|---|
| 관리 | 완전 관리형, 서버리스 |
| 스케일링 | 자동 |
| 실시간성 | Near Real-Time (버퍼링) |
| 데이터 저장 | ❌ 없음 |
| Replay | ❌ 불가 |
| 변환 | Lambda로 커스텀 변환 (CSV→JSON) |
| 형식 | CSV, JSON, Parquet, Avro, Raw, Binary |
| 압축 | gzip, snappy |
18. Kinesis Data Streams vs Data Firehose
| 비교 | Kinesis Data Streams | Amazon Data Firehose |
|---|---|---|
| 용도 | 스트리밍 데이터 수집 | 데이터 적재 |
| 코드 | Producer/Consumer 직접 작성 | 설정만 |
| 실시간성 | Real-time | Near Real-time |
| 스케일링 | Provisioned/On-demand | 자동 |
| 데이터 저장 | 최대 365일 | ❌ 없음 |
| Replay | ✅ 가능 | ❌ 불가 |
| 목적지 | Consumer 애플리케이션 | S3, Redshift, OpenSearch 등 |
19. Amazon Managed Service for Apache Flink
개요 (구 Kinesis Data Analytics)
- Apache Flink 애플리케이션을 AWS에서 관리형으로 실행
- Java, Scala, SQL로 스트림 처리
특징
| 항목 | 설명 |
|---|---|
| 소스 | Kinesis Data Streams, Amazon MSK (Kafka) |
| 컴퓨팅 | 프로비저닝된 리소스 |
| 스케일링 | 자동 |
| 백업 | Checkpoints, Snapshots |
⚠️ Amazon Data Firehose에서는 읽을 수 없음!
20. SQS vs SNS vs Kinesis 비교
| 항목 | SQS | SNS | Kinesis Data Streams |
|---|---|---|---|
| 모델 | Queue (Pull) | Pub/Sub (Push) | Stream (Pull/Push) |
| 소비자 | Pull | Push | Standard: Pull, Enhanced: Push |
| 데이터 삭제 | 소비 후 삭제 | 전달 안 되면 유실 | 만료 시까지 보존 |
| 데이터 재처리 | ❌ | ❌ | ✅ Replay 가능 |
| 소비자 수 | 여러 Consumer | 최대 12.5M 구독자 | Shard당 Consumer |
| 처리량 | 무제한 (자동) | 무제한 (자동) | Shard당 2MB/s |
| 순서 | FIFO만 보장 | FIFO Topic만 | Shard 내 보장 |
| 메시지 지연 | ✅ 개별 가능 | ❌ | ❌ |
| 용도 | 작업 큐, 디커플링 | 알림, Fan-out | 실시간 빅데이터, ETL |
핵심 요약
SQS
| 개념 | 설명 |
|---|---|
| Standard | 무제한 처리량, 순서/중복 보장 안 됨 |
| FIFO | 순서 보장, Exactly-once, 300 msg/s |
| Visibility Timeout | 기본 30초, 처리 중 다른 Consumer에게 안 보임 |
| DLQ | 처리 실패 메시지 저장, 디버깅용 |
| Long Polling | API 호출 감소, 20초 권장 |
SNS
| 개념 | 설명 |
|---|---|
| Pub/Sub | Topic에 발행, 모든 구독자 수신 |
| Fan-out | SNS + SQS로 다중 Queue 전달 |
| Message Filtering | JSON 정책으로 구독자별 필터링 |
| FIFO Topic | 순서 보장, SQS FIFO와 연동 |
Kinesis
| 개념 | 설명 |
|---|---|
| Data Streams | 실시간 수집, 최대 365일 보존, Replay 가능 |
| Data Firehose | Near Real-time 적재, S3/Redshift 등 |
| Managed Flink | 스트림 처리 (Flink) |