Selles artiklis on kogutud mõned üldised mallid, mis aitavad inseneridel hallata laias ulatuses teenuseid, millele esitatakse nõudmisi miljonitelt kasutajatelt.

Autori kogemuse põhjal pole see täielik nimekiri, kuid tõeliselt effektiivne nõuandeid. Alustame.

Tõlgitud toetusel Mail.ru Pilve Lahendused.

Põhitasemel

Allpool loetletud meetmed on suhteliselt lihtsad rakendada, kuid pakuvad kõrget tootlust. kui te pole neid varem rakendanud, siis teile pakuvad tõeliselt suured parandused.

Infrastruktuur kui kood

Esimene nõuanne on rakendada infrastruktuuri koodina. See tähendab, et teil peab olema programmiline viis kogu infrastruktuuri juurutamiseks. See kõlab keeruliselt, kuid tegelikult räägime järgnevast koodist:

100 virtuaalmasina juurutamine

Ubuntu

2 GB RAM-i igaühel

neil on järgmine kood

selliste parameetritega

Saate jälgida infrastruktuuri muudatusi ja kiiresti sellele tagasi pöörduda versioonihalduse süsteemi abil.

Modernaist minus ütleb, et Kubernetes/Dockerit on võimalik kasutada, et teha kõik eelnevalt loetletud, ja ta on õige.

Lisaks automatiseerimist saab tagada Chef, Puppet või Terraform abil.

Pidev integreerimine ja kohaletoimetamine

Mastaapsete teenuste loomiseks on oluline, et iga pull req'i jaoks oleks olemas koostamis- ja testimissegment. Isegi kui test on kõige lihtsam, garanteerib see vähemalt, et kood, mida te juurutate, kompileerub.

Igal korral selles etapis vastate küsimusele: kas minu koostamine kompileerub ja läbib teste, kas see on kehtiv? See võib tunduda madalal tasemel, kuid lahendab palju probleeme.

Pole midagi imelisemat, kui näha neid linnukesi

Selle tehnoloogia jaoks võite uurida Githubi, CircleCI või Jenkinsit.

Laadimisbalansseerijad

Nii et soovime käivitada laadimisbalansseerija, et suunata liiklust ja tagada ühtlane koormus kõigil sõlmedel või teenuse töö tõrgete korral:

Laadimisbalansseerija aitab tavaliselt hästi liiklust jaotada. Parimaks praktikaks on ülemäärane balansseerimine, et vältida ainsat tõrke punkti.

Tavaliselt seadistatakse laadimisbalansseerijad seal, kus te oma pilve kasutate.

RayID, korrelatsiooni ID või UUID päringute jaoks

Kas oled kunagi kohanud rakenduse tõrget, mille sõnum kõlab umbes nii: «Midagi läks valesti. Palun salvesta see id ja saada see meie tugiteenusele»?

Unikaalne identifikaator, correlation ID, RayID või ükskõik milline variant – see on unikaalne identifikaator, mis võimaldab jälgida päringut selle elutsükli jooksul. See võimaldab jälgida kogu päringu teed logides.

Kasutaja teeb päringu süsteemile A, seejärel A suhtleb B-ga, B suhtleb C-ga, salvestab X-sse ja seejärel naaseb päring A-le.

Kui sa ühenduksid kaugjuhtimise teel virtuaalmasinatele ja prooviksid jälgida päringu teekonda (ning käsitsi seostada, millised kutse kutsed toimuvad), siis läheks see sul hulluks. Unikaalse identifikaatori olemasolu lihtsustab elu oluliselt. See on üks lihtsamaid asju, mida teha, et säästa aega teenuse arengu jooksul.

Keskmine tase

Siin on nõuanded keerulisemad kui eelnevad, kuid õiged tööriistad muudavad ülesande lihtsamaks, tagades investeeringute tasuvuse isegi väikestes ja keskmistes ettevõtetes.

Keskne logimine

Palju õnne! Olete käivitanud 100 virtuaalmasinat. Järgmine päev tuleb tegevjuht ja kurdab tõrke üle, mille ta sai teenuse testimise ajal. Ta teatab vastavast identifikaatorist, millest me varem rääkisime, kuid peate vaatama logisid 100 masinast, et leida see, mis viga põhjustas. Ja seda tuleb leida enne homset esitlust.

Kuigi see kõlab nagu naljakas seiklus, on siiski parem veenduda, et teil on võimalus otsida kõigist logidest ühest kohast. Otsustasin probleemiks logide tsentraliseerimise ELK stack'i sisseehitatud funktsionaalsuse abil: siin toetatakse logide kogumist otsitavaks. See tõesti aitab lahendada konkreetse logi otsimise probleemi. Boonusena saate luua diagramme ja muid toredaid asju.

ELK stack'i funktsionaalsus

Jälgimisagendid

Nüüd, kui teie teenus on tööle pandud, peate veenduma, et see töötab tõrgeteta. Parim viis selleks on käivitada mitu agent, mis töötavad paralleelselt ja jälgivad, et see töötab ja et põhitegevused on täidetud.

Selles etapis kontrollite, et Käivitamiseks mõeldud koostamine töötab hästi ja toimib normaalselt.

Väikeste ja keskmise suurusega projektide puhul soovitan Postmanit API jälgimiseks ja dokumenteerimiseks. Kuid põhimõtteliselt peaksite lihtsalt veenduma, et teil on võimalus teada saada, kui ebaõnnestumine on toimunud, ja saada õigeaegne teavitus.

Automaatne skaleerimine sõltuvalt koormusest

See on väga lihtne. Kui teil on virtuaalmasin, mis teenindab päringuid ja see läheneb 80% mälu täitumise piirile, saate kas suurendada selle ressursse või lisada klastrisse rohkem virtuaalmasinaid. Nende toimingute automaatne teostamine sobib suurepäraselt paindlikuks ressursside muutmiseks koormuse ajal. Kuid peate alati olema ettevaatlik, kui palju raha kulutate, ja seadma mõistlikud piirangud.

Enamikus pilveteenustes saate automaatse skaleerimise seadistada, kasutades rohkem servereid või võimsamaid servereid.

Eksperimentide süsteem

Hea viis uuenduste turvaliseks juurutamiseks on võimalus testida midagi 1% kasutajatelt tunni jooksul. Olete kindlasti näinud selliseid mehhanisme tegutsemas. Näiteks Facebook näitab teatud osa publikust erinevat värvi või muudab fondi suurust, et näha, kuidas kasutajad muudatusi tajuvad. Seda nimetatakse A/B-testimiseks.

Isegi uue funktsiooni käivitamine võib toimuda eksperimendina ja seejärel saab määrata, kuidas seda välja anda. Samuti saate võimaluse „tagasi võtta“ või konfigureerida muuta lennult, arvestades funktsiooni, mis põhjustab teie teenuse halvenemist.

Edasijõudnud tase

Siin on nõuanded, mida on üsna raske teostada. Tõenäoliselt vajate veidi rohkem ressursse, seega on väikese või keskmise suurusega ettevõtte jaoks keeruline sellega toime tulla.

Sinine-roheline juurutamine

See on see, mida ma nimetan „Erlangi” juurutamiseks. Erlangi hakati laialdaselt kasutama, kui tekkisid telefonifirmad. Telefonikõnede marsruutimiseks hakati kasutama tarkvara lüliteid. Peamine ülesanne nende lülitite tarkvaral oli vältida kõnede katkestamist süsteemi uuendamise ajal. Erlangil on suurepärane viis uue mooduli laadimiseks ilma varasema kokkukukkumiseta.

See sammumine sõltub koormuse tasakaalustajast. Oletame, et teil on teie tarkvara versioon N ja siis soovite juurutada versiooni N+1.

Te saaksid lihtsalt peatada teenuse ja juurutada järgmise versiooni sellisel ajal, nagu arvate, et see sobib teie kasutajatele, ja получить небольшое время простоя. Aga oletame, et teil on tõeliselt rangelt SLA tingimused. Niisiis, SLA 99,99% tähendab, et võite olla offline seda 52 minutit aastas.

Kui soovite tõeliselt selliseid näitajaid saavutada, on vaja kahte juurutust samaaegselt:

see, mis on praegu (N);
järgmine versioon (N+1).

Te määrate koormuse tasakaalustajale, et suunata teatud protsent liiklusest uuele versioonile (N+1), samal ajal kui te aktiivselt jälgite regressioone.

Siin on meil roheline juurutus N, mis töötab korralikult. Proovime liikuda selle juurutuse järgmise versiooni juurde

Esiteks saadame tõeliselt väikese testi, et näha, kas meie juurutus N+1 töötab väikese liiklusega:

Lõpuks on meil rida automaatseid kiểmimisi, mida me lõpuks käivitame, kuni meie juurutamine on lõpetatud. Kui olete väga-väga ettevaatlik, võite ka hoida oma juurutust N igavesti kiireks tagasiviimiseks halva regressiooni korral:

Kui soovite minna veelgi kõrgemale tasemele, laske kõik sinise-roheline juurutuses toimuda automaatselt.

Aneomaliade tuvastamine ja automaatne leevendamine

Arvestades, et teil on tsentraliseeritud logimine ja hea logide kogumine, on juba võimalik seada kõrgemaid eesmärke. Näiteks proaktiivselt ennustada tõrkeid. Monitorides ja logides jälgitakse funktsioone ning koostatakse erinevaid diagramme - ja saate ette ennustada, mis võib valesti minna:

Aneomaliade tuvastamise abil hakkate uurima mõningaid vihjeid, mida teenus annab. Näiteks CPU koormuse tõus võib märku anda, et kõvakettas läheb katki, ja päringute arvu tõus tähendab, et on vaja skaleeruda. Sellised statistilised andmed aitavad teenust proaktiivseks muuta.

Saades selliseid analüütilisi andmeid saate skalata igas mõõtmes, proaktiivselt ja reaktiivselt muuta masinate, andmebaaside, ühenduste ja teiste ressursside omadusi.

Ja kõik!

See prioriteetide nimekiri vabastab teid paljusid probleeme, kui võtate kasutusele pilveteenuse.

Algse artikli autor kutsub lugejaid jätma oma kommentaare ja tegema muudatusi. Artikkel levib avatud lähtekoodiga, autor aktsepteerib tõmbeavaldusi GitHubis. Go ja CPU vahemälud.

Mis veel teemaga seoses lugeda:

Allikas: habr.com