Sunucu Yük Dengeleme (Load Balancing) Rehberi

Trafiğin belli saatlerde patlayıp bir tek sunucuyu dizlerinin üstüne çökerttiği anlar, çoğu sistem yöneticisinin tanıdığı bir manzaradır. İşte bu noktada gelen istekleri birden fazla arka uç sunucuya akıllıca dağıtan bir katman devreye girer ve hem yanıt süresini hem de kesintisizliği belirgin biçimde iyileştirir. Aşağıda bu katmanı sıfırdan kurarken karşınıza çıkacak kavramları, algoritmaları ve gerçek konfigürasyon örneklerini bir arada bulacaksınız.

Yük Dengeleme Tam Olarak Neyi Çözer?

Tek bir uygulama sunucusu hem CPU hem bellek hem de ağ bağlantısı açısından sonlu bir kaynaktır. Eş zamanlı istek sayısı bu sınırı aştığında kuyruk büyür, gecikme artar ve nihayetinde 5xx hataları görmeye başlarsınız. Yük dengeleyici, istekleri sağlıklı düğümler arasında bölüştürerek tek bir makineyi darboğaz olmaktan çıkarır. Yatay ölçeklemenin (yeni sunucu ekleyerek büyüme) pratikte uygulanabilir olmasının önkoşulu da budur.

• Yüksek erişilebilirlik: Bir düğüm düşse bile trafik ayakta kalan düğümlere yönlenir.
• Ölçeklenebilirlik: Talep arttıkça havuza sunucu eklemek, kodu değiştirmeden kapasiteyi büyütür.
• Bakım esnekliği: Bir sunucuyu güncellerken havuzdan çıkarıp işiniz bittikten sonra geri alabilirsiniz.

L4 ve L7: Hangi Katmanda Dağıtım?

Yük dengeleme kararı, OSI modelinin farklı katmanlarında verilebilir ve bu seçim performans ile esneklik dengenizi doğrudan belirler. Katman 4 (transport) dengeleyici yalnızca IP ve port bilgisine bakarak TCP/UDP akışını yönlendirir; içeriği açmadığı için hızlıdır ve daha az kaynak tüketir. Katman 7 (uygulama) dengeleyici ise HTTP başlıklarını, URL yolunu ve çerezleri okuyabildiği için /api trafiğini ayrı havuza, statik içeriği başka havuza gönderebilir.

Dağıtım Algoritmaları

İsteklerin hangi mantıkla bölüştürüleceği, beklediğiniz trafik desenine göre seçilmelidir. Yanlış algoritma, kağıt üstünde dengeli görünen ama gerçekte tek düğümü yoran bir kuruluma yol açabilir.

• Round Robin: Sırayla her sunucuya bir istek. Sunucular benzer kapasitedeyse en sade ve öngörülebilir seçenektir.
• Least Connections: O an en az aktif bağlantıya sahip düğüme yönlendirir. İstek süreleri değişkenken (uzun WebSocket oturumları gibi) round robin'den daha adildir.
• Weighted (ağırlıklı): Güçlü makineye daha yüksek ağırlık verip orantılı yük gönderir. Heterojen donanım havuzlarında işe yarar.
• IP Hash: İstemci IP'sini hash'leyerek aynı kullanıcıyı hep aynı sunucuya bağlar; basit bir yapışkanlık biçimidir.

Sağlık Kontrolü (Health Check)

Bir yük dengeleyicinin en kritik görevi, çöken düğümü zamanında fark edip havuzdan çıkarmaktır. Aksi halde trafiğin bir kısmını ölü sunucuya gönderip kullanıcıya hata döndürürsünüz. Pasif kontroller (gelen yanıtlardaki hataları izleme) ucuzdur ama gecikmelidir; aktif kontroller ise belirli aralıkla /healthz gibi bir uca istek atarak düğümün durumunu önceden ölçer. İdeal sağlık ucu yalnızca "ayaktayım" demekle kalmaz, veritabanı bağlantısı gibi kritik bağımlılıkları da kısaca doğrular.

HAProxy ile Örnek Konfigürasyon

Aşağıdaki /etc/haproxy/haproxy.cfg parçası, üç arka uç sunucu için L7 dengeleme, aktif sağlık kontrolü ve çerez tabanlı oturum yapışkanlığı kurar. check inter 2s ile her iki saniyede bir sağlık yoklaması yapılır, üst üste iki başarısız yanıtta düğüm devre dışı bırakılır.

frontend web_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/site.pem
    redirect scheme https if !{ ssl_fc }
    default_backend app_pool

backend app_pool
    balance leastconn
    option httpchk GET /healthz
    http-check expect status 200
    cookie SRVID insert indirect nocache
    server app1 10.0.0.11:8080 check inter 2s fall 2 rise 3 cookie a1
    server app2 10.0.0.12:8080 check inter 2s fall 2 rise 3 cookie a2
    server app3 10.0.0.13:8080 check inter 2s fall 2 rise 3 cookie a3

Konfigürasyonu yürürlüğe almadan önce haproxy -c -f /etc/haproxy/haproxy.cfg ile sözdizimini doğrulamak, üretim ortamında istemediğiniz bir kesintinin önüne geçer.

Nginx ile Hafif Bir Alternatif

Halihazırda Nginx kullanan ekipler için ayrı bir dengeleyici kurmak yerine upstream bloğu çoğu durumda yeterlidir. Aşağıdaki örnek ağırlıklı dağıtım, yedek (backup) düğüm ve başarısız denemelere göre geçici devre dışı bırakma içerir.

upstream app_pool {
    least_conn;
    server 10.0.0.11:8080 weight=3 max_fails=2 fail_timeout=10s;
    server 10.0.0.12:8080 weight=1 max_fails=2 fail_timeout=10s;
    server 10.0.0.13:8080 backup;
}

server {
    listen 443 ssl;
    location / {
        proxy_pass http://app_pool;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Oturum Yönetimi ve Donanım Tercihi

Yapışkan oturumlar (sticky sessions) hızlı bir çözümdür ama tek düğümü orantısız yorabilir ve o düğüm düştüğünde kullanıcı oturumunu kaybeder. Daha dayanıklı yaklaşım, oturum verisini Redis gibi paylaşımlı bir depoda tutup uygulamayı durumsuz (stateless) hale getirmektir; böylece istek hangi sunucuya düşerse düşsün davranış tutarlı olur. Donanım tarafında, dengeleyici ile arka uç arasındaki gecikmeyi düşük tutmak için düğümleri aynı veri merkezinde ve özel bir iç ağda konumlandırmak fark yaratır. Kaynak garantisi ve düşük gecikme arayan üretim havuzları çoğunlukla kendi kaynaklarını paylaşmayan fiziksel sunucu üzerinde kurulurken, esnek ölçeklenmesi gereken katmanlar için hızlıca çoğaltılabilen dakikalar içinde devreye alınan sanal sunucu seçenekleri pratik bir denge sunar.

Bogahost Önerisi: Yük dengeleyiciyi tek bir makineye kurup orayı kritik tek nokta haline getirmeyin. İki dengeleyici düğümünü keepalived ile sanal bir IP (VRRP) arkasında eşleyerek dengeleyicinin kendisini de yedekli yapın; aktif düğüm düştüğünde IP saniyeler içinde yedeğe geçsin.

İzleme ve Doğru Ölçüm

Kurulum bittikten sonra işin asıl kısmı başlar: havuzun gerçekten dengeli çalıştığını ölçmek. HAProxy'nin yerleşik istatistik sayfasını (stats soketi veya web arayüzü) açarak düğüm başına aktif bağlantı, kuyruk uzunluğu ve hata oranını izleyebilirsiniz. Düğümler arasında belirgin bir dengesizlik görüyorsanız çoğu durumda sorun algoritma seçiminde ya da yapışkan oturum yapılandırmasındadır. Yük testi için wrk veya vegeta gibi araçlarla gerçekçi eş zamanlılık üreterek, üretime çıkmadan davranışı gözlemlemek en sağlıklısıdır.

Özetle

Sağlam bir dağıtım katmanı; doğru katman seçimi (L4/L7), trafiğe uygun algoritma, titiz sağlık kontrolü ve dengeleyicinin kendisinin de yedekli olması üzerine kuruludur. Bu dört parçayı yerine oturttuğunuzda, tek sunucu çöktüğünde gece yarısı uyanmak yerine sistemin kendini toparlamasını izleyen tarafta olursunuz.