Biba Egunean Behin: erronka teknologikoa

Aldibereko konexio kopuru altu hau ez da normalean Egunean Behinen izaten dugun konexio patroia, non egun guztian zehar konektatzen den jendea. Azpiegitura eta aplikazioa, horretarako dago berez egokitua.

Baina zuzeneko baten patroia diferentea da guztiz. Horrelako sistemek nahiko azkar kolapsatzeko joera izaten dute, sarri ikusi ahal izan dugu kontzertuetarako sarrerak erosteko, notak kontsultatzeko edo txertoa hartzeko txandak hartzeko uneetan; mundu guztia aldi berean konektatu eta sistema goitik behera blokeatzea nahiko arrunta da.

Erronka honi aurre egiteko egokitu behar izan genuen sistema. Sistema hau eta jarraitutako bidea azalduko da artikulu honetan, mugikorreko aplikazioari sostengua ematen dion azpiegituretan zentratuta.

Hasieran, aplikazio monolitikoa

Egunean Behin-en sistema arkitekturak jokoarekin batera eboluzionatu du. Hasiera batean, orduan jende gutxi ari zela, aplikazio monolitiko bat zen instalazio aldetik. Hau da, berau osatzen dituzten osagai desberdinak zerbitzari bakarrean zeuden, nahiz eta aplikazioa bera hiru geruzatan antolatuta egon: web zerbitzaria, aplikazioa eta datu basea.

Jokatu ahal izateko mugikorreko aplikazioa zerbitzariarekin komunikatzen da API bidez eta emandako erantzunak marrazten ditu. Partida sorrera eta gordetzea zerbitzarian egiten da (telefonoko aplikazioak ez daki zein den erantzun zuzena, tranpa egiteko pentsamenduan baldin bazeundete ere). Hau dela eta, aplikazioak eragiketa gehienetarako zerbitzariarekin komunikatu beharra du.

Erabilera zabaltzen joan zen neurrian hasierako instalazio monolitiko hori arazoak sortzen hasi zen, ezin baitzuen egindako eskaera kopurua egoki kudeatu. Puntu honetan izan zen lehenengo eboluzioa: hasiera batean bertikalki eskalatu genuen sistema, hau da, zerbitzari ahaltsuagoa jarri genuen. Baina honek ere muga jo zuenean arkitektura aldaketa bat beharrezkoa zela garbi geratu zen.

Horizontalki eskalatzen

Bigarren arkitektura honetan azpiegiturak horizontalki eskalatu genituen. Horretarako lehenik eta behin zerbitzu geruza bakoitza dedikatutako zerbitzarietan jarri genuen. Horrela web, aplikazio eta datu base mailako zerbitzuak bakoitza bere zerbitzari propiora mugitu ziren. Honek hainbat aukera zabaldu zizkigun, bai konfigurazio mailan, bai arkitektura eta zerbitzu geruza bakoitzaren beharrak egokitze aldera.

Konfigurazio mailan, ostatatutako zerbitzuari egoki zaizkion doitze fina egitea ahalbideratu zigun. Doitze hau zerbitzu guztiak zerbitzari bakarrean daudenean konplexuagoa da, zerbitzu batentzako egoki dena beste batentzako okerra izan baitaiteke. Hau horrela izanda ere, banaketa honek emandako arkitektura zabaltzeko aukerak izan ziren hazkundeari egoki erantzuteko tresnarik eraginkorrena. Izan ere, banaketa honekin geruza bakoitzean zerbitzari indar gehiago jartzea posible bihurtu zein eta botila-lepoa zegoen tokian aztertu eta konpontzeko aukera izan genuen.

Arkitektura hau da egun Egunean Behin martxan jartzen duena, baina egunerokotasuna ondo maneiatzeko gai izanda ere zalantzak geneuzkan zuzeneko batek dakarren portaerarekin berdin erantzungo ote zuen.

Zuzenekoetarako nahikoa ote? Testak egiten robotekin

Pasa den ostegunekoa ez zen izan zuzeneko partidak antolatzen genituen lehen aldia. 2020. urtean pandemiagatik etxean sartuta ginela Hiru Damatxoko lagunekin Youtube bitartez jolastu ahal izan genuen. Orduan izan genuen lehenengoz gure plataforma zuzenekoen mekanikara egokitzen zen frogatzeko beharra.

Froga hau burutzeko ezinbestekoa zitzaigun ingurune guztiaren kopia bat izatea, eta nolabait konektatutako erabiltzaile kopurua simulatzeko era. Lehenengoa lortzea ez da oso konplikatua gaur egun. Ditxosozko hodeian kokatutako zerbitzariak erabiltzen ditugu eta hornitzaileek zerbitzarien bikiak erraz asko martxan jartzeko aukera handiak ematen dituzte.

Erabiltzaileak lortzea ordea konplikatuagoa da, gure frogetan parte hartzeko benetako erabiltzaileak erabiltzea ez delako bideragarria. Benetako erabiltzaile hauek nolabait simulatu egin behar genituen, eta hori egiteko erabiltzaileek mugikorrean egiten dituzten eragiketak formal formal errepikatzen zituzten robotak programatu genituen. Robot hauek mugikorreko aplikazioak egiten dituen eskaera berdinak egiten dituzte partida bat jokatzeko orduan. Azkenik robot guzti hauek dantzan jarriko zituen tresna bat behar genuen. Horrelako tresnak asko dira, famatuena agian JMeter izango da, baina tira, gu Python zaleak garenez Locust izeneko tresna bat erabili genuen gure robotei bizitza emateko. Tresna honek, guk programatutako roboten nahi adina instantzia arrankatu eta programan zehaztutako eragiketak egiten jartzen ditu. Gainera maisu bat eta N langile independente martxan jartzeko aukera ematen du eta azken hau oso garrantzitsua da erabiltzaile kopuru handi bat simulatu nahi duzunean, makina bakarrarekin ezinezkoa baita 500-1000 erabiltzaile baino gehiago martxan jartzea makina ostalariaren baliabide guztiak xahutu gabe.

Birfaktorizazioa, katxeak eta ilara sistema asinkronoa

Behin tresneria prest izanda, frogei ekin genien, eta nahiko azkar ikusi genuen sistemak ez zuela behar bezala erantzungo. Eskaera zaparradak maila askotan itotzen zuen sistema, eta ez zen konpontzen makina gehiago jarrita. Denbora/kostu erlazioan eragiketa hau izaten da ekonomikoena, birfaktorizazio edo kode aldaketa bezalako eragiketen kostuarekin alderatuz, horregatik izaten da egiten den lehen aukera. Dena dela kasu honetan ez zuen funtzionatu, eragiketek behar baino gehiago irauten zuten eta eskaerak eten egiten ziren. Hortaz, aplikazioa aztertu eta erabilitako diseinu zein baliabideen birfaktorizazioari ekin genion. Hasieratik garbi ikusi genuen aplikazioak kudeatzen zituen eragiketa kopuruaren erantzun denborak txikitu behar zirela denak ondo funtzionatu zezan. Eta hor sartu ziren jokoan http katxeak eta lanentzako ilara sistema asinkronoa.

Katxe sistema hauekin, eskaera errepikakorrek behin bakarrik jotzen zuten gure datu basea (hauek dira eskaera astunenak), gero erantzun hau katxean gordetzen zen eta bertatik erabiltzaileari zerbitzatu. Kalkulurik inplikatzen ez dutenez erantzun denborak ikaragarri hobetzen dira. Hau ikusirik, gure aplikazioaren tripak eraldatu genituen ahalik eta zuku gehien ateratzeko katxe sistemari. Birfaktorazio honen ondoren soilik behar beharrezkoak diren eragiketak (partida eskatu, gorde,...) heltzen dira aplikaziora.

Bestalde lan guztiak momentuan atenditzea ezinezkoa zen zerbitzarietan gainkarga handirik sortu gabe. HTTP protokoloaren izaera dela eta bezero batek (mugikorrak) eskaera bat egiten duenean zerbitzariaren erantzuna espero du. Hau normalean momentuan etortzen da eta burutu nahi den eragiketaren emaitza izaten da (adibidez, partida gorde). Baina horrenbeste aldibereko eskaera izaten direnean sistemak estresatzen hasten dira, eta erantzun hori ezin bueltatuta geratzen da eta normalean bezeroan erroreren bat izaten dugu. Hau ekiditeko ilara sistema bat montatu genuen eta lan uholdea antolatzeko erabili genuen. Horrela momentu batean heltzen diren eskaera guztiak ilara sisteman erregistratzen dira geroxeago prozesatzeko. Geroxeago horren iraupena eragiketaren araberakoa da, ez da berdina partida jokatu gabe daukazun notifikazioa bidaltzea edo momentuko partida gordetzea. Lehenak gehixeago itxaron dezake, bigarrena atzeratzen bada erabiltzaile esperientzia galtzen da. Ilara sistema hau antolatzeko Celery izeneko liburutegi bat erabiltzen dugu. Sistema honek atzeratutako lanak nonbait gordeta izateko azpiegitura (broker deitua) behar du. Gure kasuan Redis datu base batean antolatu genuen brokerra.

Aldaketa hauek egundoko hobekuntza eragin zuten. Berriro robotak dantzan jarri genituen eta oraingoan bai, oraingoan sistema egonkor egotea eta azkar erantzutea lortu genuen. Horrelaxe egin genituen Youtubeko zuzenekoak, lehenengoa nerbio dexenterekin (pantaila beltzen aurrean geundenok behintzat) baina zuzenekoak burutu ahala lasaiago 5000 pertsonak jokatzen zuten bitartean.

Beste salto bat eskalan

Baina ostegunekoa telebista zen, erabiltzaile dexente gehiago izango zirela suposatzen genuen, kartutxo bakarra, ordu erdi zirt edo zart, ondo atera behar zen. Hortaz berriro ekin genion sistemaren egonkortasuna aztertzeari, baina oraingoan gure buruei erabiltzaile helburu bat jarrita. 30.000 aldibereko erabiltzailerentzako prestatu behar genuen sistema (ez genekien zenbat etorriko ziren, erabiltzaile kopuru totala kontuan hartuta estimazio bat egin genuen). Eta berriro jarri genituen dantzan gure robotak, baina oraingoan dexente azpiegitura gehiagorekin.

Froga puntu altuenean 26 zerbitzari (8 vCPU/ 16GB RAM) izan genituen gure sistema estresatzen. Baita lortu ere. Gure helburura heltzeko bidearen zati bat falta genuen. Makinak gehituta ere erabiltzaile kopurua estankatuta zegoen, berriro ere lupa atera eta arazoa nondik zetorren aztertu behar genuen. Kasu honetan katxera egiten genituen konexio kopurua izan zen arazo eta muga. Erabiltzaile kopuruak gora egin ahala katxeetara egiten ziren sare konexioak ere igo egiten ziren eta ez zuen denborarik ematen guztien lanak garaiz bukatzeko. Hortaz, konexio hauek taldekatzeko egin beharreko garapenak gehitu genituen. Eta garapen horiekin gure helmugara heldu ginen, egia esan gainditu genuen, baina zenbaki zehatza zein izan zen ez dugu kontatuko ;)

Sistema monitorizatzen

Azkenean Biba Egunean Behin ondo atera zelakoan gaude, 25.000 pertsona izan genituen jokoan parte hartzen eta prestatutako azpiegiturek orokorrean ondo aguantatu zuten. Zerbitzuak ikuskatzeko Prometheus eta Grafanan oinarritutako sistema bat prestatu genuen, eta horri esker momentuan erabakiren bat edo beste hartu behar izan genuen. Bertan ikusten da nola erabiltzaileen avatarrak sortzen dituen makina sufritzen ari den, eta hori dela eta erabiltzaileen irudiren bat falta izan zen. Gure robotek ez zituzten eskatzen irudi hauek, eta hori dela eta ez genuen aurreikusi.

Arazoa espero ez genuen tokian

Kontziente gara arazo batzuk egon zirela, pare bat galderatan irudirik ez genuen erakutsi. Normalean galdera bakoitzaren irudia zerbitzatzeko Content Delivery Network (CDN) bat erabiltzen dugu. Banaketa sare honek baliabidea erabiltzaileagandik gertuen daukan zerbitzaritik banatzen dute latentzia txikitzeko eta zerbitzari asko dauzkate munduan zehar barreiatuta. Honetaz gain gure konfigurazioan, irudiak katxeatzeko daukagu konfiguratuta, horrela irudi eskaera behin bakarrik helduko litzateke gure zerbitzarietara eta hortaz lan gutxiago izango dute.

Bueno, bada finalerako galderetan irudien helbidea ez genuen CDNra apuntatu, ezta katxera ere, eta eskaera guztiak gure zerbitzarietara heldu ziren behin eta berriro eta kasu batzuetan (dexentetan) ezin izan zuten irudia zerbitzatu. Eskuz egindako konfigurazio sinpleenak egin zigun huts. Min eman zigun, baina tira, hurrengokorako hartuko ditugu neurriak hau ere testeatzeko.

Ondorio modura

Azken kontutxo hau izanda ere pozik gaude, sarritan ez da izaten eta aukerarik horrelako sistema bat prestatu, aztertu eta martxan jartzeko. Hartutako eskarmentua handia izan da eta garrantzitsuena ateratako ondorioak dira, hemen labur labur azalduta:

• Txiki hasi gaitezke, baina handitzeko prest izan behar gara.
• Erabakiak hartu aurretik, neurtu, eta hartutakoan, neurtu, eta tartean neurtu, eta badaezpada, neurtu.
• Aldaketa txikiak egin eta ahal den neurrian isolatuta frogatu.
• Aplikazioaren diseinu garaian saiatu eragiketa astunak detektatzen eta ahal dela konponbide bat aurkitzen.