[Q]
apache zookeeper도 설정되어 있는데 kafka만 재기동 하면 retention.hours=72 에서 retention.hours=720으로 증가 시켜도 되나요? 아니면 별도로 다르게 설정해야하나요?
[A]
결론부터 말씀드리면 브로커(server.properties)에서 보존 기간을 72→720으로 늘리는 것은 “Kafka만” 재기동해도 적용됩니다. ZooKeeper(KRaft가 아닌 구버전 메타데이터 모드) 설정을 따로 바꿀 필요는 없습니다. 다만 몇 가지 구분과 주의사항이 있습니다.
### 무엇을 어디에 변경하느냐에 따라 다릅니다
– 클러스터(브로커) 기본값 변경: server.properties의 log.retention.hours(또는 log.retention.ms/bytes)를 바꾸면 “새로 생성되는 토픽”과 “명시적 per-topic 설정이 없는 기존 토픽”에 기본값이 적용됩니다. 이 경우 브로커 재기동만으로 충분합니다.
– 특정 토픽별로 다르게 운영: 이미 존재하는 토픽에 개별 보존 시간이 설정되어 있다면, 브로커 기본값을 바꿔도 그 토픽에는 즉시 영향이 없습니다. 이때는 토픽 단위 설정 변경이 필요합니다.
– kafka-configs.sh –bootstrap-server … –alter –entity-type topics –entity-name
즉,
– “전체 기본 보존 기준을 늘리고 싶다” → server.properties 변경 + Kafka 재기동으로 OK
– “특정 토픽의 보존 기준을 늘리고 싶다” → 해당 토픽의 retention.ms(또는 hours) 값을 명시적으로 변경 필요
ZooKeeper는 메타데이터 저장소 역할이며, 보존 설정 자체를 직접 수정하지 않습니다. 브로커가 설정을 읽어 동작하므로 Kafka만 재기동하면 됩니다.
### 추가 체크 포인트
– 단위 일관성: 최신 Kafka에서는 ms 단위(retention.ms)를 권장합니다. hours 설정을 쓰시더라도 내부적으로 ms로 변환됩니다. 운영 표준을 retention.ms로 통일하면 혼동이 줄어듭니다.
– 삭제 정책 확인: cleanup.policy가 delete인지 compact인지(또는 혼합) 확인하세요. delete 정책에서만 보존 시간이 직접적으로 삭제 타이밍에 영향을 줍니다. compact 혼합인 경우 segment.ms, min.cleanable.dirty.ratio 등도 함께 고려해야 합니다.
– 세그먼트 경계: 보존 시간은 “세그먼트 단위”로 적용됩니다. 보존 시간이 늘어나도 이미 삭제 조건을 충족해 마크된 세그먼트는 복원되지 않습니다. 반대로 시간을 늘리면 앞으로의 삭제가 늦춰집니다.
– 디스크 용량: 보존 시간을 크게 늘리면 디스크 사용량이 증가합니다. log.segment.bytes, retention.bytes, 브로커별 볼륨 모니터링을 함께 점검하십시오.
– 롤링 재시작 권장: 다중 브로커 환경에서는 무중단을 위해 브로커를 순차적으로 재시작(rolling)하세요. 컨트롤러와 리더 파티션 이동으로 인한 일시적 지연을 최소화할 수 있습니다.
### 실무 절차 예시
1) 클러스터 기본값 상향(전역)
– server.properties에서 log.retention.ms = 259200000(= 72h) → 2592000000(= 720h)로 변경
– 브로커 롤링 재시작
– 영향 받는 토픽: per-topic retention이 비설정(default)인 토픽
2) 특정 중요 토픽만 상향
– kafka-configs.sh –alter … –add-config retention.ms=2592000000
– 브로커 재시작 불필요(동적 적용). 다만 운영 편의상 설정 변경 배포 창구를 통일하세요.
정리하면, ZooKeeper를 별도로 만질 필요는 없고, 목적에 따라 브로커 기본값 또는 토픽별 설정을 선택해 변경하시면 됩니다. 환경 정보(브로커/토픽 수, 현재 per-topic 설정 유무)를 알려주시면, 안전한 롤링 재시작 순서와 설정 값(segments, cleanup 정책 포함)을 맞춤으로 제안드리겠습니다.