Vebende Akademi - circuit-breaker-pattern
Uzmanla Konuşun
Blog
MAKALE

Circuit Breaker Deseni: Dayanıklı Mikroservisler için Pratik Rehber

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~40–120 dk

Circuit Breaker Deseni: Dayanıklı Mikroservisler için Pratik Rehber

Yayınlayan: Vebende Akademi  |  Okuma süresi: ~40–120 dk

1. GİRİŞ

Circuit Breaker (devre kesici) deseni, dağıtık sistemlerde bağımlılıkların geçici hatalara veya sürekli başarısızlığa maruz kaldığında tüm sistemin çökmesini engellemek için kullanılan temel bir resiliency (dayanıklılık) tekniğidir. Mikroservis mimarilerinde, bir servis diğerine yaptığı istekler sırasında gecikme, zaman aşımı veya hata durumlarıyla karşılaşabilir. Bu tür durumlarda art arda yapılan çağrılar, bağımlı servisin daha da baskılanmasına ve zincirleme arızalara yol açabilir. Circuit Breaker deseni, bu zincirlemeyi kırmaya ve sistemi stabil tutmaya yarar.

Bu konu neden konuşuluyor?

  • Hizmetler arası çağrıların artmasıyla birlikte cascading failures ve thundering herd riskleri büyüyor.
  • Bulut ve mikroservis destekli dağıtık uygulamalarda resiliency, performans ve kullanıcı deneyimi kritik hale geldi.
  • Observability, SRE yöntemleri ve chaos engineering ile test edilen sistemlerde circuit breaker sıkça uygulanıyor.

Kimler için önemli?

  • Backend geliştiriciler ve sistem mimarları
  • Platform mühendisleri, SRE ve DevOps ekipleri
  • Performans ve reliability mühendisleri

Hangi problemleri çözüyor?

  • Cascading failures'ı önler.
  • Bağımlı servislere uygulanan gereksiz yükün azalmasını sağlar.
  • Graceful degradation ve hızlı hata dönüşünü (fast fail) mümkün kılar.

2. KAVRAMSAL TEMELLER

2.1 Temel tanımlar

Circuit Breaker
Bir bağımlılık çağrısını izleyen ve devam eden hatalara göre çağrıları bloklayan veya izin veren kontrol mekanizması.
Closed State
Normal çalışma durumu: çağrılar izinli ve başarısızlık sayısı sıfırdan başlar.
Open State
Belirli bir eşik üzerindeki başarısızlık veya zaman aşımı durumunda circuit açılır; çağrılar başarısız olarak hemen döndürülür veya fallback uygulanır.
Half‑Open State
Bir bekleme süresinin (sleep window) ardından circuit sınırlı sayıda deneme çağrısına izin verir; başarısızlık yoksa circuit kapatılır, aksi halde tekrar açılır.
Fallback
Başarısız bir çağrı yerine çalıştırılan alternatif yol: cache, default cevap veya degraded functionality.

2.2 İlgili kavramlar

  • Timeout: Bağımlı servisin yanıt süresini sınırlamak
  • Retry ve Backoff: Geçici hatalarda yeniden denemelerle başarı şansını artırmak
  • Bulkhead: Kaynak izolasyonu ile bir bileşenin diğerlerini etkilemesini önleme
  • Rate limiting: Aşırı çağrı trafiğini sınırlama

3. NASIL ÇALIŞIR? — TEKNİK MİMARİ VE AKIŞ

3.1 Temel çalışma mantığı

Circuit Breaker üç ana durumda çalışır: Closed, Open ve Half‑Open. Sistemde çağrılar normalde Closed durumda yapılır. Eğer belirlenen hata eşiği (error threshold) kısa bir zaman diliminde aşılırsa, circuit Open durumuna geçer ve belirli bir süre (retry timeout veya sleep window) boyunca çağrılara izin vermez; bu süre içerisinde tüm çağrılara hızlı şekilde hata veya fallback döner. Sleep window dolduğunda, half‑open durumunda sınırlı denemeler gerçekleşir. Başarılı olursa circuit Closed durumuna döner; başarısızlık sürerse Open kalır.

3.2 Hata sayısı ve oran tabanlı eşikler

Circuit açma kararları genelde iki yaklaşımla alınır: aritmetik fail‑count (örneğin N başarısızlık) veya oran tabanlı (ör. son M çağrının %X'i başarısız). Oran tabanlı eşikler, kısa süreli spike'lara karşı daha az hassas iken count tabanlı eşikler hızlı tepki verir. Uygulama ihtiyaçlarına göre seçilmeli ve ayarlanmalıdır.

3.3 Timeout, Retry ve Backoff ile kombinasyon

Circuit Breaker genelde timeout ve retry mekanizmaları ile birlikte kullanılır. Timeout, bağımlı servisin isteği belli sürede sonuçlandırmasını bekler; retry ise geçici hatalarda yeniden deneme sağlar. Ancak retry kontrolsüzse, başarısız bir servise art arda tekrar tekrar istek göndererek yükü artırabilir; bu yüzden exponential backoff ve jitter ile birlikte kullanılmalıdır. Circuit Breaker, başarısızlıktan sonra retry davranışını sınırlayarak ek fayda sağlar.

3.4 Fallback stratejileri

Fallback mekanizmaları sistemin kullanıcıya sınırlı da olsa yanıt vermesini sağlar. Örnek fallback örnekleri: cache'den cevap döndürme, daha az özellikli alternatif servis çağrısı, kullanıcıya yalın bir hata mesajı gösterme veya isteği kuyruklayıp daha sonra işleme. Fallback, kullanıcı deneyimini korurken sistemin stabilize olmasına zaman kazandırır.

3.5 State management — local vs distributed

Circuit Breaker mantığının durumunu (state) nerede tuttuğunuz önemli bir mimari karardır. Local circuit (örneğin uygulama process içinde) hızlıdır ve basittir fakat dağıtık istemciler farklı circuit durumları görebilir. Distributed circuit (paylaşılan store — Redis, memcached veya database) merkezi karar verir ve tüm istemciler için tutarlıdır ama latency ve tutarlılık sorunları ekleyebilir. Büyük dağıtık sistemlerde hibrit yaklaşımlar veya koordinasyon protokolleri tercih edilir.

3.6 Metrics ve observability

Circuit Breaker için takip edilmesi gereken temel metrikler: failure rate, success rate, timeout count, open/half‑open/closed state sayısı, fallback invocation count ve latency histogramları. Bu metrikler operasyonel kararlar almak, eşikleri ayarlamak ve RCA (root cause analysis) için hayati önem taşır.

4. GERÇEK DÜNYA KULLANIMLARI

Netflix — Hystrix (tarihi örnek) ve resilience

Netflix'in Hystrix kütüphanesi, circuit breaker desenini popülerleştiren ve yaygınlaştıran projelerden biridir. Hystrix, çağrılar için timeouts, circuit states, fallback ve thread/bulkhead izolasyonu sağlayarak microservice ekosisteminde resiliency temel taşlarından biri olmuştur. Günümüzde Hystrix projesi bakım moduna geçmiş olsa da fikirleri ve telemetri yaklaşımı halen referans alınır.

Amazon, Stripe ve ölçeklenebilir fallback

E‑commerce ve ödeme sağlayıcıları (Amazon, Stripe) kritik path'lerde circuit breakeri kullanarak cascading failures'ı önler. Örneğin ödeme sağlayıcı herhangi bir üçüncü‑taraf fraud check servisine bağlıysa, bu servis hatalıysa ödeme akışını tamamen durdurmak yerine sınırlandırılmış bir doğrulama veya manuel onaya yönlendirme ile kullanıcı akışını koruyabilirler.

Cloud provider çözümleri ve managed services

Birçok managed API gateway (AWS API Gateway, Azure API Management) ve service mesh (Istio, Linkerd) circuit breaker benzeri işlevleri native olarak sunar. Service mesh, isteklerin yanıt süresi ve hata oranına göre routing ve circuit politikaları uygulamak için uygun altyapı sağlar.

5. AVANTAJLAR VE SINIRLAMALAR

Avantajlar

  • Cascading failures'ı önleyerek sistem stabilitesini artırır.
  • Fast fail — kullanıcıya hızlı geri dönüş sağlayarak bekletmeyi azaltır.
  • Fallback ile kullanıcı deneyimini degrade ederek korur.

Sınırlamalar

  • Yanlış eşik ve konfigürasyonlar sistemin gereğinden fazla servis reddetmesine yol açabilir (false positive).
  • Local state yaklaşımı dağıtık istemcilerde inconsistent davranış yaratır.
  • Fallback stratejileri tasarlanmadıysa kullanıcıya boş veya yanıltıcı bilgi dönebilir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

Yaklaşım Avantaj Dezavantaj
Local Circuit (in‑process) Düşük latency, basit implementasyon Dağıtık istemciler arasında state tutarsızlığı
Distributed Circuit (shared store) Tüm istemciler için tutarlı davranış Ekstra latency, store bağımlılığı ve tutarlılık gereksinimleri
Service Mesh Policy Merkezi yönetim, kademeli rollout ve telemetry Ekstra altyapı ve öğrenme eğrisi

7. EN İYİ PRATİKLER

Production kullanımı

  • Hata eşiği, sleep window ve deneme sayısı gibi parametreleri workload ile test ederek belirleyin.
  • Fallback'ı uygulama mantığı ile uyumlu ve güvenli tasarlayın; cache ve degraded feature seçeneklerini değerlendirin.
  • Service mesh veya API gateway üzerinden merkezi yönetim gerekiyorsa politikaları buradan yönetin.

Performans optimizasyonu

  • Local metric aggregation ile kısa vadeli kararlar alın, istatistikleri merkezi telemetriye gönderin.
  • Timeout değerlerini servisin p99/p95 latency hedeflerine göre ayarlayın; gereğinden uzun timeout sistem kaynaklarını bağlayabilir.

Güvenlik

  • Fallback mekanizmalarının kötü niyetli kullanımına karşı rate limiting ve authorization kontrolleri uygulayın.
  • Distributed store kullanıyorsanız erişim kontrolleri ve encryption uygulayın.

Observability

  • Failure, success, timeout ve fallback metriklerini izleyin; alert'leri SLA seviyelerine göre yapılandırın.
  • Canary ve synthetic checks ile real‑world senaryolarını düzenli test edin.

8. SIK YAPILAN HATALAR

  • Eşikleri varsayılan değerlerde bırakmak — her sistemin tolerans eşiği farklıdır.
  • Fallback'ı ihmal etmek — circuit açıldığında kullanıcıya anlamlı alternatif sunulmaması kötü deneyim yaratır.
  • Retries ve circuit kombinasyonunu yanlış ayarlamak — aşırı retry bağımlı servisi daha çok baskılar.
  • Eksik telemetry — circuit davranışını izleyememek RCA ve tuning süreçlerini engeller.

9. GELECEK TRENDLER

  1. Policy as code ve declarative resilience: Circuit politikalarının kod ve deklaratif yapı ile yönetilmesi yaygınlaşacak.
  2. AI‑assisted threshold tuning: Telemetry verisi ile otomatik olarak eşik ve timeout değerlerinin optimize edilmesi artacak.
  3. Service mesh entegrasyonlarının derinleşmesi: Istio/Linkerd gibi projeler üzerinden merkezi resilience control plane'leri güçlenecek.
  4. Edge ve IoT senaryoları: Offline ve intermittent connectivity koşullarında hafif circuit breaker ve local fallback stratejileri daha fazla kullanılacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

  1. 1. Circuit Breaker her durumda mı kullanılmalı?

    Genellikle dışa bağımlı kritik çağrılarda önerilir. Basit, düşük maliyetli internal çağrılarda fazladan karmaşıklık getirebilir. Risk ve fayda analizi yapın.

  2. 2. Local veya distributed circuit hangisi daha iyi?

    Hız ve basitlik için local; tutarlılık ve merkezi kontrol için distributed tercih edilir. Büyük sistemlerde hibrit yaklaşımlar sık kullanılır.

  3. 3. Hata eşiği nasıl belirlenir?

    Load testleri ve gerçek telemetri analizi ile hedef p95/p99 latency ve acceptable error rate belirlenerek eşiğe karar verilir.

  4. 4. Fallback için en iyi uygulamalar nelerdir?

    Cache first, degrade gracefully, kullanıcının işlemini kuyruklayıp arka planda tamamlamak gibi yöntemler tercih edilir.

  5. 5. Circuit Breaker ile retry birlikte mi kullanılmalı?

    Evet, ancak retry limitleri, exponential backoff ve jitter ile sınırlanmalı; circuit, retry ile gereğinden fazla yüklenmeyi engellemelidir.

  6. 6. Service mesh olmadan circuit nasıl uygulanır?

    Uygulama seviyesinde kütüphaneler (resilience4j, Polly, Hystrix) ile veya API gateway üzerinden uygulanabilir.

  7. 7. Telemetry için hangi metrikler kritik?

    Failure rate, timeout count, latency percentiles, fallback invocations ve circuit state change event'leri takip edilmelidir.

  8. 8. Circuit Breaker testleri nasıl yapılır?

    Chaos engineering, fault injection, synthetic latency ve error simulation ile circuit davranışı test edilmelidir.

Anahtar Kavramlar

Circuit Breaker
Bağımlı çağrıları izleyip hatalara göre engelleyen kontrol deseni.
Fallback
Başarısız çağrılarda uygulanan alternatif yol.
Half‑Open
Açık devre sonrası deneme durumunu temsil eden ara durum.
Bulkhead
Kaynak izolasyonu ile hata yayılımını engelleyen desen.
Hystrix / Resilience4j / Polly
Farklı platformlarda circuit breaker ve resiliency sağlayan kütüphaneler.

Öğrenme Yol Haritası

  1. 0–1 ay: Retry, timeout ve temel resiliency kavramlarını öğrenin; küçük bir bağımlı çağrıda circuit implementasyonu yapın.
  2. 1–3 ay: Hystrix, Resilience4j veya Polly gibi kütüphaneleri inceleyin; fallback ve backoff stratejileri uygulayın.
  3. 3–6 ay: Distributed store ile circuit durum yönetimi, service mesh entegrasyonu ve telemetry toplama deneyimi kazanın.
  4. 6–12 ay: Chaos engineering ile production‑benzeri ortamda circuit tuning ve operasyonel playbook geliştirin.