Skalowanie automatyczne

  • Artykuł

Skalowanie automatyczne polega na dynamicznym przydzielaniu zasobów w celu dopasowania do wymagań dotyczących wydajności. Gdy rośnie ilość pracy, aplikacja może potrzebować dodatkowych zasobów, aby utrzymać wymagane poziomy wydajności i spełniać warunki umów dotyczących poziomu usług (SLA). Kiedy zapotrzebowanie spada, dodatkowe zasoby nie są już potrzebne i można cofnąć ich przydział, aby zminimalizować koszty.

Skalowanie automatyczne wykorzystuje elastyczność środowisk hostowanych w chmurze, zmniejszając nakłady pracy związane z zarządzaniem. Zmniejsza potrzebę ciągłego monitorowania wydajności systemu przez operatora i podejmowania decyzji o dodaniu lub usunięciu zasobów.

Istnieją dwa sposoby skalowania aplikacji:

  • Skalowanie w pionie, nazywane również skalowaniem w górę i w dół, oznacza zmianę pojemności zasobu. Na przykład można przenieść aplikację na maszynę wirtualną o większym rozmiarze. Skalowanie w pionie wymaga często tymczasowej niedostępności systemu podczas jego ponownego wdrażania. W związku z tym automatyzowanie skalowania w pionie jest rzadziej używane.

  • Skalowanie w poziomie, nazywane również skalowaniem na zewnątrz i do wewnątrz, oznacza dodawanie lub usuwanie wystąpień zasobu. Podczas aprowizowania nowych zasobów aplikacja będzie nadal działać bez przeszkód. Po zakończeniu procesu aprowizacji rozwiązanie będzie wdrożone w tych dodatkowych zasobach. Jeśli zapotrzebowanie spadnie, dodatkowe zasoby można bezproblemowo wyłączyć i cofnąć ich przydział.

Wiele systemów opartych na chmurze, w tym Microsoft Azure, obsługuje automatyczne skalowanie w poziomie. Pozostała część tego artykułu koncentruje się na skalowaniu w poziomie.

Uwaga

Skalowanie automatyczne dotyczy przede wszystkim zasobów obliczeniowych. Mimo że istnieje możliwość skalowania w poziomie bazy danych lub kolejki komunikatów, wiąże się to zwykle partycjonowaniem danych, które zazwyczaj nie jest zautomatyzowane.

Składniki skalowania automatycznego

Strategia skalowania automatycznego zwykle obejmuje następujące elementy:

  • Instrumentacja i monitorowanie systemów na poziomie aplikacji, usługi i infrastruktury. Te systemy przechwytują kluczowe metryki, takie jak czasy reakcji, długości kolejek, użycie procesora CPU i użycie pamięci.
  • Logika podejmowania decyzji, która ocenia te metryki względem wstępnie zdefiniowanych progów lub harmonogramów i decyduje o tym, czy wykonać skalowanie.
  • Składniki, które skalują system.
  • Testowanie, monitorowanie i dostrajanie strategii skalowania automatycznego, aby upewnić się, że działa zgodnie z oczekiwaniami.

Platforma Azure oferuje wbudowane mechanizmy skalowania automatycznego, które dotyczą typowych scenariuszy. Jeśli określona usługa albo technologia nie ma wbudowanej funkcji skalowania automatycznego lub jeśli wymagania dotyczące skalowania automatycznego wykraczają poza możliwości wbudowane, warto rozważyć implementację niestandardową. Implementacja niestandardowa będzie zbierać metryki operacyjne i systemowe, analizować je, a następnie odpowiednio skalować zasoby.

Konfigurowanie skalowania automatycznego dla rozwiązania platformy Azure

Platforma Azure oferuje wbudowane skalowanie automatyczne dla większości opcji obliczeniowych.

Wszystkie te opcje obliczeniowe używają skalowania automatycznego usługi Azure Monitor, aby zapewnić wspólny zestaw funkcji skalowania automatycznego.

  • Usługa Azure Functions różni się od poprzednich opcji obliczeniowych, ponieważ nie wymaga konfigurowania żadnych reguł skalowania automatycznego. Zamiast tego usługa Azure Functions automatycznie przydziela moc obliczeniową podczas uruchomienia kodu, wykonując skalowanie na zewnątrz niezbędne do obsługi obciążenia. Aby uzyskać więcej informacji, zobacz Wybieranie odpowiedniego planu hostingu dla usługi Azure Functions.

Na koniec czasami przydatne mogą być niestandardowe rozwiązania skalowania automatycznego. Można na przykład użyć metryk Diagnostyka Azure i opartych na aplikacjach oraz kodu niestandardowego do monitorowania i eksportowania metryk aplikacji. Następnie można zdefiniować reguły niestandardowe na podstawie tych samych metryk i interfejsów API REST usługi Resource Manager w celu wyzwalania skalowania automatycznego. Jednak implementacja niestandardowego rozwiązania nie jest łatwa i należy je brać pod uwagę tylko w przypadku, gdy żadne z poprzednich podejść nie może spełnić określonych wymagań.

Skorzystaj z wbudowanych funkcji skalowania automatycznego platformy, jeśli spełniają one wymagania. Jeśli nie, dokładnie rozważ, czy naprawdę potrzebujesz bardziej złożonych funkcji skalowania. Przykłady dodatkowych wymagań mogą obejmować większą szczegółowość kontroli, różne sposoby wykrywania zdarzeń wyzwalacza na potrzeby skalowania, skalowania w subskrypcjach i skalowania innych typów zasobów.

Korzystanie ze skalowania automatycznego usługi Azure Monitor

Automatyczne skalowanie usługi Azure Monitor udostępnia wspólny zestaw funkcji skalowania automatycznego dla zestawów skalowania maszyn wirtualnych, aplikacja systemu Azure Service i Azure Cloud Service. Skalowanie może być wykonywane zgodnie z harmonogramem lub w oparciu o metryki środowiska uruchomieniowego, takie jak użycie procesora CPU lub pamięci.

Przykłady:

  • Skalowanie na zewnątrz do 10 wystąpień w dni robocze i skalowanie do wewnątrz do 4 wystąpień w soboty i niedziele.
  • Skalowanie na zewnątrz o jedno wystąpienie, jeśli średnie użycie procesora CPU przekracza 70%, i skalowanie do wewnątrz o jedno wystąpienie, jeśli użycie procesora CPU spadnie poniżej 50%.
  • Skalowanie na zewnątrz o jedno wystąpienie, jeśli liczba komunikatów w kolejce przekroczy określony próg.

Skaluj zasób w górę, gdy obciążenie zwiększa się, aby zapewnić dostępność. Podobnie, w czasach niskiego użycia, skaluj w dół, aby można było zoptymalizować koszty. Zawsze używaj kombinacji reguł skalowania w poziomie i skalowania w poziomie. W przeciwnym razie skalowanie automatyczne odbywa się tylko w jednym kierunku, dopóki nie osiągnie progu (maksymalna lub minimalna liczba wystąpień) ustawionego w profilu.

Wybierz domyślną liczbę wystąpień, która jest bezpieczna dla obciążenia. Jest skalowana na podstawie tej wartości, jeśli nie ustawiono maksymalnej lub minimalnej liczby wystąpień.

Aby uzyskać listę wbudowanych metryk, zobacz artykuł Azure Monitor autoscaling common metrics (Typowe metryki skalowania automatycznego w usłudze Azure Monitor). Można także wdrożyć metryki niestandardowe przy użyciu usługi Application Insights.

Skalowanie automatyczne można skonfigurować przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure, szablonu usługi Azure Resource Manager lub witryny Azure Portal. Aby uzyskać bardziej szczegółową kontrolę, należy skorzystać z interfejsu API REST usługi Azure Resource Manager. Biblioteka zarządzania usługą monitorowania platformy Azure i biblioteka usługi Microsoft Insights (w wersji zapoznawczej) to zestawy SDK, które umożliwiają zbieranie metryk z różnych zasobów i skalowanie automatyczne dzięki wykorzystaniu interfejsów API REST. W przypadku zasobów, w których obsługa usługi Azure Resource Manager jest niedostępna, lub w przypadku korzystania z usług Azure Cloud Services, na potrzeby skalowania automatycznego można używać interfejsu API REST zarządzania usługami. We wszystkich innych przypadkach należy używać usługi Azure Resource Manager.

Podczas korzystania z usługi skalowania automatycznego platformy Azure należy wziąć pod uwagę następujące kwestie:

  • Zastanów się, czy można przewidzieć obciążenie aplikacji wystarczająco dokładnie, aby używać zaplanowanego skalowania automatycznego, dodawania i usuwania wystąpień w celu spełnienia przewidywanych szczytów zapotrzebowania. Jeśli nie jest to możliwe, należy użyć reaktywnego skalowania automatycznego na podstawie metryk środowiska uruchomieniowego w celu obsługi nieprzewidywalnych zmian zapotrzebowania. Zazwyczaj można połączyć te podejścia. Na przykład utwórz strategię, która dodaje zasoby na podstawie harmonogramu czasu, w którym wiadomo, że aplikacja jest najbardziej ruchliwa. Pomaga to zapewnić dostępność pojemności wtedy, gdy jest ona wymagana, bez żadnego opóźnienia od uruchomienia nowych wystąpień. Dla każdej zaplanowanej reguły należy określić metryki, które umożliwiają reaktywne skalowanie automatyczne w tym okresie, aby upewnić się, że aplikacja może obsługiwać stałe, ale nieprzewidywalne skoki zapotrzebowania.

  • Często trudno jest zrozumieć relację między metrykami i wymaganiami dotyczącymi pojemności, zwłaszcza w przypadku wstępnego wdrożenia aplikacji. Należy zapewnić nieco dodatkowej pojemności na początku, a następnie monitorować i dostrajać reguły skalowania automatycznego, aby sprowadzić pojemność bliżej rzeczywistego obciążenia.

  • Skonfiguruj reguły skalowania automatycznego, a następnie monitoruj wydajność aplikacji w czasie. Użyj wyników monitorowania, aby dostosować sposób, w jaki system jest skalowany w razie potrzeby. Należy jednak pamiętać, że skalowanie automatyczne nie jest procesem natychmiastowym. Zareagowanie na przekroczenie lub spadek poniżej określonego progu przez metrykę, taką jak średnie użycie procesora CPU, jest czasochłonne.

  • Reguły skalowania automatycznego, które korzystają z mechanizmu wykrywania na podstawie zmierzonego atrybutu wyzwalacza (takiego jak użycie procesora CPU lub długość kolejki) używają zagregowanej wartości w czasie, a nie wartości chwilowych do wyzwalania akcji skalowania automatycznego. Domyślnie wartość zagregowana jest średnią z wartości. Zapobiega to zbyt szybkiej reakcji systemu lub szybkim oscylacjom. Umożliwia to również czas na automatyczne uruchamianie nowych wystąpień, co uniemożliwia wykonywanie dodatkowych akcji skalowania automatycznego podczas uruchamiania nowych wystąpień. W przypadku usług Azure Cloud Services i Azure Virtual Machines domyślny okres agregacji wynosi 45 minut, dlatego tyle maksymalnie może potrwać, zanim metryka wyzwoli skalowanie automatyczne w odpowiedzi na skoki zapotrzebowania. Okres agregacji można zmienić przy użyciu zestawu SDK, ale okresy mniejsze niż 25 minut mogą powodować nieprzewidywalne wyniki. W przypadku aplikacji Web Apps okres obliczania średniej jest znacznie krótszy, dzięki czemu nowe wystąpienia mogą być dostępne w ciągu około 5 minut po zmianie średniej metryki wyzwalacza.

  • Unikaj flappingu , w którym akcje skalowania i skalowania w poziomie stale przechodzą tam i z powrotem. Załóżmy, że istnieją dwa wystąpienia, a górny limit wynosi 80%, niższy limit wynosi 60%. Gdy obciążenie wynosi 85%, dodawane jest inne wystąpienie. Po pewnym czasie obciążenie zmniejsza się do 60%. Przed rozpoczęciem skalowania usługa autoskalowania oblicza rozkład całkowitego obciążenia (z trzech wystąpień) po usunięciu wystąpienia, co spowoduje jego usunięcie do 90%. Oznacza to, że konieczne byłoby natychmiastowe skalowanie w poziomie. Dlatego pomija skalowanie i może nigdy nie zobaczyć oczekiwanych wyników skalowania.

    Sytuacja flapping może być kontrolowana przez wybranie odpowiedniego marginesu między progami skalowania w poziomie i skalowania w poziomie.

  • Skalowanie ręczne jest resetowane przez maksymalną i minimalną liczbę wystąpień używanych do skalowania automatycznego. Jeśli ręcznie zaktualizujesz liczbę wystąpień do wartości wyższej lub niższej niż wartość maksymalna, aparat autoskalowania automatycznie skaluje z powrotem do minimum (jeśli jest niższa) lub maksymalną (jeśli jest wyższa). Można na przykład ustawić zakres z zakresu od 3 do 6. Jeśli masz jedno uruchomione wystąpienie, aparat skalowania automatycznego jest skalowany do trzech wystąpień w następnym uruchomieniu. Podobnie, jeśli ręcznie ustawisz skalę na osiem wystąpień, w następnym uruchomieniu autoskalowanie zostanie przeskalowanie z powrotem do sześciu wystąpień w następnym uruchomieniu. Ręczne skalowanie jest tymczasowe, chyba że zresetowane są również reguły autoskalowania.

  • Aparat skalowania automatycznego przetwarza tylko jeden profil naraz. Jeśli warunek nie jest spełniony, sprawdza on następny profil. Zachowaj kluczowe metryki z profilu domyślnego, ponieważ ten profil jest ostatnio sprawdzany. W profilu można mieć wiele reguł. W przypadku skalowania w poziomie automatyczne skalowanie jest uruchamiane, jeśli zostanie spełniona jakakolwiek reguła. Skalowanie automatyczne wymaga spełnienia wszystkich reguł w skali w poziomie.

Aby uzyskać szczegółowe informacje na temat skalowania usługi Azure Monitor, zobacz Best practices for Autoscale (Najlepsze rozwiązania dotyczące skalowania automatycznego).

  • Jeśli skonfigurujesz skalowanie automatyczne przy użyciu zestawu SDK zamiast portalu, możesz określić bardziej szczegółowy harmonogram, w którym są aktywne reguły. Można również utworzyć własne metryki i używać ich z dowolnymi istniejącymi metrykami lub samodzielnie w regułach skalowania automatycznego. Możesz na przykład użyć alternatywnych liczników, takich jak liczba żądań na sekundę lub średnia dostępność pamięci, lub użyć liczników niestandardowych do mierzenia określonych procesów biznesowych.

  • Podczas skalowania automatycznego usługi Service Fabric typy węzłów w klastrze są tworzone z zestawów skalowania maszyn wirtualnych na zapleczu, dlatego należy skonfigurować reguły automatycznego skalowania dla każdego typu węzła. Przed skonfigurowaniem skalowania automatycznego należy wziąć pod uwagę liczbę węzłów, które należy mieć. Minimalna liczba węzłów wymagana dla typu węzła podstawowego zależy od wybranego poziomu niezawodności. Aby uzyskać więcej informacji, zobacz Skalowanie klastra usługi Service Fabric w poziomie lub w poziomie przy użyciu reguł skalowania automatycznego.

  • Za pomocą portalu można połączyć zasoby, takie jak wystąpienia bazy danych SQL i kolejki, z wystąpieniem usługi w chmurze. Dzięki temu można łatwiej uzyskać dostęp do oddzielnych opcji konfiguracji ręcznego i automatycznego skalowania dla każdego z połączonych zasobów. Aby uzyskać więcej informacji, zobacz Instrukcje: Łączenie zasobu z usługą w chmurze.

  • Skonfigurowanie wielu zasad i reguł może spowodować konflikty między nimi. Skalowanie automatyczne używa następujących reguł rozwiązywania konfliktów, aby upewnić się, że zawsze uruchomiona jest wystarczająca liczba wystąpień:

    • Operacje skalowania w poziomie zawsze mają pierwszeństwo przed operacjami skalowania w poziomie.
    • W przypadku konfliktu operacji skalowania w poziomie pierwszeństwo ma reguła, która inicjuje największy wzrost liczby wystąpień.
    • W przypadku konfliktu operacji skalowania do wewnątrz pierwszeństwo ma reguła, która inicjuje najmniejszy spadek liczby wystąpień.

  • W środowisku App Service Environment do definiowania reguł skalowania automatycznego można użyć dowolnej puli procesów roboczych lub metryk frontonu. Aby uzyskać więcej informacji, zobacz Skalowanie automatyczne i środowisko usługi App Service.

Zagadnienia dotyczące projektowania aplikacji

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. Należy unikać wprowadzania założeń dotyczących koligacji wystąpień; nie należy projektować rozwiązań, które wymagają, żeby kod zawsze był uruchamiany w konkretnym wystąpieniu procesu. Podczas skalowania w poziomie usługi w chmurze lub witryny internetowej nie wolno zakładać, że seria żądań z tego samego źródła zawsze będzie 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 uruchamiać dodatkowe wystąpienia usługi, kiedy długość kolejki rośnie. 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 obsługi terminu takie zadanie może uniemożliwić prawidłowe zamknięcie wystąpienia procesu podczas skalowania systemu do wewnątrz lub spowodować utratę danych, jeśli zakończenie procesu zostanie wymuszone. 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 celu.

  • Alternatywnie można zaimplementować mechanizm punktu kontrolnego, który rejestruje informacje o stanie zadania w regularnych odstępach czasu i zapisuje ten stan w magazynie trwałym, do którego można uzyskać dostęp przez dowolne wystąpienie procesu uruchamiającego zadanie. W ten sposób, jeśli proces zostanie zamknięty, praca, którą wykonano, można wznowić z ostatniego punktu kontrolnego przy użyciu innego wystąpienia. 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.

  • W przypadku uruchamiania zadań w tle w osobnych 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 przeciwieństwo tego. Jeśli oferujesz różne poziomy usługi (takie jak pakiety usługi Podstawowa i Premium), konieczne może być skalowanie w poziomie zasobów obliczeniowych dla pakietów usługi Premium bardziej agresywnie niż zasobów dla pakietów usługi Podstawowa w celu spełnienia warunków umów 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. Jest to jeden z możliwych wskaźników nierównowagi lub różnicy między bieżącym obciążeniem a wydajnością przetwarzania zadania w tle. Istnieje nieco bardziej złożony, ale lepszy atrybut do podejmowania decyzji dotyczących skalowania podstawowego. Użyj czasu między wysłaniem komunikatu a ukończeniem jego przetwarzania, znanym jako czas krytyczny. 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, ale krytyczny czas najstarszego komunikatu to 500 ms, a ten punkt końcowy zajmuje się integracją z usługą internetową innej firmy na potrzeby wysyłania wiadomości e-mail. Jest prawdopodobne, że zainteresowane strony biznesowe rozważyłyby, że będzie to 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, gdzie uczestnicy projektu biznesowego zdefiniowali 100 ms lub mniej czasu odpowiedzi. W takim przypadku skalowanie w górę miałoby sens.
    • Aby korzystać z czasu krytycznego w decyzjach dotyczących automatycznego skalowania, warto automatycznie dodać odpowiednie informacje do nagłówków komunikatów, gdy są one wysyłane i przetwarzane. Jedną z takich bibliotek, która udostępnia tę funkcję, jest NServiceBus.

  • Jeśli swoją strategię skalowania automatycznego oprzesz na licznikach, które mierzą procesy biznesowe, takich jak liczba zamówień na godzinę lub średni czas wykonania transakcji złożonej, upewnij się, że w pełni rozumiesz relację między wynikami z tego typu liczników a rzeczywistymi wymaganiami dotyczącymi możliwości obliczeniowych. Konieczne może być skalowanie więcej niż jednego składnika lub jednostki obliczeniowej w odpowiedzi na zmiany liczników procesów biznesowych.

  • Aby zapobiec przesadnym próbom skalowania w poziomie i uniknąć kosztów związanych z uruchamianiem wielu tysięcy wystąpień, rozważ ograniczenie maksymalnej liczby wystąpień, które mogą być 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ć bezpiecznie obniżenie funkcjonalności zapewnianej przez system, jeśli po wdrożeniu maksymalnej liczby wystąpień system nadal jest przeciążony.

  • Należy pamiętać, że skalowanie automatyczne może nie być najbardziej odpowiednim mechanizmem do obsługi nagłych wzrostów obciążenia. Aprowizacja i uruchomienie nowych wystąpień usługi lub dodanie zasobów do systemu to procesy, które nieco trwają, i szczytowe zapotrzebowanie może już minąć, zanim te dodatkowe zasoby staną się dostępne. 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 wydajności, aby przetwarzać wszystkie żądania, gdy wolumin zmienia się szybko, a koszt nie jest najważniejszy, rozważ użycie strategii agresywnego skalowania automatycznego, które szybciej uruchamia dodatkowe wystąpienia. 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 je wyzwoliło, jakie zasoby zostały dodane lub usunięte i 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 dla skalowania automatycznego, mechanizm może również powiadamiać operatora, który może ręcznie uruchomić dodatkowe zasoby, jeśli to konieczne. Należy pamiętać, że w tych okolicznościach operator może być również odpowiedzialny za ręczne usunięcie tych zasobów po złagodzeniu obciążenia.

Następujące wzorce i wskazówki mogą być również istotne dla danego scenariusza podczas implementowania skalowania automatycznego:

  • Wzorzec ograniczania przepływności. Ten wzorzec opisuje, w jaki sposób aplikacja może nadal działać i spełniać warunki umów SLA, kiedy wzrost zapotrzebowania powoduje ekstremalne obciążenie zasobów. Ograniczanie może być używane ze skalowaniem automatycznym w celu zapobieżenia przeciążeniu systemu podczas skalowania systemu w poziomie.

  • Wzorzec konkurujących odbiorców. Ten wzorzec opisuje sposób implementacji puli wystąpień usługi, które mogą obsługiwać komunikaty z dowolnego wystąpienia aplikacji. Skalowanie automatyczne może służyć do uruchamiania i zatrzymywania wystąpień usługi w celu dopasowania do przewidywanego obciążenia. To podejście umożliwia systemowi przetwarzanie wielu komunikatów jednocześnie w celu zoptymalizowania przepływności, poprawy skalowalności i dostępności oraz równoważenia obciążenia.

  • Monitorowanie i diagnostyka. Instrumentacja i telemetria są istotne dla zbierania informacji, które mogą sterować skalowaniem automatycznym.