Hæ allir! Ég heiti Kirill, ég er tæknistjóri hjá Adapty. Stærstur hluti arkitektúrsins okkar er á AWS og í dag mun ég tala um hvernig við lækkuðum kostnað netþjóna um 3 sinnum með því að nota blettatilvik í framleiðsluumhverfi, sem og hvernig á að setja upp sjálfvirka mælingu þeirra. Fyrst verður yfirlit yfir hvernig það virkar og síðan nákvæmar leiðbeiningar til að hefjast handa.
Hvað eru Spot-tilvik?
tilvik eru netþjónar annarra AWS notenda sem eru aðgerðalausir um þessar mundir og þeir selja þá með miklum afslætti (Amazon skrifar allt að 90%, samkvæmt reynslu okkar ~3x, er mismunandi eftir svæði, AZ og gerð tilviks). Helsti munurinn á þeim frá venjulegum er að þeir geta slökkt á þeim hvenær sem er. Þess vegna töldum við lengi vel að það væri eðlilegt að nota þá fyrir ónýtt umhverfi, eða fyrir verkefni við að reikna eitthvað, með milliniðurstöður vistaðar á S3 eða í gagnagrunninum, en ekki fyrir sölu. Það eru til þriðju aðila lausnir sem gera þér kleift að nota bletti í framleiðslu, en það eru margar hækjur fyrir okkar mál, svo við útfærðum þær ekki. Aðferðin sem lýst er í greininni virkar algjörlega innan venjulegs AWS virkni, án viðbótar forskrifta, krónur o.s.frv.
Hér að neðan eru nokkrar skjámyndir sem sýna verðsögu fyrir bletttilvik.
m5.stór á eu-west-1 (Írlandi) svæðinu. Verð hefur verið að mestu stöðugt í 3 mánuði, sem stendur sparað 2.9x.
m5.stór á us-east-1 svæðinu (N. Virginia). Verðið er stöðugt að breytast á 3 mánuðum og sparar nú frá 2.3x í 2.8x eftir framboðssvæði.
t3.small í us-east-1 svæðinu (N. Virginia). Verð hefur verið stöðugt í 3 mánuði og sparar nú 3.4x.
Þjónustuarkitektúr
Grunnarkitektúr þjónustunnar sem við munum tala um í þessari grein er sýnd á skýringarmyndinni hér að neðan.
Forritsálagsjafnari → EC2 markhópur → Teygjanleg gámaþjónusta
Application Load Balancer (ALB) er notaður sem jafnvægistæki, sem sendir beiðnir til EC2 Target Group (TG). TG ber ábyrgð á að opna hafnir á tilvikum fyrir ALB og tengja þær við hafnir Elastic Container Service (ECS) gáma. ECS er hliðstæða Kubernetes í AWS, sem heldur utan um Docker gáma.
Eitt tilvik getur haft nokkra hlaupandi gáma með sömu höfnum, svo við getum ekki stillt þá fast. ECS segir TG að það sé að setja af stað nýtt verkefni (í Kubernetes hugtökum er þetta kallað pod), það athugar hvort lausar hafnir séu á tilvikinu og úthlutar einni þeirra á hleypt af stokkunum. TG athugar líka reglulega hvort tilvikið og API séu að vinna í því með því að nota heilsuskoðun og ef það sér einhver vandamál hættir það að senda beiðnir þangað.
EC2 Auto Scaling Groups + ECS Capacity Providers
Skýringarmyndin hér að ofan sýnir ekki EC2 Auto Scaling Groups (ASG) þjónustuna. Af nafninu geturðu skilið að það er ábyrgt fyrir að skala tilvik. Hins vegar, þar til nýlega, hafði AWS ekki innbyggða getu til að stjórna fjölda hlaupandi véla frá ECS. ECS gerði það mögulegt að skala fjölda verkefna, til dæmis eftir örgjörvanotkun, vinnsluminni eða fjölda beiðna. En ef verkefni tóku öll ókeypis tilvik, þá voru nýjar vélar ekki sjálfkrafa búnar til.
Þetta hefur breyst með tilkomu ECS Capacity Providers (ECS CP). Nú er hægt að tengja hverja þjónustu í ECS við ASG, og ef verkefnin passa ekki á hlaupandi tilvik, þá verða nýir settir upp (en innan settra ASG marka). Þetta virkar líka í gagnstæða átt, ef ECS CP sér aðgerðalaus tilvik án verkefna, þá mun það gefa ASG skipunina um að loka þeim. ECS CP hefur getu til að tilgreina markprósentu af tilvikshleðslu, þannig að ákveðinn fjöldi véla er alltaf laus til að stækka verkefni hratt; ég mun tala um þetta aðeins síðar.
EC2 ræsingarsniðmát
Síðasta þjónustan sem ég mun tala um áður en ég fer í smáatriði um að búa til þennan innviði er EC2 Launch Templates. Það gerir þér kleift að búa til sniðmát eftir því sem allar vélar fara í gang, til að endurtaka þetta ekki frá grunni í hvert skipti. Hér getur þú valið tegund vélar sem á að ræsa, öryggishóp, diskamynd og margar aðrar breytur. Þú getur líka tilgreint notendagögn sem verða hlaðið upp í öll opnuð tilvik. Þú getur keyrt forskriftir í notendagögnum, til dæmis geturðu breytt innihaldi skráar .
Ein mikilvægasta stillingarbreytan fyrir þessa grein er = satt. Ef þessi færibreyta er virkjuð, þá um leið og ECS fær merki um að verið sé að taka bletttilvik í burtu, flytur það öll verkefni sem vinna á því yfir á Tæmandi stöðu. Engum nýjum verkefnum verður úthlutað til þessa tilviks; ef það eru verkefni sem vilja fara út í það núna, verður þeim hætt. Beiðnir frá jafnvægisstjóra hætta líka að berast. Tilkynning um eyðingu tilviks kemur 2 mínútum fyrir raunverulegan atburð. Þess vegna, ef þjónustan þín framkvæmir ekki verkefni lengur en 2 mínútur og vistar ekki neitt á disknum, þá geturðu notað blettatilvik án þess að tapa gögnum.
Varðandi disk - AWS nýlega Það er hægt að nota Elastic File System (EFS) ásamt ECS; með þessu kerfi er jafnvel diskurinn ekki hindrun, en við reyndum þetta ekki, þar sem við þurfum í grundvallaratriðum ekki diskinn til að geyma ástandið. Sjálfgefið, eftir að hafa fengið SIGINT (send þegar verkefni er flutt í Tæmandi stöðu), verða öll keyrð verkefni stöðvuð eftir 30 sekúndur, jafnvel þótt þeim sé ekki enn lokið; þú getur breytt þessum tíma með því að nota færibreytuna . Aðalatriðið er að stilla það ekki lengur en í 2 mínútur fyrir punktavélar.
Að búa til þjónustu
Við skulum halda áfram að búa til þjónustuna sem lýst er. Í því ferli mun ég að auki lýsa nokkrum gagnlegum atriðum sem ekki voru nefnd hér að ofan. Almennt séð er þetta skref-fyrir-skref kennsla, en ég mun ekki fjalla um mjög grundvallaratriði eða þvert á móti mjög sérstök tilvik. Allar aðgerðir eru framkvæmdar í AWS sjóntölvunni, en hægt er að afrita þær forritunarlega með CloudFormation eða Terraform. Við hjá Adapty notum Terraform.
EC2 ræsingarsniðmát
Þessi þjónusta býr til stillingar fyrir vélar sem verða notaðar. Sniðmátum er stjórnað í hlutanum EC2 -> Tilvik -> Ræsa sniðmát.
Amazon vélamynd (AMI) — tilgreindu diskamyndina sem öll tilvik verða ræst með. Fyrir ECS er í flestum tilfellum þess virði að nota fínstilltu myndina frá Amazon. Það er uppfært reglulega og inniheldur allt sem þarf til að ECS virki. Til að finna út núverandi myndauðkenni skaltu fara á síðuna , veldu svæðið sem þú ert að nota og afritaðu AMI auðkennið fyrir það. Til dæmis, fyrir us-east-1 svæðinu, er núverandi auðkenni þegar þetta er skrifað ami-00c7c1cf5bdc913ed. Þetta auðkenni verður að vera sett inn í hlutinn Tilgreina sérsniðið gildi.
Tegund tilviks — tilgreina tegund tilviks. Veldu þann sem hentar þér best.
Lyklapar (innskráning) — tilgreindu vottorð sem þú getur tengst tilvikinu með í gegnum SSH, ef þörf krefur.
Netstillingar — tilgreindu netfæribreytur. Netvettvangur í flestum tilfellum ætti að vera Virtual Private Cloud (VPC). Öryggishópar — öryggishópar fyrir tilvikin þín. Þar sem við munum nota balancer fyrir framan tilvikin mæli ég með því að tilgreina hóp hér sem leyfir komandi tengingar aðeins frá jafnvægisbúnaðinum. Það er, þú munt hafa 2 öryggishópa, einn fyrir jafnvægisbúnaðinn, sem gerir tengingar á innleið hvar sem er á höfnum 80 (http) og 443 (https), og hinn fyrir vélar, sem leyfir komandi tengingar á hvaða tengi sem er úr jafnvægishópnum. . Útleiðartengingar í báðum hópum verða að vera opnaðar með TCP samskiptareglum við allar hafnir á öll vistföng. Þú getur takmarkað port og vistföng fyrir útgående tengingar, en þá þarftu stöðugt að fylgjast með því að þú sért ekki að reyna að komast í eitthvað á lokuðu porti.
Geymsla (magn) — tilgreindu diskbreytur fyrir vélarnar. Diskastærðin má ekki vera minni en tilgreind í AMI; fyrir ECS Optimized er það 30 GiB.
Ítarlegar upplýsingar — tilgreindu viðbótarfæribreytur.
Kaupmöguleiki — hvort við viljum kaupa blettdæmi. Við viljum það, en við munum ekki haka við þennan reit hér; við munum stilla hann í Auto Scaling Group, það eru fleiri valkostir þar.
IAM tilvikssnið — tilgreina hlutverkið sem tilvikin verða sett í. Til þess að tilvik geti keyrt í ECS þurfa þau heimildir, sem venjulega er að finna í hlutverkinu ecsInstanceRole. Í sumum tilfellum er hægt að búa það til, ef ekki, þá hér um hvernig á að gera þetta. Eftir stofnun tilgreinum við það í sniðmátinu.
Næst eru margar breytur, í grundvallaratriðum geturðu skilið eftir sjálfgefin gildi alls staðar, en hver þeirra hefur skýra lýsingu. Ég virkja alltaf EBS-bjartsýni tilvikið og T2/T3 Unlimited valkostina ef þeir eru notaðir tilvik.
Gögn notenda — tilgreina notendagögn. Við munum breyta skránni /etc/ecs/ecs.config, sem inniheldur ECS umboðsmannstillingu.
Dæmi um hvernig notendagögn gætu litið út:
#!/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 — færibreytan gefur til kynna að tilvikið tilheyri klasa með uppgefnu nafni, það er að þessi klasi mun geta sett verkefni sín á þennan netþjón. Við höfum ekki búið til klasa ennþá, en við munum nota þetta nafn þegar við búum til hann.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — færibreytan tilgreinir að þegar merki er móttekið um að slökkva á blettatilviki, ættu öll verkefni á því að flytjast yfir í tæmandi stöðu.
ECS_CONTAINER_STOP_TIMEOUT=1m - færibreytan tilgreinir að eftir að hafa fengið SIGINT merki, hafa öll verkefni 1 mínútu áður en þeim er drepið.
ECS_ENGINE_AUTH_TYPE=docker — færibreytan gefur til kynna að Docker kerfið sé notað sem heimildarkerfi
ECS_ENGINE_AUTH_DATA=... - tengibreytur við einkagámaskrána, þar sem Docker myndirnar þínar eru geymdar. Ef það er opinbert, þá þarftu ekki að tilgreina neitt.
Í tilgangi þessarar greinar mun ég nota opinbera mynd frá Docker Hub, svo tilgreindu breyturnar ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA óþarfi.
Gott að vita: Mælt er með því að uppfæra AMI reglulega, vegna þess að nýjar útgáfur uppfæra útgáfur af Docker, Linux, ECS umboðsmanni o.s.frv. Til að gleyma þessu geturðu um útgáfu nýrra útgáfur. Þú getur fengið tilkynningar með tölvupósti og uppfært handvirkt, eða þú getur skrifað Lambda aðgerð sem mun sjálfkrafa búa til nýja útgáfu af Launch Template með uppfærðu AMI.
EC2 Auto Scaling Group
Auto Scaling Group er ábyrgur fyrir því að ræsa og skala tilvik. Hópum er stjórnað í hlutanum EC2 -> Sjálfvirk stigstærð -> Sjálfvirk stærðarhópar.
Ræstu sniðmát — veldu sniðmátið sem búið var til í fyrra skrefi. Við skiljum eftir sjálfgefna útgáfu.
Kaupmöguleikar og tilviksgerðir — tilgreindu tegundir tilvika fyrir klasann. Fylgjast með ræsingarsniðmátinu notar tilviksgerðina frá ræsingarsniðmátinu. Sameina kaupmöguleika og tilviksgerðir gerir þér kleift að stilla tilviksgerðir á sveigjanlegan hátt. Við munum nota það.
Valfrjáls stöð á eftirspurn — fjöldi venjulegra tilvika án bletts sem mun alltaf virka.
On-Demand hlutfall yfir grunni — Prósentuhlutfall venjulegra tilvika og punktatilvika, 50-50 verða dreift jafnt, 20-80 fyrir hvert venjulegt tilvik hækka 4 punkta. Í þessu dæmi mun ég gefa til kynna 50-50, en í raun gerum við oftast 20-80, í sumum tilfellum 0-100.
Tegundir tilfella — hér geturðu tilgreint fleiri tegundir tilvika sem verða notuð í þyrpingunni. Við notuðum það aldrei vegna þess að ég skil eiginlega ekki merkingu sögunnar. Kannski er þetta vegna takmarkana á tilteknum tegundum tilvika, en hægt er að auka þau auðveldlega með stuðningi. Ef þú þekkir forritið mun ég vera fegin að lesa það í athugasemdunum)
Net — netstillingar, veldu VPC og undirnet fyrir vélar, í flestum tilfellum ættirðu að velja öll tiltæk undirnet.
Hlaðajafnvægi - jafnvægisstillingar, en við munum gera þetta sérstaklega, við munum ekki snerta neitt hér. Heilbrigðiseftirlit verður einnig stillt síðar.
Stærð hóps — við tilgreinum takmarkanir á fjölda véla í klasanum og æskilegan fjölda véla í upphafi. Fjöldi véla í þyrpingunni verður aldrei minni en tilgreint lágmark og meira en hámarkið, jafnvel þótt skalning ætti sér stað samkvæmt mæligildum.
Stærðarstefnur — mælikvarðabreytur, en við munum skala út frá hlaupandi ECS-verkefnum, svo við munum stilla mælikvarðana síðar.
Dæmi um innbyggingarvörn — vernd tilvika gegn eyðingu þegar minnkað er. Við virkum það þannig að ASG eyði ekki vélinni sem hefur verkefni í gangi. ECS Capacity Provider mun slökkva á vernd fyrir tilvik sem hafa ekki verkefni.
Bættu við merkjum — þú getur tilgreint merki fyrir tilvik (til þess þarf að haka í gátreitinn Merkja ný tilvik). Ég mæli með því að tilgreina Name tag, þá munu öll tilvik sem eru ræst innan hópsins bera sama nafn og það er þægilegt að skoða þau í vélinni.
Eftir að hópurinn hefur verið búinn til, opnaðu hann og farðu í hlutann Ítarlegar stillingar. Af hverju eru ekki allir valkostir sýnilegir í stjórnborðinu á stofnunarstigi.
Uppsagnarreglur — reglur sem tekið er tillit til þegar tilvikum er eytt. Þeim er beitt í röð. Við notum venjulega þær á myndinni hér að neðan. Í fyrsta lagi er tilfellum með elsta ræsingarsniðmátinu eytt (td ef við uppfærðum AMI, bjuggum við til nýja útgáfu, en öll tilvik náðu að skipta yfir í það). Þá eru valin þau tilvik sem eru næst næstu innheimtutíma. Og þá eru þeir elstu valdir miðað við upphafsdegi.
Gott að vita: til að uppfæra allar vélar í klasa, þægilegt í notkun . Ef þú sameinar þetta við Lambda aðgerðina frá fyrra skrefi muntu hafa fullkomlega sjálfvirkt tilviksuppfærslukerfi. Áður en allar vélar eru uppfærðar verður þú að slökkva á innstækkunarvörn fyrir öll tilvik í hópnum. Ekki stillingar í hópnum, heldur vernd frá vélunum sjálfum, þetta er gert á Instance management flipanum.
Application Load Balancer og EC2 markhópur
Jöfnunarbúnaðurinn er búinn til í hlutanum EC2 → Álagsjafnvægi → Álagsjafnari. Við munum nota Application Load Balancer; samanburð á mismunandi gerðum jafnvægisbúnaðar má lesa á .
Hlustendur - það er skynsamlegt að gera port 80 og 443 og beina frá 80 til 443 með því að nota jafnvægisreglur síðar.
Framboðssvæði — í flestum tilfellum veljum við aðgengissvæði fyrir alla.
Stilltu öryggisstillingar — SSL vottorðið fyrir jafnvægisbúnaðinn er tilgreint hér, þægilegasti kosturinn er í ACM. Um muninn Öryggisstefna hægt að lesa inn , þú getur látið það vera valið sjálfgefið ELBSecurityPolicy-2016-08. Eftir að þú hefur búið til jafnvægisbúnaðinn muntu sjá það DNS nafn, sem þú þarft til að stilla CNAME fyrir lénið þitt. Til dæmis, svona lítur það út í Cloudflare.
Öryggishópur — búðu til eða veldu öryggishóp fyrir jafnvægisbúnaðinn, ég skrifaði meira um þetta rétt fyrir ofan í hlutanum EC2 ræsingarsniðmát → Netstillingar.
Markhópur — við búum til hóp sem er ábyrgur fyrir því að beina beiðnum frá jafnvægisbúnaðinum til véla og athuga hvort þær séu tiltækar til að skipta um þær ef vandamál koma upp. Markgerð verður að vera tilvik, Siðareglur и Port allir, ef þú notar HTTPS fyrir samskipti milli jafnvægisbúnaðar og tilvika, þá þarftu að hlaða upp vottorði til þeirra. Að því er þetta dæmi varðar munum við ekki gera þetta, við munum einfaldlega yfirgefa höfn 80.
Heilbrigðiseftirlit — færibreytur til að athuga virkni þjónustunnar. Í raunverulegri þjónustu ætti þetta að vera sérstök beiðni sem útfærir mikilvæga hluta viðskiptarökfræðinnar; að því er þetta dæmi varðar mun ég skilja eftir sjálfgefnar stillingar. Næst geturðu valið biðtíma, tímamörk, árangurskóða osfrv. Í dæminu okkar munum við gefa til kynna árangurskóða 200-399, vegna þess að Docker myndin sem verður notuð skilar 304 kóða.
Skráðu markmið — hér eru bílarnir fyrir hópinn valdir, en í okkar tilfelli verður þetta gert af ECS, svo við sleppum þessu skrefi bara.
Gott að vita: á jafnvægisstigi geturðu virkjað annála sem verða vistaðir í S3 á ákveðnum tíma . Þaðan er hægt að flytja þær út í þjónustu þriðja aðila til greiningar, eða þú getur gert SQL fyrirspurnir beint á gögnin í S3 með . Það er þægilegt og virkar án viðbótarkóða. Ég mæli líka með því að setja upp fjarlægingu á trjábolum úr S3 fötunni eftir tiltekinn tíma.
ECS Task Skilgreining
Í fyrri skrefum bjuggum við til allt sem tengist þjónustuinnviðum; nú förum við yfir í að lýsa gámunum sem við munum setja á markað. Þetta er gert í ECS → Verkefnaskilgreiningar hlutanum.
Samhæfni við ræsingartegund - veldu EC2.
Verkefnaframkvæmd IAM hlutverk - velja ecsTaskExecutionRole. Með því að nota það eru annálar skrifaðar, aðgangur að leynilegum breytum veittur o.s.frv.
Í hlutanum Gámaskilgreiningar, smelltu á Bæta við gámi.
Mynd - hlekkur á myndina með verkefniskóðanum; fyrir þetta dæmi mun ég nota opinbera mynd frá Docker Hub .
Minni takmörk — minnistakmörk fyrir ílátið. Hard Limit — hörð mörk, ef gámurinn fer út fyrir tilgreint gildi, verður docker kill skipunin framkvæmd, gámurinn deyr strax. Mjúk takmörk — mjúk takmörk, ílátið getur farið út fyrir tilgreint gildi, en tekið verður tillit til þessarar breytu þegar verkefni eru sett á vélar. Til dæmis, ef vél er með 4 GiB af vinnsluminni og mjúk takmörk íláts eru 2048 MiB, þá getur þessi vél haft að hámarki 2 hlaupandi verkefni með þessum íláti. Í raun og veru er 4 GiB af vinnsluminni aðeins minna en 4096 MiB, þetta er hægt að skoða á ECS Instances flipanum í klasanum. Mjúk mörk geta ekki verið hærri en hörð mörk. Það er mikilvægt að skilja að ef það eru nokkrir ílát í einu verkefni, þá eru takmörk þeirra tekin saman.
Kortlagning hafna - kl Hýsingarhöfn Við tilgreinum 0, þetta þýðir að höfninni verður úthlutað á virkan hátt og markhópurinn fylgist með henni. Gámahöfn — tengið sem forritið þitt keyrir á er oft tilgreint í framkvæmdarskipuninni eða úthlutað í forritakóðanum þínum, Dockerfile osfrv. Fyrir dæmi okkar munum við nota 3000 vegna þess að það er skráð í myndin sem verið er að nota.
Heilsufarsskoðun — færibreytur fyrir heilsufarsskoðun gáma, ekki að rugla saman við þann sem er stilltur í markhópnum.
umhverfi - umhverfisstillingar. CPU einingar - svipað og minnistakmarkanir, aðeins um örgjörvann. Hver örgjörvakjarni er 1024 einingar, þannig að ef þjónninn er með tvíkjarna örgjörva og ílátið er stillt á 512, þá er hægt að ræsa 4 verkefni með þessum íláti á einum netþjóni. Örgjörvaeiningar samsvara alltaf fjölda kjarna; það getur ekki verið aðeins færri af þeim, eins og raunin er með minni.
Skipun — skipun til að hefja þjónustu inni í gámi, allar færibreytur eru tilgreindar aðskildar með kommum. Þetta gæti verið byssuhorn, npm osfrv. Ef það er ekki tilgreint verður gildi CMD tilskipunarinnar frá Dockerfile notað. Við gefum til kynna npm,start.
Umhverfisbreytur — breytur í umhverfi gáma. Þetta getur verið annað hvort einföld textagögn eða leynilegar breytur frá eða .
Geymsla og skógarhögg - hér munum við setja upp skráningu í CloudWatch Logs (þjónusta fyrir logs frá AWS). Til að gera þetta skaltu bara virkja sjálfvirkt stilla CloudWatch Logs gátreitinn. Eftir að verkefnisskilgreiningin hefur verið búin til verður hópur annála sjálfkrafa búinn til í CloudWatch. Sjálfgefið er að annálar eru geymdar í því um óákveðinn tíma; ég mæli með því að breyta varðveislutímabilinu úr Aldrei rennur út í tilskilið tímabil. Þetta er gert í CloudWatch Log hópum, þú þarft að smella á núverandi tímabil og velja nýtt.
ECS Cluster og ECS Capacity Provider
Farðu í hlutann ECS → Klasar til að búa til klasa. Við veljum EC2 Linux + Networking sem sniðmát.
Nafn klasa - mjög mikilvægt, við gerum hér sama nafn og tilgreint er í Launch Template færibreytunni ECS_CLUSTER, í okkar tilviki - DemoApiClusterProd. Hakaðu í Búa til tóman klasa gátreitinn. Valfrjálst geturðu virkjað Container Insights til að skoða mælikvarða fyrir þjónustu í CloudWatch. Ef þú gerðir allt rétt, þá muntu sjá vélar sem voru búnar til í Auto Scaling hópnum í ECS Instances hlutanum.
Farðu í flipa Getuveitendur og búa til nýjan. Leyfðu mér að minna þig á að það er nauðsynlegt til að stjórna stofnun og lokun véla eftir fjölda ECS-verkefna sem eru í gangi. Það er mikilvægt að hafa í huga að veitanda er aðeins hægt að skipa í einn hóp.
Sjálfvirk stærðarhópur — veldu hópinn sem áður var búinn til.
Stýrður mælikvarði — virkjaðu það þannig að veitandinn geti stækkað þjónustuna.
Miðað getu % — hversu mörg prósent af vélum sem eru hlaðnar verkefnum þurfum við. Ef þú tilgreinir 100%, þá verða allar vélar alltaf uppteknar við að keyra verkefni. Ef þú tilgreinir 50%, þá verður helmingur bílanna alltaf ókeypis. Í þessu tilviki, ef það er mikið stökk í álagi, munu nýir leigubílar strax komast að lausum bílum, án þess að þurfa að bíða eftir tilvikum til að dreifa.
Stýrði uppsagnarvernd — virkja, þessi færibreyta gerir þjónustuveitunni kleift að fjarlægja vernd tilvika gegn eyðingu. Þetta gerist þegar engin virk verkefni eru á vélinni og leyfir Target getu%.
ECS Þjónusta og stærðaruppsetning
Síðasta skrefið :) Til að búa til þjónustu þarftu að fara í áður stofnaðan klasa á flipanum Þjónusta.
Ræsing gerð — þú þarft að smella á Skipta yfir í áætlun um afkastagetu og velja áður stofnaða veitendur.
Skilgreining verkefnis — veldu áður stofnaða Verkefnaskilgreiningu og endurskoðun hennar.
Þjónustunafn — til að forðast rugling, tökum við alltaf það sama og Task Definition.
Þjónusta tegund - alltaf eftirmynd.
Fjöldi verkefna — þann fjölda virkra verkefna sem óskað er eftir í þjónustunni. Þessari færibreytu er stjórnað með mælikvarða, en verður samt að vera tilgreind.
Lágmarks heilbrigt prósent и Hámarks prósent — ákvarða hegðun verkefna meðan á dreifingu stendur. Sjálfgefin gildi eru 100 og 200, sem gefur til kynna að við uppsetningu mun verkefnafjöldinn fjölga nokkrum sinnum og fara síðan aftur í æskilegt gildi. Ef þú ert með 1 verkefni í gangi, min=0 og max=100, þá verður það drepið á meðan á dreifingu stendur, og eftir það verður nýtt sett upp, það er að segja að það er niðurtími. Ef 1 verkefni er í gangi, min=50, max=150, þá mun dreifing alls ekki gerast, því ekki er hægt að skipta einu verkefni í tvennt eða auka um einn og hálfan tíma.
Tegund dreifingar — farðu frá Rolling uppfærslu.
Staðsetningarsniðmát — reglur um að setja verkefni á vélar. Sjálfgefið er AZ Balanced Spread - þetta þýðir að hvert nýtt verkefni verður sett á nýtt tilvik þar til vélar á öllum framboðssvæðum hækka. Við gerum venjulega BinPack - CPU og Spread - AZ; með þessari stefnu eru verkefni sett eins þétt og hægt er á einni vél á hvern örgjörva. Ef nauðsynlegt er að búa til nýja vél er hún búin til á nýju framboðssvæði.
Tegund álagsjafnvægis — veldu Application Load Balancer.
Þjónusta IAM hlutverk - velja ecsServiceRole.
Heiti álagsjafnara — veldu áður búið til jafnvægisbúnað.
Frestur til heilsufarsskoðunar — hlé áður en þú framkvæmir heilsufarsskoðun eftir að nýtt verkefni hefur verið sett út, við stillum það venjulega á 60 sekúndur.
Gámur til að hlaða jafnvægi — í hlutnum Nafn markhóps, veldu hópinn sem áður var búinn til og allt verður sjálfkrafa útfyllt.
Þjónusta Auto Scaling — þjónustustærðarfæribreytur. Veldu Stilla sjálfvirka stærð þjónustu til að stilla æskilegan fjölda þjónustu þinnar. Við stillum lágmarks- og hámarksfjölda verkefna við skala.
IAM hlutverk fyrir sjálfvirka þjónustustærð - velja AWSServiceRoleForApplicationAutoScaling_ECSService.
Sjálfvirk verkstærðarreglur — reglur um mælikvarða. Það eru 2 tegundir:
- Markaðsmæling — mælingar á markmiðum (CPU/RAM notkun eða fjöldi beiðna fyrir hvert verkefni). Til dæmis viljum við að meðalálag örgjörva sé 85%, þegar það verður hærra bætast við ný verkefni þar til það nær markgildi. Ef álagið er minna, þá verða verkefni fjarlægð, þvert á móti, nema vörn gegn minnkun sé virkjuð (Slökktu á innskala).
- Skrefsstærð - viðbrögð við handahófskenndum atburði. Hér getur þú stillt viðbrögð við hvaða atburði sem er (CloudWatch Alarm), þegar það gerist geturðu bætt við eða fjarlægt tilgreindan fjölda verkefna, eða tilgreint nákvæman fjölda verkefna.
Þjónusta getur haft nokkrar stærðarreglur, þetta getur verið gagnlegt, aðalatriðið er að tryggja að þær stangist ekki á við hvert annað.
Ályktun
Ef þú fylgdir leiðbeiningunum og notaðir sömu Docker myndina ætti þjónustan þín að skila síðu eins og þessari.
- Við höfum búið til sniðmát þar sem allar vélar í þjónustunni eru ræstar. Við lærðum líka hvernig á að uppfæra vélar þegar sniðmátið breytist.
- Við höfum stillt vinnslu stöðvunarmerkisins tilviks, þannig að innan mínútu eftir móttöku þess eru öll hlaupandi verkefni fjarlægð úr vélinni, svo ekkert glatast eða truflast.
- Við lyftum jafnvægisbúnaðinum til að dreifa álaginu jafnt yfir vélarnar.
- Við höfum búið til þjónustu sem keyrir á staðtilvikum, sem lækkar vélakostnað um það bil 3 sinnum.
- Við höfum stillt sjálfvirka stærðarstærð í báðar áttir til að takast á við aukið vinnuálag án þess að hafa í för með sér niðurtímakostnað.
- Við notum Capacity Provider þannig að forritið stýrir innviðum (vélum) en ekki öfugt.
- Við erum frábærir.
Ef þú ert með fyrirsjáanlega háa álagi, til dæmis ertu að auglýsa í stórri tölvupóstsherferð, geturðu sett upp mælingu með því að .
Þú getur einnig skalað út frá gögnum frá mismunandi hlutum kerfisins þíns. Til dæmis höfum við virknina notendur farsímaforritsins. Stundum er herferð send til 1 milljón+ manns. Eftir slíka dreifingu er alltaf mikil aukning á beiðnum í API þar sem margir notendur skrá sig inn í forritið á sama tíma. Þannig að ef við sjáum að það eru umtalsvert fleiri staðlaðar vísbendingar í biðröðinni til að senda kynningartilkynningar, getum við strax ræst nokkrar viðbótarvélar og verkefni til að vera tilbúin fyrir álagið.
Ég mun vera ánægður ef þú segir mér í athugasemdunum áhugaverð tilvik um notkun blettatilvika og ECS eða eitthvað um mælikvarða.
Bráðum munu birtast greinar um hvernig við vinnum úr þúsundum greiningaratburða á sekúndu á aðallega netþjónslausum stafla (með peningum) og hvernig uppsetning þjónustu virkar með GitLab CI og Terraform Cloud.
Gerast áskrifandi að okkur, það verður áhugavert!
Aðeins skráðir notendur geta tekið þátt í könnuninni. , takk.
Notar þú blettatilvik í framleiðslu?
-
22,2%Já6
-
66,7%No18
-
11,1%Ég lærði um þau úr grein og ætla að nota þau3
27 notendur kusu. 5 notendur sátu hjá.
Heimild: www.habr.com