Kafka의 변화: Zookeeper에서 KRaft로

Kafka는 KIP-500에서 Zookeeper를 제외하고 KRaft를 도입하고 Kafka 2.8 버전부터 이를 지원하고 있다. Kafka는 대체 왜 Zookeeper를 버리고 KRaft를 도입하였을까? 그리고 대체 KRaft는 뭘까? 이 아티클을 통해 이를 알아보겠다.

Problem of Zookeeper

  • Zookeeper의 경우에는 Broker ID, Partition, Leader등의 Metadata를 저장한다. 또한 Controller를 지정하게 된다. 이러한 Controller는 Zookeeper에서 정보를 읽고 쓰는 역할을 한다. 또한 다른 브로커에 업데이트된 Metadata를 전달해주는 역할을 한다.

  • Broker Shutdown 문제. Leader 역할을 한 Broker가 Shutdown 되야하는 경우, Controller에 이를 보고하고 Controller는 어떤 토픽/파티션이 있는지 확인하고 Metadata를 업데이트한다. 또한 새 리더를 정하는 절차를 밟는다. 이러한 새 정보가 Zookeeper에 새로 적히고 나면, 브로커를 전부 업데이트하게 된다. 이 Request는 크게 UpdateMetadata와 LeaderAndISR이라 한다. 이 모든게 완료되면 Broker는 Shutdown할 수 있다. Zookeeper와 Broker를 업데이트하는데 Linear하게 시간이 걸리기에 많은 Partition이 있다면 꽤나 오래 걸릴 수 있다.

  • Controller Failover 문제. 이 경우는 Controller가 고장이 나는 경우이다. 컨트롤러가 고장이 나게 되면 주키퍼에서 확인하게 되고, 그러면 브로커 중 하나가 Controller로 승급을 하게 된다. 새 컨트롤러는 Zookeeper로부터 metadata를 받아오게 되고 topic partition data를 update하여 다시 작성하게 된다. 그 이후 다른 브로커에게 전달해준다. 새 Controller가 Zookeeper로부터 정보를 받아오는 동안 Bottleneck이 발생하게 되고 그 동안 아무런 Request도 받지 못한다.

  • 그 외에도 Zookeeper에서 Metadata를 저장할때 용량 문제 등이 있을 수 있고, 업그레이드하거나 Debug할때 복잡하다.

Metadata Propagation

  • Metadata를 모두가 갖고 있자!
  • Broker들이 서로 Metadata를 Replicate한다.
  • Single Controller 대신 여러 Controller로 구분 가능하다.

Primary Backup vs Quorum Replication

  • Primay Backup은 리더 하나가 받고 Follower들이 Write함. 모두가 Write하였을때 Committed되었다고 가정하고 진행한다.
  • Quorum Replication은 절반 이상만이 Write에 성공하기만 하면 된다.
  • Availability와 Replication Latencies를 Trade한다.

KRaft는 Raft Algorithm을 사용한 Quorum Replication이면서 Kafka의 Log utilities를 사용한다.

Leader Election

  • Leader, Voter, Observer. Leader는 기존 Controller 역할을 하게되고, Leader와 Voter가 모여서 Quorum을 이루게 되며 Replicated Log가 일정하도록 보장한다. Observer는 단순히 이를 Replicate해간다.
  • Leader가 없는 상황에서 Voter중 하나는 Epoch를 새롭게 만들고 Leader Candidate이 될 수 있다. 나머지 Voter들은 그렇다면 Leader 자격이 있는지 투표하게 된다. 이 경우, Voter의 로그가 더 길거나, 제공된 기존 Epoch가 자신들의 것보다 더 큰지 확인하고 그렇지않다면 찬성에 투표하게 된다. 만약 찬성이 과반 이상이라면 새로운 리더가 된다. 만약 그렇지 않다면 timeout이 일어나고, 이 과정을 다시 거치게 된다. 이 경우 epoch를 새롭게 다시 판다. 이를 통해 리더가 항상 하나만 존재할 수 있게 한다.

Log Replication

  • Voter는 Leader로 부터 특정 Epoch에서 정보를 Fetch해올 수 있다. 보통의 경우에는 요청을 하고, 그 요청이 Valid하면 Leader로 부터 fetch해오는 형식이다. 그러나 만약 이 과정에서 이전 Leader의 역할을 하는 Voter가 noncommitted된 정보를 갖고 있다면, 문제가 생겼음을 Leader가 인지하고 Error를 전달하면 Voter는 그 부분을 Truncate한다. 그리고 다시 Leader를 통해서 Fetch 해온다.

Push vs Pull based Replication

  • KRaft는 기존 Raft와 다르게 Pull based Replication을 사용한다.
  • Push based는 Fetch하는 Voter들이 Truncate할때 더 많은 Ping pong을 요구한다.
  • Pull based Replication은 Disruptive Server (Leader권한을 잃은지 모르는 Voter들)이 빨리 확인되어 덜 영향이 가게 한다.
  • Pull based Replication은 Begin Epoch라는 API가 따로 필요하다.

Quorum Controller

  • Zookeeper와 달리 이제는 Quorum Controller가 사용된다.
  • 소수의 Broker가 Quourum을 구성하고 거기서 뽑힌 Leader가 Controller 역할을 하게 된다.
  • 이외 Broker들은 Observer로 Metadata를 받아온다.
  • Broker Shutdown의 경우 새 Epoch에 변경 사항 (Partition, Broker 변경 사항)을 Batch하여 반영할 수 있다.
  • Controller Failover의 경우 Voter가 새 Leader를 뽑으면 된다.
  • 실험 결과 Shutdown Time과 Recovery Time이 훨씬 주는 것을 확인 가능하다.

Discussion

  • Similarity with Blockchain