Najważniejsze funkcje Confluent Platform w porównaniu do open-source Apache Kafka

Apache Kafka jest jedną z najczęściej wykorzystywanych platform open source do przetwarzania strumieni danych na świecie, a jej szerokie możliwości doceniło wiele firm z listy Fortune 100. Kafka powstała jako projekt open source, ale bardzo szybko znalazła zastosowanie również w środowiskach korporacyjnych i regulowanych, gdzie kluczowe są bezpieczeństwo, niezawodność i łatwość operacyjna.

Confluent Platform bazuje na Apache Kafka i rozszerza ją o zestaw funkcji klasy enterprise, których celem jest uproszczenie operacji, poprawa bezpieczeństwa oraz wsparcie złożonych scenariuszy produkcyjnych. W kontekście przejęcia Confluent przez IBM, zainteresowanie różnicami pomiędzy Kafka a Confluent Platform z pewnością będzie rosło.

W tym artykule porównujemy najważniejsze funkcje Confluent Platform, które nie są dostępne w open source Apache Kafka, skupiając się na aspektach kluczowych dla środowisk produkcyjnych.

Audit Logs (logi audytowe)

W wielu organizacjach – szczególnie w sektorach regulowanych, takich jak finanse, ochrona zdrowia czy administracja publiczna – działy bezpieczeństwa wymagają szczegółowych logów audytowych. Są one niezbędne do spełnienia wymogów regulacyjnych, analizy incydentów oraz audytów bezpieczeństwa.

Open source Apache Kafka nie oferuje wbudowanego mechanizmu audit logów. Choć można próbować realizować audyt za pomocą logów brokerów lub własnych implementacji klas autoryzujących, rozwiązania te są zwykle niekompletne i trudne w utrzymaniu.

Confluent Platform udostępnia Audit Logs poprzez dedykowany authorizer bezpieczeństwa, włączany odpowiednią konfiguracją. Zdarzenia autoryzacyjne (np. przyznanie lub odmowa dostępu) są zapisywane bezpośrednio do osobnego tematu (topicu) w Kafka. Pojedynczy wpis audytowy zawiera m.in.:

• principal (użytkownik lub service account),
• operację (READ, WRITE, DESCRIBE itd.),
• zasób (topic, consumer group, cluster),
• znacznik czasu,
• wynik (allowed / denied),
• metadane klienta (IP, listener, protokół).

Dzięki temu, że logi audytowe są przechowywane w Kafka, mogą być łatwo integrowane z systemami SIEM, długoterminowym storage’em czy narzędziami monitorującymi. W wielu organizacjach jest to bezwzględny wymóg, co czyni tę funkcję istotną przewagą Confluent Platform.

Role-Based Access Control (RBAC)

Open source Apache Kafka oferuje ACL (Access Control Lists) jako podstawowy mechanizm kontroli dostępu. ACL-e są elastyczne, ale w dużych środowiskach bardzo szybko stają się trudne w zarządzaniu, szczególnie gdy:

• istnieją setki topiców,
• wiele zespołów korzysta z jednego klastra,
• użytkownicy i aplikacje często się zmieniają.

Confluent Platform wprowadza RBAC (Role-Based Access Control), który upraszcza autoryzację poprzez przypisywanie użytkownikom ról zamiast pojedynczych ACL-i. Role agregują zestawy uprawnień i znacząco zmniejszają liczbę konfiguracji do zarządzania.

Przykładowe predefiniowane role:

• DeveloperRead
• DeveloperWrite
• ResourceOwner
• SecurityAdmin
• ClusterAdmin

RBAC znacząco redukuje złożoność operacyjną i ryzyko błędów konfiguracyjnych. Co istotne, mechanizm ten działa spójnie w całym ekosystemie Confluent, obejmując:

• brokerów Kafka,
• Schema Registry,
• Kafka Connect,
• ksqlDB,
• Control Center.

Jest to szczególnie atrakcyjne rozwiązanie dla dużych organizacji z wieloma zespołami i współdzieloną infrastrukturą Kafka.

Cluster Linking

W scenariuszach korzystających z wielu centrów danych (data center - DC) Kafka zazwyczaj wykorzystuje MirrorMaker 2. Jest to rozwiązanie oparte na Kafka Connect, które działa poprawnie, ale wiąże się z dodatkową złożonością operacyjną i większym opóźnieniem.

Confluent Platform oferuje Cluster Linking, czyli mechanizm replikacji wbudowany bezpośrednio w warstwę brokerów. Dzięki replikacji na poziomie bajtów i braku zależności od Kafka Connect, Cluster Linking:

• zapewnia niższe opóźnienia,
• zużywa mniej zasobów,
• jest prostszy w utrzymaniu i monitorowaniu.

Kluczową funkcją Cluster Linking jest możliwość replikacji offsetów consumer group. Ma to ogromne znaczenie w scenariuszach DR – w przypadku awarii klastra aktywnego konsumenci mogą przełączyć się na klaster zapasowy i kontynuować przetwarzanie praktycznie od tego samego miejsca, bez ręcznego resetowania offsetów.

Typowe zastosowania:

• active–passive disaster recovery,
• migracje danych między klastrami,
• architektury multi-cloud i hybrid cloud.

Stretched Cluster 2.5 oraz Observers

W open source Kafka architektury multi-data-center zwykle przyjmują jedną z następujących form:

• active–passive,
• active–active,
• klastry rozciągnięte na trzy centra danych (3-DC).

Ostatnie podejście wymaga utrzymywania brokerów oraz storage’u (lub ZooKeeper/KRaft) we wszystkich trzech lokalizacjach, co:

• znacząco zwiększa koszty,
• wymaga bardzo niskich opóźnień sieciowych,
• komplikuje operacje.

Confluent Platform wprowadza Stretched Cluster 2.5, który stanowi kompromis pomiędzy active–active a pełnym klastrem opartym na trzech data center:

• dane są przechowywane w dwóch data center,
• kontrolery KRaft działają w trzech data center,
• quorum realizowane jest przez 3 lub 5 węzłów KRaft.

Takie podejście zapewnia:

• automatyczny failover (bez ręcznej ingerencji),
• niższe koszty niż w architekturze trzy-DC,
• lepsze właściwości DR niż klasyczne active–passive i active-active.

Observers

Confluent rozszerza również model replikacji Kafka o Observers. W standardowej Kafka partycje składają się z lidera i synchronicznych replik (ISR).

Observers to asynchroniczne repliki, które:

• nie uczestniczą w ISR w normalnych warunkach,
• mogą zostać promowane do pełnoprawnych replik w określonych sytuacjach (np. spadek liczby ISR poniżej min.insync.replicas).

Dzięki observers możliwe jest bezpieczne przechowywanie danych w wielu centrach danych bez negatywnego wpływu na opóźnienia zapisu. Mechanizm ten pozwala egzekwować replikację między DC przy zachowaniu wysokiej dostępności.

Przeczytaj także: Understanding in-sync replicas and replication factor in Confluent Stretched Cluster 2.5

Self-Balancing Cluster

W dużych klastrach Kafka operacje takie jak:

• dodawanie nowych brokerów,
• usuwanie starych węzłów,
• zmiany liczby partycji
  są kosztowne operacyjnie i podatne na błędy. Ręczne rebalance mogą prowadzić do nierównomiernego obciążenia lub chwilowych problemów wydajnościowych.

Confluent Platform oferuje Self-Balancing Cluster, który działa w tle i automatycznie:

• równoważy rozłożenie partycji,
• rozkłada liderów partycji,
• optymalizuje wykorzystanie dysków i sieci.

Proces jest ciągły i automatyczny, co znacząco upraszcza zarządzanie dużymi klastrami.

Control Center

W open source Kafka monitoring i zarządzanie opierają się głównie na zewnętrznych narzędziach (Grafana, Prometheus, skrypty własne). Confluent Platform dostarcza Control Center – zintegrowany interfejs do zarządzania całym ekosystemem Kafka.

Control Center oferuje m.in.:

• widok end-to-end przepływu danych,
• monitoring consumer lag,
• metryki zdrowia klastra,
• wgląd w konfigurację bezpieczeństwa i RBAC,
• zarządzanie Kafka Connect i ksqlDB.

Choć Grafana jest potężnym narzędziem open source, Control Center zapewnia widok dedykowany Kafce, który znacząco ułatwia operacje i troubleshooting.

Komercyjne wsparcie i komercyjne konektory

Confluent Platform oferuje wsparcie klasy enterprise, które w systemach krytycznych bywa niezbędne. Obejmuje ono:

• SLA,
• bezpośredni dostęp do ekspertów Kafka,
• szybsze rozwiązywanie złożonych problemów produkcyjnych.

Dodatkowo Confluent dostarcza komercyjne konektory Kafka Connect do systemów takich jak:

• mainframe’y,
• bazy danych klasy enterprise,
• platformy SaaS.

Są one lepiej przetestowane, stabilne i objęte oficjalnym wsparciem.

Apache Kafka vs Confluent - Podsumowanie

Confluent Platform wnosi do Apache Kafka szereg istotnych funkcji, szczególnie w obszarach:

• bezpieczeństwa (Audit Logs, RBAC),
• disaster recovery (Cluster Linking, Stretched Cluster 2.5, Observers),
• operacji (Self-Balancing Cluster, Control Center).

Nie każda organizacja potrzebuje tych możliwości – open-source Kafka wciąż doskonale sprawdza się w wielu scenariuszach. Jednak w środowiskach regulowanych, dużych instalacjach oraz systemach o wysokich wymaganiach dostępności i bezpieczeństwa, funkcje te są zdecydowanie warte rozważenia.

W SoftwareMill na co dzień świadczymy usługi związane z Apache Kafka, pomagając organizacjom projektować, budować i utrzymywać platformy event-driven, które skalują się w sposób bezpieczny i niezawodny. Jako Confluent Elite Partner wspieramy firmy na każdym etapie cyklu życia Kafka – od architektury i wdrożenia, przez optymalizację, aż po długoterminowe utrzymanie. Jeżeli potrzebujesz jakiegokolwiek wsparcia w tym zakresie, wystarczy, że do nas napiszesz.

Recenzja artykułu: Grzegorz Kocur