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

분산 이벤트 스트리밍 플랫폼인 Kafka는 높은 처리량, 내결함성 및 확장 가능한 아키텍처로 유명합니다. Kafka의 핵심은 모든 수신 데이터를 변경 불가능한 이벤트 로그로 취급하며 새로운 메시지를 지속적으로 추가하는 것입니다. 그러나 이러한 추가 전용 특성은 중요한 질문을 제기합니다. 이 데이터를 얼마나 오랫동안 유지해야 할까요? 이 문서는 Kafka의 데이터 보존 정책을 심층적으로 다루며, 귀중한 이벤트 스트림이 저장되는 기간을 결정하는 중요한 메커니즘과 스토리지, 성능 및 규정 준수를 최적화하기 위해 이를 효과적으로 관리하는 방법을 설명합니다.

데이터 보존 기간을 이해하고 올바르게 구성하는 것은 모든 Kafka 배포에서 매우 중요합니다. 잘못된 설정은 디스크 공간 고갈, 성능 저하 또는 반대로 다운스트림 소비자, 분석 또는 규정 준수 요구 사항에 영향을 미치는 조기 데이터 손실로 이어질 수 있습니다. 우리는 데이터 보존을 위해 Kafka가 사용하는 주요 전략인 시간 기반 및 크기 기반 전략을 살펴보고, Kafka 클러스터가 효율적이고 안정적으로 작동하도록 이러한 설정을 구성하고 모니터링하는 방법에 대한 실용적인 지침을 제공할 것입니다.

Kafka에서 데이터 보존 기간의 중요성

데이터 보존은 단순한 기술적 설정이 아니라 전체 데이터 생태계에 중대한 영향을 미치는 전략적 결정입니다. 이를 효과적으로 관리하려면 다음과 같은 몇 가지 중요한 요소를 균형 있게 고려해야 합니다.

• 스토리지 비용: 방대한 양의 기록 데이터를 무기한으로 저장하는 것은 특히 스토리지가 청구되는 클라우드 환경에서 비용이 많이 들 수 있습니다. 효율적인 보존 정책은 데이터가 정말로 필요한 기간 동안만 보관되도록 보장합니다.
• 성능 및 안정성: Kafka는 확장을 위해 설계되었지만 지나치게 큰 로그 파일은 브로커 시작 시간, 장애 발생 후 복구 프로세스 및 전반적인 시스템 안정성에 영향을 미칠 수 있습니다. 적절한 보존 기간은 관리 가능한 로그 크기를 유지하는 데 도움이 됩니다.
• 규정 준수 및 거버넌스: 규제 요구 사항(예: GDPR, HIPAA)은 특정 유형의 데이터를 얼마나 오래 보존해야 하는지 또는 반대로 얼마나 빨리 삭제해야 하는지를 자주 규정합니다. Kafka의 보존 정책은 이러한 의무를 충족하는 핵심 도구입니다.
• 소비자 요구 사항: 다운스트림 애플리케이션, 데이터 웨어하우스 또는 분석 도구는 재처리, 오류 복구 또는 일괄 분석을 위해 기록 데이터에 액세스해야 할 수 있습니다. 보존 설정은 소비자가 예상하는 최대 재처리 기간과 일치해야 합니다.

Kafka의 로그 관리 기본 사항

Kafka는 메시지를 토픽에 저장하며, 이는 논리적으로 파티션으로 나뉩니다. 각 파티션은 커밋 로그와 유사한 순서가 지정된 변경 불가능한 메시지 시퀀스입니다. 새 메시지는 항상 파티션 로그의 끝에 추가됩니다. 물리적으로 각 파티션의 로그는 브로커 디스크의 파일인 로그 세그먼트로 나뉩니다. 로그 세그먼트가 특정 크기나 수명에 도달하면 Kafka는 이를 "롤링"하여 수신 메시지에 대한 새 활성 세그먼트를 생성하고 이전 세그먼트를 닫힌 것으로 표시합니다. 데이터 보존 정책은 주로 이러한 오래된 닫힌 로그 세그먼트를 삭제함으로써 작동합니다.

Kafka는 데이터 보존을 위해 두 가지 주요 전략을 제공합니다.

1. 시간 기반 보존: 지정된 기간보다 오래된 메시지를 삭제합니다.
2. 크기 기반 보존: 파티션의 총 크기가 정의된 한계를 초과하면 가장 오래된 메시지를 삭제합니다.

이러한 정책은 파티션별로 적용됩니다. 둘 다 구성된 경우 먼저 삭제를 유발하는 보존 정책이 우선 적용됩니다.

시간 기반 데이터 보존 (log.retention.ms)

시간 기반 보존은 가장 일반적으로 사용되는 전략입니다. 지정된 시간 기간보다 오래된 모든 메시지는 삭제 대상이 되도록 지정합니다. 이는 기록 데이터가 무한정 축적되지 않도록 보장합니다.

구성 매개변수:

• log.retention.ms: 이 브로커 수준 속성은 이 설정을 재정의하지 않는 모든 토픽의 기본 보존 기간을 밀리초 단위로 정의합니다. 기본값은 604800000ms (7일)입니다.
• retention.ms: 이 토픽 수준 속성을 사용하면 특정 토픽에 대해 브로커 수준 기본값을 재정의할 수 있습니다. 또한 밀리초 단위의 보존 기간을 지정합니다.

작동 방식:

Kafka 브로커는 각 파티션 내의 로그 세그먼트를 주기적으로 확인합니다. 세그먼트 내의 모든 메시지가 retention.ms (또는 log.retention.ms) 임계값보다 오래된 경우 전체 세그먼트 파일이 디스크에서 삭제됩니다.

실용적인 고려 사항:

• 소비자 지연: 모든 소비자가 메시지를 처리하기에 보존 기간이 충분히 길어야 합니다. 소비자가 너무 뒤처지면 읽히기 전에 데이터가 삭제되어 데이터가 손실될 수 있습니다.
• 복구 기간: 애플리케이션 오류 또는 새 소비자 배포 시 데이터를 얼마나 멀리까지 재처리해야 합니까?
• 개발 대 프로덕션: 개발 환경은 리소스 절약을 위해 더 짧은 보존 기간(예: 24시간)을 사용할 수 있지만, 프로덕션 환경에서는 며칠 또는 몇 주가 필요할 수 있습니다.

예시: 토픽 데이터 보존 기간을 3일로 설정

my-important-topic이라는 토픽의 데이터를 3일(72시간) 동안 보존하도록 구성하려면 kafka-configs.sh 도구를 사용합니다:

# 밀리초 단위로 3일 계산: 3 * 24 * 60 * 60 * 1000 = 259200000 ms
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --alter --add-config retention.ms=259200000

# 설정 확인
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-important-topic --describe

크기 기반 데이터 보존 (log.retention.bytes)

크기 기반 보존은 파티션 로그가 디스크에서 특정 총 크기를 초과하지 않도록 보장합니다. 이 한도에 도달하면 Kafka는 총 크기가 임계값 미만이 될 때까지 가장 오래된 로그 세그먼트를 삭제합니다.

구성 매개변수:

• log.retention.bytes: 이 브로커 수준 속성은 파티션 로그의 기본 최대 크기를 바이트 단위로 정의합니다. 기본값은 -1로, 기본적으로 크기 제한이 적용되지 않음을 의미합니다(시간 기반 보존만 활성화됨).
• retention.bytes: 이 토픽 수준 속성을 사용하면 특정 토픽에 대해 브로커 수준 기본값을 재정의하여 단일 파티션 로그의 최대 크기를 바이트 단위로 지정할 수 있습니다.

작동 방식:

시간 기반 보존과 유사하게 Kafka는 각 파티션 로그의 총 크기를 주기적으로 확인합니다. 총 크기가 retention.bytes (또는 log.retention.bytes)를 초과하면 구성된 한도 내로 크기가 조정될 때까지 가장 오래된 로그 세그먼트가 삭제됩니다.

실용적인 고려 사항:

• 디스크 용량: 이는 디스크 공간이 제한된 경우에 중요합니다. 메시지 처리량에 관계없이 토픽이 디스크를 가득 채우지 않도록 보장합니다.
• 메시지 처리량 변동: 메시지 생성 속도가 변동하는 경우 크기 기반 보존은 피크 시간에 데이터를 더 빨리 삭제할 수 있으며, 일관된 조회 기간이 필요한 소비자에게 영향을 줄 수 있습니다.
• 파티션당 한도: retention.bytes는 파티션당 적용된다는 점을 기억하십시오. 따라서 10개의 파티션을 가진 토픽에 retention.bytes=1GB를 설정하면 총 10GB의 데이터를 저장할 수 있습니다.

예시: 파티션당 최대 1GB 보존하도록 토픽 설정

high-volume-logs라는 토픽을 파티션당 최대 1GB(1,073,741,824바이트)를 보존하도록 구성하려면:

# 바이트 단위로 1GB 계산: 1 * 1024 * 1024 * 1024 = 1073741824 바이트
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --alter --add-config retention.bytes=1073741824

# 설정 확인
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name high-volume-logs --describe

Kafka에서 데이터 보존 구성

보존 설정은 브로커 수준(모든 토픽에 대한 기본값)에서 적용되거나 세분화된 제어를 위해 토픽 수준에서 재정의될 수 있습니다.

브로커 수준 구성

클러스터의 모든 토픽에 대한 기본 보존 정책을 설정하려면 각 Kafka 브로커에서 server.properties 파일을 수정하십시오.

# 모든 토픽에 대한 기본 시간 기반 보존: 7일
log.retention.ms=604800000

# 모든 토픽에 대한 기본 크기 기반 보존: 제한 없음 (-1)
# 전역 크기 제한을 원하는 경우 주석을 제거하고 값을 설정하십시오.
# log.retention.bytes=10737418240 # 예시: 파티션당 10GB

# Kafka가 삭제할 로그 세그먼트를 확인하는 빈도(기본값: 5분)
log.retention.check.interval.ms=300000

server.properties를 수정한 후에는 변경 사항을 적용하기 위해 Kafka 브로커를 다시 시작해야 합니다. 브로커 수준에서 log.retention.bytes를 사용할 때는 주의해야 합니다. 이는 파티션당 적용되므로 많은 토픽과 파티션에 걸쳐 빠르게 합산될 수 있습니다.

토픽 수준 재정의

토픽 수준 구성은 브로커 수준 기본값보다 우선합니다. 서로 다른 토픽은 종종 다른 데이터 수명 요구 사항을 가지므로, 이는 보존 관리를 위한 권장 접근 방식입니다.

새 토픽에 대한 보존 정책 설정:

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic my-new-topic \n    --partitions 3 --replication-factor 3 \n    --config retention.ms=172800000 `# 2일` \n    --config retention.bytes=536870912 `# 파티션당 512 MB`

기존 토픽의 보존 정책 수정:

# 시간 보존을 5일로 변경
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.ms=432000000

# 크기 보존을 2GB로 변경
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --add-config retention.bytes=2147483648

# 토픽 수준 재정의를 제거하고 브로커 기본값으로 되돌리려면:
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --alter --delete-config retention.ms

토픽 구성 설명:

보존 설정을 포함하여 토픽의 현재 구성을 보려면 다음을 수행하십시오.

kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name my-existing-topic --describe

데이터 보존 대 로그 압축 (log.cleanup.policy)

데이터 보존(삭제)과 로그 압축을 구별하는 것이 중요합니다. Kafka의 log.cleanup.policy는 오래된 로그 세그먼트가 처리되는 방식을 결정합니다.

• delete(기본값): 이는 우리가 논의한 보존 전략으로, 시간 또는 크기 제한에 따라 전체 로그 세그먼트가 삭제됩니다.
• compact: 이 정책은 각 메시지 키에 대한 최신 메시지만 보존합니다. 이는 변경 로그 또는 현재 상태를 나타내는 토픽(예: 데이터베이스 변경 로그, 사용자 프로필)에 적합합니다. 압축을 사용하면 동일한 키에 대한 메시지의 오래된 버전은 결국 제거되지만, 각 키에 대한 마지막 값은 연령 또는 총 로그 크기에 따라 절대 삭제되지 않습니다 (토우 스톤에 대해 retention.ms가 특별히 구성된 경우는 제외).

이 문서는 delete 정책에 중점을 두지만, 다른 사용 사례에 대한 대안 전략으로 compact를 아는 것이 중요합니다.

모범 사례 및 고려 사항

1. 소비자 이해: 보존 기간을 설정하기 전에 다운스트림 애플리케이션이 데이터에 액세스해야 하는 기간을 분석하십시오. 처리 속도, 중단 가능성 및 재처리 요구 사항을 고려하십시오.
2. 디스크 사용량 모니터링: Kafka 브로커의 디스크 사용량을 적극적으로 모니터링하십시오. 디스크가 예상보다 빨리 채워지면 보존 정책과 메시지 처리량을 검토하십시오.
3. 합리적인 기본값으로 시작: 보수적인 보존 기간(예: 7일)으로 시작하고 관찰 및 요구 사항에 따라 조정하십시오. 손실된 데이터를 복구하는 것보다 보존 기간을 연장하는 것이 더 쉽습니다.
4. 토픽 수준 구성: 항상 토픽 수준에서 보존 정책을 설정하는 것이 좋습니다. 이는 유연성을 제공하고 다른 토픽에 대한 원치 않는 결과를 방지합니다.
5. 필요한 스토리지 계산: 데이터 수집 속도와 원하는 보존 기간(시간 기반의 경우) 또는 파티션당 원하는 로그 크기(크기 기반의 경우)를 곱하여 적절한 디스크 용량이 있는지 확인하십시오.
6. log.retention.check.interval.ms: 이 설정은 Kafka가 삭제할 세그먼트를 확인하는 빈도를 제어합니다. 값이 작을수록 확인 빈도가 높아지지만 CPU 오버헤드도 증가합니다. 기본값인 5분은 보통 충분합니다.
7. 철저히 테스트: 특히 보존 기간을 줄이는 경우 프로덕션에 적용하기 전에 항상 스테이징 환경에서 보존 변경 사항을 테스트하십시오.

결론

Kafka의 데이터 보존 정책은 이벤트 스트림의 수명 주기를 관리하는 강력하고 필수적인 메커니즘입니다. 브로커 및 토픽 수준에서 retention.ms(시간 기반) 및 retention.bytes(크기 기반)를 이해하고 효과적으로 구성하면 클러스터의 스토리지 공간, 성능 및 규정 준수 상태를 정밀하게 제어할 수 있습니다. 데이터 보존은 설정하고 잊어버리는 작업이 아니라는 점을 기억하십시오. 데이터 볼륨, 소비자 요구 사항 및 비즈니스 요구 사항이 발전함에 따라 지속적인 모니터링과 조정이 필요합니다. 이러한 개념을 마스터하면 Kafka 배포가 강력하고 비용 효율적이며 조직 목표에 부합하도록 유지될 것입니다.