Udostępnij za pośrednictwem

Zalecenia dotyczące samonaprawiania i samonaprawiania

  • Artykuł

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

RE:07 Wzmocnienie odporności i możliwości odzyskiwania obciążenia przez zaimplementowanie środków samonaprawiania i samonaprawiania. Twórz możliwości w rozwiązaniu przy użyciu wzorców niezawodności opartych na infrastrukturze i wzorców projektowych opartych na oprogramowaniu w celu obsługi błędów składników i błędów przejściowych. Twórz możliwości w systemie w celu wykrywania błędów składników rozwiązania i automatycznego inicjowania akcji naprawczej, podczas gdy obciążenie nadal działa w pełni lub w ograniczonej funkcjonalności.

Powiązane przewodniki: Błędy przejściowe zadań | w tle

W tym przewodniku opisano zalecenia dotyczące tworzenia funkcji samonaprawiania i samodzielnego zachowywania w architekturze aplikacji w celu zoptymalizowania niezawodności.

Możliwości samodzielnego zachowywania zapewniają odporność na obciążenie. Zmniejszają prawdopodobieństwo pełnej awarii i umożliwiają działanie obciążenia w stanie obniżonej wydajności podczas odzyskiwania składników, które uległy awarii. Możliwości samonaprawiania pomagają uniknąć przestojów dzięki tworzeniu funkcji wykrywania błędów i automatycznych akcji naprawczych w celu reagowania na różne typy awarii.

W tym przewodniku opisano wzorce projektowe, które koncentrują się na samozachowaniu i samonaprawieniu. Uwzględnij je w obciążeniu, aby zwiększyć odporność i możliwość odzyskiwania. Jeśli nie implementujesz wzorców, aplikacje są narażone na awarię, gdy wystąpią nieuniknione problemy.

Definicje

Okres Definicja
Samonaprawianie Możliwość automatycznego rozwiązywania problemów przez odzyskanie składników, których dotyczy problem, i w razie potrzeby przełączenie w tryb failover do nadmiarowej infrastruktury.
Samozachowawczego Zdolność obciążenia do odporności na potencjalne problemy.

Kluczowe strategie projektowania

Projektowanie pod kątem samozachowawczego zachowania

Aby zaprojektować obciążenie na potrzeby samodzielnego zachowania, postępuj zgodnie z wzorcem projektowania infrastruktury i architektury aplikacji, aby zoptymalizować odporność obciążenia. Aby zminimalizować ryzyko wystąpienia pełnej awarii aplikacji, zwiększ odporność rozwiązania, eliminując pojedyncze punkty awarii i minimalizując promień awarii. Podejścia projektowe w tym artykule zawierają kilka opcji wzmocnienia odporności obciążenia i spełnienia zdefiniowanych celów dotyczących niezawodności obciążenia.

Wskazówki i wzorce dotyczące projektowania infrastruktury

Na poziomie infrastruktury projekt architektury nadmiarowej powinien obsługiwać krytyczne przepływy z zasobami wdrożonym w różnych strefach dostępności lub regionach. Zaimplementuj skalowanie automatyczne, jeśli to możliwe. Skalowanie automatyczne pomaga chronić obciążenie przed nieoczekiwanymi wzrostami aktywności, co dodatkowo wzmacnia infrastrukturę.

Użyj wzorca sygnatur wdrożenia lub wzorca bulkhead, aby zminimalizować promień wybuchu w przypadku wystąpienia problemów. Te wzorce pomagają zachować dostępność obciążenia, jeśli pojedynczy składnik jest niedostępny. Użyj następujących wzorców projektowych aplikacji w połączeniu ze strategią skalowania automatycznego.

  • Wzorzec sygnatur wdrażania: aprowizuj i monitoruj zróżnicowaną grupę zasobów do hostowania i obsługi wielu obciążeń lub dzierżaw oraz zarządzania nimi. Każda pojedyncza kopia jest nazywana sygnaturą, a czasami jednostką usługi, jednostką skalowania lub komórką.

  • Wzorzec grodziowy: partycjonowanie wystąpień usługi w różnych grupach, znanych jako pule, na podstawie wymagań dotyczących obciążenia i dostępności użytkowników. Ten projekt pomaga wyizolować awarie i umożliwia utrzymanie funkcjonalności usług dla niektórych użytkowników, nawet podczas awarii.

Wskazówki i wzorce dotyczące projektowania aplikacji

Unikaj kompilowania aplikacji monolitycznych w projekcie aplikacji. Używaj luźno powiązanych usług lub mikrousług, które komunikują się ze sobą za pośrednictwem dobrze zdefiniowanych standardów, aby zmniejszyć ryzyko rozległych problemów w przypadku awarii jednego składnika. Na przykład można standaryzacji użycia magistrali usług do obsługi całej komunikacji asynchronicznej. Standaryzacja protokołów komunikacyjnych zapewnia, że projektowanie aplikacji jest spójne i uproszczone, co sprawia, że obciążenie jest bardziej niezawodne i łatwiejsze do rozwiązywania problemów w przypadku wystąpienia awarii. W praktyce preferuj asynchroniczną komunikację między składnikami za pośrednictwem komunikacji synchronicznej, aby zminimalizować problemy z przekroczeniem limitu czasu, takie jak utracony komunikat. Poniższe wzorce projektowe ułatwiają organizowanie obciążenia i definiowanie komunikacji między składnikami w sposób, który najlepiej spełnia wymagania biznesowe.

  • Wzorzec ambasadora: oddziel logikę biznesową od kodu sieciowego i logiki odporności. Tworzenie usług pomocnika, które wysyłają żądania sieci w imieniu usługi lub aplikacji klienta. Ten wzorzec służy do implementowania mechanizmów ponawiania prób lub przerwania obwodu.

  • Wzorzec asynchronicznego żądania i odpowiedzi: rozdziel przetwarzanie zaplecza z hosta frontonu, jeśli przetwarzanie zaplecza musi być asynchroniczne, ale fronton potrzebuje jasnej odpowiedzi.

  • Wzorzec odkładania do pamięci podręcznej: ładowanie danych na żądanie z magazynu danych do pamięci podręcznej. Ten wzorzec może poprawić wydajność i zapewnić spójność danych przechowywanych w pamięci podręcznej i danych przechowywanych w bazowym magazynie danych.

  • Wzorzec wyłącznika: użyj wyłączników, aby aktywnie określić, czy zezwolić na kontynuowanie operacji, czy zwrócić wyjątek na podstawie liczby ostatnich awarii.

  • Wzorzec sprawdzania oświadczeń: podziel duży komunikat na sprawdzanie oświadczenia i ładunek. Wyślij kontrolę oświadczenia do platformy obsługi komunikatów i zapisz ładunek w usłudze zewnętrznej. Ten wzorzec umożliwia przetwarzanie dużych komunikatów przy jednoczesnym ochronie magistrali komunikatów i uniemożliwienie przeciążenia lub spowolnienia klienta.

  • Wzorzec konkurujących odbiorców: umożliwia wielu współbieżnych odbiorców przetwarzanie komunikatów odbieranych w tym samym kanale obsługi komunikatów. System może przetwarzać wiele komunikatów jednocześnie, co optymalizuje przepływność, zwiększa skalowalność i dostępność oraz równoważy obciążenie.

  • Konfigurowanie limitów czasu żądania: skonfiguruj limity czasu żądania dla wywołań usług lub baz danych. Limity czasu połączenia z bazą danych są zwykle ustawione na 30 sekund.

  • Wzorzec strażnika: ochrona aplikacji i usług przy użyciu dedykowanego wystąpienia hosta w celu brokera żądań między klientami a aplikacją lub usługą. Broker weryfikuje i czyści żądania i może zapewnić dodatkową warstwę zabezpieczeń, aby ograniczyć obszar ataków systemu.

  • Wzorzec bilansowania obciążenia opartego na kolejce: rozdziel zadania z usługi w rozwiązaniu przy użyciu kolejki między nimi, aby można było uruchamiać je asynchronicznie. Użyj kolejki jako buforu między zadaniem a usługą, którą wywołuje, aby ułatwić bezproblemowe sporadyczne duże obciążenia, które mogą spowodować awarię usługi lub przekroczenie limitu czasu zadania. Ten wzorzec może pomóc zminimalizować wpływ szczytów zapotrzebowania na dostępność i czas odpowiedzi dla zadania i usługi.

  • Wzorzec ograniczania przepustowości: kontrolowanie zużycia zasobów używanych przez wystąpienie aplikacji, pojedynczej dzierżawy lub całej usługi. Ten wzorzec umożliwia systemowi dalsze działanie i spełnianie umów dotyczących poziomu usług (SLA), nawet gdy wzrost zapotrzebowania powoduje ekstremalne obciążenie zasobów.

  • Wzorzec obsługi błędów przejściowych i wzorzec ponawiania prób: zaimplementuj strategię obsługi błędów przejściowych w celu zapewnienia odporności w obciążeniu. Błędy przejściowe są normalnymi i oczekiwanymi wystąpieniami w środowiskach chmury. Typowe przyczyny przejściowych błędów obejmują chwilową utratę łączności sieciowej, porzucone połączenie z bazą danych lub przekroczenie limitu czasu, gdy usługa jest zajęta. Aby uzyskać więcej informacji na temat opracowywania strategii ponawiania prób, zobacz przewodnik obsługi błędów przejściowych w tej serii.

Zadania w tle

Zadania w tle to skuteczny sposób zwiększania niezawodności systemu przez oddzielenie zadań od interfejsu użytkownika. Zaimplementuj zadanie jako zadanie w tle, jeśli nie wymaga danych wejściowych ani opinii użytkownika, a jeśli nie ma wpływu na czas odpowiedzi interfejsu użytkownika.

Typowe przykłady zadań w tle to:

  • Zadania intensywnie korzystające z procesora CPU, takie jak wykonywanie złożonych obliczeń lub analizowanie modeli strukturalnych.
  • Zadania intensywnie korzystające z operacji we/wy, takie jak uruchamianie wielu operacji magazynu lub indeksowanie dużych plików.
  • Zadania wsadowe, takie jak regularne aktualizowanie danych lub przetwarzanie zadań w określonym czasie.
  • Długotrwałe przepływy pracy, takie jak kończenie zamówienia lub aprowizowanie usług i systemów.

Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące zadań w tle.

Projektuj pod kątem samonaprawiania

Aby zaprojektować obciążenie na potrzeby samonaprawiania, zaimplementuj wykrywanie błędów, aby automatyczne odpowiedzi zostały wyzwolone i bezpiecznie odzyskane przepływy krytyczne. Włącz rejestrowanie, aby zapewnić szczegółowe informacje operacyjne dotyczące charakteru niepowodzenia i powodzenia odzyskiwania. Podejścia, które należy wykonać w celu samonaprawiania dla przepływu krytycznego, zależą od celów niezawodności zdefiniowanych dla tego przepływu oraz składników i zależności przepływu.

Wskazówki dotyczące projektowania infrastruktury

Na poziomie infrastruktury krytyczne przepływy powinny być obsługiwane przez nadmiarowy projekt architektury z włączonym automatycznym trybem failover dla składników, które go obsługują. Automatyczne przechodzenie w tryb failover można włączyć dla następujących typów usług:

  • Zasoby obliczeniowe: zestawy skalowania maszyn wirtualnych platformy Azure i większość usług obliczeniowych jako usługi (PaaS) można skonfigurować do automatycznego przejścia w tryb failover.

  • Bazy danych: Relacyjne bazy danych można skonfigurować do automatycznego przejścia w tryb failover przy użyciu rozwiązań, takich jak klastry trybu failover usługi Azure SQL, zawsze włączone grupy dostępności lub wbudowane funkcje z usługami PaaS. Bazy danych NoSQL mają podobne możliwości klastrowania i wbudowane funkcje dla usług PaaS.

  • Magazyn: użyj opcji magazynu nadmiarowego z automatycznym trybem failover.

Wskazówki i wzorce dotyczące projektowania aplikacji

  • Blokowanie nieprawidłowych aktorów: jeśli ograniczasz klienta, nie oznacza to, że klient działał złośliwie. Może to oznaczać, że klient przekroczył limit przydziału usługi. Jeśli jednak klient stale przekracza limit przydziału lub w inny sposób zachowuje się źle, możesz je zablokować. Zdefiniuj proces poza pasmem, aby klient zażądał odblokowania.

  • Wzorzec wyłącznika: jeśli awaria będzie się powtarzać po zainicjowaniu mechanizmu ponawiania prób, ryzyko wystąpienia kaskadowych awarii wynikających z rosnącej listy prac wywołań. Wyłącznik zaprojektowany do pracy z mechanizmem ponawiania prób ogranicza ryzyko awarii kaskadowych, uniemożliwiając aplikacji wielokrotne próby uruchomienia operacji, która może zakończyć się niepowodzeniem.

  • Wzorzec transakcji wyrównywczej: jeśli używasz ostatecznie spójnej operacji składającej się z serii kroków, zaimplementuj wzorzec transakcji wyrównywujących. Jeśli co najmniej jeden krok nie powiedzie się, możesz użyć tego wzorca, aby cofnąć wykonaną pracę.

  • Sprawność w sposób bezproblemowy: czasami nie można obejść problemu, ale można zapewnić ograniczoną funkcjonalność. Rozważmy aplikację, która wyświetla katalog książek. Jeśli aplikacja nie może pobrać miniatury okładki, może wyświetlać obraz zastępczy. Niekiedy całe podsystemy nie są niezbędne do działania aplikacji. Na przykład w witrynie internetowej handlu elektronicznego wyświetlanie zaleceń dotyczących produktów jest prawdopodobnie mniej krytyczne niż przetwarzanie zamówień. Łagodne obniżenie wydajności może również obejmować automatyczne operacje trybu failover. Gdy baza danych automatycznie przechodzi w tryb failover do repliki z powodu problemu z wystąpieniem podstawowym, wydajność jest obniżona przez krótki czas.

  • Wzorzec wyborów lidera: Jeśli musisz koordynować zadanie, użyj wyborów liderów, aby wybrać koordynatora, aby jeden koordynator nie był pojedynczym punktem awarii. Jeśli koordynator ulegnie awarii, zostanie wybrany nowy. Zamiast implementować algorytm wyboru lidera od podstaw, rozważ rozwiązanie gotowe, takie jak ZooKeeper.

  • Wzorce testów: obejmują testowanie wzorców, które są implementowane w ramach standardowych procedur testowania.

  • Użyj punktów kontrolnych dla długotrwałych transakcji: punkty kontrolne mogą zapewnić odporność, jeśli długotrwała operacja zakończy się niepowodzeniem. Gdy operacja zostanie uruchomiona ponownie, na przykład jeśli zostanie odebrana przez inną maszynę wirtualną, może ona wznowić działanie z ostatniego punktu kontrolnego. Rozważ zaimplementowanie mechanizmu, który rejestruje informacje o stanie zadania w regularnych odstępach czasu. Zapisz ten stan w trwałym magazynie, do którego można uzyskać dostęp w dowolnym wystąpieniu procesu uruchamiającego zadanie. Jeśli proces zostanie zamknięty, można wznowić pracę wykonaną 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.

Zautomatyzowane akcje samonaprawiania

Innym podejściem do samonaprawiania jest użycie automatycznych akcji, które są wyzwalane przez rozwiązanie do monitorowania po wykryciu wstępnie określonych zmian stanu kondycji. Jeśli na przykład monitorowanie wykryje, że aplikacja internetowa nie odpowiada na żądania, możesz utworzyć automatyzację za pomocą skryptu programu PowerShell w celu ponownego uruchomienia usługi app Service. W zależności od zestawu umiejętności zespołu i preferowanych technologii programowania użyj elementu webhook lub funkcji, aby utworzyć bardziej złożone akcje automatyzacji. Zobacz architekturę referencyjną automatyzacji chmury opartej na zdarzeniach, aby zapoznać się z przykładem użycia funkcji do reagowania na ograniczanie przepustowości bazy danych. Korzystanie z akcji automatycznych może pomóc w szybkim odzyskaniu i zminimalizować konieczność interwencji człowieka.

Ułatwienia platformy Azure

Większość usług platformy Azure i zestawów SDK klienta zawiera mechanizm ponawiania prób. Różnią się one jednak, ponieważ każda usługa ma różne cechy i wymagania, więc każdy mechanizm ponawiania prób jest dostrojony do określonej usługi. Aby uzyskać więcej informacji, zobacz Zalecenia dotyczące obsługi błędów przejściowych.

Użyj grup akcji usługi Azure Monitor, aby otrzymywać powiadomienia, takie jak poczta e-mail, głos lub sms, oraz wyzwalać zautomatyzowane akcje. Gdy otrzymasz powiadomienie o niepowodzeniu, wyzwól element Runbook usługi Azure Automation, usługę Azure Event Hubs, funkcję platformy Azure, aplikację logiki lub element webhook w celu wykonania akcji automatycznego naprawiania.

Kwestie wymagające rozważenia

Zapoznaj się z zagadnieniami dotyczącymi każdego wzorca. Przed wdrożeniem upewnij się, że wzorzec jest odpowiedni dla wymagań biznesowych i obciążeń.

Przykład

Przykładowe przypadki użycia niektórych wzorców można znaleźć w temacie Niezawodny wzorzec aplikacji internetowej dla platformy .NET. Wykonaj następujące kroki, aby wdrożyć implementację referencyjną.

Lista kontrolna dotycząca niezawodności

Zapoznaj się z pełnym zestawem zaleceń.

Lista kontrolna dotycząca niezawodności