Urrian argitaratu zen Mihiluze ETB1-eko programaren aplikazioa, zeinak saioko azken proban etxetik jokatzeko aukera ematen duen. CodeSyntax-en garatu dugu aplikazioa zein honen azpiegitura, eta aurrez erabilitako teknologiatan oinarritu arren, proiektu honen tipologiak erronka berriak ekarri dizkigu bereziki azpiegitura aldean.

Urriaren 16an jokatu zen Mihiluze aplikazioko aurreneko lehiaketa. Programan egiten den moduan, BAI EDO BAI izeneko proban erabiltzaileek 11 elementu markatu behar dituzte egiten zaien galderaren arabera. Behin hau eginda, Urrezko Galderari erantzuna emateko beste bi hautatu behar dituzte. Bi ataletan asmatutako erantzunen arabera puntuazio -dirua telebistan- jakin bat lortzen dute erabiltzaileek. Behin asteko lau saioak pasata, puntuazio akumulatu gehien duenak asteko saria jasotzen du. Sailkapen orokorraz gain, Egunean Behin-en moduan taldeen sailkapenak daude, familia, lagun, lankide, eta abar luze baten artean pike hori sortzeko. Programa bakoitzeko sailkapenaz gain, astekoa ere kalkulatzen da talde bakoitzeko.

Arkitektura teknikoa

Aplikazioaren zein honek eskatzen duen azpiegitura teknikoaren garapena CodeSyntax-en gauzatu dugu. Egunean Behineko zuzeneko programekin lortutako eskarmentuaz argi izan dugu sortu beharreko azpiegituraren oinarria, zeinak minutu gutxi batzuetan idazketa eta irakurketa tasa handiak prozesatu behar dituen. Honakoak dira funtsean erabiltzen diren elementuak:

  • Karga balantzeadorea: Aplikazioetatik heltzen diren eskaera guztiak barne zerbitzarietan banatzeko, hauen karga orekatuta mantentze aldera.
  • N Zerbitzari "frontal": Balantzeadoretik -aplikazioetatik- datozen eskaerak jaso eta erantzuna emateko.
  • N Zerbitzari "celery": Lan asinkronoak exekutatzeko: partiden gordetzea, sailkapenen kalkulua, etab.
  • Datu Basea: Erabiltzen diren datu guztiak gordetzeko.
  • Cache zerbitzariak: Aplikazioan eskaintzen diren zenbait datu memorian gordetzeko, behin eta berriz datu basetik ez ekartze aldera.
  • Lan asinkronoen ilara kudeatzen duen zerbitzaria.

Egitura honek eskalabilitate bertikal zein horizontala ahalbidetzen digu. Batetik, jartzen ditugun makinek prozesamendu kapazitate nahikoa ez dutela ikusiz gero, makinak "handitu" ditzakegu, hardware gehiago eman alegia. Bestetik, mota bakoitzeko behar beste zerbitzari gehitu daitezke lanak guztien artean banatze aldera.

Hasierako planteamendua hau izanik, urriak 16rako 5 "frontal" eta 4 "celery" prest utzi genituen, etorri zitekeen erabiltze kopuruaren aurreran prest egoteko. Azpiegiturak ongi erantzunda, prestatutako soluzioa egokia zela bermatu genuen, baina noski, guzti honek koste ekonomiko altua dauka. Gainera, programa gauean emititzen denez, aplikazioaren trafikoa hor konzentratzen da eta egunean zehar oinarrizko akzioak egiteko erabil daiteke soilik: erabiltzaile eta taldeak sortu, argazkia aldatu eta sailkapenak edo aurreko partidak begiratu.

Panorama horrekin argi ikusi genuen aukera onena -praktikoki eta ekonomikoki- egunean zehar ahalik eta zerbitzari gutxienekin egotea zela, eta gauerako behar besteko makinak gehitzea. Gure zerbitzari hornitzaileak orduka fakturatzen dizkigu erabilitako makinak, hortaz, asimilatu dezakegun gastua da gauean bi orduz makina gehigarri horiek martxan edukitzea. Baina nola egin hau? Kudeaketa paneletik modu nahiko errazean sortu daitezke eta proiektura gehitu, baina eskulana eskatzen du: gauero teknikari batek programa aurretik zein ostean makinak gehitzeko eta kentzeko prozesua egin beharko luke. Posible? Bai, baina praktikoa ez. Hausnarketa egiteaz batera bururatu zitzaigun gure Urrezko Galdera: badago modurik guzti hori automatikoki egiteko?

Prozesu automatikoa

Segituan ikusi genuen erantzuna baiezkoa zela, gure hornitzailean normalean eskuz egiten ditugun operazioak API bitartez egin daitezkeelako, hemen behar genituen guztiak barne. Beraz, egin beharreko bakarra API hori ikertu eta prozesu dena aurrera eramateko kodea garatzea zen. Hala egin genuen, honako prozesua sortuz:

  1. Gaurko egunean lehiaketarik dagoen begiratu. Asteko lehiaketa guztiak datu basean gordetzen dira, beraz badakigu zein egunetan jokatu daitekeen edo ez. Programarik ez badago, ez egin ezer.
  2. Sortu beharreko makinak dagoeneko martxan ez daudela ziurtatu. Dena delakoagatik sortu beharreko makinak jada martxan badaude, prozesua moztu.
  3. Gehitzera goazen makinen eredu edo "snapshot"-ak lortu. Enpresan jarraitzen dugun politika da zerbitzari guztien kopiak egitea egunero, urgentziazko arazo baten aurreran (erasoak, datu galerak...) gutxienez aurreko eguneko bertsioa eskura izateko. Kopia hauek noiz egin konfiguratu dezakegu, eta kasu honetan arratsaldean egiten ditugu. Zergatik? Egunean zehar egiten ditugun aldaketak jasotzeko. Modu honetan, zuzenketa edota hobekuntza bat igota, gauean gehituko diren makinak eguneratuta egongo direla bermatzen dugu.
  4. Makina berriak sortu ereduetatik abiatuta: zerbitzari mota bakoitzaren kopietatik abiatuta N nodo sortu daitezke. Gure kasuan parametrizatuta dauzkagu mota bakoitzean sortu beharreko kopuruak, egunen batean gehiegi edo gutxiegi direla ikusiz gero aldaketa modu azkarrean egiteko. Sorrera prozesuaren egoera konprobatu dezakegunez, denak modu egokian gehitu direla bermatzen dugu, gutxi gora behera minutu inguruz zain egonda.
  5. Frontal makinak karga balantzeadorera gehitu: Behin makinak sortuta, eskaerak jasoko dituzten makinak balantzeadorean sartzen ditugu, bestela ez dute ezer jasoko eta. Hemen ere, esleipen hauek ongi egiten direla ziurtatzen dugu.
  6. Celery makinak martxan eta prest daudela begiratu: Makina hauek zuzenean konektatzen dira lan asinkronoen ilarak kudeatzen dituen zerbitzarira, beraz sortu eta gutxira prest daude lanak jasotzeko. Zerbitzari bakoitzeko prozesuen izenak zeintzuk izango diren badakigunez -makinaren izenaren arabera sortzen dira-, hauek martxan egon arte zain egoten gara.

Prozesu guztia amaitzean, egiten ditugun konprobaketa guztien ondorioz badakigu dena behar bezala joan dela. Zehaztutako puntuetako batek huts egiten badu, jakinarazpen bat jasotzen dugu zer gertatu den azalduz. Kasu horretan -oraindik ez da gertatu- eskuz egin beharko genituzke faltan leudeken lanak.

Behin programa amaituta, margen txiki bat ematen dugu oraindik trafikoa egunean zehar baina altuagoa izango dela ikusita: jendea bere partidak ikusten dabil, sailkapenak begiratzen... Tarte hori pasatzean alderantzizko prozesua abiarazten dugu sortutako makina gehigarriak desaktibatu, itzali eta ezabatzeko. Izan ere, makina hauek itzalita egonda ere fakturazioan sartzen dira.

Ondorioak

Modu laburrean azaltzeko, hauek dira prozesu honen bitartez lortu ditugunak:

  • Programa abian dagoenerako azpiegitura indartsua martxan izaten dugu, parte hartzen duen jendeak arazo gabe jokatu ahal izateko.
  • Azpiegitura handi batek dakarren gastua minimizatzen dugu, makina gehienak soilik bi ordu inguruko tarte batez bakarrik daudelako martxan.
  • Prozesuak huts egitekotan, jakinarazpena jasotzean programa hasi aurretik erreakzionatzeko denbora daukagu.
  • Gure hornitzailearen API-aren ezagutzak ateak zabaldu dizkigu teknika hauek beste proiektu batzuetan aplikatzeko.

Agian interesatuko zaizkizu beste artikulu hauek