Helló mindenkinek! A nevem Kirill, az Adapty CTO-ja vagyok. Az architektúránk nagy része az AWS-en található, és ma arról fogok beszélni, hogyan csökkentettük le a szerverek költségeit háromszorosára a spot instance-ok használatával a produkciós környezetben, valamint arról, hogyan lehet beállítani az automatikus skálázást. Először áttekintjük, hogyan működik ez, majd részletes útmutató következik a beállításhoz.
Mi az a spot instance?
instance-ok olyan AWS szerverek, amelyek jelenleg inaktívak más felhasználók számára, és ezeket jelentős kedvezménnyel értékesítik (az Amazon szerint akár 90%, tapasztalataink szerint ~3x, ami a régiótól, az AZ-től és az instance típusától függően változik). Fő különbségük a normál instance-okhoz képest, hogy bármikor kikapcsolhatók. Tehát sokáig úgy gondoltuk, hogy ezeket csak fejlesztési környezetekhez vagy számítási feladatokhoz lehet használni, megtartva a köztes eredményeket az S3-on vagy az adatbázisban, de nem a termeléshez. Léteznek külső megoldások, amelyek lehetővé teszik a spot instance-ok használatát a termelésben, de a mi esetünkben sok workaround szükséges, ezért nem vezettük be őket. A cikkben bemutatott megközelítés teljes mértékben az AWS standard funkcióira épít, további script vagy cron használata nélkül.
Most néhány képernyőképet mutatok be, amelyek a spot instance-ok ártörténetét mutatják.
m5.large az eu-west-1 (Írország) régióban. Az ár jellemzően stabil a 3 hónap során, jelenleg 2.9x megtakarítással.
m5.large az us-east-1 (Észak-Virginia) régióban. Az ár folyamatosan változik a 3 hónap során, jelenleg 2.3x és 2.8x közötti megtakarítással a rendelkezésre állási zónától függően.
t3.small az us-east-1 (Észak-Virginia) régióban. Az ár stabil a 3 hónap során, jelenleg 3.4x megtakarítással.
A szolgáltatás architektúrája
A szolgáltatás alap architektúrája, amelyről ebben a cikkben beszélni fogunk, az alábbi diagramon látható.
Application Load Balancer → EC2 Target Group → Elastic Container Service
A forgalomelosztó az Application Load Balancer (ALB), amely az EC2 Target Group (TG) felé irányítja a kéréseket. A TG feladata, hogy megnyissa az instance-okon a portokat az ALB számára, és ezeket összekapcsolja az Elastic Container Service (ECS) konténerek portjaival. Az ECS az AWS-en belül a Docker konténerek kezelésére szolgáló Kubernetes megfelelője.
Egy példányon több azonos porttal működő konténer is lehet, ezért nem tudjuk ezeket rögzíteni. Az ECS értesíti a TG-t, hogy új feladatot indít (Kubernetes terminológiában ezt pod-nak hívják), amely ellenőrzi a szabad portokat a példányon, és hozzárendel egyet az indítandó feladathoz. A TG rendszeresen ellenőrzi, hogy a példány és rajta az API működik-e a health check segítségével, és ha bármilyen problémát észlel, akkor leállítja a kérések továbbítását oda.
EC2 Auto Scaling Csoportok + ECS Kapacitásszolgáltatók
A fent említett diagramon nem látható az EC2 Auto Scaling Csoportok (ASG) szolgáltatás. A nevéből adódóan ez a példányok méretezéséért felelős. Eddig azonban az AWS-ben nem volt beépített lehetőség a futó gépek számának ECS-ből történő kezelésére. Az ECS lehetővé tette a feladatok számának skálázását, például a CPU, RAM vagy a kérések számának használata alapján. De ha a feladatok elfoglalták az összes szabad példányt, akkor új gépek automatikusan nem indultak.
Ez megváltozott az ECS Kapacitásszolgáltatók (ECS CP) megjelenésével. Mostantól minden ECS-szolgáltatás összekapcsolható az ASG-vel, és ha a feladatok nem férnek el a működő példányokon, akkor új példányok indulnak (de az ASG által megállapított korlátok között). Ez fordítva is működik: ha az ECS CP üres példányokat észlel feladatok nélkül, akkor utasítást ad az ASG-nek, hogy kapcsolja le őket. Az ECS CP lehetőséget biztosít a példányok terhelési célzott százalékának megadására, így mindig legyen néhány gép szabadon a feladatok gyors skálázása érdekében; erről később beszélek.
EC2 Indítási Sablonok
Az utolsó szolgáltatás, amelyről beszélni fogok, mielőtt részletesen bemutatnám az infrastruktúra létrehozását, az EC2 Indítási Sablonok. Ez lehetővé teszi egy sablon létrehozását, amely alapján minden gépet indítani fognak, hogy ezt minden alkalommal ne kelljen újrakezdeni. Itt kiválasztható a futó gép típusa, a biztonsági csoport, a lemezkép és sok egyéb paraméter. Ezen kívül megadhatók felhasználói adatok is, amelyeket minden indított példányra be lehet tölteni. A felhasználói adatokban például futtathatók szkriptek, például módosítható a fájl tartalma. .
A cikk keretein belül az egyik legfontosabb konfigurációs paraméter — =true. Ha ez a paraméter be van kapcsolva, akkor amint az ECS jelet kap arról, hogy a spot példányt elviszik, az összes, rajta futó feladat státuszát Draining-re váltja. Nincs új feladat, amit erre a példányra rendelnének, ha vannak olyan feladatok, amelyek éppen most akarnak erre futni, azokat törlik. A terheléselosztóból érkező kérések is megszűnnek. Az példány eltávolításáról szóló értesítés 2 perccel a tényleges esemény előtt érkezik. Tehát ha a szolgáltatása nem fut le 2 percnél tovább, és nem tárol semmit a lemezen, akkor használhatja a spot példányokat adatvesztés nélkül.
A lemezről - az AWS nemrégiben az Elastic File System (EFS) használatát az ECS-sel, ezzel a sémával még a lemez sem akadály, de mi ezt nem próbáltuk ki, mert alapvetően nincs szükségünk lemezre az állapot tárolásához. Alapértelmezés szerint a SIGINT (amelyet a feladat Draining státuszra váltásakor küldenek) fogadása után minden aktív feladat 30 másodpercen belül leáll, még akkor is, ha nem fejeződtek be, ezt az időt a paraméter segítségével lehet megváltoztatni. . Fontos, hogy ne állítsa be 2 percnél hosszabb időre a spot gépeknél.
Szolgáltatás létrehozása
Most térjünk rá a fent említett szolgáltatás létrehozására. A folyamat során további hasznos szempontokat ismertetek, amelyeket korábban nem említettem. Ez összességében egy lépésről lépésre útmutató, de néhány nagyon alapvető vagy éppenséggel nagyon specifikus esetet nem fogok tárgyalni. Minden lépést az AWS vizuális konzolján hajtanak végre, de programozva is megvalósíthatók a CloudFormation vagy Terraform segítségével. Az Adapty-nál Terraform-ot használunk.
EC2 Launch Template
Ebben a szolgáltatásban elérhető a használni kívánt gépek konfigurációja. A sablonok kezelése az EC2 -> Instances -> Launch templates részben történik.
Amazon gép kép (AMI) — itt megadjuk a lemezkép azonosítóját, amellyel minden példány elindul. Az ECS-hez a legtöbb esetben az Amazon optimalizált képét kell használni. Ez rendszeresen frissül, és tartalmazza az ECS működéséhez szükséges összes elemet. Az aktuális képazonosító megismeréséhez menjünk el a , válasszuk ki a használni kívánt régiót, és másoljuk ki az AMI azonosítót hozzá. Például az us-east-1 régióhoz a cikk írásakor aktuális azonosító: ami-00c7c1cf5bdc913ed. Ezt az azonosítót a Specify a custom value pontba kell beilleszteni.
Példány típusa — megadjuk az instance típusát. Válassza azt, amelyik a legjobban illik a feladataihoz.
Kulcspár (bejelentkezés) — megadjuk a tanúsítványt, amellyel SSH-n keresztül csatlakozni tudunk az instance-ra, ha szükséges.
Hálózati beállítások — megadjuk a hálózati paramétereket. Hálózati platform általában Virtual Private Cloud (VPC) legyen. Biztonsági csoportok — biztonsági csoportok az instance-aink számára. Mivel terheléselosztót fogunk használni az instance-ok előtt, javaslom, hogy itt egy olyan csoportot jelöljön meg, amely engedélyezi a bejövő kapcsolatok csak a terheléselosztótól. Tehát két biztonsági csoportja lesz: az egyik a terheléselosztó számára, amely engedélyezi az összes bejövő (inbound) kapcsolatot 80 (http) és 443 (https) portokon, a másik a gépek számára, amely engedélyezi a bejövő kapcsolatokat bármely porton a terheléselosztó csoportból. A kimenő (outbound) kapcsolatoknak mindkét csoportban nyitva kell lenniük TCP protokollon minden portra minden címre. Korlátozhatjuk a kimenő kapcsolatok portjait és címeit, de akkor folyamatosan figyelni kell, hogy ne próbálkozzon olyan zárt porton való kapcsolódással.
Tárhely (volumenek) — megadjuk a lemezek paramétereit a gépek számára. A lemez mérete nem lehet kevesebb, mint az AMI-ban megadott, ECS Optimized esetén — 30 GiB.
Fejlett részletek — megadjuk a további paramétereket.
Vásárlási lehetőség — szeretnénk-e spottal rendelkező instance-okat vásárolni. Szeretnénk, de itt ezt a jelölőnégyzetet nem fogjuk bejelölni, ezt az Auto Scaling Grouppal állítjuk be, ott több lehetőség van.
IAM instance profil — megadjuk a szerepkört, amellyel az instance-ok elindulnak. Az ECS működéséhez az instance-oknak jogokra van szükségük, amelyeket általában a következő szerepkörön keresztül biztosítanak: ecsInstanceRole. Bizonyos esetekben ezt létre kell hozni, ha nincs, akkor itt tájékoztatót talál arról, hogyan lehet ezt megtenni. A létrehozás után megadjuk a sablonban.
Ezután sok paraméter következik, a legtöbb helyen az alapértelmezett értékeket lehet hagyni, de mindegyiknek világos leírása van. Én mindig bekapcsolom az EBS-optimalizált instance és a T2/T3 korlátlan lehetőségeket, ha használják instance-ok.
Felhasználói adatok — megadjuk a felhasználói adatokat. Szerkeszteni fogjuk a fájlt /etc/ecs/ecs.config, amelyben az ECS ügynök konfigurációja található.
Példa arra, hogy a felhasználói adatok hogyan nézhetnek ki:
#!/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 — a paraméter jelzi, hogy az példány egy megadott nevű klaszterhez tartozik, tehát ez a klaszter feladatokat tud elhelyezni ezen a szerveren. Jelenleg még nem hoztunk létre klasztert, de a létrehozáskor ezt a nevet fogjuk használni.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — a paraméter jelzi, hogy ha jelet kapunk a spott példány leállításáról, akkor minden feladatnak a Draining állapotba kell kerülnie.
ECS_CONTAINER_STOP_TIMEOUT=1m — a paraméter jelzi, hogy a SIGINT jelzés után minden feladatnak 1 perce van, mielőtt leállítják őket.
ECS_ENGINE_AUTH_TYPE=docker — a paraméter jelzi, hogy a hitelesítési mechanizmus a docker séma.
ECS_ENGINE_AUTH_DATA=... — a privát konténer regisztrációhoz való csatlakozási paraméterek, ahol a Docker képeid tárolódnak. Ha az nyilvános, akkor semmit nem kell megadni.
Ebben a cikkben egy nyilvános képet fogok használni a Docker Hub-ból, ezért nem fogok paramétereket megadni. ECS_ENGINE_AUTH_TYPE és ECS_ENGINE_AUTH_DATA nincs szükség rá.
Hasznos tudni: ajánlott rendszeresen frissíteni az AMI-t, mert az új verziókban frissülnek a Docker, Linux, ECS ügynök stb. verziói. Hogy ne felejtsd el, beállíthatod az új verziók megjelenéséről. Mailben kapodh az értesítéseket és manuálisan frissíthetsz, vagy írhatsz egy Lambda-funkciót, amely automatikusan létrehozza az új verziót a Launch Template-hez a frissített AMI-val.
EC2 Auto Scaling Group
Az Auto Scaling Group felelős az példányok indításáért és skálázásáért. A csoportok kezelését az EC2 -> Auto Scaling -> Auto Scaling Groups szakaszban végezzük.
Indítási sablon — válasszuk ki az előző lépésben létrehozott sablont. A verziót hagyjuk alapértelmezettnek.
Vásárlási lehetőségek és példánytípusok — megadjuk a klaszterhez szükséges példánytípusokat. A 'Adhere to launch template' a Launch Template-ből használja a példány típusát. A 'Combine purchase options and instance types' rugalmasan lehetővé teszi a példánytípusok beállítását. Ezt fogjuk használni.
Voluntary On-Demand alap — a normál, nem spott példányok száma, amelyek mindig működni fognak.
On-Demand százalék a bázis felett — a normál és spott példányok százalékos aránya, a 50-50 egyenlően osztja el, a 20-80 esetében minden normál példányhoz 4 spott példány fog felállni. E példában 50-50-et adok meg, de a valóságban a legtöbbször 20-80-at szoktunk csinálni, bizonyos esetekben 0-100 is előfordul.
Példánytípusok — itt megadhatók további példánytípusok, amelyeket a klaszterben használni fognak. Mi sosem használtuk, mert nem igazán értem ennek a történetnek a jelentését. Lehet, hogy a konkrét példánytípusokra vonatkozó korlátozásokkal van összefüggés, de ezeket a támogatás által könnyen meg lehet növelni. Ha tudja, hogy mire lehet használni, örömmel olvasnám a kommentekben.)
Hálózat — hálózati beállítások, válassza ki a VPC-t és a gépek alhálózatait, a legtöbb esetben érdemes az összes elérhető alhálózatot kiválasztani.
Terheléselosztás — terheléselosztó beállítások, de ezt külön fogjuk megcsinálni, itt most semmit sem módosítunk. Egészségügyi ellenőrzések is később lesznek beállítva.
Csoport mérete — megadjuk a korlátozásokat a klaszterben lévő gépek számára és a kívánt gépszámot a kezdetkor. A klaszterben lévő gépek száma soha nem lesz kevesebb a minimálisan megadott mennyiségénél, és nem haladhatja meg a maximálisat, még akkor sem, ha a metrikák szerint skáláznia kellene.
Skálázási irányelvek — skálázási beállítások, de a skálázásunkat az aktív ECS feladatok alapján fogjuk végezni, ezért a skálázást később beállítjuk.
Példányok scale-in védelme — védelem a példányok törlése ellen, ha lefelé skálázunk. Bekapcsoljuk, hogy az ASG ne törölje azokat a gépeket, amelyeken aktív feladatok vannak. A példányok védelmét, ahol nincsenek feladatok, az ECS Capacity Provider fogja kikapcsolni.
Címkék hozzáadása — megadhatók címkék a példányok számára (ehhez a Tag new instances jelölőnégyzetet be kell pipálni). Ajánlom, hogy adjunk meg egy Name címkét, akkor az összes példány, amelyet a csoport keretein belül indítanak, ugyanúgy fog hívódni, és kényelmes lesz nézni őket a konzolban.
A csoport létrehozása után nyissa meg, és lépjen az Advanced configurations részhez, azért, mert a létrehozás szakaszában nem minden lehetőség látható a konzolon.
Törlési irányelvek — olyan szabályok, amelyeket a példányok törlésekor figyelembe vesznek. Ezek sorrendben alkalmazásra kerülnek. Általában olyanokat használunk, mint az alábbi képen látható. Először azokat a példányokat töröljük, amelyek a legöregebb Launch Template-tel rendelkeznek (például, ha frissítettük az AMI-t, létrejön egy új verzió, de minden példány átállt rá). Ezután azok a példányok kerülnek kiválasztásra, amelyek a legközelebb állnak a következő billing időszakhoz. Végül a legöregebb példányok kerülnek választásra a telepítés dátuma szerint.
Hasznos tudni: a klaszterben lévő összes gép frissítéséhez kényelmes használni . Ha ezt ötvözi a korábbi lépés Lambda-funkciójával, akkor egy teljesen automatizált példányfrissítési rendszere lesz. Mielőtt frissítené az összes gépet, ki kell kapcsolni az instance scale-in protection-t az összes példány esetében a csoportban. Nem a csoport beállítását, hanem maguknak a gépeknek a védelmét, ezt az Instance management fülön lehet megtenni.
Application Load Balancer és EC2 Target Group
A terheléselosztót az EC2 → Load Balancing → Load Balancers szakaszban hozzuk létre. Az Application Load Balancer-t fogjuk használni, különböző típusú terheléselosztókról a .
Hallgatók — értelme van, hogy létrehozzon 80 és 443 portokat, és átirányítást állítson be a 80-ról a 443-ra a terheléselosztó szabályaival.
Availability Zones — a legtöbb esetben minden elérhetőségi zónát választunk.
Configure Security Settings — itt adja meg az SSL-tanúsítványt a terheléselosztóhoz, a legkényelmesebb megoldás — az ACM-ben. A különbségekről Security Policy többek között olvashat a , akár a kiválasztott alapértelmezett ELBSecurityPolicy-2016-08. A terheléselosztó létrehozása után meglátja a DNS nevét, amelyhez CNAME-t kell beállítani a domainjéhez. Például így néz ki a Cloudflare-ben.
Security Group — létrehoz vagy kiválaszt egy biztonsági csoportot a terheléselosztóhoz, erről korábban a EC2 Launch Template → Network settings részben írtam.
Target group — egy csoportot hozunk létre, amely felelős a kérdések irányításáért a terheléselosztóról a gépekre, és ellenőrzi azok elérhetőségét, hogy problémák esetén cserélje őket. Target type Instance kell legyen, Protocol és Port bármilyen, ha HTTPS-en keresztül kommunikál a terheléselosztó és a példányok között, akkor közvetlenül kell feltölteni a tanúsítványt. Az adott példában ezt nem fogjuk megtenni, egyszerűen hagyjuk a 80-as portot.
Egészségügyi ellenőrzések — a szolgáltatás működésének ellenőrzési paraméterei. A tényleges szolgáltatásnak egy külön kérésnek kell lennie, amely fontos üzleti logika részeit valósítja meg, az adott példában az alapértelmezett beállításokat fogom hagyni. Ezután választhat intervallumot, időtúllépést, sikeres válasz kódokat stb. A példánkban a Success codes 200-399-at határozunk meg, mivel a használt Docker image 304-es kódot ad vissza.
Register Targets — itt választjuk ki a csoport gépeit, de a mi esetünkben ezt az ECS fogja kezelni, így ezt a lépést egyszerűen kihagyjuk.
Hasznos tudni: a terheléselosztó szintjén engedélyezheti a naplókat, amelyek az S3-ban egy meghatározott helyen kerülnek mentésre. . Innenről exportálhatók elemző szolgáltatásokhoz, vagy SQL lekérdezéseket végezhetünk közvetlenül az S3 adatokra a . Ez kényelmes és nem igényel semmiféle kiegészítő kódot. Azt is javaslom, hogy állítsuk be a naplók törlését az S3 tárolóból a megadott időtartam után.
ECS Task Definition
Az előző lépések során létrehoztuk mindazt, ami a szolgáltatás infrastruktúrájával kapcsolatos, most áttérünk a konténerek leírására, amelyek futtatni fogunk. Ezt az ECS → Task Definitions részben tesszük.
A futtatási típus kompatibilitása — válasszuk az EC2-t.
Task execution IAM role — válasszuk ecsTaskExecutionRole-t.. Ezzel logok íródnak, hozzáférés engedélyeződnek titkos változókhoz, stb.
A Container Definitions részben kattintsunk az Add Container gombra.
Image — a projekt kódját tartalmazó kép hivatkozása, a jelen példa keretében én egy nyilvános képet fogok használni a Docker Hub-ból .
Memory Limits — a konténer memóriahatárai. Hard Limit — kemény határ, ha a konténer túllépi a megadott értéket, a docker kill parancs végrehajtásra kerül, a konténer azonnal leáll. Soft Limit — lágy határ, a konténer túllépheti a megadott értéket, de a feladatok gépre való elhelyezésekor figyelembe veszik ezt a paramétert. Például, ha egy gépen 4 GiB RAM van, és a konténer soft limitje 2048 MiB, akkor maximum 2 ilyen konténer relélt feladat futhat ezen a gépen. Valójában a 4 GiB RAM kicsit kevesebb, mint 4096 MiB, ezt az ECS Instances fülön lehet megnézni a klaszterben. Soft limit nem lehet nagyobb a hard limitnél. Fontos megérteni, hogy ha egy feladatban több konténer van, akkor azok határai összeadódnak.
Port mappings — ehhez tízszer kevesebb hardver szükséges. Host port — megadunk 0-t, ez azt jelenti, hogy a port dinamikusan lesz hozzárendelve, ezt a Target Group fogja figyelni. Container Port — a port, ahol az alkalmazásod fut, gyakran a futtatási parancsban van megadva, vagy a kódodban, Dockerfile-ban stb. A mi példánkban 3000-et használunk, mert ez szerepel a használt képen.
Health check — a konténer működőképességének ellenőrzési paraméterei, ne keverjük össze azzal, amelyet a Target Group-ban állítottunk be.
Environment — a környezeti beállítások. CPU units — hasonlóan a memória korlátokhoz, csak a processzorra vonatkozik. Minden processzormag — 1024 egység, tehát ha a szerveren kétszálú processzor van, és a konténer értéke 512, akkor egy szerveren 4 feladat indítható ezzel a konténerrel. A CPU egységek mindig a magok számát tükrözik, nem lehetnek kicsit kevesebbek, mint a memóriánál.
Parancs — parancs a szolgáltatás elindításához a konténeren belül, minden paramétert vesszővel kell megadni. Ez lehet gunicorn, npm stb. Ha nincs megadva, akkor a Dockerfile CMD irányelv értékét használja. Írjuk be npm,start.
Környezeti változók — a konténer környezeti változói. Ezek lehetnek sima szöveges adatok, valamint titkos változók a vagy .
Tárolás és naplózás — itt beállítjuk a naplózást a CloudWatch Logs-ba (az AWS naplózószolgáltatása). Ehhez elegendő bepipálni az Auto-configure CloudWatch Logs opciót. A Task Definition létrehozása után automatikusan létrejön egy naplócsoport a CloudWatch-ban. Alapértelmezés szerint a naplók végtelen ideig tárolódnak benne, javaslom, hogy módosítsd a Retention period-ot a Never Expire értékről a kívánt időtartamra. Ezt a CloudWatch Log csoportoknál végezheted, kattints a jelenlegi időtartamra, és válassz új értéket.
ECS Cluster és ECS Capacity Provider
Lépjünk az ECS → Clusters részhez, hogy klasztert hozzunk létre. Sablonként válasszuk az EC2 Linux + Networking-ot.
Klaszter neve — nagyon fontos, hogy ugyanezt a nevet adjuk meg, mint a Launch Template paraméterében ECS_CLUSTER, a mi esetünkben — DemoApiClusterProd. Pipáljuk be a Create an empty cluster opciót. Opcionálisan engedélyezhetjük a Container Insights-ot, hogy a CloudWatch-ban nézhessük a szolgáltatások metrikáit. Ha mindent jól csináltál, az ECS Instances részben látni fogod az Auto Scaling csoportban létrehozott gépeket.
Lépjünk a Capacity Providers fülre, és létrehozunk egy újat. Emlékeztetlek, hogy ez arra szolgál, hogy kezeljük a gépek létrehozását és leállítását az aktív ECS feladatok számának megfelelően. Fontos megjegyezni, hogy a szolgáltató csak egy csoporthoz köthető.
Auto Scaling group — válasszuk a korábban létrehozott csoportot.
Kezelt méretezés — kapcsoljuk be, hogy a szolgáltató képes legyen méretezni a szolgáltatást.
Célkapacitás % — mekkora terheltségű gépekre van szükségünk a feladatokhoz. Ha 100%-ot adunk meg, akkor minden gép mindig a futó feladatokkal lesz elfoglalva. Ha 50%-ot adunk meg, akkor a fele gép mindig szabad lesz. Ilyen esetben, ha hirtelen terhelésnövekedés lép fel, az új feladatok azonnal a szabad gépekre kerülnek, anélkül, hogy az instanciák beállítására kellene várni.
Kezelt leállítási védelem — bekapcsoljuk, ez a paraméter lehetővé teszi a szolgáltató számára, hogy eltávolítsa az instanciák törlés elleni védelmét. Ez akkor történik, amikor a gépen nincsenek aktív feladatok, és lehetővé teszi a Target capacity % beállítását.
ECS Szolgáltatás és a skálázási beállítások
Utolsó lépés :) A szolgáltatás létrehozásához lépjünk a korábban létrehozott klaszterre a Szolgáltatások fülre.
Indítási típus — kattintsunk a Kapacitáson alapuló stratégia váltására és válasszuk ki a korábban létrehozott szolgáltatót.
Feladat definíció — válasszuk ki a korábban létrehozott Feladat definíciót és annak revízióját.
Szolgáltatás neve — hogy ne zavarodjunk össze, mindig ugyanazt adjuk meg, mint a Feladat definíció.
Szolgáltatás típusa — mindig Replika.
Feladatok száma — a kívánt aktív feladatok száma a szolgáltatásban. Ezt a paramétert a skálázás irányítja, de akkor is meg kell adni.
Minimális egészséges százalék és Maximális százalék — meghatározzák a feladatok viselkedését telepítés során. Az alapértelmezett értékek 100 és 200, ami azt jelenti, hogy a telepítés pillanatában a feladatok száma megduplázódik, majd visszatér a kívánt értékhez. Ha 1 feladat fut, min=0 és max=100, akkor a telepítéskor az elpusztul, és aztán újraindul egy új, tehát lesz állásidő. Ha 1 feladat fut, min=50, max=150, akkor a telepítés egyáltalán nem fog megtörténni, mert az 1 feladatot nem lehet felezni vagy másfél szorosára növelni.
Telepítési típus — hagyjuk Rolling update.
Elhelyezési sablonok — a feladatok gépekre való elhelyezésének szabályai. Az alapértelmezett AZ Balanced Spread — ez azt jelenti, hogy minden új feladat egy új instanciára kerül, amíg a gépek minden elérhetőségi zónában fel nem állnak. Mi általában BinPack — CPU és Spread — AZ-t csinálunk, ennél a politikánál a feladatok a lehető legszorosabban kerülnek elhelyezésre egy gépen a CPU szerint. Ha új gép létrehozása szükséges, az új elérhetőségi zónában jön létre.
Terheléselosztó típusa — válasszuk az Alkalmazás terheléselosztót.
Szolgáltatás IAM szerep — válasszuk a ecsServiceRole.
Terheléselosztó neve — válasszuk a korábban létrehozott terheléselosztót.
Egészségügyi ellenőrzési türelmi idő — szünet az új feladat telepítése után az egészségügyi ellenőrzések végrehajtása előtt, mi általában 60 másodpercet állítunk be.
Konténer a terheléselosztáshoz — a Target group name pontban válasszuk ki a korábban létrehozott csoportot, és minden automatikusan ki fog töltődni.
Szolgáltatás Automatikus Méretezés — a szolgáltatás méretezési paraméterei. Válasszuk a Szolgáltatás Automatikus Méretezés konfigurálása lehetőséget a szolgáltatás kívánt számának beállításához. Állítsuk be a minimális és maximális feladatok számát a méretezéshez.
IAM szerep a Szolgáltatás Automatikus Méretezéshez — válasszuk a AWSServiceRoleForApplicationAutoScaling_ECSService.
Automatikus feladat méretezési szabályok — szabályok a méretezéshez. Két típus létezik:
- Célzott nyomkövetés — a cél metrika (CPU/RAM kihasználás vagy kérdések száma minden feladatnál) nyomkövetése. Például, ha azt akarjuk, hogy a CPU átlagos terhelése 85% legyen, amikor ez meghaladja, új feladatok kerülnek hozzáadásra, amíg el nem éri a célértéket. Ha a terhelés alacsonyabb, akkor a feladatokat éppen ellenkezőleg eltávolítják, ha nincs bekapcsolva a lefelé méretezés védelme (Lefelé méretezés letiltása).
- Lépés alapú méretezés — reakció bármilyen eseményre. Itt beállíthatjuk a reakciót bármilyen eseményre (CloudWatch Alarm), amikor az bekövetkezik, megadhatunk vagy eltávolíthatunk egy meghatározott számú feladatot, vagy megadhatjuk a pontos feladatok számát.
A szolgáltatásnak lehet több méretezési szabálya, ez hasznos lehet, fontos figyelni, hogy ne ütközzenek egymással.
Zárás
Ha követted az útmutatót, és ugyanazt a Docker imázst használtad, a szolgáltatásodnak ennek az oldalnak kell megjelenítenie.
- Létrehoztunk egy sablont, amely alapján minden gép elindul a szolgáltatásban. Megtanultuk frissíteni a gépeket a sablon módosítása esetén is.
- Beállítottuk a spot példány leállító jelének kezelését, így a jelzés kézhez vétele után egy percen belül az összes futó feladat eltávolításra kerül a gépről, ezáltal semmi nem vész el és nem szakad meg.
- Felemelkedtünk egy terheléselosztót, hogy egyenletesen elosszuk a terhelést a gépek között.
- Létrehoztunk egy szolgáltatást, amely spot példányokon működik, ezzel a gépek költségét körülbelül 3-szor csökkentjük.
- Automatikus méretezést állítottunk be mindkét irányba, hogy kezeljük a terhelés növekedését, de ugyanakkor ne fizessünk az üresjáratért.
- Kapacitás Szolgáltatót használunk, hogy az alkalmazás kezelje az infrastruktúrát (gépeket), és ne fordítva.
- Jól csináltuk.
Ha előre látható terhelésugrásaid vannak, például egy nagy email kampányt hirdetsz, beállíthatod a méretezést a .
További lehetőség a rendszered különböző részeiből származó adatok alapján történő skálázás. Például van funkciónk mobilalkalmazás felhasználóinak. Néha a kampány 1M+ emberhez jut el. Egy ilyen küldést követően mindig jelentős növekedés tapasztalható az API-hívások számában, mivel sok felhasználó egyszerre lép be az alkalmazásba. Ha tehát azt látjuk, hogy a promóciós push üzenetek küldésére várakozó sorban jelentősen több van a szokásos mutatókhoz képest, azonnal több gépet és feladatot indíthatunk, hogy felkészültek legyünk a terhelésre.
Örömmel várom, ha a megjegyzésekben érdekes spott infrastrukturális és ECS használati esettanulmányokat osztotok meg, vagy bármi a skálázásról.
Hamarosan cikkek fognak megjelenni arról, hogyan kezelünk ezer analitikai eseményt másodpercenként döntően serverless stack-en (pénzért), és hogyan valósítjuk meg a szolgáltatások telepítését a GitLab CI és a Terraform Cloud segítségével.
Kövesd a munkánkat, érdekes lesz!
Csak a regisztrált felhasználók vehetnek részt a szavazáson. , kérem.
Használjátok spot instance-eket a produkcióban?
22,2%Igen6
66,7%Nem 18
11,1%Cikkből tudtam meg róluk, tervezem a használatukat.
27 felhasználó szavazott. 5 felhasználó tartózkodott.
Forrás: habr.com
