Vasarą tradiciškai mažėja tiek pirkimo aktyvumas, tiek interneto projektų infrastruktūros pokyčių intensyvumas, – pasakoja kapitonas Obviousas. Vien dėl to, kad net IT specialistai kartais išvažiuoja atostogų. Ir CTO taip pat. Tiems, kurie lieka eiti pareigas, dar sunkiau, bet dabar ne apie tai: galbūt todėl vasara yra pats tinkamiausias laikas pamažu pagalvoti apie esamą rezervavimo schemą ir parengti jos tobulinimo planą. Ir Jegoro Andrejevo patirtis iš , apie kurią jis kalbėjo konferencijoje .
Yra keletas spąstų, į kuriuos galite patekti kurdami atsargines svetaines. Ir visiškai neįmanoma juose pagauti. O mus visame tame, kaip ir daugelyje kitų dalykų, žlugdo perfekcionizmas ir... tinginystė. Stengiamės viską, viską, viską padaryti tobulai, bet nereikia to daryti tobulai! Reikia atlikti tik tam tikrus dalykus, bet daryti juos teisingai, užbaigti, kad jie tinkamai veiktų.
Failover nėra koks nors linksmas, linksmas dalykas; tai dalykas, kuris turėtų daryti lygiai vieną dalyką – sumažinti prastovų laiką, kad tarnyba, įmonė mažiau prarastų pinigų. Ir visais rezervavimo būdais siūlau pagalvoti tokiame kontekste: kur pinigai?
Pirmieji spąstai: kai kuriame dideles, patikimas sistemas ir užsiimame pertekliumi, sumažiname nelaimingų atsitikimų skaičių. Tai siaubingas klaidingas supratimas. Kai užsiimame atleidimu, tikėtina, kad padidės nelaimingų atsitikimų skaičius. Ir jei viską padarysime teisingai, kartu sumažinsime prastovų laiką. Avarijų bus daugiau, tačiau jos įvyks mažesnėmis sąnaudomis. Kas yra rezervacija? – tai sistemos komplikacija. Bet kokia komplikacija yra blogai: turime daugiau krumpliaračių, daugiau pavarų, žodžiu, daugiau elementų – taigi ir didesnė gedimo tikimybė. Ir jie tikrai sulaužys. Ir jie lūžtų dažniau. Paprastas pavyzdys: tarkime, kad turime svetainę su PHP ir MySQL. Ir jį skubiai reikia rezervuoti.
Shtosh (c) Paimame antrą vietą, sukuriame identišką sistemą... Sudėtingumas tampa dvigubai didesnis – turime du subjektus. Taip pat įdiegiame tam tikrą duomenų perdavimo iš vienos svetainės į kitą logiką – tai yra duomenų replikavimas, statinių duomenų kopijavimas ir pan. Taigi, replikacijos logika paprastai yra labai sudėtinga, todėl bendras sistemos sudėtingumas gali būti ne 2, o 3, 5, 10 kartų didesnis.
Antra spąstai: kai kuriame tikrai dideles sudėtingas sistemas, fantazuojame apie tai, ką galiausiai norime gauti. Voila: norime gauti itin patikimą sistemą, kuri veiktų be prastovų, persijungtų per pusę sekundės (ar dar geriau – akimirksniu), ir mes pradedame pildyti svajones. Tačiau čia taip pat yra niuansas: kuo trumpesnis norimas perjungimo laikas, tuo sudėtingesnė tampa sistemos logika. Kuo sudėtingesnė ši logika, tuo dažniau sistema suges. Ir gali atsidurti labai nemalonioje situacijoje: iš visų jėgų stengiamės sumažinti prastovą, bet iš tikrųjų viską dar labiau apsunkiname, o kai kas nors nepavyks, prastovos pailgės. Čia dažnai pagauni save galvojant: na... verčiau rezervacijos nedaryti. Būtų geriau, jei jis veiktų vienas ir su suprantama prastovomis.
Kaip tu gali su tuo kovoti? Reikia nustoti sau meluoti, nustoti glostyti, kad dabar čia statysime erdvėlaivį, bet adekvačiai suprasti, kiek ilgai gali meluoti projektas. Ir šiam maksimaliam laikui mes pasirinksime, kokius metodus iš tikrųjų naudosime, kad padidintume savo sistemos patikimumą.
Atėjo laikas „istorijai iš w“... iš gyvenimo, žinoma.
Pavyzdys numeris vienas
Įsivaizduokite N mieste esančios Vamzdžių valcavimo gamyklos Nr. 1 vizitinių kortelių svetainę. Didžiulėmis raidėmis parašyta – VAMZDŽIŲ VALČIAVIMO ĮRENGINYS Nr. 1. Žemiau yra šūkis: „Mūsų vamzdžiai yra apvaliausi vamzdžiai N“. O žemiau – generalinio direktoriaus telefono numeris ir pavardė. Suprantame, kad jums reikia rezervuoti – tai labai svarbus dalykas! Pradėkime išsiaiškinti, iš ko jis susideda. Html-statistika - tai yra pora nuotraukų, kur generalinis direktorius iš tikrųjų aptarinėja kažkokį kitą sandorį prie stalo pirtyje su savo partneriu. Pradedame galvoti apie prastovą. Ateina į galvą: reikia pagulėti penkias minutes, ne daugiau. Ir tada kyla klausimas: kiek apskritai buvo pardavimų iš šios mūsų svetainės? Kiek-kiek? Ką reiškia "nulis"? O tai reiškia: nes generolas pernai visus keturis sandorius sudarė prie vieno stalo, su tais pačiais žmonėmis, su kuriais eina į pirtį ir sėda prie stalo. Ir mes suprantame, kad net jei svetainė stovės dieną, nieko baisaus nenutiks.
Remiantis įžangine informacija, yra diena iškelti šią istoriją. Pradėkime galvoti apie atleidimo schemą. Ir šiam pavyzdžiui pasirenkame idealiausią atleidimo schemą: atleidimo nenaudojame. Visą šitą reikalą bet kuris adminas gali iškelti per pusvalandį su dūmų pertraukėlėmis. Įdiekite žiniatinklio serverį, pridėkite failus – viskas. Tai veiks. Nereikia nieko stebėti, nereikia į nieką kreipti ypatingo dėmesio. Tai yra, išvada iš pavyzdžio numeris vienas yra gana akivaizdi: paslaugų, kurių nereikia rezervuoti, rezervuoti nereikia.
Antras pavyzdys
Įmonės tinklaraštis: ten naujienas rašo specialiai apmokyti žmonės, dalyvavome tokioje ir tokioje parodoje, bet išleidome dar vieną naują produktą ir t.t. Tarkime, tai yra standartinis PHP su WordPress, maža duomenų baze ir šiek tiek statinio. Žinoma, vėl ateina į galvą, kad jokiu būdu neturėtumėte gulėti - „ne ilgiau kaip penkias minutes! Bet pagalvokime toliau. Ką veikia šis tinklaraštis? Žmonės ten ateina iš „Yandex“, iš „Google“ pagal kai kurias užklausas, natūraliai. Puiku. Ar pardavimai turi ką nors bendro su tuo? Epiphany: tikrai ne. Reklamos srautas nukreipiamas į pagrindinę svetainę, kuri yra kitame kompiuteryje. Pradėkime galvoti apie užsakymo schemą. Gerąja prasme, jį reikia pakelti per porą valandų, ir būtų malonu tam pasiruošti. Būtų protinga paimti mašiną iš kito duomenų centro, į ją įkelti aplinką, tai yra žiniatinklio serverį, PHP, WordPress, MySQL ir palikti ten. Tuo momentu, kai suprantame, kad viskas sugedo, reikia padaryti du dalykus - išriedėti mysql dump 50 metrų, jis ten nuskris po minutės ir iš ten išvynioti tam tikrą skaičių nuotraukų iš atsarginės kopijos. Tai taip pat nėra, nes Dievas žino kiek laiko. Taigi per pusvalandį viskas pakyla. Jokio replikacijos arba, Dieve, atleisk man, automatinis perjungimas. Išvada: tai, ką galime greitai įdiegti iš atsarginės kopijos, atsarginės kopijos kurti nereikia.
Trečias pavyzdys, sudėtingesnis
Internetinė parduotuvė. PhP su atvira širdimi yra šiek tiek pakoreguotas, mysql su tvirtu pagrindu. Ganėtinai daug statikos (juk internetinėje parduotuvėje yra gražūs HD vaizdai ir visa kita), seansui skirtas Redis ir paieškai Elasticsearch. Pradedame galvoti apie prastovą. Ir čia, žinoma, akivaizdu, kad internetinė parduotuvė negali be skausmo išgulėti nė dienos. Juk kuo ilgiau guli, tuo daugiau pinigų prarandame. Verta paspartinti. Kiek? Manau, jei pagulėsime valandėlę, niekas neišprotės. Taip, kažką prarasime, bet jei pradėsime sunkiai dirbti, bus tik blogiau. Mes nustatome leistinų prastovų per valandą schemą.
Kaip visa tai galima rezervuoti? Automobilio reikia bet kuriuo atveju: valanda laiko yra gana mažai. Mysql: čia jau reikia replikacijos, gyvos replikacijos, nes per valandą 100 GB greičiausiai nebus pridėta į dumpą. Statika, nuotraukos: vėlgi, per valandą 500 GB gali nespėti pridėti. Todėl geriau nuotraukas nukopijuoti iš karto. Redis: štai kur viskas įdomu. „Redis“ seansai saugomi – negalime tiesiog paimti ir palaidoti. Nes tai nebus labai gerai: visi vartotojai bus atjungti, jų krepšeliai bus ištuštinti ir pan. Žmonės bus priversti iš naujo įvesti savo vartotojo vardą ir slaptažodį, o daugelis žmonių gali atsiskirti ir neužbaigti pirkimo. Vėlgi, konversijų skaičius sumažės. Kita vertus, Redis yra tiesiogiai atnaujintas, o paskutiniai prisijungę vartotojai tikriausiai taip pat nereikalingi. Ir geras kompromisas yra paimti Redis ir atkurti jį iš vakarykštės atsarginės kopijos arba, jei tai darote kas valandą, prieš valandą. Laimei, atkurti jį iš atsarginės kopijos reiškia nukopijuoti vieną failą. O įdomiausia istorija – Elasticsearch. Kas kada nors pasirinko MySQL replikaciją? Kas kada nors pasirinko Elasticsearch replikaciją? O kam po to normaliai veikė? Turiu omenyje tai, kad savo sistemoje matome tam tikrą subjektą. Atrodo, kad tai naudinga, bet sudėtinga.
Sudėtinga ta prasme, kad mūsų kolegos inžinieriai neturi darbo su juo patirties. Arba yra neigiama patirtis. Arba suprantame, kad tai vis dar gana nauja technologija, turinti niuansų ar neapdorotų. Galvojam... Velnias, elastingumas irgi sveika, atstatyti irgi iš atsarginės kopijos užtrunka ilgai, ką daryti? Suprantame, kad elastinė mūsų atveju naudojama paieškai. Kaip parduoda mūsų internetinė parduotuvė? Einame pas rinkodaros specialistus ir klausiame, iš kur žmonės ateina. Jie atsako: „90% „Yandex Market“ patenka tiesiai į produkto kortelę. Ir arba perka, arba ne. Todėl ieškoti reikia 10% vartotojų. O elastingos replikacijos išlaikymas, ypač tarp skirtingų duomenų centrų skirtingose zonose, tikrai turi daug niuansų. Kuris išėjimas? Paimame tamprę iš rezervuotos vietos ir nieko su ja nedarome. Jei byla užsitęs, galbūt kada nors ją iškelsime, bet tai nėra tikra. Tiesą sakant, išvada ta pati, pliusas ar minusas: mes vėlgi nerezervuojame paslaugų, kurios neturi įtakos pinigams. Kad diagrama būtų paprastesnė.
Ketvirtas pavyzdys, dar sunkesnis
Integratorius: parduoda gėles, išsikviečia taksi, parduoda prekes, apskritai, bet ką. Rimtas dalykas, kuris veikia 24/7 daugeliui vartotojų. Su visaverčiu įdomiu kaminu, kur yra įdomūs pagrindai, sprendimai, didelis krūvis, o svarbiausia – gulint ilgiau nei 5 minutes skauda. Ne tik ir ne tiek dėl to, kad žmonės nepirks, bet dėl to, kad žmonės pamatys, kad šis dalykas neveikia, jie susinervins ir gali išvis nebegrįžti.
GERAI. Penkios minutės. Ką darysime šiuo klausimu? Šiuo atveju mes, kaip ir suaugusieji, visus pinigus naudojame tam, kad sukurtume tikrą atsarginę svetainę su visko replikavimu, o galbūt net kiek įmanoma automatizuotume perėjimą į šią svetainę. Be to, turite nepamiršti atlikti vieno svarbaus dalyko: iš tikrųjų parašyti perjungimo taisykles. Taisyklės, net jei viskas automatizuota, gali būti labai paprastos. Iš serijų „paleisti tokį ir tokį įmanomą scenarijų“, „paspausti tokį ir tokį žymimąjį laukelį 53 maršrute“ ir t. t. – bet tai turi būti kažkoks tikslus veiksmų sąrašas.
Ir viskas atrodo aišku. Replikacijos perjungimas yra nereikšminga užduotis arba ji persijungs pati. Domeno vardo perrašymas DNS yra iš tos pačios serijos. Bėda ta, kad žlugus tokiam projektui, prasideda panika ir net stipriausi barzdoti adminai gali būti tam jautrūs. Be aiškių nurodymų „atidaryk terminalą, ateik čia, mūsų serverio adresas vis dar toks“, sunku laikytis 5 minučių gaivinimo termino. Na, be to, kai mes naudojame šiuos reglamentus, nesunku užfiksuoti, pavyzdžiui, kai kuriuos infrastruktūros pokyčius ir atitinkamai pakeisti reglamentus.
Na, o jei rezervavimo sistema yra labai sudėtinga ir kažkuriuo metu suklydome, galime sunaikinti savo atsarginę svetainę ir papildomai paversti duomenis abiejose svetainėse - bus visiškai liūdna.
Penktas pavyzdys, visiškas hardcore
Tarptautinė paslauga, turinti šimtus milijonų vartotojų visame pasaulyje. Yra visos laiko juostos, didelis apkrovimas maksimaliu greičiu, gulėti visai negalima. Minutė – ir bus liūdna. Ką daryti? Rezervuoti, vėlgi, pagal visą programą. Mes padarėme viską, apie ką kalbėjau ankstesniame pavyzdyje, ir šiek tiek daugiau. Idealus pasaulis, o mūsų infrastruktūra atitinka visas IaaC devops sąvokas. Tai yra, viskas yra git, ir jūs tiesiog paspauskite mygtuką.
Ko trūksta? Vienas – pratimai. Be jų neįmanoma. Atrodo, kad pas mus viskas puiku, mes paprastai viską kontroliuojame. Paspaudžiame mygtuką, visko būna. Net jei taip yra – ir mes suprantame, kad taip nenutinka – mūsų sistema sąveikauja su kai kuriomis kitomis sistemomis. Pavyzdžiui, tai yra dns iš 53 maršruto, s3 saugykla, integracija su kai kuriais API. Šiame spekuliaciniame eksperimente mes negalėsime visko numatyti. Ir kol iš tikrųjų nepatrauksime jungiklio, nežinosime, ar jis veiks, ar ne.
Tai turbūt ir viskas. Nebūk tingus ir nepersistenk. Ir gali būti su jumis!
Šaltinis: www.habr.com