Bilmek Gereken Üç Hata Kavramı
Hoş Geldiniz
Dağıtık sistemler kalıplar halinde hata verir. Kalıpları öğrendiğinizde, her olay sonrası inceleme bir gizem yerine bir tanıma egzersizine dönüşür.
Üretim ortamındaki hata analizinde önemli olanların çoğunu kapsayan üç kavram vardır:
Tek nokta arızası (SPOF): Arızası durumunda daha büyük bir sistemi devre dışı bırakan bir bileşen. Genellikle gizlidir: Herkesin bağımlı olduğu DNS sunucusu; her şeyin yenileme yaptığı sertifika; tek veritabanı ana sunucusu (master).
Kademeli hata (Cascading failure): Bir bileşenin arızası diğerini, o da başka birini tetikler. Yavaş bir veritabanı, API katmanında zaman aşımına (timeout) neden olur; bu da yeniden denemeleri (retry) tetikler, bu yeniden denemeler veritabanını daha da yükler ve bu da daha fazla zaman aşımına yol açar. Etki alanı yayılır.
Etki yarıçapı (Blast radius): Bir parça arızalandığında sistemin ne kadarının devre dışı kaldığı. Mimari seçimler, bu yarıçapı ya sınırlar ya da sınırsız bırakır. Tek nokta arızası (SPOF) sınırsız bir etki yarıçapına sahiptir. Bölme (bulkhead) uygulanan bir servisin ise sınırlı bir yarıçapı vardır.
Bu dersin sonunda şunları yapabileceksiniz:
- Bir mimarideki SPOF'ları (Tek Nokta Arızası) inceleme yoluyla belirlemek
- Kademeli hata kalıplarını tanımlamak: gürültülü sürü (thundering herd), yeniden deneme fırtınası (retry storm), ölüm kuyruğu (queue of death)
- Gerçek bir zaman çizelgesini okumak ve tetikleyiciyi, bu tetikleyicinin ortaya çıkardığı gizli kusurdan ayırt etmek
- İnsanları değil sistemleri hedefleyen, önleme / algılama / kurtarma süreçlerini kapsayan suçlamasız (blameless) aksiyon maddeleri yazmak
- Bölme (bulkhead) ve devre kesicileri (circuit breaker) etki yarıçapını sınırlayan araçlar olarak değerlendirmek
Tek Nokta Hatasını (Single Point of Failure) Bul
Katmanlı Mimari Denetimi
Küçük bir web mimarisini ele alalım:
- DNS: api.example.com -> tek bir DNS sağlayıcısı tarafından barındırılan tek bir isim sunucusu IP'si 203.0.113.10
- CDN: api.example.com önünde tek bir CDN tedarikçisi
- Giriş (Ingress): Yükleme dengeleyicisinin (load balancer) arkasında iki adet ters yönlendirici (reverse proxy) makinesi
- Arka Uç (Backend): İki kullanılabilirlik bölgesinde (availability zone) altı adet API replikası (bölge başına üç)
- Veritabanı: Aynı kullanılabilirlik bölgesinde birincil (primary) bir veritabanı + bir okuma replikası (read replica)
- Önbellek: Redis kümesi, aynı iki kullanılabilirlik bölgesine yayılmış üç düğüm
Soru: Hangi bileşenler SPOF'lardır? İpucu: SPOF'lar her zaman bariz 'tek makine' türü değildir. Tek bir kullanılabilirlik bölgesindeki üç makineden oluşan bir küme, o bölgenin arızası için bir SPOF'tur.
Üç Klasik Kademeli Desen
Hatalar Bağımlılıklar Arasında Yayılır
Desen 1: Gürültülü sürü (Thundering herd). Ortak bir kaynak (önbellek, kilit, veritabanı) başarısız olur veya yeniden başlatılır. Bu kaynağa bağımlı olan tüm istemciler aynı anda yeniden denemede bulunur. Bu akın, ayağa kalkan her şeyi ezerek boğar; yeniden denemeler, kurtarma sürecinin onları emme hızından daha hızlı bir şekilde birikir; kurtarma asla tamamlanmaz.
Desen 2: Yeniden deneme fırtınası (Retry storm). Aşağı akıştaki (downstream) bir yavaşlar. Yukarı akıştaki (upstream) çağıranlar, hata vermek yerine yeniden denemede bulunur. Yeniden denemeler, orijinal yükü katlar. Yavaşlayan servis daha da yavaşlar, bu da daha fazla yeniden denemeye yol açar. Sonunda yük, servisin sağlıklı bir versiyonunu bile aşar.
Desen 3: Ölüm kuyruğu (Queue of death). Geri baskı (backpressure) mekanizması olmayan bir işleme kuyruğu, işlediğinden daha hızlı veri alır. Kuyruk sınırsız şekilde büyür. Bellek tükenir; tüketici çöker; yeniden başlar; hâlâ daha büyük bir kuyrukla karşılaşır; tekrar çöker.
Ortak payda: Küçük bir başlangıç sapması, pozitif geri besleme döngüsünü tetikler. Sistemin kendi tepkisi, hatayı sönümlemek yerine onu büyütür.
Sönümleme Mekanizmaları
Jitter (rastgele gecikme) eklenmiş üstel geri çekilme (exponential backoff). Yeniden deneme yapan istemciler, her seferinde daha uzun süre bekler ve rastgele bir ofset eklenir. Bu, senkronize yeniden deneme dalgalarını önler.
Devre kesici (Circuit breaker). Çağıran taraf, aşağı akıştaki (downstream) hata oranını izler. Belirli bir eşiğin aşılması durumunda, çağıran taraf bir soğuma süresi boyunca çağrı yapmayı durdurur ve bunun yerine kendi isteklerini anında başarısız olarak işaretler. Bu, boşa iş harcanmasını önler ve aşağı akıştaki sistemin toparlanmasına izin verir.
Bulkhead (Havuz izolasyonu). Kaynakları bağımlılıklara göre izole edin. Veritabanı için A bağlantı havuzu, önbellek için ayrı bir B bağlantı havuzu kullanın. Yavaş bir veritabanı tüm bağlantıları açlığa (starvation) sürükleyemez; önbellek çağrıları devam eder.
Yük atma (Load shedding). Aşırı yüklendiğinde, istekleri kabul edip yavaşça başarısız olmak yerine kenarda (edge) düşürün. 1 ms içinde gelen bir 429 yanıtı, 30 saniye içinde gelen bir 500 yanıtından daha iyidir.
Ters basınç (Backpressure). Tüketiciler yetişemiyorsa üreticileri yavaşlatın. Kuyruklar sınırlı hale gelir; gönderenler bloklanır; işin orijinal kaynağı bu sürtünmeyi hisseder.
Kademeli Hatanın Teşhisi
Bir ekibin API katmanı, rutin bir veritabanı devre dışı bırakma (failover) sırasında çöker. Zaman çizelgesi:
- 14:00:00 — operatör yedek veritabanını (standby) ana veritabanı olarak tanımlar (promote). Beklenen erişilemezlik süresi: ~10 saniye.
- 14:00:08 — ana veritabanı (primary) erişilemez hale gelir. API katmanı istekleri veritabanı bağlantı hatalarıyla başarısız olmaya başlar.
- 14:00:08 — API katmanı yeniden denemeler yapar (varsayılan yapılandırma: 5 yeniden deneme, geri çekilme yok, 100 ms aralıklarla).
- 14:00:11 — yedek veritabanı (standby) ana veritabanı olarak tanımlanır (promote), yeni bağlantıları kabul etmeye başlar.
- 14:00:11 — API katmanı, aynı anda binlerce yeni veritabanı bağlantısı açar (her replika × her eşzamanlı istek × her yeniden deneme).
- 14:00:13 — yeni ana veritabanının (primary) bağlantı havuzu (connection pool) tükenir; yeni bağlantılar reddedilir.
- 14:00:13-14:05:00 — API katmanı replikaları bağlantı havuzlarını (connection pool) tüketir, istisna fırlatır, çöker, yeniden başlar ve bu döngü tekrarlar.
- 14:05:00 — operatör API katmanı trafiğini manuel olarak durdurur; veritabanı kararlı hale gelir.
- 14:10:00 — kademeli trafik geri yüklemesi tamamlandı. Toplam kesinti: ~10 dakika (beklenen ~10 saniyeye kıyasla).
DNS SERVFAIL: Birbirini Tetikleyen İki Hata
Gerçek Bir Olay Analizi (Postmortem)
Aşağıda, gerçek bir olayın sansürlenmiş (detayları gizlenmiş) versiyonu yer almaktadır. Tedarikçi adları değiştirilmiş, IP adresleri anonimleştirilmiştir; ancak olayın yapısı, zaman çizelgesi ve dersler gerçektir.
Özet
example.com alan adı, yaklaşık 3-4 saat boyunca tüm halka açık DNS çözümleyicilerden SERVFAIL yanıtı döndürdü. Aynı DNS ana sunucusundaki diğer 46 alan adı etkilenmedi. Kök neden: Birbirini tetikleyen iki hata.
1. Tedarikçi A (ikincil DNS sağlayıcısı), birincil sunucunun allow-axfr-ips izin listesine eklenmemiş yeni bir dahili senkronizasyon IP'si ekledi.
2. example.com alan adı, yıllardır süregelen ve RFC'ye aykırı bir CNAME çakışması içeriyordu (demo.example.com etiketinde hem CNAME hem de MX/TXT kayıtları bulunuyordu); bu durum, Tedarikçi A'nın taze AXFR sırasında alan adını reddetmesine neden oldu.
Zaman Çizelgesi (UTC)
- ~15:00 — Vendor A, altyapılarına yeni senkronizasyon IP'si 198.51.100.42 ekler
- 15:02 — 198.51.100.42 için ilk AXFR-out denied ana DNS günlüklerinde görünür (bu sinyal için uyarı yok)
- ~18:00 — SOA süresi dolma penceresine ulaşıldı; Vendor A, example.com bölgesini önbellekten düşürür
- ~18:30 — Dışarıdan SERVFAIL tespit edildi
- ~19:45 — Kök neden belirlendi
- 20:00 — 198.51.100.42, allow-axfr-ips listesine eklendi; ana sunucu yeniden başlatıldı
- 20:05 — NOTIFY gönderildi; AXFR başlatıldı; bölge HÂLÂ SERVFAIL (CNAME çakışması)
- 20:07 — check-zone, 1 hatayı ortaya çıkarıyor: demo.example.com üzerinde CNAME çakışması
- 20:09 — CNAME, A kaydı ile değiştirildi; bölge kontrolü temiz (0 hata)
- 20:10 — NOTIFY gönderildi; AXFR tamamlandı; Satıcı A bölgeyi sunmaya başladı
- 20:11 — dig @8.8.8.8 example.com A doğru IP'yi döndürüyor — ÇÖZÜLDÜ
Neden Sadece example.com?
Tüm 47 bölge aynı DNS birincilini (primary) paylaşıyor. AXFR IP engeli tüm bölgeleri etkiledi. Ancak yalnızca example.com'da CNAME çakışması vardı & yalnızca example.com için, engellene (deny) uygulandığı anda taze bir AXFR'ye ihtiyaç duyuluyordu. Diğer bölgeler, engellenmeden önce zaten yenilenmişti veya henüz buna ihtiyaç duymuyorlardı.
Gizli kusur
demo.example.com adresindeki CNAME çakışması yıllardır mevcuttu. Birincil (primary), bölgeyi veritabanından sunduğu için (RFC ihlallerine karşı hoşgörülü) & Satıcı A, ihlal girilmeden önceki eski önbellek verilerinden sunduğu için çalışıyordu. Satıcı A önbelleğini düşürdüğünde & taze veriye ihtiyaç duyduğunda, ihlal ortaya çıktı.
Tetikleyici
Tedarikçi A sessizce yeni bir senkronizasyon IP'si ekledi. Birincil izin listesi bu IP'yi içermedi. AXFR reddedildi. Üç saat sonra (SOA süresi dolunca), Tedarikçi A bölgeyi (zone) düşürdü. Latent kusur, sistem kurtarma işlemi yapmaya çalıştığında ortaya çıktı.
Suçlamasız Eylem Maddelerini Yazın
Suçlamasız: Hedef Sistemler, Kişiler Değil
Suçlamasız bir eylem maddesi, bir kişinin farklı bir şey yapması gerektiğini değil, sistemin farklı bir şey yapması gerektiğini belirtir. 'Operatörü eğitin' suçlayıcıdır. 'Bunu dağıtım öncesinde yakalayan otomatik bir kontrol ekleyin' suçlamasızdır.
İyi suçlamasız eylem maddeleri üç boyuta kümelenir:
- Önleme: Kötü şeyi daha zor veya imkânsız hale getirin
- Algılama: Olursa daha erken fark edin
- Kurtarma: Olursa hasarı sınırlayın
Her madde (1) belirli sistem değişikliğini, (2) sorumlu ekibi ve (3) hizmet ettiği boyutu belirtmelidir.
Geminin Batmadan Suya Gömülen Bölümleri
Denizcilik Mühendisliğinden Alınan
Gemi gövdesinde su geçirmez bölmeler (bulkhead) bulunur: gövdeyi bölümlere ayıran dikey duvarlar. Bir bölme su alsa bile gemi batmaz; bir diğerinin arızalanması, kalan bölümleri etkilemez.
Dağıtık sistemler de aynı kelimeyi ve aynı fikri ödünç alır.
Bulkhead (Bölme) deseni: Kaynakları bağımlılıklara göre izole edin. Üç farklı aşağı akış (downstream) API'sine çağrı yapan bir servis, üç ayrı bağlantı havuzu, üç ayrı iş parçacığı havuzu ve üç ayrı yeniden deneme bütçesi kullanır. Yavaş veya arızalı bir aşağı akış, diğer iki bağımlılık için ayrılmış kaynakları tüketemez.
Bulkhead olmadan: Yavaş bir bağımlılık, paylaşılan iş parçacığı havuzunu tüketir; diğer bağımlılıklara yapılan çağrılar, iş parçacığı boşalmasını bekleyerek bloke olur; tüm servis yanıt veremez hale gelir.
Bulkhead ile: Yavaş bir bağımlılık, kendi havuzunu tüketir; ona yapılan çağrılar hızlıca hata döndürür (fail fast); diğer bağımlılıklara yapılan çağrılar normal şekilde devam eder; hasar alanı (blast radius), arızalı bağımlılıkla sınırlı kalır.
Sigorta Kesiciler
Devre kesici deseni (Circuit breaker pattern): Hata oranını izleyen, aşağı akış (downstream) bağımlılığının etrafındaki durumlu bir sarmalayıcıdır. Üç durumu vardır:
- Kapalı (normal): Çağrılar geçer. Hatalar sayılır.
- Açık (tetiklenmiş): Bir hata eşiğinin aşılması durumunda (örneğin, son 30 saniyede %50 hata), devre kesici açılır. Çağrılar bağımlılığa denemeden anında başarısız olur. Bu, çağıran tarafın işi boşa harcamasını önler; ayrıca bağımlılığın sağlıksız olduğu sırada yük almamasını sağlar.
- Yarı-açık (test): Bir soğuma süresinin ardından, devre kesici çağrıların küçük bir kısmını geçirmeye izin verir. Başarılı olurlarsa, normale dönmek üzere kapanır. Başarısız olurlarsa, başka bir soğuma süresi için yeniden açılır.
Temel içgörü: Devre kesici, bilinen sağlıksız dönemlerde boşa çabayı önler ve aşağı akışın sürekli yük altında kalmadan toparlanma şansı verir.
Bulkhead'lar (hücresel izolasyon) patlama yarıçapını sınırlar. Devre kesiciler patlamanın kendini sürdürmesini engeller.
Patlama Yarıçapını Sınırlayın
API hizmetiniz dört aşağı akış hizmetini çağırıyor: Kullanıcı Hizmeti, Öneri Hizmeti, Bildirim Hizmeti ve üçüncü taraf Ödeme API'si. Ekip, 'Öneri Hizmeti biraz kararsız çalışıyor' duyumunu aldı ve hata verdiğinde sistemin geri kalanının sağlıklı kalmasını sağlamak istiyor.
Bugün servis, 200 iş parçacığından oluşan tek bir paylaşımlı iş parçacığı havuzu ve tek bir paylaşımlı HTTP bağlantı havuzu kullanıyor. Dört aşağı akış (downstream) bu kaynaklar için yarışıyor. Hiçbir devre kesici (circuit breaker) yok.
Hata Modu İncelemesi Tasarlayın
Sentez
Tek noktadan arıza (SPOF) durumlarını inceleme yoluyla tespit etmeyi, kademeli hata kalıplarını tanımayı, bir sonradan inceleme (postmortem) okurken tetikleyiciyi gizli kusurdan ayırt etmeyi, önleme / algılama / kurtarma boyutlarında suçlayıcı olmayan aksiyon maddeleri yazmayı ve patlama yarıçapını (blast radius) bulkhead + devre kesici (circuit breaker) + zarif bozulma (graceful degradation) ile sınırlamayı öğrendiniz.
Beşinin tamamını uygulayın.
Ekip, üç aşağı akış servisine bağımlı olan yeni bir search.example.com servisini yayına almayı planlıyor: birincil arama indeksi (index.example.com), bir analitik servisi (analytics.example.com) ve bir öneri servisi (recs.example.com). Ekip, yayına geçmeden önce bir 'hata modu incelemesi' (failure-mode review) yapmanızı istiyor.
Bu Ders Nereye Gidiyor?
Bu Ders Nereye Gidiyor?
Artık bir SPOF'ı tespit edebilir, bir kaskadı tanıyabilir, bir sonradan inceleme raporunu üretken bir şekilde okuyabilir, suçlamasız eylem maddeleri yazabilir ve patlama yarıçapını tasarım yoluyla sınırlayabilirsiniz.
Bu dersin son dersi (cs_distsys_observability_and_capacity), kullanıcıların fark etmesinden önce bir sorunun olduğunu öğrenmeniz için neyin ölçülmesi gerektiğini öğretir. Sağlık kontrolleri, sürüm uç noktaları, bir proxy katmanında dört altın sinyal ve ani kapasite kararlarının gözlemlenen verilere nasıl geri bağlandığı.
Eşlikçi ders: geometry_of_failure_modes_and_blast_radius aralık merkeziliğini (grafik düğümünün hangisinin darboğaz olduğu) ve min-cut'u (patlama yarıçapının sınırı) türetir.
İyi iş. Yola devam.