{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Skalieritava API loomine AWS-i spot-instantides","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere k\u00f5igile! Olen Kirill, Adapty CTO. Suur osa meie arhitektuurist asub AWS-is ja t\u00e4na r\u00e4\u00e4gin, kuidas me v\u00e4hendasime serverikulud kolmandiku v\u00f5rra, kasutades spot-instantte tootmis\u00fcmbruses, samuti sellest, kuidas neid automaatselt skaalaida. Esiteks, tutvustus, kuidas see t\u00f6\u00f6tab, ja seej\u00e4rel p\u00f5hjalik juhend k\u00e4ivitamiseks.<\/p>\n

<\/p>\n

Mis on spot-instantid?<\/h2>\n

<\/p>\n

Spot-instantid<\/a><\/noindex> on AWS-i teiste kasutajate serverid, mis on hetkel kasutamata, ja nad m\u00fc\u00fcvad neid suure allahindlusega (Amazon kirjutab kuni 90%, meie kogemuse j\u00e4rgi on see ~3x, varieerub olenevalt piirkonnast, AZ-st ja instantt\u00fc\u00fcbist). Peamine erinevus tavainstantidest on see, et need v\u00f5ivad igal hetkel v\u00e4lja l\u00fclituda. Seet\u00f5ttu arvasime kaua, et nende kasutamine on normaalne arenduskeskkondades v\u00f5i \u00fclesannete arvutamisel, salvestades vahepealsed tulemused S3-sse v\u00f5i andmebaasi, kuid mitte tootmises. On olemas kolmandate osapoolte lahendusi, mis v\u00f5imaldavad spot-e tootmises kasutada, kuid seal meie juhtumi korral on palju t\u00f6\u00f6kohustuslikke lahendusi, seet\u00f5ttu ei rakendanud me neid. Artiklis kirjeldatud l\u00e4henemine t\u00f6\u00f6tab t\u00e4ielikult AWS-i standardsete funktsioonide raames, ilma t\u00e4iendavate skriptide, cronide jne.<\/p>\n

<\/a><\/noindex><\/p>\n

J\u00e4rgnevalt toon m\u00f5ned ekraanipildid, mis n\u00e4itavad spot-instantide hindade ajalugu.<\/p>\n

<\/p>\n

m5.large piirkonnas eu-west-1 (Iirimaa). Hind on peamiselt stabiilne 3 kuu jooksul, praegu on kokkuhoid 2.9x.<\/p>\n

<\/p>\n

\"Skalieritava<\/p>\n

<\/p>\n

m5.large piirkonnas us-east-1 (P\u00f5hja-Virginia). Hind muutub pidevalt 3 kuu jooksul, praegu on kokkuhoid vahemikus 2.3x kuni 2.8x s\u00f5ltuvalt k\u00e4ttesaadavuse tsoonist.<\/p>\n

<\/p>\n

\"Skalieritava<\/p>\n

<\/p>\n

t3.small piirkonnas us-east-1 (P\u00f5hja-Virginia). Hind on stabiilne 3 kuu jooksul, praegu on kokkuhoid 3.4x.<\/p>\n

<\/p>\n

\"Skalieritava<\/p>\n

<\/p>\n

Teenuse arhitektuur<\/h2>\n

<\/p>\n

Otsese teenuse p\u00f5hiarhitektuur, millest me selles artiklis r\u00e4\u00e4gime, on kujutatud alloleval diagrammil.<\/p>\n

<\/p>\n

\"Skalieritava<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 sihtgrupp \u2192 Elastne konteinerite teenus<\/h3>\n

<\/p>\n

Balansseerijana kasutatakse Application Load Balancerit (ALB), mis suunab p\u00e4ringud 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.<\/p>\n

<\/p>\n

\u00dchel instantsil v\u00f5ib olla mitu t\u00f6\u00f6tavat konteinerit sama portidega, seega ei saa me neid fikseeritud m\u00e4\u00e4rata. ECS teatab TG-le, et k\u00e4ivitab uue \u00fclesande (Kubernetes'i terminoloogias nimetatakse seda pod'iks), see kontrollib instantsil vabu porte ja m\u00e4\u00e4rab \u00fche neist k\u00e4itatavale \u00fclesandele. TG kontrollib regulaarselt, kas instants ja selle API t\u00f6\u00f6tavad l\u00e4bi tervisekontrolli ning kui m\u00e4rkab mingeid probleeme, l\u00f5petab see sinna p\u00e4ringute edastamise.<\/p>\n

<\/p>\n

EC2 Auto Scaling Groups + ECS Capacity Providers<\/h3>\n

<\/p>\n

\u00dclaltoodud diagrammil ei ole kujutatud EC2 Auto Scaling Groups (ASG) teenust. Nimi \u00fctleb, et see vastutab instantside skaleerimise eest. Kuid kuni hiljuti ei v\u00f5imaldanud AWS integreeritud v\u00f5imalust hallata ECS-ist k\u00e4ivitatud masinate arvu. ECS v\u00f5imaldas skaleerida \u00fclesannete arvu, n\u00e4iteks CPU, RAM v\u00f5i p\u00e4ringute arvu alusel. Kuid kui \u00fclesanded h\u00f5ivasid k\u00f5ik vabad instantsid, siis uusi masinaid automaatselt ei t\u00f5statud.<\/p>\n

<\/p>\n

See muutus koos ECS Capacity Providers (ECS CP) ilmumisega. N\u00fc\u00fcd saab iga teenuse ECS-is siduda ASG-ga, ja kui \u00fclesanded ei mahutu t\u00f6\u00f6tavatele instantsidele, t\u00f5stetakse uusi (kuid ASG kehtestatud piirangute raames). See t\u00f6\u00f6tab ka vastupidiselt: kui ECS CP n\u00e4eb rippuvaid instantsid ilma \u00fclesanneteta, annab see ASG-le k\u00e4su need v\u00e4lja l\u00fclitada. ECS CP-l on v\u00f5imalus m\u00e4\u00e4rata sihtkoormuse protsent, et teatud hulk masinaid oleks alati vaba kiireks \u00fclesannete skaleerimiseks, sellest r\u00e4\u00e4gin v\u00e4hese aja p\u00e4rast.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

Viimane teenus, millest ma r\u00e4\u00e4gin enne, kui l\u00e4hen selle infrastruktuuri loomise \u00fcksikasjalikule kirjeldamisele, on EC2 Launch Templates. See v\u00f5imaldab luua \u0448\u0430\u0431\u043b\u043e\u043d, mille j\u00e4rgi k\u00f5ik masinad k\u00e4ivitatakse, et seda ei peaks iga kord nullist kordama. Siin saab valida k\u00e4ivitatava masina t\u00fc\u00fcbi, turvagruppi, ketta kujunduse ja palju muid parameetreid. Samuti saab m\u00e4\u00e4rata kohandatud andmeid, mis laaditakse k\u00f5ikidele k\u00e4ivitatavatele instantsidele. Kohandatud andmete kaudu saab k\u00e4ivitada skripte, n\u00e4iteks saab redigeerida faili sisu ECS agendi konfiguratsioon<\/a><\/noindex>.<\/p>\n

<\/p>\n

\u00dcks k\u00f5ige olulisemaid konfiguratsiooni parameetreid antud artiklis on ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Kui see parameeter on sisse l\u00fclitatud, siis kui ECS saab signaali, et spottinstanss on eemaldamiseks, muudab ta k\u00f5ik sellel t\u00f6\u00f6tavad \u00fclesanded staatusesse Draining. Uusi \u00fclesandeid sellele instantsile ei m\u00e4\u00e4rata, kui on \u00fclesandeid, mis soovivad sinna voolata, siis need t\u00fchistatakse. Tasakaalustajatelt ei tule ka uusi p\u00e4ringuid. Teade instantsi eemaldamisest saabub kaks minutit enne tegelikku s\u00fcndmust. Seet\u00f5ttu, kui teie teenus ei tee t\u00f6\u00f6d kauem kui 2 minutit ja ei salvesta midagi kettale, siis v\u00f5ite kasutada spottinstantsse ilma andmete kaotuseta.<\/p>\n

<\/p>\n

Ketta osas \u2014 AWS tegi hiljuti saadaval<\/a><\/noindex> , et kasutada Elastic File System (EFS) koos ECS-iga; sellise skeemi puhul ei ole ketas takistuseks, kuid me ei ole seda proovinud, kuna p\u00f5him\u00f5tteliselt ei ole meil ketast oleku salvestamiseks vaja. Vaikimisi, kui saadetakse SIGINT (saadetakse hetkel, kui \u00fclesanne muudetakse staatusesse Draining), l\u00f5petatakse k\u00f5ik t\u00f6\u00f6tavad \u00fclesanded 30 sekundi jooksul, isegi kui nad ei ole valmis saanud, seda aega saab muuta parameetri ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Peamine on mitte seada seda rohkem kui 2 minutit spottmasinate jaoks.<\/p>\n

<\/p>\n

Teenuse loomine<\/h2>\n

<\/p>\n

Liigume otse nimetatud teenuse loomise juurde. Protsessi k\u00e4igus kirjeldan t\u00e4iendavalt mitmeid kasulikke punkte, millest eelnevalt ei r\u00e4\u00e4gitud. \u00dcldiselt on see samm-sammult juhend, kuid m\u00f5ned t\u00e4iesti p\u00f5hialused v\u00f5i vastupidi, v\u00e4ga spetsiifilised juhtumid ei ole mul kavas k\u00e4sitleda. K\u00f5ik toimingud toimuvad AWS visuaalses konsoolis, kuid neid saab programmiliselt korrata CloudFormationi v\u00f5i Terraformi abil. Adapty-s kasutame Terraformi.<\/p>\n

<\/p>\n

EC2 k\u00e4ivitamis\u0161abloon<\/strong><\/h3>\n

<\/p>\n

Selles teenuses luuakse masinate konfiguratsioon, mida kasutatakse. \u0160abloonide haldamine toimub jaotises EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Amazon machine image (AMI)<\/strong> \u2014 m\u00e4\u00e4rame ketta kuju, millega k\u00f5ik instantsid k\u00e4ivituvad. ECS-i jaoks on enamasti m\u00f5istlik kasutada Amazon'i optimeeritud kujutist. See uuendatakse regulaarselt ja sisaldab k\u00f5ike vajalikku ECS-i t\u00f6\u00f6ks. Aktiivse kujutise ID teadmiseks k\u00fclastage lehte Amazon ECS-optimized AMIs<\/a><\/noindex>, valige kasutatav piirkond ja kopeerige AMI ID selle jaoks. N\u00e4iteks us-east-1 piirkonnas on kirjutamise hetkel aktiivne ID \u2014 ami-00c7c1cf5bdc913ed<\/em>. Selle ID tuleks sisestada punkti Specify a custom value.<\/p>\n

<\/p>\n

Instantsi t\u00fc\u00fcp<\/strong> \u2014 m\u00e4\u00e4rake instantsi t\u00fc\u00fcp. Valige see, mis sobib teie \u00fclesandele k\u00f5ige paremini.<\/p>\n

<\/p>\n

Ava v\u00f5tmepaar (sisselogimine)<\/strong> \u2014 m\u00e4\u00e4rake sertifikaat, millega saab instantsi SSH kaudu \u00fchenduda, kui vajadus peaks tekkima.<\/p>\n

<\/p>\n

V\u00f5rgu seaded<\/strong> \u2014 m\u00e4\u00e4rake v\u00f5rgu parameetrid. V\u00f5rgustiku platvorm<\/strong> enamikul juhtudel peaks olema Virtuaalne Erakliendi V\u00f5rk (VPC). Turvagruppide<\/strong> \u2014 turvagruppid teie instantside jaoks. Kuna me kasutame instantside ees koormuse tasakaalustajat, soovitan siin m\u00e4\u00e4rata grupi, mis lubab sissetulevad \u00fchendused ainult koormuse tasakaalustajalt. See t\u00e4hendab, et teil on 2 turvagruppi: \u00fcks koormuse tasakaalustajale, mis lubab sissetulevaid (inbound) \u00fchendusi igalt poolt portide 80 (http) ja 443 (https) kaudu, ning teine masinate jaoks, mis lubab sissetulevaid \u00fchendusi mistahes portide kaudu koormuse tasakaalustaja grupilt. V\u00e4ljaminevad (outbound) \u00fchendused m\u00f5lemas grupis tuleb avada k\u00f5igile portidele TCP protokolli kaudu k\u00f5ikidesse aadressidesse. V\u00e4ljaminevaid \u00fchendusi on v\u00f5imalik piirata portide ja aadressidega, kuid siis on vaja pidevalt j\u00e4lgida, et te ei \u00fcritaks suhelda suletud portide kaudu.<\/p>\n

<\/p>\n

Salvestus (maht)<\/strong> \u2014 m\u00e4\u00e4rake masinate ketaste parameetrid. Ketta maht ei tohi olla v\u00e4iksem kui see, mis on m\u00e4\u00e4ratud AMI-s, ECS Optimizatsiooni jaoks \u2014 30 GiB.<\/p>\n

<\/p>\n

T\u00e4iendavad \u00fcksikasjad<\/strong> \u2014 m\u00e4\u00e4rake t\u00e4iendavad parameetrid.<\/p>\n

<\/p>\n

Ostuv\u00f5imalus<\/strong> \u2014 kas soovime osta spoot instantsid. Me soovime, kuid seda m\u00e4rki me siin ei pane, seadistame selle Auto Scaling Groupis, seal on rohkem valikuid.<\/p>\n

<\/p>\n

IAM instantsi profiil<\/strong> \u2014 m\u00e4\u00e4rake roll, millega instantsid k\u00e4ivituvad. Et instantsid t\u00f6\u00f6taksid ECS-is, on neil vaja \u00f5igusi, mis tavaliselt kuuluvad rollile ecsInstanceRole<\/em>. M\u00f5nel juhul v\u00f5ib see olla loodud; kui ei, siis siin juhend<\/a><\/noindex> kuidas seda teha. P\u00e4rast loomist m\u00e4\u00e4rame selle mallis.
\nEdasi on palju parameetreid, enamikul juhtudel v\u00f5ib j\u00e4tta vaikeseaded, kuid iga\u00fchel on arusaadav kirjeldus. Ma alati l\u00fclitan sisse EBS-optimeeritud instansi ja T2\/T3 Unlimited, kui need on kasutusel burstable<\/a><\/noindex> instantside jaoks.<\/p>\n

<\/p>\n

Kasutajate andmed<\/strong> \u2014 m\u00e4\u00e4rake kasutaja andmed. Me redigeerime faili \/etc\/ecs\/ecs.config<\/code>, kus asub ECS-i agendi konfiguratsioon.
\nN\u00e4ide sellest, milline kasutaja andmed v\u00e4lja v\u00f5ivad n\u00e4ha:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 parameeter n\u00e4itab, et instants kuulub m\u00e4\u00e4ratud nimega klastrisse, st see klaster saab oma \u00fclesandeid sellele serverile paigutada. Me pole veel klastrit loonud, kuid selle loomisel kasutame seda nime.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 parameeter n\u00e4itab, et spottinstansi v\u00e4ljal\u00fclitamise signaali saamisel peavad k\u00f5ik selle \u00fclesanded olema m\u00e4\u00e4ratud staatusele Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parameeter n\u00e4itab, et p\u00e4rast SIGINT signaali saamist on k\u00f5igil \u00fclesannetel 1 minut, enne kui need l\u00f5petatakse.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parameeter n\u00e4itab, et autoriseerimise mehhanismina kasutatakse docker skeemi.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 seosed privaatse konteineriregistriga, kus teie Docker pildid asuvad. Kui see on avalik, pole midagi t\u00e4psustama.<\/p>\n
<\/p>\n
K\u00e4esolevas artiklis kasutan avalikku pilti Docker Hub'ist, seega ei tule seoseid t\u00e4psustada. ECS_ENGINE_AUTH_TYPE<\/code> ja ECS_ENGINE_AUTH_DATA<\/code> ei ole vajalik.<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: soovitatakse regulaarselt uuendada AMI-d, sest uutes versioonides uuendatakse Docker, Linux, ECS agente jne. Et sellest mitte unustada, v\u00f5ite seada teavitused<\/a><\/noindex> uusversioonide v\u00e4ljatulekust. Saate teavitusi e-posti teel ja uuendada k\u00e4sitsi v\u00f5i saate kirjutada Lambda-funktsiooni, mis loob automaatselt uue versiooni Launch Template'ist koos uuendatud AMI-ga.<\/p>\n
<\/p>\n
EC2 Auto Scaling Group<\/strong><\/h3>\n
<\/p>\n
Auto Scaling Group vastutab instantside k\u00e4ivitamise ja skaleerimise eest. Gruppide juhtimine toimub jaotises EC2 -> Auto Scaling -> Auto Scaling Groups.<\/p>\n
<\/p>\n
Launch template<\/strong> \u2014 valime eelmisel sammul loodud mall. Versioon j\u00e4\u00e4b vaikeseadeks.<\/p>\n
<\/p>\n
Ostuvalikud ja instantside t\u00fc\u00fcbid<\/strong> \u2014 m\u00e4\u00e4rame klastrile instantside t\u00fc\u00fcbid. Adhere to launch template kasutab Launch Template'ist instantsit\u00fc\u00fcpi. Combine purchase options and instance types v\u00f5imaldab paindlikult konfigureerida instantside t\u00fc\u00fcpe. Me kasutame seda.<\/p>\n
<\/p>\n
Valikuline On-Demand baaspunkt<\/strong> \u2014 tavaliste, mitte-spottinstantside arv, mis t\u00f6\u00f6tavad alati.<\/p>\n
<\/p>\n
On-Demand protsentuaalne suhe baaspunkti \u00fcle<\/strong> \u2014 tavaliste ja spottinstantside protsentuaalne suhe, 50-50 jagab v\u00f5rdselt, 20-80 t\u00e4hendab, et iga tavalise instantsi kohta t\u00f5useb 4 spottinstantsi. Antud n\u00e4ites m\u00e4\u00e4ran 50-50, kuid tegelikult teeme enamasti 20-80, m\u00f5nedel juhtudel 0-100.<\/p>\n
<\/p>\n
Instantside t\u00fc\u00fcbid<\/strong> \u2014 siit saab t\u00e4psustada t\u00e4iendavaid instantsi t\u00fc\u00fcpe, mida kasutatakse klastris. Me ei ole seda kunagi kasutanud, kuna ma ei m\u00f5ista eriti selle loo eesm\u00e4rki. V\u00f5ib-olla on teema instantsi t\u00fc\u00fcpide piirangutes, kuid need suurenevad toetuse kaudu kergesti. Kui tead rakendusest, oleksin t\u00e4nulik, kui jagaksid kommentaarides)<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
V\u00f5rk<\/strong> \u2014 v\u00f5rguseaded, valida VPC ja alamv\u00f5rgud masinate jaoks, enamikul juhtudel tasub valida k\u00f5ik saadaval olevad alamv\u00f5rgud.<\/p>\n
<\/p>\n
Koormuse tasakaalustamine<\/strong> \u2014 tasakaalustaja seaded, kuid selle teeme eraldi, siin me midagi ei muuda. Tervisekontrollid<\/strong> ka seadistatakse hiljem.<\/p>\n
<\/p>\n
R\u00fchma suurus<\/strong> \u2014 m\u00e4\u00e4rame piirangud klastris olevate masinate arvu ja soovitud masinate arvu alguses. Klastris olevate masinate arv ei muutu kunagi v\u00e4iksemaks kui minimaalne ja suuremaks kui maksimaalne, isegi kui m\u00f5\u00f5dikute puhul peaks toimuma skaleerimine.<\/p>\n
<\/p>\n
Skaleerimisreeglid<\/strong> \u2014 skaleerimise seaded, kuid me skaleerime k\u00e4ivitatud ECS \u00fclesandeid silmas pidades, seet\u00f5ttu seadistame skaleerimise hiljem.<\/p>\n
<\/p>\n
Instantsi skalaarse sissetoodud kaitse<\/strong> \u2014 instantside kaitse eemaldamise eest skaleerimise ajal alla poole. L\u00fclitame sisse, et ASG ei kustutaks masinat, millel on k\u00e4ivitatud \u00fclesanded. Kaitse eemaldamine instantsidelt, millel pole \u00fclesandeid, toimub ECS Capacity Provideri kaudu.<\/p>\n
<\/p>\n
Lisa silte<\/strong> \u2014 saab m\u00e4\u00e4rata silte instantsidele (selleks peab olema m\u00e4rgitud kinnitus 'Tag new instances'). Soovitan m\u00e4\u00e4rata sildi Nimi, siis on k\u00f5ik grupis k\u00e4ivitatavad instantsid sama nimega, neid on mugav vaadata konsoolis.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
P\u00e4rast grupi loomist avage see ja minge jaotisse T\u00e4iendavad seaded, miks ei ole loomise etapis konsoolis n\u00e4htavad k\u00f5ik valikud.<\/p>\n
<\/p>\n
L\u00f5petamisreeglid<\/strong> \u2014 reeglid, mida arvesse v\u00f5etakse instantside eemaldamisel. Need rakenduvad j\u00e4rjekorras. Me kasutame tavaliselt selliseid, nagu alloleval joonisel. Esiteks kustutatakse instantsid, millel on k\u00f5ige vanem Launch Template (n\u00e4iteks kui oleme uuendanud AMI, oleme loonud uue versiooni, kuid k\u00f5ik instantsid on j\u00f5udnud sellele \u00fcle minna). Siis valitakse instantsid, mis on k\u00f5ige l\u00e4hemal j\u00e4rgmisele arvelduseale. Ja edasi valitakse vanimad k\u00e4ivitamise kuup\u00e4eva j\u00e4rgi.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: k\u00f5igi klastris olevate masinate uuendamiseks on mugav kasutada Instantsi v\u00e4rskendus<\/a><\/noindex>. Kui kombineerida see eelneva sammu Lambda funktsiooniga, on teil t\u00e4ielikult automatiseeritud instantside v\u00e4rskendamise s\u00fcsteem. Enne k\u00f5igi masinate v\u00e4rskendamist tuleb k\u00f5igi grupi instantside jaoks keelata instantsi skaalakaitse. See ei ole grupi seade, vaid kaitse ise masinatel, mida saab teha Instantsihalduse vahekaardil.<\/p>\n
<\/p>\n
Rakenduse Load Balancer ja EC2 sihtr\u00fchm<\/h3>\n
<\/p>\n
Balansseerija luuakse EC2 \u2192 Load Balancing \u2192 Load Balancers. Kasutame rakenduse Load Balancerit, erinevate tasemete balansseerijate v\u00f5rdlemist saate lugeda teenuse lehelt<\/a><\/noindex>.<\/p>\n
<\/p>\n
Kuulajad<\/strong> \u2014 on m\u00f5istlik teha 80 ja 443 porti ning suunata 80-lt 443-le balanseerija reeglite abil.<\/p>\n
<\/p>\n
Saadavuspiirkonnad<\/strong> \u2014 enamikul juhtudel valime k\u00f5ik saadavuspiirkonnad.<\/p>\n
<\/p>\n
Konfigureeri turvaseaded<\/strong> \u2014 siin m\u00e4\u00e4ratakse SSL-sertifikaat balansseerija jaoks, mugavaim valik on teha sertifikaat<\/a><\/noindex> ACM-is. Erinevuste kohta Turvapoliitika<\/strong> v\u00f5ite lugeda dokumentatsioon<\/a><\/noindex>, v\u00f5ib j\u00e4tta vaikimisi valitud ELBSecurityPolicy-2016-08<\/code>. P\u00e4rast balansseerija loomist n\u00e4ete selle DNS nime<\/strong>, millele tuleb seadistada CNAME teie domeeni jaoks. N\u00e4iteks n\u00e4eb see Cloudflays v\u00e4lja nii.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Turgrupp<\/strong> \u2014 loome v\u00f5i valime balansseerija jaoks turvagruppi, mille kohta olen varem rohkem kirjutanud jaotisest EC2 Launch Template \u2192 V\u00f5rguseaded.<\/p>\n
<\/p>\n
Sihtr\u00fchm<\/strong> \u2014 loome r\u00fchma, mis vastutab p\u00e4ringute suunamise eest balansseerijalt masinatele ja kontrollib nende k\u00e4ttesaadavust, et neid probleemide korral asendada. Sihi t\u00fc\u00fcp<\/strong> peab olema Instants, Protokoll<\/strong> ja Port<\/strong> igat t\u00fc\u00fcpi, kui kasutate HTTPS-i kontakteerumiseks balansseerija ja instantside vahel, tuleb neile laadida sertifikaat. Antud n\u00e4ites me seda ei tee, j\u00e4etakse lihtsalt 80 port.<\/p>\n
<\/p>\n
Tervisekontrollid<\/strong> \u2014 teenuse t\u00f6\u00f6kindluse kontrollimise parameetrid. T\u00f5eliselt teenuses peaks see olema eraldi p\u00e4ring, mis viib l\u00e4bi olulised \u00e4riloogika osad, antud n\u00e4ites j\u00e4tan vaikeseaded. Edasi saab valida p\u00e4ringute intervalli, aegumise, eduka vastuse koodid jne. Meie n\u00e4ites m\u00e4\u00e4rame eduka koodid 200-399, sest Docker pilt, mida kasutatakse, tagastab 304 koodi.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Registreeri sihid<\/strong> \u2014 siin valitakse grupile masinad, kuid meie juhul tegeleb sellega ECS, seega j\u00e4tame selle sammu vahele.<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: balansseerija tasemel saab lubada logid, mis salvestatakse S3-s kindlas formaadis<\/a><\/noindex>. Sealt, mida saab eksportida kolmandate osapoolte anal\u00fc\u00fcsiteenustesse, v\u00f5i teha SQL-p\u00e4ringuid otse S3 andmete p\u00f5hjal Athena abil<\/a><\/noindex>. See on mugav ja t\u00f6\u00f6tab ilma t\u00e4iendava koodita. Samuti soovitan seadistada logide eemaldamine S3 kaustast m\u00e4\u00e4ratud aja m\u00f6\u00f6dudes.<\/p>\n
<\/p>\n
ECS \u00dclesande M\u00e4\u00e4ratlemine<\/h3>\n
<\/p>\n
Varasemates etappides l\u00f5ime k\u00f5ik, mis on seotud teenuse infrastruktuuriga, n\u00fc\u00fcd liigume konteinerite kirjeldamise juurde, mida hakkame k\u00e4ivitama. Seda tehakse ECS \u2192 Task Definitions jaos.<\/p>\n
<\/p>\n
K\u00e4ivitust\u00fc\u00fcbi \u00fchilduvus<\/strong> \u2014 valime EC2.<\/p>\n
<\/p>\n
\u00dclesande t\u00e4itmise IAM-roll<\/strong> \u2014 valime ecsTaskExecutionRole<\/code>. Selle abil kirjutatakse logisid, saadakse juurdep\u00e4\u00e4s salajastele muutujatele jne.<\/p>\n
<\/p>\n
Container Definitions jaos vajutame Lisa konteiner.<\/p>\n
<\/p>\n
Pilt<\/strong> \u2014 link projekti koodi pildile, kasutame selle n\u00e4ite raames avalikku pilti Docker Hubist bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
M\u00e4lu piirangud<\/strong> \u2014 konteineri jaoks m\u00f5eldud m\u00e4lu piirangud. J\u00f5hkrad piirangud<\/strong> \u2014 j\u00f5hkrad piirangud, kui konteiner \u00fcletab m\u00e4\u00e4ratud v\u00e4\u00e4rtuse, k\u00e4ivitatakse k\u00e4sk docker kill, konteiner sureb koheselt. Pehmed piirangud<\/strong> \u2014 pehmed piirangud, konteiner v\u00f5ib \u00fcletada m\u00e4\u00e4ratud v\u00e4\u00e4rtuse, kuid \u00fclesannete paigutamisel masinatele v\u00f5etakse see parameeter arvesse. N\u00e4iteks, kui masinal on 4 GiB RAM-i ja konteineri pehme piirang on 2048 MiB, siis v\u00f5ib sellel masinal olla maksimaalselt 2 jooksvas \u00fclesandes selle konteineriga. Tegelikult on 4 GiB RAM veidi v\u00e4hem kui 4096 MiB, seda saab vaadata klastris ECS Instances vahelehelt. Pehme piirang ei saa olla suurem kui j\u00f5hkrad piirangud. Oluline on m\u00f5ista, et kui \u00fches \u00fclesandes on mitu konteinerit, siis nende piirangud summeeruvad.<\/p>\n
<\/p>\n
Sadama kaardistamine<\/strong> \u2014 Hosti port<\/strong> m\u00e4\u00e4rame 0, see t\u00e4hendab, et port m\u00e4\u00e4ratakse d\u00fcnaamiliselt, seda j\u00e4lgib Target Group. Konteineri port<\/strong> \u2014 port, millel teie rakendus t\u00f6\u00f6tab, m\u00e4\u00e4ratakse sageli t\u00e4itmise k\u00e4sus v\u00f5i m\u00e4\u00e4ratakse teie rakenduse koodis, Dockerfile'is jne. Kasutame oma n\u00e4ites 3000, sest see on m\u00e4\u00e4ratud Dockerfile<\/a><\/noindex> kasutatavas pildis.<\/p>\n
<\/p>\n
Tervisekontroll<\/strong> \u2014 konteineri t\u00f6\u00f6kindluse kontrollimise parameetrid, mitte segi ajada with Target Group'is seadistatud.<\/p>\n
<\/p>\n
Keskkond<\/strong> \u2014 keskkonnaseaded. CPU \u00fcksused<\/strong> \u2014 sarnane m\u00e4lu piirangutega, ainult protsessori kohta. Iga protsessorituuma kohta on 1024 \u00fchikut, seega kui serveril on kahetuumaline protsessor ja konteineril on v\u00e4\u00e4rtus 512, siis saab \u00fchel serveril k\u00e4ivitada 4 \u00fclesannet selle konteineriga. CPU \u00fchikud vastavad alati tuumade arvule, neid ei saa olla natuke v\u00e4hem, nagu m\u00e4lu puhul.<\/p>\n
<\/p>\n
K\u00e4sk<\/strong> \u2014 k\u00e4sk teenuse k\u00e4ivitamiseks konteineri sees, k\u00f5ik parameetrid n\u00e4idatakse koma kaudu. See v\u00f5ib olla gunicorn, npm jne. Kui ei ole m\u00e4\u00e4ratud, kasutatakse Dockerfile'i direktiivi CMD v\u00e4\u00e4rtust. N\u00e4itame npm,start<\/code>.<\/p>\n
<\/p>\n
Keskkonnamuutujad<\/strong> \u2014 konteineri keskkonnamuutujad. Need v\u00f5ivad olla nii lihtsalt tekstilised andmed kui ka salajased muutujad Secrets Manager<\/a><\/noindex> v\u00f5i Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Salvestamine ja logimine<\/strong> \u2014 siin seadistame logimise CloudWatch Logs'i (AWS-i logiteenus). Selleks piisab Auto-configure CloudWatch Logs'i m\u00e4rkimisest. P\u00e4rast Task Definition'i loomist luuakse automaatselt logigrupp CloudWatch'is. Vaikimisi s\u00e4ilitatakse logid seal l\u00f5pmatult; soovitan muuta Retention period'i 'Never Expire' pealt soovitud ajavahemikule. Seda tehakse CloudWatch Log groups'is, tuleb kl\u00f5psata praegusel perioodil ja valida uus.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
ECS klastri ja ECS mahutuse pakkuja<\/h3>\n
<\/p>\n
Liigume jaotisse ECS \u2192 Clusters, et luua klaster. Mallina valime EC2 Linux + Networking.<\/p>\n
<\/p>\n
Klastri nimi<\/strong> \u2014 v\u00e4ga oluline, anname siin sama nime nagu Launch Template'i parameetris ECS_CLUSTER<\/code>, meie juhul \u2014 DemoApiClusterProd<\/code>. M\u00e4rkige Create an empty cluster. Valikuline on lubada Container Insights, et n\u00e4ha teenuste metrikaid CloudWatch'is. Kui olete k\u00f5ik \u00f5igesti teinud, n\u00e4ete jaotises ECS Instances masinaid, mis loodi Auto Scaling gruppi.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Liigume vahekaardile Mahutuse pakkujad<\/strong> ja loome uue. Meenutan, et see on vajalik masinate loomise ja v\u00e4ljal\u00fclitamise haldamiseks s\u00f5ltuvalt t\u00f6\u00f6tavate ECS \u00fclesannete arvust. Oluline on m\u00e4rkida, et pakkuja saab olla seotud ainult \u00fche grupiga.<\/p>\n
<\/p>\n
Auto Scaling grupp<\/strong> \u2014 valime varem loodud grupi.<\/p>\n
<\/p>\n
Hallitav skaleerimine<\/strong> \u2014 lubame, et pakkuja saaks teenust skaleerida.<\/p>\n
<\/p>\n
Sihtkapasiteet %<\/strong> \u2014 kui suur on autode koormuse protsent, mida vajame \u00fclesannete jaoks. Kui m\u00e4\u00e4rata 100%, siis on k\u00f5ik autod alati t\u00f6\u00f6tavate \u00fclesannete poolt h\u00f5ivatud. Kui m\u00e4\u00e4rata 50%, siis on pool autoreid alati vabad. Sellisel juhul, kui koormus j\u00e4rsult suureneb, saavad uued \u00fclesanded kohe vaba autot kasutada, ilma et oleks vaja oodata instantside k\u00e4ivitamist.<\/p>\n
<\/p>\n
Haldatud l\u00f5petamisprotection<\/strong> \u2014 l\u00fclitame sisse, see parameeter lubab teenusepakkujal kaitsta instantside kustutamist. See juhtub, kui masinal ei ole aktiivseid \u00fclesandeid ja see v\u00f5imaldab Target capacity %.<\/p>\n
<\/p>\n
ECS teenus ja skaleerimise seadistamine<\/h3>\n
<\/p>\n
Viimane samm:) Et luua teenus, peame minema varem loodud klastrisse vahekaardile Teenused.<\/p>\n
<\/p>\n
K\u00e4ivitamise t\u00fc\u00fcp<\/strong> \u2014 tuleb kl\u00f5psata valikul Switch to capacity provider strategy ja valida varem loodud pakkuja.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
\u00dclesande m\u00e4\u00e4ratlemine<\/strong> \u2014 valime varem loodud \u00dclesande m\u00e4\u00e4ratluse ja selle versiooni.<\/p>\n
<\/p>\n
Teenuse nimi<\/strong> \u2014 et mitte eksida, m\u00e4\u00e4rame selle alati samaks, mis \u00dclesande m\u00e4\u00e4ratlemine.<\/p>\n
<\/p>\n
Teenuse t\u00fc\u00fcp<\/strong> \u2014 alati Replica.<\/p>\n
<\/p>\n
\u00dclesannete arv<\/strong> \u2014 soovitud aktiivsete \u00fclesannete arv teenuses. Seda parameetrit hallatakse skaleerimise abil, kuid seda tuleb ikkagi m\u00e4\u00e4rata.<\/p>\n
<\/p>\n
Minimaalne tervislik protsent<\/strong> ja Maksimaalne protsent<\/strong> \u2014 m\u00e4\u00e4ravad \u00fclesannete k\u00e4itumise juurutamise ajal. Vaikimisi v\u00e4\u00e4rtused on 100 ja 200, mis n\u00e4itavad, et juurutamise ajal suureneb \u00fclesannete arv mitu korda, seej\u00e4rel naaseb see soovitud tasemele. Kui teil t\u00f6\u00f6tab 1 \u00fclesanne, min=0, ja max=100, siis juurutamise ajal see tapetakse, ja p\u00e4rast seda t\u00f5useb uus, see t\u00e4hendab, et toimub seiskamine. Kui t\u00f6\u00f6tab 1 \u00fclesanne, min=50, max=150, siis juurutamine ei toimu, sest 1 \u00fclesannet ei saa jagada pooleks v\u00f5i suurendada 1.5 korda.<\/p>\n
<\/p>\n
Juurutamise t\u00fc\u00fcp<\/strong> \u2014 j\u00e4tame Rolling update.<\/p>\n
<\/p>\n
Paigutuse mallid<\/strong> \u2014 reeglid \u00fclesannete paigutamiseks masinatesse. Vaikimisi on AZ Balanced Spread \u2014 see t\u00e4hendab, et iga uus \u00fclesanne paigutatakse uude instantsi, kuni masinad t\u00f5usevad k\u00f5igis k\u00e4ttesaadavuse tsoonides. Me tavaliselt teeme BinPack \u2014 CPU ja Spread \u2014 AZ, sellise poliitikaga paigutatakse \u00fclesanded maksimaalselt tihedalt \u00fche masina j\u00e4rgi CPU. Uue masina vajadusel luuakse see uude k\u00e4ttesaadavuse tsooni.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Koormuse tasakaalustaja t\u00fc\u00fcp<\/strong> \u2014 valime Application Load Balancer.<\/p>\n
<\/p>\n
Teenuse IAM roll<\/strong> \u2014 valime ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Koormuse tasakaalustaja nimi<\/strong> \u2014 valime varem loodud tasakaalustaja.<\/p>\n
<\/p>\n
Tervisekontrolli ootamisperiood<\/strong> \u2014 paus enne uute \u00fclesannete t\u00f6\u00f6tamise kontrollide sooritamist, m\u00e4\u00e4rame tavaliselt 60 sekundit.<\/p>\n
<\/p>\n
Konteiner, mida tasakaalustada<\/strong> \u2014 valige 'Target group name' jaoks varem loodud r\u00fchm ja k\u00f5ik t\u00e4itub automaatselt.<\/p>\n
<\/p>\n
\"Skalieritava<\/p>\n
<\/p>\n
Teenuse automaatne skaleerimine<\/strong> \u2014 teenuse skaleerimise parameetrid. Valige 'Configure Service Auto Scaling to adjust your service\u2019s desired count'. M\u00e4\u00e4rake minimaalne ja maksimaalne t\u00f6\u00f6de arv skaleerimise ajal.<\/p>\n
<\/p>\n
IAM-rolle teenuse automaatseks skaleerimiseks<\/strong> \u2014 valime AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automaatne t\u00f6\u00f6de skaleerimise poliitika<\/strong> \u2014 skaleerimise reeglid. On 2 t\u00fc\u00fcpi:<\/p>\n
<\/p>\n
    \n
  1. Sihtimise j\u00e4lgimine<\/strong> \u2014 sihtm\u00e4rkide m\u00f5\u00f5dikute j\u00e4lgimine (CPU\/RAM-i kasutamine v\u00f5i p\u00e4ringute arv t\u00f6\u00f6de kohta). N\u00e4iteks, kui soovime, et protsessori keskmine koormus oleks 85%, siis kui see t\u00f5useb, lisatakse uusi t\u00f6id seni, kuni see j\u00f5uab sihttaseme juurde. Kui koormus on madalam, siis t\u00f6\u00f6d eemaldatakse, v\u00e4lja arvatud juhul, kui on lubatud skaleerimise allapoole kaitse (Keela skaleerimine<\/strong>).<\/li>\n
  2. Samm-sammuline skaleerimine<\/strong> \u2014 reageerimine igasugusele s\u00fcndmusele. Siit saab seadistada reaktsiooni mis tahes s\u00fcndmusele (CloudWatch Alarm), kui see aset leiab, saab lisada v\u00f5i eemaldada m\u00e4\u00e4ratud arvu t\u00f6id v\u00f5i m\u00e4\u00e4rata t\u00e4pselt vajalike t\u00f6\u00f6de arvu.<\/li>\n<\/ol>\n
    <\/p>\n
    Teenusel v\u00f5ivad olla mitu skaleerimise reeglit, see v\u00f5ib olla kasulik, peamine on j\u00e4lgida, et need \u00fcksteisega ei konfliktiks.<\/p>\n
    <\/p>\n
    Kokkuv\u00f5te<\/h2>\n
    <\/p>\n
    Kui j\u00e4rgite juhiseid ja kasutate sama Docker'i pilti, peaks teie teenus tagastama sellise lehe.<\/p>\n
    <\/p>\n
    \"Skalieritava<\/p>\n
    <\/p>\n
      \n
    1. Oleme loonud \u0161ablooni, mille alusel k\u00e4ivitatakse k\u00f5ik teenuse masinad. Oleme ka \u00f5ppinud masinaid uuendama, kui \u0161abloon muutub.<\/li>\n
    2. Olemegi seadnud \u00fcles spot-instantse peatamissignaali t\u00f6\u00f6tlemise, seega \u00fche minuti jooksul p\u00e4rast selle saamist eemaldatakse k\u00f5ik t\u00f6\u00f6tavad t\u00f6\u00f6d masinast, nii et midagi ei kao ega katkeda.<\/li>\n
    3. Oleme seadnud \u00fcles koormuse tasakaalustaja, et jaotada koormus masinate vahel \u00fchtlaselt.<\/li>\n
    4. Oleme loonud teenuse, mis t\u00f6\u00f6tab spot-instantidel, mille t\u00f5ttu v\u00e4henevad masina kulud umbes 3 korda.<\/li>\n
    5. Oleme seadnud \u00fcles automaatse skaleerimise kahes suunas, et t\u00f6\u00f6delda koormuste suurenemist, kuid samas mitte maksta seismise eest.<\/li>\n
    6. Kasutame Capacity Provideri, et rakendus hallaks infrastruktuuri (masinad), mitte vastupidi.<\/li>\n
    7. Me oleme toredad.<\/li>\n<\/ol>\n
      <\/p>\n
      Kui teil on ettearvatavad koormuspiigid, n\u00e4iteks reklaamite suurt e-kirjade jagamist, saate seadistada skaleerimise vastavalt ajakavale<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Samuti on v\u00f5imalik teha skaleerimist, tuginedes erinevate osade andmetele teie s\u00fcsteemis. N\u00e4iteks on meil funktsionaalsus iseseisvate reklaampakkumiste saatmiseks<\/a><\/noindex> mobiilirakenduse kasutajatele. M\u00f5nikord saadetakse kampaania rohkem kui 1M inimesele. P\u00e4rast sellist saadet on alati m\u00e4rgata suurt kasvu API-p\u00e4ringutes, kuna paljud kasutajad logivad rakendusse samal ajal sisse. Nii et kui me n\u00e4eme, et reklaampushide saatmiseks on j\u00e4rjekorras oluliselt rohkem, kui tavaliselt, saame koheselt k\u00e4ivitada mitu t\u00e4iendavat masinat ja \u00fclesannet, et valmis olla koormuseks.<\/p>\n
      <\/p>\n
      Oleks tore, kui jagaksite kommentaarides huvitavaid n\u00e4iteid spottinstantside ja ECS kasutamisest v\u00f5i midagi skaleerimise kohta.<\/p>\n
      <\/p>\n
      Varsti tulevad artiklid selle kohta, kuidas me t\u00f5husalt t\u00f6\u00f6tleme tuhandeid anal\u00fc\u00fctilisi s\u00fcndmusi sekundis peamiselt serverless arhitektuuril (rahaga) ja kuidas teenuste juurutamine toimub GitLab CI ja Terraform Cloud abil.<\/p>\n
      <\/p>\n
      Liituge meiega, see on huvitav!<\/p>\n
      Ainult registreeritud kasutajad saavad k\u00fcsitluses osaleda. Logige sisse<\/a><\/noindex>, palun.<\/p>\n
      Kas kasutate spottinstantsse tootmises?<\/h2>\n