Kafka Controller 알아보기

- 목차

 

들어가며.

카프카는 여러개의 브로커들로 구성됩니다.

브로커의 역할은 토픽을 관리하고, 레코드들을 복제하며, 클라이언트인 Producer 와 Consumer 들과 소통해야합니다.

아래의 이미지는 브로커의 역할을 표현한 그림인데요.

3개의 브로커로 구성된 카프카 클러스터는 1개의 Leader Replica 인 Broker2 와 Follower Replica 인 Broker 1, 3 을 가집니다.

Follower Replica 인 Broker 1 과 Broker 3 은 열심히 Broker 2 의 데이터들을 복제합니다.

Follower Replica 의 큰 역할이 Replication 이기 때문이죠.

그리고 Leader Replica 인 Broker2 는 Client 와 통신하며 데이터를 생성하고 공급합니다.

 

 

여기에 Topic 들을 계속 추가하게 된다면 모든 브로커가 Leader Replica 가 됩니다.

아래의 이미지처럼 Partition 이 3개, Replication Factor 가 3 인 Topic 은 아래와 같이 구성됩니다.

브로커가 3개이고, Partition 이 3개인 경우에는 모든 브로커가 Leader Replica 가 됩니다.

그리고 Replication Factor 가 3이므로 모든 브로커가 각 Partition 의 Follower Replica 가 되죠.

 

 

갑작스럽게 브로커가 종료된다면.

위와 같은 상황에서 카프카 클러스터는 잘 동작합니다.

Partition 의 Leader Broker 가 존재하므로 데이터의 생성과 조회에 아무런 문제가 없습니다.

Partition 의 Follower Broker 또한 존재하므로 아무 이상없이 데이터를 복제합니다.

따라서 데이터의 관리와 데이터의 활용 측면에서 큰 문제가 없죠.

하지만 브로커의 갑작스런 종료와 이에 대한 Fail Over 시에 문제가 발생합니다.

"만약 Leader Replica 가 종료된다면 어떤 Follower Replica 가 이를 대체할 것인가 ?" 에 대한 문제가 가장 큰 화두입니다.

이러한 상황에선 문제 상황을 대처할 수 있는 Orchestrator 또는 Coordinator 가 필요합니다.

그리고 이러한 역할을 수행하는 대상이 바로 Controller 입니다.

이번 글에서는 Controller 에 대해서 알아보는 시간을 가져보려고 합니다.

 

 

 

Controller 이란 무엇인가 ?

먼저 Controller 또한 하나의 카프카 브로커입니다.

즉, 브로커들 중의 한 브로커가 Controller 로 선출됩니다.

그래서 Controller 는 일반적인 브로커의 역할 뿐만 아니라 Controller 로써의 역할 또한 수행합니다.

 

Controller 의 역할은 카프카 클러스터에서 Partition 의 Ownership 을 결정하는 역할을 수행합니다.

즉, 어떤 Broker 가 Partition 의 Leader Replica 또는 Follower Replica 가 될지를 결정합니다.

아래의 그림을 보시죠.

test 라는 이름의 Topic 을 생성하며, Partiiton 과 Replication Factor 는 각각 3개입니다.

토픽의 파티션과 이의 Ownership 의 결정은 Controller 가 결정합니다.

그리고 결정된 Partition Ownership 정보를 토대로 모든 Broker 들은 Topic 과 Partition 의 데이터를 생성합니다.

 

 

Controller 는 이처럼 토픽의 생성과 파티션의 할당을 책임집니다.

 

Leader Replica 가 종료된다면.

만약에 Leader Replica 가 종료되어 Follower Replica 가 새로운 Leader 가 되어야하는 상황이 발생합니다.

이 경우에서도 Controller 가 적절한 Broker 를 Leader Replica 로 선출합니다.

이러한 경우에 보통 In-Sync Replicas 에 설정된 순서대로 Follower Replica 가 Leader Replica 가 된다고 합니다.

simply the next replica in the replica list of that partition

 

아래 이미지처럼 Partition 1 의 Leader Replica 인 Broker 2 가 종료된다면,

Broker 3 이 Partition 1 의 새로운 Leader Replica 가 됩니다.

 

 

 

Controller 는 어떻게 선출될까 ?

Controller 는 선착순으로 결정됩니다.

제일 먼저 실행되는 브로커가 Controller 가 됩니다.

이 과정에서 ZooKeeper 와 Kafka Broker 간의 상호작용이 발생하는데요.

Controller 이 어떻게 선출되는지 설명하기에 앞서 간단한 ZooKeeper 에 대한 배경지식을 설명하도록 하겠습니다.

 

ZooKeeper Znode 와 Watch 란 ?

https://westlife0615.tistory.com/484

Zookeeper Znode 알아보기

https://westlife0615.tistory.com/485

Zookeeper Watch Mechanism 알아보기

 

위 두 링크는 ZooKeeper 의 Znode 와 Watch 방식에 대한 글이며,

자세한 설명은 위 링크를 통해서 살펴보시는 것을 추천합니다.

간단히 Znode 에 대해서 설명해보자면,

Znode 는 Tree 구조로 데이터들을 관리합니다.

카프카 클러스터에서 저장하는 Znode 의 구조를 살펴보면,

아래와 같은 형태로 Znode 들이 존재합니다.

FileSystem 과 같은 형식으로 Znode 들이 관리된다고 생각하시면 좋을 듯합니다.

# zookeeper-shell localhost:2181 ls /brokers/ids/1
/
/admin
/brokers
/cluster
/config
/consumers
/controller
/controller_epoch
/feature
/isr_change_notification
/latest_producer_id_block
/log_dir_event_notification
/zookeeper
/admin/delete_topics
/brokers/ids
/brokers/seqid
/brokers/topics
/brokers/ids/1
/brokers/ids/2
/brokers/ids/3
/brokers/topics/__consumer_offsets
/brokers/topics/auto-offset-reset
/brokers/topics/nums

 

그리고 /brokers/ids/1 라는 Znode 의 데이터를 살펴보겠습니다.

이는 1번 브로커의 상세 정보를 나타냅니다.

# zookeeper-shell localhost:2181 get /brokers/ids/1
{
  "features":{},
  "listener_security_protocol_map":{"INTERNAL":"PLAINTEXT","EXTERNAL":"PLAINTEXT"},
  "endpoints":["INTERNAL://kafka1:9092","EXTERNAL://localhost:29091"],
  "jmx_port":-1,
  "port":9092,
  "host":"kafka1",
  "version":5,
  "timestamp":"1705164870389"
}

 

위와 같은 방식으로 Kafka 는 Kafka Cluster 의 상태 정보를 ZooKeeper 에 저장하게 됩니다.

 

그리고 Watch Mechanism 은 Znode 의 상태가 변경될 때, 변경에 따른 알림을 받을 수 있는 구조입니다.

만약, Broker 1, 2, 3 이 /controller Znode 의 Watcher 라고 한다면, /controller Znode 가 변경될 때에

Broker 1, 2, 3 는 변경에 대한 알림을 받을 수 있습니다.

 

Controller Election 과 ZooKeeper 의 상호작용에 대해서.

이제 본격적으로 Controller Election 에 대해서 알아보겠습니다.

Controller Election 은 선착순이라고 말씀드렸습니다.

먼저 시작한 Broker 가 Controller 가 되는데요.

구체적으로는 Broker 의 실행 과정에서 "/controller"  Znode 를 생성하는 과정이 포함됩니다.

그래서 Broker 가 시작되면, ZooKeeper 의 "/controller"  Znode 를 생성하게 됩니다.

아래는 생성된 "/controller"  Znode 의 데이터입니다.

2 번 브로커가 가장 먼저 실행되었고, 따라서 Controller 가 되었습니다.

 

# zookeeper-shell localhost:2181 get /controller
{
  "version":2,
  "brokerid":2,
  "kraftControllerEpoch":-1
}

 

그리고 뒤따라 실행된 브로커들도 "/controller"  Znode 를 생성하려고 하지만 이미 "/controller"  Znode 는 생성된 상태입니다.

이 상황에서 다른 브로커들은 "/controller"  Znode 의 Watcher 가 됩니다.

만약 Controller 인 Broker 2 가 갑작스럽게 종료되어 "/controller"  Znode 의 상태가 변경되는 경우에

새로운 Controller 되기 위해 Watcher 가 되어야합니다.

 

 

"/controller"  Znode 의 값도 brokerid 2 -> brokerid : 1 로 변경됩니다.

# zookeeper-shell localhost:2181 get /controller
{
  "version":2,
  "brokerid":1,
  "kraftControllerEpoch":-1
}

 

 

실제 카프카 환경에서도 2번 브로커가 종료되면, 그에 따른 Leader Replica 가 변경됩니다.