SQS·SNS·Kinesis·Amazon MQ·EventBridge가 왜 따로 존재하는지 우체통·방송국·컨베이어 벨트 비유로 풀고, Visibility Timeout·DLQ·Fan-out 패턴·KDS vs Firehose 차이·Redshift 로드 함정까지 시험에 자주 나오는 시나리오 위주로 친절하게 정리한 SAA-C03 메시징 통합 단원.
이 글은 AWS Certified Solutions Architect Associate(SAA-C03) 스터디 노트 시리즈의 일곱 번째 편입니다. 메시징·이벤트 단원은 처음 들으면 유난히 헷갈리는 영역이에요. 비슷해 보이는 서비스가 5~6개씩 한꺼번에 쏟아져 나오거든요 — SQS, SNS, Kinesis Data Streams, Kinesis Data Firehose, Amazon MQ, EventBridge…. "이게 그거 아닌가?" 싶은 게 정말 많습니다. 이 단원의 출발점이자 가장 많이 등장하는 주인공이 SQS라서, 이 글도 SQS를 중심에 두고 풀어 갑니다.
그런데 막상 시험 문제를 풀어 보면, 이 단원이 시나리오 문제의 단골이라는 걸 알게 돼요. "트래픽 폭증으로 DB가 죽지 않게 하려면?"의 답은 거의 항상 SQS 버퍼 패턴, "S3에 파일이 올라올 때마다 여러 시스템이 동시에 처리하려면?"의 답은 SNS + SQS Fan-out, "온프레미스 RabbitMQ를 코드 수정 없이 클라우드로 옮기려면?"은 Amazon MQ — 전부 이 단원에서 답이 나옵니다.
핵심은 각 서비스가 어떤 문제를 풀려고 만들어졌는지 이해하는 거예요. 한 번 그림이 잡히면 시나리오 키워드만 봐도 답이 자동으로 떠오릅니다. 이 글에서는 우체통, 방송국, 컨베이어 벨트 같은 비유를 자주 쓸 거고, 시험에 자주 나오는 함정도 그때그때 짚어 드릴게요. 공식 문서가 필요할 땐 SQS 개발자 가이드를 곁에 두면 좋습니다.
동기 vs 비동기 — 왜 디커플링이 그렇게 중요할까요
먼저 이 단원의 큰 그림부터 잡고 갑니다. 분산 시스템에서 두 서비스가 통신하는 방식은 크게 두 가지예요.
동기(Synchronous) 통신은 서비스 A가 B에게 직접 전화를 거는 방식입니다. "이거 처리해 줘" → B가 즉시 응답. 직관적이긴 한데, B가 느려지면 A도 같이 느려져요. B가 죽으면 A도 같이 죽습니다. 마치 사무실 두 책상이 끈으로 묶여 있어서 한쪽이 넘어지면 같이 넘어지는 구조.
비동기(Asynchronous) 통신은 사이에 우체통(큐) 을 둡니다. A는 우체통에 편지를 넣고 자기 일을 계속해요. B는 자기 페이스대로 우체통에서 편지를 꺼내 처리합니다. 둘이 서로의 상태를 신경 쓰지 않아도 돼요. 이걸 멋있게 부르는 말이 디커플링(Decoupling) — "결합을 끊는다"는 뜻입니다.
| 구분 | 동기(Synchronous) | 비동기 / 이벤트 기반(Asynchronous) |
|---|---|---|
| 개념 | 애플리케이션 간 직접 연결 | 미들웨어(Queue 등)로 간접 통신 |
| 예시 | 구매 서비스가 배송 서비스에 직접 요청 | 구매 서비스는 큐에 메시지 투입 후 종료. 배송 서비스가 큐에서 꺼내 처리 |
| 단점 | 트래픽 급증 시 과부하·병목 | 아키텍처가 다소 복잡 |
| 장점 | 구조 직관적 | 디커플링·독립 확장 용이 |
디커플링은 SAA-C03에서 가장 자주 등장하는 키워드 중 하나입니다. "한 서비스의 장애가 다른 서비스로 번지지 않게 하라", "트래픽 급증 시에도 DB가 안전하게 동작하도록 하라" 같은 시나리오가 나오면 답은 거의 항상 큐를 사이에 끼우는 비동기 패턴이에요.
이 단원에서 다루는 5개 서비스를 한 줄씩 미리 소개하고 갈게요.
- Amazon SQS — 우체통. 메시지를 쌓아두고 한 명이 꺼내 처리. 디커플링의 표준
- Amazon SNS — 방송국·메일링 리스트. 한 번 외치면 모든 구독자가 동시에 들음
- Amazon Kinesis — 실시간 컨베이어 벨트. 끊임없이 흘러오는 데이터를 흘러가는 채로 처리
- Amazon MQ — 옛날 우체국 그대로. 온프레미스 메시지 브로커를 코드 수정 없이 옮길 때
- Amazon EventBridge — 사내 알림 게시판. 어디서 무슨 일이 일어났는지 규칙 기반으로 라우팅
각자 풀려는 문제가 달라요. 이제 하나씩 들여다봅니다.
SQS — 가장 단순하고 강력한 우체통
SQS(Simple Queue Service) 는 AWS 메시징의 가장 기본형입니다. 비유하자면 — 회사 안의 공용 우체통 같은 거예요. 누군가가 편지(메시지)를 넣어두면, 우체통을 확인하는 직원이 와서 한 통씩 꺼내 처리합니다.
여기 등장인물이 둘이에요.
- 생산자(Producer) — 메시지를 만들어서 SQS에 넣는 쪽. SDK의
SendMessageAPI 호출 - 소비자(Consumer) — 메시지를 꺼내서 처리하는 쪽. 폴링(Polling)으로 한 번에 최대 10개까지 가져옴
여기서 시험에 가장 자주 나오는 함정 하나 — 소비자가 메시지를 처리한 뒤에는 반드시 DeleteMessage API로 명시적으로 삭제해야 큐에서 빠집니다. "그냥 읽으면 자동으로 사라지지 않나?" — 아니에요. 명시적으로 지워줘야 해요. 안 지우면 잠깐 동안 숨겨졌다가 다시 큐에 나타납니다(이 부분은 곧 Visibility Timeout에서 자세히 설명할게요).
Standard Queue 핵심 스펙
처음에 외울 숫자 몇 개가 있어요. 이 숫자들이 시험에 거의 매번 한두 개씩 나옵니다.
- 처리량 무제한 — 초당 메시지 수 제한 없음
- 지연 시간 10ms 이내
- At-least-once delivery — 최소 한 번은 전달, 즉 중복 전달 가능
- Best-effort ordering — 보낸 순서와 다르게 받을 수 있음
- 메시지 보존 기간 — 기본 4일, 최대 14일
- 최대 메시지 크기 — 256KB (이걸 넘으면 Extended Client Library + S3 사용)
여기서 시험 함정이 둘 있어요. 첫째, Standard Queue는 중복과 순서 미보장이 기본입니다. "정확히 한 번", "엄격한 순서"가 필요하면 FIFO Queue를 써야 해요(뒤에 나옵니다). 둘째, 메시지 크기 256KB 한계는 자주 묻는데, 이 이상이면 본문을 S3에 올리고 SQS에는 포인터만 보내는 Extended Client Library 패턴이 정답입니다.
Visibility Timeout — 같은 메시지를 두 명이 처리하지 않게 하는 장치
이 부분이 SQS에서 가장 헷갈리는 개념인데, 한 번 잡으면 끝까지 통합니다. 천천히 풀어 갈게요.
상황을 상상해 봅시다. 우체통에 편지가 한 장 들어 있어요. 직원 A가 와서 편지를 꺼냈습니다. 그런데 만약 편지가 그 즉시 우체통에서 사라진다면? — A가 처리하다가 갑자기 컴퓨터가 꺼지면 그 편지는 영원히 사라져요. 그렇다고 A가 편지를 꺼낸 뒤에도 우체통에 남아 있으면? — 직원 B가 와서 같은 편지를 또 가져갑니다. 둘이 같은 일을 두 번 하는 거예요.
SQS는 이걸 Visibility Timeout으로 풉니다. 직원 A가 편지를 꺼낸 순간, 그 편지는 일정 시간 동안 다른 직원에게는 안 보이게 숨겨져요. 그 시간 안에 A가 처리를 끝내고 DeleteMessage를 호출하면 진짜로 사라집니다. 만약 시간 안에 못 끝내면? 편지가 다시 우체통에 나타나서 다른 직원이 가져갈 수 있게 돼요.
핵심 숫자를 외워둡시다.
- 기본값 30초
- 설정 범위 0초 ~ 최대 12시간
- 처리 시간이 더 필요하면
ChangeMessageVisibilityAPI로 연장 가능
여기서 시험 함정이 정말 자주 나와요. Trade-off를 묻는 문제예요.
- 너무 길게 설정하면 — 소비자가 크래시 나도 메시지가 다시 나오기까지 오래 걸려요. 다른 직원이 그 시간 동안 그 편지를 못 가져가니까요.
- 너무 짧게 설정하면 — 처리 끝나기 전에 타임아웃이 만료돼서 같은 메시지가 두 번 처리됩니다.
베스트 프랙티스는 평균 처리 시간에 맞춰 기본값을 잡고, 가끔 오래 걸리는 작업에만 ChangeMessageVisibility로 연장하는 거예요. 시험에서 "메시지가 중복 처리되는데 어떻게 해야 하나?"의 정답이 이 패턴입니다.
Dead Letter Queue — 처리 실패 메시지를 따로 모아두는 곳
가끔 메시지 자체가 잘못돼서 아무리 처리하려 해도 실패하는 경우가 있어요. JSON이 깨져 있다거나, 참조하는 데이터가 이미 삭제됐다거나. 이걸 무한 반복하면 큐가 그 메시지로 막혀버립니다.
Dead Letter Queue(DLQ) 는 이런 골칫거리 메시지를 따로 격리하는 별도 큐예요. maxReceiveCount 설정으로 "몇 번까지 실패하면 DLQ로 보낼지"를 정합니다. 예를 들어 5로 설정하면, 같은 메시지가 5번 처리 실패할 때마다 자동으로 DLQ로 옮겨져요. 그러면 본 큐는 다음 메시지로 넘어갈 수 있고, 운영자는 나중에 DLQ를 들여다보면서 원인을 파악할 수 있죠.
여기서 시험 함정이 하나 있어요 — SQS와 Lambda를 같이 쓰는 시나리오에서 DLQ는 SQS 큐 쪽에 설정합니다. Lambda 함수 자체에 거는 게 아니에요. 반면 SNS와 Lambda 시나리오에서는 DLQ를 Lambda 함수에 직접 연결합니다(SNS는 메시지를 보관하지 않으니까요). 헷갈리지 않게 짚어 두시면 돼요.
Long Polling vs Short Polling — 빈 응답을 줄이는 기술
소비자가 큐에 새 메시지가 있는지 확인하는 방식이 두 가지예요.
| 구분 | Short Polling (기본) | Long Polling (권장) |
|---|---|---|
| 동작 | 큐가 비어있으면 즉시 빈 응답 | 메시지 도착할 때까지 일정 시간 대기 |
| API 호출 수 | 빈 응답이 많아 불필요한 호출 다수 | 빈 응답 감소 → 비용 절감 |
| 지연 시간 | 상대적으로 불규칙 | 메시지 도착 즉시 전달 |
| 설정 | 기본값 | WaitTimeSeconds 1~20초, 20초 권장 |
비유하자면 — Short Polling은 1분마다 우체통을 열어보고 "비었네" 하고 닫는 거예요. 빈 응답이 잔뜩 쌓입니다. Long Polling은 우체통 옆에 서서 "최대 20초 동안 편지가 들어오면 바로 알려주세요" 하고 기다리는 거예요. API 호출 비용도 줄고 지연 시간도 짧아져서 거의 모든 경우에 Long Polling이 정답입니다.
Delay Queue — 메시지를 일정 시간 숨겼다 풀기
Delay Queue는 DelaySeconds 파라미터로 메시지를 최대 15분까지 보이지 않게 숨겼다가 풀어 주는 기능입니다. 회원가입 후 정확히 30초 뒤에 환영 이메일을 보내야 한다면, 가입 처리 시점에 30초 지연 메시지를 큐에 넣어두면 돼요. SQS Standard만 가능하고 FIFO에는 다른 방식이 있다는 점만 기억해 두세요.
SQS + ASG 스케일링 — 시험 단골 패턴
시험에 정말 자주 나오는 패턴이 SQS + Auto Scaling Group 조합입니다. EC2 인스턴스(ASG 안)가 SQS 큐를 폴링해서 메시지를 처리하는 구조예요.
핵심 CloudWatch 지표 이름을 꼭 외워둡시다 — ApproximateNumberOfMessagesVisible. 큐에 남아 있는 메시지 수를 나타내는 지표인데, 이 값이 임계값을 넘으면 ASG가 EC2를 추가(Scale-out)하고, 줄어들면 줄여요(Scale-in). 시험에서 "SQS 기반 워커의 자동 확장 지표"를 묻는 문제의 정답이 항상 이거예요.
DB Write Buffer — 트래픽 폭증으로부터 DB를 지키는 패턴
이 패턴이 시험에 자주 나옵니다. 시나리오를 한 번 그려 볼게요.
쇼핑몰에 갑자기 트래픽이 10배 폭증했어요. 프론트엔드는 어떻게든 요청을 받아내는데, RDS는 동시 쓰기 처리에 한계가 있어서 그대로 받으면 죽어 버립니다. 어떻게 풀까요?
해결은 SQS를 버퍼로 끼워 넣는 것입니다.
- 프론트엔드 앱이 DB에 직접 쓰지 않고 SQS 큐에 메시지(트랜잭션 데이터)를 넣고 끝
- 백엔드 워커 ASG가 SQS에서 메시지를 한 번에 한 묶음씩 꺼내서 DB에 안전한 속도로 INSERT
- 쓰기 완료 후 SQS에서 메시지 삭제
SQS는 무한대로 확장 가능하니까 트래픽이 아무리 늘어도 메시지 유실이 없고, DB는 워커가 정해진 속도로만 호출하니까 과부하 없이 안전하게 처리됩니다.
여기서 함정이 하나 있어요 — 이 패턴은 클라이언트가 즉시 동기적으로 DB 쓰기 결과를 확인할 필요가 없는 경우에만 적합합니다. "주문이 정확히 처리됐는지 그 자리에서 확인해야 한다" 같은 시나리오엔 안 맞아요.
SQS FIFO — 순서와 정확히 한 번이 필요할 때
Standard Queue는 빠르고 무한 확장되지만 순서 미보장 + 중복 가능입니다. 금융 트랜잭션처럼 순서와 정확성이 중요한 경우엔 부족해요. 그래서 있는 게 FIFO Queue입니다.
핵심 특징:
- 선입선출(First-In-First-Out) — 보낸 순서대로 정확히 수신
- 정확히 한 번 처리(Exactly-Once) — 큐 수준에서 중복 자동 제거
- 이름이 반드시
.fifo로 끝나야 함 (예:DemoQueue.fifo)
처리량은 Standard보다 훨씬 낮아요.
- Batching 없음 — 초당 300개
- Batching 있음 — 초당 3,000개
중복 제거(Deduplication) 는 5분 이내 동일 메시지를 자동으로 걸러냅니다. 두 가지 방식이 있어요 — Deduplication ID로 명시적으로 부여하거나, 콘텐츠 기반 중복 제거로 메시지 본문 해시를 자동 사용.
Message Group ID는 FIFO 큐에 메시지 보낼 때 필수 파라미터입니다. 여기서 시험 함정이 또 하나 — 순서 보장은 전체 큐가 아니라 동일 Message Group ID 내에서만 이루어집니다. 다른 그룹 ID는 병렬로 처리될 수 있어요. 비유하자면 — 우체통에 칸이 여러 개 있어서 같은 칸 안에서만 순서가 지켜지는 거예요. 다른 칸끼리는 동시에 처리됩니다.
SQS 보안
| 영역 | 방식 |
|---|---|
| 전송 중 암호화 | HTTPS API |
| 저장 시 암호화 | KMS(SSE-KMS) — Data Key Reuse Period로 KMS 호출 비용·스로틀링 절감 |
| 관리형 키 | SSE-SQS (기본 활성화) |
| 클라이언트 측 | 사용자가 직접 암호화/복호화 |
| 접근 제어 | IAM 정책(사용자/역할) + SQS 액세스 정책(리소스 기반, 교차 계정·다른 서비스 허용) |
여기서 짚을 점 — 다른 AWS 서비스(S3, SNS 등)가 SQS에 메시지를 보낼 수 있게 하려면 SQS 액세스 정책(리소스 기반) 을 사용합니다. 이건 SNS+SQS Fan-out에서 결정적인데, 곧 풀게요.
SNS — Pub/Sub 모델의 방송국
이제 두 번째 서비스 SNS(Simple Notification Service) 입니다. SQS가 우체통이라면 SNS는 방송국·메일링 리스트예요.
비유로 풀면 — 라디오 방송국에서 한 번 방송하면 청취자들이 모두 동시에 듣잖아요. SNS도 똑같습니다. Publisher가 SNS 토픽(Topic)에 메시지를 한 번 게시하면, 그 토픽을 구독한 모든 Subscriber에게 동시에 메시지가 전달됩니다. 이게 Pub/Sub(Publish/Subscribe) 모델이에요.
규모도 어마어마합니다 — 토픽당 1,200만 명 이상의 구독자, 계정당 최대 10만 개 토픽(한도 증설 가능).
SNS의 가장 큰 함정 — 데이터가 지속되지 않습니다
여기서 시험에 정말 자주 나오는 함정 하나 — SNS는 데이터가 지속되지 않습니다(Not persistent). 메시지를 토픽에 게시한 순간 구독자에게 배달을 시도하는데, 구독자가 없거나 배달이 실패하면 메시지가 그냥 사라져요. SQS처럼 큐에 쌓아두는 게 아니거든요.
그래서 "메시지 유실 없이 안전하게 받아야 한다"는 시나리오에서는 SNS만으로는 부족하고, SNS 뒤에 SQS를 붙여서 SQS가 메시지를 보관하게 만드는 패턴(곧 나올 Fan-out)이 정답이 됩니다.
SNS 구독자 종류
구독자(Subscriber)는 두 부류로 나뉩니다.
- 사용자 대상 — 이메일, SMS(문자), 모바일 푸시 알림(GCM·APNS), HTTP/HTTPS 엔드포인트
- AWS 서비스 대상
- SQS 큐 (Fan-out에서 가장 많이 쓰이는 조합)
- AWS Lambda (메시지 수신 후 즉시 코드 실행)
- Kinesis Data Firehose (S3·Redshift 같은 곳으로 데이터 적재)
이벤트 소스(SNS에 메시지를 보내는 쪽)는 — CloudWatch 알람, ASG, S3 이벤트, CloudFormation, RDS, DynamoDB, Lambda, Budgets 등 거의 모든 AWS 서비스가 SNS와 통합돼 있어요.
SNS Standard vs FIFO
SNS도 SQS처럼 두 종류가 있습니다.
| 구분 | Standard 토픽 | FIFO 토픽 |
|---|---|---|
| 메시지 순서 | Best-effort | 엄격한 순서 보장 |
| 전달 보장 | At-least-once | Exactly-once |
| 처리량 | 무제한 (최고 처리량) | 최대 300건/초 |
| 지원 구독자 | SQS·Lambda·HTTP/S·SMS·Email·모바일·Firehose | 오직 SQS FIFO 대기열만 |
| 이름 규칙 | 제한 없음 | 끝에 반드시 .fifo |
여기서 시험 함정 — SNS FIFO 토픽을 구독할 수 있는 건 SQS FIFO 큐뿐입니다. Lambda나 이메일 구독은 안 돼요. "순서 보장 Pub/Sub이 필요한데 Lambda를 직접 구독시키려면…" 같은 보기는 무조건 오답이에요.
메시지 필터링 — 구독별로 받을 메시지를 가린다
같은 토픽을 구독하는 여러 SQS 큐가 있는데, 어떤 큐는 "주문 생성" 메시지만 받고 어떤 큐는 "주문 취소" 메시지만 받게 하고 싶다면? 메시지 필터링(Message Filtering) 을 써요.
구독(Subscription) 수준에 JSON 형태의 필터 정책을 붙이면, 그 구독자는 자기 조건에 맞는 메시지만 받습니다. 예를 들어:
- 배송 서비스 SQS —
{"status": ["placed"]}만 수신 - 환불 서비스 SQS —
{"status": ["canceled"]}만 수신
필터 정책이 없으면 토픽의 모든 메시지를 받아요(기본값). 이걸 알아두면 "한 토픽으로 다양한 다운스트림에 분기" 시나리오를 깔끔하게 풀 수 있습니다.
SNS + SQS Fan-out 패턴 — 이 단원 최대 출제 포인트
SAA-C03에서 메시징 단원 시험 문제의 거의 절반은 이 패턴 변형입니다. 천천히 풀어 갑니다.
Fan-out은 한 메시지를 여러 시스템에 동시에 뿌리는 패턴이에요. 비유로 풀면 — 회사에서 "내일 오후 2시 전체 회의" 공지가 떴을 때, 부서장 한 명이 한 번 발표하면 모든 부서가 동시에 듣는 구조죠.
구체적으로는:
[Publisher] → [SNS Topic] → [SQS Queue 1] → [Consumer 1 (결제 서비스)]
→ [SQS Queue 2] → [Consumer 2 (재고 서비스)]
→ [SQS Queue 3] → [Consumer 3 (배송 서비스)]장점이 정말 많아요.
- 데이터 손실 방지 — SNS만 쓰면 메시지가 유실될 수 있는데, SQS가 메시지를 보존해 주니까 안전함
- 완벽한 디커플링 — 각 소비자가 독립적으로 자기 페이스대로 처리
- 확장성 — 새 서비스를 붙일 때 기존 시스템 수정 없이 SQS 큐 하나만 새로 추가하고 SNS 토픽을 구독하면 끝
여기서 시험 함정 하나 — Fan-out 패턴이 동작하려면 SQS 액세스 정책(리소스 기반 정책)에서 SNS 토픽의 쓰기 권한을 명시적으로 허용해야 합니다. SNS가 SQS에 메시지를 쓸 권한이 없으면 메시지가 못 들어가요. "Fan-out이 동작하지 않는 이유는?"의 정답이 자주 이 권한 누락이에요.
또 하나 알아둘 점 — 리전 간 배달이 가능합니다. A 리전 SNS 토픽이 B 리전 SQS 큐로 메시지를 보낼 수 있어요(권한만 허용되면).
S3 이벤트 알림의 한계 극복
S3 이벤트 규칙은 동일한 이벤트 유형 + 접두사(Prefix) 조합에 단 하나의 대상만 지정할 수 있어요. 예를 들어 images/ 접두사의 ObjectCreated 이벤트를 Lambda로도 보내고 SQS로도 보내고 싶으면? — 그대로는 안 됩니다.
해결책이 Fan-out이에요. S3 이벤트를 SNS 토픽 하나로 보내고, 거기에 여러 SQS 큐(또는 Lambda)가 구독하면 됩니다.
[S3 Upload] → [SNS Topic] → [SQS Queue A] → [썸네일 생성 서비스]
→ [SQS Queue B] → [메타데이터 추출 서비스]시험에 자주 나오는 시나리오니까 패턴 자체를 외워두세요.
FIFO Fan-out
순서 보장 + 중복 제거가 필요한 Fan-out은 SNS FIFO 토픽 → SQS FIFO 큐(여러 개) 조합이에요. 사기 탐지 + 원장 기록처럼 순서가 중요한 다중 다운스트림에 적합합니다.
Kinesis — 실시간 스트리밍의 컨베이어 벨트
이제 좀 다른 결의 서비스 Amazon Kinesis입니다. SQS·SNS가 "메시지 단위로 끊어 보내는 것"이라면 Kinesis는 끊임없이 흐르는 데이터 스트림이에요. 비유하자면 — 공장의 컨베이어 벨트처럼, 데이터가 계속 밀려 들어오고 여러 작업자가 그 벨트에서 데이터를 꺼내 동시에 작업하는 모델입니다.
Kinesis 패밀리는 네 가지가 있어요 — Data Streams, Data Firehose, Data Analytics, Video Streams. 시험에서 가장 자주 나오는 두 개가 Data Streams와 Firehose라서 이 둘을 집중적으로 풀게요.
Kinesis Data Streams — "실시간(Real-time)"이 핵심 키워드
KDS는 한 마디로 실시간 빅데이터 수집·처리 서비스입니다. 시험에서 "Real-time", "Replay", "샤드(Shard)" 같은 키워드가 보이면 이쪽이에요.
구성 요소부터 봅시다.
- Producer(생산자) — 데이터를 KDS로 보내는 쪽
- 일반 앱, AWS SDK
- KPL(Kinesis Producer Library) — 고처리량용 라이브러리. 재시도 로직·비동기 전송 같은 고수준 API 제공
- Kinesis Agent — 서버에 설치하는 데몬. 메트릭·로그를 자동으로 KDS에 전송
- Consumer(소비자) — KDS에서 데이터를 읽어 처리하는 쪽
- 일반 앱, Lambda, Kinesis Data Firehose, Apache Flink Managed Service
- KCL(Kinesis Client Library) — 샤드 추적 같은 복잡한 작업을 알아서 해주는 고수준 소비자 라이브러리
핵심 특징과 숫자 — 이 부분은 시험에 거의 매번 나옵니다.
- 데이터 보존 기간 — 기본 24시간, 최대 365일
- 데이터 재처리(Replay) 가능 — 데이터가 스트림에 남아 있어서 소비자가 다시 읽을 수 있음
- 불변성(Immutability) — 한 번 전송된 데이터는 임의로 삭제 불가 (보존 기간 만료 시에만 자동 삭제)
- 순서 보장 — 동일한 Partition Key를 가진 데이터는 동일한 샤드(Shard)로 가서 순서가 엄격히 보장됨
- 단일 레코드 최대 크기 1MB
- 보안 — 미사용 데이터 KMS 암호화, 전송 중 HTTPS
여기서 한 줄 정리 — SQS는 처리하면 삭제, Kinesis는 처리해도 보존입니다. 이게 시험에서 둘을 가르는 가장 큰 차이예요. "데이터를 다시 읽어서 재처리할 수 있어야 한다"가 시나리오에 있으면 무조건 Kinesis예요.
KDS 용량 모드 두 가지
| 구분 | Provisioned 모드 | On-Demand 모드 |
|---|---|---|
| 특징 | 사용자가 샤드 수를 직접 지정 | 자동 확장(Auto-scaling) |
| 용량 (샤드당) | 쓰기 1MB/초 또는 1,000 레코드/초, 읽기 2MB/초 | 기본 4MB/초 또는 4,000 레코드/초, 지난 30일 트래픽 기반 |
| 스케일링 | 수동 (모니터링 후 샤드 분할/병합) | 자동 |
| 과금 | 시간당 프로비저닝된 샤드 수 기준 | 시간당 스트림 요금 + 데이터 송수신량 기준 |
| 적합한 상황 | 트래픽 예측 가능·일정 | 트래픽 예측 불가·변동 심함 |
시험에서 "트래픽 변동이 심한 워크로드"는 거의 항상 On-Demand가 정답이에요.
KDS 소비 메커니즘 두 가지
소비자가 KDS에서 데이터를 읽는 방식이 두 가지 있어요.
- 표준(Standard, Pull) — 샤드당 2MB/초의 읽기 처리량을 여러 소비자가 공유. 소비자가 많아지면 한 명당 처리량이 줄어듦
- Enhanced Fan-Out(Push) — 소비자에게 데이터를 Push하며 소비자당·샤드당 전용 2MB/초. 여러 소비자가 동시에 빠르게 읽어야 할 때
데이터 읽기에서 시험 함정이 두 개 있어요. TRIM_HORIZON(Shard Iterator 유형)은 스트림의 가장 오래된 데이터부터 읽기 시작하는 옵션이고, KDS에서 읽어온 데이터는 Base64로 인코딩되어 있어서 디코딩이 필요합니다. "Lambda가 KDS 데이터를 받았는데 이상한 문자열이 나온다" 시나리오의 정답이 이 Base64 디코딩이에요.
Kinesis Data Firehose — Near Real-time 적재
Firehose는 KDS와 짝꿍이긴 한데 역할이 달라요. 한 줄로 풀면 — 스트리밍 데이터를 받아서 지정된 대상(S3·Redshift·OpenSearch 등)으로 자동으로 적재해 주는 완전 관리형 서비스입니다.
KDS가 "흐르는 데이터를 처리"한다면 Firehose는 "흐르는 데이터를 어딘가에 차곡차곡 쌓는다" 가 핵심이에요. 비유하자면 — KDS는 컨베이어 벨트, Firehose는 그 끝에 달린 자동 포장기·창고 적재기입니다. 완전 서버리스, 자동 스케일링, 사용한 만큼 지불.
데이터 흐름은 4단계예요.
① 소스(Sources) — 앱·SDK·Kinesis Agent·Kinesis Data Streams·CloudWatch(Logs/Events)·AWS IoT 등.
② 데이터 처리·변환 —
- Lambda 통합 — 전송 전 데이터 형식 변환 (CSV → JSON, PII 마스킹 같은 작업)
- 포맷 변환 — Parquet, ORC
- 압축 — gzip, snappy
- 버퍼링 — 크기(Size) 또는 시간(Time) 기준으로 모았다가 일괄 전송
③ 대상(Destinations) — 시험 필수 암기:
- AWS 서비스 — Amazon S3, Amazon Redshift(S3 거쳐 COPY), Amazon OpenSearch
- 타사 파트너 — Datadog, Splunk, New Relic, MongoDB
- 사용자 지정 — HTTP 엔드포인트
- DynamoDB·RDS는 기본 목적지가 아님 ← 이거 함정
④ 백업·실패 처리 — 모든 데이터 또는 실패한 데이터만 별도 S3 버킷으로 백업 가능.
Firehose 버퍼링 — 빠르게 보내려면?
Firehose는 데이터를 모아서 일괄로 보냅니다.
- 버퍼 크기(Size) — 1MB ~ 128MB
- 버퍼 간격(Interval) — 60초 ~ 900초
둘 중 하나라도 먼저 충족되면 즉시 전송돼요. 그래서 데이터를 빨리 전달하고 싶으면 버퍼 크기나 버퍼 간격을 줄여야 합니다. 시험에 이 부분이 자주 나와요.
Redshift 로드 함정
여기 시험에 진짜 자주 나오는 함정이 하나 있어요. Firehose가 Redshift로 데이터를 보낼 때, 직접 Redshift에 INSERT하지 않습니다. 반드시 Amazon S3를 중간 기착지로 사용해서 거기에 먼저 저장한 뒤, Redshift의 COPY 명령을 트리거해서 로드하는 구조예요.
Firehose → S3 (중간 기착) → Redshift COPY 명령 → Redshift"Firehose에서 Redshift로 직접 데이터가 들어간다" 같은 보기는 무조건 오답이에요. 반드시 S3 경유.
Kinesis Data Streams vs Firehose 비교
이 비교가 시험에 정말 자주 나와요. 표 그대로 외워두면 좋습니다.
| 구분 | Kinesis Data Streams (KDS) | Amazon Data Firehose |
|---|---|---|
| 주요 목적 | 스트리밍 데이터 수집·처리 | 스트리밍 데이터를 대상에 로드(전송) |
| 실시간 여부 | 완전 실시간(Real-time) | 거의 실시간(Near Real-time) — 버퍼링 때문 |
| 관리 방식 | 프로비저닝 또는 온디맨드(코드 작성 필요) | 완전 관리형 (서버리스, 자동 확장) |
| 데이터 저장 | 최대 1년 저장 | 저장 기능 없음 |
| 데이터 재생(Replay) | 가능 | 불가능 |
| 데이터 변환 | 직접 코드 작성 | Lambda 통한 변환 (내장) |
| 지원 목적지 | 소비자가 자유롭게 처리 | S3·Redshift·OpenSearch·Splunk·HTTP 등 제한적 |
한 줄로 — KDS = 실시간 + 재처리 가능 + 저장, Firehose = 거의 실시간 + 적재 전용 + 저장 없음.
Kinesis Data Analytics와 Video Streams
간단히만 짚고 갑니다.
- Kinesis Data Analytics — 두 모드. SQL 방식(KDS·Firehose에서 읽어 SQL로 실시간 분석)과 Apache Flink Managed Service(Java·Scala·Python으로 스트림 처리)
- Kinesis Video Streams — 카메라·영상 디바이스의 비디오 스트림을 안전하게 AWS로 보내 저장·분석·ML에 활용
Amazon MQ — 마이그레이션 전용 카드
Amazon MQ는 정말 특정한 상황에서만 쓰이는 서비스예요. 한 줄로 풀면 — RabbitMQ나 ActiveMQ 같은 전통적 메시지 브로커를 관리형으로 제공하는 서비스입니다.
비유로 풀면 — SQS·SNS가 "AWS가 처음부터 클라우드용으로 새로 만든 우체국"이라면, Amazon MQ는 옛날부터 쓰던 우체국 그대로를 AWS가 운영해 주는 곳이에요. MQTT, AMQP, STOMP, OpenWire, WSS 같은 전통적인 오픈 프로토콜을 그대로 지원해서, 이미 이 프로토콜을 쓰는 애플리케이션을 코드 한 줄 안 고치고 클라우드로 옮길 수 있게 해줍니다.
핵심 사용 사례 — 온프레미스에서 ActiveMQ나 RabbitMQ를 쓰던 애플리케이션을 클라우드로 마이그레이션할 때, SQS나 SNS API에 맞게 코드를 재작성할 필요 없이 그대로 사용. 단일 브로커 안에서 큐(SQS와 비슷)와 토픽(SNS와 비슷) 기능을 모두 제공합니다.
SQS/SNS vs Amazon MQ 비교
| 구분 | SQS & SNS | Amazon MQ |
|---|---|---|
| 태생 | 클라우드 네이티브 (AWS 독점 API) | 온프레미스 마이그레이션용 |
| 확장성 | 무한대(서버리스) | 서버 기반 (용량 제한·이슈 가능) |
| 프로토콜 | AWS 전용 | MQTT·AMQP·STOMP·OpenWire 등 오픈 |
| 코드 변경 | 필요 | 불필요 (기존 코드 그대로) |
시험 키워드 매칭 — "AMQP·MQTT", "온프레미스 마이그레이션", "코드 변경 없이"가 보이면 무조건 Amazon MQ예요.
Amazon MQ 고가용성 — EFS 함정
Amazon MQ는 Active-Standby Multi-AZ 구조로 고가용성을 구성합니다. 두 AZ에 브로커를 배치하고, 백엔드 스토리지로 Amazon EFS(Elastic File System) 를 써요.
여기서 시험 함정이 하나 있어요 — Amazon MQ의 백엔드 스토리지가 EBS가 아니라 EFS라는 점. 왜냐하면 EFS는 다중 AZ에 마운트되는 네트워크 파일 시스템이라, 활성 브로커가 죽었을 때 대기 브로커가 동일한 EFS에 그대로 마운트해서 데이터 손실 없이 Failover 할 수 있거든요. EBS는 단일 AZ에 묶여 있어서 이 역할을 못 합니다. "Amazon MQ 고가용성을 위한 백엔드 스토리지는?" 정답은 EFS.
EventBridge — 서버리스 이벤트 버스
마지막으로 EventBridge입니다. 비유하자면 — 사내 알림 게시판이에요. AWS 서비스나 SaaS 파트너, 우리 자체 앱에서 발생한 이벤트가 게시판에 올라오면, 미리 정의한 규칙에 따라 적절한 대상으로 자동 라우팅됩니다.
이벤트 버스 유형 세 가지
- Default 이벤트 버스 — AWS 서비스에서 생성되는 이벤트 수신 (기본 제공)
- Custom 이벤트 버스 — 우리 자체 앱이 만든 이벤트
- Partner 이벤트 버스 — Zendesk, Datadog 같은 SaaS 파트너 이벤트
규칙 기반 라우팅
이벤트 소스(S3·EC2·RDS 등)에서 발생한 이벤트를 규칙(Rule) 에 따라 대상(Lambda·SQS·SNS·Kinesis Firehose 등) 으로 라우팅합니다. 이때 이벤트 패턴 매칭(Event Pattern Matching) 으로 특정 조건의 이벤트만 골라낼 수 있어요. 예를 들어 "EC2 인스턴스가 stopped 상태가 됐을 때만" 같은 조건.
스케줄 기능
EventBridge는 Cron 기능도 가지고 있어요.
- Cron 기반 —
cron(0 12 * * ? *)형식으로 특정 시각에 실행 - Rate 기반 —
rate(5 minutes)형식으로 일정 간격 실행
"매일 자정에 Lambda 실행" 같은 시나리오의 정답이 이 EventBridge Schedule이에요.
Schema Registry
EventBridge로 흐르는 이벤트의 스키마(Schema)를 자동으로 발견·저장해 주는 기능입니다. 코드에서 이벤트 데이터의 구조를 미리 알 수 있게 해주고, 코드 자동 생성도 지원해요.
SQS vs SNS vs Kinesis — 한눈에 비교
이 셋을 정확히 구분할 수 있으면 메시징 시나리오 문제의 80%는 풀려요.
| 구분 | SQS | SNS | Kinesis Data Streams |
|---|---|---|---|
| 주요 목적 | 디커플링·비동기 | Pub/Sub·알림 | 실시간 스트리밍 |
| 통신 모델 | Pull (소비자가 가져감) | Push (구독자에게 밀어넣음) | Pull / Enhanced Fan-Out(Push) |
| 메시지 순서 | Standard 미보장 / FIFO 보장 | Standard 미보장 / FIFO 보장 | 샤드 내 보장 |
| 중복 처리 | Standard 가능 / FIFO 불가 | Standard 가능 / FIFO 불가 | 소비자가 재처리 가능 |
| 소비자 수 | 메시지 분배 (1메시지 1소비자) | 모든 구독자 복사본 수신 | 여러 소비자 동일 스트림 가능 |
| 데이터 영속성 | 최대 14일 | 없음 (유실 가능) | 24시간~365일 |
| 데이터 재처리(Replay) | 불가 (삭제 필요) | 불가 | 가능 |
| 확장성 | 무제한 | 무제한 (서버리스) | 샤드 수에 비례 |
| 처리량 프로비저닝 | 불필요 | 불필요 | 프로비저닝 또는 온디맨드 |
| 지연(Delay) 기능 | 있음 (최대 15분) | 없음 | 없음 |
SQS Standard vs FIFO
| 구분 | Standard | FIFO |
|---|---|---|
| 처리량 | 무제한 | 300 TPS / 3,000 TPS(Batching) |
| 메시지 순서 | Best-effort | 엄격한 순서 보장 |
| 중복 전달 | 가능 (At-least-once) | 불가 (Exactly-once) |
| 이름 규칙 | 제한 없음 | 반드시 .fifo |
| 중복 제거 | 없음 | 5분 내 동일 메시지 자동 (Deduplication ID 또는 콘텐츠 기반) |
| 메시지 그룹 | 없음 | Message Group ID (필수) |
| 적합한 사용 사례 | 처리량 우선·순서/중복 허용 | 금융 트랜잭션 등 순서·정확성 |
SQS·SNS·Kinesis 시나리오 패턴 모음
시험 직전에 시나리오 → 답 매칭으로 한 번 정리해 둡시다.
| 시나리오 키워드 | 정답 |
|---|---|
| Decouple, Buffer, Asynchronous, Spiky traffic | Amazon SQS |
| 순서 보장, Exactly-once, 금융 트랜잭션 | SQS FIFO |
| Pub/Sub, 여러 구독자에게 동시 전달, 알림 | Amazon SNS |
| Fan-out, 한 메시지 → 여러 시스템 동시 처리 | SNS + SQS |
| Real-time, Streaming, Big Data, Replay | Kinesis Data Streams |
| Near Real-time, S3/Redshift/OpenSearch로 전송 | Kinesis Data Firehose |
| AMQP·MQTT, 온프레미스 마이그레이션, 코드 변경 없이 | Amazon MQ |
| Amazon MQ 고가용성 스토리지 | Amazon EFS |
| S3 이벤트 → 여러 대상 분기 | S3 → SNS → 여러 SQS |
| DB 과부하 방지 (트래픽 폭증) | Web → SQS → Worker ASG → DB |
| IoT → S3 저장 파이프라인 | KDS → Firehose → S3 |
| FIFO Fan-out (순서 보장 + 다중 소비자) | SNS FIFO → SQS FIFO 여러 개 |
| Kinesis → Redshift 로드 | Firehose → S3 중간 기착 → Redshift COPY |
시험 직전 한 번 더 — 자주 헷갈리는 함정 모음
여기까지가 메시징·이벤트 단원의 핵심입니다. 시험 직전에 다시 펼쳐 볼 압축 노트를 마지막에 박아 둘게요.
- SQS 메시지 크기 256KB (초과 시 Extended Client Library + S3)
- SQS 보존 기본 4일 / 최대 14일
- Visibility Timeout 기본 30초, 최대 12시간, 연장은
ChangeMessageVisibility - Long Polling 20초 권장 (
WaitTimeSeconds) - ASG 스케일링 지표 =
ApproximateNumberOfMessagesVisible - Delay Queue 최대 15분
- DLQ 위치 — SQS+Lambda는 SQS 큐에, SNS+Lambda는 Lambda 함수에
- FIFO 처리량 = 300 TPS / 3,000 TPS(Batching)
- FIFO 이름 = 반드시
.fifo로 끝남 - FIFO Message Group ID = 필수, 동일 그룹 내에서만 순서 보장
- SNS는 데이터 영속성 없음 — 유실 가능 → Fan-out으로 SQS 결합
- SNS FIFO 구독자 = SQS FIFO 큐만 가능
- Fan-out 권한 = SQS 액세스 정책에서 SNS 토픽 쓰기 허용 필요
- S3 이벤트 단일 대상 한계 → S3 → SNS → 여러 SQS Fan-out으로 극복
- Kinesis 보존 = 24시간 ~ 365일, Replay 가능, 불변(임의 삭제 불가)
- Kinesis 순서 = Partition Key 동일 → 동일 샤드
- Kinesis 단일 레코드 최대 1MB, Base64 인코딩, TRIM_HORIZON(가장 오래된 데이터부터)
- KDS 용량 모드 = Provisioned(샤드 수동) / On-Demand(자동)
- KDS 소비 = 표준 Pull(공유 2MB/s) / Enhanced Fan-Out Push(전용 2MB/s)
- Firehose = Near Real-time, 저장 기능 없음, Replay 불가
- Firehose 대상 = S3·Redshift·OpenSearch·파트너·HTTP / DynamoDB·RDS는 기본 X
- Firehose Redshift 로드 = S3 중간 기착 + COPY 명령 (직접 X)
- Firehose 빠른 전달 = 버퍼 크기 또는 간격을 줄임
- Amazon MQ = 온프레미스 마이그레이션, 코드 변경 X, MQTT·AMQP·STOMP·OpenWire
- Amazon MQ 고가용성 백엔드 = Amazon EFS (EBS 아님)
- EventBridge 버스 = Default·Custom·Partner 3종, Cron/Rate 스케줄 지원
여기까지가 SAA-C03 메시징·이벤트 단원의 전부예요. 표 보면 단순해 보이지만, 실제 시험에서 시나리오 키워드만 보고 정답 서비스를 즉시 매칭할 수 있는지가 핵심입니다. "Replay"가 보이면 Kinesis, "Pub/Sub + 데이터 손실 방지"가 보이면 SNS + SQS Fan-out, "온프레미스 + 코드 변경 X"가 보이면 Amazon MQ — 이 세 매칭만 정확하면 절반 이상은 맞춰요. 더 깊이 보고 싶을 땐 EventBridge 사용자 가이드도 한 번씩 들춰보면 도움이 됩니다.
다음 글(8편)에서는 컨테이너·서버리스 영역 — ECS·Fargate·EKS·Lambda·API Gateway를 정리해요. SAA에서 점점 비중이 커지고 있는 단원이라 이번 SQS·메시징과 함께 꼭 짚고 넘어가야 하는 영역입니다.
시리즈 다른 편
같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.