Udan, bai erosketa-jarduera bai web-proiektuen azpiegituren aldaketen intentsitatea gutxitzen da tradizionalki, Captain Obvious-ek esan digunez. Besterik gabe, IT espezialistak ere batzuetan oporretara joaten direlako. Eta CTO ere. Karguan jarraitzen dutenentzat are zailagoa da, baina ez da hori orain kontua: agian horregatik uda da garairik egokiena indarrean dagoen erreserba-eskema poliki-poliki hausnartzeko eta hobetzeko plana egiteko. Eta Yegor Andreev-en esperientzia , hitzaldian hitz egin zuena .
Babeskopia guneak eraikitzean erori ditzakezun hainbat hutsune daude. Eta guztiz ezinezkoa da haietan harrapatzea. Eta guzti honetan hondatzen gaituena, beste gauza askotan bezala, perfekzionismoa eta... alferkeria da. Guztia, dena, dena primeran egiten saiatzen ari gara, baina ez dugu ezin hobeto egin behar! Gauza batzuk bakarrik egin behar dituzu, baina ondo egin, osatu behar bezala funtziona dezaten.
Failover ez da gauza dibertigarri eta dibertigarri bat; Hau gauza bakarra egin beharko lukeena da: geldialdi-denbora murriztea, zerbitzuak, enpresak, diru gutxiago gal dezan. Eta erreserba modu guztietan, hurrengo testuinguruan pentsatzea proposatzen dut: non dago dirua?
Lehenengo tranpa: sistema handiak eta fidagarriak eraikitzen ditugunean eta erredundantzian jarduten dugunean, istripu kopurua murrizten dugu. Hau uste oker izugarria da. Erredundantzian aritzen garenean, litekeena da istripu kopurua handitzea. Eta dena ondo egiten badugu, kolektiboki etenaldiak murriztuko ditugu. Istripu gehiago izango dira, baina kostu txikiagoan gertatuko dira. Zer da erreserba bat? - Hau sistemaren konplikazio bat da. Edozein konplikazio txarra da: engranaje gehiago, engranaje gehiago, hitz batean, elementu gehiago ditugu, eta, beraz, matxuratzeko aukera handiagoa dugu. Eta benetan hautsi egingo dira. Eta maizago hautsiko dira. Adibide sinple bat: demagun PHP eta MySQL dituen webgune bat dugula. Eta premiazkoa da erreserbatzea.
Shtosh (c) Bigarren gunea hartzen dugu, sistema berdina eraikitzen dugu... Konplexutasuna bi aldiz handiagoa da - bi entitate ditugu. Datuak gune batetik bestera transferitzeko logika jakin bat ere zabaltzen dugu, hau da, datuen erreplikazioa, datu estatikoak kopiatzea, etab. Beraz, erreplikazio-logika oso konplexua izan ohi da, eta, beraz, sistemaren konplexutasun osoa ez daiteke 2, 3, 5, 10 aldiz handiagoa izan.
Bigarren tranpa: sistema konplexu benetan handiak eraikitzen ditugunean, azkenean lortu nahi dugunarekin fantasiatzen dugu. Voila: sistema super fidagarri bat lortu nahi dugu, inongo denborarik gabe funtzionatzen duena, segundo erdian aldatzen duena (edo hobeto esanda, berehala) eta ametsak egia bihurtzen hasten gara. Baina ñabardura bat ere badago hemen: zenbat eta laburragoa izan nahi den aldatzeko denbora, orduan eta konplexuagoa da sistemaren logika. Zenbat eta konplexuagoa izan logika hori egiteko, orduan eta maizago apurtuko da sistema. Eta egoera oso desatseginan gera zaitezke: indar guztiarekin saiatzen ari gara geldialdi-denborak murrizten, baina, egia esan, dena zailtzen ari gara, eta zerbait okertzen denean, geldialdi-denbora luzeagoa izango da azkenean. Hemen sarritan harrapatzen zara pentsatzen: ba... hobe litzateke erreserbarik ez egitea. Hobe izango litzateke bakarrik eta ulergarria den geldialdiarekin funtzionatuko balu.
Nola borrokatu dezakezu honi? Gure buruari gezurra esateari utzi behar diogu, utzi behar diogu geure buruari orain espazio-ontzi bat eraikiko dugula lausenkatzeari, baina behar bezala ulertu proiektuak zenbat denbora iraun dezakeen. Eta gehienezko denbora honetarako, gure sistemaren fidagarritasuna areagotzeko zein metodo erabiliko ditugun aukeratuko dugu.
“W-tik ipuinen” garaia da... bizitzatik, noski.
Zenbaki bat adibidea
Imajinatu N. hiriko Pipe Rolling Plant No. 1-ren bisita-txartelen webgune bat. Letra handiz esaten du - PIPE ROLLING PLANT No. 1. Behean leloa dago: "Gure hodiak N-ko hodi biribilenak dira". Eta azpian CEOaren telefono zenbakia eta bere izena daude. Ulertzen dugu erreserba egin behar duzula - hau oso gauza garrantzitsua da! Has gaitezen asmatzen zertan datzan. Html-estatikoak - hau da, argazki pare bat non zuzendari nagusia, hain zuzen ere, bere bikotearekin bainuetxean mahaian hurrengo akordio motaren bat eztabaidatzen ari den. Geldialdietan pentsatzen hasten gara. Etortzen zait burura: bost minutuz etzanda egon behar duzu, ez gehiago. Eta orduan galdera sortzen da: zenbat salmenta izan ziren orokorrean gure gune honetatik? Zenbat-zenbat? Zer esan nahi du "zero"? Eta horrek esan nahi du: jeneralak lau transakzioak egin zituelako iaz mahai berean, bainutxera joan eta mahaian esertzen diren pertsona berdinekin. Eta ulertzen dugu gunea egun batez esertzen bada ere, ez dela ezer ikaragarririk gertatuko.
Sarrerako informazioan oinarrituta, istorio hau planteatzeko eguna dago. Has gaitezen erredundantzia-eskema bat pentsatzen. Eta adibide honetarako erredundantzia-eskema egokiena aukeratzen dugu: ez dugu erredundantziarik erabiltzen. Guzti hau edozein administratzailek planteatu dezake ordu erdian ke atsedenaldiekin. Instalatu web zerbitzari bat, gehitu fitxategiak - hori da. Lan egingo du. Ez duzu ezertan begiratu beharrik, ez diozu arreta berezirik jarri behar ezeri. Hau da, lehen adibideko ondorioa nahiko agerikoa da: erreserbatu behar ez diren zerbitzuak ez dira erreserbatu behar.
Bigarren zenbakiaren adibidea
Konpainiaren bloga: bereziki prestatuta dagoen jendeak albisteak idazten ditu bertan, halako erakusketa batean parte hartu dugu, baina beste produktu berri bat kaleratu dugu, eta abar. Demagun PHP estandarra dela WordPress-ekin, datu-base txiki bat eta apur bat estatiko. Jakina, berriro datorkit burura ez duzula inolaz ere etzan behar - "ez bost minutu baino gehiago!" Hori da guztia. Baina pentsa dezagun gehiago. Zer egiten du blog honek? Jendea Yandexetik etortzen da, Google-tik kontsulta batzuetan oinarrituta, modu organikoan. Bikaina. Salmentek ba al dute zerikusirik? Epifania: ez benetan. Publizitate trafikoa gune nagusira doa, hau da, beste makina batean dago. Has gaitezen erreserba-eskema bat pentsatzen. Modu onean, ordu pare batean altxatu behar da, eta ondo legoke horretarako prestatzea. Arrazoizkoa izango litzateke beste datu-zentro batetik makina bat hartu, ingurunea bertara botatzea, hau da, web zerbitzari bat, PHP, WordPress, MySQL, eta bertan uztea. Dena apurtuta dagoela ulertzen dugunean, bi gauza egin behar ditugu: mysql zabortegia 50 metrora zabaldu, minutu batean hara hegan egingo du eta babeskopiatik argazki kopuru jakin bat atera. Hau ere ez dago Jainkoak daki zenbat denborarako. Horrela, ordu erdian dena altxatzen da. Erreplikaziorik ez, edo Jainkoak barka nazazu, hutsegite automatikoa. Ondorioa: segurtasun kopia batetik azkar atera dezakeguna ez da babeskopia egin beharrik.
Hirugarren adibidea, konplikatuagoa
Online denda. Bihotz irekiko PhP apur bat moldatu da, mysql oinarri sendoa duena. Nahiko estatiko (azken finean, lineako dendak HD irudi ederrak eta gauza hori guztia), Redis saioarako eta Elasticsearch bilaketarako. Geldialdietan pentsatzen hasten gara. Eta hemen, noski, bistakoa da lineako denda batek ezin duela egun batez minik gabe egon. Azken finean, zenbat eta luzeago egon, orduan eta diru gehiago galtzen dugu. Merezi du bizkortzea. Zenbat? Uste dut ordubetez etzanda, inor ez dela erotuko. Bai, zerbait galduko dugu, baina lanean gogor hasten bagara, okerrera egingo du. Orduko baimendutako geldialdi eskema bat definitzen dugu.
Nola gorde daiteke hori guztia? Edonola ere auto bat behar duzu: ordubete nahiko gutxi da. Mysql: hemen jada behar dugu erreplikazioa, zuzeneko erreplikazioa, ordu batean 100 GB ziurrenik ez direlako zabortegira gehituko. Estatika, irudiak: berriro ere, ordu batean 500 GB agian ez du denbora gehitzeko. Hori dela eta, hobe da argazkiak berehala kopiatzea. Redis: hemen gauzak interesgarriak dira. Redis-en, saioak gordetzen dira; ezin dugu hartu eta lurperatu. Hau ez baita oso ona izango: erabiltzaile guztiak amaituko dira saioa, haien saskiak hustuko dira, etab. Jendea erabiltzaile-izena eta pasahitza berriro sartzera behartuta egongo da, eta jende askok hautsi eta erosketa ez amaitu dezake. Berriz ere, bihurketak jaitsi egingo dira. Bestalde, Redis zuzenean eguneratuta dago, saioa hasitako azken erabiltzaileak ere beharko ez direla ziurrenik. Eta konpromiso ona da Redis hartu eta atzoko babeskopi batetik berrezartzea edo, orduro egiten baduzu, duela ordubetetik aurrera. Zorionez, babeskopia batetik berrezartzeak fitxategi bat kopiatzea esan nahi du. Eta istoriorik interesgarriena Elasticsearch da. Nork hartu du inoiz MySQL erreplikazioa? Nork hartu du inoiz Elasticsearch erreplikazioa? Eta norentzat funtzionatu zuen normalean ondoren? Esan nahi dudana da gure sisteman entitate jakin bat ikusten dugula. Baliagarria dela dirudi, baina konplexua da.
Konplexua, gure ingeniariek lan egiten duten esperientziarik ez duten zentzuan. Edo esperientzia negatibo bat dago. Edo ulertzen dugu oraindik teknologia nahiko berria dela ñabardurak edo gordintasuna. Uste dugu... Arraioa, elastikoa ere osasuntsua da, backup batetik berreskuratzeko ere denbora asko behar da, zer egin behar dut? Gure kasuan elastikoa bilaketarako erabiltzen dela ulertzen dugu. Nola saltzen da gure online denda? Merkatariengana joaten gara eta jendea nondik datorren galdetzen dugu. Erantzuten dute: "Yandex Market-en % 90 zuzenean produktuen txartelera iristen da". Eta edo erosten dute edo ez dute. Hori dela eta, erabiltzaileen %10ek bilaketa egin behar dute. Eta erreplikazio elastikoa mantentzeak, batez ere zona ezberdinetako datu-zentro ezberdinen artean, ñabardura asko ditu benetan. Zein irteera? Erreserbatutako gune batetik elastikoa hartzen dugu eta horrekin ez dugu ezer egiten. Gaia luzatzen bada, ziurrenik noizbait planteatuko dugu, baina hori ez da ziurra. Egia esan, ondorioa berdina da, gehi edo ken: guk, berriz, ez ditugu diruari eragiten ez dioten zerbitzurik erreserbatzen. Diagrama sinpleagoa izateko.
Laugarren adibidea, are zailagoa
Integratzailea: loreak saltzea, taxi bati deitzea, salgaiak saltzea, oro har, edozer gauza. Erabiltzaile kopuru handiarentzat 24/7 funtzionatzen duen gauza serioa. Pila oso interesgarri batekin, non oinarri interesgarriak, konponbideak, karga handia dauden eta, batez ere, 5 minutu baino gehiago etzantzeak min ematen du. Ez bakarrik eta ez hainbeste jendeak erosiko ez duelako, baizik eta jendeak ikusiko duelako gauza honek ez duela funtzionatzen, haserretu egingo da eta agian ez da batere itzuliko.
ADOS. Bost minutu. Zer egingo dugu honen aurrean? Kasu honetan, helduek bezala, diru guztia erabiltzen dugu benetako babeskopia gune bat eraikitzeko, dena erreplikatuz, eta agian gune honetara aldatzea ahal den neurrian automatizatzen dugu. Eta honetaz gain, gauza garrantzitsu bat egitea gogoratu behar duzu: egia esan, aldatzeko araudia idatzi. Araudia, dena automatizatuta eduki arren, oso sinplea izan daiteke. "Exekutatu halako eta halako script ansible bat", "egin klik halako eta halako kontrol-lauki bat 53 ibilbidean" eta abar, baina ekintzen zerrenda zehatza izan behar du.
Eta dena argia dirudi. Erreplikazioa aldatzea lan hutsala da, edo bera aldatuko da. DNSn domeinu-izen bat berridaztea serie berekoa da. Arazoa da horrelako proiektu batek huts egiten duenean izua hasten dela, eta administratzaile indartsuenak ere jasan ditzaketela. Argibide argirik gabe "ireki terminala, etorri hona, gure zerbitzariaren helbidea horrelakoa da oraindik", zaila da suspertzeko emandako 5 minutuko denbora-muga betetzea. Tira, gainera, araudi hauek erabiltzen ditugunean erraza da azpiegituretan aldaketa batzuk erregistratzea, adibidez, eta horren arabera araudia aldatzea.
Beno, erreserba-sistema oso konplexua bada eta noizbait akats bat egin badugu, orduan gure babeskopia gunea suntsitu dezakegu, eta, gainera, datuak bi guneetako kalabaza bihurtu - hau guztiz tristea izango da.
Bost zenbakiaren adibidea, hardcore osoa
Mundu osoko ehunka milioi erabiltzaile dituen nazioarteko zerbitzua. Hor dauden ordu-eremu guztiak, karga handia abiadura maximoan, ezin zara batere etzan. Minutu bat - eta tristea izango da. Zer egin? Erreserba, berriz, egitarau osoaren arabera. Aurreko adibidean hitz egin dudan guztia egin dugu, eta pixka bat gehiago. Mundu ideal bat, eta gure azpiegitura IaaC devops-en kontzeptu guztien araberakoa da. Hau da, dena git-en dago, eta botoia sakatu besterik ez duzu.
Zer falta da? Bat - ariketak. Ezinezkoa da haiek gabe. Badirudi dena perfektua dela gurekin, oro har dena kontrolpean daukagu. Botoia sakatzen dugu, dena gertatzen da. Hori horrela bada ere -eta ulertzen dugu ez dela horrela gertatzen- gure sistemak beste sistema batzuekin elkarreragiten du. Esate baterako, hau 53 ibilbideko dns da, s3 biltegiratzea, api batzuekin integrazioa. Esperimentu espekulatibo honetan ezin izango dugu dena aurreikusi. Eta etengailuari tira egiten diogun arte, ez dugu jakingo funtzionatuko duen ala ez.
Hori da seguruenik dena. Ez izan alferra edo gehiegi egin. Eta egon dadila zurekin!
Iturria: www.habr.com