Elasticsearch’ün Kaos’unda Mühendislik

Photo by Angel Luciano on Unsplash

Monolitik yapıların yerini microservice’lere bırakmaya başlamasının elbette artıları olduğu kadar eksileri de var. Bu yapıların şüphesiz en büyük artısı modüler yapılarıyla gelen yönetim kolaylığıyken, diğer taraftan birbirine bağımlı birçok servisin oluşturduğu bu dağıtık yapılarda beklenmedik bir hata durumunda ne olacağını bulmanın zorlaşmış olması da önemli bir eksidir.

Daha iyi bölünmüş, daha iyi finanse edilen, daha iyi teknolojiler kullanılan ekiplerde düz mantıkla baktığımızda daha az “down time” (kesinti/çökme süresi) durumunun yaşanmasını beklesek de, veriler tüm iyileştirmelere rağmen hala çok büyük şirketlerde uzun kesintilerin olabileceğini gösteriyor. Nerede, ne süreli kesintiler meydana geliyor merak edenler Outage.Report üzerinden inceleyebilir.

Hizmet verdiğiniz bir servis için şüphesiz en önemli iki kriterden biri sistemin yavaş yanıt vermemesi veya down olmamasıdır. Servisin hizmet vermemesi bazen sistemin kendisi bazen de bağlı olduğu iç/dış diğer teknolojilerden kaynaklanabilir. Kendi servislerimiz için performans testi koşarak sistemin hangi yük altında ne sürede yanıt verdiğini, yeni geliştirmelerle sistemin ne hale geldiğini görebiliyoruz. Ayrıca performans testlerde sistemin kaldıracağı maksimum yük miktarını da gördüğümüzden, hizmet veremeyeceğimiz TP (throughput/yük) seviyesini de belirleyip sistemde performans iyileştirmeleri yapabiliyoruz.

Diğer yandan kendi servisimiz olmayan fakat servisimizin bağlı olduğu dış kaynaklardan oluşabilecek kesinti durumlarını minimize etmek gerekliliğini de kaos test ile çözüyoruz. Kaos mühendisliği, kaos testi, kaos deneyleri gibi terimler ilk olarak Netflix’le ortaya çıkıyor ve Netflix bunun için bazı otomasyon araçları (Chaos Monkey, Simian Army, Latency Monkey, Chaos Gorilla) geliştiriyor.

En kaba tabirle kaos test dediğimiz şey aslında “kaos” olarak nitelendirebileceğimiz ortamları kendi kendimize yaratmaktır ve amacı olası bir sıkıntı durumunda minimum kesinti süresi için ne yapılması gerektiğini önden belirleyebilmektir. Bu testler bizler için tıpkı F1’da pit-stop’a giren aracın lastiklerinin hızla değiştirilmesi gibi bir aksiyon planımızın olmasını sağlıyor. Bir incident olduğunda bazen 1–2 saatte ürettiğimiz çözümü aynı incident tekrar yaşandığında daha kısa sürede çözüyoruz çünkü denk geldiğimiz bir sorun kas hafızamıza yerleşiyor. Kaos test ise bize o incident’ı yaşamadan da kısa sürede sistemi ayağa kaldırabilme şansı veriyor.

Peki nelere kaos test yapmak gerekiyor derseniz, şüphesiz servisimizin bağlı olduğu her şeye (databases, other services, message queue..) derim. Ayrıca not geçmekte fayda var: Yazının başında dağıtık sistemler dedik fakat kaos test koşacağınız ortamın dağıtık olmasına gerek yoktur.

https://github.com/chaos-eng/chaos-eng.github.io/pull/23/files

Genel olarak giriş yaptığımıza göre artık bu yazıda spesifik olarak bahsetmek istediğim database olarak kullanılan Elasticsearch üzerinde uygulanabilecek kaos durumları ve backup planlarından devam edebiliriz. Yine temelden başlayalım.

Bir kaos test yapacaksanız ilk yapmanız gereken şey sistemin sabit durumunu tanımlamaktır. Sonrasında fake hata senaryoları oluşturup bunları gerçekleştirebiliriz. Büyüklerimizin de dediği gibi;

Only production is production

Yani testlerimizi production’da, buna imkan yoksa production’a en yakın ortamda simüle etmemiz gerekir. Bence kaos testin en kritik kanunu budur.

Diğer önemli konu ise teste başlamadan önce bir problem anında en hızlı şekilde geriye dönebilmek için backup planlarınızın olmasıdır.

Eğer test koşacağınız sistem, production’da birden fazla cluster’da olan bir API ise, bir cluster’ı yayından alıp o cluster’a yük vererek fake hataları denemek en sağlıklı yöntem oluyor. Fakat production’da tek cluster’ınız varsa bu kaos durumlarını denemek için production benzeri bir ortam kurmanız gerekiyor.

ES özelinde ne tip hatalar yaşanabilir diye düşündüğümde index data hataları, index & alias değişiklikleri, node & cluster değişiklikleri şeklinde 3 ana başlığa ayırmak doğru olabilir. Şimdi tek tek burada oluşturabileceğimiz kaotik durumlara bakalım.

1. Index & Alias Değişiklikleri

Servis; X index’ine ve A alias’ına bakıyorken ES üzerinde tek index varsa;

• Güncel bir index’te (X) doğru alias (A) var -> normal durum, bir problem yaşanmaz.
• Güncel bir index’te (X) 2 alias (A ve B) var -> olması gereken alias (A) zaten olduğu için, ekstra B’nin de olması bir problem yaratmaz
• Güncel bir index’te (X) yanlış alias (B) var -> servis hata almaya başlar. BACKUP PLAN: ilk önce doğru alias’ı (A) da eklemek, sonra yanlışı (B) silmek
• Güncel bir index’te (X) alias yok -> servis hata almaya başlar.
  BACKUP PLAN: indexe doğru alias’ı (A) eklemek.

Servis; Y index’ine ve A alias’ına bakıyorken ES üzerinde çift index (X ve Y) var;

• Eski index (X) ve güncel index (Y) varken alias (A) güncel index’te (Y) ise -> normal durum, bir problem yaşanmaz.
• Eski index (X) ve güncel index (Y) varken alias (A) eski index’te (X) kalırsa -> Servis hata almaz fakat veriler eksik/yanlış gösterilebilir.
  BACKUP PLAN: güncel index’e (Y) alias’ı eklemek (A) ve sonra eski index’teki (X) alias’ı (A) silmek.
• Eski index (X) ve güncel index (Y) varken alias her iki index’te (X ve Y) de varsa -> Hatalar artar fakat servis çalışmaya devam eder.
  BACKUP PLAN: eski index’teki (X) alias’ı (A) silmek.
• Eski index (X) ve güncel index (Y) varken hiçbirinde alias yoksa -> Servis hata almaya başlar.
  BACKUP PLAN: güncel index’e (Y) yeni alias’ı (A) eklemek.

Yeni index & yeni alias durumları;

• Yeni index’te yeni alias varsa ve yeni API daha deploy olmadıysa -> normal durum. API daha çıkmadığı için problem yaratmıyor.
• Yeni index’te alias yoksa ve yeni API deploy olduysa -> servis hata almaya başlar.
  BACKUP PLAN: son index’e yeni alias’ı eklemek.
• Yeni index oluşturulmadan yeni bir API deploy olduysa -> Servis hata almaya başlar.
  BACKUP PLAN: deployment’ı geri almak. (bir önceki deployment’ı çalıştırıp, yeni deployment’ı durdurmak)

2. Index & Data Durumları

Index boşken;

• Servis hata almaya başlıyor. Data basan deployment çalışıyorsa index dolmaya ve hatalar düşmeye başlar.
  BACKUP PLAN: Data basan deployment çalışmıyorsa güncel indexe bir deployment başlatmak. Data deployment’ı çalışıyorsa sağlıklı data generate edilebilir.

Index yanlış data ile doluyken;

• Servis hata almaya başlar.
  BACKUP PLAN: eski index varsa, ona alias yapmak ve güncel indexe data basan deployment başlatmak.

Index eksik data ile doluyken;

• Servis hata almaz. Client’a eksik data gönderilmiş olur.
  BACKUP PLAN: Data basan deployment’ı tekrar güncel index’le çalıştırmak.

Index’te hatalı setting & mapping varken;

• Servis tüm isteklerde hata alır.
  BACKUP PLAN: index’i silip baştan besletmek veya elimizde doğru mapping&setting varsa index’i doğruları ile editlemek.

3. Node & Cluster Değişiklikleri

İki ES cluster’ının bir cluster’ında hata var diğerinde hata yoksa;

• BACKUP PLAN: Hatalı cluster yayından alınabilir. API’ın baktığı elastic cluster’ından hatalı olan silinip deploy edilebilir. Hatalı cluster’a düzgün cluster’dan data basılabilir.

Cluster’daki bir data node’u öldürürsek;

• API çok kısa süre o node’a gidemez ama sonra toparlar. ES üzerinde ise status yellow olur ve o node offline görünür. 3 data node yerine 2 data node’lu çalışıyor gibi performans gösterir. Node tekrar aktif olduğunda yine çok kısa süre o node’a yayılmaya çalışır. ES status green’e döner ve ilgili node tekrar aktifleşir.

Cluster’daki tüm (3 tane) data node’ları öldürürsek;

• Bütün veriler gittiği için, Kibana da gider, herhangi bir şey monitor edilemez hale gelir. Bir süre sonra read time outlar gelmeye başlar.
  BACKUP PLAN: Hatalı cluster yayından alınır veya API düzgün çalışan elastic cluster’ına baktırılır.

Cluster’daki bir master node’u kapatırsak;

• Herhangi bir değişikliğe sebep olmaz. Yalnızca ES tarafında master node offline olur. ES status’u green kalmaya devam eder, geri kalan 2 master node’dan bir tanesi (master nodeX) ES’in kendi seçimiyle yeni master node olur. Kapattığımız master node’u (nodeZ) tekrar aktif ettiğimizde, yeni master olmaz ve ES’in atadığı master (nodeX) master olmaya devam eder.

Cluster’daki tüm master node’ları kapatırsak;

• Data node’lara ulaşılabilir ama master node’lar gidik, Kibana erişilemez halde olur. ES red status’tedir. API yine rps’te maksimum failure seviyeye ulaşır (tıpkı tüm data node’ları kapattığımızdaki gibi). Burada genel yaklaşım data node’ları kontrol ederiz fakat master node’lar giderse data node’ların da bir değeri kalmadığı için alert basmak gerekir. Tüm master node’lar kapanıp açıldığında, master nodeZ tekrar master olur.
  BACKUP PLAN: Hatalı cluster yayından alırız veya API’ı düzgün çalışan elastic cluster’ına baktırırız.

ES cluster’ını komple kapatırsak;

• Tüm data node’ları veya master node’ları kapatmakla aynı sonucu verir. ES status red, API maksimum failure.
  BACKUP PLAN: Hatalı cluster’ı yayından alırız veya API’ı düzgün çalışan es cluster’ına baktırırız.

Sonuç olarak, eğer database olarak Elasticsearch kullanıyorsanız, yukarıda bahsettiğim kaotik durumlar için siz de aynı backup planları kullanabilir veya aynı durumları test edebilirsiniz. Ayrıca söylemekte fayda var, bu durumların hiçbiri veri kaybına veya yeniden kurulum gerekliliğine yol açmıyor. Umarım faydalı bir yazı olmuştur. Yorumlarınızı bekliyorum. Bu arada yazıyı beğendiyseniz alkış ile beni haberdar edebilirsiniz. 🤘🏻

Önceki Yazım ->
Sonraki Yazım ->