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

분산 이벤트 스트리밍 플랫폼인 Kafka는 많은 최신 데이터 아키텍처의 핵심입니다. Kafka 토픽을 효과적으로 관리하는 것은 시스템 상태 유지, 스토리지 최적화, 데이터 무결성 보장에 매우 중요합니다. 여기에는 토픽 생성 및 모니터링뿐만 아니라 더 이상 필요하지 않은 데이터를 깔끔하게 제거하는 방법을 이해하는 것도 포함됩니다. 데이터 제거를 위한 두 가지 주요 메커니즘은 즉각적인 토픽 삭제와 시간 기반 보존 정책입니다. 둘 다 궁극적으로 데이터 제거로 이어지지만, 기능적 차이, 사용 사례 및 영향은 크게 다릅니다.

본 기사에서는 kafka-topics.sh --delete 명령을 사용한 Kafka 토픽 삭제와 retention.ms 및 retention.bytes와 같은 토픽 구성을 통한 데이터 보존 정책 설정의 미묘한 차이를 자세히 다룹니다. 각 메커니즘이 작동하는 방식, 실제 명령 예시, 각각의 장단점을 살펴보고, 최적의 Kafka 토픽 관리를 위해 언제 어떤 것을 선택해야 하는지에 대한 지침을 제공할 것입니다.

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

Kafka에서 토픽 삭제는 토픽과 관련된 모든 파티션, 데이터, 메타데이터를 Kafka 클러스터에서 완전히 제거하기 위한 직접적이고 즉각적인 조치입니다. 이는 일반적으로 토픽이 쓸모없거나, 오류로 생성되었거나, 시스템 내에서 더 이상 목적을 수행하지 않을 때 사용됩니다.

토픽 삭제 작동 방식

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

삭제 표시: ZooKeeper(또는 KRaft 클러스터의 경우 Kafka Raft 쿼럼)의 토픽 메타데이터가 업데이트되어 삭제 대상으로 표시됩니다.
컨트롤러 조치: Kafka 컨트롤러(특수 역할을 가진 브로커)가 삭제를 조정합니다. 컨트롤러는 다른 브로커들에게 삭제 표시된 토픽의 파티션에 대한 생산 및 소비를 중지하도록 지시합니다.
로그 디렉터리 정리: 삭제된 토픽의 파티션을 호스팅하는 각 브로커는 결국 디스크에서 연결된 로그 세그먼트 및 인덱스 파일을 제거합니다. 이 정리는 즉각적이지 않을 수 있으며, log.cleaner.delete.retention.ms 구성(압축된 토픽에 적용되지만 유예 기간 후 삭제된 토픽의 세그먼트 최종 제거에도 영향을 미침)과 브로커 재시작 동작에 따라 달라질 수 있습니다.

토픽 삭제 활성화

토픽을 삭제하기 전에 모든 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 브로커는 정의된 보존 제한을 초과한 데이터에 대해 토픽 세그먼트를 주기적으로 확인하는 로그 클리너 프로세스를 지속적으로 실행합니다. 주요 보존 구성에는 두 가지가 있습니다.

retention.ms (시간 기반 보존): 이 구성은 Kafka가 로그 세그먼트를 삭제 대상으로 만들기 전에 보존할 최대 시간(밀리초)을 지정합니다. 예를 들어, retention.ms가 604800000(7일)로 설정된 경우 7일보다 오래된 메시지는 모두 제거됩니다.
retention.bytes (크기 기반 보존): 이 구성은 디스크에서 토픽의 파티션이 커질 수 있는 최대 크기(바이트)를 지정하며, 이 크기에 도달하면 공간 확보를 위해 오래된 로그 세그먼트가 삭제됩니다. 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 \n                --create \n                --topic my-event-stream \n                --partitions 3 \n                --replication-factor 1 \n                --config retention.ms=86400000

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

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

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

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

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

토픽 구성 보기

보존 설정을 포함하여 토픽의 현재 구성을 검사할 수 있습니다.

kafka-configs.sh --bootstrap-server localhost:9092 \n                 --entity-type topics \n                 --entity-name my-event-stream \n                 --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 관리자의 툴킷에서 필수적인 도구이지만, 각각 뚜렷한 목적을 수행합니다. 토픽 삭제는 전체 토픽을 즉시 그리고 완전히 제거하기 위한 무딘 도구이며, 쓸모없거나 오류가 있는 토픽에 가장 적합합니다. 반면에 보존 정책은 활성 토픽 내 데이터의 수명 주기를 관리하기 위한 정교하고 자동화된 메커니즘을 제공하며, 리소스 최적화, 데이터 거버넌스 및 시스템 성능 유지에 중요합니다.

각각의 기능적 차이와 적절한 사용 사례를 이해함으로써 Kafka 클러스터를 효과적으로 관리하고, 데이터 위생을 보장하며, 스토리지 오버플로를 방지하고, 강력한 이벤트 스트리밍 인프라를 유지할 수 있습니다. 특히 프로덕션 환경에서는 의도하지 않은 데이터 손실 및 운영 중단을 방지하기 위해 데이터 수명 주기 관리 전략을 항상 신중하게 계획하십시오.