Ўсім прывітанне! Мяне клічуць Кірыл, я CTO ў Adapty. Большая частка нашай архітэктуры знаходзіцца на AWS, і сёння я раскажу пра тое, як мы скарацілі выдаткі на серверы ў 3 разы за кошт выкарыстання спотавых інстансаў на прадакшн асяроддзі, а таксама пра тое, як наладзіць іх аўтамаштабаванне. Спачатку будзе агляд таго, як гэта працуе, а потым падрабязная інструкцыя для запуску.
Што такое спотавыя інстансы?
інстансы – гэта серверы іншых карыстачоў AWS, якія ў дадзены момант прастойваюць, і яны прадаюць іх з вялікай зніжкай (Amazon піша да 90%, па нашым досведзе ~3x, вар'іруецца ў залежнасці ад рэгіёна, AZ і тыпу інстанса). Асноўнае іх адрозненне ад звычайных у тым, што яны могуць выключыцца ў любы момант. Таму мы доўгі час лічылі, што іх нармальна выкарыстоўваць для дзеў асяродкаў, альбо для задач па разліку чагосьці, з захаваннем прамежкавых вынікаў на S3 ці ў базу, але не для прода. Існуюць іншыя рашэнні, якія дазваляюць выкарыстоўваць споты на продзе, але там для нашага кейса шмат мыліц, таму мы не ўкаранялі іх. Падыход, апісаны ў артыкуле, працуе цалкам у рамках стандартнага функцыяналу AWS, без дадатковых скрыптоў, кронаў і тд.
Далей прывяду некалькі скрыншотаў, якія паказваюць гісторыю коштаў на спотавыя інстансы.
m5.large у рэгіёне eu-west-1 (Ireland). Кошт пераважна стабільная на працягу 3 месяцаў, у сапраўдны момант эканомія 2.9x.
m5.large у рэгіёне us-east-1 (N. Virginia). Кошт увесь час змяняецца на працягу 3 месяцаў, у сапраўдны момант эканомія ад 2.3x да 2.8x у залежнасці ад зоны даступнасці.
t3.small ў рэгіёне us-east-1 (N. Virginia). Кошт стабільны на працягу 3 месяцаў, у сапраўдны момант эканомія 3.4x.
Архітэктура сэрвісу
Базавая архітэктура сэрвісу, пра які мы будзем казаць у рамках дадзенага артыкула, намалявана на дыяграме ніжэй.
Application Load Balancer → EC2 Target Group → Elastic Container Service
У якасці балансіра выкарыстоўваецца Application Load Balancer (ALB), які адпраўляе запыты мэтавай групе EC2 (TG). TG адказвае за адкрыццё партоў на асобніках для ALB і падключэнне іх да партоў кантэйнераў Elastic Container Service (ECS). ECS - гэта аналаг Kubernetes у AWS, які кіруе кантэйнерамі Docker.
На адным інстансе можа быць некалькі працавальных кантэйнераў з аднолькавымі партамі, таму мы не можам задаць іх фіксавана. ECS паведамляе TG, што ён запускае новы цяг (у тэрміналогіі Kubernetes гэта называецца пад), яна робіць праверку свабодных партоў на інстансе і прызначае адзін з іх для цяга, які запускаецца. Таксама TG рэгулярна правярае, ці працуе інстанс і апі на ім з дапамогай health check, і калі бачыць нейкія праблемы, то перастае перадаваць туды запыты.
EC2 Auto Scaling Groups + ECS Capacity Providers
У прыведзенай вышэй дыяграме не паказаны сэрвіс EC2 Auto Scaling Groups (ASG). З назвы можна зразумець, што ён адказвае за маштабаванне інстансаў. Пры гэтым да нядаўняга часу ў AWS не было ўбудаванай магчымасці кіраваць колькасцю запушчаных машын з ECS. ECS дазваляў маштабаваць колькасць цягінаў, напрыклад, па выкарыстанні CPU, RAM ці колькасці запытаў. Але калі цягі займалі ўсе вольныя інстансы, то новыя машыны аўтаматычна не паднімаліся.
Гэта змянілася са з'яўленнем ECS Capacity Providers (ECS CP). Цяпер кожны сэрвіс у ECS можна звязаць з ASG, і калі цягі не змяшчаюцца на якія працуюць інстансах, то паднімуцца новыя (але ў рамках усталяваных лімітаў ASG). Гэта працуе і ў зваротны бок, калі ECS CP бачыць якія прастойваюць інстансы без цягачаў, то ён дасць каманду ASG, каб яна іх выключыла. У ECS CP ёсць магчымасць паказаць мэтавай адсотак загрузкі інстансаў, так, каб некаторая колькасць машын было заўсёды вольна для хуткага маштабавання цягачаў, распавяду пра гэта крыху пазней.
EC2 Launch Templates
Апошні сэрвіс, аб якім я распавяду, перш чым перайсці да падрабязнага апісання стварэння дадзенай інфраструктуры, – EC2 Launch Templates. Ён дазваляе стварыць шаблон, па якім будуць запускацца ўсе машыны, каб не паўтараць гэта кожны раз з нуля. Тут можна абраць тып якая запускаецца машыны, групу бяспекі, выява дыска і шмат іншых параметраў. Таксама можна пазначыць карыстацкія дадзеныя, якія будуць залітыя на ўсе якія запускаюцца інстансы. У карыстацкіх дадзеных можна запускаць скрыпты, напрыклад, можна адрэдагаваць змесціва файла .
Адзін з найболей важных у рамках дадзенага артыкула параметрам канфігурацыі. = праўда. Калі гэты параметр уключаны, то, як толькі ECS атрымлівае сігнал аб адабранні спотавага асобніка, ён пераводзіць усе задачы, якія над ім працуюць, у статус "Сліў". Ніякія новыя задачы не будуць прызначаныя для гэтага асобніка; калі ёсць задачы, якія хочуць разгарнуць на ім прама зараз, яны будуць адменены. Таксама перастаюць паступаць запыты ад балансіраў. Апавяшчэнне аб выдаленні экземпляра прыходзіць за 2 хвіліны да самой падзеі. Такім чынам, калі ваш сэрвіс не выконвае задачы больш за 2 хвіліны і нічога не захоўвае на дыск, то вы можаце выкарыстоўваць кропкавыя асобнікі без страты дадзеных.
Наконт дыска — AWS нядаўна магчымым выкарыстанне Elastic File System (EFS) разам з ECS, з гэтай схемай нават кружэлка не з'яўляецца перашкодай, але мы гэта не спрабавалі, бо ў прынцыпе нам кружэлка не патрэбен для захоўвання стану. Па змаўчанні пасля атрымання SIGINT (адпраўляецца ў момант перакладу цяга ў статут Draining) усе працавальныя задачы будуць спыненыя праз 30 секунд, нават калі яны не паспелі выканацца, змяніць гэты час можна з дапамогай параметру . Галоўнае не выстаўляць яго больш за 2 хвіліны для спотавых машын.
Стварэнне сэрвісу
Пераходзім непасрэдна да стварэння апісанага сэрвісу. У працэсе я апішу дадаткова некалькі карысных момантаў, пра якія не гаварылася вышэй. У цэлым гэта пакрокавая інструкцыя, але нейкія зусім базавыя ці наадварот вельмі спецыфічныя кейсы я не буду разглядаць. Усе дзеянні выконваюцца ў візуальнай кансолі AWS, але іх можна прайграць праграмна з дапамогай CloudFormation ці Terraform. У Adapty мы выкарыстоўваем Terraform.
EC2 Launch Template
У дадзеным сэрвісе ствараецца канфігурацыя машын, якія будуць выкарыстоўвацца. Кіраванне шаблонамі адбываецца ў раздзеле EC2 -> Instances -> Launch templates.
Вобраз машыны Amazon (AMI) - паказваем выяву дыска, з якім будуць запускацца ўсе інстансы. Для ECS у большасці выпадкаў варта выкарыстоўваць аптымізаваную выяву ад Amazon. Ён рэгулярна абнаўляецца і змяшчае усё неабходнае для працы ECS. Каб даведацца пра актуальны ID выявы, заходзім на старонку , выбіраем які выкарыстоўваецца рэгіён і капіюем AMI ID для яго. Напрыклад, для рэгіёну us-east-1 актуальны на момант напісання артыкула ID. ami-00c7c1cf5bdc913ed. Гэты ID трэба ўставіць у пункт Specify a custom value.
Тып асобніка - паказваем тып інстансу. Выбіраеце той, які лепш за ўсё падыходзіць для вашай задачы.
Key pair (login) - паказваем сертыфікат, з дапамогай якога можна будзе падлучыцца з инстансу па SSH, калі гэта трэба.
сеткавыя налады — задаць параметры сеткі. Networking platform у большасці выпадкаў павінна быць Virtual Private Cloud (VPC). Групы бяспекі - групы бяспекі для вашых інстансаў. Бо мы будзем выкарыстоўваць балансавальнік перад інстансамі, то рэкамендую паказваць тут групу, якая дазваляе ўваходныя злучэнні толькі з балансавальніка. Гэта значыць у вас будзе 2 групы бяспекі, адна для балансавальніка, якая дазваляе ўваходныя (inbound) злучэнні адусюль па партах 80 (http) і 443 (https), а другая для машын, якая дазваляе ўваходныя злучэнні па любых партах ад групы балансавальніка. Выходныя (outbound) злучэнні ў абедзвюх групах трэба адкрыць па TCP пратаколе на ўсе парты на ўсе адрасы. Можна абмежаваць парты і адрасы для выходных злучэнняў, але тады трэба ўвесь час маніторыць, што вы не спрабуеце звярнуцца кудысьці па зачыненым порце.
Сховішча (тамы) - паказваем параметры дыскаў для машын. Аб'ём дыска не можа быць менш за тое, што зададзены ў AMI, для ECS Optimized – 30 GiB.
Дадатковая інфармацыя - паказваем дадатковыя параметры.
Purchasing option - Ці жадаем мы купляць спотавыя інстансы. Мы жадаем, але тут гэтую галачку адзначаць не будзем, наладзім гэта ў Auto Scaling Group, тамака больш опцый.
IAM instance profile - паказваем ролю, з якой будуць запускаць інстансы. Для таго, каб інстансы працавалі ў ECS, ім патрэбны правы, якія звычайна ляжаць у ролі ecsInstanceRole. У некаторых выпадках яна можа быць створана, калі не, то тут аб тым, як гэта зрабіць. Пасля стварэння паказваем яе ў шаблоне.
Далей ідзе шмат параметраў, у асноўным усюды можна пакідаць дэфолтныя значэнні, але ў кожнага з іх зразумелае апісанне. Я заўсёды ўключаю параметры EBS-optimized instance і T2/T3 Unlimited, калі выкарыстоўваюцца інстансы.
Дадзеныя карыстальніка - паказваем карыстацкія дадзеныя. Мы будзем рэдагаваць файл /etc/ecs/ecs.config, У якім ляжыць канфігурацыя агента ECS.
Прыклад таго, як можа выглядаць user data:
#!/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 - параметр паказвае, што інстанс прыналежыць кластару з зададзеным імем, гэта значыць гэты кластар зможа размяшчаць на гэтым серверы свае цягі. Мы пакуль не стварылі кластар, але пры стварэнні будзем выкарыстоўваць гэтае імя.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — параметр вызначае, што пры атрыманні сігналу аб адключэнні спотавага асобніка ўсе задачы на ім павінны быць пераведзены ў статус Сліў.
ECS_CONTAINER_STOP_TIMEOUT=1m - Параметр паказвае, што пасля атрымання сігналу SIGINT, ва ўсіх задач ёсць 1 хвіліны, перш чым іх заб'юць.
ECS_ENGINE_AUTH_TYPE=docker - параметр паказвае, што ў якасці механізму аўтарызацыі выкарыстоўваецца docker-схема
ECS_ENGINE_AUTH_DATA=... - Параметры падлучэння да прыватнага container registry, дзе захоўваюцца вашыя Docker вобразы. Калі ён публічны, то нічога ўказваць не трэба.
У рамках дадзенага артыкула я буду выкарыстоўваць публічную выяву з Docker Hub, таму паказваць параметры ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ня трэба.
карысна ведаць: рэкамендуецца рэгулярна абнаўляць AMI, таму што ў новых версіях абнаўляюцца версіі Docker, Linux, ECS агента і інш. Каб не забываць пра гэта, можна аб выхадзе новых версій. Вы можаце атрымліваць апавяшчэнні на email і абнаўляць рукамі, а можаце напісаць Lambda-функцыю, якая будзе аўтаматычна ствараць новую версію Launch Template з абноўленым AMI.
EC2 Auto Scaling Group
Auto Scaling Group адказвае за запуск і маштабаванне інстансаў. Кіраванне групамі адбываецца ў раздзеле EC2 -> Auto Scaling -> Auto Scaling Groups.
Launch template - выбіраемы створаны на папярэднім кроку шаблон. Версію пакідаем дэфолтную.
Purchase options and instance types - паказваем тыпы інстанс для кластара. Adhere to launch template выкарыстоўвае тып інстанса з Launch Template. Combine purchase options and instance types дазваляе гнутка наладжваць тыпы інстансаў. Мы будзем выкарыстоўваць яго.
Optional On-Demand base - колькасць звычайных, не спотавых інстанс, якія заўсёды будуць працаваць.
On-Demand percentage above base - працэнтныя суадносіны звычайных і спотавых інстансаў, 50-50 будзе размяркоўваць пароўну, 20-80 на кожны звычайны інстанс будзе падымацца 4 спотавых. У рамках дадзенага прыкладу я пакажу 50-50, але ў рэальнасці мы часцей за ўсё які робіцца 20-80, у некаторых выпадках 0-100.
Тыпы асобнікаў - Тут можна паказаць дадатковыя тыпы інстанс, якія будуць выкарыстоўвацца ў кластары. Мы ніколі не выкарыстоўвалі, таму што я не вельмі разумею сэнс гэтай гісторыі. Магчыма справа ў ліміту на канкрэтныя тыпы інстанс, але яны павялічваюцца праз падтрымку лёгка. Калі вы ведаеце прымяненне, буду рады прачытаць у каментарах)
сетка - налады сеткі, выбіраеце VPC і падсеткі для машын, у большасці выпадкаў варта абраць усе даступныя падсеткі.
Балансаванне нагрузкі - налады балансавальніка, але мы гэта зробім асобна, тут нічога не чапаем. Праверкі стану здароўя таксама будзе наладжана пазней.
Памер групы - паказваем ліміты на колькасць машын у кластары і жаданую колькасць машын на старце. Колькасць машын у кластары ніколі не стане менш мінімальна паказанага і больш максімальнага, нават калі па метрыках павінна адбыцца маштабаванне.
Scaling policies - Параметры маштабаванне, але мы будзем маштабаваць, адштурхваючыся ад запушчаных ECS цягачаў, таму наладзім маштабаванне пазней.
Instance scale-in protection - абарона інстанс ад выдалення пры маштабаванні ўніз. Уключаем, каб ASG не выдаліла машыну, на якой ёсць працавальныя цягі. Адключаць абарону для інстансаў, на якіх няма цягачаў, будзе ECS Capacity Provider.
Дадаць тэгі - можна паказаць тэгі для інстансаў (для гэтага павінна стаяць галачка Tag new instances). Рэкамендую пазначыць тэг Name, тады ўсе інстансы, якія запускаюцца ў рамках групы, будуць аднолькава звацца, іх зручна глядзець у кансолі.
Пасля стварэння групы адкрыйце яе і зайдзіце ў раздзел Advanced configurations, чаму на этапе стварэння ў кансолі бачныя не ўсе опцыі.
Termination policies - правілы, якія ўлічваюцца пры выдаленні інстансаў. Яны прымяняюцца па парадку. Мы звычайна выкарыстоўваем такія, як на малюнку ніжэй. Спачатку выдаляюцца інстансы з найболей старым Launch Template (напрыклад, калі мы абнавілі AMI, у нас стварылася новая версія, але ўсе інстансы паспелі на яе перайсці). Потым выбіраюцца інстансы, якія бліжэй за ўсё да наступнай разліковай гадзіны па білінгу. І далей выбіраюцца самыя старыя па даце запуску.
карысна ведаць: абнавіць усе машыны ў кластары, зручна ў выкарыстанні . Калі сумясціць гэта з Lambda-функцыяй з папярэдняга кроку, то ў вас будзе цалкам аўтаматызаваная сістэма апдэйта інстансаў. Перад абнаўленнем усіх машын неабходна адключыць instance scale-in protection для ўсіх інстансаў у групе. Ці не наладу ў групе, а менавіта абарону з саміх машын, гэта робіцца на ўкладцы Instance management.
Application Load Balancer і EC2 Target Group
Балансір ствараецца ў раздзеле EC2 → Load Balancing → Load Balancers. Мы будзем выкарыстоўваць Application Load Balancer; параўнанне розных тыпаў балансіраў можна прачытаць тут .
слухачы - мае сэнс зрабіць 80 і 443 парты і зрабіць рэдырэкт з 80 на 443 з пазней дапамогай правіл балансавальніка.
Зоны даступнасці — у большасці выпадкаў выбіраем зоны даступнасці для ўсіх.
Наладзьце параметры бяспекі - тут паказваецца SSL-сертыфікат для балансавальніка, самы зручны варыянт - у ACM. Пра адрозненні палітыка бяспекі можна пачытаць у , можна пакідаць абраны па змаўчанні ELBSecurityPolicy-2016-08. Пасля стварэння балансавальніка, вы ўбачыце яго Імя DNS, на які неабходна наладзіць CNAME для вашага дамена. Напрыклад, дык гэта выглядае ў Cloudflare.
Група бяспекі — стварыць або выбраць групу бяспекі для балансіра, я пісаў пра гэта крыху вышэй у раздзеле «Шаблон запуску EC2 → Налады сеткі».
Мэтавая група - ствараем групу, якая адказвае за роўтынг запытаў з балансавальніка на машыны і правярае іх даступнасць, каб замяніць у выпадку праблем. Мэта тыпу павінен быць Instance, пратакол и Порт любыя, калі вы выкарыстоўваеце HTTPS для зносін паміж балансавальнікам і інстансамі, то на іх трэба загрузіць сертыфікат. У рамках дадзенага прыкладу мы гэта рабіць не будзем, проста пакінем 80 порт.
Праверкі стану здароўя — параметры праверкі працаздольнасці сэрвісу. У рэальным сэрвісе гэта павінен быць асобны запыт, які рэалізуе важныя часткі бізнес-логікі; для мэт гэтага прыкладу я пакіну налады па змаўчанні. Далей вы можаце выбраць інтэрвал запыту, тайм-аўт, коды поспеху і г. д. У нашым прыкладзе мы пазначым коды поспеху 200-399, таму што вобраз Docker, які будзе выкарыстоўвацца, вяртае код 304.
Register Targets — тут падбіраюцца машыны для групы, але ў нашым выпадку гэта будзе рабіць ECS, таму мы проста прапускаем гэты крок.
карысна ведаць: на ўзроўні балансавальніка можна ўключыць логі, якія будуць захоўвацца ў S3 у вызначаным . Адтуль іх можна экспартаваць у іншыя сэрвісы для аналітыкі, а можна рабіць SQL-запыты прама па дадзеных у S3 з . Гэта зручна і працуе без нейкага дадатковага кода. Таксама рэкамендую наладзіць выдаленне логаў з бакета S3 па заканчэнне зададзенага перыяду часу.
ECS Task Definition
На папярэдніх кроках мы стварылі ўсё, што звязана з інфраструктурай сэрвісу, зараз пераходзім да апісання кантэйнераў, якія мы будзем запускаць. Гэта робіцца ў раздзеле ECS → Task Definitions.
Launch type compatibility - выбіраемы EC2.
Task execution IAM role - Выбіраемы ecsTaskExecutionRole. З дапамогай яе пішуцца логі, даецца доступ да сакрэтных пераменных і інш.
У падзеле Container Definitions націскаем Add Container.
малюнак — спасылка на выяву з кодам праекту, у рамках дадзенага прыкладу я буду выкарыстоўваць публічную выяву з Docker Hub .
Абмежаванні памяці - ліміты па памяці для кантэйнера. Жорсткая мяжа - жорсткі ліміт, калі кантэйнер выйдзе за азначанае значэнне, то выканаецца каманда docker kill, кантэйнер адразу ж памрэ. Мяккі ліміт - мяккі ліміт, кантэйнер можа выйсці за азначанае значэнне, але пры гэтым пры размяшчэнне цягліц на машыны будзе ўлічвацца гэты параметр. Напрыклад, калі на машыне 4 GiB аператыўнай памяці, а soft limit кантэйнера – 2048 MiB, то на гэтай машыне можа быць максімум 2 запушчаных цяга з гэтым кантэйнерам. У рэальнасці 4 GiB аператыўнай памяці – гэта крыху менш, чым 4096 MiB, гэта можна паглядзець на ўкладцы ECS Instances ў кластары. Soft limit не можа быць больш hard limit. Важна разумець, што калі ў адным цягу ёсць некалькі кантэйнераў, то іх ліміты сумуюцца.
Port mappings - у Порт хоста паказваем 0, гэта значыць, што порт будзе прызначацца дынамічна, яго будзе адсочваць Target Group. Container Port - порт, на якім працуе ваша прыкладанне, часта задаецца ў камандзе для выканання, альбо прызначаецца ў кодзе вашага прыкладання, Dockerfile і тд. Для нашага прыкладу выкарыстоўваем 3000, таму што ён пазначаны ў выкарыстоўваецца выявы.
Праверка стану здароўя - Параметры праверкі працаздольнасці кантэйнера, не блытаць з тым, які настроены ў Target Group.
Environment - Налады асяроддзя. CPU units - падобна на Memory limits, толькі пра працэсар. Кожнае ядро працэсара - 1024 юнітаў, так што калі на серверы двух'ядравы працэсар, і ў кантэйнера варта значэнне 512, то на адным серверы можа быць запушчана 4 цяга з гэтым кантэйнерам. CPU units заўсёды адпавядаюць колькасці ядраў, іх не можа быць крыху менш як у выпадку з памяццю.
Каманда - каманда для запуску сэрвісу ўнутры кантэйнера, усе параметры паказваюцца праз коску. Гэта можа быць gunicorn, npm і тд. Калі не пазначана, то будзе скарыстана значэнне дырэктывы CMD з Dockerfile. Паказваем npm,start.
Пераменныя асяроддзя - зменныя асяроддзі кантэйнера. Гэта могуць быць як проста тэкставыя дадзеныя, так і сакрэтныя зменныя з або .
Storage and Logging - тут наладзім лагіраванне ў CloudWatch Logs (сэрвіс для логаў ад AWS). Для гэтага дастаткова ўключыць галачку Auto-configure CloudWatch Logs. Пасля стварэння Task Definition аўтаматычна створыцца група логаў у CloudWatch. Па змаўчанні логі ў ёй захоўваюцца бясконца, рэкамендую змяніць Retention period з Never Expire на патрабаваны тэрмін. Гэта робіцца ў CloudWatch Log groups, трэба клікнуць на бягучы перыяд і абраць новы.
ECS Cluster і ECS Capacity Provider
Пераходзім у раздзел ECS → Clusters, каб стварыць кластар. У якасці шаблона выбіраемы EC2 Linux + Networking.
Cluster name - вельмі важна, які робіцца тут такое ж імя, як паказана ў Launch Template у параметры ECS_CLUSTER, у нашым выпадку - DemoApiClusterProd. Адзначаем галачку Create an empty cluster. Апцыянальна можна ўключыць Container Insights, каб глядзець метрыкі па сэрвісах у CloudWatch. Калі вы ўсё зрабілі правільна, то ў падзеле ECS Instances вы ўбачыце машыны, якія былі створаны ў Auto Scaling group.
Пераходзім на ўкладку Capacity Providers і ствараем новы. Нагадаю, што ён патрэбен для таго, каб кіраваць стварэннем і выключэннем машын у залежнасці ад колькасці працавальных ECS цягачаў. Важна адзначыць, што правайдэр можа быць прывязаны толькі да адной групы.
Auto Scaling group — выбраць раней створаную групу.
Кіраванае маштабаванне - уключаем, каб правайдэр мог маштабаваць сэрвіс.
Target capacity% - які працэнт загрузкі машын цягамі нам патрэбен. Калі паказаць 100%, то ўсе машыны заўсёды будзе занятыя працавальнымі цягамі. Калі ўказаць 50%, то палова машын заўсёды будуць свабоднымі. У такім выпадку, калі здарыцца рэзкі скачок у нагрузцы, новыя таксі адразу патрапяць на вольныя машыны, без неабходнасці чакаць разгортванні інстансаў.
Managed termination protection - уключаем, гэты параметр дазваляе правайдэру прыбіраць абарону інстансаў ад выдалення. Гэта адбываецца, калі на машыне няма актыўных цягоў і дазваляе Target capacity%.
Служба ECS і налада маштабавання
Апошні крок:) Каб стварыць сэрвіс, трэба зайсці ў створаны раней кластар на ўкладку Services.
Launch type — неабходна націснуць на стратэгію «Пераключыцца на стратэгію пастаўшчыка магутнасці» і выбраць створаных раней пастаўшчыкоў.
Task Definition - выбіраемы створаны ранняе Task Definition і яго рэвізію.
служба імёнаў - каб не блытацца, мы заўсёды паказваем такі ж, як Task Definition.
Тып сэрвісу - заўсёды Replica.
Колькасць заданняў - жаданае колькасць актыўных цягачаў у сэрвісе. Гэты параметр кіруецца маштабаваннем, але ўсё роўна яго трэба паказаць.
Minimum healthy percent и Максімальны працэнт — вызначыць паводзіны задач падчас разгортвання. Значэнні па змаўчанні - 100 і 200, якія паказваюць, што падчас разгортвання колькасць задач павялічыцца ў некалькі разоў, а затым вернецца да жаданага значэння. Калі ў вас запушчана 1 задача, min=0 і max=100, то падчас разгортвання яна будзе забіта, а пасля гэтага будзе паднятая новая, гэта значыць будзе прастой. Калі запушчана 1 задача, min=50, max=150, то разгортвання не адбудзецца наогул, таму што 1 задачу нельга падзяліць напалову або павялічыць у паўтара раза.
Тып разгортвання - пакідаем Rolling update.
Placement Templates - правілы размяшчэння цягінаў на машынах. Па змаўчанні варта AZ Balanced Spread – гэта значыць, хто кожны новы таск будзе змяшчацца на новы інстанс датуль, пакуль не паднімуцца машыны ва ўсіх зонах даступнасці. Мы звычайна робім BinPack - CPU і Spread - AZ, пры такой палітыцы цягі змяшчаюцца максімальна шчыльна па на адну машыну па CPU. Пры неабходнасці стварэння новай машыны яна ствараецца ў новай зоне даступнасці.
Load balancer type - выбіраемы Application Load Balancer.
Service IAM role - выбіраемы ecsServiceRole.
Load balancer name - Выбіраемы створаны раней балансавальнік.
Health check grace period — паўза перад выкананнем праверкі спраўнасці пасля разгортвання новай задачы, мы звычайна ўсталёўваем яе на 60 секунд.
Container to load balance - У пункце Target group name выбіраем створаную раней групу, і ўсё аўтаматычна запоўніцца.
Service Auto Scaling - Параметры маштабавання сэрвісу. Выбіраемы Configure Service Auto Scaling для таго, каб палепшыць вашы паслугі з заняпаду count. Задаём мінімальную і максімальна колькасць цягінаў пры маштабаванні.
Роля IAM для аўтаматычнага маштабавання службы - выбіраемы AWSServiceRoleForApplicationAutoScaling_ECSService.
Automatic task scaling policies - правілы для маштабавання. Ёсць 2 тыпу:
- Адсочванне мэты - Адсочванне мэтавай метрыкі (выкарыстанне CPU / RAM або колькасць запытаў на кожны таск). Напрыклад, мы хочам сярэднюю загрузку працэсара была 85%, калі яна стане вышэй, то новыя цягі будуць дадавацца да таго часу, пакуль яна не прыйдзе да мэтавага значэння. Калі загрузка ніжэй, то цягі наадварот будуць прыбірацца, калі не ўключана абарона ад маштабавання ўніз (Disable scale-in).
- Step scaling - Рэакцыя на адвольнае падзея. Тут можна наладзіць рэакцыю на любую падзею (CloudWatch Alarm), калі яна будзе адбывацца, можна дадаць ці прыбраць паказаную колькасць цягінаў, ці ж паказаць дакладную колькасць цягачаў.
У сэрвісу можа быць некалькі правілаў маштабавання, гэта можа спатрэбіцца, галоўнае, каб яны не супярэчылі адзін аднаму.
Заключэнне
Калі вы прытрымліваліся інструкцыі і выкарыстоўвалі той жа Docker выява, ваш сэрвіс павінен вяртаць такую старонку.
- Мы стварылі шаблон, па якім запускаюцца ўсе машыны ў сэрвісе. Мы таксама даведаліся, як абнаўляць машыны пры змене шаблону.
- Мы наладзілі апрацоўку сігналу прыпынку спотавага інстанса, таму на працягу хвіліны пасля яго атрымання ўсе працавальныя цягі прыбіраюцца з машыны, такім чынам нічога не губляецца і не перарываецца.
- Мы паднялі балансір, каб раўнамерна размеркаваць нагрузку на машыны.
- Мы стварылі сэрвіс, які працуе на спотавых інстансах, за кошт гэтага скарачаюцца выдаткі на машыны прыкладна ў 3 разы.
- Мы настроілі аўтамаштабаванне ў абодва бакі, каб апрацоўваць павелічэнне нагрузак, але ў той жа час не плаціць за просты.
- Мы выкарыстоўваем Capacity Provider, каб прыкладанне кіравала інфраструктурай (машынамі), а не наадварот.
- Мы малайцы.
Калі ў вас ёсць прадказальныя ўсплёскі нагрузкі, напрыклад, вы рэкламуецеся ў вялікай email-рассылцы, вы можаце наладзіць маштабаванне па .
Яшчэ можна рабіць маштабаванне на аснове дадзеных з розных частак вашай сістэмы. Напрыклад, у нас ёсць функцыянал карыстальнікам мабільнага прыкладання. Часам кампанія рассылаецца на 1М+ чалавек. Пасля такой рассылкі заўсёды назіраецца вялікі рост запытаў да API, бо шмат карыстачоў адначасова заходзяць у дадатак. Так што калі мы бачым, што ў чарзе на адпраўку прома-пушай іх стала значна больш стандартных паказчыкаў, мы адразу можам запусціць некалькі дадатковых машын і цягінаў, каб быць гатовым да нагрузкі.
Буду рады, калі ў каментарах раскажаце цікавыя кейсы выкарыстання спотавых інстансаў і ECS ці ж нешта па маштабаванні.
Хутка будуць артыкулы пра тое, як мы апрацоўваем тысячы аналітычных эвентаў у секунду на пераважна serverless стэке (з грашыма) і як уладкованы дэплой сэрвісаў з дапамогай GitLab CI і Terraform Cloud.
Падпісвайцеся на нас, будзе цікава!
Толькі зарэгістраваныя карыстачы могуць удзельнічаць у апытанні. , Калі ласка.
Карыстаецеся Ці вы spot instances на продзе?
-
22,2%Так6
-
66,7%Няма18
-
11,1%Даведаўся пра іх з артыкула, планую выкарыстоўваць3
Прагаласавалі 27 карыстальнікаў. Устрымаліся 5 карыстальнікаў.
Крыніца: habr.com