DNS ile Yük Dengeleme Nedir

Bir web sitesi büyüdükçe tek bir sunucu er ya da geç yetmemeye başlar. CPU tavan yapar, bellek dolar, aynı anda gelen bağlantılar birbirini bekletir ve sayfa açılış süreleri saniyelerle ölçülür hâle gelir. Bu noktada ilk akla gelen çözüm sunucuyu büyütmektir; ama dikey büyümenin de bir sınırı vardır ve tek sunucu her zaman tek arıza noktasıdır. Asıl ölçeklenebilir yaklaşım, yükü birden çok sunucuya yaymaktır. İşte bu dağıtımı yapmanın en eski ve en basit yollarından biri, işi tam olarak alan adı çözümlemesinin yapıldığı DNS katmanında halletmektir.

DNS ile yük dengeleme, bir alan adına birden fazla sunucu IP'si tanımlayıp gelen istekleri bu IP'ler arasında paylaştırma tekniğidir. Ziyaretçi siteniz.com yazdığında tarayıcı önce DNS'e sorar, sizin ad sunucunuz da her sorguya farklı bir IP döndürerek trafiği farklı makinelere yönlendirir. Kurmak için pahalı bir donanım ya da ek bir yazılım katmanı gerekmez; sadece DNS kayıtlarınızı doğru yapılandırmanız yeterlidir. Ancak bu basitliğin bir bedeli vardır: DNS önbelleği ve TTL yüzünden dağıtım hiçbir zaman matematiksel olarak eşit olmaz ve sunucu çökünce sistem bunu anında fark edemez. Bu rehberde DNS tabanlı dengelemenin nasıl çalıştığını, round-robin, ağırlıklı dağıtım ve GeoDNS yöntemlerinin farklarını ve bu yaklaşımın uygulama katmanı dengeleyicilerinden nerede ayrıldığını pratik örneklerle anlatıyorum.

DNS Katmanında Yük Dengeleme Nasıl Çalışır#

Klasik bir DNS kaydında bir alan adına tek bir A kaydı, yani tek bir IPv4 adresi tanımlarsınız. DNS tabanlı dengelemenin temel fikri ise aynı isme birden fazla A kaydı eklemektir. Ad sunucusu bu isme sorulduğunda kayıt kümesindeki IP'leri sıra değiştirerek döndürür; böylece farklı ziyaretçiler farklı sunuculara gider.

Aşağıdaki gibi bir zone dosyası, www için üç ayrı sunucuyu işaret eden üç A kaydı içerir:

; siteniz.com zone dosyası
www     IN  A   203.0.113.10
www     IN  A   203.0.113.11
www     IN  A   203.0.113.12

Bir istemci bu isme sorduğunda DNS yanıtı üç IP'yi de içerir, ama sıraları rastgele döner. İşin püf noktası şudur: istemci tarafındaki resolver, gelen listenin genellikle ilk IP'sini kullanır. Ad sunucusu her sorguda sırayı kaydırdığı için pratikte trafik üç sunucuya yayılır. dig ile arka arkaya sorgu attığınızda sıranın değiştiğini görebilirsiniz:

dig +short www.siteniz.com A
# 203.0.113.10
# 203.0.113.11
# 203.0.113.12

dig +short www.siteniz.com A
# 203.0.113.11
# 203.0.113.12
# 203.0.113.10

Burada önemli olan, dengelemenin hiçbir trafik gerçekten sizin altyapınıza ulaşmadan, sadece isim çözümleme aşamasında yapılıyor olmasıdır. Bu, DNS dengelemesinin hem en büyük avantajı hem de en büyük kısıtıdır: son derece hafif ve dağıtıktır, ama uygulama trafiğini "görmediği" için akıllı kararlar veremez. DNS'in ne olduğunu ve kayıt türlerini hatırlamak isterseniz DNS nedir yazısı temel kavramları toparlıyor.

Round-Robin DNS ile Eşit Dağıtım#

En yaygın DNS dengeleme yöntemi round-robin'dir. Yukarıdaki örnek tam olarak budur: ad sunucusu kayıt kümesini her sorguda döndürerek IP'leri sırayla en üste taşır. Teorik olarak N sunucu varsa her biri sorguların yaklaşık 1/N'ini karşılar. Kurulumu dakikalar sürer ve neredeyse her DNS sağlayıcısı bunu doğrudan destekler.

Round-robin'in en güçlü yanı, sıfır maliyetle yatay ölçeklenme sağlamasıdır. Trafiğiniz arttıkça yeni bir sunucu kurar, aynı isme yeni bir A kaydı eklersiniz ve dağıtıma dahil olur. Ekşi yanı ise "kör" olmasıdır. Round-robin hiçbir sunucunun yükünü, sağlığını ya da yanıt süresini bilmez. Sırf sıradaki IP olduğu için, saniyede binlerce isteği zar zor kaldıran bir sunucuya da boşta bekleyen bir sunucuya da eşit trafik gönderir.

İkinci bir sorun oturum tutarlılığıdır. Bir kullanıcı ilk isteğinde 203.0.113.10'a, DNS önbelleği yenilenince bir sonraki isteğinde 203.0.113.11'e düşebilir. Oturum bilgisini sunucunun kendi belleğinde tutuyorsanız kullanıcı aniden çıkış yapmış gibi olur. Bu yüzden round-robin DNS ile çalışan mimarilerde oturumu paylaşımlı bir depoda tutmak neredeyse zorunludur:

; PHP oturumlarını Redis'te merkezileştirme
session.save_handler = redis
session.save_path = "tcp://10.0.0.5:6379?auth=GucluParola"

Oturumlar merkezi bir Redis ya da veritabanında durursa hangi sunucuya düşerseniz düşün aynı oturumu görürsünüz ve round-robin'in "kullanıcıyı fırlatma" sorunu ortadan kalkar. WordPress ya da benzeri uygulamalar çalıştırıyorsanız WordPress hosting tarafında object cache ve merkezi oturum yapılandırmasını en baştan kurgulamak bu tür sürprizleri engeller.

Ağırlıklı (Weighted) DNS Dağıtımı#

Sunucularınızın hepsi aynı güçte olmayabilir. Elinizde 8 çekirdekli güçlü bir makine ve yanında eski, 2 çekirdekli bir makine varsa ikisine eşit trafik göndermek mantıksızdır; güçlü sunucu boşta beklerken zayıf olan boğulur. Ağırlıklı DNS dağıtımı tam da bunu çözer: her kayda bir ağırlık verir ve trafik bu ağırlıklarla orantılı dağıtılır.

Klasik zone dosyaları ağırlığı doğrudan desteklemez, ama yönetilen DNS servisleri (Route 53, Cloudflare, NS1 ve benzerleri) bunu bir özellik olarak sunar. Mantık şudur: güçlü sunucuya ağırlık 3, zayıf olana 1 verirseniz, DNS yanıtlarının dörtte üçü güçlü sunucuyu, dörtte biri zayıf sunucuyu işaret eder. Aşağıda kavramsal bir yapılandırma görüyorsunuz:

# Ağırlıklı DNS kayıt seti (kavramsal)
kayitlar:
  - ad: www
    ip: 203.0.113.10   # 8 çekirdekli
    agirlik: 3
  - ad: www
    ip: 203.0.113.11   # 2 çekirdekli
    agirlik: 1
# Beklenen dağılım -> %75 güçlü sunucu, %25 zayıf sunucu

Ağırlıklı dağıtımın çok pratik bir kullanımı da kademeli geçiştir. Yeni bir sunucu ya da yeni bir kod sürümünü canlıya alırken ağırlığını başta çok düşük tutar (örneğin 20'ye 1), trafiğin küçük bir dilimini yeni tarafa yönlendirir ve sorun çıkmazsa ağırlığı yavaşça artırırsınız. Bu, riskli bir dağıtımı bütün kullanıcılara aynı anda açmak yerine kontrollü bir "canary" yayınına dönüştürür.

Yine de ağırlıklı DNS'in de sınırı vardır: ağırlık statiktir. Sunucunun o anki gerçek yükünü değil, sizin önceden tahmin ettiğiniz kapasiteyi yansıtır. Anlık yük patlamalarına kendiliğinden uyum sağlamaz.

GeoDNS ile Coğrafi Yönlendirme#

GeoDNS, dağıtımı sunucu kapasitesine değil ziyaretçinin coğrafi konumuna göre yapar. Mantık nettir: kullanıcıyı fiziksel olarak kendisine en yakın sunucuya yönlendirirsen paketlerin katetmesi gereken mesafe kısalır, gecikme (latency) düşer ve site daha hızlı açılır. İstanbul'daki bir kullanıcıyı Türkiye'deki sunucuya, Frankfurt'taki bir kullanıcıyı Almanya'daki sunucuya göndermek buna örnektir.

GeoDNS'te ad sunucusu, sorguyu gönderen resolver'ın IP'sine bakarak hangi kıtadan/ülkeden geldiğini tahmin eder ve o bölgeye atanmış IP'yi döndürür. Kavramsal olarak kural kümesi şöyle görünür:

; GeoDNS eşleme (kavramsal)
www  [TR]      A   203.0.113.10   ; Türkiye sunucusu
www  [EU]      A   198.51.100.20  ; Avrupa sunucusu
www  [DEFAULT] A   192.0.2.30     ; Eşleşme yoksa varsayılan

GeoDNS özellikle küresel bir kitleye hitap eden servisler ve içerik dağıtımı için değerlidir. Bir CDN'in temel yapı taşlarından biri de budur; kullanıcıyı en yakın kenar sunucusuna (edge) yönlendirme işi büyük ölçüde bu mantıkla döner. Cloudflare gibi bir CDN'in DNS ve önbellek katmanını nasıl birleştirdiğini merak ediyorsanız Cloudflare DNS ve CDN yazısı konuyu detaylandırıyor.

GeoDNS'in zayıf noktası, konum tahmininin resolver IP'sine dayanmasıdır. Kullanıcı, kendi bölgesinde olmayan bir genel DNS (örneğin uzaktaki bir kamu resolver'ı) kullanıyorsa GeoDNS onu yanlış bölgeye yönlendirebilir. EDNS Client Subnet gibi uzantılar bu sorunu azaltır ama tamamen ortadan kaldırmaz. Yine de ortalamada GeoDNS, küresel gecikmeyi ciddi biçimde düşürür.

TTL ve DNS Önbelleği Neden Tam Eşit Dağıtımı Engeller#

Buraya kadar anlattığım her yöntemin ortak bir zayıflığı var: DNS yanıtları önbelleğe alınır. Her A kaydının bir TTL'i (Time To Live) vardır ve bu süre boyunca ara resolver'lar ve işletim sistemleri o yanıtı yeniden sormadan kullanır. Yani ad sunucunuz IP'leri güzelce döndürse bile, aradaki önbellek katmanları bu dönüşü "dondurur".

Bunun somut etkisi şudur. Diyelim TTL'i 3600 saniye (1 saat) ayarladınız. Büyük bir kurumsal ağın resolver'ı bir kez sorgu yapıp 203.0.113.10'u aldığında, o ağdaki binlerce çalışan bir saat boyunca hep aynı sunucuya gider. Round-robin'in "sırayla dağıtma" mantığı bu ağ için tamamen devre dışı kalır. Bu yüzden gerçek dünyada DNS dengelemesi hiçbir zaman 1/N oranında pürüzsüz olmaz; belirli kaynaklardan gelen büyük öbekler tek bir sunucuya çakılır.

TTL'i düşürmek dağıtımı daha canlı hâle getirir ama bedava değildir:

; Düşük TTL -> daha hızlı yeniden dağıtım, ama daha çok DNS sorgusu
www  300  IN  A  203.0.113.10   ; 5 dakika
www  300  IN  A  203.0.113.11

Kritik nokta failover senaryosudur. Sunuculardan biri çökerse, DNS bunu otomatik bilmez; siz ölü IP'yi kayıttan elle ya da otomasyonla çıkarana kadar geçen sürede, hâlâ o IP önbellekte olan istemciler çöken sunucuya gitmeye devam eder. TTL ne kadar yüksekse bu "kör" pencere o kadar uzar. Bu yüzden DNS ile failover'a güvenen mimariler genellikle 30-60 saniye gibi düşük TTL'ler ve sağlık kontrolü yapabilen yönetilen bir DNS servisi kullanır. Sunucularınızın gerçekten ayakta olup olmadığını sürekli izlemek için Clou.TR panelindeki uptime uyarılarını da bu resmin bir parçası olarak düşünebilirsiniz; DNS tarafı ölü IP'yi düşürürken siz de anında haberdar olursunuz.

Sağlık Kontrolü ve Otomatik Failover#

Ham DNS round-robin'in en tehlikeli tarafı sağlık kontrolü yapmamasıdır. Bir A kaydı çöken bir sunucuyu gösteriyorsa, DNS onu sanki sağlıklıymış gibi trafiğe sokmaya devam eder ve kullanıcıların bir kısmı düzenli olarak hata alır. Bunu çözmek için "sağlık kontrollü DNS" (health-checked / failover DNS) gerekir.

Bu tür servisler, her IP'yi belirli aralıklarla (örneğin 30 saniyede bir) yoklar. Yoklama basit bir TCP bağlantısı ya da bir HTTP isteği olabilir. Bir HTTP sağlık uç noktası genelde şöyle sadeleştirilir:

# nginx: hafif bir sağlık kontrol uç noktası
location = /health {
    access_log off;
    add_header Content-Type text/plain;
    return 200 "ok\n";
}

Sağlık kontrollü DNS bu /health adresini düzenli yoklar; art arda birkaç kez başarısız cevap alırsa ilgili IP'yi kayıt kümesinden geçici olarak çıkarır ve trafiği yalnızca ayakta olan sunuculara yönlendirir. Sunucu geri geldiğinde kaydı otomatik yeniden ekler. Böylece round-robin'in körlüğü büyük ölçüde giderilir; yine de TTL/önbellek gecikmesi nedeniyle geçiş anlık değildir.

Aktif-pasif failover senaryosu da benzer mantıkla kurulur: birincil sunucu sağlıklıyken tüm trafik oraya gider, birincil çökerse DNS otomatik olarak yedek IP'ye geçer. Bu, coğrafi olarak dağıtılmış bir yedeklilik için basit ve etkili bir modeldir. Altyapınızın yedekliliğini planlarken düzenli yedekleme stratejisiyle bu failover mimarisini birlikte düşünmek, hem trafik hem de veri tarafında dayanıklılık sağlar.

DNS Dengelemesi ile Uygulama Katmanı Dengeleyici Farkı#

DNS dengelemesinin nerede biteceğini anlamanın en iyi yolu, onu uygulama katmanı (L4/L7) yük dengeleyicilerle karşılaştırmaktır. İkisi rakip değil, farklı katmanlarda çalışan tamamlayıcı araçlardır.

DNS dengelemesi, kullanıcı henüz sizin altyapınıza dokunmadan, sadece isim çözümleme aşamasında kararı verir. Trafiği görmez, oturumu bilmez, sunucunun anlık yükünü ölçemez ve verdiği karar TTL süresince önbellekte donar. Buna karşılık HAProxy ya da nginx gibi bir uygulama katmanı dengeleyici, her bağlantıyı gerçekten üzerinden geçirir; en az bağlantısı olan sunucuyu seçebilir, oturumu belirli bir sunucuya sabitleyebilir (sticky session), anlık sağlık kontrolü yapıp ölü sunucuyu milisaniyeler içinde devre dışı bırakabilir.

Tipik bir nginx upstream tanımı, bu akıllılığı somut gösterir:

upstream backend {
    least_conn;                        # en az bağlantısı olana yönlendir
    server 10.0.0.10:80 weight=3;      # güçlü sunucu
    server 10.0.0.11:80 weight=1;      # zayıf sunucu
    server 10.0.0.12:80 backup;        # yalnızca diğerleri çökerse
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Buradaki fark net: nginx least_conn ile o anki gerçek bağlantı sayısına bakar, backup ile pasif yedek tanımlar ve bir sunucu düştüğünde bir sonraki isteği anında sağlam sunucuya kaydırır. DNS bunların hiçbirini yapamaz. Karşılaştırma tablosu iki katmanı özetliyor:

Gerçek dünyadaki olgun mimariler ikisini katmanlar. DNS (özellikle GeoDNS) kullanıcıyı en yakın bölgeye yönlendirir; o bölgede bir uygulama katmanı dengeleyici de trafiği sunucular arasında akıllıca paylaştırır. Yani DNS "hangi veri merkezi" sorusuna, uygulama dengeleyici "o veri merkezinde hangi sunucu" sorusuna cevap verir. Bu iki katmanı doğru kurgulamak için sağlam bir sunucu altyapısı gerekir; VDS sunucu ya da genel sunucu seçenekleri, kendi dengeleyicinizi barındıracağınız esnek bir zemin sunar. Yapılandırmayı kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmetiyle bu kurulumu uzman ekibe bırakabilirsiniz.

DNS Yük Dengeleme Ne Zaman Doğru Seçim#

Her mimari her senaryo için ideal değildir. DNS dengelemesi, basit, dağıtık ve maliyetsiz bir yatay ölçekleme istediğinizde parlar. Coğrafi olarak dağıtılmış veri merkezleri arasında trafik yönlendirmek, aktif-pasif failover kurmak ya da birden çok bağımsız sunucuya kaba bir trafik paylaşımı yapmak için mükemmele yakındır. Ekstra bir donanım ya da tek arıza noktası oluşturan bir dengeleyici katmanı eklemeden ölçeklenebilirsiniz.

Öte yandan oturum tutarlılığının kritik olduğu, anlık yük dengesinin milisaniye hassasiyetinde gerektiği ya da bir sunucu çökünce sıfır kayıpla saniyeler içinde devreye girmesi beklenen sistemlerde tek başına DNS yetmez. Böyle durumlarda DNS'i sadece bölge/veri merkezi yönlendirmesi için kullanıp asıl dengelemeyi uygulama katmanına bırakmak doğru yaklaşımdır. Kısacası DNS dengelemesi bir başlangıç ve tamamlayıcı katmandır; büyüyen bir sistemde onu tek başına değil, daha akıllı bir dengeleyiciyle birlikte konumlandırmak gerekir. Kurumsal ölçekte trafik yönetiminizi güçlendirmek isterseniz WAF ve DDoS koruma gibi katmanları da bu resmin önüne eklemek, dağıtımın yanında güvenliği de sağlar.

Sıkça Sorulan Sorular#

DNS round-robin gerçekten trafiği eşit paylaştırır mı?#

Teoride eşit paylaştırmayı hedefler ama pratikte tam eşit olmaz. DNS önbelleği ve TTL nedeniyle büyük bir kurumsal ağ ya da genel bir resolver, tek bir sorgu sonucunu binlerce kullanıcı için TTL süresince yeniden kullanır. Bu yüzden trafik 1/N oranında pürüzsüz dağılmaz; belirli kaynaklardan gelen büyük öbekler tek bir sunucuda toplanabilir. DNS dengelemesini "kabaca dağıtır" diye düşünmek en doğrusudur.

DNS ile yük dengeleme için TTL değerini kaça ayarlamalıyım?#

Failover ve dağıtım tazeliğine ne kadar önem verdiğinize bağlıdır. Sunucu çökünce hızlı geçiş istiyorsanız 30-60 saniye gibi düşük değerler mantıklıdır çünkü ölü IP önbellekten çabuk düşer. Ancak düşük TTL, DNS sorgu sayısını ciddi biçimde artırır ve ad sunucularınıza yük bindirir. Değişikliğin nadir olduğu duran sistemlerde 3600 saniye yeterli olur; failover'a güveniyorsanız 60 saniye civarı iyi bir dengedir.

DNS dengelemesi sunucu çöktüğünde otomatik devre dışı bırakır mı?#

Ham DNS round-robin bunu yapmaz; çöken bir IP'yi sağlıklıymış gibi trafiğe sokmaya devam eder. Bu yeteneği kazanmak için sağlık kontrollü (health-checked) bir yönetilen DNS servisi kullanmanız gerekir. Bu servisler her IP'yi düzenli yoklar, art arda başarısız olan sunucuyu kayıt kümesinden otomatik çıkarır ve geri geldiğinde ekler. Yine de TTL/önbellek gecikmesi yüzünden geçiş anlık değil, birkaç saniyeden dakikalara kadar sürebilir.

GeoDNS mi round-robin mi kullanmalıyım?#

İkisi farklı sorunları çözer. Kullanıcılarınız tek bir ülkede yoğunlaşmışsa ve amaç sadece yükü sunuculara paylaştırmaksa round-robin ya da ağırlıklı dağıtım yeterlidir. Kullanıcı kitleniz küresel dağılmışsa ve gecikmeyi düşürmek önceliğinizse GeoDNS'i tercih edin; kullanıcıyı fiziksel olarak en yakın veri merkezine yönlendirir. Olgun kurulumlarda GeoDNS ile bölge seçilir, o bölgenin içinde de round-robin veya bir uygulama dengeleyici çalışır.

DNS dengelemesi uygulama katmanı dengeleyicinin yerini tutar mı?#

Hayır, ikisi farklı katmanlarda çalışan tamamlayıcı araçlardır. DNS dengelemesi kararı isim çözümleme anında verir; anlık yükü göremez, oturumu bilmez ve failover'ı TTL kadar gecikmelidir. HAProxy ya da nginx gibi bir uygulama dengeleyici her bağlantıyı gerçekten üzerinden geçirir, en az bağlantılı sunucuyu seçebilir, oturum sabitleyebilir ve ölü sunucuyu milisaniyeler içinde devre dışı bırakır. Sağlam mimariler genellikle DNS ile bölgeyi, uygulama dengeleyiciyle sunucuyu seçerek ikisini birlikte kullanır.

Kapanış#

DNS ile yük dengeleme, ölçeklenmenin en ucuz ve en dağıtık ilk adımıdır. Round-robin ile kaba bir paylaşım, ağırlıklı kayıtlarla kapasiteye duyarlı dağıtım ve GeoDNS ile coğrafi yönlendirme yaparsınız; ama TTL, önbellek ve sağlık kontrolü kısıtlarını her zaman hesaba katmanız gerekir. Gerçek dayanıklılık için DNS'i tek başına değil, uygulama katmanı bir dengeleyiciyle ve düzenli izlemeyle birlikte konumlandırmak en doğru yaklaşımdır.

Bu mimariyi kurmak için sağlam bir zemine ihtiyacınız var. Kendi yük dengeleyicinizi barındıracağınız esnek VDS ve sunucu çözümlerini inceleyebilir, yapılandırmayı uzmana bırakmak isterseniz sunucu yönetimi hizmetimizden yararlanabilir, alan adı ve DNS kayıtlarınızı tek panelden yönetmek için alan adı ve hosting paketlerimize göz atabilirsiniz. Clou.TR olarak, dağıtık ve dayanıklı bir altyapı kurmanın her adımında yanınızdayız.