Konsensus w systemie rozproszonym Kafki z algorytmem KRaft

Rola kontrolera w klastrze Kafki

W ekosystemie Apache Kafka kontroler jest jednym z najważniejszych komponentów, pełniącym funkcję „mózgu” klastra. Jest to broker, który odpowiada za monitorowanie stanu wszystkich pozostałych węzłów i zarządzanie metadanymi klastra, jest w danym klastrze źródłem prawdy. Do jego zadań należą: procesowanie żądania tworzenia, usuwania oraz zmiany konfiguracji topiców (np. zwiększanie liczby partycji) oraz obsługa replikacji danych.

Głównym zadaniem kontrolera jest przeprowadzanie elekcji liderów dla partycji topiców w sytuacjach, gdy dotychczasowy lider ulegnie awarii, lub gdy ma zostać wyłączony.

Konsensus w systemie rozproszonym, czyli po co Kafce ZooKeeper?

Konsensus jest fundamentalnym problemem w systemach rozproszonych, w których wiele oddziałujących na siebie komponentów musi uzgodnić stan systemu. Algorytmy konsensusu powinny być zaprojektowane tak, aby umożliwić grupie rozproszonych jednostek współpracę jako spójna grupa, nawet w przypadku awarii i przerw w działaniu. W Kafce problemem konsensusu jest wybór dokładnie jednego brokera, który w danym momencie będzie sprawował rolę kontrolera w klastrze.

Kafka do wersji 3.3 problem konsensusu rozwiązywała przy pomocy ZooKepera, a mechanizm wyboru kontrolera działał na zasadzie „kto pierwszy, ten lepszy”. Jeśli kontroler padł, proces wyboru zaczynał się od nowa, co przy tysiącach partycji mogło trwać sekundy, a nawet minuty.

Przejście Kafki z Zookepera na KRaft

W KRaft mamy do czynienia z kworum kontrolerów. To grupa kontrolerów, którzy wspólnie decydują o stanie klastra, korzystając z algorytmu konsensusu, aby zapewnić spójność i szybkość działania. Wybór lidera odbywa się za pomocą algorytmu Raft. Jeden z węzłów pełni rolę lidera, a pozostałe to kontrolerzy oczekujący (potencjalni następcy). Stan metadanych nie leży w ZooKeeperze, lecz jest replikowany między kilkoma kontrolerami wewnątrz samej Kafki. Ponieważ „zmiennicy” są już znani i zsynchronizowani, przejęcie roli lidera po awarii następuje niemal natychmiastowo.

W modelu kworum metadane klastra są traktowane jak zwykły topic w Kafce, ale o charakterze wewnętrznym. Każda zmiana to nowy wpis w logu topicu __cluster_metadata. Brokerzy nie muszą już odpytywać kontrolera, oni sami subskrybują ten dziennik metadanych i aktualizują swoją wiedzę o klastrze na bieżąco.

Dzięki przejściu na KRaft, Kafka zyskała kilka kluczowych usprawnień, takich jak obsługa milionów partycji w jednym klastrze (wcześniej limit oscylował wokół 200 tysięcy), czy szybszy restart klastra, dzięki zapisywaniu staniu klastra w lokalnym logu.

Uruchamianie Kafki z KRaftem

Uruchomienie Kafki z KRaftem nieznacznie różni się od tego z Zookeperem. Pierwszą rzeczą, jaką musimy wykonać, jest wygenerowanie UUID dla klastra:

$ KAFKA_CLUSTER_ID="$(bin/kafka-storage.sh random-uuid)"

UUID jest potrzebne do wykonania kolejnego kroku, sformatowania katalogu logów:

$ bin/kafka-storage.sh format --standalone -t $KAFKA_CLUSTER_ID -c config/server.properties

W tym momencie mamy już gotową konfigurację, możemy uruchomić serwer Kafki. Nie potrzebujemy uruchamiać żadnego dodatkowego serwisu, wystarczy jedno okno terminala.

Zmiany w konfiguracji

Zmianie uległa także konfiguracja pliku server.properties, głownie w części Server Basics, doszła też dodatkowa konfiguracja w części socketowej związana z kontrolerami.

############################# Server Basics #############################

# The role of this server. Setting this puts us in KRaft mode
process.roles=broker,controller

# The node id associated with this instance's roles
node.id=1

# The connect string for the controller quorum
controller.quorum.voters=1@localhost:9093

process.roles – broker | controller | broker,controller – KRaft wspiera dwa rodzaje deploymentu – mieszany (combined) i izolowany (isolated). Mieszany jest podobny do działania w ZooKeeperze, gdzie broker może jednocześnie działać jako standardowy broker oraz kontroler w jednym (dobry dla małych klastrów, środowisk testowych). Deployment izolowany to taki, w którym kontrolerzy nie pełnią żadnej innej roli (rekomendowany na produkcji).

node.id – zastępuje parametr broker.id ze starej konfiguracji. Każdy węzeł w klastrze (zarówno broker, jak i kontroler) musi mieć unikalny identyfikator numeryczny.

controller.quorum.voters – lista kontrolerów w formacie id@host:port. To dzięki temu brokerzy wiedzą, gdzie szukać źródła prawdy o klastrze. Zazwyczaj zalecana liczba to 3 lub 5 węzłów pełniących rolę kontrolerów.

W częsci socketowej najważniejsza zmiana to dodanie portu 9093 do wewnętrznej komunikacji kworum kontrolerów.

Podsumowanie

Przejście Kafki z Zookeepera na KRaft to jedna z największych zmian w architekturze tego systemu od lat. Nowy sposób zarządzania metadanymi klastra znacznie poprawił jego wydajność, co pozwoliło zwiększyć liczbę obsługiwanych partycji do milionów. Kafka zyskała zwiększoną stabilność, łatwiej ją monitorować i zarządzać. A to wszystko przy stosunkowo niewielkich zmianach dla użytkowników.

Źródła

https://kafka.apache.org/
https://highscalability.com/untitled-2/
https://developer.confluent.io/learn/kraft/