Kesällä sekä ostoaktiivisuus että verkkoprojektien infrastruktuurin muutosten intensiteetti perinteisesti laskee, Captain Obvious kertoo. Yksinkertaisesti siksi, että jopa IT-asiantuntijat ovat joskus lomalla. Ja CTO myös. Sitäkin vaikeampaa on virassa oleville, mutta siitä ei nyt ole kysymys: kenties siksi kesä on parasta aikaa miettiä pikkuhiljaa olemassa olevaa varausjärjestelmää ja laatia suunnitelma sen parantamiseksi. Ja Jegor Andreevin kokemus , josta hän puhui konferenssissa .
Varmuuskopiointisivustoja rakentaessasi voit joutua useisiin sudenkuoppiin. Ja niihin on täysin mahdotonta jäädä kiinni. Ja mikä meitä pilaa tässä kaikessa, kuten monessa muussakin asiassa, on perfektionismi ja... laiskuus. Yritämme tehdä kaiken, kaiken, kaiken täydellisesti, mutta meidän ei tarvitse tehdä sitä täydellisesti! Sinun tarvitsee vain tehdä tietyt asiat, mutta tehdä ne oikein, suorittaa ne niin, että ne toimivat oikein.
Failover ei ole jonkinlainen hauska, hauska asia; Tämä on asia, jonka pitäisi tehdä juuri yksi asia - vähentää seisokkeja, jotta palvelu, yritys, menettää vähemmän rahaa. Ja kaikissa varausmenetelmissä ehdotan ajattelua seuraavassa yhteydessä: missä on rahat?
Ensimmäinen ansa: kun rakennamme suuria, luotettavia järjestelmiä ja harjoitamme redundanssia, vähennämme onnettomuuksien määrää. Tämä on kauhea väärinkäsitys. Irtisanoutuessamme todennäköisesti lisäämme onnettomuuksien määrää. Ja jos teemme kaiken oikein, vähennämme seisokkeja yhdessä. Onnettomuuksia tulee enemmän, mutta ne tapahtuvat pienemmillä kustannuksilla. Mikä on varaus? - Tämä on järjestelmän monimutkaisuus. Kaikki komplikaatiot ovat huonoja: meillä on enemmän hammaspyöriä, enemmän vaihteita, sanalla sanoen enemmän elementtejä - ja siksi suurempi mahdollisuus rikkoutua. Ja ne todella rikkoutuvat. Ja ne hajoavat useammin. Yksinkertainen esimerkki: Oletetaan, että meillä on verkkosivusto, jossa on PHP ja MySQL. Ja se on kiireesti varattava.
Shtosh (c) Otamme toisen sivuston, rakennamme identtisen järjestelmän... Monimutkaisuus kasvaa kaksi kertaa - meillä on kaksi kokonaisuutta. Otamme käyttöön myös tietyn logiikan tietojen siirtämiseen yhdestä sivustosta toiseen – toisin sanoen tietojen replikointia, staattisten tietojen kopioimista ja niin edelleen. Joten replikointilogiikka on yleensä hyvin monimutkainen, ja siksi järjestelmän kokonaismonimutkaisuus ei voi olla 2, vaan 3, 5, 10 kertaa suurempi.
Toinen ansa: kun rakennamme todella suuria monimutkaisia järjestelmiä, fantasioimme siitä, mitä haluamme lopulta saada. Voila: haluamme saada erittäin luotettavan järjestelmän, joka toimii ilman seisokkeja, kytkeytyy puolessa sekunnissa (tai vielä parempaan hetkessä) ja alamme toteuttaa unelmia. Mutta tässä on myös vivahde: mitä lyhyempi haluttu kytkentäaika, sitä monimutkaisempi järjestelmälogiikka tulee. Mitä monimutkaisempi tämä logiikka on tehtävä, sitä useammin järjestelmä hajoaa. Ja voit päätyä erittäin epämiellyttävään tilanteeseen: yritämme kaikin voimin vähentää seisokkeja, mutta itse asiassa teemme kaikesta monimutkaisempaa, ja kun jokin menee pieleen, seisokit pidentyvät. Tässä usein huomaat itsesi ajattelevan: no... olisi parempi olla tekemättä varausta. Olisi parempi, jos se toimisi yksin ja ymmärrettävillä seisokkeilla.
Kuinka voit taistella tätä vastaan? Meidän on lopetettava valehtelu itsellemme, lakata imartelemasta itseämme, että aiomme rakentaa tänne nyt avaruusaluksen, mutta ymmärtää riittävästi, kuinka kauan projekti voi valehdella. Ja tämän maksimiajan aikana valitsemme, mitä menetelmiä käytämme järjestelmämme luotettavuuden lisäämiseksi.
On "tarinoiden" aika... elämästä, tietysti.
Esimerkki numero yksi
Kuvittele käyntikorttisivustoa N:n kaupungissa sijaitsevalle Pipe Rolling Plant No. 1:lle. Siellä lukee valtavilla kirjaimilla - PIPE Rolling Plant No. 1. Aivan alapuolella on iskulause: "Pippumme ovat N:n pyöreimmät putket." Ja alla on toimitusjohtajan puhelinnumero ja hänen nimensä. Ymmärrämme, että sinun on tehtävä varaus - tämä on erittäin tärkeä asia! Aloitetaan selvittää, mistä se koostuu. Html-statiikka - eli pari kuvaa, joissa pääjohtaja itse asiassa keskustelee jostain seuraavasta kaupasta kylpyläpöydässä kumppaninsa kanssa. Alamme miettiä seisokkeja. Se tulee mieleen: sinun täytyy makaa siellä viisi minuuttia, ei enempää. Ja sitten herää kysymys: kuinka monta myyntiä tällä sivustollamme ylipäänsä oli? Kuinka paljon - kuinka paljon? Mitä "nolla" tarkoittaa? Ja se tarkoittaa: koska kenraali teki viime vuonna kaikki neljä kauppaa saman pöydän ääressä, samojen ihmisten kanssa, joiden kanssa he menevät kylpylään ja istuvat pöytään. Ja ymmärrämme, että vaikka sivusto pysyisi paikallaan päivän, mitään kauheaa ei tapahdu.
Alkutietojen perusteella tämän tarinan nostamiseen on päivä. Aletaan miettimään irtisanomisjärjestelmää. Ja valitsemme ideaalisimman redundanssijärjestelmän tälle esimerkille: emme käytä redundanssia. Tämän koko asian voi kuka tahansa ylläpitäjä nostaa esiin puolessa tunnissa savutauoilla. Asenna verkkopalvelin, lisää tiedostoja - siinä kaikki. Se toimii. Sinun ei tarvitse pitää silmällä mitään, sinun ei tarvitse kiinnittää erityistä huomiota mihinkään. Eli johtopäätös esimerkistä numero yksi on varsin ilmeinen: palveluita, joita ei tarvitse varata, ei tarvitse varata.
Esimerkki numero kaksi
Yritysblogi: erikoiskoulutetut ihmiset kirjoittavat siellä uutisia, osallistuimme sellaiseen ja sellaiseen näyttelyyn, mutta julkaisimme toisen uuden tuotteen ja niin edelleen. Oletetaan, että tämä on tavallinen PHP, jossa on WordPress, pieni tietokanta ja vähän staattista. Tietysti tulee jälleen mieleen, että sinun ei pitäisi missään tapauksessa mennä makuulle - "enintään viisi minuuttia!" Siinä kaikki. Mutta mietitään vielä. Mitä tämä blogi tekee? Ihmiset tulevat sinne Yandexistä, Googlesta joidenkin kyselyjen perusteella, orgaanisesti. Loistava. Onko myynnillä mitään tekemistä asian kanssa? Epiphany: ei oikeastaan. Mainosliikenne ohjataan pääsivustolle, joka on eri koneella. Aletaan miettimään varausjärjestelmää. Hyvällä tavalla se on nostettava parissa tunnissa, ja tähän olisi mukava valmistautua. Olisi järkevää ottaa kone toisesta palvelinkeskuksesta, rullata siihen ympäristö, eli web-palvelin, PHP, WordPress, MySQL ja jättää se sinne. Sillä hetkellä, kun ymmärrämme, että kaikki on rikki, meidän on tehtävä kaksi asiaa - vieritettävä mysql-kaappi 50 metriä, se lentää sinne minuutissa ja rullata tietty määrä kuvia siellä olevasta varmuuskopiosta. Tämä ei myöskään ole olemassa, sillä Jumala tietää kuinka kauan. Siten puolessa tunnissa koko juttu nousee. Ei replikointia, tai Jumala anteeksi, automaattinen vikasieto. Johtopäätös: sitä, mitä voimme nopeasti ottaa käyttöön varmuuskopiosta, ei tarvitse varmuuskopioida.
Esimerkki numero kolme, monimutkaisempi
Verkkokauppa. PhP avoimella sydämellä on hieman muokattu, mysql vakaalla pohjalla. Melko paljon staattista (onhan verkkokaupassa kauniita HD-kuvia ja kaikkea muuta), Redis istuntoon ja Elasticsearch hakuun. Alamme miettiä seisokkeja. Ja tässä tietysti on selvää, ettei verkkokauppa voi makaamaan päivääkään kivuttomasti. Loppujen lopuksi, mitä kauemmin se on, sitä enemmän menetämme rahaa. Kannattaa kiihdyttää. Kuinka paljon? Luulen, että jos makaamme tunnin, kukaan ei tule hulluksi. Kyllä, menetämme jotain, mutta jos alamme työskennellä kovasti, se vain pahenee. Määrittelemme tunnissa sallitun seisokkiajan järjestelmän.
Miten tämän kaiken voi varata? Tarvitset auton joka tapauksessa: tunti aikaa on melko vähän. Mysql: täällä tarvitaan jo replikointia, live replikointia, koska tunnissa 100 Gt ei todennäköisesti tule lisäämään kaatopaikkaan. Statiikka, kuvat: jälleen kerran tunnissa 500 Gt ei ehkä ehdi lisätä. Siksi on parempi kopioida kuvat heti. Redis: täällä asiat ovat mielenkiintoisia. Redisissä istunnot tallennetaan - emme voi vain ottaa sitä ja haudata sitä. Koska tämä ei ole kovin hyvä: kaikki käyttäjät kirjataan ulos, heidän korinsa tyhjennetään ja niin edelleen. Ihmiset joutuvat syöttämään käyttäjätunnuksensa ja salasanansa uudelleen, ja monet ihmiset saattavat erota ja jättää ostoksen suorittamatta. Jälleen konversiot vähenevät. Toisaalta Redis on suoraan ajan tasalla, eikä myöskään viimeksi kirjautuneita käyttäjiä tarvita. Ja hyvä kompromissi on ottaa Redis ja palauttaa se eilisestä varmuuskopiosta tai, jos teet sen tunnin välein, tunnin takaisesta varmuuskopiosta. Onneksi sen palauttaminen varmuuskopiosta tarkoittaa yhden tiedoston kopioimista. Ja mielenkiintoisin tarina on Elasticsearch. Kuka on koskaan ottanut käyttöön MySQL-replikoinnin? Kuka on koskaan ottanut käyttöön Elasticsearch-kopion? Ja kenen kohdalla se toimi normaalisti sen jälkeen? Tarkoitan sitä, että näemme järjestelmässämme tietyn kokonaisuuden. Se näyttää olevan hyödyllinen - mutta se on monimutkainen.
Monimutkaista siinä mielessä, että insinööreillämme ei ole kokemusta sen kanssa työskentelemisestä. Tai sitten on negatiivinen kokemus. Tai ymmärrämme, että tämä on vielä melko uusi tekniikka vivahteineen tai raaka-aineineen. Ajattelemme... Vittu, elastisuus on myös terveellistä, sen palauttaminen varmuuskopiosta kestää myös kauan, mitä minun pitäisi tehdä? Ymmärrämme, että meidän tapauksessamme joustoa käytetään hakuun. Miten verkkokauppamme myy? Menemme markkinoijien luo ja kysymme, mistä ihmiset yleensä tulevat. He vastaavat: "90% Yandex Marketista tulee suoraan tuotekortille." Ja joko he ostavat sen tai eivät. Siksi 10 % käyttäjistä tarvitsee hakua. Ja elastisen replikoinnin pitämisessä, erityisesti erilaisten datakeskusten välillä eri vyöhykkeillä, on todella paljon vivahteita. Mikä uloskäynti? Otamme kuminauhan varatulta sivustolta emmekä tee sillä mitään. Jos tapaus venyy, saatamme nostaa sen joskus esille, mutta se ei ole varmaa. Itse asiassa johtopäätös on sama, plus tai miinus: emme taaskaan varaa palveluita, jotka eivät vaikuta rahaan. Jotta kaavio olisi yksinkertaisempi.
Esimerkki numero neljä, vielä vaikeampi
Integraattori: kukkien myynti, taksin soittaminen, tavaroiden myynti, yleensä mitä tahansa. Vakava asia, joka toimii 24/7 suurelle määrälle käyttäjiä. Täysin mielenkiintoisella pinolla, jossa on mielenkiintoisia perusteita, ratkaisuja, korkea kuormitus ja mikä tärkeintä, yli 5 minuuttia makuulle sattuu. Ei vain eikä niinkään siksi, että ihmiset eivät osta, vaan koska ihmiset näkevät, että tämä ei toimi, he järkytyvät eivätkä ehkä palaa ollenkaan.
OK. Viisi minuuttia. Mitä aiomme tehdä asialle? Tässä tapauksessa me, kuten aikuiset, käytämme kaikki rahat todellisen varmuuskopiosivuston rakentamiseen, jossa kaikki replikoidaan, ja ehkä jopa automatisoimme siirtymisen tälle sivustolle mahdollisimman paljon. Ja tämän lisäksi sinun tulee muistaa tehdä yksi tärkeä asia: itse asiassa kirjoittaa vaihtosäännöt. Säännöt voivat olla hyvin yksinkertaisia, vaikka kaikki olisi automatisoitu. Sarjoista "suorita sellainen ja sellainen mahdollinen skripti", "klikkaa sellaista ja sellaista valintaruutua reitillä 53" ja niin edelleen - mutta tämän täytyy olla jonkinlainen tarkka toimintoluettelo.
Ja kaikki näyttää selvältä. Replikoinnin vaihtaminen on triviaali tehtävä, tai se vaihtuu itsestään. Verkkotunnuksen uudelleenkirjoittaminen DNS:ssä on samasta sarjasta. Ongelmana on, että kun tällainen projekti epäonnistuu, paniikki alkaa, ja jopa vahvimmat, parrakkaat ylläpitäjät voivat olla alttiita sille. Ilman selkeitä ohjeita "avaa pääte, tule tänne, palvelimemme osoite on edelleen tällainen", on vaikea täyttää elvytykselle varattua 5 minuutin aikarajaa. No, plus, kun käytämme näitä määräyksiä, on helppo kirjata esimerkiksi infrastruktuuriin muutoksia ja muuttaa määräyksiä sen mukaan.
No, jos varausjärjestelmä on erittäin monimutkainen ja jossain vaiheessa teimme virheen, voimme tuhota varmuuskopiosivustomme ja lisäksi muuttaa tiedot kurpitsaksi molemmilla sivustoilla - tämä on täysin surullista.
Esimerkki numero viisi, täydellinen hardcore
Kansainvälinen palvelu, jolla on satoja miljoonia käyttäjiä ympäri maailmaa. Kaikki aikavyöhykkeet ovat, suuri kuorma maksiminopeudella, et voi makuulla ollenkaan. Minuutti - ja se on surullista. Mitä tehdä? Varaa jälleen koko ohjelman mukaan. Teimme kaiken, mistä puhuin edellisessä esimerkissä, ja vähän enemmänkin. Ihanteellinen maailma, ja infrastruktuurimme on kaikkien IaaC devops -käsitteiden mukainen. Eli kaikki on gitissä, ja painat vain painiketta.
Mitä puuttuu? Yksi - harjoitukset. Se on mahdotonta ilman niitä. Meillä näyttää siltä, että kaikki on täydellistä, meillä on yleensä kaikki hallinnassa. Painamme nappia, kaikki tapahtuu. Vaikka näin olisikin - ja ymmärrämme, että näin ei tapahdu - järjestelmämme on vuorovaikutuksessa joidenkin muiden järjestelmien kanssa. Tämä on esimerkiksi dns reitiltä 53, s3-tallennus, integrointi johonkin api:iin. Emme voi ennakoida kaikkea tässä spekulatiivisessa kokeilussa. Ja ennen kuin vedämme kytkimestä, emme tiedä, toimiiko se vai ei.
Siinä varmaan kaikki. Älä ole laiska tai liioittele sitä. Ja käyttöaika voi olla kanssasi!
Lähde: will.com