English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

konuk
1 / ?
derslere geri dön

Düğümler, Kenarlar, Yönler

Bir İstek Olarak Graf Üzerindeki Bir Yürüyüş

Bir isteğin dokunduğu her bileşen bir düğümdür: istemci, DNS çözümleyici, CDN kenarı, ters vekil (reverse proxy), arka uç kopyası (backend replica), veritabanı, önbellek.

İki düğüm arasındaki her bağlantı bir yönlendirilmiş kenardır: istekler ileriye, yanıtlar geriye akar. İleri yöndeki kenar, üstündeki protokol ile birlikte açık bir TCP bağlantısını temsil eder.

Tek bir istek, bu graftaki bir yoldur. Sistemin isteğe yanıt vermek için yaptığı toplam iş, her düğümdeki işin toplamı ile her kenarın gecikmesinin (latency) toplamına eşittir.

Neden önemli? Grafiği çizdikten sonra, kodda görünmez olan özellikler belirgin hale gelir:

- Zıplama sayısı (Hop count): Yoldaki kenarların sayısı. Her zıplama gecikme süresi ekler (ağ gidiş-dönüş + düğüm işleme). Daha az zıplama = gecikme süresinin daha düşük alt sınırı.

- Giriş derecesi (In-degree): Bir düğüme KAÇ kenarın İÇERİ doğru işaret ettiği. Yüksek giriş derecesi, düğümün birçok kaynaktan istek aldığını ve ölçeklenmesi veya kendini koruması gerektiğini gösterir.

- Çıkış derecesi (Out-degree): Bir düğümden KAÇ kenarın DIŞARI doğru işaret ettiği. Yüksek çıkış derecesi, düğümün birçok aşağı akışa (downstream) bağımlı olduğunu ve birçok hata yolu olduğunu gösterir.

- Kesme düğümü (Cut vertex): Kaldırıldığında grafiği birbirinden ayıran tek bir düğüm. Eşit (peer) olmayan bir ters vekil (reverse proxy) bir kesme düğümüdür; kaldırıldığında kökenlerine (origins) olan tüm erişim kaldırılır.

Yönlendirilmiş grafik üzerinden istek yolu: istemci, vekil, arka uç, veritabanı

Aşağıdaki için istek grafiğini çizin (veya metinle açıklayın): istemci tarayıcı -> CDN kenarı -> ters vekil -> arka uç kopyası (replica) -> veritabanı. Zıplama sayısını sayın. Kesme düğümlerini belirleyin. Birbiri ardına bu kadar çok kesme düğümünün olmasının bir operasyonel sonucunu tahmin edin.

Trafiğin Yoğunlaştığı Yer

Fan-In = Yoğunlaşma

Bir düğümün giriş derecesi = ona giren kenarların sayısıdır. Bir istek grafında, giriş derecesi = istek gönderen üst akış kaynaklarının sayısıdır.

Fan-in deseni: birçok istemci -> tek bir CDN; birçok CDN kenarı -> az sayıda orijin proxy'si; birçok proxy -> daha az arka uç replikası; birçok arka uç -> tek bir veritabanı.

Yoğunlaşma, en yüksek iç dereceli (in-degree) düğümün en yüksek toplam yükü görmesi nedeniyle önemlidir. Zincirin sonundaki veritabanı, tek bir kullanıcının çok az yük üretse bile, sistemdeki tüm aktif isteklerden gelen sorguları görebilir.

Fan-Out = Bağımlılık

Bir düğümün dış derecesi (out-degree), o düğümden dışarıya doğru işaret eden kenarların sayısıdır. Yüksek dış derecesi, birçok aşağı akış (downstream) bağımlılığı olduğu anlamına gelir.

Bir veritabanı, iki önbellek, üç harici API ve bir kuyruk çağıran bir arka uç, dış derecesi 7'ye sahiptir. Başarı olasılığı, aşağı akışların her birinin başarı olasılığının çarpımına yakındır (tümünün başarılı bir yanıt için gerekli olması durumunda).

0.999 ^ 7 ≈ 0.993: Her biri %99,9 güvenilirliğe sahip 7 aşağı akışa sahip bir arka uç, kendi hataları olmasa bile yalnızca ~%99,3 güvenilirlik elde edebilir.

Dış derecesini azaltmak için: aşağı akış sonuçlarını önbelleğe almak, kritik olmayan aşağı akışları isteğe bağlı hale getirmek (zarif bozulma / graceful degradation), paralelleştirilebilecek olanları paralelleştirmek.

Asimetri

Fan-in yükü yoğunlaştırır; fan-out riski çarpar. İyi şekillendirilmiş bir grafik, en yüksek etkiye sahip düğümlerde her ikisini de en aza indirir.

Veritabanı (en yüksek fan-in): Yükü azaltmak için agresif olarak önbelleğe alın. Fan-in'i birden fazla düğüm arasında dağıtmak için ok replikaları kullanın.

Orkestratör servisi (en yüksek fan-out): Bağımlılık başına devre kesiciler (circuit breakers), zarif bozulma (graceful degradation), bölme (bulkheads).

Bir arka uç replikası, her biri bağımsız olarak %99,95 kullanılabilirliğe sahip 4 aşağı akış servisini çağırır. (1) Başarılı bir yanıt için 4 çağrının tümü gerekliyse, arka ucun kullanılabilirliğinin üst sınırı nedir? (2) 4 aşağı akıştan 2'si zarif bozulma yoluyla isteğe bağlı hale getirilirse (kullanılamadığında önbelleğe alınmış yedeklerle değiştirilirse), sınır ne olur?

Ekleme Yapılan Bir Düğüm Esneklik Sağlar

Dolaylılık (Indirection) = Ara Bir Düğüm Ekleme

Bir vekil (proxy) olmadan grafik şudur: istemci -> arka uç. İstemci, arka ucun adresini bilmek zorundadır. Arka ucu taşımak, istemcinin güncellenmesini gerektirir (DNS veya yapılandırma yoluyla). Bu, sıkı bir bağlamadır.

Bir vekil (proxy) ile grafik şu hale gelir: istemci -> vekil -> arka uç. İstemci yalnızca vekili bilir. Arka ucu taşımak, istemciyi değil, vekilin üst akış (upstream) yapılandırmasını güncellemeyi gerektirir.

Grafik işlemi: mevcut bir kenar boyunca bir düğüm ekleme. Yeni istemci -> vekil kenarı kararlıdır; yeni vekil -> arka uç kenarı artık ekibin yönetimi altındadır.

Geometrik yorum: dolaylılık (indirection), üst akıştaki değişimi alt akıştaki değişimden ayıran bir katman ekler. Her katmanın kenarları bağımsız olarak yeniden bağlanabilir.

Dolaylılığın Maliyeti

Her katman şunları ekler:

- Bir gecikme sıçraması (istemciden vekile giden kenar)

- Yolda bir tane daha kesme noktası (vekilin kendisi)

- Yanlış yapılandırmanın olabileceği bir tane daha yer

Faydalar (yeni bağlantı kurma, ölçeklendirme, koruma, TLS sonlandırma, yük dağıtımı) genellikle her türlü karmaşık sistem için maliyetleri aşar. Ancak bir sınır vardır: her dolaylılık katmanı bir sıçrama ve bir tane daha tek nokta arıza (SPOF) adayı ekler.

Halk arasındaki kural: Herhangi bir sorun, bir dolaylılık katmanı eklenerek çözülebilir (çok fazla dolaylılık katmanı sorunu hariç).

Bir ekip, mevcut bir ters vekilin önüne bir CDN ekler. Yol, `istemci -> vekil -> arka uç` (2 sıçrama) şeklinden `istemci -> CDN -> vekil -> arka uç` (3 sıçrama) şekline geçer. Dolaylılığın iki faydasını (graf teorisi terimleri kabul edilir) ve iki maliyetini belirtin.

Bir Mimariliği Grafik Olarak Okumak

Sentez

Artık bir sistem mimarisini bir grafik olarak okuyabilirsiniz: atlamaları sayın, kesme köşelerini (cut vertices) belirleyin, fan-in yoğunluğunu ölçün, fan-out'tan kullanılabilirlik tavanlarını hesaplayın ve dolaylılık (indirection) ödünleşimlerini değerlendirin.

Dördünü de uygulayın.

Yeni bir servisin şu mimarisi var: clients -> CDN -> reverse proxy (2 replika) -> backend tier (8 replika) -> { DB primary, cache cluster (3 düğüm), external API }.

Analiz edin: (1) tek bir istek yolundaki maksimum atlama sayısı nedir, (2) en yüksek fan-in'e sahip katman hangisidir (& ölçekleme için ne anlama gelir), (3) DB %99,95, cache %99,95 ve external API %99,9 kullanılabilirliğe sahipse ve tümü zorunluysa backend kullanılabilirlik tavanı nedir ve (4) kaldırıldığında en çok kullanıcıyı koparacak tek düğüm hangisidir?

Eşlikçi Notlar

Eşlikçi Notlar

Bu geometri-temelli ders, Vekiller ve Kökenler ana dersini yönlendirilmiş bir graf analizi olarak yeniden ele alır.

Bu kursun bir sonraki eşlikçisi olan geometry_of_stateless_horizontal_scaling, ana ölçeklendirme dersindeki replika matematiğini alır ve kuyruklama eğrisini, Little Yasası'nı ve %80 kullanım oranı dizini (knee) noktayı geometrik olarak türetir.

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