Zalecenia dotyczące projektowania niezawodnej strategii skalowania
Dotyczy tego zalecenia listy kontrolnej dotyczącej niezawodności platformy Azure Well-Architected Framework:
| RE:06 | Zaimplementuj terminową i niezawodną strategię skalowania na poziomie aplikacji, danych i infrastruktury. |
|---|
Powiązany przewodnik: partycjonowanie danych
W tym przewodniku opisano zalecenia dotyczące projektowania niezawodnej strategii skalowania.
Definicje
| Okres | Definicja |
|---|---|
| Skalowanie w pionie | Podejście do skalowania, które dodaje pojemność obliczeniową do istniejących zasobów. |
| Skalowanie w poziomie | Podejście do skalowania, które dodaje wystąpienia danego typu zasobu. |
| Skalowanie automatyczne | Podejście do skalowania, które automatycznie dodaje lub usuwa zasoby po spełnieniu zestawu warunków. |
Uwaga
Operacje skalowania mogą być statyczne (regularne zaplanowane codzienne skalowanie w celu uwzględnienia normalnych wzorców obciążenia), automatyczne (zautomatyzowany proces w odpowiedzi na spełnione warunki) lub ręczne (operator wykonuje jednorazową operację skalowania w reakcji na nieoczekiwaną zmianę obciążenia). Skalowanie w pionie i w poziomie można wykonać za pomocą dowolnej z tych metod. Jednak automatyczne skalowanie w pionie wymaga dodatkowego niestandardowego programowania automatyzacji i może spowodować przestój w zależności od skalowanych zasobów.
Kluczowe strategie projektowania
Projektowanie zgodnie z wzorcami obciążenia
Aby zaprojektować niezawodną strategię skalowania dla obciążeń, skoncentruj się na identyfikowaniu wzorców obciążenia dla użytkowników i przepływów systemowych dla każdego obciążenia, które prowadzi do operacji skalowania. Oto przykłady różnych wzorców obciążenia:
Statyczne: Co noc do 11 PM EST liczba aktywnych użytkowników jest niższa niż 100, a użycie procesora CPU dla serwerów aplikacji spadnie o 90% we wszystkich węzłach.
Dynamiczne, regularne i przewidywalne: co poniedziałek rano 1000 pracowników w wielu regionach loguje się do systemu ERP.
Dynamiczne, nieregularne i przewidywalne: Uruchomienie produktu odbywa się w pierwszym dniu miesiąca i istnieją dane historyczne z poprzednich startów na temat wzrostu ruchu w tych sytuacjach.
Dynamiczne, nieregularne i nieprzewidywalne: Zdarzenie na dużą skalę powoduje wzrost zapotrzebowania na produkt. Na przykład firmy produkujące i sprzedające dehumidifiery mogą doświadczyć nagłego wzrostu ruchu po huraganie lub innym zdarzeniu powodziowym, gdy ludzie w dotkniętych obszarach muszą wyschnąć pomieszczenia w ich domu.
Po zidentyfikowaniu tych typów wzorców obciążenia można wykonać następujące czynności:
Zidentyfikuj, jak zmiana obciążenia skojarzona z każdym wzorcem wpływa na infrastrukturę.
Twórz automatyzację w celu niezawodnego skalowania.
W poprzednich przykładach strategie skalowania mogą być następujące:
Statyczne: masz zaplanowaną skalę węzłów obliczeniowych do minimalnej liczby (2) z zakresu od 11:00 do 6:00 EST.
Dynamiczne, regularne i przewidywalne: zaplanowano skalowanie w poziomie węzłów obliczeniowych do normalnej pojemności dziennej przed rozpoczęciem pracy w pierwszym regionie.
Dynamiczne, nieregularne i przewidywalne: definiowanie jednorazowej zaplanowanej skali w górę wystąpień obliczeniowych i baz danych w godzinach porannych uruchomienia produktu i skalowanie w dół po jednym tygodniu.
Dynamiczne, nieregularne i nieprzewidywalne: masz zdefiniowane progi autoskalowania, aby uwzględnić nieplanowane skoki ruchu.
Automatyzowanie strategii skalowania
Podczas projektowania automatyzacji skalowania należy uwzględnić następujące problemy:
Wszystkie składniki obciążenia powinny być kandydatami do implementacji skalowania. W większości przypadków globalne usługi, takie jak Microsoft Entra ID , są skalowane automatycznie i w sposób niewidoczny dla Ciebie i Twoich klientów. Pamiętaj, aby zrozumieć możliwości skalowania kontrolerów ruchu przychodzącego i wychodzącego sieci oraz rozwiązania do równoważenia obciążenia.
Te składniki, których nie można skalować w poziomie. Przykładem mogą być duże, relacyjne bazy danych, które nie mają włączonego fragmentowania i nie mogą być refaktoryzowane bez znaczącego wpływu. Udokumentowanie limitów zasobów opublikowanych przez dostawcę usług w chmurze i dokładne monitorowanie tych zasobów. Uwzględnij te konkretne zasoby w przyszłym planowaniu migracji do skalowalnych usług.
Czas potrzebny na wykonanie operacji skalowania, aby prawidłowo zaplanować operację, zanim dodatkowe obciążenie osiągnie infrastrukturę. Na przykład jeśli skalowanie składnika takiego jak usługa API Management trwa 45 minut, dostosowanie progu skalowania do 65% zamiast 90% może pomóc w skalowaniu wcześniej i przygotowaniu się do przewidywanego wzrostu obciążenia.
Relacja składników przepływu pod względem kolejności operacji skalowania. Upewnij się, że nie przypadkowo przeciążasz składnika podrzędnego, skalując najpierw składnik nadrzędny.
Wszystkie stanowe elementy aplikacji, które mogą zostać przerwane przez operację skalowania i wszelkie koligacje sesji (lub stickiness sesji) zaimplementowane. Stickiness może ograniczyć zdolność skalowania i wprowadza pojedyncze punkty awarii.
Potencjalne wąskie gardła. Skalowanie w górę nie rozwiązuje każdego problemu z wydajnością. Jeśli na przykład baza danych zaplecza jest wąskim gardłem, nie pomaga dodać więcej serwerów internetowych. Najpierw zidentyfikuj i rozwiąż wąskie gardła w systemie przed dodaniem kolejnych wystąpień. Stanowe części systemu są najbardziej prawdopodobną przyczyną wąskich gardeł.
Przestrzeganie wzorca projektowego sygnatury wdrożenia pomaga w ogólnym zarządzaniu infrastrukturą. Oparcie projektu skalowania na sygnaturach jako jednostki skali jest również korzystne. Pomaga również ściśle kontrolować operacje skalowania w wielu obciążeniach i podzestawach obciążeń. Zamiast zarządzać harmonogramami skalowania i progami skalowania automatycznego wielu różnych zasobów, można zastosować ograniczony zestaw definicji skalowania do sygnatury wdrożenia, a następnie zdublować je w miarę potrzeb.
Kompromis: skalowanie w górę ma wpływ na koszty, więc zoptymalizuj strategię skalowania w dół tak szybko, jak to możliwe, aby ułatwić kontrolowanie kosztów. Upewnij się, że automatyzacja, której używasz do skalowania w górę, ma również wyzwalacze skalowania w dół.
Ułatwienia platformy Azure
Funkcja skalowania automatycznego jest dostępna w wielu usługach platformy Azure. Umożliwia łatwe konfigurowanie warunków w celu automatycznego skalowania wystąpień w poziomie. Niektóre usługi mają ograniczoną lub nie wbudowaną funkcjonalność do automatycznego skalowania, dlatego pamiętaj, aby udokumentować te przypadki i zdefiniować procesy do obsługi skalowania.
Wiele usług platformy Azure oferuje interfejsy API, których można użyć do projektowania niestandardowych operacji automatycznego skalowania przy użyciu usługi Azure Automation, takich jak przykłady kodu w usłudze Autoskalowanie usługi Azure IoT Hub. Możesz użyć narzędzi takich jak KEDA na potrzeby automatycznego skalowania opartego na zdarzeniach, które jest dostępne w usługach Azure Kubernetes Service i Azure Container Apps.
Automatyczne skalowanie usługi Azure Monitor udostępnia wspólny zestaw funkcji skalowania automatycznego dla zestawów skalowania maszyn wirtualnych platformy Azure, aplikacja systemu Azure Service, Azure Spring Apps i nie tylko. Skalowanie można wykonać zgodnie z harmonogramem lub na podstawie metryki środowiska uruchomieniowego, takiej jak użycie procesora CPU lub pamięci. Aby uzyskać najlepsze rozwiązania, zobacz Przewodnik po usłudze Azure Monitor.
Kompromisy
Zagadnienia dotyczące skalowania automatycznego
Skalowanie automatyczne nie jest rozwiązaniem błyskawicznym. Proste dodawanie zasobów do systemu lub uruchamianie większej liczby wystąpień procesu nie gwarantuje poprawy wydajność systemu. Podczas projektowania strategii skalowania automatycznego należy wziąć pod uwagę następujące kwestie:
System musi być zaprojektowany do skalowania w poziomie. Unikaj wprowadzania założeń dotyczących koligacji wystąpienia. Nie projektuj rozwiązań, które wymagają, aby kod był zawsze uruchamiany w określonym wystąpieniu procesu. Podczas skalowania usługi w chmurze lub witryny internetowej w poziomie nie zakładaj, że seria żądań z tego samego źródła jest zawsze kierowana do tego samego wystąpienia. Z tego samego powodu należy projektować usługi bezstanowe, aby uniknąć wymagania kierowania serii żądań z aplikacji zawsze do tego samego wystąpienia usługi. Podczas projektowania usługi, która odczytuje komunikaty z kolejki i przetwarza je, nie należy przyjmować żadnych założeń dotyczących tego, które wystąpienie usługi obsługuje konkretny komunikat. Skalowanie automatyczne może uruchomić więcej wystąpień usługi w miarę wzrostu długości kolejki. Wzorzec konkurujących odbiorców opisuje sposób obsługi tego scenariusza.
Jeśli rozwiązanie implementuje długotrwałe zadanie, należy zaprojektować to zadanie do obsługi skalowania na zewnątrz i do wewnątrz. Bez należytej staranności takie zadanie może uniemożliwić wyłączenie wystąpienia procesu w sposób czysty podczas skalowania systemu. Może również utracić dane, jeśli proces zostanie wymuszony. Idealnym rozwiązaniem jest refaktoryzacja długotrwałego zadania i podzielenie wykonywanego przez nie przetwarzania na mniejsze, oddzielne fragmenty. Wzorzec potoków i filtrów zawiera przykład sposobu osiągnięcia tego rozwiązania.
Alternatywnie można zaimplementować mechanizm punktu kontrolnego, który rejestruje informacje o stanie zadania w regularnych odstępach czasu. Następnie można zapisać ten stan w magazynie trwałym, do którego można uzyskać dostęp w dowolnym wystąpieniu procesu uruchamiającego zadanie. W ten sposób, jeśli proces zostanie zamknięty, można wznowić pracę z ostatniego punktu kontrolnego przez inne wystąpienie. Istnieją biblioteki, które zapewniają tę funkcję, takie jak NServiceBus i MassTransit. Są one przezroczystie utrwalane w stanie, w którym interwały są dopasowywane do przetwarzania komunikatów z kolejek w usłudze Azure Service Bus.
Gdy zadania w tle są uruchamiane w oddzielnych wystąpieniach obliczeniowych, takich jak role procesów roboczych aplikacji hostowanej w chmurze, może być konieczne skalowanie różnych części aplikacji przy użyciu różnych zasad skalowania. Na przykład może być konieczne wdrożenie dodatkowych wystąpień obliczeniowych interfejsu użytkownika bez zwiększania liczby wystąpień obliczeniowych w tle lub odwrotnie. Jeśli oferujesz różne poziomy usług, takie jak pakiety usług podstawowych i Premium, może być konieczne skalowanie zasobów obliczeniowych dla pakietów usługi Premium bardziej agresywnie niż w przypadku podstawowych pakietów usług w celu spełnienia umów dotyczących poziomu usług (SLA).
Rozważ długość kolejki, w której komunikują się interfejs użytkownika i wystąpienia obliczeniowe w tle. Użyj go jako kryterium strategii skalowania automatycznego. Ten problem jest jednym z możliwych wskaźników nierównowagi lub różnicy między bieżącym obciążeniem a wydajnością przetwarzania zadania w tle. Nieco bardziej złożonym, ale lepszym atrybutem, na którym mają być oparte decyzje dotyczące skalowania, jest użycie czasu między wysłaniem komunikatu a ukończeniem jego przetwarzania. Ten interwał jest nazywany czasem krytycznym. Jeśli ta wartość czasu krytycznego jest poniżej znaczącego progu biznesowego, nie jest konieczne skalowanie, nawet jeśli długość kolejki jest długa.
Na przykład w kolejce może znajdować się 50 000 komunikatów. Jednak krytyczny czas najstarszej wiadomości wynosi 500 ms, a punkt końcowy zajmuje się integracją z usługą internetową innej firmy na potrzeby wysyłania wiadomości e-mail. Osoby biorące udział w projekcie biznesowym prawdopodobnie rozważyłyby okres, który nie uzasadniałby wydawania dodatkowych pieniędzy na skalowanie.
Z drugiej strony w kolejce może istnieć 500 komunikatów z tym samym czasem krytycznym 500 ms, ale punkt końcowy jest częścią krytycznej ścieżki w jakiejś grze online w czasie rzeczywistym, w której uczestnicy biznesowi zdefiniowali czas odpowiedzi 100 ms lub mniej. W takim przypadku skalowanie w górę miałoby sens.
Aby użyć czasu krytycznego w decyzjach dotyczących skalowania automatycznego, warto automatycznie dodać bibliotekę do nagłówków komunikatów podczas ich wysyłania i przetwarzania. Jedną z bibliotek, która udostępnia tę funkcję, jest NServiceBus.
Jeśli opierasz strategię skalowania automatycznego na licznikach, które mierzą procesy biznesowe, takie jak liczba zamówień złożonych na godzinę lub średni czas wykonywania złożonej transakcji, upewnij się, że w pełni rozumiesz relację między wynikami z tych typów liczników i rzeczywistymi wymaganiami dotyczącymi pojemności obliczeniowej. Może być konieczne skalowanie więcej niż jednego składnika lub jednostki obliczeniowej w odpowiedzi na zmiany liczników procesów biznesowych.
Aby zapobiec nadmiernemu skalowaniu systemu i uniknąć kosztów związanych z uruchamianiem wielu tysięcy wystąpień, rozważ ograniczenie maksymalnej liczby dodanych automatycznie wystąpień. Większość mechanizmów skalowania automatycznego umożliwia określenie minimalnej i maksymalnej liczby wystąpień dla reguły. Ponadto należy rozważyć bezproblemowe obniżenie funkcjonalności zapewnianej przez system, jeśli maksymalna liczba wystąpień została wdrożona, a system jest nadal przeciążony.
Należy pamiętać, że skalowanie automatyczne może nie być najbardziej odpowiednim mechanizmem obsługi nagłego wybuchu obciążenia. Aprowizowania i uruchamiania nowych wystąpień usługi lub dodawania zasobów do systemu zajmuje trochę czasu, a szczytowe zapotrzebowanie może potrwać, gdy te dodatkowe zasoby są dostępne. W tym scenariuszu może być lepiej ograniczyć usługę. Aby uzyskać więcej informacji, zobacz wzorzec ograniczania przepustowości.
Z drugiej strony, jeśli potrzebujesz pojemności do przetwarzania wszystkich żądań, gdy wolumin szybko się zmienia, a koszt nie jest głównym czynnikiem przyczyniającym się, rozważ użycie agresywnej strategii skalowania automatycznego, która szybciej uruchamia więcej wystąpień. Można także użyć zaplanowanych zasad, które uruchamiają liczbę wystąpień wystarczającą do zaspokojenia maksymalnego obciążenia, zanim będzie ono oczekiwane.
Mechanizm skalowania automatycznego powinien monitorować proces skalowania automatycznego i rejestrować szczegóły każdego zdarzenia skalowania automatycznego (co wyzwoliło je, jakie zasoby zostały dodane lub usunięte oraz kiedy). Jeśli tworzysz niestandardowy mechanizm skalowania automatycznego, upewnij się, że zawiera tę funkcję. Analiza informacji ułatwia pomiar skuteczności strategii skalowania automatycznego i dostrojenie jej, jeśli to konieczne. Możliwe jest dostosowywanie zarówno w krótkim okresie, w miarę jak wzorce użycia stają się bardziej oczywiste, jak i w długim okresie, w miarę rozwoju działalności lub ewolucji wymagań aplikacji. Jeśli aplikacja osiągnie górny limit zdefiniowany na potrzeby skalowania automatycznego, mechanizm może również powiadomić operatora, który może ręcznie uruchomić więcej zasobów w razie potrzeby. W takich okolicznościach operator może być również odpowiedzialny za ręczne usunięcie tych zasobów po złagodzeniu obciążenia.
Przykład
Zapoznaj się ze wskazówkami dotyczącymi skalowania architektury referencyjnej punktu odniesienia usługi AKS.
Pokrewne łącza
Lista kontrolna dotycząca niezawodności
Zapoznaj się z pełnym zestawem zaleceń.