kafka partition, replication(ISR)

Why Kafka?

Multiple Producers/Consumers. 하나의 topic에 대하여 여러 Producers 가 message 를 전송하고 여러 Consumers 가 message 를 소비하는 구조로 주아앙 집중형 구조로 구성
Disk-Based Retention
. 다른 message system과 틀리게 일정 기간동안 디스크에 message를 저장 -> 메시지의 손실을 방지
Scalable
. kafka cluster를 통하여 확장이 매우 용이 하게 설계
High Performance
. 분산처리 - 동일한 기능을 하는 여러대의 서버로 이뤄진 분산 시스템으로 구성되어, 단일 시스템보다 더 높은 성능을 얻으며, SPOF 극복
. 배치 처리 - 작은 i/o 에 대하여 묶어서 처리 하여 속도 향상에 도움
. 페이지 캐시 - 파일시스템에 쓰기전에 페이지캐시를 통하여 높은 속도 보장(실제로 하드웨어 권고 사항에 sata disk를 사용해도 무방하다고 함)

Kafka component

broker : kafka application 이 설치 되어 있는 노드
topic : message를 구분 하기 위해서 사용 하는 이름
procuder : message를 브로커의 topic으로 전송하는 서버나 application
consumer : broker의 topic 에서 저장된 message를 가져오는 서버나 application

Kafka partition

producer 가 message 를 전송 할 때 1개의 topic으로 partitioning 이 안되어 있나면 1개의 message를 낼 때 1초가 걸린다면 3개의 message를 보낼때 3초가 소요 된다.

partitioning 된다면 동일한 작업에 대하여 partition 갯수에 비례 하여 처리 속도가 향상 된다.

partition 은 topic을 생성할때 --partitions 옵션을 통하여 구성 할 수 있다.

Create topin partitions

# /opt/kafka/bin/kafka-topics.sh --create --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:2181 --replication-factor 1 --partitions 3 --topic part

partition 을 3개로 생성 하여 아래와 같이 3개의 partition이 생성 된 걸을 확인 할 수 있다.

Topic list

# /opt/kafka/bin/kafka-topics.sh --describe --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:218
 
Topic:part PartitionCount:3 ReplicationFactor:1 Configs:
Topic: part Partition: 0 Leader: 1 Replicas: 1Isr: 1
Topic: part Partition: 1 Leader: 2 Replicas: 2Isr: 2
Topic: part Partition: 2 Leader: 3 Replicas: 3Isr: 3

만약 운영중 partition 을 더 추가해야 할 경우가 있을 수 있다. 그럴경우 --alter 옵션을 통하여 변경 가능 하다.
partition을 추가 할 경우 message순서에 영향이 있을 수 있다는 경고 와 함께 partition이 추가 되는 것을 확인 할 수 있다.
( partition 을 무조건 증가 했다고 전체 처리 성능이 증가 하는 것은 아니며, 그만큼 consumer가 추가 되어야 한다 . 또한 추가만 가능 하며, 줄일 수는 없다.)

partitions 추가

# /opt/kafka/bin/kafka-topics.sh  --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:2181 --alter --partitions 4  --topic part
WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected
Adding partitions succeeded!
 
 
# /opt/kafka/bin/kafka-topics.sh --describe --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:218
Topic:part  PartitionCount:4    ReplicationFactor:1 Configs:
    Topic: part Partition: 0    Leader: 1   Replicas: 1Isr: 1
    Topic: part Partition: 1    Leader: 2   Replicas: 2Isr: 2
    Topic: part Partition: 2    Leader: 3   Replicas: 3Isr: 3
    Topic: part Partition: 3    Leader: 1   Replicas: 1Isr: 1

partition은 장점과 함께 단점이 있으니 처음부터 많은 partitioning 을 하는 것 보다, 적은 수의 partition을 생성하고 추가 하는 방식으로 가는 것이 좋으며, kafka 에서는 broker당 2,000 개의 최대 partion을 권고 하고 있다.
너무 많은 partion 은 장애시간만 증가 시키는 단점이 있음

Kafka replication

고가용성을 위하여 topic에 대한 replication(복제) 기능을 제공 하고 있으며 아래와 같이 --replication-factor 라는 옵션을 통하여 replication 갯수를 지정 하여 topic을 생성 할 수 있다.
아래 repl 이라는 topic을 1 개의 partition으로 2개의 replication으로 생성 했는데 , Leader와 replicas를 확인 해야 한다.

Topic list

# /opt/kafka/bin/kafka-topics.sh --create --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:2181 --replication-factor 2 --partitions 1 --topic repl
Created topic "repl".
 
#  /opt/kafka/bin/kafka-topics.sh --describe --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:218
 
Topic:repl  PartitionCount:1    ReplicationFactor:2 Configs:
    Topic: repl Partition: 0    Leader: 2   Replicas: 2,3   Isr: 2,3

kafka cluster 는 replication을 할 경우 broker들 간에 leader를 우선 선출 한다. 이때 선출된 leader는 모든 Read/Write 가 발생한다.

Leader는 follower라는 replication 대상으로 message를 replication 하는 방식으로 고가용성을 보장 할 수 있도록 한다.

만약 Leader가 장애 발생된다면. 아래 처럼 다른 follower가 Leader로 승격 한다.(장애 복구시 원래 Leader가 다시 Leader로 승격 되지 않으며, Leader 장애시에만 승격된다.

# /opt/kafka/bin/kafka-server-stop.sh
 
 
# /opt/kafka/bin/kafka-topics.sh --describe --zookeeper kafka-01:2181,kafka-02:2181,kafka-03:2181  
Topic:repl  PartitionCount:1    ReplicationFactor:2 Configs:
    Topic: repl Partition: 0    Leader: 3   Replicas: 2,3   Isr: 3

그렇다면 Leader와 Follower선출과 데이터의 무결성을 어떻게 처리 할까 ? kafka 에서는 ISR( In Sync Replic) 이라는 개념으로 통하여 이를 해결 하였다.
ISR은 replication group 이라고 할 수 있는데, replication factor 3으로 설정 되어 있을 경우 아래 처럼 특정 broker가 leader 나머지 broker가 follewer가 된다.
여기서 message가 leader로 전송이 지속적으로 되는 상태에서 , follewer는 지속 적으로 변경사항을 요청한다. 그리고 Leader 가 변경 사항을 전달하는 Pull방식으로replication이 된다.