Dobór rozmiaru i automatyczne skalowanie

Zmiana rozmiaru polega na dopasowaniu jednostek SKU maszyn wirtualnych lub usług Azure do rzeczywistych wymagań obciążenia — bez nadmiernej aprowizacji (marnowania pieniędzy) ani zbyt małej aprowizacji (ryzyka pogorszenia wydajności). Większość organizacji początkowo dokonuje nadmiernej aprowizacji o 30–50% z ostrożności podczas migracji z lokalnego środowiska. Regularna analiza rozmiaru, zazwyczaj przeprowadzana co miesiąc, może odzyskać znaczną część tych nadmiernych wydatków bez wpływu na wydajność aplikacji.

Użyj metryk Azure Monitor i VM Insights, aby przez co najmniej 30 dni zbierać dane o procesorze, pamięci, operacjach wejścia/wyjścia dysku oraz przepustowości sieci. Zwracaj uwagę na szczytowe wykorzystanie (P95 lub P99), a nie średnią, aby mieć pewność, że maszyna wirtualna o dobranym rozmiarze obsłuży skoki ruchu. Zalecenie Azure Advisor dotyczące zmiany rozmiaru domyślnie wykorzystuje dane z ostatnich 7 dni, ale w konfiguracji Advisor można wydłużyć ten okres do 30 lub 60 dni, aby uzyskać bardziej reprezentatywne dane.

Maszyny wirtualne Azure są uporządkowane w rodziny jednostek SKU zoptymalizowane pod kątem różnych obciążeń: D-series (ogólnego przeznaczenia), E-series (zoptymalizowane pod kątem pamięci), F-series (zoptymalizowane pod kątem obliczeń), N-series (GPU) i L-series (zoptymalizowane pod kątem magazynu). Jeśli użycie procesora przez maszynę wirtualną jest niskie, ale użycie pamięci wysokie, przejście z serii D do serii E przy tej samej liczbie vCPU zapewnia więcej pamięci RAM przy podobnym koszcie. Zmiana rozmiaru maszyny wirtualnej w Azure zazwyczaj wymaga krótkiego, trwającego kilka minut ponownego uruchomienia.

Zaplanowane automatyczne skalowanie jest właściwym wyborem, gdy wzorce obciążenia są przewidywalne. Aplikację handlową, która odnotowuje duży ruch w godzinach pracy i niemal zerowy ruch w nocy, można skonfigurować tak, aby o 07:00 zwiększała skalę, a o 22:00 ją zmniejszała. Zarówno Virtual Machine Scale Sets (VMSS), jak i App Service obsługują zaplanowane reguły automatycznego skalowania. Takie podejście jest prostsze i zapewnia bardziej przewidywalne koszty niż automatyczne skalowanie oparte na metrykach w przypadku znanych wzorców obciążenia.

Automatyczne skalowanie oparte na metrykach dynamicznie dodaje lub usuwa wystąpienia w odpowiedzi na metryki w czasie rzeczywistym, takie jak procent użycia procesora, długość kolejki żądań HTTP lub metryki niestandardowe publikowane za pośrednictwem Azure Monitor. Definiuje się reguły zwiększania skali (kiedy dodawać wystąpienia) i reguły zmniejszania skali (kiedy usuwać wystąpienia), a także okresy ochładzania zapobiegające zbyt częstym zmianom. Najlepszą praktyką jest ustawienie progu zwiększania skali niżej niż progu zmniejszania skali — na przykład zwiększanie skali przy użyciu procesora >70% i zmniejszanie przy użyciu <30% — z 5-minutowym okresem ochładzania.

Azure Spot VMs umożliwiają korzystanie z niewykorzystanej pojemności platformy Azure z rabatem do 90% w porównaniu z cenami płatności zgodnie z użyciem. Kompromisem jest to, że gdy Azure ponownie potrzebuje tej pojemności, może usunąć maszyny Spot z 30-sekundowym wyprzedzeniem. Dzięki temu wystąpienia Spot są idealne dla przerywalnych obciążeń wsadowych, takich jak renderowanie, obliczenia naukowe i potoki przetwarzania danych. Dzięki zasadzie mieszania priorytetów VMSS obsługuje w jednym zestawie skalowania połączenie zwykłych maszyn wirtualnych (dla bazowej pojemności) z maszynami Spot (dla dodatkowej pojemności w okresach wzmożonego zapotrzebowania).

Automatyczne skalowanie usługi Azure App Service działa na poziomie planu App Service — dodaje lub usuwa wystąpienia robocze na podstawie skonfigurowanych reguł. Dostępne wyzwalacze metryk obejmują długość kolejki HTTP, procent użycia procesora i procent użycia pamięci. Warstwa Standard oraz wyższe obsługują skalowanie ręczne i automatyczne, natomiast warstwa Basic obsługuje tylko skalowanie ręczne. W przypadku obciążeń bezserwerowych warto rozważyć Azure Functions w planie Consumption, który skaluje się do zera i nalicza opłaty tylko za wykonania, całkowicie eliminując koszt bezczynnych wystąpień.

Typowe pułapki automatycznego skalowania: session affinity — jeśli aplikacja przechowuje stan sesji w pamięci maszyny wirtualnej, skalowanie w dół spowoduje utratę sesji; zamiast tego użyj Redis Cache lub sesji obsługiwanych przez bazę danych. Długi czas uruchamiania — jeśli rozgrzanie maszyn wirtualnych lub kontenerów trwa 10 minut, automatyczne skalowanie oparte na metrykach nie zareaguje wystarczająco szybko; przed przewidywanymi szczytami wstępnie przygotuj wystąpienia, planując skalowanie w górę. Zbyt agresywne skalowanie w dół — kończenie działania wystąpień podczas przetwarzania żądań w toku powoduje błędy; skonfiguruj connection draining oraz odpowiednio długi okres schładzania.

Dobór odpowiedniego rozmiaru dotyczy również usług PaaS. Rozmiar usługi Azure SQL Database w modelu DTU można zmniejszyć, jeśli procent DTU stale utrzymuje się poniżej 50%. Model vCore umożliwia niezależne skalowanie procesora i magazynu. Usługę Azure Cache for Redis można obniżyć z warstwy Premium do Standard, jeśli trwałość danych i replikacja geograficzna nie są potrzebne. Pule węzłów Azure Kubernetes Service mogą korzystać z Cluster Autoscaler, aby skalować liczbę węzłów w górę i w dół na podstawie oczekujących podów oraz stanów bezczynności.

Dobór odpowiedniego rozmiaru nie jest jednorazowym działaniem. Obciążenia zmieniają się z czasem — zmieniają się wzorce ruchu, dodawane są funkcje, a liczba użytkowników rośnie lub maleje. Uwzględnij comiesięczny przegląd doboru rozmiaru w procesie FinOps: pobieraj zalecenia usługi Advisor, analizuj 10 maszyn wirtualnych o najniższym wykorzystaniu oraz nadmiernie skonfigurowane usługi PaaS i twórz elementy pracy dla odpowiedzialnych zespołów. Śledź zrealizowane oszczędności w porównaniu z wygenerowanymi zaleceniami, aby wykazać kierownictwu zwrot z inwestycji w FinOps.

Optymalna strategia kosztowa polega na tym, aby najpierw dobrać odpowiedni rozmiar, a następnie dokonać rezerwacji. Zakup Reserved VM Instance dla nadmiernie skonfigurowanej maszyny wirtualnej oznacza zobowiązanie dotyczące niewłaściwego SKU. Najpierw zmień rozmiar maszyny wirtualnej na właściwy, obserwuj jej nowe wykorzystanie przez 30 dni, aby potwierdzić stabilność, a następnie kup rezerwację dla tego odpowiednio dobranego SKU. To dwuetapowe podejście maksymalizuje rabat i pozwala uniknąć marnowania zarezerwowanej pojemności.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) z tej lekcji.

W tej lekcji nauczono się, że: dobór odpowiedniego rozmiaru dopasowuje SKU maszyn wirtualnych do rzeczywistych wymagań obciążenia na podstawie metryk wydajności, planowane i oparte na metrykach automatyczne skalowanie dynamicznie dostosowuje pojemność do zapotrzebowania, a Spot VMs zapewniają rabaty do 90% dla przerywalnych obciążeń wsadowych. Następnie omówione zostaną plany oszczędnościowe i rezerwacje Azure dla obciążeń wymagających zobowiązania.