Transkrypcja
Wstęp
Cześć, Wojtek.
Cześć, Michał.
Witamy w nowym odcinku zatytułowanym „O Kafce przy kawce”.
Masz kawkę?
Mam kawkę.
No to o co w niej chodzi?
No jest smaczna, daje nam dużo energii.
No i musi być przy kodowaniu. Dobra, ale wszyscy tak o tej Kafce mówią. Gdzie by nie spojrzeć, to Kafka, Kafka. Jak gdzieś jest jakiś broker, to gdzie tam Królika [RabbitMQ] dawać, albo ActiveMQ to już chyba wszyscy zapomnieli. Nie wiem, czy wszyscy, ale tak w nowych projektach to raczej ciężko spotkać takie wynalazki. Ale Kafkę to tak raczej łatwo.
Każdy chętnie, albo przynajmniej każdy chętnie by ją wziął.
I to na tej zasadzie, że: „bo jeszcze nie mam w CV”.
No właśnie, jeśli to jest nasz jedyny powód, to może być za mało powodów i rzeczywiście niewystarczająca przesłanka…
Dlaczego warto zainteresować się Kafką?
…no bo tak naprawdę, wiadomo, każdy deweloper, każdy pracujący przy projektach chce mieć i używać jak najnowocześniejszych rozwiązań. I ta Kafka gdzieś tam bryluje na konferencjach, w różnych materiałach i gdzie czytamy. Jak gdzieś każdy chciałby tego użyć, ale właśnie pojawia się pytanie, dlaczego ja właściwie tej Kafki powinienem użyć? I tu są takie dwa wymiary takich zastosowań i aspektów. Po pierwsze technicznie – co by mi to pomogło w takim technicznym aspekcie. I tu możemy sobie pewne rzeczy wylistować i zaraz sobie powiemy. Ale też druga rzecz – jeśli nie mamy jeszcze Kafki w naszej firmie czy w naszej organizacji, no to pytanie, co ta Kafka nam da w takim wymiarze bardziej biznesowym, czyli dosłownie streszczenie dla kierownictwa, dlaczego potrzebujemy na przykład tej Kafki właśnie. Bo to też generalnie chyba sprowadza się do tego, że jako inżynierowie nie do końca potrafią sprzedawać.
Albo w ogóle.
Albo też w ogóle, bo też nie od tego są oczywiście. Ale pewne dobre pomysły trzeba troszkę sprzedać i gdzieś tam na górze powiedzieć takie bardziej nietechniczne powody, dlaczego tę albo inną technologię warto użyć. No bo to nie tylko Kafki się tyczy, to oczywiście tyczy się szerszego spektrum. To sobie bierzemy z Mavena, z npma i lecimy, i nikogo to nie interesuje, że to jest wersja 0.0.1, lecimy na produkcję z tym i tyle.
Nie no, czasem interesuje.
No czasem tak.
Musiałem takie audyty robić nawet kiedyś.
Tak, oczywiście w większych organizacjach oczywiście to interesuje.
No ale do prototypowania to bierzemy jak leci i później się tam popatrzy. Coś się wymyśli, nie? Ale taką Kafkę… Ona się tak kojarzyła kiedyś na pewno, może teraz już troszkę mniej, z takim wielkim ustrojstwem, ciężkim, dużym i takim trochę… trochę taką armatą, z której strzelać można by było w jakimś prostym projekcie do komara, nie? W sensie, tak trochę tak wyglądałaby jak taka armata, z której strzelamy do komara, bo ten problem to taka niewielka rzecz jest, nie? A jednak tą Kafkę ludzie biorą i próbują nawet w jakichś mniejszych rzeczach umieszczać.
Czyli w te komary strzelać. No właśnie, tak. No bo pytanie, to jeśli nie mamy jej w CV, czy warto ją użyć?
No to też nie jest takie bez sensu, bo jak jej nie mamy w CV, to może warto ją w końcu mieć, bo przecież w tych ofertach, które spływają, to jednak smutne Kafki.
Oczywiście, to jest jak najbardziej powód zasadny. To nie jest…
To jak nie mam w CV, to zaraz będę miał.
Zaraz będziemy mieli. Innym powodem oczywiście może być to, że jakiś tam team obok tego używa, a u nas w projekcie tego jeszcze nie ma. Na przykład mamy tę Kafkę w organizacji, więc możemy sobie ją użyć, jest hostowana w ten czy inny sposób, i na przykład inne teamy używają Kafki, a my nie mamy tego. No bo u nas nie, bo ktoś powiedział…
W ogóle, odpukać, w konkurencyjnym jakimś software housie. No właśnie, i to jest kolega, co siedział w ławce ze mną, to już ją ma.
To jest właśnie taki szerszy argument a propos właśnie konkurencyjności. No bo tak naprawdę, okej, no team kolegi tego używa, wiele firm tego używa. No Kafka sama i Confluent bardziej chwali się, że Kafki używa 80% firm z Fortune 100, czyli z takiego rankingu największych firm. No i jakby teraz my, aspirując do… „my” mam na myśli, powiedzmy, firma albo, powiedzmy, jakiś dyrektor techniczny, czy jakiś inny CTO, używając nomenklatury, no też może się zastanawiać, skoro firmy tego używają i dzięki temu mogą mieć jakąś przewagę technologiczną, konkurencyjną, może my też powinniśmy zrobić jakiś prototyp, zobaczyć, czy u nas w organizacji to się do czegoś nie przyda. No bo faktycznie, faktycznie, faktycznie są jakieś pewne powody, dlaczego aż tyle firm tego używa. I to chyba nie może być aż taki zły albo jakiś nieprzydatny, skoro to faktycznie jest używane.
Żeby nie było jak z tymi muchami.
No trochę do tego zmierzałem oczywiście.
Ale nie, tutaj nie wygląda aż tak.
Nie wygląda aż tak, nie, nie, nie. Więc nawet z takiego zwykłego sprawdzenia, co jest standardem, można powiedzieć, w szeroko rozumianej branży. Bo Kafka jest standardem w wielu branżach. Zwykle tu mówimy o e-commerce, gdzieś tam w finansowych branżach, w logistyce również. Więc to są pewne standardy. Ale to oczywiście nie jest jedyne ograniczenie i nie musimy patrzeć tak branżowo, przekrojowo na to. Możemy tego też użyć w naszej jakiejś takiej branży, w której my akurat jesteśmy. Więc generalnie… No to są jakieś powody, takie ogólne można powiedzieć, dlaczego warto się akurat Kafką zainteresować. No i te powody są na pewno zasadne i dla deweloperów jako takich, ale również dla samych właścicieli firm i dla jakichś osób z takiego szeroko rozumianego C-levelu zarządczego.
Bo jak się zaraz zapewne przyjrzymy, jak to działa tak przynajmniej pobieżnie, to może się wyjaśnić, że jednak nie jest bez sensu zainteresować się tym właśnie na tym levelu wyższym. No bo mogłoby się okazać, że to jest takie porządne, sprawdzone rozwiązanie, z którego właśnie korzysta… nie wiem czy te 80% procent firm…
No to jest pewna statystyka.
Tak, ale na pewno jakiś procent firm z tego korzysta i są takie przypadki użycia, gdzie opłaca się z tego skorzystać.
Jak działa Kafka?
No to dobra. To jak już wiemy, na co to komu, to ten „drzewiej” to sobie odpuścimy, bo to nie było drzewiej tego. Chyba że tak niedawno drzewiej…
…to Kafki jako takiej może nie było rzeczywiście.
Ale odejdziemy od schematu dzisiaj, czyli po prostu: jak działa?
No generalnie tutaj skupimy się tak wysokopoziomowo, bo tak mocno technicznie nie ma sensu też schodzić. Ogólnie Kafka służy do przesyłania eventów, do szeroko rozumianego messagingu. I technicznie to po prostu jest append-only log, czyli po prostu do końcówki naszego loga, powiedzmy, dopisujemy kolejne eventy o pewnej strukturze, no i generalnie jest to niemodyfikowalne i po prostu dokładamy sobie kolejne eventy. I to właściwie jest tyle.
Więc jakby sam koncept takiego append-only loga jest banalnie prosty i stary jak świat, więc nie jest to żadna nowość. Jak też omawialiśmy to w odcinku o bazach danych, jest to też podstawa działania logów i generalnie jakby baz danych, które też właśnie w sobie mają jakieś transaction logi czy tego typu struktury, które gwarantują nam, że ta baza danych, powiedzmy, działa. Więc tutaj mamy po prostu ten element tej bazy danych bez całej tej otoczki, tylko sam ten spód, powiedzmy, zostawiono.
To, co niezbędne, wszystkie dyrdymały wyrzucono.
Tak, tak, tak, ale okazuje się, że nawet ten niezbędny, taki malutki kawałeczek, który zostawiono, jest również przydatny.
Eventy generalnie składają się z pewnego nagłówka i różnych metadanych, które możemy w tym evencie zawrzeć. Timestampy, tego typu rzeczy, jakieś correlation ID, które możemy sobie wrzucać, no i jakiegoś body, jakiegoś ciała, które możemy sobie w takim evencie wysłać. Z tym, że na Kafce raczej nie przesyłamy jakichś bardzo dużych payloadów tak zwanych, czyli tutaj taką zasadą jest jakieś tam ograniczenie się do jednego megabajta, powiedzmy, no ale to oczywiście różni się w zależności…
To znaczy jeden megabajt to już jest dużo.
To już też jest dużo. Jak sobie wyobrazimy taki przeciętny obiekt reprezentujący jakieś zdarzenie biznesowe, gdzie głównym założeniem jest w ogóle zasygnalizowanie, że coś się zdarzyło. Oczywiście wiadomo, że trzeba tam te wszystkie korelacyjne dane, jakieś tam ID i tam szczątkowe wskazówki, o co tam chodziło, zawrzeć, ale właśnie dzięki temu, no i oczywiście te timestampy, na których nam zależy, no to dostajemy takie malutkie coś.
Pokroju tam pojedynczego kilobajta najczęściej, prawdopodobnie.
Tak, nawet mniej.
Tak, to są zwykle… zwykle celujemy w mniejsze.
Jakieś setki bajtów i coś tak, coś koło tego będzie też oczywiście. No tutaj, tutaj raczej, no to zależy później od jakby przepustowości tego, jak będą…
Tak, a właśnie, jeszcze tylko do tego nawiązując. Dokładnie taki case mieliśmy w projekcie, o którym zresztą było tutaj już wspominane, tylko nie pamiętam, w którym odcinku, ale gdzieś bardziej na początku, gdzie integrowaliśmy sobie wielu producentów z wieloma konsumentami właśnie przez takie stado topików Kafkowych. I faktycznie, tam payloady, też takie komunikaty… to znaczy, które chciałyby mieć na przykład po 100 mega tego payloadu, ale wtedy trzeba było zastosować taki sprytny pattern, który pozwalał najpierw zastorować tę dużą zawartość, a później w samym komunikacie zawrzeć tylko ID-ka do tego.
Dokładnie, i system już miał sobie wiedzieć, gdzie to dokładnie się znajduje, i po tym ID-ku mógł sobie to…
Czyli dalej redukowaliśmy to do minimalistycznych takich komunikatów.
Czyli nawet taki już da się zawrzeć.
Wszystko się da, ale generalnie w eventy celujemy, żeby były jak najmniejsze. No i technicznie jeszcze wracając, mamy w Kafce producentów, czyli aplikacje, systemy, które te eventy wysyłają, brokerów i konsumentów, którzy te eventy mogą odczytywać. Jest pod spodem jeszcze dużo innych rzeczy. Są jeszcze partycje, możemy sobie to rozciągać i skalować. Jest jeszcze parę rzeczy odnośnie gwarancji dostarczania i tak zwane semantic delivery, czyli exactly once, at least once – tego typu rzeczy. To, powiedzmy, już są takie bardziej techniczne, niskopoziomowe detale, które pewnie gdzieś tam może kiedyś omówimy przy następnych odcinkach.
Techniczne zalety i przewagi
No i teraz, mając taki prosty koncept, takiego zwykłego loga, do którego zapisujemy, można powiedzieć: „Ok, mamy tutaj bazę danych, po co nam teraz taka Kafka, skoro w bazie danych mamy o wiele więcej?”. Też mamy tego loga, który jest w Kafce, ale mamy też tabele, mamy zapytania, mamy całą masę rzeczy, czy to w bazach danych zwykłych, czy w NoSQL-owych. Taka Kafka wydaje się w tym porównaniu troszkę mieć mniej funkcjonalności, ale też dzięki temu ma pewne zalety techniczne, bo jest szybsza od tych rozwiązań.
Na przykład, no to również według badań Confluenta, twierdzą, że są szybsi od baz SQL-owych, NoSQL-owych, między innymi też od Rabbita. Ogólnie od baz, ale są też szybsze od Rabbita.
No, ale Rabbit twierdzi, że jest szybszy.
No właśnie. Jeszcze niedawno chyba twierdził, ale może to zależy chyba od badań, kto to mierzy, i walka na twierdzenia, dokładnie.
Więc, no jak mierzy Rabbit, to Rabbit jest szybszy, jak mierzą oni, to…
Dokładnie, zależy, kto jest tutaj ośrodkiem badań opinii. Ale co do szybkości, to chyba wszystkie takie rozwiązania, nie tylko Kafka, mają szansę być szybkie właśnie dzięki zastosowaniu tego podejścia append-only.
Tak, czyli niemutowalność.
Niemutowalność i wręcz… znaczy, tutaj dobra, mieliśmy nie schodzić niskopoziomowo.
Tak, tylko troszeczkę.
Tylko troszeczkę, nie wiem, to tyci-tyci wspomnę, że tam file system nie lubi, jak mu się grzebie po blokach. Konkretnie, właściwie file system to jeszcze mu tam wszystko jedno, ale już sam dysk pod spodem, gdzie już nawet dyski SSD mają też troszkę jakby większą na to tolerancję, ale stare dyski, właśnie chyba stąd się to wzięło w ogóle, to podejście append-only, jakoś musiało ewoluować. Dyski, które faktycznie były dyskami, czyli obracającymi się talerzami, gdzie dostęp był i tak sekwencyjny, mimo że to była taka pamięć z zewnątrz widziana jako pamięć o dostępie swobodnym, tylko wolniejsza od pamięci operacyjnej. To właśnie filozofia zapisu i odczytu danych na takim dysku, albo ogólnie w ogóle w takiej pamięci, która jest podzielona na sektory… bo już możemy te dyski z powrotem odłożyć na półkę i wracamy do naszych SSD – i tak są podzielone na sektory, po to, żeby system operacyjny łatwiej mógł tym zarządzać. Albo w ogóle, żeby mógł tym zarządzać. I wtedy okazuje się, że grzebanie w danych, które są zapisane w jakichś sektorach, które już gdzieś tam były tknięte wcześniej, jest dużo wolniejsze niż dokładanie na końcu.
I to jest właśnie cała ta przyczyna popularności tego podejścia append-only, bo nie dość, że generuje mniej problemów… Oczywiście problemy biznesowe, jakie były, takie są, może nawet gorsze, bo jak dokładamy naszych eventów czy komunikatów, czy tych logów, bo to różnie jest nazywane, no to dopisując nowe śmieci, musimy je później kompensować gdzieś tam.
No tak, nie ma takiego łatwego mechanizmu: „a wrócę tu sobie, podmienię jedno pole w tym JSON-ie, którego tam zapisałem dwa miesiące temu, i wszystko będzie dobrze”. Nie, zapisałem, jest wyryte w kamieniu, zostało już tam, gdzie jest, a świat idzie do przodu, więc nowe dane są dopisywane w nowe miejsce.
Dokładnie tak. I to też jest jakby podstawą skalowalności, no bo nie od dziś wiadomo, że niemutowalność bardzo wspomaga taką horyzontalną skalowalność. No bo nie musimy robić synchronizacji danych, wystarczy tylko, że raz sobie skopiujemy jakieś rzeczy na nasze, na nasze gdzieś tam partycje, no i generalnie to już jest prawda wyryta, nie musimy tutaj więcej tam zaglądać i tego skalować. Więc nie ma też żadnych konfliktów i tego typu rzeczy.
Więc dokładnie, i tymi partycjami się łatwiej zarządza, bo możemy je sobie poprzydzielać po jakichś kryteriach i wtedy dopisywać na końcu danej partycji to, co nam wychodzi akurat z bieżącego żądania.
Dokładnie tak. No i tu są jeszcze takie niskopoziomowe jakieś optymalizacje polegające na tym, że Kafka sama w sobie, w sensie broker, tak naprawdę nie zagląda specjalnie do naszych danych. Więc jako binarne dane gdzieś tam są przesyłane pomiędzy RAM-em, dyskiem i socketami.
Czyli znowuż na tym najniższym poziomie, po prostu…
Tak, tak, tak, już dobrodziejstwa nawet sprzętu.
Dokładnie, dokładnie. Więc to są takie drobne smaczki, które pozwalają sprawić, że na Kafce no możemy tych eventów przesyłać bardzo, bardzo dużo.
Czyli wynika z tego, że nam się to szybciej zapisuje, niż my to wysyłamy?
No, generalnie tak, dość szybko. To znaczy, nieprędko jesteśmy w stanie jakby wysycić tutaj naszą Kafkę naszymi aplikacjami, bo ona jednak będzie szybsza niż nasze aplikacje.
No i teraz ta niemutowalność też wpływa bardzo mocno na metryki, jak trwałość danych czy ogólnie replikacja. No bo tutaj generalnie Kafka w sobie jest skalowalna i oczywiście tych brokerów może mieć więcej, właśnie po to, żeby wspomagać tę skalowalność. Też siłą rzeczy wtedy te dane też mogą być rozparcelowane na więcej partycji i siedzieć na większej ilości węzłów. Więc jakby tutaj też ta odporność na awarie jest większa. Nody mogą być podnoszone, mogą być podmieniane, mogą być upgrade’owane bez jakichś wyraźnych spadków wydajności czy problemów.
Replikacja jest względnie nietrudna. Miałem powiedzieć, że względnie prosta, to może za mało, ale względnie nietrudna to już jest ok.
Tak, więc to są takie techniczne, można powiedzieć, zalety, które pewnie przemówią do części programistów. Może też częściowo do biznesu, no bo jednak odporność systemu na awarie czy trwałość danych, no to niewątpliwe są też jakieś biznesowe wymagania. No bo nie chcemy, żeby nasze aplikacje nagle traciły swoje dane.
Jedną z takich zalet technicznych, chyba nie tak często wymienianą może, albo może też nieczęsto tak podkreślaną przy wielu rozwiązaniach, jest to, że Kafka generalnie jest rozwiązaniem open source. Mamy oczywiście rozwiązania dedykowane, Confluent Cloud, który Kafkę nam hostuje, ale generalnie Kafka sama w sobie rozwijana jest przez Apache, tak jak większość jakiś tam bibliotek, i Kafka sama w sobie jest otwartym rozwiązaniem.
Czyli możemy sobie na przykład, biorąc jakieś hostowane rozwiązanie Kafki i mając naszą aplikację, która na tym polega, implementuje pewne rzeczy, jeśli teraz ten dostawca tej Kafki na przykład z jakiegoś powodu nam się nie spodoba, czy będziemy chcieli go zmienić, możemy spokojnie to zrobić. Bo tutaj mamy pod spodem to samo rozwiązanie, które jest open source, jakby nie mamy tego tak zwanego vendor lock-inu. Więc to jest takie troszkę niedoceniane może rozwiązanie i jak porównamy sobie to na przykład, jeśli chcielibyśmy wziąć jakieś podobne rozwiązanie, ogólnie messagingowe, jak na przykład Event Hub w Azurze, czy gdzieś tam kombinacje SNS-a i SQS-a w AWS-ie, no to tutaj już nie będziemy mieli takiego komfortu. Jak już raz na to się zdecydujemy, no to raczej ciężko nam będzie teraz tak łatwo podmienić providera.
I tak jakiś tam koszt tej podmiany by był, no bo trzeba na przykład z tej chmury uciec do innej.
Więc zerowy koszt nie byłby, ale wiadomo, ale nie ma tego…
To są te same…
Tak, nie ma tego kosztu refaktoringowego, bo jednak będzie dokładnie ten sam, będą te same klasy, będzie ta sama, można powiedzieć, filozofia.
Dokładnie.
Oczywiście. A jeśli sobie pójdziemy w SNS czy w SQS, to trzeba będzie jednak przepisać ten kawałek kodu, który po prostu odpowiada za…
Wujek by tu przyszedł i powiedział, że stosuje adapter.
No tak, tylko to już tutaj nie musimy do adaptera dostosowywać, więc jednak troszkę to będzie prostsze. Więc to jest jakaś tam na pewno zaleta i możemy wtedy więcej sobie tych rozwiązań wybrać. W ogólności możemy sobie postawić swoją własną Kafkę, jeśli żaden…
Dokładnie, nawet mamy tu drugą. Więc w takiej sytuacji w ogóle już mamy rozwiązanie open source, które jest bezkosztowe, nie licząc kosztów utrzymania i tego typu rzeczy, ale to przejdziemy za chwilę.
Bezkosztowe, nie licząc kosztów utrzymania.
Jakiś koszt zawsze jest.
Dobra, dobra. Nie ma darmowych obiadów.
Właśnie, ten argument bezkosztowości może trafić do naszego menedżmentu.
Tak, oczywiście.
Faktury nie pokażemy za chmurę.
Tak, to jest oczywiście pozorna bezkosztowość.
Zmiana paradygmatu i analityka z KSQLDB
No i z takich zalet jeszcze technicznych można powiedzieć, czy to powiedzmy… no bo teraz musimy troszeczkę zmienić, tak leciutko, musimy zmienić paradygmat, no bo jednak mindset, więc jeśli jesteśmy przyzwyczajeni do takiego tabelarycznego podejścia, że wszystko mamy gdzieś tam w bazie danych, w tabelach i wszystko jest dostępne na wyciągnięcie ręki.
No właśnie, i tutaj może być na pewno opór wielu ludzi, że jak to jest możliwe, że te eventy, gdzie one teraz będą, w jakichś kolejkach, jak ja je zobaczę? No to tak się nie da.
W topikach, panie, gdzie w kolejkach?
Na partycjach.
To jeszcze w ogóle gorzej, to nie przejdzie.
I jeszcze będą się replikować.
No właśnie, i kto to będzie kontrolował? Więc…
Na co to komu?
Wracamy do pytania. Wydaje mi się, że jest faktycznie…
Spędziliśmy…
Tak, oczywiście. Część jest wyolbrzymiana oczywiście, ale faktycznie są to pewne obawy, kiedy przechodzimy z jednego podejścia na drugie, które różni się troszkę, jakby, sposobem realizacji pewnych rozwiązań.
No tutaj mamy te nasze eventy, które…
Przechodzimy z wieku dwudziestego w dwudziesty pierwszy.
Tak, mamy te nasze eventy, które mogą być troszkę efemeryczne, ulotne, chociaż nie muszą. One są jak najbardziej… możemy sobie na stałe zapisać, jest persystencja oczywiście. Natomiast jeśli kogoś przeraża wizja tego, że to są eventy siedzące gdzieś w topikach, gdzie ciężko to podejrzeć, mamy też coś takiego jak KSQLDB.
Czyli to jest taka specjalna, można powiedzieć, specjalny produkt też od Confluenta. I dzięki temu możemy sobie zrobić widoki na nasze topiki w postaci właściwie takich pseudo-tabel.
Takie projekcje.
Takie projekcje i takim SQL-kompatybilnym językiem odpytywać te nasze topiki tak jak nasze stare, dobre tabele w naszym starym, dobrym Oraclu. Z tą przewagą, że te tabele będą automatycznie zasilane danymi z tych topików, więc będą cały czas aktualne. Więc fajnie się to nadaje do takiego analitycznego data miningu i sprawdzania, i analizowania. Takiej pracy, która powiedzmy nie jest pełniona jakby przez aplikacje stricte, ale bardziej gdzieś tam przez analityczne narzędzia dla takich business analityków.
Jakiegoś tam business intelligence to by było w sam raz.
Tak, to jest właśnie ta część, którą dodano, bo najpierw ją usunięto. Znaczy koncepcja, tak jak powiedziałeś, w ogóle zakładała, że tego nie będzie, tak, ale okazało się, że ktoś tam jednak tego potrzebuje. Może i słusznie, bo jeżeli mamy mieć takie fajne cacko na nasze strumienie danych, bo tutaj już właśnie…
Jeszcze a propos tego, co tam w tej Kafce siedzi – no nie będą to jakieś pojedyncze zdarzenia emitowane raz na tam 5 minut albo raz na dzień, chociaż i do takich zastosowań się używa tego. Ale raczej fajnie, jeżeli jest w tym taka moc, to żeby tam po prostu miliony ich latały. To byłoby najlepsze zastosowanie i generalnie w tym sprawdzi się najlepiej, bo to nie jest z kolei zastosowanie, w którym bazy danych jako takie są dobre, czyli w takiej agregacji częstej, dużej ilości danych. Więc tutaj taka Kafka jak najbardziej.
Główne przypadki użycia
No i tak jak mówiłeś właśnie, miliony. Czyli najczęściej, może nie najczęściej, ale taką pierwszą rzeczą, którą możemy sobie w łatwy sposób śledzić, są pewnie jakieś na przykład akcje użytkownika na naszej stronie, czyli zachowania, gdzieś kliknięcia, monitorowanie właśnie aktywności.
Właściwie, co użytkownik robi na naszej stronie.
Zaraz do gamedevu dojdziemy, bo przecież tam przy gamedevie było takie coś podobne, tylko niekoniecznie tam chyba Kafka była pod spodem, a może była.
A technicznie to już pewnie może też być, no bo to jest tylko środek do celu.
Tam powinno być dużo tych właśnie zdarzeń.
Tak, tak, no tutaj w engine’ie to się dzieje. Do tego to się właśnie nada idealnie, bo rzeczywiście wszelkie interakcje użytkowników, czy to właśnie w grze, czy to właśnie w systemie, czy generalnie…
Ale gdybyśmy mieli jakiś system sprzedaży czegoś tam i mamy dużo użytkowników, albo nie wiem, w ogóle agregacji jakichś danych, no metryki, nie.
Tak, to jest taki dobry use case na to, bo mamy ileś tam węzłów, z których cały czas płyną nam strumienie. To możemy te strumienie sobie przetwarzać właśnie Kafką, łapać je i możemy… Możemy domniemywać, że mocy tam będzie w sam raz, bo jak zabraknie, to się przeskaluje. Dołożymy partycji, czary-mary i nagle mamy znowu dobrą Kafkę.
Ktoś może powiedzieć: „No dobra, przecież to samo mogę zrobić tutaj, nawet nie na króliku, na zwykłym… tutaj mam takie REST-owe API właśnie zrobiłem i tu proszę z frontu uderzać pod ten, i ja sobie pod spodem wszystko zapiszę w tym moim Oraclu”.
Myślałem, że w pliku. Bo jak w pliku to jeszcze…
Albo w pliku i to… albo w pliku. Jak append-only, to zapiszę w pliku.
To nawet bardziej w pliku, bo jak w Oraclu, to mamy Kafkę i bazę produkcyjną, więc zróbmy to na boku, w pliku.
No i właśnie, żeby przeciwdziałać takim domorosłym zapędom, to właśnie warto użyć narzędzi, które są lepiej do tego przystosowane.
Ta Kafka też to zrobi w pliku.
Ta Kafka też to zrobi, tylko że ten plik nam ładnie podzieli, rozpartycjonuje, zapisze troszkę szybciej. A jak my to zaczniemy robić, to powstanie nam pewnie 100-gigabajtowy plik, który za chwilę zgubimy, bo oczywiście serwer nam padnie. I okaże się, że tak naprawdę…
Jak skopiujemy go, to nam padnie.
Skopiujemy go na pendrive’a, więc powiemy, że jak serwer padł, to my mamy go na pendrive’ie, łamiąc wszelkie reguły bezpieczeństwa, RODO i tego typu rzeczy.
Żeby był zaszyfrowany.
Tak, tak, tak, oczywiście, że tak. Naturalnie.
Po co wymyślać koło na nowo?
Więc oczywiście da się wszystko zrobić na własną rękę i na piechotę, to tutaj…
Tylko po co to robić, jak już to zrobili?
Dokładnie tak.
I zajęło im to ile lat?
Tak, z kilkanaście chyba.
Właśnie o to chodzi, że…
No tak, w tym zresztą… Właśnie chyba z takiego samego założenia wyszli w LinkedInie, bo Kafka powstała generalnie w LinkedInie i tam podejrzewam, że też pojawiła się jakaś osoba, która zapisywała do pliku, aż w końcu ktoś wymyślił, że: „a może ten plik podzielimy na więcej serwerów, a może zróbmy brokery”. Jest taki artykuł, tylko no teraz go z pamięci nie wyrecytuję, URL-a do niego, ale gdzieś tam właśnie z LinkedIna wypłynął i to była taka historia Kafki napisana przez twórców Kafki.
I właśnie oni tam argumentowali, że próbowali różnych rzeczy, próbowali sobie to zapisywać tak i owak, nawet w plikach. No i jak już doszli do poziomu plików, bo z baz już zrezygnowali, a chodziło o to, że tam mieli… robili to, czego pogromcy duchów nie robią, czyli krzyżowali strumienie. Mieli te strumienie przede wszystkim do krzyżowania i chcieli krzyżować, musieli je krzyżować, żeby tam jakieś analizy na nich robić. Więc no okazało się, że takie klasyczne rozwiązania klękają przy takim wolumenie danych, jakie oni akurat mieli. I to doprowadziło do takich obserwacji, że może wywalić to wszystko z wierzchu, zostawić samo sedno. Wiadomo, że to musi być zapisane, więc w pliku. No i tak zaczął przyrastać ten mechanizm zapisu efektywnego, append-only, tychże właśnie, jak oni to nazwali wtedy, jeszcze logów, a teraz to możemy pełnoprawnie nazwać event streamami.
No właśnie, czyli strumieniami. Czyli ktoś już to przerobił i przeszedł te wszystkie rzeczy, więc troszkę nie ma sensu, żebyśmy teraz odkrywali to koło na nowo, tylko lepiej skorzystać z tego, że możemy tę technologię wziąć i użyć generalnie niewielkim, relatywnie niewielkim wysiłkiem, a chyba jeszcze mniejszym kosztem w porównaniu do roboczogodzin, które są wymagane. Czy to do napisania czegoś takiego, czy nawet najprostszej wersji, która miałaby robić mniej więcej podobne rzeczy, czyli chociażby ten zapis do pliku jakichś tam, powiedzmy, eventów z frontu. Znacznie szybciej po prostu zintegrujemy Kafkę, nawet w jakimś deweloperskim takim proof of concepcie, i szybciej pewnie dojdziemy do wniosków.
Tym bardziej, że ją teraz można z jednego Dockera chyba odpalić.
Tak, tak, to właśnie przejdziemy za parę chwil, jak właściwie tę Kafkę postawić, jak ją tak ogólnie, skąd ją wziąć.
Dobra ta Kafka.
Jednak dobra.
Jednak dobra.
Zdecentralizowana komunikacja i integracja
No i też jeszcze wracając do… wspomnieliśmy właśnie o tych użytkownikach i o monitorowaniu ich aktywności, ruchu, często też do wykrywania jakiś podejrzanych zachowań. No bo jednak mając z pozycji w czasie rzeczywistym jakieś tam akcje użytkownika czy transakcje użytkownika finansowe, to znacznie prościej i szybciej wykryjemy pewne wzorce, czy np. zasilimy jakiś model sztucznej inteligencji tymi naszymi zdarzeniami i wykryjemy te wzorce. Więc to też może być fajny taki element, który wspomaga nasz mechanizm takiego uczenia maszynowego. Co też oczywiście da się zrobić na poziomie bazy danych, ale to już nie będzie w czasie rzeczywistym, to już nie będzie tak nas szybko alarmować.
Z tego też oczywiście jasno dość wynika, że… jasno, nie jasno, ale jeśli mówimy o messagingu i o… Po niekąd o systemach rozproszonych może to być ciekawe narzędzie użyte do tak zwanego decouplingu aplikacji. Czyli zamiast standardowej komunikacji gdzieś tam jakimiś API, czy to REST-owymi, czy jakimś gRPC, czy tego typu rzeczami, które zawsze będą troszkę wrażliwe na tak zwany temporal coupling, czyli polegamy na tym, że druga strona musi w danym momencie działać, bo jak nie, to wiadomo, nasz REST-owy call po prostu się wywali.
Możemy w fajny sposób użyć tego jako: wysyłamy event, a druga strona jak będzie działać, to go odbierze, przeprocesuje i zwróci nam wynik albo zrobi swoją robotę. I to już jest z gwarancją dostarczenia, ze wszystkimi cechami, które są dość pożądane w takiej komunikacji.
No to też jest na pewno fajny feature, który dzięki temu możemy zbudować taką bardziej komunikację, która jest stabilniejsza, zwłaszcza jeśli tych usług, serwisów, czy mikroserwisów, czy nawet monolitów… No bo kto nam zabroni używać tego w komunikacji między monolitami? To nie musi być decoupling mikroserwisów, to może być decoupling monolitów.
Nawet w samym można, chociaż tutaj nie ukrywam, że takie używanie Kafki w pojedynczym monolicie, tylko po to, żeby z jednej klasy do drugiej coś sobie przesłać, może być delikatnym nadużyciem.
Kto bogatemu zabroni?
Tak, chyba że planujemy albo widzimy, że tak naprawdę te dwa kawałki w przyszłości mogą zostać rozdzielone, więc już będziemy mieli tę komunikację i tę warstwę pomiędzy tymi kawałkami wydzieloną właśnie do tego naszego serwisu Kafki. I wtedy już jakby sama kwestia deploymentu to już jest jakby inna sprawa, ale już te dwa moduły, powiedzmy, będą mogły się komunikować, będąc osobnymi mikroserwisami. Więc to jest też, można traktować jako taki pierwszy krok na przykład w takiej separacji monolitu na mniejsze części. No bo tutaj już będziemy mieli ten kawałek komunikacji.
A to też jeszcze można dopowiedzieć, że nie ma co ukrywać, że ten model to nie tylko w Kafce występuje w sensie takiego persistentnego brokera. No bo istnieje wiele brokerów konkurencyjnych dla Kafki, które to umożliwiają.
Tylko kwestia jest w tym, że… znaczy ogólnie ta akumulacja dobrych cech decyduje o tym, że jednak ta Kafka wygrywa, bo w różnych, u różnych dostawców możemy mieć persistentne komunikaty. Tylko ich odbieranie np. w scenariuszu wstawania z awarii może już nie być tak przyjemne wszędzie. Zresztą Kafka też tam ma swoje jakieś takie za uszami, ale generalnie jednak te mechanizmy są na tyle dopracowane, że robi się to dość sprawnie.
Dokładnie tak. No i w dzisiejszym świecie też coraz częstszym takim przypadkiem użycia jest integracja IoT, czyli tego naszego Internetu rzeczy. Zresztą sami mieliśmy cały czas taki projekt, gdzie na Kafce integrujemy pewne rzeczy fizyczne, które też wysyłają swoje własne eventy.
Zwykle robi się to gdzieś przez integrację Kafki z MQTT, który jest trochę lżejszym protokołem, najczęściej właśnie używanym przez jakieś mniejsze urządzonka, no ale generalnie to też jest jakiś element takiego właśnie większej architektury, która zbiera nam dane czy jakieś sygnały z takich urządzeń inteligentnych, czy z jakichś opasek, czy zegarków, czy innych, a tego może być sporo.
To się, specyfika takich cacek wymaga, żeby tam się dużo działo, nie? Żeby po prostu dużo rzeczy płynęło.
No dzisiaj wszystko jest ze wszystkim połączone. Odbieramy połączenia na zegarku, płacimy zegarkiem, oczekujemy wręcz, że nasze urządzenia będą się łączyć. Że nasze aplikacje jak Spotify czy tego typu rzeczy odpalimy na dowolnym urządzeniu. Odpalamy je na telefonie, na telewizorze, na czymkolwiek, i one wszystkie muszą z sobą jakoś się komunikować.
No i ciężko oczekiwać, że tam wszędzie będą latały REST-owe calle, a przynajmniej nie w każdym przypadku.
A SOAP-owe to już w ogóle.
A SOAP-owe to już w ogóle.
Ale to fajnie, że przywołałeś ten nasz projekt, w którym mieliśmy możliwość właśnie zintegrowania sobie takich… ogólnie mówiąc urządzeń. Większa część to opaski teraz i jeżeli mamy zestaw takich kilkudziesięciu urządzeń, które po prostu co kilkanaście sekund emitują ileś tam eventów, które sobie zebrały, głównie związanych z ruchem, jakiemu zostały poddane.
Bo na przykład rzecz dzieje się na parku rozrywki i tam właśnie cała grupa dzieci hasa po trampolinach, zbiera jakieś magiczne punkty, a my to musimy zgrabnie przetworzyć i ubrać w jakąś grę, w którą właśnie te dzieci grają. No to wypisz, wymaluj, po drugiej stronie rysuje nam się taka Kafka, która tam czeka na te eventy i je nam przemiela. Znaczy, my je przemielamy, z niej wyciągając.
Ona nie tylko zbiera, ale może też tam transformować w locie, jakby była taka potrzeba.
No tak, tak, właśnie, to jest też kolejna zaleta ekosystemu Kafki.
Ekosystem i integracje z Kafka Connect
No wspomnieliśmy właśnie o tym KSQLDB, to jest jeden z takich fajnych feature’ów, który ma Kafka, czyli mapowanie tych naszych topików na takie tabele pseudorelacyjne.
Ale generalnie Kafka i taki ogólny mechanizm Kafka Connect pozwala na łatwy sposób integracji tej Kafki z innymi systemami. To zarówno w postaci źródeł, czyli możemy sobie z danego źródła, czyli bazy danych, możemy sobie te dane automatycznie przez ten konektor rozsyłać do topików, bądź możemy sobie nasze dane z naszych topików eksportować właśnie odpowiednim konektorem do jakichś zewnętrznych źródeł.
Czyli takie klasyczne przypadki użycia, czyli wspomnieliśmy te logi na przykład. No i okej, mamy sobie te logi tego użytkownika na naszym froncie, on tam sobie klika i widzimy jego aktywność. No ale co dalej? Te logi w samym topiku niekoniecznie są przydatne do dalszej analizy. Możemy sobie to zrzucić do KSQLDB, a możemy sobie odpowiednim konektorem zrzucić je gdzieś do Elasticsearcha, możemy zrzucić je sobie do S3, gdzieś do Hadoopa i tam dalej będziemy je procesować, analizować, agregować i robić te wszystkie rzeczy, do których tamte narzędzia są stworzone. Ale będą, dzięki tej naszej Kafce, będą zasilane na bieżąco aktywnością, ruchem, czymkolwiek co chcemy śledzić, logami, tego typu rzeczami.
Czyli stosujemy jedno narzędzie, które jest dedykowane do zbierania pewnych danych z niską latencją i z dużą trwałością tych danych, a z drugiej strony eksportujemy to do narzędzia, które pozwala, umożliwia nam dalszą obróbkę tych danych.
Natomiast w drugą stronę, takim klasycznym przypadkiem użycia, o którym już często rozmawialiśmy, jest łatwy sposób wyciągania kawałków funkcjonalności z takich legacy systemów. Czyli możemy sobie Kafką, a właściwie naszym konektorem Kafki, podpiąć się do jakiejś relacyjnej bazy danych i będziemy nasłuchiwać na tej bazie danych na zmiany w danej tabeli, w jednej czy drugiej, i pod spodem będziemy sobie te dane wysyłać do topiku. A na tym topiku możemy sobie naszym wspaniałym kawałkiem kodu, naszym nowym mikroserwisem realizować jakąś nową funkcjonalność, nie obawiając się albo w ogóle nie musząc w ogóle zmieniać nic w naszym monolicie, załóżmy.
Monolit nawet nie zorientuje się.
Monolit nawet się nie zorientuje, nawet nie musi wiedzieć, że ktoś mu tam grzebie po bazie. Więc jest to fajny właśnie taki wzór do zastosowania, nieinwazyjny właśnie w legacy systemach, albo w systemach, gdzie generalnie może mamy jakiś dłuższy czas wprowadzania zmian albo mamy deploye co pół roku, bo taki mamy system, a jednak chcemy iterować z biznesem z większą częstotliwością.
Więc tutaj możemy sobie tak troszkę na boczku, w łatwy sposób, może robić jakieś eksperymenty, może tworzyć jakieś małe serwisy, które będą korzystać tylko z części funkcjonalności, z części bazy danych, ale realizować jakąś ważną, nową funkcjonalność.
Więc możemy sobie w ten sposób łatwo podłączać się do różnych źródeł danych. I to są bazy danych, to są pliki, więc tutaj jakby tych konektorów jest bardzo dużo i to też jest taka przewaga konkurencyjna Kafki też nad innymi brokerami, które zwykle nie mają aż takiego szerokiego wachlarza integracji z różnymi źródłami danych.
To też mi się obiło o uszy, że taki konektor można sobie samemu napisać.
Można też sobie samemu napisać, tak.
Jeśli nie znajdziemy, żeby się podpiąć na przykład do Cyberpunka.
Na przykład. Nie wiem, jak miałoby to wyglądać, ale oczywiście da się to zrobić.
Też nie wiem, no to do Wiedźmina, no.
Przetwarzanie w czasie rzeczywistym
Czyli to jest taki ogólnie jakby stosowany pattern, nazwany właśnie taką ciągłą integracją. Czyli możemy po prostu w sposób ciągły, w czasie rzeczywistym integrować się z naszymi systemami. I co ważniejsze, możemy to robić w obie strony. Czyli możemy z naszych systemów zasysać dane z różnych źródeł i wrzucać je na topic, żeby później móc robić coś z tymi danymi dalej. Albo w drugą stronę – możemy z naszych topików również wyrzucać te dane już do konkretnych, docelowych systemów, żeby je dalej procesować.
Więc to daje nam takie szerokie możliwości, żeby faktycznie lepiej agregować nasze dane, których jednak w takich aplikacjach biznesowych w dzisiejszych czasach jest bardzo dużo.
Ciągle przybywa, ale my tutaj nie musimy się obawiać wolumenu tych danych.
Z poziomu Kafki raczej nie musimy.
Z poziomu rachunku to może.
No to jest inna sprawa.
Ale jak mamy tyle danych do przetworzenia, że aż rachunek widać, to może jednak i w drugą stronę to też coś generuje. Że to się jednak kompensuje, więc nie ma się co tego obawiać.
A chyba łatwość użycia została już dowiedziona w tego typu przypadkach. W ogóle same korzyści. Właśnie ta nieinwazyjność podglądania takiego systemu.
Tak, gdzie możemy sobie wręcz, zacząwszy go podglądać, możemy sobie już powoli obmyślać model refaktoryzacji, być może całego tego monolitu. Pocięcia go na plasterki albo w ogóle zastąpienia czym innym.
Tak. Ta nieinwazyjność to dla mnie mega zaleta i też chyba widać po obecnych jakby czasach czy aplikacjach, z którymi mamy do czynienia, jest też ten czas rzeczywisty, ten aspekt natychmiastowej możliwości, natychmiastowej reakcji, możliwości natychmiastowego reagowania. Na takie rzeczy, że pewne zachowania użytkownika możemy w łatwy sposób zaproponować mu podobny produkt, możemy go powiadomić na aplikację mobilną o jakiejś tam akcji, albo że na jego koncie są jakieś podejrzane zachowania wykryte czy coś takiego.
Nie musimy tego robić w takim starszym podejściu batchowym, że przeprowadzamy jakieś tam wielkie operacje, wielkie joby chodzą po naszej bazie i coś tam próbują wygenerować, coś tam próbują zanalizować.
Podobnie z raportami – to już nie są te czasy, kiedy musimy czekać 24 godziny, aż nam wygenerują się raporty z poprzedniego dnia i biznes tam dzielnie czeka i zawsze ma te 20 czy ileś godzin do tyłu, jeśli chodzi o świeżość danych. W tym momencie jednak musimy reagować troszkę szybciej, więc te dane musimy móc przetwarzać troszkę szybciej, niż w takim podejściu relacyjnym i po prostu select z zakresu i wtedy coś analizujemy.
A w tym momencie już przybyło nam ileś tam ton tych danych.
Tak, no w klasycznym ujęciu to my na samym tym transaction logu, który jeszcze się tam pewnie w miarę jakoś zachowuje w takiej bazie, mamy całą tę nakładkę, która nam robi te… jeżeli mówimy o bazie, na przykład o jakimś tam Oraclu zbugowanym niedawno, ale to nie musi być on, bo dowolna inna baza, i tutaj ostatnio miałem przyjemność z Microsoft SQL Serwerem coś takiego uskuteczniać w fajnym projekcie. No to wiadomo, że jak to jest duże, to wolno działa, bo cała ta maszyneria, zanim przetrawi tę zmianę, to zajmuje czas. A tutaj nie mamy tej maszynerii, w sensie sama idea zakłada, że mamy samo sedno jej.
No i właśnie ten paradygmat, ciągle, ciągle się kręcimy wokół paradygmatu tego append-only i message-driven.
To właśnie to jest tutaj najgłówniejszym sednem tego wszystkiego.
Dokładnie tak, po prostu tam już wszystko jest uproszczone do granic. Wiemy, że możemy tylko dodawać na końcu. Tych końców możemy mieć dużo, bo już wspomnieliśmy o partycjonowaniu, więc tutaj można sobie jeden topic nawet podzielić na partycje i są bardzo różne strategie partycjonowania. Dla każdego coś miłego, w zależności od use case’a możemy sobie wybrać taką albo inną, tę, która będzie dla nas najlepiej pracować i cieszyć się tą wydajnością.
Mało tego, bo możemy to skalować, jeszcze te partycje osobno też, nie? Czyli taki sam ten broker, który dba o to, on też może być… właśnie on jest przeskalowany.
Właśnie, ale wbrew pozorom ta prostota otworzyła znacznie większe pole manewru dla tych zastosowań, o których mówimy. I podobnie też z takim specyficznym zastosowaniem event sourcingu, to co gdzieś tam w pierwszych odcinkach omawialiśmy.
No tutaj wrócimy, jeszcze pewnie wrócimy.
No tutaj można powiedzieć, z jednej strony aż się prosi o taki event store’a.
Miałem powiedzieć, event.
Tak. Tu oczywiście jest pewna dyskusja otwarta, czy Kafka to jest dobry event store i tutaj zdania są podzielone.
Jeden konsultant powie tak, drugi powie nie.
Więc tutaj też chyba nie będziemy aż zajmować jakiegoś większego stanowiska. Chociaż gdzieś tam przyszło nam pracować w projektach, gdzie Kafka była używana jako event store.
Tak jest, i jeszcze tylko dopowiem, że w niedługim czasie kroi się webinar, który będzie o czymś takim traktował.
Także niedługo też powinno to wybrzmieć i tam też, jak już będziemy mówili o zaletach takich, a nie innych podejść, to pewnie gdzieś tam się też Kafka pojawi pod spodem.
Dokładnie, więc to jest temat, który, jasne, ciągle powraca, ciągle powraca i pewnie zasługuje na osobny… osobny, tak jak Wiedźmin, na osobny odcinek. Więc jakby tutaj wartości, jakby cechy event sourcingu, pewnie sobie jeszcze omówimy, bo to jest troszkę, troszkę inny kawałek.
Kiedy Kafka to nie jest najlepszy wybór?
Natomiast, do czego może ta Kafka nie do końca będzie nam się nadawać? No bo tutaj zachwalamy i od lewej do prawej podajemy bez podawania VAT-u.
Czyli VAT-u nie ma.
Dziękujemy za uwagę.
No dobra, to do czego?
Patrząc, patrząc tak szczerze mówiąc po profilu aplikacji, które tutaj wymieniliśmy, Kafka nie do końca pewnie znajdzie sobie zastosowanie w takich aplikacjach tzw. płytkich, czyli generalnie…
Kurde, do CRUDA się nie nada.
No właśnie. No właśnie, pytanie, co ten CRUD robi?
Bo jeśli ten CRUD jest faktycznie CRUD-em, ale pod spodem z tego CRUD-a te dane gdzieś tam używają systemy…
Taki CRUD, który nie tylko dla siebie te dane zapisuje, ale też może dla wielu innych systemów. Może potrzebuje te dane gdzieś jeszcze rozesłać, może kogoś powiadomić. No to jak najbardziej.
Natomiast jeśli mamy aplikację, która generalnie żyje sobie sama dla siebie, nie potrzebuje żadnych zewnętrznych usług, niespecjalnie mamy bogatą logikę, system jest, można powiedzieć, płytki, czyli to, co widzimy na interfejsie, w zasadzie jest naszą logiką, czyli zapisujemy, ktoś tam sobie to później odczytuje i tylko zmienia status, np. bo mamy jakiś prosty obieg dokumentów. Tutaj troszkę ciężko może być znalezienie takiego zastosowania, bo jasne, możemy oczywiście pomiędzy modułami naszego monolitu zrobić komunikację na Kafce, ale to już na pewno troszkę stracimy na latencji, bo jednak wyskoczymy poza nasz serwer i jednak ta wiadomość szybko, bo szybko, ale na pewno nie dojdzie tak szybko, jak po prostu wywołanie metody w tej samej przestrzeni.
Tak, tak. A to można też ogarnąć jednym takim ciekawym sposobem, ale to może po Kafce.
Czyli, czyli… to jest… czyli tak, nie do CRUD-ów, takich najprostszych, nie, może niekoniecznie. No żeby też nie był ten przypadek z armatą na komara, nie? Tam właśnie wolumen danych, jeżeli wiemy, że nie spodziewamy się jakichś nie wiadomo jakich rewelacji.
To może nie opłaca nam się utrzymywać tej całej infrastruktury kafkopodobnej.
Tak. Nawet nie opłaca nam się może tylko jednego dockera mieć. I właśnie kuszące jest do tego, do takiego refactoringu legacy, rozważyć sobie taką Kafkę, ale być może trzeba by ją było opakować za jakąś abstrakcją, jakiegoś medium do przesyłania komunikatów, żeby nie powiedzieć szyny danych, ale czegoś takiego, jakiegoś topika.
No właśnie, takiego brokera zasymulować tam. Nawet wręcz użyć coś, ale tutaj, za radą wujka Boba przytoczoną, jednak za jakąś abstrakcją w to schować, za jakimiś adapterami prostymi, ustalić interfejs tego swój własny. I na razie, na początku, w tym CRUD-zie zrobić to nawet na piechotę, na czymkolwiek, nie? Kiedyś nawet zrobiliśmy to na guavowej kolejce, która już teraz jest bardzo niepolecana, ale asynchroniczną wersję dalej można używać, bo ta synchroniczna jest już teraz taka nie-tega. A później przesiąść się, jak już na przykład rozdzielimy na dwoje takiego CRUD-a, tego monolitycznego, no to wtedy dać mu, jeśli by jeszcze zechciał wolumen danych tam wzrosnąć, dać mu wtedy implementację w postaci Kafki.
Tak, już tak z prawdziwego zdarzenia.
Tak. No generalnie, jeśli widzimy w przyszłości jakieś kierunki rozwoju naszego systemu, jeśli, jeśli no… No wiadomo, po prostu to nie jest dla bardzo prostych systemów. No tak jak większość troszkę bardziej skomplikowanych tooli. Tak samo jak dla prostych systemów nie będziemy konfigurować całego data lake’a czy nie będziemy konfigurować jakiejś skomplikowanej chmurowej konfiguracji. No to jest taka, można powiedzieć, standardowa reguła. No po prostu używamy narzędzi…
Sam też event sourcing, już wspomniany, też nie jest dla najprostszych rozwiązań dedykowany. Muszą zaistnieć przesłanki, żeby tego używać.
Tak, tak, tak. No i też nie musi być w całej aplikacji oczywiście używany, więc to zresztą podobnie jak w Kafce, no Kafka też nie musi być używana od razu w całej aplikacji. Możemy wybrać sobie kawałek, gdzie chcemy to przetestować, czy w ogóle możemy to sobie zrobić zupełnie na boku, tak jak wspomnieliśmy z tymi konektorami. Więc tutaj jakby też duża możliwość właśnie integracji Kafki jako takiego elementu naszego technicznego przybornika może być, może być plusem. No nie trzeba od razu naszej aplikacji gdzieś tam mocno przeorać, żeby taką Kafkę wprowadzić.
Jak zacząć? Opcje wdrożenia i koszty
Natomiast, okej, załóżmy, że przekonaliśmy już siebie jako inżyniera, załóżmy, że przekonaliśmy już biznes albo jakiegoś dyrektora, czy naszego przełożonego. No i dobra, i wszyscy zgodzili się: idziemy w Kafkę. Idziemy, rzeczywiście, fajne narzędzie, tym się nauczymy. No i teraz co dalej? Chcemy skądś tę Kafkę wziąć, no bo Kafka to nie jest jedna dżarka wrzucona do projektu, więc teraz mamy…
Kilka możliwości, kilka możliwości i są możliwości polecane i niepolecane.
To może najpierw te niepolecane, żebyśmy o nich zapomnieli.
Niech wybrzmią i idziemy dalej.
Tak jak wspomnieliśmy, Kafka jest open source, więc możemy w łatwy sposób po prostu postawić sobie klaster Kafki.
Jak słyszę „w łatwy sposób postawić klaster”, to tak, mam chęć napić się kawki.
To jest taki eufemizm, powiedzmy, ale w łatwy w rozumieniu możemy sobie znaleźć docker-compose’a, a w nim będziemy mieli dwa obrazy: Kafki i ZooKeepera do niedawna.
Będzie klaster.
Będzie klaster, to może jeszcze dużo powiedziane, ale będzie instancja i możemy z tego korzystać dewelopersko, i będzie wszystko grało.
Tak, tak, tak, możemy to oczywiście zrobić. W ostatniej wersji 3.6 już nawet nie mamy ZooKeepera. W sensie, to jeszcze nie jest do końca produkcyjnie gotowe, ale Confluent i generalnie środowisko bardzo mocno walczyło, żeby Kafka była niezależna od ZooKeepera. Bo to też zawsze był bardzo mocny narzut operacyjny, żeby zarządzać całym ZooKeeperem, który, zdaje się, nie jest super przyjazny.
Kolejny klocek.
On taki jest bardzo nieprzyjazny, zwłaszcza na początku, jak tam się czytało o tej Kafce.
No właśnie, i od nowej wersji już praktycznie tego ZooKeepera nie potrzebujemy. Ale oczywiście, jeśli postawimy to sami, dewelopersko nie ma problemu. No bo to sobie stawiamy na własnych maszynkach czy gdzieś tam i nawet nie musimy za bardzo się nim przejmować.
Niestety, nie ma tutaj wymagań pewnych takich produkcyjnych.
No właśnie, no właśnie. Natomiast jeśli pojawiają się te wymagania produkcyjne, no to teraz pytanie, czy mamy tę wiedzę w naszej organizacji, czy my to mamy tę wiedzę, czy jesteśmy w stanie się tego nauczyć, czy chcemy w ogóle się tego nauczyć, czy może lepiej zastosować jakieś rozwiązanie hostowane?
No właśnie, no właśnie, tutaj jakby przechodzimy płynnie do rozwiązań takich zarządzalnych, hostowalnych. Czyli tak naprawdę, biorąc pod uwagę, że coraz częściej idziemy w rozwiązania chmurowe, czyli nawet już tych serwerów sami nie utrzymujemy, tylko bierzemy gotowe usługi, tak samo możemy zrobić z Kafką.
I tutaj mamy pełne pole do popisu i manewru, bo tych rozwiązań jest dużo. Pierwsze, które najbardziej, można powiedzieć, narzuca się, to jest Confluent Cloud. To jest zarządzalna Kafka, która tworzona jest przez firmę, która powstała, można powiedzieć, z ludzi, którzy Kafkę w LinkedInie stworzyli, a później stworzyli własną firmę i teraz oferują właśnie Kafkę jako rozwiązanie zarządzalne.
Tam również możemy sobie w tymże Confluent Cloudzie użyć kilku dodatkowych narzędzi. Na przykład właśnie ten wspomniany KSQLDB możemy sobie zintegrować. Mamy też do dyspozycji Stream Designer. Stream Designer jest, można powiedzieć, takim graficznym narzędziem do tworzenia naszych flowów w Kafka Streams. To też jest pewien taki koncept agregujący więcej strumieni. Ale możemy sobie fajnie narysować i stworzyć naszą taką topologię naszego processingu. No i od niedawna, to jeszcze nie jest w wersji produkcyjnej, Confluent oferuje też Flinka. Bardzo ciekawa biblioteka, z którą miałem przyjemność pracować przez dłuższy czas. I rzeczywiście możemy cały pakiet takich narzędzi okołokafkowych od jednego providera dostać i po prostu ich używać.
To wszystko jest oczywiście zarządzalne, backupowane, bezpieczne, wiadomo, certyfikaty ISO i tego typu rzeczy. Więc jeśli potrzebujemy mieć podkładkę dla naszej firmy, że ta Kafka będzie bezpieczna, no to tutaj na pewno ją dostaniemy.
Więc musimy tutaj rozważyć ewentualne koszty hostowania tego. Mamy oczywiście AWS-a. Od już bodaj czterech lat AWS oferuje MSK, czyli zarządzalny klaster Kafki. Tutaj już nie mamy do dyspozycji aż tylu narzędzi co w Confluencie. Natomiast to jest standardowo, tak jak bierzemy sobie usługę z AWS-a, dostajemy sobie klaster. Mamy też pewną zarządzalność, konfigurowalność. No i tutaj tak klasycznie, jak to w AWS-ie, w cenie zbliżonej do jakiejś EC2-ki, bo za najmniejszy klaster zapłacimy około 40 euro miesięcznie.
Więc jak mamy sobie porównać te 40 euro miesięcznie kontra godziny pracy, czy to jakiś DevOpsów, czy deweloperów, którzy musieliby to robić, no to rachunek zysków i strat raczej przemawia na stronę zarządzanych rozwiązań, bo ciężko raczej w tej kwocie byłoby zmieścić się nawet z minimalnym maintenance’em.
Za 40 euro dopiero książkę otworzymy.
Dokładnie. 40 euro to nam zajmie jedno daily takiego zespołu, które miałoby tę Kafkę w ogóle postawić.
Możemy sobie w łatwy sposób to sprawdzić i chyba tutaj raczej nie będzie nikt w firmie nam narzekał, że to jakoś sprawi, że firma zbankrutuje, bo będziemy płacić 40 euro za tę Kafkę.
No chyba że nam się tam przeskaluje jakoś magicznie i później te faktury pójdą tam takie.
No tak, ale to jak ze wszystkim. Jak ze wszystkim w AWS-ie.
Ale na szczęście to nie do nas idą te faktury, tylko do nich tam gdzieś.
Dokładnie. Nie ma się co martwić.
Jest też kilka takich bardziej egzotycznych rozwiązań na Kafkę. IBM-owa chmura OpenShift ma Event Streams, który szczerze mówiąc z moich doświadczeń nie był tak przyjemny. Jednocześnie nie był aż tak łatwy, można powiedzieć, w użyciu.
A z ciekawości, co w nim takiego zgrzytało?
Pod spodem chodzi normalna Kafka, ale gdzieś zawsze mieliśmy problemy ze stabilnością tego rozwiązania. Gdzieś jednak… to jest pytanie, czy to była bardziej stabilność, można powiedzieć, też naszych komponentów, ale jednak jakoś ten Control Plane też nie był tak łatwy w użyciu, zarówno jeśli chodzi o możliwości konfiguracji, dostania się do jakichś bebechów tej Kafki. No wszystko jakoś takie było nie do końca łatwe w użyciu, więc tutaj mam takie mieszane uczucia.
I z pewną taką ciekawością też odkryłem, że Kafkę hostuje również DigitalOcean oraz OVH.
Na co im to?
No właśnie, ciekawe. Postanowili też…
Oni teraz będą chmury otwierać?
No to chyba też po części jednak świadczy mocno o popularności Kafki, bo jeśli takie OVH bierze się za zarządzalną Kafkę, no to to jednak…
No ale oni tam dają niby jakieś serwerki takie, znaczy dają takie totalnie proste. W sensie gołą maszynę można dostać.
No tak, ale też i chyba jakieś takie sprytniejsze, czyli tak jakby w sensie takie bardziej chmurzaste rozwiązania. Teraz się do tego przysposabiają, więc pewnie ta Kafka to taki plan na to, żeby jednak jakąś chmurkę sobie zacząć tworzyć, nie? Żeby coraz bardziej stawać się takim, może nawet tak zwanym, Infrastructure-as-a-Service, czy coraz więcej tej infrastruktury dawać.
Zobaczymy, co wyjdzie, może coś tam wyjdzie. Jeśli ktoś jest bardzo przypięty do infrastruktury OVH, może to być fajnym rozwiązaniem i mieć tę Kafkę blisko, bo wtedy możemy skorzystać pewnie na jakiejś bliskości naszych serwerów z serwerami Kafki. Tego bym przynajmniej oczekiwał, że taka kolokacja będzie na naszą korzyść.
Jeśli żyjemy gdzieś tam w AWS-ie, raczej oczywistą sprawą będzie, że weźmiemy sobie AWS-a. Natomiast jeśli żyjemy poza chmurą, to prawdopodobnie Confluent będzie oferował najwięcej możliwości.
Podsumowanie
Tak podsumowując, już trochę zmierzając ku końcowi, Kafka nie jest aż taka super droga. Można ją w dość łatwy sposób wypróbować, nawet jeśli mielibyśmy zrobić jakieś małe MVP. No bo to chyba na części od tego się zaczyna, niż od razu wprowadzać gdzieś do naszej wielkiej aplikacji i teraz zablokować development na 3 miesiące, bo my tutaj teraz Kafkę stawiamy i nic nie może nam przeszkodzić.
Biorąc pod uwagę też właśnie te wzorce integracyjne, które omówiliśmy, no to jednak one sprzyjają właśnie takiemu łatwemu, przyrostowemu integracji z naszym systemem, no bo właśnie nie musimy tego wszystkiego przeorać. Możemy sobie zrobić to na boczku.
No i na pewno zespoły w naszej organizacji też będą jak najbardziej zainteresowane użyciem nowoczesnych technologii.
A nawet gdybyśmy mieli taki przypadek, że już mamy jakiegoś brokera, albo może go wyrzucić i wziąć Kafkę?
No właśnie. Nawet kilka, bo można by było mieć jeden, drugi i eksperymenty jakieś pomiędzy nimi.
Oczywiście.
I mogłoby się okazać, że dalej brakuje mocy.
Wtedy znowu idzie wujek Bob ze swoim adapterem.
Wsadzimy Kafkę i gotowe.
Bob włączy tę samą płytę na tym adapterze. Bo to tak mniej więcej ma działać.
Także przeszliśmy mniej więcej przez kilka technicznych aspektów, kilka biznesowych aspektów, dlaczego warto Kafki używać. Większość z tych rzeczy tyczy się, właśnie tak jak mówisz, innych brokerów, więc to nie jest tak, że Kafka jest lekiem na całe zło.
Tym bardziej, że ona też jest taka trochę inna niż inne. Niekiedy nie są tak… niby jest ten cały pub-sub tam, publisher-subscriber, publish-subscribe wzorzec, ale troszkę się tego inaczej używa niż takiego na przykład ActiveMQ czy tam jakiegoś JMS-a, nie?
Tak, stąd chyba też ta mnogość zastosowań właśnie, która z tego wynika, że możemy tego używać aż w takiej ilości zastosowań, bo łatwo, łatwo możemy sobie manipulować jakby trybem, można powiedzieć, czy to ma bardziej być taki tryb subskrypcyjny, czy bardziej po prostu do zwykłego wysyłania message’y: wyślij, zapomnij i nas to nie interesuje, czy może bardziej w stronę event sourcingu. No właśnie, to są te zalety i możemy sobie wybrać to, co nam bardziej pasuje.
Jaki mamy round-robiny, można sobie dopasować, nie? Żeby też nie było, że tutaj jest jakoś trudniej od innych brokerów. To w zasadzie każdy znany sposób ma jakieś tam swoje, że tak powiem, naleciałości, nie? Bo weźmy takiego RabbitMQ, wcale nie jest łatwiejszy do skumania od Kafki.
Tak, to już zawsze, jeśli mówimy o jakimś większym kawałku w naszej tutaj technologicznej układance, to zawsze ten narzut będzie trochę większy. Więc z tym się też trzeba liczyć, że wprowadzając do naszego projektu tę Kafkę, no troszkę trzeba będzie czasu poświęcić na pewne techniczne aspekty. Jest pewna krzywa uczenia, no to nie jest tak, jak na początku wspomnieliśmy, jedna dżarka, którą sobie wrzucamy do projektu. Więc no, jest pewna krzywa uczenia.
Niemniej jednak wydaje nam się i chyba tu będziemy zgodni, że warto się tutaj na tę krzywą wspiąć i spróbować.
I nie spaść.
I nie spaść. Ona nie jest aż taka stroma, żeby nie spaść. Może tam delikatnie się sturlać.
Ale lepiej już zostać tam na niej.
Lepiej zostać.
Jak już się wespniemy.
Lepiej zostać, bo tak jak widać, jest to na pewno kawałek technologii, który jest coraz powszechniej używany i daje naprawdę wymierne i fajne korzyści biznesowe. Więc warto również, jeśli jesteśmy od tej bardziej strony biznesowej, zastanowić się, czy może w naszej organizacji ta Kafka nie wprowadziłaby czegoś fajnego, nie dałaby nam jakiejś przewagi albo nie usprawniła naszych własnych procesów.
Albo nie pozwoliła nam tak dobiec do tych, którzy już ją mają, próbować ich trochę ścigać.
No to jest, to jest ważny aspekt, żeby też gonić konkurencję. Więc jeśli konkurencja tej Kafki używa, no to to jest jeden z argumentów.
Dlaczego jeszcze nie spadła z krzywej?
I jeszcze nie spadła.
Może warto tam też być.
Może warto tam być.
No to okej. Wprawdzie było mało wstawek kulturalnych, ale jakby komuś trzeba było, to Kafkę też można poczytać. Czemu nie? Są książki. Proszę sobie odszukać. Okej, to co? Napijmy się kawki.
Napijmy się kawki. Dzięki Michał za odcinek.
Trzymajcie się.
Cześć.