Člověče, mysli trochu negativně ... s Azure Chaos Studio

Přemýšlet o tom, jak zařídit, aby vaše aplikace byla skvělá, je zábavné a naplňující. Je to stejné jako přemítat o tom, jak úžasná bude vaše dovolená nebo nový byt - kam půjdete, co kam dáte, co jak zařídíte. Daleko míň nadšení přináší úvahy typu a co když materiál zdraží na dvojnásobek, co když to nebude pasovat, co když řemeslník nedorazí, co když ztratím pas, co když děcko dostane COVID. Často tak máme tendenci mít fantasticky promyšlený scénář úspěchu a přípravu na ty nepovedené trochu odflákneme. A to i při provozu aplikací.

Co s tím? Chce to myslet trochu negativně. Když o ničem moc nepřemýšlíte a ono vám to skvěle funguje, tak je klidně možné, že máte prostě jen kliku - a to není strategie. Lepší je nedoufat a tím peklem si projít a proč čekat na to, až to ovlivní vaše uživatele, když pořádné inferno můžete rozpoutat ve svém testovacím prostředí? Dnes budeme šířit chaos díky Azure Chaos Studio.

Proč dělat chaos

Důvody jsem naznačil v předchozím odstavci, tak je pojďme trochu rozvést:

  • To, že si myslím, že je něco odolné, není totéž, jako vědět, že to odolné je.
  • Vývojáři mohou udělat změny, které mají negativní dopad na schopnost přestát havárie a to nemusím chytnout ve standardní testu zaměřeném na to dobré. Jinak řečeno to, že jsem loni při výpadku ověřil, že redundance funguje neznamená, že funguje dnes, protože se kód mnohokrát změnil.
  • Je samozřejmě skvělé, když se věci vyřeší automaticky a aplikace dokáže tolerovat výpadek, ale ne vždy je to možné nebo rentabilní vzhledem k velikosti týmu. Ruční zásah není nutně špatně, ale klíčem je schopnost detekovat problém a pochopit příčinu. Monitorujeme věci tak, abychom problémy včas odhalili a netápali ve tmě? Nenaletěli jsme na chybné vnímání světa na svítí/nesvítí a problém typu funguje, ale blbě, neumíme odhalit a řešit?
  • Při havárii autobusu dokáže náhodou přítomný záchranář v civilu reagovat daleko rychleji a přesněji, než průměrný cestující. Jasně, znalosti mu pomůžou použít správné postupy, ale schopnost zareagovat není o znalosti, ale cviku a zkušenosti. Kdo nikdy nezachraňoval, má to mnohem těžší.

Azure Chaos Studio

Microsoft uvedl do preview novou službu na generování a řízení chaosu, která vychází z technologií, které používá dlouhodobě interně. Umožní naplánovat komplexní scénáře a postupy, celé workflow, kdy si vaše aplikace projde peklem - 3 minuty škodí tady, pak 2 minuty tady.V zásadě jde o tři hlavní oblasti testů:

  • Azure jako takový, tedy restart platformní služby, sestřelení VM, síťové odizolování komponenty přes NSG a seznam se bude jistě významně rozšiřovat
  • Aplikace ve VM, kdy se použije agent, který na základě příkazů z Azure Chaos Studio provádí záškodnické akce. U Linuxu typicky s využitím stress-ng nebo zabíjení procesů, u Windows díky interně vyvinuté technologii, která dokáže věci jako sestřelování procesů, izolace sítě, zanášení latence do síťové komunikace, generování zátěže apod.
  • Kubernetes, kdy se využívá výborné open source technologie Chaos Mesh, o které jsem psal v samostatném článku

Co mě opravdu potěšilo je propracovanost co do řízení přístupů. Každý agent ve VM má svou identitu, celé chaos studio má svou identitu a každý jednotlivý experiment taky. Do toho přidejte proces onboardování a zapínání jaké funkce na kterém zdroji jsou k dispozici. Zkrátka zdá se mi, že služba udělala opravdu všechno pro to, abyste si omylem nezavraždili produkci nebo aby nějaký super silný účet nepřinášel bezpečnostní riziko.

Služba je v preview a očekávám tam bouřlivý vývoj. Jedna oblast, kde do budoucna doufám ve vylepšení je integrace s věcmi jako Azure Load Testing (generování zátěže a měření výsledků) nebo Application Insights (dostupnost a výkonnost aplikací). Moc rád bych tohle propojil dohromady a dostal výsledný report - tady je generovaná zátěž vs. dostupnost aplikace a jak to vypadá v jednotlivých fázích chaos experimentu.

Připravíme si prostředí

Nahodím si nějaká VMkaa, chaos studio, identity, přístupy.

az provider register -n Microsoft.Chaos
az group create -n chaos -l westeurope
az network vnet create -n chaosnet -g chaos --address-prefixes 10.10.0.0/16
subnetId=$(az network vnet subnet create -n default --address-prefixes 10.10.0.0/20 -g chaos --vnet-name chaosnet --query id -o tsv)

az aks create -n chaosaks -g chaos -c 1 -x -s Standard_B2s --vnet-subnet-id $subnetId -y

az network nsg create -n chaosvmnsg -g chaos 
az network nsg rule create -n ssh -g chaos --nsg-name chaosvmnsg --priority 120 --source-address-prefixes $(curl ifconfig.io) --destination-port-ranges 22 
az network nsg rule create -n rdp -g chaos --nsg-name chaosvmnsg --priority 130 --source-address-prefixes $(curl ifconfig.io) --destination-port-ranges 3389

az identity create -n chaosidentity -g chaos
az role assignment create --role Contributor \
    --assignee-object-id $(az identity show -n chaosidentity -g chaos --query principalId -o tsv) \
    -g chaos

az vm create -n chaosvm \
    -g chaos \
    --size Standard_B1s \
    --image UbuntuLTS \
    --admin-username tomas \
    --ssh-key-values ~/.ssh/id_rsa.pub \
    --public-ip-address chaosvmip \
    --nsg chaosvmnsg \
    --assign-identity chaosidentity

az vm create -n chaosvmwin \
    -g chaos \
    --size Standard_B2s \
    --image Win2019Datacenter \
    --admin-username tomas \
    --admin-password Azure12345678 \
    --public-ip-address chaosvmipwin \
    --nsg chaosvmnsg \
    --assign-identity chaosidentity

az aks get-credentials -n chaosaks -g chaos

redisName=chaosredis$RANDOM
az redis create -n $redisName -g chaos --sku Premium --vm-size p1 -l westeurope --shard-count 2

Nasazení Chaos Studia a první experiment

Pojďme tedy do Chaos studia.

Nejdřív nalodíme všechny zdroje do studia.

V případě VM musí Azure doručit Azure Chaos Studio agenta do virtuálky - nalodíme.

Následně můžu u každé VM selektivně říct, které testy jsem ochoten pro ni připustit.

Pojďme tedy vytvořit první experiment.

Každý experiment se skládá ze sekvenčních kroků a v každém může být několik větví. Do toho vkládáme jednotlivé záškodnické akce včetně možnosti čekat, než sestřelíme další věc.

Začněme NSG akcí - pojďme dost brutálně zakázat VM, na které NSG je, jakoukoli komunikaci ven, takže ji efektivně odstřihneme. Dejme jí tuto drastickou kůru po dobu jedné minuty.

Každý experiment má svou identitu a ve výchozím stavu samozřejmě nemůže vůbec nic. Musím mu proto aktivně přiřadit práva. Nemusím se tedy být - i kdyby byl někdo Contributor mé produkce, nemůže omylem vytvořit experiment, který ji sestřelí - musí být Owner nebo User Access Manager, aby mohl taková práva experimentu dát.

Takhle vypadá moje NSG před zásahem záškodníků.

Spusťme experiment.

Po chvilce se NSG změní … škodíme. Po nastaveném čase (1 minuta) se vrátíme do normálu.

Restart Azure Redis

Zkusme teď další další sabotáž - restart Azure Redis, což by nám mohlo v aplikaci sestřelit Redis spojení a propláchnou cache.

Podíval jsem se do Activity Log o mé Azure Redis a vidím, že identita exp1 tam skutečně byla a provedla restart - mrška.

Necháme Azure ubližovat mašinkám

Pojďme teď jednoduše vypnout VM, protože hardware může umřít, VM nám na chvíli zmizí (než se spustí jinde) a jak se s tím vypořádáme? Ten cluster co máme nastaven - funguje vůbec?

Vypnutí provedeme na dvě minuty.

Pouštím experiment. A jejda, VMko jde dolu.

Po dvou minutách znovu startuje.

Záškodnictví přímo ve VM

Dalším typem generování chaosu je využití agenta ve VM, který na základě příkazů z Chaos Studio bude provádět patřičné akce. Tady se podpora různí podle OS - ve Windows například umí simulovat i síťovou latenci, v Linux zatím ne. Já použiji přetížení procesoru a aby to fungovalo, musím dle dokumentace mít v mašině balíček stress-ng. To jsem udělal, pojďme na to.

Spustím experiment a skutečně ve stroji pozoruji stress-ng proces a velkou zátěž CPU.

top - 18:39:45 up 3 min,  1 user,  load average: 1.31, 0.97, 0.43
Tasks: 134 total,   2 running,  67 sleeping,   1 stopped,   0 zombie
%Cpu(s): 90.7 us,  0.3 sy,  0.0 ni,  8.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   939060 total,   202568 free,   281788 used,   454704 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   498828 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
16186 root      20   0   89256   8324   4024 R 90.7  0.9   0:57.05 stress-ng-cpu
 1459 root      20   0 2954316  56760  22960 S  0.3  6.0   0:01.87 AzureChaosAgent
 1489 root      20   0  186888   6272   4624 S  0.3  0.7   0:00.26 omiagent
 2097 omsagent  20   0  265504  42516   8424 S  0.3  4.5   0:00.50 omsagent-26e203
17211 tomas     20   0   44548   4048   3420 R  0.3  0.4   0:00.04 top

Zkusíme teď něco ve Windows a nejvíc mě láká zpomalit některé síťové requesty. Stažení stránky ipconfig.io mi vychází na nějakých 263 milisekund.

PS C:\Users\tomas> measure-command {invoke-webrequest http://ipconfig.io}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 263
Ticks             : 2630618
TotalDays         : 3.04469675925926E-06
TotalHours        : 7.30727222222222E-05
TotalMinutes      : 0.00438436333333333
TotalSeconds      : 0.2630618
TotalMilliseconds : 263.0618

Pojďme teď po dobu pěti minut zavařit všem destinacím na portu 80 navýšením latence o jednu vteřinu.

Spustíme experiment a ejhle - už request netrvá čtvrt vteřiny, ale vteřinu a čtvrt, jak jsme čekali.

PS C:\Users\tomas> measure-command {invoke-webrequest http://ipconfig.io}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 1
Milliseconds      : 249
Ticks             : 12492932
TotalDays         : 1.4459412037037E-05
TotalHours        : 0.000347025888888889
TotalMinutes      : 0.0208215533333333
TotalSeconds      : 1.2492932
TotalMilliseconds : 1249.2932

Tohle se myslím opravdu hodí - jak se moje aplikace začne chovat, když se najednou přístupy do databáze zpomalí? Nestane se náhodou, že řetězcem událostí tahle komponenta začne být pomalá, jiná kvůli tomu taky, následně se na nějaké třetí začnou hromadit nevyřízené požadavky až ta to neustojí a odumře?

Kouzla v Kubernetes s Chaos Mesh

Azure Chaos Studio dokáže ovládat Chaos Mesh projekt v Kubernetes, o kterém jsem psal v samostatném článku

Jednoduše přidáte další krok a Chaos Mesh parametry mu předáte.

Za mě je Azure Chaos Studio výborné a slibuji si hodně i od dalšího rozvoje, zejména v oblasti monitoringu. Zajímá mě i integrace do CI/CD s GitHub Actions … to zkusím jetě prozkoumat.



Federace tokenů GitHub Actions s Azure Active Directory pro přístup z vaší CI/CD do Azure bez hesel Automatizace
GitOps pro konzistentní stav všech vašich Kubernetes clusterů s Azure a Flux Automatizace
Automatizujte koloběh sandbox prostředí v Azure s Bicep, Terraform nebo Pulumi Automatizace
Infrastructure as code v Azure: Bicep (ARM) vs. Terraform vs. Pulumi vs. Crossplane Automatizace
Bicep - výhody nativní ARM automatizace s jednoduchostí ala Terraform Automatizace