Ahojte všetci! Volám sa Kirill, som CTO v Adapty. Väčšina našej architektúry je na AWS a dnes budem hovoriť o tom, ako sme trojnásobne znížili náklady na server pomocou bodových inštancií v produkčnom prostredí, ako aj o tom, ako nastaviť ich automatické škálovanie. Najprv bude prehľad, ako to funguje, a potom podrobné pokyny na začiatok.
Čo sú spotové inštancie?
inštancie sú servery iných používateľov AWS, ktorí sú momentálne nečinní a predávajú ich s veľkou zľavou (Amazon píše až 90 %, podľa našich skúseností ~ 3x, líši sa v závislosti od regiónu, AZ a typu inštancie). Ich hlavným rozdielom od bežných je to, že sa môžu kedykoľvek vypnúť. Preto sme dlho verili, že je normálne používať ich v panenských prostrediach, alebo na úlohy niečoho vypočítať, s medzivýsledkami uloženými na S3 alebo v databáze, ale nie na predaj. Existujú riešenia tretích strán, ktoré vám umožňujú použiť spoty pri výrobe, ale v našom prípade existuje veľa bariel, takže sme ich neimplementovali. Prístup popísaný v článku funguje úplne v rámci štandardnej funkcionality AWS, bez ďalších skriptov, korún atď.
Nižšie je uvedených niekoľko snímok obrazovky, ktoré zobrazujú históriu cien pre spotové prípady.
m5.veľký v regióne eu-west-1 (Írsko). Cena je väčšinou stabilná 3 mesiace, v súčasnosti šetrí 2.9x.
m5.veľký v regióne us-východ-1 (Severná Virgínia). Cena sa počas 3 mesiacov neustále mení, v súčasnosti šetrí od 2.3x do 2.8x v závislosti od zóny dostupnosti.
t3.malý v regióne us-východ-1 (Severná Virgínia). Cena je stabilná 3 mesiace, momentálne šetrí 3.4x.
Architektúra služby
Základná architektúra služby, o ktorej budeme hovoriť v tomto článku, je znázornená na obrázku nižšie.
Aplikácia Load Balancer → EC2 Target Group → Elastic Container Service
Aplikačný Load Balancer (ALB) sa používa ako balancer, ktorý posiela požiadavky do EC2 Target Group (TG). TG je zodpovedná za otváranie portov na inštanciách pre ALB a ich pripojenie k portom kontajnerov Elastic Container Service (ECS). ECS je analógom Kubernetes v AWS, ktorý spravuje kontajnery Docker.
Jedna inštancia môže mať niekoľko spustených kontajnerov s rovnakými portami, takže ich nemôžeme nastaviť pevne. ECS povie TG, že spúšťa novú úlohu (v terminológii Kubernetes sa to nazýva pod), skontroluje voľné porty na inštancii a jeden z nich priradí k spustenej úlohe. TG tiež pravidelne kontroluje, či na nej inštancia a API pracujú pomocou kontroly stavu a ak vidí nejaké problémy, prestane tam posielať požiadavky.
Skupiny automatického škálovania EC2 + poskytovatelia kapacity ECS
Vyššie uvedený diagram nezobrazuje službu EC2 Auto Scaling Groups (ASG). Z názvu môžete pochopiť, že je zodpovedný za škálovanie inštancií. Až donedávna však AWS nemalo zabudovanú schopnosť spravovať počet bežiacich strojov z ECS. ECS umožnilo škálovať počet úloh, napríklad podľa využitia CPU, RAM alebo počtu požiadaviek. Ak však úlohy obsadili všetky voľné inštancie, nové počítače sa nevytvorili automaticky.
To sa zmenilo s príchodom poskytovateľov kapacity ECS (ECS CP). Teraz môže byť každá služba v ECS priradená k ASG, a ak sa úlohy nezmestia do spustených inštancií, potom sa vytvoria nové (ale v rámci stanovených limitov ASG). Funguje to aj v opačnom smere, ak ECS CP vidí nečinné inštancie bez úloh, potom vydá príkaz ASG na ich vypnutie. ECS CP má schopnosť špecifikovať cieľové percento zaťaženia inštancie, takže určitý počet počítačov je vždy voľný pre úlohy rýchleho škálovania; o tom budem hovoriť o niečo neskôr.
Spúšťacie šablóny EC2
Poslednou službou, o ktorej budem hovoriť predtým, ako sa podrobne zapojím do vytvárania tejto infraštruktúry, sú EC2 Launch Templates. Umožňuje vám vytvoriť si šablónu, podľa ktorej sa spustia všetky stroje, aby sa to zakaždým neopakovalo od začiatku. Tu si môžete vybrať typ spusteného počítača, bezpečnostnú skupinu, obraz disku a mnoho ďalších parametrov. Môžete tiež zadať používateľské údaje, ktoré sa nahrajú do všetkých spustených inštancií. V používateľských údajoch môžete spúšťať skripty, napríklad môžete upravovať obsah súboru .
Jedným z najdôležitejších konfiguračných parametrov tohto článku je = pravda. Ak je tento parameter povolený, potom akonáhle ECS dostane signál, že sa inštancia miesta odoberá, prenesie všetky úlohy, ktoré na ňom pracujú, do stavu Draining. K tejto inštancii nebudú priradené žiadne nové úlohy; ak existujú úlohy, ktoré do nej chcú byť zavedené práve teraz, budú zrušené. Prestávajú prichádzať aj požiadavky od balancera. Oznámenie o odstránení inštancie prichádza 2 minúty pred skutočnou udalosťou. Ak teda vaša služba nevykonáva úlohy dlhšie ako 2 minúty a neukladá nič na disk, môžete použiť spotové inštancie bez straty údajov.
Čo sa týka disku - AWS nedávno Spolu s ECS je možné použiť Elastic File System (EFS), pri tejto schéme nie je prekážkou ani disk, ale toto sme neskúšali, keďže na ukladanie stavu disk v zásade nepotrebujeme. Štandardne sa po prijatí SIGINT (odoslaného pri prenesení úlohy do stavu Vypúšťanie) všetky spustené úlohy zastavia po 30 sekundách, aj keď ešte neboli dokončené; tento čas môžete zmeniť pomocou parametra . Hlavná vec je nenastavovať ho na viac ako 2 minúty pre bodové automaty.
Vytvorenie služby
Prejdime k vytvoreniu opísanej služby. V tomto procese dodatočne popíšem niekoľko užitočných bodov, ktoré neboli uvedené vyššie. Vo všeobecnosti ide o návod krok za krokom, ale nebudem zvažovať niektoré veľmi základné alebo naopak veľmi špecifické prípady. Všetky akcie sa vykonávajú vo vizuálnej konzole AWS, ale možno ich reprodukovať programovo pomocou CloudFormation alebo Terraform. V Adapty používame Terraform.
EC2 Launch Template
Táto služba vytvorí konfiguráciu strojov, ktoré sa budú používať. Šablóny sa spravujú v sekcii EC2 -> Instance -> Launch templates.
Obraz stroja Amazon (AMI) — zadajte obraz disku, s ktorým sa budú spúšťať všetky inštancie. Pre ECS sa vo väčšine prípadov oplatí použiť optimalizovaný obrázok od Amazonu. Je pravidelne aktualizovaný a obsahuje všetko potrebné pre fungovanie ECS. Ak chcete zistiť aktuálne ID obrázka, prejdite na stránku , vyberte oblasť, ktorú používate, a skopírujte pre ňu AMI ID. Napríklad pre región us-východ-1 je aktuálne ID v čase písania tohto článku ami-00c7c1cf5bdc913ed. Toto ID musí byť vložené do položky Zadajte vlastnú hodnotu.
Typ inštancie — uveďte typ inštancie. Vyberte si ten, ktorý najlepšie vyhovuje vašej úlohe.
Pár kľúčov (prihlásenie) — zadajte certifikát, pomocou ktorého sa môžete v prípade potreby pripojiť k inštancii cez SSH.
Nastavenie siete — špecifikujte parametre siete. Sieťová platforma vo väčšine prípadov by mal existovať virtuálny súkromný cloud (VPC). Skupiny zabezpečenia — bezpečnostné skupiny pre vaše inštancie. Keďže pred inštanciami budeme používať balancer, odporúčam tu špecifikovať skupinu, ktorá povoľuje prichádzajúce spojenia len z balancera. To znamená, že budete mať 2 bezpečnostné skupiny, jednu pre balancer, ktorá umožňuje prichádzajúce pripojenia odkiaľkoľvek na portoch 80 (http) a 443 (https), a druhú pre počítače, ktorá umožňuje prichádzajúce pripojenia na ľubovoľných portoch zo skupiny balancerov. . Odchádzajúce spojenia v oboch skupinách musia byť otvorené pomocou protokolu TCP na všetky porty na všetky adresy. Môžete obmedziť porty a adresy pre odchádzajúce pripojenia, ale potom musíte neustále sledovať, či sa nepokúšate pristupovať k niečomu na uzavretom porte.
Ukladací priestor (zväzky) — zadajte parametre disku pre počítače. Veľkosť disku nemôže byť menšia ako veľkosť špecifikovaná v AMI, pre ECS Optimized je to 30 GiB.
Pokročilé detaily — špecifikovať dodatočné parametre.
Možnosť nákupu — či chceme nakupovať spotové inštancie. Chceme, ale toto políčko tu nezačiarkneme; nakonfigurujeme ho v skupine Auto Scaling, tam je viac možností.
Profil inštancie IAM — uveďte rolu, s ktorou budú inštancie spúšťané. Aby inštancie mohli bežať v ECS, potrebujú povolenia, ktoré sa zvyčajne nachádzajú v role ecsInstanceRole. V niektorých prípadoch sa dá vytvoriť, ak nie, potom tu o tom, ako to urobiť. Po vytvorení to uvedieme v šablóne.
Ďalej je tu veľa parametrov, v podstate môžete všade ponechať predvolené hodnoty, ale každý z nich má jasný popis. Vždy povolím inštanciu optimalizovanú pre EBS a možnosti T2/T3 Unlimited, ak sa použijú prípadov.
Užívateľ čas — uveďte údaje používateľa. Súbor upravíme /etc/ecs/ecs.config, ktorý obsahuje konfiguráciu agenta ECS.
Príklad toho, ako môžu vyzerať používateľské údaje:
#!/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 — parameter označuje, že inštancia patrí do klastra s daným názvom, to znamená, že tento klaster bude môcť umiestniť svoje úlohy na tento server. Klaster sme ešte nevytvorili, ale tento názov použijeme pri jeho vytváraní.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameter určuje, že keď sa prijme signál na vypnutie bodovej inštancie, všetky úlohy na nej by sa mali preniesť do stavu vypúšťania.
ECS_CONTAINER_STOP_TIMEOUT=1m - parameter určuje, že po prijatí signálu SIGINT majú všetky úlohy 1 minútu pred tým, než budú ukončené.
ECS_ENGINE_AUTH_TYPE=docker — parameter označuje, že ako autorizačný mechanizmus sa používa schéma Docker
ECS_ENGINE_AUTH_DATA=... — parametre pripojenia k súkromnému registru kontajnerov, kde sú uložené vaše obrázky Docker. Ak je verejný, nemusíte nič špecifikovať.
Na účely tohto článku použijem verejný obrázok z Docker Hub, takže špecifikujte parametre ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nie je potrebné.
Je dobré vedieť: Odporúča sa pravidelne aktualizovať AMI, pretože nové verzie aktualizujú verzie Docker, Linux, ECS agent atď. Aby ste na to nezabudli, môžete o vydaní nových verzií. Môžete dostávať upozornenia e-mailom a aktualizovať manuálne, alebo môžete napísať funkciu Lambda, ktorá automaticky vytvorí novú verziu Launch Template s aktualizovaným AMI.
EC2 Auto Scaling Group
Auto Scaling Group je zodpovedná za spúšťanie a škálovanie inštancií. Skupiny sa spravujú v sekcii EC2 -> Auto Scaling -> Auto Scaling Groups.
Spustiť šablónu — vyberte šablónu vytvorenú v predchádzajúcom kroku. Ponecháme predvolenú verziu.
Možnosti nákupu a typy inštancií — špecifikujte typy inštancií pre klaster. Šablóna Adhere to launch používa typ inštancie zo šablóny Launch Template. Kombinácia možností nákupu a typov inštancií vám umožňuje flexibilne konfigurovať typy inštancií. My to využijeme.
Voliteľná základňa On-Demand — počet bežných, nebodových prípadov, ktoré budú vždy fungovať.
Percento na požiadanie nad základnou hodnotou — percentuálny pomer bežných a spotových prípadov, 50-50 sa rozdelí rovnomerne, 20-80 za každý riadny prípad sa zvýšia 4 bodové. Pre účely tohto príkladu uvediem 50-50, ale v skutočnosti najčastejšie uvádzame 20-80, v niektorých prípadoch 0-100.
Typy inštancií — tu môžete zadať ďalšie typy inštancií, ktoré sa použijú v klastri. Nikdy sme to nepoužili, pretože veľmi nerozumiem zmyslu príbehu. Možno je to kvôli obmedzeniam na konkrétne typy inštancií, ale môžu sa ľahko zvýšiť pomocou podpory. Ak aplikáciu poznáte, rád si ju prečítam v komentároch)
sieť — nastavenia siete, vyberte VPC a podsiete pre stroje, vo väčšine prípadov by ste mali vybrať všetky dostupné podsiete.
Rozdelenie výkonu - nastavenia vyvažovača, ale urobíme to samostatne, nič sa tu nedotkneme. Zdravotné prehliadky bude tiež nakonfigurovaný neskôr.
Veľkosť skupiny — uvádzame limity počtu strojov v klastri a požadovaný počet strojov na začiatku. Počet počítačov v klastri nebude nikdy menší ako špecifikované minimum a väčší ako maximum, aj keď by malo dôjsť k škálovaniu podľa metrík.
Zásady škálovania — parametre škálovania, ale škálovať budeme na základe spustených úloh ECS, takže škálovanie nakonfigurujeme neskôr.
Inštancia ochrany proti vodnému kameňu — ochrana inštancií pred vymazaním pri zmenšení. Povolíme to, aby ASG neodstránila stroj, na ktorom sú spustené úlohy. Poskytovateľ kapacity ECS zakáže ochranu pre inštancie, ktoré nemajú úlohy.
Pridať značky — môžete zadať značky pre inštancie (na tento účel musí byť začiarknuté políčko Označiť nové inštancie). Odporúčam zadať Name tag, potom budú mať všetky inštancie spustené v rámci skupiny rovnaký názov a je vhodné ich zobraziť v konzole.
Po vytvorení skupiny ju otvorte a prejdite do časti Rozšírené konfigurácie Prečo nie sú všetky možnosti viditeľné v konzole vo fáze vytvárania.
Zásady ukončenia — pravidlá, ktoré sa berú do úvahy pri odstraňovaní inštancií. Aplikujú sa v poradí. Zvyčajne používame tie na obrázku nižšie. Najprv sa vymažú inštancie s najstaršou Launch Template (ak sme napríklad aktualizovali AMI, vytvorili sme novú verziu, no všetky inštancie sa na ňu stihli prepnúť). Potom sa vyberú prípady, ktoré sú najbližšie k nasledujúcej fakturačnej hodine. A potom sa vyberú tie najstaršie na základe dátumu spustenia.
Je dobré vedieť: na aktualizáciu všetkých strojov v klastri, pohodlné použitie . Ak to skombinujete s funkciou Lambda z predchádzajúceho kroku, získate plne automatizovaný systém aktualizácie inštancií. Pred aktualizáciou všetkých počítačov musíte vypnúť ochranu škálovania inštancií pre všetky inštancie v skupine. Nie konfigurácia v skupine, ale ochrana pred samotnými strojmi, to sa robí na karte Správa inštancií.
Application Load Balancer a EC2 Target Group
Balancer sa vytvára v časti EC2 → Load Balancing → Load Balancers. Použijeme Application Load Balancer, porovnanie rôznych typov balancerov si môžete prečítať na .
poslucháči - má zmysel vytvoriť porty 80 a 443 a presmerovať z 80 na 443 pomocou vyrovnávacích pravidiel neskôr.
Zóny dostupnosti — vo väčšine prípadov vyberáme zóny dostupnosti pre každého.
Nakonfigurujte nastavenia zabezpečenia — tu je uvedený certifikát SSL pre balancera, najpohodlnejšia možnosť je v ACM. O rozdieloch Bezpečnostná politika dá sa prečítať , môžete ho ponechať predvolene vybratý ELBSecurityPolicy-2016-08. Po vytvorení balancéra to uvidíte Názov DNS, ktorý potrebujete na konfiguráciu CNAME pre vašu doménu. Takto to napríklad vyzerá v Cloudflare.
bezpečnostná skupina — vytvorte alebo vyberte bezpečnostnú skupinu pre balancer, viac som o tom napísal vyššie v sekcii EC2 Launch Template → Network settings.
Cieľová skupina — vytvoríme skupinu, ktorá je zodpovedná za smerovanie požiadaviek z balancéra na stroje a kontrolu ich dostupnosti s cieľom nahradiť ich v prípade problémov. Cieľový typ musí byť inštancia, Protokol и prístav ľubovoľné, ak na komunikáciu medzi balancerom a inštanciami používate HTTPS, musíte do nich nahrať certifikát. Na účely tohto príkladu to neurobíme, jednoducho ponecháme port 80.
Zdravotné prehliadky — parametre na kontrolu funkčnosti služby. V reálnej službe by to mala byť samostatná požiadavka, ktorá implementuje dôležité časti obchodnej logiky, pre účely tohto príkladu ponechám predvolené nastavenia. Ďalej môžete vybrať interval požiadavky, časový limit, kódy úspechu atď. V našom príklade uvedieme kódy úspechu 200-399, pretože obrázok Docker, ktorý sa použije, vráti kód 304.
Zaregistrujte ciele — tu sa vyberú autá pre skupinu, ale v našom prípade to urobí ECS, takže tento krok preskočíme.
Je dobré vedieť: na úrovni balancera môžete povoliť protokoly, ktoré sa v určitom čase uložia do S3 . Odtiaľ ich možno exportovať do služieb tretích strán na analýzu, alebo môžete zadávať SQL dotazy priamo na dáta v S3 pomocou . Je to pohodlné a funguje to bez akéhokoľvek dodatočného kódu. Odporúčam tiež nastaviť odstraňovanie guľatiny z vedra S3 po stanovenej dobe.
Definícia úlohy ECS
V predchádzajúcich krokoch sme vytvorili všetko, čo súvisí s infraštruktúrou služieb, teraz prejdeme k popisu kontajnerov, ktoré spustíme. Toto sa vykonáva v časti ECS → Definície úloh.
Kompatibilita typu spustenia - vyberte EC2.
Vykonávanie úlohy Rola IAM - vybrať si ecsTaskExecutionRole. Pomocou neho sa zapisujú protokoly, udeľuje sa prístup k tajným premenným atď.
V časti Definície kontajnera kliknite na položku Pridať kontajner.
Obraz — odkaz na obrázok s kódom projektu; pre tento príklad použijem verejný obrázok z Docker Hub .
Pamäťové limity — limity pamäte pre kontajner. Tvrdý limit — pevný limit, ak kontajner prekročí zadanú hodnotu, vykoná sa príkaz docker kill, kontajner okamžite zomrie. Mäkký limit — mäkký limit, kontajner môže prekročiť špecifikovanú hodnotu, ale tento parameter sa bude brať do úvahy pri zadávaní úloh na strojoch. Napríklad, ak má stroj 4 GiB RAM a mäkký limit kontajnera je 2048 MiB, potom tento stroj môže mať s týmto kontajnerom spustené maximálne 2 úlohy. V skutočnosti sú 4 GiB pamäte RAM o niečo menej ako 4096 XNUMX MiB, čo je možné zobraziť na karte Inštancie ECS v klastri. Mäkký limit nemôže byť väčší ako pevný limit. Je dôležité pochopiť, že ak je v jednej úlohe niekoľko kontajnerov, ich limity sa spočítajú.
Mapovanie prístavov - v Hostiteľský port Označujeme 0, to znamená, že port bude prideľovaný dynamicky a bude sledovaný cieľovou skupinou. Kontajnerový prístav — port, na ktorom beží vaša aplikácia, je často špecifikovaný v príkaze na vykonanie alebo priradený v kóde vašej aplikácie, súbore Docker atď. Pre náš príklad použijeme 3000, pretože je uvedený v používaný obrázok.
Kontrola zdravia — parametre kontroly stavu kontajnera, nezamieňať s parametrami nakonfigurovanými v cieľovej skupine.
prostredie - nastavenia prostredia. CPU jednotky - podobne ako limity pamäte, len o procesore. Každé jadro procesora má 1024 jednotiek, takže ak má server dvojjadrový procesor a kontajner je nastavený na 512, na jednom serveri možno spustiť 4 úlohy s týmto kontajnerom. CPU jednotky vždy zodpovedajú počtu jadier, nemôže ich byť o niečo menej, ako je to v prípade pamätí.
povel — príkaz na spustenie služby v kontajneri, všetky parametre sú zadané oddelené čiarkami. Môže to byť gunicorn, npm atď. Ak nie je zadaný, použije sa hodnota direktívy CMD z Dockerfile. Naznačujeme npm,start.
Premenné prostredia — premenné prostredia kontajnera. Môžu to byť jednoduché textové údaje alebo tajné premenné z alebo .
Ukladanie a protokolovanie — tu nastavíme prihlasovanie do CloudWatch Logs (služba pre denníky od AWS). Ak to chcete urobiť, začiarknite políčko Automaticky konfigurovať protokoly CloudWatch. Po vytvorení Definície úlohy sa v CloudWatch automaticky vytvorí skupina protokolov. Štandardne sú v ňom protokoly uložené na dobu neurčitú, odporúčam zmeniť Retention period z Never Expire na požadovanú dobu. Robí sa to v skupinách CloudWatch Log, musíte kliknúť na aktuálne obdobie a vybrať nové.
ECS Cluster a ECS Capacity Provider
Prejdite do sekcie ECS → Klastre a vytvorte klaster. Ako šablónu vyberieme EC2 Linux + Networking.
Názov klastra - veľmi dôležité, tu vytvoríme rovnaký názov, aký je uvedený v parametri Launch Template ECS_CLUSTER, v našom prípade - DemoApiClusterProd. Začiarknite políčko Vytvoriť prázdny klaster. Voliteľne môžete povoliť Container Insights na zobrazenie metrík pre služby v CloudWatch. Ak ste urobili všetko správne, v sekcii Inštancie ECS uvidíte stroje, ktoré boli vytvorené v skupine Auto Scaling.
Prejdite na kartu Poskytovatelia kapacity a vytvorte nový. Dovoľte mi pripomenúť, že je potrebné riadiť vytváranie a vypínanie strojov v závislosti od počtu spustených úloh ECS. Je dôležité poznamenať, že poskytovateľa je možné priradiť iba do jednej skupiny.
Skupina automatického škálovania — vyberte predtým vytvorenú skupinu.
Riadené škálovanie — povoliť, aby poskytovateľ mohol službu škálovať.
Cieľová kapacita % — aké percento strojov zaťažených úlohami potrebujeme. Ak zadáte 100 %, všetky počítače budú vždy zaneprázdnené spustenými úlohami. Ak zadáte 50 %, polovica áut bude vždy voľná. V tomto prípade, ak dôjde k prudkému nárastu nákladu, nové taxíky sa okamžite dostanú k voľným autám bez toho, aby museli čakať na nasadenie inštancií.
Riadená ochrana ukončenia — povoliť, tento parameter umožňuje poskytovateľovi odstrániť ochranu inštancií pred vymazaním. Stáva sa to vtedy, keď na stroji nie sú žiadne aktívne úlohy a je povolená cieľová kapacita %.
Nastavenie služby ECS a škálovania
Posledný krok :) Ak chcete vytvoriť službu, musíte prejsť do predtým vytvoreného klastra na karte Služby.
Typ spustenia — musíte kliknúť na Prepnúť na stratégiu poskytovateľa kapacity a vybrať predtým vytvorených poskytovateľov.
Definícia úlohy — vyberte predtým vytvorenú definíciu úlohy a jej revíziu.
Názov služby — aby nedošlo k zámene, vždy označujeme to isté ako definícia úlohy.
Typ služby - vždy replika.
Počet úloh — požadovaný počet aktívnych úloh v službe. Tento parameter je riadený zmenou mierky, ale musí byť špecifikovaný.
Minimálne zdravé percento и Maximálne percento — určiť správanie úloh počas nasadenia. Predvolené hodnoty sú 100 a 200, čo znamená, že v čase nasadenia sa počet úloh niekoľkokrát zvýši a potom sa vráti na požadovanú hodnotu. Ak máte spustenú 1 úlohu, min=0 a max=100, počas nasadenia bude zabitá a potom sa spustí nová, to znamená, že dôjde k výpadku. Ak beží 1 úloha, min=50, max=150, k nasadeniu vôbec nedôjde, pretože 1 úloha sa nedá rozdeliť na polovicu ani zvýšiť jedenapolkrát.
Typ nasadenia — opustiť priebežnú aktualizáciu.
Šablóny umiestnení — pravidlá umiestňovania úloh na strojoch. Predvolená hodnota je AZ Balanced Spread – to znamená, že každá nová úloha bude umiestnená do novej inštancie, kým sa nezvýšia počítače vo všetkých zónach dostupnosti. Zvyčajne robíme BinPack - CPU a Spread - AZ; s touto politikou sú úlohy umiestnené čo najhustejšie na jednom počítači na CPU. Ak je potrebné vytvoriť nový stroj, vytvorí sa v novej zóne dostupnosti.
Typ vyvažovača zaťaženia — vyberte položku Application Load Balancer.
Úloha služby IAM - vybrať si ecsServiceRole.
Názov vyrovnávača zaťaženia — vyberte predtým vytvorený vyvažovač.
Ochranná lehota na kontrolu zdravotného stavu — pauza pred vykonaním kontroly stavu po spustení novej úlohy, zvyčajne ju nastavujeme na 60 sekúnd.
Kontajner na vyváženie nákladu — v položke Názov cieľovej skupiny vyberte predtým vytvorenú skupinu a všetko sa automaticky vyplní.
Automatické škálovanie služby — parametre škálovania služby. Vyberte možnosť Konfigurovať automatické škálovanie služby a upravte požadovaný počet služieb. Pri škálovaní nastavujeme minimálny a maximálny počet úloh.
Úloha IAM pre automatické škálovanie služieb - vybrať si AWSServiceRoleForApplicationAutoScaling_ECSService.
Zásady automatického škálovania úloh — pravidlá pre škálovanie. Existujú 2 typy:
- Sledovanie cieľa — sledovanie cieľových metrík (využitie CPU/RAM alebo počet požiadaviek na každú úlohu). Napríklad chceme, aby priemerná záťaž procesora bola 85 %, keď bude vyššia, budú pribúdať nové úlohy, kým nedosiahne cieľovú hodnotu. Ak je zaťaženie nižšie, úlohy sa odstránia, naopak, pokiaľ nie je povolená ochrana proti zmenšeniu (Zakázať škálovanie).
- Kroková mierka - reakcia na svojvoľnú udalosť. Tu môžete nakonfigurovať reakciu na akúkoľvek udalosť (CloudWatch Alarm), keď k nej dôjde, môžete pridať alebo odobrať zadaný počet úloh alebo určiť presný počet úloh.
Služba môže mať niekoľko pravidiel škálovania, to môže byť užitočné, hlavnou vecou je zabezpečiť, aby neboli navzájom v rozpore.
Záver
Ak ste postupovali podľa pokynov a použili ste rovnaký obrázok Docker, vaša služba by mala vrátiť stránku podobnú tejto.
- Vytvorili sme šablónu, podľa ktorej sa spúšťajú všetky stroje v službe. Tiež sme sa naučili, ako aktualizovať stroje pri zmene šablóny.
- Nastavili sme spracovanie signálu zastavenia bodovej inštancie, takže do minúty po jeho prijatí sa zo stroja odstránia všetky spustené úlohy, takže sa nič nestratí ani nepreruší.
- Zdvihli sme vyvažovačku, aby sa zaťaženie rovnomerne rozložilo medzi strojmi.
- Vytvorili sme službu, ktorá beží na mieste, čo znižuje náklady na stroj asi 3-krát.
- Nastavili sme automatické škálovanie v oboch smeroch, aby sme zvládli zvýšené pracovné zaťaženie bez toho, aby vznikli náklady na prestoje.
- Capacity Provider používame na to, aby aplikácia spravovala infraštruktúru (stroje) a nie naopak.
- Sme skvelí.
Ak máte predvídateľné výkyvy zaťaženia, napríklad inzerujete vo veľkej e-mailovej kampani, môžete nastaviť škálovanie .
Môžete tiež škálovať na základe údajov z rôznych častí vášho systému. Máme napríklad funkčnosť používateľov mobilnej aplikácie. Niekedy sa kampaň odošle viac ako 1 miliónu ľudí. Po takejto distribúcii vždy dôjde k veľkému nárastu požiadaviek na API, keďže sa do aplikácie prihlasuje veľa používateľov súčasne. Ak teda vidíme, že v rade na odosielanie propagačných push notifikácií je podstatne viac štandardných indikátorov, môžeme okamžite spustiť niekoľko ďalších strojov a úloh, aby sme boli pripravení na záťaž.
Budem rád, ak mi v komentároch poviete zaujímavé prípady použitia spotových inštancií a ECS alebo niečo o škálovaní.
Čoskoro tu budú články o tom, ako spracovávame tisíce analytických udalostí za sekundu na prevažne bezserverovom zásobníku (s peniazmi) a ako funguje nasadzovanie služieb pomocou GitLab CI a Terraform Cloud.
Prihláste sa na odber, bude to zaujímavé!
Do prieskumu sa môžu zapojiť iba registrovaní užívatelia. Prosím.
Používate spotové inštancie vo výrobe?
-
22,2%Áno6
-
66,7%č.18
-
11,1%Dozvedel som sa o nich z článku a plánujem ich použiť3
Hlasovalo 27 užívateľov. 5 užívateľov sa zdržalo hlasovania.
Zdroj: hab.com