🥇Skaleeritava API loomine AWS spottinstantsidel

Tere kõigile! Olen Kirill, Adapty CTO. Suur osa meie arhitektuurist asub AWS-is ja täna räägin, kuidas me vähendasime serverikulud kolmandiku võrra, kasutades spot-instantte tootmisümbruses, samuti sellest, kuidas neid automaatselt skaalaida. Esiteks, tutvustus, kuidas see töötab, ja seejärel põhjalik juhend käivitamiseks.

Mis on spot-instantid?

Spot-instantid on AWS-i teiste kasutajate serverid, mis on hetkel kasutamata, ja nad müüvad neid suure allahindlusega (Amazon kirjutab kuni 90%, meie kogemuse järgi on see ~3x, varieerub olenevalt piirkonnast, AZ-st ja instanttüübist). Peamine erinevus tavainstantidest on see, et need võivad igal hetkel välja lülituda. Seetõttu arvasime kaua, et nende kasutamine on normaalne arenduskeskkondades või ülesannete arvutamisel, salvestades vahepealsed tulemused S3-sse või andmebaasi, kuid mitte tootmises. On olemas kolmandate osapoolte lahendusi, mis võimaldavad spot-e tootmises kasutada, kuid seal meie juhtumi korral on palju töökohustuslikke lahendusi, seetõttu ei rakendanud me neid. Artiklis kirjeldatud lähenemine töötab täielikult AWS-i standardsete funktsioonide raames, ilma täiendavate skriptide, cronide jne.

Järgnevalt toon mõned ekraanipildid, mis näitavad spot-instantide hindade ajalugu.

m5.large piirkonnas eu-west-1 (Iirimaa). Hind on peamiselt stabiilne 3 kuu jooksul, praegu on kokkuhoid 2.9x.

m5.large piirkonnas us-east-1 (Põhja-Virginia). Hind muutub pidevalt 3 kuu jooksul, praegu on kokkuhoid vahemikus 2.3x kuni 2.8x sõltuvalt kättesaadavuse tsoonist.

t3.small piirkonnas us-east-1 (Põhja-Virginia). Hind on stabiilne 3 kuu jooksul, praegu on kokkuhoid 3.4x.

Teenuse arhitektuur

Otsese teenuse põhiarhitektuur, millest me selles artiklis räägime, on kujutatud alloleval diagrammil.

Application Load Balancer → EC2 sihtgrupp → Elastne konteinerite teenus

Balansseerijana kasutatakse Application Load Balancerit (ALB), mis suunab päringud EC2 sihtgruppi (TG). TG vastutab portide avamise eest instantides ALB jaoks ja nende sidumise eest Elastse konteinerite teenuse (ECS) konteinerite portidega. ECS on AWS-i Kubernetes, mis tegeleb Docker konteinerite haldamisega.

Ühel instantsil võib olla mitu töötavat konteinerit sama portidega, seega ei saa me neid fikseeritud määrata. ECS teatab TG-le, et käivitab uue ülesande (Kubernetes'i terminoloogias nimetatakse seda pod'iks), see kontrollib instantsil vabu porte ja määrab ühe neist käitatavale ülesandele. TG kontrollib regulaarselt, kas instants ja selle API töötavad läbi tervisekontrolli ning kui märkab mingeid probleeme, lõpetab see sinna päringute edastamise.

EC2 Auto Scaling Groups + ECS Capacity Providers

Ülaltoodud diagrammil ei ole kujutatud EC2 Auto Scaling Groups (ASG) teenust. Nimi ütleb, et see vastutab instantside skaleerimise eest. Kuid kuni hiljuti ei võimaldanud AWS integreeritud võimalust hallata ECS-ist käivitatud masinate arvu. ECS võimaldas skaleerida ülesannete arvu, näiteks CPU, RAM või päringute arvu alusel. Kuid kui ülesanded hõivasid kõik vabad instantsid, siis uusi masinaid automaatselt ei tõstatud.

See muutus koos ECS Capacity Providers (ECS CP) ilmumisega. Nüüd saab iga teenuse ECS-is siduda ASG-ga, ja kui ülesanded ei mahutu töötavatele instantsidele, tõstetakse uusi (kuid ASG kehtestatud piirangute raames). See töötab ka vastupidiselt: kui ECS CP näeb rippuvaid instantsid ilma ülesanneteta, annab see ASG-le käsu need välja lülitada. ECS CP-l on võimalus määrata sihtkoormuse protsent, et teatud hulk masinaid oleks alati vaba kiireks ülesannete skaleerimiseks, sellest räägin vähese aja pärast.

EC2 Launch Templates

Viimane teenus, millest ma räägin enne, kui lähen selle infrastruktuuri loomise üksikasjalikule kirjeldamisele, on EC2 Launch Templates. See võimaldab luua шаблон, mille järgi kõik masinad käivitatakse, et seda ei peaks iga kord nullist kordama. Siin saab valida käivitatava masina tüübi, turvagruppi, ketta kujunduse ja palju muid parameetreid. Samuti saab määrata kohandatud andmeid, mis laaditakse kõikidele käivitatavatele instantsidele. Kohandatud andmete kaudu saab käivitada skripte, näiteks saab redigeerida faili sisu ECS agendi konfiguratsioon.

Üks kõige olulisemaid konfiguratsiooni parameetreid antud artiklis on ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Kui see parameeter on sisse lülitatud, siis kui ECS saab signaali, et spottinstanss on eemaldamiseks, muudab ta kõik sellel töötavad ülesanded staatusesse Draining. Uusi ülesandeid sellele instantsile ei määrata, kui on ülesandeid, mis soovivad sinna voolata, siis need tühistatakse. Tasakaalustajatelt ei tule ka uusi päringuid. Teade instantsi eemaldamisest saabub kaks minutit enne tegelikku sündmust. Seetõttu, kui teie teenus ei tee tööd kauem kui 2 minutit ja ei salvesta midagi kettale, siis võite kasutada spottinstantsse ilma andmete kaotuseta.

Ketta osas — AWS tegi hiljuti saadaval , et kasutada Elastic File System (EFS) koos ECS-iga; sellise skeemi puhul ei ole ketas takistuseks, kuid me ei ole seda proovinud, kuna põhimõtteliselt ei ole meil ketast oleku salvestamiseks vaja. Vaikimisi, kui saadetakse SIGINT (saadetakse hetkel, kui ülesanne muudetakse staatusesse Draining), lõpetatakse kõik töötavad ülesanded 30 sekundi jooksul, isegi kui nad ei ole valmis saanud, seda aega saab muuta parameetri ECS_CONTAINER_STOP_TIMEOUT. Peamine on mitte seada seda rohkem kui 2 minutit spottmasinate jaoks.

Teenuse loomine

Liigume otse nimetatud teenuse loomise juurde. Protsessi käigus kirjeldan täiendavalt mitmeid kasulikke punkte, millest eelnevalt ei räägitud. Üldiselt on see samm-sammult juhend, kuid mõned täiesti põhialused või vastupidi, väga spetsiifilised juhtumid ei ole mul kavas käsitleda. Kõik toimingud toimuvad AWS visuaalses konsoolis, kuid neid saab programmiliselt korrata CloudFormationi või Terraformi abil. Adapty-s kasutame Terraformi.

EC2 käivitamisšabloon

Selles teenuses luuakse masinate konfiguratsioon, mida kasutatakse. Šabloonide haldamine toimub jaotises EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — määrame ketta kuju, millega kõik instantsid käivituvad. ECS-i jaoks on enamasti mõistlik kasutada Amazon'i optimeeritud kujutist. See uuendatakse regulaarselt ja sisaldab kõike vajalikku ECS-i tööks. Aktiivse kujutise ID teadmiseks külastage lehte Amazon ECS-optimized AMIs, valige kasutatav piirkond ja kopeerige AMI ID selle jaoks. Näiteks us-east-1 piirkonnas on kirjutamise hetkel aktiivne ID — ami-00c7c1cf5bdc913ed. Selle ID tuleks sisestada punkti Specify a custom value.

Instantsi tüüp — määrake instantsi tüüp. Valige see, mis sobib teie ülesandele kõige paremini.

Ava võtmepaar (sisselogimine) — määrake sertifikaat, millega saab instantsi SSH kaudu ühenduda, kui vajadus peaks tekkima.

Võrgu seaded — määrake võrgu parameetrid. Võrgustiku platvorm enamikul juhtudel peaks olema Virtuaalne Erakliendi Võrk (VPC). Turvagruppide — turvagruppid teie instantside jaoks. Kuna me kasutame instantside ees koormuse tasakaalustajat, soovitan siin määrata grupi, mis lubab sissetulevad ühendused ainult koormuse tasakaalustajalt. See tähendab, et teil on 2 turvagruppi: üks koormuse tasakaalustajale, mis lubab sissetulevaid (inbound) ühendusi igalt poolt portide 80 (http) ja 443 (https) kaudu, ning teine masinate jaoks, mis lubab sissetulevaid ühendusi mistahes portide kaudu koormuse tasakaalustaja grupilt. Väljaminevad (outbound) ühendused mõlemas grupis tuleb avada kõigile portidele TCP protokolli kaudu kõikidesse aadressidesse. Väljaminevaid ühendusi on võimalik piirata portide ja aadressidega, kuid siis on vaja pidevalt jälgida, et te ei üritaks suhelda suletud portide kaudu.

Salvestus (maht) — määrake masinate ketaste parameetrid. Ketta maht ei tohi olla väiksem kui see, mis on määratud AMI-s, ECS Optimizatsiooni jaoks — 30 GiB.

Täiendavad üksikasjad — määrake täiendavad parameetrid.

Ostuvõimalus — kas soovime osta spoot instantsid. Me soovime, kuid seda märki me siin ei pane, seadistame selle Auto Scaling Groupis, seal on rohkem valikuid.

IAM instantsi profiil — määrake roll, millega instantsid käivituvad. Et instantsid töötaksid ECS-is, on neil vaja õigusi, mis tavaliselt kuuluvad rollile ecsInstanceRole. Mõnel juhul võib see olla loodud; kui ei, siis siin juhend kuidas seda teha. Pärast loomist määrame selle mallis.
Edasi on palju parameetreid, enamikul juhtudel võib jätta vaikeseaded, kuid igaühel on arusaadav kirjeldus. Ma alati lülitan sisse EBS-optimeeritud instansi ja T2/T3 Unlimited, kui need on kasutusel burstable instantside jaoks.

Kasutajate andmed — määrake kasutaja andmed. Me redigeerime faili /etc/ecs/ecs.config, kus asub ECS-i agendi konfiguratsioon.
Näide sellest, milline kasutaja andmed välja võivad näha:

#!/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 — parameeter näitab, et instants kuulub määratud nimega klastrisse, st see klaster saab oma ülesandeid sellele serverile paigutada. Me pole veel klastrit loonud, kuid selle loomisel kasutame seda nime.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameeter näitab, et spottinstansi väljalülitamise signaali saamisel peavad kõik selle ülesanded olema määratud staatusele Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m — parameeter näitab, et pärast SIGINT signaali saamist on kõigil ülesannetel 1 minut, enne kui need lõpetatakse.

ECS_ENGINE_AUTH_TYPE=docker — parameeter näitab, et autoriseerimise mehhanismina kasutatakse docker skeemi.

ECS_ENGINE_AUTH_DATA=... — seosed privaatse konteineriregistriga, kus teie Docker pildid asuvad. Kui see on avalik, pole midagi täpsustama.

Käesolevas artiklis kasutan avalikku pilti Docker Hub'ist, seega ei tule seoseid täpsustada. ECS_ENGINE_AUTH_TYPE ja ECS_ENGINE_AUTH_DATA ei ole vajalik.

Kasulik teada: soovitatakse regulaarselt uuendada AMI-d, sest uutes versioonides uuendatakse Docker, Linux, ECS agente jne. Et sellest mitte unustada, võite seada teavitused uusversioonide väljatulekust. Saate teavitusi e-posti teel ja uuendada käsitsi või saate kirjutada Lambda-funktsiooni, mis loob automaatselt uue versiooni Launch Template'ist koos uuendatud AMI-ga.

EC2 Auto Scaling Group

Auto Scaling Group vastutab instantside käivitamise ja skaleerimise eest. Gruppide juhtimine toimub jaotises EC2 -> Auto Scaling -> Auto Scaling Groups.

Launch template — valime eelmisel sammul loodud mall. Versioon jääb vaikeseadeks.

Ostuvalikud ja instantside tüübid — määrame klastrile instantside tüübid. Adhere to launch template kasutab Launch Template'ist instantsitüüpi. Combine purchase options and instance types võimaldab paindlikult konfigureerida instantside tüüpe. Me kasutame seda.

Valikuline On-Demand baaspunkt — tavaliste, mitte-spottinstantside arv, mis töötavad alati.

On-Demand protsentuaalne suhe baaspunkti üle — tavaliste ja spottinstantside protsentuaalne suhe, 50-50 jagab võrdselt, 20-80 tähendab, et iga tavalise instantsi kohta tõuseb 4 spottinstantsi. Antud näites määran 50-50, kuid tegelikult teeme enamasti 20-80, mõnedel juhtudel 0-100.

Instantside tüübid — siit saab täpsustada täiendavaid instantsi tüüpe, mida kasutatakse klastris. Me ei ole seda kunagi kasutanud, kuna ma ei mõista eriti selle loo eesmärki. Võib-olla on teema instantsi tüüpide piirangutes, kuid need suurenevad toetuse kaudu kergesti. Kui tead rakendusest, oleksin tänulik, kui jagaksid kommentaarides)

Võrk — võrguseaded, valida VPC ja alamvõrgud masinate jaoks, enamikul juhtudel tasub valida kõik saadaval olevad alamvõrgud.

Koormuse tasakaalustamine — tasakaalustaja seaded, kuid selle teeme eraldi, siin me midagi ei muuda. Tervisekontrollid ka seadistatakse hiljem.

Rühma suurus — määrame piirangud klastris olevate masinate arvu ja soovitud masinate arvu alguses. Klastris olevate masinate arv ei muutu kunagi väiksemaks kui minimaalne ja suuremaks kui maksimaalne, isegi kui mõõdikute puhul peaks toimuma skaleerimine.

Skaleerimisreeglid — skaleerimise seaded, kuid me skaleerime käivitatud ECS ülesandeid silmas pidades, seetõttu seadistame skaleerimise hiljem.

Instantsi skalaarse sissetoodud kaitse — instantside kaitse eemaldamise eest skaleerimise ajal alla poole. Lülitame sisse, et ASG ei kustutaks masinat, millel on käivitatud ülesanded. Kaitse eemaldamine instantsidelt, millel pole ülesandeid, toimub ECS Capacity Provideri kaudu.

Lisa silte — saab määrata silte instantsidele (selleks peab olema märgitud kinnitus 'Tag new instances'). Soovitan määrata sildi Nimi, siis on kõik grupis käivitatavad instantsid sama nimega, neid on mugav vaadata konsoolis.

Pärast grupi loomist avage see ja minge jaotisse Täiendavad seaded, miks ei ole loomise etapis konsoolis nähtavad kõik valikud.

Lõpetamisreeglid — reeglid, mida arvesse võetakse instantside eemaldamisel. Need rakenduvad järjekorras. Me kasutame tavaliselt selliseid, nagu alloleval joonisel. Esiteks kustutatakse instantsid, millel on kõige vanem Launch Template (näiteks kui oleme uuendanud AMI, oleme loonud uue versiooni, kuid kõik instantsid on jõudnud sellele üle minna). Siis valitakse instantsid, mis on kõige lähemal järgmisele arvelduseale. Ja edasi valitakse vanimad käivitamise kuupäeva järgi.

Kasulik teada: kõigi klastris olevate masinate uuendamiseks on mugav kasutada Instantsi värskendus. Kui kombineerida see eelneva sammu Lambda funktsiooniga, on teil täielikult automatiseeritud instantside värskendamise süsteem. Enne kõigi masinate värskendamist tuleb kõigi grupi instantside jaoks keelata instantsi skaalakaitse. See ei ole grupi seade, vaid kaitse ise masinatel, mida saab teha Instantsihalduse vahekaardil.

Rakenduse Load Balancer ja EC2 sihtrühm

Balansseerija luuakse EC2 → Load Balancing → Load Balancers. Kasutame rakenduse Load Balancerit, erinevate tasemete balansseerijate võrdlemist saate lugeda teenuse lehelt.

Kuulajad — on mõistlik teha 80 ja 443 porti ning suunata 80-lt 443-le balanseerija reeglite abil.

Saadavuspiirkonnad — enamikul juhtudel valime kõik saadavuspiirkonnad.

Konfigureeri turvaseaded — siin määratakse SSL-sertifikaat balansseerija jaoks, mugavaim valik on teha sertifikaat ACM-is. Erinevuste kohta Turvapoliitika võite lugeda dokumentatsioon, võib jätta vaikimisi valitud ELBSecurityPolicy-2016-08. Pärast balansseerija loomist näete selle DNS nime, millele tuleb seadistada CNAME teie domeeni jaoks. Näiteks näeb see Cloudflays välja nii.

Turgrupp — loome või valime balansseerija jaoks turvagruppi, mille kohta olen varem rohkem kirjutanud jaotisest EC2 Launch Template → Võrguseaded.

Sihtrühm — loome rühma, mis vastutab päringute suunamise eest balansseerijalt masinatele ja kontrollib nende kättesaadavust, et neid probleemide korral asendada. Sihi tüüp peab olema Instants, Protokoll ja Port igat tüüpi, kui kasutate HTTPS-i kontakteerumiseks balansseerija ja instantside vahel, tuleb neile laadida sertifikaat. Antud näites me seda ei tee, jäetakse lihtsalt 80 port.

Tervisekontrollid — teenuse töökindluse kontrollimise parameetrid. Tõeliselt teenuses peaks see olema eraldi päring, mis viib läbi olulised äriloogika osad, antud näites jätan vaikeseaded. Edasi saab valida päringute intervalli, aegumise, eduka vastuse koodid jne. Meie näites määrame eduka koodid 200-399, sest Docker pilt, mida kasutatakse, tagastab 304 koodi.

Registreeri sihid — siin valitakse grupile masinad, kuid meie juhul tegeleb sellega ECS, seega jätame selle sammu vahele.

Kasulik teada: balansseerija tasemel saab lubada logid, mis salvestatakse S3-s kindlas formaadis. Sealt, mida saab eksportida kolmandate osapoolte analüüsiteenustesse, või teha SQL-päringuid otse S3 andmete põhjal Athena abil. See on mugav ja töötab ilma täiendava koodita. Samuti soovitan seadistada logide eemaldamine S3 kaustast määratud aja möödudes.

ECS Ülesande Määratlemine

Varasemates etappides lõime kõik, mis on seotud teenuse infrastruktuuriga, nüüd liigume konteinerite kirjeldamise juurde, mida hakkame käivitama. Seda tehakse ECS → Task Definitions jaos.

Käivitustüübi ühilduvus — valime EC2.

Ülesande täitmise IAM-roll — valime ecsTaskExecutionRole. Selle abil kirjutatakse logisid, saadakse juurdepääs salajastele muutujatele jne.

Container Definitions jaos vajutame Lisa konteiner.

Pilt — link projekti koodi pildile, kasutame selle näite raames avalikku pilti Docker Hubist bitnami/node-example:0.0.1.

Mälu piirangud — konteineri jaoks mõeldud mälu piirangud. Jõhkrad piirangud — jõhkrad piirangud, kui konteiner ületab määratud väärtuse, käivitatakse käsk docker kill, konteiner sureb koheselt. Pehmed piirangud — pehmed piirangud, konteiner võib ületada määratud väärtuse, kuid ülesannete paigutamisel masinatele võetakse see parameeter arvesse. Näiteks, kui masinal on 4 GiB RAM-i ja konteineri pehme piirang on 2048 MiB, siis võib sellel masinal olla maksimaalselt 2 jooksvas ülesandes selle konteineriga. Tegelikult on 4 GiB RAM veidi vähem kui 4096 MiB, seda saab vaadata klastris ECS Instances vahelehelt. Pehme piirang ei saa olla suurem kui jõhkrad piirangud. Oluline on mõista, et kui ühes ülesandes on mitu konteinerit, siis nende piirangud summeeruvad.

Sadama kaardistamine — Hosti port määrame 0, see tähendab, et port määratakse dünaamiliselt, seda jälgib Target Group. Konteineri port — port, millel teie rakendus töötab, määratakse sageli täitmise käsus või määratakse teie rakenduse koodis, Dockerfile'is jne. Kasutame oma näites 3000, sest see on määratud Dockerfile kasutatavas pildis.

Tervisekontroll — konteineri töökindluse kontrollimise parameetrid, mitte segi ajada with Target Group'is seadistatud.

Keskkond — keskkonnaseaded. CPU üksused — sarnane mälu piirangutega, ainult protsessori kohta. Iga protsessorituuma kohta on 1024 ühikut, seega kui serveril on kahetuumaline protsessor ja konteineril on väärtus 512, siis saab ühel serveril käivitada 4 ülesannet selle konteineriga. CPU ühikud vastavad alati tuumade arvule, neid ei saa olla natuke vähem, nagu mälu puhul.

Käsk — käsk teenuse käivitamiseks konteineri sees, kõik parameetrid näidatakse koma kaudu. See võib olla gunicorn, npm jne. Kui ei ole määratud, kasutatakse Dockerfile'i direktiivi CMD väärtust. Näitame npm,start.

Keskkonnamuutujad — konteineri keskkonnamuutujad. Need võivad olla nii lihtsalt tekstilised andmed kui ka salajased muutujad Secrets Manager või Parameter Store.

Salvestamine ja logimine — siin seadistame logimise CloudWatch Logs'i (AWS-i logiteenus). Selleks piisab Auto-configure CloudWatch Logs'i märkimisest. Pärast Task Definition'i loomist luuakse automaatselt logigrupp CloudWatch'is. Vaikimisi säilitatakse logid seal lõpmatult; soovitan muuta Retention period'i 'Never Expire' pealt soovitud ajavahemikule. Seda tehakse CloudWatch Log groups'is, tuleb klõpsata praegusel perioodil ja valida uus.

ECS klastri ja ECS mahutuse pakkuja

Liigume jaotisse ECS → Clusters, et luua klaster. Mallina valime EC2 Linux + Networking.

Klastri nimi — väga oluline, anname siin sama nime nagu Launch Template'i parameetris ECS_CLUSTER, meie juhul — DemoApiClusterProd. Märkige Create an empty cluster. Valikuline on lubada Container Insights, et näha teenuste metrikaid CloudWatch'is. Kui olete kõik õigesti teinud, näete jaotises ECS Instances masinaid, mis loodi Auto Scaling gruppi.

Liigume vahekaardile Mahutuse pakkujad ja loome uue. Meenutan, et see on vajalik masinate loomise ja väljalülitamise haldamiseks sõltuvalt töötavate ECS ülesannete arvust. Oluline on märkida, et pakkuja saab olla seotud ainult ühe grupiga.

Auto Scaling grupp — valime varem loodud grupi.

Hallitav skaleerimine — lubame, et pakkuja saaks teenust skaleerida.

Sihtkapasiteet % — kui suur on autode koormuse protsent, mida vajame ülesannete jaoks. Kui määrata 100%, siis on kõik autod alati töötavate ülesannete poolt hõivatud. Kui määrata 50%, siis on pool autoreid alati vabad. Sellisel juhul, kui koormus järsult suureneb, saavad uued ülesanded kohe vaba autot kasutada, ilma et oleks vaja oodata instantside käivitamist.

Haldatud lõpetamisprotection — lülitame sisse, see parameeter lubab teenusepakkujal kaitsta instantside kustutamist. See juhtub, kui masinal ei ole aktiivseid ülesandeid ja see võimaldab Target capacity %.

ECS teenus ja skaleerimise seadistamine

Viimane samm:) Et luua teenus, peame minema varem loodud klastrisse vahekaardile Teenused.

Käivitamise tüüp — tuleb klõpsata valikul Switch to capacity provider strategy ja valida varem loodud pakkuja.

Ülesande määratlemine — valime varem loodud Ülesande määratluse ja selle versiooni.

Teenuse nimi — et mitte eksida, määrame selle alati samaks, mis Ülesande määratlemine.

Teenuse tüüp — alati Replica.

Ülesannete arv — soovitud aktiivsete ülesannete arv teenuses. Seda parameetrit hallatakse skaleerimise abil, kuid seda tuleb ikkagi määrata.

Minimaalne tervislik protsent ja Maksimaalne protsent — määravad ülesannete käitumise juurutamise ajal. Vaikimisi väärtused on 100 ja 200, mis näitavad, et juurutamise ajal suureneb ülesannete arv mitu korda, seejärel naaseb see soovitud tasemele. Kui teil töötab 1 ülesanne, min=0, ja max=100, siis juurutamise ajal see tapetakse, ja pärast seda tõuseb uus, see tähendab, et toimub seiskamine. Kui töötab 1 ülesanne, min=50, max=150, siis juurutamine ei toimu, sest 1 ülesannet ei saa jagada pooleks või suurendada 1.5 korda.

Juurutamise tüüp — jätame Rolling update.

Paigutuse mallid — reeglid ülesannete paigutamiseks masinatesse. Vaikimisi on AZ Balanced Spread — see tähendab, et iga uus ülesanne paigutatakse uude instantsi, kuni masinad tõusevad kõigis kättesaadavuse tsoonides. Me tavaliselt teeme BinPack — CPU ja Spread — AZ, sellise poliitikaga paigutatakse ülesanded maksimaalselt tihedalt ühe masina järgi CPU. Uue masina vajadusel luuakse see uude kättesaadavuse tsooni.

Koormuse tasakaalustaja tüüp — valime Application Load Balancer.

Teenuse IAM roll — valime ecsServiceRole.

Koormuse tasakaalustaja nimi — valime varem loodud tasakaalustaja.

Tervisekontrolli ootamisperiood — paus enne uute ülesannete töötamise kontrollide sooritamist, määrame tavaliselt 60 sekundit.

Konteiner, mida tasakaalustada — valige 'Target group name' jaoks varem loodud rühm ja kõik täitub automaatselt.

Teenuse automaatne skaleerimine — teenuse skaleerimise parameetrid. Valige 'Configure Service Auto Scaling to adjust your service’s desired count'. Määrake minimaalne ja maksimaalne tööde arv skaleerimise ajal.

IAM-rolle teenuse automaatseks skaleerimiseks — valime AWSServiceRoleForApplicationAutoScaling_ECSService.

Automaatne tööde skaleerimise poliitika — skaleerimise reeglid. On 2 tüüpi:

Sihtimise jälgimine — sihtmärkide mõõdikute jälgimine (CPU/RAM-i kasutamine või päringute arv tööde kohta). Näiteks, kui soovime, et protsessori keskmine koormus oleks 85%, siis kui see tõuseb, lisatakse uusi töid seni, kuni see jõuab sihttaseme juurde. Kui koormus on madalam, siis tööd eemaldatakse, välja arvatud juhul, kui on lubatud skaleerimise allapoole kaitse (Keela skaleerimine).
Samm-sammuline skaleerimine — reageerimine igasugusele sündmusele. Siit saab seadistada reaktsiooni mis tahes sündmusele (CloudWatch Alarm), kui see aset leiab, saab lisada või eemaldada määratud arvu töid või määrata täpselt vajalike tööde arvu.

Teenusel võivad olla mitu skaleerimise reeglit, see võib olla kasulik, peamine on jälgida, et need üksteisega ei konfliktiks.

Kokkuvõte

Kui järgite juhiseid ja kasutate sama Docker'i pilti, peaks teie teenus tagastama sellise lehe.

Oleme loonud šablooni, mille alusel käivitatakse kõik teenuse masinad. Oleme ka õppinud masinaid uuendama, kui šabloon muutub.
Olemegi seadnud üles spot-instantse peatamissignaali töötlemise, seega ühe minuti jooksul pärast selle saamist eemaldatakse kõik töötavad tööd masinast, nii et midagi ei kao ega katkeda.
Oleme seadnud üles koormuse tasakaalustaja, et jaotada koormus masinate vahel ühtlaselt.
Oleme loonud teenuse, mis töötab spot-instantidel, mille tõttu vähenevad masina kulud umbes 3 korda.
Oleme seadnud üles automaatse skaleerimise kahes suunas, et töödelda koormuste suurenemist, kuid samas mitte maksta seismise eest.
Kasutame Capacity Provideri, et rakendus hallaks infrastruktuuri (masinad), mitte vastupidi.
Me oleme toredad.

Kui teil on ettearvatavad koormuspiigid, näiteks reklaamite suurt e-kirjade jagamist, saate seadistada skaleerimise vastavalt ajakavale.

Samuti on võimalik teha skaleerimist, tuginedes erinevate osade andmetele teie süsteemis. Näiteks on meil funktsionaalsus iseseisvate reklaampakkumiste saatmiseks mobiilirakenduse kasutajatele. Mõnikord saadetakse kampaania rohkem kui 1M inimesele. Pärast sellist saadet on alati märgata suurt kasvu API-päringutes, kuna paljud kasutajad logivad rakendusse samal ajal sisse. Nii et kui me näeme, et reklaampushide saatmiseks on järjekorras oluliselt rohkem, kui tavaliselt, saame koheselt käivitada mitu täiendavat masinat ja ülesannet, et valmis olla koormuseks.

Oleks tore, kui jagaksite kommentaarides huvitavaid näiteid spottinstantside ja ECS kasutamisest või midagi skaleerimise kohta.

Varsti tulevad artiklid selle kohta, kuidas me tõhusalt töötleme tuhandeid analüütilisi sündmusi sekundis peamiselt serverless arhitektuuril (rahaga) ja kuidas teenuste juurutamine toimub GitLab CI ja Terraform Cloud abil.

Liituge meiega, see on huvitav!

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.