Suvel langeb traditsiooniliselt nii ostuaktiivsus kui ka veebiprojektide infrastruktuuri muutuste intensiivsus, ütleb kapten Obvious. Lihtsalt sellepärast, et isegi IT-spetsialistid lähevad vahel puhkusele. Ja CTO ka. Seda keerulisem on ametisse jääjatel, aga see pole praegu asja mõte: võib-olla just seetõttu on suvi parim aeg tasakesi mõelda olemasolevale broneerimisskeemile ja koostada plaan selle täiustamiseks. Ja Jegor Andrejevi kogemus aastast , millest ta konverentsil rääkis .
Varundamissaitide loomisel võite sattuda mitmesse lõksu. Ja nende vahele jääda on täiesti võimatu. Ja mis meid selle kõige juures, nagu ka paljudes muudes asjades, rikub, on perfektsionism ja... laiskus. Püüame teha kõike, kõike, kõike täiuslikult, kuid me ei pea seda ideaalselt tegema! Peate tegema ainult teatud asju, kuid tegema neid õigesti, lõpetama, et need korralikult töötaksid.
Failover ei ole mingi lõbus, lõbus asi; see on asi, mis peaks tegema täpselt üht – vähendama seisakuid, et teenindus, ettevõte, vähem raha kaotaks. Ja kõigi broneerimismeetodite puhul soovitan mõelda järgmises kontekstis: kus on raha?
Esimene lõks: kui ehitame suuri ja töökindlaid süsteeme ja tegeleme koondamisega, vähendame õnnetuste arvu. See on kohutav eksiarvamus. Kui tegeleme koondamisega, suurendame tõenäoliselt õnnetuste arvu. Ja kui teeme kõik õigesti, vähendame ühiselt seisakuid. Õnnetusi juhtub rohkem, kuid need toimuvad väiksemate kuludega. Mis on broneering? - see on süsteemi komplikatsioon. Iga komplikatsioon on halb: meil on rohkem hammasrattaid, rohkem käike, ühesõnaga rohkem elemente – ja seega suurem rikkevõimalus. Ja nad tõesti purunevad. Ja nad lähevad sagedamini katki. Lihtne näide: oletame, et meil on PHP ja MySQL-iga veebisait. Ja see tuleb kiiresti reserveerida.
Shtosh (c) Me võtame teise saidi, ehitame identse süsteemi... Keerulisus muutub kaks korda suuremaks – meil on kaks olemit. Samuti võtame kasutusele teatud loogika andmete ühelt saidilt teisele ülekandmiseks – see tähendab andmete replikatsiooni, staatiliste andmete kopeerimist ja nii edasi. Seega on replikatsiooniloogika tavaliselt väga keeruline ja seetõttu ei saa süsteemi kogukeerukus olla mitte 2, vaid 3, 5, 10 korda suurem.
Teine lõks: kui ehitame tõeliselt suuri keerulisi süsteeme, siis fantaseerime, mida me lõpuks saada tahame. Voila: tahame saada üliusaldusväärse süsteemi, mis töötab ilma seisakuta, lülitub poole sekundiga (või veel parem, koheselt) ja hakkame unistusi täitma. Kuid siin on ka nüanss: mida lühem on soovitud lülitusaeg, seda keerulisemaks muutub süsteemiloogika. Mida keerulisemaks me seda loogikat tegema peame, seda sagedamini süsteem katki läheb. Ja võite sattuda väga ebameeldivasse olukorda: me püüame kõigest väest vähendada seisakuid, kuid tegelikult muudame kõik keerulisemaks ja kui midagi läheb valesti, pikeneb seisak lõpuks. Siin tabad end sageli mõttelt: noh... parem oleks mitte broneerida. Parem oleks, kui see töötaks üksi ja arusaadavate seisakutega.
Kuidas saate selle vastu võidelda? Peame lõpetama endale valetamise, lõpetama enda meelitamise, et me ehitame siia nüüd kosmoselaeva, kuid adekvaatselt mõistma, kui kaua projekt valetada võib. Ja selle maksimaalse aja jooksul valime, milliseid meetodeid me oma süsteemi töökindluse suurendamiseks tegelikult kasutame.
On aeg “lugudeks w”... elust muidugi.
Näide number üks
Kujutage ette N-i linna torurullitehase nr 1 visiitkaartide veebisaiti. Seal on tohutute tähtedega kirjas – TORUVALTSITEHAS nr 1. Allpool on loosung: "Meie torud on N-i ümaraimad torud." Ja allpool on tegevjuhi telefoninumber ja nimi. Mõistame, et peate tegema broneeringu – see on väga oluline asi! Hakkame välja mõtlema, millest see koosneb. Html-staatika - ehk siis paar pilti, kus peadirektor tegelikult oma elukaaslasega saunas laua taga mingit järgmist tehingut arutab. Hakkame mõtlema seisakutele. Tuleb meelde: sa pead seal viis minutit lamama, mitte rohkem. Ja siis tekib küsimus: kui palju müüke sellelt meie saidilt üldiselt oli? Kui palju-kui palju? Mida tähendab "null"? Ja see tähendab: kuna kindral tegi eelmisel aastal kõik neli tehingut ühe laua taga, samade inimestega, kellega koos käiakse vannis ja istutakse lauda. Ja me mõistame, et isegi kui sait seisab päeva, ei juhtu midagi kohutavat.
Sissejuhatava info põhjal on päev selle loo tõstatamiseks. Hakkame mõtlema koondamisskeemile. Ja me valime selle näite jaoks kõige ideaalsema koondamisskeemi: me ei kasuta koondamist. Kogu selle asja võib suitsupausidega poole tunniga tõsta iga adminn. Installige veebiserver, lisage faile - see on kõik. See toimib. Pole vaja millelgi silma peal hoida, millelegi pole vaja erilist tähelepanu pöörata. See tähendab, et järeldus näitest number üks on üsna ilmne: teenuseid, mida ei ole vaja broneerida, ei ole vaja broneerida.
Näide number kaks
Firmablogi: seal kirjutavad uudiseid spetsiaalselt koolitatud inimesed, osalesime sellisel ja sellisel näitusel, aga andsime välja veel ühe uue toote jne. Oletame, et see on standardne PHP, millel on WordPress, väike andmebaas ja natuke staatilisust. Muidugi tuleb jälle meelde, et te ei tohiks mingil juhul pikali heita - "mitte rohkem kui viis minutit!" See on kõik. Aga mõelgem edasi. Mida see blogi teeb? Inimesed tulevad sinna Yandexist, mõne päringu põhjal Google'ist, orgaaniliselt. Suurepärane. Kas müügil on sellega midagi pistmist? Epiphany: tegelikult mitte. Reklaamiliiklus suunatakse põhisaidile, mis asub teisel masinal. Hakkame mõtlema broneerimisskeemi peale. Heas mõttes on vaja paari tunniga tõsta ja selleks oleks tore valmistuda. Mõistlik oleks võtta mõnest teisest andmekeskusest masin, veeretada sinna peale keskkond ehk siis veebiserver, PHP, WordPress, MySQL ja sinna jätta. Sel hetkel, kui saame aru, et kõik on katki, peame tegema kahte asja - rullima mysql-i prügimäe 50 meetrit välja, see lendab minuti pärast sinna ja veeretama seal varukoopiast teatud arvu pilte. Seda pole ka jumal teab kui kauaks. Seega poole tunniga kerkib kogu asi. Ilma replikatsioonita või jumal andke andeks, automaatne tõrkevahetus. Järeldus: seda, mida saame varukoopiast kiiresti välja tuua, ei ole vaja varundada.
Näide number kolm, keerulisem
Online pood. Avatud südamega PhP on veidi tuunitud, mysql kindla põhjaga. Päris palju staatilist (netipoes on ju ilusad HD-pildid ja kõik muu selline), seansi jaoks Redis ja otsinguks Elasticsearch. Hakkame mõtlema seisakutele. Ja siin on muidugi ilmselge, et veebipood ei saa päevagi valutult ringi vedeleda. Lõppude lõpuks, mida kauem see valetab, seda rohkem raha me kaotame. Tasub kiirendada. Kui palju? Ma arvan, et kui me tund aega pikali lamame, ei lähe keegi hulluks. Jah, me kaotame midagi, aga kui hakkame pingutama, läheb see ainult hullemaks. Määratleme tunnis lubatud seisakuaja skeemi.
Kuidas seda kõike reserveerida? Autot on igal juhul vaja: tund aega on üsna vähe. Mysql: siin on juba vaja replikatsiooni, reaalajas replikatsiooni, sest tunniga 100 GB suure tõenäosusega prügimäele ei lisandu. Staatika, pildid: jällegi, tunniga 500 GB ei pruugi olla aega lisada. Seetõttu on parem pildid kohe kopeerida. Redis: siin lähevad asjad huvitavaks. Redis salvestatakse seansid – me ei saa seda lihtsalt võtta ja maha matta. Sest see ei ole väga hea: kõik kasutajad logitakse välja, nende korvid tühjendatakse jne. Inimesed on sunnitud oma kasutajanime ja parooli uuesti sisestama ning paljud inimesed võivad lahku minna ja ostu sooritamata jätta. Jällegi konversioonid vähenevad. Teisalt on Redis otseselt kursis, viimaseid sisseloginud kasutajaid pole ilmselt ka vaja. Ja hea kompromiss on võtta Redis ja taastada see eilsest varukoopiast või, kui teete seda iga tund, siis tunnitagusest varukoopiast. Õnneks tähendab selle varukoopiast taastamine ühe faili kopeerimist. Ja kõige huvitavam lugu on Elasticsearch. Kes on kunagi MySQL-i replikatsiooni üles võtnud? Kes on kunagi Elasticsearchi replikatsiooni üles võtnud? Ja kelle jaoks see pärast normaalselt töötas? Pean silmas seda, et me näeme oma süsteemis teatud üksust. Tundub, et see on kasulik, kuid see on keeruline.
Keeruline selles mõttes, et meie kolleegidel puudub sellega töötamise kogemus. Või on negatiivne kogemus. Või saame aru, et see on veel üsna uus tehnoloogia, millel on nüansse või toorust. Arvame... Kurat, elastik on ka tervislik, ka selle varukoopiast taastamine võtab kaua aega, mida teha? Mõistame, et meie puhul kasutatakse otsinguks elastset. Kuidas meie veebipood müüb? Läheme turundajate juurde ja küsime, kust inimesed tulevad. Nad vastavad: "90% Yandex Marketist tulevad otse tootekaardile." Ja nad kas ostavad selle või ei osta. Seetõttu vajavad otsingut 10% kasutajatest. Ja elastse replikatsiooni hoidmisel, eriti erinevate andmekeskuste vahel erinevates tsoonides, on tõesti palju nüansse. Milline väljapääs? Võtame reserveeritud saidilt elastiku ega tee sellega midagi. Kui asi venib, siis ilmselt tõstatame selle kunagi üles, aga see pole kindel. Tegelikult on järeldus sama, pluss või miinus: me jällegi ei broneeri teenuseid, mis raha ei mõjuta. Et diagramm oleks lihtsam.
Näide number neli, veelgi raskem
Integraator: lillede müük, takso kutsumine, kauba müük, üldiselt kõik. Tõsine asi, mis töötab 24/7 suure hulga kasutajate jaoks. Täisväärtusliku huvitava stäkiga, kus on huvitavad alused, lahendused, suur koormus ja mis peamine, üle 5 minuti pikali on valus. Mitte ainult ja mitte niivõrd sellepärast, et inimesed ei osta, vaid sellepärast, et inimesed näevad, et see asi ei tööta, nad ärrituvad ja ei pruugi üldse tagasi tulla.
OKEI. Viis minutit. Mida me sellega ette võtame? Sel juhul kasutame me, nagu täiskasvanud, kogu raha tõelise varusaidi loomiseks koos kõike replikatsiooniga ja võib-olla isegi automatiseerime sellele saidile ülemineku nii palju kui võimalik. Ja lisaks sellele peate meeles pidama üht olulist asja: tegelikult kirjutage vahetusmäärused. Eeskirjad võivad olla väga lihtsad, isegi kui teil on kõik automatiseeritud. Sarjadest "käivita selline ja selline võimalik skript", "klõpsake marsruudil 53 sellist ja sellist märkeruutu" ja nii edasi - aga see peab olema mingi täpne toimingute loend.
Ja kõik tundub selge. Replikatsiooni vahetamine on triviaalne ülesanne või see lülitub ise. Domeeninime ümberkirjutamine DNS-is on samast seeriast. Häda on selles, et kui selline projekt ebaõnnestub, algab paanika ja isegi kõige tugevamad habemega administraatorid võivad sellele vastuvõtlikud olla. Ilma selgete juhisteta “ava terminal, tule siia, meie serveri aadress on ikka selline”, on raske elustamiseks määratud 5-minutilist tähtaega täita. Pluss, kui me neid määrusi kasutame, siis on lihtne näiteks mõned muudatused infrastruktuuris fikseerida ja vastavalt muuta määrusi.
Noh, kui broneerimissüsteem on väga keeruline ja mingil hetkel tegime vea, siis võime oma varundamissaidi hävitada ja lisaks muuta mõlema saidi andmed kõrvitsaks - see on täiesti kurb.
Näide number viis, täielik hardcore
Rahvusvaheline teenus, millel on sadu miljoneid kasutajaid üle maailma. Kõik ajavööndid on olemas, maksimaalne koormus suur, ei saa üldse pikali. Minut – ja see on kurb. Mida teha? Broneeri jällegi täisprogrammi järgi. Tegime kõike, millest eelmises näites rääkisin, ja natuke rohkemgi. Ideaalne maailm ja meie infrastruktuur vastab kõigile IaaC devopsi kontseptsioonidele. See tähendab, et kõik on gitis ja vajutate lihtsalt nuppu.
Mis on puudu? Üks - harjutused. Ilma nendeta on see võimatu. Tundub, et meiega on kõik täiuslik, meil on üldiselt kõik kontrolli all. Vajutame nuppu, kõik juhtub. Isegi kui see nii on – ja me mõistame, et see nii ei juhtu – suhtleb meie süsteem mõne teise süsteemiga. Näiteks on see dns marsruudilt 53, s3 salvestusruum, integratsioon mõne api-ga. Me ei saa selles spekulatiivses eksperimendis kõike ette näha. Ja kuni me tegelikult lülitit tõmbame, ei tea me, kas see töötab või mitte.
See on ilmselt kõik. Ärge olge laisk ega pingutage üle. Ja tööaeg võib olla teiega!
Allikas: www.habr.com