Ovaj članak sadrži neke uobičajene obrasce koji pomažu inženjerima u radu s velikim uslugama kojima pristupaju milijuni korisnika.
Prema autorovom iskustvu, ovo nije iscrpan popis, ali jest djelotvoran savjet. Dakle, počnimo.
Prevedeno uz podršku .
Razina upisa
Dolje navedene mjere relativno su jednostavne za provedbu, ali imaju visok učinak. Ako ih dosad niste isprobali, iznenadit ćete se značajnim poboljšanjima.
Infrastruktura kao šifra
Prvi dio savjeta je implementacija infrastrukture kao koda. To znači da morate imati programski način za implementaciju cijele infrastrukture. Zvuči komplicirano, ali zapravo govorimo o sljedećem kodu:
Postavljanje 100 virtualnih strojeva
- s Ubuntuom
- 2 GB RAM-a svaki
- oni će imati sljedeći kod
- s ovim parametrima
Možete pratiti promjene svoje infrastrukture i brzo se vratiti na njih pomoću kontrole verzija.
Modernist u meni kaže da možete koristiti Kubernetes/Docker za sve gore navedeno i u pravu je.
Osim toga, možete osigurati automatizaciju koristeći Chef, Puppet ili Terraform.
Kontinuirana integracija i isporuka
Za stvaranje skalabilne usluge važno je imati cjevovod za izgradnju i testiranje za svaki zahtjev za povlačenjem. Čak i ako je test vrlo jednostavan, barem će osigurati da se kod koji implementirate kompajlira.
Svaki put u ovoj fazi odgovorite na pitanje: hoće li moj sklop kompilirati i proći testove, je li valjan? Ovo se može činiti kao niska letvica, ali rješava mnogo problema.
Nema ništa ljepše nego vidjeti ove krpelje
Za ovu tehnologiju možete procijeniti Github, CircleCI ili Jenkins.
Balanceri opterećenja
Dakle, želimo pokrenuti balanser opterećenja za preusmjeravanje prometa i osiguranje jednakog opterećenja na svim čvorovima ili se usluga nastavlja u slučaju kvara:
Uravnoteživač opterećenja obično dobro raspoređuje promet. Najbolja praksa je prevladati tako da nemate nijednu točku kvara.
U pravilu se balanseri opterećenja konfiguriraju u oblaku koji koristite.
RayID, ID korelacije ili UUID za zahtjeve
Jeste li ikada naišli na pogrešku aplikacije s porukom poput ove: "Nešto je pošlo po zlu. Spremite ovaj ID i pošaljite ga našem timu za podršku"?
Jedinstveni identifikator, korelacijski ID, RayID ili bilo koja od varijacija jedinstveni je identifikator koji vam omogućuje praćenje zahtjeva tijekom njegovog životnog ciklusa. To vam omogućuje praćenje cijelog puta zahtjeva u zapisima.
Korisnik postavlja zahtjev sustavu A, zatim A kontaktira B, koji kontaktira C, pohranjuje ga u X i zatim se zahtjev vraća A
Kad biste se daljinski povezali s virtualnim strojevima i pokušali pratiti putanju zahtjeva (i ručno povezati koji se pozivi upućuju), poludjeli biste. Imati jedinstveni identifikator čini život mnogo lakšim. Ovo je jedna od najjednostavnijih stvari koje možete učiniti kako biste uštedjeli vrijeme kako vaša usluga raste.
Srednja razina
Ovdje su savjeti složeniji od prethodnih, ali pravi alati olakšavaju zadatak, osiguravajući povrat ulaganja čak i malim i srednjim tvrtkama.
Centralizirano evidentiranje
Čestitamo! Postavili ste 100 virtualnih strojeva. Sljedeći dan dolazi CEO i žali se na pogrešku koju je dobio tijekom testiranja usluge. Prijavljuje odgovarajući ID o kojem smo govorili gore, ali morat ćete pregledati zapise 100 strojeva kako biste pronašli onaj koji je uzrokovao rušenje. I treba ga pronaći prije sutrašnje prezentacije.
Iako ovo zvuči kao zabavna avantura, najbolje je pobrinuti se da imate mogućnost pretraživanja svih časopisa na jednom mjestu. Riješio sam problem centraliziranja dnevnika pomoću ugrađene funkcije ELK stoga: on podržava pretraživo prikupljanje dnevnika. To će stvarno pomoći u rješavanju problema pronalaska određenog časopisa. Kao bonus, možete stvarati grafikone i druge slične stvari.
ELK stack funkcionalnost
Agenti za praćenje
Sada kada je vaša usluga pokrenuta, morate se pobrinuti da radi glatko. Najbolji način da to učinite je pokrenuti nekoliko agenti, koji rade paralelno i provjeravaju radi li i izvode li se osnovne operacije.
U ovom trenutku to provjerite radna konstrukcija je dobra i dobro radi.
Za male do srednje velike projekte preporučujem Postman za praćenje i dokumentiranje API-ja. Ali općenito, samo želite biti sigurni da imate način da znate kada je došlo do prekida rada i da budete pravovremeno obaviješteni.
Automatsko skaliranje ovisno o opterećenju
Vrlo je jednostavno. Ako imate zahtjeve za servisiranjem VM-a i on se približava 80% upotrebe memorije, možete povećati njegove resurse ili dodati više VM-ova u klaster. Automatsko izvođenje ovih operacija izvrsno je za elastične promjene snage pod opterećenjem. Ali uvijek morate paziti koliko novca trošite i postaviti razumna ograničenja.
Kod većine usluga u oblaku možete ga konfigurirati za automatsko skaliranje pomoću više poslužitelja ili moćnijih poslužitelja.
Sustav pokusa
Dobar način za sigurno uvođenje ažuriranja je mogućnost testiranja nečega za 1% korisnika na sat vremena. Vi ste, naravno, vidjeli takve mehanizme na djelu. Na primjer, Facebook prikazuje dijelove publike drugom bojom ili mijenja veličinu fonta kako bi vidio kako korisnici percipiraju promjene. To se zove A/B testiranje.
Čak se i izdavanje nove značajke može započeti kao eksperiment, a zatim odrediti kako je objaviti. Također dobivate mogućnost "zapamćivanja" ili promjene konfiguracije u hodu na temelju funkcije koja uzrokuje degradaciju vaše usluge.
Napredna razina
Evo savjeta koje je prilično teško provesti. Vjerojatno će vam trebati malo više resursa, pa će mala ili srednja tvrtka to teško snaći.
Plavo-zeleni rasporedi
To je ono što ja zovem "Erlang" način odvijanja. Erlang je postao široko korišten kada su se pojavile telefonske kompanije. Softswitchevi su se počeli koristiti za usmjeravanje telefonskih poziva. Glavna svrha softvera na ovim preklopnicima bila je ne prekidati pozive tijekom nadogradnje sustava. Erlang ima lijep način učitavanja novog modula bez rušenja prethodnog.
Ovaj korak ovisi o prisutnosti balansera opterećenja. Zamislimo da imate verziju N svog softvera, a zatim želite implementirati verziju N+1.
Vi mogli bismo samo zaustavite uslugu i izbacite sljedeću verziju u vrijeme koje odgovara vašim korisnicima i ostvarite neko vrijeme zastoja. Ali pretpostavimo da imate stvarno strogi SLA uvjeti. Dakle, SLA 99,99% znači da možete otići izvan mreže samo za 52 minute godišnje.
Ako stvarno želite postići takve pokazatelje, potrebne su vam dvije implementacije u isto vrijeme:
- onaj koji je upravo sada (N);
- sljedeća verzija (N+1).
Kažete balanseru opterećenja da preusmjeri postotak prometa na novu verziju (N+1) dok vi aktivno pratite regresije.
Ovdje imamo implementaciju zelenog N koja dobro radi. Pokušavamo prijeći na sljedeću verziju ove implementacije
Prvo šaljemo stvarno mali test da vidimo funkcionira li naša N+1 implementacija s malom količinom prometa:
Konačno, imamo skup automatiziranih provjera koje na kraju pokrećemo dok se naša implementacija ne završi. Ako ti jako jako oprezno, također možete zauvijek spremiti svoju N implementaciju za brzo vraćanje unatrag u slučaju loše regresije:
Ako želite prijeći na još napredniju razinu, pustite da se sve u plavo-zelenoj implementaciji pokreće automatski.
Otkrivanje anomalija i automatsko ublažavanje
S obzirom na to da imate centralizirano evidentiranje i dobro prikupljanje dnevnika, već sada možete postavljati veće ciljeve. Na primjer, proaktivno predviđajte neuspjehe. Funkcije se prate na monitorima i u zapisima i izrađuju se razni dijagrami - i možete unaprijed predvidjeti što će poći po zlu:
Nakon što se otkriju anomalije, počinjete ispitivati neke od tragova koje pruža usluga. Na primjer, skok u opterećenju CPU-a može značiti da je tvrdi disk u kvaru, dok skok u zahtjevima može značiti da trebate povećati. Ova vrsta statističkih podataka omogućuje vam da uslugu učinite proaktivnom.
S ovim uvidima možete skalirati bilo koju dimenziju i proaktivno i reaktivno mijenjati karakteristike strojeva, baza podataka, veza i drugih resursa.
To je sve!
Ova lista prioriteta će vas spasiti od mnogih problema ako podižete uslugu u oblaku.
Autor izvornog članka poziva čitatelje da ostave svoje komentare i unesu izmjene. Članak se distribuira kao open source, zahtjev za povlačenjem autora .
Što još pročitati na temu:
Izvor: www.habr.com