{"id":32632,"date":"2019-10-31T21:48:08","date_gmt":"2019-10-31T18:48:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo\/"},"modified":"2019-10-31T21:48:08","modified_gmt":"2019-10-31T18:48:08","slug":"ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/ne-tolko-obrabotka-kak-my-sdelali-iz-kafka-streams-raspredelennuyu-bazu-dannyh-i-chto-iz-etogo-vyshlo","title":{"rendered":"Nie tylko przetwarzanie: Jak zrobili\u015bmy z Kafka Streams rozproszon\u0105 baz\u0119 danych i co z tego wynik\u0142o","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107, Habr!<\/p>\n

Przypominamy, \u017ce po ksi\u0105\u017cce o Kafka<\/a><\/noindex> opublikowali\u015bmy nie mniej interesuj\u0105c\u0105 prac\u0119 o bibliotece Kafka Streams API<\/a><\/noindex>. <\/p>\n

\"Nie
\n
\nNa razie spo\u0142eczno\u015b\u0107 dopiero odkrywa granice mo\u017cliwo\u015bci tego pot\u0119\u017cnego narz\u0119dzia. Niedawno ukaza\u0142 si\u0119 artyku\u0142, z t\u0142umaczeniem kt\u00f3rego chcemy Pa\u0144stwa zapozna\u0107. Autor opisuje na swoim do\u015bwiadczeniu, jak stworzy\u0107 z Kafka Streams rozproszone magazyn danych. Mi\u0142ej lektury!
\n<\/a><\/noindex>
\nBiblioteka Apache Kafka Streams<\/a><\/noindex> jest u\u017cywana na ca\u0142ym \u015bwiecie w przedsi\u0119biorstwach do rozproszonego przetwarzania strumieniowego na bazie Apache Kafka. Jednym z niedocenianych aspekt\u00f3w tego frameworka jest to, \u017ce pozwala na utrzymywanie lokalnego stanu, generowanego na podstawie przetwarzania strumieniowego.<\/p>\n

W tym artykule opowiem, jak w naszej firmie uda\u0142o si\u0119 efektywnie wykorzysta\u0107 t\u0119 mo\u017cliwo\u015b\u0107 przy opracowywaniu produktu dotycz\u0105cego bezpiecze\u0144stwa aplikacji w chmurze. Przy pomocy Kafka Streams stworzyli\u015bmy mikroserwisy z dzielonym stanem, z kt\u00f3rych ka\u017cdy jest dla nas odporno\u015bci\u0105 na awarie oraz wysoko dost\u0119pnym \u017ar\u00f3d\u0142em wiarygodnych informacji o stanie obiekt\u00f3w w systemie. To krok naprz\u00f3d zar\u00f3wno pod wzgl\u0119dem niezawodno\u015bci, jak i wygody wsparcia.<\/p>\n

Je\u015bli interesuje Pa\u0144stwa alternatywne podej\u015bcie, kt\u00f3re umo\u017cliwia wykorzystanie jednego centralnego bazy danych do wsparcia formalnego stanu Pa\u0144stwa obiekt\u00f3w \u2013 przeczytajcie, warto\u2026 <\/p>\n

Dlaczego uznali\u015bmy, \u017ce nadszed\u0142 czas na zmian\u0119 naszych podej\u015b\u0107 do pracy z dzielonym stanem <\/b><\/p>\n

Musieli\u015bmy utrzymywa\u0107 stan r\u00f3\u017cnych obiekt\u00f3w, opieraj\u0105c si\u0119 na raportach agent\u00f3w (np. czy strona by\u0142a atakowana?). Przed przej\u015bciem na Kafka Streams cz\u0119sto polegali\u015bmy na zarz\u0105dzaniu stanem za pomoc\u0105 jednej centralnej bazy danych (+ API us\u0142ugowe). Takie podej\u015bcie ma swoje wady: w sytuacjach intensywnych danych<\/a><\/noindex> utrzymanie sp\u00f3jno\u015bci i synchronizacji staje si\u0119 prawdziwym wyzwaniem. Baza danych mo\u017ce sta\u0107 si\u0119 w\u0105skim gard\u0142em lub znajdowa\u0107 si\u0119 w stanie wy\u015bcigu<\/a><\/noindex> i cierpie\u0107 z powodu nieprzewidywalno\u015bci.<\/p>\n

\"Nie
\n
\nIlustracja 1: typowy scenariusz z podzia\u0142em stanu, kt\u00f3re wyst\u0119powa\u0142y przed przej\u015bciem na
\nKafka i Kafka Streams: agenci przekazuj\u0105 swoje reprezentacje przez API, zaktualizowany stan jest obliczany za pomoc\u0105 centralnej bazy danych. <\/i><\/p>\n

Poznajcie Kafka Streams \u2013 tworzenie mikroserwis\u00f3w z dzielonym stanem sta\u0142o si\u0119 proste. <\/b><\/p>\n

Oko\u0142o rok temu postanowili\u015bmy dok\u0142adnie przeanalizowa\u0107 nasze scenariusze pracy z dzielonym stanem, aby rozwi\u0105za\u0107 pewne problemy. Od razu postanowili\u015bmy wypr\u00f3bowa\u0107 Kafka Streams \u2013 wiadomo, jak bardzo jest skalowalna, wysoko dost\u0119pna i odporna na b\u0142\u0119dy oraz jak bogate ma funkcjonalno\u015bci strumieniowe (przekszta\u0142cenia, w tym z zachowaniem stanu). Dok\u0142adnie to, czego potrzebowali\u015bmy, nie wspominaj\u0105c o tym, jak dojrza\u0142ym i niezawodnym systemem wymiany wiadomo\u015bci jest Kafka.<\/p>\n

Ka\u017cdy z naszych stworzonych mikroserwis\u00f3w z zachowaniem stanu oparty by\u0142 na instancji Kafka Streams z do\u015b\u0107 prost\u0105 topologi\u0105. Sk\u0142ada\u0142a si\u0119 ona z 1) \u017ar\u00f3d\u0142a 2) procesora z trwa\u0142ym magazynem kluczy i warto\u015bci 3) odcinka:<\/p>\n

\"Nie
\n
\nIlustracja 2: domy\u015blna topologia naszych instancji strumieniowych dla mikroserwis\u00f3w z zachowaniem stanu. Zauwa\u017c, \u017ce znajduje si\u0119 tutaj tak\u017ce magazyn, w kt\u00f3rym przetrzymywane s\u0105 metadane dotycz\u0105ce harmonogramowania. <\/i><\/p>\n

W tym nowym podej\u015bciu agenci tworz\u0105 wiadomo\u015bci wprowadzane do pocz\u0105tkowego tematu, a konsumenci \u2013 na przyk\u0142ad, us\u0142uga powiadomie\u0144 e-mail \u2013 odbieraj\u0105 obliczony dzielony stan przez odcinek (temat wyj\u015bciowy).<\/p>\n

\"Nie
\n
\nIlustracja 3: nowy przyk\u0142ad strumienia zada\u0144 dla scenariusza z dzielonymi mikroserwisami: 1) agent generuje wiadomo\u015b\u0107, kt\u00f3ra trafia do pocz\u0105tkowego tematu Kafka; 2) mikroserwis z dzielonym stanem (u\u017cywaj\u0105cy Kafka Streams) przetwarza j\u0105 i zapisuje obliczony stan w ko\u0144cowym temacie Kafka; po czym 3) konsumenci odbieraj\u0105 nowy stan.<\/i><\/p>\n

Hej, a to wbudowane magazyn kluczy i warto\u015bci jest naprawd\u0119 bardzo przydatne!<\/b><\/p>\n

Jak wspomniano wcze\u015bniej, nasza topologia z dzielonym stanem zawiera magazyn kluczy i warto\u015bci. Znale\u017ali\u015bmy kilka sposob\u00f3w jego wykorzystania, z kt\u00f3rych dwa opisane s\u0105 poni\u017cej.<\/p>\n

Opcja #1: wykorzystanie magazynu kluczy i warto\u015bci w obliczeniach.<\/b><\/i><\/p>\n

Nasze pierwsze magazyn kluczy i warto\u015bci zawiera\u0142 dane pomocnicze potrzebne do naszych oblicze\u0144. Na przyk\u0142ad, w niekt\u00f3rych przypadkach wsp\u00f3\u0142dzielony stan by\u0142 okre\u015blany na zasadzie \u201ewi\u0119kszo\u015bci g\u0142os\u00f3w\u201d. W magazynie mo\u017cna by\u0142o przechowywa\u0107 wszystkie ostatnie raporty agent\u00f3w dotycz\u0105ce stanu pewnego obiektu. Nast\u0119pnie, otrzymuj\u0105c nowy raport od danego agenta, mogli\u015bmy go zapisa\u0107, wydoby\u0107 z magazynu raporty wszystkich innych agent\u00f3w dotycz\u0105ce tego samego obiektu i powt\u00f3rzy\u0107 obliczenia.
\nNa poni\u017cszej ilustracji 4 pokazano, jak otwierali\u015bmy dost\u0119p do magazynu kluczy i warto\u015bci metodzie przetwarzaj\u0105cej procesora, dzi\u0119ki czemu mo\u017cna by\u0142o przetworzy\u0107 now\u0105 wiadomo\u015b\u0107.<\/p>\n

\"Nie
\n
\nIlustracja 4: otwieramy dost\u0119p do magazynu kluczy i warto\u015bci dla przetwarzaj\u0105cej metody procesora (po tym ka\u017cdy scenariusz operuj\u0105cy na wsp\u00f3\u0142dzielonym stanie musi zaimplementowa\u0107 metod\u0119 doProcess<\/code>)<\/i><\/p>\n

Opcja #2: tworzenie API CRUD na bazie Kafka Streams<\/b><\/i><\/p>\n

Po ustabilizowaniu naszego podstawowego strumienia zada\u0144 zacz\u0119li\u015bmy pr\u00f3bowa\u0107 napisa\u0107 RESTful CRUD API dla naszych mikroserwis\u00f3w z wsp\u00f3\u0142dzielonym stanem. Chcieli\u015bmy, aby mo\u017cna by\u0142o pobiera\u0107 stan niekt\u00f3rych lub wszystkich obiekt\u00f3w, a tak\u017ce ustawia\u0107 lub usuwa\u0107 stan obiektu (co jest przydatne w przypadku utrzymania backendu).<\/p>\n

Aby zapewni\u0107 wsparcie dla wszystkich API Get State, za ka\u017cdym razem, gdy musieli\u015bmy ponownie oblicza\u0107 stan podczas przetwarzania, przez d\u0142ugi czas przechowywali\u015bmy go w wbudowanym magazynie kluczy i warto\u015bci. W takim przypadku wystarczy zaimplementowa\u0107 takie API za pomoc\u0105 jednego wyst\u0105pienia Kafka Streams, jak pokazano w poni\u017cszym kodzie:<\/p>\n

\"Nie
\n
\nIlustracja 5: u\u017cycie wbudowanego magazynu kluczy i warto\u015bci do uzyskania wcze\u015bniej obliczonego stanu obiektu <\/i><\/p>\n

Aktualizacja stanu obiektu przez API r\u00f3wnie\u017c jest \u0142atwa do zrealizowania. W zasadzie, aby to zrobi\u0107, trzeba tylko stworzy\u0107 producenta Kafka, a za jego pomoc\u0105 dokona\u0107 zapisu zawieraj\u0105cego nowy stan. Dzi\u0119ki temu zapewniono, \u017ce wszystkie wiadomo\u015bci generowane przez API b\u0119d\u0105 przetwarzane dok\u0142adnie w taki sam spos\u00f3b, jak te pochodz\u0105ce od innych producent\u00f3w (np. agent\u00f3w).<\/p>\n

\"Nie
\n
\nIlustracja 6: stan obiektu mo\u017cna ustawi\u0107 za pomoc\u0105 producenta Kafka <\/i><\/p>\n

Ma\u0142e komplikacje: Kafka ma wiele partycji<\/b><\/p>\n

Nast\u0119pnie chcieli\u015bmy roz\u0142o\u017cy\u0107 obci\u0105\u017cenie zwi\u0105zane z przetwarzaniem i poprawi\u0107 dost\u0119pno\u015b\u0107, dostarczaj\u0105c dla ka\u017cdego scenariusza klaster mikroserwis\u00f3w ze wsp\u00f3\u0142dzielonym stanem. Konfiguracja okaza\u0142a si\u0119 dla nas dziecinnie prosta: po skonfigurowaniu wszystkich instancji tak, aby pracowa\u0142y z tym samym ID aplikacji (i tymi samymi serwerami pocz\u0105tkowymi), praktycznie wszystko pozosta\u0142e odbywa\u0142o si\u0119 automatycznie. Ustalili\u015bmy r\u00f3wnie\u017c, \u017ce ka\u017cdy temat \u017ar\u00f3d\u0142owy b\u0119dzie sk\u0142ada\u0142 si\u0119 z kilku partycji, aby ka\u017cdej instancji przypisa\u0107 podzbi\u00f3r takich partycji.<\/p>\n

Warto r\u00f3wnie\u017c wspomnie\u0107, \u017ce tutaj w porz\u0105dku rzeczy jest tworzenie kopii zapasowej magazynu stan\u00f3w, aby na przyk\u0142ad w przypadku przywracania po awarii przenie\u015b\u0107 t\u0119 kopi\u0119 na inn\u0105 instancj\u0119. Dla ka\u017cdego magazynu stan\u00f3w w Kafka Streams tworzony jest replicable topic z dziennikiem zmian (w kt\u00f3rym \u015bledzone s\u0105 lokalne aktualizacje). W ten spos\u00f3b Kafka ci\u0105gle zabezpiecza magazyn stan\u00f3w. Dlatego w przypadku awarii danej instancji, magazyn stan\u00f3w Kafka Streams mo\u017ce by\u0107 szybko przywr\u00f3cony na innej instancji, na kt\u00f3r\u0105 przenios\u0105 si\u0119 odpowiednie partycje. Nasze testy pokaza\u0142y, \u017ce trwa to zaledwie kilka sekund, nawet je\u015bli w magazynie znajduj\u0105 si\u0119 miliony wpis\u00f3w.<\/p>\n

Przechodz\u0105c od jednego mikroserwisu ze wsp\u00f3\u0142dzielonym stanem do klastra mikroserwis\u00f3w, wdro\u017cenie Get State API nie jest ju\u017c tak trywialne. W nowej sytuacji w magazynie stan\u00f3w ka\u017cdego mikroserwisu znajduje si\u0119 tylko cz\u0119\u015b\u0107 og\u00f3lnego obrazu (te obiekty, kt\u00f3rych klucze by\u0142y mapowane na konkretn\u0105 partycj\u0119). Musieli\u015bmy okre\u015bli\u0107, na kt\u00f3rej instancji znajdowa\u0142 si\u0119 stan poszukiwanego obiektu, co robili\u015bmy na podstawie metadanych strumieni, jak pokazano poni\u017cej:<\/p>\n

\"Nie
\n
\nIlustracja 7: przy pomocy metadanych strumieni okre\u015blamy, z kt\u00f3rej instancji \u017c\u0105da\u0107 stanu poszukiwanego obiektu; podobne podej\u015bcie stosowane by\u0142o z GET ALL API.<\/i><\/p>\n

G\u0142\u00f3wne wnioski<\/b><\/p>\n

Magazyny stan\u00f3w w Kafka Streams de facto mog\u0105 s\u0142u\u017cy\u0107 jako rozproszona baza danych, <\/p>\n