[웹서버] → [SQS 큐] → [이미지 처리 서버]
이미지 처리 서버가 다운되어도:
→ 메시지는 큐에 안전하게 쌓여있음 (유실 안 됨)
→ 웹서버는 큐에 메시지만 넣으면 되니 계속 정상 동작
→ 이미지 처리 서버가 복구되면, 쌓여있던 메시지부터 순서대로 처리 시작
[Producer (생산자)] → 메시지를 큐에 보냄 (SendMessage)
↓
[SQS Queue] → 메시지를 안전하게 보관
↓
[Consumer (소비자)] → 큐에서 메시지를 꺼내서 처리 (ReceiveMessage → 처리 → DeleteMessage)
| 특징 | 설명 |
|---|---|
| 처리량 | 사실상 무제한 (초당 수천~수만 건 처리 가능) |
| 전달 순서 | 순서 보장 안 됨 (Best-effort ordering, 보낸 순서와 다르게 도착할 수 있음) |
| 전달 횟수 | 최소 1번 이상 전달(At-Least-Once Delivery) — 같은 메시지가 중복으로 전달될 수도 있음 |
| 따라서 Consumer은 중복처리에 안전하게 설계해야 한다! | |
| 메시지 보관 기간 | 기본 4일, 최대 14일까지 설정 가능 |
| 메시지 크기 | 최대 256KB |
→ "큐에 쌓인 메시지 양(작업량)에 따라, 이걸 처리하는 EC2(Worker)의 개수를 자동으로 조절하고 싶다"
1. Producer(웹서버 등)가 SQS 큐에 계속 메시지를 쌓음
↓
2. CloudWatch가 큐의 지표를 모니터링
→ 핵심 지표: ApproximateNumberOfMessagesVisible
(큐에 쌓여있는, 아직 처리 안 된 메시지 개수)
↓
3. 메시지가 많이 쌓이면(예: 1000개 이상) → CloudWatch 알람 발동
↓
4. ASG(Auto Scaling Group)가 이 알람을 받아서 → EC2(Worker) 개수를 늘림
↓
5. 늘어난 Worker(EC2)들이 큐에서 메시지를 꺼내서 병렬로 처리 → 처리 속도 향상
↓
6. 메시지가 줄어들면(처리 다 됨) → ASG가 다시 Worker 개수를 줄임 (비용 절감)
Message Visibility Timeout (가시성 제한 시간)
→ 한 Consumer가 메시지를 꺼내가면, 그 메시지는 일정 시간 동안 다른 Consumer에게 "안 보이게(invisible)" 처리돼요.
Consumer A가 메시지를 받아감 (ReceiveMessage)
↓
그 메시지는 Visibility Timeout(기본 30초) 동안 큐에서 "숨겨짐"
→ 다른 Consumer가 같은 메시지를 중복으로 가져가지 못하게 방지
↓
Consumer A가 처리를 완료하면 → DeleteMessage로 큐에서 완전히 삭제
↓
만약 Consumer A가 Timeout 안에 처리를 못 끝내고 죽어버리면?
→ Visibility Timeout이 지나면 메시지가 다시 "보이는" 상태로 복귀
→ 다른 Consumer가 다시 가져가서 처리 가능 (메시지 유실 방지)
💡 시험 포인트: "처리 시간이 긴 작업인데, Consumer가 처리 중에 메시지가 다시 노출되어 중복 처리된다" → Visibility Timeout을 늘려야 하는 문제로 자주 나와요.
즉, 이미 백엔드에서는 처리를 했는데 MVT때문에 1번 더 메세지가 백엔드에서 처리될 수 있다. 위에서 언급한 중복처리 이슈가 발생할 수 있음.
Short Polling (기본): Consumer가 큐에 "메시지 있어?"라고 물어봄
→ 없으면 즉시 "없음" 응답 → Consumer가 계속 짧은 간격으로 다시 물어봐야 함 (비효율적, 비용 낭비)
Long Polling: "메시지 있어?"라고 물어봤을 때, 없으면 즉시 응답 안 하고
→ 최대 20초까지 "기다렸다가", 메시지가 도착하면 그때 응답
→ 불필요한 빈 응답(폴링) 횟수를 줄여서 비용 절감 + 효율 향상