FinTech platna platforma sa visokim protokom transakcija doživljavala je ozbiljne kaskadne padove tokom stvarnih skokova transakcionog opterećenja. Neposredni simptomi obuhvatali su iscrpljivanje niti, iscrpljivanje konekcionog pula baze podataka, nagli rast latencije i tajmaute transakcija. Forenzička analiza je pokazala da osnovni problem nije bio nedostatak infrastrukture. Sam model konkurentnosti postao je usko grlo.
SWARCS je redizajnirao putanju upisa transakcija oko determinističkog vlasništva umesto arbitraže zasnovane na distribuiranim lock-ovima. Transakcije su ključane po account_id-u i rutirane kroz Kafku tako da se operacije koje pripadaju istom nalogu dodeljuju istoj particiji i obrađuju redosledom particije od strane konzumenta odgovornog za tu particiju. Redizajnirani tok kombinovao je particionisanu obradu događaja, validaciju stanja u memoriji i append-only perzistenciju. Time su distribuirane lock operacije uklonjene iz putanje upisa transakcija, a sistem je prešao sa koordinacije konkurentnih izvršilaca na rutiranje povezanog rada kroz determinističku processing putanju. Platforma je na taj način mogla da podrži značajno veći obim transakcija bez kaskadnog iscrpljivanja resursa koje je bilo prisutno u originalnom dizajnu.
Model konkurentnosti promenjen je sa koordinacije konkurentnog izvršavanja putem distribuiranih lock-ova na model u kome konkurentno izvršavanje koje dovodi do konflikta više nije potrebno za operacije koje pripadaju istom nalogu. Izmereni rezultati obuhvatili su smanjenje p99 latencije sa 4.500 ms na 18 ms, povećanje stabilnog protoka sa 3.200 TPS na 18.500+ TPS, smanjenje stope tajmauta transakcija sa 8,5% na 0,0% i smanjenje pritiska na konekcije baze podataka sa 100% na 26% u uslovima testiranog ciljnog opterećenja.
Platforma obrađuje FinTech platne transakcije u realnom vremenu koje utiču na stanja naloga i knjigovodstveno stanje kroz hiljade istovremeno aktivnih naloga. Ciljno opterećenje obuhvata transakcione pikove od približno 15.000 TPS.
Izazov je bio da se održi obrada transakcija pod visokim stepenom konkurentnosti, bez dozvoljavanja da troškovi koordinacije ugroze propusnost, latenciju ili konzistentnost stanja.
Nasleđena arhitektura koristila je Redis preko Redisson-a da obezbedi međusobno isključivanje kada više aplikacionih čvorova pokuša da ažurira stanje istog naloga. Sa porastom konkurentnosti transakcija, pribavljanje distribuiranih lock-ova i čekanje na njih postali su usko grlo u transakcionoj putanji.
[Istovremene transakcije]
|
v
+-----------------------+
| Spring Boot čvorovi |
| |
| Više JVM niti |
+-----------+-----------+
|
v
+-----------------------+
| Redisson distribuirani|
| lock / lease |
| |
| Kontencija |
+-----------+-----------+
|
v
+-----------------------+
| Ažuriranje naloga |
| |
| Baza podataka |
+-----------------------+
Veći saobraćaj
|
v
Veća kontencija lock-ova
|
v
Više blokiranih niti
|
v
Veći pritisak na konekcije
|
v
Veća latencija
|
v
Više isteka vremena
|
v
Više ponovljenih pokušaja
|
v
Veći saobraćaj
Ponovljeni pokušaji sa klijentske strane pojačavali su opterećenje već degradirane putanje obrade. Dodatni infrastrukturni kapacitet ili drugačija podešavanja isteka vremena za lock mogli su da promene trenutak nastupanja degradacije, ali nijedna od tih mera ne bi uklonila distribuiranu arbitražu iz transakcione putanje.
account_id
|
v
Deterministička particija
|
v
Jedinstvena putanja obrade
|
v
Sekvencijalna promena stanja naloga
Ključna promena odnosi se na mesto na kojem se kontroliše konkurentnost. Umesto arbitriranja o vlasništvu pomoću distribuiranih lock-ova, sistem usmerava transakcije za isti nalog u istu Kafka particiju i obrađuje njene zapise sekvencijalno. Različite particije mogu da napreduju konkurentno, dok nepovezani nalozi dodeljeni istoj particiji dele njenu granicu obrade.
+-------------------+
| Transakcija |
+---------+---------+
|
v
+-------------------+
| Spring Boot čvor |
+---------+---------+
|
v
+-------------------+
| Redis / Redisson |
| Distribuirani lock|
+---------+---------+
|
+----+----+
| |
v v
ČEKANJE IZVRŠENJE
| |
+----+----+
|
v
Ažuriranje baze
+-------------------+
| Dolazna |
| transakcija |
+---------+---------+
|
v
+-------------------+
| Apache Kafka |
| |
| Ključ: account_id |
+---------+---------+
|
v
+-------------------+
| Kafka particija |
| |
| Determinističko |
| rutiranje naloga |
+---------+---------+
|
v
+-------------------+
| Jedinstvena |
| putanja obrade |
| |
| Sekvencijalne |
| promene stanja |
+---------+---------+
|
+------------------+
| |
v v
+-------------------+ +-------------------+
| Caffeine | | Perzistencija |
| Stanje u memoriji | | događaja |
| i validacija | | dodavanjem zapisa |
+-------------------+ +-------------------+
|
v
+-----------------------+
| account_events |
| |
| Nepromenljivi događaji|
+-----------------------+
Kafka zapisi koriste account_id kao ključ, čime se, prema konfigurisanom modelu particionisanja, zapisi za isti nalog usmeravaju u istu particiju. Zapisi se obrađuju sekvencijalno unutar particije, uz očuvanje redosleda zapisa u njoj. Grupa potrošača dodeljuje particiju jednoj instanci potrošača u datom trenutku, mada se dodela može promeniti tokom rebalance-a. Paralelna obrada odvija se između particija, a ne između zapisa koji dele istu granicu obrade particije.
Sloj zasnovan na Caffeine-u održava često korišćeno stanje naloga u memoriji, blizu procesora, i omogućava validaciju transakcija bez ponovnog rekonstruisanja aktivnog stanja kroz blokirajuća čitanja iz baze podataka. Nepromenljivi zapisi stanja i eksplicitna logika zasnovana na enum tipovima čine prelaze između stanja jasno definisanim.
Model perzistencije promenjen je tako da umesto konkurentnih ažuriranja promenljivih redova naloga koristi model događaja naloga zasnovan na dodavanju novih zapisa.
Promena stanja i trajni upis događaja obuhvaćeni su istom atomskom transakcijom baze podataka. Time je obezbeđena njihova atomarnost unutar transakcije baze; to ne podrazumeva atomarnu koordinaciju sa kešom u memoriji ili upravljanjem Kafka offset-ima.
Kompozitni indeks omogućava pretraživanje događaja za pojedinačni nalog i pristup istoriji ledger-a prema rednom broju. Sam indeks ne definiše način dodeljivanja rednih brojeva niti garantuje određeni postupak oporavka.
Redizajn je promenio model konkurentnosti, a ne samo zamenio Redis Kafkom. Povezane transakcije sada prate determinističku, uređenu putanju obrade, a trajni transakcioni događaji dodaju se kao novi zapisi umesto da se konkurentnim ažuriranjima menja isti promenljivi red naloga.
Time se granica obrade definiše kroz model rutiranja, dok nezavisne particije mogu da napreduju konkurentno. Izmereni rezultati pokazuju poboljšanje pri testiranom opterećenju, bez tvrdnje da su svi mogući isteci vremena ili operativni otkazi eliminisani.
Smanjenje od 99,6%
Približno 5,8 puta veća stabilna propusnost
Nije uočeno pri testiranom opterećenju
Smanjenje od 74%
Uklonjene
Na izmerenom opterećenju, redizajn je objedinio veću stabilnu propusnost sa znatno nižom repnom latencijom i manjom iskorišćenošću pula konekcija. Rezultat u pogledu isteka vremena pruža dodatni dokaz poboljšanog ponašanja pod tim uslovima, dok uklanjanje operacija distribuiranih lock-ova potvrđuje suštinsku arhitektonsku promenu.
Determinističko rutiranje promenilo je način kontrole konkurentnosti transakcija: povezani posao pratio je uređenu putanju obrade bez distribuiranih lock-ova u putanji upisa. Pri testiranom opterećenju, izmereni rezultati pokazuju poboljšanja propusnosti, repne latencije, ponašanja u pogledu isteka vremena i iskorišćenosti pula konekcija.
SWARCS je sproveo arhitektonsku forenziku putanje obrade transakcija, identifikovao kontenciju distribuiranih lock-ova kao ključno usko grlo i redizajnirao obradu oko determinističkog rutiranja naloga. Rad je obuhvatio međusobni uticaj čekanja na lock-ove, raspoloživosti radnih niti, pritiska na konekcije baze, latencije i ponovljenih pokušaja klijenata, umesto da se ovi simptomi tretiraju nezavisno.
PRESTANITE DA SE NADMEĆETE ZA VLASNIŠTVO. UČINITE VLASNIŠTVO DETERMINISTIČKIM.
Suštinsko poboljšanje bilo je promena kontrole konkurentnosti, a ne samo promena infrastrukturnih komponenti. Determinističko rutiranje odredilo je gde se obrađuju povezane transakcije, dok je perzistencija dodavanjem novih zapisa odredila kako se njihovi trajni događaji čuvaju. Rezultujuća arhitektura smanjila je kontenciju u transakcionoj putanji, uz očuvanje mogućnosti paralelne obrade između particija.