[AWS-SAA] 11. SQS, SNS, Kinesis, Amazon MQ 요약

AWS 메시징 서비스 총정리 (SQS, SNS, Kinesis, Amazon MQ)

1. 메시징 통신 개념

• 여러 애플리케이션 간에 데이터를 주고받을 때 메시지 기반 통신이 필요하다.
• 메시지 통신은 크게 두 가지 방식으로 나뉜다.

동기 통신

• 애플리케이션 간 직접 호출 (API → 응답)
• 응답을 기다려야 하므로 지연에 민감
• 서비스 간 의존성이 높아짐

비동기 통신

• 메시지를 중간 버퍼(큐/토픽)에 남기고 비동기 처리
• 생산자와 소비자 간 느슨한 결합 가능
• 메시지를 저장하고 나중에 처리할 수 있어 확장성 및 내결함성 확보

2. Amazon SQS (Simple Queue Service)

기본 개념

• 완전관리형 메시지 큐 서비스
• 생산자와 소비자 사이의 버퍼 역할
• 메시지를 큐에 저장해 비동기 처리

표준 큐(Standard Queue)

• 대기열 기반 메시징
• 순서 보장되지 않음
• 중복 메시지 가능 (at-least-once 전달)
• 최대 256KB 메시지 크기
• 기본 보존 기간 4일(최대 14일)
• 무제한 처리량

FIFO 큐(First-In-First-Out)

• 순서 보장 (정확히 한 번 처리)
• 처리량 제한 존재 (300~3000 msg/s)
• 큐 이름에 .fifo 접미사 필수
• 메시지 그룹 ID를 이용해 다중 소비자 동시 처리 가능

가시성 시간 초과(Visibility Timeout)

• 메시지를 가져오면 일정 시간 동안 다른 소비자가 보지 못하게 잠금
• 기본 30초, 연장 가능
• 메시지 처리가 실패하면 다시 큐에 나타남

롱 폴링(Long Polling)

• 큐에 메시지가 없을 경우 대기 상태 유지
• 즉시 실패 방지, 불필요한 요청 제거
• 1~20초까지 설정 가능

활용 사례

• 프론트엔드 → SQS → 백엔드 구조
• 대기열 길이에 따라 Auto Scaling Group 조절
• 대량 주문 처리 시 데이터베이스에 무리 없이 쓰기 가능

3. Amazon SNS (Simple Notification Service)

기본 개념

• 퍼블리시/서브스크라이브(pub/sub) 기반 메시징
• 한 메시지를 다수 구독자에게 동시에 전달

작동 방식

• 생산자가 SNS 주제(topic)에 메시지를 게시
• 구독자는 이메일, SQS, Lambda, HTTPS, SMS 등 다양한 대상 가능
• 주제당 최대 1,200만 구독자
• 계정당 최대 10만 개 주제 생성 가능

팬아웃(Fan-out) 패턴

• SNS를 사용하여 하나의 메시지를 여러 SQS 큐에 동시에 전달
• 애플리케이션 티어 간 완전한 디커플링 가능
• 교차 리전 전송 지원

FIFO 주제

• SNS에서도 FIFO 주제 사용 가능
• 순서 보장 및 중복 제거
• SQS FIFO 큐와 결합하여 정확한 순서 처리 구현

메시지 필터링

• JSON 필터를 통해 구독자별로 메시지를 조건부 수신 가능
• 불필요한 메시지 수신 최소화

활용 사례

• S3 이벤트를 다수 큐에 전달할 때 SNS 중간에 사용
• Kinesis Firehose를 통해 S3, Redshift 등으로 데이터 유입 가능

4. Amazon Kinesis

기본 개념

• 실시간 스트리밍 데이터 수집/처리/분석 서비스
• 고속 대량 데이터 처리를 위한 아키텍처에 적합

구성 요소

1. Kinesis Data Streams
   • 샤드 기반 스트리밍 처리
   • 순서 보장, 파티션 키 기반 샤드 배정
   • 소비자 정의 가능, 재처리 가능
2. Kinesis Data Firehose
   • 스트리밍 → 저장소 자동 연계
   • S3, Redshift, OpenSearch, HTTP, 서드파티로 전송 가능
   • 완전관리형, 서버리스
3. Kinesis Data Analytics
   • SQL 기반 실시간 분석
   • Apache Flink 지원
4. Kinesis Video Streams
   • 실시간 비디오 처리용 (시험 범위 외)

용량 모델

• 프로비저닝: 샤드 수 직접 설정, 수동 스케일
• 온디맨드: 자동 스케일, 예측 없이 사용 가능

향상된 팬아웃

• 한 샤드에 여러 소비자에 병렬 푸시 가능
• 소비자별 독립적인 처리량 확보

활용 사례

• 실시간 IoT/로그 수집
• 실시간 클릭스트림 분석
• 이벤트 기반 ETL 처리

5. Kinesis vs SQS vs SNS 비교

SQS

• 풀 기반 처리
• 메시지 보존 및 재시도 가능
• 느슨한 결합된 비동기 처리
• 순서 보장(FIFO), 대기열 기반
• 지연 처리, 버퍼링 효과 우수

SNS

• 푸시 기반 처리
• 다수 대상에 동시 전달
• 저장 없음, 실패 시 메시지 소실 가능
• Pub/Sub 구조에 적합
• 팬아웃 구현 가능

Kinesis

• 스트리밍 데이터 처리
• 실시간 빅데이터, IoT, 클릭 로그 등
• 순서 보장 및 재처리
• 처리량 제어 가능 (샤드 단위)
• 다양한 소비자 동시 처리 가능

6. Kinesis vs SQS FIFO – 정렬 방식

• Kinesis: 파티션 키 기반으로 샤드에 메시지를 할당하고, 샤드 내에서 순서 보장
• SQS FIFO: 메시지 그룹 ID 단위로 순서 보장, 소비자 병렬화 시 그룹 ID 필요

예시

• Kinesis는 샤드 개수만큼 병렬 처리 가능
• SQS FIFO는 메시지 그룹 수만큼 병렬 처리 가능

7. Amazon MQ

기본 개념

• 기존 **온프레미스 메시지 브로커(RabbitMQ, ActiveMQ)**를 클라우드로 이전할 때 사용
• MQTT, AMQP, STOMP 등 개방형 프로토콜 지원
• SQS/SNS와 달리 브로커 기반 메시징

특징

• 주제(topic), 큐(queue) 동시 제공
• 고가용성 구성 지원 (다중 AZ, EFS 백엔드)
• 전통적인 시스템 통합에 적합
• 자동 스케일링/무제한 확장은 불가

활용 사례

• 레거시 시스템 마이그레이션
• 표준 프로토콜이 필수인 애플리케이션
• 하이브리드 아키텍처 구성 시 브릿지 역할

8. 메시징 서비스 선택 가이드

• SQS: 분산 작업자 시스템, 큐 기반 버퍼링, 내결함성 요구 시
• SNS: 이벤트 알림, 다중 수신자 필요 시, 알람 및 트리거 용도
• Kinesis: 실시간 스트리밍 데이터 처리, 빅데이터 파이프라인 구축
• Amazon MQ: 표준 프로토콜 호환이 필요한 기존 애플리케이션