Sådan fik Nordea has på ‘Dødsstjernen’ med Kafka

Hao Shen og Niels Bjørkøe (th.) fra Nordeas platformshold har bragt køserveren Kafka til bankens applikationer. Illustration: Tania Andersen
Open source-køsystemet Kafka løste bankens problem med applikationer, der snakker på kryds og tværs af hinanden. Men der skal knofedt til for at få systemet til at spille på bankverdenens præmisser.

En bank som Nordea, der har fundet sin ganske store form gennem opkøb af en lang række pengeinstitutter, har også et pænt udvalg af de seneste tredive års it-teknologier i stalden. Derfor er der også plads til kø-serveren Apache Kafka.

Den er ellers mest tiltænkt anvendelser, hvor mange små hændelser skal processeres - såsom klik på en webside. Men softwaren kan også bruges i en bank.

Det fortæller Niels Bjørkøe fra Nordea, som sammen med sin kollega Hao Shen gav et indblik i bankens anvendelse af kø-systemet på Goto Copenhagen-konferencen, der afholdes i Bella Center i København i disse dage.

Det er 'Dødsstjernen', som Kafka skal gøre kål på:

»Dødsstjerne-arkitektur er den situation, hvor du har en stribe applikationer, der alle sammen snakker med hinanden,« forklarer Niels Bjørkøe efterfølgende til Version2.

Det kaldes for Dødsstjernen, som kendt fra Stjernekrigsfilmene, fordi det er stort og ondt - og svært at slå ihjel.

Løsningen er publish-subscribe, udgiv og abonner, hvor et centralt postkontor holder styr på det samlede systems meddelelser på en disciplineret facon. Postkontoret er Apache Kafka.

Det, der efter Niels Bjørkøes mening gør Kafka mere anvendelig for banken end andre systemer, som f.eks. Rabbitmq, der er en anden populær køserver, er, at Kafka selv gemmer sine beskeder, samt at et flow af beskeder kan afspilles igen, så at sige. Dertil kommer Kafkas distribuerede natur, som gør, at systemet spiller videre, selv hvis nogle af systemets noder går ned.

Læs også: Tjep køkultur med Apache Kafka

Skulle pakkes ind i sikkerhed

Nordea tog hul på Kafka for tre år siden. Ved starten var Kafkas manglende sikkerhed den første udfordring, som skulle løses. Der var også mangel på værktøjer til systemet, og det hverken var eller er gearet til meddelelser i den størrelse, som der kræves til bankforretning - nemlig én megabyte eller mere pr. meddelelse. Der var også mangel på klient-bindinger til sprog og miljøer.

Det første skridt på vejen bestod i at 'pakke Kafka ind i sikkerhed', som Niels Bjørkøe udtrykker det. Dernæst blev systemet driftet og styret som en central tjeneste. Men det var ikke lige det, som Nordeas forskellige udviklerhold ville have. De vil nemlig helst selv styre farten, og løsningen blev en portal, hvor holdene selv kan starte deres egne køer, som at oppe at køre efter to minutter.

Systemet behandler 45 millioner hændelser pr. dag, fordelt over 62 applikationer. Der har været fem minutters nedetid på et år, og det var vist selvforskyldt, forstår man på Niels Bjørkøe. Dertil kommer, at systemet er tunet til aldrig at tabe en besked.

Dumme rør og kloge slutpunkter

Kafka er skruet sammen som en ‘commit log,’ forklarer Hao Shen fra Nordea. En kø kaldes for en ‘topic’, og såkaldte producenter tilføjer meddelelser, mens konsumenter modtager og læser dem. Det handler om at have dumme ‘pipes’, rør, og kloge endpoints, indgange til applikationerne.

En vigtig egenskab for Nordea er at man kan ‘spole tilbage’ i køen og læse tidligere meddelelser én gang til, hvis det skulle være nødvendigt.

Det centrale punkt er, som tidligere nævnt, at undgå ‘Dødsstjernen’, hvor alle processer kommunikerer på kryds og tværs, fra punkt til punkt. Udgiv/abonner-modellen forsimpler systemet væsentligt.

De vigtige punkter i forhold til Kafka til bankdrift er sikkerhed, garanti for modtagelse og oppetid, fastslår Hao Shen.

Sikkerheden, som altså ikke var til stede i Kafka som udgangspunkt, blev klaret ved at benytte sikkerhedsprotokollen TLS (efterfølgeren til SSL), samt en eksplicit access control list, som klart fortæller, hvilke brugere der har rettigheder til at læse og/eller skrive. Der anvendes certifikater i begge ender, altså både for server og klient.

Noder på klynger giver driftssikkerhed

Sikkerhed er én ting, men oppetid er også vigtig, og her er Kafkas model som et system af klynger det helt rigtige valg. Hvis én node står af, kører køen videre på en anden. Det fungerer også godt sammen med bankens forskellige driftscentre, der er fysisk placeret langt fra hinanden, som det er standarden i bankverdenen.

Systemet er endvidere konfigureret til ikke at tabe beskeder, samt garantere i hvert fald én modtagelse, af en besked. Derudover ankommer meddelelserne i den rækkefølge, de er afsendt.

Et problem med Kafka kunne Nordea dog ikke løse. Det er størrelsen på meddelelser, der som tidligere nævnt er på en megabyte og opefter. Sådan er det bare inden for finans, så her måtte platformsholdet finde på en anden løsning.

Den bestod i at skabe et eksternt storage-system til indholdet i meddelelserne. Selve meddelelsen er nu en url, som peger på en binær blob i et lager. Med protokollen gRPC kan indholdet i meddelelsen hentes, også med TLS og certifikater i begge ender, og genbrug af Kafkas access control list.

Hao Shen viser, hvordan udviklingsholdene kan få sig en kø gennem høflig selvbetjening på en webportal, der nærmest ligner et stykke forbrugersoftware. Gennem portalen kan holdene provisionere køen uden at skulle få tilladelse fra centralt hold, sådan som de agile dyder også foreskriver.

I den efterfølgende spørgetid kommer Hao Shen ind på problematikken med eksempelvis personoplysninger, som skal slettes fra systemet inden for en bestemt tidsfrist.

Det problem er løst ude i verden, fortæller han, og måske skulle Rigspolitiet lytte med: Man krypterer blot meddelelsen, og når tidsperioden er udløbet, smides nøglen væk. Selv om meddelelsen stadig ligger et sted på en disk eller et bånd, kan den ikke læses.

Læs også: Rigspolitiet: ANPG-data skal slettes efter 30 dage - men ikke i backup-systemet

En anden publikummer vil vide, om Kafka kun er anvendeligt til kæmpe-firmaer som Nordea, eller om små virksomheder med en håndfuld udviklere også kan få gavn af det.

»Jeg kom fra en mindre virksomhed, som anvendte Kafka, før jeg skiftede til Nordea,« fortæller Niels Bjørkøe.

»Hvis det passer til formålet, så brug det.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Sune Marcher

Det lyder lidt som at forsøge at lappe en problemstilling med en løsning, som så også skal lappes/tilrettes.


Et andet syn på sagen kunne være at man har valgt en komponentbaseret tilgang til softwareudvikling, hvori kafka er én komponent der udfører sit tiltænkte arbejde rigtigt godt - men skal suppleres af komponenter, der håndterer andre dele af det samlede system.

Det er desværre en af de talks der ikke blev filmet, og jeg valgte selv at se State or Events? Which Shall I Keep? - det kunne have været interessant at høre lidt mere om sikkerhedsaspekterne, bl.a. hvor meget der er tweaking af indstillinger og hvad der krævede in-house programmering.

  • 1
  • 1
Denny Christensen

Jeg er ikke enig - jeg ser mere en kø/esb/whatever som en realistisk metode til at opløse 117 mil point-to-point integrationer af forskellig teknisk karakter, modenhed og driftsstabilitet.

Det giver et umuligt driftmiljø, hvori ændringer er ganske uoverskuelige at gennemføre.

En mere metodisk, komponentbaseret og event driven tilgang løsner, efter min mening og erfaring, ganske meget op for den hårknude arkitektur der kommer ud at af fikse ting een ad gangen (Dødsstjerne er nu en fantastisk benævnelse).

  • 2
  • 0
Log ind eller Opret konto for at kommentere