카프카 가이드

1. 개요 (Overview)

우리 프로젝트는 Spring Kafka를 사용하여 서비스 간 비동기 통신을 처리합니다. 복잡한 직렬화/역직렬화 설정은 공통 설정(application.yml)에 의해 자동으로 처리되므로, 개발자는 이벤트 정의, 발행(Send), 수신(Listen) 세 가지 단계만 신경 쓰면 됩니다.

2. 핵심 설정

application.yml에 정의된 주요 설정입니다.

구분	설정 항목	설정값 (Class/Value)	설명 (Why?)
공통	`bootstrap-servers`	`localhost:29092`	Kafka 브로커 주소입니다. (환경 변수로 주입 - 기본값 localhost:29092)
Producer	`value-serializer`	`JacksonJsonSerializer`	객체(DTO)를 보낼 때 자동으로 JSON 문자열로 변환하여 전송합니다.
Consumer	`value-deserializer`	`JacksonJsonDeserializer`	들어온 JSON 메시지를 자동으로 Java 객체(DTO)로 매핑합니다.
Consumer	`group-id`	`${spring.application.name}-group`	향후 서비스(모듈)가 쪼개져도 설정 파일 수정 없이 그룹 ID 충돌을 방지합니다.
Consumer	`auto-offset-reset`	`earliest`	서버가 새로 뜨거나 그룹이 바뀌었을 때, 과거에 쌓인 중요한(결제, 경매) 이벤트를 놓치지 않고 다 읽어옵니다.
Listener	`ack-mode`	`batch`	성능 향상을 위해 메시지를 하나씩 처리하지 않고 배치 단위로 처리 후 커밋합니다.

Kafka auto-offset-reset 설정

Kafka의 auto-offset-reset 설정은 “컨슈머 그룹이 처음 생겼거나, 저장된 위치(Offset) 정보가 날아갔을 때 어디서부터 읽을 것인가?"를 결정하는 중요한 옵션입니다.

1. `latest` (기본값)

"과거는 잊고, 지금부터 들어오는 것만 처리하자!"

동작: 컨슈머가 실행된 이후에 도착하는 메시지부터 읽습니다. 실행 전 쌓여있던 데이터는 무시(Skip)합니다.
장점: 중복 처리 가능성이 낮고, 실시간성이 중요한 데이터(센서 데이터, 로그 모니터링)에 적합합니다.
단점: 데이터 유실(Data Loss) 위험. 컨슈머가 잠시 죽었다가(또는 배포 중) 다시 살아나는 사이에 들어온 중요 이벤트(결제, 경매 낙찰 등)를 놓칠 수 있습니다.

2. `earliest` (우리 설정)

"처음부터 빠짐없이 다 읽자!"

동작: 카프카에 남아있는 가장 오래된 메시지(맨 처음)부터 순서대로 다 읽어옵니다.
장점: 데이터 누락 없음. 시스템이 다운되었다 복구되어도, 그 사이 쌓인 데이터를 놓치지 않고 다 처리합니다. (결제, 정산, 주문 시스템 필수)
단점: 중복 처리(Duplicate Processing) 가능성. 이미 처리한 데이터인데 오프셋 정보가 없으면 다시 처리할 수 있습니다.
- 해결책: 비즈니스 로직을 멱등성(Idempotent) 있게 짜면 됩니다. (예: "이미 정산된 주문이면 패스" 로직 추가) - 중요

3. 이벤트 발행 (Producer) - 하이브리드 아키텍처

우리 프로젝트는 도메인 로직의 순수성과 데이터 일관성을 위해 Spring Event와 Kafka Bridge를 조합하여 사용합니다.