Yük dengeleme (load balancing) nedir?

• Sunucu ve Altyapı
• Güncelleme: 04.10.2026
• Yaklaşık 8 dk okuma

Yük dengeleme nasıl çalışır?

1. 1

   İstekler birden çok sunucuya dağıtılır

   Yük dengeleyici, ziyaretçi ile arka uç sunucuları (backend) arasında duran bir ters vekildir (reverse proxy). Üç temel yarar sağlar:

   • Kapasite: Tek sunucunun karşılayamayacağı yük birkaç sunucuya bölünür. İhtiyaç arttığında gruba yeni sunucu eklenir.
   • Kesintisizlik: Sunuculardan biri arızalanırsa istekler kalanlara yönlendirilir; site yavaşlayabilir ama açık kalır.
   • Bakım kolaylığı: Güncellenecek sunucu gruptan çıkarılır, işi bitince geri alınır. Ziyaretçi bakımı fark etmez.

   Yük dengeleme tek başına bir hız ayarı değildir: yavaş bir sorguyu hızlandırmaz, yalnızca aynı anda daha çok isteğin karşılanmasını sağlar.

   : Büyüt

2. 2

   Dağıtım yöntemini seçin

   Yük dengeleyicinin sıradaki isteği hangi sunucuya vereceğini dağıtım yöntemi belirler. Nginx'te en sık kullanılan üç yöntem şunlardır:

   Yöntem	Nasıl dağıtır?	Ne zaman uygun?
   round-robin (varsayılan)	İstekleri sırayla, ağırlıklara göre dağıtır.	Sunucular benzer güçte ve istekler benzer sürede bitiyorsa.
   least_conn	İsteği o anda en az etkin bağlantısı olan sunucuya verir.	İsteklerin süresi birbirinden çok farklıysa (uzun raporlar, dosya indirme).
   ip_hash	Aynı istemci adresinden gelen istekleri aynı sunucuya yollar.	Oturum sunucuda tutuluyorsa, geçici çözüm olarak.

   Kararsızsanız varsayılan yöntemle başlayın; çoğu site için yeterlidir.

   : Büyüt

3. 3

   Yanıt vermeyen sunucu devreden çıkarılır

   Yük dengeleyici, arızalı sunucuya istek göndermeyi bırakabilmelidir. Buna sağlık kontrolü (health check) denir. Açık kaynak Nginx'te bu kontrol pasiftir: Nginx sunucuları ayrıca yoklamaz, gerçek ziyaretçi isteklerinin sonucuna bakar. Bir sunucuyla iletişim belirli sürede belirli sayıda başarısız olursa o sunucu bir süre kullanılmaz; süre dolunca yeniden denenir.

   Sunucuları düzenli aralıklarla kendiliğinden yoklayan etkin sağlık kontrolü açık kaynak sürümde yerleşik değildir; ticari sürümde, ek modüllerde ya da başka yük dengeleyici yazılımlarında bulunur.

   : Büyüt

4. 4

   Oturumlar için plan yapın

   Birçok uygulama oturum bilgisini (giriş durumu, sepet) sunucunun kendi diskinde tutar. Tek sunucuda sorun olmaz; birden çok sunucuda ise ziyaretçinin ilk isteği A sunucusuna, ikincisi B sunucusuna gidebilir ve B onu tanımaz. Sonuç: kullanıcı durup dururken oturumdan düşer ya da sepeti boşalır. Bu soruna oturum yapışkanlığı (session stickiness) sorunu denir; çözümleri aşağıda ayrı bir bölümde anlatılmıştır.

   : Büyüt

Nginx'te upstream bloğu

Nginx'te arka uç sunucuları upstream bloğuyla bir grup olarak tanımlanır. Bu blok http bloğunun içinde, server bloklarının dışında yer alır. Gruba bir ad verilir ve proxy_pass yönergesinde (directive) bu ad kullanılır:

# http bloğunun içinde: arka uç sunucu grubu
upstream uygulama {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

server {
    listen 80;
    server_name ornek.com www.ornek.com;

    location / {
        proxy_pass http://uygulama;
        proxy_set_header Host $host;
        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;
    }
}

Bu örnekte başka bir ayar yapılmadığı için istekler üç sunucuya sırayla dağıtılır. proxy_set_header satırları, arka uç sunucusunun ziyaretçinin istediği alan adını, gerçek IP adresini ve bağlantının HTTPS olup olmadığını öğrenmesini sağlar; bunlar olmadan uygulama tüm istekleri yük dengeleyiciden geliyor sanar. Temel kurulum için reverse proxy kurulumu rehberine bakın.

HTTPS kullanıyorsanız sertifika genellikle yük dengeleyiciye kurulur (SSL sonlandırma, SSL termination); ayrıntılar Nginx'te HTTPS rehberindedir.

Her değişiklikten sonra yapılandırmayı önce sınayın, hata yoksa yeniden yükleyin:

# Yapılandırmayı sına
sudo nginx -t
# Hata yoksa bağlantıları kesmeden yeniden yükle
sudo systemctl reload nginx

Yöntemler: round-robin, least_conn, ip_hash

round-robin için bir yönerge yazılmaz; varsayılandır. Diğer yöntemler upstream bloğunun başına tek satırla eklenir.

least_conn, isteği o anda en az etkin bağlantısı olan sunucuya verir; ağırlıklar da hesaba katılır:

upstream uygulama {
    least_conn;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

ip_hash, istemcinin IP adresine göre sunucu seçer; aynı adresten gelen istekler, o sunucu kullanılabilir olduğu sürece hep aynı sunucuya gider. IPv4 adreslerinde adresin ilk üç bölümü, IPv6'da adresin tamamı kullanılır.

upstream uygulama {
    ip_hash;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080 down;   # bakımda: eşleşmeler korunur
    server 10.0.0.13:8080;
}

ip_hash kullanırken bir sunucuyu geçici olarak çıkarmanız gerekirse satırı silmek yerine down ile işaretleyin; böylece diğer istemcilerin sunucu eşleşmesi korunur.

weight, backup ve down parametreleri

Her server satırının sonuna o sunucunun davranışını belirleyen parametreler eklenebilir:

• weight: Sunucunun ağırlığı; varsayılanı 1'dir. Ağırlığı 3 olan sunucu, ağırlığı 1 olan sunucunun yaklaşık üç katı istek alır. Daha güçlü sunucuya daha çok pay vermek için kullanılır.
• backup: Yedek sunucu. Yalnızca asıl sunucuların hiçbiri kullanılamadığında istek alır. ip_hash yöntemiyle birlikte kullanılamaz.
• down: Sunucuyu kalıcı olarak kullanım dışı işaretler. Bakım sırasında sunucuyu gruptan çıkarmanın en basit yoludur.

upstream uygulama {
    server 10.0.0.11:8080 weight=3;   # daha güçlü sunucu: daha çok istek
    server 10.0.0.12:8080;            # weight=1 (varsayılan)
    server 10.0.0.13:8080 down;       # bakımda, istek almaz
    server 10.0.0.14:8080 backup;     # yalnız diğerleri kullanılamazsa
}

Bakım akışı şöyledir: sunucunun satırına down ekleyin, yapılandırmayı sınayıp yeniden yükleyin, bakımı yapın, down sözcüğünü kaldırıp yeniden yükleyin. Yeniden yükleme (reload) sırasında süren bağlantılar kesilmez; eski çalışan süreçler ellerindeki istekleri tamamlayıp kapanır.

Sağlık kontrolü: max_fails ve fail_timeout

Pasif sağlık kontrolü iki parametreyle ayarlanır:

• max_fails: Sunucunun kullanılamaz sayılması için gereken başarısız deneme sayısı. Varsayılanı 1'dir; 0 yazılırsa sayım kapatılır.
• fail_timeout: Hem başarısız denemelerin sayıldığı süre hem de sunucunun kullanılamaz sayılacağı süredir. Varsayılanı 10 saniyedir.

upstream uygulama {
    # 30 saniyede 3 başarısız deneme: sunucu 30 saniye kullanılmaz
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name ornek.com;

    location / {
        proxy_pass http://uygulama;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # Kapalı sunucuda uzun süre bekleme
        proxy_connect_timeout 3s;
        # Hangi durumlarda sıradaki sunucu denensin?
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
    }
}

Bu örnekte bir sunucuyla iletişim 30 saniye içinde 3 kez başarısız olursa o sunucuya 30 saniye boyunca istek gönderilmez. Süre dolunca Nginx sunucuyu gerçek bir istekle yeniden dener.

Neyin "başarısız" sayılacağını proxy_next_upstream yönergesi belirler. Varsayılan olarak bağlantı hatası ve zaman aşımı (timeout) başarısızlık sayılır; örnekte buna 502 ve 503 yanıtları da eklenmiştir. Başarısız olan istek sıradaki sunucuya aktarılır; proxy_next_upstream_tries bu denemelerin sayısını sınırlar. proxy_connect_timeout değerini kısa tutmak, kapalı bir sunucunun ziyaretçiyi uzun süre bekletmesini önler.

Pasif kontrolün sınırı şudur: arıza, ancak bir ziyaretçi isteği başarısız olduğunda fark edilir. Bu yüzden sunucuları dışarıdan da izleyin; yedekleme ve izleme rehberindeki çalışma süresi izleme önerileri burada da geçerlidir. Ziyaretçinin gördüğü 502 ve 504 hatalarının nedenleri için 502 ve 504 hataları rehberine bakın.

Oturum yapışkanlığı ve çözümleri

Oturum bilgisi tek bir sunucunun diskinde ya da belleğinde duruyorsa, ziyaretçinin her isteği o sunucuya gitmek zorundadır. Üç çözüm yolu vardır:

• ip_hash ile aynı sunucuya yönlendirme: En hızlı uygulanan çözümdür ama sınırlıdır. Aynı ağdan çıkan çok sayıda kullanıcı (bir şirket ya da kurum) tek sunucuya yığılır; mobil kullanıcının IP adresi değişince oturumu kaybolur; bir sunucu devreden çıkınca o sunucudaki oturumlar düşer. Yük dengeleyicinin önünde bir CDN ya da başka bir vekil sunucu (proxy) varsa Nginx ziyaretçinin değil o katmanın adresini görür ve dağılım bozulur.
• Oturumu paylaşılan bir depoda tutma: Oturumlar sunucuların diskinde değil, hepsinin eriştiği ortak bir yerde (Redis ya da Memcached gibi bir bellek deposu veya veritabanı) saklanır. Hangi sunucu yanıt verirse versin oturum bulunur. Kalıcı çözüm çoğunlukla budur.
• Durumsuz kimlik belirteci: Sunucu oturum saklamaz; kullanıcının kimliği, sunucunun imzaladığı ve her istekte gönderilen bir belirteçle (token) taşınır. Her sunucu imzayı doğrulayabildiği için istek hangisine giderse gitsin kabul edilir. İmza anahtarının tüm sunucularda aynı olması ve belirtecin süresinin kısa tutulması gerekir.

Oturum çerezlerinin güvenli ayarları için giriş ve oturum güvenliği rehberine bakın.

Dikkat edilecekler

• Yüklenen dosyalar ortak olmalı: Kullanıcının yüklediği bir görsel yalnızca isteği alan sunucunun diskine yazılırsa, diğer sunucular o dosyayı bulamaz. Yüklenen dosyaları tüm sunucuların eriştiği ortak bir depolama alanında tutun ya da sunucular arasında eşitleyin.
• Veritabanı tek nokta olarak kalır: Uygulama sunucularını çoğaltmak veritabanını çoğaltmaz. Tüm sunucular aynı veritabanına bağlanır; yavaşlık ya da arıza oradaysa yük dengeleme çözmez. Veritabanı için ayrıca yedekleme ve yedek sunucu planı gerekir.
• Yük dengeleyicinin kendisi tek hata noktasıdır: Arkada üç sunucu olsa da öndeki tek yük dengeleyici durursa site kapanır. Kesintisizlik önemliyse yük dengeleyici de yedekli kurulur (ikinci bir yük dengeleyici ve arıza anında ona geçen ortak bir IP adresi) ya da barındırma sağlayıcının yönetilen yük dengeleme hizmeti kullanılır.
• Sürümler tutarlı dağıtılmalı: Sunucularda farklı kod sürümleri çalışırsa aynı ziyaretçi bir istekte yeni, diğerinde eski sayfayı görür. Güncellemeyi sunucuları sırayla gruptan çıkararak yapın ve veritabanı değişikliklerinin eski sürümle de uyumlu olmasına dikkat edin.
• Zamanlanmış görevler: Her sunucuda ayrı ayrı çalışan zamanlanmış bir görev aynı işi birkaç kez yapar (örneğin aynı e-postayı üç kez gönderir). Bu görevleri tek sunucuda çalıştırın ya da kilit kullanın.
• Önbellek ve günlükler: Sunucu başına tutulan önbellek, sunucular arasında farklı sonuçlar verebilir. Günlükler de dağınık kalır; sorun ararken hepsine bakmanız gerekir.

Tek sunucunun yetmediğinden emin değilseniz önce mevcut sunucuyu iyileştirmeyi değerlendirin: önbellek ve sıkıştırma çoğu zaman daha az emekle daha çok kazanç sağlar.

Sık sorulan sorular

İlgili rehberler

• Reverse proxy (ters vekil) nedir?Ters vekilin görevleri, tipik mimariler, gerçek ziyaretçi IP'si ve başlıklar, CDN ile ilişkisi ve kısa Nginx örneği.
• Nginx ile reverse proxy (ters vekil) kurulumuserver bloğu, proxy_pass, iletilecek başlıklar, WebSocket, zaman aşımları ve gerçek IP ayarıyla adım adım kurulum.
• 502, 504 ve diğer Nginx hataları: nedenleri ve çözümleri502, 504, 413, 499, 403 ve 404 hatalarının anlamı, olası nedenleri, günlüklerle teşhisi ve çözümü.
• CDN (içerik dağıtım ağı) nedir?CDN'in ne olduğu, nasıl devreye alındığı ve gerçek IP, önbellek, kaynak sunucu güvenliği konusunda dikkat edilecekler.