파티션 분산(이동) 테스트
부하 분산이 목적인 경우에 브로커만 추가했다고 끝나는 것이 아니라 새롭게 추가된 브로커에도 기존의 파티션들을 할당 해야 함
(클러스터링 테스트 사전작업1)
3node 환경에서 4partition 1replication factor 토픽을 만들게 될 경우
참고) partition이 하나 더 생기는 broker는 랜덤
(클러스터링 테스트 사전작업2 - 브로커 추가 및 백업)
4node 환경으로 만든 다음, topic2를 추가했을 때 상황
- 3node상태에서 만들었던 topic의 partition 위치는 변함X
(클러스터링 테스트1)
1. 브로커 부하 분산을 위해 partitions을 고르게 분산
- 해당 json 포맷에는 분산시킬 대상 토픽을 추가해 작성.
작성 후, reassign-partitions-topic.json 으로 저장
| {"topics": [{"topic":"r1p4-topic"}], "version":1 } |
참고) 분산시킬 토픽이 여러개일 경우, 콤마 (,) 구분자를 사용해 토픽 추가하면 됨 (파티션을 이동하는 작업도 replication 작업이라 부하가 되어 여러 topic을 사용하는 것은 지양)
| {"topics": [{"topic":"r1p4-topic-1"}, {"topic":"r1p4-topic-2"} ], "version":1 } |
2. 분산시킬 대상 토픽에 대한 json 파일 생성 후, kafka-reassign-partitions.sh명령어를 이용해 파티션을 분산시킬 브로커 리스트를 지정함
- 1,2,3,4 브로커 모두에게 분산할 경우
명령어 생성 옵션 topic partition 분산 옵션 브로커 지정 옵션
$> bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --generate --topics-to-move-json-file /kafka/src/reassign-partitions-topic.json --broker-list "1,2,3,4"
3. 제안하는 파티션 배치가 출력된 후, 복사하여 새로운 move.json 파일 생성
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"r1p4-topic","partition":0,"replicas":[3],"log_dirs":["any"]},{"topic":"r1p4-topic","partition":1,"replicas":[4],"log_dirs":["any"]},{"topic":"r1p4-topic","partition":2,"replicas":[1],"log_dirs":["any"]},{"topic":"r1p4-topic","partition":3,"replicas":[2],"log_dirs":["any"]}]}
4. 토픽 파티션 배치 실행
$>bin/kafka-reassign-partitions.sh --bootstrap-server broker1:9092 reassign-json-file /kafka/src/move.json --excute
5. 브로커에 고르게 배치됐는지 확인
$> bin/kafka-topic.sh --bootstrap-server broker1:9092 --describe --topic test01
파티션 재배치 이후 상태 )
결론 : 기존 클러스터에 브로커 추가 시, 기존 브로커들이 갖고 있던 파티션들은 자동으로 분산되지 않음
즉, 브로커 추가될 때마다 수동 분산 작업이 필요함.
또한 추가한 broker는 consumer offsets이 생성되지 않기때문에 conusmer offsets도 동시에 늘려줘야 함
배치 확인 후 데이터 정상적으로 받는 지 확인 도중, broker 4에만 __consumer_offsets partition이 생기지 않음 확인
(브로커4대인 상태에서 새로운 토픽 생성하여 데이터 전송 후, 취득하여도 consumer offset partition 이 생기지 않음
따라서, broker 를 추가할 시,partition을 이동하고 싶은 topic과 더불어 __consumer_offsets topic도 함께 분산 작업 이행해야 함)
클러스터링 테스트2 - partition 과 replication factor 조정을 동시에 할 수 있는지 확인
6. 분산시킬 대상 토픽에 대한 json 파일 생성 후, kafka-reassign-partitions.sh명령어를 이용해 replication factor를 조정함
- 토픽 파티션 배치 실행하는 명령어 및 옵션과 동일함
- 결과 : 불가
- 에러 문구 : Partition replica lists may not contain duplicate entries: r1p4-test02-2 contains multiple entries for 3
org.apache.kafka.server.common.AdminCommandFailedException: Partition replica lists may not con - 파티션 복제본 목록에 중복된 항목이 포함되지 않을 수 있습니다. r1p4-test02-2에 3에 대한 여러 항목이 포함되어 있습니다
org.apache.kafka.server.common.Admin CommandFailedException: 파티션 복제본 목록이 동기화되지 않을 수 있습니다 - 결론 : topic의 파티션 이동과 replication factor를 조정하는 명령어 및 json파일은 같지만 동시에 할 수 없음 (파티션을 먼저 늘리고 replication factor를 적용해야 함
명령어
$> bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 --reassignment-json-file /kafka/src/rp_move.json --execute (replication factor 증량 명령어)
최종 결론 및 의견 : partition 을 분산(이동)할 경우 json파일을 통해 옮겨야 하며, 제안해주는 configuration을 복사하여 이동할 수는 있으나 기동되고 있는 partition의 리더기점으로 제안해주지않고 랜덤 브로커 번호로 지정해주기 때문에 부하가 발생할 수 있음
따라서 제안해주는 configuration을 그대로 복사해오는 것보다 topic 의 describe를 이용해 각 partition 마다 leader는 변동되지 않도록 확인하며 partition을 이동하는 것이 좋다고 생각함
예상외로 브로커 증설 작업 후 파티션 분산 작업이 수동적이라 스크립트 작성해 볼 예정
[kafka@rocky-web01 bin]$ ./kafka-topics.sh --bootstrap-server broker3:9092 --topic r1p4-topic --describe
Topic: r1p4-topic TopicId: 7p4uoGCUQd6_vqpQgwhCtg PartitionCount: 4 ReplicationFactor: 1 Configs: min.insync.replicas=2,segment.bytes=209715200,retention.bytes=3221225472
Topic: r1p4-topic Partition: 0 Leader: 1 Replicas: 1 Isr: 1
Topic: r1p4-topic Partition: 1 Leader: 2 Replicas: 2 Isr: 2
Topic: r1p4-topic Partition: 2 Leader: 3 Replicas: 3 Isr: 3
Topic: r1p4-topic Partition: 3 Leader: 1 Replicas: 1 Isr: 1
추가 240722)
json 파일에 모든 partition 을 지정하지 않고 하나의 partition만 지정하더라도 partition 의 leader와 replicas를 변동할 수 있는 것을 확인함
그러므로 전체 partition 을 바꾸지않아도 하나의 partition만 지정해도 이동이 가능하며, replication factor 또한 조정할 수 있음
다만 아래와 이미 같은 토픽의 다른 partition의 리더 브로커를 맡고있을 경우 (partition 0만 수정한 상태)
Topic: r1p4-test02 TopicId: maY_FBYgSQOF-_roVVeJcw PartitionCount: 4 ReplicationFactor: 3 Configs: min.insync.replicas=2
Topic: r1p4-test02 Partition: 0 Leader: 1 Replicas: 2,1,3 Isr: 1,2,3 (정책상 replicas 맨 앞번호는 항상 리더이다)
Topic: r1p4-test02 Partition: 1 Leader: 2 Replicas: 2,1,3,4 Isr: 2,1,3,4
Topic: r1p4-test02 Partition: 2 Leader: 3 Replicas: 3,1,2,4 Isr: 3,4,2,1
Topic: r1p4-test02 Partition: 3 Leader: 4 Replicas: 4,1,2,3 Isr: 4,3,1,2
리더 선임은 불가할 수 있다. 따라서 각 partition 의 리더를 확인하여 replicas 를 작성 해야 함
kafka data확인 시 , json 파일 적용했을 경우 실제로 data가 삭제되는 것을 확인함
결론 : partition 개별로 replicas를 관리하는 것은 가능하지만 기존 partition의 leader를 잘 확인하고 부하를 주지 않는 선에서 변경해야 함.
Topic: r1p4-test02 TopicId: maY_FBYgSQOF-_roVVeJcw PartitionCount: 4 ReplicationFactor: 1 Configs: min.insync.replicas=2
Topic: r1p4-test02 Partition: 0 Leader: 4 Replicas: 4 Isr: 4
Topic: r1p4-test02 Partition: 1 Leader: 2 Replicas: 2,1,3,4 Isr: 2,1,3,4
Topic: r1p4-test02 Partition: 2 Leader: 3 Replicas: 3,1,2,4 Isr: 3,4,2,1
Topic: r1p4-test02 Partition: 3 Leader: 4 Replicas: 4,1,2,3 Isr: 4,3,1,2
partition 하나만 적용하는 방법 :
ex) 원하는 partition에 replicas를 수정 (단 replicas 맨 앞자리는 leader broker를 의미함)
| {"version":1,"partitions":[{"topic":"r1p4-test02","partition":0,"replicas":[4]}]} |
*분산 배치 작업 시 주의사항
1. 카프카 샤용량이 낮은 시간에 진행할 것 (브로커 내부적으로 리플리케이션하는 동작이 일어나기 때문)
2. 용량이 큰 토픽의 파티션을 재배치 할 경우,
최근의 내용까지 모두 컨슘했고 앞으로 재 처리 할 일이 없다면 최근 메시지를 제외한 나머지 메시지들은 모두 삭제해도 무방함
-> 임시로 해당 토픽의 보관주기를 1주일에서 1일로 변경한다면 700G였던 파티션의 크기는 100G로 줄어들 것이고 파티션의 크기를 줄이고 난 후 재배치 작업을 진행한다면 기존 대비 브로커 부하나 네트워크 사용량 절감
3. 파티션 재배치 작업 시 여러 개의 토픽을 동시에 진행하지 않고, 단 하나의 토픽만 진행해야 함
출처) 실전 카프카 개발부터 운영까지