Cześć wszystkim! Nazywam się Kirill, jestem CTO w Adapty. Większość naszej architektury opiera się na AWS, a dzisiaj opowiem, jak zmniejszyliśmy koszty serwerów trzykrotnie, korzystając z instancji spot na środowisku produkcyjnym, oraz jak skonfigurować ich automatyczne skalowanie. Najpierw będzie przegląd, jak to działa, a potem szczegółowa instrukcja uruchomienia.
Czym są instancje spot?
spot to serwery innych użytkowników AWS, które w danym momencie są niewykorzystane i sprzedają je z dużą zniżką (Amazon podaje do 90%, według naszego doświadczenia około 3x, co różni się w zależności od regionu, AZ i typu instancji). Ich główną różnicą od zwykłych jest to, że mogą zostać wyłączone w każdej chwili. Dlatego przez długi czas uważaliśmy, że można je używać tylko do środowisk deweloperskich lub do obliczeń, zachowując wyniki pośrednie na S3 lub w bazie, ale nie do produkcji. Istnieją zewnętrzne rozwiązania, które pozwalają używać spotów w produkcji, ale w naszym przypadku wiązałoby się to z wieloma problemami, dlatego ich nie wdrażaliśmy. Podejście opisane w artykule działa w pełni w ramach standardowej funkcjonalności AWS, bez dodatkowych skryptów, cronów itp.
Poniżej przedstawiam kilka zrzutów ekranu, które pokazują historię cen instancji spot.
m5.large w regionie eu-west-1 (Irlandia). Cena jest głównie stabilna przez 3 miesiące, aktualnie oszczędność wynosi 2.9x.
m5.large w regionie us-east-1 (N. Wirginia). Cena zmienia się stale przez 3 miesiące, aktualnie oszczędność wynosi od 2.3x do 2.8x w zależności od strefy dostępności.
t3.small w regionie us-east-1 (N. Wirginia). Cena jest stabilna przez 3 miesiące, aktualnie oszczędność wynosi 3.4x.
Architektura usługi
Podstawowa architektura usługi, o której będziemy mówić w tym artykule, przedstawiona jest na diagramie poniżej.
Application Load Balancer → EC2 Target Group → Elastic Container Service
Jako load balancer używany jest Application Load Balancer (ALB), który kieruje żądania do EC2 Target Group (TG). TG odpowiada za otwieranie portów na instancjach dla ALB i kojarzenie ich z portami kontenerów Elastic Container Service (ECS). ECS to odpowiednik Kubernetes w AWS, który zarządza kontenerami Docker.
Na jednym instansie może działać kilka kontenerów na tych samych portach, dlatego nie możemy ich ustawić na stałe. ECS informuje TG, że uruchamia nowe zadanie (w terminologii Kubernetes nazywane pod), wykonuje sprawdzenie dostępnych portów na instansie i przydziela jeden z nich do uruchamianego zadania. TG regularnie sprawdza, czy instans działa i czy API na nim jest sprawne za pomocą health check, a jeśli zauważy jakieś problemy, przestaje przekazywać tam zapytania.
EC2 Auto Scaling Groups + ECS Capacity Providers
Na powyższej ilustracji nie pokazano usługi EC2 Auto Scaling Groups (ASG). Z nazwy można wywnioskować, że odpowiada ona za skalowanie instansów. Do niedawna w AWS nie było wbudowanej możliwości zarządzania liczbą uruchomionych maszyn z poziomu ECS. ECS pozwalał na skalowanie liczby zadań, na przykład w zależności od wykorzystania CPU, RAM lub liczby zapytań. Jednak jeśli zadania zajmowały wszystkie dostępne instansy, nowe maszyny nie były automatycznie uruchamiane.
To się zmieniło wraz z wprowadzeniem ECS Capacity Providers (ECS CP). Teraz każdą usługę w ECS można połączyć z ASG, a jeśli zadania nie mieszczą się na działających instansach, uruchomią się nowe (jednak w ramach ustalonych limitów ASG). Działa to w obie strony: jeśli ECS CP zauważy bezczynne instansy bez zadań, zleci ASG, aby je wyłączyła. ECS CP ma możliwość wskazania docelowego procentu obciążenia instansów, aby pewna liczba maszyn zawsze była dostępna do szybkiego skalowania zadań, o czym opowiem nieco później.
Szablony uruchamiania EC2
Ostatnią usługą, o której opowiem, zanim przejdę do szczegółowego opisu tworzenia tej infrastruktury, są szablony uruchamiania EC2. Pozwalają one stworzyć szablon, według którego będą uruchamiane wszystkie maszyny, aby nie powtarzać tego za każdym razem od nowa. Można tu wybrać typ uruchamianej maszyny, grupę bezpieczeństwa, obraz dysku i wiele innych parametrów. Można także wskazać dane użytkownika, które będą przesyłane do wszystkich uruchamianych instansów. W danych użytkownika można uruchamiać skrypty, na przykład można edytować zawartość pliku .
Jednym z najważniejszych parametrów konfiguracji w ramach tego artykułu jest =true. Jeśli ten parametr jest włączony, to gdy ECS otrzyma sygnał o tym, że instancja spotowa jest zabierana, zmienia status wszystkich zadań, które na niej działają, na Draining. Żadne nowe zadania nie będą przypisywane do tej instancji, a jeśli są zadania, które aktualnie chcą na nią przejść, zostaną one anulowane. Żądania z balancera również przestaną przychodzić. Powiadomienie o usunięciu instancji jest wysyłane na 2 minuty przed rzeczywistym zdarzeniem. Dlatego jeśli Twój serwis nie wykonuje zadań dłużej niż 2 minuty i nic nie zapisuje na dysku, możesz korzystać z instancji spotowych bez utraty danych.
Jeśli chodzi o dysk — AWS niedawno użycie Elastic File System (EFS) w połączeniu z ECS, dzięki temu nawet dysk nie stanowi przeszkody, ale nie próbowaliśmy tego, ponieważ zasadniczo nie potrzebujemy dysku do przechowywania stanu. Domyślnie po otrzymaniu SIGINT (wysyłane w momencie zmiany statusu zadania na Draining) wszystkie działające zadania zostaną zatrzymane w ciągu 30 sekund, nawet jeśli nie udało im się zakończyć, a ten czas można zmienić za pomocą parametru . Najważniejsze, aby nie ustawiać go na więcej niż 2 minuty dla instancji spotowych.
Tworzenie usługi
Przechodzimy bezpośrednio do tworzenia opisanej usługi. W trakcie opowiem również o kilku przydatnych aspektach, o których nie wspomniano wcześniej. Ogólnie to instrukcja krok po kroku, ale nie będę omawiać bardzo podstawowych ani zbyt specyficznych przypadków. Wszystkie działania odbywają się w wizualnej konsoli AWS, ale można je powtórzyć programowo za pomocą CloudFormation lub Terraform. W Adapty używamy Terraform.
Szablon uruchamiania EC2
W tej usłudze tworzona jest konfiguracja maszyn, które będą używane. Zarządzanie szablonami odbywa się w sekcji EC2 -> Instances -> Launch templates.
Obraz maszyny Amazon (AMI) — wskazujemy obraz dysku, na podstawie którego będą uruchamiane wszystkie instancje. Dla ECS w większości przypadków należy używać zoptymalizowanego obrazu od Amazon. Jest regularnie aktualizowany i zawiera wszystko, co potrzebne do działania ECS. Aby poznać aktualny ID obrazu, przechodzimy na stronę , wybieramy używany region i kopiujemy ID AMI dla niego. Na przykład, dla regionu us-east-1 aktualny w momencie pisania tego artykułu ID to ami-00c7c1cf5bdc913ed. Ten ID należy wkleić w punkcie Specify a custom value.
Typ instancji — wskazujemy typ instancji. Wybieramy ten, który najlepiej odpowiada naszym potrzebom.
Para kluczy (logowanie) — wskazujemy certyfikat, za pomocą którego można połączyć się z instancją przez SSH, jeśli to konieczne.
Ustawienia sieciowe — wskazujemy parametry sieci. Platforma sieciowa w większości przypadków powinna być Wirtualną Chmurą Prywatną (VPC). Grupy zabezpieczeń — grupy zabezpieczeń dla twoich instancji. Ponieważ będziemy używać load balancera przed instancjami, zalecam wskazanie tutaj grupy, która zezwala na połączenia przychodzące tylko z load balancera. Oznacza to, że będziesz miał 2 grupy zabezpieczeń, jedną dla load balancera, która zezwala na połączenia przychodzące (inbound) z wszędzie przez porty 80 (http) i 443 (https), a drugą dla maszyn, która zezwala na połączenia przychodzące przez dowolne porty z grupy load balancera. Połączenia wychodzące (outbound) w obu grupach muszą być otwarte protokołem TCP na wszystkie porty na wszystkie adresy. Można ograniczyć porty i adresy dla połączeń wychodzących, ale wtedy trzeba ciągle monitorować, czy nie próbujesz połączyć się z zamkniętym portem.
Magazyn (wolumeny) — wskazujemy parametry dysków dla maszyn. Pojemność dysku nie może być mniejsza niż ta określona w AMI, dla ECS Optimized — 30 GiB.
Szczegóły zaawansowane — wskazujemy dodatkowe parametry.
Opcja zakupu — czy chcemy kupić instancje spotowe. Chcemy, ale tutaj nie zaznaczymy tego pola, skonfigurujemy to w Grupie Auto Scaling, tam jest więcej opcji.
Profil instancji IAM — wskazujemy rolę, z którą będą uruchamiane instancje. Aby instancje działały w ECS, potrzebują uprawnień, które zwykle znajdują się w roli ecsInstanceRole. W niektórych przypadkach może ona zostać utworzona, jeśli nie, to tutaj znajdziesz informacje o tym, jak to zrobić. Po utworzeniu wskazujemy ją w szablonie.
Dalej znajduje się wiele parametrów, w większości wszędzie można zostawić domyślne wartości, ale każde z nich ma zrozumiałe opisy. Zawsze włączam parametry EBS-optimized instance i T2/T3 Unlimited, jeśli są używane instancje.
Dane użytkownika — wskazujemy dane użytkownika. Będziemy edytować plik /etc/ecs/ecs.config, w którym znajduje się konfiguracja agenta ECS.
Przykład, jak mogą wyglądać dane użytkownika:
#!/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 — parametr wskazuje, że instancja należy do klastra o podanej nazwie, co oznacza, że ten klaster będzie mógł uruchamiać swoje zadania na tym serwerze. Na razie nie utworzyliśmy klastra, ale przy jego tworzeniu użyjemy tej nazwy.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametr wskazuje, że po otrzymaniu sygnału o wyłączeniu instancji spot, wszystkie zadania na niej powinny zostać przeklasyfikowane do statusu Draining.
ECS_CONTAINER_STOP_TIMEOUT=1m — parametr wskazuje, że po otrzymaniu sygnału SIGINT, wszystkie zadania mają 1 minutę, zanim zostaną zabite.
ECS_ENGINE_AUTH_TYPE=docker — parametr wskazuje, że jako mechanizm autoryzacji używana jest schemata docker.
ECS_ENGINE_AUTH_DATA=... — parametry połączenia z prywatnym rejestrem kontenerów, gdzie przechowywane są Twoje obrazy Docker. Jeśli jest publiczny, nie trzeba nic podawać.
W ramach tego artykułu będę używać publicznego obrazu z Docker Hub, dlatego nie trzeba podawać parametrów. ECS_ENGINE_AUTH_TYPE i ECS_ENGINE_AUTH_DATA nie jest konieczne.
Warto wiedzieć: zaleca się regularne aktualizowanie AMI, ponieważ w nowych wersjach aktualizowane są wersje Docker, Linux, agenta ECS i innych. Aby o tym nie zapomnieć, można o wydaniu nowych wersji. Możesz otrzymywać powiadomienia na email i aktualizować ręcznie, lub możesz napisać funkcję Lambda, która automatycznie stworzy nową wersję Launch Template z zaktualizowanym AMI.
EC2 Auto Scaling Group
Auto Scaling Group odpowiada za uruchamianie i skalowanie instancji. Zarządzanie grupami odbywa się w sekcji EC2 -> Auto Scaling -> Auto Scaling Groups.
Launch template — wybieramy stworzony na poprzednim kroku szablon. Wersję pozostawiamy domyślną.
Opcje zakupu i typy instancji — wskazujemy typy instancji dla klastra. Adhere to launch template wykorzystuje typ instancji z Launch Template. Combine purchase options and instance types pozwala elastycznie konfigurować typy instancji. Będziemy go używać.
Opcjonalna baza On-Demand — liczba zwykłych, nie spotowych instancji, które zawsze będą działać.
Procent On-Demand powyżej bazy — procentowe proporcje zwykłych i spotowych instancji, 50-50 będzie rozdzielać równo, 20-80 na każdą zwykłą instancję będzie podnosić 4 spotowe. W ramach tego przykładu wskaźę 50-50, ale w rzeczywistości najczęściej robimy 20-80, w niektórych przypadkach 0-100.
Typy instancji — tutaj można wskazać dodatkowe typy instancji, które będą używane w klastrze. Nigdy tego nie używaliśmy, ponieważ niezbyt rozumiem sens tego rozwiązania. Może chodzi o limity na konkretne typy instancji, ale można je łatwo zwiększyć przez wsparcie. Jeśli znasz zastosowanie, chętnie przeczytam w komentarzach)
Sieć — ustawienia sieci, wybierz VPC i podsieci dla maszyn, w większości przypadków należy wybrać wszystkie dostępne podsieci.
Obciążenie równoważenie — ustawienia load balancera, ale zrobimy to osobno, tutaj nic nie zmieniamy. Sprawdzanie stanu zostaną również skonfigurowane później.
Rozmiar grupy — podajemy limity na liczbę maszyn w klastrze i pożądaną liczbę maszyn na starcie. Liczba maszyn w klastrze nigdy nie spadnie poniżej minimalnej wartości i nie przekroczy maksymalnej, nawet jeśli według metryk powinno nastąpić skalowanie.
Polityki skalowania — parametry skalowania, ale będziemy skalować, opierając się na uruchomionych zadaniach ECS, dlatego skonfigurujemy skalowanie później.
Ochrona przed skalowaniem instancji w dół — ochrona instancji przed usunięciem podczas skalowania w dół. Włączamy, aby ASG nie usunęło maszyny, na której są aktywne zadania. Wyłączenie ochrony dla instancji, na których nie ma zadań, będzie realizowane przez ECS Capacity Provider.
Dodaj tagi — można wskazać tagi dla instancji (do tego musi być zaznaczona opcja Tag new instances). Polecam wskazać tag Name, wtedy wszystkie instancje, które zostaną uruchomione w ramach grupy, będą nosić tę samą nazwę, co ułatwi ich przeglądanie w konsoli.
Po utworzeniu grupy otwórz ją i przejdź do sekcji Advanced configurations, dlaczego na etapie tworzenia w konsoli nie widać wszystkich opcji.
Polityki zakończenia — zasady, które są brane pod uwagę przy usuwaniu instancji. Są stosowane w kolejności. Zazwyczaj używamy takich jak na poniższym obrazku. Najpierw usuwane są instancje z najbardziej starym Launch Template (na przykład, jeśli zaktualizowaliśmy AMI, stworzyła się nowa wersja, ale wszystkie instancje zdążyły na nią przejść). Następnie wybierane są instancje, które są najbliżej następnej jednostki czasu do rozliczenia. A później wybierane są najstarsze według daty uruchomienia.
Warto wiedzieć: do aktualizacji wszystkich maszyn w klastrze, wygodnie jest użyć . Jeśli połączyć to z funkcją Lambda z poprzedniego kroku, otrzymasz w pełni zautomatyzowany system aktualizacji instancji. Przed zaktualizowaniem wszystkich maszyn trzeba wyłączyć ochronę przed skalowaniem instancji dla wszystkich instancji w grupie. Nie konfigurację w grupie, lecz ochrona na samych maszynach, wykonuje się to na karcie zarządzania instancjami.
Application Load Balancer i EC2 Target Group
Balansator jest tworzony w sekcji EC2 → Load Balancing → Load Balancers. Będziemy używać Application Load Balancer, porównanie różnych typów balansatorów można przeczytać na .
Słuchacze — ma sens stworzenie portów 80 i 443 oraz przekierowanie z 80 na 443 przy użyciu reguł balansatora.
Strefy dostępności — w większości przypadków wybieramy wszystkie strefy dostępności.
Skonfiguruj ustawienia zabezpieczeń — tutaj podaje się certyfikat SSL dla balansatora, najwygodniejsza opcja to w ACM. O różnicach Polityka bezpieczeństwa można przeczytać w , można pozostawić wybraną domyślnie ELBSecurityPolicy-2016-08. Po utworzeniu balansatora, zobaczysz jego nazwę DNS, dla którego należy skonfigurować CNAME dla Twojej domeny. Na przykład, tak to wygląda w Cloudflare.
Grupa zabezpieczeń — tworzymy lub wybieramy grupę zabezpieczeń dla balansatora, więcej na ten temat pisałem wcześniej w sekcji EC2 Launch Template → Network settings.
Grupa docelowa — tworzymy grupę, która odpowiada za routowanie zapytań z balansatora do maszyn i sprawdza ich dostępność, aby wymieniać w przypadku problemów. Typ docelowy musi być instancją, Protokół i Port dowolne, jeśli korzystasz z HTTPS do komunikacji między balansatorem a instancjami, należy na nich zainstalować certyfikat. W ramach tego przykładu tego nie zrobimy, po prostu pozostawimy port 80.
Sprawdzanie stanu — parametry sprawdzania dostępności usługi. W rzeczywistym serwisie powinno to być osobne zapytanie, które realizuje istotne części logiki biznesowej, w ramach tego przykładu pozostawię ustawienia domyślne. Następnie można wybrać interwał zapytań, timeout, kody odpowiedzi sukcesu itp. W naszym przykładzie wskaźniki sukcesu ustawimy na 200-399, ponieważ obraz Dockera, który będzie używany, zwraca kod 304.
Zarejestruj cele — tutaj wybierane są maszyny dla grupy, ale w naszym przypadku zajmie się tym ECS, więc po prostu pomijamy ten krok.
Warto wiedzieć: na poziomie balansatora można włączyć logi, które będą przechowywane w S3 w określonym . Można je stamtąd eksportować do zewnętrznych usług analitycznych lub wykonywać zapytania SQL bezpośrednio na danych w S3 za pomocą . To jest wygodne i działa bez dodatkowego kodu. Rekomenduję również skonfigurowanie usuwania logów z koszyka S3 po upływie określonego czasu.
Definicja zadania ECS
Na poprzednich krokach stworzyliśmy wszystko, co związane z infrastrukturą usługi, teraz przechodzimy do opisu kontenerów, które będziemy uruchamiać. Dzieje się to w sekcji ECS → Definicje zadań.
Kompatybilność typu uruchomienia — wybieramy EC2.
Rola IAM do wykonania zadania — wybieramy ecsTaskExecutionRole. Dzięki niej pisane są logi, uzyskuje się dostęp do zmiennych tajnych itd.
W sekcji Definicje kontenerów klikamy Dodaj kontener.
Obraz — link do obrazu z kodem projektu, w ramach tego przykładu wykorzystam publiczny obraz z Docker Hub .
Limity pamięci — limity pamięci dla kontenera. Twardy limit — twardy limit, jeśli kontener przekroczy określoną wartość, zostanie wykonana komenda docker kill, kontener natychmiast umrze. Miękki limit — miękki limit, kontener może przekroczyć określoną wartość, ale podczas uruchamiania zadań na maszynach ten parametr będzie brany pod uwagę. Na przykład, jeśli maszyna ma 4 GiB pamięci RAM, a miękki limit kontenera to 2048 MiB, to na tej maszynie mogą być uruchomione maksymalnie 2 zadania z tym kontenerem. W rzeczywistości 4 GiB pamięci RAM to nieco mniej niż 4096 MiB, co można zobaczyć na karcie ECS Instances w klastrze. Miękki limit nie może być większy niż twardy limit. Ważne jest zrozumienie, że jeśli w jednym zadaniu znajduje się kilka kontenerów, to ich limity sumują się.
Mapowanie portów — w Port hosta wskazujemy 0, to oznacza, że port będzie przydzielany dynamicznie, a jego śledzeniem zajmie się Grupa docelowa. Port kontenera — port, na którym działa Twoja aplikacja, często ustalany jest w poleceniu do wykonania, lub przypisywany w kodzie Twojej aplikacji, Dockerfile itd. W naszym przykładzie użyjemy 3000, ponieważ jest on określony w używanym obrazie.
Sprawdzanie stanu — parametry sprawdzania działania kontenera, nie mylić z tym, który skonfigurowano w Grupie docelowej.
Środowisko — ustawienia środowiska. Jednostki CPU — przypomina to limity pamięci, tylko że chodzi o procesor. Każde jądro procesora to 1024 jednostki, więc jeśli na serwerze jest procesor dwurdzeniowy, a wartość w kontenerze wynosi 512, to na jednym serwerze mogą działać 4 zadania z tym kontenerem. Jednostki CPU zawsze odpowiadają liczbie rdzeni, nie może ich być trochę mniej, jak ma to miejsce w przypadku pamięci.
Polecenie — komenda do uruchamiania usługi w kontenerze, wszystkie parametry podajemy oddzielone przecinkami. Może to być gunicorn, npm itd. Jeśli nie podano, użyte zostanie wartość dyrektywy CMD z Dockerfile. Podajemy npm,start.
Zmienne środowiskowe — zmienne środowiskowe kontenera. Mogą to być zarówno proste dane tekstowe, jak i sekretne zmienne z lub .
Przechowywanie i logowanie — tutaj skonfigurujemy logowanie w CloudWatch Logs (usługa do logów od AWS). Wystarczy zaznaczyć opcję Auto-configure CloudWatch Logs. Po utworzeniu definicji zadania automatycznie stworzy się grupa logów w CloudWatch. Domyślnie logi są w niej przechowywane bezterminowo, zalecam zmianę okresu retencji z Never Expire na wymagany czas. Można to zrobić w grupach logów CloudWatch, trzeba kliknąć na obecny okres i wybrać nowy.
Klaster ECS i Dostawca Zasobów ECS
Przechodzimy do sekcji ECS → klastry, aby utworzyć klaster. Jako szablon wybieramy EC2 Linux + Networking.
Nazwa klastra — bardzo ważne, podajemy tutaj taką samą nazwę, jak podano w szablonie uruchamiania w parametrze ECS_CLUSTER, w naszym przypadku — DemoApiClusterProd. Zaznaczamy opcję Create an empty cluster. Opcjonalnie można włączyć Container Insights, aby monitorować metryki usług w CloudWatch. Jeśli wszystko zrobiliśmy poprawnie, to w sekcji ECS Instances zobaczymy maszyny, które zostały utworzone w grupie Auto Scaling.
Przechodzimy na zakładkę Dostawcy Zasobów i tworzymy nowego. Przypominam, że jest on potrzebny do zarządzania tworzeniem i wyłączaniem maszyn w zależności od liczby działających zadań ECS. Ważne jest, aby zauważyć, że dostawca może być przypisany tylko do jednej grupy.
Grupa Auto Scaling — wybieramy wcześniej utworzoną grupę.
Zarządzane skalowanie — włączamy, aby dostawca mógł skalować usługę.
Docelowa pojemność % — jaki procent obciążenia maszyn zadaniami jest nam potrzebny. Jeśli podamy 100%, to wszystkie maszyny będą zawsze zajęte działającymi zadaniami. Jeśli podamy 50%, to połowa maszyn zawsze będzie wolna. W takim przypadku, jeśli wystąpi nagły wzrost obciążenia, nowe zadania natychmiast trafią na wolne maszyny, bez potrzeby czekania na wdrożenie instancji.
Zarządzana ochrona przed usunięciem — włączamy, ten parametr pozwala dostawcy na usunięcie ochrony instancji przed usunięciem. Dzieje się to, gdy na maszynie nie ma aktywnych zadań i pozwala na Target capacity %.
Usługa ECS i konfiguracja skalowania
Ostatni krok:) Aby utworzyć usługę, należy przejść do wcześniej utworzonego klastra na zakładkę Usługi.
Typ uruchomienia — należy kliknąć na Przełącz na strategię dostawcy pojemności i wybrać wcześniej utworzonego dostawcę.
Definicja zadania — wybieramy wcześniej utworzoną Definicję zadania i jej rewizję.
Nazwa usługi — aby się nie mylić, zawsze podajemy taką samą, jak Definicja zadania.
Typ usługi — zawsze Replica.
Liczba zadań — pożądana liczba aktywnych zadań w usłudze. Ten parametr jest zarządzany przez skalowanie, ale i tak należy go wskazać.
Minimalny zdrowy procent i Maksymalny procent — określają zachowanie zadań podczas wdrażania. Wartości domyślne to 100 i 200, co oznacza, że w momencie wdrażania liczba zadań wzrośnie kilkakrotnie, a następnie wróci do pożądanej. Jeśli pracuje 1 zadanie, min=0, a max=100, to wtedy podczas wdrażania będzie ono usuwane, a następnie podnoszone nowe, co oznacza przestój. Jeśli pracuje 1 zadanie, min=50, max=150, to wdrożenie w ogóle nie nastąpi, ponieważ 1 zadania nie można podzielić na pół ani zwiększyć o połowę.
Typ wdrożenia — pozostawiamy Rolling update.
Szablony rozmieszczenia — zasady rozmieszczania zadań na maszynach. Domyślnie ustawione AZ Balanced Spread — oznacza to, że każde nowe zadanie będzie umieszczane na nowej instancji, dopóki nie zostaną uruchomione maszyny we wszystkich strefach dostępności. Zwykle stosujemy BinPack — CPU i Spread — AZ, przy tej polityce zadania są umieszczane możliwie najgęściej na jednej maszynie w zależności od CPU. W razie potrzeby utworzenia nowej maszyny, jest tworzona w nowej strefie dostępności.
Typ balancera obciążenia — wybieramy Application Load Balancer.
Rola IAM usługi — wybieramy ecsServiceRole.
Nazwa balancera obciążenia — wybieramy wcześniej utworzony balancer.
Okres gracji dla sprawdzania poprawności — przerwa przed wykonaniem testów sprawności po wdrożeniu nowego zadania, zazwyczaj ustawiamy 60 sekund.
Kontener do balansowania obciążenia — w punkcie Nazwa grupy docelowej wybieramy wcześniej utworzoną grupę, a wszystko automatycznie się uzupełni.
Automatyczne skalowanie usługi — parametry skalowania usługi. Wybieramy Skonfiguruj automatyczne skalowanie usługi, aby dostosować pożądaną liczbę zadań. Ustawiamy minimalną i maksymalną liczbę zadań podczas skalowania.
Rola IAM dla automatycznego skalowania usługi — wybieramy AWSServiceRoleForApplicationAutoScaling_ECSService.
Automatyczne polityki skalowania zadań — zasady skalowania. Są 2 rodzaje:
- Śledzenie celu — śledzenie metryki docelowej (zużycie CPU/RAM lub liczba żądań na każde zadanie). Na przykład, chcemy, aby średnie obciążenie procesora wynosiło 85%, kiedy przekroczy ten poziom, nowe zadania będą dodawane, aż obciążenie wróci do wartości docelowej. Jeśli obciążenie jest niższe, zadania będą usuwane, jeśli nie włączona jest ochrona przed skalowaniem w dół (Wyłącz skalowanie w dół).
- Skalowanie krokowe — reakcja na dowolne zdarzenie. Można tutaj skonfigurować reakcję na każde zdarzenie (Alarm CloudWatch), które się wydarzy, można dodać lub usunąć określoną liczbę zadań, lub wskazać dokładną liczbę zadań.
Usługa może mieć kilka reguł skalowania, co może być pomocne, ważne, aby upewnić się, że nie kolidują one ze sobą.
Podsumowanie
Jeśli postępowałeś zgodnie z instrukcjami i używałeś tego samego obrazu Dockera, Twoja usługa powinna wyświetlać taką stronę.
- Stworzyliśmy szablon, według którego uruchamiane są wszystkie maszyny w usłudze. Nauczyliśmy się również aktualizować maszyny w przypadku zmiany szablonu.
- Skonfigurowaliśmy obsługę sygnału zatrzymania instancji spot, dlatego w ciągu minuty po jego odebraniu wszystkie działające zadania są usuwane z maszyny, w ten sposób nic nie jest tracone i nie przerywa się.
- Wdrożyliśmy balansator, aby równomiernie rozkładać obciążenie między maszynami.
- Stworzyliśmy usługę, która działa na instancjach spot, co obniża koszty maszyn o około 3 razy.
- Skonfigurowaliśmy automatyczne skalowanie w obie strony, aby obsługiwać zwiększone obciążenia, ale jednocześnie nie płacić za przestoje.
- Używamy Capacity Provider, aby aplikacja zarządzała infrastrukturą (maszynami), a nie odwrotnie.
- Jesteśmy świetni.
Jeśli masz przewidywalne skoki obciążenia, na przykład, gdy reklamujesz się w dużej kampanii emailowej, możesz skonfigurować skalowanie według .
Można także przeprowadzać skalowanie na podstawie danych z różnych części Twojego systemu. Na przykład, mamy funkcjonalność użytkowników aplikacji mobilnej. Czasami kampania jest wysyłana do ponad 1 miliona osób. Po takiej wysyłce zawsze obserwuje się znaczny wzrost zapytań do API, ponieważ wielu użytkowników jednocześnie loguje się do aplikacji. Jeśli więc zauważamy, że w kolejce do wysyłki promocyjnych powiadomień ich ilość znacznie przekracza standardowe wskaźniki, możemy natychmiast uruchomić kilka dodatkowych maszyn i zadań, aby być gotowym na obciążenie.
Będę wdzięczny, jeśli w komentarzach podzielicie się interesującymi przypadkami użycia instancji spot i ECS lub czymś na temat skalowania.
Wkrótce ukażą się artykuły na temat tego, jak przetwarzamy tysiące zdarzeń analitycznych na sekundę na przeważnie serverless stacku (na pieniądze) oraz jak zorganizowany jest deploy usług za pomocą GitLab CI i Terraform Cloud.
Subskrybujcie nas, będzie ciekawie!
Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. , proszę.
Czy używacie instancji spot na produkcji?
22,2%Tak
66,7%Nie18
11,1%Dowiedziałem się o nich z artykułu, planuję używać
Głosowało 27 użytkowników. Wstrzymało się 5 użytkowników.
Źródło: habr.com
