Denna artikel innehåller några allmänna mallar som hjälper ingenjörer att arbeta med storskaliga tjänster som miljontals användare gör förfrågningar mot.

Enligt författarens erfarenhet är detta ingen uttömmande lista, men verkligen effektiva råd. Så, låt oss börja.

Översatt med stöd av Mail.ru Cloud Solutions.

Grundnivå

Åtgärderna nedan är relativt enkla att genomföra, men ger hög avkastning. Om du inte har vidtagit dessa tidigare, kommer du bli förvånad över de betydande förbättringarna.

Infrastruktur som kod

Den första delen av råden handlar om att implementera infrastruktur som kod. Det innebär att du ska ha ett programmatic sätt att distribuera hela infrastrukturen. Det låter krångligt, men i själva verket pratar vi om följande kod:

Distribution av 100 virtuella maskiner

med Ubuntu

2 GB RAM på varje

de kommer att ha följande kod

med sådana parametrar

Du kan spåra ändringar i infrastrukturen och snabbt återgå till dem med hjälp av ett versionshanteringssystem.

Modernisten inom mig säger att man kan använda Kubernetes/Docker för att göra allt ovanstående, och han har rätt.

Dessutom kan automatisering göras med hjälp av Chef, Puppet eller Terraform.

Kontinuerlig integration och leverans

För att skapa en skalbar tjänst är det viktigt att ha en bygg- och testpipeline för varje pull-request. Även om testet är det enklaste, säkerställer det åtminstone att koden du distribuerar kompilera.

Varje gång i detta steg svarar du på frågan: kommer min byggnation att kompilera och klara tester, är den giltig? Det kan verka som en låg ribba, men det löser många problem.

Det finns inget mer vackert än att se dessa bockar

För denna teknik kan du överväga Github, CircleCI eller Jenkins.

Belastningsbalanserare

Så, vi vill köra en belastningsbalanserare för att omdirigera trafik och säkerställa jämn belastning på alla noder eller tjänstens funktion i fall av fel:

Belastningsbalanserare hjälper vanligtvis till att fördela trafiken. Bästa praxis är att använda redundanta balansörer, så att du inte har en enda felpunkt.

Ofta konfigureras belastningsbalanserare i den molnplattform du använder.

RayID, korrelations-ID eller UUID för förfrågningar

Har du någonsin stött på ett fel i en applikation med ett meddelande som liknar detta: «Något gick fel. Spara detta ID och skicka det till vår supporttjänst»?

Ett unikt identifierare, correlation ID, RayID eller någon av varianterna – är en unik identifierare som gör det möjligt att spåra en begäran under hela dess livscykel. Detta gör det möjligt att följa hela vägen för begäran i loggarna.

Användaren skickar en begäran till system A, sedan kontaktar A B, som kontaktar C, sparar i X, och sedan returneras begäran till A.

Om du anslöt dig fjärrmässigt till virtuella maskiner och försökte följa vägen för begäran (och manuellt koppla samman vilka anrop som görs), skulle du bli galen. Att ha en unik identifierare gör livet mycket enklare. Det är en av de enklaste sakerna att göra för att spara tid när tjänsten växer.

Medelnivå

Här är tipsen svårare än de tidigare, men rätt verktyg gör uppgiften enklare, vilket ger avkastning även för små och medelstora företag.

Centraliserad loggning

Grattis! Du har implementerat 100 virtuella maskiner. Nästa dag kommer VD:n och klagar på ett fel han fick under test av tjänsten. Han rapporterar den relevanta identifierare som vi pratade om tidigare, men du måste bläddra igenom loggar för 100 maskiner för att hitta den som orsakade felet. Och du måste hitta den innan morgondagens presentation.

Även om det låter som ett roligt äventyr, är det bättre att se till att du har möjlighet att söka i alla loggar från en plats. Jag löste centraliseringsfrågan med den inbyggda funktionaliteten i ELK-stacken: här stöds insamling av loggar med sökmöjligheter. Detta kommer verkligen att hjälpa till att lösa problemet med att hitta en specifik logg. Som en bonus kan du skapa diagram och liknande roliga saker.

Funktionalitet i ELK-stacken

Övervakningsagenter

Nu när din tjänst har satts i drift, måste du säkerställa att den fungerar utan avbrott. Det bästa sättet att göra detta är att köra flera agenter, som arbetar parallellt och kontrollerar att den fungerar och att grundläggande operationer utförs.

Vid detta stadium kontrollerar du att Den körda versionen fungerar bra och arbetar normalt..

För små och medelstora projekt rekommenderar jag Postman för att övervaka och dokumentera API:er. Men generellt sett bör du bara se till att du har ett sätt att veta när det inträffar ett fel och få snabb avisering.

Automatisk skalning beroende på belastning.

Det är väldigt enkelt. Om du har en virtuell maskin som hanterar begärningar och den närmar sig att 80 % av minnet är upptaget, kan du antingen öka dess resurser eller lägga till fler virtuella maskiner i klustret. Automatisk utförande av dessa operationer är utmärkt för flexibel kapacitet anpassning under belastning. Men du måste alltid vara försiktig med hur mycket pengar du spenderar och sätta rimliga gränser.

I de flesta molntjänster kan du ställa in automatisk skalning genom att använda fler servrar eller kraftfullare servrar.

Experimentsystem.

Ett bra sätt att säkert rulla ut uppdateringar är att kunna testa något för 1 % av användarna under en timme. Du har säkert sett sådana mekanismer i aktion. Till exempel visar Facebook delar av publiken en annan färg eller ändrar fontstorleken för att se hur användarna uppfattar ändringar. Detta kallas A/B-testning.

Även lanseringen av en ny funktion kan startas som ett experiment, för att sedan avgöra hur den ska släppas. Dessutom får du möjlighet att "återkalla" eller ändra konfigurationen i farten med avseende på en funktion som orsakar degradering av din tjänst.

Avancerad nivå.

Här är råd som är ganska svåra att implementera. Du kommer sannolikt att behöva lite mer resurser, så det kan vara svårt för ett litet eller medelstort företag att hantera detta.

Blågröna lanseringar.

Detta kallar jag en "Erlang-metod" för lansering. Erlang blev allmänt använt när telefonföretagen dök upp. För att dirigera telefonsamtal började man använda mjukvarubaserade växlingssystem. Huvuduppgiften för mjukvaran i dessa växlingssystem var att inte släppa samtal under systemuppgradering. Erlang har ett utmärkt sätt att ladda ett nytt modul utan att krascha den tidigare.

Det här steget beror på tillgången till en lastbalanserare. Anta att du har version N av din programvara och sedan vill du rulla ut version N+1.

Du kunde bara stoppa tjänsten och rulla ut nästa version vid den tidpunkt du anser vara lämplig för dina användare, och få en viss nedtid. Men anta att du har verkligen strikta SLA-villkor. Så, en SLA på 99,99 % betyder att du kan vara offline bara i 52 minuter per år.

Om du verkligen vill uppnå sådana nivåer, behöver du två distributioner samtidigt:

den som finns just nu (N);
nästa version (N+1).

Du instruerar lastbalanseraren att omdirigera en procentandel av trafiken till den nya versionen (N+1), medan du själv aktivt övervakar regressioner.

Här har vi en grön distribution N som fungerar normalt. Vi försöker övergå till nästa version av denna distribution

Först skickar vi en riktigt liten test för att se om vår distribution N+1 fungerar med en liten mängd trafik:

Slutligen har vi en uppsättning automatiska kontroller som vi slutligen kör tills vår distribution är avslutad. Om du är väldigt, väldigt försiktig kan du också behålla din distribution N för alltid för en snabb återgång vid en dålig regression:

Om du vill gå till en ännu mer avancerad nivå, låt allt i den blågröna distributionen utföras automatiskt.

Upptäckta anomalier och automatisk avhjälpande

Med centralt loggande och en bra logghantering kan du redan sätta högre mål. Till exempel att proaktivt förutsäga fel. På övervakningssystem och i loggar följs funktioner och olika diagram byggs - och man kan förutsäga vad som kommer gå fel i förväg:

Med anomalidetektering börjar du att studera vissa ledtrådar som tjänsten ger. Till exempel kan en ökning av CPU-belastningen indikera att hårddisken håller på att gå sönder, och en ökning av antalet förfrågningar kan betyda att det är dags att skalera. Sådan statistik gör tjänsten proaktiv.

Genom att få sådan analytisk information kan du skala upp på alla dimensioner, proaktivt och reaktivt ändra egenskaperna hos maskiner, databaser, anslutningar och andra resurser.

Det är allt!

Denna prioriteringslista kommer att befria dig från många problem när du höjer din molntjänst.

Författaren av den ursprungliga artikeln inbjuder läsare att lämna sina kommentarer och göra ändringar. Artikeln sprids som öppen källkod, pull requests accepteras av författaren på Github.

Vad mer att läsa om ämnet:

Källa: habr.com