Kafka 토픽 삭제 vs 보존 정책 명령어 비교

Kafka에서 데이터를 제거하는 방법은 두 가지로 매우 다릅니다: 전체 토픽을 삭제하거나, 보존 정책을 통해 활성 토픽에서 오래된 로그 세그먼트를 제거하는 것입니다. Kafka 토픽을 효과적으로 관리하는 것은 시스템 상태를 유지하고, 스토리지를 최적화하며, 데이터 무결성을 보장하는 데 중요합니다. 여기에는 토픽 생성 및 모니터링뿐만 아니라 더 이상 필요하지 않은 데이터를 안전하게 제거하는 방법을 이해하는 것도 포함됩니다. 데이터 제거에는 두 가지 주요 메커니즘이 있습니다: 즉시 토픽 삭제와 시간 기반 보존 정책입니다. 두 방법 모두 궁극적으로 데이터가 제거되지만, 기능적 차이, 사용 사례 및 영향은 크게 다릅니다.

토픽 자체가 사라져야 할 때는 토픽 삭제를 사용하세요. 토픽은 유지하되 오래된 데이터가 자동으로 삭제되도록 하려면 보존 설정을 사용하세요.

Kafka 토픽 삭제 이해하기 (kafka-topics.sh --delete)

Kafka에서 토픽 삭제는 토픽, 모든 파티션, 데이터 및 메타데이터를 Kafka 클러스터에서 완전히 제거하기 위한 직접적이고 즉각적인 작업입니다. 이는 일반적으로 토픽이 더 이상 사용되지 않거나, 오류로 생성되었거나, 시스템에서 더 이상 필요하지 않을 때 사용됩니다.

토픽 삭제 작동 방식

토픽 삭제 명령을 실행하면 Kafka는 해당 토픽을 삭제 대상으로 표시합니다. 실제 삭제 프로세스는 여러 단계로 진행됩니다:

1. 삭제 표시: ZooKeeper(또는 KRaft 클러스터의 경우 Kafka Raft 쿼럼)에 있는 토픽의 메타데이터가 삭제 대상으로 업데이트됩니다.
2. 컨트롤러 작업: Kafka 컨트롤러(특별한 역할을 가진 브로커)가 삭제를 조정합니다. 다른 브로커들에게 표시된 토픽의 파티션에 대한 생성 및 소비를 중단하도록 지시합니다.
3. 로그 디렉토리 정리: 삭제된 토픽의 파티션을 호스팅하는 각 브로커는 결국 디스크에서 관련 로그 세그먼트와 인덱스 파일을 제거합니다. 이 정리는 비동기적으로 이루어지며 브로커/컨트롤러 조정 및 파티션을 호스팅한 브로커의 파일 시스템 정리에 따라 달라집니다.

토픽 삭제 활성화

토픽을 삭제하려면 먼저 모든 Kafka 브로커에서 토픽 삭제를 명시적으로 활성화해야 합니다. 이는 우발적인 데이터 손실을 방지하기 위한 중요한 안전 조치입니다.

토픽 삭제를 활성화하려면 각 Kafka 브로커의 server.properties 파일에 다음 속성을 설정하세요:

delete.topic.enable=true

server.properties를 수정한 후 변경 사항을 적용하려면 Kafka 브로커를 다시 시작하세요.

실용 예제: 토픽 삭제

my-obsolete-topic이라는 토픽을 삭제하려면:

kafka-topics.sh --bootstrap-server localhost:9092 --delete --topic my-obsolete-topic

출력 예시:

Deleting topic my-obsolete-topic.

토픽을 나열하여 삭제 대상으로 표시되었는지 확인할 수 있습니다:

kafka-topics.sh --bootstrap-server localhost:9092 --list

성공하면 my-obsolete-topic이 처음에는 목록에 계속 나타날 수 있지만(삭제 대상으로 표시됨), 모든 브로커에서 정리 프로세스가 완료된 후에는 완전히 사라집니다.

경고: 토픽 삭제는 파괴적이고 되돌릴 수 없는 작업입니다. 삭제되면 데이터는 사라집니다. 항상 극도의 주의를 기울이고 백업이 있거나 데이터가 더 이상 필요하지 않다는 확신이 있는지 확인하세요.

Kafka 토픽 보존 정책 구성

Kafka 보존 정책은 메시지를 토픽에 얼마나 오래 보관할지 또는 얼마나 많은 공간을 차지할지 정의하여 데이터 수명 주기를 보다 세분화되고 자동으로 관리할 수 있는 방법을 제공합니다. 이는 오래된 데이터가 시간이 지남에 따라 자연스럽게 중요성을 잃는 이벤트 스트림, 로그 또는 메트릭을 저장하는 활성 토픽에 이상적입니다.

보존 정책 작동 방식

Kafka 브로커는 정의된 보존 한계를 초과한 데이터가 있는지 주기적으로 토픽 세그먼트를 확인하는 로그 정리 프로세스를 지속적으로 실행합니다. 두 가지 주요 보존 구성이 있습니다:

1. retention.ms (시간 기반 보존): 이 구성은 Kafka가 로그 세그먼트를 삭제 대상으로 삼기 전에 보관할 최대 시간(밀리초)을 지정합니다. 예를 들어 retention.ms가 604800000(7일)로 설정된 경우 7일보다 오래된 모든 메시지는 제거됩니다.

2. retention.bytes (크기 기반 보존): 이 구성은 토픽의 파티션이 디스크에서 차지할 수 있는 최대 크기(바이트)를 지정합니다. 이 크기에 도달하면 Kafka는 retention.ms와 관계없이 토픽 크기가 한도 내에 들어올 때까지 가장 오래된 세그먼트를 삭제합니다.

retention.ms와 retention.bytes가 모두 구성된 경우 먼저 트리거되는 정책이 우선 적용됩니다. 예를 들어 크기 한도보다 시간 한도에 먼저 도달하면 retention.ms에 의해 데이터가 삭제됩니다. 시간 한도보다 크기 한도에 먼저 도달하면 retention.bytes가 삭제를 트리거합니다.

참고: retention.ms 값이 -1이면 무기한 보존을 의미합니다(데이터가 시간에 의해 삭제되지 않음).

실용 예제: 보존 설정으로 토픽 생성

24시간 보존 기간(86,400,000밀리초)으로 my-event-stream 토픽을 생성하려면:

kafka-topics.sh --bootstrap-server localhost:9092 \
                --create \
                --topic my-event-stream \
                --partitions 3 \
                --replication-factor 1 \
                --config retention.ms=86400000

실용 예제: 기존 토픽의 보존 설정 변경

기존 토픽 my-log-topic의 보존을 7일(604,800,000밀리초)로 변경하고 크기 한도를 1GB(1,073,741,824바이트)로 추가하려면:

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --add-config retention.ms=604800000,retention.bytes=1073741824

특정 보존 설정을 제거하려면(예: retention.bytes를 브로커 기본값으로 되돌리려면):

kafka-configs.sh --bootstrap-server localhost:9092 \
                 --entity-type topics \
                 --entity-name my-log-topic \
                 --alter \
                 --delete-config retention.bytes

토픽 구성 보기

보존 설정을 포함한 토픽의 현재 구성을 확인할 수 있습니다:

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

주요 차이점 및 사용 사례

기능	토픽 삭제 (--delete)	보존 정책 (retention.ms/retention.bytes)
작업 유형	수동, 즉시, 되돌릴 수 없음	자동, 지속적, 구성 가능
범위	전체 토픽 제거(모든 데이터 및 메타데이터)	활성 토픽 내 오래된 데이터 세그먼트 제거
목적	더 이상 사용되지 않는 토픽 제거, 오류 수정	활성 토픽의 데이터 수명 주기 관리, 스토리지 사용량 제어
데이터 손실 위험	높음(모든 데이터가 즉시 손실됨)	통제됨(정책을 초과하는 데이터만 제거됨)
구성	브로커 수준 delete.topic.enable, 그 다음 명령 실행	토픽 수준 구성 (--config 또는 --alter)
되돌리기 가능성	아니요	향후 데이터에 대해 변경 또는 비활성화 가능하지만, 과거 제거는 영구적

토픽 삭제를 사용해야 하는 경우

• 더 이상 사용되지 않는 토픽: 프로젝트나 서비스가 중단되고 관련 Kafka 토픽이 더 이상 필요하지 않은 경우.
• 개발/테스트 정리: 개발 또는 테스트 주기 동안 생성된 임시 토픽 정리.
• 오류 수정: 잘못된 구성(예: 너무 많은 파티션, 잘못된 복제 계수)으로 토픽이 생성되어 처음부터 다시 만드는 것이 더 쉬운 경우.

보존 정책을 사용해야 하는 경우

• 로깅/모니터링 데이터: 오래된 데이터가 결국 가치를 잃는 애플리케이션 로그, 메트릭 또는 감사 이벤트를 수집하는 토픽의 경우.
• 이벤트 스트림: 이벤트 기반 아키텍처에서 이벤트를 재생 또는 소비자 동기화를 위해 일정 기간 동안 액세스할 수 있어야 하지만 무기한으로는 필요하지 않은 경우.
• 리소스 관리: 토픽이 Kafka 브로커에서 과도한 디스크 공간을 소비하는 것을 방지하여 클러스터 안정성과 비용 효율성을 보장합니다.
• 규정 준수: 특정 기간 후에 데이터를 삭제하도록 요구하는 데이터 보존 규정을 준수합니다.

모범 사례 및 고려 사항

• delete.topic.enable=true를 신중하게 활성화: 삭제에 필요하지만 프로덕션 환경에서 삭제 작업을 수행할 수 있는 사람을 주의하세요.
• 보존 자동화: 대부분의 활성 토픽의 경우 처음부터 합리적인 보존 정책을 수립하여 예상치 못한 디스크 공간 문제를 방지하세요.
• 디스크 사용량 모니터링: Kafka 브로커 디스크 사용량을 정기적으로 모니터링하세요. 토픽이 예상치 못하게 증가하는 경우 보존 정책을 검토하거나 프로듀서 동작을 조사하세요.
• 삭제/보존 테스트: 비프로덕션 환경에서 토픽 삭제를 시뮬레이션하고 보존 정책이 어떻게 작동하는지 관찰하여 그 영향을 완전히 이해하세요.
• 중요 데이터 백업: 중요하거나 장기 보관 데이터가 포함된 토픽의 경우 Kafka의 무기한 보존에만 의존하지 말고 외부 보관 솔루션(예: S3, HDFS)을 고려하거나 retention.ms를 -1로 설정하고 retention.bytes를 충분히 크게 또는 -1로 설정하세요.
• 압축된 토픽: 로그 압축이 활성화된 토픽(cleanup.policy=compact)의 경우 retention.ms는 압축된 오래된 세그먼트(개별 메시지가 아님)를 삭제하는 데 여전히 적용되며, min.cleanable.dirty.ratio는 압축이 실행되는 시기를 제어합니다. 이는 표준 보존과는 별개의 메커니즘이며 특정 키의 최신 값이 중요한 토픽(예: 데이터베이스 변경 로그, 사용자 프로필)에 사용됩니다.

결론

프로듀서, 컨슈머 및 다운스트림 종속성이 더 이상 필요하지 않을 때만 Kafka 토픽을 삭제하세요. 활성 토픽의 경우 retention.ms와 retention.bytes를 신중하게 설정하고 브로커 디스크 사용량을 모니터링하여 스토리지 압박이 문제가 되기 전에 오래된 데이터가 만료되도록 하세요.