AWS Integration & Messaging (SQS, SNS, Kinesis) 정리

AWSSQSSNSKinesisDVA-C02

작성자 : 오예환 | 작성일 : 2026-01-11 | 수정일 : 2026-01-11

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의 SendMessage API 사용
메시지는 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 Bucket

9. 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 간단한 알림 서비스 메시지 즉시 전달 (발행-구독)

서비스	약자	전체 이름	핵심
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 Service

15. 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)