Tere kõigile! Minu nimi on Kirill, ma olen Adapty tehnoloogiadirektor. Suurem osa meie arhitektuurist on AWS-is ja täna räägin sellest, kuidas vähendasime serverikulusid 3 korda, kasutades tootmiskeskkonnas kohapealseid eksemplare, ja kuidas seadistada nende automaatne skaleerimine. Kõigepealt antakse ülevaade selle toimimisest ja seejärel üksikasjalikud juhised alustamiseks.
Mis on kohtjuhtumid?
eksemplarid on teiste hetkel jõude seisvate AWS-i kasutajate serverid ja nad müüvad neid suure allahindlusega (Amazon kirjutab kuni 90%, meie kogemuse järgi ~3x, varieerub sõltuvalt piirkonnast, AZ-ist ja eksemplari tüübist). Nende peamine erinevus tavalistest on see, et neid saab igal ajal välja lülitada. Seetõttu arvasime pikka aega, et on normaalne kasutada neid esmastes keskkondades või millegi arvutamise ülesannete jaoks, mille vahetulemused on salvestatud S3-le või andmebaasi, kuid mitte müügiks. On olemas ka kolmandate osapoolte lahendusi, mis võimaldavad tootmisel spotte kasutada, kuid meie puhul on palju karkusid, mistõttu me neid ei rakendanud. Artiklis kirjeldatud lähenemine töötab täielikult standardse AWS-i funktsionaalsuse piires, ilma täiendavate skriptide, kroonide jmsta.
Allpool on mõned ekraanipildid, mis näitavad kohapealsete juhtumite hinnaajalugu.
m5.suur eu-west-1 (Iirimaa) piirkonnas. Hind on olnud enamjaolt stabiilne 3 kuud, hetkel säästetakse 2.9x.
m5.suur USA-ida-1 piirkonnas (N. Virginia). Hind muutub 3 kuu jooksul pidevalt, hetkel säästes olenevalt saadavuse tsoonist 2.3x kuni 2.8x.
t3.väike us-ida-1 piirkonnas (N. Virginia). Hind on püsinud stabiilne 3 kuud, hetkel sääst 3.4x.
Teenuse arhitektuur
Teenuse põhiarhitektuur, millest me selles artiklis räägime, on näidatud alloleval diagrammil.
Rakendus Load Balancer → EC2 Sihtrühm → Elastic Container Service
Tasakaalustajana kasutatakse rakenduste koormuse tasakaalustajat (ALB), mis saadab päringud EC2 sihtrühmale (TG). TG vastutab ALB-de eksemplaride portide avamise ja nende ühendamise eest elastsete konteinerite teenuse (ECS) konteinerite portidega. ECS on Kubernetese analoog AWS-is, mis haldab Dockeri konteinereid.
Ühel eksemplaril võib olla mitu samade pordidega töötavat konteinerit, seega ei saa me neid kindlalt seadistada. ECS teatab TG-le, et käivitab uue ülesande (Kubernetese terminoloogias nimetatakse seda pod), see kontrollib eksemplari vabade pordide olemasolu ja määrab ühe neist käivitatud ülesandele. Samuti kontrollib TG regulaarselt tervisekontrolli abil, kas eksemplar ja API töötavad selle kallal, ning kui ta näeb mingeid probleeme, siis lõpetab sinna päringute saatmise.
EC2 automaatse skaleerimise rühmad + ECS võimsuse pakkujad
Ülaltoodud diagramm ei näita teenust EC2 Auto Scaling Groups (ASG). Nime järgi saate aru, et see vastutab eksemplaride skaleerimise eest. Kuid kuni viimase ajani ei olnud AWS-il sisseehitatud võimalust hallata ECS-ist töötavate masinate arvu. ECS võimaldas ülesannete arvu skaleerida, näiteks protsessori kasutuse, RAM-i või päringute arvu järgi. Kuid kui ülesanded hõivasid kõik vabad eksemplarid, siis uusi masinaid automaatselt ei loodud.
See on muutunud ECS võimsuse pakkujate (ECS CP) tulekuga. Nüüd saab iga ECS-i teenuse seostada ASG-ga ja kui ülesanded ei mahu töötavatele eksemplaridele, tõstetakse uued (kuid kehtestatud ASG piirides). See toimib ka vastupidises suunas, kui ECS CP näeb jõudeolekus eksemplare ilma ülesanneteta, siis annab ASG käsu need sulgeda. ECS CP-l on võimalus määrata eksemplari koormuse sihtprotsent, nii et teatud arv masinaid on ülesannete kiireks skaleerimiseks alati vabad; sellest räägin veidi hiljem.
EC2 käivitusmallid
Viimane teenus, millest räägin enne selle infrastruktuuri loomise üksikasjalikku käsitlemist, on EC2 käivitusmallid. See võimaldab teil luua malli, mille järgi kõik masinad käivituvad, et mitte korrata seda iga kord nullist. Siin saate valida käivitatava masina tüübi, turvarühma, kettapildi ja palju muid parameetreid. Samuti saate määrata kasutajaandmed, mis laaditakse üles kõikidesse käivitatud eksemplaridesse. Saate käivitada skripte kasutajaandmetes, näiteks saate redigeerida faili sisu .
Selle artikli üks olulisemaid konfiguratsiooniparameetreid on = tõsi. Kui see parameeter on lubatud, siis niipea, kui ECS saab signaali, et kohapealne eksemplar võetakse ära, edastab see kõik sellega töötavad toimingud olekusse Tühjendamine. Sellele eksemplarile uusi ülesandeid ei määrata; kui on ülesandeid, mida soovitakse sellele praegu avaldada, siis need tühistatakse. Samuti lakkavad tulemast nõudmised tasakaaluliikurilt. Teade eksemplari kustutamise kohta tuleb 2 minutit enne tegelikku sündmust. Seega, kui teie teenus ei täida ülesandeid kauem kui 2 minutit ega salvesta midagi kettale, saate kasutada kohapealseid eksemplare ilma andmeid kaotamata.
Seoses kettaga - AWS hiljuti ECS-iga on võimalik kasutada elastset failisüsteemi (EFS), selle skeemi puhul pole isegi ketas takistuseks, kuid me ei proovinud seda, kuna põhimõtteliselt pole oleku salvestamiseks ketast vaja. Vaikimisi peatatakse pärast SIGINT-i (saadetakse, kui ülesanne teisaldatakse olekusse Tühjendamine) saamist kõik töötavad toimingud 30 sekundi pärast, isegi kui need pole veel lõpule viidud; seda aega saate muuta parameetriga . Peaasi, et punktmasinate jaoks ei tohi seda rohkem kui 2 minutiks seada.
Teenuse loomine
Liigume edasi kirjeldatud teenuse loomise juurde. Selle käigus kirjeldan lisaks mitmeid kasulikke punkte, mida eespool ei mainitud. Üldiselt on see samm-sammult juhis, kuid ma ei käsitle mõnda väga elementaarset või vastupidi väga spetsiifilist juhtumit. Kõik toimingud tehakse AWS-i visuaalses konsoolis, kuid neid saab programmiliselt reprodutseerida CloudFormationi või Terraformi abil. Adaptys kasutame Terraformi.
EC2 käivitusmall
See teenus loob kasutatavate masinate konfiguratsiooni. Malle hallatakse jaotises EC2 -> Eksemplarid -> Käivitage mallid.
Amazoni masina pilt (AMI) — määrake ketta kujutis, millega kõik eksemplarid käivitatakse. ECS-i puhul tasub enamikul juhtudel kasutada Amazoni optimeeritud pilti. Seda uuendatakse regulaarselt ja see sisaldab kõike, mis on ECS-i tööks vajalik. Praeguse pildi ID väljaselgitamiseks minge lehele , valige kasutatav piirkond ja kopeerige selle jaoks AMI ID. Näiteks us-ida-1 piirkonna jaoks on kirjutamise hetkel kehtiv ID ami-00c7c1cf5bdc913ed. See ID tuleb sisestada üksusse Määra kohandatud väärtus.
Eksemplari tüüp — märkige eksemplari tüüp. Valige see, mis teie ülesandele kõige paremini sobib.
Võtmepaar (sisselogimine) — määrake sertifikaat, millega saate vajadusel SSH kaudu eksemplari ühenduse luua.
Võrgu seaded — määrata võrguparameetrid. Võrgustikuplatvorm enamikul juhtudel peaks olema virtuaalne privaatpilv (VPC). Turvarühmad — teie eksemplaride turvarühmad. Kuna instantside ees hakkame kasutama tasakaalustajat, siis soovitan siin määrata grupi, mis lubab sissetulevaid ühendusi ainult tasakaalustajast. See tähendab, et teil on 2 turvagruppi, üks tasakaalustaja jaoks, mis võimaldab sissetulevaid ühendusi kõikjalt pordidest 80 (http) ja 443 (https) ja teine masinate jaoks, mis võimaldab sissetulevaid ühendusi tasakaalustaja rühma mis tahes pordiga. . Mõlema rühma väljaminevad ühendused tuleb avada TCP-protokolli abil kõikidele portidele kõikidele aadressidele. Väljaminevate ühenduste porte ja aadresse saab piirata, kuid siis tuleb pidevalt jälgida, et sa ei üritaks suletud pordis millelegi ligi pääseda.
Salvestusruum (mahud) — määrata masinate kettaparameetrid. Ketta suurus ei tohi olla väiksem kui AMI-s määratud; ECS Optimizedi puhul on see 30 GiB.
Täpsemad üksikasjad — täpsustada täiendavad parameetrid.
Ostuvõimalus — kas tahame osta kohapealseid eksemplare. Me tahame, kuid me ei märgi seda kasti siin; me konfigureerime selle automaatse skaleerimise rühmas, seal on rohkem võimalusi.
IAM-i eksemplari profiil — märkige roll, millega eksemplarid käivitatakse. Eksemplaride töötamiseks ECS-is vajavad nad õigusi, mis tavaliselt leidub rollis ecsInstanceRole. Mõnel juhul saab selle luua, kui mitte, siis siin kuidas seda teha. Pärast loomist märgime selle mallis.
Järgmisena on palju parameetreid, põhimõtteliselt saate vaikeväärtused jätta kõikjale, kuid igal neist on selge kirjeldus. Luban alati EBS-i optimeeritud eksemplari ja valikud T2/T3 Unlimited, kui neid kasutatakse juhtumid.
Kasutaja aeg — näidata kasutajaandmeid. Muudame faili /etc/ecs/ecs.config, mis sisaldab ECS-agendi konfiguratsiooni.
Näide kasutajaandmetest:
#!/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 — parameeter näitab, et eksemplar kuulub antud nimega klastrisse, see tähendab, et see klaster saab paigutada oma ülesanded sellesse serverisse. Me ei ole veel klastrit loonud, kuid kasutame selle loomisel seda nime.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameeter määrab, et kui võetakse vastu signaal punkteksemplari väljalülitamiseks, tuleks kõik sellel olevad ülesanded üle kanda olekusse Tühjendamine.
ECS_CONTAINER_STOP_TIMEOUT=1m - parameeter määrab, et pärast SIGINT-signaali saamist on kõigil ülesannetel aega 1 minut enne tapmist.
ECS_ENGINE_AUTH_TYPE=docker — parameeter näitab, et autoriseerimismehhanismina kasutatakse Dockeri skeemi
ECS_ENGINE_AUTH_DATA=... — ühenduse parameetrid privaatkonteineri registriga, kuhu teie Dockeri kujutised salvestatakse. Kui see on avalik, siis ei pea te midagi täpsustama.
Selle artikli jaoks kasutan Docker Hubi avalikku pilti, seega täpsustage parameetrid ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA pole vaja.
Hea teada: AMI-d on soovitatav regulaarselt värskendada, kuna uued versioonid värskendavad Dockeri, Linuxi, ECS agendi jne versioone. Et seda mitte unustada, saate uute versioonide avaldamise kohta. Saate saada teatisi meili teel ja värskendada käsitsi või kirjutada Lambda funktsiooni, mis loob automaatselt käivitamismalli uue versiooni koos värskendatud AMI-ga.
EC2 automaatse skaleerimise rühm
Auto Scaling Group vastutab eksemplaride käivitamise ja skaleerimise eest. Gruppe hallatakse jaotises EC2 -> Auto Scaling -> Auto Scaling Groups.
Käivitage mall — valige eelmises etapis loodud mall. Jätame vaikeversiooni.
Ostuvalikud ja eksemplaritüübid — määrake klastri eksemplaride tüübid. Käivitusmalli järgimine kasutab käivitamismalli eksemplari tüüpi. Ostuvalikute ja eksemplaritüüpide kombineerimine võimaldab teil eksemplaritüüpe paindlikult konfigureerida. Me kasutame seda.
Valikuline on-demand baas — alati toimivate tavapäraste mitte-kohalike eksemplaride arv.
Nõudmise protsent üle baasi — tava- ja kohanäidiste protsentuaalne suhe, 50-50 jagatakse võrdselt, 20-80 iga tavaeksemplari kohta tõstetakse 4 spoti. Selle näite jaoks toon välja 50-50, kuid tegelikkuses teeme enamasti 20-80, mõnel juhul 0-100.
Eksemplaride tüübid — siin saate määrata täiendavaid eksemplaride tüüpe, mida klastris kasutatakse. Me ei kasutanud seda kunagi, sest ma ei saa loo tähendusest tegelikult aru. Võib-olla on see tingitud teatud tüüpi eksemplaride piirangutest, kuid neid saab tugi abil hõlpsasti suurendada. Kui teate rakendust, loen seda hea meelega kommentaarides)
võrk — võrguseaded, valige VPC ja masinate alamvõrgud, enamikul juhtudel peaksite valima kõik saadaolevad alamvõrgud.
Koormuse tasakaalustamine - tasakaalustaja seaded, kuid me teeme seda eraldi, me ei puuduta siin midagi. Tervisekontrollid konfigureeritakse ka hiljem.
Grupi suurus — anname stardis ära masinate arvu piirangud klastris ja soovitud masinate arvu. Masinate arv klastris ei ole kunagi väiksem kui määratud miinimum ja suurem kui maksimaalne, isegi kui skaleerimine peaks toimuma vastavalt mõõdikutele.
Skaleerimise poliitikad — skaleerimise parameetrid, kuid skaleerime töötavate ECS-ülesannete alusel, nii et skaleerimise konfigureerime hiljem.
Eksemplari mastaabikaitse — eksemplaride kaitse kustutamise eest skaleerimisel. Lubame selle, et ASG ei kustutaks masinat, millel on tööülesanded. ECS Capacity Provider keelab kaitse selliste juhtumite puhul, millel pole ülesandeid.
Lisa märksõnu — saate määrata eksemplaridele silte (selleks tuleb märkida ruut Märgista uued eksemplarid). Soovitan määrata nimesildi, siis on kõik grupis käivitatavad eksemplarid sama nimega ja neid on mugav konsoolis vaadata.
Pärast grupi loomist avage see ja minge jaotisse Täpsemad seadistused Miks ei ole kõik valikud konsoolis loomise etapis nähtavad.
Lõpetamiseeskirjad — reeglid, mida eksemplaride kustutamisel arvesse võetakse. Neid rakendatakse järjekorras. Tavaliselt kasutame alloleval pildil olevaid. Esiteks kustutatakse vanima käivitusmalliga eksemplarid (näiteks kui värskendasime AMI-d, lõime uue versiooni, kuid kõigil eksemplaridel õnnestus sellele lülituda). Seejärel valitakse eksemplarid, mis on järgmisele arveldustunnile kõige lähemal. Ja siis valitakse välja vanimad väljalaskekuupäeva järgi.
Hea teada: kõigi klastri masinate värskendamiseks, mugav kasutada . Kui ühendate selle eelmise etapi Lambda funktsiooniga, saate täielikult automatiseeritud eksemplari värskendamise süsteemi. Enne kõigi masinate värskendamist peate keelama eksemplari skaleerimiskaitse kõigi rühma eksemplaride jaoks. Mitte konfiguratsioon rühmas, vaid kaitse masinate endi eest, seda tehakse vahekaardil Eksemplaride haldus.
Rakenduse koormuse tasakaalustaja ja EC2 sihtrühm
Tasakaalustaja luuakse jaotises EC2 → Load Balancing → Load Balancers. Kasutame Application Load Balancerit, erinevat tüüpi tasakaalustajate võrdlust saab lugeda aadressilt .
Kuulajad - hiljem on mõttekas teha pordid 80 ja 443 ning suunata 80-lt 443-le, kasutades tasakaalustaja reegleid.
Kättesaadavuse tsoonid — enamikul juhtudel valime juurdepääsetavuse tsoonid kõigile.
Konfigureerige turvaseaded — siin on märgitud tasakaalustaja SSL-sertifikaat, mugavaim variant on ACM-is. Erinevuste kohta Julgeolekupoliitika saab sisse lugeda , võite selle vaikimisi valida ELBSecurityPolicy-2016-08. Pärast tasakaalustaja loomist näete seda DNS-i nimi, mida peate oma domeeni jaoks CNAME-i konfigureerima. Näiteks näeb see Cloudflare'is välja selline.
Julgeolekukomitee — looge või valige tasakaalustaja turvagrupp, sellest kirjutasin lähemalt just eespool jaotises EC2 Launch Template → Network settings.
Sihtgrupp — loome grupi, mis vastutab taotluste suunamise eest tasakaalustajast masinatesse ja nende saadavuse kontrollimise eest, et need probleemide korral välja vahetada. Sihtmärgi tüüp peab olema näide, Protokoll и port mis tahes, kui kasutate tasakaalustaja ja eksemplaride vaheliseks suhtluseks HTTPS-i, peate neile üles laadima sertifikaadi. Selle näite puhul me seda ei tee, me lihtsalt lahkume pordist 80.
Tervisekontrollid — teenuse funktsionaalsuse kontrollimise parameetrid. Reaalses teenuses peaks see olema eraldi päring, mis rakendab äriloogika olulisi osi, selle näite jaoks jätan vaikeseaded. Järgmisena saate valida päringu intervalli, ajalõpu, edukoodid jne. Meie näites näitame edukoodid 200–399, kuna kasutatav Dockeri pilt tagastab koodi 304.
Registreeri sihtmärgid — siin valitakse grupi autod, kuid meie puhul teeb seda ECS, seega jätame selle sammu lihtsalt vahele.
Hea teada: Tasakaalustaja tasemel saate lubada logid, mis salvestatakse teatud S3-sse . Sealt saab neid analüütika jaoks eksportida kolmandate osapoolte teenustesse või teha SQL-päringuid otse S3 andmetele, kasutades . See on mugav ja töötab ilma lisakoodita. Samuti soovitan seadistada logide eemaldamise S3 ämbrist teatud aja möödudes.
ECS-i ülesande definitsioon
Eelmistes etappides lõime kõik teenuse infrastruktuuriga seonduva, nüüd liigume edasi käivitatavate konteinerite kirjeldamise juurde. Seda tehakse jaotises ECS → Task Definitions.
Käivitustüübi ühilduvus - valige EC2.
Ülesande täitmise IAM-i roll - vali ecsTaskExecutionRole. Seda kasutades kirjutatakse logisid, antakse juurdepääs salajastele muutujatele jne.
Jaotises Konteineri definitsioonid klõpsake nuppu Lisa konteiner.
pilt — link projekti koodiga pildile; selle näite puhul kasutan Docker Hubi avalikku pilti .
Mälu piirangud — konteineri mälupiirangud. Kõva piirang — kõva limiit, kui konteiner ületab määratud väärtuse, käivitatakse dokkeri tapmiskäsk, konteiner sureb kohe. Pehme limiit — pehme piir, mahuti võib ületada määratud väärtust, kuid seda parameetrit võetakse masinatele ülesannete paigutamisel arvesse. Näiteks kui masinal on 4 GiB RAM-i ja konteineri pehme limiit on 2048 MiB, siis sellel masinal saab selle konteineriga töötada maksimaalselt 2 toimingut. Tegelikkuses on 4 GiB muutmälu veidi vähem kui 4096 MiB, seda saab vaadata klastri vahekaardilt ECS Instances. Pehme limiit ei saa olla suurem kui kõva limiit. Oluline on mõista, et kui ühes ülesandes on mitu konteinerit, siis nende piirid summeeritakse.
Portide kaardistamine - sisse Hosti port Tähistame 0, see tähendab, et port määratakse dünaamiliselt ja seda jälgib sihtrühm. Konteinerport — port, millel teie rakendus töötab, on sageli määratud täitmiskäskluses või määratud teie rakenduse koodis, Dockerfile'is jne. Meie näites kasutame 3000, kuna see on loetletud kasutatav pilt.
Tervise kontroll — konteineri tervisekontrolli parameetrid, mida ei tohi segi ajada sihtrühmas konfigureeritud parameetritega.
keskkond — keskkonna seaded. CPU ühikud - sarnane mälupiirangutele, ainult protsessori kohta. Iga protsessori tuum on 1024 ühikut, nii et kui serveris on kahetuumaline protsessor ja konteiner on seatud 512-le, saab selle konteineriga ühes serveris käivitada 4 ülesannet. Protsessori ühikud vastavad alati tuumade arvule, neid ei saa olla natuke vähem, nagu mälu puhul.
käsk — käsk teenuse käivitamiseks konteineris, kõik parameetrid on eraldatud komadega. See võib olla gunicorn, npm jne. Kui pole määratud, kasutatakse Dockerfile'i CMD-direktiivi väärtust. Me näitame npm,start.
Keskkonnamuutujad — konteineri keskkonnamuutujad. Need võivad olla kas lihtsad tekstiandmed või salajased muutujad või .
Ladustamine ja logimine - siin seadistame logimise CloudWatchi logides (AWS-i logide teenus). Selleks lubage lihtsalt ruut CloudWatchi logide automaatne konfigureerimine. Pärast ülesande definitsiooni loomist luuakse CloudWatchis automaatselt logide rühm. Vaikimisi salvestatakse logisid selles lõputult, soovitan muuta Säilitusperioodi väärtusest Mitte kunagi aeguda nõutud perioodiks. Seda tehakse CloudWatchi logi rühmades, peate klõpsama praegusel perioodil ja valima uue.
ECS-klaster ja ECS-võimsuse pakkuja
Klastri loomiseks minge jaotisse ECS → Klastrid. Valime malliks EC2 Linux + Networking.
Klastri nimi - väga oluline, teeme siin sama nime, mis on määratud parameetris Launch Template ECS_CLUSTER, meie puhul - DemoApiClusterProd. Märkige ruut Loo tühi klaster. Soovi korral saate lubada Container Insightsi, et vaadata CloudWatchis teenuste mõõdikuid. Kui tegite kõik õigesti, näete jaotises ECS-i eksemplarid masinaid, mis loodi grupis Automaatne skaleerimine.
Minge vahekaardile Võimsuse pakkujad ja looge uus. Lubage mul teile meelde tuletada, et see on vajalik masinate loomise ja seiskamise juhtimiseks sõltuvalt töötavate ECS-ülesannete arvust. Oluline on märkida, et teenusepakkuja saab määrata ainult ühte rühma.
Automaatse skaleerimise rühm — valige varem loodud rühm.
Hallatud skaleerimine — lubage see, et teenusepakkuja saaks teenust skaleerida.
Sihtvõimsus % — mitu protsenti ülesannetega koormatud masinaid vajame. Kui määrate 100%, on kõik masinad alati tööülesannetega hõivatud. Kui määrata 50%, siis pooled autod on alati tasuta. Sel juhul jõuavad järsu koormuse hüppe korral uued taksod kohe vabade autode juurde, ilma et peaks ootama instantside kasutuselevõttu.
Hallatud lõpetamiskaitse — luba – see parameeter võimaldab pakkujal eemaldada eksemplaride kaitse kustutamise eest. See juhtub siis, kui masinal pole aktiivseid ülesandeid ja see võimaldab sihtvõimsust%.
ECS-teenuse ja skaleerimise seadistamine
Viimane samm :) Teenuse loomiseks tuleb Teenused vahekaardil minna eelnevalt loodud klastrisse.
Käivitamise tüüp — peate klõpsama nuppu Lülita võimsuse pakkuja strateegiale ja valima eelnevalt loodud pakkujad.
Ülesande definitsioon — valige eelnevalt loodud ülesande definitsioon ja selle redaktsioon.
Teenuse nimi — segaduse vältimiseks märgime alati sama, mis ülesande definitsioon.
Teenuse liik - alati koopia.
Ülesannete arv — soovitud aktiivsete ülesannete arv teenuses. Seda parameetrit juhitakse skaleerimisega, kuid see tuleb siiski täpsustada.
Minimaalne terve protsent и Maksimaalne protsent — määrata kindlaks ülesannete käitumine juurutamise ajal. Vaikeväärtused on 100 ja 200, mis näitab, et juurutamise ajal suureneb ülesannete arv mitu korda ja naaseb seejärel soovitud väärtusele. Kui sul on 1 ülesanne töös, min=0 ja max=100, siis juurutamise käigus see tapetakse ja peale seda tõstetakse uus ehk siis seisak. Kui töötab 1 ülesanne, min=50, max=150, siis juurutamist ei toimu üldse, sest 1 ülesannet ei saa pooleks jagada ega poolteist korda suurendada.
Juurutamise tüüp - lahkuge jooksvast värskendusest.
Paigutuse mallid — masinatele ülesannete paigutamise reeglid. Vaikimisi on AZ Balanced Spread – see tähendab, et iga uus ülesanne paigutatakse uuele eksemplarile, kuni kõikides saadavustsoonides olevad masinad tõusevad. Tavaliselt teeme BinPack - CPU ja Spread - AZ; selle poliitikaga paigutatakse ülesanded võimalikult tihedalt ühte masinasse protsessori kohta. Kui on vaja luua uus masin, luuakse see uude saadavustsooni.
Koormuse tasakaalustaja tüüp — valige Rakenduse koormuse tasakaalustaja.
Service IAM roll - vali ecsServiceRole.
Koormuse tasakaalustaja nimi — valige eelnevalt loodud tasakaalustaja.
Tervisekontrolli ajapikendusperiood — paus enne tervisekontrolli tegemist pärast uue ülesande käivitamist, tavaliselt määrame selleks 60 sekundit.
Konteiner laadimise tasakaalule — valige punktis Sihtrühma nimi varem loodud grupp ja kõik täidetakse automaatselt.
Teenuse automaatne skaleerimine — teenuse skaleerimise parameetrid. Valige teenuse automaatse skaleerimise seadistamine, et kohandada oma teenuse soovitud arvu. Skaleerimisel määrame ülesannete minimaalse ja maksimaalse arvu.
IAM-i roll teenuse automaatse skaleerimise jaoks - vali AWSServiceRoleForApplicationAutoScaling_ECSService.
Automaatsed ülesannete skaleerimise poliitikad — skaleerimise reeglid. Neid on 2 tüüpi:
- Sihtmärgi jälgimine — sihtmõõdikute jälgimine (CPU/RAM-i kasutus või taotluste arv iga ülesande jaoks). Näiteks tahame, et protsessori keskmine koormus oleks 85%, kui see tõuseb, lisatakse uusi ülesandeid, kuni see saavutab sihtväärtuse. Kui koormus on väiksem, siis ülesanded eemaldatakse, vastupidi, välja arvatud juhul, kui kaitse vähendamise eest on lubatud (Keela skaleerimine).
- Astmeline skaleerimine - reaktsioon suvalisele sündmusele. Siin saate konfigureerida reaktsiooni mis tahes sündmusele (CloudWatch Alarm), selle ilmnemisel saate lisada või eemaldada määratud arvu ülesandeid või määrata täpse arvu ülesandeid.
Teenusel võib olla mitu skaleerimisreeglit, see võib olla kasulik, peaasi, et need ei läheks üksteisega vastuollu.
Järeldus
Kui järgisite juhiseid ja kasutasite sama Dockeri pilti, peaks teie teenus tagastama sellise lehe.
- Oleme loonud malli, mille järgi käivitatakse kõik teenuses olevad masinad. Õppisime ka masinate värskendamist, kui malli muutub.
- Oleme konfigureerinud kohapealse eksemplari seiskamissignaali töötlemise, nii et minuti jooksul pärast selle saamist eemaldatakse masinast kõik töötavad toimingud, nii et midagi ei lähe kaduma ega katkema.
- Tõstsime tasakaalustaja üles, et jaotada koormus ühtlaselt masinate vahel.
- Oleme loonud kohapealsetel eksemplaridel töötava teenuse, mis vähendab masinakulusid umbes 3 korda.
- Oleme konfigureerinud automaatse skaleerimise mõlemas suunas, et tulla toime suurenenud töökoormusega ilma seisakukulusid kandmata.
- Capacity Providerit kasutame selleks, et rakendus haldaks infrastruktuuri (masinaid) ja mitte vastupidi.
- Oleme suurepärased.
Kui teil on prognoositavaid koormuse hüppeid, näiteks reklaamite suures meilikampaanias, saate skaleerimise seadistada .
Saate skaleerida ka oma süsteemi eri osade andmete põhjal. Näiteks on meil funktsionaalsus mobiilirakenduse kasutajad. Mõnikord saadetakse kampaania rohkem kui miljonile inimesele. Pärast sellist levitamist suureneb API-le suunatud päringute arv alati märkimisväärselt, kuna paljud kasutajad logivad rakendusse korraga sisse. Seega kui näeme, et reklaam-tõuketeadete saatmise järjekorras on oluliselt rohkem standardnäitajaid, saame kohe käivitada mitmeid lisamasinaid ja ülesandeid, et olla laadimiseks valmis.
Mul on hea meel, kui räägite mulle kommentaarides huvitavaid juhtumeid kohapealsete eksemplaride ja ECS-i kasutamise kohta või midagi skaleerimise kohta.
Peagi ilmuvad artiklid selle kohta, kuidas me töötleme valdavalt serverita pinus (rahaga) tuhandeid analüütilisi sündmusi sekundis ning kuidas toimib teenuste juurutamine GitLab CI ja Terraform Cloudi abil.
Liituge meiega, see saab olema huvitav!
Küsitluses saavad osaleda ainult registreerunud kasutajad. palun.
Kas kasutate tootmises kohapealseid eksemplare?
-
22,2%jah 6
-
66,7%Ei 18
-
11,1%Õppisin nende kohta artiklist ja kavatsen neid kasutada3
27 kasutajat hääletas. 5 kasutajat jäi erapooletuks.
Allikas: www.habr.com