alt

7주차 렌 멘토님

2026년 6월 30일 공유

Kafka와 비동기 메시징 설계 원칙

개요

비동기 메시지 시스템(특히 Kafka)을 도입하면서 발생하는 프로듀서·컨슈머 관계, 오류 처리, 메시지 순서 보장, 그리고 키/파티션 설계에 관한 핵심 개념을 정리합니다. 본 문서는 실무에서 흔히 접하는 상황과 해결 방안을 사례 중심으로 설명합니다.
핵심 메시지 비동기 메시징은 트래픽 부하를 완화하지만, 오류 처리와 순서 보장을 위한 설계가 필수이며, 프로듀서와 컨슈머의 결합도를 낮추는 목적을 충실히 수행해야 합니다.

핵심 포인트

비동기 메시징의 정의
  • 메시지를 보내고 바로 종료(fire‑and‑forget), 이후 결과를 별도로 처리
  • 단순 동기 호출보다 부하 분산에 효과적
프로듀서 실패 시 처리
  • Retry(지수 백오프) → DLQ(Dead‑Letter Queue) 저장
  • 전송 실패 시 비즈니스 로직은 컨슈머가 담당해야 함
  • 프로듀서가 컨슈머 로직을 알면 모듈 결합도가 상승 → 비동기 메시징의 의미 상실
컨슈머 오류 처리
  • 메시지 소비 중 예외 발생 시 offset 커밋 방지
  • 순서 보장을 위해 FIFO(First‑In‑First‑Out) 파티션 설계 필요
  • DLQ에 메시지 저장 후 재시도는 순서 보장이 깨질 수 있음 → 필요 시 수동 개입
파티션·키 설계
  • 동일한 키는 같은 파티션에 배분 → 순서 보장
  • 핫 파티션 발생 시 파티션 수를 늘리거나 키 재설계 필요
  • Parallel Consumer 사용 시 순서 보장은 보장되지 않음 → 핵심 이벤트에 한정 사용
오류 복구 및 모니터링
  • Retry, DLQ 외에도 오프셋 리셋 및 백오프 로직 구현
  • 핫 파티션 감지와 옵서버빌리티(모니터링) 필수
  • 순서 깨짐이 발생하면 수동 재처리 또는 스케줄러 재시도 활용
오류 처리와 트랜잭션
  • 트랜잭션 아웃박스 패턴은 원장 데이터와 이벤트를 동시 저장 필요
  • 로컬 이벤트(내부 통신)와 글로벌 이벤트(다른 서비스) 구분이 중요
  • 로컬 이벤트는 아웃박스에 저장하지 않아도 되지만, 데이터 일관성이 깨질 위험이 있음
CDC(Change Data Capture) 활용
  • DB 변경을 감지해 바로 이벤트를 발행 → 실시간성 향상
  • 단점: 관리 포인트 증가, 장애 시 복구 어려움
  • 폴링 방식과 비교해 트레이드‑오프를 명확히 인지해야 함
메시지 순서와 트래픽
  • 선착순 쿠폰과 같은 경우, 정렬 인덱스를 DB에 저장해 파티션 외부에서 정렬
  • 순서 보장이 필요하면 파티션 수를 늘리지 말고 키 기반 순서 유지
  • Parallel Consumer 사용 시 파티션 별 순서 보장 필요 시 주의

상세 노트

1. 프로듀서 실패 처리

단계
수행 내용
주의점
1. 전송 실패
지수 백오프(1s, 3s, 5s…)
재시도 횟수 초과 시 DLQ
2. DLQ 저장
메시지와 메타데이터 보존
DLQ 순서 보장 가능, 그러나 파티션 순서는 깨짐
3. 로깅
실패 원인 기록
운영팀 모니터링에 활용
4. 알림
장애 발생 시 알림 전송
빠른 대응을 위해 모니터링 대시보드에 연동

2. 컨슈머 오류 처리

오프셋 커밋 방지: 실패 시 커밋 방지 → 재시도 가능
  • 순서 보장: 파티션 내 FIFO 보장 → DLQ 재시도 시 전 순서를 유지하도록 구현
수동 개입: 복잡한 순서 깨짐 시 수동 재처리 또는 스케줄러를 통한 재시도

3. 파티션 & 키 설계

키 기반 라우팅: 동일 키 → 동일 파티션
  • 핫 파티션 방지: 파티션 수 증가, 파티션 키 재설계, Parallel Consumer 제한
동시성 제어: 파티션 수와 소비자 수를 일치시켜 오프셋 충돌 방지

4. 아웃박스 패턴과 트랜잭션

원장 데이터와 이벤트를 같은 트랜잭션으로 저장
  • 로컬 이벤트는 별도 처리 가능, 단 데이터 무결성이 깨질 위험이 있음
Dual‑Write 방지: 이벤트 저장 실패 시 비즈니스 로직도 롤백
  • 오류 시 재시도: 이벤트가 DLQ에 저장되면, 레플리케이션을 통해 재발행

5. CDC 활용

DB 변경 감지 → 이벤트 발행 → Kafka 토픽에 전달
  • 실시간성 향상: 수동 폴링보다 빠름
복구: 이벤트 스토어(원장)에서 재생(Replay) 가능
  • 단점: 관리 포인트 증가, 장애 시 복구 복잡

6. 모니터링 & 트러블슈팅

항목
지표
도구
핫 파티션
파티션 소비량 비율
Kafka Manager, Prometheus
DLQ 메시지
수신 건수, 재시도 횟수
Kafka UI, ELK
오프셋 오프셋
오프셋 비동기율
Confluent Control Center
Retry/Backoff
평균 재시도 시간
Grafana


마지막 정리 비동기 메시징을 도입할 때는 프로듀서-컨슈머 결합도 감소와 오류 처리 전략을 가장 먼저 설계해야 합니다. 파티션·키 설계, DLQ 활용, 순서 보장 정책, 모니터링 체계 구축은 운영 안정성을 좌우하므로 실무에 바로 적용할 수 있도록 가이드라인을 마련해 두는 것이 중요합니다.

공개 노트 모두 보기