AWS 메시징

💬 AWS 메시징 완벽 정리: SQS, SNS, Kinesis 차이와 활용법

현대 애플리케이션은 점점 복잡해지고 있으며, 각 기능이 별도의 서비스로 나뉘어 배포되는 경우가 많습니다. 이런 환경에서 중요한 건, 서비스 간의 안정적인 통신이죠.
AWS에서는 이를 위해 SQS, SNS, Kinesis라는 세 가지 강력한 메시징 서비스를 제공합니다.

이 글에서는 세 가지 서비스를 하나씩 뜯어보며, 언제, 왜, 어떻게 사용하는지 자세히 살펴보겠습니다.

---

🔄 먼저, 왜 메시징 서비스가 필요할까요?

📍 서비스 간 통신 방식

• 동기(Synchronous): 한쪽이 요청을 보내고, 응답을 기다리는 구조
  → 예: 웹 서버가 DB에 직접 요청하고 응답받기
• 비동기(Asynchronous): 요청을 큐(queue)에 넣고, 나중에 처리되는 구조
  → 예: 사용자가 주문 버튼을 누르면, 주문 내용은 큐에 쌓이고 백엔드가 천천히 처리

📍 왜 비동기 메시징이 필요할까?

• 트래픽이 갑자기 폭증하면 동기 구조는 병목이 생김
• 예: 보통 10개 영상만 처리하던 서비스가 어느 날 1000개를 처리해야 한다면?
• 이럴 때는 SQS/SNS/Kinesis를 통해 각 서비스를 독립적으로 확장 가능

---

📨 Amazon SQS – 큐 기반 메시징 서비스

SQS(Simple Queue Service)는 가장 오래된 AWS 메시징 서비스입니다.

✅ 핵심 기능

• Producer → Queue → Consumer 구조
• 메시지는 최대 14일간 보관
• 소비자가 메시지를 받아 처리 후 삭제(DeleteMessage API)
• 표준(Standard) 큐: 중복 허용, 순서 보장 없음
• FIFO 큐: 순서 보장, 중복 제거 기능 제공

✅ 실전 예시

• 웹 프론트에서 주문 요청 → SQS 큐 → 백엔드에서 순차적으로 처리
• EC2 Auto Scaling 그룹과 연동하여 처리량 증가에 따라 소비자 수 자동 확장

🔐 보안

• HTTPS 기반 전송 암호화, KMS를 통한 저장 암호화
• IAM 및 SQS Access Policy로 접근 제어

⏳ 메시지 가시성 타임아웃

• 메시지를 가져오면 일정 시간 동안 다른 소비자에게 안 보임 (기본 30초)
• 시간 내에 처리 안 되면 다시 보이므로 중복 처리 가능성 존재

⌛ Long Polling

• 메시지가 없을 때, 지정한 시간(최대 20초)만큼 기다렸다가 응답
• API 호출 수 줄이고 효율성 증가

---

📣 Amazon SNS – 퍼블리시/서브스크라이브 방식

SNS(Simple Notification Service)는 이벤트 기반으로 다수에게 동시에 메시지를 전달합니다.

✅ 핵심 기능

• 한 메시지를 여러 구독자에게 동시에 전송
• SQS, Lambda, Email, SMS, HTTP 등 다양한 타입의 수신자 연결 가능
• 메시지 필터링 기능으로 특정 조건에 맞는 구독자만 수신 가능

✅ 실전 예시

• 주문 발생 → SNS로 이벤트 발행 → 배송, 결제, 이메일 알림 등 각각 수신

🔐 보안

• HTTPS 암호화, KMS 저장 암호화
• IAM, SNS Access Policy로 접근 제어

🔁 SNS + SQS 구조 (Fan-out)

• 하나의 SNS 토픽에서 여러 SQS 큐로 메시지를 분산
• 서비스 간 완전한 분리 가능 (디커플링 구조)

🧠 SNS FIFO 토픽

• 메시지 순서 보장 및 중복 제거 기능
• SQS FIFO 큐와 함께 사용하면 순서 + 재시도 + 다수 수신자 구조 완성

 

 

⚡ Amazon Kinesis – 실시간 데이터 스트리밍의 핵심

Amazon Kinesis는 실시간 데이터 스트리밍을 위한 서비스로, 대규모의 데이터를 빠르게 수집, 처리, 분석할 수 있게 도와줍니다. Kinesis는 실시간 분석이 필요한 상황에서 강력한 도구로, 예를 들어 IoT 센서 데이터, 웹 클릭 스트림, 로그 분석 등의 데이터 흐름을 처리할 때 사용됩니다.

✅ Kinesis의 주요 서비스 구성 요소

1. Kinesis Data Streams
   • 데이터 스트림을 생성하여 실시간 데이터를 수집하고 처리하는 기본 구성 요소입니다.
   • 데이터를 shard 단위로 나누어 저장하고 처리합니다.
     • 1 샤드는 초당 1MB의 입력과 2MB의 출력을 처리할 수 있습니다.
   • **프로듀서(Producer)**는 데이터를 스트림으로 보냅니다. 예를 들어 웹사이트에서 발생하는 클릭 데이터를 실시간으로 스트림에 기록할 수 있습니다.
   • **컨슈머(Consumer)**는 스트림에서 데이터를 읽고 처리합니다. 예를 들어, Lambda나 EC2 인스턴스를 사용하여 데이터를 실시간으로 분석하거나 저장할 수 있습니다.
   • 재처리 가능 (Replay): 데이터는 최대 365일 동안 저장되며, 소비자는 필요시 과거 데이터를 재처리할 수 있습니다.
2. Kinesis Data Firehose
   • 완전 관리형 스트리밍 서비스로, 실시간 데이터 스트림을 S3, Redshift, OpenSearch 등으로 자동으로 전송합니다.
   • 버퍼링 기능을 통해 데이터를 일정 시간 또는 크기만큼 모은 뒤 일괄 처리할 수 있어 지연 시간이 중요한 상황에서 유용합니다.
   • 데이터가 전송되기 전에 AWS Lambda를 이용해 데이터 변환도 가능합니다. 예를 들어, CSV 파일을 JSON 형식으로 변환 후 저장할 수 있습니다.
3. Kinesis Data Analytics (Flink 기반)
   • 실시간으로 스트리밍 데이터를 SQL 기반으로 분석할 수 있는 서비스입니다.
   • 데이터를 수집한 뒤, 실시간으로 분석하고 결과를 다른 시스템으로 전송할 수 있습니다.
   • Apache Flink를 기반으로 하여 고급 실시간 분석을 가능하게 합니다.

---

✅ Kinesis의 특징과 장점

1. 실시간 처리
   • Kinesis는 데이터를 실시간으로 스트리밍하여 즉시 분석할 수 있습니다. 이는 대규모 데이터 환경에서 중요한 요소입니다.
   • 예를 들어 실시간 광고 클릭 분석, 트랜잭션 분석, IoT 센서 데이터 모니터링 등 빠른 데이터 처리가 필요한 모든 분야에서 활용 가능합니다.
2. 자동 확장
   • Provisioned mode에서 shard 수를 수동으로 설정하거나, On-demand mode에서는 자동으로 확장되어, 사용자는 데이터 트래픽에 맞게 유연하게 대응할 수 있습니다.
   • 온디맨드 모드는 자동으로 확장되므로 관리자가 직접 샤드를 추가/제거할 필요가 없습니다.
3. 내구성
   • Kinesis Data Streams는 데이터를 최대 365일 동안 저장할 수 있고, 데이터 손실 없이 **다시 처리(replay)**할 수 있습니다.
   • Kinesis Data Firehose는 기본적으로 데이터를 실시간으로 전송하며 배치 처리도 지원하여 데이터 손실 없이 안정적인 전송을 보장합니다.
4. 확장성
   • Kinesis는 대량의 데이터를 처리할 수 있는 확장 가능한 아키텍처를 제공합니다. 데이터 흐름이 증가하면 샤드를 추가하여 성능을 확장할 수 있습니다.
5. 대규모 데이터 처리
   • Clickstream 데이터, 로그 분석, IoT 센서 데이터와 같이 대량의 작은 데이터를 실시간으로 처리할 수 있습니다.

---

✅ Kinesis 데이터 스트리밍 활용 예시

1. 웹사이트 클릭 스트림 분석
   • Kinesis를 사용해 웹사이트에서 발생하는 사용자 클릭 데이터를 실시간으로 수집하고, 실시간 분석을 통해 사용자의 행동을 추적하거나, 맞춤형 광고를 제공할 수 있습니다.
2. IoT 데이터 수집 및 분석
   • 수천 개의 IoT 장치에서 발생하는 데이터를 Kinesis로 실시간 수집하여 서버로 전송하고, 이를 즉시 분석하여 장비의 이상 상태를 모니터링하거나 경고를 보낼 수 있습니다.
3. 로그 분석
   • 서버에서 발생하는 로그 데이터를 실시간으로 Kinesis로 스트리밍하여, 로그를 즉시 분석하고, 에러를 실시간으로 탐지할 수 있습니다.
4. 실시간 금융 데이터 처리
   • 주식 거래 데이터나 금융 거래 데이터를 실시간으로 스트리밍하여 가격 변화나 시장 변동성을 분석하고 실시간 대응할 수 있습니다.

🔄 Kinesis vs Firehose

 

기능	Data Streams	Data Firehose
처리 방식	직접 작성 (실시간)	완전관리형 (버퍼 후 전송)
데이터 저장	최대 365일 저장 가능	저장 안 됨
재처리 가능	가능	불가
목적지	S3, Redshift, OpenSearch 등	S3, Redshift, 3rd-party 등

 

---

🧾 정리: SQS, SNS, Kinesis 차이 한눈에 보기

항목	SQS	SNS	Kinesis
구조	Queue (Pull)	Pub/Sub (Push)	Streaming (Push/Pull 혼합)
저장	최대 14일	저장 안 됨	최대 365일 저장
순서	FIFO 큐에서만 보장	FIFO 토픽에서만 보장	파티션 키 기준 순서 보장
중복	일부 허용	보장 안 됨	Deduplication 가능
대상	단일 소비자	다수 구독자	스트리밍 분석 및 ETL
확장성	무한 소비자 확장	최대 1,250만 구독자	샤드 기반 확장 / 온디맨드 확장

 

---

✍ 마무리

• SQS는 요청이 많아도 순차적으로 안정적으로 처리하고 싶을 때
• SNS는 하나의 이벤트로 여러 곳에 알림을 보내야 할 때
• Kinesis는 대량의 실시간 데이터를 빠르게 수집하고 분석할 때