DNS Load Balancing: Round Robin ve Weighted Routing Nasıl Çalışır?

DNS ile yük dağıtımı, ilk bakışta basit görünen ama uygulamada beklenmedik sorunlar çıkarabilen bir konudur. Birden fazla sunucuya sahip bir yapıda DNS round robin, trafiği dağıtmak için hızlıca başvurulan ilk yöntemdir; kurulum gerektirmez, ek bir altyapı maliyeti yoktur ve hemen devreye alınabilir; kayıt tipi ise birden fazla A kaydıdır. Peki bu yeterli midir?

Round robin her zaman işe yaramaz. Özellikle oturum tutarlılığı gereken uygulamalarda veya sunuculardan biri çöktüğünde round robin'in sınırları çok net ortaya çıkar; sağlık sinyali failover DNS katmanında durur. DNS'in kendi mimarisi, bu dağıtım yönteminin neden sağlıklı bir yük dengeleyicinin yerini tutamayacağını açıklar.

Weighted routing ve Cloudflare Load Balancer gibi araçlar, round robin'in açık bıraktığı boşlukları kapatmak için tasarlanmıştır; çok hedefli dağıtım çoklu CDN stratejisiyle aynı sorunu paylaşır. Hangisini nerede kullanacağınıza karar vermek için önce her yöntemin nasıl çalıştığını, nerede takıldığını ve gerçekte ne kadar güvenilir olduğunu anlamak gerekir.

DNS Round Robin Nasıl Çalışır?

DNS round robin, aynı alan adına birden fazla A kaydı eklenerek oluşturulur. Bir istemci bu alan adını sorguladığında, yetkili nameserver kayıtları sırayla döner; bir sonraki sorguda sıra değişir. Böylece farklı istemciler, teorik olarak farklı IP adreslerine yönlendirilmiş olur.

Kurulum gerçekten basittir. app.example.com için üç sunucu kullanmak istiyorsanız üç ayrı A kaydı eklersiniz:

app.example.com  A  203.0.113.10  TTL 60
app.example.com  A  203.0.113.20  TTL 60
app.example.com  A  203.0.113.30  TTL 60

Nameserver her sorguda bu listeyi farklı sırayla döner. İstemciler listedeki ilk IP'ye bağlanmaya çalışır, bu da dağıtımı sağlar. Ek bir yazılım, proxy veya altyapı maliyeti yoktur.

Ancak bu dağıtım mekanizması nameserver düzeyinde çalışır. Gerçek yük dağıtımını siz değil, istemcilerin DNS yanıtını nasıl kullandığı belirler. Bu önemli bir ayrımdır ve round robin'in temel kırılganlığı burada başlar.

TTL ve DNS Önbelleği: Round Robin'in Görünmez Sorunu

DNS round robin'in en büyük problemi, sizin kontrolünüzde olmayan bir katmanda yaşanır: önbellek.

İstemciler DNS yanıtını aldıktan sonra o IP'yi TTL süresi boyunca önbellekte saklar. Bir kullanıcı app.example.com'u sorguladı ve 203.0.113.10'u aldı; TTL 300 saniyeyse sonraki 5 dakika boyunca her isteği bu IP'ye gider. Bu süre içinde aynı sunucuya bağlı kalır, diğer sunuculara hiç gitmez.

Daha büyük sorun şuradadır: her istemci kendi önbelleğini yönetir. Resolver katmanı önbelleği temizlemeden yeni sırayı görmez. Kurumsal ağlarda DNS resolverlar TTL süresini kendi politikalarına göre uzatabilir. Bazı işletim sistemleri veya tarayıcılar kaydı belirtilen süreden çok daha uzun tutar. Yük dağıtımı tahmin ettiğiniz gibi gerçekleşmez; bir sunucu çok daha fazla trafik alırken diğeri boşta kalabilir.

Düşük TTL kullanmak bu sorunu hafifletir ama tamamen çözmez. TTL'i 30 saniyeye indirirseniz nameserver yükünüz artar, önbellekleme verimliliği düşer ve her sorgu için ekstra gecikme oluşur. Üstelik bazı resolverlar minimum TTL sınırı uygular; 30 saniyelik kaydı 60 veya 120 saniye boyunca önbellekte tutabilirler.

Oturum Tutarlılığı: Round Robin Nerede Çöker?

Durumsuz (stateless) uygulamalar için round robin makul ölçüde çalışır. Oturum bilgisi taşımayan bir API veya statik içerik sunucusu düşünün; hangi sunucuya gidilirse gitsin yanıt aynıdır. Burada round robin kabul edilebilir bir yöntemdir.

Oturum tutarlılığı gereken uygulamalarda tablo değişir. Bir kullanıcı giriş yaptı, oturumu Sunucu A'da saklandı. Bir sonraki istekte DNS önbelleği tazelendi ve istemci Sunucu B'ye yönlendi; oturum orada yok, kullanıcı çıkış yapmış gibi görünür. Uygulamanız bu durumu yönetmiyorsa kullanıcı deneyimi ciddi biçimde bozulur.

Sticky session, bazı yük dengeleyicilerin sunduğu bir özelliktir - DNS round robin'in sunduğu değil. Round robin bu soruya yanıt veremez.

Failover da round robin ile güvenilir biçimde yapılamaz. Sunuculardan biri devre dışı kalırsa DNS hala o IP'yi listede tutmaya devam eder. İstemciler devre dışı sunucuya bağlanmaya çalışır, bağlantı zaman aşımına uğrar, sonra listedeki bir sonraki IP'ye geçer. Bu süreç saniyelerce sürebilir ve kullanıcı tarafından açık bir hata olarak görülür. Yeniden bağlanma süresi uygulamanızın TCP zaman aşımı ayarına bağlıdır ve çoğu durumda 10 ila 30 saniye arasında değişir.

Weighted Routing ile Trafik Ağırlıklandırma

Weighted routing, round robin'in saf eşit dağıtımının ötesine geçer. Her kayıt için bir ağırlık (weight) değeri belirtirsiniz; DNS resolver trafiği bu ağırlık oranına göre dağıtır.

AWS Route 53 ile örnek bir yapı kuralım. Ağırlıklı routing politikası seçildiğinde aynı kayıt için farklı değerler atanır:

app.example.com  A  203.0.113.10  Weight: 70
app.example.com  A  203.0.113.20  Weight: 20
app.example.com  A  203.0.113.30  Weight: 10

Bu yapıda trafiğin yaklaşık yüzde yetmişi birinci sunucuya, yüzde yirmisi ikinciye, yüzde onu üçüncüye gider. Yeni bir sunucu devreye alırken düşük ağırlıkla başlayıp kademeli artırabilirsiniz; bu yönteme genellikle kademeli dağıtım (gradual rollout) denir. Bir sunucuyu bakıma almadan önce ağırlığını sıfıra indirmek, trafiği kesintisiz kaydırmanın en pratik yollarından biridir.

Route 53, weighted routing'i health check ile birleştirebilir. Bir kaydın health check'i başarısız olursa, ağırlığı sıfır olmasa bile o kayda trafik yönlendirilmez. Bu, round robin'in yapamadığı otomatik failover'ı mümkün kılar. Google Cloud DNS de benzer bir ağırlıklı yönlendirme özelliği sunar; zone düzeyinde politika kayıtlarıyla trafik dağıtımı yapılandırılabilir ve health check entegrasyonu eklenebilir.

Cloudflare Load Balancer ile Aktif Sağlık Kontrolü

Cloudflare Load Balancer, DNS tabanlı yük dağıtımını bir adım ileriye taşır: pasif bir kayıt listesi değil, aktif sağlık kontrolü yapan bir sistem sunar.

Pool yapısı şöyle çalışır: sunucularınızı bir veya birden fazla pool'a atarsınız, her pool'a origin eklenir ve Cloudflare belirlediğiniz aralıklarla bu originlere HTTP veya TCP sağlık kontrolü yapar. Bir origin sağlık kontrolünü geçemezse pool dışına alınır; trafik sağlıklı originlere yönlenir. Tüm pool sağlıksız hale gelirse yedek pool devreye girer.

Pool: Production
  Origin A: 203.0.113.10  Weight: 1
  Origin B: 203.0.113.20  Weight: 1

Pool: Fallback
  Origin C: 203.0.113.30  Weight: 1

Sağlık kontrolü başarısız olan origin, döngüden otomatik çıkar; diğer originler yükü paylaşır. Devre dışı kalan origin sağlığını yeniden kazandığında tekrar aktif olur. Tüm bu süreç sizin müdahaleniz olmadan, DNS düzeyinde gerçekleşir.

Coğrafi yönlendirme (geo-steering) de Cloudflare Load Balancer'ın sunduğu özelliklerden biridir. Avrupa'dan gelen istekler yakın pool'a, Amerika'dan gelenler farklı bir pool'a yönlendirilebilir. Bu hem gecikmeyi azaltır hem de bölgesel kesintilerin etkisini sınırlar. DigitalOcean gibi cloud platformları kendi DNS yönetim panellerinde temel yönlendirme seçenekleri sunmaya başlamış olsa da Cloudflare'in sağlık kontrolü mekanizması daha ayrıntılı yapılandırma imkanı verir.

Round Robin'i Ne Zaman Kullanmalı, Ne Zaman Terk Etmeli?

Her durumda tam özellikli yük dengeleyici kurmak gerekmez. Round robin hala geçerli bir seçenektir, doğru senaryoda.

Round robin mantıklıdır; stateless ve oturum bilgisi taşımayan hizmetler için, DNS tabanlı coğrafi yedeklilik amacıyla iki farklı veri merkezini aynı isimle erişilebilir kılmak istediğinizde ve yatay ölçeklenen her isteği bağımsız işleyen API servislerinde kabul edilebilir bir başlangıç noktasıdır.

Round robin yetersiz kalır; oturum tutarlılığı gerektiren uygulamalar için, otomatik failover beklentiniz varsa, kademeli dağıtım (canary release veya blue-green deployment) planınız varsa ve farklı kapasitelerde sunucularınız varsa yükü orantılı dağıtmak istediğinizde.

Seçim basittir. Bir sunucu çöktüğünde otomatik olarak devre dışı alınmasını bekliyorsanız DNS round robin size bunu vermez; health check destekli bir çözüme geçmeniz gerekir. Vercel veya Netlify gibi platformlarda custom domain kurulumu yaparken bu platformların kendi load balancing altyapısı zaten devrede olduğundan, bu sunuculara ekstra round robin kaydı eklemeniz anlamsız hale gelir; platformun kendi sistemi trafiği yönetir.

Round Robin'den Weighted Routing'e Geçiş

Round robin kullanıyorsanız ve daha sağlıklı bir yük dağıtımına geçmek istiyorsanız, bu geçiş planlı yapılmalıdır. TTL süresi geçişin hızını doğrudan belirler.

Önce mevcut TTL değerini düşürün. Geçişten en az 24 saat önce TTL'i 300 saniyeye veya daha düşük bir değere indirin. Bu sayede geçiş sonrasında eski kayıtların önbellekte tutulma süresi kısalır ve yeni yapıya geçiş daha hızlı tamamlanır.

Yeni routing politikasını paralel olarak test edin. Weighted routing veya load balancer yapısını ayrı bir subdomain üzerinde kurup lb.example.com gibi bir isim kullanarak sağlık kontrollerinin beklendiği gibi çalıştığını doğrulayın. Tüm originler sağlıklı görünüyorsa ve ağırlık dağıtımı doğruysa asıl alan adına geçebilirsiniz.

Geçiş sırasında her iki yapı da çalışıyor olabilir; eski round robin kayıtları hala bazı istemcilerin önbelleğindedir. TTL süresi dolana kadar her iki yapıdan da trafik gelebileceğini hesaba katarak log takibi yapın.

Geçişi tamamladıktan sonra eski A kayıtlarını silin. Round robin kayıtları ile weighted routing kayıtları aynı anda var olmamalıdır; aksi halde hangi yapının trafiği yönettiği belirsizleşir ve sağlık kontrolü mantığı tutarsız sonuçlar verebilir. Azure DNS üzerinde Traffic Manager ile entegre weighted routing, özellikle Microsoft ekosisteminde çok kiracılı yapılar için yaygın bir tercihdir ve geçiş sürecinde zone bazında yönetimi kolaylaştırır.

DNS load balancing, altyapı karmaşıklığını artırmadan trafik dağıtımı sağlamanın cazip bir yolu olarak görünür. Round robin bu cazibeyi en net biçimde temsil eder; ancak güvenilirlik, oturum tutarlılığı ve failover gibi ihtiyaçlar söz konusu olduğunda bu yaklaşımın sınırları belirginleşir.

Weighted routing ve Cloudflare Load Balancer gibi araçlar, bu sınırları aşmak için DNS'in üzerine ek bir kontrol katmanı inşa eder. Sağlık kontrolü, ağırlıklandırma ve otomatik failover, round robin'in veremediği garantileri sağlar; bu garantilere ihtiyaç duyup duymadığınızı ise uygulamanızın oturum yönetimi ve kesinti toleransı belirler.

Hangi yapıyı seçeceğinize karar verirken şu soruyu sorun: sunuculardan biri devre dışı kalırsa kullanıcılar ne görmeli? Yanıt "hiçbir şey farketmemeli" ise round robin yeterli değildir.