Kiedy warto rozważyć wdrożenie Apache Kafka?

Apache Kafka to rozproszona platforma strumieniowania zdarzeń, którą warto rozważyć, gdy wiele systemów musi niezależnie korzystać z tych samych zdarzeń, a historia zdarzeń musi być przechowywana przez pewien czas, aby można było ją później ponownie odczytać. Zamiast wybierać ją tylko dlatego, że potrzebne jest przetwarzanie asynchroniczne, lepiej ocenić, czy jednocześnie potrzebujesz wielu subskrypcji, przetwarzania dużych wolumenów, ponownego przetwarzania i odporności na awarie. kafka.apache.org↗

Kafka jest często opisywana jako „kolejka komunikatów”, ale sama ta etykieta nie wyjaśnia w pełni jej kluczowej wartości. Doskonale sprawdza się w rejestrowaniu jako zdarzeń faktów, które wystąpiły w systemie — takich jak utworzenie zamówienia, ukończenie płatności, działanie klienta czy dziennik systemowy — a następnie pozwala wielu aplikacjom i systemom danych odczytywać je w ich własnym tempie. Natomiast jeśli niewielka usługa musi tylko jednorazowo przetworzyć jeden rodzaj zadania w tle, złożoność operacyjna Kafki może przewyższyć jej korzyści.

W tym artykule najpierw zdefiniowano problemy rozwiązywane przez Kafkę, a następnie omówiono sygnały zwiększające wartość jej wdrożenia oraz kompromisy związane z jej projektem i eksploatacją.

Jakim rodzajem platformy jest Kafka?

Kafka działa wokół tematów rejestrujących zdarzenia. Zdarzenie to rekord danych reprezentujący fakt, który wystąpił w systemie, na przykład „utworzono zamówienie”, „użytkownik wyświetlił produkt” lub „zmierzono temperaturę czujnika”. Aplikacje zapisujące zdarzenia są nazywane producentami, natomiast aplikacje odczytujące i przetwarzające je — konsumentami. kafka.apache.org↗

Producenci publikują zdarzenia w tematach, a konsumenci subskrybują i odczytują potrzebne im tematy. Producenci nie muszą bezpośrednio wiedzieć, kto odczytuje ich zdarzenia. Nawet jeśli później zostanie dodana usługa analityczna, powiadomień lub indeksowania wyszukiwania, usługa zamówień może zasadniczo publikować to samo zdarzenie zamówienia bez ciągłego dodawania osobnego kodu integracyjnego dla każdego systemu. Jest to luźne powiązanie między producentami a konsumentami. kafka.apache.org↗

Ponadto zdarzenia Kafka nie znikają natychmiast po odczytaniu ich przez konsumenta. Są przechowywane zgodnie z zasadami retencji na poziomie tematu, a konsumenci zarządzają pozycjami wskazującymi, jak daleko odczytali dane. Dzięki temu nowy konsument może czytać rekordy historyczne, a istniejący konsument może ponownie przetwarzać dane od określonego punktu po naprawieniu błędu. kafka.apache.org↗

Z tego powodu bardziej użyteczne jest rozumienie Kafki jako platformy, która „utrzymuje współdzieloną historię zdarzeń”, a nie jedynie „dostarcza komunikaty”. Retencja nie oznacza jednak przechowywania danych na zawsze. Rzeczywisty okres przechowywania należy określić na podstawie zasad dla tematów i planowania pojemności pamięci masowej.

Jak współdziałają podstawowe komponenty?

Rozróżnienie głównych komponentów Kafki ułatwia podejmowanie decyzji wdrożeniowych i analizę incydentów.

Temat jest podzielony na jedną lub więcej partycji. Partycja jest uporządkowanym logiem zdarzeń, a Kafka używa wielu partycji do równoległego odczytu i zapisu. Dlatego liczba partycji nie jest tylko wartością konfiguracji; jest decyzją projektową, która jednocześnie odzwierciedla docelową przepustowość, równoległość konsumentów i wymagania dotyczące kolejności. kafka.apache.org↗

Grupa konsumentów to zbiór instancji konsumentów wykonujących to samo zadanie. Na przykład, jeśli kilka instancji konsumentów ładuje zdarzenia zamówień do hurtowni danych, mogą tworzyć jedną grupę. W obrębie grupy każda partycja może zostać przypisana jednemu konsumentowi, aby rozdzielić obciążenie przetwarzaniem. Z kolei usługa powiadomień i usługa analityczna należą do różnych grup, więc każda z nich może niezależnie odczytywać te same zdarzenia zamówień. kafka.apache.org↗

Ta struktura sprzyja skalowaniu, ale większa liczba aktywnych konsumentów w grupie niż partycji nie oznacza, że wszystkie będą mogły jednocześnie przetwarzać więcej partycji. Nie należy oczekiwać, że równoległość będzie rosła bez ograniczeń wyłącznie przez zwiększanie liczby instancji. Już od początku planowanie partycji musi uwzględniać rzeczywisty rozkład kluczy oraz przyszłe potrzeby skalowania.

Jakie problemy sprawiają, że Kafka lepiej pasuje do danego zastosowania?

Najsilniejszym sygnałem przemawiającym za wdrożeniem jest sytuacja, w której wiele systemów musi wykorzystywać jedno zdarzenie w różnych celach i z różną prędkością. Liczy się nie sama liczba konsumentów, lecz to, czy konsumenci muszą rozwijać się niezależnie od producenta.

Rozważ system e-commerce, w którym tworzone jest zamówienie. Początkowo wystarczać może aktualizacja wyłącznie bazy danych zamówień. Później mogą dojść rezerwacja zapasów, procesy płatności, powiadomienia klientów, wykrywanie oszustw, aktualizacje danych wyszukiwania i rekomendacji oraz ładowanie danych analitycznych. Jeśli każda z tych funkcji nadal będzie podłączać się do usługi zamówień za pomocą wywołań synchronicznych, opóźnienie lub awaria jednej funkcji może wpłynąć na ścieżkę obsługi zamówienia, a zależności integracyjne mogą stać się złożone.

W takim przypadku usługa zamówień może opublikować zdarzenie order created, podczas gdy każdy system podrzędny odczytuje potrzebne zdarzenia przez osobną grupę konsumentów. Kluczowym zastosowaniem Kafki jest możliwość dodawania nowych konsumentów bez bezpośredniej modyfikacji istniejącego producenta. kafka.apache.org↗

Szczególnie warto ocenić następujące sytuacje:

• Istnieją kluczowe zdarzenia, takie jak zmiany statusu zamówienia, płatności lub członkostwa, do których odwołuje się kilka systemów biznesowych.
• Dane takie jak kliknięcia użytkowników, odsłony stron, logi operacyjne lub pomiary gromadzą się nieprzerwanie.
• Analityka, powiadomienia, indeksowanie i ładowanie do hurtowni danych potrzebują tych samych zdarzeń źródłowych.
• Przepływ produkcyjny musi działać nadal, nawet gdy konsumenci mają różne prędkości przetwarzania i punkty odzyskiwania po awariach.
• Gdy pojawia się nowy przypadek użycia, bezpośrednie łączenie usługi źródłowej z każdym systemem podrzędnym jest uciążliwe.

Każdy z tych warunków z osobna nie musi oznaczać, że Kafka jest wymagana. Jeśli jednak kilka z nich występuje równocześnie, a każdy przepływ danych prawdopodobnie będzie rosnąć, architektura strumieniowania zdarzeń może oferować większe korzyści niż proste integracje punkt-punkt.

Jak Kafka absorbuje duże wolumeny i gwałtowne wahania?

Kafka została zaprojektowana do rozdzielania odczytu i zapisu zdarzeń przez partycje, dlatego może być używana dla przepływów danych, które stale generują dużą liczbę zdarzeń. Typowe przykłady to agregacja logów, śledzenie aktywności użytkowników, metryki monitoringu, pomiary IoT i zdarzenia transakcyjne. kafka.apache.org↗

Rola Kafki polega tutaj na rozluźnieniu powiązania, które wymaga, by tempo produkcji i konsumpcji zawsze było takie samo. Na przykład, gdy liczba zdarzeń gwałtownie wzrasta w określonym okresie, konsumenci mogą nie być w stanie przetworzyć ich wszystkich od razu. Jeśli zdarzenia są przechowywane, konsumenci mogą później nadrobić zaległości. Daje to konsumentom możliwość niezależnego dostosowania tempa przetwarzania bez blokowania producentów.

Nie oznacza to, że opóźnienie znika. Oznacza raczej, że można nim zarządzać jako skumulowanym zaległym wolumenem zapisanych zdarzeń. Opóźnienie konsumenta jest metryką operacyjną pokazującą, jak daleko konsument pozostaje za najnowszymi zdarzeniami. Jeśli opóźnienie stale rośnie, należy zbadać wydajność konsumenta, zależności zewnętrzne, rozkład partycji i ponawianie po błędach. Kafka udostępnia metryki monitorowania oparte na JMX, a środowiska produkcyjne muszą także uwzględniać bezpieczeństwo ścieżek dostępu do monitoringu. kafka.apache.org↗

Przy ocenie wymagań dotyczących przepustowości lepiej rozdzielić następujące pytania, zamiast ogólnie stwierdzać, że „ruch jest wysoki”:

1. Ile zdarzeń występuje na sekundę lub w każdym okresie?
2. Jaki jest średni i maksymalny rozmiar pojedynczego zdarzenia?
3. Jak długo utrzymują się szczyty?
4. Jakie opóźnienie konsumenta jest akceptowalne?
5. Jak szybko należy przetworzyć zaległości po awarii?
6. Jak długo zdarzenia muszą być przechowywane?

Odpowiedzi na te pytania ujawniają, że liczba partycji, pojemność pamięci masowej, replikacja, skalowanie konsumentów i czas ponownego przetwarzania są powiązanymi zagadnieniami. Kafka zapewnia podstawę wysokiej przepustowości, ale rzeczywista wydajność i koszt zależą od rozmiaru zdarzeń, nierównomierności kluczy, zasad retencji i wąskich gardeł w logice konsumentów.

Dlaczego ponowne przetwarzanie jest ważnym powodem wdrożenia Kafki?

Przetwarzanie w czasie rzeczywistym to praca, która daje wynik natychmiast po nadejściu zdarzenia. Przykładami są aktualizacja zapasów po zamówieniu, wykrywanie transakcji spełniających określone warunki lub agregowanie metryk minutowych. Jednak ponowne przetwarzanie danych historycznych może być wymaganiem równie ważnym jak przetwarzanie w czasie rzeczywistym.

Ponowne przetwarzanie jest potrzebne z wielu powodów. Po naprawieniu błędu w kodzie konsumenta można odtworzyć wyniki, których brakowało lub które zostały obliczone nieprawidłowo. Po wprowadzeniu nowych reguł analitycznych można utworzyć dane pochodne z istniejącej historii zdarzeń. Jeśli konsumpcja zatrzyma się z powodu awarii, można odzyskać działanie przez ponowny odczyt od ostatniej przetworzonej pozycji. W Kafce zdarzenia nie są usuwane natychmiast po konsumpcji i mogą być ponownie odczytywane w ramach zasad retencji. kafka.apache.org↗

Załóżmy na przykład, że zdarzenia zachowań klientów były początkowo używane jedynie do agregowania dziennej liczby odwiedzających. Jeśli później potrzebna będzie analiza konwersji według kanału pozyskania, osobna grupa konsumentów może odczytać zdarzenia historyczne i wygenerować nowe wyniki analityczne, pod warunkiem że zdarzenia zawierają wymagane pola, a okres retencji nadal trwa. Pracę można odizolować bez zatrzymywania istniejącego konsumenta agregującego lub wykonywania zapytań na dużą skalę wobec bazy danych usługi źródłowej.

Sama możliwość ponownego przetwarzania nie rozwiązuje jednak problemów z jakością danych. Jeśli zdarzenia nie zawierają wymaganych identyfikatorów, znaczników czasu wystąpienia lub informacji o wersji albo jeśli znaczenie schematu zmieniło się bez zarządzania kompatybilnością, trudno jest uzyskać wiarygodne wyniki nawet wtedy, gdy dane historyczne można odczytać. Ponadto wymaganie ponownego przetwarzania danych starszych niż okres retencji może nie zostać spełnione wyłącznie przez tematy Kafka. Dlatego, jeśli ponowne przetwarzanie jest powodem wdrożenia, najpierw określ „co będzie odtwarzane, przez jak długo i z jakim znaczeniem”.

Czy Kafka może również łączyć bazy danych i systemy zewnętrzne?

Kafka może być używana nie tylko do dostarczania zdarzeń między usługami, ale również jako centralny przepływ dla potoków danych. Change data capture (CDC) to podejście polegające na przesyłaniu do przepływu danych zmian zachodzących w bazie danych; można je rozważyć, gdy zmiany w danych operacyjnych muszą być odzwierciedlane w analityce, wyszukiwaniu lub innych usługach. Kafka Connect udostępnia API i model konektorów dla cyklicznych integracji wejścia i wyjścia danych z systemami zewnętrznymi. kafka.apache.org↗

Przykłady, w których taka konfiguracja może być użyteczna, obejmują:

• Ciągłe wysyłanie zmian z operacyjnej bazy danych do magazynu analitycznego.
• Zbieranie logów i metryk z wielu aplikacji do wspólnego przepływu.
• Odzwierciedlanie danych generowanych w jednym systemie w indeksie lub tabeli pochodnej w innym magazynie.
• Tworzenie ciągłych przepływów danych między środowiskami lokalnymi i chmurowymi.

Użycie konektorów nie eliminuje różnic w modelach danych, semantyce usuwania, problemach z kolejnością, zarządzaniu dostępem ani limitach zapisu systemów docelowych. W szczególności, gdy zmiany w bazie danych są używane jako zdarzenia, trzeba odróżnić fakt, że „wiersz się zmienił”, od zdarzenia biznesowego, że „zamówienie zostało potwierdzone”. Pierwsze jest bliższe zmianie w pamięci masowej, drugie zaś jest zdarzeniem biznesowym o znaczeniu domenowym. Traktowanie ich jako tego samego może spowodować, że konsumenci staną się zbyt silnie zależni od struktury przechowywania danych.

Dlatego wdrożenie Kafki dla potoków danych jest bardziej niezawodne, gdy robi coś więcej niż zmniejsza liczbę połączeń — gdy jednocześnie wyjaśnia właścicieli danych, schematy i odpowiedzialność za zmiany.

W jakim zakresie gwarantowana jest kolejność i dlaczego projekt klucza ma znaczenie?

W Kafce kolejność zdarzeń jest gwarantowana w obrębie partycji, a nie w całym temacie. Wiele partycji umożliwia przetwarzanie równoległe, lecz nie ma jednej globalnej kolejności między nimi. kafka.apache.org↗

Na przykład, jeśli status zamówienia musi być przetwarzany w sekwencji created, payment completed i shipping started, można użyć identyfikatora zamówienia jako klucza, aby zdarzenia dotyczące tego samego zamówienia były zapisywane w tej samej partycji. Pozwala to korzystać z kolejności rekordów w obrębie tego zamówienia jako jednostki. Zmiany statusu klienta można zaprojektować podobnie, używając identyfikatora klienta jako klucza.

Odwrotnie, jeśli wszystkie zdarzenia zamówień muszą być przetwarzane pojedynczo w ogólnej kolejności chronologicznej, w praktyce może być wymagany wybór zbliżony do pojedynczej partycji. W takim przypadku kolejność może stać się prostsza, ale możliwości przetwarzania równoległego są ograniczone. Globalna kolejność i wysoka równoległość nie są właściwościami, których można uzyskać jednocześnie bez ograniczeń.

Wybór klucza rodzi kolejny problem. Jeśli określony klient lub urządzenie generuje wyjątkowo dużą liczbę zdarzeń, ten klucz może koncentrować się w jednej partycji. Można to uznać za nierównomierność kluczy i tylko niektórzy konsumenci mogą stać się nadmiernie obciążeni. Klucze powinny więc reprezentować jednostkę biznesową wymagającą kolejności, a zarazem być oceniane pod kątem tego, czy nie powodują nadmiernej nierównomierności w oczekiwanym rozkładzie danych.

Podczas dokumentowania wymagań dotyczących kolejności nie należy poprzestawać na stwierdzeniu, że „kolejność ma znaczenie”. Lepiej je sprecyzować w następujący sposób:

• W zakresie jakiego identyfikatora wymagana jest kolejność?
• Czy wymagana jest kolejność czasu zdarzenia, czy kolejność zapisu rekordów?
• Jak będą obsługiwane zdarzenia docierające z opóźnieniem?
• Jaki błąd biznesowy występuje, jeśli zdarzenia są poza kolejnością?
• Czy globalna kolejność jest potrzebna nawet kosztem mniejszej równoległości?

Odpowiedzi określają podział tematów, klucze, liczbę partycji i logikę konsumentów.

Jak rozumieć przetwarzanie duplikatów i przetwarzanie dokładnie raz?

Konsumenci Kafka wymagają projektów zakładających domyślnie przetwarzanie co najmniej raz, z uwzględnieniem awarii i ponawiania. Na przykład, jeśli konsument zakończy przetwarzanie zdarzenia, ale zatrzyma się przed zapisaniem swojej pozycji przetwarzania, po odzyskaniu działania może ponownie odczytać to samo zdarzenie. W związku z tym możliwe jest wielokrotne przetworzenie tego samego zdarzenia. kafka.apache.org↗

Praktycznym rozwiązaniem jest uczynienie logiki konsumenta idempotentną. Idempotencja to właściwość polegająca na uzyskaniu tego samego wyniku końcowego, nawet gdy ta sama operacja zostanie wykonana wielokrotnie. Na przykład operację taką jak set the status of order 123 to delivered można zaprojektować tak, aby powtórzenie tej samej aktualizacji statusu nie zmieniało istotnie wyniku. Natomiast operacja, która unconditionally adds 1,000 points, może dać inny wynik, jeśli otrzyma to samo zdarzenie dwa razy, dlatego wymaga strategii deduplikacji, takiej jak rejestrowanie identyfikatorów zdarzeń lub stosowanie ograniczeń unikalności w magazynie docelowym.

Przy łączeniu odczytu, przetwarzania i zapisu w obrębie tematów Kafka wspiera konfiguracje przetwarzania dokładnie raz za pomocą transakcji i poziomu izolacji read_committed. Nie należy jednak rozumieć tego jako gwarancji, że każdy efekt zewnętrzny automatycznie nastąpi tylko raz. Skutki uboczne poza Kafką, takie jak aktualizacje zewnętrznej bazy danych, wysyłka e-maili czy wywołania API płatności, wymagają koordynacji z systemem docelowym i osobnego projektu. kafka.apache.org↗

Dlatego przed wdrożeniem zadaj następujące pytania dla każdego konsumenta:

• Co się stanie, jeśli to samo zdarzenie zostanie przetworzone dwa razy?
• Czy każde zdarzenie ma identyfikator, który można wykorzystać do wykrywania duplikatów?
• Czy magazyn wyników zapobiega duplikatom lub wspiera bezpieczne aktualizacje?
• Jakie są kryteria ponawiania, gdy zewnętrzne wywołanie nie powiedzie się lub jego odpowiedź jest niejednoznaczna?
• Jak podczas ponownego przetwarzania będą obsługiwane skutki uboczne już wykonane?

Jeżeli Kafka zostanie wdrożona bez odpowiedzi na te pytania, sam transport może być niezawodny, podczas gdy zduplikowane lub niespójne wyniki biznesowe nadal będą trudne do wykrycia.

Czy odporność na awarie i trwałość są gwarantowane automatycznie?

Kafkę można skonfigurować tak, aby przygotować się na awarie brokerów poprzez replikację partycji tematów. Może to być istotną zaletą dla przepływów danych, w których ważne są replikowane partycje, ciągłość działania podczas awarii brokerów oraz rozkład obciążenia między wielu konsumentów. kafka.apache.org↗

Jednak wniosek, że „dane nigdy nie mogą zostać utracone, ponieważ używamy Kafki”, nie jest poprawny. Rzeczywista trwałość i dostępność zależą od współczynnika replikacji, ustawień potwierdzeń producenta, zakresu awarii, które mogą wystąpić jednocześnie, zasad retencji oraz procedur operacyjnych. Nawet przy replikach wyniki mogą odbiegać od oczekiwań, jeśli repliki są umieszczone w tej samej domenie awarii, ważne ustawienia nie spełniają wymaganego poziomu lub procedury odzyskiwania nie zostały zweryfikowane przez operatorów. kafka.apache.org↗

Pomaga jawne zapisanie wymagań dotyczących odporności na awarie. Na przykład: „Produkcja i konsumpcja zdarzeń zamówień muszą być kontynuowane, gdy jeden broker przestanie działać”, „Duplikaty są akceptowalne po awarii konsumenta, ale pominięcia nie” albo „Zdarzenia z określonego okresu muszą dawać się ponownie przetworzyć”. Te wymagania określają nie tylko replikację i potwierdzenia, ale również idempotencję konsumentów, monitoring, pojemność pamięci masowej i ćwiczenia odzyskiwania.

Ponieważ historia możliwa do ponownego przetworzenia może stać się ważnym zasobem danych, należy osobno ocenić, czy tematy zawierają dane osobowe lub poufne dane biznesowe. Kontrola dostępu i bezpieczeństwo interfejsów operacyjnych nie są zadaniami wykonywanymi po fakcie, oddzielonymi od projektowania przepływu danych. Operacje Kafka wymagają również ustawień bezpieczeństwa dla dostępu administracyjnego, w tym do monitoringu. kafka.apache.org↗

Czy Kafka jest zawsze lepsza niż prosta kolejka zadań lub synchroniczne API?

Nie. Kafka nie jest automatycznym zastępstwem dla każdego wymagania asynchronicznego. Jeżeli wymaganie jest bliższe „jednorazowej konwersji obrazu”, „wygenerowania raportu i zwrócenia tylko wyniku” lub „pobrania i przetworzenia zadania przez jednego konsumenta”, a długa retencja, wiele subskrypcji i ponowne przetwarzanie nie są kluczowe, prostsza kolejka zadań lub usługa zarządzana może lepiej odpowiadać potrzebom pod względem kosztu i narzutu operacyjnego. Główne mocne strony Kafki ujawniają się, gdy łączą się przepływy zdarzeń na dużą skalę, wielu niezależnych konsumentów i ponowne wykorzystanie przechowywanej historii. kafka.apache.org↗

Synchroniczne API również pełnią inną rolę. Żądanie, w którym użytkownik klika przycisk i potrzebuje natychmiastowego wyniku sukcesu lub błędu, naturalnie pasuje do API typu żądanie-odpowiedź. Po zakończeniu tego żądania przepływ informowania systemów podrzędnych o tym fakcie można rozdzielić na zdarzenia. Innymi słowy, zamiast wybierać wyłącznie wywołania synchroniczne albo Kafkę, często bardziej odpowiednie jest użycie API dla interakcji użytkownika oraz zdarzeń do asynchronicznego rozsyłania pracy do systemów podrzędnych.

Poniższe porównanie może uprościć decyzję:

Ta tabela nie jest bezwzględną regułą wyboru produktu. Na decyzję wpływają także istniejąca platforma zespołu, dostępność usług zarządzanych, zasady bezpieczeństwa i obsada operacyjna. Kluczowy jest charakter przepływu danych, który próbujesz rozwiązać, a nie lista funkcji.

Co należy przygotować w zakresie eksploatacji i zarządzania?

Wdrożenie Kafki nie ogranicza się do dodania biblioteki aplikacyjnej. Wymaga także modelu operacyjnego do ciągłego zarządzania tematami, partycjami, replikacją, retencją, uprawnieniami dostępu, monitoringiem i pojemnością. Kafka udostępnia metryki JMX, ale informacje operacyjne tworzą rzeczywistą wartość tylko wtedy, gdy określisz, które metryki wyzwalają alerty, kto reaguje i jak przebiega odzyskiwanie. kafka.apache.org↗

Najpierw należy zarządzać kontraktami zdarzeń. Kontrakt zdarzenia obejmuje nie tylko nazwy pól i typy danych, lecz także biznesowe znaczenie każdego pola, to, czy jest ono opcjonalne, sposób obsługi zmian wersji oraz rozróżnienie między czasem produkcji a czasem wystąpienia. Potrzebne są standardy kompatybilności, aby konsumenci nie działali po cichu nieprawidłowo, gdy producent usuwa pole lub zmienia jego znaczenie.

Następnie zasady dla tematów muszą być jasne. Dla każdego tematu należy zdecydować o następujących kwestiach:

• Jakie zdarzenia zawiera i kto jest ich właścicielem.
• Jaki jest okres retencji i kryteria pojemności pamięci masowej.
• Które wymagania dotyczące kolejności i przepustowości określiły liczbę partycji oraz klucz.
• Jaki poziom odporności na awarie mają osiągnąć replikacja i potwierdzenia producenta.
• Kto może produkować i konsumować dane oraz jak chronione są dane wrażliwe.
• Przy jakim poziomie opóźnienia konsumenta rozpoczyna się badanie i reakcja.

Ważne jest także planowanie pojemności. Dłuższe okresy retencji lub większa replikacja zwiększają wymagania dotyczące pamięci masowej. Jeśli konsumenci muszą móc ponownie przetwarzać dane po długim okresie zatrzymania, historia może wymagać odpowiedniego przechowywania. Z kolei krótka retencja może obniżyć koszt, ale ogranicza zakres danych historycznych dostępnych do odzyskiwania po awarii lub dodawania nowych konsumentów. Ten wybór określa nie tylko koszty, ale również zakres możliwości produktu i odtwarzalność.

W organizacjach o niejasnej odpowiedzialności operacyjnej współdzielona platforma Kafka może zamiast tego zwiększyć problemy z zależnościami. Uzgodnienie, za które zmiany i incydenty odpowiadają właściciele tematów, operatorzy platformy, właściciele bezpieczeństwa i zespoły rozwijające konsumentów, jest równie ważne jak konfiguracja techniczna.

Jakich pytań użyć przy podejmowaniu decyzji przed wdrożeniem?

Pytanie, które najlepiej odróżnia przypadki uzasadniające wdrożenie Kafki, nie brzmi: „Czy potrzebujemy komunikatów asynchronicznych?”. Trafniejsze pytanie brzmi: Czy wielu niezależnych konsumentów musi stale odczytywać historię zdarzeń na dużą skalę i ponownie ją przetwarzać po opóźnieniu lub awarii? Jeśli odpowiedź jest wyraźnie twierdząca, wymagania prawdopodobnie są zgodne z kluczowymi cechami Kafki. kafka.apache.org↗kafka.apache.org↗

Możesz użyć następującej listy kontrolnej, rozpoczynając rozmowy o wdrożeniu:

1. Wielu konsumentów: Czy wiele systemów obecnie lub w niedalekiej przyszłości musi niezależnie używać tego samego zdarzenia?
2. Wartość historii: Czy zdarzenia muszą być przechowywane po konsumpcji i ponownie odczytywane na potrzeby naprawy błędów, audytów lub nowych analiz?
3. Skala przetwarzania: Czy trwałe przyjmowanie dużych wolumenów danych lub ruch szczytowy wymaga rozdzielenia produkcji od konsumpcji?
4. Zakres kolejności: Czy problem można rozwiązać kolejnością według klucza, takiego jak klient lub zamówienie, zamiast kolejności globalnej?
5. Obsługa duplikatów: Czy każdy konsument może bezpiecznie przetwarzać lub identyfikować zduplikowane zdarzenia?
6. Zarządzanie kontraktami: Czy istnieją właściciele i procesy do zarządzania zmianami w schematach i znaczeniach zdarzeń?
7. Gotowość operacyjna: Czy istnieje odpowiedzialny właściciel, który może obserwować i reagować na opóźnienia, pojemność pamięci masowej, awarie brokerów, uprawnienia i ponowne przetwarzanie?
8. Porównanie alternatyw: Czy wymaganie można spełnić prościej przez dystrybucję zadań dla jednego konsumenta albo samo żądanie-odpowiedź?

Nie każdy element musi być doskonały od początku, aby wdrożyć Kafkę. Jeśli jednak potrzeby z punktów od 1 do 5 są silne, a przygotowanie z punktów 6 i 7 nie istnieje, może wystąpić duża luka między możliwością techniczną a systemem, który da się eksploatować. Pomocne może być najpierw zweryfikowanie kontraktów zdarzeń, obsługi duplikatów, obserwacji opóźnień i ponownego przetwarzania w jednym przepływie danych o małym zakresie.

Podsumowanie: Kafka jest potężna, gdy historia zdarzeń musi być współdzielona

Apache Kafka nie jest jedynie narzędziem do asynchronicznego przesyłania komunikatów; jest platformą, która przechowuje przepływy zdarzeń współdzielone przez wiele systemów i pozwala im niezależnie konsumować te przepływy. Wartość jej wdrożenia wzrasta w środowiskach, które jednocześnie potrzebują wielu subskrypcji tych samych zdarzeń, równoległego przetwarzania przepływów danych o dużym wolumenie, nadrabiania opóźnień oraz ponownego przetwarzania rekordów historycznych. kafka.apache.org↗kafka.apache.org↗

Z kolei prostsze alternatywy mogą lepiej odpowiadać wymaganiom polegającym na przekazaniu jednorazowej pracy jednemu konsumentowi, żądaniom skoncentrowanym na natychmiastowych odpowiedziach lub niewielkim przepływom, w których narzut operacyjny musi być minimalny. Wybierając Kafkę, oceń nie tylko przepustowość, lecz także gotowość do zarządzania kolejnością na poziomie partycji, przetwarzaniem duplikatów, zasadami retencji, kontraktami zdarzeń, bezpieczeństwem i obserwowalnością. Im więcej z tych warunków jest spełnionych, tym bardziej Kafka może stać się fundamentem ograniczającym powiązania między usługami i rozszerzającym sposoby wykorzystania danych.