[Q]
kafka가 동기화가 retention.hours가 72인데 50시간이 지났습니다. 오랫동안 안되었을때 문제점이 있나요? 아니면 retention이 남았으니 상관없나요?
[A]
결론부터 말씀드리면 “retention.hours=72”에서 50시간이 경과한 상태라면, 보존 시간 관점에서는 아직 삭제 시점 전이므로 당장 데이터가 사라지지는 않습니다. 다만 “동기화가 오랫동안 안 되었다”는 사실 자체가 다른 위험을 키울 수 있어 몇 가지 체크가 필요합니다.
### 지금 상태에서의 영향 정리
– 보존 관점: 72시간 보존이면 50시간 경과 시점까지의 세그먼트는 삭제 대상이 아닙니다. 즉시 유실되지는 않습니다.
– 위험 누적 관점:
– 백로그 급증: 프로듀스는 계속되는데 컨슘/동기화가 지연되면 미처리 메시지가 쌓입니다. 처리 재개 시 폭증한 레코드로 인해 소비 지연, 다운스트림 병목, 재처리 시간 증가가 발생할 수 있습니다.
– 디스크 압력: retention.bytes 또는 디스크 용량 한계에 먼저 도달하면, 시간 보존(72시간) 이전에 오래된 세그먼트가 삭제될 수 있습니다. 이 경우 “미처리라도” 삭제될 수 있어 위험합니다.
– 오프셋 범위 이탈: 지연이 더 길어져 삭제가 발생하면 컨슈머가 마지막 커밋 오프셋에서 읽으려 할 때 OutOfRange가 나고, auto.offset.reset 정책(earliest/latest)에 따라 재지정됩니다. 결과적으로 일부 데이터가 재처리 불가해질 수 있습니다.
– 컴팩션 토픽 주의: cleanup.policy=compact(또는 mixed)라면 같은 키의 과거 버전이 컨슈머 미처리와 무관하게 일찍 정리될 수 있습니다. 과거 버전 재처리가 필요하다면 원본 보관 토픽을 별도로 두는 설계가 안전합니다.
### 당장 무엇을 점검해야 할까요?
– 현재 백로그 규모: 컨슈머 그룹의 lag(파티션별)과 추정 소요 시간(처리율 대비)을 확인하세요.
– 디스크 여유와 retention.bytes: 각 브로커의 로그 디렉터리 사용률과 토픽별 retention.bytes 설정을 함께 체크하세요. 바이트 한계가 시간 보존보다 먼저 발동할 수 있습니다.
– 정책 확인: 각 토픽의 cleanup.policy(compact/delete), retention.ms/bytes, segment.bytes/ms를 확인해 실제 삭제/컴팩션 타이밍을 파악하세요.
– 컨슈머 복구 전략: auto.offset.reset, 커밋 방식(수동/자동), 재처리 시 중복 허용 설계를 점검하세요. 필요시 DLT(실패 격리)나 리플레이 경로를 마련하십시오.
### 지연이 더 길어질 것 같다면 권장 대응
– 일시적 보존 연장: 위험 토픽만 retention.ms를 일시적으로 상향하면, 브로커 재시작 없이 즉시 적용됩니다. 디스크 모니터링을 강화하세요.
– 처리량 증대: 컨슈머 인스턴스/스레드 확장, max.poll.records 조정, fetch/receive 버퍼 확대 등으로 단기 처리 역량을 올리세요.
– 백프레셔/스로틀: 다운스트림이 병목이면 프로듀서 전송률 제한 또는 배치 크기 조정으로 폭주를 완화하세요.
– 아카이빙 병행: Kafka Connect Sink(S3/HDFS 등)로 원본을 아카이브해 만일의 유실에 대비하고, 필요 시 재주입 경로를 확보하세요.
### 요약
– 50시간 경과는 아직 보존 시간 내라 당장 “시간 기준” 삭제는 없습니다.
– 그러나 디스크 용량/retention.bytes, 컴팩션 정책, 백로그 폭증으로 인한 2차 장애가 더 큰 리스크입니다.
– 지연이 계속될 조짐이 보이면, 위험 토픽의 retention 임시 상향 + 컨슈머 스케일 아웃 + 디스크 모니터링을 즉시 병행하시길 권장드립니다.
토픽별 설정 값(cleanup.policy, retention.ms/bytes)과 현재 lag/디스크 사용률을 알려주시면, 자성님 환경에 맞춰 어떤 토픽부터 얼마큼 보존을 늘리고, 컨슈머를 어떻게 증설하면 좋은지 구체적으로 계산해 드리겠습니다.