📨 AWS Integration & Messaging#

Standard Queue#

SQS 메시지 흐름#

1
[Producer] ─ SendMessage API ─→ [SQS Queue] ─ Poll ─→ [Consumer]
2
                                                          │
3
                                                   처리 완료 후
4
                                                   DeleteMessage API

• Consumer는 한 번에 최대 10개 메시지 수신 (Receive)
• 메시지는 Consumer가 DeleteMessage API를 호출하기 전까지 Queue에 유지
• Consumer는 EC2, Lambda, 온프레미스 서버 등 어디서든 실행 가능

Message Visibility Timeout (메시지 가시성 타임아웃)#

1
Consumer가 메시지를 Poll
2
    │
3
    ▼
4
메시지가 다른 Consumer에게 "비가시(Invisible)" 상태로 전환
5
    │
6
    ▼
7
기본 30초 내에 처리 + DeleteMessage 완료 → 메시지 영구 삭제
8
처리 실패 / 시간 초과 → 메시지가 다시 Queue에 "가시(Visible)" 상태로 복귀
9
                          → 다른 Consumer가 재처리 (중복 처리 가능)

Long Polling (롱 폴링)#

• Consumer가 Queue에 메시지가 없을 때 **일정 시간 대기(Wait)**하여 메시지 도착 시 즉시 수신
• Short Polling (기본): 메시지 없으면 즉시 빈 응답 → API 호출 낭비
• Long Polling 장점:
  • SQS에 대한 API 호출 수 감소 → 비용 절감
  • 지연 시간(Latency) 감소
  • 애플리케이션 효율 향상
• 대기 시간: 1초 ~ 20초 (20초 권장)
• 설정: Queue 레벨 또는 API 레벨 (WaitTimeSeconds 파라미터)

💡 Long Polling이 Short Polling보다 항상 권장됨

SQS 보안#

SQS + Auto Scaling Group (ASG) 패턴#

1
[요청]
2
  │
3
  ▼
4
[Frontend App (ASG)] ─ SendMessage ─→ [SQS Queue]
5
                                           │
6
                                     CloudWatch Metric
7
                                     (ApproximateNumberOfMessages)
8
                                           │ Queue 길이 임계값 초과
9
                                           ▼
10
                                     [CloudWatch Alarm]
11
                                           │
12
                                           ▼
13
                                     [Backend ASG Scale Out]
14
                                           │
15
                                     ReceiveMessage ─→ DB Insert

활용 시나리오:

• Frontend와 Backend를 완전히 분리(Decouple)
• Backend 처리 속도보다 요청이 빠를 때 SQS를 Buffer로 활용 → 데이터 유실 없음
• ApproximateNumberOfMessages CloudWatch Metric → ASG Scaling 트리거

Pub/Sub 패턴#

1
[Event Producer]
2
      │
3
      ▼
4
[SNS Topic]  ← 메시지 1회 발행
5
   │  │  │
6
   ▼  ▼  ▼
7
[Sub1] [Sub2] [Sub3] ...  ← 모든 Subscriber가 메시지 수신

지원 Subscriber 유형:

• SQS, Lambda, Kinesis Data Firehose, HTTP/HTTPS Endpoint
• Email, SMS, Mobile Push Notification

SNS 보안#

SQS와 동일한 구조:

• In-flight: HTTPS / At-rest: KMS / Client-side: 고객 직접 처리
• IAM Policies + SNS Access Policy (Cross-Account, S3 등 서비스가 SNS에 쓰기 허용)

SNS Message Filtering (메시지 필터링)#

• JSON Policy로 각 Subscription이 수신할 메시지를 필터링
• 필터가 없는 Subscription → 모든 메시지 수신

1
[SNS Topic: 주문 이벤트]
2
      │
3
      ├── [SQS: 주문완료 큐]    ← Filter: {"state": ["placed"]}
4
      ├── [SQS: 취소 큐]       ← Filter: {"state": ["cancelled"]}
5
      └── [Lambda: 전체 처리]   ← Filter 없음 (모든 메시지 수신)

SNS + SQS Fan-Out 패턴#

문제: S3 Event는 하나의 Rule에 하나의 대상만 설정 가능 해결: SNS Topic을 중간에 두고 여러 SQS Queue로 Fan-Out

1
[S3 Event] ─→ [SNS Topic] ─→ [SQS Queue A] → 썸네일 생성
2
                          ─→ [SQS Queue B] → 메타데이터 저장
3
                          ─→ [SQS Queue C] → 감사 로그

Fan-Out 장점:

• 완전한 Decoupling, 데이터 유실 없음
• SQS: 데이터 영속성, 지연 처리, 재시도 가능
• 나중에 Subscriber 추가 가능 (기존 아키텍처 변경 없이)
• Cross-Region Delivery 지원 (다른 리전의 SQS Queue에 전달 가능)

SNS → Kinesis Data Firehose → S3 패턴#

1
[서비스] → [SNS Topic] → [Kinesis Data Firehose] → [S3 / Redshift / OpenSearch]

SNS가 직접 지원하지 않는 대상(S3 등)에 데이터를 전달할 때 Firehose를 중간 단계로 활용.

SNS FIFO Topic#

• SQS FIFO와 유사한 기능:
  • Message Group ID 기반 순서 보장
  • Deduplication ID 또는 Content-Based Deduplication으로 중복 제거
• Subscriber: SQS Standard 또는 SQS FIFO Queue
• 제한된 Throughput

SNS FIFO + SQS FIFO = Fan-Out + Ordering + Deduplication 동시 달성

Kinesis 서비스 구성#

Kinesis Data Streams#

데이터 흐름:

1
[Producers: App, IoT, Click Stream] → [Kinesis Data Streams] → [Consumers: Lambda, ECS, App]

Kinesis Data Streams - Capacity Modes#

Amazon Data Firehose (구: Kinesis Data Firehose)#

• 완전 관리형, Serverless, 자동 스케일링
• Near Real-Time 전달 (버퍼링으로 인한 약간의 지연)
• 사용한 만큼 과금 (Pay for what you use)

지원 대상 (Destinations):

1
AWS: Amazon S3, Amazon Redshift, Amazon OpenSearch Service
2
3rd Party: Splunk, MongoDB, Datadog, NewRelic
3
Custom: HTTP Endpoint

데이터 변환:

• Lambda로 Custom 변환 (예: CSV → JSON)
• Parquet/ORC 변환, gzip/snappy 압축

Kinesis Data Streams vs. Amazon Data Firehose#

왜 Amazon MQ인가?#

• SQS/SNS는 AWS 독점(Cloud-Native) 프로토콜 사용
• 기존 온프레미스 애플리케이션은 오픈 표준 프로토콜 사용:
  • MQTT, AMQP, STOMP, OpenWire, WSS 등
• 클라우드 이전 시 애플리케이션 재설계 없이 기존 프로토콜 그대로 사용 가능

Amazon MQ 특성#

📌 선택 기준: 새로운 애플리케이션 → SQS/SNS 사용. 기존 온프레미스 Message Broker 마이그레이션 → Amazon MQ 사용.