Zalecenia dotyczące projektowania niezawodnej strategii skalowania

  • Artykuł

Dotyczy tego zalecenia dotyczącego listy kontrolnej niezawodności platformy Azure Well-Architected Framework:

RE:06 Zaimplementuj strategię terminowego i niezawodnego skalowania na poziomie aplikacji, danych i infrastruktury.

Przewodnik pokrewny:partycjonowanie danych

W tym przewodniku opisano zalecenia dotyczące projektowania niezawodnej strategii skalowania.

Definicje

Okres Definicja
Skalowanie w pionie Podejście 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 skalowania, które automatycznie dodaje lub usuwa zasoby po spełnieniu zestawu warunków.

Uwaga

Operacje skalowania mogą być statyczne (regularnie 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 programowania automatyzacji niestandardowej i może spowodować przestój w zależności od skalowanych zasobów.

Kluczowe strategie projektowania

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 o 11:00 EST liczba aktywnych użytkowników jest poniżej 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ę pierwszego dnia miesiąca i istnieją dane historyczne z poprzednich uruchomień 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ąć pokoje w ich domu.

Po zidentyfikowaniu tych typów wzorców obciążenia można wykonać następujące czynności:

  • Określ, w jaki sposób zmiana obciążenia skojarzona z każdym wzorcem wpływa na infrastrukturę.

  • Automatyzacja tworzenia w celu niezawodnego rozwiązywania problemów ze skalowaniem.

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 dziennej pojemności przed rozpoczęciem pracy w pierwszym regionie.

  • Dynamiczne, nieregularne i przewidywalne: definiowanie jednorazowego zaplanowanego skalowania w górę wystąpień obliczeniowych i baz danych w godzinach porannych uruchomienia produktu oraz skalowanie z powrotem w dół po jednym tygodniu.

  • Dynamiczne, nieregularne i nieprzewidywalne: masz zdefiniowane progi autoskalowania, aby uwzględnić nieplanowane skoki ruchu.

Podczas projektowania automatyzacji skalowania należy uwzględnić następujące problemy:

  • Wszystkie składniki obciążenia powinny być kandydatami do wdrożenia skalowania. W większości przypadków globalne usługi, takie jak Microsoft Entra identyfikatory, 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 można ich refaktoryzować 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łej planowaniu migracji do skalowalnych usług.

  • Czas potrzebny na wykonanie operacji skalowania, aby prawidłowo zaplanować operację, zanim dodatkowe obciążenie osiągnie infrastrukturę. Jeśli na przykład skalowanie składnika takiego jak 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.

  • Wszelkie elementy aplikacji stanowej, które mogą zostać przerwane przez operację skalowania i koligację sesji (lub trwałość sesji), która jest zaimplementowana. 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ą. Korzystne jest również oparcie projektu skalowania na sygnaturach, ponieważ jednostki skalowania są 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 odrębnych zasobów, można zastosować ograniczony zestaw definicji skalowania do sygnatury wdrożenia, a następnie zdublować je w razie potrzeby.

Kompromis: skalowanie w górę ma wpływ na koszty, więc zoptymalizuj strategię skalowania w dół tak szybko, jak to możliwe, aby pomóc utrzymać kontrolę nad kosztami. Upewnij się, że automatyzacja, której używasz do skalowania w górę, ma również wyzwalacze skalowania w dół.

Ułatwienia dla 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ą funkcję do automatycznego skalowania, dlatego pamiętaj, aby udokumentować te przypadki i zdefiniować procesy do obsługi skalowania w poziomie.

Wiele usług platformy Azure oferuje interfejsy API, których można użyć do projektowania niestandardowych operacji automatycznego skalowania przy użyciu Azure Automation, takich jak przykłady kodu w sekcji Autoskalowanie 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 w usłudze Azure Monitor udostępnia wspólny zestaw funkcji skalowania automatycznego dla usługi Azure Virtual Machine Scale Sets, Azure App 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 należy zakładać, ż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ć zamknięcie wystąpienia procesu w sposób czysty, gdy system się skaluje. 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, na którym uruchomiono zadanie. W ten sposób, jeśli proces zostanie zamknięty, wykonaną pracę można wznowić z ostatniego punktu kontrolnego przez inne wystąpienie. Istnieją biblioteki, które zapewniają tę funkcję, takie jak NServiceBus i MassTransit. Są one w przezroczysty sposób utrwalane w stanie, w którym interwały są dopasowywane do przetwarzania komunikatów z kolejek w 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 w warstwie Podstawowa i Premium, może być konieczne skalowanie zasobów obliczeniowych dla pakietów usług w warstwie Premium bardziej agresywnie niż w przypadku podstawowych pakietów usług w celu spełnienia umów dotyczących poziomu usług (SLA).

Należy wziąć pod uwagę 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 określany jako czas krytyczny. Jeśli ta krytyczna wartość czasu jest niższa od znaczącego progu biznesowego, nie trzeba jej skalować, 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 do wysyłania wiadomości e-mail. Zainteresowane strony biznesowe prawdopodobnie rozważyłyby okres, który nie uzasadniałby wydawania dodatkowych pieniędzy na skalowanie.

Z drugiej strony może istnieć 500 komunikatów w kolejce, 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ę ma sens.

Aby użyć czasu krytycznego w decyzjach dotyczących skalowania automatycznego, warto automatycznie dodać odpowiednie informacje do nagłówków komunikatów podczas ich wysyłania i przetwarzania. Jedną z bibliotek, która zapewnia 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 działania 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 wystąpień, które są automatycznie dodawane. 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 wzrostu obciążenia. Aprowizowania i uruchamiania nowych wystąpień usługi lub dodawania zasobów do systemu potrzeba czasu, a szczytowe zapotrzebowanie może upłynął do czasu udostępnienia tych dodatkowych zasobów. W tym scenariuszu lepszym rozwiązaniem może być ograniczenie usługi. Aby uzyskać więcej informacji, zobacz wzorzec ograniczania przepustowości.

Z drugiej strony, jeśli potrzebujesz pojemności do przetwarzania wszystkich żądań, gdy wolumin zmienia się szybko, a koszt nie jest głównym czynnikiem współtworzenia, rozważ użycie agresywnej strategii skalowania automatycznego, która uruchamia więcej wystąpień szybciej. 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 go wyzwoliło, 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 w usłudze AKS.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności