Kafka에서 Topic을 생성할 때, 두 가지 주요한 설정을 할 수 있습니다.
바로 ReplicationFactor와 PartitionCount입니다.
./bin/kafka-topics.sh --create --bootstrap-server BootstrapServerString --command-config client.properties --replication-factor 3 --partitions 4 --topic TestTopic
ReplicationFactor는 Topic의 Partition을 몇 개의 Broker에 복제할 것인지를 결정합니다.
Partition을 복제함으로써 Message 처리의 안정성을 높일 수 있습니다.
Partition은 Topic의 데이터 레코드를 물리적으로 분리하여, 여러 Broker에 분산해서 저장하고 처리하는 단위입니다.
Partition을 늘리면 데이터를 분산해서 병렬로 빠른 처리가 가능합니다.
kafka-topic.sh --describe
명령어로 현재 Kafka의 설정 값을 확인할 수 있습니다.
./bin/kafka-topics.sh --describe --bootstrap-server BootstrapServerString --command-config client.properties --topic TestTopic
아래는 Broker 4개, Partition 4개일 경우입니다.
Leader와 Replica는 랜덤으로 설정됩니다.
Topic: TestTopic PartitionCount: 4 ReplicationFactor: 3 Configs: Topic: TestTopic Partition:0 Leader: 2 Replica:1,4 Isr: 1,4 Topic: TestTopic Partition:1 Leader: 1 Replica:4,2 Isr: 4,2 Topic: TestTopic Partition:2 Leader: 3 Replica:2,1 Isr: 2,1 Topic: TestTopic Partition:3 Leader: 4 Replica:3,2 Isr: 3,2
참고로 Isr은 In Sync Replica
의 약어로 Partition의 Replica 설정을 나타냅니다.
ReplicationFactor는 일반적으로 고가용성을 유지하기 위해 3개를 설정합니다.
그러면 Broker 하나에 장애가 발생해도 나머지 두 개의 복제본을 통해 데이터 손실을 방지할 수 있습니다.
물론 더 높은 안정성이 필요하면 복제본을 추가할 수도 있습니다.
하지만 그만큼 데이터 용량과 네트워크 대역폭을 더 사용하게 됩니다.
거기에 Broker 간에 데이터 복제 시간이 추가로 소요됩니다.
이는 관리 복잡도와 운영 비용 증가로 이어집니다.
따라서 서비스 규모나 형태에 맞는 설정이 필요합니다.
PartitionCount는 일반적으로 Consumer 개수와 일치시킵니다.
Partition에는 하나의 Consumer만 연결할 수 있기 때문입니다.
참고로 Topic에는 Consumer Group이 지정됩니다.
그리고 Consumer Group에는 여러 Consumer들이 속해서 메시지를 분산처리합니다.
물론 Partition 개수를 늘려서 Consumer가 여러 Partition의 데이터를 소비할 수도 있습니다.
이때는 Consumer의 메시지 병렬 처리 성능이 보장되어야 합니다.
그렇지 않으면 1대1 구조가 가장 이상적입니다.
Partion이 늘어난만큼 Consumer를 늘려주면 됩니다.
참고로 Partition : Consumer = 1 : 1 Or N : 1
구조가 가능합니다.
Partition에 Consumer를 중복할당 할수는 없습니다.
그리고 Procuder 메시지 생산량이나 Broker 성능도 고려 대상입니다.
하지만 가장 중요한 건 최종 소비를 담당하는 Consumer 성능입니다.