Üleminek: meid tapab perfektsionism ja… laiskus

Suvel tõuseb traditsiooniliselt nii ostjate aktiivsus kui ka veebiprojektide infrastruktuuri muutumise intensiivsus, ütleb meile Kapten Ilmselgus. Lihtsalt sellepärast, et isegi IT-ala spetsialistid lähevad vahetevahel puhkusele. Ja CTO-d samuti. Sellega on raskem neil, kes jäävad ametisse, kuid praegu sellest ei räägi: võib-olla on just seetõttu suvi parim aeg rahulikult üle vaadata olemasolev varukoopiate skeem ja koostada plaan selle täiustamiseks. Ja selles aitab teid Egor Andreevi kogemus, AdminDivision, millest ta rääkis konverentsil Uptime day.

Varupindade ehitamisel ja varukoopiate tegemisel on mitmeid lõkse, millesse on lihtne sattuda. Ja nendesse ei tohi kindlasti sattuda. Selle kõik hävitab meid, nagu ka paljus muus, perfektsionism ja… laiskus. Me püüame teha kõike võimalikult ideaalselt, aga ideaalselt tegema tegelikult ei pea! Tuleb teha ainult teatud asju, kuid õigesti, viia need lõpule, et nad korralikult töötaksid.

Failover ei ole mingi lõbus ja mänguline asi, "et oleks"; see on asi, mis peab tegema täpselt ühte asja — vähendama seisaku aega, et teenus, ettevõte kaotaks vähem raha. Ja kõigis varukoopiate meetodites soovitan mõelda järgmises kontekstis: kus on raha?

Esimene lõks: kui me ehitame suuri usaldusväärseid süsteeme ja tegeleme varukoopiate tegemisega — vähendame õnnetuste arvu. See on hirmus eksiarvamus. Kui me tegeleme varukoopiate tegemisega, suurendab see tõenäoliselt õnnetuste arvu. Ja kui me teeme kõik õigesti, siis kokkuvõttes vähendame me seisaku aega. Õnnetusi on rohkem, kuid need juhtuvad väiksemate kuludega. Mis on varukoopia? — see on süsteemi keerukuse suurendamine. Iga keerukus on halb: meil on rohkem kruvikeerajaid, rohkem hammasrattaid, sõnaga, rohkem komponente — ja seega suurem tõenäosus rikete tekkeks. Ja nad tõepoolest purunevad. Ja purunevad tihedamini. Lihtne näide: ütleme, et meil on mingi veebileht PHP ja MySQL. Ja see tuleb kiiresti varundada.

Noh, võtame teise platvormi ja ehitame sarnase süsteemi… Raskusaste kahekordistub – meil on kaks üksust. Lisaks sellele rakendame teatud loogikat andmete ülekandmiseks ühelt platvormilt teisele – see tähendab andmete replikatsiooni, staatika kopeerimist ja nii edasi. Noh, replikatsiooni loogika on tavaliselt väga keeruline, mistõttu võib süsteemi koguraskus olla mitte 2, vaid 3, 5 või isegi 10 korda suurem.

Teine lõks: kui ehitame tõeliselt suuri ja keerulisi süsteeme, fantaseerime, mida me lõpuks soovime saada. Voilà: me tahame superusaldusväärset süsteemi, mis töötab täiesti katkestusteta, vahetub poolsesekundi jooksul (või veel parem – koheselt) ja hakkame oma unistusi ellu viima. Kuid siin on ka nüanss: mida vähem on soovitud vahetus aega, seda keerulisemaks muutub süsteemi loogika. Mida keerulisemad on meie süsteemilogika nõuded, seda sagedamini see tõrkuda võib. Ja võime sattuda tõeliselt ebamugavasse olukorda: me püüame igati katkestus aega vähendada, kuid tegelikult keerustame asju, ja kui midagi läheb valesti, on katkestus aeg lõpuks suurem. Tihti tabad end mõttelt: noh… parem ei oleks me reserveerinud. Paremini oleks üks nõudmist täitnud ja mõistetava katkestus ajaga.

Kuidas selle vastu võidelda? Tuleb lõpetada endale vale ütlemine, lõpetada endale kiitmine, et me hakkame siin kosmoselaeva ehitama, ja mõista adekvaatselt, kui kaua projekt tegelikult kestab. Ja selle maksimaalse aja põhjal valime, milliseid meetodeid usaldusväärsuse suurendamiseks rakendame.

On just õige aeg «jutustusteks elust»… elu, muidugi.

Näide number üks

Kujutage ette visiitkaarti torutootmisettevõttest N. linnas. Sellel on suurte tähtedega kirjutatud – TORUTOOTMINE №1. Veidi madalamal on slogan: «Meie torud on kõige ümmargused torud N-s». Ja allpool on ettevõtte direktori telefoninumber ja tema nimi. Mõistame, et broneerimine on vajalik – see on väga oluline asi! Alustame välja selgitamist, millest see koosneb. Html-staatika – see tähendab paar pilti, kus direktor, tegelikult, istub laua taga saunas oma partneriga, arutades mõnda järjekordset tehingut. Alustame mõtlema seisakule. Tuleb pähe: seal peab olema umbes viis minutit, mitte rohkem. Ja nüüd küsimus: kui palju meie saidilt on üldse müüke olnud? Kui palju-kui palju? Mida tähendab «null»? Ameerika selgub: kuna kõik neli tehingut eelmise aasta jooksul tegi direktor just seal laua taga, samade inimestega, kellega nad koos saunas on. Ja mõistame, et isegi kui sait lebab päeva, pole seal midagi kohutavat.

Lähtudes sisendist, on ühte päeva selle asja üles tõstmiseks. Alustame mõtlema broneerimisskeemile. Ja valime selle näite jaoks kõige ideaalsema broneerimisskeemi: me ei kasuta broneerimist. Kõik see tõstetakse üles igasuguse administraatori poolt poole tunni jooksul koos pausidega. Veebiserveri seadistamine, failide üleslaadimine – kõik. See hakkab tööle. Ei pea millegi jälgimisega vaeva nägema, millelegi erilist tähelepanu pöörama. Seega on esimese näite järeldus üsna ilmselge: teenuseid, mida broneerida ei ole vaja – broneerida ei ole vaja.

Teine näide

Ettevõtte blogi: spetsiaalselt koolitatud inimesed kirjutavad sinna uudiseid, et osaleda näiteks mingil messil või esitleda uut toodet ja nii edasi. Oletame, et see on standardne PHP koos WordPressiga, väike andmebaas ja natuke staatikat. Loomulikult tuleb jälle meelde, et midagi ei tohi jätta lihtsalt seisma — "kuni viis minutit!", ja need asjad. Kuid mõelgem edasi. Mida see blogi teeb? Siia tulevad külastajad Yandexist, Google'ist mingite päringute kaudu, orgaaniliselt. Huvitav. Aga kuidas on müügiga? Üks teadlik avastus: ei kuigi palju. Reklaamiliiklus suundub peamisele saidile, mis asub teisel serveril. Hakkame mõtlema, kuidas tagada blogi reserveerimine. Parima lahendusena peaksime olema valmis selle paariks tunniks üles tõstma. Mõistlik oleks võtta teises andmekeskuses server, installida sellele keskkond, st veebiserver, PHP, WordPress, MySQL ja hoida seda nö. valmisolekus. Kui me mõistame, et midagi on katki, tuleb teha kaks asja - taastada MySQL dump suurusega 50 MB, mis läbib seal minutiga, ja OAuth seansiga taastada mingi hulk pilte varukoopiast. See ei ole ka seal just tohutult palju. Nii tõuseb kogu see süsteem poole tunni pärast üles. Ei mingit replikatsiooni või lunastust, Allah hoidku, automaatset failover'it. Järeldus: mida saame kiiresti taastada varukoopiast, ei pea reserveerima.

Näide number kolm, keerulisem

Internetipood. PHP koos pisut kohandatud open heart'iga, MySQL korraliku andmebaasiga. Suur hulk staatikat (sest internetipoes on ilusad HD-pildid ja muud sellist), Redis sessioonide jaoks ja Elasticsearch otsinguks. Hakkame mõtlema seisaku ajale. Ja siin on loomulikult ilmne, et päev ilma probleemideta internetipood ei saa olla. Mida kauem see seisab, seda rohkem raha me kaotame. Tuleb kiirendada. Aga kui palju? Arvan, et kui me tunni seisame, siis keegi ei lähe segaseks. Jah, me kaotame midagi, aga kui hakkame liiga agaralt pingutama — läheb vaid hullemaks. Määrame tunni jooksul lubatava seisaku skeemi.

Kuidas seda kõike reserveerida? Masin on igal juhul vajalik: tund aega on üsna vähe. Mysql: siin on juba vajalik replikatsioon, elav replikatsioon, sest tunni jooksul 100 GB dumpi tõenäoliselt ei mahu. Statiika, pildid: taas, tunni jooksul 500 GB ei pruugi jõuda. Seega on parem kohe pildid kopeerida. Redis: siin on asi huvitavam. Redis'e seansid on seal — lihtsalt võtta ja hävitada me ei saa. Sest see ei oleks väga hea: kõik kasutajad logivad välja, ostukorvid on tühjad ja nii edasi. Inimesed peavad uuesti sisestama oma sisselogimise ja parooli, ja palju inimesi võib loobuda ning ostu mitte lõpetada. Jälle, konversioon langeb. Teiselt poolt, Redis on siiski täpselt nagu viimasena sisse logitud kasutajad, ilmselt ei ole ka see vajalik. Hea kompromiss oleks võtta Redis ja taastada see varukoopiast, eilsetest, või kui see toimub iga tunni järel, — tunni vanusest. Õnneks on selle taastamine varukoopiast ühe faili kopeerimine. Ja kõige huvitavam lugu on Elasticsearch. Kes on kunagi seadistanud MySQL replikatsiooni? Kes on kunagi seadistanud Elasticsearch'i replikatsiooni? Ja kellel see on pärast normaalselt töötanud? Mida ma mõtlen: näeme meie süsteemis mingit olemust. See tundub olevat kasulik — aga see on keeruline.
See, our engineers have little to no experience working with it. Or they have some negative experiences. We understand that this is still a fairly new technology with nuances or immaturity. We're thinking… Damn, Elasticsearch is also quite bulky, and it takes a long time to recover it from backup, what do we do? We understand that Elasticsearch is used for searching in this case. But how does our online store sell? We ask the marketers where customers come from. They reply: "90% come directly from Yandex Market to the product card." And they either buy or they don’t. Consequently, search is only needed by 10% of users. Maintaining the replication of Elasticsearch, especially between different data centers in various zones, indeed has many nuances. What’s the way out? We take Elasticsearch on a dedicated site and do nothing with it. If it takes longer, maybe we'll bring it back up someday, but that's not certain. Essentially, the conclusion remains more or less the same: services that don’t affect revenue, we again don’t reserve. To keep the scheme simpler.

Example number four, even more complicated.

Integrator: flower sales, taxi calls, product sales, in general, anything. A serious setup that operates 24/7 for a large number of users. With a fully featured interesting stack, containing intriguing databases, solutions, high loads, and most importantly, being down for more than 5 minutes is painful. Not just because people won’t buy, but because they will see that this thing isn’t working, get upset, and might not come back at all.

Okay. Five minutes. What are we going to do about this? In this case, we seriously build a real backup site with replication of everything and possibly even automate the switch to this site to the maximum. And in addition to that, one important thing should not be forgotten: to actually write a switching procedure. The procedure, even if everything is automated, can be very simple. Like "run this ansible scenario," "check this box in Route 53," and so on — but it should be a precise list of actions.

Ja kõik tundub olevat selge. Replikatsiooni aktiveerimine on triviaalne ülesanne, või siis aktiveerub see ise. Domeeninime mõttevahetus DNS-is kuulub sama kategooriasse. Probleem on selles, et kui sarnane projekt ebaõnnestub, tekib paanika, ja isegi kõige tugevamad, kogenud administraatorid võivad selle all murduda. Ilma selgete juhisteta "ava terminal, mine siia, meie serveri aadress on endiselt selline" on raske pidada 5-minutilist tähtaega elustamiseks. Lisaks, kui me seda korda kasutame, on lihtne fikseerida mingeid muudatusi infrastruktuuris, näiteks — ja vastavalt sellele muuta korda.
Kuid, kui broneerimissüsteem on väga keeruline ja mingil hetkel teeme vea, võime me lükata alla ka meie varukoha, ning lisaks muuta andmed mõlemas kohas peaaegu kasutuks — see oleks tõeliselt kurb.

Näide number viis, täielik hardcore.

Rahvusvaheline teenus, millel on sadu milioneid kasutajaid üle kogu maailma. Kõik ajavööndid, mis ainult olemas on, kõrge koormus maksimaalselt, ei tohi üldse olla häired. Üks minut — ja olukord muutub kurvaks. Mida teha? Broneerida, jälle täielikult. Tehtud on kõik, millest eelnevas näites rääkisin, ja veel natuke rohkem. Ideaalne maailm, ja meie infrastruktuur – see on kõigis DevOps'i mõistes IaaC. See tähendab, et kõik on git'is, ja vajuta lihtsalt nuppu.

Mida puudu jääb? Üht — harjutusi. Ilma nendeta ei saa. Tundub, et meil on kõik ideaalne, meil on tõeliselt kõik kontrolli all. Vaatame nuppu, kõik juhtub. Isegi kui see nii on — ja me mõistame, et see ei ole tõsi — meie süsteem suhtleb mingite teiste süsteemidega. Näiteks, see on DNS Route 53-lt, S3 salvestamiseks, integreerimine mingite API-dega. Kõike ette näha selle hüpoteetilise eksperimendi raames me ei suuda. Ja kuni me reaalsetl lülitit ei tõmba — ei saa me teada, kas see töötab või mitte.

Sellega on vist kõik. Ärge olge laisk ja ärge üle pingutage. Ja las uptime olgu teiega!

Allikas: habr.com