{"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":"Skalaarse API loomine AWS-i spottinstantsidel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tere k\u00f5igile! Minu nimi on Kirill, olen Adapty CTO. Suur osa meie arhitektuurist asub AWS-is, ja t\u00e4na r\u00e4\u00e4gin, kuidas me v\u00e4hendasime serverikulud kolmandiku v\u00f5rra, kasutades spottinstante tootmiskeskkonnas, ning kuidas neid automaatseteks skaleerimiseks seadistada. Esiteks, anan \u00fclevaate, kuidas see toimib, ja seej\u00e4rel detaliseeritud juhendi k\u00e4ivitamiseks.<\/p>\n

<\/p>\n

Mis on spottinstantsid?<\/h2>\n

<\/p>\n

Spottinstantsid<\/a><\/noindex> Instants on AWS \u2014 see on teiste kasutajate serverid, mis hetkel seisavad ja mida nad m\u00fc\u00fcvad suure allahindlusega (Amazon v\u00e4idab kuni 90%, meie kogemusest ~3x, varieerub s\u00f5ltuvalt regionaalsetest erip\u00e4ra, AZ-st ja instantside t\u00fc\u00fcbist). Peamine erinevus tavainstantsidest seisneb selles, et need v\u00f5ivad igal hetkel v\u00e4lja l\u00fclituda. Seet\u00f5ttu oleme pikalt arvanud, et neid on normaalne kasutada arendus- v\u00f5i testkeskkondades v\u00f5i erinevate arvutuste tegemiseks, salvestades vahekohti S3-le v\u00f5i andmebaasi, kuid mitte tootmises. On olemas kolmandate osapoolte lahendusi, mis v\u00f5imaldavad spote kasutada tootmises, kuid meie juhtumi jaoks on seal palju alternatiivseid lahendusi, mist\u00f5ttu me neid ei rakendanud. Artiklis kirjeldatud l\u00e4henemine t\u00f6\u00f6tab t\u00e4ielikult AWS-i standardse funktsionaalsuse raames, ilma t\u00e4iendavate skriptide, cronide jne kasutamiseta.<\/p>\n

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

J\u00e4rgnevalt toon v\u00e4lja m\u00f5ned ekraanipildid, mis n\u00e4itavad spotaalsete instantside hinnahistorit.<\/p>\n

<\/p>\n

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

<\/p>\n

\"Skalaarse<\/p>\n

<\/p>\n

m5.large us-east-1 piirkonnas (N. Virginia). Hind muutub pidevalt 3 kuu v\u00e4ltel, praegu on s\u00e4\u00e4st 2,3x kuni 2,8x s\u00f5ltuvalt k\u00e4ttesaadavuspiirkonnast.<\/p>\n

<\/p>\n

\"Skalaarse<\/p>\n

<\/p>\n

t3.small us-east-1 piirkonnas (N. Virginia). Hind on olnud stabiilne 3 kuu jooksul, praegu on s\u00e4\u00e4st 3,4x.<\/p>\n

<\/p>\n

\"Skalaarse<\/p>\n

<\/p>\n

Teenuse arhitektuur<\/h2>\n

<\/p>\n

Alusarhitektuur teenusele, millest me selles artiklis r\u00e4\u00e4gime, on kujutatud alloleval diagrammil.<\/p>\n

<\/p>\n

\"Skalaarse<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Balansseerijana kasutatakse Application Load Balancerit (ALB), mis suunab p\u00e4ringud EC2 Target Groupi (TG). TG vastutab ALB-le portide avamise eest instantsidel ja nende sidumise eest Elastic Container Service'i (ECS) konteinerite portidega. ECS on AWS-s Kubernetes'e analoog, mis haldab Docker konteinerite k\u00e4sitsemist.<\/p>\n

<\/p>\n

\u00dchel instantsil v\u00f5ib olla mitu t\u00f6\u00f6tavat konteinerit sama pordiga, seega ei saa me neid fikseerida. ECS teavitab TG-d, et ta k\u00e4ivitab uue \u00fclesande (Kubernetes'i terminoloogias tuntud kui pod), see kontrollib instantsi vaba porte ja m\u00e4\u00e4rab \u00fche neist k\u00e4ivitatavale \u00fclesandele. Samuti kontrollib TG regulaarselt, kas instants ja selle API t\u00f6\u00f6tavad, kasutades health check'i, ja kui ta n\u00e4eb mingeid probleeme, siis l\u00f5petab ta sealsete p\u00e4ringute edastamise.<\/p>\n

<\/p>\n

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

<\/p>\n

\u00dclaltoodud diagrammil pole n\u00e4idatud EC2 Auto Scaling Groups (ASG) teenust. Nagu nimest j\u00e4reldada v\u00f5ib, vastutab see instantside skaleerimise eest. Siiski ei olnud viimase ajani AWS-is sisseehitatud funktsiooni, mis v\u00f5imaldaks ECS-ist k\u00e4ivitatud masinate arvu hallata. ECS v\u00f5imaldas \u00fclesannete arvu skaleerida, n\u00e4iteks CPU, RAMi v\u00f5i p\u00e4ringute arvu p\u00f5hjal. Kuid kui \u00fclesanded kasutasid k\u00f5ik vabad instantsid, siis uusi masinaid automaatselt ei k\u00e4ivitatud.<\/p>\n

<\/p>\n

See muutus ECS Capacity Providers (ECS CP) tekkimisega. N\u00fc\u00fcd saab iga ECS teenuse siduda ASG-ga, ja kui \u00fclesanded ei mahu t\u00f6\u00f6tavatesse instantsidesse, k\u00e4ivitatakse uued (kuid ASG seatud piirangute raames). See t\u00f6\u00f6tab ka vastupidiselt: kui ECS CP n\u00e4eb ootavaid instantsse ilma \u00fclesanneteta, annab ta ASG-le k\u00e4su need v\u00e4lja l\u00fclitada. ECS CP-l on v\u00f5imalus m\u00e4\u00e4rata instantside sihtkoormuse protsent, et teatud arv masinaid oleks alati vabast, et tagada kiire \u00fclesannete skaleerimine; r\u00e4\u00e4gin sellest natuke hiljem.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

Viimane teenus, millest ma r\u00e4\u00e4gin, enne kui l\u00e4hen \u00fcksikasjalikule \u00fclevaatele selle infrastruktuuri loomise kohta, on EC2 Launch Templates. See v\u00f5imaldab luua malli, mille alusel k\u00f5ik masinad k\u00e4ivitatakse, et seda iga kord nullist mitte korrata. Siin saab valida k\u00e4ivitatava masina t\u00fc\u00fcbi, turvagruppi, ketta pildi ja palju muid parameetreid. Samuti saab m\u00e4\u00e4rata kasutajateabe, mis laetakse k\u00f5ikidele k\u00e4ivitatud instantsidele. Kasutajateabes 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 selles artiklis on ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Kui see parameeter on sisse l\u00fclitatud, siis niipea kui ECS saab signaali, et spott instanssi eemaldatakse, muudab see k\u00f5ik \u00fclesanded, mis sellele t\u00f6\u00f6tavad, olekusse Draining. Uusi \u00fclesandeid sellele instansile ei m\u00e4\u00e4rata, ja kui on \u00fclesandeid, mis soovivad sellele v\u00e4lja lasta, t\u00fchistatakse need. Tasakaalustajalt tulevad p\u00e4ringud lakkaavad saabumast. Teate eemaldamise kohta saadetakse 2 minutit enne tegelikku s\u00fcndmust. Seet\u00f5ttu, kui teie teenus ei tee \u00fclesandeid kauem kui 2 minutit ja ei salvesta midagi kettale, siis saate kasutada spott instansse ilma andmete kaotuseta.<\/p>\n

<\/p>\n

Ketta osas \u2014 AWS on hiljuti teinud<\/a><\/noindex> Elastic File System (EFS) kasutamine koos ECS-iga on v\u00f5imalik, selle skeemiga ei ole isegi ketas takistuseks, kuid me ei ole seda proovinud, kuna p\u00f5him\u00f5tteliselt ei vaja me ketast oleku s\u00e4ilitamiseks. Vaikimisi saadetakse SIGINT (mis saadetakse \u00fclesande staatuse muutmise ajal Drainingiks) k\u00f5ik jooksvaid \u00fclesandeid peatatakse 30 sekundi p\u00e4rast, isegi kui nad ei ole l\u00f5pule viidud, seda aega saab muuta parameetri abil ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Peamine on mitte seadistada seda \u00fcle 2 minuti spootmasinate jaoks.<\/p>\n

<\/p>\n

Teenuse loomine<\/h2>\n

<\/p>\n

Liigume otse nimetatud teenuse loomise juurde. Protsessi k\u00e4igus selgitan mitmeid kasulikke punkte, millest pole varem r\u00e4\u00e4gitud. \u00dcldiselt on see samm-sammult juhend, kuid ma ei k\u00e4sitle m\u00f5ningaid t\u00f5eliselt p\u00f5hitaseme v\u00f5i vastupidi v\u00e4ga spetsiifilisi juhtumeid. K\u00f5ik toimingud viiakse l\u00e4bi AWS visuaalses konsoolis, kuid neid saab programmiliselt uuesti luua CloudFormationi v\u00f5i Terraformi abil. Adapty's kasutame Terraformi.<\/p>\n

<\/p>\n

EC2 Launch Template<\/strong><\/h3>\n

<\/p>\n

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

<\/p>\n

Amazon machine image (AMI)<\/strong> \u2014 m\u00e4\u00e4rame diskifaili, millega k\u00f5ik instantsid k\u00e4ivituvad. ECS-i jaoks on enamikul juhtudel otstarbekas kasutada Amazoni optimeeritud pilti. See uuendatakse regulaarselt ja sisaldab k\u00f5ike vajalikku ECS-i toimimiseks. Aktuaalse ID leidmiseks k\u00fclastame lehte Amazon ECS-iga optimeeritud AMI-d<\/a><\/noindex>, valime kasutatava piirkonna ja kopeerime AMI ID selle jaoks. N\u00e4iteks piirkonnas us-east-1 on artikkel kirjutamise hetkeks aktuaalne ID \u2014 ami-00c7c1cf5bdc913ed<\/em>. Selle ID tuleb sisestada punkti Specify a custom value.<\/p>\n

<\/p>\n

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

<\/p>\n

Ahnuse paar (sisselogimine)<\/strong> \u2014 m\u00e4\u00e4rame sertifikaadi, millega saab vajadusel instantsiga SSH kaudu \u00fchendust luua.<\/p>\n

<\/p>\n

V\u00f5rguseaded<\/strong> \u2014 m\u00e4\u00e4rame v\u00f5rgu parameetrid. V\u00f5rguteenuste platvorm<\/strong> enamikul juhtudel peab olema Virtual Private Cloud (VPC). Turvagrupp<\/strong> \u2014 turvaregid teie instantside jaoks. Kuna me kasutame koormuse tasakaalustajat instantside ees, soovitan siin m\u00e4\u00e4rata grupi, mis lubab sisenevaid \u00fchendusi ainult koormuse tasakaalustajalt. Niisiis, teil on kaks turvaregistreid: \u00fcks koormuse tasakaalustaja jaoks, mis lubab sisenevaid (inbound) \u00fchendusi k\u00f5ikjal portidel 80 (http) ja 443 (https), ja teine masinate jaoks, mis lubab sisenevaid \u00fchendusi k\u00f5igis portides koormuse tasakaalustaja grupist. V\u00e4ljuvad (outbound) \u00fchendused m\u00f5lemas grupis tuleb avada TCP protokolli kaudu k\u00f5igis portides, k\u00f5ikidest aadressidest. V\u00e4ljuvate \u00fchenduste portide ja aadresside piiramine on v\u00f5imalik, kuid siis tuleb pidevalt j\u00e4lgida, et te ei p\u00fc\u00fca \u00fchendust luua suletud pordi kaudu.<\/p>\n

<\/p>\n

Salvestus (mahud)<\/strong> \u2014 m\u00e4\u00e4rame masinate ketaste parameetreid. Ketta maht ei tohi olla v\u00e4iksem sellest, mis on m\u00e4\u00e4ratud AMI-s, ECS Optimeeritud puhul \u2014 30 GiB.<\/p>\n

<\/p>\n

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

<\/p>\n

Ostuvalik<\/strong> \u2014 kas soovime osta spotinstante. Me tahame, kuid siin me seda m\u00e4rget ei pane, seame selle Auto Scaling Group\u2019is, seal on rohkem valikuid.<\/p>\n

<\/p>\n

IAM instantsi profiil<\/strong> \u2014 m\u00e4\u00e4rame rolli, millega instantsid k\u00e4ivitatakse. Et instantsid t\u00f6\u00f6taksid ECS-is, on neil vaja \u00f5igusi, mis tavaliselt kuuluvad rolli ecsInstanceRole<\/em>. M\u00f5nel juhul v\u00f5ib see olla loodud, kui ei ole, siis siin juhend<\/a><\/noindex> kuidas seda teha. P\u00e4rast loomist m\u00e4\u00e4rame selle mallis.
\nEdasi tuleb palju parameetreid, enamasti saab j\u00e4tta vaikimisi v\u00e4\u00e4rtused, kuid iga\u00fchel on arusaadav kirjeldus. Mina lisan alati EBS-optimized instance ja T2\/T3 Unlimited parameetrid, kui kasutatakse burstable<\/a><\/noindex> instantsid.<\/p>\n

<\/p>\n

Kasutajaandmed<\/strong> \u2014 m\u00e4\u00e4rame kasutajaandmed. Me redigeerime faili \/etc\/ecs\/ecs.config<\/code>, kus on ECS agendi konfiguratsioon.
\nN\u00e4ide sellest, milline v\u00f5ib olla kasutajaandmed:<\/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 klastrisse, mille nimi on m\u00e4\u00e4ratud, see t\u00e4hendab, et see klaster saab oma \u00fclesandeid sellel serveril majutada. Me pole veel klastrit loonud, kuid loomisel kasutame seda nime.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 parameeter n\u00e4itab, et kui spootinstansi v\u00e4ljal\u00fclitamise signaal tuleb, peavad k\u00f5ik sellel olevad \u00fclesanded minema staatusse Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parameeter m\u00e4\u00e4rab, et SIGINT signaali saamisel on k\u00f5igil \u00fclesannetel 1 minut, enne kui need tapetakse.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parameeter m\u00e4\u00e4rab, et autoriseerimise mehhanismina kasutatakse docker-skeemi.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 \u00fchendamisparameetrid privaatsele konteineriregistrile, kus teie Docker pildid asuvad. Kui see on avalik, siis ei pea midagi n\u00e4itama.<\/p>\n
<\/p>\n
Selles artiklis kasutan avalikku pilti Docker Hubist, seega ei pea parameetreid ECS_ENGINE_AUTH_TYPE<\/code> ja ECS_ENGINE_AUTH_DATA<\/code> n\u00e4itama.<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: soovitatakse regulaarselt AMI-d uuendada, kuna uutes versioonides uuendatakse Docker, Linux, ECS agent ja teised. Et sellest mitte unustada, v\u00f5ib seada teavitused<\/a><\/noindex> uusversioonide v\u00e4ljastamise kohta. Saate teavitusi emailile ja uuendada k\u00e4sitsi, v\u00f5i v\u00f5ite 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. R\u00fchmade haldamine toimub EC2 -> Auto Scaling -> Auto Scaling Groups jaotises.<\/p>\n
<\/p>\n
Launch template<\/strong> \u2014 valime eelmisel sammul loodud mall. Versiooni j\u00e4tame vaikev\u00e4\u00e4rtuseks.<\/p>\n
<\/p>\n
Ostuv\u00f5imalused ja instantside t\u00fc\u00fcbid<\/strong> \u2014 m\u00e4\u00e4rame v\u00e4lja klastrite instantside t\u00fc\u00fcbid. Adhere to launch template kasutab Launch Template'i instantsi t\u00fc\u00fcpi. Combine purchase options and instance types v\u00f5imaldab instantside t\u00fc\u00fcpide paindlikku seadistamist. Me kasutame seda.<\/p>\n
<\/p>\n
Valikuline On-Demand baas<\/strong> \u2014 tavaliste, mitte-spotseeritud instantside arv, mis alati t\u00f6\u00f6tavad.<\/p>\n
<\/p>\n
On-Demand protsent baasist<\/strong> \u2014 tavaliste ja spot-instantide protsentuaalne suhe, 50-50 jagab \u00fchtlaselt, 20-80 t\u00e4hendab, et iga tavaline instants t\u00f5stetakse 4 spot-instantiga. Antud n\u00e4ite p\u00f5hjal esitan 50-50, aga tegelikult teeme me k\u00f5ige sagedamini 20-80, m\u00f5nel juhul 0-100.<\/p>\n
<\/p>\n
Instantside t\u00fc\u00fcbid<\/strong> \u2014 siin saab m\u00e4\u00e4rata t\u00e4iendavad instantside t\u00fc\u00fcbid, mida klastris kasutatakse. Me ei ole kunagi kasutanud, sest ma ei saa sellest h\u00e4sti aru. V\u00f5ib-olla on asi instantside t\u00fc\u00fcpidega seotud limiitides, aga need t\u00f5stetakse h\u00f5lpsasti toe kaudu. Kui teil on rakendamise kohta teadmisi, oleksin r\u00f5\u00f5mus, kui loeksin kommentaarides).<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
V\u00f5rk\n   log \/dev\/log local0\n   log \/dev\/log local1 notice\n   chroot \/var\/lib\/haproxy\n   stats timeout 30s\n   user haproxy\n   group haproxy\n   daemon\n\ndefaults\n   log global\n   mode http\n   option httplog\n   option dontlognull\n   timeout connect 5000\n   timeout client 50000\n   timeout server 50000\n\nfrontend http_front\n   bind *:80\n   stats uri \/haproxy?stats\n   default_backend http_back\n\nbackend http_back\n   balance roundrobin\n   server server_name1 private_ip1:80 check\n   server server_name2 private_ip2:80 check<\/strong> \u2014 v\u00f5rguseaded, valige VPC ja alamv\u00f5rgud masinate jaoks, enamikul juhtudel tasub valida k\u00f5ik saadaval olevad alamv\u00f5rgud.<\/p>\n
<\/p>\n
Laotamine<\/strong> \u2014 tasakaalustamise seadistused, aga me teeme seda eraldi, siin ei puutu me midagi. Tervisekontrollid<\/strong> seadeid kohandatakse hiljem.<\/p>\n
<\/p>\n
Gruppide suurus<\/strong> \u2014 m\u00e4\u00e4rame piirid klastris olevate masinate arvu ja soovitud k\u00e4ivitamise masinate arvu. Klastris olevate masinate arv ei saa kunagi olla v\u00e4iksem kui minimaalne number ja suurem kui maksimaalne, isegi kui m\u00f5\u00f5dikute p\u00f5hjal peaks toimuma skaleerimine.<\/p>\n
<\/p>\n
Skaaleerimise poliitikad<\/strong> \u2014 skaleerimise parameetrid, kuid me skaleerime vastavalt k\u00e4ivitatud ECS \u00fclesannetele, seega seadistame skaleerimise hiljem.<\/p>\n
<\/p>\n
Instantsi skaaleerimise kaitse<\/strong> \u2014 kaitse instantside kustutamise eest allaskaleerimise korral. L\u00fclitame sisse, et ASG ei kustutaks masinat, millel on t\u00f6\u00f6tavad \u00fclesanded. Kaitse eemaldatakse instantsidelt, millel ei ole \u00fclesandeid, ECS Capacity Provideri poolt.<\/p>\n
<\/p>\n
Lisa silte<\/strong> \u2014 instantsidele saab lisada silte (kui on t\u00e4psustatud m\u00e4rge \"Tag new instances\"). Soovitan m\u00e4rkida sildi \"Name\", siis nimetatakse k\u00f5ik instantsid, mis k\u00e4ivituvad grupi raames, \u00fchesuguseks, mida on mugav j\u00e4lgida konsoolis.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
P\u00e4rast grupi loomist avage see ja minge jaotisse \"Advanced configurations\", miks ei ole loomise etapis konsoolis n\u00e4htavad k\u00f5ik valikud.<\/p>\n
<\/p>\n
L\u00f5petamispoliitikad<\/strong> \u2014 reeglid, mida arvestatakse instantside eemaldamisel. Need kehtivad j\u00e4rjekorras. Kasutame tavaliselt selliseid nagu pildil allpool. Esiteks eemaldatakse instantsid, millel on k\u00f5ige vanem Launch Template (n\u00e4iteks, kui oleme AMI-d uuendanud, on meil loodud uus versioon, aga k\u00f5ik instantsid on selle peale vahetunud). Siis valitakse v\u00e4lja instantsid, mis on k\u00f5ige l\u00e4hemal j\u00e4rgmisele arveldamise ajale. Edasi valitakse k\u00f5ige vanemad loodud kuup\u00e4evaga instantsid.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: k\u00f5ikide masinate v\u00e4rskendamiseks klastris on mugav kasutada Instance Refresh<\/a><\/noindex>. Kui seda kombineerida eelneva sammu Lambda-funktsiooniga, siis on teil t\u00e4iesti automatiseeritud instantside uuendamise s\u00fcsteem. K\u00f5ikide masinate uuendamise eel tuleb v\u00e4lja l\u00fclitada instantside scale-in kaitse k\u00f5igile grupi instantsidele. Mitte grupi seadistus, vaid just masinate kaitse ennast, see tehakse Instantside halduse vahekaardil.<\/p>\n
<\/p>\n
Application Load Balancer ja EC2 Target Group<\/h3>\n
<\/p>\n
Tasakaalustaja luuakse EC2 \u2192 Load Balancing \u2192 Load Balancers osas. Kasutame Application Load Balancerit, erinevate tasakaalustajate t\u00fc\u00fcpide v\u00f5rdlust saab lugeda teenuse lehelt<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 on m\u00f5istlik seadistada 80. ja 443. port ning suunata 80. port 443. porti kaudu \u00fclesandeid tasakaalujao reeglite abil.<\/p>\n
<\/p>\n
Saadavuse tsoonid<\/strong> \u2014 valime enamasti k\u00f5iki saadavuse tsoone.<\/p>\n
<\/p>\n
Konfigureeri turvaseaded<\/strong> \u2014 siin m\u00e4\u00e4ratakse SSL-sertifikaat tasakaalustajale, k\u00f5ige mugavam variant on luua sertifikaat<\/a><\/noindex> ACM-is. Erinevuste kohta Turvapoliitika<\/strong> v\u00f5ib lugeda dokumentatsioonis<\/a><\/noindex>, v\u00f5ib j\u00e4tta vaikes\u00e4tteks valitud ELBSecurityPolicy-2016-08<\/code>. P\u00e4rast tasakaalustaja loomist n\u00e4ete selle DNS-nime<\/strong>, millele tuleb seadistada CNAME teie domeenile. N\u00e4iteks, nii see v\u00e4lja n\u00e4eb Cloudflares.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Turvagrupp<\/strong> \u2014 loome v\u00f5i valime tasakaalustajale turgrupi, sellest on rohkem kirjutatud eelnevalt osas EC2 Launch Template \u2192 V\u00f5rguseaded.<\/p>\n
<\/p>\n
Sihtgrupp<\/strong> \u2014 loome grupi, mis vastutab p\u00e4ringute suunamise eest tasakaalustajalt masinatele ja kontrollib nende k\u00e4ttesaadavust, et asendada probleemide korral. Sihtt\u00fc\u00fcp<\/strong> peab olema Instance, Protokoll<\/strong> ja Port<\/strong> m\u00f5lemad, kui kasutate HTTPS-i suhtlemiseks tasakaalustaja ja instantside vahel, siis tuleb neile \u00fcles laadida sertifikaat. Antud n\u00e4ite raames me seda tegema ei hakka, lihtsalt j\u00e4tame 80. porti.<\/p>\n
<\/p>\n
Tervisekontrollid<\/strong> \u2014 teenused, mida kontrollida. K\u00e4esolev teenus peaks olema eraldi p\u00e4ring, mis rakendab olulisi \u00e4riloogika komponente; antud n\u00e4ite kontekstis j\u00e4tan vaikeseaded alles. Edasi saab valida p\u00e4ringute vahemaa, ajutise katkestuse, eduka vastuse koodid jne. N\u00e4ites m\u00e4\u00e4rame edukate koodide vahemiku 200-399, kuna kasutatav Docker pilt tagastab koodi 304.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Registreeri sihtpunktid<\/strong> \u2014 siin valitakse masinad grupi jaoks, kuid meie juhul tegeleb sellega ECS, seega j\u00e4tame selle sammu lihtsalt vahele.<\/p>\n
<\/p>\n
Kasulik teada<\/strong>: tasemel laadimisjagaja saab lubada logid, mis salvestatakse S3-sse teatud formaadis<\/a><\/noindex>. Sealt saab neid eksportida kolmandatesse teenustesse anal\u00fc\u00fcsiks v\u00f5i teha SQL-p\u00e4ringuid otse S3 andmetele Athena<\/a><\/noindex>. See on mugav ja t\u00f6\u00f6tab ilma t\u00e4iendava koodita. Soovitan samuti seadistada logide eemaldamine S3 \u00e4mbrist etten\u00e4htud aja m\u00f6\u00f6dudes.<\/p>\n
<\/p>\n
ECS \u00fclesande m\u00e4\u00e4ratlemine<\/h3>\n
<\/p>\n
Varasematel etappidel loodi k\u00f5ik teenuse infrastruktuuriga seonduv, n\u00fc\u00fcd liigume konteinerite kirjeldamise juurde, mida me k\u00e4ivitame. See toimub jaotises ECS \u2192 \u00dclesande m\u00e4\u00e4ratlused.<\/p>\n
<\/p>\n
K\u00e4ivitamise t\u00fc\u00fcpide \u00fchilduvus<\/strong> \u2014 valige EC2.<\/p>\n
<\/p>\n
\u00dclesande t\u00e4itmise IAM-rakk<\/strong> \u2014 valige ecsTaskExecutionRole<\/code>. Selle abil kirjutatakse logisid, antakse juurdep\u00e4\u00e4s salajastele muutujaile jms.<\/p>\n
<\/p>\n
Container Definitions jaotises vajutage Lisa konteiner.<\/p>\n
<\/p>\n
Image<\/strong> \u2014 lingi pilt projekti koodiga, antud n\u00e4ite puhul kasutan avalikku pilti Docker Hub'ist bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
M\u00e4lu limiidid<\/strong> \u2014 konteineri m\u00e4lu limiidid. J\u00f5hker limiit<\/strong> \u2014 rangelt m\u00e4\u00e4ratud limiit, kui konteiner \u00fcletab m\u00e4\u00e4ratud v\u00e4\u00e4rtuse, t\u00e4idetakse k\u00e4sk docker kill, konteiner sureb kohe. Pehme limiit<\/strong> \u2014 pehme limiit, konteiner v\u00f5ib \u00fcletada m\u00e4\u00e4ratud v\u00e4\u00e4rtuse, kuid \u00fclesannete paigutamisel masinates arvestatakse seda parameetrit. N\u00e4iteks kui masinas on 4 GiB RAM-i ja konteineri pehme limiit on 2048 MiB, siis v\u00f5ib selle konteineri jaoks olla masinas maksimaalselt 2 \u00fclesannet k\u00e4ivitatud. Tegelikult on 4 GiB RAM-i veidi v\u00e4hem kui 4096 MiB, seda saab vaadata ECS Instances vahekaardilt klastris. Pehme limiit ei saa olla suurem kui j\u00f5hker limiit. Oluline on m\u00f5ista, et kui \u00fches \u00fclesandes on mitu konteinerit, siis nende limiidid liidetakse.<\/p>\n
<\/p>\n
Sadama kaardistamine<\/strong> \u2014 in Hosti port<\/strong> M\u00e4\u00e4rame 0, see t\u00e4hendab, et port m\u00e4\u00e4ratakse d\u00fcnaamiliselt, seda j\u00e4lgib Target Group. Kontaineri port<\/strong> \u2014 port, millel teie rakendus t\u00f6\u00f6tab, m\u00e4\u00e4ratakse sageli t\u00e4itmis k\u00e4sus v\u00f5i m\u00e4\u00e4ratakse teie rakenduse koodis, Dockerfile'is jne. Meie n\u00e4ites kasutame 3000, sest see on m\u00e4\u00e4ratud Dockerfile<\/a><\/noindex> kasutatava pildi.<\/p>\n
<\/p>\n
Tervisekontroll<\/strong> \u2014 konteineri t\u00f6\u00f6kindluse kontrollimise parameetrid, mitte segi ajada sellega, mis on seadistatud Target Group'is.<\/p>\n
<\/p>\n
Keskkond<\/strong> \u2014 keskkonna seaded. CPU \u00fchikud<\/strong> \u2014 sarnaneb M\u00e4lul\u00e4venditega, ainult et see on protsessori kohta. Iga protsessori tuum on 1024 \u00fchikut, nii et kui serveril on kahetuumaline protsessor ja konteineril on v\u00e4\u00e4rtuseks seatud 512, siis sama serveri peal v\u00f5ib olla k\u00e4ivitatud 4 \u00fclesannet selle konteineriga. CPU \u00fchikute arv vastab alati tuumade arvule, neid ei saa olla v\u00e4hem kui m\u00e4lu puhul.<\/p>\n
<\/p>\n
K\u00e4sk<\/strong> \u2014 k\u00e4sk teenuse k\u00e4ivitamiseks konteineri sees, k\u00f5ik parameetrid m\u00e4\u00e4ratakse koma kaudu. See v\u00f5ib olla gunicorn, npm jne. Kui ei ole m\u00e4\u00e4ratud, kasutatakse Dockerfile'i CMD direktiivi v\u00e4\u00e4rtust. M\u00e4\u00e4rame npm,start<\/code>.<\/p>\n
<\/p>\n
Keskkonnamuutujad<\/strong> \u2014 konteineri keskkonnavariandid. Need v\u00f5ivad olla nii lihtsad tekstilised andmed kui ka salajased variandid Secrets Manager<\/a><\/noindex> v\u00f5i Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Salvestamine ja logimine<\/strong> \u2014 siin seadistame logimise CloudWatch Logs'ile (AWS'i logiteenuse). Selleks piisab, kui m\u00e4rkida Auto-configure CloudWatch Logs. P\u00e4rast Task Definition'i loomist koostatakse automaatselt logigrupp CloudWatch'is. Vaikimisi s\u00e4ilitatakse logid selles l\u00f5putult, soovitan muuta Retention period'it vahemikule Never Expire vastavalt n\u00f5udmistele. Seda tehakse CloudWatch Log groups, klikkides praegusele perioodile ja valides uue.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
ECS Cluster ja ECS Capacity Provider<\/h3>\n
<\/p>\n
Liigume jaotisse ECS \u2192 Clusters, et luua klaster. Mallina valime EC2 Linux + Networking.<\/p>\n
<\/p>\n
Klasteri nimi<\/strong> \u2014 on \u00e4\u00e4rmiselt oluline, et nimi oleks siin sama, mis Launch Template'is parameetris ECS_CLUSTER<\/code>, meie puhul \u2014 DemoApiClusterProd<\/code>. M\u00e4rkige Create an empty cluster. Valikuliselt saate lubada Container Insights, et j\u00e4lgida teenuste m\u00f5\u00f5dikuid CloudWatch'is. Kui k\u00f5ik on \u00f5igesti tehtud, n\u00e4ete jaotises ECS Instances masinaid, mis loodi Auto Scaling grupis.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Liigume vahekaardile Capacity Providers<\/strong> ja loome uue. Tuletan meelde, et see on vajalik masinate loomise ja v\u00e4ljal\u00fclitamise haldamiseks s\u00f5ltuvalt aktiivsete ECS-t\u00f6\u00f6\u00fclesannete arvust. Oluline on m\u00e4rkida, et pakkuja saab olla seotud ainult \u00fche grupiga.<\/p>\n
<\/p>\n
Auto Scaling group<\/strong> \u2014 valime varasemalt loodud grupi.<\/p>\n
<\/p>\n
Managed scaling<\/strong> \u2014 aktiveerime, et pakkuja saaks teenust juurde skaleerida.<\/p>\n
<\/p>\n
Target capacity %<\/strong> \u2014 kui suur protsent masinate koormusest on meie jaoks vajalik. Kui m\u00e4rkida 100%, on k\u00f5ik masinad alati t\u00f6\u00f6le kasutuses. Kui m\u00e4rkida 50%, j\u00e4\u00e4b pooled masinad alati vabaks. Sellisel juhul, kui koormus j\u00e4rsult t\u00f5useb, saavad uued t\u00f6\u00f6\u00fclesanded kohe vabadele masinatele, ilma et peaks ootama instantside juurutamist.<\/p>\n
<\/p>\n
Managed termination protection<\/strong> \u2014 aktiveerime, see seade lubab pakkujal eemaldada instantside kustutamise kaitse. See toimub, kui masinal ei ole aktiivseid t\u00f6\u00f6\u00fclesandeid ja v\u00f5imaldab Target capacity %.<\/p>\n
<\/p>\n
ECS teenus ja skaleerimise seadistamine<\/h3>\n
<\/p>\n
Viimane samm :) Teenuse loomiseks tuleb minna varasemalt loodud klastrisse vahekaardile Teenused.<\/p>\n
<\/p>\n
Launch type<\/strong> \u2014 tuleb kl\u00f5psata valikul Switch to capacity provider strategy ja valida varasemalt loodud pakkuja.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Task Definition<\/strong> \u2014 valime varem loodud Task Definition'i koos selle versiooniga.<\/p>\n
<\/p>\n
Teenuse nimi<\/strong> \u2014 et mitte segadusse minna, m\u00e4\u00e4rame alati sama, mis Task Definition.<\/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 juhib skaleerimine, kuid see tuleb ikkagi m\u00e4\u00e4rata.<\/p>\n
<\/p>\n
Minimaalne tervena p\u00fcsiv protsent<\/strong> ja Maksimaalne protsent<\/strong> \u2014 m\u00e4\u00e4ravad \u00fclesannete k\u00e4itumise juurutamisel. Vaikimisi v\u00e4\u00e4rtused 100 ja 200 viitavad sellele, et juurutamise hetkel suureneb \u00fclesannete arv mitu korda ning seej\u00e4rel naaseb soovitud hulka. Kui teil t\u00f6\u00f6tab 1 \u00fclesanne, min=0 ja max=100, siis juurutamisel see tapetakse ja seej\u00e4rel k\u00e4ivitatakse uus, st toimub seisak. Kui t\u00f6\u00f6tab 1 \u00fclesanne, min=50 ja max=150, siis juurutamine ei toimu, sest 1 \u00fclesannet ei saa pooleks jagada ega 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 \u00fclesannete paigutamise reeglid masinates. Vaikimisi on AZ Balanced Spread \u2013 see t\u00e4hendab, et iga uus \u00fclesanne paigutatakse uuele instantsile seni, kuni masinad t\u00f5usevad k\u00f5igis k\u00e4ttesaadavuse tsoonides. Me kasutame tavaliselt BinPack - CPU ja Spread - AZ, mille puhul paigutatakse \u00fclesanded maksimaalselt tihedalt \u00fchte masinasse CPU j\u00e4rgi. Uue masina loomise vajadusel luuakse see uues k\u00e4ttesaadavuse tsoonis.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Laadurit\u00fc\u00fcp<\/strong> \u2014 valime Rakenduse Tasakaalustaja.<\/p>\n
<\/p>\n
Teenuse IAM roll<\/strong> \u2014 valime ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Laadurite nimi<\/strong> \u2014 valime varem loodud tasakaalustaja.<\/p>\n
<\/p>\n
Tervisekontrolli gracia periood<\/strong> \u2014 paus enne tervisekontrollide teostamist p\u00e4rast uue \u00fclesande versiooni, tavaliselt seame 60 sekundit.<\/p>\n
<\/p>\n
Konteiner, mida tasakaalustada<\/strong> \u2014 punktis Sihtgrupi nimi valime varem loodud r\u00fchma ja k\u00f5ik t\u00e4itub automaatselt.<\/p>\n
<\/p>\n
\"Skalaarse<\/p>\n
<\/p>\n
Teenuse automaatne skaleerimine<\/strong> \u2014 teenuse skaleerimise parameetrid. Valime Configure Service Auto Scaling to adjust your service\u2019s desired count. Seame minimaalne ja maksimaalne \u00fclesannete arv skaleerimise ajal.<\/p>\n
<\/p>\n
IAM roll teenuse automaatseks skaleerimiseks<\/strong> \u2014 valime AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automaatne \u00fclesannete skaleerimise poliitika<\/strong> \u2014 skaleerimise reeglid. On 2 t\u00fc\u00fcpi:<\/p>\n
<\/p>\n
    \n
  1. Sihtj\u00e4lgimise<\/strong> \u2014 sihtm\u00f5\u00f5diku j\u00e4lgimine (CPU\/RAM kasutamine v\u00f5i k\u00f5igi \u00fclesannete jaoks tehtud p\u00e4ringute arv). N\u00e4iteks tahame, et keskmine protsessori koormus oleks 85%, ning kui see t\u00f5useb k\u00f5rgemale, siis uusi \u00fclesandeid lisatakse, kuni see j\u00f5uab sihttasemele. Kui koormus on madalam, siis \u00fclesandeid vastupidi eemaldatakse, kui allapoole skaleerimise kaitse ei ole sisse l\u00fclitatud (Keela sisse skaleerimine<\/strong>).<\/li>\n
  2. Samm-sammuline skaleerimine<\/strong> \u2014 reageerimine juhuslikule s\u00fcndmusele. Siin saab seadistada reageerimise mis tahes s\u00fcndmusele (CloudWatch Alarm), ja s\u00fcndmuse toimumisel saab lisada v\u00f5i eemaldada m\u00e4\u00e4ratud arvu \u00fclesandeid, v\u00f5i m\u00e4\u00e4rata t\u00e4pse \u00fclesannete arvu.<\/li>\n<\/ol>\n
    <\/p>\n
    Teenusel v\u00f5ib olla mitu skaleerimisreeglit, mis v\u00f5ib olla kasulik, kuid tuleb j\u00e4lgida, et need \u00fcksteisega ei konflikteeruks.<\/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
    \"Skalaarse<\/p>\n
    <\/p>\n
      \n
    1. Oleme loonud mall, mille alusel k\u00e4ivitatakse k\u00f5ik masinad teenuses. Oleme \u00f5ppinud ka masinaid ajakohastama, kui mall muutub.<\/li>\n
    2. Me oleme seadistatud katkestussignaali t\u00f6\u00f6tlemise spottinstantside jaoks, seega eemaldatakse k\u00f5ik t\u00f6\u00f6tavad \u00fclesanded masinal \u00fche minuti jooksul p\u00e4rast signaali saamist, nii et midagi ei kaota ega katkestata.<\/li>\n
    3. Oleme seadistanud tasakaalustaja, et jaotada koormust masinate vahel \u00fchtlaselt.<\/li>\n
    4. Oleme loonud teenuse, mis t\u00f6\u00f6tab spottinstantsidel, seel\u00e4bi v\u00e4hendades masinaid umbes kolm korda.<\/li>\n
    5. Oleme seadistanud automaatse skaaleerimise m\u00f5lemas suunas, et hallata koormuste suurenemist, kuid samal ajal mitte maksta seismise eest.<\/li>\n
    6. Kasutame Capacity Provider'i, et rakendus hallaks infrastruktuuri (masinaid), mitte vastupidi.<\/li>\n
    7. Me oleme toredad.<\/li>\n<\/ol>\n
      <\/p>\n
      Kui teil on ettearvatavad koormuse t\u00f5usud, n\u00e4iteks reklaamite suure e-kirja saatmisega, saate seadistada skaaleerimise ajakava j\u00e4rgi<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Samuti on v\u00f5imalik teha skaaleerimist andmete p\u00f5hjal erinevatest teie s\u00fcsteemi osadest. N\u00e4iteks meil on funktsionaalsus isikliku reklaamipakkumise saatmiseks.<\/a><\/noindex> mobiilirakenduse kasutajad. M\u00f5nikord saadetakse kampaania 1M+ inimesele. P\u00e4rast sellist saatmist t\u00e4heldatakse alati suurt API-p\u00e4ringute kasvu, kuna palju kasutajaid siseneb samal ajal rakendusse. Seega, kui n\u00e4eme, et promotsioonipushide saatmise j\u00e4rjekorras on oluliselt rohkem inimesi kui tavap\u00e4raselt, saame kohe k\u00e4ivitada mitu t\u00e4iendavat masinat ja \u00fclesannet, et olla valmis koormuseks.<\/p>\n
      <\/p>\n
      Oleksin v\u00e4ga t\u00e4nulik, kui jagaksite kommentaarides huvitavaid juhtumeid spottinstantside ja ECS kasutamise kohta v\u00f5i midagi, mis puudutab skaleerimist.<\/p>\n
      <\/p>\n
      Peagi tulevad artiklid selle kohta, kuidas t\u00f6\u00f6tleme tuhandeid anal\u00fc\u00fctilisi s\u00fcndmusi sekundis peamiselt serverless tehnoloogial (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