Önceden uygulamaların işleyişi, sadece tek bir web servisin tüm işi yürütmesi ile gerçekleşiyordu. Fakat son yıllarda, mikroservis mimarilerin yaygınlaşması ile birlikte, uygulama altyapısı birçok servisin birbiri ile konuştuğu dağıtık yapılara dönüşmüş durumda. Bu yapıların bir avantajı olarak, servislerin modüler yapıda olması ve bu sebeple ayrı ayrı yönetiminin kolay bir şekilde yürütülmesi gösteriliyor. Fakat bu avantaj, bir ip yumağı gibi birbirine dolanmış servislerin yönetiminin zorlaşması ve hata ayıklama sürecinin güç hale gelmesi gibi birtakım yan etkileri de beraberinde getiriyor. Ayrı modüler yapıların gözlenmesi için sektörde çeşitli araçlar mevcut. Fakat beklenmedik bir hata olması veya ağdaki bir servisin hizmet verememesi durumunda nelerle karşılaşılacağını tahmin etmek oldukça güç bir hal alıyor. 2017 yılında yapılan bir araştırmaya katılan şirketlerin %98’i, 1 saatlik çöküntü sonucu 100.000 doların üstünde kayıp yaşadığını belirtiyor. Bu tarz beklenmedik durumlar nadiren gerçekleşse de, uygulamanın bulunduğu canlı ortamı yıkıcı bir şekilde etkileyecek kadar sistemi bozarak, dağıtık sistemleri kaotik duruma getirebiliyor. British Airways’in 2017 yılında yaşadığı bir IT kesintisi ile 80 milyon pound kaybetmesi de bu tarz kaotik durumlara örnek olarak gösterilebilir.

Bu nedenle, bir hata ortaya çıkıp tüm sisteme yayılarak etki etmeden önce, sistemin zaafiyetlerini tespit etmek gerekiyor. Sistem zaafiyetleri için örnek vermek gerekirse:

• Bir servisin çökmesi durumunda, yerine geçecek servis için oluşturulan yapılandırma dosyasının yanlış kodlanması,
• Zaman aşımı değerlerinin düzgün bir şekilde ayarlanmamasından dolayı isteklerin sürekli gönderilmesi,
• Sistemin bağımlı olduğu alt bileşenin aşırı veri trafiği alması ile oluşan kesinti,
• Tek bir hata ile oluşan çöküşün tüm sisteme yayılması vb. durumlar örnek olarak verilebilir.

Bu tarz problemlerin, canlı ortamdaki uygulamaları kullanan müşterilere etki etmeden önce, en önemli olanları tespit edilmesi gereklidir. Bu nedenle, sistemin ne kadar dağınık veya karmaşık olduğu farketmeksizin, beklenmedik hatalara karşı sisteme güvenin oluşturulması amacıyla, oluşabilecek kaotik durumun yönetilmesi için bir yöntem gerekmektedir.

Deneysel ve sistem temelli bir yaklaşım sayesinde, dağıtık sistemlerde oluşabilecek kaotik durumların ölçeklendirilerek tespit edilmesi ve bu sistemlerin çöküntüler esnasında ayakta kalabilirliği için güvenin oluşturulması sağlanır. Aynı biyolojide olduğu gibi kontrollü deneyler gerçekleştirilerek, bir dağıtık sistemin anormal durumlar esnasındaki davranışı gözlenerek bilgi edinilebilir. Bu çalışmaya kaos mühendisliği adı verilir.

• Kaos mühendisliği: canlı ortamda oluşabilecek problemli durumlara karşı, sistemin ayakta kalma kabiliyetine olan güvenin oluşturulması amacıyla, sistem üzerinde kaotik deneyler yapma disiplinidir.

Kaos Mühendisliği Nasıl Ortaya Çıktı?

2010: Chaos Monkey’in Ortaya Çıkışı

2010 yılında Netflix’in kendi servislerini AWS’ye taşıması sürecinde, canlı ortamda oluşabilecek hataların testi için uygun bir araç bulunmamaktaydı. Oluşacak test aracının geliştirimindeki temel maksat, hiçbir hatanın oluşmayacağı yazılım geliştirme modelinden, kaçınılmaz şekilde çöküntülerin yaşanabileceği ve yazılımcıların da bu çöküntüleri nasıl düzeltilebileceği bilinci ile geliştirim yapacağı bir modele geçmekti. Bu amaç doğrultusunda Chaos Monkey adlı yazılımı geliştirdiler.

Chaos Monkey yazılımı, tıpkı sistem odasına salıverilen bir maymunun, network kablolarını kopartarak sistemi çalışmaz hale getirmesi gibi çalışıyordu. Canlı ortamdaki dağıtık servislerden herhangi birini mesai saatleri içerisinde kapatıyordu. Bu sayede mevcut sistemin bu kesintiden nasıl etkilendiğini ve kesintiyi ne şekilde telafi ettiğini gözlemlemek mümkün hale geliyordu. Mesai saatleri içerisinde böyle bir işlem yapmak kulağa ne kadar çılgınca gelse de, kesintinin iyileştirilmesi otomatik hale gelmiş oluyordu. Bunun en güzel avantajı da, pazar gecesi saat 03.00’te herhangi bir kesinti olsa dahi sistem ekibinin bu durumdan neredeyse hiç haberi olmuyordu.

2011: Simian Army’nin Ortaya Çıkışı

2011 yılında Netflix’in kaos yönetim araçlarını birleştirerek adına Simian Army ismini verdi. Simian Army, Chaos Monkey üzerine enjekte edilerek ve yeni yetenekler kazandırarak sistemde çeşitli tiplerde sorun oluşturmaya yarıyordu. Örneğin Simian Army içerisinde yer alan Latency Monkey, istemci ve sunucu arasında bir katman oluşturarak, gelen isteklerin ve gönderilen cevapların gecikmesine hatta ilgili servisin tamamen hizmet verememesine yol açıyordu.

2012: Chaos Monkey’in Açık Kaynak Haline Gelmesi

2012 yılına gelindiğinde Netflix, Chaos Monkey’in kaynak kodlarını GitHub üzerinde paylaşarak, sıklıkla oluşan beklenmedik hatalar karşısında en iyi savunma yöntemi olduğunu, ve Netflix’in bu sayede daha hata toleranslı hale geldiğini açıkladılar.

2014: Kaos Mühendisliğinin Oluşturulması

2014 yılında Netflix, Chaos Engineer adında yeni bir meslekî rol oluşturdu. Daha sonra Google, Microsoft, Facebook, LinkedIn ve Amazon gibi birçok büyük şirket kaos mühendisliğini tatbik eder hale geldi. Hatta geleneksel mimari üzerine kurulu bankacılık ve finans sektöründe yer alan Ulusal Avustralya Bankası da kaos mühendisliği pratikleri uygulandı. Ayrıca kaos mühendisliği üzerinde çalışan mühendisler ve ilgili araçları içeren diyagram da oluşturuldu.

Kaos Mühendisliğinin Uygulanması

Kaos mühendisliği, dağıtık sistemin bir hata karşısında nasıl davranacağını göstermesi için, özenli ve planlı bir şekilde deneylerin yürütülmesidir. Bu deneyler aşağodaki gibi 3 adımdan oluşur:

Kaos Mühendisliğinde uygulanan temel adımlar

1. Deneyin planlanması. Sistemde nasıl bir hata oluşabilir? Bunun için hipotez oluşturulur.
2. Patlatma oluşturulur. En küçük ölçekte bir hata oluşturulur. Bu ölçek, sistemin yanlış çalıştığı anlarda bilgi verebilecek büyüklükte olmalıdır.
3. Ölçekleme. Sorun çözüldü ise deney bitirilir. Aksi halde ölçek büyütülerek hatanın daha fazla servise etki etmesi sağlanır.

Deney bittiğinde, sisteme gerçekte oluşacak etki ile ilgili bilgi sağlanmış olur.

Peki Neden Sistemi Bilerek Patlatıyoruz?

Aynı aşı olduğumuzdaki gibi, vücuda az miktarda virüsün enjekte edilip savaşarak nasıl bağışıklık kazanıyorsak, dağıtık sistemlerde de kaos mühendisliği uygulanarak sisteme enjekte edilen ağ gecikmeleri, işlemci hataları, ağ paketlerinin kaybolması gibi kötü huylu davranışlar oluşturularak sistemin çökmesine karşı bağışıklık kazandırılabilir.

Ayrıca bu deneyler, sistemde kesintiler oluştuğunda mühendislerin hemen fark edebileceği bir kas hafızası da oluşturur. Aynı F1’de pit-stop’a giren aracın lastiklerinin hızla değiştirilmesi gibi, sistem mühendisleri de aynı çeviklikte sorunu çözebilir hale gelirler.

Dağıtık Sistemlerde Kaos Mühendisliğinin Rolü Nedir?

Dağıtık sistemler, doğası gereği yekpare sistemlere göre hataya daha meyillidirler. Bu nedenle, herhangi bir yerden, nasıl bir hata geleceğini fark etmek daha zordur. Peter Deutsch tarafından yayınlanan aşağıdaki listede, dağıtık sistemlerin geliştiriminde düşülecek 8 yanılgı yer almaktadır:

1. Ağ bağlantısı güvenilirdir.
2. Servis gecikmeleri hiç yaşanmaz.
3. Bant genişliği sonsuzdur.
4. Ağ bağlantısı güvenlidir, hiç saldırı gelmez.
5. Ağ topolojisi hiç değişmez.
6. Sadece bir tane yönetici yetkili kullanıcı vardır.
7. Taşınma maliyeti sıfırdır.
8. Ağdaki cihazlar homojendir.

Bu yanılgılardan birçoğu Kaos Mühendisliği deneyleri için, paket kaybına yönelik saldırılar ve ağ gecikmeleri gibi saldırı tiplerinin tasarlanmasında ön ayak olurlar. Örneğin ağ bağlantısı kesintileri, birçok müşteriyi etkileyebilecek uygulama hatalarına sebep olabilir. Bu nedenle uygulamalar, sonsuza dek bir ağ paketinin gelmesini bekleyebilir. Bekledikleri süre boyunca bellek ve diğer sistem kaynaklarını kalıcı olarak ele geçirip tüketebilirler. Ağ bağlantısı kesintisi düzelse dahi, uygulamalar sürekli istek göndererek bekleme yaptıklarından dolayı nihai olarak hata alabilirler. Servisleri tekrar elle başlatmak dahi gerekebilir. Bu tür örnekler test edilmeli ve oluşabilecek hatalara karşı hazırlıklı olunmalıdır.

Kaos Mühendisliğinin; Kullanıcı, Kurum ve Teknik Bazda Yararları Nelerdir?

• Kullanıcı bazında: Uygulamaların sürdürülebilirliği ve dayanıklılığı arttığı için kesinti oluşmayacağından dolayı, kullanıcının yaşantısını etkileyecek bir çöküntü meydana gelmeyecektir.
• Kurum bazında: Kaos Mühendisliği, kurum için oldukça büyük gelir kayıplarını önleyebilir, bakım maliyetlerini düşürebilir, daha mutlu ve işine sarılan mühendislerin oluşmasını sağlayabilir, mühendis ekipleri için telefon görüşmelerindeki çalışmalarını geliştirebilir, ve tüm şirkette sorunlu olay yönetimlerini iyileştirebilir.
• Teknik bazda: Kaos deneylerinden elde edilen öngörüler, hataların ve bir hata oluştuğunda telefonla aramaların azalmasına, sistem hataları üzerinde daha fazla bilgi edinilmesine, sistem tasarımının iyileştirilmesine, ve ortalama hata tespiti sürelerinin azalmasını sağlamaktadır.

Servis Ekipleri için Kaos Mühendisliği

Netflix gibi birçok mühendislik icra eden şirkette, hususi olarak ayrılmış Kaos Mühendisliği ekipleri bulunmaktadır. Bu ekipler genellikle 2-5 kişilik küçük gruplar halinde yer alırlar. Kaos Mühendisliği ekibi, kurum içerisinde Kaos Mühendisliğinin gerçekleştirilmesi ve desteklenmesinden sorumludur. Ancak bu ekip sadece Kaos Mühendisliğinde çalışmaz. Aynı zamanda kurum içerisindeki ekipler arasında Kaos Mühendisliğinin uygulanmasını da destekler.

Genellikle kurum içerisinde, Kaos Mühendisliğini ilk uygulayan ekipler aşağıdaki gibi gerçekleşir:

• Ağ Trafiği Ekibi (Örn: Nginx, Apache, DNS)
• Veri Akışı Ekibi (Örn: Kafka)
• Veri Depolama Ekibi (Örn: Amazon S3)
• Veri ekibi (Örn: Hadoop/HDFS)
• Veritabanı Ekibi (Örn: MySQL, Amazon RDS, PostgreSQL)

Bazı şirketler, Kaos Mühendisliğini normal uygulama yayımlama döngüsüne test pratiği olarak entegre etmişlerdir. Bu sayede her sürümde oluşturulan özelliğin sistemi bozmadığndan emin olunmuş olur.

Kaos Mühendisliği Deneylerine Nasıl Başlanır?

Kaos mühendisliği deneyleri, Donald Rumsfeld’in sözünün baz alındığı aşağıdaki sıra ile önceliklendirilerek uygulanmalıdır:

1. Bilinen Bilinenler – Farkında olduğumuz ve anlayabildiğimiz hatalar.
2. Bilinen Bilinmeyenler – Farkında olduğumuz fakat tam olarak anlayamadığınız hatalar.
3. Bilinmeyen bilinenler – Anladığımız fakat farkında olmadığınız hatalar.
4. Bilinmeyen bilinmeyenler – Ne farkında olduğumuz ne de anlayabileceğimiz hatalar. Diyagram aşağıdaki gibi olacaktır:

Teste öncelikle known knowns (bilinen bilinenler) kısmından başlanır

Bu diyagramı açıklamak için, öncelikle parçalara ayrılmış örnek bir MySQL veritabanı üzerinde nasıl deneyleri seçeceğimize değinelim. Bu örnekte 100 adet MySQL sunucusunun bulunduğu bir cluster yer alsın ve her sunucuda çoklu shard edilmiş bölümler bulunsun.

Region’ların birinde, iki replikanın yer aldığı temel bir veritabanı sunucumuz var, ve yarı senkron olarak replikasyon işlemi gerçekleştiriliyor. Diğer region’da ise temel sunucunun bir pseudo (sahte) versiyonu var ve iki adet pseudo replikası bulunuyor:

Bilinen Bilinenler

• Bir replika kapatıldığında, cluster’dan kaldırılmış olacağını biliyoruz. Devamında kaldırılan replikanın temel sunucudan klonlanarak tekrar cluster’a ekleneceğinin de farkındayız.

Bilinen Bilinmeyenler

• Log dosyalarına bakarak klonlama işleminin hatalı veya başarılı bir şekilde gerçekleştiğini biliyoruz. Fakat hata oluştuğunda, klonun yaratılarak, tekrar cluster’a dönmesi için geçen haftalık ortalama süreyi bilmiyoruz.
• Replikanın kapatılması sonucu cluster’da bir replika kalmasından 5 dk sonra uyarı mesajını alacağımızı biliyoruz. Fakat hataların daha verimli bir şekilde engellenmesi için uyarı mesajının gönderileceği eşik sürenin kusursuz biçimde doğru olduğundan emin değiliz.

Bilinmeyen Bilinenler

• Yoğun bir pazartesi günü mesai saatinde aynı anda iki replikayı kapattığımızda, klonlama ve cluster’a ekleme süresinin ortalama ne kadar olacağını bilmiyoruz. Fakat diğer region’daki pseudo sunucu ve replikaların sorunsuz çalışarak hizmet vereceğini biliyoruz.

Bilinmeyen Bilinmeyenler

• Region A’daki tüm cluster’ı kapattığımızda ne olacağını bilmiyoruz. Ayrıca bu senaryoyu çalıştırmadığımız için, pseudo region’ın kendini ilk region’a klonlayacağını da bilmiyoruz.

Aşağıdaki sırayla çalıştırılacak şekilde kaos deneylerini yaratabiliriz:

1. Bilinen Bilinenler: Replikalardan biri kapatılır ve ölçümleme işlemine başlanır. Kapatılma anına kadar geçen süre, kapatılan replikanın kaldırılması, klonlama işleminin başlatılması, klonlama işleminin tamamlanması, klonun cluster’a eklenmesi süreleri ölçülür. Bu deneye başlamadan önce replika sayısı ikiden üçe çıkartılır. Bu kapatılma deneyi düzenli sayıda replika seçilerek yürütülür ama asla 0 adet (hiç replikanın seçilmemesi durumu) olmamalıdır. Replikanın kapatılması hatasının giderilmesi için geçen ortalama süre raporlanır ve yoğun geçen mesai saatleri hesaba katılarak deneyin gün ve saatlere bölünerek gerçekleştirilmesi sağlanır.
2. Bilinen Bilinmeyenler: Bilinen-bilinenler deneyinden elde edilen sonuç verileri kullanılarak “bilinen-bilinmeyenler” sorularına cevaplar bulunmaya çalışılır. Bu sayede, replikanın kapatılma hatasının oluşmasından, klonun cluster’a eklenmesine kadar geçen ortalama süre haftalık bazlında bilinir hale gelecektir. Ayrıca kapatılma olayı gerçekleştiğinde 5 dakika sonra uyarı mesajının gönderilmesinin de uygun bir eşik değer olup olmadığı farkedilecektir.
3. Bilinmeyen Bilinenler: Bu deney başlatılmadan önce replika sayısı üçten dörde çıkarılır. Cluster içerisindeki iki replika birden aynı anda kapatılır. Her pazartesi mesaisinde gerçekleştirilen ve birkaç ay sürecek olan deneylerde, iki replikanın klonlanarak yerini alması için geçen süre ölçümlenir. Bu deney sayesinde, ana cluster’ın klonlama ve backup yapma sırasında oluşan yükü kaldıramaması gibi birçok bilinmeyen problem tespit edilebilir. Böylece replikaların daha iyi yönetimi için çalışmalar yapılabilir.
4. Bilinmeyen bilinmeyenler: Cluster’ın tamamının (birincil sunucu ve iki replikasının) kapatılması için iyi bir mühendislik çalışması gerekecektir. Bu hata gerçek ortamda beklenmedik şekilde oluşabilir. Fakat henüz bu hatayı gidermek için hazır olmadığınızdan dolayı, bu tarz kaos deneylerini yapmadan önce gerekli mühendislik çalışmasını önceliklendirmeniz gereklidir.

İlk Kaos Deneyleri Nasıl Planlanmalıdır?

İlk Kaos Deneyinin Planlanması

Kaos Mühendisliğindeki en temel sorulardan biri “Ne yanlış gidebilir ki?”‘dir. Kendi servislerimiz hakkında bu soruyu sorarak, potansiyel sistem zaafiyetlerini değerlendirebilir ve hata olması durumunda ne gibi etkilere neden olacağını tartışabiliriz. Bu durum, risk değerlendirmesine benzer şekilde hangi senaryonun önceliklendirileceğini ve ilk defa test edileceğini hakkında bilgi verir. Ekip olarak toplantı düzenleyip, servislerin bağımlılıklarını, ve veri sunan katmanların diyagramını çizerek “Ne yanlış gidebilir ki?” sorusunun resmini formüle edebilirsiniz. Eğer kararsızlık yaşarsanız, her bağımlılığınız için bir hata veya bir miktar gecikme süresi eklemek iyi bir başlangıç testi olabilir.

Hipotezin oluşturulması

Artık neyin yanlış gidebileceği hakkında fikriniz var ve sisteme enjekte edilecek uygun hatayı türünü belirlediniz. Peki ya sonra ne olacak? Bu soru, bir takım olarak çalışırken egzersiz yapmak için tartışılabilecek mükemmel bir sorudur. Senaryoyu tartışarak, hatayı yayına almadan önce oluşabilecek sonuçları hipotez edebilirsiniz. Müşterilerinize, servislerinize ve sistem bağımlılıklarınıza ne gibi bir etki olacaktır?

Etkinin Ölçülmesi

Sisteminizin baskı altında nasıl davranacağını anlamak için sisteminizin kullanılabilirliğini ve dayanıklılığını ölçmeniz gereklidir. Müşteri ile başarılı bir şekilde gerçekleştirilen olay ile ilişkili olacak biçimde temel bir performans ölçüsüne (örn. dakikada satılan ürün adedi, veya saniyede başlatılan video akış miktarına) sahip olmak iyi bir sonuç verecektir. Çünkü, müşteriye verilen servis kalitesini etkileyen bir ölçüm değerinde azalma görürseniz, anında o deneyi sonlandırmak isteyebilirsiniz. Daha sonra, hipotezinizi doğrulamak (veya yanlışlamak) için hatayı ölçümleyiniz. Buradaki ölçü kıstası servis gecikmeleri, saniyede yapılan istek sayısı, veya sistem kaynaklarının ne kadar kullanıldığı gibi değerler olabilir. Son olarak, gösterge tablolarınızı ve alarmlarınızı kontrol ederek, istenmeyen yan etkilere karşı önlem almak isteyebilirsiniz.

Hatayı Geri Alma Planının Belirlenmesi

Bir şeyler yanlış gittiğinde her zaman bir B planınızın olması gerekir. Fakat, B planının dahi işe yaramayacağı zamanlar olabilir. Bunun için ekibinizle hatanın geri alınmasını nasıl yürüteceğinizi konuşmalısınız. Eğer komut satırında elle komutları giriyorsanız, sisteminizin SSH erişimini patlatmamaya özen göstermeniz gerekir.

Gidin ve Sorunu Çözün

İlk deneyinizi gerçekleştirdikten sonra aşağıdaki iki durumdan birini tespit etmiş olacaksınız:

• Enjekte ettiğiniz hata karşısında sistem dayandı ve siz de bunu doğruladınız.
• Hata karşısında bir problem oluştu ve bunu çözmeniz gerekiyor.

Üstteki iki durum da iyi sonuç olarak değerlendirilebilir. Çünkü birinde sisteme ve sistemin davranışına güven artışı sağlamış oluyorsunuz, diğerinde ise bir kesinti yaşamadan önce ortaya çıkacak bir problemi tespit etmiş oluyorsunuz.

Sonuç olarak

Mikroservisler ve dağıtık sistemlerin yükselişi ile birlikte web uygulamalarının karmaşıklaşması neticesiyle canlı ortamda oluşabilecek hataların kestirimi güç bir hale gelebiliyor. Bu nedenle hataların önceden kestirimi için ön çalışmalar yaparak sistemi oluşabilecek hataların yol açacağı durumlar için hazırlamak gerekiyor.

Bu yazımızda sizlere Kaos Mühendisliğinin ne olduğunu, tarihini, nasıl uygulandığını ve organizasyona nasıl bir fayda sağladığından bahsettik. Bu konu hakkında görüş veya önerileriniz varsa yorum bölümünden bize yazabilirsiniz. Sonraki yazımızda görüşmek üzere.