Trivoren asiantuntija Stefan Roos kirjoittaa Apache Kafkasta, joka on kiinnostava tietovirtojen kuljetukseen suunniteltu alusta. Alunperin LinkedInin käyttöön suunniteltua alustaa on sittemmin hyödynnetty laajemminkin ohjelmistokehityksessä, mukaan lukien erinäisissä Trivoren projekteissa.
Kirjoittajasta
Stefan Roos toimii Trivoren Product Technical Leadina. Työssään hän toimii erityisesti integraatioiden ja Trivoren IAM-järjestelmän parissa sekä Trivoren johtoryhmän jäsenenä.
Mikä Apache Kafka käytännössä on?
Apache Kafka on alunperin vuonna 2011 tietovirtojen kuljetukseen suunniteltu alusta. Se suunniteltiin LinkedInin käyttöön sen sisäisten viestien välittämiseksi. (Li 2020; Koutanov 2020.) Tapahtumien kuljettaminen tietovirroissa (event streaming) voidaan kuvata vastaavaksi, kuin mitä ihmisen hermostossa tapahtuu. Kafkaa voisikin siis sanoa digitaaliseksi versioksi keskushermostosta (Apache Kafka, 2022).
Kafkaa voidaan käyttää muun muassa publish-subscribe-mallin viestinvälitykseen, lokien aggregointiin, lokien edelleenlähetykseen (log shipping), asynkronisiin yhteyksiin (SEDA), monimutkaisten tapahtumien prosessointiin (CEP) sekä tapahtumapohjaiseen komento-kyselyvastuun segrekointiin (Event-sourced CQRS) (Koutanov 2020). Kafkaa voidaan käyttää viestikanavana, sovellusten integrointiin, datastorena, tietovirtojen käsittelyjärjestelmiin sekä skaalautuvien ja vikasietoisten mikropalveluiden rakentamiseen (Shapira 2017).
Koutanovin (2020) mukaan Kafka-järjestelmä tarvitsee useita komponentteja toimiakseen oikein.
Avainkomponentit ovat:
- Brokerit – vastuussa varsinaisista IO-operaatiosta sekä datan persistoinnista
- Zookeeperit – vastuussa kafka-klusterin tilasta ja sen kontrolloinnista.
- Producer – asiakasjärjestelmiä/-sovelluksia, jotka tuottavat dataa jonoihin.
- Consumerit – asiakasjärjestelmiä/-sovelluksia, jotka noutavat dataa jonoista. (Koutanov 2020.)
Messetti (2022) kirjoittaa kuitenkin, että näistä komponenteista Zookeeper voidaan jatkossa jättää pois, sillä Kafkan sisälle toteutettu KRaft-protokolla hoitaa siihen liittyvät tehtävät jatkossa. Uusimmissa versioissa Kafkasta ei siis ole enää tarvetta käyttää ulkopuolista palvelua klusterin metatietojen välitykseen. Tämä muutos käytännössä yksinkertaistaa Kafka-klusterin rakennetta sekä parantaa sen skaalautuvuutta.
Avainkonseptit Kafkan käyttämisessä ovat topicit (aihe) sekä partitiot. Topic tarkoittaa kafkassa käytännössä yhtä jonoa, johon voidaan dataa viedä tai noutaa. Jono voidaan sisäisesti jakaa useiksi partitioiksi. Jokainen partitio on käytännössä järjestetty sarja tietueita (record). Voimme kutsua näitä myös viesteiksi.
Tietueilla on sijainti (offset) ja sillä voi olla myös avain sekä arvo. Koska partitiot ovat täysin järjestettyjä (ordered), on varmuus siitä, että consumer saa viestit/tietueet siinä järjestyksessä, kun producer on ne lähettänyt. Kafkassa on myös tae siitä, että kaikki lukevat viestit aina samassa järjestyksessä. Tämä on hyvin tärkeää suurelle osalle sovelluksista. Huomioitava on kuitenkin, että jos on kyse tilanteesta, jossa on useita producereita, voivat ne lähettää samanaikaisesti viestejä samalle partitiolle, eikä näin ollen ole taetta siitä, että producereiden kesken viestit olisivat oikeassa järjestyksessä. (Koutanov 2020.)
Topic kattaa siis joko yhden tai useamman partition: se on siis looginen kokoelma partitioita. Jokainen partitio voi olla vain tasan yhdessä topicissa. Topicit ovat hyvin tärkeä osa Kafkan rakennetta ja toiminnallisuutta. Ne mahdollistavat muun muassa sovellusten kuormantasauksen sekä rinnakkaisuuden. (Koutanov 2020.)
Avainkonseptit Kafkan käyttämisessä ovat topicit (aihe) sekä partitiot. Topic tarkoittaa kafkassa käytännössä yhtä jonoa, johon voidaan dataa viedä tai noutaa. Jono voidaan sisäisesti jakaa useiksi partitioiksi. Jokainen partitio on käytännössä järjestetty sarja tietueita (record). Voimme kutsua näitä myös viesteiksi.
Producerit määrittelevät, mitä tietueita voidaan samanaikaisesti käsitellä, ja mitä on käsiteltävä lineaarisesti. Kun tuottaja luo tietueita, se voi määritellä avaimen tietueelle, jonka perusteella tietueet voidaan sijoittaa siten samaan partiotioon. Tämä takaa sen, että tietueet ovat järjestyksessä. Kafka vastaanottaessaan tietueen laskee tiivisteen (hash) avaimelle ja sijoittaa sitten tietueen oikeaan partitioon sen mukaisesti. (Koutanov 2020.)
Consumerit saavat dataa tilaamalla tietyn topicin ja liittymällä kuluttajaryhmään (consumer group). Kun consumer tilaa tällaisen topicin, saa se aluksi kaikki topicissa olevat partitiot käyttöönsä, mikäli muita consumereita ei ole. Tämän jälkeen seuraava liittyvä consumer saa puolet partitioista, eli näin saadaan jaettua kuormitusta järjestelmässä. Vastaavasti consumerin poistuessa jaetaan sillä olleet partitiot muille, vielä mukana oleville consumereille samassa ryhmässä. Kafka takaa, että kuluttajaryhmän sisällä ei koskaan anneta samaa partitiota useammalle kuin yhdelle consumerille. Useat kuluttajaryhmät voivat toki käyttää samaa topicia. (Koutanov 2020.)
Huomion arvioista Kafkassa on se, että tietueen lukeminen ei poista sitä järjestelmästä. Consumerit eivät voi siis poistaa dataa lainkaan jonoista/topiceista tai partitioista. Topicia voi muokata ainoastaan producer itse. Consumereilla on tieto lukemisen sijainnista (offset), jonka perusteella ne tietävät, mistä kohtaa luetaan seuraava tietue.
Kafka oletuksena tekee automaattista offsetin tallennusta 5 sekunnin välein. Tämä on kuitenkin useille sovelluksille huono vaihtoehto, koska datan käsittely voi olla vielä kesken. Jos siis operaatio epäonnistuu täysin ja consumer kaatuu, pitäisi sen seuraavalla kerralla yrittää käsitellä samaa tietuetta, mutta offset kertoo sen olevan jo käsitelty. On siis usein hyvä vaihtoehto muuttaa asetus enable.auto.commit asentoon false. (Koutanov 2020.)
Miten Kafka eroaa perinteisistä viestijonojärjestelmistä?
Kafka tarjoaa käytännössä yleisemmän mallin viestien välitykseen kuin monet muut järjestelmät. Kafkassa voidaan yhtä ja samaa topicia käyttää usean kaltaiseen tarkoitukseen useille erilaisille consumereille. Toinen mielenkiintoinen ero on se, että kafkasta viestit eivät oletuksena poistu, kun ne luetaan. Monissa muissa viestijärjestelmissä viesti poistuu, kun joku kuittaa sen käsitellyksi. (Koutanov 2020.)
Kafka on optimoitu suurelle määrälle viestien käsittelyä. Se kykenee kevyesti käsittelemään miljoonia viestejä sekunneissa. Yksi syy tähän on juuri se, että Kafka ei poista käsiteltyjä viestejä. Tämä ominaisuus poistaa levyoperaation, joka hidastaisi järjestelmää. Kafka myös käsittelee tietueita erissä, jolloin käsittely on tehokkaampaa. Tärkeä huomio on myös se, että Kafka ei synkronoi levylle asti tietueita ennen kuin se kuittaa producerille vastaanottamisesta, vaan se vie tietueen vain puskurille asti. (Koutanov 2020.)
Miinuspuolina Kafkan käyttöön voidaan nähdä esimerkiksi mahdollinen latenssi viestien välityksessä. Kafka on optimoitu suuren viestimäärän kuljettamiseksi, mutta ei varsinaisesti pienelle latenssille producerin ja consumerin välillä. Kafkan optimointiin on myös hyvin suuri määrä erilaisia parametreja, mikä voi tuntua etenkin vasta-alkajista hurjalta. Kafkan oletusasetukset voivat olla myös turvattomat joillekin sovelluksille. (Koutanov 2020.)
Turvallisuus ja autentikointimahdollisuudet
Entä turvallisuus ja autentikointimahdollisuudet? Kafka tukee TLS:n versiota 1.2, joten liikenne eri tahojen välillä saadaan turvattua. Tämän lisäksi on mahdollista konfiguroida SASL-pohjainen autentikointi (Kerberos,OAuth, SCRAM, yms). Autentikoinnin lisäksi Kafka tukee ACL:iä tarkemman autorisoinnin määrittelemiseksi. (Koutanov 2020.)
Carder (2022) esittää viisi erinomaista käytännön toimea, joilla saadaan varmistettua hyvä turvallisuus Kafkan kanssa.
- Autentikointi on syytä aktivoida Kafkassa.
- Kaikki yhteydet tulee salata. Yksi helppo ratkaisu tämän toteuttamiseksi ovat LetsEncrypt-sertifikaatit.
- Päivitetään järjestelmä säännöllisesti.
- Aktivoidaan ja konfiguroidaan ACL:t, eli pääsynhallintalistat
- Ei turhaan pelätä hankalampiakin tietoturvaa parantavia asioita, kuten SELinux. SELinux liian usein kytketään sallivaan tilaan tai jopa kokonaan pois päältä. Sen käyttäminen kuitenkin tuo lisäturvaa.
Käyttäjät eri rooleissa
Shapiran (2017) mukaan Kafkan käyttöön tutustumisessa on järkevä huomioida rooli, jossa olet Kafkan kanssa tekemisissä. Eri rooleissa olevat henkilöt operoivat eri tavoin Kafkan kanssa. Sovelluskehittäjät tarvitset jonkinlaisen kirjaston tyypillisesti Kafka topicien käyttämiseksi sovelluksessaan. On suositeltava luoda jokin pieni harjoitusprojekti, jossa kokeilee ensin sopivaa Kafka-kirjastoa. Soton (2022) mukaan Quarkuksessa on erinomainen tuki Kafkan käyttämiseksi. Quarkus on koko pinon kattava (full-stack) Kubernetes-natiivi Java-sovelluskehityksen sovelluskehys (framework). Soto (2022) kuvaa kirjoituksessaan kattavasti, miten Kafkaa käyttävän Quarkus-sovelluksen voi luoda.
Sysadminit taas joutuvat operoimaan varsinaisen Kafka-instanssin kanssa, eli huolehtimaan siitä, että se on ajossa, tarkistamaan sen lokeja sekä valvomaan sitä esimerkiksi JMX:n kautta. Tietovarastojen kanssa työskentelevät ihmiset taas ovat kiinnostuneita siitä, että tieto kulkee luotettavasti Kafkan kautta esimerkiksi MySQL-teitokannasta johonkin toiseen tietovarastoon. (Shapira 2017.)
Lähteet
Apache Kafka 2022. Dokumentaatio. Saatavilla https://kafka.apache.org/documentation/ Viitattu 14.11.2022.
Carder J. 2022. OpenLogic. https://www.openlogic.com/blog/apache-kafka-best-practicessecurity Viitattu 21.11.2022.
Koutanov E. 2020. Medium. Saatavilla https://medium.com/swlh/apache-kafka-in-a-nutshell-5782b01d9ffb Viitattu 14.11.2022.
Li S. 2020. He Left His High-Paying Job At LinkedIn And Then Built A $4.5 Billion Business In A Niche You’ve Never Heard Of. Forbes. https://www.forbes.com/sites/stevenli1/2020/05/11/confluent-jay-kreps-kafka-4-billion-2020/ Viitattu 14.11.2022.
Messetti A. 2022. Apache Kafka 3.3 Replaces ZooKeeper with the New KRaft Consensus Protocol. https://www.infoq.com/news/2022/10/apache-kafka-kraft/ Viitattu 15.11.2022
Shapira G. 2017. Apache Kafka: Getting Started. Saatavilla https://www.confluent.io/blog/apache-kafka-getting-started/ Viitattu 14.11.2022.
Soto A. 2022. Getting Started to Quarkus Reactive Messaging with Apache Kafka. https://www.infoq.com/articles/data-with-quarkus-kafka/ Viitattu 14.11.2022