Здраво на сите! Јас се викам Кирил, јас сум CTO во Адапти. Поголемиот дел од нашата архитектура е на AWS, а денес ќе зборувам за тоа како ги намаливме трошоците на серверот за 3 пати со користење на инстанци на место во производствена средина, како и како да го поставиме нивното автоматско скалирање. Прво ќе има преглед на тоа како функционира, а потоа детални упатства за почеток.
Што се Спот примери?
примероците се сервери на други корисници на AWS кои моментално се неактивен, и тие ги продаваат со голем попуст (Амазон пишува до 90%, според нашето искуство ~ 3x, варира во зависност од регионот, AZ и типот на примерот). Нивната главна разлика од обичните е тоа што тие можат да се исклучат во секое време. Затоа, долго време верувавме дека е нормално да ги користиме за девствени средини, или за задачи за пресметување на нешто, со средни резултати зачувани на S3 или во базата на податоци, но не и за продажба. Постојат решенија од трети страни кои ви дозволуваат да користите точки за производство, но има многу патерици за нашиот случај, па затоа не ги имплементиравме. Пристапот опишан во статијата работи целосно во рамките на стандардната функционалност AWS, без дополнителни скрипти, круни итн.
Подолу се дадени неколку слики од екранот што ја прикажуваат историјата на цените за самоточни примери.
m5.голем во регионот eu-west-1 (Ирска). Цената е главно стабилна веќе 3 месеци, моментално заштедува 2.9 пати.
m5.голема во регионот САД-исток-1 (Н. Вирџинија). Цената постојано се менува во текот на 3 месеци, моментално заштедува од 2.3x до 2.8x во зависност од зоната на достапност.
t3.мали во регионот САД-исток-1 (Н. Вирџинија). Цената е стабилна веќе 3 месеци, во моментов заштедува 3.4 пати.
Архитектура на услуги
Основната архитектура на услугата за која ќе зборуваме во оваа статија е прикажана на дијаграмот подолу.
Баланс на оптоварување на апликации → Целна група EC2 → Сервис за еластичен контејнер
Application Load Balancer (ALB) се користи како балансирач, кој испраќа барања до EC2 Target Group (TG). TG е одговорен за отворање порти на примероци за ALB и нивно поврзување со пристаништа на контејнери за Elastic Container Service (ECS). ECS е аналог на Kubernetes во AWS, кој управува со контејнерите на Docker.
Еден пример може да има неколку работи контејнери со исти порти, така што не можеме да ги поставиме фиксно. ECS му кажува на TG дека започнува нова задача (во терминологијата на Kubernetes ова се нарекува pod), тој проверува дали има бесплатни порти на примерокот и доделува една од нив на стартуваната задача. TG, исто така, редовно проверува дали инстанцата и API работат на тоа со помош на здравствена проверка, и ако види какви било проблеми, престанува да испраќа барања таму.
Групи за автоматско скалирање EC2 + Обезбедувачи на капацитет на ECS
Горенаведениот дијаграм не ја прикажува услугата EC2 Auto Scaling Groups (ASG). Од името можете да разберете дека е одговорен за скалирање на примероци. Сепак, до неодамна, AWS немаше вградена способност за управување со бројот на работи машини од ECS. ECS овозможи да се скалира бројот на задачи, на пример, според користењето на процесорот, RAM меморијата или бројот на барања. Но, ако задачите ги окупираа сите бесплатни примероци, тогаш новите машини не беа автоматски креирани.
Ова се промени со доаѓањето на ECS Capacity Providers (ECS CP). Сега секоја услуга во ECS може да се поврзе со ASG, и ако задачите не се вклопуваат во тековните инстанци, тогаш ќе се подигнат нови (но во утврдените ASG граници). Ова функционира и во спротивна насока, ако ECS CP гледа неактивен примероци без задачи, тогаш ќе и даде на командата ASG да ги исклучи. ECS CP има способност да одреди цел процент на оптоварување на примерот, така што одреден број машини се секогаш слободни за задачи за брзо скалирање; ќе зборувам за ова малку подоцна.
Шаблони за лансирање EC2
Последната услуга за која ќе зборувам пред да навлегувам во детали за создавање на оваа инфраструктура е EC2 Launch Templates. Ви овозможува да креирате шаблон според кој ќе стартуваат сите машини, за да не се повторува ова од нула секој пат. Овде можете да изберете тип на машина за стартување, безбедносна група, слика на дискот и многу други параметри. Можете исто така да наведете кориснички податоци што ќе бидат поставени на сите стартувани примероци. Можете да извршите скрипти во кориснички податоци, на пример, можете да ја уредувате содржината на датотеката .
Еден од најважните конфигурациски параметри за овој напис е =точно. Ако овој параметар е овозможен, тогаш штом ECS прими сигнал дека се одзема точката, ги префрла сите задачи што работат на него во статусот Draining. Нема да му бидат доделени нови задачи на овој пример; ако има задачи што сакаат да му се префрлат во моментов, тие ќе бидат откажани. Престануваат да доаѓаат и барања од балансерот. Известувањето за бришење на пример доаѓа 2 минути пред вистинскиот настан. Затоа, ако вашата услуга не извршува задачи подолги од 2 минути и не зачувува ништо на дискот, тогаш можете да користите инстанци на самото место без да изгубите податоци.
Во врска со дискот - AWS неодамна Можно е да се користи Elastic File System (EFS) заедно со ECS; со оваа шема, дури и дискот не е пречка, но ние не го пробавме ова, бидејќи во принцип не ни треба дискот за складирање на состојбата. Стандардно, по примањето SIGINT (испратено кога задачата е префрлена во статусот „Исцедување“, сите работи што се извршуваат ќе бидат стопирани по 30 секунди, дури и ако сè уште не се завршени; можете да го промените овој пат користејќи го параметарот . Главната работа е да не го поставувате повеќе од 2 минути за машините за место.
Создавање услуга
Ајде да продолжиме кон создавање на опишаната услуга. Во тој процес, дополнително ќе опишам неколку корисни точки кои не беа споменати погоре. Во принцип, ова е чекор-по-чекор инструкција, но нема да разгледам некои многу основни или, напротив, многу конкретни случаи. Сите дејства се изведуваат во визуелната конзола AWS, но може да се репродуцираат програмски користејќи CloudFormation или Terraform. Во Adapty користиме Terraform.
Шаблон за лансирање EC2
Оваа услуга создава конфигурација на машини што ќе се користат. Со шаблоните се управува во делот EC2 -> Instances -> Launch templates.
Слика на машината на Амазон (AMI) — наведете ја сликата на дискот со која ќе се стартуваат сите примероци. За ECS, во повеќето случаи вреди да се користи оптимизираната слика од Amazon. Редовно се ажурира и содржи се што е потребно за да функционира ECS. За да го дознаете тековниот ID на сликата, одете на страницата , изберете го регионот што го користите и копирајте го AMI ID за него. На пример, за регионот us-east-1, сегашниот ID во моментот на пишување е ami-00c7c1cf5bdc913ed. Овој ID мора да се вметне во ставката Наведете приспособена вредност.
Тип на пример — наведете го типот на примерот. Изберете го оној кој најмногу одговара на вашата задача.
Пар клучеви (најава) — наведете сертификат со кој можете да се поврзете со примерокот преку SSH, доколку е потребно.
Мрежни поставки — наведете ги мрежните параметри. Платформа за вмрежување во повеќето случаи треба да има виртуелен приватен облак (VPC). Безбедносни групи — безбедносни групи за вашите примери. Бидејќи ќе користиме балансер пред примероците, препорачувам овде да наведете група која дозволува дојдовни врски само од балансерот. Односно, ќе имате 2 безбедносни групи, едната за балансерот, која дозволува влезни врски од каде било на пристаништата 80 (http) и 443 (https), а втората за машините, која овозможува дојдовни конекции на кои било порти од групата за балансирање . Појдовните врски во двете групи мора да се отворат со помош на протоколот TCP до сите порти до сите адреси. Можете да ги ограничите портите и адресите за појдовни конекции, но потоа треба постојано да следите дека не се обидувате да пристапите до нешто на затворена порта.
Складирање (томови) — наведете ги параметрите на дискот за машините. Големината на дискот не може да биде помала од онаа наведена во AMI; за ECS Optimized е 30 GiB.
Напредни детали — наведете дополнителни параметри.
Опција за купување — дали сакаме да купиме само инстанци. Сакаме, но нема да го штиклираме ова поле овде; ќе го конфигурираме во групата за автоматско скалирање, има повеќе опции таму.
Профил на пример IAM — наведете ја улогата со која ќе се активираат примероците. За да можат примерите да работат во ECS, им требаат дозволи, кои обично се наоѓаат во улогата ecsInstanceRole. Во некои случаи може да се создаде, ако не, тогаш овде за тоа како да го направите ова. По креирањето, го означуваме во шаблонот.
Следно, има многу параметри, во основа можете да оставите стандардни вредности насекаде, но секој од нив има јасен опис. Секогаш ги овозможувам EBS-оптимизираниот примерок и T2/T3 Unlimited опциите доколку се користат инстанци.
Кориснички податоци — означете ги корисничките податоци. Ќе ја уредиме датотеката /etc/ecs/ecs.config, кој ја содржи конфигурацијата на агентот ECS.
Пример за тоа како би можеле да изгледаат корисничките податоци:
#!/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 — параметарот одредува дека кога ќе се прими сигнал за исклучување на примерок од место, сите задачи на него треба да се префрлат во статусот „Draining“.
ECS_CONTAINER_STOP_TIMEOUT=1m - параметарот одредува дека по добивањето на SIGINT сигнал, сите задачи имаат 1 минута пред да бидат убиени.
ECS_ENGINE_AUTH_TYPE=docker — параметарот покажува дека Docker шемата се користи како механизам за авторизација
ECS_ENGINE_AUTH_DATA=... — параметри за поврзување со регистарот на приватниот контејнер, каде што се зачувани вашите Docker слики. Ако е јавно, тогаш не треба ништо да наведете.
За целите на овој напис, ќе користам јавна слика од Docker Hub, па наведете ги параметрите ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA не треба.
Добро е да се знае: Се препорачува редовно да се ажурира AMI, бидејќи новите верзии ги ажурираат верзиите на Docker, Linux, ECS агентот итн. За да не заборавите на ова, можете да за објавување на нови верзии. Може да примате известувања по е-пошта и да се ажурирате рачно, или можете да напишете функција Lambda што автоматски ќе создаде нова верзија на Шаблон за стартување со ажуриран AMI.
Група за автоматско скалирање EC2
Auto Scaling Group е одговорна за лансирање и скалирање на примероци. Групите се управуваат во делот EC2 -> Auto Scaling -> Auto Scaling Groups секцијата.
Стартувајте шаблон — изберете го шаблонот создаден во претходниот чекор. Ја оставаме стандардната верзија.
Опции за купување и типови на примери — наведете ги типовите на примероци за кластерот. Придржувајте се до шаблонот за стартување го користи типот на пример од Шаблонот Стартување. Комбинацијата на опции за купување и типови на примери ви овозможува флексибилно да ги конфигурирате типовите на примероци. Ние ќе го искористиме.
Изборна база на барање — бројот на редовни, не-местен примероци кои секогаш ќе работат.
Процент на барање над основата — процентуален сооднос на редовни и спот инстанци, 50-50 ќе бидат распределени подеднакво, 20-80 за секоја редовна инстанца ќе се подигнат 4 точки. За потребите на овој пример, ќе наведам 50-50, но во реалноста најчесто правиме 20-80, во некои случаи 0-100.
Видови на примери — овде можете да наведете дополнителни типови на примероци што ќе се користат во кластерот. Никогаш не го користевме затоа што навистина не го разбирам значењето на приказната. Можеби ова се должи на ограничувањата на одредени типови на примероци, но тие лесно може да се зголемат преку поддршка. Ако ја знаете апликацијата, ќе ми биде драго да ја прочитам во коментарите)
мрежа — мрежни поставки, изберете VPC и подмрежи за машини, во повеќето случаи треба да ги изберете сите достапни подмрежи.
Балансирање на товарот - поставки за балансирање, но ние ќе го направиме ова одделно, нема да допреме ништо овде. Здравствени проверки исто така ќе се конфигурира подоцна.
Големина на групата — ги означуваме ограничувањата на бројот на машини во кластерот и саканиот број на машини на почетокот. Бројот на машини во кластерот никогаш нема да биде помал од наведениот минимум и поголем од максимумот, дури и ако скалирањето треба да се случи според метриката.
Политики за скалирање — параметри за скалирање, но ќе скалираме врз основа на тековните задачи на ECS, па ќе го конфигурираме скалирањето подоцна.
Заштита од скала на пример — заштита на примероци од бришење при намалување. Го овозможуваме ASG да не ја избрише машината што има задачи што работат. ECS Capacity Provider ќе ја оневозможи заштитата за случаи кои немаат задачи.
Додадете ознаки — можете да наведете ознаки за примероци (за ова, полето за избор Ознака нови примери мора да се штиклира). Препорачувам да ја наведете ознаката Име, тогаш сите примероци што се стартуваат во групата ќе го имаат истото име и погодно е да ги видите во конзолата.
Откако ќе ја креирате групата, отворете ја и одете во делот Напредни конфигурации Зошто не се видливи сите опции во конзолата во фазата на креирање.
Политики за раскинување — правила кои се земаат предвид при бришење на примероци. Тие се применуваат по редослед. Обично ги користиме оние на сликата подолу. Прво, примероците со најстариот Шаблон за стартување се бришат (на пример, ако го ажуриравме AMI, создадовме нова верзија, но сите примероци успеаја да се префрлат на неа). Потоа се избираат примероците што се најблиску до следниот час за наплата. И тогаш најстарите се избираат врз основа на датумот на лансирање.
Добро е да се знае: за ажурирање на сите машини во кластер, погодно за употреба . Ако го комбинирате ова со функцијата Lambda од претходниот чекор, ќе имате целосно автоматизиран систем за ажурирање на примероци. Пред да ги ажурирате сите машини, мора да ја оневозможите заштитата од скала на пример за сите примероци во групата. Не конфигурација во групата, туку заштита од самите машини, ова се прави на картичката Управување со примери.
Апликација Load Balancer и EC2 Target Group
Балансерот е креиран во делот EC2 → Load Balancing → Load Balancers. Ќе користиме Application Load Balancer; споредба на различни типови балансери може да се прочита на .
Слушатели - има смисла да се направат порти 80 и 443 и да се пренасочат од 80 на 443 користејќи правила за балансирање подоцна.
Зони за достапност — во повеќето случаи, избираме зони за пристапност за секого.
Конфигурирајте ги поставките за безбедност — овде е означен SSL сертификатот за балансерот, најзгодната опција е во ACM. За разликите Безбедносна политика може да се прочита во , можете да го оставите стандардно избрано ELBSecurityPolicy-2016-08. Откако ќе го креирате балансерот, ќе го видите Име на ДНС, што треба да го конфигурирате CNAME за вашиот домен. На пример, вака изгледа во Cloudflare.
Група за безбедност — креирајте или изберете група за безбедност за балансерот, напишав повеќе за ова веднаш погоре во делот EC2 Launch Template → Network settings.
Целна група — создаваме група која е одговорна за насочување на барањата од балансерот до машини и проверка на нивната достапност со цел да ги замени во случај на проблеми. Тип на целта мора да биде пример, Протокол и Порт било, ако користите HTTPS за комуникација помеѓу балансерот и примероците, тогаш треба да поставите сертификат на нив. За целите на овој пример, ние нема да го направиме ова, едноставно ќе ја оставиме портата 80.
Здравствени проверки — параметри за проверка на функционалноста на услугата. Во вистинска услуга, ова треба да биде посебно барање кое имплементира важни делови од деловната логика; за целите на овој пример, ќе ги оставам стандардните поставки. Следно, можете да го изберете интервалот на барањето, истекот на времето, успешните кодови, итн. Во нашиот пример, ќе ги посочиме Успешните кодови 200-399, бидејќи сликата на Docker што ќе се користи враќа шифра 304.
Регистрирајте цели — овде се избираат автомобилите за групата, но во нашиот случај тоа ќе го направи ECS, па ние само го прескокнуваме овој чекор.
Добро е да се знае: на ниво на балансер можете да овозможите логови кои ќе бидат зачувани во S3 во одредено . Оттаму тие можат да се извезат во услуги од трети страни за аналитика, или можете да направите SQL барања директно на податоците во S3 со . Удобно е и работи без дополнителен код. Исто така, препорачувам да го поставите отстранувањето на дневниците од корпата S3 по одреден временски период.
Дефиниција на задачата ECS
Во претходните чекори, создадовме сè што е поврзано со сервисната инфраструктура, сега продолжуваме да ги опишуваме контејнерите што ќе ги лансираме. Ова е направено во делот ECS → Дефиниции на задачи.
Компатибилност со типот на стартување - изберете EC2.
Извршување задача IAM улога - изберете ecsTaskExecutionRole. Користејќи го, се пишуваат дневници, се дава пристап до тајните променливи итн.
Во делот Дефиниции на контејнер, кликнете Додај контејнер.
Сликата — линк до сликата со кодот на проектот; за овој пример ќе користам јавна слика од Docker Hub .
Ограничувања на меморијата — граници на меморија за контејнерот. Тешка граница — тешко ограничување, ако контејнерот оди подалеку од наведената вредност, командата за убивање на докерот ќе се изврши, контејнерот веднаш ќе умре. Мека граница — мека граница, контејнерот може да ја надмине одредената вредност, но овој параметар ќе се земе предвид при поставување задачи на машините. На пример, ако машината има 4 GiB RAM меморија, а меката граница на контејнер е 2048 MiB, тогаш оваа машина може да има најмногу 2 работни задачи со овој контејнер. Во реалноста, 4 GiB RAM меморија е нешто помалку од 4096 MiB, ова може да се види на картичката ECS Instances во кластерот. Мека граница не може да биде поголема од тврда граница. Важно е да се разбере дека ако има неколку контејнери во една задача, тогаш нивните граници се сумирани.
Карти на пристаништа - во Пристаниште за домаќин Посочуваме 0, тоа значи дека пристаништето ќе биде доделено динамички и ќе биде надгледувано од Целната група. Контејнерско пристаниште — пристаништето на кое работи вашата апликација често е наведена во командата за извршување или се доделува во кодот на вашата апликација, Dockerfile итн. За нашиот пример ќе користиме 3000 бидејќи е наведено во сликата што се користи.
Здравствен преглед — параметри за здравствена проверка на контејнерот, кои не треба да се мешаат со конфигурираните во Целната група.
животната средина - поставки за околината. Единици на процесорот - слично на ограничувањата на меморијата, само за процесорот. Секое процесорско јадро има 1024 единици, па ако серверот има двојадрен процесор и контејнерот е поставен на 512, тогаш 4 задачи со овој контејнер може да се стартуваат на еден сервер. Единиците на процесорот секогаш одговараат на бројот на јадра; не може да има малку помалку од нив, како што е случајот со меморијата.
Команда — команда за започнување на услуга во контејнер, сите параметри се наведени одделени со запирки. Ова може да биде пунџа, npm, итн. Ако не е наведено, ќе се користи вредноста на директивата CMD од Dockerfile. Ние укажуваме npm,start.
Променливи на животната средина — променливи на околината на контејнерот. Ова може да биде или едноставни текстуални податоци или тајни променливи од или .
Складирање и логирање — овде ќе поставиме најавување во CloudWatch Logs (услуга за дневници од AWS). За да го направите ова, само овозможете го полето за избор Автоматско конфигурирање на дневници на CloudWatch. По креирањето на Дефиницијата за задачи, група од дневници автоматски ќе се креираат во CloudWatch. Стандардно, дневниците се чуваат во него на неодредено време; Ви препорачувам да го промените периодот на задржување од Никогаш не истекува на потребниот период. Ова се прави во групите CloudWatch Log, треба да кликнете на тековниот период и да изберете нов.
ECS кластер и ECS капацитет провајдер
Одете во делот ECS → Кластери за да креирате кластер. Избираме EC2 Linux + Networking како шаблон.
Име на кластерот - многу важно, овде го правиме истото име како што е наведено во параметарот Launch Template ECS_CLUSTER, во нашиот случај - DemoApiClusterProd. Проверете го полето за избор Креирај празен кластер. Изборно, можете да овозможите Container Insights за прегледување на метрика за услугите во CloudWatch. Ако сте направиле сè правилно, тогаш во делот ECS Instances ќе видите машини што се создадени во групата Автоматско скалирање.
Одете на јазичето Даватели на капацитет и креирајте нова. Дозволете ми да ве потсетам дека е потребно за контрола на создавањето и исклучувањето на машините во зависност од бројот на работни задачи на ECS. Важно е да се забележи дека давателот може да биде доделен само на една група.
Група за автоматско скалирање — изберете ја претходно креираната група.
Управувано скалирање — овозможете го така што давателот може да ја зголеми услугата.
Целен капацитет % — колкав процент од машини натоварени со задачи ни требаат. Ако наведете 100%, тогаш сите машини секогаш ќе бидат зафатени со извршување задачи. Ако наведете 50%, тогаш половина од автомобилите секогаш ќе бидат бесплатни. Во овој случај, ако има остар скок на товарот, новите такси веднаш ќе стигнат до бесплатни автомобили, без да треба да чекаат да се распоредат примероци.
Управувана заштита од прекинување — овозможи, овој параметар му овозможува на давателот да ја отстрани заштитата на примероците од бришење. Ова се случува кога нема активни задачи на машината и дозволува Целен капацитет%.
ECS сервис и поставување на скалирање
Последен чекор :) За да креирате услуга, треба да отидете во претходно креираниот кластер на картичката Услуги.
Тип на стартување — треба да кликнете на Префрли се на стратегија за провајдер на капацитет и да ги изберете претходно креираните провајдери.
Дефиниција на задача — изберете ја претходно креираната Дефиниција за задачи и нејзината ревизија.
Името на сервисот — за да се избегне забуна, секогаш го означуваме истото како Дефиниција на задачата.
Тип на услуга - секогаш Реплика.
Број на задачи — саканиот број на активни задачи во услугата. Овој параметар се контролира со скалирање, но сепак мора да биде наведен.
Минимален здрав процент и Максимален процент — одредување на однесувањето на задачите за време на распоредувањето. Стандардните вредности се 100 и 200, што покажува дека во моментот на распоредување бројот на задачи ќе се зголеми неколку пати, а потоа ќе се врати на саканата вредност. Ако имаш 1 задача која работи, min=0 и max=100, тогаш при распоредувањето ќе се убие, а после тоа ќе се подигне нова, односно ќе биде прекин. Ако работи 1 задача, min=50, max=150, тогаш распоредувањето нема да се случи воопшто, бидејќи 1 задача не може да се подели на половина или да се зголеми за еден и пол пати.
Тип на распоредување — оставете го ажурирањето на Rolling.
Шаблони за поставување — правила за поставување задачи на машини. Стандардно е AZ Balanced Spread - тоа значи дека секоја нова задача ќе биде поставена на нов примерок додека не се покачат машините во сите зони на достапност. Ние обично правиме BinPack - CPU и Spread - AZ; со оваа политика, задачите се поставуваат колку што е можно погусто на една машина по процесор. Доколку е потребно да се создаде нова машина, таа се создава во нова зона на достапност.
Тип на балансер на оптоварување — изберете Application Load Balancer.
Улога на IAM на услугата - изберете ecsServiceRole.
Име на балансерот на вчитување — изберете го претходно креираниот балансер.
Грејс период за проверка на здравјето — паузираме пред да извршиме здравствени проверки откако ќе поставиме нова задача, обично ја поставуваме на 60 секунди.
Контејнер за рамнотежа на товарот — во ставката Име на целната група, изберете ја претходно креираната група и сè ќе се пополни автоматски.
Сервисно автоматско скалирање — параметри за скалирање на услугата. Изберете Конфигурирај автоматско скалирање на услугата за да го прилагодите саканиот број на вашата услуга. Го поставуваме минималниот и максималниот број на задачи при скалирање.
Улога на IAM за автоматско скалирање на услугата - изберете AWSServiceRoleForApplicationAutoScaling_ECSService.
Политики за автоматско скалирање на задачите — правила за скалирање. Постојат 2 типа:
- Следење на целта — следење на целните метрика (користење процесор/РАМ или број на барања за секоја задача). На пример, сакаме просечното оптоварување на процесорот да биде 85%, кога ќе стане поголемо, ќе се додаваат нови задачи додека не ја достигне целната вредност. Ако оптоварувањето е помало, тогаш задачите ќе се отстранат, напротив, освен ако не е овозможена заштита од намалување (Оневозможи скалирање).
- Скалирање на чекори - реакција на произволен настан. Овде можете да конфигурирате реакција на кој било настан (CloudWatch Alarm), кога ќе се појави, можете да додадете или отстраните одреден број задачи или да го одредите точниот број на задачи.
Услугата може да има неколку правила за скалирање, ова може да биде корисно, главната работа е да се осигурате дека тие не се во конфликт едни со други.
Заклучок
Ако ги следевте упатствата и ја користевте истата слика на Docker, вашата услуга треба да врати страница како оваа.
- Создадовме шаблон според кој се стартуваат сите машини во услугата. Научивме и како да ги ажурираме машините кога се менува шаблонот.
- Ја конфигуриравме обработката на сигналот за запирање на самото место, така што во рок од една минута по неговото примање, сите работни задачи се отстрануваат од машината, така што ништо не се губи или прекинува.
- Го подигнавме балансерот за рамномерно да го распредели товарот низ машините.
- Создадовме услуга која работи на самото место, што ги намалува трошоците на машината за околу 3 пати.
- Го конфигуриравме автоматското скалирање во двете насоки за да се справи со зголемениот обем на работа без да се трошат трошоци за застој.
- Ние користиме Capacity Provider за апликацијата да управува со инфраструктурата (машините), а не обратно.
- Ние сме супер.
Ако имате предвидливи скокови во оптоварувањето, на пример, рекламирате во голема кампања за е-пошта, можете да поставите скалирање според .
Можете исто така да скалирате врз основа на податоци од различни делови на вашиот систем. На пример, ја имаме функционалноста корисници на мобилната апликација. Понекогаш се испраќа кампања до 1 милион+ луѓе. По таквата дистрибуција, секогаш има големо зголемување на барањата до API, бидејќи многу корисници се најавуваат во апликацијата во исто време. Така, ако видиме дека има значително повеќе стандардни индикатори во редот за испраќање промотивни притисни известувања, можеме веднаш да стартуваме неколку дополнителни машини и задачи за да бидеме подготвени за оптоварување.
Ќе ми биде драго ако ми кажете во коментарите интересни случаи на користење на инстанци на место и ECS или нешто за скалирање.
Наскоро ќе има написи за тоа како обработуваме илјадници аналитички настани во секунда на оџак претежно без сервер (со пари) и како функционира распоредувањето на услугите користејќи ги GitLab CI и Terraform Cloud.
Претплатете се на нас, ќе биде интересно!
Само регистрирани корисници можат да учествуваат во анкетата. , вие сте добредојдени.
Дали користите спот инстанци во производството?
-
22,2%Да 6
-
66,7%Бр 18 г
-
11,1%Научив за нив од една статија и планирам да ги користам3
Гласаа 27 корисници. 5 корисници беа воздржани.
Извор: www.habr.com