Hystrix Circuit Breaker Configuration

Bu yazımızda daha önce detayından bahsettiğimiz Hystrix circuit breaker patterninin konfigürasyon değerlerinin nasıl ayarlanması gerektiğini inceleyeceğiz ve karşılaştığımız önemli noktaları paylaşacağız. Öncelikle circuit breaker yaklaşımının işlevini gerçekleştirebilmesi için dikkate aldığı 3 temel config değerine bakalım;

• Request Volume Threshold
• Sleep Window In Milliseconds
• Error Threshold Percentage

1. Request Volume Threshold

Circuit breakerın uygulanabilmesi için sleep window configinde belirlenen süre içerisinde geçmesi beklenen minimum istek sayısıdır. Örneğin sleep window değerimiz 3000 ms olsun. 3 saniye aralığı içerisinde minimum bu değere ulaşıldığında, hesaplanan hata oranı ile birlikte gelmeye devam eden isteklerin kabul veya reddedilmesi belirlenecektir. Minimum değerin üzerinde çıkan istek sayısı dikkate alınarak her gelen istek sonrası hata oranı tekrardan hesaplanır ve gelen isteklerin akıbetine karar verilir. Varsayılan değeri 20 olarak belirlenmiştir.

2. Error Threshold Percentage

Sleep window süresi içinde minimum istek sayısına ulaştığımızda veya aştığımızda yeni gelen isteklerin (sleep window içerisinde) kabul edilmesini veya reddedilmesini belirleme amacıyla konulan yüzdelik değerdir. Örneğin 3 saniye içerisinde 25 istek geldiyse, bu isteklerin hata oranı, belirlediğimiz hata oranına ulaşırsa devre açık konuma geçecek ve yine “sleep window“ süresince istek kabul etmeyecektir. Varsayılan yüzdelik değer 50 olarak belirlenmiştir.

3. Sleep Window In Milliseconds

Gelen requestlerin değerlendirildiği değer aralığı diyebiliriz. Sleep Window değeri aralığında gelen requestler inceleniyor ve circuit breaker’ın açılıp kapanması belirleniyor. Milisaniye cinsindendir ve varsayılan değeri 20'dir. Bu değerin fazla tutulmaması öneriliyor. Sebebi ise eğer uygulamanın devre açık pozisyonuna geçmesi halinde, bu süre kadar istek kabul etmeyecek olmasıdır.

4. Use Case

Bir önceki yazımızda, command keylerin dinamik olarak yönetilebildiğinden bahsetmiştik. Örnek bir mimariden bahsedecek olursak, gelen tüm istekler bir api gateway’den geçerek bir başka uygulamaya gelir ve buradan ilgili mikro servislere istek gönderilir. Tüm isteklerin bir uygulamadan geçmesinin faydaları yanında tehlikeli yanları da yok değil. Örneğin bu uygulamanın erişilemez olması veya herhangi bir mikro servisin timeout alarak tüm threadleri tutması ve çalışan diğer mikro servislere erişime engel olması gibi. Bu sebeple ekip olarak bu uygulamanın resilince patternler ile desteklenmesi konusunda hem fikir kaldık. Amacımız herhangi bir mikro servisin yoğunluk yaşaması nedeniyle diğer mikro servislerin etkilenmemesini sağlamak (bulkhead) ve herhangi bir hata olduğunda circuit breaker patternlerini devreye sokup isteklerin daha fazla yoğunluk yaratmasını engellemek.

Hystrix’i entegre ettikten sonra konfigürasyonlarının nasıl yapılması gerektiği konusunda kararsızdık. Konuyla alakalı çok fazla doyurucu bilgi bulamamakla birlikte optimizasyonun servisleri gözlemleyerek yapılması kararını aldık. Uygulamayı düşündüğümüz pilot mikro servisler için command keyler oluşturarak ilgili configleri, gelen log isteklerin frekanslarına bakarak ayarlamaya çalıştık.

Sistemi hayata geçirdiğimizde karşılaştığımız problemlerden biri request volume threshold değerini eksik anlamak oldu. Bu değeri, son yapılan ve değerlendirilecek istek sayısı olarak algıladık. Örneğin son 200 istekte %50 den fazla hata oranı olur ise devre açılsın şeklinde bir anlam yüklemiştik. Ancak bu değerin sleep window değeri içinde olması gibi bir detayı atlayınca canlı ortamda hiç devrenin açılmadığını gördük. Sonrasında bu değerin aslında sleep window değeri ile paralellik içermesi gerektiğini anladık. Burada yapılması gereken, mikro servise gelen istek sayılarının (req/sn) ortalamasının çıkartılması buna göre de sleep window ve request volume threshold değerinin ayarlanması. Örneğin saniyede ortalama 20 istek geliyor ise sleep window değerini 3 sn yapıp request volume threshold değerini 30–50 arası belirlemek mantıklı olabilir.

5. Sonuç

Config değerlerin ne kadar agresif olacağı tamamen size bağlı. Ne kadar hata oranını aşağı çekerseniz o kadar sıkı ve hata kabul etmeyen bir davranış şeklini benimsemiş olursunuz. Çok yoğun istek alan ve önemli bir uygulama ise sleep window değerini çok tutmamakta fayda var. Devreyi açtığımızda, uygulama sleep window süresi kadar erişilemez olacaktır. Ama tabii ki bir sorun var ise gelen tüm isteklerin sistemin dışında tutulması da avantaj olarak görülebilir.

Canlı ortama geçtikten sonra hystrix dashboard yardımıyla command keylerin ne durumda olduklarını gözlemlemek ve hata durumlarında circuit breakerın çalışıp çalışmadığını kontrol etmek faydalı olur. Yapılan gözlemler ışığında config değerleri dinamik olarak değiştirilerek optimum hale getirilebilir.

Optimum hale getirildiği düşünülen değerlerin, her devre açıldığında panikle kapatmaya yönelik config güncellemelerinden kaçınmak gerekiyor. Zira bu kütüphanenin yapmaya çalıştığı şey bir problem olduğunda sistemi güvence altına alması.

Teşekkürler