Dag Allemaal! Mijn naam is Kirill, ik ben CTO bij Adapty. Het grootste deel van onze architectuur is gebaseerd op AWS, en vandaag zal ik het hebben over hoe we de serverkosten drie keer hebben verlaagd door spotinstances in een productieomgeving te gebruiken, en hoe we de automatische schaling ervan kunnen instellen. Eerst zal er een overzicht zijn van hoe het werkt, en daarna gedetailleerde instructies om aan de slag te gaan.
Wat zijn spotinstanties?
instances zijn servers van andere AWS-gebruikers die momenteel inactief zijn, en ze verkopen ze met een grote korting (Amazon schrijft tot 90%, in onze ervaring ~3x, varieert afhankelijk van de regio, AZ en instancetype). Het belangrijkste verschil met gewone apparaten is dat ze op elk moment kunnen worden uitgeschakeld. Daarom geloofden we lange tijd dat het normaal was om ze te gebruiken voor nieuwe omgevingen, of voor taken om iets te berekenen, met tussenresultaten opgeslagen op S3 of in de database, maar niet voor verkoop. Er zijn oplossingen van derden waarmee je spots tijdens de productie kunt gebruiken, maar er zijn veel krukken voor onze zaak, dus die hebben we niet geïmplementeerd. De in het artikel beschreven aanpak werkt volledig binnen de standaard AWS-functionaliteit, zonder extra scripts, kronen etc.
Hieronder vindt u enkele schermafbeeldingen die de prijsgeschiedenis voor spotinstanties tonen.
m5.groot in de regio eu-west-1 (Ierland). De prijs is al drie maanden grotendeels stabiel en bespaart momenteel 3x.
m5.groot in de regio us-east-1 (N. Virginia). De prijs verandert voortdurend gedurende 3 maanden en bespaart momenteel van 2.3x tot 2.8x, afhankelijk van de beschikbaarheidszone.
t3.small in de regio us-east-1 (N. Virginia). De prijs is al 3 maanden stabiel en bespaart momenteel 3.4x.
Service-architectuur
De basisarchitectuur van de service waar we het in dit artikel over zullen hebben, wordt weergegeven in het onderstaande diagram.
Applicatie Load Balancer → EC2 Doelgroep → Elastic Container Service
Als balancer wordt de Application Load Balancer (ALB) gebruikt, die verzoeken verzendt naar de EC2 Doelgroep (TG). TG is verantwoordelijk voor het openen van poorten op instances voor ALB's en het verbinden ervan met poorten van Elastic Container Service (ECS)-containers. ECS is een analoog van Kubernetes in AWS, dat Docker-containers beheert.
Eén exemplaar kan meerdere actieve containers hebben met dezelfde poorten, dus we kunnen deze niet vast instellen. ECS vertelt TG dat het een nieuwe taak lanceert (in Kubernetes-terminologie wordt dit een pod genoemd), het controleert op vrije poorten op de instance en wijst een daarvan toe aan de gelanceerde taak. TG controleert ook regelmatig of de instance en de API eraan werken met behulp van een health check, en als er problemen optreden, stopt het met het versturen van verzoeken daarheen.
EC2 Auto Scaling Groups + ECS-capaciteitsaanbieders
Het bovenstaande diagram toont niet de EC2 Auto Scaling Groups (ASG)-service. Uit de naam kun je begrijpen dat het verantwoordelijk is voor het schalen van instanties. Tot voor kort had AWS echter geen ingebouwde mogelijkheid om het aantal actieve machines vanuit ECS te beheren. ECS maakte het mogelijk om het aantal taken te schalen, bijvoorbeeld op basis van CPU-gebruik, RAM of aantal verzoeken. Maar als taken alle vrije exemplaren bezetten, werden er niet automatisch nieuwe machines gemaakt.
Dit is veranderd met de komst van ECS Capacity Providers (ECS CP). Nu kan elke service in ECS worden gekoppeld aan een ASG, en als de taken niet passen op de actieve instanties, zullen er nieuwe worden aangemaakt (maar binnen de vastgestelde ASG-limieten). Dit werkt ook in de tegenovergestelde richting: als ECS CP inactieve exemplaren zonder taken ziet, geeft het de ASG-opdracht om ze af te sluiten. ECS CP heeft de mogelijkheid om een doelpercentage van de instancebelasting te specificeren, zodat een bepaald aantal machines altijd vrij is voor het snel schalen van taken; ik zal hier later over praten.
EC2-lanceringssjablonen
De laatste service waar ik het over zal hebben voordat ik in detail ga over het creëren van deze infrastructuur, is EC2 Launch Templates. Hiermee kunt u een sjabloon maken op basis waarvan alle machines zullen starten, zodat u dit niet elke keer opnieuw hoeft te doen. Hier kunt u het type machine selecteren dat u wilt starten, de beveiligingsgroep, de schijfkopie en vele andere parameters. U kunt ook gebruikersgegevens opgeven die naar alle gelanceerde exemplaren worden geüpload. U kunt scripts uitvoeren in gebruikersgegevens, u kunt bijvoorbeeld de inhoud van een bestand bewerken .
Een van de belangrijkste configuratieparameters voor dit artikel is = waar. Als deze parameter is ingeschakeld, worden alle taken die daaraan werken, zodra ECS een signaal ontvangt dat een spot-instance wordt verwijderd, overgezet naar de status Aftappen. Er worden geen nieuwe taken aan deze instantie toegewezen. Als er taken zijn die er nu naartoe willen worden uitgerold, worden deze geannuleerd. Ook verzoeken van de balancer komen niet meer binnen. De melding over het verwijderen van een exemplaar komt 2 minuten vóór de daadwerkelijke gebeurtenis. Als uw service daarom geen taken langer dan twee minuten uitvoert en niets op schijf opslaat, kunt u spotinstances gebruiken zonder gegevensverlies.
Wat betreft schijf - AWS onlangs Het is mogelijk om het Elastic File System (EFS) samen met ECS te gebruiken; met dit schema vormt zelfs de schijf geen obstakel, maar we hebben dit niet geprobeerd, omdat we de schijf in principe niet nodig hebben om de status op te slaan. Standaard worden na ontvangst van SIGINT (verzonden wanneer een taak wordt overgedragen naar de status Aftappen) alle lopende taken na 30 seconden gestopt, zelfs als ze nog niet zijn voltooid; u kunt deze tijd wijzigen met behulp van de parameter . Het belangrijkste is om het voor spotmachines niet langer dan 2 minuten in te stellen.
Een dienst creëren
Laten we verder gaan met het maken van de beschreven service. Tijdens het proces zal ik bovendien een aantal nuttige punten beschrijven die hierboven niet zijn genoemd. Over het algemeen is dit een stapsgewijze instructie, maar ik zal enkele zeer fundamentele of, integendeel, zeer specifieke gevallen niet bespreken. Alle acties worden uitgevoerd in de visuele console van AWS, maar kunnen programmatisch worden gereproduceerd met behulp van CloudFormation of Terraform. Bij Adapty gebruiken we Terraform.
EC2-lanceringssjabloon
Deze service creëert een configuratie van machines die zullen worden gebruikt. Sjablonen worden beheerd in de sectie EC2 -> Instances -> Startsjablonen.
Afbeelding van Amazon-machine (AMI) — specificeer de schijfkopie waarmee alle exemplaren worden gestart. Voor ECS is het in de meeste gevallen de moeite waard om de geoptimaliseerde afbeelding van Amazon te gebruiken. Het wordt regelmatig bijgewerkt en bevat alles wat nodig is om ECS te laten werken. Ga naar de pagina om de huidige afbeeldings-ID te achterhalen , selecteer de regio die u gebruikt en kopieer de AMI-ID daarvoor. Voor de regio us-east-1 is dit bijvoorbeeld de huidige ID op het moment van schrijven ami-00c7c1cf5bdc913ed. Deze ID moet worden ingevoegd in het item Een aangepaste waarde opgeven.
Instantietype — geef het exemplaartype aan. Kies degene die het beste bij uw taak past.
Sleutelpaar (inloggen) — geef indien nodig een certificaat op waarmee u via SSH verbinding kunt maken met de instantie.
Netwerkinstellingen — specificeer de netwerkparameters. Netwerkplatform in de meeste gevallen zou er sprake moeten zijn van een Virtual Private Cloud (VPC). Beveiligingsgroepen — beveiligingsgroepen voor uw instanties. Omdat we vóór de instances een balancer gaan gebruiken, raad ik aan hier een groep op te geven die alleen inkomende verbindingen van de balancer toestaat. Dat wil zeggen dat u twee beveiligingsgroepen heeft, één voor de balancer, die inkomende verbindingen vanaf elke locatie op poort 2 (http) en 80 (https) toestaat, en de tweede voor machines, die inkomende verbindingen op alle poorten van de balancergroep toestaat. . Uitgaande verbindingen in beide groepen moeten worden geopend met behulp van het TCP-protocol naar alle poorten naar alle adressen. Je kunt poorten en adressen voor uitgaande verbindingen beperken, maar dan moet je constant in de gaten houden dat je niet probeert toegang te krijgen tot iets op een gesloten poort.
Opslag (volumes) — specificeer de schijfparameters voor de machines. De schijfgrootte kan niet kleiner zijn dan gespecificeerd in de AMI; voor ECS Optimized is dit 30 GiB.
Geavanceerde details — aanvullende parameters specificeren.
Aankoop optie – of we spotexemplaren willen kopen. Dat willen we, maar we zullen dit vakje hier niet aanvinken; we zullen het configureren in de Auto Scaling Group, daar zijn meer opties.
IAM-instantieprofiel — geef aan met welke rol de instanties zullen worden gelanceerd. Om instances in ECS te kunnen uitvoeren, hebben ze machtigingen nodig, die meestal in de rol te vinden zijn ecsInstanceRole. In sommige gevallen kan het worden gemaakt, zo niet, dan hier over hoe u dit moet doen. Na creatie geven we dit aan in de template.
Vervolgens zijn er veel parameters, in principe kun je overal standaardwaarden laten staan, maar elk ervan heeft een duidelijke beschrijving. Ik schakel altijd de voor EBS geoptimaliseerde instantie en T2/T3 Unlimited-opties in, indien gebruikt exemplaren.
Gebruiker tijd — gebruikersgegevens aangeven. Wij zullen het bestand bewerken /etc/ecs/ecs.config, dat de ECS-agentconfiguratie bevat.
Een voorbeeld van hoe 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.configECS_CLUSTER=DemoApiClusterProd — de parameter geeft aan dat de instantie tot een cluster met de opgegeven naam behoort, dat wil zeggen dat dit cluster zijn taken op deze server kan plaatsen. We hebben nog geen cluster aangemaakt, maar we zullen deze naam gebruiken bij het maken ervan.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — de parameter specificeert dat wanneer een signaal wordt ontvangen om een spotinstantie uit te schakelen, alle taken erop moeten worden overgedragen naar de status Aftappen.
ECS_CONTAINER_STOP_TIMEOUT=1m - de parameter specificeert dat alle taken na ontvangst van een SIGINT-signaal 1 minuut de tijd hebben voordat ze worden gedood.
ECS_ENGINE_AUTH_TYPE=docker — de parameter geeft aan dat het Docker-schema wordt gebruikt als autorisatiemechanisme
ECS_ENGINE_AUTH_DATA=... — verbindingsparameters met het privécontainerregister, waar uw Docker-images worden opgeslagen. Als het openbaar is, hoeft u niets op te geven.
Voor de doeleinden van dit artikel zal ik een openbare afbeelding van Docker Hub gebruiken, dus geef de parameters op ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA niet nodig.
Goed om te weten: Het wordt aanbevolen om de AMI regelmatig te updaten, omdat nieuwe versies versies van Docker, Linux, ECS-agent, etc. updaten. Om dit niet te vergeten, kunt u over de release van nieuwe versies. U kunt meldingen per e-mail ontvangen en handmatig bijwerken, of u kunt een Lambda-functie schrijven die automatisch een nieuwe versie van Launch Template maakt met een bijgewerkte AMI.
EC2 Automatische schalingsgroep
Auto Scaling Group is verantwoordelijk voor het starten en schalen van instanties. Groepen worden beheerd in de sectie EC2 -> Auto Scaling -> Auto Scaling Groups.
Lanceringssjabloon — selecteer de sjabloon die in de vorige stap is gemaakt. We laten de standaardversie staan.
Aankoopopties en exemplaartypen — specificeer de typen exemplaren voor het cluster. Houd u aan de startsjabloon en gebruikt het instantietype uit de startsjabloon. Door aankoopopties en exemplaartypen te combineren, kunt u exemplaartypen flexibel configureren. Wij zullen het gebruiken.
Optionele On-Demand-basis — het aantal reguliere, niet-spot-exemplaren dat altijd zal werken.
On-Demand-percentage boven basis — procentuele verhouding tussen reguliere en spot-instanties, 50-50 wordt gelijkelijk verdeeld, 20-80 voor elke reguliere instantie worden 4 spot-exemplaren verhoogd. Voor dit voorbeeld geef ik 50-50 aan, maar in werkelijkheid doen we meestal 20-80, in sommige gevallen 0-100.
Instantietypen — hier kunt u aanvullende typen exemplaren opgeven die in het cluster worden gebruikt. We hebben het nooit gebruikt omdat ik de betekenis van het verhaal niet echt begrijp. Misschien komt dit door de limieten voor specifieke soorten instances, maar deze kunnen eenvoudig worden verhoogd via ondersteuning. Als u de toepassing kent, lees ik deze graag in de opmerkingen)
Netwerk — netwerkinstellingen, selecteer VPC en subnetten voor machines, in de meeste gevallen moet u alle beschikbare subnetten selecteren.
Load balancing - balancerinstellingen, maar we zullen dit apart doen, we zullen hier niets aanraken. Gezondheidchecks wordt ook later geconfigureerd.
Groepsgrootte — we geven bij de start de grenzen aan van het aantal machines in het cluster en het gewenste aantal machines. Het aantal machines in het cluster zal nooit minder zijn dan het opgegeven minimum en nooit meer dan het maximum, zelfs als er moet worden geschaald volgens de statistieken.
Schaalbeleid — Schaalparameters, maar we zullen schalen op basis van de lopende ECS-taken, dus we zullen de schaling later configureren.
Bescherming tegen inschalen van instanties — bescherming van exemplaren tegen verwijdering bij het terugschalen. We schakelen het in zodat ASG de machine met actieve taken niet verwijdert. ECS Capacity Provider schakelt de bescherming uit voor instances die geen taken hebben.
Voeg tags toe — u kunt tags opgeven voor exemplaren (hiervoor moet het selectievakje Nieuwe exemplaren taggen aangevinkt zijn). Ik raad aan om de Name-tag op te geven, dan zullen alle instanties die binnen de groep worden gelanceerd dezelfde naam hebben, en het is handig om ze in de console te bekijken.
Nadat u de groep heeft aangemaakt, opent u deze en gaat u naar de sectie Geavanceerde configuraties Waarom zijn niet alle opties zichtbaar in de console tijdens de aanmaakfase.
Beëindigingsbeleid — regels waarmee rekening wordt gehouden bij het verwijderen van exemplaren. Ze worden in volgorde toegepast. Meestal gebruiken wij degene op de onderstaande afbeelding. Eerst worden instanties met de oudste opstartsjabloon verwijderd (als we bijvoorbeeld de AMI hebben bijgewerkt, hebben we een nieuwe versie gemaakt, maar alle instanties zijn erin geslaagd ernaar over te schakelen). Vervolgens worden de exemplaren geselecteerd die het dichtst bij het volgende facturatieuur liggen. En dan worden de oudste geselecteerd op basis van de lanceringsdatum.
Goed om te weten: om alle machines in een cluster bij te werken, handig in gebruik . Als je dit combineert met de Lambda-functie uit de vorige stap, heb je een volledig geautomatiseerd instance-updatesysteem. Voordat u alle machines bijwerkt, moet u de inschaalbeveiliging voor alle exemplaren in de groep uitschakelen. Geen configuratie in de groep, maar bescherming vanaf de machines zelf, dit gebeurt op het tabblad Instance management.
Applicatie Load Balancer en EC2 Doelgroep
De balancer wordt aangemaakt in de sectie EC2 → Load Balancing → Load Balancers. We zullen Application Load Balancer gebruiken; een vergelijking van verschillende soorten balancers kunt u lezen op .
luisteraars - het is zinvol om poorten 80 en 443 te maken en later om te leiden van 80 naar 443 met behulp van balancerregels.
Beschikbaarheidszones — in de meeste gevallen selecteren we toegankelijkheidszones voor iedereen.
Beveiligingsinstellingen configureren — het SSL-certificaat voor de balancer wordt hier aangegeven, de handigste optie is bij ACM. Over de verschillen Veiligheidsbeleid kan worden ingelezen , kunt u deze standaard geselecteerd laten ELBSecurityPolicy-2016-08. Nadat u de balancer heeft gemaakt, ziet u deze DNS-naam, die u nodig heeft om de CNAME voor uw domein te configureren. Zo ziet het er bijvoorbeeld uit in Cloudflare.
Beveiligingsgroep — maak of selecteer een beveiligingsgroep voor de balancer. Ik heb hier hierboven meer over geschreven in de sectie EC2 Launch Template → Netwerkinstellingen.
Doelgroep — we creëren een groep die verantwoordelijk is voor het routeren van verzoeken van de balancer naar machines en het controleren van hun beschikbaarheid om ze te vervangen in geval van problemen. Doeltype moet een instantie zijn, Protocol и Haven Als u HTTPS gebruikt voor de communicatie tussen de balancer en instances, moet u daar een certificaat naar uploaden. Voor de doeleinden van dit voorbeeld zullen we dit niet doen, we zullen gewoon poort 80 verlaten.
Gezondheidchecks — parameters voor het controleren van de functionaliteit van de dienst. In een echte service zou dit een afzonderlijk verzoek moeten zijn dat belangrijke delen van de bedrijfslogica implementeert; voor de doeleinden van dit voorbeeld laat ik de standaardinstellingen staan. Vervolgens kunt u het verzoekinterval, de time-out, succescodes, etc. selecteren. In ons voorbeeld geven we Succescodes 200-399 aan, omdat de Docker-image die wordt gebruikt een 304-code retourneert.
Doelen registreren — hier worden de auto's voor de groep geselecteerd, maar in ons geval wordt dit gedaan door ECS, dus we slaan deze stap gewoon over.
Goed om te weten: op balancerniveau kunt u logboeken inschakelen die op een bepaald moment in S3 worden opgeslagen . Van daaruit kunnen ze worden geëxporteerd naar services van derden voor analyse, of u kunt rechtstreeks SQL-query's uitvoeren op de gegevens in S3 met . Het is handig en werkt zonder extra code. Ik raad ook aan om de verwijdering van logboeken uit de S3-bucket na een bepaalde periode in te stellen.
ECS-taakdefinitie
In de vorige stappen hebben we alles gemaakt wat met de service-infrastructuur te maken heeft; nu gaan we verder met het beschrijven van de containers die we gaan lanceren. Dit wordt gedaan in de sectie ECS → Taakdefinities.
Compatibiliteit met starttypes - selecteer EC2.
Taakuitvoering IAM-rol - kiezen ecsTaskExecutionRole. Hiermee worden logs geschreven, wordt toegang gegeven tot geheime variabelen, enz.
Klik in de sectie Containerdefinities op Container toevoegen.
Beeld — link naar de afbeelding met de projectcode; voor dit voorbeeld gebruik ik een openbare afbeelding van Docker Hub .
Geheugenlimieten — geheugenlimieten voor de container. Harde limiet — harde limiet, als de container de opgegeven waarde overschrijdt, wordt het docker kill-commando uitgevoerd en gaat de container onmiddellijk dood. Zachte limiet — zachte limiet, de container kan verder gaan dan de opgegeven waarde, maar met deze parameter wordt rekening gehouden bij het plaatsen van taken op machines. Als een machine bijvoorbeeld 4 GiB RAM heeft en de zachte limiet van een container 2048 MiB is, kan deze machine maximaal 2 actieve taken hebben met deze container. In werkelijkheid is 4 GiB RAM iets minder dan 4096 MiB. Dit kun je bekijken op het tabblad ECS Instances in het cluster. Zachte limiet kan niet groter zijn dan harde limiet. Het is belangrijk om te begrijpen dat als er meerdere containers in één taak zijn, hun limieten worden samengevat.
Poorttoewijzingen - in Hostpoort Wij geven 0 aan, dit betekent dat de poort dynamisch wordt toegewezen en gemonitord wordt door de Doelgroep. Containerhaven — de poort waarop uw applicatie draait, wordt vaak gespecificeerd in de uitvoeringsopdracht, of toegewezen in uw applicatiecode, Dockerfile, enz. Voor ons voorbeeld gebruiken we 3000 omdat dit wordt vermeld in de afbeelding die wordt gebruikt.
Gezondheids controle — parameters voor containergezondheidscontrole, niet te verwarren met de parameters die zijn geconfigureerd in de doelgroep.
Milieu - omgevingsinstellingen. CPU-eenheden - vergelijkbaar met Geheugenlimieten, alleen over de processor. Elke processorkern bestaat uit 1024 eenheden, dus als de server een dual-coreprocessor heeft en de container is ingesteld op 512, kunnen met deze container 4 taken op één server worden gestart. CPU-eenheden komen altijd overeen met het aantal kernen; er kunnen er niet iets minder zijn, zoals het geval is met geheugen.
commando — een commando om een service in een container te starten, alle parameters worden gespecificeerd, gescheiden door komma's. Dit kan gunicorn, npm, enz. zijn. Indien niet gespecificeerd, wordt de waarde van de CMD-instructie uit het Dockerbestand gebruikt. Wij geven aan npm,start.
Omgevingsvariabelen — containeromgevingsvariabelen. Dit kunnen eenvoudige tekstgegevens zijn of geheime variabelen of .
Opslag en logboekregistratie — hier zullen we het loggen instellen in CloudWatch Logs (een service voor logs van AWS). Om dit te doen, schakelt u gewoon het selectievakje CloudWatch Logs automatisch configureren in. Na het aanmaken van de Taakdefinitie wordt er automatisch een groep logbestanden aangemaakt in CloudWatch. Standaard worden logs daarin voor onbepaalde tijd opgeslagen; ik raad aan om de bewaartermijn te wijzigen van Never Expire naar de vereiste periode. Dit gebeurt in CloudWatch Log-groepen, u moet op de huidige periode klikken en een nieuwe selecteren.
ECS Cluster en ECS Capaciteitsaanbieder
Ga naar de sectie ECS → Clusters om een cluster aan te maken. We selecteren EC2 Linux + Networking als sjabloon.
Clusternaam - heel belangrijk, we maken hier dezelfde naam als gespecificeerd in de parameter Launch Template ECS_CLUSTER, in ons geval - DemoApiClusterProd. Schakel het selectievakje Een leeg cluster maken in. Optioneel kunt u Container Insights inschakelen om statistieken voor services in CloudWatch te bekijken. Als je alles goed hebt gedaan, zie je in de sectie ECS Instances machines die zijn gemaakt in de groep Auto Scaling.
Ga naar het tabblad Capaciteitsaanbieders en maak een nieuwe. Laat me u eraan herinneren dat het nodig is om het aanmaken en afsluiten van machines te controleren, afhankelijk van het aantal lopende ECS-taken. Het is belangrijk op te merken dat een aanbieder slechts aan één groep kan worden toegewezen.
Auto Scaling-groep — selecteer de eerder gemaakte groep.
Beheerd schalen — schakel het in zodat de aanbieder de dienst kan schalen.
Doelcapaciteit % – welk percentage machines geladen met taken hebben we nodig. Als u 100% opgeeft, zullen alle machines altijd bezig zijn met het uitvoeren van taken. Als u 50% opgeeft, is de helft van de auto's altijd gratis. In dit geval zullen nieuwe taxi's, als er sprake is van een sterke belastingsprong, onmiddellijk bij de vrije auto's komen, zonder te hoeven wachten tot de exemplaren worden ingezet.
Beheerde beëindigingsbescherming — enable: met deze parameter kan de provider de bescherming van instances tegen verwijdering opheffen. Dit gebeurt wanneer er geen actieve taken op de machine zijn en Doelcapaciteit% is toegestaan.
ECS-service en schalingsinstellingen
Laatste stap :) Om een service aan te maken, ga je naar het eerder gemaakte cluster op het tabblad Services.
Starttype — u moet op Overschakelen naar strategie voor capaciteitsaanbieders klikken en de eerder aangemaakte aanbieders selecteren.
Taakdefinitie — selecteer de eerder gemaakte Taakdefinitie en de revisie ervan.
Servicenaam — om verwarring te voorkomen geven we altijd hetzelfde aan als Taakdefinitie.
Service type - altijd replica.
Aantal taken — het gewenste aantal actieve taken in de dienst. Deze parameter wordt bepaald door schaling, maar moet nog steeds worden opgegeven.
Minimaal gezond percentage и Maximaal percentage — het gedrag van taken tijdens de inzet bepalen. De standaardwaarden zijn 100 en 200, wat aangeeft dat op het moment van implementatie het aantal taken verschillende keren zal toenemen en vervolgens zal terugkeren naar de gewenste waarde. Als er één taak actief is, min=1 en max=0, dan wordt deze tijdens de implementatie beëindigd en daarna wordt er een nieuwe aangemaakt, dat wil zeggen dat er sprake is van downtime. Als er 100 taak draait, min=1, max=50, dan zal er helemaal geen implementatie plaatsvinden, omdat 150 taak niet gehalveerd kan worden of anderhalf keer vergroot kan worden.
Implementatietype - verlaat de Rolling-update.
Plaatsingssjablonen — regels voor het plaatsen van taken op machines. De standaardinstelling is AZ Balanced Spread - dit betekent dat elke nieuwe taak op een nieuw exemplaar wordt geplaatst totdat de machines in alle beschikbaarheidszones stijgen. Meestal doen we BinPack - CPU en Spread - AZ; met dit beleid worden taken zo dicht mogelijk op één machine per CPU geplaatst. Als het nodig is om een nieuwe machine te maken, wordt deze gemaakt in een nieuwe beschikbaarheidszone.
Type load balancer — selecteer Applicatie Load Balancer.
Service IAM-rol - Kiezen ecsServiceRole.
Naam van load balancer — selecteer de eerder gemaakte balancer.
Respijtperiode voor de gezondheidscontrole - pauzeren voordat u gezondheidscontroles uitvoert na het uitrollen van een nieuwe taak, stellen we deze meestal in op 60 seconden.
Container-naar-laadbalans — selecteer bij Doelgroepnaam de eerder aangemaakte groep en alles wordt automatisch ingevuld.
Service automatisch schalen — serviceschalingsparameters. Selecteer Service automatisch schalen configureren om het gewenste aantal van uw service aan te passen. Bij het schalen stellen we het minimale en maximale aantal taken in.
IAM-rol voor Service Auto Scaling - Kiezen AWSServiceRoleForApplicationAutoScaling_ECSService.
Beleid voor automatisch schalen van taken — regels voor schaalvergroting. Er zijn 2 soorten:
- Doel volgen — het bijhouden van doelstatistieken (CPU/RAM-gebruik of aantal verzoeken voor elke taak). We willen bijvoorbeeld dat de gemiddelde processorbelasting 85% is, wanneer deze hoger wordt, zullen er nieuwe taken worden toegevoegd totdat de doelwaarde wordt bereikt. Als de belasting lager is, worden taken verwijderd, integendeel, tenzij de bescherming tegen schaalverkleining is ingeschakeld (Schakel inschalen uit).
- Stapsgewijs schalen - reactie op een willekeurige gebeurtenis. Hier kunt u een reactie configureren op elke gebeurtenis (CloudWatch Alarm). Wanneer deze zich voordoet, kunt u het opgegeven aantal taken toevoegen of verwijderen, of het exacte aantal taken opgeven.
Een service kan meerdere schaalregels hebben, dit kan handig zijn, het belangrijkste is om ervoor te zorgen dat ze niet met elkaar in conflict komen.
Conclusie
Als u de instructies hebt gevolgd en dezelfde Docker-image hebt gebruikt, zou uw service een pagina als deze moeten retourneren.
- We hebben een sjabloon gemaakt op basis waarvan alle machines in de service worden gelanceerd. We hebben ook geleerd hoe we machines kunnen updaten als de sjabloon verandert.
- We hebben de verwerking van het stopsignaal van de spot instance geconfigureerd, zodat binnen een minuut na ontvangst alle lopende taken van de machine worden verwijderd, zodat er niets verloren gaat of wordt onderbroken.
- We hebben de balancer omhoog gebracht om de belasting gelijkmatig over de machines te verdelen.
- We hebben een service gecreëerd die ter plekke wordt uitgevoerd, waardoor de machinekosten ongeveer drie keer worden verlaagd.
- We hebben automatisch schalen in beide richtingen geconfigureerd om de toegenomen werkdruk aan te kunnen zonder kosten voor downtime.
- Wij maken gebruik van Capacity Provider zodat de applicatie de infrastructuur (machines) beheert en niet andersom.
- Waren geweldig.
Als u voorspelbare pieken in de belasting heeft, bijvoorbeeld als u adverteert in een grote e-mailcampagne, kunt u schaling instellen door .
U kunt ook schalen op basis van gegevens uit verschillende delen van uw systeem. We hebben bijvoorbeeld de functionaliteit gebruikers van de mobiele applicatie. Soms wordt een campagne naar meer dan 1 miljoen mensen gestuurd. Na een dergelijke distributie is er altijd een grote toename in verzoeken aan de API, aangezien veel gebruikers tegelijkertijd inloggen op de applicatie. Dus als we zien dat er aanzienlijk meer standaardindicatoren in de wachtrij staan voor het verzenden van promotionele pushmeldingen, kunnen we onmiddellijk verschillende extra machines en taken lanceren om klaar te zijn voor de lading.
Ik zal blij zijn als je me in de reacties interessante gevallen vertelt over het gebruik van spotinstances en ECS of iets over schaling.
Binnenkort verschijnen er artikelen over hoe we duizenden analytische gebeurtenissen per seconde verwerken op een overwegend serverloze stack (met geld) en hoe de inzet van diensten werkt met behulp van GitLab CI en Terraform Cloud.
Abonneer je op ons, het zal interessant zijn!
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Maakt u gebruik van spotinstances in productie?
-
22,2%Ja6
-
66,7%Geen18
-
11,1%Ik heb erover geleerd via een artikel en ben van plan ze te gebruiken3
27 gebruikers hebben gestemd. 5 gebruikers onthielden zich van stemming.
Bron: www.habr.com