🥇Skapande av ett skalbart API på AWS spot-instanser

Hej alla! Jag heter Kirill och jag är CTO på Adapty. Största delen av vår arkitektur är på AWS, och idag kommer jag att berätta hur vi har minskat serverkostnaderna med 3 gånger genom att använda spotinstanser i produktionsmiljö, samt hur man ställer in autoskalning för dem. Först blir en översikt över hur detta fungerar och sedan en detaljerad guide för att sätta igång.

Vad är spotinstanser?

Spotinstanser är servrar som tillhör andra AWS-användare och som för närvarande står tomma, och de säljer dem med en stor rabatt (Amazon skriver upp till 90 %, men enligt vår erfarenhet är det ~3x, beroende på region, AZ och typ av instans). Den främsta skillnaden från vanliga instanser är att de kan stängas av när som helst. Därför trodde vi länge att det var okej att använda dem för utvecklingsmiljöer eller för beräkningsuppgifter, med lagring av mellanresultat på S3 eller i en databas, men inte för produktion. Det finns tredjepartslösningar för att använda spotinstanser i produktion, men de har många begränsningar för vårt fall, så vi implementerade inte dem. Metoden som beskrivs i artikeln fungerar helt inom standardfunktionaliteten för AWS, utan extra skript, cron-jobb etc.

Nedan följer några skärmdumpar som visar prishistoriken för spotinstanser.

m5.large i regionen eu-west-1 (Irland). Priset har huvudsakligen varit stabilt under 3 månader, just nu är besparingen 2.9x.

m5.large i regionen us-east-1 (N. Virginia). Priset ändras kontinuerligt under 3 månader, just nu är besparingen mellan 2.3x och 2.8x beroende på tillgänglighetszon.

t3.small i regionen us-east-1 (N. Virginia). Priset har varit stabilt under 3 månader, just nu är besparingen 3.4x.

Tjänstens arkitektur

Den grundläggande arkitekturen för tjänsten som vi kommer att diskutera i denna artikel visas i diagrammet nedan.

Application Load Balancer → EC2 Target Group → Elastic Container Service

Vi använder Application Load Balancer (ALB) som balansräknare, som skickar förfrågningar till EC2 Target Group (TG). TG ansvarar för att öppna portar på instanserna för ALB och koppla dem till portarna för Elastic Container Service (ECS) containrar. ECS är motsvarigheten till Kubernetes i AWS som hanterar Docker-kontainrar.

På en instans kan det finnas flera aktiva containrar med samma portar, så vi kan inte ange dem fast. ECS meddelar TG att den startar en ny uppgift (i Kubernetes-termer kallas det en pod), den gör en kontroll av tillgängliga portar på instansen och tilldelar en av dem till den startade uppgiften. TG kontrollerar också regelbundet om instansen och API:t på den fungerar genom hälsokontroll, och om den ser några problem slutar den att skicka begärningar dit.

EC2 Auto Scaling-grupper + ECS kapacitetsleverantörer

I diagrammet ovan visas inte tjänsten EC2 Auto Scaling-grupper (ASG). Av namnet kan man förstå att den ansvarar för att skala instanser. Fram till nyligen fanns det ingen inbyggd möjlighet i AWS att hantera antalet aktiva maskiner från ECS. ECS tillät att skala antalet uppgifter, till exempel baserat på CPU-, RAM-användning eller antal begärningar. Men om uppgifterna tog upp alla fria instanser, så startades inga nya maskiner automatiskt.

Detta ändrades med introduktionen av ECS kapacitetsleverantörer (ECS CP). Nu kan varje tjänst i ECS kopplas till ASG, och om uppgifterna inte får plats på de aktiva instanserna startas nya (men inom de gränser som ASG har ställt in). Detta fungerar också åt andra hållet; om ECS CP ser inaktiva instanser utan uppgifter ger det en signal till ASG att stänga av dem. ECS CP har möjlighet att ange en målsatt procentandel av instansbelastningen, så att ett antal maskiner alltid är fria för snabb skalning av uppgifter, vilket jag kommer att berätta mer om lite senare.

EC2 startmallar

Den sista tjänsten jag kommer att berätta om innan jag går in på en detaljerad beskrivning av skapandet av denna infrastruktur är EC2 startmallar. Den gör det möjligt att skapa en mall som alla maskiner kommer att startas utifrån, så att man inte behöver göra det från grunden varje gång. Här kan man välja typ av körd maskin, säkerhetsgrupp, diskbild och många andra parametrar. Man kan också ange användardata som kommer att laddas upp till alla startade instanser. I användardata kan man köra skript, till exempel kan man redigera innehållet i filen konfiguration av ECS-agenten.

En av de viktigaste konfigurationsparametrarna i denna artikel är ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Om den här inställningen är aktiverad, kommer ECS, så snart den får signalen om att en spot-instans tas bort, att överföra alla uppgifter som körs på den till status Draining. Inga nya uppgifter kommer att tilldelas till denna instans, och om det finns uppgifter som just nu vill startas på den, kommer de att avbrytas. Förfrågningar från lastbalanseraren slutar också komma. Aviseringen om borttagning av instansen kommer två minuter innan den faktiska händelsen. Därför, om din tjänst inte har uppgifter som pågår längre än 2 minuter och inte sparar någonting på disken, kan du använda spot-instans utan risk för dataloss.

När det gäller disken — AWS har nyligen gjort det möjligt att använda Elastic File System (EFS) tillsammans med ECS, med detta upplägg utgör inte ens disken ett hinder, men vi har inte provat det eftersom vi i princip inte behöver en disk för att spara status. Som standard, efter att ha mottagit SIGINT (som skickas i det ögonblick då uppgiften övergår till status Draining), kommer alla aktiva uppgifter att stoppas inom 30 sekunder, även om de inte har blivit klara, detta tidsintervall kan justeras med hjälp av parametern ECS_CONTAINER_STOP_TIMEOUT. Det viktigaste är att inte ställa in detta till mer än 2 minuter för spot-maskiner.

Skapa tjänst

Låt oss gå direkt till att skapa den beskrivna tjänsten. Under processen kommer jag att beskriva några ytterligare användbara punkter som inte nämndes ovan. Generellt är detta en steg-för-steg-instruktion, men några mycket grundläggande eller å sin sida mycket specifika fall kommer jag inte att diskutera. Alla åtgärder utförs i den visuella konsolen i AWS, men de kan även reproduceras programatiskt med hjälp av CloudFormation eller Terraform. På Adapty använder vi Terraform.

EC2 Launch Template

I denna tjänst skapas en konfiguration av maskiner som ska användas. Hanteringen av mallarna sker under EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — vi anger diskimage som alla instanser ska startas med. För ECS bör man i de flesta fall använda en optimerad bild från Amazon. Den uppdateras regelbundet och innehåller allt nödvändigt för att ECS ska fungera. För att ta reda på aktuell bild-ID går vi till sidan Amazon ECS-optimized AMIs, väljer den aktuella regionen och kopierar AMI ID för den. Till exempel, för regionen us-east-1, är det aktuella ID som skrivs i artikeln — ami-00c7c1cf5bdc913ed. Detta ID måste klistras in i punkten Specificera ett anpassat värde.

Instanstyp — specificera typ av instans. Välj den som passar bäst för dina uppgifter.

Nyckelpar (inloggning) — specificera certifikatet som gör det möjligt att ansluta till instansen via SSH, om det är nödvändigt.

Nätverksinställningar — specificera nätverksparametrar. Nätverksplattform bör i de flesta fall vara Virtual Private Cloud (VPC). Säkerhetsgrupper — säkerhetsgrupper för dina instanser. Eftersom vi kommer att använda en lastbalanserare framför instanserna, rekommenderar jag att ange en grupp här som tillåter inkommande anslutningar endast från lastbalanseraren. Det betyder att du kommer att ha 2 säkerhetsgrupper, en för lastbalanseraren som tillåter inkommande (inbound) anslutningar från alla håll på portarna 80 (http) och 443 (https), och en andra för maskinerna som tillåter inkommande anslutningar på alla portar från lastbalanserarens grupp. Utgående (outbound) anslutningar i båda grupperna måste öppnas via TCP-protokollet på alla portar till alla adresser. Du kan begränsa portar och adresser för utgående anslutningar, men då måste du ständigt övervaka att du inte försöker ansluta till någon stängd port.

Lagring (volymer) — specificera diskparametrar för maskinerna. Diskens storlek kan inte vara mindre än vad som anges i AMI, för ECS-optimerad — 30 GiB.

Avancerade detaljer — specificera ytterligare parametrar.

Köpalternativ — vill vi köpa spottinstanser. Vi vill, men här kommer vi inte att markera denna ruta, vi konfigurerar det i Auto Scaling Group, där det finns fler alternativ.

IAM instansprofil — specificera rollen som instanserna ska startas med. För att instanserna ska fungera i ECS behövs rättigheter som vanligtvis ligger i rollen ecsInstanceRole. I vissa fall kan den skapas, om inte, så här instruktion om hur man gör detta. Efter skapandet anger vi den i mallen.
Därefter följer många parametrar, i de flesta fall kan standardvärdena lämnas, men varje parameter har en tydlig beskrivning. Jag aktiverar alltid parametrarna EBS-optimera instans och T2/T3 Unlimited, om de används burstable instanser.

Användardata — specificera användardata. Vi kommer att redigera filen /etc/ecs/ecs.config, där konfigurationen av ECS-agenten ligger.
Ett exempel på hur användardata kan se ut:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — parametern anger att instansen tillhör ett kluster med det angivna namnet, vilket innebär att detta kluster kan köra sina uppgifter på den här servern. Vi har ännu inte skapat ett kluster, men vi kommer att använda detta namn när vi skapar ett.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametern anger att när ett slutsignal ges för en spotinstans, bör alla uppgifter på den flyttas till statusen Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m — parametern anger att efter att ha mottagit SIGINT-signalen har alla uppgifter 1 minut på sig innan de stängs av.

ECS_ENGINE_AUTH_TYPE=docker — parametern anger att Docker-schema används som autentiseringsmetod.

ECS_ENGINE_AUTH_DATA=... — anslutningsparametrar för det privata container-registret där dina Docker-bilder lagras. Om det är offentligt, behöver ingenting anges.

I den här artikeln kommer jag att använda en offentlig bild från Docker Hub, så jag behöver inte ange parametrar. ECS_ENGINE_AUTH_TYPE och ECS_ENGINE_AUTH_DATA behöver inte anges.

Bra att veta: det rekommenderas att regelbundet uppdatera AMI, eftersom nya versioner uppdaterar versioner av Docker, Linux, ECS-agenten med mera. För att inte glömma detta kan man ställa in notifieringar om nya versioner släpps. Du kan få notifieringar via e-post och uppdatera manuellt, eller så kan du skriva en Lambda-funktion som automatiskt skapar en ny version av Launch Template med den uppdaterade AMI:n.

EC2 Auto Scaling Group

Auto Scaling Group ansvarar för att starta och skala instanser. Hantering av grupper sker under EC2 -> Auto Scaling -> Auto Scaling Groups.

Launch template — vi väljer den mall som skapades i föregående steg. Låt versionen vara standard.

Purchase options and instance types — vi anger instanstyper för klustret. Keep in launch template använder instanstypen från Launch Template. Combine purchase options and instance types tillåter flexibilitet i instanstyper. Vi kommer att använda den.

Optional On-Demand base — antalet vanliga, icke-spotsinstanser som alltid kommer att vara aktiva.

On-Demand percentage above base — procentandelen av vanliga och spottinstanser, 50-50 kommer att fördela lika, 20-80 kommer att resultera i att 4 spottinstanser startas för varje vanlig instans. I det här exemplet kommer jag att ange 50-50, men i verkligheten gör vi oftast 20-80, i vissa fall 0-100.

Instanstyper — här kan du ange ytterligare typinstanser som ska användas i klustret. Vi har aldrig använt detta eftersom jag inte riktigt förstår syftet. Kanske handlar det om begränsningar för specifika typinstanser, men dessa kan enkelt ökas genom support. Om du känner till något tillämpningsområde skulle jag gärna läsa om det i kommentarerna)

Nätverk — nätverksinställningar, välj VPC och undernät för maskiner, i de flesta fall bör man välja alla tillgängliga undernät.

Lastbalansering — inställningar för lastbalanserare, men vi gör detta separat, här rör vi inget. Sundhetskontroller kommer också att konfigureras senare.

Gruppstorlek — anger begränsningar för antalet maskiner i klustret och önskat antal maskiner vid start. Antalet maskiner i klustret kommer aldrig att bli mindre än det minimi angivna och mer än det maximala, även om det baserat på mätningar borde ske en skalning.

Skalningspolicyer — skalningsparametrar, men vi kommer att skala baserat på de aktiva ECS-uppgifterna, så vi kommer att ställa in skalning senare.

Skalningsskydd för instanser — skydd av instanser mot borttagning vid nedskalning. Vi aktiverar detta så att ASG inte tar bort en maskin som har aktiva uppgifter. Att inaktivera skydd för instanser utan uppgifter kommer att göras av ECS Capacity Provider.

Lägg till taggar — du kan ange taggar för instanser (för detta måste rutan Tag new instances vara markerad). Jag rekommenderar att ange taggen Namn, så att alla instanser som startas inom gruppen får samma namn, vilket gör det lättare att se dem i konsolen.

Efter att ha skapat gruppen, öppna den och gå till avsnittet Avancerade konfigurationer, varför alla alternativ inte syns i konsolen vid skapandet.

Borttagningspolicyer — regler som beaktas vid borttagning av instanser. De tillämpas i ordning. Vi använder vanligtvis sådana som på bilden nedan. Först tas instanser med den äldsta Launch Template bort (till exempel, om vi har uppdaterat AMI, har vi fått en ny version, men alla instanser hann övergå till den). Sedan väljs instanser som ligger närmast nästa beräknade timme för fakturering. Och därefter väljs de som är äldst baserat på startdatum.

Bra att veta: för att uppdatera alla maskiner i klustret, är det bekvämt att använda Instansuppdatering. Om du kombinerar detta med Lambda-funktionen från föregående steg, får du ett helt automatiserat system för att uppdatera instanser. Innan du uppdaterar alla maskiner måste instansers skydd mot nedskala in stängas av för alla instanser i gruppen. Det handlar inte om inställningen i gruppen, utan om skyddet på själva maskinerna, vilket görs på fliken Instanshantering.

Application Load Balancer och EC2 Target Group

Balansieraren skapas under EC2 → Load Balancing → Load Balancers. Vi kommer att använda Application Load Balancer, och du kan läsa om jämförelsen mellan olika typer av balansierare på tjänstens sida.

Listeners — det är meningsfullt att skapa portarna 80 och 443 och att göra en omdirigering från 80 till 443 med hjälp av balansierarens regler.

Availability Zones — i de flesta fall väljer vi alla tillgänglighetszoner.

Configure Security Settings — här anges SSL-certifikat för balansieraren, det mest bekväma alternativet är att skapa certifikatet i ACM. Du kan läsa om skillnaderna i Security Policy , den kan lämnas vald från början dokumentationenELBSecurityPolicy-2016-08 . Efter att balansieraren har skapats kommer du att se dessDNS-namn , som du måste ställa in CNAME för din domän. Så här ser det ut i Cloudflare.Security Group

— vi skapar eller väljer en säkerhetsgrupp för balansieraren, mer om detta har jag skrivit tidigare i avsnittet EC2 Launch Template → Nätverksinställningar. Target group

— vi skapar en grupp som ansvarar för att dirigera förfrågningar från balansieraren till maskinerna och kontrollerar deras tillgänglighet för att ersätta dem vid problem. Target type ska vara Instance, Protocol — alla, om du använder HTTPS för kommunikationen mellan balansieraren och instanserna, måste du ladda certifikatet på dem. I det här exemplet kommer vi inte att göra det, utan bara lämna port 80. och Port — parametrar för att kontrollera tjänstens funktionalitet. I den verkliga tjänsten bör detta vara en separat begäran som implementerar viktiga delar av affärslogiken, i det här exemplet lämnar jag standardinställningarna. Sedan kan du välja begärningsintervall, timeout, koder för framgångsrika svar och mer. I vårt exempel angör vi framgångskoder 200-399, eftersom Docker-avbildningen som kommer att användas returnerar kod 304.

Sundhetskontroller Register Targets

— här väljs maskiner för gruppen, men i vårt fall kommer detta att hanteras av ECS, så vi hoppar bara över detta steg. : på balansierarens nivå kan du aktivera loggar som kommer att sparas i S3 i ett visst

Bra att vetaformat i SVG-konturformat.. Därifrån kan de exporterats till tredjepartstjänster för analys, eller så kan man göra SQL-frågor direkt mot data i S3 med hjälp av Athena.. Det är praktiskt och fungerar utan någon extra kod. Jag rekommenderar också att ställa in radering av loggar från S3-bucketen efter en viss tidsperiod.

ECS Task Definition

I de tidigare stegen skapade vi allt som har att göra med tjänstens infrastruktur, nu går vi vidare till beskrivningen av de containrar som vi kommer att köra. Detta görs i avsnittet ECS → Task Definitions.

Launch type compatibility — välj EC2.

Task execution IAM role — välj ecsTaskExecutionRole. Med den skrivs loggar, ge åtkomst till hemliga variabler etc.

I avsnittet Container Definitions klickar vi på Add Container.

Image — länk till bilden med projektets kod, i detta exempel kommer jag att använda en offentlig bild från Docker Hub bitnami/node-example:0.0.1.

Memory Limits — minnesgränser för containern. Hard Limit — hård gräns, om containern överstiger det angivna värdet kommer kommandot docker kill att köras, containern dör omedelbart. Soft Limit — mjuk gräns, containern kan överstiga det angivna värdet, men vid placering av uppgifter på maskiner kommer denna parameter att beaktas. Till exempel, om maskinen har 4 GiB RAM och containerns mjuka gräns är 2048 MiB, kan det maximalt finnas 2 aktiva uppgifter med denna container på denna maskin. I verkligheten är 4 GiB RAM något mindre än 4096 MiB, vilket kan ses på fliken ECS Instances i klustret. Mjuk gräns kan inte vara större än hård gräns. Det är viktigt att förstå att om en uppgift har flera containrar så summeras deras gränser.

Port mappings — i Host port anger 0, vilket betyder att porten kommer att tilldelas dynamiskt, den övervakas av Target Group. Container Port — porten där din applikation körs, oftast anges den i körkommandot eller tilldelas i koden av din applikation, Dockerfile etc. För vårt exempel använder vi 3000, eftersom den anges i Dockerfile den använda bilden.

Health check — parametrar för att kontrollera hälso-statusen för containern, förväxla inte med den som ställts in i Target Group.

Environment — miljöinställningar. CPU units — liknar på minnesgränser, men handlar om processorn. Varje processor kärna motsvarar 1024 enheter, så om servern har en dubbelkärnig processor och containern har värdet 512, kan 4 uppgifter med denna container köras på en server. CPU-enheter motsvarar alltid antalet kärnor, de kan inte vara något färre som i fallet med minnet.

Kommando — kommandot för att starta tjänsten inuti containern, alla parametrar anges med kommatecken. Det kan vara gunicorn, npm och så vidare. Om inget anges kommer värdet från CMD-direktivet i Dockerfile att användas. Ange npm,start.

Miljövariabler — miljövariabler för containern. Dessa kan vara både enkla textdata och hemliga variabler från Secrets Manager eller Parameter Store.

Lagring och loggning — här kommer vi att konfigurera loggning i CloudWatch Logs (tjänsten för loggar från AWS). Det räcker att aktivera rutan Auto-configure CloudWatch Logs. Efter skapandet av Task Definition kommer en logggrupp automatiskt att skapas i CloudWatch. Som standard lagras loggarna där oändligt, jag rekommenderar att ändra Retention period från Never Expire till den önskade perioden. Detta görs i CloudWatch Log groups, klicka på den aktuella perioden och välj en ny.

ECS Kluster och ECS Kapacitetsleverantör

Gå till avsnittet ECS → Clusters för att skapa ett kluster. Välj EC2 Linux + Networking som mall.

Kluster namn — mycket viktigt, vi gör här samma namn som anges i Launch Template i parametern ECS_CLUSTER, i vårt fall — DemoApiClusterProd. Markera rutan Create an empty cluster. Valfritt kan Container Insights aktiveras för att se mätvärden för tjänster i CloudWatch. Om du har gjort allt rätt kommer du i avsnittet ECS Instances att se maskiner som skapades i Auto Scaling group.

Gå till fliken Kapacitetsleverantörer och skapa en ny. Jag påminner om att den behövs för att hantera skapandet och avstängningen av maskiner beroende på antalet aktiva ECS-tasker. Det är viktigt att notera att leverantören endast kan knytas till en grupp.

Auto Scaling group — välj den tidigare skapade gruppen.

Hantera skalning — aktivera så att leverantören kan skala tjänsten.

Målkapacitet % — vilken procentbelastning av maskiner med uppgifter vi behöver. Om du anger 100 % kommer alla maskiner alltid att vara upptagna med aktiva uppgifter. Om du anger 50 % kommer hälften av maskinerna alltid vara lediga. I så fall, om det finns en plötslig ökning i belastningen, kommer nya uppgifter omedelbart att gå till de lediga maskinerna utan att behöva vänta på att instanserna ska rullas ut.

Hantera avslutningsskydd — vi aktiverar detta parameter som tillåter leverantören att ta bort skyddet för instanser från borttagning. Detta sker när det inte finns några aktiva uppgifter på maskinen och möjliggör Target capacity %.

ECS-tjänst och inställning av skalning

Sista steget :) För att skapa en tjänst måste du gå in i den tidigare skapade klustern på fliken Tjänster.

Lanseringstyp — du måste klicka på Switch to capacity provider strategy och välja den tidigare skapade leverantören.

Uppgiftsdefinition — vi väljer den tidigare skapade uppgiftsdefinitionen och dess version.

Tjänstnamn — för att inte blanda ihop, anger vi alltid samma namn som uppgiftsdefinitionen.

Tjänsttyp — alltid Replica.

Antal uppgifter — önskat antal aktiva uppgifter i tjänsten. Denna parameter styrs av skalning, men den måste fortfarande anges.

Minimalt hälsoprocent och Maximalt procent — bestämmer beteendet för uppgifter vid distribution. Standardvärdena 100 och 200 innebär att antalet uppgifter vid distribution ökar med en faktor och sedan återgår till önskat antal. Om du har 1 uppgift, min=0 och max=100, kommer den att dödas vid distribution, och sedan kommer en ny att startas, vilket innebär död tid. Om 1 uppgift fungerar, min=50, max=150, då kommer distribution överhuvudtaget inte att ske, eftersom 1 uppgift inte kan delas i hälften eller ökas med en och en halv gång.

Distributionstyp — vi lämnar Rolling update.

Placering smallar — regler för placering av uppgifter på maskiner. Som standard står det AZ Balanced Spread — detta innebär att varje ny uppgift kommer att placeras på en ny instans tills alla maskiner i alla tillgänglighetszoner startas. Vi gör vanligtvis BinPack — CPU och Spread — AZ, under denna policy placeras uppgifter så nära varandra som möjligt per maskin enligt CPU. Vid behov av att skapa en ny maskin skapas den i en ny tillgänglighetszon.

Lastbalanserartyp — vi väljer Application Load Balancer.

Tjänst IAM-roll — vi väljer ecsServiceRole.

Lastbalanserarnamn — vi väljer den tidigare skapade lastbalanseraren.

Hälsokontrollspärrperiod — paus före utförande av hälsokontroller efter distribution av en ny uppgift, vi sätter vanligtvis 60 sekunder.

Behållare för att lastbalansera — i fältet Target group name väljer vi den tidigare skapade gruppen, och allt kommer att fyllas i automatiskt.

Service Auto Scaling — inställningar för tjänstens skalning. Välj Configure Service Auto Scaling för att justera önskat antal på din tjänst. Ange minimi- och maximala antalet uppgifter vid skalning.

IAM-roll för Service Auto Scaling — vi väljer AWSServiceRoleForApplicationAutoScaling_ECSService.

Automatiska uppgiftsskaleringspolicyer — regler för skalning. Det finns två typer:

Target tracking — övervakning av en målmetrik (CPU/RAM-användning eller antal förfrågningar per uppgift). Till exempel, vi vill att den genomsnittliga CPU-belastningen ska vara 85%, när den blir högre kommer nya uppgifter att läggas till tills den når målvärdet. Om belastningen är lägre kommer uppgifterna att tas bort, om inte skydd mot nedskalning är aktiverat (Disable scale-in).
Step scaling — respons på ett vilkorat evenemang. Här kan vi ställa in reaktionen på vilket som helst evenemang (CloudWatch Alarm), när det inträffar kan vi lägga till eller ta bort ett angivet antal uppgifter, eller ange ett exakt antal uppgifter.

Tjänsten kan ha flera skalningsregler, vilket kan vara användbart, men det är viktigt att se till att de inte stöter på varandra.

Slutsats

Om du följde instruktionerna och använde samma Docker-image, bör din tjänst returnera en sådan sida.

Vi har skapat en mall som alla maskiner i tjänsten startas med. Vi har också lärt oss att uppdatera maskinerna vid ändring av mallen.
Vi har ställt in hantering av stopp-signaler för spottinstanser, så inom en minut efter att den mottas tas alla aktiva uppgifter bort från maskinen, vilket gör att inget går förlorat eller avbryts.
Vi har lyft en belastningsutjämnare för att fördela lasten jämnt mellan maskinerna.
Vi har skapat en tjänst som körs på spottinstanser, vilket minskar kostnaderna för maskiner med cirka tre gånger.
Vi har ställt in automatiskt skalande i båda riktningarna för att hantera ökad belastning, men samtidigt inte betala för stillestånd.
Vi använder Capacity Provider så att applikationen hanterar infrastrukturen (maskinerna), och inte tvärtom.
Vi är duktiga.

Om du har förutsägbara häftiga belastningar, till exempel om du gör reklam i en stor e-postutskick, kan du ställa in skalning baserad på schema.

Det är också möjligt att skala baserat på data från olika delar av ditt system. Till exempel har vi funktionaliteten att skicka individuella kampanjerbjudanden till användare av mobilappen. Ibland går kampanjen ut till över 1M personer. Efter en sådan utskick ses alltid en stor ökning av API-förfrågningar, då många användare loggar in på appen samtidigt. Så om vi ser att kön för att skicka kampanjnotiser har ökat markant jämfört med standardnivåerna, kan vi omedelbart starta några extra maskiner och uppgifter för att vara redo för belastningen.

Jag skulle bli glad om ni i kommentarerna delar intressanta fall av användning av spot-instanser och ECS eller något om skalning.

Snart kommer det artiklar om hur vi hanterar tusentals analystjänster per sekund på en främst serverlös stack (med kostnader) och hur distributionen av tjänster sker med hjälp av GitLab CI och Terraform Cloud.

Följ oss, det kommer bli intressant!

Endast registrerade användare kan delta i omröstningen. Logga in, tack.