Hej alla! Jag heter Kirill, jag är CTO på Adapty. Det mesta av vår arkitektur är på AWS, och idag kommer jag att prata om hur vi minskade serverkostnaderna med 3 gånger genom att använda punktinstanser i en produktionsmiljö, samt hur man ställer in deras automatiska skalning. Först kommer det att finnas en översikt över hur det fungerar, och sedan detaljerade instruktioner för att komma igång.
Vad är Spot-instanser?
instanser är servrar för andra AWS-användare som för närvarande är inaktiva, och de säljer dem till en stor rabatt (Amazon skriver upp till 90%, enligt vår erfarenhet ~3x, varierar beroende på region, AZ och instanstyp). Deras huvudsakliga skillnad från vanliga är att de kan stängas av när som helst. Därför trodde vi länge att det var normalt att använda dem för jungfruliga miljöer, eller för uppgifter att beräkna något, med mellanresultat sparade på S3 eller i databasen, men inte för försäljning. Det finns tredjepartslösningar som låter dig använda fläckar i produktionen, men det finns många kryckor för vårt fall, så vi implementerade dem inte. Tillvägagångssättet som beskrivs i artikeln fungerar helt inom standard AWS-funktionaliteten, utan ytterligare skript, kronor, etc.
Nedan finns några skärmdumpar som visar prishistoriken för spot-instanser.
m5.stor i regionen eu-west-1 (Irland). Priset har varit mestadels stabilt i 3 månader, för närvarande sparat 2.9x.
m5.stor i us-east-1-regionen (N. Virginia). Priset förändras ständigt under 3 månader och sparar för närvarande från 2.3x till 2.8x beroende på tillgänglighetszon.
t3.small i us-east-1-regionen (N. Virginia). Priset har varit stabilt i 3 månader, för närvarande sparat 3.4x.
Tjänstearkitektur
Den grundläggande arkitekturen för tjänsten som vi kommer att prata om i den här artikeln visas i diagrammet nedan.
Application Load Balancer → EC2 Target Group → Elastic Container Service
Application Load Balancer (ALB) används som en balanserare, som skickar förfrågningar till EC2 Target Group (TG). TG ansvarar för att öppna portar på instanser för ALB och ansluta dem till hamnar i ECS-containrar (Elastic Container Service). ECS är en analog till Kubernetes i AWS, som hanterar Docker-containrar.
En instans kan ha flera containrar igång med samma portar, så vi kan inte ställa dem fast. ECS säger till TG att den lanserar en ny uppgift (i Kubernetes terminologi kallas detta en pod), den söker efter lediga portar på instansen och tilldelar en av dem till den startade uppgiften. TG kontrollerar också regelbundet om instansen och API:et arbetar med den med hjälp av hälsokontroll, och om den ser några problem slutar den att skicka förfrågningar dit.
EC2 Auto Scaling Groups + ECS Capacity Providers
Diagrammet ovan visar inte tjänsten EC2 Auto Scaling Groups (ASG). Av namnet kan du förstå att det är ansvarigt för skalning av instanser. Men tills nyligen hade AWS inte en inbyggd förmåga att hantera antalet körande maskiner från ECS. ECS gjorde det möjligt att skala antalet uppgifter, till exempel efter CPU-användning, RAM eller antal förfrågningar. Men om uppgifter ockuperade alla lediga instanser skapades inte nya maskiner automatiskt.
Detta har förändrats med tillkomsten av ECS Capacity Providers (ECS CP). Nu kan varje tjänst i ECS associeras med en ASG, och om uppgifterna inte passar på de körande instanserna så kommer nya att tas upp (men inom de fastställda ASG-gränserna). Detta fungerar också i motsatt riktning, om ECS CP ser lediga instanser utan uppgifter, kommer det att ge ASG-kommandot för att stänga av dem. ECS CP har förmågan att specificera en målprocent för instansbelastning, så att ett visst antal maskiner alltid är lediga för snabba skalningsuppgifter; jag ska prata om detta lite senare.
EC2-startmallar
Den sista tjänsten jag kommer att prata om innan jag går in i detalj om att skapa den här infrastrukturen är EC2 Launch Templates. Det låter dig skapa en mall enligt vilken alla maskiner startar, för att inte upprepa detta från början varje gång. Här kan du välja vilken typ av maskin som ska startas, säkerhetsgrupp, diskavbildning och många andra parametrar. Du kan också ange användardata som ska laddas upp till alla lanserade instanser. Du kan köra skript i användardata, till exempel kan du redigera innehållet i en fil .
En av de viktigaste konfigurationsparametrarna för den här artikeln är =sant. Om denna parameter är aktiverad, så fort ECS tar emot en signal om att en punktinstans tas bort, överför den alla uppgifter som arbetar på den till Dräneringsstatus. Inga nya uppgifter kommer att tilldelas den här instansen; om det finns uppgifter som vill rullas ut till den just nu kommer de att avbrytas. Förfrågningar från balansören slutar också komma. Meddelande om instansradering kommer 2 minuter före själva händelsen. Därför, om din tjänst inte utför uppgifter längre än 2 minuter och inte sparar något på disken, kan du använda punktinstanser utan att förlora data.
Angående disk - AWS nyligen Det är möjligt att använda Elastic File System (EFS) tillsammans med ECS; med detta schema är inte ens disken ett hinder, men vi försökte inte detta, eftersom vi i princip inte behöver disken för att lagra tillståndet. Som standard, efter att ha tagit emot SIGINT (skickat när en uppgift överförs till statusen Dränering), stoppas alla pågående uppgifter efter 30 sekunder, även om de inte har slutförts ännu; du kan ändra denna tid med parametern . Det viktigaste är att inte ställa in den i mer än 2 minuter för spotmaskiner.
Skapa en tjänst
Låt oss gå vidare till att skapa den beskrivna tjänsten. I processen kommer jag dessutom att beskriva flera användbara punkter som inte nämndes ovan. I allmänhet är detta en steg-för-steg-instruktion, men jag kommer inte att överväga några mycket grundläggande eller, tvärtom, mycket specifika fall. Alla åtgärder utförs i AWS visuella konsol, men kan reproduceras programmatiskt med CloudFormation eller Terraform. På Adapty använder vi Terraform.
EC2-startmall
Den här tjänsten skapar en konfiguration av maskiner som kommer att användas. Mallar hanteras i avsnittet EC2 -> Instanser -> Starta mallar.
Amazon maskinbild (AMI) — ange diskavbildningen med vilken alla instanser ska startas. För ECS är det i de flesta fall värt att använda den optimerade bilden från Amazon. Den uppdateras regelbundet och innehåller allt som behövs för att ECS ska fungera. För att ta reda på aktuellt bild-ID, gå till sidan , välj den region du använder och kopiera AMI-ID för den. Till exempel, för us-east-1-regionen, är det aktuella ID:t i skrivande stund ami-00c7c1cf5bdc913ed. Detta ID måste infogas i objektet Ange ett anpassat värde.
Instans typ — ange instanstypen. Välj den som bäst passar din uppgift.
Nyckelpar (inloggning) — ange ett certifikat med vilket du kan ansluta till instansen via SSH, om det behövs.
Nätverksinställningar — ange nätverksparametrarna. Nätverksplattform i de flesta fall bör det finnas ett Virtual Private Cloud (VPC). Säkerhetsgrupper — säkerhetsgrupper för dina instanser. Eftersom vi kommer att använda en balancer framför instanserna rekommenderar jag att du specificerar en grupp här som tillåter inkommande anslutningar endast från balancern. Det vill säga, du kommer att ha 2 säkerhetsgrupper, en för balanseraren, som tillåter inkommande anslutningar från var som helst på portarna 80 (http) och 443 (https), och den andra för maskiner, som tillåter inkommande anslutningar på alla portar från balanseringsgruppen . Utgående anslutningar i båda grupperna måste öppnas med TCP-protokollet till alla portar till alla adresser. Du kan begränsa portar och adresser för utgående anslutningar, men då behöver du hela tiden övervaka att du inte försöker komma åt något på en stängd port.
Lagring (volymer) — ange diskparametrarna för maskinerna. Diskstorleken kan inte vara mindre än den som anges i AMI, för ECS Optimized är den 30 GiB.
Avancerade detaljer — ange ytterligare parametrar.
Köpalternativ — om vi vill köpa spot-instanser. Vi vill, men vi kommer inte att markera den här rutan här; vi kommer att konfigurera den i Auto Scaling Group, det finns fler alternativ där.
IAM-instansprofil — ange vilken roll instanserna kommer att lanseras med. För att instanser ska kunna köras i ECS behöver de behörigheter, som vanligtvis finns i rollen ecsInstanceRole. I vissa fall kan det skapas, om inte, så här om hur man gör detta. Efter skapandet anger vi det i mallen.
Därefter finns det många parametrar, i princip kan du lämna standardvärden överallt, men var och en av dem har en tydlig beskrivning. Jag aktiverar alltid den EBS-optimerade instansen och T2/T3 Unlimited-alternativen om de används instanser.
Användningstid — ange användardata. Vi kommer att redigera filen /etc/ecs/ecs.config, som innehåller ECS-agentkonfigurationen.
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.configECS_CLUSTER=DemoApiClusterProd — parametern indikerar att instansen tillhör ett kluster med det angivna namnet, det vill säga detta kluster kommer att kunna placera sina uppgifter på denna server. Vi har inte skapat ett kluster ännu, men vi kommer att använda detta namn när vi skapar det.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametern anger att när en signal tas emot för att stänga av en punktinstans, ska alla uppgifter på den överföras till Dräneringsstatus.
ECS_CONTAINER_STOP_TIMEOUT=1m - parametern anger att efter att ha mottagit en SIGINT-signal har alla uppgifter 1 minut innan de avbryts.
ECS_ENGINE_AUTH_TYPE=docker — Parametern indikerar att Docker-schemat används som auktoriseringsmekanism
ECS_ENGINE_AUTH_DATA=... — anslutningsparametrar till det privata containerregistret, där dina Docker-bilder lagras. Om det är offentligt behöver du inte ange något.
För den här artikeln kommer jag att använda en offentlig bild från Docker Hub, så ange parametrarna ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA behövs inte.
Bra att veta: Det rekommenderas att uppdatera AMI regelbundet, eftersom nya versioner uppdaterar versioner av Docker, Linux, ECS-agent, etc. För att inte glömma detta kan du om lanseringen av nya versioner. Du kan få aviseringar via e-post och uppdatera manuellt, eller så kan du skriva en Lambda-funktion som automatiskt skapar en ny version av Launch Template med en uppdaterad AMI.
EC2 Auto Scaling Group
Auto Scaling Group ansvarar för att starta och skala instanser. Grupper hanteras i avsnittet EC2 -> Autoskalning -> Autoskalningsgrupper.
Starta mall — välj mallen som skapades i föregående steg. Vi lämnar standardversionen.
Köpalternativ och instanstyper — ange typer av instanser för klustret. Följ startmallen använder instanstypen från startmallen. Genom att kombinera köpalternativ och instanstyper kan du flexibelt konfigurera instanstyper. Vi kommer att använda den.
Valfri On-Demand-bas — Antalet regelbundna, icke-spot-instanser som alltid kommer att fungera.
On-Demand procentandel över basen — Procentandel av vanliga fall och spot-instanser, 50-50 kommer att fördelas lika, 20-80 för varje vanlig instans höjs 4 spot-ettor. För detta exempel 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 typer av instanser som kommer att användas i klustret. Vi använde det aldrig eftersom jag inte riktigt förstår meningen med berättelsen. Kanske beror detta på begränsningarna för specifika typer av instanser, men de kan enkelt ökas genom stöd. Om du känner till applikationen kommer jag gärna att läsa den i kommentarerna)
nätverks — nätverksinställningar, välj VPC och undernät för maskiner, i de flesta fall bör du välja alla tillgängliga undernät.
Lastbalansering - balanseringsinställningar, men vi kommer att göra detta separat, vi kommer inte att röra någonting här. Hälsokontroller kommer också att konfigureras senare.
Gruppstorlek — vi anger gränserna för antalet maskiner i klustret och det önskade antalet maskiner vid starten. Antalet maskiner i klustret kommer aldrig att vara mindre än det angivna minimumet och fler än det maximala, även om skalning skulle ske enligt måtten.
Skalningspolicyer — skalningsparametrar, men vi kommer att skala baserat på de pågående ECS-uppgifterna, så vi kommer att konfigurera skalningen senare.
Exempelvis inskalningsskydd — skydd av instanser från radering vid nedskalning. Vi aktiverar det så att ASG inte tar bort maskinen som har körande uppgifter. ECS Capacity Provider kommer att inaktivera skyddet för instanser som inte har uppgifter.
Lägg till taggar — du kan ange taggar för instanser (för detta måste kryssrutan Tagga nya instanser vara markerad). Jag rekommenderar att du specificerar namntaggen, då kommer alla instanser som startas inom gruppen att ha samma namn, och det är bekvämt att se dem i konsolen.
När du har skapat gruppen, öppna den och gå till avsnittet Avancerade konfigurationer Varför inte alla alternativ är synliga i konsolen när du skapar den.
Uppsägningspolicyer — regler som beaktas vid borttagning av instanser. De appliceras i ordning. Vi brukar använda de på bilden nedan. Först tas instanser med den äldsta startmallen bort (om vi till exempel uppdaterade AMI skapade vi en ny version, men alla instanser lyckades byta till den). Därefter väljs de instanser som ligger närmast nästa debiteringstimme. Och sedan väljs de äldsta ut utifrån lanseringsdatum.
Bra att veta: för att uppdatera alla maskiner i ett kluster, bekvämt att använda . Om du kombinerar detta med Lambda-funktionen från föregående steg får du ett helautomatiskt instansuppdateringssystem. Innan du uppdaterar alla maskiner måste du inaktivera instansinskalningsskydd för alla instanser i gruppen. Inte konfiguration i gruppen, utan skydd från själva maskinerna, detta görs på fliken Instanshantering.
Application Load Balancer och EC2 Target Group
Balanseraren skapas i avsnittet EC2 → Lastbalansering → Lastbalanserare. Vi kommer att använda Application Load Balancer; en jämförelse av olika typer av balanserare kan läsas på .
lyssnare - Det är vettigt att göra portarna 80 och 443 och omdirigera från 80 till 443 med hjälp av balansreglerna senare.
Tillgänglighetszoner — i de flesta fall väljer vi tillgänglighetszoner för alla.
Konfigurera säkerhetsinställningar — SSL-certifikatet för balanseraren anges här, det bekvämaste alternativet är i ACM. Om skillnaderna Säkerhetspolitiken kan läsas in , kan du låta den vara markerad som standard ELBSecurityPolicy-2016-08. När du har skapat balanseringen kommer du att se den DNS-namn, som du behöver för att konfigurera CNAME för din domän. Så här ser det till exempel ut i Cloudflare.
Säkerhetsgrupp — skapa eller välj en säkerhetsgrupp för balansören, jag skrev mer om detta precis ovan i avsnittet EC2 Launch Template → Nätverksinställningar.
Målgrupp — vi skapar en grupp som ansvarar för att dirigera förfrågningar från balansören till maskiner och kontrollera deras tillgänglighet för att ersätta dem vid problem. Måltyp måste vara instans, Protokoll и Hamn någon, om du använder HTTPS för kommunikation mellan balanseraren och instanserna, måste du ladda upp ett certifikat till dem. För detta exempel kommer vi inte att göra detta, vi lämnar helt enkelt port 80.
Hälsokontroller — Parametrar för kontroll av tjänstens funktionalitet. I en riktig tjänst bör detta vara en separat begäran som implementerar viktiga delar av affärslogiken; för detta exempel kommer jag att lämna standardinställningarna. Därefter kan du välja förfrågningsintervall, timeout, framgångskoder etc. I vårt exempel kommer vi att indikera framgångskoder 200-399, eftersom Docker-bilden som kommer att användas returnerar en 304-kod.
Registrera mål — här väljs bilarna för gruppen ut, men i vårt fall kommer detta att göras av ECS, så vi hoppar bara över det här steget.
Bra att veta: på balanseringsnivån kan du aktivera loggar som kommer att sparas i S3 i en viss . Därifrån kan de exporteras till tredjepartstjänster för analys, eller så kan du göra SQL-frågor direkt på data i S3 med . Det är bekvämt och fungerar utan någon extra kod. Jag rekommenderar också att du ställer in borttagning av stockar från S3-skopan efter en viss tidsperiod.
ECS Task Definition
I de föregående stegen skapade vi allt relaterat till tjänsteinfrastrukturen, nu går vi vidare till att beskriva containrarna som vi kommer att lansera. Detta görs i avsnittet ECS → Uppgiftsdefinitioner.
Kompatibilitet med starttyp - välj EC2.
Uppgiftsutförande IAM roll - välj ecsTaskExecutionRole. Med hjälp av den skrivs loggar, ges tillgång till hemliga variabler osv.
Klicka på Lägg till behållare i avsnittet Behållardefinitioner.
Bild — länk till bilden med projektkoden; för det här exemplet kommer jag att använda en offentlig bild från Docker Hub .
Minnesgränser — Minnesgränser för behållaren. Hård gräns — hård gräns, om behållaren går utöver det angivna värdet, kommer docker kill-kommandot att köras, behållaren kommer att dö omedelbart. Mjuk gräns — mjuk gräns, behållaren kan gå utöver det angivna värdet, men denna parameter kommer att beaktas när uppgifter placeras på maskiner. Till exempel, om en maskin har 4 GiB RAM och den mjuka gränsen för en behållare är 2048 MiB, kan den här maskinen ha maximalt 2 köruppgifter med den här behållaren. I verkligheten är 4 GiB RAM något mindre än 4096 MiB, detta 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 det finns flera behållare i en uppgift, så summeras deras gränser.
Hamnkartläggningar - kl Värdport Vi anger 0, detta betyder att porten kommer att tilldelas dynamiskt och kommer att övervakas av målgruppen. Containerport — porten som din applikation körs på anges ofta i exekveringskommandot eller tilldelas i din applikationskod, Dockerfile, etc. För vårt exempel kommer vi att använda 3000 eftersom det är listat i bilden som används.
Hälsokontroll — Parametrar för behållarehälsokontroll, inte att förväxla med den som konfigurerats i målgruppen.
Miljö - miljöinställningar. CPU-enheter - liknande Minnesgränser, bara om processorn. Varje processorkärna är 1024 enheter, så om servern har en dubbelkärnig processor och behållaren är inställd på 512, kan 4 uppgifter med denna behållare startas på en server. CPU-enheter motsvarar alltid antalet kärnor, det kan inte finnas lite färre av dem, vilket är fallet med minne.
Kommando — ett kommando för att starta en tjänst inuti en behållare, alla parametrar anges avgränsade med kommatecken. Detta kan vara gunicorn, npm, etc. Om det inte anges kommer värdet på CMD-direktivet från Dockerfilen att användas. Vi indikerar npm,start.
Miljövariabler — Containermiljövariabler. Detta kan vara antingen enkel textdata eller hemliga variabler från eller .
Lagring och loggning — här ställer vi in inloggning i CloudWatch Logs (en tjänst för loggar från AWS). För att göra detta, aktivera bara kryssrutan Autokonfigurera CloudWatch-loggar. Efter att ha skapat uppgiftsdefinitionen skapas en grupp loggar automatiskt i CloudWatch. Som standard lagras loggar i den på obestämd tid; jag rekommenderar att du ändrar lagringsperioden från Aldrig löper ut till den nödvändiga perioden. Detta görs i CloudWatch Log-grupper, du måste klicka på den aktuella perioden och välja en ny.
ECS Cluster och ECS Capacity Provider
Gå till avsnittet ECS → Kluster för att skapa ett kluster. Vi väljer EC2 Linux + Networking som mall.
Klusternamn - mycket viktigt, vi gör här samma namn som anges i parametern Launch Template ECS_CLUSTER, i vårat fall - DemoApiClusterProd. Markera kryssrutan Skapa ett tomt kluster. Alternativt kan du aktivera Container Insights för att visa statistik för tjänster i CloudWatch. Om du gjorde allt korrekt, kommer du i avsnittet ECS-instanser att se maskiner som skapades i gruppen Automatisk skalning.
Gå till fliken Kapacitetsleverantörer och skapa en ny. Låt mig påminna dig om att det behövs för att styra skapandet och avstängningen av maskiner beroende på antalet körande ECS-uppgifter. Det är viktigt att notera att en leverantör endast kan tilldelas en grupp.
Grupp för automatisk skalning — välj den tidigare skapade gruppen.
Hanterad skalning — aktivera det så att leverantören kan skala tjänsten.
Målkapacitet % — hur stor andel av maskiner laddade med uppgifter behöver vi. Om du anger 100% kommer alla maskiner alltid att vara upptagna med att köra uppgifter. Om du anger 50 % så kommer alltid hälften av bilarna att vara gratis. I det här fallet, om det blir ett kraftigt hopp i lasten, kommer nya taxibilar omedelbart att ta sig till fria bilar, utan att behöva vänta på att instanser ska sättas in.
Hanterade uppsägningsskydd — aktivera, den här parametern tillåter leverantören att ta bort skyddet för instanser från radering. Detta händer när det inte finns några aktiva uppgifter på maskinen och tillåter Målkapacitet %.
ECS Service och skalningssetup
Sista steget :) För att skapa en tjänst måste du gå till det tidigare skapade klustret på fliken Tjänster.
Starttyp — du måste klicka på Byt till strategi för kapacitetsleverantör och välja de tidigare skapade leverantörerna.
Uppgiftsdefinition — välj den tidigare skapade uppgiftsdefinitionen och dess revision.
Service namn — för att undvika förvirring anger vi alltid detsamma som uppgiftsdefinition.
Service type - alltid replika.
Antal uppgifter — önskat antal aktiva uppgifter i tjänsten. Denna parameter styrs av skalning, men måste fortfarande anges.
Minsta friska procent и Max procent — bestämma beteendet för uppgifter under driftsättning. Standardvärdena är 100 och 200, vilket indikerar att antalet uppgifter kommer att öka flera gånger vid tidpunkten för driftsättning och sedan återgå till önskat värde. Om du har en aktivitet igång, min=1 och max=0, kommer den att dödas under driftsättningen, och efter det kommer en ny att höjas, det vill säga att det blir stillestånd. Om 100 uppgift körs, min=1, max=50, kommer driftsättningen inte att ske alls, eftersom 150 uppgift inte kan delas på mitten eller ökas med en och en halv gång.
Implementeringstyp — lämna rullande uppdatering.
Placeringsmallar — regler för placering av uppgifter på maskiner. Standard är AZ Balanced Spread - detta innebär att varje ny uppgift kommer att placeras på en ny instans tills maskiner i alla tillgänglighetszoner stiger. Vi brukar göra BinPack - CPU och Spread - AZ; med denna policy placeras uppgifter så tätt som möjligt på en maskin per CPU. Om det är nödvändigt att skapa en ny maskin skapas den i en ny tillgänglighetszon.
Typ av lastbalanserare — välj Application Load Balancer.
Service IAM roll - välj ecsServiceRole.
Lastbalanserarens namn — välj den tidigare skapade balanseraren.
Hälsokontroll respitperiod — pausa innan du utför hälsokontroller efter utrullning av en ny uppgift, vi brukar ställa in den på 60 sekunder.
Behållare till lastbalans — i objektet Målgruppsnamn, välj den tidigare skapade gruppen, så fylls allt i automatiskt.
Service automatisk skalning — Serviceskalningsparametrar. Välj Konfigurera automatisk skalning för tjänst för att justera tjänstens önskade antal. Vi ställer in minsta och maximala antal uppgifter vid skalning.
IAM-roll för Service Auto Scaling - välj AWSServiceRoleForApplicationAutoScaling_ECSService.
Policyer för automatisk uppgiftsskalning — regler för skalning. Det finns 2 typer:
- Målspårning — spåra målvärden (CPU/RAM-användning eller antal förfrågningar för varje uppgift). Till exempel vill vi att den genomsnittliga processorbelastningen 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 uppgifter att tas bort, tvärtom, om inte skydd mot nedskalning är aktiverat (Inaktivera inskalning).
- Stegskalning - reaktion på en godtycklig händelse. Här kan du konfigurera en reaktion på vilken händelse som helst (CloudWatch Alarm), när den inträffar kan du lägga till eller ta bort det angivna antalet uppgifter, eller ange det exakta antalet uppgifter.
En tjänst kan ha flera skalningsregler, detta kan vara användbart, huvudsaken är att se till att de inte kommer i konflikt med varandra.
Slutsats
Om du följde instruktionerna och använde samma Docker-bild, bör din tjänst returnera en sida som denna.
- Vi har skapat en mall enligt vilken alla maskiner i tjänsten lanseras. Vi lärde oss också hur man uppdaterar maskiner när mallen ändras.
- Vi har konfigurerat bearbetningen av punktinstansens stoppsignal, så inom en minut efter mottagandet tas alla pågående uppgifter bort från maskinen, så att ingenting går förlorat eller avbryts.
- Vi höjde balanseraren för att fördela belastningen jämnt över maskinerna.
- Vi har skapat en tjänst som körs på spot-instanser, vilket minskar maskinkostnaderna med cirka 3 gånger.
- Vi har konfigurerat automatisk skalning i båda riktningarna för att hantera ökade arbetsbelastningar utan att ådra sig kostnader för stillestånd.
- Vi använder Capacity Provider så att applikationen hanterar infrastrukturen (maskinerna) och inte tvärtom.
- Var bra.
Om du har förutsägbara toppar i belastningen, till exempel annonserar du i en stor e-postkampanj, kan du ställa in skalning med .
Du kan även skala baserat på data från olika delar av ditt system. Vi har till exempel funktionen användare av mobilapplikationen. Ibland skickas en kampanj till över 1 miljon personer. Efter en sådan distribution sker det alltid en stor ökning av förfrågningar till API:t, eftersom många användare loggar in i applikationen samtidigt. Så om vi ser att det finns betydligt fler standardindikatorer i kön för att skicka PR-pushnotiser kan vi direkt lansera flera ytterligare maskiner och uppgifter för att vara redo för belastningen.
Jag blir glad om du berättar för mig i kommentarerna intressanta fall av användning av spot-instanser och ECS eller något om skalning.
Snart kommer det att finnas artiklar om hur vi behandlar tusentals analytiska händelser per sekund på en övervägande serverlös stack (med pengar) och hur distributionen av tjänster fungerar med hjälp av GitLab CI och Terraform Cloud.
Prenumerera på oss, det kommer att bli intressant!
Endast registrerade användare kan delta i undersökningen. , Snälla du.
Använder du spot-instanser i produktionen?
-
22,2%Ja 6
-
66,7%Nr 18
-
11,1%Jag lärde mig om dem från en artikel och planerar att använda dem3
27 användare röstade. 5 användare avstod från att rösta.
Källa: will.com