Hei kaikki! Nimeni on Kirill, olen Adaptyn teknologiajohtaja. Suurin osa arkkitehtuuristamme on AWS:llä, ja tänään puhun siitä, kuinka pienensimme palvelinkustannuksia 3 kertaa käyttämällä spot-esiintymiä tuotantoympäristössä sekä kuinka määritimme niiden automaattisen skaalauksen. Ensin on yleiskatsaus sen toiminnasta ja sitten yksityiskohtaiset ohjeet aloittamiseen.
Mitä ovat spot-instanssit?
esiintymät ovat muiden tällä hetkellä käyttämättömien AWS-käyttäjien palvelimia ja myyvät niitä suurella alennuksella (Amazon kirjoittaa jopa 90%, kokemuksemme mukaan ~3x, vaihtelee alueen, AZ:n ja ilmentymän tyypin mukaan). Niiden tärkein ero tavallisiin on, että ne voidaan sammuttaa milloin tahansa. Siksi uskoimme pitkään, että on normaalia käyttää niitä neitseellisiin ympäristöihin tai laskutehtäviin, joiden välitulokset on tallennettu S3:lle tai tietokantaan, mutta ei myyntiin. On olemassa kolmansien osapuolien ratkaisuja, joiden avulla voit käyttää spotteja tuotannossa, mutta meidän tapauksellemme on monia kainalosauvoja, joten emme toteuttaneet niitä. Artikkelissa kuvattu lähestymistapa toimii täysin AWS-standardin toiminnallisuuden puitteissa ilman ylimääräisiä komentosarjoja, kruunuja jne.
Alla on muutama kuvakaappaus, jotka näyttävät spot-tapausten hintahistorian.
m5.suuri alueella eu-west-1 (Irlanti). Hinta on ollut pääosin vakaa 3 kuukautta, tällä hetkellä säästö 2.9x.
m5.suuri us-east-1 alueella (N. Virginia). Hinta muuttuu jatkuvasti 3 kuukauden aikana ja säästää tällä hetkellä 2.3 x 2.8 x saatavuudesta riippuen.
t3.pieni us-east-1 -alueella (N. Virginia). Hinta on ollut vakaa 3 kuukautta, tällä hetkellä säästö 3.4x.
Palveluarkkitehtuuri
Palvelun perusarkkitehtuuri, josta puhumme tässä artikkelissa, on esitetty alla olevassa kaaviossa.
Sovellus Load Balancer → EC2 Kohderyhmä → Elastic Container Service
Application Load Balancer (ALB) toimii tasapainottimena, joka lähettää pyynnöt EC2-kohderyhmälle (TG). TG vastaa porttien avaamisesta ALB:ille ja niiden liittämisestä ECS (Elastic Container Service) -konttien portteihin. ECS on AWS:n Kubernetesin analogi, joka hallitsee Docker-säiliöitä.
Yhdessä ilmentymässä voi olla useita käynnissä olevia säiliöitä samoilla porteilla, joten emme voi asettaa niitä kiinteästi. ECS kertoo TG:lle käynnistävänsä uuden tehtävän (Kubernetes-terminologiassa tätä kutsutaan podiksi), se tarkistaa, onko ilmentymässä vapaita portteja ja määrittää yhden niistä käynnistetylle tehtävälle. TG myös tarkistaa säännöllisesti kuntotarkastuksen avulla, toimivatko ilmentymä ja API sen kanssa, ja jos se havaitsee ongelmia, se lopettaa pyyntöjen lähettämisen sinne.
EC2 Auto Scaling Groups + ECS kapasiteetin tarjoajat
Yllä oleva kaavio ei näytä EC2 Auto Scaling Groups (ASG) -palvelua. Nimestä voit ymmärtää, että se on vastuussa ilmentymien skaalauksesta. Viime aikoihin asti AWS:llä ei kuitenkaan ollut sisäänrakennettua kykyä hallita käynnissä olevien koneiden määrää ECS:stä. ECS mahdollisti tehtävien määrän skaalaamisen esimerkiksi suorittimen käytön, RAM-muistin tai pyyntöjen määrän mukaan. Mutta jos tehtävät valtasivat kaikki vapaat esiintymät, uusia koneita ei luotu automaattisesti.
Tämä on muuttunut ECS-kapasiteetintarjoajien (ECS CP) myötä. Nyt jokainen ECS:n palvelu voidaan liittää ASG:hen, ja jos tehtävät eivät mahdu käynnissä oleviin ilmentymiin, uusia nostetaan (mutta määritettyjen ASG-rajojen sisällä). Tämä toimii myös päinvastaiseen suuntaan, jos ECS CP näkee tyhjäkäynnit ilman tehtäviä, se antaa ASG-komennon sulkea ne. ECS CP:llä on mahdollisuus määrittää instanssikuormituksen tavoiteprosentti, jotta tietty määrä koneita on aina vapaana nopeaa skaalausta varten; puhun tästä hieman myöhemmin.
EC2 Launch Templates
Viimeinen palvelu, josta puhun ennen kuin käsittelen tämän infrastruktuurin luomista, on EC2 Launch Templates. Sen avulla voit luoda mallin, jonka mukaan kaikki koneet käynnistyvät, jotta tämä ei toistu alusta joka kerta. Täällä voit valita käynnistettävän koneen tyypin, suojausryhmän, levykuvan ja monet muut parametrit. Voit myös määrittää käyttäjätiedot, jotka ladataan kaikkiin käynnistettyihin esiintymiin. Voit ajaa komentosarjoja käyttäjätiedoissa, esimerkiksi muokata tiedoston sisältöä .
Yksi tämän artikkelin tärkeimmistä määritysparametreista on = totta. Jos tämä parametri on käytössä, niin heti kun ECS vastaanottaa signaalin spot-instanssin poistamisesta, se siirtää kaikki sitä koskevat tehtävät Tyhjennys-tilaan. Tälle ilmentymälle ei osoiteta uusia tehtäviä. Jos siinä on tehtäviä, jotka halutaan ottaa käyttöön juuri nyt, ne peruutetaan. Myös tasapainottajan pyyntöjä ei tule. Ilmoitus ilmentymän poistamisesta tulee 2 minuuttia ennen varsinaista tapahtumaa. Siksi, jos palvelusi ei suorita tehtäviä yli 2 minuuttia eikä tallenna mitään levylle, voit käyttää spot-instanssia menettämättä tietoja.
Mitä tulee levyyn - AWS äskettäin ECS:n kanssa on mahdollista käyttää Elastic File System (EFS) -järjestelmää, tällä menetelmällä edes levy ei ole este, mutta emme kokeilleet tätä, koska emme periaatteessa tarvitse levyä tilan tallentamiseen. Oletusarvoisesti kaikki käynnissä olevat tehtävät pysähtyvät 30 sekunnin kuluttua SIGINT-ilmoituksen (lähetetään, kun tehtävä siirretään tyhjennystilaan) vastaanottamisen jälkeen, vaikka niitä ei olisi vielä suoritettu. Voit muuttaa tätä aikaa parametrilla . Tärkeintä ei ole asettaa sitä yli 2 minuutiksi spot-koneille.
Palvelun luominen
Jatketaan kuvatun palvelun luomiseen. Prosessin aikana kuvaan lisäksi useita hyödyllisiä kohtia, joita ei mainittu yllä. Yleensä tämä on vaiheittainen ohje, mutta en käsittele joitain hyvin yksinkertaisia tai päinvastoin hyvin erityisiä tapauksia. Kaikki toiminnot suoritetaan AWS-visuaalisessa konsolissa, mutta ne voidaan toistaa ohjelmallisesti CloudFormationin tai Terraformin avulla. Adaptylla käytämme Terraformia.
EC2-käynnistysmalli
Tämä palvelu luo käytettävien koneiden kokoonpanon. Malleja hallitaan osiossa EC2 -> Instanssit -> Launch templates.
Amazon-konekuva (AMI) — määritä levykuva, jolla kaikki esiintymät käynnistetään. ECS:ssä useimmissa tapauksissa kannattaa käyttää Amazonin optimoitua kuvaa. Sitä päivitetään säännöllisesti ja se sisältää kaiken tarvittavan ECS:n toimintaan. Selvitä nykyinen kuvatunnus siirtymällä sivulle , valitse käyttämäsi alue ja kopioi sen AMI-tunnus. Esimerkiksi us-east-1-alueella nykyinen tunnus kirjoitushetkellä on ami-00c7c1cf5bdc913ed. Tämä tunnus on lisättävä Määritä mukautettu arvo -kohtaan.
Ilmentymän tyyppi — ilmoittaa ilmentymän tyyppi. Valitse tehtäväänne parhaiten sopiva.
Avainpari (kirjautuminen) — määritä varmenne, jolla voit tarvittaessa muodostaa yhteyden ilmentymään SSH:n kautta.
Verkkoasetukset — määritä verkkoparametrit. Verkostoitumisalusta useimmissa tapauksissa pitäisi olla Virtual Private Cloud (VPC). Suojausryhmät - suojausryhmät tapauksillesi. Koska käytämme balansoijaa instanssien edessä, suosittelen määrittelemään tähän ryhmän, joka sallii saapuvat yhteydet vain balansoijalta. Toisin sanoen sinulla on 2 suojausryhmää, yksi tasapainottimelle, joka mahdollistaa saapuvat yhteydet mistä tahansa porteista 80 (http) ja 443 (https) ja toinen koneille, joka sallii saapuvat yhteydet mihin tahansa porttiin balanssiryhmästä. . Molempien ryhmien lähtevät yhteydet on avattava TCP-protokollalla kaikkiin portteihin kaikkiin osoitteisiin. Voit rajoittaa lähtevien yhteyksien portteja ja osoitteita, mutta silloin sinun on jatkuvasti valvottava, että et yritä käyttää jotain suljetussa portissa.
Tallennustila (määrät) — määrittää levyparametrit koneille. Levyn koko ei voi olla pienempi kuin AMI:ssä määritetty; ECS Optimizedille se on 30 GiB.
Lisätiedot — määritä lisäparametrit.
Ostomahdollisuus - haluammeko ostaa spot-esiintymiä. Haluamme, mutta emme valitse tätä valintaruutua täällä; määritämme sen Auto Scaling Groupissa, siellä on enemmän vaihtoehtoja.
IAM-instanssiprofiili — ilmoittaa rooli, jolla instanssit käynnistetään. Jotta instanssit voisivat toimia ECS:ssä, ne tarvitsevat käyttöoikeudet, jotka yleensä löytyvät roolista ecsInstanceRole. Joissakin tapauksissa se voidaan luoda, jos ei, niin täällä miten tämä tehdään. Luomisen jälkeen ilmoitamme sen mallissa.
Seuraavaksi on monia parametreja, periaatteessa voit jättää oletusarvot kaikkialle, mutta jokaisella niistä on selkeä kuvaus. Otan aina käyttöön EBS-optimoidun ilmentymän ja T2/T3 Unlimited -vaihtoehdot, jos niitä käytetään tapauksia.
Käyttäjän aika — ilmoittaa käyttäjätiedot. Muokkaamme tiedostoa /etc/ecs/ecs.config, joka sisältää ECS-agenttimääritykset.
Esimerkki siitä, miltä käyttäjätiedot voivat näyttää:
#!/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 — parametri osoittaa, että ilmentymä kuuluu tietynnimiseen klusteriin, eli tämä klusteri pystyy sijoittamaan tehtävänsä tälle palvelimelle. Emme ole vielä luoneet klusteria, mutta käytämme tätä nimeä luodessasi sitä.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametri määrittää, että kun vastaanotetaan signaali spot-instanssin sammuttamiseksi, kaikki sen tehtävät tulee siirtää tyhjennystilaan.
ECS_CONTAINER_STOP_TIMEOUT=1m - parametri määrittää, että SIGINT-signaalin vastaanottamisen jälkeen kaikilla tehtävillä on 1 minuutti ennen kuin ne tapetaan.
ECS_ENGINE_AUTH_TYPE=docker — parametri osoittaa, että Docker-mallia käytetään valtuutusmekanismina
ECS_ENGINE_AUTH_DATA=... — yhteysparametrit yksityiseen säilörekisteriin, johon Docker-kuvasi on tallennettu. Jos se on julkinen, sinun ei tarvitse määrittää mitään.
Käytän tätä artikkelia varten julkista kuvaa Docker Hubista, joten määritä parametrit ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ei tarvitse.
Hyvä tietää: On suositeltavaa päivittää AMI säännöllisesti, koska uudet versiot päivittävät Dockerin, Linuxin, ECS-agentin jne. versioita. Voit unohtaa tämän uusien versioiden julkaisemisesta. Voit vastaanottaa ilmoituksia sähköpostitse ja päivittää manuaalisesti tai voit kirjoittaa Lambda-toiminnon, joka luo automaattisesti uuden version Launch Templatesta, jossa on päivitetty AMI.
EC2 Auto Scaling Group
Auto Scaling Group vastaa ilmentymien käynnistämisestä ja skaalauksesta. Ryhmiä hallitaan osiossa EC2 -> Auto Scaling -> Auto Scaling Groups.
Käynnistä malli — valitse edellisessä vaiheessa luotu malli. Jätämme oletusversion.
Ostovaihtoehdot ja ilmentymätyypit — määrittää klusterin ilmentymien tyypit. Noudata käynnistysmallia käyttää instanssityyppiä Launch Templatesta. Yhdistämällä ostovaihtoehtoja ja ilmentymätyyppejä voit määrittää ilmentymätyyppejä joustavasti. Käytämme sitä.
Valinnainen on-demand-pohja — säännöllisten, ei-spot-tapahtumien määrä, jotka toimivat aina.
On-demand prosenttiosuus perustason yläpuolella — tavallisten ja spot-esiintymien prosenttiosuus, 50-50 jaetaan tasaisesti, 20-80 jokaista tavallista esiintymää kohden nostetaan 4 spottia. Tässä esimerkissä merkitsen 50-50, mutta todellisuudessa teemme useimmiten 20-80, joissakin tapauksissa 0-100.
Ilmentymien tyypit — Tässä voit määrittää muita esiintymätyyppejä, joita käytetään klusterissa. Emme koskaan käyttäneet sitä, koska en oikein ymmärrä tarinan merkitystä. Ehkä tämä johtuu tietyntyyppisten esiintymien rajoituksista, mutta niitä voidaan helposti lisätä tuen avulla. Jos tiedät sovelluksen, luen sen mielelläni kommenteissa)
verkko — verkkoasetukset, valitse VPC ja koneiden aliverkot, useimmissa tapauksissa kannattaa valita kaikki käytettävissä olevat aliverkot.
Kuormituksen tasapainoittaminen - tasapainottimen asetukset, mutta teemme tämän erikseen, emme koske täällä mihinkään. Terveystarkastukset konfiguroidaan myös myöhemmin.
Ryhmän koko — ilmoitamme alussa klusterin koneiden lukumäärän rajat ja halutun koneiden määrän. Koneiden määrä klusterissa ei koskaan ole pienempi kuin määritetty vähimmäismäärä ja suurempi kuin enimmäismäärä, vaikka skaalaus tapahtuisi mittareiden mukaan.
Skaalauskäytännöt - skaalausparametrit, mutta skaalaamme käynnissä olevien ECS-tehtävien perusteella, joten määritämme skaalauksen myöhemmin.
Instanssisuojaus — tapausten suojaus poistumista vastaan skaalattaessa. Otamme sen käyttöön, jotta ASG ei poista konetta, jolla on käynnissä olevia tehtäviä. ECS Capacity Provider poistaa suojauksen käytöstä tapauksissa, joissa ei ole tehtäviä.
Lisää tageja — voit määrittää tageja ilmentymille (tätä varten Merkitse uudet esiintymät -valintaruutu on oltava valittuna). Suosittelen nimitunnisteen määrittämistä, jolloin kaikilla ryhmän sisällä käynnistetyillä esiintymillä on sama nimi ja niitä on kätevää tarkastella konsolissa.
Kun olet luonut ryhmän, avaa se ja siirry Lisäasetukset-osioon Miksi kaikki vaihtoehdot eivät näy konsolissa luontivaiheessa.
Irtisanomisen säännöt — säännöt, jotka otetaan huomioon instanssien poistamisessa. Niitä sovelletaan järjestyksessä. Käytämme yleensä alla olevassa kuvassa olevia. Ensin poistetaan esiintymät, joissa on vanhin Launch Template (jos esimerkiksi päivitimme AMI:n, loimme uuden version, mutta kaikki esiintymät onnistuivat siirtymään siihen). Sitten valitaan ne esiintymät, jotka ovat lähinnä seuraavaa laskutustuntia. Ja sitten valitaan vanhimmat julkaisupäivän perusteella.
Hyvä tietää: päivittää kaikki klusterin koneet, kätevä käyttää . Jos yhdistät tämän edellisen vaiheen Lambda-toimintoon, saat täysin automaattisen ilmentymän päivitysjärjestelmän. Ennen kuin päivität kaikki koneet, sinun on poistettava ilmentymien skaalaussuojaus käytöstä kaikista ryhmän ilmentymistä. Ei konfigurointia ryhmässä, vaan suojaus itse koneilta, tämä tehdään Ilmentymien hallinta -välilehdellä.
Application Load Balancer ja EC2 kohderyhmä
Tasapainotin luodaan osiossa EC2 → Load Balancing → Load Balancers. Käytämme Application Load Balanceria; erityyppisten tasapainottimien vertailu on luettavissa osoitteessa .
kuuntelijoita - On järkevää tehdä portit 80 ja 443 ja ohjata 80:sta 443:een tasapainotussäännöillä myöhemmin.
Saatavuusalueet - Useimmissa tapauksissa valitsemme esteettömyysvyöhykkeet kaikille.
Määritä suojausasetukset — Tässä näkyy tasapainottimen SSL-sertifikaatti, kätevin vaihtoehto on ACM:ssä. Tietoja eroista Turvallisuuspolitiikka voidaan lukea sisään , voit jättää sen oletusarvoisesti valituksi ELBSecurityPolicy-2016-08. Kun olet luonut tasapainottimen, näet sen DNS-nimi, jonka sinun on määritettävä verkkotunnuksesi CNAME. Esimerkiksi tältä se näyttää Cloudflaressa.
Turvallisuusryhmä — luo tai valitse tasapainottimelle suojausryhmä, kirjoitin tästä lisää juuri edellä kohdassa EC2 Launch Template → Network settings.
Kohderyhmä — Luomme ryhmän, joka vastaa pyyntöjen reitittämisestä tasapainottimesta koneille ja niiden saatavuuden tarkistamisesta, jotta ne voidaan vaihtaa ongelmatilanteissa. Kohdetyyppi täytyy olla instanssi, Protokolla и portti jos käytät HTTPS-yhteyttä tasapainottimen ja ilmentymien väliseen viestintään, sinun on ladattava varmenne niihin. Tässä esimerkissä emme tee tätä, jätämme yksinkertaisesti portin 80.
Terveystarkastukset — parametrit palvelun toimivuuden tarkistamiseksi. Oikeassa palvelussa tämän pitäisi olla erillinen pyyntö, joka toteuttaa tärkeitä osia liiketoimintalogiikasta, tässä esimerkissä jätän oletusasetukset. Seuraavaksi voit valita pyyntövälin, aikakatkaisun, onnistumiskoodit jne. Esimerkissämme ilmoitamme onnistumiskoodit 200-399, koska käytettävä Docker-kuva palauttaa 304-koodin.
Rekisteröi tavoitteet — Täällä valitaan ryhmän autot, mutta meidän tapauksessamme sen tekee ECS, joten ohitamme tämän vaiheen.
Hyvä tietää: Tasapainottajatasolla voit ottaa käyttöön lokit, jotka tallennetaan S3:een tietyssä vaiheessa . Sieltä ne voidaan viedä kolmannen osapuolen palveluihin analytiikkaa varten tai voit tehdä SQL-kyselyitä suoraan S3:n tiedoista . Se on kätevä ja toimii ilman lisäkoodia. Suosittelen myös lokien poistamisen määrittämistä S3-ämpäristä tietyn ajan kuluttua.
ECS-tehtävän määritelmä
Aiemmissa vaiheissa loimme kaiken palveluinfrastruktuuriin liittyvän, nyt siirrymme lanseeraavien konttien kuvaukseen. Tämä tehdään osiossa ECS → Task Definitions.
Käynnistystyypin yhteensopivuus - valitse EC2.
Tehtävän suorittamisen IAM-rooli - valita ecsTaskExecutionRole. Sen avulla kirjoitetaan lokeja, annetaan pääsy salaisiin muuttujiin jne.
Napsauta Säilön määritelmät -osiossa Lisää säilö.
Kuva — linkki kuvaan, jossa on projektikoodi; tässä esimerkissä käytän julkista kuvaa Docker Hubista .
Muistin rajoitukset — säiliön muistirajat. Kova raja — kova raja, jos kontti ylittää määritetyn arvon, suoritetaan telakointiaseman tappamiskomento, kontti kuolee välittömästi. Pehmeä raja — pehmeä raja, säiliö voi ylittää määritetyn arvon, mutta tämä parametri otetaan huomioon tehtäessä koneille. Jos koneessa on esimerkiksi 4 GiB RAM-muistia ja säilön pehmeä raja on 2048 MiB, tällä koneella voi olla enintään 2 käynnissä olevaa tehtävää tämän säilön kanssa. Todellisuudessa 4 GiB RAM-muistia on hieman vähemmän kuin 4096 MiB, tämä näkyy klusterin ECS-instanssit-välilehdellä. Pehmeä raja ei voi olla suurempi kuin kova raja. On tärkeää ymmärtää, että jos yhdessä tehtävässä on useita säiliöitä, niiden rajat lasketaan yhteen.
Porttikartoitukset - klo Isäntäportti Osoitamme 0, mikä tarkoittaa, että portti osoitetaan dynaamisesti ja kohderyhmä valvoo sitä. Kontin portti — portti, jossa sovelluksesi toimii, on usein määritetty suorituskomennossa tai määritetty sovelluskoodissasi, Dockerfile-tiedostossa jne. Esimerkissämme käytämme 3000, koska se on listattu käytettävä kuva.
Terveystarkastus — Säilön kuntotarkastusparametrit, joita ei pidä sekoittaa kohderyhmässä määritettyyn parametriin.
ympäristö - ympäristöasetukset. CPU-yksiköt - samanlainen kuin Muistirajat, vain prosessorin osalta. Kukin prosessoriydin on 1024 yksikköä, joten jos palvelimessa on kaksiytiminen prosessori ja säilö on asetettu arvoon 512, 4 tehtävää tällä säilöllä voidaan käynnistää yhdellä palvelimella. Prosessoriyksiköt vastaavat aina ytimien määrää, niitä ei voi olla vähän vähemmän, kuten muistin tapauksessa.
Komento — komento palvelun käynnistämiseksi säilön sisällä, kaikki parametrit määritellään pilkuilla erotettuina. Tämä voi olla gunicorn, npm jne. Jos sitä ei ole määritetty, käytetään Dockerfile-tiedoston CMD-direktiivin arvoa. Osoitamme npm,start.
Ympäristömuuttujat — konttiympäristömuuttujat. Tämä voi olla joko yksinkertaista tekstidataa tai salaisia muuttujia tai .
Varastointi ja kirjaaminen - Tässä määritämme kirjautumisen CloudWatch Logsiin (AWS:n lokien palvelu). Voit tehdä tämän ottamalla käyttöön CloudWatch-lokien automaattinen määritys -valintaruudun. Tehtävämäärittelyn luomisen jälkeen CloudWatchiin luodaan automaattisesti lokiryhmä. Oletuksena lokit tallennetaan siihen määräämättömän ajan; suosittelen Säilytysjakson vaihtamista Ei koskaan vanhenemisesta vaadittuun ajanjaksoon. Tämä tehdään CloudWatch Log -ryhmissä, sinun on napsautettava nykyistä jaksoa ja valittava uusi.
ECS-klusteri ja ECS-kapasiteetin tarjoaja
Luo klusteri siirtymällä kohtaan ECS → Klusterit. Valitsemme malliksi EC2 Linux + Networking.
Ryhmän nimi - erittäin tärkeää, teemme tässä saman nimen kuin Launch Template -parametrissa on määritetty ECS_CLUSTER, meidän tapauksessamme - DemoApiClusterProd. Valitse Luo tyhjä klusteri -valintaruutu. Vaihtoehtoisesti voit ottaa Container Insightsin käyttöön nähdäksesi palvelujen mittareita CloudWatchissa. Jos teit kaiken oikein, ECS-instanssit-osiossa näet koneet, jotka on luotu Automaattinen skaalaus -ryhmässä.
Siirry välilehteen Kapasiteetintarjoajat ja luo uusi. Haluan muistuttaa, että sitä tarvitaan ohjaamaan koneiden luomista ja sammuttamista käynnissä olevien ECS-tehtävien määrästä riippuen. On tärkeää huomata, että palveluntarjoaja voidaan määrittää vain yhteen ryhmään.
Automaattinen skaalausryhmä — valitse aiemmin luotu ryhmä.
Hallittu skaalaus — Ota se käyttöön, jotta palveluntarjoaja voi skaalata palvelua.
Tavoitekapasiteetti % — kuinka monta prosenttia tehtävillä ladattuja koneita tarvitsemme. Jos määrität 100%, kaikki koneet ovat aina kiireisiä käynnissä olevien tehtävien kanssa. Jos määrität 50%, puolet autoista on aina ilmaisia. Tässä tapauksessa, jos kuorma hyppää jyrkästi, uudet taksit pääsevät välittömästi vapaisiin autoihin ilman, että joutuisi odottamaan tapausten käyttöönottoa.
Hallittu irtisanomissuoja — Ota käyttöön, tämän parametrin avulla palveluntarjoaja voi poistaa ilmentymien suojauksen poistoa vastaan. Tämä tapahtuu, kun koneessa ei ole aktiivisia tehtäviä ja sallii Tavoitekapasiteetin%.
ECS-palvelu ja skaalausasetukset
Viimeinen vaihe :) Luodaksesi palvelun, sinun on siirryttävä aiemmin luotuun klusteriin Palvelut-välilehdellä.
Käynnistystyyppi — sinun on napsautettava Vaihda kapasiteetintarjoajastrategiaan ja valittava aiemmin luodut palveluntarjoajat.
Tehtävän määritelmä — valitse aiemmin luotu Task Definition ja sen versio.
Palvelun nimi — Sekaannusten välttämiseksi merkitsemme aina saman kuin Tehtävämäärittely.
Palvelutyyppi - aina kopio.
Tehtävien määrä — haluttu aktiivisten tehtävien määrä palvelussa. Tätä parametria ohjataan skaalauksella, mutta se on silti määritettävä.
Minimi terve prosentti и Maksimiprosentti — määrittää tehtävien käyttäytyminen käyttöönoton aikana. Oletusarvot ovat 100 ja 200, mikä tarkoittaa, että käyttöönoton aikana tehtävien määrä kasvaa useita kertoja ja palaa sitten haluttuun arvoon. Jos sinulla on 1 tehtävä käynnissä, min = 0 ja max = 100, niin se lopetetaan käyttöönoton aikana ja sen jälkeen nostetaan uusi, eli se on seisokki. Jos 1 tehtävä on käynnissä, min=50, max=150, käyttöönottoa ei tapahdu ollenkaan, koska yhtä tehtävää ei voi jakaa puoliksi tai kasvattaa puolitoista kertaa.
Käyttöönoton tyyppi - poistu jatkuvasta päivityksestä.
Sijoittelumallit — säännöt tehtävien asettamisesta koneille. Oletus on AZ Balanced Spread – tämä tarkoittaa, että jokainen uusi tehtävä sijoitetaan uuteen esiintymään, kunnes kaikkien käytettävyysalueiden koneet nousevat. Teemme yleensä BinPack - CPU ja Spread - AZ; tällä käytännöllä tehtävät sijoitetaan mahdollisimman tiheään yhteen koneeseen prosessoria kohden. Jos on tarpeen luoda uusi kone, se luodaan uudelle käytettävyysvyöhykkeelle.
Kuormantasaajan tyyppi — valitse Application Load Balancer.
Palvelun IAM-rooli - valita ecsServiceRole.
Kuormantasaajan nimi — valitse aiemmin luotu tasapainotin.
Terveystarkastuksen lisäaika — tauko ennen terveystarkastusten suorittamista uuden tehtävän käyttöönoton jälkeen, yleensä asetamme sen 60 sekuntiin.
Säiliö kuorman tasapainottamiseen — Valitse Kohderyhmän nimi -kohdassa aiemmin luotu ryhmä, niin kaikki täytetään automaattisesti.
Palvelun automaattinen skaalaus — palvelun skaalausparametrit. Valitse Configure Service Auto Scaling säätääksesi palvelun haluamaasi määrää. Asetamme tehtävien vähimmäis- ja enimmäismäärän skaalattaessa.
IAM-rooli palvelun automaattisessa skaalauksessa - valita AWSServiceRoleForApplicationAutoScaling_ECSService.
Automaattiset tehtävien skaalauskäytännöt — skaalaussäännöt. Niitä on 2 tyyppiä:
- Kohteen seuranta — tavoitemittojen seuranta (suorittimen/RAM-käyttö tai kunkin tehtävän pyyntöjen määrä). Haluamme esimerkiksi, että prosessorin keskimääräinen kuormitus on 85 %, kun se kasvaa, uusia tehtäviä lisätään, kunnes se saavuttaa tavoitearvon. Jos kuormitus on pienempi, tehtävät poistetaan, päinvastoin, ellei pienennyssuoja ole käytössä (Poista skaalaus käytöstä).
- Askelskaalaus - reagointi mielivaltaiseen tapahtumaan. Täällä voit määrittää reaktion mihin tahansa tapahtumaan (CloudWatch Alarm), kun se tapahtuu, voit lisätä tai poistaa määritetyn määrän tehtäviä tai määrittää tarkan tehtävien määrän.
Palvelulla voi olla useita skaalaussääntöjä, tämä voi olla hyödyllistä, tärkeintä on varmistaa, etteivät ne ole ristiriidassa keskenään.
Johtopäätös
Jos noudatit ohjeita ja käytit samaa Docker-kuvaa, palvelusi pitäisi palauttaa tämän kaltainen sivu.
- Olemme luoneet mallin, jonka mukaan kaikki palvelun koneet käynnistetään. Opimme myös päivittämään koneita, kun malli muuttuu.
- Olemme konfiguroineet spot-instanssin pysäytyssignaalin käsittelyn, joten minuutin kuluessa sen vastaanottamisesta kaikki käynnissä olevat tehtävät poistetaan koneesta, joten mitään ei katoa tai keskeydy.
- Nostimme tasapainotinta jakaaksemme kuorman tasaisesti koneille.
- Olemme luoneet paikan päällä toimivan palvelun, joka pienentää koneen kustannuksia noin 3 kertaa.
- Olemme määrittäneet automaattisen skaalauksen molempiin suuntiin käsittelemään lisääntynyttä työmäärää ilman seisokkikuluja.
- Käytämme Capacity Provideria, jotta sovellus hallitsee infrastruktuuria (koneita) eikä päinvastoin.
- Olemme mahtavia.
Jos sinulla on ennakoitavissa olevia kuormituspiikkejä, esimerkiksi mainostat suuressa sähköpostikampanjassa, voit määrittää skaalauksen .
Voit myös skaalata järjestelmän eri osien tietojen perusteella. Meillä on esimerkiksi toiminnallisuus mobiilisovelluksen käyttäjiä. Joskus kampanja lähetetään yli miljoonalle ihmiselle. Tällaisen jakelun jälkeen API-pyynnöt lisääntyvät aina voimakkaasti, koska monet käyttäjät kirjautuvat sovellukseen samanaikaisesti. Joten jos näemme, että mainoksen push-ilmoitusten lähetysjonossa on huomattavasti enemmän vakio-indikaattoreita, voimme käynnistää välittömästi useita lisäkoneita ja tehtäviä ollaksemme valmiita lataukseen.
Olen iloinen, jos kerrot minulle kommenteissa mielenkiintoisia tapauksia spot-instanssien ja ECS:n käytöstä tai jotain skaalauksesta.
Pian tulee artikkeleita siitä, kuinka käsittelemme tuhansia analyyttisiä tapahtumia sekunnissa pääosin palvelimettomalla pinolla (rahalla) ja kuinka palveluiden käyttöönotto toimii GitLab CI:n ja Terraform Cloudin avulla.
Tilaa meille, se on mielenkiintoista!
Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. , ole kiltti.
Käytätkö spot-esiintymiä tuotannossa?
-
22,2%Kyllä 6
-
66,7%Nro 18
-
11,1%Opin niistä artikkelista ja aion käyttää niitä3
27 käyttäjää äänesti. 5 käyttäjää pidättyi äänestämästä.
Lähde: will.com