Softwarearen erresilientzia aplikazio batek ondo eta fidagarritasunez funtzionatzen jarraitzeko duen gaitasunari esaten zaio, baita ustekabeko arazoen edo hutsegiteen aurrean ere. Fintech proiektuetan erresilientzia bereziki garrantzitsua da hainbat arrazoirengatik. Lehenik eta behin, enpresek arauzko baldintzak betetzera behartuta daude eta finantza-erregulatzaileek erresilientzia operatiboa azpimarratzen dute sistemaren egonkortasuna mantentzeko. Gainera, tresna digitalak ugaritzeak eta hirugarrenen zerbitzu-hornitzaileenganako konfiantzak Fintech negozioak segurtasun mehatxu handien aurrean jartzen ditu. Erresilientzia ere hainbat faktorek eragindako etenaldi arriskuak arintzen laguntzen du, hala nola zibermehatxuak, pandemiak edo gertaera geopolitikoak, negozioaren oinarrizko eragiketak eta aktibo kritikoak babesten.

Erresilientzia-ereduen arabera, softwareak etenaldiak jasan ditzakeela eta bere eragiketak mantentzea ziurtatzeko diseinatutako praktika eta estrategia onen multzoa ulertzen dugu. Eredu hauek segurtasun-sare gisa jokatzen dute, akatsak kudeatzeko, karga kudeatzeko eta hutsegiteetatik berreskuratzeko mekanismoak eskainiz, eta, horrela, baldintza kaltegarrietan aplikazio sendoak eta fidagarriak izaten jarraitzen dutela bermatzen dute.

Erresilientzia estrategia ohikoenak bulkhead, cache, fallback, berriro saiatu eta etengailua dira. Artikulu honetan, zehatzago eztabaidatuko dut, konpontzen lagun dezaketen arazoen adibideekin.

Bultzada

Ikus dezagun goiko ezarpenari. Oso aplikazio arrunt bat dugu atzean hainbat backend dituena datu batzuk lortzeko. Hainbat HTTP bezero daude backend horietara konektatuta. Bihurtzen da denek konexio-igerileku bera partekatzen dutela! Eta baita CPU eta RAM bezalako beste baliabide batzuk ere.

Zer gertatuko da, backendetako batek eskaeraren latentzia handia eragiten duen arazoren bat izanez gero? Erantzun denbora handia dela eta, konexio-talde osoa guztiz okupatuko da backend1-en erantzunen zain dauden eskaerekin. Ondorioz, backend2 eta backend3 osasuntsuetarako zuzendutako eskaerak ezin izango dira aurrera egin, igerilekua agortuta dagoelako. Horrek esan nahi du gure backendetako batean hutsegiteak aplikazio osoan porrot bat eragin dezakeela. Egokiena, huts egiten duen backendarekin lotutako funtzionalitateak soilik degradatzea nahi dugu, gainerako aplikazioak normal funtzionatzen jarraitzen duen bitartean.

Nola erabil dezakegu Bulkhead eredua arazo hau konpontzeko?

Bulkhead eredua aplikazio baten barruan hainbat baliabide mota isolatzeko erabil daiteke, zati batean hutsegite batek sistema osoan eragina izan ez dezan. Hona hemen nola aplikatu dezakegun gure arazoari:

1. Konexio-igerilekuak isolatzea Backend bakoitzerako konexio-talde bereiziak sor ditzakegu (backend1, backend2, backend3). Honek ziurtatzen du backend1 erantzun-denbora edo hutsegite handiak jasaten baditu, bere konexio-biltegia modu independentean agortuko dela, eta backend2 eta backend3-ren konexio-multzoak eraginik gabe utziko ditu. Isolamendu horri esker, backend osasuntsuek eskaerak normal prozesatzen jarraitzea ahalbidetzen du.
2. Atzeko jardueretarako baliabideak mugatzea Bulkheads erabiliz, atzeko planoko jardueretarako baliabide espezifikoak esleitu ditzakegu, hala nola loteka prozesatzeko edo programatutako zereginetarako. Horrek jarduera hauek denbora errealeko eragiketetarako beharrezkoak diren baliabideak kontsumitzea eragozten du. Esaterako, atzeko planoko zereginetara dedikatzen diren hari kopurua edo PUZaren erabilera muga dezakegu, sarrerako eskaerak kudeatzeko nahikoa baliabide eskuragarri egongo direla ziurtatuz.
3. Sarrerako eskaeren murrizketak ezartzea Bulkheads ere aplika daitezke sarrerako eskaera kopurua aplikazioaren atal ezberdinetara mugatzeko. Esate baterako, gorako zerbitzu bakoitzerako aldi berean prozesatu daitezkeen eskaera kopuruan gehienezko muga ezarri dezakegu. Honek backend bakar batek sistema gainditzea ekiditen du eta beste backend batzuek funtzionatzen jarraitu ahal izango dutela ziurtatzen du karga handian egon arren.

Mina

Demagun gure backend sistemek banaka erroreak aurkitzeko probabilitate txikia dutela. Hala ere, eragiketa batek backend horiek guztiak paraleloan kontsultatzea dakarrenean, bakoitzak modu independentean errore bat itzuli dezake. Errore hauek modu independentean gertatzen direnez, gure aplikazioan errore bat izateko probabilitate orokorra edozein backend bakarren errore probabilitatea baino handiagoa da. Errore probabilitate metatua P_total=1−(1−p)^n formula erabiliz kalkula daiteke, non n backend-en sistema kopurua den.

Esate baterako, hamar backend baditugu, bakoitza p=0,001eko errore-probabilitatearekin (% 99,9ko SLA-ri dagokiona), ondoriozko errore-probabilitatea hau da:

P_guztira=1−(1−0,001)^10=0,009955

Horrek esan nahi du gure SLA konbinatua % 99ra jaisten dela gutxi gorabehera, fidagarritasun orokorra nola murrizten den hainbat backend paraleloan kontsultatzean. Arazo hau arintzeko, memoriako cache bat ezar dezakegu.

Nola konpondu dezakegu memoriako cachearekin

Memoriako cache batek abiadura handiko datuen buffer gisa balio du, maiz atzitzen diren datuak gordetzen ditu eta iturri moteletatik ateratzeko beharra ezabatzen du. Memorian gordetako cache-ek % 0ko errorea izateko aukera dutenez datuak sarean eskuratzearekin alderatuta, gure aplikazioaren fidagarritasuna nabarmen handitzen dute. Gainera, cacheak sareko trafikoa murrizten du, akatsak izateko aukera gehiago murriztuz. Ondorioz, memoriako cache bat erabiliz, gure aplikazioan errore-tasa are txikiagoa lor dezakegu gure backend sistemekin alderatuta. Gainera, memoria barneko cache-k sarean oinarritutako bilketa baino datuen berreskurapena azkarragoa eskaintzen du, eta, ondorioz, aplikazioen latentzia murrizten da, abantaila nabarmena.

Memoria barneko cachea: cache pertsonalizatuak

Datu pertsonalizatuetarako, hala nola erabiltzaileen profilak edo gomendioak, memoriako cacheak erabiltzea ere oso eraginkorra izan daiteke. Baina erabiltzaile baten eskaera guztiak aplikazioaren instantzia berera doazela ziurtatu behar dugu, haientzako cachean gordetako datuak erabiltzeko, eta horrek saio itsaskorrak behar ditu. Saio itsaskorrak ezartzea zaila izan daiteke, baina eszenatoki honetarako ez dugu mekanismo konplexurik behar. Trafikoaren berreoreka txikia onargarria da, beraz, hashing koherentea bezalako karga orekatzeko algoritmo egonkorra nahikoa izango da.

Gainera, nodoaren hutsegite bat gertatuz gero, hashing koherenteak bermatzen du huts egin duen nodoarekin lotutako erabiltzaileek soilik berrereka egingo dutela, sistemaren etena gutxituz. Ikuspegi honek cache pertsonalizatuen kudeaketa errazten du eta gure aplikazioaren egonkortasun orokorra eta errendimendua hobetzen ditu.

Memoriako cachea: tokiko datuen erreplikazioa

Cachean gorde nahi ditugun datuak kritikoak badira eta gure sistemak kudeatzen dituen eskaera guztietan erabiltzen badira, hala nola, sarbide-politikak, harpidetza-planak edo gure domeinuko beste funtsezko entitate batzuk; datu horien iturburuak hutsegite puntu garrantzitsua sor dezake gure sisteman. Erronka honi aurre egiteko, ikuspegi bat datu hauek zuzenean gure aplikazioaren memorian guztiz errepikatzea da.

Eszenatoki honetan, iturriko datu-bolumena kudeagarria bada, prozesua abiarazi dezakegu datu horien argazki bat deskargatuz gure aplikazioaren hasieran. Ondoren, eguneratze-gertaerak jaso ditzakegu cachean gordetako datuak iturriarekin sinkronizatuta jarraitzen dutela ziurtatzeko. Metodo hau hartuta, datu erabakigarri horietara sartzeko fidagarritasuna hobetzen dugu, berreskuratze bakoitza memoriatik zuzenean gertatzen baita %0ko errore probabilitatearekin. Gainera, memoriatik datuak berreskuratzea oso azkarra da, eta horrela gure aplikazioaren errendimendua optimizatzen da. Estrategia honek modu eraginkorrean arintzen du kanpoko datu-iturri batean konfiantza izatearekin lotutako arriskua, gure aplikazioaren funtzionamendurako informazio kritikorako sarbide koherentea eta fidagarria bermatuz.

Birkargatu daitekeen konfigurazioa

Hala ere, aplikazioak abiaraztean datuak deskargatu beharrak, eta, ondorioz, abiarazte prozesua atzeratuz, aplikazioak abiarazte azkarraren alde egiten duen '12 faktoreko aplikazioaren' printzipioetako bat urratzen du. Baina, ez ditugu cachea erabiltzearen onurak galdu nahi. Dilema honi aurre egiteko, azter ditzagun irtenbide posibleak.

Abiarazte azkarra funtsezkoa da, batez ere Kubernetes bezalako plataformetarako, aplikazioen migrazio azkarra nodo fisiko desberdinetara oinarritzen baita. Zorionez, Kubernetes-ek abiarazte moteleko aplikazioak kudea ditzake abiarazte-zundak bezalako funtzioak erabiliz.

Aplikazioa martxan dagoen bitartean konfigurazioak eguneratzea izan dezakegun beste erronka bat da. Askotan, cachearen denborak doitzea edo eskaeraren denbora-muga behar da ekoizpen-arazoak konpontzeko. Nahiz eta gure aplikazioan eguneratutako konfigurazio-fitxategiak azkar zabaldu, aldaketa hauek aplikatzeak berrabiarazi behar du normalean. Aplikazio bakoitzaren abiarazte-denbora luzatuta, berrabiarazteko etengabeak nabarmen atzeratu dezake gure erabiltzaileentzako konponketak zabaltzea.

Horri aurre egiteko, irtenbide bat da konfigurazioak aldibereko aldagai batean gordetzea eta atzeko planoko hari bat aldian-aldian eguneratzea. Hala ere, zenbait parametrok, hala nola HTTP eskaeraren denbora-muga, HTTP edo datu-baseko bezeroak berriro abiaraztea eska dezakete dagokien konfigurazioa aldatzen denean, erronka potentziala sortuz. Hala ere, bezero batzuek, Javarako Cassandra kontrolatzaileak bezala, konfigurazioen birkarga automatikoa onartzen dute, prozesu hau sinplifikatuz.

Konfigurazio birkargagarriak ezartzeak aplikazioak abiarazteko denbora luzeen eragin negatiboa arin dezake eta onura gehigarriak eskain ditzake, hala nola, eginbide-marken inplementazioa erraztea. Ikuspegi honi esker, aplikazioen fidagarritasuna eta erantzuna mantentzea ahalbidetzen dugu konfigurazio eguneraketak modu eraginkorrean kudeatzen ditugun bitartean.

Erabakia

Ikus dezagun orain beste arazo bati: gure sisteman, erabiltzaileen eskaera bat backend edo datu-base batera kontsulta bat bidaliz jaso eta prozesatzen denean, noizean behin, espero diren datuen ordez errore-erantzun bat jasotzen da. Ondoren, gure sistemak erabiltzaileari "errore" batekin erantzuten dio.

Hala ere, eszenatoki askotan, hobeagoa izan daiteke apur bat zaharkitutako datuak bistaratzea datuak freskatzeko atzerapena dagoela adierazten duen mezu batekin batera, erabiltzaileari errore-mezu gorri handi batekin utzi beharrean.

Arazo honi aurre egiteko eta gure sistemaren portaera hobetzeko, Fallback eredua ezar dezakegu. Eredu honen atzean dagoen kontzeptuak bigarren mailako datu-iturburu bat izatea dakar, eta horrek kalitate edo freskotasun baxuagoko datuak izan ditzake lehen mailako iturriarekin alderatuta. Datu-iturburu nagusia ez badago erabilgarri edo errore bat itzultzen badu, sistema bigarren mailako iturri horretatik datuak berreskuratzera jo dezake, erabiltzaileari informazio motaren bat aurkezten zaiola ziurtatuz errore-mezu bat erakutsi beharrean.

Saiatu berriro

Goiko irudiari erreparatuz gero, orain aurrean dugun arazoaren eta cachearen adibidearekin aurkitu dugunaren arteko antzekotasuna ikusiko duzu.

Hori konpontzeko, berriro saiatu izenez ezagutzen den eredua ezartzea pentsa dezakegu. Cacheetan fidatu beharrean, sistema akatsen bat gertatuz gero eskaera automatikoki berriro bidaltzeko diseinatu daiteke. Berriro saiatu eredu honek alternatiba sinpleagoa eskaintzen du eta gure aplikazioan akatsen probabilitatea modu eraginkorrean murrizten du. Cachean gordetzea ez bezala, askotan cachea baliogabetzeko mekanismo konplexuak behar baititu datuen aldaketak kudeatzeko, huts egindako eskaerak berriro saiatzea nahiko erraza da inplementatzea. Cache baliogabetzea softwarearen ingeniaritzako atazarik zailenetako bat dela uste denez, berriro saiakera estrategia bat hartzeak erroreen kudeaketa erraztu eta sistemaren erresilientzia hobetu dezake.

Etengailu

Hala ere, berriro saiatu estrategia bat hartzeak ondorio potentzialak kontuan hartu gabe konplikazio gehiago sor ditzake.

Imajina dezagun gure backendetako batek porrot bat bizi duela. Egoera horretan, hutsegitearen backend-ean berriro saiakerak abiarazteak trafiko-bolumena nabarmen handitzea eragin dezake. Trafikoaren bat-bateko gorakada honek backend-a gainezka dezake, hutsegitea areagotuz eta sistema osoan kaskada-efektua eragin dezake.

Erronka honi aurre egiteko, garrantzitsua da berriro saiatu eredua etengailuaren ereduarekin osatzea. Etengailuak beheko zerbitzuen errore-tasa kontrolatzen duen babes-mekanismo gisa balio du. Errore-tasak aurrez zehaztutako atalasea gainditzen duenean, etengailuak kaltetutako zerbitzuaren eskaerak eteten ditu iraupen zehatz batean. Epe horretan, sistemak ez du eskaera gehigarriak bidaltzen huts egiten duen zerbitzuaren denbora berreskuratzeko. Izendatutako tartea igaro ondoren, etengailuak zuhurtziaz eskaera kopuru mugatu bat igarotzen uzten du, zerbitzua egonkortu den egiaztatuz. Zerbitzua berreskuratu bada, trafiko normala berreskuratzen da pixkanaka; bestela, zirkuituak irekita jarraitzen du, eskaerak blokeatzen jarraituz, zerbitzuak funtzionamendu normala berreskuratu arte. Etengailuaren eredua berriro saiatu logikarekin batera integratuz, errore-egoerak modu eraginkorrean kudea ditzakegu eta sistemaren gainkarga saihestuko dugu backend akatsetan.

Biltzea

Amaitzeko, erresilientzia-eredu hauek ezarriz, gure aplikazioak larrialdien aurrean indartu ditzakegu, erabilgarritasun handia mantendu eta erabiltzaileei esperientzia ezin hobea eskaintzeko. Gainera, azpimarratu nahiko nuke telemetria proiektuaren erresilientzia eskaintzean ahaztu behar ez den beste tresna bat dela. Erregistro eta neurketa onek zerbitzuen kalitatea nabarmen hobetu dezakete eta haien errendimenduari buruzko informazio baliotsuak eman ditzakete, gehiago hobetzeko erabaki informatuak hartzen lagunduz.