🥇Creëren van een schaalbare API op AWS spot-instanties

Hallo allemaal! Mijn naam is Kirill, ik ben CTO bij Adapty. Het grootste deel van onze architectuur draait op AWS, en vandaag zal ik uitleggen hoe we onze serverkosten met 3 keer hebben verminderd door gebruik te maken van spot instances in de productieomgeving. Eerst zal ik een overzicht geven van hoe dit werkt, en daarna volgt een gedetailleerde handleiding voor het opzetten ervan.

Wat zijn spot instances?

Spot instances zijn servers van andere AWS-gebruikers die momenteel niet in gebruik zijn, en ze worden met een hoge korting verkocht (Amazon zegt tot 90%, maar uit onze ervaring is het ongeveer 3x, dit varieert afhankelijk van de regio, AZ en het type instance). Het belangrijkste verschil met normale instances is dat ze op elk moment kunnen worden uitgeschakeld. Daarom hebben we lange tijd gedacht dat het normaal is om ze te gebruiken voor ontwikkelingsomgevingen of voor berekeningen met tussentijdse resultaten die op S3 of in een database worden opgeslagen, maar niet voor productie. Er zijn derden-oplossingen die het gebruik van spot instances in productie mogelijk maken, maar voor onze cases zijn er veel haken en ogen, dus hebben we ze niet geïmplementeerd. De methode die in dit artikel wordt beschreven, werkt volledig binnen de standaardfunctionaliteit van AWS, zonder extra scripts, cronjobs, enz.

Hieronder volgen een aantal screenshots die de prijsontwikkeling van spot instances tonen.

m5.large in de regio eu-west-1 (Ierland). De prijs is gedurende 3 maanden voornamelijk stabiel, momenteel is de besparing 2.9x.

m5.large in de regio us-east-1 (N. Virginia). De prijs varieert voortdurend over een periode van 3 maanden, momenteel is de besparing tussen 2.3x en 2.8x afhankelijk van de beschikbaarheidszone.

t3.small in de regio us-east-1 (N. Virginia). De prijs is gedurende 3 maanden stabiel, momenteel is de besparing 3.4x.

Architectuur van de service

De basisarchitectuur van de service waarover we in dit artikel zullen spreken, is weergegeven in de onderstaande diagram.

Application Load Balancer → EC2 Target Group → Elastic Container Service

Als load balancer wordt de Application Load Balancer (ALB) gebruikt, die aanvragen naar de EC2 Target Group (TG) stuurt. TG is verantwoordelijk voor het openen van poorten op de instances voor de ALB en het koppelen van deze aan de poorten van de Elastic Container Service (ECS) containers. ECS is de tegenhanger van Kubernetes in AWS, die verantwoordelijk is voor het beheren van Docker-containers.

Op één instantie kunnen meerdere werkende containers met dezelfde poorten draaien, dus we kunnen deze niet vast instellen. ECS meldt TG dat het een nieuwe taak start (in de terminologie van Kubernetes wordt dit een pod genoemd), deze controleert beschikbare poorten op de instantie en wijst er een toe voor de startende taak. TG controleert ook regelmatig of de instantie en de API daarop functioneren met behulp van een health check, en als het problemen waarneemt, stopt het met het doorsturen van verzoeken daarheen.

EC2 Auto Scaling Groups + ECS Capaciteitsproviders

In het bovenstaande diagram is de EC2 Auto Scaling Groups (ASG) service niet weergegeven. Uit de naam blijkt dat deze verantwoordelijk is voor het schalen van instanties. Tot voor kort had AWS geen ingebouwde mogelijkheid om het aantal actieve machines vanuit ECS te beheren. ECS stelde in staat om het aantal taken te schalen, bijvoorbeeld op basis van CPU-, RAM-gebruik of het aantal verzoeken. Maar als taken alle beschikbare instanties gebruikten, werden er geen nieuwe machines automatisch opgestart.

Dit veranderde met de komst van ECS Capaciteitsproviders (ECS CP). Nu kan elke service in ECS worden gekoppeld aan een ASG, en als taken niet meer passen op de actieve instanties, zullen er nieuwe worden opgestart (maar binnen de vastgestelde limieten van de ASG). Dit werkt ook in omgekeerde richting; als ECS CP inactieve instanties zonder taken ziet, geeft het ASG de opdracht om deze uit te schakelen. ECS CP heeft de mogelijkheid om een doelpercentage van de belasting van instanties op te geven, zodat een aantal machines altijd vrij is voor snelle schaalvergroting van taken; daarover later meer.

EC2 Launch Templates

De laatste service waarover ik zal vertellen voordat ik verder ga met een gedetailleerde beschrijving van het opzetten van deze infrastructuur, zijn de EC2 Launch Templates. Hiermee kunt u een sjabloon maken dat gebruikt zal worden voor het opstarten van alle machines, zodat u dit niet telkens opnieuw hoeft te doen. Hier kunt u het type machine selecteren, de beveiligingsgroep, de schijfimage en veel andere parameters. Ook kunt u gebruikersgegevens opgeven die op alle opgestarte instanties worden geladen. In de gebruikersgegevens kunnen scripts worden uitgevoerd, bijvoorbeeld om de inhoud van een bestand te bewerken. configuratie van de ECS-agent.

Een van de meest belangrijke parameters van configuratie in dit artikel is ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Als deze parameter is ingeschakeld, zal ECS zodra het een signaal ontvangt dat de spotinstantie wordt beëindigd, alle taken die erop draaien in de status Draining zetten. Er kunnen geen nieuwe taken aan deze instantie worden toegewezen; als er taken zijn die willen worden uitgevoerd, worden ze geannuleerd. Verzoeken van de load balancer worden ook gestopt. Een melding van de verwijdering van de instantie komt 2 minuten voor het feitelijke evenement. Als uw service geen taken langer dan 2 minuten uitvoert en niets op de schijf opslaat, kunt u spotinstellingen gebruiken zonder dataverlies.

Wat betreft de schijf — AWS heeft onlangs mogelijk gemaakt om Elastic File System (EFS) samen met ECS te gebruiken; met dit schema vormt de schijf zelfs geen belemmering, maar we hebben dit niet getest, omdat we in principe geen schijf nodig hebben voor statusopslag. Standaard zullen bij ontvangst van SIGINT (verzonden op het moment dat de taak in de status Draining gaat) alle actieve taken binnen 30 seconden worden gestopt, zelfs als ze niet zijn afgerond. Deze tijd kan worden gewijzigd met de parameter ECS_CONTAINER_STOP_TIMEOUT. Het is belangrijk om deze niet op meer dan 2 minuten in te stellen voor spotmachines.

Een service maken

Laten we direct overgaan op het maken van de beschreven service. Onderweg zal ik nog een aantal nuttige punten beschrijven die eerder niet zijn genoemd. In wezen is dit een stapsgewijze handleiding, maar enkele heel basis of zeer specifieke gevallen zal ik niet behandelen. Alle acties worden uitgevoerd in de visuele AWS-console, maar ze kunnen ook programmatisch worden gereproduceerd met CloudFormation of Terraform. Bij Adapty gebruiken we Terraform.

EC2 Launch Template

In deze service wordt een configuratie van de machines gemaakt die zullen worden gebruikt. Het beheer van sjablonen vindt plaats in de sectie EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — we geven de schijfafbeelding op waarmee alle instanties worden gestart. Voor ECS moet in de meeste gevallen het geoptimaliseerde beeld van Amazon worden gebruikt. Dit wordt regelmatig bijgewerkt en bevat alles wat nodig is voor de werking van ECS. Om de actuele AMI-ID te achterhalen, gaan we naar de pagina Amazon ECS-optimized AMIs, kiezen de gebruikte regio en kopiëren de AMI-ID voor die regio. Bijvoorbeeld, voor de regio us-east-1 is de actuele ID op het moment van schrijven ami-00c7c1cf5bdc913ed. Deze ID moet in het veld Specify a custom value worden ingevoerd.

Instance type — geef het type instantie op. Kies degene die het beste past bij uw taak.

Sleutelpair (inloggen) — geef het certificaat op waarmee verbinding kan worden gemaakt met de instantie via SSH, indien nodig.

Netwerkinstellingen — geef de netwerkparameters op. Netwerkplatform in de meeste gevallen moet dit Virtual Private Cloud (VPC) zijn. Beveiligingsgroepen — beveiligingsgroepen voor uw instanties. Aangezien we een load balancer voor de instanties gaan gebruiken, raad ik aan hier een groep op te geven die alleen inkomende verbindingen vanaf de load balancer toestaat. Dat wil zeggen, u heeft 2 beveiligingsgroepen: een voor de load balancer die inkomende (inbound) verbindingen vanaf overal op poorten 80 (http) en 443 (https) toestaat, en een tweede voor machines die inkomende verbindingen op willekeurige poorten van de load balancer-groep toestaat. Uitgaande (outbound) verbindingen in beide groepen moeten op het TCP-protocol voor alle poorten naar alle adressen worden geopend. U kunt poorten en adressen voor uitgaande verbindingen beperken, maar dan moet u constant controleren dat u niet probeert verbinding te maken via een gesloten poort.

Opslag (volumes) — geef de schijfparameters voor de machines op. De schijfgrootte mag niet kleiner zijn dan wat er in de AMI is opgegeven, voor ECS Geoptimaliseerd — 30 GiB.

Geavanceerde details — geef aanvullende parameters op.

Aankoopoptie — willen we spottestinstanties kopen. We willen dat, maar hier zullen we dit vinkje niet zetten, we configureren dit in de Auto Scaling Group, daar zijn meer opties.

IAM instantieprofiel — geef de rol op waarmee de instanties worden gestart. Om ervoor te zorgen dat de instanties in ECS werken, hebben ze rechten nodig, die meestal in de rol zitten ecsInstanceRole. In sommige gevallen kan deze worden aangemaakt, als dat niet het geval is, dan is hier handleiding hoe dit te doen. Na het aanmaken geven we deze op in de sjabloon.
Daarna volgen er veel parameters, meestal kunnen de standaardwaarden worden behouden, maar elk van hen heeft een duidelijke beschrijving. Ik geef altijd de parameters EBS-geoptimaliseerde instantie en T2/T3 Unlimited op, als ze worden gebruikt burstable instanties.

Gebruikersgegevens — geef gebruikersgegevens op. We gaan het bestand bewerken /etc/ecs/ecs.config, waarin de configuratie van de ECS-agent is opgenomen.
Een voorbeeld van hoe de gebruikersgegevens eruit kunnen zien:

#!/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 — de parameter geeft aan dat de instantie behoort tot een cluster met de opgegeven naam, wat betekent dat dit cluster zijn taken op deze server kan plaatsen. We hebben momenteel geen cluster aangemaakt, maar we zullen deze naam gebruiken bij het creëren.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — de parameter geeft aan dat bij het ontvangen van een signaal om de spot-instantie uit te schakelen, alle taken op die instantie moeten worden overgezet naar de status Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m — de parameter geeft aan dat na het ontvangen van het SIGINT-signaal, alle taken 1 minuut de tijd hebben voordat ze worden beëindigd.

ECS_ENGINE_AUTH_TYPE=docker — de parameter geeft aan dat de docker-schema als authenticatiemechanisme wordt gebruikt.

ECS_ENGINE_AUTH_DATA=... — verbindingsparameters voor de privé container registry, waar uw Docker-images worden opgeslagen. Als het openbaar is, hoeft u niets op te geven.

In dit artikel zal ik een openbaar image uit Docker Hub gebruiken, dus ik hoef geen parameters op te geven. ECS_ENGINE_AUTH_TYPE en ECS_ENGINE_AUTH_DATA dat is niet nodig.

Goed om te weten: het wordt aanbevolen om AMI regelmatig bij te werken, omdat in nieuwe versies de versies van Docker, Linux, ECS-agent en meer worden bijgewerkt. Om dit niet te vergeten, kunt u meldingen instellen over nieuwe versies. U kunt e-mailmeldingen ontvangen en handmatig bijwerken, of u kunt een Lambda-functie schrijven die automatisch een nieuwe versie van de Launch Template met het bijgewerkte AMI aanmaakt.

EC2 Auto Scaling Group

De Auto Scaling Group is verantwoordelijk voor het starten en schalen van instanties. Het beheer van de groepen vindt plaats in de sectie EC2 -> Auto Scaling -> Auto Scaling Groups.

Launch template — we kiezen de sjabloon die in de vorige stap is aangemaakt. Laat de versie standaard.

Purchase options and instance types — we geven de typen instanties voor het cluster op. Adhere to launch template gebruikt het type instantie uit de Launch Template. Combine purchase options and instance types maakt flexibele configuratie van de typen instanties mogelijk. We zullen deze gebruiken.

Optional On-Demand base — het aantal standaard, niet-spot instanties die altijd zullen draaien.

On-Demand percentage above base — de procentuele verhouding van standaard en spot-instanties; 50-50 verdeelt gelijkmatig, 20-80 betekent dat er 4 spot-instanties worden gestart voor elke standaard instantie. In dit voorbeeld geef ik 50-50 op, maar in de praktijk doen we vaker 20-80, en in sommige gevallen 0-100.

Instance types — hier kunnen extra types instanties worden opgegeven die in het cluster zullen worden gebruikt. We hebben dit nooit gebruikt, omdat ik de betekenis van dit verhaal niet echt begrijp. Misschien heeft het te maken met de limieten voor specifieke soorten instanties, maar die kunnen eenvoudig worden verhoogd via ondersteuning. Als je een toepassing kent, lees ik het graag in de reacties)

Netwerk global log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check — netwerkinstellingen, kies VPC en subnetten voor de machines, in de meeste gevallen is het het beste om alle beschikbare subnetten te selecteren.

Load balancing — instellingen voor de load balancer, maar we zullen dit apart doen, hier raken we niets aan. Health checks zullen ook later worden ingesteld.

Groepsgrootte — we geven limieten op voor het aantal machines in het cluster en het gewenste aantal machines bij de start. Het aantal machines in het cluster zal nooit minder worden dan het minimaal opgegeven aantal en meer dan het maximaal opgegeven aantal, zelfs als het volgens de statistieken nodig is om te schalen.

Schaalbeleid — schalingparameters, maar we zullen schalen op basis van de draaiende ECS-taken, dus we zullen de schaling later instellen.

Instance scale-in bescherming — bescherming van instanties tegen verwijdering bij het naar beneden schalen. We schakelen dit in zodat de ASG de machine waarop actieve taken draaien niet verwijdert. De bescherming uitschakelen voor instanties zonder taken wordt gedaan door de ECS Capacity Provider.

Tags toevoegen — je kunt tags voor instanties opgeven (hiervoor moet het vakje 'Tag new instances' aangekruist zijn). Ik raad aan om de tag 'Name' op te geven, zodat alle instanties die binnen de groep worden gestart dezelfde naam hebben, wat het handig maakt om ze in de console te bekijken.

Na het aanmaken van de groep, open deze en ga naar het gedeelte Geavanceerde configuraties, waarom niet alle opties zichtbaar zijn tijdens de creatiefase in de console.

Beleid voor beëindiging — regels die in overweging worden genomen bij het verwijderen van instanties. Ze worden op volgorde toegepast. We gebruiken meestal de regels zoals op de afbeelding hieronder. Eerst worden de instanties met de oudste Launch Template verwijderd (bijvoorbeeld, als we de AMI hebben geüpdatet, hebben we een nieuwe versie gemaakt, maar alle instanties hebben het al overgenomen). Daarna worden de instanties gekozen die het dichtst bij de volgende berekeningsuur voor de facturering liggen. En vervolgens worden de oudste opstartdatum gekozen.

Goed om te weten: voor het bijwerken van alle machines in het cluster, is het handig om gebruik te maken van Instance Refresh. Door dit te combineren met de Lambda-functie uit de vorige stap, heeft u een volledig geautomatiseerd systeem voor het bijwerken van instanties. Voordat u alle machines bijwerkt, moet u de instance scale-in bescherming voor alle instanties in de groep uitschakelen. Dit gaat niet om de instellingen in de groep, maar specifiek om de bescherming op de machines zelf, wat gedaan kan worden op het tabblad Instance management.

Application Load Balancer en EC2 Target Group

De load balancer wordt aangemaakt in het gedeelte EC2 → Load Balancing → Load Balancers. We zullen de Application Load Balancer gebruiken, het vergelijken van verschillende soorten load balancers kan worden gelezen op de service pagina.

Listeners — het is logisch om poorten 80 en 443 te maken en een omleiding van 80 naar 443 te maken met behulp van regels van de load balancer.

Beschikbaarheidszones — in de meeste gevallen kiezen we voor alle beschikbaarheidszones.

Configureer beveiligingsinstellingen — hier wordt het SSL-certificaat voor de load balancer opgegeven, de meest handige optie is om het certificaat in ACM te maken. Voor meer informatie over de verschillen beveiligingsbeleid kan worden gelezen op de documentatie, u kunt de standaardkeuze ELBSecurityPolicy-2016-08aanhouden. Na het aanmaken van de load balancer, ziet u de DNS-naam, waarvoor u een CNAME moet instellen voor uw domein. Dit is hoe het eruitziet in Cloudflare.

Security Group — we maken of kiezen een beveiligingsgroep voor de load balancer, meer hierover is hierboven besproken in het gedeelte EC2 Launch Template → Netwerkinstellingen.

Target group — we maken een groep die verantwoordelijk is voor het routeren van verzoeken van de load balancer naar de machines en hun beschikbaarheid controleert, zodat ze in geval van problemen kunnen worden vervangen. Targettype moet Instance zijn, Protocol en Poort en alles, als u HTTPS gebruikt voor communicatie tussen de load balancer en de instanties, moet u het certificaat op hen uploaden. In dit voorbeeld zullen we dit niet doen, we laten gewoon poort 80.

Health checks — parameters voor de controle op de beschikbaarheid van de service. In de echte service moet dit een afzonderlijk verzoek zijn dat belangrijke delen van de bedrijfslogica implementeert, in dit voorbeeld laat ik de standaardinstellingen staan. Verder kunt u het verzoekinterval, time-out, codes voor succesvolle antwoorden, enz. kiezen. In ons voorbeeld geven we Success codes 200-399 op, omdat de Docker-image die wordt gebruikt, de code 304 retourneert.

Registreer doelen — hier worden de machines voor de groep geselecteerd, maar in ons geval zal ECS dit doen, dus we slaan deze stap gewoon over.

Goed om te weten: op het niveau van de load balancer kunt u logboeken inschakelen die worden opgeslagen in S3 op een bepaald in het formaat. Van daaruit kunnen ze worden geëxporteerd naar externe services voor analyse, of SQL-query's kunnen direct op de gegevens in S3 worden uitgevoerd met help van Athena. Dit is handig en werkt zonder extra code. Ook raad ik aan om het verwijderen van logs uit de S3-bucket in te stellen na een bepaalde periode.

ECS Taakdefinitie

In de vorige stappen hebben we alles gecreëerd dat met de infrastructuur van de service te maken heeft, nu gaan we over naar de beschrijving van de containers die we zullen starten. Dit wordt gedaan in de sectie ECS → Taakdefinities.

Compatibiliteit van het type lancering — kies EC2.

IAM-rol voor taakuitvoering — kiezen ecsTaskExecutionRole. Hiermee worden logs geschreven, toegang verleend tot geheime variabelen, enz.

In de sectie Containerdefinities klikken we op Container toevoegen.

Afbeelding — link naar het beeld met de projectcode, in dit voorbeeld gebruik ik een openbaar beeld van Docker Hub bitnami/node-example:0.0.1.

Geheugenlimieten — geheugenlimieten voor de container. Harde limiet — harde limiet, als de container de opgegeven waarde overschrijdt, wordt het commando docker kill uitgevoerd en de container wordt onmiddellijk beëindigd. Zachte limiet — zachte limiet, de container kan de opgegeven waarde overschrijden, maar tijdens het plaatsen van taken op machines wordt rekening gehouden met deze parameter. Bijvoorbeeld, als de machine 4 GiB RAM heeft en de zachte limiet van de container 2048 MiB is, kunnen er maximaal 2 taken met deze container op deze machine worden uitgevoerd. In werkelijkheid is 4 GiB RAM iets minder dan 4096 MiB, dit kan worden bekeken op het tabblad ECS-instanties in de cluster. De zachte limiet mag niet groter zijn dan de harde limiet. Het is belangrijk te begrijpen dat als er meerdere containers in één taak zijn, hun limieten worden opgeteld.

Poortkoppelingen — tot Hostpoort we geven 0 op, dit betekent dat de poort dynamisch zal worden toegewezen, deze wordt gevolgd door de Target Group. Containerpoort — de poort waarop uw applicatie draait, vaak ingesteld in de uitvoeringsopdracht of toegewezen in de code van uw applicatie, Dockerfile, enz. Voor ons voorbeeld gebruiken we 3000, omdat dit is aangegeven in Dockerfile het gebruikte beeld.

Health check — parameters voor het controleren van de werking van de container, niet te verwarren met degene die is ingesteld in de Target Group.

Omgeving — omgevingsinstellingen. CPU-eenheden — lijkt op geheugentesten, maar dan voor de processor. Elke processor-core vertegenwoordigt 1024 eenheden, dus als de server een dual-core processor heeft en de containerwaarde is ingesteld op 512, dan kunnen er op één server 4 taken met deze container worden uitgevoerd. CPU-eenheden komen altijd overeen met het aantal cores; ze kunnen niet iets minder zijn zoals bij geheugen.

Commando — commando om een service binnen de container te starten, alle parameters worden door komma's gescheiden. Dit kan gunicorn, npm, etc. zijn. Als dit niet is opgegeven, wordt de waarde van de CMD-directive in het Dockerfile gebruikt. We geven aan npm,start.

Omgevingsvariabelen — omgevingsvariabelen van de container. Dit kunnen zowel gewone tekstgegevens zijn als geheime variabelen uit Secrets Manager of Parameter Store.

Opslag en Logging — hier configureren we het loggen naar CloudWatch Logs (dienst voor logs van AWS). Het is voldoende om het vakje Auto-configure CloudWatch Logs in te schakelen. Na het maken van de Task Definition wordt er automatisch een loggroep in CloudWatch aangemaakt. Standaard worden logs hierin eeuwig bewaard; ik raad aan de Retentieperiode van Never Expire op te wijzigen naar de vereiste termijn. Dit doe je in CloudWatch Log groups, klik op de huidige periode en kies een nieuwe.

ECS Cluster en ECS Capacity Provider

Ga naar het gedeelte ECS → Clusters om een cluster te maken. Kies als sjabloon EC2 Linux + Networking.

Clusternaam — erg belangrijk, gebruik hier dezelfde naam als opgegeven in de Launch Template onder de parameter ECS_CLUSTER, in ons geval — DemoApiClusterProd. Vink het vakje Create an empty cluster aan. Optioneel kun je Container Insights inschakelen om metrics over de services in CloudWatch te bekijken. Als je alles goed hebt gedaan, zie je in het gedeelte ECS Instances de machines die zijn aangemaakt in de Auto Scaling group.

Ga naar het tabblad Capacity Providers en we creëren een nieuwe. Ik herinner eraan dat deze nodig is om de creatie en het uitschakelen van machines te beheren, afhankelijk van het aantal actieve ECS-taken. Het is belangrijk op te merken dat de provider slechts aan één groep kan worden gekoppeld.

Auto Scaling group — kies de groep die eerder is gemaakt.

Beheerd schalen — schakelen we in, zodat de provider de service kan schalen.

Doelcapaciteit % — welk percentage van de belasting van de machines met taken hebben we nodig. Als je 100% opgeeft, zijn alle machines altijd bezet met actieve taken. Als je 50% opgeeft, zijn de helft van de machines altijd vrij. In dat geval, als er een plotselinge piek in de belasting is, zullen nieuwe taken onmiddellijk op de beschikbare machines worden geplaatst zonder te hoeven wachten op het uitrollen van instanties.

Beheerde beëindigingsbescherming — hierbij schakelen we deze parameter in, waardoor de provider de bescherming van instanties kan verwijderen. Dit gebeurt wanneer er geen actieve taken op de machine zijn en stelt het Target capacity % mogelijk.

ECS Service en schalingconfiguratie

Laatste stap :) Om een service te creëren, moet je de eerder gemaakte cluster openen en naar het tabblad Services gaan.

Starttype — je moet klikken op Switch to capacity provider strategy en de eerder gemaakte provider selecteren.

Taakdefinitie — we kiezen de eerder gemaakte Taakdefinitie en zijn revisie.

Dienstnaam — om verwarring te voorkomen, geven we altijd dezelfde op als de Taakdefinitie.

Servicetype — altijd Replica.

Aantal taken — het gewenste aantal actieve taken in de service. Deze parameter wordt beheerd door de schaling, maar moet nog steeds worden opgegeven.

Minimaal gezond percentage en Maximaal percentage — bepalen het gedrag van taken tijdens de implementatie. De standaardwaarden zijn 100 en 200, wat betekent dat bij de implementatie het aantal taken wordt verdubbeld en daarna weer naar het gewenste aantal terugkeert. Als je 1 taak draait, min=0, en max=100, dan zal deze tijdens de implementatie worden beëindigd en vervolgens weer worden opgepakt, wat betekent dat er downtime is. Als er 1 taak draait, min=50, max=150, dan vindt de implementatie helemaal niet plaats, omdat je 1 taak niet in tweeën kunt splitsen of met anderhalf kunt verhogen.

Implementatietype — we laten Rolling update staan.

Plaatsingstemplates — regels voor het plaatsen van taken op machines. Standaard staat AZ Balanced Spread — dit betekent dat elke nieuwe taak op een nieuwe instantie wordt geplaatst totdat de machines in alle beschikbaarheidszones operationeel zijn. Gewoonlijk maken we BinPack — CPU en Spread — AZ, bij dit beleid worden taken zo dicht mogelijk bij elkaar op één machine op CPU geplaatst. Bij de noodzaak om een nieuwe machine te creëren, wordt deze in een nieuwe beschikbaarheidszone aangemaakt.

Type load balancer — we kiezen Application Load Balancer.

IAM-rol voor de service — we kiezen ecsServiceRole.

Naam van de load balancer — we kiezen de eerder gemaakte balancer.

Gezondheidscontrole-graceperiode — pauze voordat de werkingcontroles na het uitrollen van een nieuwe taak worden uitgevoerd, wij zetten meestal 60 seconden.

Container om te load balancen — in het veld Naam van de doelfgroep kiezen we de eerder gemaakte groep, en alles wordt automatisch ingevuld.

Service Auto Scaling — parameters voor de autoschaling van de service. We kiezen Configure Service Auto Scaling to adjust your service’s desired count. We stellen het minimale en maximale aantal taken in bij het schalen.

IAM-rol voor Service Auto Scaling — we kiezen AWSServiceRoleForApplicationAutoScaling_ECSService.

Automatische taak_scalering beleidsregels — regels voor schaling. Er zijn 2 soorten:

Doel tracking — het volgen van een doelmetric (gebruik van CPU/RAM of het aantal verzoeken per taak). Bijvoorbeeld, we willen dat de gemiddelde CPU-belasting 85% is. Wanneer deze hoger wordt, zullen nieuwe taken worden toegevoegd totdat deze weer naar de doelwaarde terugkeert. Als de belasting lager is, worden taken verwijderd, tenzij er een bescherming tegen neerwaartse schaling is ingeschakeld (Schaling-in uitschakelen).
Stap schaling — reactie op willekeurige gebeurtenissen. Hier kunt u een reactie op elk evenement (CloudWatch Alarm) instellen. Wanneer dit zich voordoet, kunt u een opgegeven aantal taken toevoegen of verwijderen, of het exacte aantal taken opgeven.

De service kan meerdere schalingsregels hebben, wat nuttig kan zijn, maar let erop dat ze niet met elkaar in conflict komen.

Conclusie

Als u de instructies heeft gevolgd en dezelfde Docker-image heeft gebruikt, zou uw service deze pagina moeten retourneren.

We hebben een sjabloon gemaakt waarop alle machines in de service worden gestart. We hebben ook geleerd hoe we machines kunnen bijwerken wanneer het sjabloon verandert.
We hebben de afhandeling van het stop-signaal van de spot-instanties ingesteld, zodat binnen een minuut na ontvangst alle actieve taken van de machine worden verwijderd en er niets verloren gaat of onderbroken wordt.
We hebben een load balancer opgezet om de belasting gelijkmatig over de machines te verdelen.
We hebben een service opgezet die draait op spot-instanties, wat de kosten voor de machines met ongeveer 3 keer vermindert.
We hebben autoscaling ingesteld in beide richtingen om te kunnen omgaan met toenemende belastingen, maar tegelijkertijd niet te betalen voor inactiviteit.
We gebruiken Capacity Provider, zodat de applicatie de infrastructuur (machines) beheert en niet andersom.
We hebben het goed gedaan.

Als u voorspelbare pieken in de belasting heeft, bijvoorbeeld wanneer u grote e-mailcampagnes uitvoert, kunt u schaling instellen op schema.

U kunt ook schaling maken op basis van gegevens uit verschillende delen van uw systeem. Bijvoorbeeld, we hebben functionaliteit voor het verzenden van persoonlijke promotieaanbiedingen gebruikers van de mobiele applicatie. Soms wordt de campagne naar meer dan 1M mensen gestuurd. Na zo'n campagne zien we altijd een grote stijging van verzoeken aan de API, aangezien veel gebruikers tegelijkertijd de app openen. Dus als we zien dat er in de wachtrij voor het verzenden van promo-pushmeldingen aanzienlijk meer zijn dan de standaardindicatoren, kunnen we onmiddellijk meerdere extra machines en taken starten om klaar te zijn voor de belasting.

Ik ben benieuwd of jullie in de comments interessante cases willen delen over het gebruik van spot-instanties en ECS, of iets over schaalvergroting.

Binnenkort komen er artikelen over hoe we duizenden analytische evenementen per seconde verwerken op een voornamelijk serverless stack (met geld) en hoe de deployment van services werkt met behulp van GitLab CI en Terraform Cloud.

Volg ons, het zal interessant zijn!

Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. Log in, alstublieft.