Automatyczne skalowanie usług ECS i równoważenie obciążenia

Stała wartość desired count w usłudze ECS nie reaguje na wahania ruchu — albo przydzielają Państwo zbyt dużo zasobów (marnując pieniądze), albo zbyt mało (pogarszając wydajność). ECS Service Auto Scaling automatycznie dostosowuje wartość desired count zadań na podstawie metryk CloudWatch. Wykorzystuje w tym celu usługę Application Auto Scaling — ten sam mechanizm jest używany przez DynamoDB, Aurora i ElastiCache. Automatyczne skalowanie usług ECS obsługuje zasady śledzenia celu, skalowania krokowego i skalowania według harmonogramu.

Przed dodaniem zasad skalowania należy zarejestrować usługę ECS w Application Auto Scaling jako scalable target. Należy określić minimalną i maksymalną liczbę zadań, nazwę klastra oraz nazwę usługi jako identyfikator zasobu. Tworzy to zakres, w którym będzie działać automatyczne skalowanie. Minimalna liczba zapewnia stałą bazową pojemność, a maksymalna zapobiega niekontrolowanemu skalowaniu, które mogłoby wyczerpać pojemność Fargate lub instancji EC2.

Target Tracking to zalecana zasada automatycznego skalowania dla większości usług ECS. Najczęściej używaną metryką docelową jest ECSServiceAverageCPUUtilization — należy ustawić cel na poziomie 50–70%, a ECS będzie dodawać lub usuwać zadania, aby utrzymać ten poziom użycia procesora. Inną przydatną metryką jest ALBRequestCountPerTarget: śledzi ona liczbę żądań ALB przypadających na zadanie i umożliwia skalowanie w celu utrzymania docelowej liczby żądań na instancję. AWS automatycznie obsługuje skalowanie w górę i w dół, stosując odpowiednie okresy schładzania.

Dołączenie Application Load Balancer (ALB) do usługi ECS rozdziela ruch HTTP/HTTPS między wszystkie uruchomione zadania. Grupa docelowa ALB rejestruje adres IP każdego zadania (w przypadku Fargate/awsvpc) lub port kontenera (w trybie bridge). ECS automatycznie rejestruje nowe zadania w grupie docelowej podczas ich uruchamiania i wyrejestrowuje je podczas zatrzymywania. ALB wykonuje testy kondycji każdego zadania; zadania uznane za niesprawne są opróżniane (połączenia są zamykane w kontrolowany sposób), zanim usługa je zakończy.

Jednym z użytecznych wzorców jest kierowanie różnych ścieżek URL do różnych usług ECS za pomocą ALB path-based routing. Pojedynczy ALB z jednym odbiornikiem HTTPS może kierować: /api/orders/* do usługi ECS Orders, /api/users/* do usługi ECS Users oraz /api/products/* do usługi ECS Products — każda z nich korzysta z własnej usługi ECS i niezależnego skalowania. Eliminuje to potrzebę używania oddzielnych modułów równoważenia obciążenia dla każdego mikrousługi, obniżając koszty i upraszczając zarządzanie DNS.

Gdy zadanie ECS jest kończone (podczas skalowania w dół lub wdrażania), ALB oznacza je jako draining i przestaje kierować do niego nowe żądania, jednocześnie pozwalając na zakończenie żądań będących w toku. deregistration delay (domyślnie 300 sekund, z możliwością konfiguracji w zakresie 0–3600 sekund) określa, jak długo ALB czeka przed wymuszonym zamknięciem połączeń. W przypadku ECS i krótkiego czasu trwania żądań warto ustawić mniejsze opóźnienie wyrejestrowania (30–60 sekund), aby przyspieszyć wdrożenia i operacje skalowania w dół. W przypadku długotrwałych połączeń (WebSocket, przesyłanie plików) należy pozostawić większe opóźnienie.

Poza użyciem procesora i pamięci można publikować custom CloudWatch metrics z aplikacji (głębokość kolejki, aktywne sesje, kluczowe wskaźniki biznesowe) i używać ich do sterowania skalowaniem. Jeśli na przykład każde zadanie ECS może jednocześnie obsługiwać 50 komunikatów z kolejki, można publikować głębokość kolejki SQS jako niestandardową metrykę i utworzyć zasadę śledzenia celu ustawioną na 50 komunikatów na zadanie. Umożliwia to bezpośrednie skalowanie sterowane logiką biznesową zamiast polegania na metrykach infrastruktury, które mogą nie odzwierciedlać obciążenia aplikacji.

Podobnie jak EC2 Auto Scaling, ECS obsługuje task scale-in protection. Uruchomione zadanie może za pośrednictwem interfejsu API ECS ustawić własną flagę ochrony przed skalowaniem w dół, aby nie zostać zakończone podczas skalowania w dół w trakcie przetwarzania krytycznego zadania. Jest to przydatne w przypadku zadań ECS pełniących funkcję pracowników SQS — pracownik, który właśnie pobrał długotrwałe zadanie, może się ochronić, zakończyć pracę, a następnie usunąć ochronę. Bez tego skalowanie w dół mogłoby zakończyć zadanie w trakcie przetwarzania, powodując powielenie zadania lub utratę danych.

Metrykę skalowania należy wybrać starannie. CPU utilisation jest ustawieniem domyślnym i sprawdza się w przypadku obciążeń ograniczonych wydajnością obliczeniową. Memory utilisation (ECSServiceAverageMemoryUtilization) jest przydatne w aplikacjach ograniczonych ilością pamięci, ale zwiększenie dostępnej pamięci wymaga dodania zadań — jeśli zadanie jest ograniczone pamięcią przypisaną do pojedynczego zadania, a nie liczbą równoległych operacji, lepszym rozwiązaniem może być zmiana przydziału pamięci w definicji zadania. ALBRequestCountPerTarget bezpośrednio odpowiada doświadczeniu użytkownika i jest najbardziej praktyczną metryką dla internetowych interfejsów API — skalowanie odbywa się na podstawie rzeczywistej liczby żądań przypadających na zadanie.

ECS Deployment Circuit Breaker automatycznie wykrywa nieudane wdrożenia i przywraca ostatnią stabilną wersję. Bez niego nieudane wdrożenie (kontener, który nie przechodzi testów kondycji) powodowałoby, że ECS bez końca próbowałby uruchamiać nowe zadania. Po włączeniu wyłącznika, jeśli określony odsetek nowo uruchomionych zadań nie przejdzie testów kondycji w wyznaczonym oknie wykrywania, ECS oznacza wdrożenie jako FAILED i automatycznie przywraca poprzednią wersję definicji zadania. Zapobiega to długotrwałemu pogorszeniu działania usługi wskutek nieudanego wdrożenia.

Architektura gotowego do użycia produkcyjnie konteneryzowanego internetowego interfejsu API: Route 53 rozwiązuje domenę do nazwy DNS ALB; ALB kończy połączenia HTTPS (certyfikat ACM), stosuje reguły WAF i kieruje żądania do ECS service target group; zadania Fargate w prywatnych podsieciach w 3 AZ obsługują żądania; ECS Service Auto Scaling ze śledzeniem celu na podstawie ALBRequestCountPerTarget dostosowuje liczbę zadań od 2 do 50; zadania łączą się z RDS Aurora i ElastiCache w prywatnych podsieciach. Wszystkie dzienniki trafiają do CloudWatch Logs, a metryki zasilają pulpity i alarmy CloudWatch.

Sprawdź swoją znajomość zagadnień AWS Solutions Architect (SAA-C03) omówionych w tej lekcji.

W tej lekcji nauczyli się Państwo, że ECS Service Auto Scaling korzysta z Application Auto Scaling i śledzenia celu (na podstawie użycia procesora, żądań ALB lub niestandardowych metryk), aby dostosowywać liczbę zadań w skonfigurowanym zakresie wartości minimalnej i maksymalnej; ALB path-based routing umożliwia jednemu modułowi równoważenia obciążenia obsługę wielu mikrousług ECS przez kierowanie ścieżek URL do różnych grup docelowych; natomiast Deployment Circuit Breaker automatycznie przywraca nieudane wdrożenia, zanim spowodują długotrwałe pogorszenie działania usługi. To kończy moduł dotyczący ECS i kontenerów — w następnej części omówimy Amazon EKS dla Kubernetes w AWS.