Denne artikel indeholder nogle almindelige mønstre, der hjælper ingeniører med at arbejde med tjenester i stor skala, som millioner af brugere har adgang til.
Efter forfatterens erfaring er dette ikke en udtømmende liste, men faktisk effektiv råd. Så lad os begynde.
Oversat med støtte .
Første niveau
Foranstaltningerne nedenfor er relativt enkle at implementere, men har stor effekt. Hvis du ikke har prøvet dem før, vil du blive overrasket over de betydelige forbedringer.
Infrastruktur som kode
Den første del af rådgivningen er at implementere infrastruktur som kode. Det betyder, at du skal have en programmatisk måde at implementere hele infrastrukturen på. Det lyder kompliceret, men vi taler faktisk om følgende kode:
Udrulning af 100 virtuelle maskiner
- med Ubuntu
- 2 GB RAM hver
- de vil have følgende kode
- med disse parametre
Du kan spore ændringer i din infrastruktur og hurtigt vende tilbage til dem ved hjælp af versionskontrol.
Modernisten i mig siger, at du kan bruge Kubernetes/Docker til at gøre alt det ovenstående, og han har ret.
Derudover kan du sørge for automatisering ved hjælp af Chef, Puppet eller Terraform.
Kontinuerlig integration og levering
For at skabe en skalerbar service er det vigtigt at have en build- og testpipeline for hver pull-anmodning. Selvom testen er meget enkel, vil den i det mindste sikre, at den kode, du installerer, kompilerer.
Hver gang på dette trin svarer du på spørgsmålet: vil min samling kompilere og bestå tests, er den gyldig? Dette kan virke som en lav bar, men det løser en masse problemer.
Der er ikke noget smukkere end at se disse flåter
For denne teknologi kan du evaluere Github, CircleCI eller Jenkins.
Load Balancers
Så vi ønsker at køre en belastningsbalancer for at omdirigere trafik og sikre lige belastning på alle noder, ellers fortsætter tjenesten i tilfælde af fejl:
En load balancer gør normalt et godt stykke arbejde med at fordele trafikken. Den bedste praksis er at overbalancere, så du ikke har et eneste fejlpunkt.
Typisk er load balancers konfigureret i den sky, du bruger.
RayID, korrelations-ID eller UUID for anmodninger
Har du nogensinde stødt på en applikationsfejl med en meddelelse som denne: "Noget gik galt. Gem dette id og send det til vores supportteam"?
En unik identifikator, korrelations-id, RayID eller en hvilken som helst af variationerne er en unik identifikator, der giver dig mulighed for at spore en anmodning gennem dens livscyklus. Dette giver dig mulighed for at spore hele anmodningsstien i loggene.
Brugeren laver en anmodning til system A, derefter kontakter A B, som kontakter C, gemmer den i X, og derefter returneres anmodningen til A
Hvis du fjernopretter forbindelse til virtuelle maskiner og prøver at spore anmodningsstien (og manuelt korrelerer, hvilke opkald der foretages), ville du blive skør. At have en unik identifikator gør livet meget lettere. Dette er en af de enkleste ting, du kan gøre for at spare tid, efterhånden som din service vokser.
Gennemsnitligt niveau
Rådgivningen her er mere kompleks end de tidligere, men de rigtige værktøjer gør opgaven nemmere og giver et investeringsafkast selv for små og mellemstore virksomheder.
Centraliseret logning
Tillykke! Du har installeret 100 virtuelle maskiner. Dagen efter kommer den administrerende direktør og klager over en fejl, han har modtaget, mens han testede tjenesten. Det rapporterer det tilsvarende ID, vi talte om ovenfor, men du bliver nødt til at kigge gennem loggene på 100 maskiner for at finde den, der forårsagede nedbruddet. Og den skal findes inden morgendagens præsentation.
Selvom dette lyder som et sjovt eventyr, er det bedst at sørge for, at du har mulighed for at søge i alle magasiner ét sted. Jeg løste problemet med at centralisere logfiler ved hjælp af den indbyggede funktionalitet i ELK-stakken: den understøtter søgbar logindsamling. Dette vil virkelig hjælpe med at løse problemet med at finde en bestemt journal. Som en bonus kan du lave diagrammer og lignende sjove ting.
ELK stack funktionalitet
Overvågningsagenter
Nu hvor din tjeneste er oppe at køre, skal du sørge for, at den kører problemfrit. Den bedste måde at gøre dette på er at køre flere agenter, som arbejder parallelt og kontrollerer, at det virker, og grundlæggende operationer udføres.
På dette tidspunkt tjekker du det løbebygningen føles god og fungerer fint.
Til små til mellemstore projekter anbefaler jeg Postman til overvågning og dokumentation af API'er. Men generelt vil du bare sikre dig, at du har en måde at vide, hvornår der er opstået en fejl, og få besked i tide.
Autoskalering afhængig af belastning
Det er meget enkelt. Hvis du har en VM-serviceanmodning, og den nærmer sig 80 % hukommelsesforbrug, kan du enten øge dens ressourcer eller tilføje flere VM'er til klyngen. Automatisk udførelse af disse operationer er fremragende til elastiske kraftændringer under belastning. Men du skal altid være forsigtig med, hvor mange penge du bruger og sætte rimelige grænser.
Med de fleste cloud-tjenester kan du konfigurere den til automatisk skalering ved hjælp af flere servere eller mere kraftfulde servere.
Eksperiment system
En god måde at udrulle opdateringer sikkert på er at kunne teste noget for 1 % af brugerne i en time. Du har selvfølgelig set sådanne mekanismer i aktion. For eksempel viser Facebook dele af publikum en anden farve eller ændrer skriftstørrelsen for at se, hvordan brugerne opfatter ændringerne. Dette kaldes A/B-test.
Selv frigivelse af en ny funktion kan startes som et eksperiment og derefter bestemme, hvordan den skal frigives. Du får også muligheden for at "huske" eller ændre konfigurationen med det samme baseret på den funktion, der forårsager forringelse af din tjeneste.
Avanceret niveau
Her er tips, der er ret svære at implementere. Du skal nok bruge lidt flere ressourcer, så en lille eller mellemstor virksomhed vil have svært ved at styre dette.
Blå-grønne udrulninger
Det er det, jeg kalder "Erlang" måden at udfolde sig på. Erlang blev meget brugt, da telefonselskaber dukkede op. Softswitches begyndte at blive brugt til at dirigere telefonopkald. Hovedformålet med softwaren på disse switches var ikke at droppe opkald under systemopgraderinger. Erlang har en god måde at indlæse et nyt modul på uden at crashe det forrige.
Dette trin afhænger af tilstedeværelsen af en belastningsbalancer. Lad os forestille os, at du har version N af din software, og så vil du implementere version N+1.
Du vi kunne bare stop tjenesten og udrul den næste version på et tidspunkt, der fungerer for dine brugere, og få lidt nedetid. Men antag at du har virkelig strenge SLA-betingelser. Så SLA 99,99% betyder, at du kan gå offline kun med 52 minutter om året.
Hvis du virkelig ønsker at opnå sådanne indikatorer, har du brug for to implementeringer på samme tid:
- den, der er lige nu (N);
- næste version (N+1).
Du fortæller load balanceren at omdirigere en procentdel af trafikken til den nye version (N+1), mens du aktivt overvåger for regression.
Her har vi en grøn N-installation, der fungerer fint. Vi forsøger at flytte til den næste version af denne implementering
Først sender vi en virkelig lille test for at se, om vores N+1-implementering fungerer med en lille mængde trafik:
Endelig har vi et sæt automatiske kontroller, som vi til sidst kører, indtil vores implementering er færdig. hvis du meget meget forsigtig, du kan også gemme din N-installation for evigt for en hurtig tilbagerulning i tilfælde af dårlig regression:
Hvis du ønsker at gå til et endnu mere avanceret niveau, så lad alt i den blå-grønne implementering køre automatisk.
Anomalidetektion og automatisk afhjælpning
Da du har centraliseret logning og god logindsamling, kan du allerede nu sætte højere mål. For eksempel proaktivt forudsige fejl. Funktioner spores på skærme og i logs, og der bygges forskellige diagrammer - og du kan på forhånd forudsige, hvad der vil gå galt:
Når der er opdaget uregelmæssigheder, begynder du at undersøge nogle af de spor, som tjenesten giver. For eksempel kan en stigning i CPU-belastning indikere, at en harddisk fejler, mens en stigning i anmodninger kan indikere, at du skal skalere op. Denne form for statistiske data giver dig mulighed for at gøre tjenesten proaktiv.
Med denne indsigt kan du skalere i enhver dimension og proaktivt og reaktivt ændre karakteristika for maskiner, databaser, forbindelser og andre ressourcer.
Det er alt!
Denne liste over prioriteter vil spare dig for mange problemer, hvis du rejser en cloud-tjeneste.
Forfatteren af den originale artikel inviterer læserne til at skrive deres kommentarer og foretage ændringer. Artiklen distribueres som open source, pull-anmodninger fra forfatteren .
Hvad skal man ellers læse om emnet:
Kilde: www.habr.com