Dobór rozmiaru i Compute Optimizer

Jednym z najczęstszych i najbardziej kosztownych błędów w architekturze chmurowej jest nadmierne przydzielanie zasobów — przydzielanie większej ilości zasobów, niż obciążenie rzeczywiście potrzebuje. Zespoły IT często przydzielają zbyt dużo zasobów z powodu przyzwyczajeń wyniesionych ze środowisk lokalnych (kupowanie pojemności na obciążenie szczytowe), obaw przed spadkiem wydajności albo po prostu braku ponownej weryfikacji początkowych decyzji dotyczących rozmiaru. W AWS nadmiernie zwymiarowane instancje EC2, woluminy EBS i funkcje Lambda generują niepotrzebne koszty przez każdą minutę działania. Dobór właściwego rozmiaru to systematyczny proces identyfikowania i eliminowania tego marnotrawstwa.

AWS Compute Optimizer analizuje historyczne dane o wykorzystaniu z CloudWatch i wykorzystuje uczenie maszynowe do rekomendowania optymalnych zasobów obliczeniowych AWS. Obejmuje instancje EC2, grupy EC2 Auto Scaling, woluminy EBS, funkcje Lambda oraz Amazon ECS na Fargate. Compute Optimizer wymaga co najmniej 30 dni historii metryk, aby generować wiarygodne rekomendacje. Jego włączenie jest bezpłatne, a rekomendacje zawierają szacowane miesięczne oszczędności oraz ocenę ryzyka zmiany.

Compute Optimizer analizuje wykorzystanie procesora EC2, wykorzystanie pamięci (za pośrednictwem agenta CloudWatch), przepustowość sieci i IOPS EBS z ostatnich 3, 14 lub co najmniej 30 dni. Następnie przedstawia jedno z czterech ustaleń: Optimized (bieżący rozmiar jest odpowiedni), Over-provisioned (można zmniejszyć rozmiar), Under-provisioned (należy zwiększyć rozmiar) albo Not optimized (niewystarczająca ilość danych). Należy zawsze przeanalizować ryzyko dla wydajności — Compute Optimizer przypisuje każdej rekomendacji poziom ryzyka VeryLow, Low, Medium, High.

Opłaty za funkcje Lambda są naliczane za każdą milisekundę czasu wykonania pomnożoną przez przydzieloną pamięć. Przydzielenie większej ilości pamięci, niż jest potrzebna, generuje niepotrzebne koszty, ale większa pamięć oznacza również większą moc procesora — dlatego właściwym rozwiązaniem jest ustawienie pamięci, przy którym koszt pojedynczego wywołania jest minimalny. Compute Optimizer analizuje czas trwania wywołań Lambda, współczynnik błędów i metryki limitu czasu, aby rekomendować optymalne ustawienie pamięci. Narzędzie open source Lambda Power Tuning może również wywoływać funkcję przy różnych ustawieniach pamięci, aby empirycznie znaleźć konfigurację zapewniającą najniższy koszt.

Woluminy EBS są często nadmiernie zwymiarowane zarówno pod względem rozmiaru (niewykorzystywane miejsce na dysku), jak i IOPS (zarezerwowane IOPS, które nigdy nie są wykorzystywane). Compute Optimizer analizuje metryki VolumeReadOps, VolumeWriteOps, VolumeReadBytes, VolumeWriteBytes. Częsta rekomendacja to migracja z gp2 do gp3 (który oddziela rozmiar od IOPS) — można wtedy niezależnie dobrać IOPS, często oszczędzając 20%. Należy również zidentyfikować niepodłączone woluminy EBS (instancje zostały zakończone, ale woluminy pozostały), a następnie utworzyć ich migawki lub je usunąć.

Compute Optimizer analizuje wykorzystanie zasobów przez ASG dla instancji w całej grupie i rekomenduje zmiany w szablonie uruchamiania dotyczące typu instancji. Jeśli wszystkie instancje w ASG są stale nadmiernie zwymiarowane, przełączenie na mniejszy typ instancji obniża koszt w całej skali. Na przykład jeśli ASG korzysta średnio z 10 instancji typu m5.large, przełączenie na m5.medium pozwala zaoszczędzić 50% na każdej instancji. Compute Optimizer rekomenduje również instancje oparte na Graviton, gdy oprogramowanie jest z nimi zgodne, zapewniając zarówno wzrost wydajności, jak i obniżenie kosztów.

AWS Trusted Advisor to kolejne narzędzie dostarczające informacji dotyczących optymalizacji kosztów, a także kontroli bezpieczeństwa, wydajności, tolerancji błędów i limitów usług. Najważniejsze kontrole kosztów obejmują: Low Utilization EC2 Instances (wykorzystanie procesora poniżej 10% przez co najmniej 4 dni), Unassociated Elastic IP Addresses (opłaty są naliczane, gdy adresy nie są przypisane), Underutilized EBS Volumes, Idle Load Balancers (brak zdrowych celów) oraz Unused Reserved Instances. Podstawowe kontrole Trusted Advisor są bezpłatne; pełny zestaw wymaga planu Business lub Enterprise Support.

Firma AWS regularnie udostępnia nowe, wydajniejsze generacje instancji EC2, które zapewniają lepszą wydajność przy niższym lub takim samym koszcie. Przejście z 5. generacji (m5, c5, r5) do 7. generacji (m7g, c7g, r7g) może zapewnić o 40% wyższą wydajność obliczeniową przy podobnym lub niższym koszcie. Compute Optimizer specjalnie wskazuje możliwości przejścia na nowsze generacje, w tym instancje oparte na Graviton. Aktualizacja instancji jest często najprostszym działaniem w ramach doboru właściwego rozmiaru — ta sama konfiguracja, nowszy sprzęt, lepsza wydajność i niższy koszt.

Instancje RDS są kosztowne i często nadmiernie zwymiarowane. Do oceny wykorzystania RDS należy używać metryk CloudWatch: CPUUtilization, FreeableMemory, ReadIOPS i WriteIOPS. Jeśli wykorzystanie procesora utrzymuje się poniżej 20%, a ilość dostępnej pamięci pozostaje stale wysoka, warto rozważyć zmniejszenie instancji. W produkcyjnych bazach danych z konfiguracją Multi-AZ dobór właściwego rozmiaru podwaja oszczędności, ponieważ zmieniane są zarówno instancja podstawowa, jak i zapasowa. Należy również rozważyć przejście z RDS MySQL/PostgreSQL na Aurora, która często zapewnia lepszą wydajność przy podobnym koszcie i jest bardziej opłacalna przy dużej skali.

Dobór właściwego rozmiaru powinien być procesem ciągłym, a nie jednorazowym działaniem. Należy ustalić miesięczny lub kwartalny harmonogram przeglądów: pobierać rekomendacje Compute Optimizer, oceniać, które z nich można bezpiecznie zastosować, wdrażać zmiany w oknie konserwacyjnym i mierzyć oszczędności. Proste działania warto automatyzować: czyszczenie niepodłączonych woluminów EBS, zwalnianie nieużywanych adresów Elastic IP oraz usuwanie bezczynnych modułów równoważenia obciążenia można realizować za pomocą skryptów. Należy utworzyć w CloudWatch panel optymalizacji kosztów, który śledzi miesięczne wydatki według usług i wskazuje nietypowe wzrosty.

Dobór właściwego rozmiaru rozwiązuje problem nadmiernego przydzielania zasobów w ramach istniejących architektur, ale czasami problemem jest sama architektura. Pojedyncza duża instancja EC2 uruchamiająca wiele aplikacji może wymagać dekompozycji architektury (mikrousługi na Fargate), a nie tylko przejścia na mniejszą instancję. Monolityczna baza danych może wymagać fragmentacji lub buforowania zamiast samego zmniejszenia instancji. Dobór właściwego rozmiaru to pierwszy i najszybszy krok. Optymalizacja architektury (serverless, kontenery, buforowanie) zapewnia większe i trwalsze oszczędności, ale wymaga więcej pracy. Filar Cost Optimisation zaleca realizowanie obu podejść.

W tej lekcji dowiedzieli się Państwo, że: AWS Compute Optimizer wykorzystuje uczenie maszynowe i metryki CloudWatch do rekomendowania zasobów obliczeniowych o właściwie dobranym rozmiarze, dobór właściwego rozmiaru dotyczy EC2, Lambda, EBS, ASG oraz ECS na Fargate, a przejście na nowsze generacje instancji (zwłaszcza Graviton) zapewnia zarówno obniżenie kosztów, jak i poprawę wydajności. Należy uczynić dobór właściwego rozmiaru regularną praktyką, a nie jednorazowym działaniem. W następnej części omówimy modele zakupu Reserved Instances, Savings Plans i Spot.