일정 기간 동안 메시지를 지속성 있게 보관하는 것. 카프카가 큐가 아니라 로그인 이유이며, 컨슈머가 실시간으로 읽고 있지 않아도 되는 이유다.
시간과 크기 기준
자르는 기준은 시간과 크기다. 시간 기준은 log.retention.hours(기본 168시간, 1주일), log.retention.minutes, log.retention.ms로 잡고 더 작은 단위가 우선한다. log.retention.ms를 잡아두면 언제나 그 값이 적용되는 것이 보장되므로 이쪽이 권장된다. 크기 기준은 log.retention.bytes이고 -1이면 영구 보존이다. 둘 다 설정하면 하나만 성립해도 메시지가 삭제되므로, 의도치 않은 유실을 막으려면 둘 중 하나만 쓰는 편이 낫다.
파티션 단위의 적용
모든 보존 기능의 작동 단위는 파티션이다. 파티션이 8개이고 log.retention.bytes = 1GB면 토픽 전체의 최대 저장 용량은 8GB다. 그리고 파티션 수를 늘리면 보존되는 데이터 양도 함께 늘어난다. 크기 기준 보존을 쓸 때 놓치기 쉬운 지점이다.
세그먼트가 닫히는 시점
보존 설정은 개별 메시지에 적용되지 않는다. 로그 세그먼트 단위로 적용된다. 메시지는 현재 로그 세그먼트의 끝에 붙고, 세그먼트가 log.segment.bytes(기본 1GB)에 가까워지면 브로커가 그것을 닫고 새 세그먼트를 연다. 그리고 닫히기 전까지는 만료와 삭제의 대상이 아니다. 시간 기준 보존은 세그먼트 파일의 마지막 수정 시각(mtime), 즉 그 세그먼트가 닫힌 시각을 기준으로 판단한다.
로그 압착
압착은 다른 갈래다. 같은 키를 갖는 메시지 중 가장 최신 것만 보존하는데, 오래되었다고 지우는 것이 아니라 덮어써졌다고 지운다.
마지막 변경 값만 중요한 체인지 로그 형태의 데이터에 유용하다. 설정 저장용 토픽, 상태 저장소의 백업, DB 변경 스트림이 그렇다. 압착이 걸린 토픽은 아무리 오래되어도 각 키의 최신 값이 남아 있으므로 언제든 처음부터 읽어서 현재 상태를 복원할 수 있다. 스트림과 테이블이 성립하는 근거이고, 상태를 가진 스트림 처리에서 로컬 상태를 복구하는 방법이다.
보존 기간보다 오래 남는 데이터
세그먼트가 닫혀야 만료된다는 규칙이 놀라운 결과를 만든다. 하루 100MB가 들어오는 토픽에 log.segment.bytes는 기본값 1GB, log.retention.ms는 1주일을 걸었다고 하자. 세그먼트 하나를 채우는 데 10일이 걸리고 닫힌 뒤 7일을 더 보존하므로, 실제로는 최대 17일치가 저장되어 있다.
메시지가 뜸하게 들어오는 토픽이라면 세그먼트 크기를 줄여야 한다. 법적 요구사항으로 30일 보존을 걸어둔 경우에도 같은 함정이 있고, 이때는 AdminClient의 deleteRecords()로 직접 지운다.
log.roll.ms
log.roll.ms로 시간 기준으로 세그먼트를 닫을 수도 있는데 기본값은 설정되어 있지 않다. 브로커가 시작되는 시점부터 시간이 계산되므로 크기 제한에 도달하지 못한 작은 파티션들이 한꺼번에 닫히면서 디스크에 부담을 줄 수 있다.
참고
원본은 log.retention.ms의 기본값이 168시간이라고 적었다. 168시간은 log.retention.hours의 기본값이고, log.retention.ms와 log.retention.minutes에는 기본값이 없다. 값을 지정하지 않으면 더 큰 단위인 log.retention.hours가 쓰인다. Kafka Broker Configs