{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Tworzenie skalowalnego API na spotowych instancjach AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Cze\u015b\u0107 wszystkim! Nazywam si\u0119 Kirill, jestem CTO w Adapty. Wi\u0119kszo\u015b\u0107 naszej architektury opiera si\u0119 na AWS, a dzisiaj opowiem, jak zmniejszyli\u015bmy koszty serwer\u00f3w trzykrotnie, korzystaj\u0105c z instancji spot na \u015brodowisku produkcyjnym, oraz jak skonfigurowa\u0107 ich automatyczne skalowanie. Najpierw b\u0119dzie przegl\u0105d, jak to dzia\u0142a, a potem szczeg\u00f3\u0142owa instrukcja uruchomienia.<\/p>\n

<\/p>\n

Czym s\u0105 instancje spot?<\/h2>\n

<\/p>\n

Instancje<\/a><\/noindex> spot to serwery innych u\u017cytkownik\u00f3w AWS, kt\u00f3re w danym momencie s\u0105 niewykorzystane i sprzedaj\u0105 je z du\u017c\u0105 zni\u017ck\u0105 (Amazon podaje do 90%, wed\u0142ug naszego do\u015bwiadczenia oko\u0142o 3x, co r\u00f3\u017cni si\u0119 w zale\u017cno\u015bci od regionu, AZ i typu instancji). Ich g\u0142\u00f3wn\u0105 r\u00f3\u017cnic\u0105 od zwyk\u0142ych jest to, \u017ce mog\u0105 zosta\u0107 wy\u0142\u0105czone w ka\u017cdej chwili. Dlatego przez d\u0142ugi czas uwa\u017cali\u015bmy, \u017ce mo\u017cna je u\u017cywa\u0107 tylko do \u015brodowisk deweloperskich lub do oblicze\u0144, zachowuj\u0105c wyniki po\u015brednie na S3 lub w bazie, ale nie do produkcji. Istniej\u0105 zewn\u0119trzne rozwi\u0105zania, kt\u00f3re pozwalaj\u0105 u\u017cywa\u0107 spot\u00f3w w produkcji, ale w naszym przypadku wi\u0105za\u0142oby si\u0119 to z wieloma problemami, dlatego ich nie wdra\u017cali\u015bmy. Podej\u015bcie opisane w artykule dzia\u0142a w pe\u0142ni w ramach standardowej funkcjonalno\u015bci AWS, bez dodatkowych skrypt\u00f3w, cron\u00f3w itp.<\/p>\n

<\/a><\/noindex><\/p>\n

Poni\u017cej przedstawiam kilka zrzut\u00f3w ekranu, kt\u00f3re pokazuj\u0105 histori\u0119 cen instancji spot.<\/p>\n

<\/p>\n

m5.large w regionie eu-west-1 (Irlandia). Cena jest g\u0142\u00f3wnie stabilna przez 3 miesi\u0105ce, aktualnie oszcz\u0119dno\u015b\u0107 wynosi 2.9x.<\/p>\n

<\/p>\n

\"Tworzenie<\/p>\n

<\/p>\n

m5.large w regionie us-east-1 (N. Wirginia). Cena zmienia si\u0119 stale przez 3 miesi\u0105ce, aktualnie oszcz\u0119dno\u015b\u0107 wynosi od 2.3x do 2.8x w zale\u017cno\u015bci od strefy dost\u0119pno\u015bci.<\/p>\n

<\/p>\n

\"Tworzenie<\/p>\n

<\/p>\n

t3.small w regionie us-east-1 (N. Wirginia). Cena jest stabilna przez 3 miesi\u0105ce, aktualnie oszcz\u0119dno\u015b\u0107 wynosi 3.4x.<\/p>\n

<\/p>\n

\"Tworzenie<\/p>\n

<\/p>\n

Architektura us\u0142ugi<\/h2>\n

<\/p>\n

Podstawowa architektura us\u0142ugi, o kt\u00f3rej b\u0119dziemy m\u00f3wi\u0107 w tym artykule, przedstawiona jest na diagramie poni\u017cej.<\/p>\n

<\/p>\n

\"Tworzenie<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Jako load balancer u\u017cywany jest Application Load Balancer (ALB), kt\u00f3ry kieruje \u017c\u0105dania do EC2 Target Group (TG). TG odpowiada za otwieranie port\u00f3w na instancjach dla ALB i kojarzenie ich z portami kontener\u00f3w Elastic Container Service (ECS). ECS to odpowiednik Kubernetes w AWS, kt\u00f3ry zarz\u0105dza kontenerami Docker.<\/p>\n

<\/p>\n

Na jednym instansie mo\u017ce dzia\u0142a\u0107 kilka kontener\u00f3w na tych samych portach, dlatego nie mo\u017cemy ich ustawi\u0107 na sta\u0142e. ECS informuje TG, \u017ce uruchamia nowe zadanie (w terminologii Kubernetes nazywane pod), wykonuje sprawdzenie dost\u0119pnych port\u00f3w na instansie i przydziela jeden z nich do uruchamianego zadania. TG regularnie sprawdza, czy instans dzia\u0142a i czy API na nim jest sprawne za pomoc\u0105 health check, a je\u015bli zauwa\u017cy jakie\u015b problemy, przestaje przekazywa\u0107 tam zapytania.<\/p>\n

<\/p>\n

EC2 Auto Scaling Groups + ECS Capacity Providers<\/h3>\n

<\/p>\n

Na powy\u017cszej ilustracji nie pokazano us\u0142ugi EC2 Auto Scaling Groups (ASG). Z nazwy mo\u017cna wywnioskowa\u0107, \u017ce odpowiada ona za skalowanie instans\u00f3w. Do niedawna w AWS nie by\u0142o wbudowanej mo\u017cliwo\u015bci zarz\u0105dzania liczb\u0105 uruchomionych maszyn z poziomu ECS. ECS pozwala\u0142 na skalowanie liczby zada\u0144, na przyk\u0142ad w zale\u017cno\u015bci od wykorzystania CPU, RAM lub liczby zapyta\u0144. Jednak je\u015bli zadania zajmowa\u0142y wszystkie dost\u0119pne instansy, nowe maszyny nie by\u0142y automatycznie uruchamiane.<\/p>\n

<\/p>\n

To si\u0119 zmieni\u0142o wraz z wprowadzeniem ECS Capacity Providers (ECS CP). Teraz ka\u017cd\u0105 us\u0142ug\u0119 w ECS mo\u017cna po\u0142\u0105czy\u0107 z ASG, a je\u015bli zadania nie mieszcz\u0105 si\u0119 na dzia\u0142aj\u0105cych instansach, uruchomi\u0105 si\u0119 nowe (jednak w ramach ustalonych limit\u00f3w ASG). Dzia\u0142a to w obie strony: je\u015bli ECS CP zauwa\u017cy bezczynne instansy bez zada\u0144, zleci ASG, aby je wy\u0142\u0105czy\u0142a. ECS CP ma mo\u017cliwo\u015b\u0107 wskazania docelowego procentu obci\u0105\u017cenia instans\u00f3w, aby pewna liczba maszyn zawsze by\u0142a dost\u0119pna do szybkiego skalowania zada\u0144, o czym opowiem nieco p\u00f3\u017aniej.<\/p>\n

<\/p>\n

Szablony uruchamiania EC2<\/h3>\n

<\/p>\n

Ostatni\u0105 us\u0142ug\u0105, o kt\u00f3rej opowiem, zanim przejd\u0119 do szczeg\u00f3\u0142owego opisu tworzenia tej infrastruktury, s\u0105 szablony uruchamiania EC2. Pozwalaj\u0105 one stworzy\u0107 szablon, wed\u0142ug kt\u00f3rego b\u0119d\u0105 uruchamiane wszystkie maszyny, aby nie powtarza\u0107 tego za ka\u017cdym razem od nowa. Mo\u017cna tu wybra\u0107 typ uruchamianej maszyny, grup\u0119 bezpiecze\u0144stwa, obraz dysku i wiele innych parametr\u00f3w. Mo\u017cna tak\u017ce wskaza\u0107 dane u\u017cytkownika, kt\u00f3re b\u0119d\u0105 przesy\u0142ane do wszystkich uruchamianych instans\u00f3w. W danych u\u017cytkownika mo\u017cna uruchamia\u0107 skrypty, na przyk\u0142ad mo\u017cna edytowa\u0107 zawarto\u015b\u0107 pliku konfiguracji agenta ECS<\/a><\/noindex>.<\/p>\n

<\/p>\n

Jednym z najwa\u017cniejszych parametr\u00f3w konfiguracji w ramach tego artyku\u0142u jest ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Je\u015bli ten parametr jest w\u0142\u0105czony, to gdy ECS otrzyma sygna\u0142 o tym, \u017ce instancja spotowa jest zabierana, zmienia status wszystkich zada\u0144, kt\u00f3re na niej dzia\u0142aj\u0105, na Draining. \u017badne nowe zadania nie b\u0119d\u0105 przypisywane do tej instancji, a je\u015bli s\u0105 zadania, kt\u00f3re aktualnie chc\u0105 na ni\u0105 przej\u015b\u0107, zostan\u0105 one anulowane. \u017b\u0105dania z balancera r\u00f3wnie\u017c przestan\u0105 przychodzi\u0107. Powiadomienie o usuni\u0119ciu instancji jest wysy\u0142ane na 2 minuty przed rzeczywistym zdarzeniem. Dlatego je\u015bli Tw\u00f3j serwis nie wykonuje zada\u0144 d\u0142u\u017cej ni\u017c 2 minuty i nic nie zapisuje na dysku, mo\u017cesz korzysta\u0107 z instancji spotowych bez utraty danych.<\/p>\n

<\/p>\n

Je\u015bli chodzi o dysk \u2014 AWS niedawno umo\u017cliwi\u0142<\/a><\/noindex> u\u017cycie Elastic File System (EFS) w po\u0142\u0105czeniu z ECS, dzi\u0119ki temu nawet dysk nie stanowi przeszkody, ale nie pr\u00f3bowali\u015bmy tego, poniewa\u017c zasadniczo nie potrzebujemy dysku do przechowywania stanu. Domy\u015blnie po otrzymaniu SIGINT (wysy\u0142ane w momencie zmiany statusu zadania na Draining) wszystkie dzia\u0142aj\u0105ce zadania zostan\u0105 zatrzymane w ci\u0105gu 30 sekund, nawet je\u015bli nie uda\u0142o im si\u0119 zako\u0144czy\u0107, a ten czas mo\u017cna zmieni\u0107 za pomoc\u0105 parametru ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Najwa\u017cniejsze, aby nie ustawia\u0107 go na wi\u0119cej ni\u017c 2 minuty dla instancji spotowych.<\/p>\n

<\/p>\n

Tworzenie us\u0142ugi<\/h2>\n

<\/p>\n

Przechodzimy bezpo\u015brednio do tworzenia opisanej us\u0142ugi. W trakcie opowiem r\u00f3wnie\u017c o kilku przydatnych aspektach, o kt\u00f3rych nie wspomniano wcze\u015bniej. Og\u00f3lnie to instrukcja krok po kroku, ale nie b\u0119d\u0119 omawia\u0107 bardzo podstawowych ani zbyt specyficznych przypadk\u00f3w. Wszystkie dzia\u0142ania odbywaj\u0105 si\u0119 w wizualnej konsoli AWS, ale mo\u017cna je powt\u00f3rzy\u0107 programowo za pomoc\u0105 CloudFormation lub Terraform. W Adapty u\u017cywamy Terraform.<\/p>\n

<\/p>\n

Szablon uruchamiania EC2<\/strong><\/h3>\n

<\/p>\n

W tej us\u0142udze tworzona jest konfiguracja maszyn, kt\u00f3re b\u0119d\u0105 u\u017cywane. Zarz\u0105dzanie szablonami odbywa si\u0119 w sekcji EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Obraz maszyny Amazon (AMI)<\/strong> \u2014 wskazujemy obraz dysku, na podstawie kt\u00f3rego b\u0119d\u0105 uruchamiane wszystkie instancje. Dla ECS w wi\u0119kszo\u015bci przypadk\u00f3w nale\u017cy u\u017cywa\u0107 zoptymalizowanego obrazu od Amazon. Jest regularnie aktualizowany i zawiera wszystko, co potrzebne do dzia\u0142ania ECS. Aby pozna\u0107 aktualny ID obrazu, przechodzimy na stron\u0119 Amazon ECS-optimized AMIs<\/a><\/noindex>, wybieramy u\u017cywany region i kopiujemy ID AMI dla niego. Na przyk\u0142ad, dla regionu us-east-1 aktualny w momencie pisania tego artyku\u0142u ID to ami-00c7c1cf5bdc913ed<\/em>. Ten ID nale\u017cy wklei\u0107 w punkcie Specify a custom value.<\/p>\n

<\/p>\n

Typ instancji<\/strong> \u2014 wskazujemy typ instancji. Wybieramy ten, kt\u00f3ry najlepiej odpowiada naszym potrzebom.<\/p>\n

<\/p>\n

Para kluczy (logowanie)<\/strong> \u2014 wskazujemy certyfikat, za pomoc\u0105 kt\u00f3rego mo\u017cna po\u0142\u0105czy\u0107 si\u0119 z instancj\u0105 przez SSH, je\u015bli to konieczne.<\/p>\n

<\/p>\n

Ustawienia sieciowe<\/strong> \u2014 wskazujemy parametry sieci. Platforma sieciowa<\/strong> w wi\u0119kszo\u015bci przypadk\u00f3w powinna by\u0107 Wirtualn\u0105 Chmur\u0105 Prywatn\u0105 (VPC). Grupy zabezpiecze\u0144<\/strong> \u2014 grupy zabezpiecze\u0144 dla twoich instancji. Poniewa\u017c b\u0119dziemy u\u017cywa\u0107 load balancera przed instancjami, zalecam wskazanie tutaj grupy, kt\u00f3ra zezwala na po\u0142\u0105czenia przychodz\u0105ce tylko z load balancera. Oznacza to, \u017ce b\u0119dziesz mia\u0142 2 grupy zabezpiecze\u0144, jedn\u0105 dla load balancera, kt\u00f3ra zezwala na po\u0142\u0105czenia przychodz\u0105ce (inbound) z wsz\u0119dzie przez porty 80 (http) i 443 (https), a drug\u0105 dla maszyn, kt\u00f3ra zezwala na po\u0142\u0105czenia przychodz\u0105ce przez dowolne porty z grupy load balancera. Po\u0142\u0105czenia wychodz\u0105ce (outbound) w obu grupach musz\u0105 by\u0107 otwarte protoko\u0142em TCP na wszystkie porty na wszystkie adresy. Mo\u017cna ograniczy\u0107 porty i adresy dla po\u0142\u0105cze\u0144 wychodz\u0105cych, ale wtedy trzeba ci\u0105gle monitorowa\u0107, czy nie pr\u00f3bujesz po\u0142\u0105czy\u0107 si\u0119 z zamkni\u0119tym portem.<\/p>\n

<\/p>\n

Magazyn (wolumeny)<\/strong> \u2014 wskazujemy parametry dysk\u00f3w dla maszyn. Pojemno\u015b\u0107 dysku nie mo\u017ce by\u0107 mniejsza ni\u017c ta okre\u015blona w AMI, dla ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

Szczeg\u00f3\u0142y zaawansowane<\/strong> \u2014 wskazujemy dodatkowe parametry.<\/p>\n

<\/p>\n

Opcja zakupu<\/strong> \u2014 czy chcemy kupi\u0107 instancje spotowe. Chcemy, ale tutaj nie zaznaczymy tego pola, skonfigurujemy to w Grupie Auto Scaling, tam jest wi\u0119cej opcji.<\/p>\n

<\/p>\n

Profil instancji IAM<\/strong> \u2014 wskazujemy rol\u0119, z kt\u00f3r\u0105 b\u0119d\u0105 uruchamiane instancje. Aby instancje dzia\u0142a\u0142y w ECS, potrzebuj\u0105 uprawnie\u0144, kt\u00f3re zwykle znajduj\u0105 si\u0119 w roli ecsInstanceRole<\/em>. W niekt\u00f3rych przypadkach mo\u017ce ona zosta\u0107 utworzona, je\u015bli nie, to tutaj instrukcja<\/a><\/noindex> znajdziesz informacje o tym, jak to zrobi\u0107. Po utworzeniu wskazujemy j\u0105 w szablonie.
\nDalej znajduje si\u0119 wiele parametr\u00f3w, w wi\u0119kszo\u015bci wsz\u0119dzie mo\u017cna zostawi\u0107 domy\u015blne warto\u015bci, ale ka\u017cde z nich ma zrozumia\u0142e opisy. Zawsze w\u0142\u0105czam parametry EBS-optimized instance i T2\/T3 Unlimited, je\u015bli s\u0105 u\u017cywane burstable<\/a><\/noindex> instancje.<\/p>\n

<\/p>\n

Dane u\u017cytkownika<\/strong> \u2014 wskazujemy dane u\u017cytkownika. B\u0119dziemy edytowa\u0107 plik \/etc\/ecs\/ecs.config<\/code>, w kt\u00f3rym znajduje si\u0119 konfiguracja agenta ECS.
\nPrzyk\u0142ad, jak mog\u0105 wygl\u0105da\u0107 dane u\u017cytkownika:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 parametr wskazuje, \u017ce instancja nale\u017cy do klastra o podanej nazwie, co oznacza, \u017ce ten klaster b\u0119dzie m\u00f3g\u0142 uruchamia\u0107 swoje zadania na tym serwerze. Na razie nie utworzyli\u015bmy klastra, ale przy jego tworzeniu u\u017cyjemy tej nazwy.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 parametr wskazuje, \u017ce po otrzymaniu sygna\u0142u o wy\u0142\u0105czeniu instancji spot, wszystkie zadania na niej powinny zosta\u0107 przeklasyfikowane do statusu Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parametr wskazuje, \u017ce po otrzymaniu sygna\u0142u SIGINT, wszystkie zadania maj\u0105 1 minut\u0119, zanim zostan\u0105 zabite.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parametr wskazuje, \u017ce jako mechanizm autoryzacji u\u017cywana jest schemata docker.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 parametry po\u0142\u0105czenia z prywatnym rejestrem kontener\u00f3w, gdzie przechowywane s\u0105 Twoje obrazy Docker. Je\u015bli jest publiczny, nie trzeba nic podawa\u0107.<\/p>\n
<\/p>\n
W ramach tego artyku\u0142u b\u0119d\u0119 u\u017cywa\u0107 publicznego obrazu z Docker Hub, dlatego nie trzeba podawa\u0107 parametr\u00f3w. ECS_ENGINE_AUTH_TYPE<\/code> i ECS_ENGINE_AUTH_DATA<\/code> nie jest konieczne.<\/p>\n
<\/p>\n
Warto wiedzie\u0107<\/strong>: zaleca si\u0119 regularne aktualizowanie AMI, poniewa\u017c w nowych wersjach aktualizowane s\u0105 wersje Docker, Linux, agenta ECS i innych. Aby o tym nie zapomnie\u0107, mo\u017cna ustawi\u0107 powiadomienia<\/a><\/noindex> o wydaniu nowych wersji. Mo\u017cesz otrzymywa\u0107 powiadomienia na email i aktualizowa\u0107 r\u0119cznie, lub mo\u017cesz napisa\u0107 funkcj\u0119 Lambda, kt\u00f3ra automatycznie stworzy now\u0105 wersj\u0119 Launch Template z zaktualizowanym AMI.<\/p>\n
<\/p>\n
EC2 Auto Scaling Group<\/strong><\/h3>\n
<\/p>\n
Auto Scaling Group odpowiada za uruchamianie i skalowanie instancji. Zarz\u0105dzanie grupami odbywa si\u0119 w sekcji EC2 -> Auto Scaling -> Auto Scaling Groups.<\/p>\n
<\/p>\n
Launch template<\/strong> \u2014 wybieramy stworzony na poprzednim kroku szablon. Wersj\u0119 pozostawiamy domy\u015bln\u0105.<\/p>\n
<\/p>\n
Opcje zakupu i typy instancji<\/strong> \u2014 wskazujemy typy instancji dla klastra. Adhere to launch template wykorzystuje typ instancji z Launch Template. Combine purchase options and instance types pozwala elastycznie konfigurowa\u0107 typy instancji. B\u0119dziemy go u\u017cywa\u0107.<\/p>\n
<\/p>\n
Opcjonalna baza On-Demand<\/strong> \u2014 liczba zwyk\u0142ych, nie spotowych instancji, kt\u00f3re zawsze b\u0119d\u0105 dzia\u0142a\u0107.<\/p>\n
<\/p>\n
Procent On-Demand powy\u017cej bazy<\/strong> \u2014 procentowe proporcje zwyk\u0142ych i spotowych instancji, 50-50 b\u0119dzie rozdziela\u0107 r\u00f3wno, 20-80 na ka\u017cd\u0105 zwyk\u0142\u0105 instancj\u0119 b\u0119dzie podnosi\u0107 4 spotowe. W ramach tego przyk\u0142adu wska\u017a\u0119 50-50, ale w rzeczywisto\u015bci najcz\u0119\u015bciej robimy 20-80, w niekt\u00f3rych przypadkach 0-100.<\/p>\n
<\/p>\n
Typy instancji<\/strong> \u2014 tutaj mo\u017cna wskaza\u0107 dodatkowe typy instancji, kt\u00f3re b\u0119d\u0105 u\u017cywane w klastrze. Nigdy tego nie u\u017cywali\u015bmy, poniewa\u017c niezbyt rozumiem sens tego rozwi\u0105zania. Mo\u017ce chodzi o limity na konkretne typy instancji, ale mo\u017cna je \u0142atwo zwi\u0119kszy\u0107 przez wsparcie. Je\u015bli znasz zastosowanie, ch\u0119tnie przeczytam w komentarzach)<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Sie\u0107<\/strong> \u2014 ustawienia sieci, wybierz VPC i podsieci dla maszyn, w wi\u0119kszo\u015bci przypadk\u00f3w nale\u017cy wybra\u0107 wszystkie dost\u0119pne podsieci.<\/p>\n
<\/p>\n
Obci\u0105\u017cenie r\u00f3wnowa\u017cenie<\/strong> \u2014 ustawienia load balancera, ale zrobimy to osobno, tutaj nic nie zmieniamy. Sprawdzanie stanu<\/strong> zostan\u0105 r\u00f3wnie\u017c skonfigurowane p\u00f3\u017aniej.<\/p>\n
<\/p>\n
Rozmiar grupy<\/strong> \u2014 podajemy limity na liczb\u0119 maszyn w klastrze i po\u017c\u0105dan\u0105 liczb\u0119 maszyn na starcie. Liczba maszyn w klastrze nigdy nie spadnie poni\u017cej minimalnej warto\u015bci i nie przekroczy maksymalnej, nawet je\u015bli wed\u0142ug metryk powinno nast\u0105pi\u0107 skalowanie.<\/p>\n
<\/p>\n
Polityki skalowania<\/strong> \u2014 parametry skalowania, ale b\u0119dziemy skalowa\u0107, opieraj\u0105c si\u0119 na uruchomionych zadaniach ECS, dlatego skonfigurujemy skalowanie p\u00f3\u017aniej.<\/p>\n
<\/p>\n
Ochrona przed skalowaniem instancji w d\u00f3\u0142<\/strong> \u2014 ochrona instancji przed usuni\u0119ciem podczas skalowania w d\u00f3\u0142. W\u0142\u0105czamy, aby ASG nie usun\u0119\u0142o maszyny, na kt\u00f3rej s\u0105 aktywne zadania. Wy\u0142\u0105czenie ochrony dla instancji, na kt\u00f3rych nie ma zada\u0144, b\u0119dzie realizowane przez ECS Capacity Provider.<\/p>\n
<\/p>\n
Dodaj tagi<\/strong> \u2014 mo\u017cna wskaza\u0107 tagi dla instancji (do tego musi by\u0107 zaznaczona opcja Tag new instances). Polecam wskaza\u0107 tag Name, wtedy wszystkie instancje, kt\u00f3re zostan\u0105 uruchomione w ramach grupy, b\u0119d\u0105 nosi\u0107 t\u0119 sam\u0105 nazw\u0119, co u\u0142atwi ich przegl\u0105danie w konsoli.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Po utworzeniu grupy otw\u00f3rz j\u0105 i przejd\u017a do sekcji Advanced configurations, dlaczego na etapie tworzenia w konsoli nie wida\u0107 wszystkich opcji.<\/p>\n
<\/p>\n
Polityki zako\u0144czenia<\/strong> \u2014 zasady, kt\u00f3re s\u0105 brane pod uwag\u0119 przy usuwaniu instancji. S\u0105 stosowane w kolejno\u015bci. Zazwyczaj u\u017cywamy takich jak na poni\u017cszym obrazku. Najpierw usuwane s\u0105 instancje z najbardziej starym Launch Template (na przyk\u0142ad, je\u015bli zaktualizowali\u015bmy AMI, stworzy\u0142a si\u0119 nowa wersja, ale wszystkie instancje zd\u0105\u017cy\u0142y na ni\u0105 przej\u015b\u0107). Nast\u0119pnie wybierane s\u0105 instancje, kt\u00f3re s\u0105 najbli\u017cej nast\u0119pnej jednostki czasu do rozliczenia. A p\u00f3\u017aniej wybierane s\u0105 najstarsze wed\u0142ug daty uruchomienia.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Warto wiedzie\u0107<\/strong>: do aktualizacji wszystkich maszyn w klastrze, wygodnie jest u\u017cy\u0107 Odnawianie instancji<\/a><\/noindex>. Je\u015bli po\u0142\u0105czy\u0107 to z funkcj\u0105 Lambda z poprzedniego kroku, otrzymasz w pe\u0142ni zautomatyzowany system aktualizacji instancji. Przed zaktualizowaniem wszystkich maszyn trzeba wy\u0142\u0105czy\u0107 ochron\u0119 przed skalowaniem instancji dla wszystkich instancji w grupie. Nie konfiguracj\u0119 w grupie, lecz ochrona na samych maszynach, wykonuje si\u0119 to na karcie zarz\u0105dzania instancjami.<\/p>\n
<\/p>\n
Application Load Balancer i EC2 Target Group<\/h3>\n
<\/p>\n
Balansator jest tworzony w sekcji EC2 \u2192 Load Balancing \u2192 Load Balancers. B\u0119dziemy u\u017cywa\u0107 Application Load Balancer, por\u00f3wnanie r\u00f3\u017cnych typ\u00f3w balansator\u00f3w mo\u017cna przeczyta\u0107 na stronie us\u0142ugi<\/a><\/noindex>.<\/p>\n
<\/p>\n
S\u0142uchacze<\/strong> \u2014 ma sens stworzenie port\u00f3w 80 i 443 oraz przekierowanie z 80 na 443 przy u\u017cyciu regu\u0142 balansatora.<\/p>\n
<\/p>\n
Strefy dost\u0119pno\u015bci<\/strong> \u2014 w wi\u0119kszo\u015bci przypadk\u00f3w wybieramy wszystkie strefy dost\u0119pno\u015bci.<\/p>\n
<\/p>\n
Skonfiguruj ustawienia zabezpiecze\u0144<\/strong> \u2014 tutaj podaje si\u0119 certyfikat SSL dla balansatora, najwygodniejsza opcja to stworzenie certyfikatu<\/a><\/noindex> w ACM. O r\u00f3\u017cnicach Polityka bezpiecze\u0144stwa<\/strong> mo\u017cna przeczyta\u0107 w dokumentacji<\/a><\/noindex>, mo\u017cna pozostawi\u0107 wybran\u0105 domy\u015blnie ELBSecurityPolicy-2016-08<\/code>. Po utworzeniu balansatora, zobaczysz jego nazw\u0119 DNS<\/strong>, dla kt\u00f3rego nale\u017cy skonfigurowa\u0107 CNAME dla Twojej domeny. Na przyk\u0142ad, tak to wygl\u0105da w Cloudflare.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Grupa zabezpiecze\u0144<\/strong> \u2014 tworzymy lub wybieramy grup\u0119 zabezpiecze\u0144 dla balansatora, wi\u0119cej na ten temat pisa\u0142em wcze\u015bniej w sekcji EC2 Launch Template \u2192 Network settings.<\/p>\n
<\/p>\n
Grupa docelowa<\/strong> \u2014 tworzymy grup\u0119, kt\u00f3ra odpowiada za routowanie zapyta\u0144 z balansatora do maszyn i sprawdza ich dost\u0119pno\u015b\u0107, aby wymienia\u0107 w przypadku problem\u00f3w. Typ docelowy<\/strong> musi by\u0107 instancj\u0105, Protok\u00f3\u0142<\/strong> i Port<\/strong> dowolne, je\u015bli korzystasz z HTTPS do komunikacji mi\u0119dzy balansatorem a instancjami, nale\u017cy na nich zainstalowa\u0107 certyfikat. W ramach tego przyk\u0142adu tego nie zrobimy, po prostu pozostawimy port 80.<\/p>\n
<\/p>\n
Sprawdzanie stanu<\/strong> \u2014 parametry sprawdzania dost\u0119pno\u015bci us\u0142ugi. W rzeczywistym serwisie powinno to by\u0107 osobne zapytanie, kt\u00f3re realizuje istotne cz\u0119\u015bci logiki biznesowej, w ramach tego przyk\u0142adu pozostawi\u0119 ustawienia domy\u015blne. Nast\u0119pnie mo\u017cna wybra\u0107 interwa\u0142 zapyta\u0144, timeout, kody odpowiedzi sukcesu itp. W naszym przyk\u0142adzie wska\u017aniki sukcesu ustawimy na 200-399, poniewa\u017c obraz Dockera, kt\u00f3ry b\u0119dzie u\u017cywany, zwraca kod 304.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Zarejestruj cele<\/strong> \u2014 tutaj wybierane s\u0105 maszyny dla grupy, ale w naszym przypadku zajmie si\u0119 tym ECS, wi\u0119c po prostu pomijamy ten krok.<\/p>\n
<\/p>\n
Warto wiedzie\u0107<\/strong>: na poziomie balansatora mo\u017cna w\u0142\u0105czy\u0107 logi, kt\u00f3re b\u0119d\u0105 przechowywane w S3 w okre\u015blonym formacie<\/a><\/noindex>. Mo\u017cna je stamt\u0105d eksportowa\u0107 do zewn\u0119trznych us\u0142ug analitycznych lub wykonywa\u0107 zapytania SQL bezpo\u015brednio na danych w S3 za pomoc\u0105 Athena<\/a><\/noindex>. To jest wygodne i dzia\u0142a bez dodatkowego kodu. Rekomenduj\u0119 r\u00f3wnie\u017c skonfigurowanie usuwania log\u00f3w z koszyka S3 po up\u0142ywie okre\u015blonego czasu.<\/p>\n
<\/p>\n
Definicja zadania ECS<\/h3>\n
<\/p>\n
Na poprzednich krokach stworzyli\u015bmy wszystko, co zwi\u0105zane z infrastruktur\u0105 us\u0142ugi, teraz przechodzimy do opisu kontener\u00f3w, kt\u00f3re b\u0119dziemy uruchamia\u0107. Dzieje si\u0119 to w sekcji ECS \u2192 Definicje zada\u0144.<\/p>\n
<\/p>\n
Kompatybilno\u015b\u0107 typu uruchomienia<\/strong> \u2014 wybieramy EC2.<\/p>\n
<\/p>\n
Rola IAM do wykonania zadania<\/strong> \u2014 wybieramy ecsTaskExecutionRole<\/code>. Dzi\u0119ki niej pisane s\u0105 logi, uzyskuje si\u0119 dost\u0119p do zmiennych tajnych itd.<\/p>\n
<\/p>\n
W sekcji Definicje kontener\u00f3w klikamy Dodaj kontener.<\/p>\n
<\/p>\n
Obraz<\/strong> \u2014 link do obrazu z kodem projektu, w ramach tego przyk\u0142adu wykorzystam publiczny obraz z Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Limity pami\u0119ci<\/strong> \u2014 limity pami\u0119ci dla kontenera. Twardy limit<\/strong> \u2014 twardy limit, je\u015bli kontener przekroczy okre\u015blon\u0105 warto\u015b\u0107, zostanie wykonana komenda docker kill, kontener natychmiast umrze. Mi\u0119kki limit<\/strong> \u2014 mi\u0119kki limit, kontener mo\u017ce przekroczy\u0107 okre\u015blon\u0105 warto\u015b\u0107, ale podczas uruchamiania zada\u0144 na maszynach ten parametr b\u0119dzie brany pod uwag\u0119. Na przyk\u0142ad, je\u015bli maszyna ma 4 GiB pami\u0119ci RAM, a mi\u0119kki limit kontenera to 2048 MiB, to na tej maszynie mog\u0105 by\u0107 uruchomione maksymalnie 2 zadania z tym kontenerem. W rzeczywisto\u015bci 4 GiB pami\u0119ci RAM to nieco mniej ni\u017c 4096 MiB, co mo\u017cna zobaczy\u0107 na karcie ECS Instances w klastrze. Mi\u0119kki limit nie mo\u017ce by\u0107 wi\u0119kszy ni\u017c twardy limit. Wa\u017cne jest zrozumienie, \u017ce je\u015bli w jednym zadaniu znajduje si\u0119 kilka kontener\u00f3w, to ich limity sumuj\u0105 si\u0119.<\/p>\n
<\/p>\n
Mapowanie port\u00f3w<\/strong> \u2014 w Port hosta<\/strong> wskazujemy 0, to oznacza, \u017ce port b\u0119dzie przydzielany dynamicznie, a jego \u015bledzeniem zajmie si\u0119 Grupa docelowa. Port kontenera<\/strong> \u2014 port, na kt\u00f3rym dzia\u0142a Twoja aplikacja, cz\u0119sto ustalany jest w poleceniu do wykonania, lub przypisywany w kodzie Twojej aplikacji, Dockerfile itd. W naszym przyk\u0142adzie u\u017cyjemy 3000, poniewa\u017c jest on okre\u015blony w Dockerfile<\/a><\/noindex> u\u017cywanym obrazie.<\/p>\n
<\/p>\n
Sprawdzanie stanu<\/strong> \u2014 parametry sprawdzania dzia\u0142ania kontenera, nie myli\u0107 z tym, kt\u00f3ry skonfigurowano w Grupie docelowej.<\/p>\n
<\/p>\n
\u015arodowisko<\/strong> \u2014 ustawienia \u015brodowiska. Jednostki CPU<\/strong> \u2014 przypomina to limity pami\u0119ci, tylko \u017ce chodzi o procesor. Ka\u017cde j\u0105dro procesora to 1024 jednostki, wi\u0119c je\u015bli na serwerze jest procesor dwurdzeniowy, a warto\u015b\u0107 w kontenerze wynosi 512, to na jednym serwerze mog\u0105 dzia\u0142a\u0107 4 zadania z tym kontenerem. Jednostki CPU zawsze odpowiadaj\u0105 liczbie rdzeni, nie mo\u017ce ich by\u0107 troch\u0119 mniej, jak ma to miejsce w przypadku pami\u0119ci.<\/p>\n
<\/p>\n
Polecenie<\/strong> \u2014 komenda do uruchamiania us\u0142ugi w kontenerze, wszystkie parametry podajemy oddzielone przecinkami. Mo\u017ce to by\u0107 gunicorn, npm itd. Je\u015bli nie podano, u\u017cyte zostanie warto\u015b\u0107 dyrektywy CMD z Dockerfile. Podajemy npm,start<\/code>.<\/p>\n
<\/p>\n
Zmienne \u015brodowiskowe<\/strong> \u2014 zmienne \u015brodowiskowe kontenera. Mog\u0105 to by\u0107 zar\u00f3wno proste dane tekstowe, jak i sekretne zmienne z Menad\u017cer Sekret\u00f3w<\/a><\/noindex> lub Magazyn Parametr\u00f3w<\/a><\/noindex>.<\/p>\n
<\/p>\n
Przechowywanie i logowanie<\/strong> \u2014 tutaj skonfigurujemy logowanie w CloudWatch Logs (us\u0142uga do log\u00f3w od AWS). Wystarczy zaznaczy\u0107 opcj\u0119 Auto-configure CloudWatch Logs. Po utworzeniu definicji zadania automatycznie stworzy si\u0119 grupa log\u00f3w w CloudWatch. Domy\u015blnie logi s\u0105 w niej przechowywane bezterminowo, zalecam zmian\u0119 okresu retencji z Never Expire na wymagany czas. Mo\u017cna to zrobi\u0107 w grupach log\u00f3w CloudWatch, trzeba klikn\u0105\u0107 na obecny okres i wybra\u0107 nowy.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Klaster ECS i Dostawca Zasob\u00f3w ECS<\/h3>\n
<\/p>\n
Przechodzimy do sekcji ECS \u2192 klastry, aby utworzy\u0107 klaster. Jako szablon wybieramy EC2 Linux + Networking.<\/p>\n
<\/p>\n
Nazwa klastra<\/strong> \u2014 bardzo wa\u017cne, podajemy tutaj tak\u0105 sam\u0105 nazw\u0119, jak podano w szablonie uruchamiania w parametrze ECS_CLUSTER<\/code>, w naszym przypadku \u2014 DemoApiClusterProd<\/code>. Zaznaczamy opcj\u0119 Create an empty cluster. Opcjonalnie mo\u017cna w\u0142\u0105czy\u0107 Container Insights, aby monitorowa\u0107 metryki us\u0142ug w CloudWatch. Je\u015bli wszystko zrobili\u015bmy poprawnie, to w sekcji ECS Instances zobaczymy maszyny, kt\u00f3re zosta\u0142y utworzone w grupie Auto Scaling.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Przechodzimy na zak\u0142adk\u0119 Dostawcy Zasob\u00f3w<\/strong> i tworzymy nowego. Przypominam, \u017ce jest on potrzebny do zarz\u0105dzania tworzeniem i wy\u0142\u0105czaniem maszyn w zale\u017cno\u015bci od liczby dzia\u0142aj\u0105cych zada\u0144 ECS. Wa\u017cne jest, aby zauwa\u017cy\u0107, \u017ce dostawca mo\u017ce by\u0107 przypisany tylko do jednej grupy.<\/p>\n
<\/p>\n
Grupa Auto Scaling<\/strong> \u2014 wybieramy wcze\u015bniej utworzon\u0105 grup\u0119.<\/p>\n
<\/p>\n
Zarz\u0105dzane skalowanie<\/strong> \u2014 w\u0142\u0105czamy, aby dostawca m\u00f3g\u0142 skalowa\u0107 us\u0142ug\u0119.<\/p>\n
<\/p>\n
Docelowa pojemno\u015b\u0107 %<\/strong> \u2014 jaki procent obci\u0105\u017cenia maszyn zadaniami jest nam potrzebny. Je\u015bli podamy 100%, to wszystkie maszyny b\u0119d\u0105 zawsze zaj\u0119te dzia\u0142aj\u0105cymi zadaniami. Je\u015bli podamy 50%, to po\u0142owa maszyn zawsze b\u0119dzie wolna. W takim przypadku, je\u015bli wyst\u0105pi nag\u0142y wzrost obci\u0105\u017cenia, nowe zadania natychmiast trafi\u0105 na wolne maszyny, bez potrzeby czekania na wdro\u017cenie instancji.<\/p>\n
<\/p>\n
Zarz\u0105dzana ochrona przed usuni\u0119ciem<\/strong> \u2014 w\u0142\u0105czamy, ten parametr pozwala dostawcy na usuni\u0119cie ochrony instancji przed usuni\u0119ciem. Dzieje si\u0119 to, gdy na maszynie nie ma aktywnych zada\u0144 i pozwala na Target capacity %.<\/p>\n
<\/p>\n
Us\u0142uga ECS i konfiguracja skalowania<\/h3>\n
<\/p>\n
Ostatni krok:) Aby utworzy\u0107 us\u0142ug\u0119, nale\u017cy przej\u015b\u0107 do wcze\u015bniej utworzonego klastra na zak\u0142adk\u0119 Us\u0142ugi.<\/p>\n
<\/p>\n
Typ uruchomienia<\/strong> \u2014 nale\u017cy klikn\u0105\u0107 na Prze\u0142\u0105cz na strategi\u0119 dostawcy pojemno\u015bci i wybra\u0107 wcze\u015bniej utworzonego dostawc\u0119.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Definicja zadania<\/strong> \u2014 wybieramy wcze\u015bniej utworzon\u0105 Definicj\u0119 zadania i jej rewizj\u0119.<\/p>\n
<\/p>\n
Nazwa us\u0142ugi<\/strong> \u2014 aby si\u0119 nie myli\u0107, zawsze podajemy tak\u0105 sam\u0105, jak Definicja zadania.<\/p>\n
<\/p>\n
Typ us\u0142ugi<\/strong> \u2014 zawsze Replica.<\/p>\n
<\/p>\n
Liczba zada\u0144<\/strong> \u2014 po\u017c\u0105dana liczba aktywnych zada\u0144 w us\u0142udze. Ten parametr jest zarz\u0105dzany przez skalowanie, ale i tak nale\u017cy go wskaza\u0107.<\/p>\n
<\/p>\n
Minimalny zdrowy procent<\/strong> i Maksymalny procent<\/strong> \u2014 okre\u015blaj\u0105 zachowanie zada\u0144 podczas wdra\u017cania. Warto\u015bci domy\u015blne to 100 i 200, co oznacza, \u017ce w momencie wdra\u017cania liczba zada\u0144 wzro\u015bnie kilkakrotnie, a nast\u0119pnie wr\u00f3ci do po\u017c\u0105danej. Je\u015bli pracuje 1 zadanie, min=0, a max=100, to wtedy podczas wdra\u017cania b\u0119dzie ono usuwane, a nast\u0119pnie podnoszone nowe, co oznacza przest\u00f3j. Je\u015bli pracuje 1 zadanie, min=50, max=150, to wdro\u017cenie w og\u00f3le nie nast\u0105pi, poniewa\u017c 1 zadania nie mo\u017cna podzieli\u0107 na p\u00f3\u0142 ani zwi\u0119kszy\u0107 o po\u0142ow\u0119.<\/p>\n
<\/p>\n
Typ wdro\u017cenia<\/strong> \u2014 pozostawiamy Rolling update.<\/p>\n
<\/p>\n
Szablony rozmieszczenia<\/strong> \u2014 zasady rozmieszczania zada\u0144 na maszynach. Domy\u015blnie ustawione AZ Balanced Spread \u2014 oznacza to, \u017ce ka\u017cde nowe zadanie b\u0119dzie umieszczane na nowej instancji, dop\u00f3ki nie zostan\u0105 uruchomione maszyny we wszystkich strefach dost\u0119pno\u015bci. Zwykle stosujemy BinPack \u2014 CPU i Spread \u2014 AZ, przy tej polityce zadania s\u0105 umieszczane mo\u017cliwie najg\u0119\u015bciej na jednej maszynie w zale\u017cno\u015bci od CPU. W razie potrzeby utworzenia nowej maszyny, jest tworzona w nowej strefie dost\u0119pno\u015bci.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Typ balancera obci\u0105\u017cenia<\/strong> \u2014 wybieramy Application Load Balancer.<\/p>\n
<\/p>\n
Rola IAM us\u0142ugi<\/strong> \u2014 wybieramy ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Nazwa balancera obci\u0105\u017cenia<\/strong> \u2014 wybieramy wcze\u015bniej utworzony balancer.<\/p>\n
<\/p>\n
Okres gracji dla sprawdzania poprawno\u015bci<\/strong> \u2014 przerwa przed wykonaniem test\u00f3w sprawno\u015bci po wdro\u017ceniu nowego zadania, zazwyczaj ustawiamy 60 sekund.<\/p>\n
<\/p>\n
Kontener do balansowania obci\u0105\u017cenia<\/strong> \u2014 w punkcie Nazwa grupy docelowej wybieramy wcze\u015bniej utworzon\u0105 grup\u0119, a wszystko automatycznie si\u0119 uzupe\u0142ni.<\/p>\n
<\/p>\n
\"Tworzenie<\/p>\n
<\/p>\n
Automatyczne skalowanie us\u0142ugi<\/strong> \u2014 parametry skalowania us\u0142ugi. Wybieramy Skonfiguruj automatyczne skalowanie us\u0142ugi, aby dostosowa\u0107 po\u017c\u0105dan\u0105 liczb\u0119 zada\u0144. Ustawiamy minimaln\u0105 i maksymaln\u0105 liczb\u0119 zada\u0144 podczas skalowania.<\/p>\n
<\/p>\n
Rola IAM dla automatycznego skalowania us\u0142ugi<\/strong> \u2014 wybieramy AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automatyczne polityki skalowania zada\u0144<\/strong> \u2014 zasady skalowania. S\u0105 2 rodzaje:<\/p>\n
<\/p>\n
    \n
  1. \u015aledzenie celu<\/strong> \u2014 \u015bledzenie metryki docelowej (zu\u017cycie CPU\/RAM lub liczba \u017c\u0105da\u0144 na ka\u017cde zadanie). Na przyk\u0142ad, chcemy, aby \u015brednie obci\u0105\u017cenie procesora wynosi\u0142o 85%, kiedy przekroczy ten poziom, nowe zadania b\u0119d\u0105 dodawane, a\u017c obci\u0105\u017cenie wr\u00f3ci do warto\u015bci docelowej. Je\u015bli obci\u0105\u017cenie jest ni\u017csze, zadania b\u0119d\u0105 usuwane, je\u015bli nie w\u0142\u0105czona jest ochrona przed skalowaniem w d\u00f3\u0142 (Wy\u0142\u0105cz skalowanie w d\u00f3\u0142<\/strong>).<\/li>\n
  2. Skalowanie krokowe<\/strong> \u2014 reakcja na dowolne zdarzenie. Mo\u017cna tutaj skonfigurowa\u0107 reakcj\u0119 na ka\u017cde zdarzenie (Alarm CloudWatch), kt\u00f3re si\u0119 wydarzy, mo\u017cna doda\u0107 lub usun\u0105\u0107 okre\u015blon\u0105 liczb\u0119 zada\u0144, lub wskaza\u0107 dok\u0142adn\u0105 liczb\u0119 zada\u0144.<\/li>\n<\/ol>\n
    <\/p>\n
    Us\u0142uga mo\u017ce mie\u0107 kilka regu\u0142 skalowania, co mo\u017ce by\u0107 pomocne, wa\u017cne, aby upewni\u0107 si\u0119, \u017ce nie koliduj\u0105 one ze sob\u0105.<\/p>\n
    <\/p>\n
    Podsumowanie<\/h2>\n
    <\/p>\n
    Je\u015bli post\u0119powa\u0142e\u015b zgodnie z instrukcjami i u\u017cywa\u0142e\u015b tego samego obrazu Dockera, Twoja us\u0142uga powinna wy\u015bwietla\u0107 tak\u0105 stron\u0119.<\/p>\n
    <\/p>\n
    \"Tworzenie<\/p>\n
    <\/p>\n
      \n
    1. Stworzyli\u015bmy szablon, wed\u0142ug kt\u00f3rego uruchamiane s\u0105 wszystkie maszyny w us\u0142udze. Nauczyli\u015bmy si\u0119 r\u00f3wnie\u017c aktualizowa\u0107 maszyny w przypadku zmiany szablonu.<\/li>\n
    2. Skonfigurowali\u015bmy obs\u0142ug\u0119 sygna\u0142u zatrzymania instancji spot, dlatego w ci\u0105gu minuty po jego odebraniu wszystkie dzia\u0142aj\u0105ce zadania s\u0105 usuwane z maszyny, w ten spos\u00f3b nic nie jest tracone i nie przerywa si\u0119.<\/li>\n
    3. Wdro\u017cyli\u015bmy balansator, aby r\u00f3wnomiernie rozk\u0142ada\u0107 obci\u0105\u017cenie mi\u0119dzy maszynami.<\/li>\n
    4. Stworzyli\u015bmy us\u0142ug\u0119, kt\u00f3ra dzia\u0142a na instancjach spot, co obni\u017ca koszty maszyn o oko\u0142o 3 razy.<\/li>\n
    5. Skonfigurowali\u015bmy automatyczne skalowanie w obie strony, aby obs\u0142ugiwa\u0107 zwi\u0119kszone obci\u0105\u017cenia, ale jednocze\u015bnie nie p\u0142aci\u0107 za przestoje.<\/li>\n
    6. U\u017cywamy Capacity Provider, aby aplikacja zarz\u0105dza\u0142a infrastruktur\u0105 (maszynami), a nie odwrotnie.<\/li>\n
    7. Jeste\u015bmy \u015bwietni.<\/li>\n<\/ol>\n
      <\/p>\n
      Je\u015bli masz przewidywalne skoki obci\u0105\u017cenia, na przyk\u0142ad, gdy reklamujesz si\u0119 w du\u017cej kampanii emailowej, mo\u017cesz skonfigurowa\u0107 skalowanie wed\u0142ug harmonogramu<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Mo\u017cna tak\u017ce przeprowadza\u0107 skalowanie na podstawie danych z r\u00f3\u017cnych cz\u0119\u015bci Twojego systemu. Na przyk\u0142ad, mamy funkcjonalno\u015b\u0107 wysy\u0142ki indywidualnych ofert promocyjnych<\/a><\/noindex> u\u017cytkownik\u00f3w aplikacji mobilnej. Czasami kampania jest wysy\u0142ana do ponad 1 miliona os\u00f3b. Po takiej wysy\u0142ce zawsze obserwuje si\u0119 znaczny wzrost zapyta\u0144 do API, poniewa\u017c wielu u\u017cytkownik\u00f3w jednocze\u015bnie loguje si\u0119 do aplikacji. Je\u015bli wi\u0119c zauwa\u017camy, \u017ce w kolejce do wysy\u0142ki promocyjnych powiadomie\u0144 ich ilo\u015b\u0107 znacznie przekracza standardowe wska\u017aniki, mo\u017cemy natychmiast uruchomi\u0107 kilka dodatkowych maszyn i zada\u0144, aby by\u0107 gotowym na obci\u0105\u017cenie.<\/p>\n
      <\/p>\n
      B\u0119d\u0119 wdzi\u0119czny, je\u015bli w komentarzach podzielicie si\u0119 interesuj\u0105cymi przypadkami u\u017cycia instancji spot i ECS lub czym\u015b na temat skalowania.<\/p>\n
      <\/p>\n
      Wkr\u00f3tce uka\u017c\u0105 si\u0119 artyku\u0142y na temat tego, jak przetwarzamy tysi\u0105ce zdarze\u0144 analitycznych na sekund\u0119 na przewa\u017cnie serverless stacku (na pieni\u0105dze) oraz jak zorganizowany jest deploy us\u0142ug za pomoc\u0105 GitLab CI i Terraform Cloud.<\/p>\n
      <\/p>\n
      Subskrybujcie nas, b\u0119dzie ciekawie!<\/p>\n
      Tylko zarejestrowani u\u017cytkownicy mog\u0105 bra\u0107 udzia\u0142 w ankiecie. Zaloguj si\u0119<\/a><\/noindex>, prosz\u0119.<\/p>\n
      Czy u\u017cywacie instancji spot na produkcji?<\/h2>\n