Gecikme, Trafik, Hatalar, Doygunluk

Dört Sayı İşletmenin Çoğunu Kapsar

Google SRE kitabından. Her hizmet katmanında ölçtüğünüz dört sinyal. Bu dört sinyali iyi bir şekilde enstrümanlarsanız, kullanıcılar fark etmeden çoğu üretim sorununu yakalarsınız.

Gecikme (Latency): Bir istek ne kadar sürer? Sadece ortalamalar değil, dağılımları raporlayın. p99 (99. yüzdelik gecikme) ortalama değerden daha önemlidir, çünkü kuyruk gecikmesi (tail latency) kullanıcıların 'yavaş' olarak hissettiği şeydir. Ortalaması 50 ms ve p99'u 5.000 ms olan bir serviste, çoğu kullanıcının asla fark etmediği ancak en çok etkilenen %1'in kesinlikle hissettiği gerçek bir sorun vardır.

Trafik: Saniyede kaç istek var? Toplam istekler, uç başına (per-endpoint), durum kodu başına, bölge başına. Baz çizgisi (baseline) bilinmelidir; anomalilerde (ani düşüş = giriş sorunu; ani artış = ani talep artışı veya saldırı) uyarı verin.

Hatalar: Başarısız isteklerin oranı. 4xx (istemci hataları, sizin suçunuz değil) ile 5xx (sunucu hataları, sizin suçunuz) arasında ayrım yapın. Uyarıların farklı yük seviyelerinde çalışabilmesi için hata oranını mutlak sayılar olarak değil, trafiğin yüzdesi olarak izleyin.

Doygunluk (Saturation): Sistem ne kadar dolu? CPU kullanımı, bellek, bağlantı havuzu derinliği, kuyruk uzunluğu. Öncü gösterge. Doygunluk, gecikme veya hatalar bozulmadan önce yükselir. %90 doymuş bir katman, kuyruk çöküşüne tek kötü dakikadır.

Özellikle Bir Vekil (Proxy) Katmanında

Her sinyal kenar katmanında (edge layer) aydınlanır:

- Vekilde gecikme: TLS el sıkışma süresi, üst akış (upstream) bağlantı süresi, istek-yanıt toplamı. Yolun farklı kısımlarında oldukları için ayrı ayrı ölçülürler.

- Vekilde trafik: Toplam istek/sn, arka uç (backend) dağılımı başına (sıcak bir arka uç, yük dengeleyici eğilimine işaret eder), durum kodu kırılımı.

- Vekilde (proxy) hatalar: İstemcilerden gelen 4xx'ler (kötü uç noktalara erişen kullanıcılarınız), arka uçlardan gelen 5xx'ler (hizmetlerinizin başarısız olması), vekil içi hatalar (502 = arka uca ulaşılamıyor, 504 = arka uç zaman aşımı).

- Vekilde (proxy) doygunluk: TLS oturum sayısı, üst akış (upstream) bağlantı havuzu derinliği, vekilin kendisindeki CPU kullanımı (TLS sonlandırma CPU açısından yoğun iş yükü oluşturur).

İpucu: Arka uç gecikmesinin düşük olduğu bir anda 502 hatasında ani bir artış, arka uca yanıt vermeden önce bağlantıyı kapattığını (bağlantı sıfırlama, çökme, OOM) gösterir. 504 hatasındaki artış ise arka uca yavaş olduğunu ama hâlâ yanıt verdiğini gösterir. Hata kodunu okuyun; hata nerede yaşandığını söyler.

Sinyalleri Okuyun

Gösterge paneliniz son 10 dakika içinde şunları gösteriyor:

- Trafik: 800 istek/sn civarında kabaca sabit (ani artış yok)

- Gecikme: p50 40ms'de sabit, p99 5 dakika içinde 200ms'ten 2.500ms'e yükseldi ve hâlâ yükseliyor

- Hatalar: 4xx oranı %0,3'te stabil (normal arka plan); 5xx oranı %0,1'den %1,2'ye yükseldi (çoğunlukla 504 Gateway Timeout)

- Doygunluk: Arka uç (backend) CPU'su aynı 5 dakikalık sürede %45'ten %78'e yükseldi; proxy CPU'su %30'da stabil

Ne Zaman Ölçeklenecek, Ne Zaman Tahliye Edilecek, Ne Zaman Sayfa (Bildirim) Gönderilecek

Kapasite Kararları Tetikleyiciler Gerektirir

Metrikleri gözlemlemek kolaydır. Bunlara ne zaman müdahale edileceğini bilmek ise disiplindir.

Şu durumda ölçeklendirin (scale up): Doyma (saturation) sürekli bir eşiği aştığında (ör. arka uç CPU %70'in üzerinde 5 dakika boyunca), veya kuyruk derinliği hedefin ötesine geçtiğinde, veya gecikme p99 SLO'yu aştığında. Tetikleyici, sistemler bozulmadan önce, bozulma anında değil, tetiklenmelidir.

Şu durumda bir replikayı tahliye edin (drain): Peers (eşler) sağlıklıyken sürekli yavaş / hatalıyken (sıcak çalışan tek bir replika genellikle bir uygulama sorunu değil, bir ana bilgisayar düzeyi sorunudur), veya yeni bir sürüm dağıtılırken, veya bir replika nazikçe emekli edilirken.

Şu durumda bir insana sayfa (page) gönderin: Bir SLO, hata bütçesinin (error budget) sürdürülebilir olabileceğinden daha hızlı tüketiliyorsa, veya bir doyma tetikleyicisi otomatik ölçeklendirmenin (autoscaling) bunu emememesiyle tetikleniyorsa, veya bir kademeli (cascade) örüntü ortaya çıkıyorsa (hata oranı + yeniden deneme oranı her ikisi de yükseliyorsa).

Şu durumda sayfa (page) göndermeyin: Tek bir kötü dakika kendi kendine çözüldüğünde, veya arka plan toplu işlemleri (batch jobs) beklenen periyodik dalgalanmalara neden olduğunda, veya gürültü eşiği aştığında (yanlış olan sistem değil, eşiğin kendisidir).

SLO'lar ve Hata Bütçesi Tüketimi

Bir SLO (hizmet düzeyi hedefi), kabul edilebilir performansı tanımlar: '28 günlük pencere boyunca başarı oranı >= %99,9'. Tamamlayıcı olan kısım (%0,1) hata bütçesidir.

Tüketim hızı (Burn rate): Hata bütçesini ne kadar hızlı tükettiğinizi gösterir. Bütçenin %10'unu 1 saat içinde tüketiyorsanız, hızınız sürdürülebilir olanın 240 katı daha hızlıdır (1 saat, 28 günlük pencerenin 1/672'sidir; bu pencerede %10 tüketmek = %10 × 672 = tam pencere için %6720 öngörüsü demektir, oysa izin verilen yalnızca %100'dür).

Çoklu pencere tüketim hızı uyarıları: Hem kısa bir pencere (5 dakika, 14,4x hız) hem de uzun bir pencere (1 saat, 6x hız) sürdürülebilir olandan daha hızlı tükendiğinde sayfa (page) oluşturur. Hem hızlı kesintileri hem de yavaş bozulmaları yakalar.

Neden bu kapasite için önemli: %99,9 SLO ile çalışan ve %1'lik bir payı olan bir hizmet, küçük dalgalanmaları absorbe edebilir. %99,93'te olan (SLO'yu zar zor karşılayan) bir hizmet ise tek kötü bir günden ihlale geçebilir. Kapasite kararları, SLO'yu karşılayan minimum değere değil, rahat bir SLO marjına yönelik olmalıdır.

Gözlem Altında Bir Kapasite Kararı

Hizmetinizin 28 gün boyunca %99,9 başarılı istek SLO'su var. Son bir saatteki izleme verilerine göre mevcut durum:

- Başarı oranı: %99,5 (30 dakika boyunca sürdü)

- Arka uç CPU: Filoda ortalama %82 (hedef %70)

- p99 gecikme: 800 ms (SLO hedefi: <500 ms)

- Trafik: 1.400 istek/sn, taban değer 1.000 istek/sn'den yükseldi (normalin %40 üzerinde; trend hâlâ yükseliyor)

- Otomatik ölçeklendirme: CPU %80'in üzerinde 5 dakika boyunca devam ettiğinde replika eklemek üzere yapılandırıldı; şu anda ~90 saniye içinde 3 replika ekleyecek olan bir ölçeklendirme işlemi ortasında

Bir Lansman Gözlemlenebilirlik Planı Tasarlayın

Sentez

Artık gerçek arızaları yakalayan bir /health, dağıtımları doğrulamanızı sağlayan bir /version, proxy katmanında dört altın sinyal panoları ve SLO yakma oranına bağlı kapasite tetikleyicileri tasarlayabilirsiniz.

Dördünü de uygulayın.

Ekip, search.example.com'u (arıza modları dersindeki arama servisi) yayına alıyor. Ekip, kullanıcıların fark etmesinden önce sorunları yakalayan ve net bir sayfa açma/açmama karar matrisine sahip gözlemlenebilirlik yayınlamak istiyor. SLO: %99,9 başarılı istek, 28 günlük pencere boyunca p99 gecikme < 300 ms.

Kursu Kapatma

Kursu Kapatma

Beş dersin tamamını tamamladınız:

- Proksiler ve Kaynaklar (Origins): Neredeyse tüm halka açık web hizmetlerinin kullandığı kenar katmanı (edge-layer) yapısı

- Durumsuz Yatay Ölçeklendirme (Stateless Horizontal Scaling): Durumsuz bir katmanın neden ucuz bir şekilde çoğaltılabildiği ve nasıl boyutlandırılacağı

- Giriş ve Çıkış Ayrımı (Ingress & Egress Separation): Neden tek bir kutu iki kutuya dönüşür ve bunu zorlayan hata modu

- Hata Modları ve Etki Alanı (Blast Radius): Tek nokta arızaları (SPOF), kaskat etkileri, olay sonrası analizler (postmortem) ve suçlayıcı olmayan aksiyon maddeleri

- Gözlemlenebilirlik ve Kapasite (bu ders): Kullanıcılar fark etmeden sorunların ortaya çıkmasını sağlamak için neyin ölçülmesi gerektiği

Ana hat (throughline): Web ölçeğinde dağıtık bir sistem sihirbazlık değildir. Küçük bir desen setinin (ters proxy, durumsuz kopyalar, giriş/çıkış ayrımı, bölmeler ve devre kesiciler, dört altın sinyal) düşünceli bir şekilde bir araya getirilmesidir. Desenleri tanıdığınız anda, bunları her üretim mimarisinde görebilirsiniz.

Eşlikçi dersler: Beş adet geometri temalı ders, aynı materyali graf teorisi ve geometri olarak yeniden ele alır. Bu dersler her iki sırayla da iyi çalışır.

İyi iş çıkardınız.