Sprievodca modernou middleware architektúrou v Raiffeisen Processing Centre
V dnešnom rýchlo sa meniacom finančnom sektore je spoľahlivosť viac než len funkciou – je nevyhnutnosťou. Keď vaša spoločnosť poskytuje služby bankám nad tak kritickým produktom, akým sú platobné karty, aj najmenšie zaváhanie môže mať ďalekosiahle dôsledky. Toto platí najmä pri architektúrach postavených na mikroslužbách, kde každý komponent musí byť robustný aj pod značnou záťažou. V tomto článku preskúmame princípy odolnosti voči chybám v takýchto ekosystémoch, predstavíme si reálne implementačné stratégie z našej Raiffeisen Processing Centre (ďalej len RPC) kuchyne a zdôrazníme základné knižnice a nástroje, ktoré pomôžu možno aj Vašim API odolať neočakávaným situáciám.
Pochopenie architektúry: Gateways, Domains a Facades
Predstavme si robustný core systém, ktorý nemá ambíciu poskytovať služby okoliu moderným štandardom či protokolom. Svoju úlohu plní skvele, avšak potrebuje výkonný middleware, ktorý vystaví jeho funkcionalitu voči nenásytnému okoliu. Presne o takomto middleware sa budeme rozprávať a popíšeme si jeho architektúru pozostávajúcu z troch vertikálnych rezov na báze mikroslužieb:
- Gateways: Vstupné body pre požiadavky bánk, ktoré sa starajú o autentifikáciu, smerovanie a počiatočnú validáciu.
- Domains: Špecialisti na biznis logiku, každý zodpovedný za určitú časť kartového ekosystému (napr. karty, klientské kontrakty, transakcie).
- Facades: Integračná vrstva spájajúca domény s backendom a core systémami, abstrahujúc zložitosť starších systémov alebo služieb tretích strán.
Každá skupina je kľúčová a zlyhanie jednej môže mať kaskádový efekt na celý systém. Preto je odolnosť voči chybám nevyhnutná.
Zdroj: Interný dokument RPC
Čo znamená odolnosť voči chybám v tomto kontexte?
Odolnosť voči chybám je schopnosť vašich API a podkladových mikroslužieb – pokračovať vo fungovaní aj pri najmenšom zlyhaní. Či už kvôli sieťovým problémom, aplikačným chybám, preťaženiu alebo prerušovaným výpadkom backendu. Vo finančnom odvetví je potrebné byť vždy k dispozícii a poskytovať kritické služby užívateľom. RPC ako člen skupiny Raiffeisen Bank International musí poskytovať služby svojim bankám s čo najnižším „downtime“ a plniť tak prísne SLA definované bankou.
Kľúčové stratégie pre robustné API v RPC
Odolnosť voči chybám nie je možné dosiahnuť jednou stratégiou – je to súbor praktík a technológií, ktoré musia spolupracovať. Tu popisujeme tie, ktoré nám v RPC pomáhajú dosahovať čo najlepšie výsledky:
1. Circuit Breakers
Circuit breaker bráni ako klientom, tak aj iným mikroslužbám opakovane skúšať operáciu, ktorá pravdepodobne zlyhá – napríklad, ak ďalšia služba v rade nereaguje. Namiesto toho sa circuit breaker aktivuje a požiadavka rýchlo zlyhá, čo umožňuje systému kontrolovane reagovať a rýchlejšie sa zotaviť.
Príklad: Naša doménová služba na vytváranie karty závisí od fasády, ktorá integruje core systém. Ak je core systém nedostupný, circuit breaker zasiahne, vráti kontrolovanú chybu a zabráni vyčerpaniu zdrojov. Tento mechanizmus musí byť však stabilne podložený biznis procesom a používať sa iba tam, kde to dáva zmysel.
Populárne knižnice:
- Resilience4j (Java/Spring Boot)
- Hystrix (legacy, pre Java)
- Polly (.NET)
2. Retries with Backoff
Dočasné chyby – napríklad sieťová porucha – je možné vyriešiť opakovaním neúspešnej operácie po krátkom čase. Exponenciálne oneskorenie zvyšuje intervaly medzi pokusmi, aby nedošlo k zhoršeniu problému. Aj keď sa tento mechanizmus využíva pomerne často, vzhľadom na povahu nami poskytovaných služieb pre nás nemá veľký význam. Význam by sme naopak videli pri jeho implementácii na strane klienta – teda banky.
Príklad: Pri získavaní zoznamu kariet klienta, klientovi vrátime v odpovedi status 503 z dôvodu nedostupnosti niektorej z vrstiev. Klient môže skúsiť zopakovať požiadavku niekoľkokrát s rastúcimi intervalmi, než nakoniec príjme chybu. Je to samozrejme pre prípady, kedy náš middleware neodošle klientovi „retryAfter“ hlavičku, ktorá popisuje klientovi, koľko by mal čakať pred ďalším pokusom.
Knižnice/nástroje:
- Spring Retry (Java/Spring Boot)
- Resilience4j Retry modul
- Polly Retry (pre .NET)
3. Timeouts
Častou chybou distribuovaných systémov je nechať volania bežať navždy. Čas pre spracovanie sa snažíme nastavovať na základe analytických dát a prispôsobovať ich zložitosti danej operácie. Vstupujú do toho samozrejme aj SLA dohodnuté s klientom.
Aktuálne pracujeme s myšlienkou distribuovať časový limit na odbavenie danej požiadavky medzi mikroslužbami. Časový limit by sme posielali HTTP hlavičkou na každý ďalší komponent v rade a informovali ho tak, koľko času má na vykonanie danej operácie. V zásade sa jedná o jednoduchý návrh, implementácia sa však môže poňať viacerými spôsobmi, napríklad týmto :
Zdroj: Interný dokument RPC
4. Rate Limiters
Základnou ochranou proti preťaženiu je určite vstupná ochrana na báze počítadla požiadaviek v čase. Je viacero možností, ako limitovať počet dotazov voči aplikácii. My sme sa rozhodli limitovať ich priamo na sieťovej úrovni, teda loadbalancermi. Nie je to však úplne jednoduché, nakoľko si nemôžeme dovoliť určiť jeden globálny limiter pre všetky banky. Každú banku musíme limitovať osobitne. Tie limity sú formálne dohodnuté na základe analýz očakávanej záťaže. V praxi to môže vyzerať tak, že banka A má dohodnutý limit 20 dotazov zasekundu a banka B zase 10 dotazov za sekundu.
Ak by sme nastavili globálny limiter na napr. 120 dotazov za sekundu, niektoré banky by mohli využiť rozhranie na dávkové spracovanie veľkých objemov takým spôsobom, ktorý by im umožnil získať neprimeraný podiel výhod na úkor ostatných účastníkov trhu. Tým by ostatné banky trpeli na nedostupnosť našich služieb. Dôležité je spomenúť fakt, že bánk/konzumentov máme niekoľko. Core systém však iba jeden a je potrebné si ho chrániť.
5. Odlievanie dát
Ďalším mechanizmom pre ochranu core systému v RPC je možnosť odlievania dát do menších – dostupnejších lokálnych databáz. Tieto databázy sú škálované na vysokú dostupnosť a vysokú záťaž tak, aby boli dáta čo najbližšie ku klientovi v akomkoľvek čase. Týmto nám odpadá nutnosť smerovať každý dotaz na core systém, čím zvyšujeme jeho dostupnosť pre iné služby, kde odlievanie dát nedáva zmysel.
Treba však podotknúť, že kľúčom k úspechu je pravidelná synchronizácia dát s core databázou.
6. Monitoring a Alerts
Monitoring a alerting nie je nutné bližšie rozoberať. Je to alfa-omega prevádzky každého IT systému. Reagovať na problém expresne a adresne je nutnosť aj v našom prípade, nakoľko sa aj najmenšie výpadky priamo dotýkajú držiteľov platobných kariet.
Nástroje:
- Prometheus/Grafana na monitorovanie
- ELK Stack na logovanie
- Jaeger/Zipkin na distribuované trasovanie
Reálna odolnosť voči chybám v praxi
Prejdime si scenár pri vytváraní platobnej karty pre klienta banky:
- Banka iniciuje požiadavku na vytvorenie novej karty cez gateway.
- Gateway vykoná validáciu a pošle požiadavku do príslušnej doménovej služby.
- Doménová služba spracuje biznis logiku a oslovuje fasádnu vrstvu pre integráciu s core kartovým systémom.
- Ak je fasáda nereagujúca kvôli výpadku core systému:
– Circuit breaker v doménovej službe zasiahne a po dosiahnutí prahovej hodnoty rýchlo ukončí požiadavku.
– Gateway vráti banke zrozumiteľnú chybu, prípadne s odporúčaním na opakovaný pokus neskôr, použitím „retryAfter“ hlavičky.
– Monitorovacie systémy upozornia technikov.
Počas celého procesu zbierame metriky služieb a distribuované trasovanie pomáha určiť príčinu poruchy.
Odporúčané knižnice a nástroje
Tu je zoznam osvedčených riešení na implementáciu „fault tolerance“ vo Vašom technology stacku:
- Resilience4j: Ľahká, modulárna knižnica pre Java mikroslužby (circuit breaker, retry, bulkhead, rate limiter).
- Spring Cloud: Integruje Resilience4j a poskytuje komplexné vzory pre Spring Boot aplikácie.
- Polly: Rozšírené riešenie pre .NET.
- Istio: Service mesh pre pokročilé riadenie prevádzky, circuit breaker a telemetriu v Kubernetes prostredí.
- Prometheus & Grafana: Monitorovanie a upozorňovanie na dostupnosť a výkon mikroslužieb
- Jaeger/Zipkin: Distribuované trasovanie pre vizualizáciu API volaní naprieč mikroslužbami.
Dôveruj, ale preveruj… v rozumnej miere
Budovanie odolných API v ekosystéme poskytovania finančných služieb je technickou výzvou aj obchodným imperatívom. V RPC z povahy kartového biznisu nie je príliš priestor na chyby a nedostupnosť, preto musíme naše systémy patrične chrániť a neustále zdokonaľovať. Je však dôležité nájsť správny kompromis medzi ochranou systému a spokojnosťou na strane klienta. Ľahko sa môže stať, že prílišnou robustnosťou budete klienta limitovať až príliš, čo môže mať negatívny dopad na samotný biznis. Ochrana systému by mala mať čo najmenší dopad na klienta a sledovať reálne požiadavky a hrozby a nie sa snažiť za každú cenu vytvárať prevenciu voči scenárom, ktoré s najväčšou pravdepodobnosťou nikdy nenastanú.
——-
V Raiffeisen Processing Centre (RPC) poskytujeme centralizované služby súvisiace s platobnými kartami.
Sme jednou z najväčších spracovateľských spoločností v regióne pre strednú a východnú Európu, ktorá ročne spracuje viac ako 2 miliardy platobných transakcií Ako súčasť Raiffeisen Bank International skupiny poskytujeme bezpečné a spoľahlivé kartové služby bankám a vyvíjame platobné riešenia ako digitálna peňaženka, merchant portal, platobná brána a iné.
Na riešeniach pracuje 260+ zamestnancov, 39% tvoria ženy, z ktorých 30% pracuje priamo na technických pozíciách.
Zdroj: Codecon.sk