[Compute] SQS 컨셉 노트
시험 빈출 SQS 컨셉 노트
Amazon SQS for SAA-C03
One-Line Summary
SQS는 메시지를 큐에 쌓아두고 소비자가 자기 속도로 꺼내 처리하게 하는 완전관리형 메시지 큐다. 생산자와 소비자를 느슨하게 결합(decoupling) 하고, 갑작스러운 트래픽을 큐가 흡수(buffer)해 시스템을 안정시킨다. 메시지가 손실되면 안 되고 순서/정확히 한 번 처리가 중요할 때 핵심 서비스다.
Why It Exists
생산자(요청을 만드는 쪽)와 소비자(처리하는 쪽)를 직접 연결하면, 소비자가 느리거나 죽으면 생산자도 막히고 요청이 유실된다.
SQS는 이 둘 사이에 큐를 두어 서로를 직접 몰라도 되게 만든다.
직접 연결
Producer -> Consumer
소비자가 느리거나 죽으면 요청 유실/블로킹, 함께 확장/축소해야 함
SQS 큐 사용
Producer -> [SQS 큐] -> Consumer
큐가 메시지를 보관 -> 소비자는 자기 속도로 처리, 각자 독립 확장
시험 감각:
"두 컴포넌트를 분리(decouple)하라", "메시지가 유실되면 안 된다", "트래픽 급증을 완충하라" = SQS.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
SQS | Simple Queue Service | 완전관리형 메시지 큐 서비스 |
FIFO | First-In-First-Out | 먼저 넣은 메시지를 먼저, 정확히 한 번 처리하는 큐 |
Producer | Producer | 큐에 메시지를 넣는 쪽 |
Consumer | Consumer | 큐에서 메시지를 꺼내 처리하는 쪽 |
DLQ | Dead-Letter Queue | 반복 처리에 실패한 메시지를 따로 모으는 큐 |
Visibility Timeout | Visibility Timeout | 소비자가 꺼낸 메시지를 다른 소비자에게 잠시 숨기는 시간 |
Polling | Polling | 소비자가 큐에 메시지가 있는지 물어보며 가져오는 방식 |
결합을 어떻게 느슨하게 하나 (Decoupling)
핵심은 생산자와 소비자가 서로를 직접 호출하지 않고, 오직 큐만 바라본다는 점이다.
| 항목 | 직접 연결 | SQS로 분리 |
|---|---|---|
| 서로에 대한 의존 | 소비자 주소/상태를 알아야 함 | 큐만 알면 됨 |
| 소비자가 다운되면 | 요청 유실/생산자 블로킹 | 메시지는 큐에 남아 있다가 나중에 처리 |
| 확장 | 함께 확장해야 함 | 각자 독립적으로 확장/축소 |
| 처리 속도 차이 | 빠른 생산자가 느린 소비자를 압도 | 큐가 완충, 소비자는 자기 속도로 처리 |
Producer는 "큐에 넣었다"까지만 책임
Consumer는 "큐에서 꺼내 처리"만 책임
-> 한쪽이 느리거나 죽어도 다른 쪽은 계속 동작
왜 트래픽 견딤성이 올라가나 (Buffering)
트래픽이 순간적으로 폭증해도 메시지는 일단 큐에 쌓인다. 소비자는 처리 가능한 만큼만 꺼내 가므로, 급증한 요청이 소비자(또는 DB)를 직접 때려 과부하로 죽는 일을 막는다.
급증하는 요청 -> [SQS 큐가 흡수] -> 소비자는 일정한 속도로 처리
(spike를 평탄화 = load leveling)
- 큐가 완충 버퍼 역할 → 소비자/백엔드가 순간 폭주에 무너지지 않음
- 소비자를 Auto Scaling으로 붙이면 큐 길이에 따라 대수를 늘려 밀린 메시지를 소화
- 시험에서 "smooth out traffic spikes", "buffer requests" 표현이 나오면 SQS
Standard vs FIFO
| 구분 | Standard Queue | FIFO Queue |
|---|---|---|
| 처리량 | 사실상 무제한, 매우 높음 | 초당 처리량 제한 있음 (기본 300 msg/s, batching 시 3,000) |
| 순서 | 보장 안 됨 (best-effort) | 보낸 순서 그대로 보장 |
| 전달 횟수 | 최소 1회 (드물게 중복 가능) | 정확히 한 번 (exactly-once) |
| 언제 쓰나 | 높은 처리량 필요, 순서가 중요치 않음 | 순서 중요, 중복 처리하면 안 됨 |
| 대표 예시 | 대량 이미지 썸네일 작업, 로그 처리 | 금융 거래, 주문 처리, 재고 차감 |
시험 감각:
"순서가 중요하다 / 정확히 한 번 처리해야 한다" = FIFO. "최대 처리량 / 순서 상관없음" = Standard.
처리 흐름의 핵심 용어
| 개념 | 의미 | 왜 중요한가 |
|---|---|---|
| Visibility Timeout | 소비자가 메시지를 꺼내면 그 시간 동안 다른 소비자에게 숨김 | 두 소비자가 같은 메시지를 중복 처리하는 것을 방지 |
| 메시지 삭제 | 처리 성공 후 소비자가 명시적으로 삭제해야 큐에서 사라짐 | 처리 중 소비자가 죽으면 타임아웃 후 다시 보이게 되어 유실 방지 |
| DLQ | 여러 번 처리 실패한 메시지를 따로 보관 | 문제 메시지가 큐를 막지 않게 격리·분석 |
| Long Polling | 메시지가 올 때까지 잠시 기다렸다 응답 | 빈 응답을 줄여 비용·불필요한 호출 감소 |
큐 깊이 기반 Auto Scaling (빈출)
밀린 메시지(backlog)를 빨리 처리하려면, 큐 길이에 따라 소비자(EC2/ECS) 대수를 자동으로 늘렸다 줄인다. CloudWatch 지표를 기준으로 Auto Scaling 정책을 건다.
큐에 메시지가 쌓임(backlog 증가)
-> CloudWatch: ApproximateNumberOfMessagesVisible 상승
-> Auto Scaling: 소비자 인스턴스/태스크 증설
-> 메시지 소진되면 다시 축소
| 항목 | 내용 |
|---|---|
| 대표 지표 | ApproximateNumberOfMessagesVisible (대기 중 메시지 수) |
| 권장 지표 | 인스턴스당 처리량 기준 Backlog per instance (Target Tracking) |
| 시험 키워드 | "process backlog", "scale workers based on queue length" |
시험 감각:
"밀린 큐를 빨리 비우게 워커를 확장하라" = 큐 깊이 지표 기반 Auto Scaling.
메시지 제약과 큰 메시지 처리 (빈출)
| 항목 | 값 | 비고 |
|---|---|---|
| 최대 메시지 크기 | 256 KB | 초과 시 아래 방법 |
| 큰 메시지(>256KB) | S3에 본문 저장 + SQS Extended Client | 큐에는 S3 참조만 넣음 |
| 메시지 보존 기간 | 기본 4일, 최대 14일 | 이 기간 지나면 자동 삭제 |
| Delay Queue / Message Timer | 메시지를 일정 시간 뒤에 보이게 함 | 처리 지연이 필요할 때 |
시험 감각:
"256KB보다 큰 메시지를 큐로 보내야 한다" = S3 + SQS Extended Client.
SQS vs SNS vs 비교 감각
| 구분 | SQS | SNS |
|---|---|---|
| 모델 | 큐 (pull, 1:1 소비) | 발행/구독 (push, 1:N 팬아웃) |
| 소비 방식 | 소비자가 꺼내 감(polling) | 구독자에게 밀어 보냄 |
| 대표 키워드 | decouple, buffer, process in order | fan-out, notify many subscribers |
| 조합 | SNS → 여러 SQS로 팬아웃(fan-out 패턴)도 자주 출제 |
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 순서·정확히 한 번이 필요한데 Standard 선택 | 순서/중복 보장은 FIFO |
| 최대 처리량이 목적인데 FIFO 선택 | FIFO는 처리량 제한 → 순서 불필요하면 Standard |
| 여러 시스템에 동시에 알림을 뿌려야 하는데 SQS | 1:N 팬아웃은 SNS (또는 SNS+SQS) |
| 트래픽 급증 완충을 Auto Scaling만으로 해결 | 스케일링에도 시간 필요 → 큐로 요청을 버퍼링해 완충 |
| 소비자가 죽으면 메시지 유실이라고 생각 | 삭제 전까지 큐에 남고 Visibility Timeout 후 재노출 |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "decouple components", "loosely coupled" | SQS |
| "buffer requests", "smooth out spikes", "load leveling" | SQS |
| "messages must not be lost", "process reliably" | SQS |
| "process in exact order", "exactly-once", "no duplicates" | SQS FIFO |
| "maximum throughput", "order doesn't matter" | SQS Standard |
| "fan-out to multiple subscribers", "notify many systems" | SNS (필요 시 SNS+SQS) |
| "handle failed messages separately" | DLQ |
| "process backlog", "scale consumers by queue length" | 큐 깊이 기반 Auto Scaling (ApproximateNumberOfMessagesVisible) |
| "message larger than 256 KB" | S3 + SQS Extended Client |
| "delay message delivery" | Delay Queue / Message Timer |
Memory Sentence
SQS는 큐로 생산자·소비자를 분리하고 트래픽 급증을 완충한다. 순서·정확히 한 번이 필요하면 FIFO, 최대 처리량이 필요하고 순서 상관없으면 Standard. 1:N으로 여러 곳에 알림을 뿌리는 건 SNS.
References
댓글
아직 댓글이 없습니다.