Omówienie inżynierii chaosu i odporności
Przed rozpoczęciem korzystania z usługi Azure Chaos Studio warto zapoznać się z podstawowymi pojęciami inżynierii niezawodności lokacji, które są stosowane.
Co to jest odporność?
Tworzenie aplikacji rozproszonych na dużą skalę nigdy nie było łatwiejsze. Infrastruktura jest hostowana w chmurze, a obsługa języka programowania jest zróżnicowana. Istnieje również wiele składników i usług typu open source i hostowanych do kompilacji.
Niestety, nie ma gwarancji niezawodności dla tych podstawowych składników i zależności lub dla systemów opartych na nich. Infrastruktura może przechodzić w tryb offline, a w dowolnym momencie mogą wystąpić przerwy w działaniu usługi lub awarie. Niewielkie zakłócenia w jednym obszarze mogą być powiększone i mają długotrwałe skutki uboczne w innym.
Aplikacje i usługi muszą planować i uwzględniać problemy, takie jak:
- Awarie usług.
- Zakłócenia znanych i nieznanych zależności.
- Nagłe nieoczekiwane obciążenie.
- Opóźnienia w całym systemie.
Aplikacje i usługi muszą być zaprojektowane tak, aby obsługiwały awarie i zostały wzmocnione przed zakłóceniami.
Aplikacje i usługi, które zajmują się stresem i problemami, są bezpiecznie odporne. Niezawodność poszczególnych składników jest dobra, ale odporność jest właściwością całego systemu. Kompleksowa odporność systemu musi zostać zweryfikowana w zintegrowanym środowisku przypominającym środowisko produkcyjne z warunkami i obciążeniem w środowisku produkcyjnym.
Co to jest inżynieria chaosu i iniekcja błędów?
- Inżynieria chaosu: praktyka poddania aplikacji i usług rzeczywistym stresom i awariom. Celem jest budowanie i weryfikowanie odporności na zawodne warunki i brakujące zależności.
- Wstrzykiwanie błędów: czynność wprowadzenia błędu do systemu. Do docelowych składników systemowych można użyć różnych błędów, takich jak opóźnienie sieci lub utrata dostępu do magazynu. Można tworzyć scenariusze, z których aplikacja lub usługa musi być w stanie obsłużyć lub odzyskać dane.
Eksperyment chaosu polega na stosowaniu błędów pojedynczo, równolegle lub sekwencyjnie względem co najmniej jednego zasobu subskrypcji lub zależności. Celem jest monitorowanie zachowania systemu i kondycji, dzięki czemu można wykonywać działania na wszelkie pojawiające się problemy.
Eksperyment może reprezentować rzeczywisty scenariusz, taki jak awaria zasilania centrum danych lub opóźnienie sieci na serwerze DNS. Można go również użyć do symulowania warunków brzegowych, które występują. Przykłady to Zakupy Black Friday sprees lub gdy bilety koncertowe idą na sprzedaż dla popularnego zespołu.