Hi almal! My naam is Kirill, ek is CTO by Adapty. Die meeste van ons argitektuur is op AWS, en vandag gaan ek praat oor hoe ons bedienerkoste met 3x sny deur Spot Instances in produksie te gebruik, en hoe om dit outomaties te skaal. Daar sal eers 'n oorsig wees van hoe dit werk, en dan gedetailleerde instruksies om te begin.
Wat is Spot Instances?
gevalle is bedieners van ander AWS-gebruikers wat tans ledig is en hulle verkoop dit teen 'n groot afslag (Amazon skryf tot 90%, volgens ons ervaring ~3x, wissel volgens streek, AZ en instansietipe). Hul belangrikste verskil van die gewone is dat hulle enige tyd kan afskakel. Daarom het ons vir 'n lang tyd gedink dat dit normaal is om dit te gebruik vir ontwikkelingsomgewings, of vir take om iets te bereken, met die stoor van tussenresultate op S3 of in die databasis, maar nie vir verkoop nie. Daar is derdeparty-oplossings wat jou toelaat om kolle op prod te gebruik, maar daar is baie krukke vir ons saak, so ons het dit nie geïmplementeer nie. Die benadering wat in die artikel beskryf word, werk heeltemal binne die raamwerk van die standaard AWS-funksionaliteit, sonder bykomende skrifte, crons, ens.
Hier is 'n paar skermkiekies wat die prysgeskiedenis vir Spot Instances wys.
m5.groot in eu-west-1 (Ierland). Die prys is meestal stabiel vir 3 maande, wat op die oomblik 2.9x bespaar.
m5.groot in die us-oos-1 (N. Virginia) streek. Prys wissel voortdurend oor die loop van 3 maande, met huidige besparings wat wissel van 2.3x tot 2.8x afhangende van beskikbaarheidsone.
t3.klein in ons-oos-1 (N. Virginia). Prys stabiel vir 3 maande, spaar tans 3.4x.
Diensargitektuur
Die basiese argitektuur van die diens, waaroor ons in hierdie artikel sal praat, word in die diagram hieronder getoon.
Toepassingslasbalanseerder → EC2-teikengroep → Elastiese houerdiens
'n Toepassingslasbalanseerder (ALB) word as 'n balanseerder gebruik, wat versoeke aan die EC2-teikengroep (TG) stuur. Die TG is verantwoordelik vir die opening van hawens vir die ALB's op die gevalle en bind hulle aan die Elastic Container Service (ECS) houer hawens. ECS is 'n analoog van Kubernetes in AWS, wat handel oor die bestuur van Docker-houers.
In een geval kan daar verskeie lopende houers met dieselfde poorte wees, so ons kan dit nie regstel nie. ECS sê vir TG dat dit 'n nuwe taak begin (in Kubernetes-terminologie word dit 'n pod genoem), dit kyk vir gratis poorte op die instansie en ken een van hulle toe aan die taak wat geloods word. TG kyk ook gereeld of die instansie en api daaraan werk deur 'n gesondheidskontrole te gebruik, en as dit enige probleme sien, hou dit op om versoeke daarheen te stuur.
EC2 Outo-skaalgroepe + ECS-kapasiteitverskaffers
Die diagram hierbo wys nie die EC2 Auto Scaling Groups (ASG) diens nie. Uit die naam kan jy verstaan dat dit verantwoordelik is vir die skaal van gevalle. Terselfdertyd, tot onlangs, het AWS nie 'n ingeboude vermoë gehad om die aantal lopende masjiene vanaf ECS te bestuur nie. ECS het toegelaat om die aantal take te skaal, byvoorbeeld volgens SVE-gebruik, RAM of die aantal versoeke. Maar as take alle gratis gevalle beset het, het nuwe masjiene nie outomaties opgestaan nie.
Dit het verander met die koms van ECS Capacity Providers (ECS CP). Nou kan elke diens in die ECS met ASG geassosieer word, en as die take nie op lopende gevalle pas nie, sal nuwes styg (maar binne die vasgestelde ASG-limiete). Dit werk ook in die teenoorgestelde rigting, as die ECS CP ledige gevalle sonder take sien, sal dit ASG opdrag gee om dit af te skakel. ECS CP het die vermoë om die teikenpersentasie van gevalle wat laai, te spesifiseer, sodat 'n sekere aantal masjiene altyd gratis is vir vinnige skaal van take, ek sal 'n bietjie later hieroor praat.
EC2-bekendstellingsjablone
Die laaste diens waaroor ek sal praat voordat ek na 'n gedetailleerde beskrywing van die skepping van hierdie infrastruktuur gaan, is EC2 Launch Templates. Dit laat jou toe om 'n sjabloon te skep waarmee alle masjiene sal begin, om dit nie elke keer van nuuts af te herhaal nie. Hier kan u die tipe masjien kies om te begin, sekuriteitsgroep, skyfbeeld en baie ander opsies. U kan ook gebruikersdata spesifiseer wat na alle geloodsde gevalle opgelaai sal word. Jy kan skrifte in gebruikersdata laat loop, byvoorbeeld, jy kan die inhoud van 'n lêer wysig .
Een van die belangrikste konfigurasie-opsies in hierdie artikel is =waar. As hierdie instelling geaktiveer is, dan sodra die ECS 'n sein ontvang dat die Spot Instance opgetel word, dra dit alle take wat daaraan werk oor na die Dreineer-status. Geen nuwe take sal aan hierdie instansie toegewys word nie, as daar take is wat nou daarheen wil uitrol, word dit gekanselleer. Versoeke van die balanseerder hou ook op om te kom. Die instansie-skrapkennisgewing kom 2 minute voor die werklike gebeurtenis. As u diens dus nie meer as 2 minute take uitvoer nie en niks op die skyf stoor nie, kan u Spot Instances gebruik sonder dataverlies.
Oor die skyf - AWS onlangs dit is moontlik om Elastic File System (EFS) saam met ECS te gebruik, met hierdie skema is selfs 'n skyf nie 'n struikelblok nie, maar ons het dit nie probeer nie, aangesien ons in beginsel nie 'n skyf nodig het om toestand te stoor nie. By verstek, na ontvangs van 'n SIGINT (gestuur op die oomblik dat die taak na die Dreineer-status oorgedra word), sal alle lopende take na 30 sekondes gestop word, selfs al is hulle nog nie voltooi nie, kan jy hierdie tyd verander met die parameter . Die belangrikste ding is om dit nie vir meer as 2 minute bloot te stel vir spot motors nie.
Diensskepping
Ons gaan direk voort met die skepping van die beskryf diens. In die proses sal ek ook 'n paar nuttige punte beskryf wat nie hierbo genoem is nie. Oor die algemeen is dit 'n stap-vir-stap instruksie, maar ek sal nie 'n paar baie basiese of, inteendeel, baie spesifieke gevalle oorweeg nie. Alle aksies word in die AWS-visuele konsole uitgevoer, maar hulle kan programmaties gespeel word met CloudFormation of Terraform. By Adapty gebruik ons Terraform.
EC2 Begin Sjabloon
In hierdie diens word die konfigurasie van die masjiene wat gebruik gaan word, geskep. Sjablone word bestuur in die EC2 -> Gevalle -> Begin sjablone afdeling.
Amazon-masjienbeeld (AMI) - spesifiseer die skyfbeeld waarmee alle gevalle geloods sal word. Vir ECS moet jy in die meeste gevalle die geoptimaliseerde beeld van Amazon gebruik. Dit word gereeld opgedateer en bevat alles wat jy nodig het om ECS te laat loop. Gaan na die bladsy om die huidige beeld-ID uit te vind , kies die gebruikte streek en kopieer die AMI ID daarvoor. Byvoorbeeld, vir die us-east-1-streek is die huidige ID ten tyde van die skryf hiervan ami-00c7c1cf5bdc913ed. Hierdie ID moet in die Spesifiseer 'n pasgemaakte waarde-item ingevoeg word.
Instance tipe - Spesifiseer die instansie tipe. Kies die een wat die beste by jou taak pas.
Sleutelpaar (aanmelding) - spesifiseer die sertifikaat waarmee u aan die instansie kan koppel via SSH, indien nodig.
Netwerkstellings - Spesifiseer die netwerkinstellings. Netwerkplatform moet in die meeste gevalle 'n virtuele privaat wolk (VPC) wees. Veiligheidsgroepe - sekuriteitsgroepe vir u gevalle. Aangesien ons die balanseerder voor die gevalle sal gebruik, beveel ek aan dat u 'n groep hier spesifiseer wat slegs inkomende verbindings vanaf die balanseerder toelaat. Dit wil sê, jy sal 2 sekuriteitsgroepe hê, een vir die balanseerder, wat inkomende (inkomende) verbindings van oral op poorte 80 (http) en 443 (https) toelaat, en die tweede vir masjiene, wat inkomende verbindings op enige poorte vanaf die balanseerdergroep. Uitgaande (uitgaande) verbindings in beide groepe moet via die TCP-protokol na alle poorte na alle adresse oopgemaak word. Jy kan poorte en adresse vir uitgaande verbindings beperk, maar dan moet jy voortdurend monitor dat jy nie iewers op 'n geslote poort toegang probeer kry nie.
Berging (volumes) - spesifiseer die parameters van skywe vir masjiene. Die skyfgrootte kan nie minder wees as dié wat in AMI gespesifiseer is nie, vir ECS Geoptimaliseerd - 30 GiB.
Gevorderde besonderhede - spesifiseer addisionele parameters.
Koop opsie - of ons Spot Instances wil koop. Ons wil, maar ons sal nie hierdie blokkie hier merk nie, ons sal dit in die Outo-skaalgroep instel, daar is meer opsies.
IAM-instansieprofiel - spesifiseer die rol waarmee die gevalle geloods sal word. Om vir gevalle in ECS te werk, het hulle regte nodig, wat gewoonlik in die rol lê ecsInstanceRole. In sommige gevalle kan dit geskep word, indien nie, dan hier oor hoe om dit te doen. Na die skepping spesifiseer ons dit in die sjabloon.
Dan is daar baie parameters, basies kan u standaardwaardes oral laat, maar elkeen van hulle het 'n duidelike beskrywing. Ek aktiveer altyd die EBS-geoptimaliseerde instansie en T2/T3 Unlimited-opsies as dit gebruik word gevalle.
Gebruikersdata - Spesifiseer gebruikersdata. Ons sal die lêer wysig /etc/ecs/ecs.config, wat die konfigurasie van die ECS-agent bevat.
'n Voorbeeld van hoe gebruikersdata kan lyk:
#!/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 - die parameter dui aan dat die instansie aan 'n groep met 'n gegewe naam behoort, dit wil sê, hierdie groep sal sy take op hierdie bediener kan huisves. Ons het nog nie 'n groepering geskep nie, maar ons sal hierdie naam gebruik wanneer ons dit skep.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — die parameter dui aan dat wanneer 'n sein ontvang word oor die afskakeling van 'n Spot-instansie, alle take daarop na die Dreineer-status oorgedra moet word.
ECS_CONTAINER_STOP_TIMEOUT=1m - parameter spesifiseer dat na ontvangs van die SIGINT-sein, alle take 1 minuut het voordat hulle doodgemaak word.
ECS_ENGINE_AUTH_TYPE=docker - die parameter dui aan dat die docker-skema as die magtigingsmeganisme gebruik word
ECS_ENGINE_AUTH_DATA=... - verbindingsparameters na die private houerregister, waar u Docker-beelde gestoor word. As dit publiek is, hoef niks gespesifiseer te word nie.
In hierdie artikel sal ek 'n publieke beeld van Docker Hub gebruik, so spesifiseer die parameters ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nie nodig nie.
Goed om te weet: dit word aanbeveel om die AMI gereeld op te dateer, want die nuwe weergawes bywerk die weergawes van Docker, Linux, ECS agent, ens. Om dit in gedagte te hou, kan jy oor die vrystelling van nuwe weergawes. Jy kan kennisgewings per e-pos ontvang en handmatig opdateer, of jy kan 'n Lambda-funksie skryf wat outomaties 'n nuwe weergawe van die bekendstellingsjabloon met 'n opgedateerde AMI sal skep.
EC2 Outo-skaalgroep
Die Outo-skaalgroep is verantwoordelik vir die bekendstelling en skaal van gevalle. Groepe word bestuur in die afdeling EC2 -> Outomatiese skaal -> Outomatiese skaalgroepe.
sjabloon bekendstel - kies die sjabloon wat in die vorige stap geskep is. Los die verstekweergawe.
Aankoopopsies en instansietipes - spesifiseer die tipes gevalle vir die cluster. Voldoen aan bekendstellingsjabloon gebruik die instansietipe van Launch Template. Kombineer aankoopopsies en instansietipes laat jou toe om instansietipes buigsaam op te stel. Ons sal dit gebruik.
opsionele op-aanvraag basis - die aantal gereelde, nie-kol gevalle wat altyd sal werk.
Op-aanvraag persentasie bo basis - die persentasie gereelde en kol-gevalle, 50-50 sal gelykop verdeel word, 20-80 vir elke gereelde instansie sal 4-plek verhoog word. Vir hierdie voorbeeld sal ek 50-50 aandui, maar in werklikheid doen ons meestal 20-80, in sommige gevalle 0-100.
Instansetipes - hier kan u addisionele tipes gevalle spesifiseer wat in die groepering gebruik sal word. Ons het nooit gebruik nie, want ek verstaan nie regtig die betekenis van hierdie storie nie. Miskien is dit die limiete vir spesifieke soorte gevalle, maar dit verhoog maklik deur ondersteuning. As jy die aansoek ken, sal ek bly wees om in die kommentaar te lees)
Netwerk - netwerkinstellings, kies VPC en subnette vir masjiene, in die meeste gevalle moet u alle beskikbare subnette kies.
Vrag balansering - balanseerder instellings, maar ons sal dit afsonderlik doen, ons raak niks hier aan nie. Gesondheidskontroles sal ook later gekonfigureer word.
Groepgrootte - spesifiseer die limiete op die aantal masjiene in die groep en die verlangde aantal masjiene aan die begin. Die aantal masjiene in die groep sal nooit minder as die minimum gespesifiseerde en groter as die maksimum wees nie, selfs al moet die maatstawwe skaal.
Skaalbeleid - skaalparameters, maar ons sal skaal gebaseer op die uitvoer van ECS-take, so ons sal die skaal later instel.
Toestandskaalbeskerming - beskerming van gevalle teen uitvee wanneer dit afgeskaal word. Ons aktiveer dit sodat ASG nie 'n masjien uitvee wat lopende take het nie. ECS Capacity Provider sal beskerming deaktiveer vir gevalle wat nie take het nie.
Voeg etikette by - jy kan etikette vir instansies spesifiseer (hiervoor moet die Merk nuwe instansies merkblokkie gemerk word). Ek beveel aan dat u die naammerker spesifiseer, dan sal alle gevalle wat binne die groep geloods word dieselfde naam hê, dit is gerieflik om dit in die konsole te sien.
Nadat u 'n groep geskep het, maak dit oop en gaan na die afdeling Gevorderde konfigurasies, en daarom is nie alle opsies in die skeppingsfase sigbaar in die konsole nie.
Beëindigingsbeleide - reëls wat in ag geneem word wanneer gevalle uitgevee word. Hulle word in volgorde toegepas. Ons gebruik gewoonlik dié in die prent hieronder. Eerstens word gevalle met die oudste bekendstellingsjabloon uitgevee (byvoorbeeld, as ons die AMI opgedateer het, het ons 'n nuwe weergawe geskep, maar alle gevalle het daarin geslaag om daarna oor te skakel). Dan word die gevalle wat die naaste aan die volgende betaaltyd in terme van fakturering is, gekies. En dan word die oudstes volgens bekendstellingsdatum gekies.
Goed om te weet: om alle masjiene in die groep op te dateer, is dit gerieflik om te gebruik . Kombineer dit met die Lambda-funksie van die vorige stap en jy het 'n ten volle outomatiese instansie-opdateringstelsel. Voordat u alle masjiene opgradeer, moet u instansieskaalbeskerming vir alle instansies in die groep deaktiveer. Nie 'n instelling in 'n groep nie, maar beskerming teen die masjiene self, dit word gedoen op die Instance management tab.
Toepassing Load Balancer en EC2-teikengroep
Die balanseerder word in die EC2 → Load Balancing → Load Balancers-afdeling geskep. Ons sal die Application Load Balancer gebruik, 'n vergelyking van verskillende tipes load balancers kan gevind word by .
luisteraars - dit maak sin om poorte 80 en 443 te maak en later van 80 na 443 te herlei deur die balanseerreëls te gebruik.
Beskikbaarheidsones - in die meeste gevalle kies ons alle toegangsones.
Stel sekuriteitsinstellings op - hier spesifiseer u die SSL-sertifikaat vir die balanseerder, die gerieflikste opsie is in ACM. Oor verskille Veiligheidsbeleid kan ingelees word , kan jy dit by verstek gekies laat ELBSecurityPolicy-2016-08. Nadat u 'n balanseerder geskep het, sal u dit sien DNS-naam, waarna jy die CNAME vir jou domein moet opstel. Dit is byvoorbeeld hoe dit in Cloudflare lyk.
Veiligheidsgroep - skep of kies 'n sekuriteitsgroep vir die balanseerder, ek het meer hieroor geskryf 'n bietjie hoër in die EC2 Launch Template → Netwerkinstellings afdeling.
Teikengroep - ons skep 'n groep wat verantwoordelik is om versoeke van die balanseerder na masjiene te stuur en hul beskikbaarheid nagaan om dit te vervang in geval van probleme. Teiken tipe moet Instance wees, Protokol и Port enige, as jy HTTPS gebruik om tussen die balanseerder en gevalle te kommunikeer, dan moet jy 'n sertifikaat na hulle oplaai. In hierdie voorbeeld sal ons dit nie doen nie, ons sal net poort 80 verlaat.
Gesondheidskontroles - diens gesondheidskontrole parameters. In 'n regte diens moet dit 'n aparte versoek wees wat belangrike dele van die besigheidslogika implementeer, vir hierdie voorbeeld sal ek die verstekinstellings verlaat. Vervolgens kan jy die versoekinterval, time-out, sukseskodes, ens kies. In ons voorbeeld sal ons sukseskodes 200-399 spesifiseer, want die Docker-beeld wat gebruik gaan word, gee 'n 304-kode terug.
Registreer teikens - masjiene vir die groep word hier gekies, maar in ons geval sal ECS dit hanteer, so ons slaan net hierdie stap oor.
Goed om te weet: op die vlak van die balanseerder, kan jy logs wat in S3 gestoor sal word in 'n sekere aktiveer . Van daar af kan dit na derdepartydienste uitgevoer word vir ontleding, of jy kan SQL-navrae direk op die data in S3 maak met . Dit is gerieflik en werk sonder enige bykomende kode. Ek beveel ook aan dat die uitvee van logs uit die S3-emmer na 'n bepaalde tydperk opgestel word.
ECS Taak Definisie
In die vorige stappe het ons alles geskep wat met die diensinfrastruktuur verband hou, nou gaan ons verder met die beskrywing van die houers wat ons sal laat loop. Dit word gedoen in die ECS → Taakdefinisies afdeling.
Begin tipe verenigbaarheid - kies EC2.
Taakuitvoering IAM-rol - kies ecsTaskExecutionRole. Daarmee word logs geskryf, toegang tot geheime veranderlikes gegee, ens.
In die Houerdefinisies-afdeling, klik Voeg Houer by.
Image - skakel na die beeld met die projekkode, in hierdie voorbeeld sal ek 'n publieke beeld van Docker Hub gebruik .
Geheue beperkings - geheue limiete vir die houer. Harde limiet - 'n harde limiet, as die houer verder gaan as die gespesifiseerde waarde, dan sal die docker kill-opdrag uitgevoer word, die houer sal onmiddellik sterf. Sagte limiet - sagte limiet, die houer kan verder gaan as die gespesifiseerde waarde, maar hierdie parameter sal in ag geneem word wanneer take op masjiene geplaas word. Byvoorbeeld, as die masjien 4 GiB RAM het, en die sagte limiet van die houer is 2048 MiB, dan kan hierdie masjien 'n maksimum van 2 lopende take met hierdie houer hê. In werklikheid is 4 GiB RAM effens minder as 4096 MiB, wat op die ECS Instances-oortjie in die groep gesien kan word. Sagte limiet kan nie groter as harde limiet wees nie. Dit is belangrik om te verstaan dat as daar verskeie houers in een taak is, dan word hul limiete opgesom.
Port kartering - in Gasheerpoort spesifiseer 0, wat beteken dat die poort dinamies toegewys sal word, dit sal deur die teikengroep opgespoor word. houer hawe - die poort waarop u toepassing loop, word dikwels in die opdrag gestel vir uitvoering, of toegewys in u toepassingskode, Dockerfile, ens. Vir ons voorbeeld gebruik ons 3000 omdat dit gespesifiseer is in gebruikte beeld.
Gesondheids ondersoek - Parameters vir houergesondheidkontrole, moet nie verwar word met die een wat in die teikengroep opgestel is nie.
omgewing - omgewing instellings. SVE eenhede - soortgelyk aan geheue limiete, net oor die verwerker. Elke verwerkerkern is 1024 eenhede, so as die bediener 'n dubbelkernverwerker het, en die houer het 'n waarde van 512, dan kan 4 take met hierdie houer op een bediener geloods word. SVE-eenhede stem altyd ooreen met die aantal kerne, hulle kan nie 'n bietjie minder wees nie, soos in die geval van geheue.
Command - opdrag om die diens binne die houer te begin, alle parameters word deur kommas geskei. Dit kan geweerhoring, npm, ens. Indien nie gespesifiseer nie, sal die waarde van die CMD-aanwysing van die Dockerfile gebruik word. Spesifiseer npm,start.
Omgewings veranderlikes - houer omgewing veranderlikes. Dit kan óf net teksdata óf geheime veranderlikes van wees of .
Berging en logboek - hier sal ons aanteken in CloudWatch Logs (log diens van AWS) konfigureer. Om dit te doen, aktiveer net die Outo-konfigureer CloudWatch Logs-merkblokkie. Nadat die taakdefinisie geskep is, sal 'n groep logs outomaties in CloudWatch geskep word. By verstek word logs onbepaald daarin gestoor, ek beveel aan dat u die Behoudtydperk verander van Never Expire na die vereiste tydperk. Dit word in CloudWatch Log-groepe gedoen, u moet op die huidige tydperk klik en 'n nuwe een kies.
ECS Cluster en ECS kapasiteitsverskaffer
Gaan na die ECS → Clusters afdeling om 'n cluster te skep. Ons kies EC2 Linux + Networking as 'n sjabloon.
groep naam - baie belangrik, ons maak dieselfde naam hier as gespesifiseer in die Launch Template in die parameter ECS_CLUSTER, in ons geval - DemoApiClusterProd. Merk die blokkie Skep 'n leë groepering. Opsioneel kan jy Container Insights aktiveer om diensstatistieke in CloudWatch te sien. As jy alles korrek gedoen het, sal jy in die ECS Instances-afdeling masjiene sien wat in die Outomatiese skaal-groep geskep is.
Gaan na oortjie Kapasiteitsverskaffers en skep 'n nuwe een. Laat ek u daaraan herinner dat dit nodig is om die skepping en afsluiting van masjiene te bestuur, afhangende van die aantal lopende ECS-take. Dit is belangrik om daarop te let dat 'n verskaffer slegs met een groep geassosieer kan word.
outomatiese skaalgroep - kies die voorheen geskepte groep.
Bestuurde skaal - aktiveer sodat die verskaffer die diens kan skaal.
teiken kapasiteit % - watter persentasie van die laai van motors met take wat ons nodig het. As jy 100% spesifiseer, sal alle masjiene altyd deur lopende take beset word. As jy 50% spesifiseer, sal die helfte van die motors altyd gratis wees. In hierdie geval, as daar 'n skerp sprong in die vrag is, sal nuwe taxi's onmiddellik op gratis motors klim, sonder om te wag vir die ontplooiing van gevalle.
Bestuurde beëindigingsbeskerming - aktiveer, hierdie parameter laat die verskaffer toe om die beskerming van gevalle van verwydering te verwyder. Dit gebeur wanneer daar geen aktiewe take op die masjien is nie en laat Teikenkapasiteit % toe.
ECS-diens en skaalopstelling
Die laaste stap :) Om 'n diens te skep, moet jy na die voorheen geskepde groepering op die Dienste-oortjie gaan.
bekendstelling tipe - jy moet op Skakel na kapasiteitsverskafferstrategie klik en die voorheen geskepde verskaffer kies.
Taakdefinisie - kies die voorheen geskepte taakdefinisie en die hersiening daarvan.
Diensnaam - om nie deurmekaar te raak nie, spesifiseer ons altyd dieselfde as die Taakdefinisie.
Diens tipe - altyd Replika.
Aantal take — die verlangde aantal aktiewe take in die diens. Hierdie parameter word deur skaal beheer, maar moet steeds gespesifiseer word.
Minimum gesonde persentasie и maksimum persentasie - bepaal die gedrag van take tydens ontplooiing. Die verstekwaardes van 100 en 200 dui aan dat die aantal take ten tye van ontplooiing met 'n faktor van twee sal toeneem, en dan sal terugkeer na die verlangde een. As 1 taak vir jou werk, min=0, en maks=100, dan sal dit tydens ontplooiing doodgemaak word, en daarna sal 'n nuwe een opgewek word, dit wil sê, dit sal eenvoudig wees. As 1 taak werk, min=50, maks=150, dan sal die ontplooiing glad nie gebeur nie, want 1 taak kan nie in die helfte gedeel of met een en 'n half keer verhoog word nie.
Ontplooiingstipe - verlaat Rolling update.
Plasingsjablone - reëls vir die plasing van take op motors. Die verstek is AZ Balanced Spread - dit beteken wie elke nuwe taak op 'n nuwe instansie geplaas sal word totdat die masjiene in alle beskikbaarheidsones styg. Ons doen gewoonlik BinPack - CPU en Spread - AZ, met hierdie beleid word take so dig as moontlik op een masjien per SVE geplaas. As 'n nuwe masjien geskep moet word, word dit in 'n nuwe beskikbaarheidsone geskep.
tipe lasbalanseerder - kies Application Load Balancer.
Diens IAM rol - kies ecsServiceRole.
Naam van lasbalanseerder - kies die voorheen geskep balanseerder.
Gesondheidsondersoek grasietydperk - 'n pouse voor die uitvoer van gesondheidsondersoeke na die uitrol van 'n nuwe taak, ons stel gewoonlik 60 sekondes.
Houer om balans te laai - in die Teikengroepnaam-item, kies die groep wat vroeër geskep is, en alles sal outomaties ingevul word.
Diens outomatiese skaal - diens skaal parameters. Kies Stel diens outomatiese skaal op om jou diens se verlangde telling aan te pas. Stel die minimum en maksimum aantal take tydens skaal.
IAM-rol vir Service Outo-skaal - kies AWSServiceRoleForApplicationAutoScaling_ECSService.
Outomatiese taakskaalbeleide — Reëls vir skaal. Daar is 2 tipes:
- Teikennasporing - dop van die teikenmetriek (CPU / RAM-gebruik of die aantal versoeke vir elke taak). Ons wil byvoorbeeld hê dat die gemiddelde SVE-lading 85% moet wees, wanneer dit hoër word, sal nuwe take bygevoeg word totdat dit die teikenwaarde bereik. As die las laer is, sal die take, inteendeel, verwyder word as beskerming teen afskaal nie geaktiveer is nie (Deaktiveer inskaal).
- stap skaal - reaksie op 'n ewekansige gebeurtenis. Hier kan jy 'n reaksie op enige gebeurtenis opstel (CloudWatch Alarm), wanneer dit plaasvind, kan jy die gespesifiseerde aantal take byvoeg of verwyder, of die presiese aantal take spesifiseer.
'n Diens kan verskeie skaalreëls hê, dit kan nuttig wees, die belangrikste ding is om seker te maak dat hulle nie met mekaar bots nie.
Gevolgtrekking
As jy die instruksies gevolg het en dieselfde Docker-beeld gebruik het, moet jou diens so 'n bladsy terugstuur.
- Ons het 'n sjabloon geskep waarmee al die masjiene in die diens begin. Ons het ook geleer hoe om motors op te dateer wanneer die sjabloon verander.
- Ons het die verwerking van die Spot-instansiestopsein opgestel, so binne 'n minuut nadat ons dit ontvang het, word alle lopende take van die masjien verwyder, sodat niks verlore gaan of onderbreek word nie.
- Ons het die balanseerder opgelig om die vrag eweredig oor die masjiene te versprei.
- Ons het 'n diens geskep wat op Spot Instances loop, as gevolg hiervan word die koste van masjiene met ongeveer 3 keer verminder.
- Ons stel outoskaling in beide rigtings op om die toename in vragte te hanteer, maar betaal terselfdertyd nie vir stilstand nie.
- Ons gebruik die kapasiteitsverskaffer sodat die toepassing die infrastruktuur (masjiene) bestuur en nie andersom nie.
- Ons is puik.
As jy byvoorbeeld voorspelbare vragpunte het, jy adverteer in 'n groot e-posveldtog, kan jy die skaal aanpas deur .
Jy kan ook skaal gebaseer op data van verskillende dele van jou stelsel. Ons het byvoorbeeld 'n funksie mobiele toepassing gebruikers. Soms word die veldtog na 1M+ mense gestuur. Daar is altyd 'n groot toename in API-versoeke na so 'n pos, aangesien baie gebruikers terselfdertyd toegang tot die toepassing het. So as ons sien dat die tou vir die stuur van promo-stoot aansienlik meer geword het as die standaard-aanwysers, kan ons onmiddellik verskeie bykomende masjiene en take begin om gereed te wees vir die vrag.
Ek sal bly wees as jy in die kommentaar interessante gevalle vertel van die gebruik van Spot Instances en ECS, of iets wat met skaal verband hou.
Binnekort sal daar artikels wees oor hoe ons duisende analitiese gebeurtenisse per sekonde verwerk op 'n oorwegend bedienerlose stapel (met geld) en hoe dienste ontplooi word met GitLab CI en Terraform Cloud.
Teken in op ons, dit sal interessant wees!
Slegs geregistreerde gebruikers kan aan die opname deelneem. , asseblief.
Gebruik jy spotgevalle in produksie?
-
22,2%Ja 6
-
66,7%No18
-
11,1%Ek het van hulle geleer uit die artikel, ek beplan om 3 te gebruik
27 gebruikers het gestem. 5 gebruikers het buite stemming gebly.
Bron: will.com