[Kafka] 스프링 카프카 실무 가이드 지도: 설정, 유실 방지, 리밸런싱, 트러블슈팅 11편 정리

[Kafka] 스프링 카프카 실무 가이드 지도: 설정, 유실 방지, 리밸런싱, 트러블슈팅 11편 정리

이 블로그의 스프링 카프카 시리즈 11편이 완결됐어요. 이 글은 그 지도예요. 처음부터 순서대로 읽는 동선과, 지금 겪는 증상에서 바로 찾아가는 인덱스를 같이 정리했어요.

01. 추천 학습 순서

처음 설정부터 잡는다면 이 순서가 자연스러워요. 컨슈머 기본 → 프로듀서 → 신뢰성 → 보장 수준 → 스키마 → 테스트 → 운영 순이에요.

• 1. 컨슈머 기본 — @KafkaListener 컨슈머 설정 정리: concurrency, ackMode, containerFactory, 역직렬화. 시리즈의 출발점이에요.
• 2. 프로듀서 안전 — 프로듀서 acks=all, min.insync.replicas, 멱등 프로듀서: 유실 막고 순서 보장하는 표준 조합.
• 3. 파티셔닝 — 파티셔닝과 메시지 키: 순서 보장, hot partition, 파티션 수 정하는 기준.
• 4. 커밋과 중복 — 수동 커밋(AckMode MANUAL)과 멱등성: 메시지 중복이 생기는 원인과 처리 패턴 4가지.
• 5. 리밸런싱 — 컨슈머 리밸런싱 원인과 줄이는 법: CooperativeStickyAssignor, static membership.
• 6. 실패 처리 — 컨슈머 에러 핸들링과 DLQ: 재시도 BackOff, poison pill, 실패 메시지 재처리.
• 7. 보장 수준 — Exactly-once 트랜잭션 설정: 멱등 프로듀서, transactional.id, read_committed와 한계.
• 8. 스키마 — 직렬화와 스키마 관리: JSON vs Avro, Schema Registry 호환성 검사.
• 9. 테스트 — 카프카 테스트 작성법: EmbeddedKafka vs Testcontainers, Awaitility.
• 10. 모니터링 — 컨슈머 lag 모니터링: 측정 방법, 늘어나는 원인 진단, 알림 설계.
• 11. 트러블슈팅 — 성능 트러블슈팅 가이드: 증상별 원인과 대응 종합.

02. 증상으로 바로 찾기

운영 중에 문제가 터졌으면 학습 순서 말고 여기서 바로 들어가요.

• 메시지가 가끔 사라져요 → acks와 유실 방지
• 메시지가 중복 처리돼요 → 수동 커밋과 멱등성
• 순서가 뒤섞여요 → 파티셔닝과 메시지 키
• 배포 때마다 처리가 뚝뚝 끊겨요 → 리밸런싱 줄이는 법
• 한 건 실패에 컨슈머 전체가 멈췄어요 → 에러 핸들링과 DLQ
• lag이 계속 늘어나요 → lag 모니터링
• 역직렬화 에러가 무한 반복돼요 → poison pill 처리
• 스키마 바꿨더니 컨슈머가 깨졌어요 → Schema Registry 호환성
• 정확히 한 번 처리가 정말 되는 건지 모르겠어요 → Exactly-once의 경계
• 뭐가 문제인지 모르겠어요 → 증상별 트러블슈팅

03. 시리즈를 관통하는 세 가지

11편을 다 쓰고 보니 결국 세 문장으로 모여요.

첫째, 안전한 전송은 공식이 있어요. acks=all + min.insync.replicas=2 + 멱등 프로듀서. 이 조합에서 출발해 데이터 성격에 따라 완화하는 거지, 반대로 가면 유실을 운에 맡기게 돼요.

둘째, 중복은 막는 게 아니라 견디는 거예요. 카프카는 기본이 at-least-once라 중복은 언젠가 와요. 컨슈머를 멱등하게 만드는 쪽이 중복을 0으로 만들려는 시도보다 훨씬 싸요.

셋째, 순서는 파티션 안에서만 보장돼요. 순서가 필요한 데이터에 같은 키를 주는 설계가 모든 순서 문제의 출발점이에요.

2021년에 쓴 구현 기록들(KafkaTemplate Producer, Message Listeners Consumer, Concurrency 실측)도 코드 레벨 참고로 여전히 유효해요.

이 시리즈 다음은 Redis 편이에요. Spring Data Redis 설정부터 이어져요.