Aloitetaan siitä, mitä 4 9’s tarkalleen ottaen tarkoittaa:
Neljä ysiä on 4,38 minuuttia seisokkiaikaa kuukaudessa tai 52,56 minuuttia vuodessa.
Se on luultavasti enemmän kuin hyväksyttävää lähes kaikille internetin palveluille, ei kaikille, mutta lähes kaikille. Eli sähköpostisi on alhaalla 4 minuuttia kuukaudessa, ei mikään maailmanloppu. Tarkoitan, että et luultavasti edes huomaisi. Siihen mennessä, kun menisit tarkistamaan Twitteristä, johtuuko se vain sinusta vai ei, se olisi taas toiminnassa.
Tyypillisesti hyvän käytettävyysajan saamiseksi ajattelemme redundanssin ja replikoinnin lisäämistä niin, että jos jokin palvelin vikaantuu, sinulla on jo käynnissä muita, jotka ottavat välittömästi vastuun. Ongelmana tässä lähestymistavassa on, että se on monimutkainen ja kallis. Tarvitset useita palvelimia, yleensä kolme tai enemmän sekä sovellusta että tietokantaa varten, ja lisäksi tarvitset kuorman tasaajan niiden eteen. Ja sitten sinun on hallittava/valvottava kaikkia näitä koneita.
Ja uuden mikropalvelutrendin myötä, jossa ihmiset pilkkovat sovelluksensa pienempiin palveluihin, sinun on toistettava nämä monimutkaiset asetukset jokaista palvelua varten.
Jos rakennat mikropalvelua, mitä vähemmän ”tavaraa” tarvitset sen pyörittämiseen, sen parempi. Et kai halua, että joudut asentamaan uuden replikoidun tietokannan joka kerta, kun haluat heittää yhteen pienen API:n? Haluan olla erittäin tuottava, haluan pystyä tuottamaan palvelun nopeasti ilman, että minun tarvitsee käsitellä kaikkia monimutkaisia, aikaa vieviä ops-juttuja.
Sitten aloin miettiä: ”No, entä jos on olemassa keino olla… tarpeeksi luotettava?”. Tarkoitan, kuinka monen rakentamasi asian täytyy oikeasti olla erittäin saatavilla? Kuinka monella palvelulla ei ole varaa olla poissa muutaman minuutin siellä sun täällä tai menettää pieni määrä dataa kerran sinisessä kuussa kohtalokkaan palvelinvian takia?
Arvelen, että ei ole kovin montaa palvelua, jolla ei ole varaa menettää hyvin pientä määrää dataa ja muutaman minuutin seisokkiaikaa vuodessa. Vaikka arkkitehtisitkin palvelusi helvetin hyvin, niin luultavasti alasajoja tulee joka tapauksessa jostain syystä. Miksi ei siis pidettäisi asiaa yksinkertaisena.
Aluksi muutama luku: Sanotaan, että keskimäärin AWS EC2-instanssi vikaantuu kuuden kuukauden välein. Luulen, että se on nykyään paljon vähemmän, mutta kukaan ei oikeasti tiedä, joten olemme konservatiivisia. Meillä on siis noin 26,5 minuuttia aikaa palauttaa sovellus kuuden kuukauden välein ja saada silti 4 9:n käyttöaika.
Tässä kerrotaan, miten saat 4 9:n käyttöajan yhdellä koneella.
Vaihe 1) Käynnistä palvelin, ota sovellus käyttöön ja vaihda DNS-skripti
Aluksi tarvitsemme yksinkertaisen skriptin, jolla voimme käynnistää uuden instanssin, käynnistää sovelluksen (Docker tekee tämän helpoksi) ja vaihtaa DNS:n osoittaaksemme uuteen instanssiin. En aio mennä yksityiskohtaisesti tähän vaiheeseen tässä viestissä, mutta jos voit tehdä yhden rivin skriptin, joka voi tehdä nämä vaiheet, olet hyvä. Service fails: run script.
Vaihe 2) Tietokanta automaattisella varmuuskopioinnilla ja automaattisella palautuksella
Jos pystyt varmistamaan, että sinulla on hyvin tuoreet varmuuskopiot tietokannastasi ja että ne on tallennettu helposti saatavilla olevaan paikkaan, kuten S3:een, voit luoda sovelluksen, joka voi palauttaa itsensä, kun se käynnistyy. Sulautetun tietokannan käyttäminen tekee kaikesta yksinkertaisempaa, koska sinun tarvitsee ottaa käyttöön vain yksi asia: sovelluksesi.
Olen käyttänyt BoltDB:tä paljon viime aikoina, lähinnä siksi, että kirjoitan paljon Go:ta ja Bolt on yksinkertainen sulautettu tietokanta, joka on saatavilla Go-paketissa, jota käytät kuten mitä tahansa muuta riippuvuutta. Sinun ei siis tarvitse käyttää erillistä tietokantaa, johon muodostat yhteyden, ja sinun ei tarvitse huolehtia sen käynnissä pitämisestä. Käytät vain kirjastoa ja tiedot kirjoitetaan paikalliselle levyllesi.
Tässä on myös Boltin ongelma, tiedot ovat vain paikallisella koneellasi sovelluksesi rinnalla. Jos kone vikaantuu, menetät kaiken datasi.
Kuinka olisi, jos tekisit varmuuskopion minuutin tai kahden välein? Ja voisit automaattisesti palauttaa varmuuskopion, kun sovellus käynnistyy?
Olen luonut lib:n, joka tekee juuri tämän, nimeltään Bolt Backup, ja vain muuttamalla BoltDb:n alustusriviä, se tekee automaattisesti varmuuskopion tietokannastasi S3:een ja mikä parasta, kun käynnistät sovelluksen, se palauttaa viimeisimmän varmuuskopion.
Voit testata tätä helposti lisäämällä dataa Bolt-tietokantaan, tappamalla sovelluksen, poistamalla Boltin datatiedoston ja käynnistämällä sovelluksen sitten uudelleen. Se jatkaa siitä, mihin se jäi, riippumatta siitä, mistä käynnistät sovelluksesi uudelleen.
Tässä on tätä käyttävä esimerkkisovellus, jota voit kokeilla: https://github.com/treeder/bolt-backup/tree/master/example
Johtopäätös
Yllä olevilla yksinkertaisilla konsepteilla voit palauttaa sovelluksesi alle 26 minuutissa ja saavuttaa siten 4 9:n tai paremman käytettävyyden. Varmista vain, että kaikki on automatisoitu käynnistysskriptillä ja automaattisella tietokannan palautuksella, kuten edellä mainitulla Bolt Backup -kirjastolla.
Yksinkertaisuuden arvo voi joskus kadota, kun innostumme ”web-asteikosta”, mutta usein voit säästää itseltäsi paljon aikaa ja murhetta, jos pidät asiat yksinkertaisina. Ja paljon rahaa.