Nyáron hagyományosan csökken mind a beszerzési aktivitás, mind a webprojektek infrastruktúrájában bekövetkezett változások intenzitása – mondja lapunknak Obvious kapitány. Egyszerűen azért, mert néha még az informatikusok is elmennek nyaralni. És a CTO is. A hivatalban maradóknak annál nehezebb, de most nem ez a lényeg: talán éppen ezért a nyár a legalkalmasabb időszak arra, hogy lassan átgondoljuk a meglévő foglalási rendszert, és tervet készítsünk annak javítására. És Jegor Andreev tapasztalata , amelyről a konferencián beszélt .
A biztonsági mentési helyek készítése során számos buktatóba eshet. És teljesen lehetetlen elkapni őket. És ami ebben az egészben tönkretesz minket, mint sok mindenben, az a perfekcionizmus és... a lustaság. Igyekszünk mindent, mindent, mindent tökéletesen megcsinálni, de nem kell tökéletesen! Csak bizonyos dolgokat kell megcsinálni, de helyesen csinálni, befejezni, hogy megfelelően működjenek.
A feladatátvétel nem valamiféle mulatságos, mulatságos dolog; ez az a dolog, aminek pontosan egy dolgot kell tennie – csökkenteni az állásidőt, hogy a szolgáltatás, a cég kevesebb pénzt veszítsen. És minden foglalási módnál javaslom a következő összefüggésben gondolkodni: hol van a pénz?
Első csapda: amikor nagy, megbízható rendszereket építünk és redundanciát folytatunk, csökkentjük a balesetek számát. Ez egy szörnyű tévhit. Ha redundanciát hajtunk végre, akkor valószínűleg növeljük a balesetek számát. És ha mindent jól csinálunk, akkor közösen csökkentjük az állásidőt. Több lesz a baleset, de azok alacsonyabb költségek mellett történnek. Mi az a foglalás? - ez a rendszer bonyodalma. Bármilyen komplikáció rossz: több fogaskerekünk, több fogaskerekünk, egyszóval több elemünk van – és ezért nagyobb a meghibásodás esélye. És tényleg összetörnek. És gyakrabban fognak eltörni. Egy egyszerű példa: tegyük fel, hogy van egy weboldalunk PHP-val és MySQL-lel. És sürgősen le kell foglalni.
Shtosh (c) Vegyük a második helyszínt, egy azonos rendszert építünk... A bonyolultság kétszer nagyobb lesz – két entitásunk van. Ezenkívül bevezetünk egy bizonyos logikát az adatok egyik helyről a másikra való átvitelére – azaz adatreplikációra, statikus adatok másolására és így tovább. Tehát a replikációs logika általában nagyon összetett, ezért a rendszer teljes összetettsége nem 2-szer, hanem 3-szor, 5-ször, 10-szer nagyobb lehet.
Második csapda: amikor igazán nagy, összetett rendszereket építünk, arról fantáziálunk, hogy végül mit is szeretnénk elérni. Voila: egy szupermegbízható rendszert szeretnénk kapni, amely minden leállás nélkül működik, fél másodperc alatt (vagy jobb esetben azonnal) kapcsol, és elkezdjük megvalósítani az álmainkat. De van itt egy árnyalat is: minél rövidebb a kívánt kapcsolási idő, annál bonyolultabbá válik a rendszerlogika. Minél összetettebbé kell alakítanunk ezt a logikát, annál gyakrabban fog összeomlani a rendszer. És nagyon kellemetlen helyzetbe kerülhet: minden erőnkkel igyekszünk csökkenteni az állásidőt, de valójában mindent bonyolultabbá teszünk, és ha valami elromlik, az állásidő hosszabb lesz. Itt gyakran azon kapod magad, hogy azt gondolod: hát... jobb lenne nem foglalni. Jobb lenne, ha egyedül és érthető állásidővel működne.
Hogyan lehet ez ellen küzdeni? Abba kell hagynunk a hazudozást magunknak, abba kell hagynunk magunknak a hízelgést, hogy most űrhajót fogunk építeni ide, de kellőképpen meg kell értenünk, meddig hazudhat a projekt. És erre a maximális időre kiválasztjuk, hogy ténylegesen milyen módszerekkel növeljük rendszerünk megbízhatóságát.
Itt az ideje a „sztoriknak w-ből”... az életből, természetesen.
Első számú példa
Képzeljen el egy névjegykártyás weboldalt az 1. számú csőhengerműhöz N. városában. Hatalmas betűkkel ez áll: 1. CSŐhengermű. Alatta a szlogen: „A mi pipáink a legkerekebb pipák N-ben.” Alul pedig a vezérigazgató telefonszáma és neve. Megértjük, hogy le kell foglalnia - ez nagyon fontos dolog! Kezdjük kitalálni, miből áll. Html-statika - vagyis pár kép, ahol a vezérigazgató tulajdonképpen valami következő üzletről tárgyal a fürdőházban az asztalnál párjával. Elkezdünk az állásidőre gondolni. Eszembe jut: öt percig kell ott feküdnie, nem tovább. És akkor felmerül a kérdés: általában hány eladás volt erről az oldalunkról? Mennyi-mennyi? Mit jelent a "nulla"? Ez pedig azt jelenti: mert a tábornok tavaly mind a négy tranzakciót egy asztalnál kötötte, ugyanazokkal az emberekkel, akikkel fürdőbe mennek és asztalhoz ülnek. És megértjük, hogy még ha az oldal egy napig is működik, semmi szörnyű nem fog történni.
A bevezető információk alapján van egy nap ennek a történetnek a felvetése. Kezdjünk el gondolkodni egy elbocsátási rendszeren. És ehhez a példához a legideálisabb redundanciasémát választjuk: nem használunk redundanciát. Ezt az egészet bármelyik admin fél óra alatt fel tudja emelni füstszünetekkel. Telepítsen egy webszervert, adjon hozzá fájlokat - ennyi. Működni fog. Nem kell semmire sem figyelni, semmire nem kell különösebben odafigyelni. Vagyis az első számú példa következtetése egészen nyilvánvaló: azokat a szolgáltatásokat, amelyeket nem kell lefoglalni, nem kell lefoglalni.
Második példa
Céges blog: speciálisan képzett emberek írnak oda híreket, részt vettünk ilyen-olyan kiállításon, de kiadtunk még egy új terméket stb. Tegyük fel, hogy ez egy szabványos PHP WordPress-szel, egy kis adatbázissal és egy kis statikussággal. Természetesen újra eszembe jut, hogy semmi esetre se feküdjön le - „legfeljebb öt percet!” Ez minden. De gondoljuk tovább. Mit csinál ez a blog? Az emberek a Yandextől, bizonyos lekérdezések alapján a Google-tól organikusan jönnek oda. Nagy. Az értékesítésnek van valami köze hozzá? Vízkereszt: nem igazán. A hirdetési forgalom a fő webhelyre irányul, amely egy másik gépen van. Kezdjünk el gondolkodni egy foglalási rendszeren. Jó értelemben pár óra alatt fel kell nevelni, erre jó lenne felkészülni. Célszerű lenne egy másik adatközpontból venni egy gépet, rátekerni a környezetet, azaz webszervert, PHP-t, WordPress-t, MySQL-t, és ott hagyni. Abban a pillanatban, amikor megértjük, hogy minden elromlott, két dolgot kell tennünk - 50 méterrel ki kell gördíteni a mysql dump-ot, egy percen belül odarepül, és ki kell gurítani bizonyos számú képet a biztonsági másolatból. Ez sincs ott, Isten tudja meddig. Így fél óra alatt az egész felemelkedik. Nincs replikáció, vagy Isten bocsásson meg, automatikus feladatátvétel. Következtetés: amit egy biztonsági mentésből gyorsan ki tudunk állítani, arról nem kell biztonsági másolatot készíteni.
Harmadik példa, bonyolultabb
Online áruház. Nyitott szívű PhP egy kicsit átdolgozott, mysql szilárd alappal. Meglehetősen sok statikus (elvégre az online áruházban gyönyörű HD-képek vannak, meg minden ilyesmi), Redis a munkamenethez és Elasticsearch a kereséshez. Elkezdünk az állásidőre gondolni. És itt persze nyilvánvaló, hogy egy webáruház egy napig sem heverhet el fájdalommentesen. Végtére is, minél tovább fekszik, annál több pénzt veszítünk. Érdemes gyorsítani. Mennyi? Szerintem ha lefekszünk egy órát, senki nem fog megőrülni. Igen, veszítünk valamit, de ha elkezdünk keményen dolgozni, az csak rosszabb lesz. Meghatározzuk az óránként megengedett állásidő sémáját.
Hogyan lehet mindezt lefoglalni? Autóra mindenképpen szükség van: egy óra idő elég kevés. Mysql: itt már replikáció, élő replikáció kell, mert egy óra múlva 100 GB nagy valószínűséggel nem kerül a dumpba. Statika, képek: megint egy óra múlva 500 GB-ot nem biztos, hogy lesz idő hozzáadni. Ezért jobb, ha azonnal másolja a képeket. Redis: itt kezdenek érdekesek lenni a dolgok. A Redisben a munkamenetek tárolódnak – nem tudjuk csak úgy elvenni és eltemetni. Mert ez nem lesz túl jó: minden felhasználó ki lesz jelentkezve, kosara kiürül stb. Az emberek kénytelenek lesznek újra megadni felhasználónevüket és jelszavukat, és sokan elszakadhatnak, és nem fejezik be a vásárlást. A konverziók ismét csökkenni fognak. Másrészt a Redis közvetlenül naprakész, valószínűleg az utoljára bejelentkezett felhasználókra sem lesz szükség. És egy jó kompromisszum az, ha előveszed a Redist és visszaállítod egy tegnapi biztonsági másolatból, vagy ha óránként csinálod, akkor egy órával ezelőttről. Szerencsére a biztonsági másolatból történő visszaállítás egy fájl másolásával jár. És a legérdekesebb történet az Elasticsearch. Ki vette már fel a MySQL replikációt? Ki vette már fel az Elasticsearch replikációt? És kinek működött utána normálisan? Úgy értem, hogy látunk egy bizonyos entitást a rendszerünkben. Hasznosnak tűnik – de összetett.
Bonyolult abban az értelemben, hogy mérnöktársainknak nincs tapasztalatuk ezzel kapcsolatban. Vagy van negatív tapasztalat. Vagy megértjük, hogy ez még mindig meglehetősen új technológia árnyalatokkal vagy nyersséggel. Szerintünk... Basszus, a rugalmas is egészséges, mentésből is sokáig tart visszaállítani, mit tegyek? Megértjük, hogy esetünkben az elasztikust a kereséshez használjuk. Hogyan értékesít webáruházunk? Elmegyünk marketingesekhez, és megkérdezzük, honnan jönnek az emberek. Azt válaszolják: „A Yandex Market 90%-a közvetlenül a termékkártyára érkezik.” És vagy megveszik, vagy nem. Ezért a keresésre a felhasználók 10%-ának van szüksége. És a rugalmas replikáció megtartása, különösen a különböző zónákban lévő különböző adatközpontok között, valóban sok árnyalattal jár. Melyik kijárat? Foglalt oldalról veszünk gumit, és nem csinálunk vele semmit. Ha elhúzódik az ügy, valószínűleg egyszer felvetjük, de ez nem biztos. Valójában a következtetés ugyanaz, plusz vagy mínusz: ismét nem foglalunk le olyan szolgáltatásokat, amelyek nem érintik a pénzt. Hogy a diagram egyszerűbb legyen.
A negyedik példa, még nehezebb
Integrátor: virágok eladása, taxi hívása, áruk eladása, általában bármi. Komoly dolog, amely a hét minden napján, 24 órában működik nagyszámú felhasználó számára. Teljes értékű érdekes stack-el, ahol érdekes alapok, megoldások, nagy terhelés, és ami a legfontosabb, 7 percnél tovább fáj a fekvés. Nem csak és nem annyira azért, mert az emberek nem vásárolnak, hanem mert az emberek látják, hogy ez a dolog nem működik, idegesek lesznek, és lehet, hogy egyáltalán nem jönnek vissza.
RENDBEN. Öt perc. Mit fogunk tenni ez ügyben? Ebben az esetben mi, akárcsak a felnőttek, minden pénzt arra fordítunk, hogy valódi biztonsági másolatot készítsünk, mindent replikálva, és talán még automatizáljuk is az erre az oldalra való váltást, amennyire csak lehetséges. És ezen kívül egy fontos dolgot meg kell tennie: tulajdonképpen meg kell írnia a váltási szabályzatot. A szabályozás, még ha mindent automatizált is, nagyon egyszerűek lehetnek. A „futtasson ilyen és olyan lehetséges szkriptet”, „kattintson egy ilyen és ehhez hasonló jelölőnégyzetet az 53-as útvonalon” és így tovább sorozatból - de ez egy pontos lista a műveletekről.
És minden világosnak tűnik. A replikáció váltása triviális feladat, vagy magától átvált. A tartománynév DNS-ben történő átírása ugyanabból a sorozatból származik. Az a baj, hogy ha egy ilyen projekt meghiúsul, pánik kezdődik, és még a legerősebb, szakállas adminok is fogékonyak lehetnek rá. A „nyisd ki a terminált, gyere ide, a szerverünk címe még mindig ilyen” egyértelmű utasítások nélkül nehéz betartani az újraélesztésre szánt 5 perces határidőt. Plusz, amikor ezeket a szabályozásokat alkalmazzuk, könnyen rögzíthetünk például néhány változást az infrastruktúrában, és ennek megfelelően módosíthatjuk a szabályozást.
Nos, ha a foglalási rendszer nagyon összetett, és valamikor hibát követtünk el, akkor megsemmisíthetjük a biztonsági másolatot, és ráadásul mindkét oldalon tökké alakíthatjuk az adatokat - ez teljesen szomorú lesz.
Ötödik példa, teljes hardcore
Nemzetközi szolgáltatás több száz millió felhasználóval szerte a világon. Minden időzóna van, nagy terhelés maximális sebességnél, egyáltalán nem lehet feküdni. Egy perc – és szomorú lesz. Mit kell tenni? Foglaljon, ismét a teljes program szerint. Mindent megtettünk, amiről az előző példában beszéltem, és egy kicsit többet is. Ideális világ, és az infrastruktúránk az IaaC devops összes koncepciója szerint működik. Vagyis minden a gitben van, és csak meg kell nyomni a gombot.
Mi hiányzik? Egy - gyakorlatok. Nélkülük lehetetlen. Úgy tűnik, nálunk minden tökéletes, általában mindent kézben tartunk. Megnyomjuk a gombot, minden történik. Még ha ez így is van - és megértjük, hogy ez nem így történik -, rendszerünk kölcsönhatásba lép néhány más rendszerrel. Ez például dns az 53-as útvonalról, s3 tárhely, integráció valamilyen api-val. Ebben a spekulatív kísérletben nem fogunk tudni mindent előre látni. És amíg meg nem húzzuk a kapcsolót, nem tudjuk, hogy működni fog-e vagy sem.
Valószínűleg ennyi. Ne legyen lusta és ne vigye túlzásba. És az üzemidő legyen veled!
Forrás: will.com