Hilabeteak eman dituzu zure monolitoa mikrozerbitzuetan berreraikitzen, eta azkenean denak prest daude etengailua pizteko. Zure lehen web orria bisitatzen duzu... eta ez da ezer gertatzen. Berriro kargatzen duzu, eta berriro ere, ez da ezer gertatzen; gunea hain da motela, ezen minutu batzuetan ez baitu erantzuten. Zer gertatu da?
Bere hitzaldian, Jimmy Bogardek benetako mikrozerbitzu hondamendi baten autopsia egingo du. Aurkitu zituen modelizazio, garapen eta ekoizpen arazoak azpimarratuko ditu, eta azalduko du nola bere taldeak poliki-poliki monolito banatu berri bat ikuspegi osasuntsu batean eraldatu zuen. Diseinu akatsak erabat saihestea ezinezkoa den arren, gutxienez posible da arazoak diseinu prozesuaren hasieran identifikatzea, azken produktua sistema banatu fidagarri bihurtzen dela ziurtatzeko.
Kaixo guztioi, ni Jimmy naiz, eta gaur mikrozerbitzuak eraikitzean mega-hondamendiak nola saihestu entzungo duzue. Hau da urtebete eta erdiz lan egin nuen enpresa baten istorioa, haien itsasontzia izotz mendi baten kontra talka ez egiteko. Istorio hau behar bezala kontatzeko, denboran atzera egin beharko dut eta enpresa hau nola hasi zen eta bere IT azpiegitura nola hazi zen denboran zehar hitz egin. Hondamendi honetan errugabeak direnen izenak babesteko, enpresa honen izena Bell Computers izatera aldatu dut. Hurrengo diapositibak enpresa horien IT azpiegiturak nolakoak ziren erakusten du 90eko hamarkadaren erdialdean. Hau ordenagailu-denda baterako HP Tandem Mainframe zerbitzari handi, orokorreko eta hutsegite-tolerante baten arkitektura tipikoa da.
Eskaera, salmenta, itzulketa, produktuen katalogo eta bezero-base guztiak kudeatzeko sistema bat eraiki behar zuten, beraz, garai hartako mainframe irtenbiderik ohikoena aukeratu zuten. Sistema erraldoi honek imajina zitekeen enpresaren informazio zati guztiak zituen, eta transakzio guztiak mainframe honen bidez prozesatzen ziren. Arrautza guztiak saski berean jarri eta ondo zegoela pentsatu zuten. Sartu ez ziren gauza bakarra posta bidezko katalogoak eta telefono bidezko eskaerak izan ziren.
Denborarekin, sistema gero eta handiagoa bihurtu zen, zabor kopuru izugarria metatuz. Gainera, COBOL ez da munduko hizkuntzarik adierazkorrena, beraz, sistema azkenean zabor multzo erraldoi eta monolitiko batean endekatu zen. 2000. urterako, konturatu ziren enpresa askok beren negozio osoa egiteko erabiltzen zituzten webguneak zituztela, eta beren lehen dot-com webgune komertziala eraikitzea erabaki zuten.
Hasierako diseinua nahiko erakargarria zirudien eta goi-mailako webgune bat, bell.com, eta banakako aplikazioetarako azpidomeinu batzuk zituen: catalog.bell.com, accounts.bell.com, orders.bell.com eta product search.bell.com. Azpidomeinu bakoitzak ASP.Net 1.0 framework-a eta bere datu-baseak erabiltzen zituen, guztiak sistemaren backend-arekin komunikatuz. Hala ere, eskaera guztiak mainframe erraldoi bakar batean prozesatzen eta betetzen jarraitu zuten, non zabor guztia geratzen zen, frontend-a aplikazio eta datu-base bereiziekin webgune bereiziez osatuta zegoen bitartean.
Beraz, sistemaren diseinua ordenatua eta logikoa zirudien, baina benetako sistema hurrengo diapositiban erakusten den bezalakoa zen.
Elementu guztiek elkarri deiak egiten zizkioten, APIetara sartzen ziren, hirugarrenen DLLak txertatzen zituzten, eta abar. Askotan gertatzen zen bertsio-kontrol sistemek beste pertsonen kodea hartzen zutela, proiektuan sartzen zutela, eta gero dena hondatzen zela. MS SQL Server 2005ek esteka-zerbitzarien kontzeptua erabiltzen zuen, eta diapositiban geziekin erakutsi ez nuen arren, datu-base bakoitzak elkarren artean komunikatzen zuen, ez baitago ezer txarrik datu-base anitzetatik berreskuratutako datuetan oinarritutako taulak eraikitzean.
Sistemaren eremu logiko desberdinen artean bereizketa batzuk zituztenez, lokatz-puska sakabanatuak bihurtu ziren, zabor zatirik handiena mainframe-aren atzeko aldean geratzen zelarik.
Gauzarik barregarriena zen ordenagailu nagusi hau Bell Computersen lehiakideek eraiki zutela eta oraindik haien aholkulari teknikoek konpontzen zutela. Aplikazioek gaizki funtzionatzen zutela konturatu ondoren, enpresak kentzea eta sistema berriro diseinatzea erabaki zuen.
Aplikazioa 15 urtez egon zen ekoizpenean, ASP.Net-en oinarritutako aplikazioetarako errekorra. Zerbitzuak mundu osoko eskaerak onartzen zituen, eta aplikazio bakar honetatik lortutako urteko diru-sarrerak mila milioi dolarretara iritsi ziren. Diru-sarrera horien zati handi bat bell.com webgunetik zetorren. Ostiral Beltzetan, gunearen bidez egindako eskaeren kopurua hainbat milioira iritsi zen. Hala ere, arkitektura zaharrak ez zuen inolako garapenik ahalbidetzen, sistemaren elementuen arteko elkarrekiko menpekotasun zurrunek ia ezinezko egiten baitzuten zerbitzuan aldaketak egitea.
Arazo larriena herrialde batetik eskaera bat egin, beste batean ordaindu eta hirugarren batera bidali ezin izatea zen, ohikoa dena enpresa globalen artean. Dauden webguneak ez zuen horretarako aukerarik ematen, beraz, eskaera horiek telefonoz onartu eta prozesatu behar izan zituzten. Horrek enpresa gero eta gehiago kontuan hartzera eraman zuen bere arkitektura aldatzea, zehazki mikrozerbitzuetara aldatzea.
Zentzuduntasunez, beste enpresa batzuei begiratu zieten antzeko arazo bat nola konpondu zuten ikusteko. Horrelako irtenbide bat Netflixen zerbitzu arkitektura izan zen, APIen eta kanpoko datu-base baten bidez konektatutako mikrozerbitzuez osatua.
Bell Computers-eko zuzendaritzak arkitektura hori bera eraikitzea erabaki zuen, oinarrizko printzipio batzuei jarraituz. Lehenik eta behin, datuen bikoiztasuna ezabatu zuten, datu-base partekatu baten ikuspegia erabiliz. Ez zen daturik bidaltzen; horren ordez, behar zuen orok iturri zentralizatu batera sartu behar zuen. Ondoren, isolamendua eta autonomia etorri ziren: zerbitzu bakoitza besteengandik independentea zen. Web API bat erabiltzea erabaki zuten denetarako: datuak berreskuratu edo beste sistema batean aldaketak egin nahi bazenuen, dena web API baten bidez egiten zen. Azken ezaugarri nagusia "Bell on Bell" izeneko mainframe berri bat izan zen, lehiakideen hardwarean oinarritutako "Bell" mainframearen aldean.
Beraz, 18 hilabetez, sistema eraiki zuten, oinarrizko printzipio hauek gidatuta, eta aurre-ekoizpen fasera eraman zuten. Asteburuaren ondoren lanera itzulita, garatzaileak bildu eta sistema berria konektatuta zegoen zerbitzari guztiak piztu zituzten. Hemezortzi hilabeteko lana, ehunka garatzaile, Bell hardware modernoa... eta emaitza positiborik ez! Honek jende askori frustrazioa eragin zion, sistema ordenagailu eramangarrietan hainbat aldiz exekutatu baitzuten, eta dena ondo funtzionatzen baitzuen.
Zentzudun jokatu zuten, arazo hau konpontzeko diru guztia xahutuz. Punta-puntako zerbitzari-rack-ak instalatu zituzten etengailuak erabiliz, gigabit zuntz optikoa erabili zuten, RAM kopuru izugarria zuen zerbitzari-hardware indartsuena, dena konektatu zuten, konfiguratu zuten... eta oraindik ezer ez! Orduan, denbora-mugak errudunak izan zitezkeela susmatzen hasi ziren, beraz, web ezarpen guztietan, API ezarpen guztietan sartu ziren, eta denbora-muga konfigurazio guztiak balio maximoetara eguneratu zituzten. Egin zezaketen guztia webguneari zerbait gertatu arte eseri eta itxarotea zen. Itxaron, eta itxaron, eta 9 minutuz itxaron zuten webgunea azkenean kargatu arte.
Ondoren, konturatu ziren egungo egoerak analisi sakona behar zuela, beraz, gonbidatu gintuzten. Lehenengo gauza aurkitu genuena izan zen garapenaren 18 hilabeteetan zehar ez zela benetako "mikro" bakar bat ere sortu; dena gero eta handiagoa bihurtzen ari zen. Ondoren, post mortem bat idazten hasi ginen, "atzera begirako ikuspegia" edo "erru-ekaitza" bezala ere ezagutzen dena, hondamendiaren kausa ulertzeko.
Hainbat pista genituen, horietako bat API deiaren unean trafikoaren saturazio osoa izan zen. Zerbitzu-arkitektura monolitiko bat erabiltzen duzunean, berehala uler dezakezu zer joan den gaizki zehazki, hutsegitea eragin zezakeen guztiaren berri ematen duen pila bakar baterako arrasto bat duzulako. Hainbat zerbitzuk aldi berean API bakar batera sartzen direnean, ez dago arrastoa jarraitzeko modurik WireShark bezalako sareko monitorizazio-tresna gehigarriak erabili gabe, eskaera bakarra aztertu eta bere exekuzioan zehar gertatutakoa zehazteko aukera ematen baitute. Beraz, web orri bakarra hartu eta ia bi aste eman genituen piezak elkartzen, hainbat dei eginez eta bakoitzaren emaitzak aztertuz.
Begira ezazu irudi hau. Kanpoko eskaera bakar batek nola eragiten dion zerbitzu bati barneko hainbat dei egiteko, eta denak itzultzen direla erakusten du. Badirudi barneko dei bakoitzak jauzi gehigarriak egiten dituela eskaera bera zerbitzatzeko, ezin duelako beste inora iritsi beharrezko informazioa lortzeko. Irudi hau dei-jauzi zentzugabea dela dirudi, kanpoko eskaerak zerbitzu gehigarriak deitzen baititu, eta hauek are zerbitzu gehigarri gehiago deitzen dituzte, eta abar, ia infinituki.
Diagrama honetako kolore berdeak zerbitzuek elkarri deitzen dioten erdizirkulu bat erakusten du: A zerbitzuak B zerbitzuari deitzen dio, B zerbitzuak C zerbitzuari deitzen dio, eta honek, ondoren, berriro A zerbitzuari deitzen dio. Emaitza "blokeo banatua" da. Eskaera bakar batek milaka sareko API dei sortzen zituen, eta sistemak ez zuenez inolako akats-tolerantziarik edo begizta-babesik, eskaera huts egingo luke API dei horietako batek ere huts egingo balu.
Kalkulu batzuk egin genituen. API dei bakoitzak gehienez 150 ms-ko SLA eta % 99,9ko funtzionamendu-denbora zuen. Eskaera bakar batek 200 dei desberdin eragiten zituen, eta kasurik onenean, orrialdea 200 x 150 ms = 30 segundotan bistaratuko zen. Jakina, hori ez zen nahikoa. % 99,9ko funtzionamendu-denbora 200ez biderkatzeak % 0ko erabilgarritasuna eman zuen. Arkitektura hau hasieratik porrotera kondenatuta zegoela dirudi.
Garatzaileengana jo eta galdetu genien nola huts egin zuten arazo hau 18 hilabetetan zehar antzemateko. Gertatu zen exekutatzen zuten kodearen SLAk bakarrik kalkulatzen zituztela, baina haien zerbitzuak beste zerbitzu bat deitzen bazuen, ez zuten denbora hori kontuan hartzen beren SLAetan. Prozesu bakar batean exekutatzen zen guztia 150 ms-ko balioari eusten zion, baina beste zerbitzu-prozesu batzuk deitzeak latentzia orokorra asko handitzen zuen. Honetatik ikasitako lehen ikasgaia hau izan zen: "Zure SLAren jabea zara, ala zure jabea da zurea?" Gure kasuan, azken hau izan zen.
Hurrengo konturatu ginen Peter Deutsch eta James Gosling-ek formulatutako konputazio banatuaren falazien kontzeptuaz jabetzen zirela, baina lehenengo zatia alde batera utzi zutela. Bertan esaten da "sarea fidagarria da", "latentzia zero da" eta "banda-zabalera infinitua da" adierazpenak falaziak direla. Falaziak dira, halaber, "sarea segurua da", "topologia ez da inoiz aldatzen", "administratzaile bakarra dago", "datuen transferentziaren kostua zero da" eta "sarea homogeneoa da".
Akats bat egin zuten, beren zerbitzua tokiko makinetan probatu eta ez zutelako inoiz kanpoko zerbitzuetara konektatu. Tokiko garapenarekin eta tokiko cache batekin, ez zuten inoiz sareko jauzirik aurkitu. Garapenaren 18 hilabeteetan zehar, ez zuten behin ere kontuan hartu zer gerta zitekeen kanpoko zerbitzuak kaltetuta egongo balira.
Aurreko irudiko zerbitzu-mugak aztertzen badituzu, ikusiko duzu guztiak oker daudela. Zerbitzu-mugak nola definitu aholkatzen duten iturri ugari daude, eta gehienek gaizki egiten dute, hurrengo diapositibako Microsoft-en adibidea bezala.
Irudi hau MS blogeko "Nola eraiki mikrozerbitzuak" argitalpenetik hartua da. Web aplikazio sinple bat, negozio logika bloke bat eta datu-base bat erakusten ditu. Eskaera zuzenean dator, beraz, ziurrenik zerbitzari bat egongo da weberako, bat negozioarentzat eta bat datu-basearentzat. Trafikoa handitzen baduzu, irudia apur bat aldatuko da.
Hemen, karga-banatzaile batek bi web zerbitzariren arteko trafikoa banatzen duela dirudi, web zerbitzuaren eta negozio-logikaren artean kokatutako cache bat, eta negozio-logikaren eta datu-basearen artean beste cache bat. Hain zuzen ere, Bellek bere aplikaziorako erabili zuen arkitektura da hau: karga-banaketa eta urdin/berde hedapena, 2000ko hamarkadaren erdialdean amaitua. Denbora batez, dena ondo funtzionatu zuen, diseinu hau egitura monolitiko baterako pentsatuta baitzegoen.
Hurrengo irudiak MS-k monolito batetik mikrozerbitzuetara igarotzea nola gomendatzen duen erakusten du, hau da, zerbitzu nagusi bakoitza mikrozerbitzu bereizietan banatzea. Ikuspegi hau ezartzean egin zuen Bellek akatsa.
Zerbitzu guztiak maila ezberdinetan banatu zituzten, bakoitza hainbat zerbitzu indibidualez osatuta. Adibidez, web zerbitzuak edukia errendatzeko eta autentifikatzeko mikrozerbitzuak zituen, negozio logika zerbitzuak eskaeren prozesatzeko eta kontuaren informaziorako mikrozerbitzuak zituen, eta datu-basea datu espezializatuak zituzten mikrozerbitzu multzo batean banatuta zegoen. Weba, negozio logika eta datu-basea egoerarik gabeko zerbitzuak ziren.
Hala ere, irudi hau guztiz okerra zen, ez baitzuen enpresaren IT klusterretik kanpoko negozio unitaterik mapatzen. Eskema honek ez zuen kanpoko munduarekiko konexiorik kontuan hartzen, beraz, ez zegoen argi nola lortu, adibidez, hirugarrenen negozio analisiak. Kontuan izan behar dut, halaber, diru gehiago irabazteko ahalik eta jende gehien kudeatu nahi zuten langile indibidualen karrerak garatzeko diseinatutako hainbat zerbitzu ere bazituzten.
Mikrozerbitzuetara migratzeko, nahikoa zela uste zuten barneko N mailako azpiegitura fisikoa hartu eta Docker bertan txertatzea. Ikus dezagun nolakoa den N mailako arkitektura tradizional bat.
Lau geruza ditu: UI geruza, negozio logikaren geruza, datuetarako sarbide geruza eta datu-basea. Aurrerakoiagoa da DDD (Domain-Driven Design) edo software-orientatutako arkitektura, non erdiko bi geruzek domeinu objektuak eta biltegi bat adierazten dituzten.
Arkitektura honetako aldaketa-eremu eta erantzukizun desberdinak kontuan hartzen saiatu nintzen. N mailako aplikazio tipiko batean, aldaketa-eremu desberdinak sailkatuta daude eta egitura bertikalki zeharkatzen dute goitik behera. Horien artean daude Katalogoa, ordenagailu bakoitzean egindako Konfigurazio-ezarpenak eta nire taldeak kudeatu dituen Checkout egiaztapenak.
Eskema honen berezitasuna da aldaketa-eremu hauen mugek ez dutela negozio-logika mailan bakarrik eragiten, baizik eta datu-basera ere hedatzen direla.
Ikus dezagun zer esan nahi duen zerbitzu izateak. Sei propietate hauek definitzen dituzte zerbitzu bat: softwarea:
- erakunde espezifiko batek sortu eta erabilia;
- sistemaren barruan informazio mota jakin baten edukiaren, prozesamenduaren eta/edo horniduraren arduraduna da;
- eragiketa-helburu zehatzak betetzeko modu independentean sortu, zabaldu eta exekutatu daiteke;
- kontsumitzaileekin eta beste zerbitzu batzuekin komunikatzen da, akordioetan edo kontratu-bermeetan oinarritutako informazioa emanez;
- bere burua baimenik gabeko sarbideetatik eta bere informazioa galeratik babesten du;
- akatsak informazioari kalterik eragin ez diezaioten moduan kudeatzen ditu.
Ezaugarri horiek guztiak hitz bakar batean laburbil daitezke: "autonomia". Zerbitzuek elkarrengandik independenteki funtzionatzen dute, zenbait muga betetzen dituzte eta pertsonek behar duten informazioa lor dezaketen kontratuak definitzen dituzte. Ez ditut teknologia zehatzak aipatu, eta horien erabilera berez agerikoa da.
Orain, ikus dezagun mikrozerbitzuen definizioa:
- mikrozerbitzu bat tamaina txikikoa da eta arazo zehatz bat konpontzeko diseinatuta dago;
- mikrozerbitzua autonomoa da;
- Mikrozerbitzuen arkitektura bat sortzerakoan, "hirigintza" metafora erabiltzen da. Definizio hau Sam Newmanen "Building Microservices" liburutik dator.
Testuinguru Mugatuaren definizioa Eric Evansen "Domain-Driven Design" liburutik dator. Domain-Driven Design-en oinarrizko eredua da, arkitektura-diseinuaren ikuspegi zentral bat, arkitektura-eredu handiekin lan egiten duena, testuinguru mugatu desberdinetan banatuz eta haien arteko elkarrekintzak esplizituki definituz.
Laburbilduz, Testuinguru Mugatu batek modulu espezifiko bat aplika daitekeen esparrua definitzen du. Testuinguru honen barruan eredu logikoki bateratu bat dago, zure negozio-eremuan aurki daitekeena, adibidez. Eskaerak prozesatzen dituzten langileei "zer da bezero bat?" galdetzen badiezu, definizio bat jasoko duzu, salmenta-taldeari galdetzen badiozu, beste bat jasoko duzu, eta gero salmenta-taldeak hirugarren definizio bat emango dizu.
Beraz, Bounded Context-ek iradokitzen du gure zerbitzuen kontsumitzaile bat zer den argi definitzen ez badugu, termino honen esanahia eztabaidatzeko mugak defini ditzagun, eta gero definizio hauen arteko trantsizio puntuak identifikatu ditzagun. Hau da, eskaeren prozesamenduari dagokionez bezero bati buruz ari bagara, hau eta hura esan nahi du, eta salmenten aldetik bezero bati buruz ari bagara, hau eta hura esan nahi du.
Mikrozerbitzu baten hurrengo definizioa edozein motatako barne-eragiketen kapsulazioa da, lan-fluxuaren osagaiak ingurunera "ihes egitea" eragotziz. Ondoren, "kanpoko interakzioetarako edo kanpoko komunikazioetarako kontratu esplizituen definizioa" dator, SLAetatik itzultzen diren kontratuen ideiarekin irudikatuta dagoena. Azken definizioa zelula baten metafora da, mikrozerbitzu baten barruko eragiketa multzo baten kapsulazio osoa eta kanpoko munduarekin komunikatzeko hartzaileak bertan egotea adierazten duena.
Beraz, Bell Computers-ekoei esan genien: "Ezin dugu sortu duzuen kaosa konpondu, dirurik ez duzuelako, baina zerbitzu bakarra konponduko dugu dena merezi izan dezan". Hemen hasiko naiz zerbitzu hori nola konpondu dugun kontatzen, eskaerei 9 minutu baino gutxiagoan erantzun ahal izateko.
22:30 min
Oso laster jarraitzeko...
Publizitate apur bat
Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, , sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).
Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz
Iturria: www.habr.com
