04/10 — 메시지로 비동기 압력 제어

이 구간은 유입·처리 속도, 순서 범위, 재시도, 실패·우선순위 격리를 대기열 구성으로 연결하게 해준다.

1. 단순 정의

• SQS Standard: 높은 처리량으로 작업을 분산하는 기본 대기열이다. at-least-once 전달과 best-effort 순서를 전제로 소비자를 멱등하게 구성한다. SQS 대기열 유형
• SQS FIFO: 같은 MessageGroupId 안의 메시지를 순서대로 제공한다. 다른 그룹은 병렬 처리하며, MessageDeduplicationId 또는 본문 기반 중복 제거로 5분 안의 생산자 재전송을 합친다. FIFO 중복 제거
• Visibility timeout: 수신 메시지를 처리하는 동안 다른 소비자에게 숨기는 시간이다. 성공 후 DeleteMessage로 완료하고, 시간이 가변적이면 ChangeMessageVisibility로 연장한다. Visibility timeout
• DLQ(Dead-Letter Queue): 반복 실패 메시지를 정상 흐름과 분리해 조사하는 대기열이다. 원본 큐의 redrive policy가 DLQ와 maxReceiveCount를 정한다.
• 멱등성: 같은 업무 요청을 반복해도 결과를 한 번 처리한 상태로 유지하는 성질이다. 업무 ID를 조건부 쓰기나 처리 기록의 키로 사용한다.
• Long polling: ReceiveMessage가 메시지를 기다렸다가 반환하는 방식이다. 빈 응답과 호출량을 줄이며, 여러 큐를 직접 읽을 때는 큐마다 독립 poller를 둔다. Long polling

2. 결정 축과 관계

첫 번째 축은 유입 속도와 처리 속도의 분리다. 생산자는 작업을 SQS에 기록하고 응답하며, 독립 소비자는 자신의 속도로 가져간다. 순간 유입이 소비자 용량을 넘어도 대기열이 작업을 보존한다. 소비자 확장은 단순 큐 길이보다 대기 메시지 수 ÷ 실행 중인 소비자 수인 backlog per worker와 허용 지연을 연결한다. SQS 기반 확장

두 번째 축은 순서가 필요한 범위다. 처리량 중심이면 Standard, 주문·계정별 순서가 중요하면 FIFO를 쓴다. MessageGroupId=orderId라면 같은 주문은 직렬로, 다른 주문은 병렬로 처리된다. 하나의 group ID는 전역 순서와 하나의 처리 흐름을 만든다.

FIFO의 중복 제거와 소비자 멱등성은 서로 다른 경계다. FIFO는 deduplication ID를 기준으로 5분 안의 중복 전송이 큐에 추가되는 것을 막는다. 소비자가 외부 저장을 끝낸 뒤 메시지 삭제에 실패하면 다시 처리될 수 있으므로, Standard와 FIFO 모두 업무 ID 기반 멱등 처리를 유지한다. Lambda의 SQS event source mapping도 at-least-once로 처리한다. Lambda와 SQS

세 번째 축은 처리 시간과 재시도 시점이다. 메시지는 큐에 남은 채 visibility timeout 동안 숨겨진다. 처리와 영구 저장 뒤 삭제한다. 작업 시간이 일정하면 예상 시간에 맞추고, 변동하면 heartbeat 방식으로 연장한다.

네 번째 축은 실패와 서비스 등급의 격리다. 원본 큐의 redrive policy는 반복 실패를 같은 유형의 DLQ로 보낸다. DLQ의 redrive allow policy는 자신을 사용할 원본 큐를 제한한다. 원인을 고친 뒤 속도를 제어해 원본이나 같은 유형의 다른 큐로 redrive한다. DLQ 보존 기간은 원본보다 길게 잡는다. FIFO DLQ는 실패 메시지를 순서 흐름에서 분리해도 되는 업무에 둔다. DLQ, DLQ redrive

처리 등급은 등급별 큐와 독립 소비자 용량으로 표현한다. 높은 등급에 더 많은 소비자 용량을 할당하고 각 큐를 따로 관찰하면 우선순위·적체·실패 경계가 함께 분리된다.

3. 아키텍처 적용

사례 A — 급격히 몰리는 이미지 변환

API는 작업 ID와 S3 객체 위치를 Standard 큐에 넣고 응답한다. Fargate 작업자는 long polling으로 받아 멱등하게 변환한 뒤 삭제한다. backlog per task로 확장하고, 가변 작업은 visibility를 연장하며 반복 실패는 Standard DLQ로 격리한다.

사례 B — 주문별 순차 명령

FIFO 큐에서 MessageGroupId=orderId, 안정적인 deduplication ID를 사용한다. 한 주문의 명령은 순차 처리되고 여러 주문은 병렬 처리된다. 소비자는 주문 이벤트 ID로 결과 쓰기를 멱등하게 만든다.

사례 C — 프리미엄·일반 작업 분리

라우터가 요청을 두 Standard 큐로 나누고 별도 worker pool을 연결한다. 프리미엄 큐에 독립 용량을 할당하며, 각 큐는 자체 확장 지표·visibility·DLQ를 가진다.

4. 정답 구조

• 유입 폭증과 느린 백엔드 처리 → Standard SQS + 독립 소비자 확장 → 생산·소비 속도 분리
• 높은 처리량과 순서 비의존 → Standard + 멱등 소비자 → at-least-once 안전성
• 엔터티별 엄격한 순서 → FIFO + 엔터티 ID를 MessageGroupId로 → 그룹 안 직렬·그룹 간 병렬
• 생산자 재전송 중복 억제 → FIFO deduplication ID → 5분 중복 제거 창
• 가변 처리 시간 → visibility timeout + heartbeat 연장 → 처리 중 은닉과 실패 후 재시도
• 반복 실패 조사 → redrive policy + 동일 유형 DLQ → 정상 흐름과 실패 격리
• 수정 후 재처리 → 제어된 DLQ redrive → 목적지 큐로 복귀
• 처리 등급별 우선순위 → 별도 큐 + 독립 소비자 용량 → 용량·적체·실패의 분리

5. 긍정형 암기표

요구사항의 중심	올바른 연결
처리량 중심 비동기 작업	SQS Standard
중복 전달에도 같은 결과	업무 ID 기반 멱등 소비자
엔터티별 처리 순서	FIFO + MessageGroupId
생산자 재전송 중복 억제	MessageDeduplicationId
처리 중 다른 소비자에게 은닉	Visibility timeout
가변적인 작업 시간	ChangeMessageVisibility heartbeat
반복 실패 메시지 격리	DLQ + maxReceiveCount
DLQ를 사용할 원본 제한	Redrive allow policy
빈 receive와 호출량 감소	Long polling
등급별 처리 우선순위	별도 큐 + 독립 소비자 용량

다음: 05/10 — 가용성·전환·재해 복구. 장애 도메인, 검증·전환 방식, RPO·RTO·비용을 연결한다.