리텐션

Kafka가 메시지를 얼마나 오래 보관할지 정하는 설정. cleanup.policy=delete(기본)일 때 적용된다.

"소비해도 안 사라진다"의 진짜 의미

Kafka는 큐가 아니라 로그라서 소비해도 메시지가 남는다 — 여기까지는 맞는데, 언제까지 남는지가 빠지면 반쪽 지식이다. 그 답이 리텐션이다.

둘 중 어느 하나라도 넘기면 삭제 대상이 된다.

어떻게 지우나 — 세그먼트 단위

Kafka는 파티션 로그를 세그먼트라는 파일 여러 개로 나눠 쓴다. 지금 쓰는 파일(액티브 세그먼트)이 일정 크기(segment.bytes, 기본 1GB)나 시간(segment.ms)에 도달하면 닫고 새 파일을 연다.

파티션 0 디렉터리
  00000000000000000000.log   ← 닫힌 세그먼트 (삭제 후보)
  00000000000000523100.log   ← 닫힌 세그먼트 (삭제 후보)
  00000000000001048200.log   ← 액티브 세그먼트 (지우지 않는다)

삭제는 레코드 하나씩이 아니라 파일 통째로 이뤄진다. 파일 단위라 삭제 비용이 거의 0이지만, 그래서 "리텐션이 지나면 즉시 사라진다"가 아니다 — 그 레코드가 속한 세그먼트가 닫히고 조건을 넘겨야 지워진다. 리텐션을 1시간으로 잡아도 데이터가 며칠 남아 있는 일이 생기는 이유가 이것이다.

실무에서 걸리는 지점

① 재처리 창이 곧 리텐션이다. "3개월 전 이벤트를 다시 흘려 주세요"는 리텐션이 7일이면 애초에 불가능하다. 장기 보관이 필요하면 별도 저장소(데이터 레이크·오브젝트 스토리지)로 싱크해 두는 게 정석이다.

② 컨슈머가 오래 죽어 있으면 데이터를 건너뛴다. 컨슈머가 커밋해 둔 오프셋의 데이터가 리텐션으로 이미 지워졌다면, 그 오프셋은 더 이상 존재하지 않는다. 이때 동작은 auto.offset.reset 설정이 정한다 — earliest(남아 있는 가장 오래된 것부터)나 latest(지금부터). latest면 그사이 데이터를 조용히 통째로 건너뛴다.

③ 랙이 갑자기 0이 되면 의심한다. 따라잡은 게 아니라 리텐션으로 데이터가 날아간 것일 수 있다.

어디에 설정하나

브로커 전역(log.retention.hours)과 토픽별(retention.ms) 둘 다 가능하고, 토픽 설정이 우선한다. 토픽 성격에 따라 다르게 잡는 게 정상이다 — 감사 로그는 길게, 일회성 알림은 짧게.

면접 함정

• ❌ "Kafka는 메시지를 영구 보관한다" → 기본 7일이다.
• ❌ "리텐션이 지나면 바로 지워진다" → 세그먼트 파일 단위라 지연이 있다.

토픽별로 설정하기

# 이 토픽만 30일 보관
kafka-configs.sh --bootstrap-server localhost:9092 \
  --alter --entity-type topics --entity-name orders \
  --add-config retention.ms=2592000000

# 현재 설정 확인
kafka-configs.sh --bootstrap-server localhost:9092 \
  --describe --entity-type topics --entity-name orders

브로커 전역 설정(log.retention.hours)보다 토픽 설정이 우선한다. 감사 로그는 길게, 일회성 알림은 짧게 — 토픽 성격에 따라 다르게 잡는 게 정상이다.

컨슈머가 뒤처졌을 때의 동작

auto.offset.reset=earliest   # 남아 있는 가장 오래된 것부터 (유실을 감지하고 최대한 복구)
auto.offset.reset=latest     # 지금부터 (그사이 데이터를 조용히 건너뛴다)
auto.offset.reset=none       # 예외를 던진다 (문제를 숨기지 않는다)

정합성이 중요하면 none으로 두고 사람이 판단하게 하는 선택지도 있다.