Denne artikkelen inneholder noen vanlige mønstre for å hjelpe ingeniører med å jobbe med tjenester i stor skala som er tilgang til av millioner av brukere.
Etter forfatterens erfaring er ikke dette en uttømmende liste, men faktisk effektiv råd. Så la oss begynne.
Oversatt med støtte .
Første nivå
Tiltakene nedenfor er relativt enkle å implementere, men har stor effekt. Hvis du ikke har prøvd dem før, vil du bli overrasket over de betydelige forbedringene.
Infrastruktur som kode
Den første delen av rådet er å implementere infrastruktur som kode. Dette betyr at du må ha en programmatisk måte å distribuere hele infrastrukturen på. Det høres komplisert ut, men vi snakker faktisk om følgende kode:
Utplassering av 100 virtuelle maskiner
- med Ubuntu
- 2 GB RAM hver
- de vil ha følgende kode
- med disse parameterne
Du kan spore endringer i infrastrukturen din og raskt gå tilbake til dem ved hjelp av versjonskontroll.
Modernisten i meg sier at du kan bruke Kubernetes/Docker til å gjøre alt ovenfor, og han har rett.
I tillegg kan du sørge for automatisering ved hjelp av Chef, Puppet eller Terraform.
Kontinuerlig integrasjon og levering
For å lage en skalerbar tjeneste er det viktig å ha en bygge- og testpipeline for hver pull-forespørsel. Selv om testen er veldig enkel, vil den i det minste sikre at koden du distribuerer kompilerer.
Hver gang på dette stadiet svarer du på spørsmålet: vil forsamlingen min kompilere og bestå tester, er den gyldig? Dette kan virke som en lav bar, men det løser mange problemer.
Det er ingenting vakrere enn å se disse flåttene
For denne teknologien kan du evaluere Github, CircleCI eller Jenkins.
Lastbalansere
Så vi ønsker å kjøre en lastbalanser for å omdirigere trafikk og sikre lik belastning på alle noder, ellers fortsetter tjenesten i tilfelle feil:
En lastbalanser gjør vanligvis en god jobb med å distribuere trafikk. Den beste praksisen er å overbalansere slik at du ikke har et eneste feilpunkt.
Vanligvis er lastbalansere konfigurert i skyen du bruker.
RayID, korrelasjons-ID eller UUID for forespørsler
Har du noen gang støtt på en applikasjonsfeil med en melding som denne: "Noe gikk galt. Lagre denne ID-en og send den til vårt supportteam"?
En unik identifikator, korrelasjons-ID, RayID eller hvilken som helst av variantene, er en unik identifikator som lar deg spore en forespørsel gjennom hele livssyklusen. Dette lar deg spore hele forespørselsbanen i loggene.
Brukeren sender en forespørsel til system A, deretter kontakter A B, som kontakter C, lagrer den i X, og deretter returneres forespørselen til A
Hvis du eksternt kobler deg til virtuelle maskiner og prøver å spore forespørselsbanen (og manuelt korrelerer hvilke samtaler som blir foretatt), ville du blitt gal. Å ha en unik identifikator gjør livet mye enklere. Dette er en av de enkleste tingene du kan gjøre for å spare tid etter hvert som tjenesten din vokser.
Gjennomsnittlig nivå
Rådene her er mer komplekse enn de tidligere, men de riktige verktøyene gjør oppgaven enklere, og gir avkastning på investeringen selv for små og mellomstore bedrifter.
Sentralisert logging
Gratulerer! Du har distribuert 100 virtuelle maskiner. Dagen etter kommer administrerende direktør og klager på en feil han fikk under testing av tjenesten. Den rapporterer den tilsvarende IDen vi snakket om ovenfor, men du må se gjennom loggene til 100 maskiner for å finne den som forårsaket krasjet. Og den må finnes før morgendagens presentasjon.
Selv om dette høres ut som et morsomt eventyr, er det best å sørge for at du har muligheten til å søke i alle bladene på ett sted. Jeg løste problemet med å sentralisere logger ved å bruke den innebygde funksjonaliteten til ELK-stakken: den støtter søkbar loggsamling. Dette vil virkelig bidra til å løse problemet med å finne en bestemt journal. Som en bonus kan du lage diagrammer og andre morsomme ting.
ELK stack funksjonalitet
Overvåkingsagenter
Nå som tjenesten din er oppe og går, må du sørge for at den fungerer problemfritt. Den beste måten å gjøre dette på er å kjøre flere agenter, som jobber parallelt og kontrollerer at det fungerer og grunnleggende operasjoner utføres.
På dette tidspunktet sjekker du det løpekonstruksjonen føles bra og fungerer bra.
For små til mellomstore prosjekter anbefaler jeg Postman for overvåking og dokumentering av APIer. Men generelt vil du bare sørge for at du har en måte å vite når et strømbrudd har oppstått og bli varslet i tide.
Autoskalering avhengig av belastning
Det er veldig enkelt. Hvis du har en VM-serviceforespørsler og den nærmer seg 80 % minnebruk, kan du enten øke ressursene eller legge til flere VM-er i klyngen. Automatisk utførelse av disse operasjonene er utmerket for elastiske kraftendringer under belastning. Men du bør alltid være forsiktig med hvor mye penger du bruker og sette rimelige grenser.
Med de fleste skytjenester kan du konfigurere den til å autoskalere ved å bruke flere servere eller kraftigere servere.
Eksperimentsystem
En god måte å trygt rulle ut oppdateringer er å kunne teste noe for 1 % av brukerne i en time. Du har selvfølgelig sett slike mekanismer i aksjon. For eksempel viser Facebook deler av publikum en annen farge eller endrer skriftstørrelsen for å se hvordan brukerne oppfatter endringene. Dette kalles A/B-testing.
Til og med frigjøring av en ny funksjon kan startes som et eksperiment og deretter bestemme hvordan den skal utgis. Du får også muligheten til å "huske" eller endre konfigurasjonen med en gang basert på funksjonen som forårsaker forringelse av tjenesten din.
Avansert nivå
Her er tips som er ganske vanskelige å implementere. Du trenger nok litt mer ressurser, så en liten eller mellomstor bedrift vil ha vanskelig for å klare dette.
Blågrønne utplasseringer
Det er dette jeg kaller «Erlang»-måten å utfolde seg på. Erlang ble mye brukt da telefonselskaper dukket opp. Softswitcher begynte å bli brukt til å rute telefonsamtaler. Hovedformålet med programvaren på disse bryterne var å ikke slippe anrop under systemoppgraderinger. Erlang har en fin måte å laste inn en ny modul uten å krasje den forrige.
Dette trinnet avhenger av tilstedeværelsen av en lastbalanser. La oss forestille oss at du har versjon N av programvaren din, og så vil du distribuere versjon N+1.
Du vi kunne bare stopp tjenesten og rull ut neste versjon på et tidspunkt som fungerer for brukerne dine og få litt nedetid. Men anta at du har virkelig strenge SLA-betingelser. Så SLA 99,99% betyr at du kan gå offline bare med 52 minutter per år.
Hvis du virkelig ønsker å oppnå slike indikatorer, trenger du to distribusjoner samtidig:
- den som er akkurat nå (N);
- neste versjon (N+1).
Du ber lastbalanseren omdirigere en prosentandel av trafikken til den nye versjonen (N+1) mens du aktivt overvåker for regresjoner.
Her har vi en grønn N-distribusjon som fungerer fint. Vi prøver å gå til neste versjon av denne distribusjonen
Først sender vi en veldig liten test for å se om N+1-distribusjonen vår fungerer med en liten mengde trafikk:
Til slutt har vi et sett med automatiserte kontroller som vi til slutt kjører til implementeringen vår er fullført. Hvis du veldig veldig forsiktig, du kan også lagre N-distribusjonen for alltid for en rask tilbakeføring i tilfelle dårlig regresjon:
Hvis du vil gå til et enda mer avansert nivå, la alt i den blågrønne distribusjonen kjøre automatisk.
Oppdagelse av anomalier og automatisk avbøting
Gitt at du har sentralisert logging og god loggsamling, kan du allerede sette høyere mål. For eksempel proaktivt forutsi feil. Funksjoner spores på monitorer og i logger og ulike diagrammer bygges – og du kan forutsi på forhånd hva som vil gå galt:
Når uregelmessigheter er oppdaget, begynner du å undersøke noen av ledetrådene som tjenesten gir. For eksempel kan en økning i CPU-belastning indikere at en harddisk svikter, mens en økning i forespørsler kan indikere at du må skalere opp. Denne typen statistiske data lar deg gjøre tjenesten proaktiv.
Med denne innsikten kan du skalere i alle dimensjoner og proaktivt og reaktivt endre egenskapene til maskiner, databaser, tilkoblinger og andre ressurser.
Det er alt!
Denne listen over prioriteringer vil spare deg for mange problemer hvis du driver en skytjeneste.
Forfatteren av den originale artikkelen inviterer leserne til å legge igjen kommentarer og gjøre endringer. Artikkelen er distribuert som åpen kildekode, pull-forespørsler fra forfatteren .
Hva annet å lese om emnet:
Kilde: www.habr.com