Kaixo guztioi! Nire izena Kirill da, Adapty-ko zuzendaria naiz. Gure arkitektura gehiena AWS-n dago, eta gaur zerbitzariaren kostuak 3 aldiz murriztu genituen ekoizpen-ingurunean instantzia puntualak erabiliz, eta haien eskalatze automatikoa nola konfiguratu ere azalduko dut. Lehenik eta behin funtzionamenduaren ikuspegi orokorra izango da, eta ondoren hasteko argibide zehatzak.
Zer dira Spot Instantziak?
instantziak une honetan inaktibo dauden beste AWS erabiltzaile batzuen zerbitzariak dira, eta deskontu handiarekin saltzen dituzte (Amazonek % 90 arte idazten du, gure esperientzian ~ 3x, eskualdearen, AZaren eta instantzia motaren arabera aldatzen da). Ohikoekin duten desberdintasun nagusia edozein unetan itzal daitezkeela da. Horregatik, denbora luzez uste genuen normala zela ingurune birjinetarako erabiltzea, edo zerbait kalkulatzeko zereginetarako, tarteko emaitzak S3-n edo datu-basean gordeta, baina ez salmentarako. Badaude hirugarrenen soluzioak ekoizpenean spotak erabiltzeko aukera ematen dutenak, baina gure kasurako makulu asko daude, beraz, ez ditugu inplementatu. Artikuluan deskribatutako ikuspegiak AWS funtzionalitate estandarraren barruan funtzionatzen du guztiz, script, koroa eta abar gehigarririk gabe.
Jarraian, tokiko instantzien prezioen historia erakusten duten pantaila-argazki batzuk daude.
m5.handia eu-west-1 (Irlanda) eskualdean. Prezioa egonkorra izan da 3 hilabetez, eta gaur egun 2.9 aldiz aurrezten da.
m5.handia us-east-1 eskualdean (N. Virginia). Prezioa etengabe aldatzen ari da 3 hilabetetan zehar, une honetan 2.3x-tik 2.8x-ra aurrezten da erabilgarritasun-eremuaren arabera.
t3.txikia us-east-1 eskualdean (N. Virginia). Prezioa egonkorra izan da 3 hilabetez, eta gaur egun 3.4 aldiz aurrezten da.
Zerbitzuen arkitektura
Artikulu honetan hitz egingo dugun zerbitzuaren oinarrizko arkitektura beheko diagraman agertzen da.
Aplikazioaren karga-balantzatzailea → EC2 xede-taldea → Elastic Container Zerbitzua
Application Load Balancer (ALB) orekatzaile gisa erabiltzen da, eta eskaerak EC2 Target Group (TG) bidaltzen ditu. TG-k ALBentzako instantzietan portuak irekitzeaz eta Elastic Container Service (ECS) edukiontzien portuetara konektatzeaz arduratzen da. ECS Kubernetes-en analogoa da AWS-n, Docker edukiontziak kudeatzen dituena.
Instantzia batek hainbat edukiontzi izan ditzake portu berdinekin, beraz, ezin ditugu finkoki ezarri. ECS-k ataza berri bat abiarazten ari dela esaten dio TGri (Kubernetes-en terminologian pod deitzen zaio), instantzian portu libreak dauden egiaztatzen du eta horietako bat esleitzen dio abiarazitako atazari. TGk aldizka egiaztatzen du instantzia eta APIa horretan lanean ari diren ala ez osasun egiaztapena erabiliz, eta arazorik ikusten badu, eskaerak bidaltzeari uzten dio.
EC2 Auto Scaling Groups + ECS Capacity Providers
Goiko diagramak ez du EC2 Auto Scaling Groups (ASG) zerbitzua erakusten. Izenetik uler dezakezu instantzien eskalatzeaz arduratzen dela. Hala ere, duela gutxi arte, AWS-k ez zuen ECStik martxan dauden makina kopurua kudeatzeko gaitasun integraturik. ECS-k ataza kopurua eskalatzea ahalbidetu zuen, adibidez, CPU erabileraren, RAMaren edo eskaera kopuruaren arabera. Baina zereginek doako instantzia guztiak hartzen bazituzten, orduan makina berriak ez ziren automatikoki sortuko.
Hau aldatu egin da ECS Capacity Providers (ECS CP) sorrerarekin. Orain ECSko zerbitzu bakoitza ASG batekin lotu daiteke, eta zereginak martxan dauden instantzietan sartzen ez badira, berriak sortuko dira (baina ezarritako ASG mugen barruan). Horrek ere kontrako norabidean funtzionatzen du, ECS CP-k zereginik gabeko instantziarik gabe ikusten baditu, orduan ASG komandoa emango du itzaltzeko. ECS CP-k instantzia-kargaren helburu-portzentaje bat zehazteko gaitasuna du, makina kopuru jakin bat beti libre egon dadin zereginak azkar eskalatzeko; pixka bat geroago hitz egingo dut horri buruz.
EC2 abiarazteko txantiloiak
Azpiegitura hau sortzeari buruz xehetasunetan sartu aurretik hitz egingo dudan azken zerbitzua EC2 Launch Templates da. Makina guztiak martxan jarriko diren txantiloi bat sortzeko aukera ematen du, aldi bakoitzean hutsetik errepika ez dadin. Hemen abiarazteko makina mota, segurtasun taldea, diskoaren irudia eta beste hainbat parametro hauta ditzakezu. Abian jarritako instantzia guztietan kargatuko diren erabiltzaile-datuak ere zehaztu ditzakezu. Erabiltzaileen datuetan scriptak exekutatu ditzakezu, adibidez, fitxategi baten edukia edita dezakezu .
Artikulu honen konfigurazio-parametro garrantzitsuenetako bat da = egia. Parametro hau gaituta badago, ECS-k lekuko instantzia bat kentzen ari den seinalea jasotzen duen bezain laster, bertan lan egiten duten zeregin guztiak Draining egoerara transferitzen ditu. Instantzia honi ez zaio zeregin berririk esleituko; oraintxe bertan zabaldu nahi diren zereginak baldin badaude, bertan behera geratuko dira. Balantzatzailearen eskaerak ere etortzeari uzten diote. Instantzia ezabatzearen jakinarazpena benetako gertaera baino 2 minutu lehenago dator. Hori dela eta, zure zerbitzuak 2 minutu baino gehiagoko zereginak egiten ez baditu eta ez badu ezer gordetzen diskoan, orduan lekuko instantziak erabil ditzakezu datuak galdu gabe.
Diskoari dagokionez - AWS duela gutxi ECSrekin batera Elastic File System (EFS) erabiltzea posible da; eskema honekin, diskoa ere ez da oztopoa, baina ez dugu horretan saiatu, printzipioz ez baitugu diskorik behar egoera gordetzeko. Lehenespenez, SIGINT jaso ondoren (zeregin bat Draining egoerara pasatzen denean bidalitakoa), exekutatzen ari diren zeregin guztiak 30 segundoren buruan geldituko dira, oraindik amaitu ez badira ere; denbora hau alda dezakezu parametroa erabiliz. . Garrantzitsua da spot-makinetarako 2 minutu baino gehiago ez ezartzea.
Zerbitzu bat sortzea
Goazen deskribatutako zerbitzua sortzera. Prozesuan, gainera, goian aipatu ez ziren hainbat puntu erabilgarria deskribatuko ditut. Oro har, urratsez urratseko instrukzioa da, baina ez ditut kasu oso oinarrizkoak edo, aitzitik, oso zehatzak kontuan hartuko. Ekintza guztiak AWS ikus-kontsolan egiten dira, baina programatikoki erreproduzi daitezke CloudFormation edo Terraform erabiliz. Adapty-n Terraform erabiltzen dugu.
EC2 abiarazteko txantiloia
Zerbitzu honek erabiliko diren makinen konfigurazioa sortzen du. Txantiloiak EC2 -> Instantziak -> Abiarazi txantiloiak atalean kudeatzen dira.
Amazon makinaren irudia (AMI) — zehaztu instantzia guztiak abiaraziko dituen diskoaren irudia. ECSrentzat, kasu gehienetan, merezi du Amazon-en irudi optimizatua erabiltzea. Aldian-aldian eguneratzen da eta ECS-k funtziona dezan beharrezko guztia dauka. Uneko irudiaren IDa ezagutzeko, joan orrialdera , hautatu erabiltzen ari zaren eskualdea eta kopiatu horren AMI IDa. Adibidez, us-east-1 eskualderako, idazteko unean dagoen IDa da ami-00c7c1cf5bdc913ed. ID hau Zehaztu balio pertsonalizatua elementuan txertatu behar da.
Instantzia mota — adierazi instantzia mota. Aukeratu zure zereginari ondoen egokitzen zaiona.
Gako bikotea (saioa) — zehaztu SSH bidez instantziara konekta zaitezkeen ziurtagiri bat, beharrezkoa bada.
Sareko ezarpenak — zehaztu sarearen parametroak. Sareko plataforma kasu gehienetan Hodei Pribatu Birtual bat (VPC) egon beharko litzateke. Segurtasun taldeak — zure instantzietarako segurtasun taldeak. Instantziaren aurrean orekatzailea erabiliko dugunez, orekatzailetik soilik sarrerako konexioak ahalbidetzen dituen talde bat zehaztea gomendatzen dut hemen. Hau da, 2 segurtasun talde izango dituzu, bata orekatzailearentzat, 80 (http) eta 443 (https) portuetan edozein lekutatik sarrerako konexioak ahalbidetzen dituena, eta bigarrena makinentzat, sarrerako konexioak aukera ematen dituena orekatzaile taldeko edozein portutan. . Bi taldeetako irteerako konexioak TCP protokoloa erabiliz ireki behar dira helbide guztietarako ataka guztietara. Portuak eta helbideak muga ditzakezu irteerako konexioetarako, baina gero etengabe kontrolatu behar duzu ez zarela ataka itxi batean zerbait sartzen saiatzen.
Biltegiratzea (bolumenak) — zehaztu makinen disko-parametroak. Diskoaren tamaina ezin da izan AMIan zehaztutakoa baino txikiagoa; ECS Optimized-erako 30 GiB da.
Xehetasun aurreratuak — parametro osagarriak zehaztu.
Erosteko aukera — Leku-instantziak erosi nahi ditugun ala ez. Nahi dugu, baina hemen ez dugu lauki hau markatuko; Auto Scaling Taldean konfiguratuko dugu, aukera gehiago daude bertan.
IAM instantzia profila — Adierazi zein funtziorekin jarriko diren martxan instantziak. Instantziak ECS-en exekutatzeko, baimenak behar dituzte, normalean rolean aurkitzen direnak ecsInstanceRole. Zenbait kasutan sortu daiteke, ez bada, hemen hau nola egin. Sortu ondoren, txantiloian adierazten dugu.
Ondoren, parametro asko daude, funtsean, balio lehenetsiak edonon utzi ditzakezu, baina horietako bakoitzak deskribapen argia du. EBS optimizatutako instantzia eta T2/T3 Unlimited aukerak erabiltzen baditut gaitzen ditut beti kasuak.
Erabiltzailearen datuak — adierazi erabiltzailearen datuak. Fitxategia editatuko dugu /etc/ecs/ecs.config, ECS agentearen konfigurazioa dauka.
Erabiltzaileen datuak nolakoak izan daitezkeen adibide bat:
#!/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 — parametroak adierazten du instantzia izena duen kluster batekoa dela, hau da, kluster honek zerbitzari honetan jarri ahal izango ditu bere zereginak. Oraindik ez dugu klusterrik sortu, baina sortzerakoan izen hori erabiliko dugu.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — Parametroak zehazten du puntu-instantzia bat desaktibatzeko seinalea jasotzen denean, bertan dauden zeregin guztiak Draining egoerara pasatu behar direla.
ECS_CONTAINER_STOP_TIMEOUT=1m - parametroak zehazten du SIGINT seinalea jaso ondoren, zeregin guztiek minutu 1 behar dutela hil aurretik.
ECS_ENGINE_AUTH_TYPE=docker — parametroak Docker eskema baimen-mekanismo gisa erabiltzen dela adierazten du
ECS_ENGINE_AUTH_DATA=... — edukiontzi pribatuaren erregistrorako konexio-parametroak, non zure Docker irudiak gordetzen diren. Publikoa bada, ez duzu ezer zehaztu beharrik.
Artikulu honen helburuetarako, Docker Hub-eko irudi publiko bat erabiliko dut, beraz, zehaztu parametroak ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA beharrik ez.
Ona da jakitea: AMIa aldizka eguneratzea gomendatzen da, bertsio berriek Docker, Linux, ECS agente eta abarren bertsioak eguneratzen dituztelako. Honetaz ez ahazteko, dezakezu bertsio berrien kaleratzeari buruz. Jakinarazpenak jaso ditzakezu posta elektronikoz eta eskuz eguneratu, edo Lambda funtzio bat idatzi dezakezu Launch Template-ren bertsio berri bat automatikoki sortuko duen AMI eguneratu batekin.
EC2 Auto Scaling taldea
Auto Scaling Group instantziak abiarazteko eta eskalatzeaz arduratzen da. Taldeak EC2 -> Auto Scaling -> Auto Scaling Taldeak atalean kudeatzen dira.
Abiarazi txantiloia — hautatu aurreko urratsean sortutako txantiloia. Bertsio lehenetsia uzten dugu.
Erosteko aukerak eta instantzia motak — zehaztu klusterraren instantzia motak. Abiarazte txantiloiari atxikitzea Abiarazteko txantiloiaren instantzia mota erabiltzen du. Erosketa-aukerak eta instantzia motak konbinatuz, instantzia motak malgutasunez konfigura ditzakezu. Erabiliko dugu.
Aukerako On-Demand oinarria — beti funtzionatuko duten instantzia arrunt eta ez-puntualen kopurua.
Eskaera-portzentajea oinarriaren gainetik — Instantzia arrunt eta puntualen ehuneko ratioa, 50-50 berdin banatuko da, 20-80 instantzia arrunt bakoitzeko 4 puntu igoko dira. Adibide honen ondorioetarako, 50-50 adieraziko dut, baina errealitatean gehienetan 20-80 egiten dugu, kasu batzuetan 0-100.
Instantzia motak — hemen klusterrean erabiliko diren instantzia mota gehigarriak zehaztu ditzakezu. Inoiz ez dugu erabili istorioaren esanahia benetan ulertzen ez dudalako. Beharbada, instantzia mota zehatzen mugengatik gertatu da, baina laguntzaren bidez erraz handitu daitezke. Aplikazioa ezagutzen baduzu, pozik irakurriko dut iruzkinetan)
Sarea — sarearen ezarpenak, hautatu VPC eta makinen azpisareak, kasu gehienetan eskuragarri dauden azpisare guztiak hautatu behar dituzu.
Karga orekatzea - orekatzailearen ezarpenak, baina hau bereiz egingo dugu, hemen ez dugu ezer ukituko. Osasun kontrolak geroago ere konfiguratuko da.
Taldearen tamaina — klusterreko makina-kopuruaren mugak eta nahi den makina-kopurua hasieran adierazten ditugu. Klusterreko makina-kopurua ez da inoiz zehaztutako minimoa baino txikiagoa eta gehienezkoa baino handiagoa izango, nahiz eta eskalatzea neurrien arabera gertatu.
Eskalatzeko politikak — eskalatzeko parametroak, baina exekutatzen ari diren ECS zereginen arabera eskalatuko dugu, beraz, eskalatzea geroago konfiguratuko dugu.
Instantzia eskalatzeko babesa — Instantziak ezabatzetik babestea eskalatzean. Gaitzen dugu, ASG-k exekutatzen ari diren zereginak dituen makina ezabatzeko. ECS Capacity Provider-ek babesa desgaituko du zereginik ez duten instantzietarako.
Etiketak gehitu — Instantziaren etiketak zehaztu ditzakezu (horretarako, Etiketatu instantzia berriak kontrol-laukia markatuta egon behar da). Izena etiketa zehaztea gomendatzen dut, orduan taldean abiarazten diren instantzia guztiek izen bera izango dute, eta komenigarria da kontsolan ikustea.
Taldea sortu ondoren, ireki eta joan Konfigurazio aurreratuak atalera.Zergatik ez daude aukera guztiak kontsolan sorrera fasean.
Amaierako politikak — Instantziak ezabatzerakoan kontuan hartzen diren arauak. Ordenan aplikatzen dira. Normalean beheko irudian agertzen direnak erabiltzen ditugu. Lehenik eta behin, Abiarazteko txantiloi zaharrena duten instantzia ezabatzen dira (adibidez, AMI eguneratzen badugu, bertsio berri bat sortu dugu, baina instantzia guztiek horretara aldatzea lortu dute). Ondoren, hurrengo fakturazio-ordutik hurbilen dauden kasuak hautatzen dira. Eta gero zaharrenak abiarazteko dataren arabera hautatzen dira.
Ona da jakitea: cluster bateko makina guztiak eguneratzeko, erabiltzeko erosoa . Hau aurreko urratseko Lambda funtzioarekin konbinatzen baduzu, instantzia eguneratzeko sistema guztiz automatizatua izango duzu. Makina guztiak eguneratu aurretik, taldeko instantzia guztietan desgaitu behar duzu instantzia handitzeko babesa. Taldean konfigurazioa ez, makinen beraren babesa baizik, Instantziak kudeatzeko fitxan egiten da.
Aplikazioa Load Balancer eta EC2 Target Group
Balantzailea EC2 → Load Balancer → Load Balancers atalean sortzen da. Aplikazioaren karga-orekatzailea erabiliko dugu; orekatzaile mota ezberdinen konparaketa hemen irakur daiteke .
entzuleak - Zentzuzkoa da 80 eta 443 atakak egitea eta 80tik 443ra birbideratzea gero orekatzaile-arauak erabiliz.
Erabilgarritasun guneak — Kasu gehienetan, guztientzako irisgarritasun-guneak hautatzen ditugu.
Konfiguratu segurtasun ezarpenak — Balantzailearen SSL ziurtagiria adierazten da hemen, aukerarik egokiena da ACMn. Desberdintasunei buruz Segurtasun Politika barruan irakur daiteke , lehenespenez hautatuta utz dezakezu ELBSecurityPolicy-2016-08. Balantzailea sortu ondoren, ikusiko duzu DNS izena, zure domeinurako CNAME konfiguratu behar duzuna. Esaterako, hauxe da Cloudflare-n.
Segurtasun Taldea — Sortu edo hautatu segurtasun-talde bat orekatzailearentzat, horretaz gehiago idatzi nuen goian EC2 Launch Template → Sarearen ezarpenak atalean.
Helburu taldea — Balantzagailutik makinetara eskaerak bideratzeaz eta haien erabilgarritasuna egiaztatzeaz arduratzen den talde bat sortzen dugu, arazoak izanez gero ordezkatzeko. Helburu mota Instantzia izan behar du, Protokoloa и Port edozein, orekatzailearen eta instantzien arteko komunikaziorako HTTPS erabiltzen baduzu, ziurtagiri bat igo behar duzu haietara. Adibide honen helburuetarako, ez dugu hau egingo, 80 ataka utziko dugu besterik gabe.
Osasun kontrolak — zerbitzuaren funtzionaltasuna egiaztatzeko parametroak. Benetako zerbitzu batean, negozio-logikaren zati garrantzitsuak ezartzen dituen eskaera bereizia izan beharko litzateke; Adibide honen helburuetarako, ezarpen lehenetsiak utziko ditut. Jarraian, eskaera-tartea, denbora-muga, arrakasta-kodeak eta abar hauta ditzakezu. Gure adibidean, Arrakasta-kodeak 200-399 adieraziko ditugu, erabiliko den Docker irudiak 304 kodea itzultzen duelako.
Erregistratu Helburuak — hemen talderako autoak hautatzen dira, baina gure kasuan ECSek egingo du, beraz, urrats hau saltatzen dugu.
Ona da jakitea: orekatzaile mailan S3-n gordeko diren erregistroak gaitu ditzakezu . Bertatik hirugarrenen zerbitzuetara esportatu daitezke analitiketarako, edo SQL kontsultak zuzenean egin ditzakezu S3-ko datuekin. . Erosoa da eta kode gehigarririk gabe funtzionatzen du. S3 ontzitik erregistroak kentzea ere gomendatzen dut epe jakin baten ondoren.
ECS Zereginen Definizioa
Aurreko pausoetan, zerbitzu-azpiegiturekin lotutako guztia sortu genuen; orain abiaraziko ditugun edukiontziak deskribatzera pasatzen gara. ECS → Zereginen definizioak atalean egiten da.
Abiarazi motaren bateragarritasuna - hautatu EC2.
Ataza exekutatzeko IAM rola - aukeratu ecsTaskExecutionRole. Erabiliz, erregistroak idazten dira, aldagai sekretuetarako sarbidea ematen da, etab.
Edukiontzien definizioak atalean, egin klik Gehitu edukiontzia.
Irudia — lotura proiektuaren kodea duen irudira; adibide honetarako Docker Hub-eko irudi publiko bat erabiliko dut .
Memoriaren mugak — edukiontziaren memoria-mugak. Muga gogorra — muga gogorra, edukiontzia zehaztutako baliotik haratago joaten bada, docker kill komandoa exekutatuko da, edukiontzia berehala hilko da. Muga biguna — muga biguna, edukiontzia zehaztutako baliotik haratago joan daiteke, baina parametro hori kontuan hartuko da makinetan zereginak jartzerakoan. Adibidez, makina batek 4 GiB RAM baditu eta edukiontzi baten muga biguna 2048 MiB bada, orduan makina honek gehienez 2 zeregin izan ditzake edukiontzi honekin. Egia esan, 4 GiB RAM 4096 MiB baino apur bat gutxiago dira, hau klusterreko ECS Instantziak fitxan ikus daiteke. Muga biguna ezin da izan muga gogorra baino handiagoa. Garrantzitsua da ulertzea zeregin batean hainbat edukiontzi baldin badaude, orduan haien mugak laburbiltzen direla.
Portuen mapak - urtean Ostalari ataka 0 adierazten dugu, honek esan nahi du ataka dinamikoki esleituko dela eta Helburu Taldeak kontrolatuko duela. Edukiontzien Portua — Zure aplikazioa exekutatzen den ataka askotan exekuzio komandoan zehazten da, edo zure aplikazioaren kodean, Dockerfilean, etab. Gure adibiderako 3000 erabiliko dugu zerrendan dagoelako erabiltzen ari den irudia.
Osasun azterketa — Edukiontzien osasun-egiaztapenaren parametroak, ez nahastu Helburu Taldean konfiguratutakoarekin.
Ingurumena - ingurunearen ezarpenak. CPU unitateak - Memoria mugen antzekoa, prozesadoreari buruz bakarrik. Prozesadorearen nukleo bakoitzak 1024 unitate ditu, beraz, zerbitzariak nukleo bikoitzeko prozesadorea badu eta edukiontzia 512an ezarrita badago, edukiontzi honekin 4 zeregin abiarazi daitezke zerbitzari batean. CPU unitateak nukleo kopuruari dagozkio beti; ezin dira gutxiago izan, memoriarekin gertatzen den bezala.
Komandoa — Edukiontzi baten barruan zerbitzu bat abiarazteko komando bat, parametro guztiak komaz bereizita zehazten dira. Hau gunicorn, npm, etab izan daiteke. Zehazten ez bada, Dockerfileko CMD zuzentarauaren balioa erabiliko da. Adierazten dugu npm,start.
Inguruko aldagaiak — edukiontziaren ingurune-aldagaiak. Hau testu-datu soilak edo aldagai sekretuak izan daitezke edo .
Biltegiratzea eta erregistroa - hemen CloudWatch Logs-en saioa konfiguratuko dugu (AWS-ren erregistroetarako zerbitzua). Horretarako, gaitu Automatikoki CloudWatch Logs kontrol-laukia. Zereginen Definizioa sortu ondoren, automatikoki erregistro talde bat sortuko da CloudWatch-en. Lehenespenez, erregistroak mugarik gabe gordetzen dira bertan; Atxikipen-epea Inoiz iraungitzetik behar den aldira aldatzea gomendatzen dut. Hau CloudWatch Log taldeetan egiten da, uneko aldian klik egin eta berri bat hautatu behar duzu.
ECS Cluster eta ECS Capacity Provider
Joan ECS → Klusterrak atalera kluster bat sortzeko. EC2 Linux + Networking aukeratzen dugu txantiloi gisa.
Kluster izena - oso garrantzitsua, hemen Launch Template parametroan zehaztutako izen bera egiten dugu ECS_CLUSTER, gure kasuan - DemoApiClusterProd. Markatu Sortu kluster huts bat kontrol-laukia. Aukeran, Container Insights gaitu dezakezu CloudWatch-en zerbitzuen neurketak ikusteko. Dena behar bezala egin baduzu, ECS Instantziak atalean Auto Scaling taldean sortutako makinak ikusiko dituzu.
Joan fitxara Ahalmen-hornitzaileak eta sortu berri bat. Gogorarazten dizut beharrezkoa dela makinen sorrera eta itzaltzea exekutatzen ari diren ECS zereginen kopuruaren arabera kontrolatzeko. Garrantzitsua da kontuan izan hornitzaile bat talde bati soilik esleitu ahal zaiola.
Auto Scaling taldea — hautatu aurretik sortutako taldea.
Eskalatze kudeatua — gaitu hornitzaileak zerbitzua eskala dezan.
Helburuko edukiera % — Zereginez kargatutako makinen ehunekoa behar dugun. % 100 zehazten baduzu, makina guztiak beti lanpetuta egongo dira exekutatzen zereginekin. % 50 zehazten baduzu, orduan autoen erdia doakoa izango da beti. Kasu honetan, karga-jauzi handia gertatzen bada, taxi berriak berehala iritsiko dira auto libreetara, instantzia zabaltzeko itxaron gabe.
Kudeatutako baja babesa — gaitu, parametro honek aukera ematen dio hornitzaileak instantzien babesa ezabatzetik kentzeko. Hau makinan zeregin aktiborik ez dagoenean gertatzen da eta Helburu-ahalmenaren %% aukera ematen du.
ECS Zerbitzua eta eskalatzearen konfigurazioa
Azken urratsa :) Zerbitzu bat sortzeko, Zerbitzuak fitxan aldez aurretik sortutako klusterera joan behar duzu.
Abiarazteko mota — Aldatu ahalmen-hornitzaileen estrategian sakatu eta aldez aurretik sortutako hornitzaileak hautatu behar dituzu.
Zereginaren definizioa — hautatu aurretik sortutako Zereginen Definizioa eta haren berrikuspena.
Zerbitzuaren izena — nahasketa saihesteko, beti adieraziko dugu Zereginaren Definizioa.
Zerbitzu mota - beti Erreplika.
Zeregin kopurua — Zerbitzuan nahi den zeregin aktibo kopurua. Parametro hau eskalatuz kontrolatzen da, baina oraindik zehaztu behar da.
Gutxieneko ehuneko osasungarria и Gehienezko ehunekoa — hedapenean zereginen portaera zehaztea. Balio lehenetsiak 100 eta 200 dira, inplementazioan zeregin kopurua hainbat aldiz handituko dela eta gero nahi den baliora itzuliko dela adierazten du. Zeregin 1 exekutatzen baduzu, min=0 eta max=100, orduan inplementazioan zehar hil egingo da, eta horren ostean berri bat sortuko da, hau da, geldialdi-denbora izango da. Zeregin bat exekutatzen ari bada, min = 1, max = 50, orduan inplementazioa ez da batere gertatuko, zeregin bat ezin delako zatitu edo bider eta erdi handitu.
Inplementazio mota — utzi Rolling eguneratzea.
Kokapen txantiloiak — Makinetan zereginak jartzeko arauak. Lehenetsia AZ Balanced Spread da - horrek esan nahi du zeregin berri bakoitza instantzia berri batean jarriko dela erabilgarritasun-eremu guztietako makinak igo arte. Normalean BinPack - CPU eta Spread - AZ egiten dugu; politika honekin, zereginak ahalik eta trinkoen jartzen dira CPU bakoitzeko makina batean. Makina berri bat sortzea beharrezkoa bada, erabilgarritasun eremu berri batean sortzen da.
Karga orekatzeko mota — hautatu Aplikazioaren karga-balantzatzailea.
Zerbitzu IAM rola - aukeratu ecsServiceRole.
Karga-orekatzailearen izena — hautatu aurretik sortutako orekatzailea.
Osasun egiaztapena grazia epea — pausatu osasun-azterketak egin aurretik zeregin berri bat zabaldu ondoren, normalean 60 segundora ezartzen dugu.
Ontzia kargatzeko balantzea — Helburu-taldearen izena elementuan, hautatu aurretik sortutako taldea, eta dena automatikoki beteko da.
Eskalatze automatikoa zerbitzua — Zerbitzua eskalatzeko parametroak. Hautatu Konfiguratu zerbitzuaren eskala automatikoa zure zerbitzuaren nahi duzun zenbaketa doitzeko. Eskalatzerakoan gutxieneko eta gehienezko zereginen kopurua ezartzen dugu.
IAM rola Service Auto Scaling-erako - aukeratu AWSServiceRoleForApplicationAutoScaling_ECSService.
Zereginen eskalatze-politika automatikoak — eskalatzeko arauak. 2 mota daude:
- Helburuen jarraipena — helburu-neurriak jarraitzea (CPU/RAM erabilera edo zeregin bakoitzeko eskaera kopurua). Esaterako, prozesadorearen batez besteko karga %85ekoa izatea nahi dugu, handiagoa denean, zeregin berriak gehituko dira xede-balioa lortu arte. Karga txikiagoa bada, zereginak kendu egingo dira, aitzitik, eskalatzearen aurkako babesa gaituta ez badago (Desgaitu eskalatzea).
- Urratsaren eskalatzea - gertaera arbitrario baten aurrean erreakzioa. Hemen edozein gertaeraren aurrean erreakzio bat konfigura dezakezu (CloudWatch Alarm), gertatzen denean, zehaztutako zeregin kopurua gehitu edo kendu dezakezu, edo zeregin kopuru zehatza zehaztu.
Zerbitzu batek eskalatzeko hainbat arau izan ditzake, hau erabilgarria izan daiteke, gauza nagusia elkarren artean gatazkarik ez dutela ziurtatzea da.
Ondorioa
Argibideak jarraitu badituzu eta Docker-eko irudi bera erabili baduzu, zure zerbitzuak honelako orrialde bat itzuli beharko luke.
- Zerbitzuko makina guztiak martxan jartzen diren txantiloi bat sortu dugu. Txantiloia aldatzen denean makinak nola eguneratu ere ikasi dugu.
- Leku-instantzia gelditzeko seinalearen prozesamendua konfiguratu dugu, beraz, jaso eta minutu batean, martxan dauden zeregin guztiak kentzen dira makinatik, beraz, ez da ezer galtzen edo eteten.
- Balantzailea altxatu genuen karga makinetan uniformeki banatzeko.
- Lekuko instantzietan exekutatzen den zerbitzu bat sortu dugu, eta horrek makinen kostuak hiru aldiz gutxitzen ditu.
- Eskalatze automatikoa bi noranzkoetan konfiguratu dugu lan-karga handitzea kudeatzeko, geldialdi-kostuak eragin gabe.
- Capacity Provider erabiltzen dugu aplikazioak azpiegitura (makinak) kudeatzeko eta ez alderantziz.
- Handiak gara.
Karga-puntak aurreikusten badituzu, adibidez, posta elektronikoko kanpaina handi batean iragartzen ari bazara, eskalatzea konfigura dezakezu. .
Zure sistemaren atal ezberdinetako datuetan oinarrituta ere eska dezakezu. Adibidez, funtzionaltasuna dugu mugikorreko aplikazioaren erabiltzaileak. Batzuetan, 1M+ pertsonari bidaltzen zaie kanpaina bat. Banaketa horren ondoren, beti dago APIrako eskaerak handitu egiten direla, erabiltzaile asko aplikazioan aldi berean sartzen baitira. Beraz, sustapen push jakinarazpenak bidaltzeko ilaran adierazle nabarmen gehiago daudela ikusten badugu, berehala abiarazi ditzakegu hainbat makina eta zeregin gehigarri kargarako prest egoteko.
Pozik egongo naiz iruzkinetan lekuko instantzien eta ECS edo eskalatzearen inguruko kasu interesgarriak kontatzen badituzu.
Laster, zerbitzaririk gabeko pila batean segunduko milaka gertaera analitiko prozesatzen ditugun (diruarekin) eta GitLab CI eta Terraform Cloud erabiliz zerbitzuen inplementazioak nola funtzionatzen duen buruzko artikuluak egongo dira.
Harpidetu gurekin, interesgarria izango da!
Erregistratutako erabiltzaileek soilik parte hartu dezakete inkestan. , mesedez.
Erabiltzen al dituzu lekuko instantziak ekoizpenean?
-
22,2%Bai6
-
66,7%18. zenbakia
-
11,1%Artikulu batetik ezagutu nituen eta erabiltzeko asmoa3
27 erabiltzailek eman dute botoa. 5 erabiltzaile abstenitu ziren.
Iturria: www.habr.com