Projektowanie eksperymentów chaosu
Aplikacja o krytycznym znaczeniu musi być odporna i gotowa do reagowania na błędy. Trudno jednak przewidzieć potencjalne scenariusze awarii w chmurze. Inżynieria chaosu umożliwia przeprowadzanie eksperymentów awarii w kontrolowanym środowisku w celu identyfikowania problemów, które mogą wystąpić podczas opracowywania i wdrażania. Celowo wprowadzasz błędy w świecie rzeczywistym i obserwujesz, jak system reaguje.
W tej lekcji użyjemy usługi Azure Chaos Studio. Usługa pomoże Ci zmierzyć, zrozumieć i poprawić odporność aplikacji i usług w chmurze. Będziesz przygotowany do szybkiego reagowania, jeśli ten błąd wystąpi w niekorzystnych warunkach w środowisku produkcyjnym.
Przeprowadzanie analizy trybu awarii
Podczas projektowania eksperymentu chaosu pierwszym krokiem jest przeprowadzenie analizy trybu awarii (FMA) składników aplikacji w celu zidentyfikowania potencjalnych scenariuszy awarii.
Wyświetl listę wszystkich składników, które są istotne dla przepływu użytkownika, które muszą być dostępne i funkcjonalne. Na przykład przepływ wyewidencjonowania użytkownika używa aplikacja systemu Azure Usług, Funkcji i bazy danych Cosmos DB.
Dla każdego składnika należy wyświetlić listę możliwych przypadków awarii, ich wpływ i potencjalne środki zaradcze.
Zobaczmy wynik fmA wykonany dla składników przykładu przepływu użytkownika wyewidencjonowania firmy Contoso Shoes.
usługa aplikacja systemu Azure do hostowania aplikacji frontonu
| Ryzyko | Wpływ | Możliwe środki zaradcze |
|---|---|---|
| Awaria strefy dostępności | Wystąpienia w tej strefie mogą stać się niedostępne. Pełna awaria nie jest oczekiwana, ponieważ nadmiarowość strefy jest włączona w planie usługi App Service. |
Zezwól na dodatkowe obciążenie pozostałych wystąpień i zapewnij wystarczającą ilość miejsca dla tego scenariusza, jednocześnie osiągając cele dotyczące wydajności. |
| Wyczerpanie portów SNAT | Nie można utworzyć połączeń wychodzących. W związku z tym wywołania podrzędne, takie jak wywołania bazy danych, kończą się niepowodzeniem. | Użyj prywatnych punktów końcowych do nawiązywania połączenia ze składnikami podrzędnymi. |
| Pojedyncze wystąpienie staje się w złej kondycji | Ruch użytkowników kierowany do wystąpienia w złej kondycji może spowodować niską wydajność, a nawet całkowicie zakończyć się niepowodzeniem. | Funkcja sprawdzania Kondycja usługi aplikacji spowoduje automatyczne zidentyfikowanie wystąpień w złej kondycji i zastąpienie ich nowymi wystąpieniami w dobrej kondycji. |
Logika wyewidencjonowania w usłudze Azure Functions
| Ryzyko | Wpływ | Możliwe środki zaradcze |
|---|---|---|
| Niska (zimna) wydajność uruchamiania | Ponieważ jest używany plan użycia usługi Azure Functions, nowe wystąpienia nie będą miały gwarancji wydajności. Wysokie zapotrzebowanie na usługę (od "hałaśliwych sąsiadów") może spowodować, że funkcja wyewidencjonowania będzie mieć długi czas trwania uruchamiania, który wpływa na cele wydajności. |
Uaktualnij plan usługi Azure Functions w warstwie Premium. |
| Awaria magazynu bazowego | Jeśli bazowe konto magazynu stanie się niedostępne, funkcja przestanie działać. | Użyj zasobów obliczeniowych o zrównoważonym obciążeniu z magazynem regionalnym lub zasobów obliczeniowych o zrównoważonym obciążeniu z magazynem udostępnionym GRS. |
Baza danych usługi Azure Cosmos DB
| Ryzyko | Wpływ | Możliwe środki zaradcze |
|---|---|---|
| Zmiana nazwy bazy danych lub kolekcji | Ze względu na niezgodność konfiguracji może dojść do utraty danych. Aplikacja nie będzie mogła uzyskać dostępu do żadnych danych, dopóki konfiguracja nie zostanie zaktualizowana i jej składniki zostaną ponownie uruchomione. | Zapobiegaj tej sytuacji przy użyciu blokad na poziomie bazy danych i kolekcji. |
| Awaria regionu zapisu | Jeśli region podstawowy (lub region zapisu) napotka awarię, konto usługi Azure Cosmos DB automatycznie podwyższy poziom regionu pomocniczego, aby był nowym podstawowym regionem zapisu po skonfigurowaniu automatycznego (zarządzanego przez usługę) trybu failover na koncie usługi Azure Cosmos DB. Przejście w tryb failover nastąpi w innym regionie w kolejności określonego priorytetu regionu. | Skonfiguruj konto bazy danych z wieloma regionami i automatycznym trybem failover. Jeśli wystąpi awaria, usługa automatycznie przejdzie w tryb failover i zapobiegnie wszelkim trwałym problemom w aplikacji. |
| Obszerne ograniczanie przepustowości spowodowane brakiem jednostek żądania (RU) | Niektóre sygnatury mogą działać gorąco przy użyciu usługi Azure Cosmos DB, podczas gdy inne mogą nadal obsługiwać żądania. | Użyj lepszej dystrybucji obciążenia, aby uzyskać więcej sygnatur lub dodać więcej jednostek RU. |
Projektowanie eksperymentu chaosu
Aby zaprojektować eksperyment chaosu, wybierz kilka przypadków awarii. Wybór może być oparty na prawdopodobieństwie wystąpienia awarii lub możliwego wpływu.
Celem eksperymentu jest zweryfikowanie miar odporności wdrożonych w aplikacji. Załóżmy na przykład, że uruchamiasz aplikację w usłudze App Service z włączoną nadmiarowością strefy. Jeśli wszystkie wystąpienia bazowe w strefie spadną, oczekujesz, że aplikacja będzie nadal działać.
Użyj programu Chaos Studio, aby wstrzyknąć błędy do odpowiednich składników. Program Chaos Studio oferuje bibliotekę błędów do wyboru. Jednak ponieważ biblioteka błędów nie obejmuje wszystkich elementów, może być konieczne dostosowanie scenariusza. Może też być konieczne znalezienie dodatkowych narzędzi, aby pomóc w wstrzyknięciu błędu.
Ważne
Wyceluj tylko środowisko nieprodukcyjne na eksperymenty. Wprowadzanie błędów do środowiska produkcyjnego może być ryzykowne i wymaga doświadczenia i planowania.
Przykład: awaria i tryb failover usługi Azure Cosmos DB
Załóżmy, że w tabeli wybrano scenariusz awarii "awarii regionu zapisu" usługi Azure Cosmos DB. Hipoteza jest: Zainicjowane przez usługę przejście w tryb failover nie powinno spowodować trwałego wpływu na aplikację. Jeśli hipoteza ta okaże się prawdziwa, sprawdzono, że miara odporności replikacji do wielu regionów ma pożądany pozytywny wpływ na niezawodność aplikacji.
Aby zasymulować ten błąd, użyj błędu usługi Azure Cosmos DB z biblioteki błędów programu Chaos Studio.
Ten przykład dotyczy trybu failover usługi Azure Cosmos DB, który działa przez 10 minut (PT10M) i używa West US 2 go jako nowego regionu zapisu. Przyjęto założenie, że West US 2 został już skonfigurowany jako jeden z regionów replikacji odczytu.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Po zakończeniu eksperymentu program Chaos Studio przełącza region zapisu z powrotem na oryginalną wartość.
Aby można było wstrzyknąć błąd względem zasobu platformy Azure, należy włączyć odpowiednie ustawienia obiektów docelowych i możliwości dla tego zasobu. To ustawienie steruje błędami, które mogą być uruchamiane względem zasobów włączonych w celu wstrzyknięcia błędów. W przypadku korzystania z obiektów docelowych i możliwości z innymi środkami zabezpieczeń można uniknąć przypadkowego lub złośliwego wstrzyknięcia błędów.
Po zaprojektowaniu zarówno testów obciążeniowych, jak i eksperymentów chaosu należy zautomatyzować je w potokach, aby były one uruchamiane spójnie i regularnie. W następnej lekcji dowiesz się więcej o dodawaniu testów potoków ciągłej integracji/ciągłego wdrażania.