GeoDNS ve Çok Bölgeli Hosting Neden Gündeminizde Olmalı?
Artık yalnızca tek bir ülkedeki ziyaretçilere hitap eden web siteleri bile, reklam ağları, sosyal medya paylaşımları ve organik aramalar sayesinde kısa sürede global trafiğe açılıyor. Sunucunuz Türkiye’de, ama trafiğinizin ciddi bir kısmı Avrupa, Orta Doğu hatta Amerika’dan geliyor olabilir. Bu noktada tek bölgede çalışan klasik bir hosting mimarisi, uzak ziyaretçiler için gecikmeyi artırabilir ve bölge çapındaki kesintilere karşı yetersiz kalabilir.
İşte tam burada GeoDNS ve çok bölgeli (multi-region) hosting mimarisi devreye giriyor. GeoDNS, DNS sorgusundan tahmin edilen konuma göre farklı IP adresleri döndürebilen bir DNS yaklaşımı. Çok bölgeli hosting ise uygulamanızın farklı coğrafi bölgelerdeki veri merkezlerinde, mümkünse birbirinden bağımsız altyapılarda çalıştırılması anlamına geliyor. Birlikte kullanıldıklarında, uygun veri replikasyonu ve failover tasarımıyla global ziyaretçileriniz için gecikmeyi azaltabilir ve yedekliliği güçlendirebilirler.
Bu yazıda GeoDNS + çok bölgeli mimarileri, varsayımsal senaryolarla ve pratik karar noktalarıyla ele alacağız. Hangi desen ne zaman mantıklı, veritabanı ve oturum (session) yönetimini nasıl çözersiniz, DNS tarafında hangi tuzaklara düşmemelisiniz; hepsini adım adım netleştireceğiz.
GeoDNS Nedir? Klasik DNS’ten Temel Farkı
Konuma göre yanıt üretmeyen basit bir DNS yapılandırmasında, alan adınız için belirlediğiniz A/AAAA kayıtları dünyanın her yerinden gelen sorgulara aynı adresleri döndürür. Örneğin www.ornek.com için 203.0.113.10 IP’sini tanımladıysanız, Türkiye’den de ABD’den de gelen ziyaretçi bu IP’ye yönlenir.
GeoDNS ise DNS cevabını tahmini konuma göre farklılaştırır. Bu tahmin genellikle sorguyu ileten özyinelemeli DNS çözümleyicisinin IP adresine, desteklenip iletildiğinde ise EDNS Client Subnet bilgisine dayanır; kullanıcının gerçek konumuyla örtüşmeyebilir. Aynı alan adı için, farklı coğrafi bölgelerden gelen isteklere farklı IP adresleri dönebilirsiniz. Örneğin:
- Avrupa ve Türkiye’den gelen ziyaretçiler: 198.51.100.10 (İstanbul veri merkezi)
- ABD’den gelen ziyaretçiler: 198.51.100.20 (New York veri merkezi)
- Asya’dan gelen ziyaretçiler: 198.51.100.30 (Singapur veri merkezi)
Bu yönlendirme genellikle IP coğrafi veritabanları (GeoIP) ve DNS sağlayıcısının altyapısı sayesinde yapılır. Sonuçta DNS yanıtı, belirlediğiniz kurallara göre uygun görülen bölgenin adresini içerir; coğrafi yakınlık, ağ açısından en düşük gecikmeyi garanti etmez.
GeoDNS’i, DNS kayıtlarını manuel olarak bölge bölge değiştirmek yerine, otomatik ve kural tabanlı bir yönlendirme katmanı gibi düşünebilirsiniz. Bunu anlamak için DNS temel kayıt türlerine hâkim olmak önemli; eğer bu konuda eksik hissediyorsanız, önce DNS kayıtları A’dan Z’ye rehberimize göz atmanız yararlı olacaktır.
Çok Bölgeli Hosting Mimarisi Ne Anlama Geliyor?
Çok bölgeli (multi-region) mimari kısaca, uygulamanızın yalnızca tek bir veri merkezinde değil, en az iki coğrafi bölgede çalışmasıdır. Bu bölgeler:
- Farklı şehirlerdeki veri merkezleri (İstanbul + Frankfurt gibi)
- Farklı ülkelerdeki veri merkezleri (Türkiye + Hollanda + ABD gibi)
- Hatta farklı veri merkezi operatörleri ve ağlar olabilir
Böyle bir mimari şu bileşenlerle kurgulanabilir:
- Uygulama katmanı: Her bölgede ayrı VPS veya dedicated sunucu kümeleri
- Veritabanı katmanı: Replikasyon, cluster veya tek yazma (single-writer) + çoklu okuma (read-replica) mimarisi
- DNS/GeoDNS katmanı: Trafiği doğru bölgeye yönlendiren, gerektiğinde failover yapabilen akıllı DNS
- Depolama ve medya: Ortak obje depolama (S3 uyumlu) veya bölgesel replikasyon; uygulamanın tutarlılık ve erişilebilirlik gereksinimlerine göre seçim
Çok bölgeli mimarilerle ilgili daha derin bir giriş yapmak isterseniz, yine kendi içimizden hazırladığımız DNS geo-routing ve veritabanı replikasyonu odaklı çok bölgeli mimari rehberimize de bakabilirsiniz.
Global Ziyaretçiler İçin Olası Kazanımlar: Gecikme, SEO ve Yedeklilik
GeoDNS ve çok bölgeli hosting çoğu zaman "kurumsal lüks" olarak algılanır. Oysa kesinti maliyeti ve bölgesel performans gereksinimleri arttığında, ek altyapı ve işletim maliyetine rağmen riski azaltmak için anlamlı bir seçenek olabilir. Olası kazanımları netleştirelim:
Daha Düşük Gecikme ve Daha İyi Kullanıcı Deneyimi
Kullanıcı ile sunucu arasındaki ağ gecikmesi arttıkça, TTFB (Time To First Byte) ve genel sayfa yüklenme süreleri uzayabilir; sunucu işlem süresi ve önbellek kullanımı da sonucu etkiler. Özellikle dinamik uygulamalarda bu durum, dönüşüm ve terk oranlarını etkileyebilir. Daha düşük gecikmeli bir bölgeden cevap vermenin kazancını, bölgesel TTFB ve Core Web Vitals ölçümleriyle değerlendirmek gerekir; sabit bir milisaniye kazancı beklenmemelidir.
SEO ve Bölgesel Hedefleme
Düşük sunucu yanıt süreleri sayfa hızını destekleyebilir; ancak GeoDNS kullanımı tek başına arama sıralaması veya ülke hedefleme avantajı sağlamaz. Bölgesel alt alan adlarını (örneğin de.ornek.com, fr.ornek.com) farklı veri merkezlerine yönlendirmek için standart DNS kayıtları da kullanılabilir. GeoDNS’in burada eklediği olanak, aynı ad için sorgunun tahmini konumuna göre farklı adresler döndürmektir; bu, içerik ve dil hedeflemesinden ayrı bir altyapı kararıdır.
Yüksek Erişilebilirlik ve Felaket Dayanıklılığı
Tek bölgeli mimarilerde, veri merkezi çapındaki bir kesinti tüm sitenizi erişilemez hale getirebilir; tek bir donanım veya ağ bileşeni arızasının etkisi ise bölge içi yedekliliğe bağlıdır. Çok bölgeli mimaride, sağlık kontrolü ve DNS failover desteğiyle yeni bağlantılar diğer bölgelere yönlendirilebilir. Bunun işe yaraması, hedef bölgelerin yeterli kapasiteye ve gerekli verilere sahip olmasına bağlıdır. Geçiş süresi arıza tespiti ve DNS önbelleklerinden etkilenir; mevcut bağlantılar DNS değişikliğiyle taşınmaz. Bu yaklaşımı, "felaket kurtarma" senaryoları ile birleştirerek felaket kurtarma provasının gerçekten işe yaradığı bir yapı kurmak mümkün.
GeoDNS ile Trafik Yönlendirme Desenleri
Coğrafi yönlendirmeye ek olarak, DNS sağlayıcısının desteklediği özelliklere bağlı biçimde gecikme tabanlı seçim, ağırlıklandırma ve sağlık kontrolüne dayalı failover desenleri de kullanılabilir.
1. Coğrafi Bölgeye Göre Yönlendirme
Temel bir senaryo, sorgunun tahmini coğrafi konumunu önceden seçilmiş bir sunucu bölgesiyle eşlemektir. Varsayımsal bir dağılım şöyle olabilir:
- TR + MENA trafiği: İstanbul bölgesi
- Batı Avrupa trafiği: Frankfurt / Amsterdam bölgesi
- Kuzey Amerika trafiği: ABD Doğu / Batı kıyısı bölgeleri
Burada dikkat edilmesi gereken, yalnızca fiziksel mesafe değil, gerçek ağ gecikmesi ve bağlantı kalitesidir. Bazen harita üzerinde daha uzakta olan bir bölge, omurga bağlantıları nedeniyle daha hızlı yanıt verebilir. Bu yüzden tasarım aşamasında mutlaka ölçüm yapılmasını öneriyoruz.
2. Gecikme Tabanlı Yönlendirme (Latency-Based Routing)
Coğrafi yönlendirme iyi bir başlangıçtır, ancak mutlak doğru değildir. Latency-based routing, sağlayıcının kullandığı gecikme verilerine göre uygun bölgeyi seçmeyi amaçlar. Ölçüm noktaları ve verilerin güncelliği sağlayıcıya bağlıdır; her DNS sorgusunda çözümleyici ile tüm bölgeler arasında anlık RTT (round-trip time) ölçümü yapıldığı varsayılmamalıdır.
Bu yaklaşım, kullanılan ölçümler ağ koşullarını yeterince yansıtıyorsa daha düşük gecikmeli bölgenin seçilmesine yardımcı olabilir. Ancak DNS önbellekleri ve mevcut bağlantılar nedeniyle kullanıcı trafiği anında başka bölgeye taşınmaz; performans istikrarı garanti değildir.
3. Ağırlıklı Yönlendirme (Weighted Routing) ve Canary Dağıtım
Ağırlıklı yönlendirmeyi destekleyen bir DNS hizmeti, yanıt seçimlerini belirlenen ağırlıklara göre dağıtmak için kullanılabilir. Önbellekler ve çözümleyicilerin hizmet verdiği kullanıcı sayıları nedeniyle bu ağırlıklar, gerçek HTTP trafiğinde aynı yüzdeleri garanti etmez. Örneğin:
- İstanbul bölgesi: %80 DNS yanıt seçim ağırlığı
- Frankfurt bölgesi: %20 DNS yanıt seçim ağırlığı (yeni altyapıyı test etmek için)
Bu sayede yeni bir bölgeyi düşük ağırlıkla devreye alıp gerçek trafik dağılımını ve hata oranlarını gözlemleyebilir, sonuçlara göre ağırlığı artırabilirsiniz. Uygulama güncellemelerinizde, ağırlıklı DNS yönlendirmesiyle canary release veya blue/green deployment stratejilerini destekleyebilirsiniz; ancak DNS önbellekleri nedeniyle geçiş ve geri alma anlık değildir.
4. Failover Senaryoları ve Sağlık Kontrolleri
Çok bölgeli bir yapıda en kritik konulardan biri, bir bölge sorun yaşadığında trafiğin diğer bölgelere otomatik olarak kaydırılabilmesidir. Sağlık kontrolü ve failover destekleyen bir DNS hizmetinde örnek akış şöyledir:
- Her bölgedeki uygulama uç noktalarına (HTTP/HTTPS) düzenli sağlık kontrolü (health check) yapılır
- Belirli sayıda başarısız kontrol sonrasında, o bölgenin IP kayıtları DNS cevaplarından çıkarılır
- GeoDNS, kalan sağlıklı bölgelere göre yeni yönlendirme planını uygular
Küçük ve orta ölçekli siteler için bu mantığı daha hafif şekilde ele alan bir yazımız da var: küçük işletme siteleri için multi-region DNS ve CDN failover mimarisi başlıklı rehbere göz atmanız, kavramları sadeleştirmek açısından faydalı olacaktır.
Örnek Çok Bölgeli Mimari Senaryoları
Senaryo 1: TR + Avrupa Trafiği Olan E-Ticaret Sitesi
Varsayımsal bir örnekte, Türkiye merkezli bir e-ticaret siteniz olduğunu düşünelim; trafiğin %70’i Türkiye’den, %20’si Avrupa’dan, %10’u da dünyanın geri kalanından geliyor. Bu örnekte tek veri merkezli mimaride Avrupa kullanıcılarının TTFB değerlerinin özellikle kampanya dönemlerinde arttığını varsayalım.
Bu senaryo için değerlendirilebilecek bir mimari:
- İstanbul’da ana bölge: Uygulama sunucuları + yazma veritabanı
- Avrupa veri merkezinde ikincil bölge: Uygulama sunucuları + okuma replikası veritabanı
- GeoDNS ile TR/MENA trafiği İstanbul’a, Avrupa trafiği Avrupa bölgesine yönlendirilir
- Sepet ve ödeme süreçlerinde oturum verisinin bölge değişiminde de erişilebilir olması planlanır; merkezi bir session store (Redis gibi) bir seçenektir. "Stickiness" tek başına veri tutarlılığı veya bölgesel kesintide oturum sürekliliği sağlamaz
Ödeme ve stok yönetimi gibi kritik yazma işlemleri, sadece ana veritabanı bölgesine yönlendirilir. Okuma ağırlıklı ürün listeleme sayfaları ise bölgesel replikalardan beslenebilir.
Senaryo 2: Global SaaS Uygulaması
Uygulamanız SaaS modeliyle çalışıyor ve müşterileriniz dünya geneline yayılmış durumda. Burada yalnızca web arayüzünün hızlı açılması değil, API çağrılarının da düşük gecikmeyle cevap vermesi kritik.
Bu tip yapılar için örnek bir desen:
- Örneğin 3 bölgede (TR, EU, US) uygulama sunucuları kümesi; bölge sayısı trafik ve dayanıklılık hedeflerine göre seçilir
- Merkezi veya bölgesel veritabanı mimarisi (müşteri bölgesine göre veriyi bölgesel tutma kararı dahil)
- GeoDNS ile API adı için, DNS sorgusunda görülen konuma ve yönlendirme kurallarına göre uygun bölgenin adresinin döndürülmesi; bu seçim her kullanıcı için en düşük gecikmeyi garanti etmez
- CDN + GeoDNS kombinasyonuyla statik varlıkların bölgesel sunumu
Böyle bir mimaride, özellikle veri yerelleştirme ve regülasyonlar (KVKK, GDPR vb.) önemli hale gelir. Bu konularda daha derin bir perspektif için, KVKK ve GDPR uyumlu hosting mimarisi rehberimize göz atabilirsiniz.
Senaryo 3: Yüksek Trafikli Haber / İçerik Sitesi
Günde yüz binlerce ziyaretçi alan bir haber veya blog siteniz var. İçerik büyük oranda statik, ama manşet, kategori sayfaları ve kullanıcıya özel bazı bloklar dinamik.
Bu senaryoda şu mimari değerlendirilebilir:
- Global CDN: Statik görseller, CSS/JS ve herkese açık HTML uygun önbellek kurallarıyla CDN’den sunulur; kullanıcıya özel yanıtlar ortak önbelleğe alınmaz
- İki veya daha fazla bölgede web "origin" sunucuları
- CDN’in origin çözümleme davranışı uygunsa, GeoDNS origin adı için bölgesel IP’ler döndürebilir; seçim ziyaretçinin değil CDN’in DNS sorgusunda görülen konumuna dayanabilir
- Veritabanı tarafında, okuma ağırlıklı replikalar ve güçlü önbellekleme stratejileri kullanılır
Bu yapı, CDN ve origin yönlendirmesi birlikte doğru çalışacak şekilde tasarlandığında, kampanya, seçim veya büyük bir olay sırasında tek bir web origin bölgesine bağımlılığı azaltabilir. Veritabanı gibi ortak bileşenlerin kapasite ve erişilebilirlik sınırları ayrıca değerlendirilmelidir.
Çok Bölgeli Mimaride Veritabanı ve Durum Yönetimi
İşin DNS tarafı görece kolay; asıl zor kısım, veritabanı ve uygulama durumunu (state) çok bölgeli yapıyla uyumlu hale getirmek. Burada birkaç temel yaklaşım var:
1. Tek Yazma Bölgesi (Single-Writer) + Çoklu Okuma Replikası
Yazma çakışmalarını yönetmeyi basitleştiren bir yaklaşım, yalnızca bir bölgede yazma işlemlerine izin vermek, diğer bölgelerdeki veritabanlarını read-replica yani okuma replikası olarak kullanmaktır. Avantajları:
- Bölgeler arası eşzamanlı yazma çakışmalarını önler; ancak replikasyon gecikmesi nedeniyle eski veri okunabilir. Güncellik gerektiren okumalar ve ana bölge kaybında güvenli yazma devri ayrıca tasarlanmalıdır
- Uygulama katmanında daha basit bir mantıkla çalışabilirsiniz
- Okuma yükünü farklı bölgelere dağıtarak ölçeklenebilirliği artırırsınız
MySQL/PostgreSQL replikasyon kurulumuna dair adım adım bir rehbere ihtiyacınız varsa, VPS üzerinde MySQL ve PostgreSQL replikasyon rehberimizi inceleyebilirsiniz.
2. Çoklu Yazma (Multi-Primary / Cluster) Mimarileri
Daha iddialı yapılarda, MariaDB Galera Cluster veya MySQL Group Replication benzeri çözümlerle birden fazla bölgede yazma kabul eden cluster mimarileri kullanılabiliyor. Bu yaklaşım:
- Yazma kabul edecek şekilde yapılandırılan bölgelerde yerel bir uç nokta sunabilir; yazmanın tamamlanması yine bölgeler arası iletişime bağlı olabilir
- Ancak ağ gecikmesi ve "split-brain" riskleri nedeniyle dikkatli tasarım ister
Bu tip yapıları düşünüyorsanız, önce Galera ve Group Replication ile yüksek erişilebilirlik rehberimize göz atmanızı öneririz; oradaki ilkeler, bölgeler arası gecikme ve ağ kesintisi koşulları dikkate alınarak yeniden değerlendirilmelidir.
3. Oturum (Session) Yönetimi ve Kullanıcı Durumu
Load balancer ve GeoDNS ile kullanıcıyı farklı bölgelere gönderebildiğiniz bir dünyada, session yönetimi büyük önem kazanıyor. Temel seçenekler:
- Stateless yaklaşım: Sunucu tarafındaki oturum sorgularını azaltmak için seçili kimlik bilgilerini imzalı ve doğrulanan JWT gibi tokenlarda taşımak. Token süresi ve iptal mekanizması planlanmalı; sepet gibi değişken uygulama verileri uygun bir veri deposunda tutulmalıdır
- Merkezi session store: Redis gibi bir yapıda oturumları saklamak; bu durumda gecikme, bölgesel erişim ve store’un bulunduğu bölge kaybedildiğinde oturumların nasıl korunacağı tasarlanmalıdır
- Region stickiness: Kullanıcıyı belirli bir süre aynı bölgede tutmak. Cookie tabanlı karar HTTP katmanında alınır; GeoDNS cookie okuyamaz. DNS’te IP tabanlı seçim ise her zaman tekil kullanıcıyı temsil etmez
Hangi yaklaşımı seçerseniz seçin, çok bölgeli mimaride en büyük hedefiniz, kullanıcı deneyiminde tutarlılık ve veri bütünlüğü olmalıdır.
DNS ve GeoDNS Katmanında Dikkat Edilmesi Gerekenler
TTL Stratejisi: Esneklik ve Önbellek Dengesini Kurmak
GeoDNS ile çalışırken, DNS kayıtlarınızın TTL (Time To Live) değerleri kritik hale gelir. Çok düşük TTL, önbellekteki DNS yanıtlarının daha sık yenilenmesini sağlayarak değişikliklerin daha hızlı görülmesine yardımcı olur; ancak tüm istemcilerin anında geçişini garanti etmez ve:
- DNS sorgu trafiğinizi artırır
- Önbellek yenilemesi gereken sorgularda ek DNS çözümleme gecikmesine neden olabilir
Çok yüksek TTL ise değişikliklerin, özellikle failover durumunda, kullanıcıya ulaşmasını geciktirir. Planlı geçişlerde TTL’yi önceden düşürmek ve eski TTL süresinin dolmasını beklemek yararlıdır. Beklenmedik arızalarda ise olay sırasında TTL’yi düşürmek, önceden önbelleğe alınmış yanıtların süresini kısaltmaz; normal TTL değeri failover hedefiyle uyumlu seçilmelidir. Bu dengeyi nasıl kuracağınızı detaylı anlattığımız zero-downtime taşıma için TTL stratejileri yazımızı mutlaka okumanızı öneririz.
DNSSEC, Güvenlik ve Bütünlük
Çok bölgeli, çok sağlayıcılı DNS kurgularında DNS güvenliği de kritik hale gelir. GeoDNS kullanırken de, DNS verilerini DNSSEC ile imzalamak, üst bölgeye uzanan güven zinciri doğru kurulduğunda ve çözümleyici DNSSEC doğrulaması yaptığında, sahte DNS yanıtlarına karşı koruma sağlar. DNSSEC kavramına yabancıysanız, DNSSEC nedir ve adım adım kurulum rehberimize göz atarak başlayabilirsiniz.
Çoklu Sağlayıcı DNS ile Dayanıklılığı Artırmak
Tek bir DNS sağlayıcısına bağımlı kalmak, çok bölgeli mimarinin kazandırdığı dayanıklılığı kısmen geri alabilir. Bu yüzden, özellikle kritik projelerde, çoklu sağlayıcı DNS stratejisini konuşuyoruz. Bu senaryoda:
- DNS kayıtlarınız birden fazla sağlayıcıda senkronize tutulur ve her sağlayıcının yetkili ad sunucuları delegasyonda yer alır; DNSSEC kullanılıyorsa imzalama ve güven zinciri birlikte planlanır
- Her iki tarafta da uyumlu GeoDNS/health check kuralları yapılandırılır; yalnızca statik kayıtları senkronize etmek dinamik yönlendirme politikalarını eşitlemez
- Bir DNS sağlayıcısı sorun yaşadığında, diğer sağlayıcı üzerinden çözümleme devam eder
Bunu pratikte nasıl kuracağınızı, octoDNS ile çoklu sağlayıcı DNS ve dayanıklılık rehberimizde örneklerle gösteriyoruz.
GeoDNS ve Çok Bölgeli Hosting İçin Altyapı Nasıl Planlanır?
GeoDNS ve çok bölgeli mimari planında domain ve DNS yönetimi ile hosting, VPS, dedicated sunucu veya colocation seçenekleri birlikte değerlendirilmelidir. Seçilecek planın bölge seçenekleri, GeoDNS ve sağlık kontrolü desteği ile yönetim sorumlulukları netleştirilmelidir. Planlama için şu adımlar izlenebilir:
- 1. Trafik ve kullanıcı analizi: Hangi ülkelerden, hangi oranlarda trafik geliyor? Hangi sayfalar en kritik?
- 2. Kapasite ve büyüme tahmini: Önümüzdeki 6–12 ay için trafik hedefleri ve kampanya planları
- 3. Bölge seçimi: Hangi veri merkezleri ve ağlar, sizin kullanım senaryonuza en iyi karşılığı veriyor?
- 4. Veritabanı ve veri yerleşimi kararı: Single-writer + read-replica mı, yoksa cluster mı?
- 5. DNS/GeoDNS tasarımı: Hangi alt alan adları hangi bölgelere gidecek, failover kuralları nasıl olacak?
- 6. Test, load test ve felaket senaryoları: Gerçek kullanıcıya açmadan önce kapsamlı denemeler
Bu süreçte, özellikle load test ve kapasite planlama rehberimizde anlatılan yaklaşımları kullanarak, her bölgedeki altyapının kapasitesini canlıya geçmeden önce ölçebilirsiniz.
Adım Adım Geçiş Rehberi: Tek Bölgeden Çok Bölgeye
Halihazırda tek bölgede çalışan bir siteniz varsa ve "Biz bunu çok bölgeli hale getirebilir miyiz?" diye düşünüyorsanız, aşağıdaki adımlar geçişi daha kontrollü hale getirecektir.
1. Mevcut Durumu Ölçmek
Önce nerede olduğunuzu bilmeniz gerekiyor. Farklı ülkelerden:
- TTFB ve toplam sayfa yüklenme sürelerini ölçün
- Veritabanı sorgu sürelerini ve yoğunluk anlarını analiz edin
- Hangi işlemlerin (kayıt, ödeme, rapor, API) gecikmeye en hassas olduğunu belirleyin
2. İkinci Bölgeyi "Okuma Ağırlıklı" Olarak Devreye Almak
İlk adımda tüm trafiği ikinci bölgeye açmak yerine, genellikle okuma ağırlıklı yükü ikinci bölgeye almak daha güvenlidir. Örneğin:
- Statik içerikleri ve medya dosyalarını ikinci bölgedeki sunuculara kopyalayın
- Veritabanı için okuma replikası kurun ve replikasyon gecikmesini tolere edebilen rapor/arama işlemlerini buraya taşıyın
- GeoDNS ile yalnızca belirli alt alan adlarını (örneğin CDN origin) ikinci bölgeye yönlendirin
3. Trafiği Kademeli Olarak Dağıtmak
Her şey yolunda gidiyorsa, GeoDNS sağlayıcınız destekliyorsa ağırlıklı yönlendirme kullanarak ikinci bölgedeki uygulama sunucularına düşük bir DNS yanıt ağırlığı vermeye başlayabilirsiniz. DNS önbellekleri ve istemci davranışları nedeniyle bu ağırlıklar gerçek istek trafiğinde aynı yüzdeleri garanti etmez. Örnek ağırlıklar:
- Başlangıç: %90 birinci bölge, %10 ikinci bölge
- Gözlem ve optimizasyon sonrası: %70 / %30
Bu sırada loglarınızı, gecikme sürelerini, hata oranlarını ve veritabanı tutarlılığını yakından izlemeniz gerekir.
4. Failover Senaryolarını Test Etmek
En kritik adımlardan biri, kağıt üzerinde kalan felaket senaryolarını gerçekten test etmektir. Örneğin:
- Önce izole bir test ortamında birinci bölgedeki uygulama sunucularını devre dışı bırakın; canlı ortam denemesi için ikinci bölgenin kapasitesini doğrulayın, bakım penceresi ve geri dönüş planı belirleyin
- Veritabanı yazma rolü de devredilecekse, DNS failover’ın okuma replikasını kendiliğinden yazılabilir ana veritabanına dönüştürmediğini dikkate alın. Eski ana veritabanının çakışan yazmaları kabul etmesini engelleyin (fencing), replikasyon gecikmesini kabul edilebilir veri kaybı hedefiyle karşılaştırın ve hedef bölgenin veri ve uygulama açısından hazır olduğunu doğrulamadan trafiği açmayın
- Yapılandırdığınız GeoDNS sağlık kontrollerinin arızalı bölgeyi yeni DNS yanıtlarından çıkardığını doğrulayın; önbellekteki yanıtlar ve mevcut bağlantılar nedeniyle geçişin ne kadar sürdüğünü ölçün
- Kullanıcı deneyimini gerçek tarayıcı ve cihazlarla gözlemleyin; yazma işlemlerini, oturum kurtarmayı ve eski bölgeye güvenli geri dönüşü de test edin
Bu testleri sadece bir kez değil, belli aralıklarla tekrar etmeniz gerekiyor; tıpkı düzenli yedeklerinizi ara ara geri yükleyerek test etmeniz gerektiği gibi.
Sonuç: GeoDNS ve Çok Bölgeli Mimariyi Ne Zaman Ciddiye Almalısınız?
GeoDNS ve çok bölgeli hosting mimarisi, başta karmaşık ve pahalı görünebilir. Yatırım kararı, gecikme nedeniyle kaybedilebilecek gelir ve kesinti riskleri ile ek altyapı ve işletim maliyetlerini karşılaştırmalıdır. Çok bölgeli mimariyi değerlendirmeye değer kılabilecek durumlar şunlardır:
- Yurt dışı trafiğinizde ölçülen gecikmeler kullanıcı deneyimini veya iş hedeflerinizi olumsuz etkilediğinde
- Kampanya dönemlerinde tek bölgedeki kapasite yetersiz kaldığında; önce önbellekleme ve bölge içi ölçekleme seçenekleriyle karşılaştırarak
- Her dakika kesintinin ciddi maddi/itibar kaybı anlamına geldiği bir noktaya geldiğinizde
Bu yazıda GeoDNS’in temel mantığını, çok bölgeli hosting desenlerini, veritabanı ve DNS tarafındaki kritik tasarım kararlarını örnek senaryolarla ele aldık.
Çok bölgeli bir tasarım için seçilecek DNS ve barındırma hizmetlerinin bölge seçeneklerini, yönlendirme yeteneklerini ve yedeklilik gereksinimlerini karşılayıp karşılamadığını doğrulayın. Hangi bölgede ne kadar kaynak kullanılacağını, DNS stratejisini ve geçiş planını bu doğrulamalar ile ölçüm sonuçlarına dayanan somut bir yol haritasına dönüştürün.
