야간 정산 배치가 OutOfMemory로 죽습니다. "데이터를 한 번에 다 올렸나 봐요." 한편 주문 이벤트를 처리하는 Consumer는 lag이 쌓이고, DLQ엔 실패 메시지가 수천 건. "같은 알림이 두 번 갔다"는 클레임도 들어옵니다. PM·인프라인 당신은 배치·비동기 용어를 알아야 이 문제들의 방향을 잡을 수 있습니다. 이 사전은 대량 처리·배치·비동기 용어를 빠르게 해독합니다. 설계 원리는 [[async-event-driven]]에서 다룹니다.
- 1배치(Job·Step·Chunk·Reader/Processor/Writer) 구조를 설명할 수 있다
- 2메시지 큐(Producer/Consumer·Topic/Partition/Offset)의 구성을 이해할 수 있다
- 3전달 보장(at-least/most/exactly-once)과 멱등·DLQ의 관계를 설명할 수 있다
- 4백프레셔·재시도큐 등 안정성 용어로 비동기 장애를 진단할 수 있다
배치 처리
대량 데이터를 안정적으로 처리하는 구조
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Batch / Spring Batch | 대량 일괄 처리 / 자바 배치 프레임워크 | 정산·집계 → [[scheduler-batch-ops]] | ★★ |
| Job / Step / Chunk | 배치 작업 / 단계 / 처리 묶음 | Chunk로 메모리 관리 | ★★ |
| Reader / Processor / Writer | 읽기 / 가공 / 쓰기 | 청크 처리 3요소 | ★★ |
| Scheduler / Cron | 예약 실행 / 크론 표현식 | → [[cron-scheduling]] | ★★ |
| Bulk Insert / Update / API | 대량 삽입·수정 | 성능 → [[bulk-operations]] | ★★ |
핵심: 배치 OutOfMemory의 단골 원인은 '전체를 한 번에 메모리 적재'입니다. Chunk 처리(N건씩 읽고-쓰기 반복)로 메모리 부담 없이 대용량을 처리합니다([[bulk-operations]]).
메시지 큐 · 이벤트
비동기 통신의 부품들
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Queue / Message Queue | 큐 / 메시지 큐 | 분리·완충 → [[async-event-driven]] | ★★ |
| Kafka / RabbitMQ / Redis Queue / SQS / Pub/Sub | 대표 메시징 시스템 | 스택 → [[tech-stack-reading]] | ★★ |
| Producer / Consumer / Consumer Group | 발행자 / 소비자 / 소비 그룹 | 그룹=병렬 확장 | ★★ |
| Topic / Partition / Offset / Broker | 채널 / 분할 / 읽은위치 / 큐서버 | Kafka 핵심 | ★★ |
| Event / Event Driven / Async Processing | 이벤트 / 이벤트기반 / 비동기처리 | → [[async-event-driven]] | ★★ |
핵심: Consumer Group에 소비자를 늘려 처리량을 확장합니다. Consumer lag(소비 지연)이 쌓이면 소비 속도 < 유입 — 소비자 증설이나 처리 최적화 신호입니다.
전달 보장 · 안정성
중복·실패·역압을 다루는 용어
| 용어 | 한 줄 뜻 | 비고 | 중요도 |
|---|---|---|---|
| Retry Queue / Dead Letter Queue (DLQ) | 재시도 큐 / 실패 격리 큐 | 적체=경고 신호 | ★★★ |
| Backpressure | 소비 못 따라갈 때 유입 조절 | 과부하 방지 | ★★ |
| At-least-once / At-most-once / Exactly-once | 최소1번(중복가능) / 최대1번(유실가능) / 정확1번 | 대부분 at-least-once | ★★★ |
| Idempotent Processing / Duplicate Handling | 멱등 처리 / 중복 처리 | at-least-once 필수 짝 → [[requirements-prd]] | ★★★ |
핵심: 대부분 at-least-once(중복 가능)이므로 멱등 처리가 필수입니다 — 안 하면 중복 결제·중복 알림. DLQ 적체는 특정 메시지가 반복 실패 중이라는 '조용한 사고' 신호입니다([[async-event-driven]]).
비동기 장애 진단 — 직접 확인
비동기 시스템은 lag(소비 지연)과 DLQ(실패 격리)로 건강을 봅니다.
점검:
1) Consumer lag 추세: 계속 증가? → 소비 < 유입(소비자 증설/최적화)
2) DLQ 적체: 쌓이고 있나? → 특정 메시지 반복 실패(형식·버그)
3) 중복 처리: 같은 이벤트 2회 처리 흔적? → 멱등 미보장
4) 배치 메모리: OOM? → Chunk 미사용(전체 적재)
Consumer lag: 12,000 → 45,000 (증가 중) → 소비 못 따라감, 소비자 증설
DLQ: 3,200건 (동일 형식 에러) → 잘못된 메시지 형식, 소비자 버그
중복 알림 클레임 발생 → 멱등 키 미적용([[glossary-api-auth]])
야간배치 OOM → 전체 select 후 메모리 적재, Chunk로 전환([[bulk-operations]])
echo 'lag 추세 + DLQ 적체 + 중복 처리 여부 확인'- Consumer lag이 우상향이면 소비 속도 < 유입 → 소비자(그룹 내) 증설 또는 처리 최적화. 방치하면 지연 폭증·메모리 압박
- DLQ가 쌓이면 특정 메시지가 반복 실패 중 → 그 메시지 형식·소비자 버그 조사. DLQ 적체는 "조용히 누적되는 실패"라 알람 필수
- 중복 결제·알림 클레임이 있으면 at-least-once + 멱등 미보장 → Idempotency Key·중복 체크 적용([[requirements-prd]])
- 배치 OOM이면 전체 데이터 메모리 적재 의심 → Chunk(N건씩 읽고-쓰기)로 전환([[bulk-operations]]). 청크 크기는 메모리·성능 균형
상황: 주문 이벤트를 비동기로 정산 처리하는데, 일부 메시지가 처리 실패해 DLQ로 갔지만 아무도 DLQ를 보지 않아 며칠간 정산 누락이 누적된 뒤에야 발견됩니다.
원인: DLQ에 대한 모니터링·알람 부재입니다. 비동기는 실패가 즉시 사용자에게 안 보여 '조용히' 누적됩니다. DLQ가 안전망 역할을 했지만, 그것을 감시하지 않으면 데이터 유실로 이어집니다.
진단:
□ DLQ 크기에 대한 알람이 있나? (>0이면 경고)
□ 실패 메시지의 공통 원인은? (형식 오류 vs 일시 장애)
□ 재처리 절차가 있나? (고친 뒤 DLQ→원큐 재투입)
해결: (1) DLQ 크기 알람을 걸어 적체를 즉시 감지([[glossary-observability]]). (2) 실패 원인 분류 — 형식 오류는 생산자/스키마 수정, 일시 장애는 재시도. (3) 원인 수정 후 DLQ 메시지를 재처리하는 절차 마련. 비동기의 실패는 '안 보이는 것'이 가장 위험하므로, DLQ·lag를 관측성에 반드시 포함시킵니다([[slo-error-budget]]).
인프라/SRE로서 메시징·배치 도입은 새로운 운영 책임을 동반합니다 — 브로커 클러스터 이중화·디스크/보존기간 산정·Consumer lag·DLQ 알람을 설계합니다([[glossary-observability]]). "비동기로 빼자"는 결정에 이 운영 비용을 함께 견적해야 합니다([[architecture-patterns]]). PM은 비동기 요구사항에 멱등·DLQ·재처리 절차를 인수 기준으로 명시하고([[requirements-prd]]), '조용한 실패(DLQ 적체)'가 데이터 사고로 번지지 않도록 모니터링을 요구합니다. 비동기는 응답을 빠르게 하지만, 보이지 않는 실패를 보이게 만드는 설계가 함께 가야 합니다.
다음 용어사전에서는 성능을 끌어올리는 캐시·세션 용어를 정리합니다.