Apache Kafka – przewodnik po Disaster Recovery i architekturach opartych o wiele regionów

Nowoczesne systemy informatyczne często są oparte na zdarzeniach (event-driven), działają w czasie rzeczywistym i wymagają globalnego rozproszenia. Dla wielu organizacji Apache Kafka to nie tylko kolejny komponent, lecz fundament przepływu danych pomiędzy usługami, zespołami i regionami.

Kiedy Kafka przestaje działać, często zatrzymuje się biznes:

• płatności nie są przetwarzane,
• zamówienia nie są wysyłane,
• procesy wykrywania oszustw stają w miejscu,
• powiadomienia dla klientów nie docierają,
• analityka przestaje nadążać.

W branżach silnie regulowanych awarie mogą oznaczać nie tylko straty operacyjne, ale i kosztowne kary finansowe.

Dlatego disaster recovery dla Kafki i architektura multi-region to nie „miły dodatek”. To kluczowe elementy strategii ciągłości działania (Business Continuity Plan).

Kafka - krytyczny element infrastruktury

W wielu architekturach Kafka znajduje się w samym centrum:

• komunikacji między mikroserwisami,
• systemów event sourcing,
• pipeline’ów CDC (change data capture),
• analityki czasu rzeczywistego,
• warstw zasilających platformy danych,
• procesów generowania cech dla modeli ML (feature pipelines).

Ta centralna rola sprawia, że Kafka jest niezwykle potężnym narzędziem, ale jednocześnie staje się krytycznym punktem awarii (Single Point of Failure). Jeśli jeden region przestanie działać, a klaster nie posiada odpowiednio skonfigurowanej replikacji, skutki dla całej organizacji mogą być katastrofalne.

Projektowanie systemów odpornych na awarie (odpornych na przestoje) wymaga odpowiedzi na zestaw trudnych pytań:

• Co się stanie, jeśli padnie cała strefa dostępności (AZ)?
• Co jeśli cały region geograficzny stanie się niedostępny?
• Jak zachowa się system, gdy klaster będzie działał, ale nastąpi segmentacja sieci (network partition) między regionami?
• Co w przypadku błędu ludzkiego – np. przypadkowego usunięcia topicu lub uszkodzenia danych?

Skuteczna architektura Disaster Recovery (DR) dla Kafki musi brać pod uwagę każdy z tych scenariuszy, balansując między spójnością danych a ich dostępnością.

Dlaczego DR (Disaster Recovery) i multi-region dla Kafki są ważne

Wiele zespołów polega wyłącznie na replikacji wewnątrz klastra, zakładając, że to w zupełności wystarczy.

To ryzykowne założenie.

Standardowa replikacja w Kafce (np. przy współczynniku replication.factor=3) skutecznie chroni przed:

• awarią pojedynczego brokera,
• uszkodzeniem dysku,
• chwilową niedostępnością pojedynczego węzła.

Nie stanowi jednak zabezpieczenia w przypadku:

• awarii całego centrum danych (Data Center),
• całkowitego paraliżu regionu geograficznego,
• poważnych incydentów sieciowych (np. problemów z routingiem u dostawcy),
• kaskadowych awarii usług regionalnych po stronie dostawcy chmury.

Właśnie dlatego w krytycznych systemach wdrożenie architektury multi-region nie jest luksusem, lecz koniecznością. Pozwala ona na przetrwanie scenariuszy, w których tracimy kontrolę nad całym obszarem infrastruktury.

Rzeczywisty koszt przestoju

Projektowanie architektury multi-region należy zacząć od analizy wpływu biznesowego i odpowiedzi na kluczowe pytania:

• Ile przychodu tracimy z każdą minutą przestoju?
• Na jakie kary umowne (SLA) oraz straty wizerunkowe jesteśmy narażeni?
• Ile danych możemy bezpowrotnie utracić (RPO – Recovery Point Objective)?
• Czy systemy typu downstream tolerują ponowne przetworzenie danych (replay)?
• Jakie restrykcje prawne i regulacyjne (np. RODO, DORA) musimy spełnić?

Wymagania będą się różnić w zależności od krytyczności systemu:

• Dla systemów o niższym priorytecie: Kilkusekundowa utrata danych może być akceptowalna, a przywrócenie sprawności w ciągu 15–30 minut (RTO – Recovery Time Objective) jest wystarczające.
• Dla systemów krytycznych (Mission Critical): Utrata danych musi być bliska zeru (Zero Data Loss), proces przełączania na region zapasowy (failover) musi być w pełni zautomatyzowany, a sama awaria powinna być całkowicie niezauważalna dla użytkownika końcowego.

Nie istnieje jedna uniwersalna architektura DR dla Kafki. Każde rozwiązanie to kompromis pomiędzy kosztami, stopniem skomplikowania a poziomem gwarancji bezpieczeństwa danych.

Zacznij od fundamentów: RPO i RTO

Projektowanie architektury DR bez jasno określonych wymagań biznesowych to jeden z najczęstszych i najkosztowniejszych błędów architektonicznych. Przed wyborem konkretnej technologii należy zadać sobie dwa kluczowe pytania:

1. Ile danych możemy stracić?
2. Jak długo system może być niedostępny?

Odpowiedzi na te pytania definiują dwa najważniejsze parametry każdego planu ciągłości działania: Recovery Point Objective (RPO) oraz Recovery Time Objective (RTO). Każda architektura DR to kompromis między tymi metrykami a złożonością operacyjną i kosztem utrzymania.

Recovery Point Objective (RPO)

RPO Określa maksymalną dopuszczalną utratę danych w czasie. W kontekście Apache Kafki, RPO definiuje:

• ile wiadomości (zdarzeń) może zostać bezpowrotnie utraconych,
• jaki poziom opóźnienia (lag) w replikacji jest akceptowalny,
• czy dopuszczamy replikację asynchroniczną.

Na wartość RPO wpływają przede wszystkim:

• mechanizm replikacji: (np. MirrorMaker 2, Cluster Linking, Confluent Replicator),
• opóźnienia sieciowe: odległość między regionami (latencja),
• konfiguracja producentów: ustawienia potwierdzeń (acks=all vs acks=1),
• typ replikacji: synchroniczna vs asynchroniczna.

Warto zrozumieć, że większość konfiguracji replikacji międzyregionowej w Kafce ma charakter asynchroniczny, co oznacza, że RPO rzadko wynosi równe zero. Jeśli Twój biznes wymaga absolutnego braku utraty danych (RPO = 0) nawet w przypadku awarii całego regionu, architektura musi zostać zaprojektowana ze szczególną dbałością o spójność (np. poprzez Stretch Clusters).

Recovery Time Objective (RTO)

RTO określa, jak szybko system musi wrócić do pełnej sprawności po wystąpieniu awarii. Z perspektywy ekosystemu Kafki RTO odpowiada na pytania:

• Jak szybko producenci (producers) muszą przełączyć się na nowy klaster?
• Jak szybko konsumenci (consumers) wznowią przetwarzanie od właściwego miejsca?
• Czy dopuszczalne są działania manualne (operatora), czy wymagany jest automatyczny failover?
• Czy czas propagacji zmian w DNS (może trwać kilka minut) jest akceptowalny?

Niskie RTO w Kafce zależy od:

• Inteligentnych klientów: czy konfiguracja aplikacji obsługuje listę wielu klastrów,
• Replikacji offsetów: czy po przełączeniu na inny region konsumenci „wiedzą”, gdzie skończyli czytać,
• Orkiestracji failoveru: jak zautomatyzowany jest proces przełączania ruchu,
• Gotowości infrastruktury: czy zasoby w regionie zapasowym są już uruchomione (pre-provisioned).

Dążenie do ekstremalnie niskiego RTO zazwyczaj wymusza stosowanie architektury Active-Active, automatycznego failoveru lub tzw. klastrów rozciągniętych (Stretched Clusters).

Podstawy replikacji w Apache Kafka

Zanim zaprojektujesz architekturę Disaster Recovery (DR) obejmującą wiele regionów, musisz dokładnie zrozumieć gwarancje replikacji, jakie Kafka zapewnia w obrębie pojedynczego klastra. Wiele błędnych decyzji architektonicznych wynika z nieprawidłowych założeń dotyczących trwałości danych i spójności. Wyjaśnijmy zatem, co Kafka faktycznie gwarantuje i pod jakimi warunkami.

Gwarancje replikacji w obrębie klastra

Podstawą modelu wysokiej dostępności (HA) w Kafce jest replikacja partycji. Każda partycja tematu (topic) posiada repliki rozmieszczone na różnych brokerach:

• Replika lidera (leader) – obsługuje wszystkie operacje odczytu i zapisu.
• Repliki podrzędne (followers) – synchronicznie replikują dane od lidera.
• Replika typu observer – replika asynchroniczna (dostępna w dystrybucji Confluent); wrócimy do tego pojęcia później przy omawianiu klastrów typu 2.5-DC.

Lider wraz ze wszystkimi w pełni zsynchronizowanymi replikami follower tworzy zbiór In-Sync Replicas (ISR). Jeśli replika follower opóźnia się bardziej niż dopuszczają skonfigurowane progi, zostaje usunięta z ISR.

Gdy producent wysyła wiadomość, trwałość zapisu zależy od:

• współczynnika replikacji (replication factor, RF),
• konfiguracji potwierdzeń (acks),
• parametru min.insync.replicas,
• polityki wyboru lidera (leader election policy).

Rozbijmy to na czynniki pierwsze.

Replication Factor (RF)

Współczynnik replikacji określa, ile kopii każdej partycji istnieje w klastrze.

Przykład:

Replication factor = 3
 Partycja P0    →    Broker 1 (leader)
           Broker 2 (follower)
           Broker 3 (follower)

Jeśli jeden broker ulegnie awarii, Kafka może wybrać nowego lidera ze zbioru ISR. Jednak sam współczynnik replikacji nie gwarantuje braku utraty danych.

Potwierdzenia producenta (acks)

Gwarancje trwałości po stronie producenta zależą od poziomu potwierdzeń:

• acks=0 → brak gwarancji trwałości, producent nie czeka na żadne potwierdzenie.
• acks=1 → Potwierdzenie wysyła tylko lider (ryzyko utraty danych, jeśli lider padnie przed replikacją).
• acks=all (lub -1) → lider czeka na potwierdzenie od wszystkich replik znajdujących się aktualnie w ISR.

Zalecana konfiguracja dla systemów krytycznych:

• acks=all,
• min.insync.replicas ≥ 2,
• replication.factor ≥ 3.

Zapewnia to, że wiadomość zostanie zapisana na wielu brokerach przed wysłaniem potwierdzenia. Jednak nawet taka konfiguracja chroni jedynie w obrębie pojedynczego centrum danych.

Wybór lidera a ryzyko utraty danych

Gdy lider ulegnie awarii, Kafka wybiera nowego lidera ze zbioru ISR.

Jeśli:

unclean.leader.election.enable=false (zalecane)

Kafka wybierze nowego lidera wyłącznie spośród replik w pełni zsynchronizowanych (z ISR). Jeśli nie ma takich replik, partycja staje się niedostępna. To podejście przedkłada spójność danych nad dostępność.

Jeśli:

unclean.leader.election.enable=true

Kafka może wybrać nieaktualną replikę (spoza ISR). System pozostaje dostępny, ale dochodzi do utraty danych.

W systemach, w których priorytetem jest trwałość danych, a nie dostępność, należy wyłączyć unclean leader election.

Replikacja synchroniczna vs asynchroniczna

Przy przejściu do architektury wieloregionowej model replikacji w Kafce zmienia się fundamentalnie. W obrębie jednego klastra replikacja jest ściśle koordynowana przez kontroler, a gwarancje ISR są egzekwowane synchronicznie. W przypadku wielu regionów sytuacja zależy od wybranego modelu:

Asynchroniczna replikacja między regionami

Mechanizmy replikacji multi-region w Kafce, takie jak MirrorMaker 2, Confluent Replicator czy Cluster Linking, działają asynchronicznie.

W tym modelu proces replikacji przesyła dane z klastra głównego do klastra zapasowego. Oznacza to, że:

• występuje opóźnienie replikacji (replication lag),
• w przypadku awarii regionu najnowsze wiadomości mogą nie zostać zreplikowane,
• failover wymaga przekierowania klientów (producentów i konsumentów).

Zalety:

• niższe opóźnienia zapisu,
• lepsza dostępność niż w przypadku pojedynczego klastra w jednym regionie,
• lepsza wydajność niż przy replikacji synchronicznej.

Kompromisy: RPO i RTO rzadko są równe zero.

W kontekście Kafki, mówiąc o asynchronicznej replikacji między regionami, mamy najczęściej na myśli architektury active-active lub active-passive (wyjątkiem są repliki typu observer — patrz klastry typu 2.5-DC).

Synchroniczna replikacja między regionami

Replikacja synchroniczna oznacza, że wiadomość została potwierdzona dopiero po zapisaniu jej w wielu regionach. W praktyce oznacza to RPO = 0, czyli brak utraty danych w przypadku awarii regionu.

Jednak wiąże się to z istotnymi konsekwencjami:

• opóźnienia między regionami znacząco zwiększają czas zapisu,
• niestabilność sieci może wpływać na wydajność i/lub dostępność systemu.

W Kafce synchroniczna replikacja między regionami najczęściej oznacza wykorzystanie tzw. klastrów rozciągniętych (stretched clusters):

• Stretched Cluster 3-DC
• Stretched Cluster 2.5-DC (Confluent)

Przegląd architektur Disaster Recovery dla Kafki

Mając już jasno zdefiniowane wymagania RPO i RTO oraz rozumiejąc gwarancje replikacji wewnątrz klastra, możesz przejść do wyboru docelowej architektury Disaster Recovery.

Nie istnieje jedna „najlepsza” architektura multi-region. Wybór konkretnego wzorca to zawsze proces ważenia kompromisów pomiędzy:

• dostępnością (Availability),
• trwałością danych (Durability),
• opóźnieniami (Latency),
• złożonością operacyjną,
• kosztami infrastruktury.

Najczęściej spotykane architektury disaster recovery dla Kafki to:

• Active-Passive,
• Active-Active,
• Three Data Center (3-DC),
• 2.5-DC z replikami typu observer

Architektura Active-Passive w Kafce

W tym modelu jeden region pełni rolę główną (Primary) i obsługuje cały ruch produkcyjny. Drugi region pozostaje w trybie gotowości (Standby) i przejmuje zadania dopiero w momencie awarii.
Dane są przesyłane między regionami asynchronicznie przy użyciu narzędzi takich jak MirrorMaker 2, Confluent Replicator lub Cluster Linking.

Jak to działa w praktyce?

Wszyscy producenci i konsumenci łączą się wyłącznie z aktywnym klastrem. Klaster pasywny stale "zasysa" dane ze źródła, ale nie obsługuje żadnego ruchu zewnętrznego, dopóki nie zostanie zainicjowany proces failoveru.

Co dzieje się podczas awarii regionu?

Jeśli region A (Primary) ulegnie awarii:

• replikacja zostaje zatrzymana,
• ruch musi zostać przekierowany do regionu B — producenci i konsumenci muszą się ponownie połączyć,
• konieczne jest odtworzenie offsetów (w sposób zależny od użytego mechanizmu replikacji).

RPO = opóźnienie replikacji (replication lag)
RTO = czas wykrycia awarii + orkiestracja failoveru + ponowne połączenie klientów

Architektura active-passive jest dobrym punktem wyjścia dla rozwiązań multi-region, jednak należy pamiętać, że:

• możliwa jest utrata danych (ograniczona przez lag replikacji),
• failover może wymagać ręcznej interwencj i rekonfiguracji klientówi.

Zespół SRE musi zdecydować, kiedy — i czy w ogóle — rozpocząć failover, a te decyzje mają bezpośredni wpływ na spójność danych oraz konieczność ewentualnego replayu.

Architektura Active-Active w Kafce

Architektury active-active mają na celu zmniejszenie RTO, a potencjalnie także RPO, poprzez umożliwienie obsługi ruchu jednocześnie przez oba regiony.

W tej architekturze oba klastry przyjmują zapisy, a dane są replikowane dwukierunkowo — nadal jednak asynchronicznie. Każdy region obsługuje lokalny ruch, jednocześnie replikując dane do drugiego regionu.

Zalety:

• Lokalność danych: Klienci łączą się z geograficznie najbliższym regionem, co redukuje opóźnienia.
• Błyskawiczny failover: Jeśli jeden region padnie, drugi już działa i obsługuje ruch.
• Efektywność kosztowa: Infrastruktura w obu regionach pracuje na siebie, zamiast "czekać" na awarię.

Wyzwania:

Taka architektura często nie jest implementowana jako jeden współdzielony topic (np. orders), lecz jako zestaw topiców zależnych od regionu:

• dc1.orders,
• dc2.orders.

W takim podejściu lokalni producenci zapisują dane wyłącznie do lokalnego topicu, natomiast konsumenci odczytują dane z obu — lokalnego oraz „zdalnego”, zreplikowanego do lokalnego DC.

Konsumenci mogą korzystać z subskrypcji opartej na wyrażeniach regularnych, np. *.orders.

Takie podejście wprowadza jednak istotne problemy:

• brak globalnego porządku danych (dwa niezależne strumienie zamiast jednego),
• trudności przy migracji konsumentów podczas failoveru, w tym poprawne zarządzanie offsetami,
• partycje sieciowe, w których oba klastry mogą niezależnie przyjmować zapisy, prowadząc do rozbieżności danych.

Architektury active-active zapewniają bardzo wysoką dostępność, ale wymagają starannego zaprojektowania pod kątem:

• idempotencji,
• gwarancji kolejności przetwarzania,
• zarządzania offsetami.

Kafka w architekturze trzech centrów danych (3-DC)

Architektura 3-DC (znana jako Stretched Cluster) opiera się na zupełnie innym modelu. Zamiast łączyć oddzielne klastry za pomocą narzędzi do replikacji, tworzymy jeden logiczny klaster Kafki, którego węzły są fizycznie rozproszone pomiędzy trzy centra danych (lub strefy dostępności – AZ).

W tym modelu brokerzy oraz kontrolery (ZooKeeper lub KRaft) są rozmieszczeni tak, aby każde centrum danych posiadało ich reprezentację.

Przy odpowiedniej konfiguracji:

• każda partycja posiada repliki we wszystkich trzech DC,
• wybór lidera wymaga kworum — czyli większości (2 z 3) węzłów ZooKeeper lub kontrolerów KRaft,
• utrata jednego centrum danych nie zatrzymuje działania klastra,
• failover następuje automatycznie i jest niewidoczny dla klientów,
• nie jest wymagane tłumaczenie offsetów między klastrami.

Podsumowując – RPO i RTO mogą wynosić zero.

Wady

Oczywiście rozwiązanie to ma także swoje minusy:

• wysokie opóźnienia między centrami danych wpływają na wydajność zapisu — wymaga to stabilnych, niskolatencyjnych połączeń między DC; architektura ta najlepiej sprawdza się, gdy centra danych są geograficznie blisko siebie,
• większe wymagania sprzętowe (trzy centra danych),
• w środowiskach chmurowych replikacja między strefami/centrami danych może generować wysokie koszty.

Rozciąganie klastra Kafka na odległe regiony geograficzne (np. Europa i USA) zazwyczaj nie jest praktyczne ze względu na opóźnienia i kompromisy związane z dostępnością.

Architektura Kafka 2.5-DC

Architektura 2.5-DC jest wariantem modelu klastra rozciągniętego, ale z mniejszymi wymaganiami infrastrukturalnymi niż pełne wdrożenie 3-DC.

Naturalne pytanie brzmi: dlaczego nie użyć po prostu dwóch centrów danych?

Odpowiedź tkwi w kworum metadanych. Kafka (zarówno z ZooKeeperem, jak i KRaft) wymaga większości węzłów metadanych do wyboru liderów partycji i utrzymania spójności klastra. Oznacza to, że warstwa metadanych musi składać się z nieparzystej liczby węzłów głosujących.

W przypadku tylko dwóch lokalizacji, utrata jednej z nich oznacza utratę kworum. Aby uniknąć ryzyka rozspójnienia danych (split-brain), klaster automatycznie przestaje działać.

Architektura 2.5-DC rozwiązuje ten problem poprzez:

• rozmieszczenie warstwy metadanych w trzech centrach danych,
• przechowywanie danych tylko w dwóch centrach danych.

W praktyce oznacza to, że trzecie centrum danych zawiera zazwyczaj tylko jedną maszynę (lub VM) uruchamiającą pojedynczą instancję KRaft.

Co zyskujemy?

• dwa „pełne” centra danych (DC1 i DC2),
• jedną lekką lokalizację trzecią (DC3),
• DC3 uczestniczy w kworum, ale nie obsługuje ruchu danych — działa jako tzw. tiebreaker.

Przy odpowiedniej konfiguracji rozwiązanie to oferuje, podobnie jak architektura 3-DC:

• RPO = 0,
• RTO = 0.

Aby osiągnąć te właściwości, Confluent wprowadził dodatkowe mechanizmy wspierające ten model.

Repliki typu Observer w Kafce (tylko Confluent)

Replika typu observer to specjalny rodzaj repliki dostępny w dystrybucjach Confluent.

Observer:

• replikuje dane asynchronicznie,
• nie należy do zbioru ISR
• nie obsługuje ruchu klientów,
• nie wpływa na opóźnienia zapisu w taki sposób jak pełne repliki.

Repliki observer pozwalają zwiększyć trwałość danych oraz elastyczność rozmieszczenia replik bez zwiększania wymagań dotyczących kworum zapisu.

Automatyczna promocja observerów

Observerzy mogą być automatycznie promowani do pełnych replik, gdy zajdzie taka potrzeba. Najczęstszy przypadek to sytuacja, gdy liczba replik w ISR spadnie poniżej skonfigurowanej wartości min.insync.replicas (min ISR).

W takim scenariuszu:

• observer nadrabia zaległości względem lidera,
• zostaje promowany do pełnej repliki,
• dołącza do ISR, przywracając wymagane gwarancje replikacji.

Gdy uszkodzony follower wróci do działania i ponownie dołączy do ISR, observer może powrócić do swojej pierwotnej roli.

Mechanizm ten pozwala utrzymać możliwość zapisu nawet w przypadku częściowych awarii. Aby w pełni zrozumieć jego znaczenie, musimy przyjrzeć się jeszcze jednemu zagadnieniu.

Ograniczenia rozmieszczenia replik (Confluent Placement Constraints)

Confluent umożliwia definiowanie ograniczeń rozmieszczenia replik na poziomie topicu. Pozwala to kontrolować:

• ile replik znajduje się w każdym centrum danych,
• ile observerów znajduje się w każdym centrum danych,
• kiedy observerzy powinni być promowani do pełnych replik.

Dlaczego potrzebujemy observerów i kontrolowanego rozmieszczenia? Załóżmy, że mamy 6 brokerów w 2 centrach danych (po 3 brokery w każdym). Pojawia się pytanie: jaki ustawić Replication Factor i min ISR?

Dla środowisk produkcyjnych Confluent zazwyczaj rekomenduje min.insync.replicas = 3, więc przyjmijmy to jako punkt wyjścia.

Scenariusz 1

• RF=4,
• min.isr = 3,
• brak observerów
• brak ograniczeń rozmieszczenia

W tym przypadku nie mamy gwarancji, że zapisy są potwierdzane w obu centrach danych.

Ponieważ min.isr = 3, możliwe jest, że wszystkie trzy potwierdzenia pochodzą z replik znajdujących się w jednym DC. To stwarza ryzyko utraty danych, jeśli to centrum danych ulegnie awarii tuż po zapisie.

Scenariusz 2

• RF=6,
• min.isr = 4,
• brak observerów
• brak ograniczeń rozmieszczenia

W tym scenariuszu zapisy zawsze trafiają do replik w obu DC (np. rozkład 2+2 lub 3+1).

Problem pojawia się jednak w przypadku awarii jednego DC.

Jeśli jedno centrum danych przestanie działać, pozostają tylko 3 brokery. Przy min.isr = 4 zapisy nie mogą być kontynuowane — klaster przestaje przyjmować dane.

Scenariusz 3

• RF=6,
• min.isr = 3,
• brak observerów
• brak ograniczeń rozmieszczenia

Ten scenariusz jest podobny do scenariusza 1. Mimo że repliki znajdują się w obu DC, nie ma gwarancji, że potwierdzenia zapisu będą pochodziły z obu lokalizacji. Trwałość między centrami danych nie jest wymuszona.

Scenariusz 4

• RF=6,
• min.isr = 3,
• 2 obserwery
• jawnie zdefiniowane ograniczenia rozmieszczenia replik

Przykładowa konfiguracja:

{
    "version": 2,
    "replicas": [
        {
            "count": 2,
            "constraints": {
                "rack": "dc1"
            }
        },
        {
            "count": 2,
            "constraints": {
                "rack": "dc2"
            }
        }
    ],
    "observers": [
      {
          "count": 1,
          "constraints": {
              "rack": "dc1"
          }
      },
      {
          "count": 1,
          "constraints": {
              "rack": "dc2"
          }
      }
    ],
    "observerPromotionPolicy":"under-min-isr"
}

W tej konfiguracji każde centrum danych zawiera:

• dwie repliki synchroniczne,
• jednego observera.

Daje to:

• DC1: leader, follower, observer
• DC2: dwa followery, observer

Podczas normalnej pracy:

• zapis wymaga potwierdzenia od co najmniej trzech replik (min.isr = 3),
• ograniczenia rozmieszczenia zapewniają, że repliki są rozłożone między oba DC.

W przypadku awarii całego centrum danych:

• observer w ocalałym DC zostaje promowany do pełnej repliki,
• ISR zostaje przywrócony do wymaganej liczby,
• zapisy mogą być kontynuowane bez naruszania gwarancji trwałości.

To podejście zapewnia wysoką trwałość danych przy jednoczesnym zachowaniu możliwości zapisu zarówno w przypadku częściowych, jak i pełnych awarii centrów danych.

Read also: Understanding in-sync replicas and replication factor in Confluent Stretched Cluster 2.5

Mechanizmy replikacji Kafka w architekturach multi-region

Projektowanie architektury wieloregionowej dla Kafki to układanka z wieloma zmiennymi. Jeśli zdecydujesz się na model Active-Passive lub Active-Active, przed Tobą najważniejszy wybór: jak fizycznie przesyłać dane między klastrami?

Warto pamiętać, że replikacja między regionami nie jest wbudowana w silnik Apache Kafka w ten sam sposób, co replikacja wewnątrz klastra. Realizuje się ją za pomocą zewnętrznych narzędzi lub dedykowanych funkcji platformowych.

Najczęściej spotykane rozwiązania to:

• MirrorMaker 2,
• Confluent Replicator,
• Cluster Linking (Confluent).

MirrorMaker 2

MirrorMaker 2 (MM2) to standardowe rozwiązanie open source do replikacji między klastrami Kafka. Jest zbudowane na bazie Kafka Connect i zostało wprowadzony jako ulepszenie oryginalnego MirrorMaker.

MirrorMaker 2 konsumuje dane z topiców w klastrze źródłowym i publikuje je w klastrze docelowym, podobnie jak standardowe konektory Source i Sink w Kafka Connect. Replikacja jest asynchroniczna, a korzystanie z MM2 wymaga uruchomienia i monitorowania klastra Kafka Connect.

Największym wyzwaniem przy pracy z MirrorMaker 2 jest zarządzanie offsetami konsumentów. Zreplikowane wiadomości w klastrze docelowym mają inne offsety niż w klastrze źródłowym. Dla zdecydowanej większości przypadków stanowi to poważną trudność. Nie można bowiem łatwo przepiąć konsumenta z klastra A na klaster B i mieć pewność że wznowi pracę dokładnie w tym samym punkcie.

Confluent Replicator

Confluent Replicator działa podobnie do MirrorMaker 2, ale jest komercyjnym rozwiązaniem dostarczanym przez Confluent. Również opiera się na Kafka Connect i jest ściśle zintegrowany z ekosystemem Confluent.

W porównaniu do MirrorMaker 2 Replicator zapewnia:

• Wsparcie Enterprise: Pełna integracja z Control Center i wsparcie techniczne.
• Automatyzacje: Lepiej radzi sobie z replikacją metadanych tematów (konfiguracje, ACL-e).

Ma jednak swoje ograniczenia: podobnie jak MM2, jest to replikacja asynchroniczna, wymagająca utrzymywania dodatkowej warstwy infrastruktury (Connect).

Cluster Linking

Cluster Linking to kolejny mechanizm replikacji oferowany przez Confluent, ale działa on w zasadniczo inny sposób. W przeciwieństwie do MirrorMaker 2 czy Replicatora, Cluster Linking jest wbudowany bezpośrednio w brokery Confluent Platform.

Oznacza to, że:

• nie jest wymagany osobny klaster Kafka Connect,
• replikacja jest zarządzana na poziomie brokerów.

Cluster Linking:

• replikuje topiki bezpośrednio na poziomie brokera,
• zachowuje tożsamość topiców,
• zachowuje offsety,
• działa szybciej niż Replicator.

Eliminując potrzebę stosowania zewnętrznych konektorów replikacyjnych, Cluster Linking upraszcza architekturę i usuwa jedną z największych trudności operacyjnych związanych z MirrorMaker 2 - replikację offsetów w consumer grupach.

W przypadku wdrożeń opartych o Confluent Platform lub Confluent Cloud, Cluster Linking jest zazwyczaj rekomendowanym mechanizmem replikacji zamiast Confluent Replicator.

Offsets a Disaster Recovery

Zarządzanie offsetami podczas awarii jest jednym z największych wyzwań zarówno w architekturach active-passive, jak i active-active.

Jak wspomniano wcześniej, MirrorMaker 2 oraz Confluent Replicator zmieniają offsety wiadomości podczas procesu replikacji. Cluster Linking nie ma tej konkretnej wady, ale nadal istnieje istotne ograniczenie: wszystkie te mechanizmy działają asynchronicznie, co oznacza, że utrata danych jest możliwa.

Jak dochodzi do utraty danych? (Scenariusz awarii)

Rozważmy następujący scenariusz.

Mamy dwa regiony:

• Region A (główny)
• Region B (zapasowy)

Replikacja odbywa się przy użyciu Cluster Linking.

1. Region A zawiera 1000 wiadomości.
2. Region B zreplikował tylko 950 wiadomości (ze względu na lag replikacji).
3. Region A ulega awarii.
4. Następuje failover do regionu B.
5. W regionie B zaczynają być zapisywane nowe wiadomości pod offsetami 951, 952 itd.
6. Region A zostaje przywrócony.
7. Chcemy wrócić (failback) do regionu A.

W tym momencie Cluster Linking ponownie zsynchronizuje dane. Jednak oryginalne wiadomości w regionie A o offsetach od 951 do 1000 mogą zostać nadpisane przez nowsze wiadomości zapisane w regionie B.

Efekt: utrata około 50 wiadomości.

Dokładna liczba utraconych wiadomości zależy od opóźnienia replikacji między regionami w momencie awarii.

Jak zapobiec utracie danych?

1. Wybór innej architektury

Można zastosować architekturę zapewniającą synchroniczną replikację między regionami (np. stretched cluster). Znacząco ogranicza to lub eliminuje utratę danych kosztem większych opóźnień i wyższej złożoności operacyjnej.

2. Kontrolowany mechanizm replay

Jeśli konieczna jest replikacja asynchroniczna, potrzebny jest dodatkowy mechanizm zabezpieczający na czas failoveru.

Jednym z praktycznych podejść jest wprowadzenie kontrolowanego okna replay po stronie producenta.

W tym modelu:

• aplikacje produkcyjne przechowują ostatnie X wysłanych wiadomości (gdzie X jest większe niż maksymalny oczekiwany lag replikacji),
• po failoverze lub failbacku producenci mogą odtworzyć te wiadomości na żądanie.

To podejście wymaga:

• aby konsumenci byli idempotentni,
• aby systemy downstream tolerowały duplikaty.

Przenosi ono część odpowiedzialności z infrastruktury na logikę aplikacji, ale znacząco zwiększa odporność na utratę danych wynikającą z opóźnień replikacji.

Testowanie Disaster Recovery dla Kafki

Zaprojektowanie architektury typu Active-Passive, Active-Active czy 2.5-DC „na papierze” to dopiero połowa sukcesu. Architektura definiuje intencję, ale to testy weryfikują rzeczywistość. Bez regularnych ćwiczeń, Twój plan DR jest jedynie hipotezą, która może zawieść w najmniej odpowiednim momencie.

Musisz mieć pewność, że system zachowuje się zgodnie z założonymi wartościami RPO i RTO. Oznacza to świadome i kontrolowane wywoływanie scenariuszy awaryjnych.

Zacznij od awarii częściowych

Zanim „wyłączysz” cały region, przetestuj mniejsze zakłócenia w obrębie klastra:

• Awarie brokerów i dysków,
• Wymuszone re-elekcje liderów partycji,
• Awarie kontrolerów KRaft,
• Nieudane restarty kroczące (rolling restarts).

Te testy zweryfikują sprawność replikacji wewnętrznej i Twoją gotowość operacyjną do reagowania na codzienne incydenty.

Scenariusze o dużym wpływie (Cross-Region)

Kolejnym krokiem są testy związane z replikacją między regionami:

• tymczasowe pogorszenie jakości połączenia między regionami,
• całkowita utrata łączności między centrami danych,
• awarie procesów replikacji,
• przerwy w działaniu Kafka Connect lub Cluster Linking.

Scenariusze te ujawniają zachowanie systemu w kontekście lagów replikacji, synchronizacji offsetów oraz ponownego łączenia klientów.

Pełnoskalowe scenariusze katastroficzne

Na samym końcu zasymuluj „najgorsze”:

• awaria całej strefy dostępności,
• całkowita awaria centrum danych,
• nagła utrata głównego regionu.

Dopiero te testy dadzą Ci odpowiedź na pytanie, czy Twoja architektura faktycznie spełnia obietnicę ciągłości działania.

Dla każdego scenariusza należy:

• od strony biznesu określić rzeczywiste RPO i RTO,
• zmierzyć rzeczywiste RTO (czas pełnego powrotu producentów i konsumentów do działania),
• zweryfikować poprawność offsetów konsumentów,
• przeprowadzić udokumentowane procedury failoveru,
• wykonać proces przywracania i powrotu (failback),
• dokonać analizy wyników wyciągając wnioski co do konfiguracji, wymagań, procedur, metodyki testowania oraz potencjalnie architektury systemu.

Równie ważne jest przećwiczenie:

• przełączania ruchu (DNS, load balancery, service mesh),
• migracji grup konsumenckich,
• walidacji offsetów lub mechanizmów ich cofania (rewind),
• odbudowy i reintegracji klastra.

Plan disaster recovery jest wiarygodny tylko wtedy, gdy został przećwiczony end-to-end. Nie wystarczy testować samego failoveru – należy również testować procesy odzyskiwania i przywracania systemu cyklicznie weryfikując założenia planu z rzeczywistymi wynikami.

Podsumowanie i najważniejsze wnioski

Projektowanie disaster recovery oraz architektur multi-region dla Apache Kafka nie polega na włączeniu replikacji i liczeniu na to, że wszystko będzie działać. Chodzi o świadome podejmowanie kompromisów pomiędzy:

• RPO i RTO,
• opóźnieniami a trwałością danych,
• złożonością a dojrzałością operacyjną,
• kosztami a odpornością systemu.

Każdy wzorzec architektoniczny — active-passive, active-active, 3-DC czy 2.5-DC — rozwiązuje inny problem. Żaden z nich nie jest uniwersalnie najlepszy.

Właściwe rozwiązanie zależy od:

• wymagań dotyczących ciągłości działania,
• tolerancji na utratę danych,
• oczekiwanego czasu odzyskiwania,
• możliwości operacyjnych zespołu.

Co najważniejsze, disaster recovery to nie konfiguracja – to praktyka.

Wymaga ona:

• świadomych decyzji architektonicznych,
• zdyscyplinowanej konfiguracji,
• obserwowalności,
• automatyzacji,
• oraz regularnych ćwiczeń failoveru.

Kafka bardzo często staje się fundamentem systemów krytycznych dla biznesu. Traktowanie strategii disaster recovery jako sprawy drugorzędnej jest jednym z najdroższych błędów architektonicznych, jakie organizacja może popełnić.

Potrzebujesz pomocy w zaprojektowaniu lub weryfikacji architektury DR dla Kafki?

Zaprojektowanie produkcyjnej architektury multi-region dla Kafki oraz zweryfikowanie, że faktycznie spełnia ona założenia RPO i RTO, wymaga zarówno wiedzy o systemach rozproszonych, jak i doświadczenia operacyjnego.

W SoftwareMill, jako Confluent Elite Partner, pomagamy organizacjom:

• projektować strategie disaster recovery dla Kafki (zarówno open source, jak i Confluent Platform),
• wdrażać architektury multi-region (w tym 3-DC i 2.5-DC),
• weryfikować procedury failoveru,
• bezpiecznie migrować między klastrami i regionami,
• przeprowadzać realistyczne testy disaster recovery.

Jeśli planujesz wdrożenie multi-region dla Kafki lub chcesz przeanalizować swoją obecną strategię disaster recovery, skontaktuj się z nami.

Chętnie pomożemy Ci upewnić się, że Twoja architektura działa nie tylko na diagramach, ale również w rzeczywistych warunkach awarii.

Recenzja wykonana przez Bartłomiej Rekke