Chaos Engineering ya da Türkçe olarak Kaos Mühendisliği, yeni duymaya başladığımız bir kavram olsa da, aslında konsept olarak yeni değil. Kısaca kaos mühendisliği, sistemin sorun anlarında nasıl tepki vereceğini, nasıl davranacağını sorun henüz oluşmadan anlamamızı sağlamak için uygulamayacağımız yöntemleri belirlemek olarak tanımlanabilir. Burada önemli olan ve dikkat etmemiz gereken kısım ise “henüz oluşmadan önce” derken aslında bir simülasyondan değil, gerçekten bu sorunu kasıtlı olarak oluşturup sistemin davranışını gözlemlemek. Kısaca bu işlemi yaparken oldukça dikkatli ve bütün ortamını indirmeden önce gerekli hazırlıkların tamamlandığından emin olmalısınız.
Kaos oluşturma işlemi için sistem üzerinde birden çok kesinti uygulamayabilirsiniz. Network bağlantılarını kesintiye uğratma, sistemi yavaşlatma, API erişimlerindeki token’ları iptal etme gibi bir çok yöntem var. İşin mühendislik kısmı ise testlerde akıla gelmeyecek sorunları da oluşturup test edebilmekten geçiyor.
Kaos mühendisliğinde de diğer mühendislik alanlarında olduğu gibi best practice olarak da bildiğimiz tavsiye edilen yöntemler var.
- Shift left: Amaç çalışmaları dev ve test ortamlarında yaparak, sonuçları daha prod’a alınmadan gözlemleyebilmek. Burada dev/test ortamınızın pre-prod/prod ile birebir aynı olduğunu varsayıyorum.
- Shift right: Gerçek yük altında sisteminizin her türlü sorunda ayakta kalacağına %100 güveniyor ya da kısa süreli kesintiler çok da sorun olmaz diyebiliyorsanız (?), prod ya da pre-prod ortamlarınızda uygulayabilirsiniz. Gerçek kaosu görmek isteyenler için :)
- Blast radius: Sisteminizdeki bütün ürünleri aynı anda indirebilir miyiz değil, belirli bir alan belirleyerek sadece o alan içerisinde hareket etmek. A ürününü denerken konudan bağımız B ürününü de deneylere eklemek çok da mantıklı olmayabilir.
- Error budget testing: Kaos mühendisliğine belirli bir bütçe ayırmakta ve bunu bir kere değil düzenli olarak yapmakta fayda var. Özellikle de sistemle ilgili herhangi bir güncelleme sonrası.
Bu işlemleri Azure üzerinde yapabilmek için ise Microsoft bize Azure Chaos Studio adından bir ürün sunuyor. Kullanımı oldukça kolay olan ve ben bu yazıyı yazarken hala Preview aşamasında olan bu ürünü bir kaç örnek ile inceleyelim.
İlk olarak yapmanız gereken, kullanacağınız subscription altındaki Resource Providers‘a gidip Microsoft.Chaos‘u register etmek (Resim-1).
Resim-1
Sonrasında ise Azure Portal ana sayfasının üst kısımında Resim-2‘de göreceğiniz gibi Chaos Studio ikonunu göreceksiniz.
Resim-2
Chaos Studio bir resource olmadığı için, sol tarafta alışık olduğunuz seçenekler bulunmuyor. Overview kısmını geçecek olursak Experiment Management altında 2 adet seçenek var: Targets ve Experiments.
Resim-3
Targets altında üst kısımda bulunan filtreleri kullanarak yaptığınız seçimlere göre seçtiğiniz subscription ve resource group’lara göre Chaos Studio experiments yapabileceğiniz kaynakları listeleyebilirsiniz.
Demo ortamında bir adet VNET, bu VNET’e bağlı 2 adet Ubuntu VM ve önlerinde de bir Azure Load Balancer bulunuyor. Her iki Ubuntu VM içerisinde de docker kurulu ve docker üzerinde de traefik/whoami çalışıyor. Bu imaj basit bir go server ve isteklere OS ve HTTP bilgilerini dönüyor.
Terminal üzerinden load balancer adresine her 2 saniyede bir istek atan basit bir döngü yazdım. Hostname değerinden de göreceğiniz gibi her istek farklı VM’lere gidiyor.
Resim-4
Sıradaki işimiz ise VM’lere Chaos Studio üzerinden sorun ekleyerek sistemin nasıl davranacağını gözlemlemek. İlk olarak Enable targets seçeneği ile VM üzerinde nasıl bir sorun oluşturmak istediğimizi belirlememiz gerekiyor.
- Service-direct targets: Azure servislerine yönelik sorunlar oluşturmak için; VM kapatma, diğer servislere erişimlerini engelleme vb.
- Agent-based targets: VM üzerinde bir sorun oluşturmak için; yüksek CPU/RAM kullanımı, disk problemleri vb.
Resim-5
İlk olarak service-direct agent seçeneği ile ilerleyelim. Burada bir resource deployment ekranı göreceksiniz, ama sizden herhangi bir bilgi girişi istemeyecek. Deployment işlemi oldukça hızlı bir şekilde tamamlanıyor, sonrasında Targets üzerindeki listeden işlemin tamamlandığını ayrıca teyit etmek isterseniz service-direct kolonundaki değerin Enabled olarak değiştiğini görebilirsiniz.
Sırada Experiments oluşturma var. Burada ise yeni bir experiment yani bir resource oluşturacağız. İlk adımda standart olarak subscription, resource group, name ve region seçenekleri mevcut.
Resim-6
İkinci kısımda ise Experiment designer seçeneği ile karşılaşıyoruz. Burada birden fazla adım ve branch tanımı yapabilir, sorunları sıralı bir şekilde ve gruplayarak tanımlayabilirsiniz. Add action altında da sorun ya da gecikme ekleme seçenekleri mevcut.
Resim-7
Add fault seçeceği ile devam ediyorum ve sağ tarafta Resim-8‘de göreceğiniz ekran çıkıyor.
Resim-8
İlk olarak nasıl bir sorun ekleme istediğimizi select a fault altından seçebiliyoruz. Tam liste ve detaylara buradan ulaşabilirsiniz. VM Shutdown seçeneğini seçiyorum. Süre olarak min değer olan 5 dk, ve en altta da abruptShutdown yani “direkt fişi çek” seçeceğini işaretliyorum. :)
Resim-9
Bir sonraki kısımda da hangi kaynaklarda bu sorunu uygulayacağımızı seçiyorum.
Resim-10
Ekranda gördüğünüz detaylar tamamsa Review+create‘a basarak experiment’i oluşturabilirsiniz. Üst kısımda çıkan uyarı mesajından da göreceğiniz gibi, experiment oluşturduktan sonra, resource target olarak seçtiğimiz VM’e erişmesi için bir de yetki tanımı yapmamız gerekecek.
Resim-11
Bu tanım için de Azure Portal üzerinden ilgili VM’e gidip, IAM altından Virtual Machine Contributor yetkisi vermem gerekiyor.
Resim-12
Son olarak oluşturduğum experiment’e gelip start tuşuna basmak kaldı. Ekranda yazan ciddi sorunlar çıkabilir uyarısını dikkate aldıktan sonra experiment’i başlatıyorum.
Resim-13
Status running olarak gördükten sonra, yazının başlarında çalıştığım bash script’ini tekrar çalıştıyorum. Resim-14‘te de gördüğünüz gibi artık istekler sadece tek bir VM’e gidiyor.
Resim-14
Experiment üzerinde target resource olarak seçtiğiniz VM’e giderseniz gerçekten stopped olarak görebilirsiniz. Experiment’i sonlandırdığınız zaman VM otomatik olarak başlatılacağı için ekstra bir işlem yapmanıza gerek yok.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
Azure Chaos Studio documentation – tutorials, API reference | Microsoft Learn
TAGs: Azure, Azure Chaos Studio, Chaos Engineering, Virtual Machines, VM, Fault Injection, Resilience
