Çok bölgeli (multi-region / multi-DC) mimarilerde gerçek problem “iki yerde servis var” demek değildir; problem şudur: hangi kullanıcı hangi bölgeye gidecek, ne zaman yön değiştirecek ve ne zaman geri dönecek? Bu kararları “DNS zaten çözer” diye bırakırsanız, incident anında üç tip sürpriz yaşarsınız:
- Health-check “yeşil” görünüp kullanıcılar hata alır (kontrol noktası yanlış yerde).
- Failover gerçekleşir ama geri dönüş (failback) yanlış zamanda yapılır ve ikinci dalga incident üretir.
- DNS TTL / cache davranışı yüzünden değişiklik “yavaş ve düzensiz” yayılır; triage karmaşıklaşır.
Bu yazıda, ürün bağımsız bir GSLB tasarımını (Cloud LB, on-prem GTM, açık kaynak çözümler fark etmez) sahada çalışacak hale getiren sinyal, hold-down ve runbook yaklaşımını anlatıyorum.
1) Önce hedefi netleştir: aktif-aktif mi, aktif-pasif mi?
GSLB’yi seçmeden önce şu kararı netleştirin:
- Aktif-aktif: Trafik normalde iki (veya daha fazla) bölgeye dağıtılır. Hedef: kapasite + düşük latency + bölgesel arıza dayanımı.
- Aktif-pasif: Trafik normalde tek bölgededir; arızada ikinci bölge devreye girer. Hedef: daha sade işletim, daha az “çapraz” risk.
İki modelin de ortak gerçeği: failover anı kadar failback anı da risklidir.
2) Health-check’te en sık hata: yanlış katmandan ölçmek
GSLB health-check’leri üç seviyede ele alın:
- L3/L4 erişilebilirlik: TCP/443 açılıyor mu? (en hızlı, en sığ sinyal)
- L7 hazırlık (readiness):
/healthz200 dönüyor mu? (ama hâlâ yüzeysel olabilir) - Kritik yol (critical path): “Gerçek kullanıcı” davranışına yakın bir sentetik istek (auth + cache + DB gibi bağımlılıkları kapsar)
Üretimde sık gördüğüm problem: /healthz yeşildir ama uygulama bağımlılıkları (DB, queue, upstream) yüzünden iş yapamaz. GSLB doğru sinyal almazsa “yanlış yere” trafik iter.
2.1 Tek sinyal yerine çoklu sinyal (multi-signal) yaklaşımı
GSLB kararını tek bir check’e bağlamak yerine, kapı (gate) gibi düşünün:
- L7 readiness geçmezse bölge “down” say.
- Readiness geçiyor ama error rate / latency bozulduysa bölgeyi “degrade” moda al (ağırlık düşür).
- Sadece kapasite baskısı varsa (CPU/mem) “traffic shaping” yap (ağırlık azalt, ama tamamen kapatma).
Bu yaklaşım GSLB’yi “binary” olmaktan çıkarır; incident sırasında daha kontrollü manevra sağlar.
3) DNS gerçekliği: TTL tek başına kontrol değildir
TTL’yi düşürmek, cache davranışını “garanti etmez”. Çünkü:
- Bazı resolver’lar TTL’i “minimum”a yuvarlar.
- Mobil/kurumsal caching katmanları kararları geciktirir.
- İstemci uygulamaları DNS’i beklemediğiniz şekilde cache’leyebilir.
Bu yüzden GSLB tasarımında yayılım süresini (propagation) ölçülebilir hâle getirin:
- Kaydı değiştirince, farklı ASN/ISP/region’dan “cevap hangi IP” geliyor?
- TTL düşürme/artarımında “şok dalgası” (anlık cache miss) upstream’i boğuyor mu?
4) Hold-down ve hysteresis: flap’i engellemenin anahtarı
GSLB’de en pahalı durum “down oldu → up oldu → down oldu” döngüsüdür. Bunun ilacı:
- Hold-down: Bölge down sayıldıktan sonra belirli süre “down” kalır (hemen geri açılmaz).
- Hysteresis: Down karar eşiği ile up karar eşiği farklıdır (daha zor “up” olur).
Örnek (ürün bağımsız mantık):
- Down kriteri: 3 check üst üste başarısız
- Up kriteri: 10 check üst üste başarılı + p95 latency < eşik
- Hold-down: 10 dakika
Bu, “küçük dalgalanma”yı incident’e çevirmeyi engeller.
5) Failback stratejisi: geri dönüş “tek hamle” değil, ritimdir
Failback’i kademeli tasarlayın:
- Soğuk doğrulama: Bölgeye sentetik trafik (internal) gönder; kritik yol geçiyor mu?
- Canary: Trafiğin %1–5’ini geri getir; hata/latency izleniyor mu?
- Kademeli artır: %10 → %25 → %50 → normal
- Geri dönüş kapısı: Her aşamada “geri al” (rollback) kararı kolay olmalı
Bu süreç, “bölge döndü” cümlesini operasyonel gerçeğe çevirir.
6) Minimum viable runbook: GSLB incident anında ne yaparım?
Aşağıdaki checklist’i pratik bir başlangıç olarak kullanabilirsiniz:
6.1 İlk 5 dakika (triage)
- Problem global mi, bölgesel mi? (hata/latency haritası)
- Health-check hangi katmandan? (L4 mi L7 mi critical path mi?)
- DNS cevabı gerçekten değişiyor mu? (farklı resolver/region’dan ölç)
- Bölge bazında bağımlılık arızası var mı? (DB, queue, auth, storage)
6.2 Failover kararı
- Failover’un hedefi ne? “Hizmeti ayağa kaldır” mı “hata oranını düşür” mü?
- İkinci bölgenin kapasite headroom’u var mı?
- İkinci bölgede warm cache / warm pool var mı? Yoksa çarpan etkisi bekle.
6.3 Stabilizasyon
- Hold-down devrede mi? Flap engelleniyor mu?
- Uygulama katmanında rate-limit / load shedding gerekli mi?
- İletişim: “hangi bölge primary” bilgisi net mi?
6.4 Failback (kontrollü)
- Failback için “up kriteri” sağlandı mı?
- Canary ile geri dönüş denendi mi?
- Geri dönüş sonrası “ikinci dalga” riskine karşı alarm eşiği sıkı mı?
7) Kapanış: GSLB’yi DNS değil “operasyon sistemi” olarak düşün
GSLB, çok bölgeli mimarilerde bir “DNS kaydı yönetimi” işi değildir. Başarı; doğru health sinyali, flap’i engelleyen hold-down/hysteresis ve kontrollü failback ritmi ile gelir. Bunlar yoksa, GSLB sadece incident anında “bir şeyler değişiyor ama neden?” duygusu üretir.
Eğer tek cümlelik hedef koyacaksanız şunu seçin: Failover hızlı olsun; failback kontrollü olsun; kararlar ölçülebilir olsun.