[Q]
cleanup.policy 부분과 min.cleanable.dirty.ratio의 상관관계는 어떻게 되나요? 설정을 잘못하면 처리되지않은 topic이 삭제되나요.
[A]
아주 중요한 포인트를 짚어주셨습니다. 결론부터 말씀드리면, cleanup.policy와 min.cleanable.dirty.ratio는 “로그 압축(compaction) 동작 시점과 강도”를 좌우하는 핵심 설정이며, 조합을 잘못하면 “미처리 메시지”가 삭제되는 게 아니라 “키 기준의 오래된 버전”이 예상보다 빨리(또는 느리게) 압축될 수 있습니다. 다만 cleanup.policy에 delete가 포함되어 있고 보존 한계(retention.ms / retention.bytes)를 넘기면, 미처리 여부와 무관하게 세그먼트가 삭제될 수 있습니다. 각각을 분리해 설명드리겠습니다.
### 개념 정리
– cleanup.policy
– delete: 보존 시간/용량 기준에 따라 오래된 세그먼트를 삭제합니다.
– compact: 같은 키에 대한 여러 버전 중 “가장 최근 버전”만 남기고 과거 버전을 정리합니다. 삭제 레코드(툼스톤)가 합의된 시간 이후 실제로 데이터를 제거하는 역할도 합니다.
– compact,delete: 두 정책을 함께 적용합니다. 이 경우 compaction이 주기적으로 실행되고, 보존 기준을 넘긴 세그먼트는 삭제(delete)도 일어납니다.
– min.cleanable.dirty.ratio (로그 컴팩션 “시작 임계치”)
– 의미: “압축되지 않은 더러운 데이터의 비율이 어느 정도 쌓여야 컴팩터가 해당 로그 세그먼트를 청소할지”를 결정합니다.
– 값이 낮을수록: 더 자주, 더 공격적으로 compaction이 진행됩니다(더 빨리 과거 버전이 제거).
– 값이 높을수록: compaction이 덜 자주 일어납니다(과거 버전이 더 오래 남음).
– segment.ms/segment.bytes, delete.retention.ms, max.compaction.lag.ms 등
– compaction의 타이밍과 삭제 레코드(툼스톤) 보존 기간, 세그먼트 회전 주기를 보조적으로 결정합니다.
### 상관관계와 영향
– cleanup.policy=compact인 토픽
– min.cleanable.dirty.ratio를 낮추면: 같은 키의 “과거 레코드”가 빨리 정리됩니다. 최신값은 남습니다.
– min.cleanable.dirty.ratio를 높이면: compaction이 느려지고 과거 레코드가 더 오래 남습니다. 복구/리플레이에 과거 버전이 일정 기간 필요하다면 높게 잡는 전략이 유리할 수 있습니다.
– 중요한 점: compaction은 “미처리 여부”가 아니라 “키 버전의 최신성”을 기준으로 과거 레코드를 정리합니다. 즉, 컨슈머가 아직 읽지 않았더라도 같은 키의 과거 값은 압축으로 사라질 수 있습니다. 이것을 “삭제”로 체감할 수 있으니 주의가 필요합니다.
– cleanup.policy=delete인 토픽
– min.cleanable.dirty.ratio는 compaction에만 영향을 주므로 사실상 무관합니다.
– 삭제는 retention.ms/retention.bytes에 의해 결정됩니다. 임계에 도달하면 세그먼트가 통째로 삭제되며, 컨슈머가 아직 처리하지 않은 메시지도 사라질 수 있습니다.
– cleanup.policy=compact,delete 혼합
– compaction이 먼저 과거 버전을 줄이고, 보존 기준(retention.*)에 도달하면 세그먼트 삭제가 발생합니다.
– min.cleanable.dirty.ratio가 낮아 compaction이 자주 일어나면, 과거 버전이 빠르게 정리된 상태에서 delete 보존 한계에 도달했을 때 세그먼트 삭제까지 이어질 수 있습니다. 반대로 ratio가 높으면 과거 버전이 비교적 오래 남지만, retention 한계에 닿으면 compaction 여부와 상관없이 세그먼트 삭제가 일어납니다.
### “설정을 잘못하면 처리되지 않은 토픽/메시지가 삭제되나요?”
– “토픽 자체”가 삭제되는 것은 별도의 삭제 명령 없이는 일어나지 않습니다.
– “메시지”는 아래 경우 삭제될 수 있습니다.
1) cleanup.policy에 delete가 포함되고 retention 한계를 초과한 경우: 컨슈머가 아직 처리하지 않아도 세그먼트가 삭제되어 읽을 수 없게 됩니다.
2) cleanup.policy=compact(혹은 혼합)이고 같은 키의 최신값이 존재하는 경우: 과거 버전은 compaction으로 정리되어 더는 소비할 수 없습니다. 이는 “유실”이 아니라 설계된 동작입니다. 키별 최신 스냅샷만 유지하려는 목적의 토픽에 적합합니다.
– 따라서 “미처리 메시지를 반드시 보존해야 하는” 요구가 있다면:
– cleanup.policy=delete만 사용하는 토픽에서는 retention.ms/bytes를 충분히 크게 잡아야 합니다.
– cleanup.policy=compact를 사용하는 토픽에서는 “과거 버전도 소비가 필요”하다면 설계가 맞지 않습니다. 대신 원본 로그를 delete 토픽에 보관하고, 별도의 compact 토픽을 파생해 운영하는 이중 토픽 패턴을 고려하시는 것이 안전합니다.
### 안전한 운영 가이드
– 미처리 데이터 보호가 최우선이면
– delete 정책: retention.ms를 넉넉히, retention.bytes도 용량 여유에 맞게 설정. 디스크 모니터링 필수.
– compact 정책: 과거 버전 보존이 필요하면 min.cleanable.dirty.ratio를 높이고, max.compaction.lag.ms를 길게 설정하여 compaction 지연. 다만 영구 보존이 목표라면 compact 토픽이 적합하지 않습니다.
– 재처리/리플레이 요구가 있으면
– 원본 토픽(삭제 위주) + 아카이브(Connect Sink to S3/HDFS) + 재주입 파이프라인을 표준화하십시오.
– 또는 원본 그대로 delete 정책, 파생 토픽으로 compact 정책을 분리해 목적별 사용.
– 혼합 정책(compact,delete)을 쓸 때
– compaction으로 과거 버전이 줄어들고, retention 임계 도달 시 삭제가 일어남을 전제로 테스트하세요.
– min.cleanable.dirty.ratio를 너무 낮게 두면 compaction이 빈번하여 예상보다 이른 “과거 버전 소멸”을 체감할 수 있습니다. 0.5 전후에서 시작해 트래픽/세그먼트 패턴을 보며 조정하는 방식을 권장드립니다.
### 요약
– min.cleanable.dirty.ratio는 “compact 동작 빈도/개시 임계”입니다. 낮을수록 과거 버전이 빨리 정리됩니다.
– 미처리 메시지가 통째로 사라지는 주된 원인은 delete 정책에서의 retention 한계 초과입니다. compact는 “같은 키의 과거 버전”만 제거합니다.
– 미처리 보존이 반드시 필요하다면 retention을 넉넉히 하고, compact 토픽을 원본 보관 목적으로 쓰지 마시길 권장드립니다.
현재 사용 중인 각 토픽의 cleanup.policy, retention.ms/bytes, 그리고 compact 여부를 알려 주시면, 자성님 워크로드 특성(처리 지연 허용 범위, 재처리 요구)에 맞춘 안전한 파라미터 조합을 구체적으로 제안드리겠습니다.