주문 API가 결제·알림·재고 시스템을 순서대로 동기 호출합니다. 어느 날 알림 서비스가 느려지자 주문 API 전체가 그 응답을 기다리다 타임아웃, 결국 주문조차 안 됩니다. 트래픽이 몰린 세일 날엔 한 번에 들어온 요청을 다 받아내지 못해 줄줄이 실패합니다. 서비스를 동기로 직접 묶으면 한 곳의 느림·장애가 전체로 번집니다. 메시지 큐는 그 사이에 완충 지대를 둡니다.
- 1메시지 큐가 생산자·소비자를 비동기로 분리하는 원리를 안다
- 2큐(작업 분배)와 발행구독(팬아웃)의 차이를 구분할 수 있다
- 3최소 1회 전달과 멱등성이 왜 짝인지 설명할 수 있다
- 4DLQ가 독성 메시지를 격리하는 방식을 이해한다
- 5큐 길이를 스케일링·알람의 신호로 쓰는 법을 안다
사이에 완충 지대를 둔다
동기 호출의 결합 vs 큐의 분리
A가 B를 동기 호출하면, B가 느리면 A도 느리고 B가 죽으면 A도 막힙니다 — 강하게 결합됩니다. 사이에 메시지 큐를 두면, A는 큐에 메시지를 넣고 바로 응답하고, B는 자기 속도로 큐에서 꺼내 처리합니다.
효과: ① B가 잠깐 죽어도 메시지는 큐에 보관(유실 방지), ② 트래픽 급증을 큐가 완충(B는 밀린 만큼 천천히 처리), ③ B의 장애가 A로 전파되지 않음(장애 격리). 이것이 비동기 디커플링입니다(동기 vs 비동기).
위 그림처럼 동기 호출은 응답을 기다려야 하므로 하나가 느려지면 전체가 막힙니다. 큐로 분리하면 생산자와 소비자가 독립적으로 동작해 장애가 전파되지 않습니다.
위 그림처럼 큐(SQS)는 메시지 하나를 워커 하나가 가져가고, Pub/Sub(SNS)는 모든 구독자에게 각각 전달합니다. 작업 분산이냐 이벤트 팬아웃이냐에 따라 선택이 달라집니다.
위 그림처럼 큐는 '최소 1회' 전달을 보장하므로 소비자가 멱등하게 설계돼야 합니다. 처리 실패가 반복되면 DLQ로 격리해 장애 원인을 분석하고 수동으로 재처리합니다.
큐(작업 분배) vs 발행구독(팬아웃)
- 큐(SQS, point-to-point): 메시지를 여러 워커가 나눠 처리. 한 메시지는 보통 한 워커가. 작업을 분산 처리할 때.
- 발행구독(SNS, pub/sub): 한 번 발행한 이벤트를 구독한 여러 대상에 동시 전달(팬아웃). 예: 주문 1건 → 결제·알림·재고에 동시 통지.
실무 패턴: SNS → 여러 SQS 로 묶어 "한 이벤트를 여러 시스템에 팬아웃하되, 각 시스템은 자기 큐로 안정적으로 소비"하게 만듭니다. 이벤트 버스(EventBridge)는 여기에 라우팅 규칙을 더한 형태입니다.
최소 1회 전달과 멱등성 — 중복을 견디는 설계
대부분의 분산 큐는 최소 1회(at-least-once) 전달입니다 — 재시도 때문에 같은 메시지가 두 번 올 수 있습니다. 처리 로직이 멱등하지 않으면 이중 결제·이중 차감이 납니다.
해결: 메시지 ID로 "이미 처리했는지" 확인하거나, "존재하면 갱신(upsert)"처럼 두 번 처리해도 결과가 같게 설계합니다(용어사전의 Idempotency-Key와 같은 원리). 반복 실패하는 독성 메시지는 DLQ(Dead Letter Queue)로 빼내 정상 흐름을 막지 않게 합니다.
큐에 쌓인(아직 처리 안 된) 메시지 수를 봅니다. 계속 늘면 소비자가 못 따라가는 것입니다.
aws sqs get-queue-attributes --queue-url "$Q_URL" \
--attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible \
--query "Attributes"
{ "ApproximateNumberOfMessages": "1340", "ApproximateNumberOfMessagesNotVisible": "12" }
aws sqs get-queue-attributesDLQ에 메시지가 있으면 반복 실패가 있다는 신호입니다. 수를 확인하고 원인 메시지를 들여다봅니다.
aws sqs get-queue-attributes --queue-url "$DLQ_URL" \
--attribute-names ApproximateNumberOfMessages --query "Attributes.ApproximateNumberOfMessages"
"7" # 7건이 반복 실패 → 조사 필요
aws sqs get-queue-attributes (DLQ)- ApproximateNumberOfMessages가 계속 증가 추세 — 소비자 처리량 < 유입량. 워커 수를 큐 길이 기반으로 스케일아웃(오토스케일링 + 로드밸런서)하거나 처리 최적화
- NotVisible(처리 중) 수가 비정상적으로 큼 — 처리가 오래 걸려 가시성 타임아웃 동안 잠겨 있음. 처리 시간 vs visibility timeout 점검
- DLQ에 메시지가 쌓임 — 독성 메시지/버그. DLQ 적체는 알람 대상. 메시지 본문으로 원인 파악 후 수정·재처리
- 같은 작업이 두 번 수행된 흔적(이중 결제/알림) — 멱등성 미보장. 메시지 ID 기반 중복 제거 도입
상황: 메시지가 중복 처리돼 부작용이 두 번 발생.
원인: 큐의 최소 1회 전달 특성. 소비자가 메시지를 처리하고 삭제(ack)하기 전에 죽거나 가시성 타임아웃이 지나면, 메시지가 다시 보여 다른 워커가 또 처리합니다. 멱등하지 않은 로직이면 부작용이 중복됩니다.
진단: 처리 시간이 visibility timeout보다 긴지 확인 → 처리 완료 후에만 메시지를 삭제하는지(중간 실패 시 미삭제) → 멱등 처리 여부 확인.
해결: ① 처리 로직을 멱등하게(메시지 ID 중복 체크/upsert), ② visibility timeout을 실제 처리 시간보다 넉넉히, ③ 처리 완료 후 삭제. 정확히 1회가 꼭 필요하면 FIFO 큐(중복 제거) 검토 — 단 처리량 제약이 있음. 중복은 '없앤다'보다 '견딘다'가 분산 시스템의 기본 자세입니다.
"트래픽 급증을 어떻게 견디나요?"의 핵심 답 중 하나가 큐입니다 — 동기 처리로 다 받아내려다 무너지는 대신, 큐로 받아 두고 소비자가 자기 속도로 처리하면 스파이크를 흡수합니다(오토스케일링 + 로드밸런서). "서비스 간 장애 전파를 어떻게 막나요?"의 답도 큐를 통한 비동기 분리입니다.
설계 면접 단골: "주문 처리를 어떻게 구성하나요?" → "주문은 동기로 받아 확정하고, 결제 후속·알림·재고는 이벤트로 발행(SNS)해 각 시스템이 자기 큐(SQS)로 비동기 처리, 멱등성으로 중복 견디고 DLQ로 실패 격리"가 탄탄한 답입니다. 이벤트 기반 아키텍처(동기 vs 비동기)와 서버리스(서버리스(Lambda))가 자연스럽게 결합됩니다.
이로써 Cloud 트랙은 계정·네트워크·컴퓨트·스토리지·DB·서버리스·컨테이너·IaC·비용·관측·보안·메시징까지 — 클라우드 위에서 시스템을 설계·운영하는 큰 그림을 갖췄습니다. 더 깊은 이벤트 아키텍처는 동기 vs 비동기, 오케스트레이션은 Kubernetes로 이어집니다.