3.6. 데이터 보존 정책을 사용하여 로그 관리

Kafka는 로그를 사용하여 메시지 데이터를 저장합니다. 로그는 다양한 인덱스와 관련된 일련의 세그먼트입니다. 새 메시지는 활성 세그먼트에 기록되며 이후에 수정되지 않습니다. 세그먼트는 소비자의 가져오기 요청을 제공할 때 읽습니다. 정기적으로 활성 세그먼트가 읽기 전용이 되도록 롤아웃 되고 이를 대체하기 위해 새 활성 세그먼트가 생성됩니다. 한 번에 하나의 세그먼트만 활성화됩니다. 이전 세그먼트는 삭제할 수 있을 때까지 유지됩니다.

브로커 수준의 구성은 로그 세그먼트의 최대 크기(바이트)와 활성 세그먼트가 롤링되기 전의 시간(밀리초)을 설정합니다.

# ...
log.segment.bytes=1073741824
log.roll.ms=604800000
# ...

segment.bytessegment.ms 를 사용하여 주제 수준에서 이러한 설정을 재정의할 수 있습니다. 이러한 값을 낮추거나 높여야 하는지 여부는 세그먼트 삭제 정책에 따라 다릅니다. 크기가 클수록 활성 세그먼트에 더 많은 메시지가 포함되고 덜 자주 롤아웃됩니다. 또한 세그먼트는 덜 자주 삭제할 수 있게 됩니다.

로그를 관리할 수 있도록 시간 기반 또는 크기 기반 로그 보존 및 정리 정책을 설정할 수 있습니다. 요구 사항에 따라 로그 보존 구성을 사용하여 이전 세그먼트를 삭제할 수 있습니다. 로그 보존 정책을 사용하면 보존 제한에 도달하면 비활성 로그 세그먼트가 제거됩니다. 이전 세그먼트 삭제는 로그에 필요한 스토리지 공간을 제한하므로 디스크 용량을 초과하지 않습니다.

시간 기반 로그 보존의 경우 시간, 분 및 밀리초에 따라 보존 기간을 설정합니다.For time-based log retention, you set a retention period based on hours, minutes, and milliseconds. 보존 기간은 메시지가 세그먼트에 추가된 시간을 기반으로 합니다.

밀리초 구성의 우선 순위는 분보다 우선하며 시간보다 우선합니다. 기본적으로 분 및 밀리초 구성은 null이지만 세 가지 옵션은 유지하려는 데이터에 대한 상당한 수준의 제어를 제공합니다. 동적으로 업데이트할 수 있는 세 가지 속성 중 유일한 속성 중 하나이기 때문에 밀리초 구성에 우선 순위를 지정해야 합니다.

# ...
log.retention.ms=1680000
# ...

log.retention.ms 가 -1로 설정되면 로그 보존에 시간 제한이 적용되지 않으므로 모든 로그가 유지됩니다. 디스크 사용량을 항상 모니터링해야 하지만 -1 설정은 전체 디스크의 문제를 일으킬 수 있으므로 권장되지 않으며 이는 수정하기 어려울 수 있습니다.

크기 기반 로그 보존의 경우 최대 로그 크기(로그의 모든 세그먼트)를 바이트 단위로 설정합니다.

# ...
log.retention.bytes=1073741824
# ...

즉, 로그에는 일반적으로 정상 상태가 되면 로그.retention.bytes/log.segment.bytes 세그먼트가 포함됩니다. 최대 로그 크기에 도달하면 이전 세그먼트가 제거됩니다.

최대 로그 크기를 사용할 때의 잠재적인 문제는 메시지가 세그먼트에 추가되는 시간을 고려하지 않는다는 것입니다. 필요한 균형을 얻기 위해 정리 정책에 시간 기반 및 크기 기반 로그 보존을 사용할 수 있습니다. 먼저 정리를 트리거하는 임계값에 해당하는 것은 무엇입니까.

세그먼트 파일이 시스템에서 삭제되기 전에 시간 지연을 추가하려면 주제 구성의 특정 항목에 대해 브로커 수준 또는 file.delete.delay.ms 의 모든 항목에 대해 log.segment.delete.delay.ms 를 사용하여 지연을 추가할 수 있습니다.

# ...
log.segment.delete.delay.ms=60000
# ...