소개
토픽은 생산자에게 전달하는 이름 이상의 의미가 있습니다. 파티션은 이벤트 로그를 구성하고 복제본은 저장 사본을 나타내며 보존 설정은 저장 기록을 얼마나 오래 유지 대상으로 둘지 정합니다. 읽기 진행 상태는 소비자에 속하는 별도 관심사입니다.
토픽 두 개를 만들고 메타데이터를 확인하며 각각 명시적 보존 정책을 설정한 뒤 하나만 바꿉니다. 실제 삭제를 기다리거나 브로커 전체 구성을 바꾸지 않고 토픽별 재정의의 의미를 분리해 확인합니다.
준비된 단일 브로커가 실행 중이며 두 토픽 이름은 이전 실습과 독립적입니다. 기본 터미널 사용법이면 충분하고 Python이나 Java 프로그래밍은 필요하지 않습니다. 브로커 한 대의 학습 환경에는 복제본 하나가 적절합니다. 터미널을 사용하세요.
두 토픽을 만들고 메타데이터 읽기
이 단계에서는 명시적인 두 파티션 수를 비교합니다. 작업 공간에서 시작합니다.
cd /home/labex/project
--bootstrap-server는 준비된 브로커 주소를 제공합니다. orders-retained는 파티션 둘, orders-control은 하나로 만듭니다. 환경에 브로커가 한 대이므로 둘 다 복제본 하나를 사용합니다.
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-retained --partitions 2 --replication-factor 1
kafka-topics.sh --bootstrap-server localhost:9092 --create --topic orders-control --partitions 1 --replication-factor 1
토픽을 나열하고 각 설명을 저장합니다. 셸의 >는 로컬 파일을 만들거나 기존 내용을 바꿉니다.
kafka-topics.sh --bootstrap-server localhost:9092 --list
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained > /home/labex/project/output/orders-retained-description.txt
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-control > /home/labex/project/output/orders-control-description.txt
cat /home/labex/project/output/orders-retained-description.txt
cat /home/labex/project/output/orders-control-description.txt
PartitionCount: 2와 1의 차이 및 둘 다 ReplicationFactor: 1인 것을 찾으세요. 각 파티션에 리더 항목이 있습니다. 리더 브로커 식별자는 파티션 수가 아니며 파티션 둘이 브로커 컴퓨터 두 대를 뜻하지 않습니다.
토픽에는 같은 브로커의 파티션 여러 개가 있을 수 있습니다. 복제 계수는 소비자마다 별도의 사본 수가 아니라 브로커들에 걸친 각 파티션의 사본을 설명합니다. 다음에는 이 두 속성을 바꾸지 않고 저장 보존을 변경합니다.
각 토픽에 명시적 하루 보존 재정의 설정하기
이 단계에서는 상속한 기본값과 토픽별 설정을 구분합니다. kafka-configs.sh는 구성 자원을 관리합니다. --entity-type topics는 토픽 자원을, --entity-name은 영향을 받을 토픽 하나를 선택합니다. --describe는 보통 토픽 재정의를 보여줍니다. 재정의가 없다고 브로커 기본값도 없다는 뜻은 아닙니다.
변경 전에 retained 토픽을 확인합니다.
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe
retention.ms는 밀리초 단위 기간입니다. 하루는 24 × 60 × 60 × 1000 = 86400000밀리초입니다. --alter --add-config는 해당 이름의 재정의를 설정합니다. 두 토픽 각각에 같은 명시적 정책을 설정합니다.
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=86400000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --alter --add-config retention.ms=86400000
실제 재정의를 읽고 관찰을 저장합니다.
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-one-day-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-one-day-config.txt
cat /home/labex/project/output/retained-one-day-config.txt
cat /home/labex/project/output/control-one-day-config.txt
각 토픽의 retention.ms=86400000을 찾으세요. 클라이언트는 설정 출처나 민감성 세부 정보도 출력할 수 있으며 세부 정보와 형식은 달라질 수 있습니다.
보존은 브로커 저장 정책이며 소비자가 읽자마자 기록을 지우라는 지시가 아닙니다. 기록의 나이와 로그 세그먼트 정리 방식이 삭제 대상과 시점을 결정합니다. 기간은 특정 메시지가 정확한 순간에 사라진다는 약속이 아닙니다. 이번 연습은 정리를 기다리는 대신 설정한 재정의를 검사합니다.
토픽 하나만 바꾸고 범위 확인하기
이 단계에서는 orders-retained를 이틀로 바꾸고 orders-control은 하루로 유지합니다. 어떤 메타데이터가 바뀔지 예상하세요. retained 토픽의 보존 재정의만 바뀌며 두 파티션 수와 복제 계수는 같습니다.
이틀은 172800000밀리초입니다. 이 값을 지정한 retained 토픽에만 적용합니다.
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --alter --add-config retention.ms=172800000
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-retained --describe > /home/labex/project/output/retained-final-config.txt
kafka-configs.sh --bootstrap-server localhost:9092 --entity-type topics --entity-name orders-control --describe > /home/labex/project/output/control-final-config.txt
cat /home/labex/project/output/retained-final-config.txt
cat /home/labex/project/output/control-final-config.txt
orders-retained에는 retention.ms=172800000, orders-control에는 retention.ms=86400000이 예상됩니다. 브로커 주소가 같아도 토픽 재정의가 전역 설정이 되지는 않습니다.
retained 토픽을 다시 설명합니다.
kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic orders-retained
여전히 파티션 둘과 복제본 하나여야 합니다. 보존 변경은 새 토픽을 만들거나 파티션을 더하거나 소비 진행 상태를 복사하거나 이벤트를 소비하지 않았습니다. 의도한 변경과 영향받지 않은 이웃 토픽을 모두 검증했습니다. 다음에는 키로 주문 식별자를 파티션과 연결합니다.
요약
명시적인 파티션과 복제본으로 토픽을 만들고 메타데이터를 확인했으며 밀리초 단위 보존 재정의를 적용했습니다. 한 토픽을 바꿔도 다른 토픽은 유지되어 토픽 저장 정책과 소비 진행 상태를 구분했습니다. 다음에는 키로 관련 이벤트를 전달하고 파티션 내부 오프셋을 확인합니다.
