Kafka 데이터 보존: 이벤트 스트림 이해 및 관리

Kafka 데이터 보존은 실용적인 질문에 답합니다: 이벤트 스트림이 Kafka에서 삭제되기 전에 디스크에 얼마나 오래 남아 있어야 할까요? 설정이 너무 느슨하면 브로커의 공간이 부족해질 수 있습니다. 너무 공격적이면 느린 소비자가 데이터를 재생할 기회를 잃을 수 있습니다.

Kafka는 레코드를 파티션 로그에 저장합니다. 이러한 로그는 세그먼트 파일로 분할되며, 보존 정리 작업은 오래된 닫힌 세그먼트를 삭제합니다. 이 세부 사항이 중요한 이유는 Kafka가 일반적으로 레코드가 오래되자마자 한 번에 하나씩 삭제하지 않기 때문입니다. 세그먼트는 구성된 보존 규칙을 충족할 때만 삭제 대상이 됩니다.

보존 설정이 중요한 이유

보존은 스토리지, 재생 요구 사항 및 운영 위험 간의 균형입니다.

스토리지 비용: 볼륨이 큰 토픽의 장기 보존은 많은 브로커 디스크를 소비할 수 있습니다.
소비자 복구: 보존 기간은 가장 긴 현실적인 소비자 중단 또는 재처리 기간보다 길어야 합니다.
안정성: 디스크가 가득 차면 브로커가 쓰기를 수락하지 못하고 더 넓은 클러스터 문제를 유발할 수 있습니다.
규정 준수: 일부 데이터는 최소 기간 동안 보관해야 하는 반면, 다른 데이터는 신속하게 제거해야 합니다.

결제 토픽은 며칠의 재생 기록이 필요할 수 있습니다. 개발 클러스터의 디버그 로그 토픽은 몇 시간만 필요할 수 있습니다.

Kafka가 오래된 데이터를 삭제하는 방법

Kafka 토픽은 파티션으로 나뉩니다. 각 파티션은 순서가 지정된 추가 전용 로그입니다. Kafka는 새 레코드를 활성 세그먼트에 쓰고 현재 세그먼트가 구성된 크기나 사용 기간에 도달하면 새 세그먼트로 롤오버합니다.

보존은 파티션별로 적용됩니다. retention.bytes=1073741824로 설정하면 전체 토픽에 대해 1GiB가 아니라 파티션당 약 1GiB입니다. 따라서 12개의 파티션이 있는 토픽은 복제본을 계산하기 전에 약 12GiB를 유지할 수 있습니다.

시간 기반 및 크기 기반 보존이 모두 구성된 경우 Kafka는 두 제한 중 하나라도 정리가 필요할 때 적격한 오래된 세그먼트를 삭제할 수 있습니다.

시간 기반 보존

시간 기반 보존은 구성된 기간 동안 레코드를 유지합니다.

브로커 수준에서 log.retention.ms는 재정의하지 않는 토픽의 기본값을 설정합니다. 토픽 수준에서 retention.ms는 단일 토픽에 대해 해당 기본값을 재정의합니다.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --alter \
  --add-config retention.ms=259200000

이 예제는 orders를 3일로 설정합니다. 다음으로 확인합니다:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name orders \
  --describe

주요 요구 사항이 "소비자가 주말 중단에서 복구할 수 있어야 함"과 같은 재생 기간인 경우 시간 보존을 사용합니다.

크기 기반 보존

크기 기반 보존은 각 파티션이 유지할 수 있는 로그 데이터의 양을 제한합니다.

브로커 수준에서 log.retention.bytes는 파티션당 기본 제한을 설정합니다. 토픽 수준에서 retention.bytes는 단일 토픽에 대해 이를 재정의합니다. -1 값은 해당 설정에서 크기 제한이 없음을 의미합니다.

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name high-volume-logs \
  --alter \
  --add-config retention.bytes=1073741824

이는 파티션당 1GiB 제한을 설정합니다. 고정된 시간 기간보다 디스크 보호가 더 중요한 경우 크기 보존을 사용합니다. 트래픽 급증으로 인해 효과적인 재생 기간이 단축될 수 있으므로 버스트가 발생하는 토픽에 주의하십시오.

브로커 기본값 및 토픽 재정의

브로커 기본값은 server.properties에 있으며 자체 보존 값을 설정하지 않은 토픽에 적용됩니다.

log.retention.ms=604800000
log.retention.bytes=-1
log.retention.check.interval.ms=300000

브로커 기본값을 변경하려면 일반적으로 Kafka 버전 및 배포 도구에 따라 브로커 재시작 또는 동적 브로커 구성 변경이 필요합니다. kafka-configs.sh를 통한 토픽 수준 변경은 종종 더 안전합니다. 다른 토픽이 동일한 보존 기간을 필요로 하는 경우는 드물기 때문입니다.

새 토픽의 경우 생성 시 보존을 설정합니다:

kafka-topics.sh --bootstrap-server localhost:9092 \
  --create \
  --topic audit-events \
  --partitions 6 \
  --replication-factor 3 \
  --config retention.ms=604800000 \
  --config retention.bytes=2147483648

기존 토픽의 경우 토픽 구성을 변경합니다:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --add-config retention.ms=1209600000

브로커 기본값으로 되돌리려면 토픽 재정의를 삭제합니다:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name audit-events \
  --alter \
  --delete-config retention.ms

보존 및 로그 압축

Kafka 정리는 cleanup.policy에 의해 제어됩니다. 일반적인 값은 delete, compact 또는 compact,delete입니다.

delete는 보존 시간 또는 크기에 따라 오래된 로그 세그먼트를 제거합니다.
compact는 각 키의 최신 값을 유지하고 시간이 지남에 따라 해당 키의 이전 값을 제거합니다.
compact,delete는 압축 및 삭제 규칙을 모두 적용할 수 있습니다.

압축은 고객 ID를 키로 하는 고객 프로필 업데이트와 같은 변경 로그 스타일 토픽에 유용합니다. 보존의 일반적인 대체는 아닙니다. 톰스톤 및 삭제 보존에는 자체 타이밍 동작이 있으므로 정리에 의존하기 전에 압축된 토픽을 테스트하십시오.

실용적인 보존 체크리스트

견딜 수 있는 가장 긴 소비자 중단부터 시작하십시오. 소비자 그룹이 48시간 동안 오프라인 상태가 될 수 있다면 24시간 보존 기간은 너무 짧습니다.

프로덕션 토픽을 변경하기 전에 디스크 요구 사항을 추정하십시오:

초당 수집 속도 x 보존 시간(초) x 파티션 수 x 복제 계수

압축, 레코드 크기, 인덱스 및 세그먼트 오버헤드가 실제 숫자에 영향을 미치기 때문에 이는 추정치일 뿐입니다. 그럼에도 불구하고 유용한 출발점을 제공합니다.

브로커 디스크 사용량, 토픽 증가율, 복제본 미달 파티션 및 소비자 지연을 함께 모니터링하십시오. 디스크 압박과 증가하는 지연은 소비자가 보존 기간을 벗어날 수 있다는 경고입니다.

가장 안전한 기본값은 간단합니다: 토픽 수준 보존을 사용하고, 각 볼륨이 큰 토픽에 설정이 있는 이유를 문서화하고, 프로덕션에 적용하기 전에 스테이징에서 더 짧은 보존을 테스트하십시오.