Kamusta kayong lahat! Ang pangalan ko ay Kirill, ako ay CTO sa Adapty. Karamihan sa aming arkitektura ay nasa AWS, at ngayon ay magsasalita ako tungkol sa kung paano namin binawasan ang mga gastos sa server ng 3 beses sa pamamagitan ng paggamit ng mga spot instances sa isang production environment, pati na rin kung paano i-set up ang kanilang autoscaling. Una, magkakaroon ng pangkalahatang-ideya kung paano ito gumagana, at pagkatapos ay mga detalyadong tagubilin para sa pagsisimula.
Ano ang mga Spot Instances?
Ang mga instance ay mga server ng iba pang mga gumagamit ng AWS na kasalukuyang idle, at ibinebenta nila ang mga ito sa isang malaking diskwento (nagsusulat ang Amazon ng hanggang 90%, sa aming karanasan ~3x, nag-iiba depende sa rehiyon, AZ at uri ng instance). Ang kanilang pangunahing pagkakaiba mula sa mga regular ay maaari silang i-off anumang oras. Samakatuwid, sa loob ng mahabang panahon ay naniniwala kami na normal na gamitin ang mga ito para sa mga birhen na kapaligiran, o para sa mga gawain ng pagkalkula ng isang bagay, na may mga intermediate na resulta na naka-save sa S3 o sa database, ngunit hindi para sa mga benta. May mga third-party na solusyon na nagbibigay-daan sa iyong gumamit ng mga spot sa produksyon, ngunit maraming saklay para sa aming kaso, kaya hindi namin ipinatupad ang mga ito. Ang diskarte na inilarawan sa artikulo ay ganap na gumagana sa loob ng karaniwang paggana ng AWS, nang walang karagdagang mga script, mga korona, atbp.
Nasa ibaba ang ilang screenshot na nagpapakita ng history ng presyo para sa mga spot instances.
m5.malaki sa rehiyon ng eu-west-1 (Ireland). Ang presyo ay halos stable sa loob ng 3 buwan, kasalukuyang nakakatipid ng 2.9x.
m5.malaki sa us-silangan-1 rehiyon (N. Virginia). Ang presyo ay patuloy na nagbabago sa loob ng 3 buwan, kasalukuyang nagse-save mula 2.3x hanggang 2.8x depende sa availability zone.
t3.maliit sa us-silangan-1 na rehiyon (N. Virginia). Ang presyo ay stable sa loob ng 3 buwan, kasalukuyang nakakatipid ng 3.4x.
Arkitektura ng serbisyo
Ang pangunahing arkitektura ng serbisyo na pag-uusapan natin sa artikulong ito ay ipinapakita sa diagram sa ibaba.
Application Load Balancer → EC2 Target Group → Elastic Container Service
Ang Application Load Balancer (ALB) ay ginagamit bilang isang balancer, na nagpapadala ng mga kahilingan sa EC2 Target Group (TG). Responsable ang TG sa pagbubukas ng mga port sa mga instance para sa mga ALB at pagkonekta sa mga ito sa mga port ng mga container ng Elastic Container Service (ECS). Ang ECS ay isang analogue ng Kubernetes sa AWS, na namamahala sa mga container ng Docker.
Ang isang instance ay maaaring magkaroon ng ilang tumatakbong container na may parehong mga port, kaya hindi namin maitakda ang mga ito nang maayos. Sinasabi ng ECS sa TG na naglulunsad ito ng bagong gawain (sa terminolohiya ng Kubernetes ito ay tinatawag na pod), sinusuri nito ang mga libreng port sa instance at itinalaga ang isa sa mga ito sa inilunsad na gawain. Regular ding sinusuri ng TG kung gumagana ang instance at ang API dito gamit ang health check, at kung makakita ito ng anumang problema, hihinto ito sa pagpapadala ng mga kahilingan doon.
EC2 Auto Scaling Groups + ECS Capacity Provider
Ang diagram sa itaas ay hindi nagpapakita ng serbisyo ng EC2 Auto Scaling Groups (ASG). Mula sa pangalan, mauunawaan mo na responsable ito sa pag-scale ng mga pagkakataon. Gayunpaman, hanggang kamakailan lamang, ang AWS ay walang built-in na kakayahan upang pamahalaan ang bilang ng mga tumatakbong makina mula sa ECS. Ginawang posible ng ECS na sukatin ang bilang ng mga gawain, halimbawa, sa pamamagitan ng paggamit ng CPU, RAM o bilang ng mga kahilingan. Ngunit kung ang mga gawain ay sumasakop sa lahat ng mga libreng pagkakataon, kung gayon ang mga bagong makina ay hindi awtomatikong nilikha.
Nagbago ito sa pagdating ng ECS Capacity Providers (ECS CP). Ngayon, ang bawat serbisyo sa ECS ay maaaring iugnay sa isang ASG, at kung ang mga gawain ay hindi akma sa mga tumatakbong pagkakataon, ang mga bago ay itataas (ngunit sa loob ng itinatag na mga limitasyon ng ASG). Gumagana rin ito sa kabaligtaran na direksyon, kung ang ECS CP ay nakakita ng mga idle na pagkakataon na walang mga gawain, pagkatapos ay ibibigay nito ang ASG command upang isara ang mga ito. Ang ECS CP ay may kakayahang tumukoy ng target na porsyento ng instance load, upang ang ilang partikular na bilang ng mga makina ay palaging libre para sa mabilis na pag-scale ng mga gawain; pag-uusapan ko ito sa ibang pagkakataon.
Mga Template ng Paglunsad ng EC2
Ang huling serbisyong tatalakayin ko bago magdetalye tungkol sa paglikha ng imprastraktura na ito ay ang EC2 Launch Templates. Pinapayagan ka nitong lumikha ng isang template ayon sa kung saan magsisimula ang lahat ng mga makina, upang hindi ito ulitin mula sa simula sa bawat oras. Dito maaari mong piliin ang uri ng makina na sisimulan, pangkat ng seguridad, imahe ng disk at maraming iba pang mga parameter. Maaari mo ring tukuyin ang data ng user na ia-upload sa lahat ng inilunsad na pagkakataon. Maaari kang magpatakbo ng mga script sa data ng user, halimbawa, maaari mong i-edit ang mga nilalaman ng isang file .
Ang isa sa pinakamahalagang parameter ng pagsasaayos para sa artikulong ito ay = totoo. Kung naka-enable ang parameter na ito, sa sandaling makatanggap ang ECS ng senyales na inaalis ang isang spot instance, ililipat nito ang lahat ng gawaing gumagana dito sa status ng Draining. Walang mga bagong gawain ang itatalaga sa pagkakataong ito; kung may mga gawaing gustong ilunsad dito ngayon, kakanselahin ang mga ito. Hindi na rin dumarating ang mga kahilingan mula sa balancer. Ang abiso ng pagtanggal ng instance ay darating 2 minuto bago ang aktwal na kaganapan. Samakatuwid, kung ang iyong serbisyo ay hindi nagsasagawa ng mga gawain nang mas mahaba kaysa sa 2 minuto at hindi nagse-save ng anuman sa disk, maaari kang gumamit ng mga spot instances nang hindi nawawala ang data.
Tungkol sa disk - AWS kamakailan Posibleng gamitin ang Elastic File System (EFS) kasama ang ECS; sa pamamaraang ito, kahit na ang disk ay hindi isang balakid, ngunit hindi namin ito sinubukan, dahil sa prinsipyo hindi namin kailangan ang disk upang maiimbak ang estado. Bilang default, pagkatapos matanggap ang SIGINT (ipinadala kapag ang isang gawain ay inilipat sa Draining status), ang lahat ng mga tumatakbong gawain ay hihinto pagkatapos ng 30 segundo, kahit na hindi pa sila nakumpleto; maaari mong baguhin ang oras na ito gamit ang parameter . Ang pangunahing bagay ay hindi itakda ito ng higit sa 2 minuto para sa mga spot machine.
Paglikha ng isang serbisyo
Magpatuloy tayo sa paglikha ng inilarawang serbisyo. Sa proseso, ilalarawan ko rin ang ilang mga kapaki-pakinabang na punto na hindi nabanggit sa itaas. Sa pangkalahatan, ito ay isang sunud-sunod na pagtuturo, ngunit hindi ko isasaalang-alang ang ilang napaka-pangunahing o, sa kabaligtaran, napaka-espesipikong mga kaso. Ang lahat ng mga aksyon ay ginagawa sa AWS visual console, ngunit maaaring kopyahin gamit ang CloudFormation o Terraform. Sa Adapty ginagamit namin ang Terraform.
Template ng Paglunsad ng EC2
Lumilikha ang serbisyong ito ng configuration ng mga machine na gagamitin. Ang mga template ay pinamamahalaan sa EC2 -> Instances -> Ilunsad ang mga template na seksyon.
Larawan ng makina ng Amazon (AMI) — tukuyin ang disk image kung saan ilulunsad ang lahat ng pagkakataon. Para sa ECS, sa karamihan ng mga kaso ito ay nagkakahalaga ng paggamit ng na-optimize na imahe mula sa Amazon. Ito ay regular na ina-update at naglalaman ng lahat ng kailangan para gumana ang ECS. Para malaman ang kasalukuyang image ID, pumunta sa page , piliin ang rehiyon na iyong ginagamit at kopyahin ang AMI ID para dito. Halimbawa, para sa us-east-1 na rehiyon, ang kasalukuyang ID sa oras ng pagsulat ay ami-00c7c1cf5bdc913ed. Dapat na maipasok ang ID na ito sa item na Tukuyin ang isang custom na halaga.
Uri ng instance — ipahiwatig ang uri ng instance. Piliin ang isa na pinakaangkop sa iyong gawain.
Key pares (login) — tukuyin ang isang sertipiko kung saan maaari kang kumonekta sa instance sa pamamagitan ng SSH, kung kinakailangan.
Mga setting ng network — tukuyin ang mga parameter ng network. Platform sa networking sa karamihan ng mga kaso dapat mayroong Virtual Private Cloud (VPC). Mga pangkat ng seguridad — mga pangkat ng seguridad para sa iyong mga pagkakataon. Dahil gagamit kami ng balancer sa harap ng mga pagkakataon, inirerekomenda kong tukuyin ang isang pangkat dito na nagbibigay-daan lamang sa mga papasok na koneksyon mula sa balancer. Ibig sabihin, magkakaroon ka ng 2 pangkat ng seguridad, isa para sa balancer, na nagbibigay-daan sa mga papasok na koneksyon mula sa kahit saan sa mga port 80 (http) at 443 (https), at ang pangalawa para sa mga makina, na nagpapahintulot sa mga papasok na koneksyon sa anumang mga port mula sa pangkat ng balancer . Ang mga papalabas na koneksyon sa parehong grupo ay dapat mabuksan gamit ang TCP protocol sa lahat ng port sa lahat ng address. Maaari mong limitahan ang mga port at address para sa mga papalabas na koneksyon, ngunit pagkatapos ay kailangan mong patuloy na subaybayan na hindi mo sinusubukang i-access ang isang bagay sa isang saradong port.
Imbakan (mga volume) — tukuyin ang mga parameter ng disk para sa mga makina. Ang laki ng disk ay hindi maaaring mas mababa kaysa sa tinukoy sa AMI; para sa ECS Optimized ito ay 30 GiB.
Mga advanced na detalye — tukuyin ang mga karagdagang parameter.
Opsyon sa pagbili — kung gusto nating bumili ng mga spot instances. Gusto namin, ngunit hindi namin lagyan ng check ang kahon na ito dito; iko-configure namin ito sa Auto Scaling Group, mayroong higit pang mga opsyon doon.
IAM instance profile — ipahiwatig ang tungkulin kung saan ilulunsad ang mga pagkakataon. Upang tumakbo ang mga instance sa ECS, kailangan nila ng mga pahintulot, na karaniwang makikita sa tungkulin ecsInstanceRole. Sa ilang mga kaso maaari itong malikha, kung hindi, pagkatapos ay dito kung paano ito gagawin. Pagkatapos ng paglikha, ipinapahiwatig namin ito sa template.
Susunod, mayroong maraming mga parameter, karaniwang maaari mong iwanan ang mga default na halaga sa lahat ng dako, ngunit ang bawat isa sa kanila ay may malinaw na paglalarawan. Palagi kong pinapagana ang EBS-optimized na instance at T2/T3 Unlimited na mga opsyon kung ginamit mga pagkakataon.
Data ng gumagamit — ipahiwatig ang data ng gumagamit. I-edit namin ang file /etc/ecs/ecs.config, na naglalaman ng configuration ng ahente ng ECS.
Isang halimbawa ng maaaring hitsura ng data ng user:
#!/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 — ang parameter ay nagpapahiwatig na ang instance ay kabilang sa isang cluster na may ibinigay na pangalan, iyon ay, ang cluster na ito ay makakapaglagay ng mga gawain nito sa server na ito. Hindi pa kami nakakagawa ng cluster, ngunit gagamitin namin ang pangalang ito kapag nililikha ito.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — ang parameter ay tumutukoy na kapag ang isang senyas ay natanggap upang i-off ang isang spot instance, ang lahat ng mga gawain dito ay dapat ilipat sa Draining status.
ECS_CONTAINER_STOP_TIMEOUT=1m - ang parameter ay tumutukoy na pagkatapos makatanggap ng isang SIGINT signal, lahat ng mga gawain ay may 1 minuto bago patayin.
ECS_ENGINE_AUTH_TYPE=docker — ang parameter ay nagpapahiwatig na ang Docker scheme ay ginagamit bilang mekanismo ng awtorisasyon
ECS_ENGINE_AUTH_DATA=... — mga parameter ng koneksyon sa pribadong container registry, kung saan nakaimbak ang iyong mga larawan ng Docker. Kung ito ay pampubliko, hindi mo kailangang tukuyin ang anuman.
Para sa mga layunin ng artikulong ito, gagamit ako ng pampublikong imahe mula sa Docker Hub, kaya tukuyin ang mga parameter ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA hindi na kailangan.
Magandang malaman: Inirerekomenda na regular na i-update ang AMI, dahil ang mga bagong bersyon ay nag-a-update ng mga bersyon ng Docker, Linux, ECS agent, atbp. Upang hindi makalimutan ang tungkol dito, maaari mong tungkol sa pagpapalabas ng mga bagong bersyon. Maaari kang makatanggap ng mga notification sa pamamagitan ng email at manu-manong mag-update, o maaari kang magsulat ng Lambda function na awtomatikong gagawa ng bagong bersyon ng Launch Template na may na-update na AMI.
EC2 Auto Scaling Group
Ang Auto Scaling Group ay responsable para sa paglulunsad at pag-scale ng mga pagkakataon. Ang mga pangkat ay pinamamahalaan sa seksyong EC2 -> Auto Scaling -> Auto Scaling Groups.
Ilunsad ang template — piliin ang template na ginawa sa nakaraang hakbang. Iniwan namin ang default na bersyon.
Mga opsyon sa pagbili at mga uri ng instance — tukuyin ang mga uri ng mga pagkakataon para sa cluster. Ang pagsunod sa template ng paglulunsad ay gumagamit ng uri ng halimbawa mula sa Template ng Paglulunsad. Ang pagsamahin ang mga opsyon sa pagbili at mga uri ng instance ay nagbibigay-daan sa iyong flexible na i-configure ang mga uri ng instance. Gagamitin natin.
Opsyonal na On-Demand na base — ang bilang ng mga regular, non-spot instance na palaging gagana.
On-Demand na porsyento sa itaas ng base — percentage ratio ng regular at spot instances, 50-50 ang ipapamahagi nang pantay, 20-80 para sa bawat regular na instance 4 na spot ang itataas. Para sa mga layunin ng halimbawang ito, ipahiwatig ko ang 50-50, ngunit sa katotohanan ay madalas naming ginagawa ang 20-80, sa ilang mga kaso 0-100.
Mga uri ng pagkakataon — dito maaari mong tukuyin ang mga karagdagang uri ng mga pagkakataon na gagamitin sa cluster. We never used it kasi hindi ko talaga maintindihan yung meaning ng story. Marahil ito ay dahil sa mga limitasyon sa mga partikular na uri ng mga pagkakataon, ngunit madali silang madagdagan sa pamamagitan ng suporta. Kung alam mo ang application, matutuwa akong basahin ito sa mga komento)
network — mga setting ng network, piliin ang VPC at mga subnet para sa mga makina, sa karamihan ng mga kaso dapat mong piliin ang lahat ng magagamit na mga subnet.
Mag-load balancing - mga setting ng balancer, ngunit gagawin namin ito nang hiwalay, hindi kami hahawak ng anuman dito. Mga pagsusuri sa kalusugan ay i-configure din sa ibang pagkakataon.
Laki ng pangkat — ipinapahiwatig namin ang mga limitasyon sa bilang ng mga makina sa cluster at ang nais na bilang ng mga makina sa simula. Ang bilang ng mga machine sa cluster ay hindi kailanman magiging mas mababa sa minimum na tinukoy at higit sa maximum, kahit na ang pag-scale ay dapat mangyari ayon sa mga sukatan.
Mga patakaran sa pag-scale — mga parameter ng scaling, ngunit susukatin namin batay sa tumatakbong mga gawain sa ECS, kaya i-configure namin ang pag-scale sa ibang pagkakataon.
Instance scale-in na proteksyon — proteksyon ng mga instance mula sa pagtanggal kapag pinababa. Pinagana namin ito upang hindi matanggal ng ASG ang makina na may mga tumatakbong gawain. Idi-disable ng ECS Capacity Provider ang proteksyon para sa mga pagkakataong walang mga gawain.
Magdagdag ng mga tag — maaari mong tukuyin ang mga tag para sa mga instance (para dito, dapat na lagyan ng check ang Tag new instance na checkbox). Inirerekomenda kong tukuyin ang Name tag, pagkatapos ay magkakaroon ng parehong pangalan ang lahat ng mga pagkakataon na inilunsad sa loob ng grupo, at maginhawang tingnan ang mga ito sa console.
Pagkatapos gawin ang grupo, buksan ito at pumunta sa seksyong Advanced na mga configuration. Bakit hindi lahat ng opsyon ay makikita sa console sa yugto ng paglikha.
Mga patakaran sa pagwawakas — mga panuntunan na isinasaalang-alang kapag nagtatanggal ng mga pagkakataon. Inilapat ang mga ito sa pagkakasunud-sunod. Karaniwan naming ginagamit ang mga nasa larawan sa ibaba. Una, ang mga instance na may pinakalumang Template ng Paglulunsad ay tatanggalin (halimbawa, kung na-update namin ang AMI, gumawa kami ng bagong bersyon, ngunit lahat ng pagkakataon ay nakalipat dito). Pagkatapos ay pipiliin ang mga instance na pinakamalapit sa susunod na oras ng pagsingil. At pagkatapos ay pipiliin ang mga pinakaluma batay sa petsa ng paglulunsad.
Magandang malaman: upang i-update ang lahat ng mga makina sa isang kumpol, madaling gamitin . Kung isasama mo ito sa Lambda function mula sa nakaraang hakbang, magkakaroon ka ng ganap na automated na instance update system. Bago i-update ang lahat ng machine, dapat mong i-disable ang instance scale-in na proteksyon para sa lahat ng pagkakataon sa grupo. Hindi configuration sa grupo, ngunit proteksyon mula sa mga machine mismo, ginagawa ito sa tab na Pamamahala ng Instance.
Application Load Balancer at EC2 Target Group
Ang balancer ay ginawa sa seksyong EC2 → Load Balancing → Load Balancers. Gagamitin namin ang Application Load Balancer; isang paghahambing ng iba't ibang uri ng mga balancer ay mababasa sa .
Mga tagapakinig - makatuwirang gumawa ng mga port 80 at 443 at mag-redirect mula 80 hanggang 443 gamit ang mga panuntunan sa balanse sa ibang pagkakataon.
Mga Zona ng Pagkakaroon — sa karamihan ng mga kaso, pumipili kami ng mga accessibility zone para sa lahat.
I-configure ang Mga Setting ng Seguridad — ang SSL certificate para sa balancer ay ipinahiwatig dito, ang pinaka-maginhawang opsyon ay sa ACM. Tungkol sa mga pagkakaiba Patakaran sa Seguridad mababasa sa , maaari mo itong iwanan na pinili bilang default ELBSecurityPolicy-2016-08. Pagkatapos gumawa ng balancer, makikita mo ito Pangalan ng DNS, na kailangan mong i-configure ang CNAME para sa iyong domain. Halimbawa, ganito ang hitsura nito sa Cloudflare.
Grupo ng Seguridad — lumikha o pumili ng pangkat ng seguridad para sa balancer, sumulat ako ng higit pa tungkol dito sa itaas lamang sa EC2 Launch Template → Network settings section.
Tinatarget na grupo — lumikha kami ng isang pangkat na responsable para sa pagruruta ng mga kahilingan mula sa balancer patungo sa mga makina at suriin ang kanilang kakayahang magamit upang palitan ang mga ito kung sakaling magkaroon ng mga problema. Uri ng target dapat na Instance, Protokol и Port anuman, kung gumagamit ka ng HTTPS para sa komunikasyon sa pagitan ng balancer at mga instance, kailangan mong mag-upload ng certificate sa kanila. Para sa mga layunin ng halimbawang ito, hindi namin gagawin ito, iiwan lang namin ang port 80.
Mga pagsusuri sa kalusugan — mga parameter para sa pagsuri sa functionality ng serbisyo. Sa isang tunay na serbisyo, ito ay dapat na isang hiwalay na kahilingan na nagpapatupad ng mahahalagang bahagi ng lohika ng negosyo; para sa mga layunin ng halimbawang ito, iiwan ko ang mga default na setting. Susunod, maaari mong piliin ang agwat ng kahilingan, timeout, mga code ng tagumpay, atbp. Sa aming halimbawa, ipahiwatig namin ang mga code ng Tagumpay 200-399, dahil ang imahe ng Docker na gagamitin ay nagbabalik ng 304 code.
Magrehistro ng mga Target — dito pinipili ang mga sasakyan para sa grupo, ngunit sa aming kaso ito ay gagawin ng ECS, kaya laktawan na lang namin ang hakbang na ito.
Magandang malaman: sa antas ng balanse maaari mong paganahin ang mga log na ise-save sa S3 sa isang tiyak . Mula doon maaari silang i-export sa mga serbisyo ng third-party para sa analytics, o maaari kang gumawa ng mga query sa SQL nang direkta sa data sa S3 gamit ang . Ito ay maginhawa at gumagana nang walang anumang karagdagang code. Inirerekomenda ko rin ang pag-set up ng pag-aalis ng mga log mula sa S3 bucket pagkatapos ng tinukoy na tagal ng panahon.
Kahulugan ng Gawain ng ECS
Sa mga nakaraang hakbang, ginawa namin ang lahat ng nauugnay sa imprastraktura ng serbisyo; ngayon ay nagpapatuloy kami sa paglalarawan ng mga lalagyan na aming ilulunsad. Ginagawa ito sa seksyong ECS → Mga Kahulugan ng Gawain.
Pagkatugma sa uri ng paglunsad - piliin ang EC2.
Tungkulin ng IAM sa pagpapatupad ng gawain - pumili ecsTaskExecutionRole. Gamit ito, isinulat ang mga log, ibinibigay ang access sa mga lihim na variable, atbp.
Sa seksyong Mga Kahulugan ng Container, i-click ang Magdagdag ng Container.
Imahen — link sa larawan gamit ang project code; para sa halimbawang ito ay gagamit ako ng pampublikong imahe mula sa Docker Hub .
Mga Limitasyon sa Memorya — mga limitasyon ng memorya para sa lalagyan. Matigas na Limitasyon — mahirap na limitasyon, kung ang lalagyan ay lumampas sa tinukoy na halaga, ang docker kill command ay isasagawa, ang lalagyan ay mamamatay kaagad. Malimit na Limitasyon — malambot na limitasyon, ang lalagyan ay maaaring lumampas sa tinukoy na halaga, ngunit ang parameter na ito ay isasaalang-alang kapag naglalagay ng mga gawain sa mga makina. Halimbawa, kung ang isang makina ay may 4 GiB ng RAM, at ang malambot na limitasyon ng isang lalagyan ay 2048 MiB, ang makina na ito ay maaaring magkaroon ng maximum na 2 tumatakbong gawain sa container na ito. Sa katotohanan, ang 4 GiB ng RAM ay bahagyang mas mababa sa 4096 MiB, maaari itong tingnan sa tab na ECS Instances sa cluster. Ang malambot na limitasyon ay hindi maaaring mas malaki kaysa sa mahirap na limitasyon. Mahalagang maunawaan na kung mayroong ilang mga lalagyan sa isang gawain, kung gayon ang kanilang mga limitasyon ay nabubuod.
Mga pagmamapa ng port - sa Host port Ipinapahiwatig namin ang 0, nangangahulugan ito na ang port ay dynamic na itatalaga at susubaybayan ng Target Group. Port ng Container — ang port kung saan tumatakbo ang iyong application ay madalas na tinutukoy sa execution command, o nakatalaga sa iyong application code, Dockerfile, atbp. Para sa aming halimbawa gagamitin namin ang 3000 dahil nakalista ito sa larawang ginagamit.
Pagsusuri sa kalusugan — mga parameter ng pagsusuri sa kalusugan ng container, hindi dapat ipagkamali sa isa na na-configure sa Target na Grupo.
kapaligiran - mga setting ng kapaligiran. Mga yunit ng CPU - katulad ng mga limitasyon ng Memory, tungkol lamang sa processor. Ang bawat core ng processor ay 1024 na unit, kaya kung ang server ay may dual-core na processor at ang container ay nakatakda sa 512, 4 na gawain sa container na ito ang maaaring ilunsad sa isang server. Ang mga yunit ng CPU ay palaging tumutugma sa bilang ng mga core; hindi maaaring mas kaunti sa kanila, tulad ng kaso sa memorya.
Utos — isang utos upang simulan ang isang serbisyo sa loob ng isang lalagyan, ang lahat ng mga parameter ay tinukoy na pinaghihiwalay ng mga kuwit. Ito ay maaaring gunicorn, npm, atbp. Kung hindi tinukoy, ang halaga ng direktiba ng CMD mula sa Dockerfile ay gagamitin. Ipinapahiwatig namin npm,start.
Mga variable ng kapaligiran — mga variable ng kapaligiran ng lalagyan. Ito ay maaaring alinman sa simpleng data ng text o mga lihim na variable mula sa o .
Imbakan at Pag-log — dito kami magse-set up ng pag-log in sa CloudWatch Logs (isang serbisyo para sa mga log mula sa AWS). Upang gawin ito, paganahin lamang ang checkbox ng Auto-configure ang CloudWatch Logs. Pagkatapos gawin ang Task Definition, isang pangkat ng mga log ang awtomatikong gagawin sa CloudWatch. Bilang default, ang mga log ay naka-imbak dito nang walang katiyakan; Inirerekomenda kong baguhin ang panahon ng Pagpapanatili mula sa Never Expire sa kinakailangang panahon. Ginagawa ito sa mga grupo ng CloudWatch Log, kailangan mong mag-click sa kasalukuyang panahon at pumili ng bago.
ECS Cluster at ECS Capacity Provider
Pumunta sa seksyong ECS → Clusters para gumawa ng cluster. Pinipili namin ang EC2 Linux + Networking bilang template.
Pangalan ng cluster - napakahalaga, ginagawa namin dito ang parehong pangalan tulad ng tinukoy sa parameter ng Template ng Paglunsad ECS_CLUSTER, sa kaso natin - DemoApiClusterProd. Lagyan ng check ang checkbox na Gumawa ng walang laman na cluster. Opsyonal, maaari mong paganahin ang Container Insights upang tingnan ang mga sukatan para sa mga serbisyo sa CloudWatch. Kung ginawa mo nang tama ang lahat, pagkatapos ay sa seksyong ECS Instances makikita mo ang mga machine na ginawa sa pangkat ng Auto Scaling.
Pumunta sa tab Mga Tagabigay ng Kapasidad at lumikha ng bago. Hayaan mong ipaalala ko sa iyo na kailangan mong kontrolin ang paglikha at pagsara ng mga makina depende sa bilang ng mga tumatakbong gawain sa ECS. Mahalagang tandaan na ang isang provider ay maaari lamang italaga sa isang grupo.
Pangkat ng Auto Scaling — piliin ang dating ginawang grupo.
Pinamamahalaang pag-scale — paganahin ito upang ma-scale ng provider ang serbisyo.
Target na kapasidad % — ilang porsyento ng mga makina na puno ng mga gawain ang kailangan natin. Kung tinukoy mo ang 100%, ang lahat ng mga makina ay palaging magiging abala sa pagpapatakbo ng mga gawain. Kung tinukoy mo ang 50%, kung gayon ang kalahati ng mga kotse ay palaging magiging libre. Sa kasong ito, kung mayroong isang matalim na pagtalon sa karga, ang mga bagong taxi ay agad na makakarating sa mga libreng sasakyan, nang hindi na kailangang maghintay para sa mga pagkakataon na mai-deploy.
Proteksyon ng pinamamahalaang pagwawakas — paganahin, pinapayagan ng parameter na ito ang provider na alisin ang proteksyon ng mga pagkakataon mula sa pagtanggal. Nangyayari ito kapag walang aktibong gawain sa makina at pinapayagan ang Target na kapasidad%.
Serbisyo ng ECS at setup ng scaling
Huling hakbang :) Upang lumikha ng isang serbisyo, kailangan mong pumunta sa dating ginawang cluster sa tab na Mga Serbisyo.
Uri ng paglulunsad — kailangan mong i-click ang Switch to capacity provider na diskarte at piliin ang mga dating ginawang provider.
Kahulugan ng Gawain — piliin ang naunang ginawang Task Definition at ang rebisyon nito.
Pangalan ng serbisyo — upang maiwasan ang pagkalito, palagi naming ipinapahiwatig ang Kahulugan ng Gawain.
Uri ng serbisyo - laging Replica.
Bilang ng mga gawain — ang nais na bilang ng mga aktibong gawain sa serbisyo. Ang parameter na ito ay kinokontrol sa pamamagitan ng pag-scale, ngunit dapat pa ring tukuyin.
Pinakamababang malusog na porsyento и Pinakamataas na porsyento — tukuyin ang pag-uugali ng mga gawain sa panahon ng pag-deploy. Ang mga default na halaga ay 100 at 200, na nagpapahiwatig na sa oras ng pag-deploy ang bilang ng mga gawain ay tataas nang maraming beses, at pagkatapos ay bumalik sa nais na halaga. Kung mayroon kang 1 gawain na tumatakbo, min=0, at max=100, pagkatapos ay sa panahon ng deployment ito ay papatayin, at pagkatapos nito ay itataas ang bago, iyon ay, ito ay magiging downtime. Kung tumatakbo ang 1 gawain, min=50, max=150, hindi mangyayari ang deployment, dahil hindi maaaring hatiin sa kalahati o dagdagan ng isa at kalahating beses ang 1 gawain.
Uri ng deployment — umalis sa Rolling update.
Mga Template ng Placement — mga panuntunan para sa paglalagay ng mga gawain sa mga makina. Ang default ay AZ Balanced Spread - nangangahulugan ito na ang bawat bagong gawain ay ilalagay sa isang bagong instance hanggang sa tumaas ang mga machine sa lahat ng availability zone. Karaniwan naming ginagawa ang BinPack - CPU at Spread - AZ; sa patakarang ito, ang mga gawain ay inilalagay nang mas makapal hangga't maaari sa isang makina bawat CPU. Kung kinakailangan upang lumikha ng isang bagong makina, ito ay nilikha sa isang bagong availability zone.
Uri ng load balancer — piliin ang Application Load Balancer.
Tungkulin ng IAM sa serbisyo - pumili ecsServiceRole.
Pangalan ng load balancer — piliin ang dating ginawang balancer.
Palugit na panahon ng pagsusuri sa kalusugan — i-pause bago magsagawa ng mga pagsusuri sa kalusugan pagkatapos maglunsad ng bagong gawain, karaniwan naming itinatakda ito sa 60 segundo.
Lalagyan para magkarga ng balanse — sa item na Pangalan ng Target na grupo, piliin ang dating ginawang grupo, at lahat ay awtomatikong mapupunan.
Serbisyo Auto Scaling — mga parameter ng pag-scale ng serbisyo. Piliin ang I-configure ang Auto Scaling ng Serbisyo upang isaayos ang nais na bilang ng iyong serbisyo. Itinakda namin ang minimum at maximum na bilang ng mga gawain kapag nag-scale.
Tungkulin ng IAM para sa Service Auto Scaling - pumili AWSServiceRoleForApplicationAutoScaling_ECSService.
Mga patakaran sa awtomatikong pag-scale ng gawain — mga panuntunan para sa pag-scale. Mayroong 2 uri:
- Target na pagsubaybay — pagsubaybay sa mga sukatan ng target (paggamit ng CPU/RAM o bilang ng mga kahilingan para sa bawat gawain). Halimbawa, gusto naming maging 85% ang average na load ng processor, kapag tumaas ito, magdaragdag ng mga bagong gawain hanggang sa maabot nito ang target na halaga. Kung mas mababa ang load, aalisin ang mga gawain, sa kabaligtaran, maliban kung pinagana ang proteksyon laban sa pag-scale pababa (Huwag paganahin ang scale-in).
- Hakbang scaling - reaksyon sa isang arbitrary na kaganapan. Dito maaari mong i-configure ang isang reaksyon sa anumang kaganapan (CloudWatch Alarm), kapag nangyari ito, maaari mong idagdag o alisin ang tinukoy na bilang ng mga gawain, o tukuyin ang eksaktong bilang ng mga gawain.
Ang isang serbisyo ay maaaring magkaroon ng ilang mga panuntunan sa pag-scale, maaari itong maging kapaki-pakinabang, ang pangunahing bagay ay upang matiyak na hindi sila sumasalungat sa bawat isa.
Konklusyon
Kung sinunod mo ang mga tagubilin at ginamit mo ang parehong larawan ng Docker, ang iyong serbisyo ay dapat magbalik ng isang pahinang tulad nito.
- Gumawa kami ng template ayon sa kung saan inilunsad ang lahat ng makina sa serbisyo. Natutunan din namin kung paano mag-update ng mga machine kapag nagbago ang template.
- Na-configure namin ang pagproseso ng spot instance stop signal, kaya sa loob ng isang minuto matapos itong matanggap, ang lahat ng tumatakbong gawain ay aalisin sa makina, kaya walang mawawala o maabala.
- Itinaas namin ang balancer para pantay-pantay na ipamahagi ang load sa mga makina.
- Gumawa kami ng serbisyo na tumatakbo sa mga lugar na instance, na binabawasan ang mga gastos sa makina nang humigit-kumulang 3 beses.
- Na-configure namin ang autoscaling sa parehong direksyon upang mahawakan ang mas maraming workload nang hindi nagkakaroon ng mga gastos sa downtime.
- Gumagamit kami ng Capacity Provider upang ang application ay namamahala sa imprastraktura (mga makina) at hindi sa kabaligtaran.
- Ang galing namin.
Kung mayroon kang mga predictable spike sa pag-load, halimbawa ay nag-a-advertise ka sa isang malaking email campaign, maaari kang mag-set up ng scaling sa pamamagitan ng .
Maaari mo ring sukatin batay sa data mula sa iba't ibang bahagi ng iyong system. Halimbawa, mayroon kaming functionality mga gumagamit ng mobile application. Minsan may ipinapadalang kampanya sa 1M+ tao. Pagkatapos ng naturang pamamahagi, palaging may malaking pagtaas sa mga kahilingan sa API, dahil maraming user ang nag-log in sa application nang sabay-sabay. Kaya't kung nakita namin na mayroong higit pang mga karaniwang tagapagpahiwatig sa pila para sa pagpapadala ng mga pampromosyong push notification, maaari kaming agad na maglunsad ng ilang karagdagang mga makina at gawain upang maging handa para sa pagkarga.
Matutuwa ako kung sasabihin mo sa akin sa mga komento ang mga kagiliw-giliw na kaso ng paggamit ng mga spot instances at ECS o isang bagay tungkol sa pag-scale.
Sa lalong madaling panahon magkakaroon ng mga artikulo tungkol sa kung paano namin pinoproseso ang libu-libong analytical na kaganapan sa bawat segundo sa isang nakararami na walang server na stack (na may pera) at kung paano gumagana ang deployment ng mga serbisyo gamit ang GitLab CI at Terraform Cloud.
Mag-subscribe sa amin, ito ay magiging kawili-wili!
Ang mga rehistradong user lamang ang maaaring lumahok sa survey. , pakiusap
Gumagamit ka ba ng mga spot instances sa produksyon?
-
22,2%Oo6
-
66,7%No18
-
11,1%Nalaman ko ang tungkol sa mga ito mula sa isang artikulo at plano kong gamitin ang mga ito3
27 user ang bumoto. 5 na user ang umiwas.
Pinagmulan: www.habr.com