Yük Dengeleyici (Load Balancer) Nedir

Tek sunucuda çalışan bir uygulamanın iki temel sınırı vardır: o sunucunun kaynakları bittiğinde site yavaşlar, o sunucu çöktüğünde site tamamen gider. Yük dengeleyici (load balancer) tam olarak bu iki sorunu aynı anda çözmek için araya giren bir trafik dağıtım katmanıdır. Ziyaretçiler artık doğrudan uygulama sunucusuna değil, yük dengeleyicinin IP adresine bağlanır; yük dengeleyici de gelen her isteği arkasındaki sunucu havuzundan uygun olan birine iletir. Dışarıdan bakan için hiçbir şey değişmez, tek bir alan adı ve tek bir IP vardır; içeride ise iki, beş ya da elli sunucu çalışıyor olabilir.

Bu rehberde yük dengeleyicinin gerçekte ne yaptığını, L4 ile L7 dengelemenin neden farklı işler olduğunu, hangi dağıtım algoritmasını ne zaman seçmen gerektiğini, sağlık kontrollerinin (health check) neden bütün işin kalbi olduğunu ve oturum sürekliliği konusunda yapılan klasik hataları anlatacağım. Ayrıca yük dengeleyicinin kendisinin nasıl tek hata noktası hâline geldiğini ve bundan nasıl kaçınacağını da göreceksin — çünkü sahada gördüğüm en can sıkıcı kesintiler, "ölçeklenmiş" bir mimarinin önünde tek bir dengeleyici durduğu için yaşanır.

Yük Dengeleyici Tam Olarak Ne Yapar#

Bir yük dengeleyicinin işi kâğıt üzerinde çok basittir: bir sanal IP (VIP) üzerinde dinler, gelen bağlantıyı kabul eder, arkasındaki hedef havuzundan (backend pool, upstream, farm — üründen ürüne isim değişir) bir üye seçer ve trafiği ona aktarır. Ancak bu basit tanımın altında dört ayrı sorumluluk saklıdır ve bir ürünün "iyi bir yük dengeleyici" olup olmadığını bu dördü belirler: dağıtım kararı, sağlık takibi, bağlantı yönetimi ve gözlemlenebilirlik.

Alan adının DNS kayıtları artık uygulama sunucularını değil, yük dengeleyicinin adresini gösterir. Yani firmaniz.com için A kaydın 185.12.34.56 ise bu IP dengeleyiciye aittir; 10.0.0.11, 10.0.0.12, 10.0.0.13 gibi özel ağdaki uygulama sunucuları dışarıya hiç açılmaz. Bu tek başına bir güvenlik kazancıdır: uygulama sunucularının 80 ve 443 portları yalnızca dengeleyiciden gelen trafiğe açık olur.

# Uygulama sunucularında yalnızca dengeleyiciden gelen HTTP'ye izin ver
sudo ufw allow from 10.0.0.5 to any port 80 proto tcp
sudo ufw deny 80/tcp
# Aktif kuralları doğrula
sudo ufw status numbered

Yük dengeleyicinin ikinci, çoğu zaman göz ardı edilen faydası bakım kolaylığıdır. Bir sunucuyu havuzdan çıkarıp güncelleyip geri almak (drain → patch → enable) kesintisiz sürüm geçişinin en pratik yoludur. Tek sunuculu mimaride her apt upgrade küçük bir kesinti riskiyken, havuzlu mimaride sıradan bir bakım işidir.

L4 ve L7 Yük Dengeleme Arasındaki Fark#

Yük dengeleyiciler OSI modelinin hangi katmanında karar verdiklerine göre ikiye ayrılır ve bu ayrım tamamen pratik sonuçlar doğurur. L4 (taşıma katmanı) dengeleyici yalnızca IP adresi ve port bilgisine bakar; paketin içindeki HTTP başlığını, URL'yi ya da çerezi hiç açmaz. L7 (uygulama katmanı) dengeleyici ise HTTP isteğini tam olarak ayrıştırır; Host başlığını, yolu, çerezleri, hatta gövdenin bir kısmını görebilir ve buna göre karar verir.

Pratikte web uygulamaları için neredeyse her zaman L7 tercih edilir, çünkü yola göre yönlendirme, başlık ekleme, gzip, önbellekleme ve düzgün hata sayfaları ancak L7'de mümkündür. Buna karşılık PostgreSQL, Redis ya da SMTP gibi HTTP olmayan servisleri dağıtacaksan L4 zorunludur. HAProxy gibi ürünler her iki modu da destekler ve seçim tek satırlık bir ayardır:

# L7: HTTP'yi ayrıştırır, başlık ekleyebilir, yola göre yönlendirebilir
frontend web_in
    bind *:80
    mode http
    default_backend web_pool

# L4: sadece TCP akışını taşır, içeriğe bakmaz
frontend db_in
    bind *:5432
    mode tcp
    default_backend db_pool

TLS'i nerede sonlandıracağın da bu seçimle iç içedir. Sertifikayı dengeleyicide sonlandırmak (TLS termination) yönetimi kolaylaştırır; tek yerde yenilersin, arka uçlar düz HTTP konuşur. Uçtan uca şifreleme şartsa ya paketleri hiç açmadan geçirirsin (TLS passthrough, L4) ya da dengeleyicide çözüp arka uca yeniden şifrelersin (re-encrypt). Nginx ile Apache'nin bu senaryolardaki davranış farklarını merak ediyorsan Apache ve Nginx karşılaştırması iyi bir başlangıç noktası.

Dağıtım Algoritmaları ve Doğru Seçim#

"Trafiği eşit dağıt" cümlesi kulağa tek bir işlem gibi gelse de, eşitliğin tanımı senaryoya göre değişir. Yük dengeleyicilerin sunduğu klasik algoritmalar ve gerçek kullanım yerleri şöyle:

Varsayılan olarak round robin ile başlamak makuldür ama yanıt süreleri birbirinden çok farklı isteklerin olduğu bir uygulamada (örneğin bir rapor ekranı 8 saniye, ana sayfa 80 milisaniye sürüyorsa) round robin yanıltıcıdır: sunuculardan biri arka arkaya üç ağır rapor alıp boğulurken diğeri boş durabilir. Bu tabloda leastconn neredeyse her zaman daha iyi davranır. Ağırlıklı dağıtımı ise özellikle farklı nesil donanımların bir arada olduğu havuzlarda kullanırsın; yeni bir dedicated sunucu ile eski bir düğümü aynı havuza koyduğunda ağırlık vermeden dağıtmak eski makineyi darboğaza çevirir.

Sağlık Kontrolü Olmadan Yük Dengeleyici Olmaz#

Bir yük dengeleyiciyi DNS round robin'den ayıran tek şey sağlık kontrolüdür. DNS, arkadaki sunucunun ayakta olup olmadığını bilmez; yük dengeleyici bilir ve çökmüş üyeyi saniyeler içinde havuzdan çıkarır. Bu yüzden sağlık kontrolü ayarları, yapılandırmanın en kritik satırlarıdır.

İki tür kontrol vardır. Aktif kontrol, dengeleyicinin belirli aralıklarla üyeye kendi başına istek atmasıdır. Pasif kontrol, gerçek kullanıcı isteklerinin sonucuna bakarak (arka arkaya N hata → üyeyi işaretle) karar vermektir. En sağlam kurulumlar ikisini birlikte kullanır.

# HAProxy: 2 saniyede bir /healthz iste, 3 başarıda aç, 3 hatada kapat
backend web_pool
    mode http
    option httpchk GET /healthz
    http-check expect status 200
    default-server inter 2s rise 3 fall 3
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check
    server web3 10.0.0.13:80 check

Buradaki üç sayı doğrudan kesinti süreni belirler: inter 2s fall 3 demek, çökmüş bir sunucunun havuzdan çıkması için en kötü ihtimalle 6 saniye geçecek demektir. Sayıları küçültmek tepkiyi hızlandırır ama ağdaki anlık bir dalgalanmada sağlıklı sunucuları da havuzdan atma riskini büyütür; rise 3 ise geri alma kararını yavaşlatarak "yalpalayan" (flapping) bir üyenin sürekli girip çıkmasını engeller.

Sağlık kontrolü uç noktasını yazarken düşülen en pahalı tuzak, kontrolü fazla derinleştirmektir. /healthz içinde veritabanına sorgu atıyorsan ve veritabanı bir saniyeliğine yavaşlarsa, tüm uygulama sunucuların aynı anda sağlıksız işaretlenir ve dengeleyici trafiği verecek kimse bulamaz — kısmi bir sorun tam kesintiye dönüşür. Doğru yaklaşım iki ayrı uç nokta tutmaktır: /healthz yalnızca sürecin ayakta ve istek alabilir olduğunu söyler, /readyz ise bağımlılıkları kontrol eder ve yalnızca dağıtım (deploy) sırasında kullanılır.

Oturum Sürekliliği ve Durum Yönetimi#

Klasik senaryo şudur: kullanıcı giriş yapar, oturum bilgisi o sunucunun disk ya da belleğinde tutulur, bir sonraki isteği başka sunucuya düşer ve kullanıcı kendini çıkış yapmış bulur. Bunun iki çözümü var; biri kolay ama borç biriktiriyor, diğeri biraz emek istiyor ama kalıcı.

Kolay çözüm sticky session: dengeleyici kullanıcıyı bir çerez ya da kaynak IP hash'i ile hep aynı sunucuya sabitler. Nginx'te ip_hash, HAProxy'de cookie SRV insert bunu yapar.

upstream app_pool {
    ip_hash;                 # aynı IP hep aynı sunucuya
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

Bu yöntemin bedeli, ölçekleme esnekliğini kaybetmendir: bir sunucu çöktüğünde ona sabitlenmiş bütün kullanıcıların oturumu gerçekten kaybolur, havuza yeni üye eklediğinde dağılım anında dengelenmez ve NAT arkasındaki büyük bir kurumsal ağ tek bir IP olarak görüneceği için yüzlerce kullanıcı tek sunucuya yığılabilir.

Kalıcı çözüm, uygulamayı durumsuz (stateless) hâle getirmektir: oturumu Redis, Memcached ya da veritabanı gibi paylaşılan bir depoda tut; yüklenen dosyaları yerel diske değil ortak bir depolama alanına yaz; önbelleği merkezîleştir. Bunu bir kez yaptığında yalnızca yük dengeleme değil, otomatik ölçekleme ve mavi-yeşil dağıtım gibi her şey mümkün hâle gelir. Sunucu yapılandırmalarının tüm düğümlerde aynı kalmasını sağlamak için Ansible ile sunucu otomasyonu yazısındaki yaklaşım burada çok işine yarar.

Yük Dengeleyicinin Kendisi Tek Hata Noktası Olmasın#

Üç uygulama sunucusunu tek bir dengeleyicinin arkasına koyduğunda, kesinti olasılığını üçe bölmüş olmazsın — sadece taşımış olursun. Dengeleyici düğümü çöktüğünde arkadaki üç sağlıklı sunucunun hiçbir anlamı kalmaz. Bu yüzden ciddi bir kurulumda dengeleyici her zaman en az iki düğümdür ve aralarında bir sanal IP dolaşır: aktif düğüm çökerse pasif düğüm IP'yi devralır ve trafiği saniyeler içinde karşılamaya devam eder.

Bu devralma mekanizmasının yaygın uygulaması VRRP protokolüdür ve Linux tarafında keepalived ile kurulur. Bulut sağlayıcılarında ise aynı işi API üzerinden taşınabilen bir yüzen IP (floating IP) görür. Kurulum tercihin şuna göre değişir: kendi ağını yönetiyorsan VRRP, sağlayıcı ağındaysan floating IP daha pratiktir. Trafik hacmin büyüdükçe dengeleyici katmanının önüne DDoS koruma ve WAF katmanlarını eklemek de mantıklı olur; dengeleyici trafiği dağıtır ama kötü niyetli trafiği ayıklamak onun işi değildir.

Sık Yapılan Hatalar#

En sık gördüğüm ilk hata gerçek ziyaretçi IP'sinin kaybolmasıdır. Dengeleyici araya girdiğinde uygulama sunucusu bütün istekleri dengeleyicinin IP'sinden geliyor sanır; erişim kayıtların tek bir IP ile dolar, IP tabanlı hız sınırlaman ve coğrafi analizin çöker. Çözüm, L7'de X-Forwarded-For başlığını iletmek ve web sunucusuna bu başlığa güvenmesini söylemektir:

# Dengeleyici tarafı: gerçek IP'yi ilet
proxy_set_header X-Real-IP        $remote_addr;
proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Arka uç tarafı: yalnızca dengeleyiciden gelen başlığa güven
set_real_ip_from 10.0.0.5;
real_ip_header X-Forwarded-For;

İkinci klasik hata yönlendirme döngüsüdür. TLS'i dengeleyicide sonlandırıp arka uca düz HTTP gönderirsen, arka uçtaki "HTTP ise HTTPS'e yönlendir" kuralı sonsuz döngü üretir; tarayıcı ERR_TOO_MANY_REDIRECTS verir. Çözüm, arka uçtaki yönlendirme kuralını $http_x_forwarded_proto değerine bakacak biçimde yazmaktır.

Üçüncü hata zaman aşımı uyumsuzluğudur. Dengeleyicinin boşta bekleme süresi arka ucun keepalive süresinden kısaysa, kapanmak üzere olan bağlantılara istek düşer ve rastgele 502 hataları görürsün. Kural basittir: arka ucun keepalive süresi, dengeleyicinin boşta zaman aşımından daima büyük olmalı.

Dördüncü hata, dengeleyiciyi ekledikten sonra kapasiteyi ölçmemektir. TLS sonlandırma CPU yakar; 10 Gbit hattı doldurabilecek bir trafikte dengeleyici düğümün çekirdek sayısı yetmezse darboğaz artık uygulama değil, dengeleyicidir. Trafik projeksiyonun için bant genişliği hesaplayıcı aracını kullanabilir, hedeflediğin kesintisizlik oranını uptime ve SLA hesaplayıcı ile somut dakikalara çevirebilirsin.

Sıkça Sorulan Sorular#

Yük dengeleyici siteyi hızlandırır mı#

Doğrudan hızlandırmaz, ama yükü dağıttığı için sunucuların doygunluğa ulaşmasını engeller ve yoğun saatlerde yanıt sürelerinin bozulmasını önler. Tek sunucun boşta gezerken yük dengeleyici eklemek ölçülebilir bir hız kazancı getirmez; hatta araya bir ağ atlaması eklediği için birkaç milisaniye ekler. Asıl kazanç, trafik arttığında performansın çökmemesi ve bir sunucu arızalandığında sitenin ayakta kalmasıdır.

Kaç sunucudan sonra yük dengeleyici gerekmeye başlar#

Sayıdan çok risk toleransına bakmalısın. İki sunucun varsa zaten bir dengeleyiciye ihtiyacın vardır, çünkü ikisine trafiği dağıtacak bir mekanizma olmadan ikinci sunucu sadece boşta duran bir yedektir. Tek sunucuda çalışıyorsan ve planlı bakımlarda birkaç dakikalık kesinti senin için kabul edilebilirse yük dengeleyiciye henüz gerek yoktur; kesinti kabul edilemez hâle geldiği gün gereklidir.

Yük dengeleyici tek başına yüksek erişilebilirlik sağlar mı#

Hayır. Tek bir yük dengeleyici düğümü, mimarideki tek hata noktasını uygulama katmanından ağ katmanına taşımaktan başka bir şey yapmaz. Gerçek yüksek erişilebilirlik için dengeleyicinin de en az iki düğüm olması ve aralarında VRRP ya da yüzen IP ile otomatik devralma bulunması gerekir. Ayrıca veritabanı katmanının da yedekli olması gerekir; yoksa tek veritabanı çöktüğünde kaç web sunucun olduğunun önemi kalmaz.

Ücretsiz yük dengeleyici var mı#

Evet, en yaygın iki seçenek olan HAProxy ve Nginx açık kaynaklıdır ve üretim ortamlarında yıllardır ücretsiz sürümleriyle kullanılır. Maliyet lisansta değil, üzerinde çalışacakları sunucuda ve yönetim emeğindedir. Bulut sağlayıcılarının yönetilen yük dengeleyici hizmetleri ise genelde saatlik ücretlendirilir; karşılığında yedeklilik ve bakımı sen değil sağlayıcı üstlenir.

DNS round robin yük dengeleyici yerine geçer mi#

Sınırlı biçimde. Aynı isim için birden fazla A kaydı tanımlarsan trafik kabaca dağılır, ama DNS sunucuların sağlığını denetlemediği için çökmüş bir sunucunun IP'sini dağıtmaya aynı sıklıkta devam eder ve kullanıcıların bir kısmı hata alır. Ayrıca istemci tarafındaki önbellekleme yüzünden dağılım hiçbir zaman gerçekten eşit olmaz. Basit bir başlangıç adımı olarak düşünülebilir, yüksek erişilebilirlik çözümü olarak değil.

SSL sertifikasını yük dengeleyiciye mi yoksa arka uç sunuculara mı kurmalıyım#

Çoğu senaryoda dengeleyicide sonlandırmak en pratik yoldur: sertifikayı tek yerde yenilersin, arka uçlar düz HTTP konuşur ve CPU tasarrufu sağlarsın. Ancak dengeleyici ile arka uç arasındaki ağ güvenilmezse ya da uyum gereksinimlerin uçtan uca şifreleme istiyorsa, dengeleyicide çözüp arka uca yeniden şifreleyen (re-encrypt) yapıyı tercih etmelisin. Bu durumda arka uçtaki sertifikaların özel bir iç sertifika otoritesinden olması yeterlidir.

Yük dengeleyicinin arkasındaki gerçek ziyaretçi IP'sini nasıl görürüm#

L7 modda dengeleyiciye X-Forwarded-For ve X-Real-IP başlıklarını eklettirir, arka uç web sunucusunda da bu başlıklara yalnızca dengeleyicinin IP'sinden gelirse güvenecek şekilde ayar yaparsın. L4 modda HTTP başlığı ekleyemezsin; bu durumda HAProxy'nin send-proxy seçeneği ve arka uçta PROXY protokol desteği kullanılır. Başlığa doğrulamasız güvenmek tehlikelidir, çünkü istemci sahte bir X-Forwarded-For gönderebilir.

Kapanış#

Yük dengeleyici, "sunucu ekleyerek büyümek" fikrini mümkün kılan bileşendir; ama gerçek değerini dağıtım algoritmasından değil, sağlık kontrolünden ve arkasındaki mimarinin durumsuz olmasından alır. Aklında kalması gereken dört alışkanlık şu: sağlık kontrolünü sığ tut ve inter/rise/fall değerlerini bilinçli seç, oturumu sunucu belleğinden çıkarıp paylaşılan bir depoya taşı, gerçek ziyaretçi IP'sini ilk günden itibaren doğru ilet ve dengeleyiciyi tek düğüm olarak bırakma.

Bu katmanı kurarken altyapı tarafını bize bırakmak istersen, esnek kaynaklı bulut sunucu ve VDS paketlerimizle havuzunu dakikalar içinde büyütebilir, kurulum ve izleme işini sunucu yönetimi hizmetimize devredebilir, dengeleyicinin önüne DDoS koruma katmanı ekleyerek trafik dağıtımını gerçek saldırılara karşı da anlamlı hâle getirebilirsin.