Çoklu CDN ve Çoklu Sunucu Yapısında DNS Stratejisi

Tek bir CDN sağlayıcısına bağımlı olmak, o sağlayıcının kesintisini doğrudan son kullanıcıya yansıtır. Çoklu CDN ya da çoklu origin sunucu mimarisinde DNS, yalnızca bir isim-IP eşleşmesinden ibaret değildir; trafik yönlendirme, failover ve coğrafi dağıtım kararlarının verildiği katmandır. Bu katmanı doğru planlamak, DNS kayıtlarının kendisini planlamak kadar — hatta daha fazla — önem taşır.

Çoklu CDN kullanımının iki farklı motivasyonu vardır. Birincisi dayanıklılık: bir CDN sağlayıcısı kesintiye uğradığında trafik otomatik olarak diğerine yönlenir. İkincisi performans: farklı bölgelerdeki kullanıcılara o bölgeye daha yakın CDN sunucularından içerik sunulur. DNS bu iki hedefe farklı mekanizmalarla yanıt verir — her iki motivasyon için aynı DNS stratejisi uygulanmaz; hangisinin öncelikli olduğunu anlamadan yapılandırmaya başlamak, tasarımı başından çözdürür.

Bu yazıda çoklu CDN mimarisinde DNS'in hangi yöntemleri desteklediğini, bu yöntemlerin nasıl birbirinden farklılaştığını ve her birinin hangi senaryoda anlamlı olduğunu ele alıyoruz.

DNS traffic steering: temel yöntemler ve farkları

DNS katmanındaki trafik yönlendirme, sorgulayan istemciye hangi IP adresinin döndürüleceğini değiştirmek üzerine kuruludur. Standart DNS bu konuda oldukça kısıtlıdır: bir A kaydı belirli bir IP adresine işaret eder ve bu yanıt tüm sorgulara aynı şekilde verilir. Trafik yönlendirme bu monotonluğu kıran özelliklerdir ve genellikle DNS sağlayıcısının platform özelliklerine bağlıdır.

Weighted round-robin, aynı domain için birden fazla A kaydı tanımlamayı ve bu kayıtlara farklı ağırlıklar atamayı sağlar. Standart DNS, birden fazla A kaydı dönüldüğünde genellikle hepsini döndürür ve istemci birini seçer — bu basit round-robin'dir. Ağırlıklı round-robin ise sağlayıcı düzeyinde uygulanır: bazı sağlayıcılar sorgu başına hangi IP'nin döndürüleceğini ağırlık oranına göre belirler. %70 trafik birinci CDN'e, %30 ikinci CDN'e gidecekse ağırlıklar buna göre ayarlanır. Bu yöntem A/B testi ve kademeli geçiş için de kullanılabilir.

; Ağırlıklı kayıtlar sağlayıcı panelinde tanımlanır;
; DNS sorgusu sağlayıcının ağırlık mantığına göre yanıtlanır.

; Kavramsal gösterim:
sirket.com.  300  IN  A  203.0.113.10   ; CDN-A — ağırlık 70
sirket.com.  300  IN  A  198.51.100.20  ; CDN-B — ağırlık 30

; dig sorgusunda her seferinde farklı IP dönebilir:
$ dig sirket.com A +short
203.0.113.10   ; %70 olasılıkla CDN-A
$ dig sirket.com A +short
198.51.100.20  ; %30 olasılıkla CDN-B

GeoDNS, sorgunun kaynaklandığı coğrafi konuma göre farklı IP adresi döndürür. Avrupa'dan gelen sorgu Avrupa'daki CDN PoP'una, Asya'dan gelen sorgu Asya CDN'ine yönlenir. GeoDNS, istemcinin IP adresinden coğrafi konumu tahmin eder ve coğrafyaya göre ayrılmış kayıt kümelerini döndürür. Bu yöntem performans odaklı çoklu CDN mimarilerinde en yaygın yaklaşımdır; anycast'in aksine coğrafi segmentasyon DNS katmanında elle yönetilir.

Latency-based routing, sorgunun hangi sağlayıcıdan daha hızlı yanıt alacağını ölçerek yönlendirme yapar. AWS Route 53'ün latency routing politikası bu yöntemi uygular: Route 53, farklı AWS bölgelerine olan gecikmeyi periyodik olarak ölçer ve her sorgu için en düşük gecikme süreli bölgeye yönlendirir. Bu yöntem, coğrafi konumdan bağımsız olarak gerçek ağ performansına göre karar verir.

Failover DNS: health check entegrasyonu ve otomatik yönlendirme

Çoklu CDN mimarisinin dayanıklılık boyutu failover mekanizmasına dayanır. DNS failover, birincil kaynağın erişilemez hale gelmesi durumunda yedek kaynağa otomatik geçiş yapar. Bu mekanizmanın çalışabilmesi için DNS sağlayıcısının health check özelliğini desteklemesi ve bu kontrolleri DNS yanıtlarıyla ilişkilendirmesi gerekir.

Health check, DNS sağlayıcısının belirli aralıklarla birincil kaynağa (CDN uç noktası veya origin IP) HTTP, HTTPS veya TCP bağlantısı kurarak erişilebilirliğini doğrulamasıdır. Birincil kaynak ardışık birkaç health check'te yanıt vermezse sağlayıcı o kaynağı "unhealthy" olarak işaretler ve gelen sorgulara artık o IP'yi döndürmez; bunun yerine yedek olarak tanımlanan adres döndürülür.

; Birincil kayıt — health check bağlı:
sirket.com.  60   IN  A  203.0.113.10   ; CDN-A (primary, health check: OK)

; Birincil erişilemez olduğunda yedek devreye girer:
sirket.com.  60   IN  A  198.51.100.20  ; CDN-B (failover)

; Health check başarısız olduğunda:
; CDN-A kaydı DNS yanıtından kaldırılır
; Tüm sorgulara CDN-B IP'si döndürülür
; CDN-A iyileşince otomatik olarak yeniden eklenir

Failover senaryosunda TTL değeri kritiktir. Birincil kaynak devre dışı kaldığında, önbelleklerdeki eski TTL süresi dolmadan geçiş tamamlanamaz. 3600 saniyelik TTL ile yapılandırılmış bir failover, birincil kaynak düştükten sonra saatlerce eski IP döndürmeye devam edebilir. Bu nedenle failover için kullanılan kayıtların TTL değeri genellikle 30-60 saniye olarak ayarlanır — bu düşük TTL, normal operasyon sırasında DNS sunucusuna ek yük bindirse de kesinti anında hızlı geçiş sağlar. TTL değerini optimize etmek, failover hızı ile DNS altyapı yükü arasındaki dengeyi bulmaktır.

CNAME zinciri ve çoklu CDN — apex domain kısıtı

Çoklu CDN yapılandırmalarında sık karşılaşılan bir sorun, apex domain (sirket.com gibi @ kaydı) için CNAME kullanamama kısıtıdır. RFC 1912 uyarınca, zone apex'ine CNAME konulamaz çünkü zone apex'inde SOA ve NS kayıtları bulunmak zorundadır; CNAME ise aynı isim için başka kayıt olamayacağını belirtir.

CDN sağlayıcıları genellikle origin IP yerine bir hostname sağlar: örneğin sirket.cdn-a.net. Alt domain'ler için bu hostname'e CNAME vermek sorunsuz çalışır. Ama sirket.com için CNAME vermek RFC kısıtına çarpar. Bu durumun üç çözümü vardır.

Birincisi, CNAME flattening destekleyen bir DNS sağlayıcısı kullanmaktır. CNAME flattening, DNS sağlayıcısının zone apex'ine girilen CNAME hedefini sorgulama anında A kaydına çevirmesidir; dışarıya A kaydı döner, RFC kısıtı ihlal edilmez. Cloudflare, AWS Route 53 (ALIAS kaydıyla) ve NS1 bu özelliği farklı isimlerle destekler.

İkincisi, ALIAS veya ANAME kaydı kullanmaktır. Bu kayıt türleri CNAME flattening ile aynı mantığı farklı bir kayıt tipiyle uygular; bazı DNS sağlayıcıları CNAME yerine bu tipleri tercih eder.

Üçüncüsü, apex domain için doğrudan birden fazla A kaydı tanımlamaktır. Eğer CDN sağlayıcınız statik IP sağlıyorsa (bazı enterprise CDN'ler bunu destekler), IP'leri doğrudan A kaydına yazabilirsiniz. Ancak CDN IP'leri dinamik değişebileceğinden bu yöntem her zaman güvenilir değildir.

; ALIAS kaydı destekleyen sağlayıcıda apex domain için:
sirket.com.  300  IN  ALIAS  sirket.cdn-a.net.
; veya weighted/failover policy ile:
sirket.com.  300  IN  ALIAS  sirket.cdn-a.net.  ; primary, weight 70
sirket.com.  300  IN  ALIAS  sirket.cdn-b.net.  ; secondary, weight 30

; Alt domain için CNAME (kısıtsız):
www.sirket.com.  300  IN  CNAME  sirket.cdn-a.net.

CDN geçişinde DNS stratejisi ve geçiş penceresi yönetimi

Mevcut tek CDN yapısından çoklu CDN mimarisine geçiş, standart DNS geçişinden farklı bir planlama gerektirir. Sadece bir IP'yi değiştirmek değil, yeni bir trafik dağıtım mantığı kurmak söz konusudur.

Geçişin ilk adımı, yeni CDN sağlayıcısını yapılandırmak ve eski sağlayıcıyla paralel test etmektir. Yeni CDN, eski sağlayıcı aktifken arka planda origin'den içerik çekip çekemediği, önbellekleme davranışı ve SSL sertifikası durumu test edilir. Yeni sağlayıcı hazır olana kadar DNS'e dokunulmaz.

İkinci adımda mevcut A kaydının TTL değeri düşürülür — 48 saat öncesinden 300 saniyeye indirilir, mevcut TTL kadar beklenir. Ardından weighted ya da failover yapılandırması devreye alınır: yeni CDN düşük ağırlıkla (örneğin %10) sisteme dahil edilir. Sorun çıkmazsa ağırlık kademeli olarak artırılır.

; Aşama 1 — Yeni CDN düşük ağırlıkla test:
sirket.com.  300  IN  A  203.0.113.10   ; CDN-A (eski) — ağırlık 90
sirket.com.  300  IN  A  198.51.100.20  ; CDN-B (yeni) — ağırlık 10

; Aşama 2 — Sorun yoksa ağırlık artırılır:
sirket.com.  300  IN  A  203.0.113.10   ; CDN-A — ağırlık 50
sirket.com.  300  IN  A  198.51.100.20  ; CDN-B — ağırlık 50

; Aşama 3 — Çoklu CDN kalıcı yapı:
sirket.com.  300  IN  A  203.0.113.10   ; CDN-A — primary (failover)
sirket.com.  300  IN  A  198.51.100.20  ; CDN-B — secondary (failover)

Bu kademeli yaklaşımın kritik avantajı, sorun çıktığında geri dönüş kolaylığıdır. TTL 300 saniyeyse yeni CDN'i sıfıra indirmek ve trafiğin tamamını eski sağlayıcıya yönlendirmek 5 dakika içinde tamamlanabilir. DNS propagasyonu düşük TTL sayesinde hızlanır.

Çoklu origin sunucu yapısında DNS — CDN olmadan yük dağıtımı

Bazı mimariler CDN kullanmadan çoklu origin sunucuyla çalışır: birden fazla fiziksel ya da sanal sunucu aynı içeriği sunar ve DNS bu sunucular arasında trafiği dağıtır. Bu yapı daha düşük gecikme gerektiren, CDN önbelleklemesinden yararlanamayan dinamik içerikler için tercih edilebilir.

Standart round-robin DNS, bu yapının en basit halidir: birden fazla A kaydı tanımlanır, DNS sunucusu sorgulara bu IP'leri sırayla döndürür. Basit ama kör bir yöntemdir — bir sunucu devre dışı kalsa bile DNS o IP'yi döndürmeye devam eder. Health check entegrasyonu olmadan round-robin failover sağlamaz.

Daha sağlam yapı için DNS sağlayıcısının health check özelliği devreye alınır. Her origin sunucu için ayrı bir subdomain tanımlanır (örneğin origin1.sirket.com, origin2.sirket.com), her birine health check bağlanır ve ana domain bunları CNAME ya da ALIAS üzerinden işaret eder. Bir origin düştüğünde DNS onu yanıttan çıkarır; kalan origin'ler trafiği paylaşır.

; Her origin için subdomain:
origin1.sirket.com.  60  IN  A  93.184.216.10   ; sunucu 1
origin2.sirket.com.  60  IN  A  93.184.216.11   ; sunucu 2
origin3.sirket.com.  60  IN  A  93.184.216.12   ; sunucu 3

; Ana domain — weighted veya failover ile üç origin'e dağıtım:
sirket.com.  60  IN  A  93.184.216.10   ; origin1 — ağırlık 33
sirket.com.  60  IN  A  93.184.216.11   ; origin2 — ağırlık 33
sirket.com.  60  IN  A  93.184.216.12   ; origin3 — ağırlık 33
; health check bağlı: unhealthy origin DNS yanıtından çıkar

Bu yapının bir sınırı vardır: DNS yük dağıtımı sunucu başına gerçek trafik yükünü bilemez. Bazı kullanıcılar çok sayıda istek yaparken bazıları çok az yaparsa DNS'in "eşit" dağıttığı görünür ama gerçekte yük dengesizdir. Uygulama katmanı yük dengeleyicisi (L7 load balancer) bu sorunu çözer; DNS, trafiği yük dengeleyiciye yönlendirirken yük dengeleyici sunucular arasındaki gerçek dağıtımı yönetir.

Çoklu CDN mimarisinde DNS sağlayıcısı seçimi

Çoklu CDN ya da çoklu origin yapısının DNS katmanı için standart yetkili DNS yeterli değildir. Weighted routing, GeoDNS, health check ve failover özelliklerinin tamamını destekleyen bir sağlayıcı gerekir.

AWS Route 53, bu özelliklerin tamamını "routing policy" adı altında sunar: simple, weighted, latency-based, failover, geolocation ve multivalue routing politikaları ayrı ayrı yapılandırılabilir. Aynı domain için farklı politikalar, policy record zincirleme ile birleştirilebilir. NS1 ve Dyn gibi enterprise DNS sağlayıcıları da benzer filtreleme ve yönlendirme özelliklerine sahiptir. Cloudflare DNS, weighted round-robin ve health check özelliklerini destekler; GeoDNS ise Cloudflare Load Balancing ürünü aracılığıyla sunulur ve ayrı ücretlendirilir.

Standart yetkili DNS sağlayıcılarının çoğu bu özellikleri sunmaz. Bu nedenle çoklu CDN mimarisi planlanıyorken DNS sağlayıcısı seçimi, CDN sağlayıcısı seçiminden önce gelir — doğru DNS sağlayıcısı olmadan trafik yönlendirme mantığı kurulamaz.

Çoklu CDN ve çoklu origin yapısında DNS, pasif bir altyapı bileşeni olmaktan çıkar; trafik yönetiminin aktif bir parçası haline gelir. Weighted routing, GeoDNS, health check ve failover birlikte kullanıldığında DNS katmanı tek başına önemli bir dayanıklılık ve performans katkısı sağlar. Ama bu mekanizmaların her birinin kendi trade-off'u vardır: düşük TTL DNS sunucusuna ek yük bindirir, health check aralığı failover hızını belirler, GeoDNS coğrafi sınıflandırmanın isabetine bağımlıdır. Bu sınırları önceden anlamak, mimarinin gerçek bir güvenceye mi yoksa kağıt üzerindeki bir dayanıklılık varsayımına mı dayandığını belirler.