Nginx ile Yük Dengeleme (Load Balancing)

Tek bir uygulama sunucusuyla yola çıkarsınız; işler yolunda gittikçe trafik artar, CPU %90'larda gezinmeye başlar ve bir gün o tek makine ya çöker ya da yavaşlar. İşte tam bu noktada yük dengeleme (load balancing) devreye girer. Gelen istekleri arkadaki birden çok sunucuya paylaştırarak hem tek bir makinenin üzerindeki baskıyı azaltır hem de bir sunucu devre dışı kalsa bile hizmetin ayakta kalmasını sağlarsınız. Nginx, bu işi yıllardır kanıtlanmış, hafif ve son derece güvenilir bir şekilde yapan en yaygın araçlardan biridir.

Bu rehberde Nginx'in upstream bloğunu sıfırdan kurup, gelen trafiği birden çok arka uç (backend) sunucuya nasıl dağıtacağınızı; round robin, least_conn ve ip_hash gibi algoritmaların ne zaman hangisinin doğru tercih olduğunu; weight, backup ve down parametreleriyle sunucu havuzunu nasıl ince ayarladığınızı; pasif sağlık kontrolünün nasıl çalıştığını ve oturum yapışkanlığı (sticky session) mantığını adım adım göreceğiz. Örnekler gerçek dünyadan; kıdemli bir sistem yöneticisinin ekrana bakıp anlatacağı sadelikte. Nginx'i henüz kurmadıysanız Ubuntu üzerinde Nginx kurulumu rehberimizle başlayabilirsiniz.

Yük Dengeleme Neden Gerekli?#

Yük dengelemeyi iki temel ihtiyaç doğurur: ölçeklenebilirlik ve yüksek erişilebilirlik. Ölçeklenebilirlik, tek makinenin kaldıramayacağı yükü birden çok makineye bölmektir. Dikey ölçekleme (aynı sunucuya daha fazla RAM/CPU eklemek) bir noktadan sonra hem pahalıya patlar hem de fiziksel bir tavana çarpar. Yatay ölçekleme ise iki, üç, beş orta seviye sunucuyu yan yana koyup önlerine bir dengeleyici dikmektir; çok daha ekonomik ve esnektir.

Yüksek erişilebilirlik (high availability) ise farklı bir dertle ilgilenir: bir sunucu çökerse ne olacak? Tek makineli bir kurulumda cevap acıdır — site tümüyle düşer. Load balancer'lı bir kurulumda ise dengeleyici, çöken sunucuyu havuzdan çıkarır ve trafiği ayakta kalan makinelere yönlendirir. Kullanıcı çoğu zaman bir kesinti bile fark etmez. Nginx tam olarak bu iki ihtiyacı tek bir yapılandırma bloğuyla karşılar.

Bakım pencereleri de önemli bir kazanımdır. Load balancer arkasında güncelleme yaparken sunucuları teker teker havuzdan çıkarır, güncellersiniz ve geri eklersiniz; site hiç kapanmadan sürüm geçişini tamamlarsınız. Buna "rolling update" (kademeli güncelleme) denir ve tek sunucuyla imkânsızdır.

upstream Bloğu ile Temel Yapı#

Nginx'te yük dengelemenin kalbi upstream bloğudur. Bu blok, arkadaki sunucuları bir havuz olarak tanımlar; sonra bir server bloğu içinde proxy_pass ile bu havuza trafik gönderirsiniz. En sade haliyle şöyle görünür:

# /etc/nginx/conf.d/load-balancer.conf

upstream uygulama_sunuculari {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

server {
    listen 80;
    server_name uygulama.example.com;

    location / {
        proxy_pass http://uygulama_sunuculari;

        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;
    }
}

Burada uygulama_sunuculari isimli havuza üç arka uç ekledik. Nginx varsayılan olarak gelen istekleri bu üç sunucuya sırayla dağıtır. proxy_set_header satırları hayati önemdedir: arka uç uygulaması, isteğin gerçekte hangi istemciden ve hangi protokolden geldiğini bu başlıklardan öğrenir. Bunları atlarsanız uygulamanız her isteği load balancer'ın IP'sinden geliyormuş gibi görür; loglarınız bozulur, coğrafi tespit ve rate limiting yanlış çalışır.

Yapılandırmayı kaydettikten sonra her zaman şu iki komutu çalıştırma alışkanlığı edinin:

# Söz dizimini doğrula
sudo nginx -t

# Kesintisiz olarak yeni yapılandırmayı yükle
sudo systemctl reload nginx

reload, restart'tan farklı olarak mevcut bağlantıları koparmadan yapılandırmayı tazeler. Üretimde neredeyse her zaman reload kullanırsınız.

Yük Dağıtım Algoritmaları#

Nginx havuzdaki sunuculara isteği nasıl dağıtacağını bir algoritmaya göre belirler. Üç temel yöntem vardır ve doğru olanı seçmek performansı doğrudan etkiler.

Round Robin (varsayılan). Hiçbir algoritma belirtmezseniz Nginx istekleri sırayla dağıtır: birinci istek 1. sunucuya, ikinci 2. sunucuya, üçüncü 3. sunucuya, dördüncü tekrar 1. sunucuya. Basit, öngörülebilir ve sunucuların benzer güçte olduğu, isteklerin de kabaca eşit maliyette olduğu senaryolar için idealdir.

least_conn (en az bağlantı). Bu yöntem isteği, o an en az aktif bağlantıya sahip sunucuya gönderir. Bazı isteklerin uzun sürdüğü (büyük dosya indirmesi, ağır rapor üretimi, WebSocket bağlantısı) durumlarda round robin bir sunucuyu tıkarken diğerini boş bırakabilir; least_conn bu dengesizliği otomatik düzeltir.

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

ip_hash. Bu algoritma istemcinin IP adresinden bir hash üretir ve aynı IP'yi her zaman aynı sunucuya yönlendirir. Böylece bir kullanıcı oturumu boyunca hep aynı arka uca düşer — oturum yapışkanlığının (sticky session) en basit yoludur.

upstream uygulama_sunuculari {
    ip_hash;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.13:8080;
}

Aşağıdaki tablo hangi durumda hangisini seçeceğinizi özetler:

Genel bir kural olarak: durum tutmayan (stateless) modern uygulamalarda least_conn çoğu zaman en dengeli sonucu verir; oturumunu sunucu belleğinde tutan eski uygulamalarda ise ip_hash hayat kurtarır.

Sunucu Ağırlıkları, Backup ve Down#

Gerçek dünyada havuzdaki sunucular her zaman eşit güçte olmaz. Belki biri 8 çekirdekli yeni bir makine, diğeri 4 çekirdekli eski bir kutudur. İşte burada weight (ağırlık) parametresi devreye girer. Ağırlığı yüksek olan sunucu daha fazla istek alır:

upstream uygulama_sunuculari {
    server 10.0.0.11:8080 weight=3;   # Güçlü makine — 3 kat trafik
    server 10.0.0.12:8080 weight=1;   # Standart
    server 10.0.0.13:8080 weight=1;   # Standart
}

Bu yapılandırmada her 5 istekten 3'ü ilk sunucuya, kalan ikisi diğerlerine gider. Ağırlıkları sunucuların gerçek kapasitesine göre ayarlamak, zayıf makineyi ezmeden havuzdan maksimum verim almanızı sağlar.

backup parametresi bir sunucuyu yedek olarak işaretler. Yedek sunucu, normal sunucuların hepsi devre dışı kalmadıkça hiç trafik almaz. Felaket anı için elinizde tuttuğunuz bir sigortadır:

upstream uygulama_sunuculari {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    server 10.0.0.99:8080 backup;   # Sadece diğerleri düşerse devreye girer
}

down ise bir sunucuyu geçici olarak havuzdan tümüyle çıkarmanın en temiz yoludur. Bakım yapacağınız sunucuyu silmek yerine down işaretler, işiniz bitince kaldırırsınız. Yapılandırmadaki yeri korunduğu için geri almak tek satır düzeltmesidir:

upstream uygulama_sunuculari {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080 down;      # Bakımda — trafik almaz
    server 10.0.0.13:8080;
}

down işaretinden sonra sudo nginx -t && sudo systemctl reload nginx çalıştırdığınızda o sunucuya yeni istek gitmez; mevcut bağlantılar tamamlanır. Kademeli güncellemenin (rolling update) temeli budur.

Pasif Sağlık Kontrolü#

Bir arka uç sunucu çöktüğünde Nginx bunu nasıl anlar? Ücretsiz açık kaynak sürümde pasif sağlık kontrolü vardır. Nginx, canlı trafiği kullanarak sunucuların durumunu izler: bir sunucuya yaptığı istek başarısız olursa (bağlantı reddedildi, zaman aşımı, hata döndü) bunu bir "başarısızlık" olarak sayar. Belirli bir eşiği aşan sunucuyu geçici olarak havuzdan çıkarır ve bir süre sonra tekrar dener.

Bu davranışı iki parametre yönetir: max_fails ve fail_timeout.

upstream uygulama_sunuculari {
    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;
}

Buradaki mantık şudur: fail_timeout süresi (30 saniye) içinde max_fails sayısı (3) kadar başarısızlık olursa Nginx o sunucuyu "erişilemez" sayar ve yine fail_timeout süresi boyunca ona hiç istek göndermez. Süre dolunca tek bir deneme isteği gönderir; başarılıysa sunucu havuza geri döner, değilse dışarıda beklemeye devam eder.

Hangi hataların "başarısızlık" sayılacağını proxy_next_upstream yönergesiyle netleştirebilirsiniz. Böylece bir sunucu hata verirse Nginx aynı isteği sıradaki sağlıklı sunucuya devreder ve kullanıcı hiçbir şey fark etmez:

location / {
    proxy_pass http://uygulama_sunuculari;

    proxy_next_upstream error timeout http_502 http_503 http_504;
    proxy_connect_timeout 3s;
    proxy_read_timeout    30s;
}

Pasif kontrolün sınırı şudur: sunucu ancak gerçek bir istek geldiğinde test edilir. Trafik yoksa Nginx bir sunucunun çöktüğünü hemen bilemez. Sürekli aktif sağlık yoklaması (belirli aralıklarla bir sağlık uç noktasına istek atmak) yalnızca ticari Nginx Plus'ta yerleşiktir. Açık kaynakta bu ihtiyacı, hizmetlerinizin dışarıdan sürekli izlendiği bir yapıyla kapatırsınız — Clou.TR panelindeki Uptime Uyarıları tam da bu boşluğu doldurur ve bir servis düştüğünde e-posta veya webhook ile sizi anında uyarır.

Sticky Session (Oturum Yapışkanlığı) Mantığı#

Yük dengelemenin en sık takılınan konusu oturumlardır. Sorun şu: kullanıcı giriş yaptığında oturum bilgisi 1. sunucunun belleğine yazılırsa ve bir sonraki isteği round robin yüzünden 2. sunucuya düşerse, kullanıcı aniden "çıkış yapmış" gibi görünür. Çünkü 2. sunucunun o oturumdan haberi yoktur.

Bu problemi çözmenin iki yaklaşımı vardır. Birincisi ve açık kaynakta en pratik olanı ip_hash ile yapışkanlığı IP üzerinden sağlamaktır. Aynı IP hep aynı sunucuya gittiği için oturum tutarlı kalır:

upstream uygulama_sunuculari {
    ip_hash;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

ip_hash'in zayıf noktası, aynı kurumsal ağ veya mobil operatör NAT'ı arkasındaki yüzlerce kullanıcının aynı dış IP'yi paylaşıp tek sunucuya yığılabilmesidir. Bu da dengeyi bozar. Çerez tabanlı yapışkanlık (sticky cookie) daha isabetli çalışır ancak bu yönerge yalnızca Nginx Plus'ta bulunur.

İkinci ve modern mimarilerde tercih edilen yaklaşım ise sorunu kökten çözmektir: oturumu sunucu belleğinden çıkarıp merkezi bir depoya taşımak. Redis veya Memcached gibi paylaşımlı bir oturum deposu kullandığınızda, kullanıcı hangi arka uca düşerse düşsün oturumu oradan okur. Böylece yapışkanlığa hiç ihtiyaç kalmaz ve gerçek bir stateless mimariye kavuşursunuz. Örneğin PHP tarafında:

; php.ini — oturumları Redis'te sakla
session.save_handler = redis
session.save_path = "tcp://10.0.0.50:6379"

Kural olarak: yeni bir sistem tasarlıyorsanız merkezi oturum deposunu seçin; mevcut ve değiştiremediğiniz bir uygulamayı hızlıca ölçeklemeniz gerekiyorsa ip_hash ile idare edin.

Tam Örnek: Tek Domain Arkasında Birden Çok Uygulama Sunucusu#

Şimdi öğrendiklerimizi tek bir üretim benzeri yapılandırmada birleştirelim. Senaryo şu: uygulama.example.com domaini SSL ile yayında, arkada üç uygulama sunucusu var, biri yedek, sağlık kontrolü açık ve algoritma least_conn.

upstream uygulama_havuzu {
    least_conn;

    server 10.0.0.11:8080 weight=2 max_fails=3 fail_timeout=20s;
    server 10.0.0.12:8080 weight=1 max_fails=3 fail_timeout=20s;
    server 10.0.0.13:8080 backup;

    keepalive 32;   # Arka uçlara kalıcı bağlantı havuzu — gecikmeyi azaltır
}

server {
    listen 443 ssl;
    http2 on;
    server_name uygulama.example.com;

    ssl_certificate     /etc/ssl/certs/uygulama.crt;
    ssl_certificate_key /etc/ssl/private/uygulama.key;

    location / {
        proxy_pass http://uygulama_havuzu;

        proxy_http_version 1.1;
        proxy_set_header Connection "";          # keepalive için gerekli
        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;

        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_connect_timeout 3s;
        proxy_read_timeout    30s;
    }
}

# HTTP'yi HTTPS'e yönlendir
server {
    listen 80;
    server_name uygulama.example.com;
    return 301 https://$host$request_uri;
}

Bu yapılandırmanın birkaç ince noktasına dikkat edin. keepalive 32 satırı, Nginx ile arka uçlar arasında kalıcı bağlantı havuzu tutarak her istekte yeni TCP el sıkışması yapma maliyetini ortadan kaldırır; bunun çalışması için proxy_http_version 1.1 ve boş Connection başlığı şarttır. SSL sonlandırması load balancer'da yapılır ( SSL termination) — arka uçlar düz HTTP konuşur, bu da onların yükünü hafifletir. Sertifika yönetimini hiç uğraşmadan çözmek için ücretsiz SSL sertifikası seçeneklerimize göz atabilirsiniz.

DNS tarafında ise domaini yalnızca load balancer'ın genel IP'sine yöneltmeniz yeterlidir; arka uç sunucuların özel IP'leri dışarıya hiç görünmez:

uygulama.example.com.   IN   A   203.0.113.10

Trafik büyüdükçe havuza yeni bir server satırı ekleyip reload demeniz kapasiteyi anında artırır. Load balancer'ın önüne bir de WAF ve DDoS koruması koyarsanız hem kötü niyetli trafiği süzer hem de arka uçlarınızı zararlı isteklerden korursunuz. Nginx'in Apache karşısındaki proxy ve statik içerik performansını merak ediyorsanız Apache mı Nginx mi karşılaştırmamız iyi bir başlangıç noktasıdır.

Yaygın Hatalar ve İpuçları#

En sık görülen hata, load balancer'ın kendisinin tek arıza noktası (single point of failure) olmasını gözden kaçırmaktır. Arka uçları çoğaltıp önlerine tek bir Nginx dikerseniz, o Nginx çöktüğünde her şey durur. Kritik sistemlerde iki Nginx'i keepalived ve ortak bir sanal IP (VIP) ile eşleyerek dengeleyici katmanını da yedekli hale getirmelisiniz.

İkinci sık hata, gerçek istemci IP'sini arka uca taşımayı unutmaktır. X-Forwarded-For başlığını ayarlamazsanız uygulamanız tüm trafiği load balancer'dan geliyor sanır; güvenlik logları, coğrafi kısıtlamalar ve hız sınırlama yanlış çalışır. Arka uç uygulamanızın bu başlığa güvenmesi için proxy'nin güvenilir olduğunu ona ayrıca bildirmeniz gerekebilir (örneğin PHP'de trusted_proxies ayarı).

Üçüncüsü, zaman aşımlarını varsayılana bırakmaktır. Uzun süren istekleri olan bir API'de proxy_read_timeout düşük kalırsa Nginx isteği yarıda keser ve kullanıcı 504 alır. Zaman aşımlarını uygulamanızın gerçek davranışına göre ayarlayın. Son olarak, yapılandırma değişikliği yaparken her zaman önce nginx -t ile söz dizimini doğrulayın; kırık bir yapılandırmayı canlıya reload etmek üretimi anında düşürebilir. Sunucu yönetiminde deneyimli değilseniz ve bu katmanı sizin adınıza kurulu tutacak birini arıyorsanız sunucu yönetimi hizmetimiz tam bu iş içindir.

Sıkça Sorulan Sorular#

Nginx yük dengeleme ücretsiz mi, yoksa Nginx Plus mı gerekiyor?#

Bu rehberde anlatılan her şey — upstream bloğu, round robin, least_conn, ip_hash, weight, backup, down ve pasif sağlık kontrolü — açık kaynak ve tamamen ücretsiz Nginx sürümünde bulunur. Yalnızca aktif sağlık yoklaması, çerez tabanlı sticky session ve yönetim API'si gibi ileri düzey özellikler ticari Nginx Plus'a özeldir. Çoğu orta ölçekli proje ücretsiz sürümle rahatça çalışır.

least_conn mı yoksa round robin mi kullanmalıyım?#

İstekleriniz kısa ve kabaca eşit maliyetliyse round robin fazlasıyla yeterlidir; basit ve öngörülebilir çalışır. Ancak bazı istekler uzun sürüyorsa (dosya indirme, ağır raporlama, WebSocket) least_conn daha dengeli sonuç verir çünkü isteği o an en boş sunucuya gönderir. Emin değilseniz least_conn ile başlamak genellikle güvenli bir varsayılandır.

Bir arka uç sunucu çökerse kullanıcılar hata görür mü?#

Pasif sağlık kontrolü ve proxy_next_upstream doğru ayarlandıysa çoğu durumda hayır. Nginx, hata veren sunucuya giden isteği otomatik olarak sıradaki sağlıklı sunucuya devreder ve çöken makineyi bir süreliğine havuzdan çıkarır. Kullanıcı genellikle bir kesinti bile fark etmez. Yalnızca havuzdaki tüm sunucular aynı anda düşerse gerçek bir hata sayfasıyla karşılaşılır.

ip_hash kullanmadan oturumları nasıl koruyabilirim?#

En sağlam yöntem oturumu sunucu belleğinden çıkarıp Redis ya da Memcached gibi merkezi bir depoya taşımaktır. Böylece kullanıcı hangi arka uca düşerse düşsün oturumu ortak depodan okur ve yapışkanlığa hiç ihtiyaç kalmaz. Bu yaklaşım uygulamayı gerçek anlamda stateless yapar; ölçeklerken en esnek ve modern çözümdür. ip_hash yalnızca uygulamayı değiştiremediğiniz durumlarda pratik bir kestirmedir.

Yeni bir sunucuyu havuza kesinti olmadan nasıl eklerim?#

upstream bloğuna yeni bir server satırı ekler, ardından sudo nginx -t ile söz dizimini doğrular ve sudo systemctl reload nginx komutunu çalıştırırsınız. reload, mevcut bağlantıları koparmadan yapılandırmayı tazeler; yeni sunucu birkaç saniye içinde trafik almaya başlar. Aynı yöntemle bir sunucuyu down işaretleyip bakıma alabilir, işiniz bitince geri açabilirsiniz — buna kademeli güncelleme (rolling update) denir.

Load balancer'ın kendisi çökerse ne olur?#

Tek bir Nginx dengeleyici, dikkat edilmezse tüm sistemin tek arıza noktası olur. Kritik kurulumlarda bu katmanı da yedeklemek gerekir: iki Nginx sunucusunu keepalived ve ortak bir sanal IP (VIP) ile eşlersiniz; biri çökerse VIP diğerine geçer ve hizmet kesintisiz sürer. Yönetilen bir altyapıda bu yedeklilik genellikle hizmet sağlayıcı tarafında kurulur, sizin ayrıca uğraşmanıza gerek kalmaz.

Kapanış#

Nginx ile yük dengeleme, tek bir yapılandırma bloğuyla hem performansı hem de erişilebilirliği katbekat artıran, öğrenmesi kolay ama etkisi büyük bir tekniktir. upstream bloğunu kurmak, doğru algoritmayı seçmek, ağırlıkları ve yedekleri ayarlamak ve pasif sağlık kontrolünü açmak — bu adımları birleştirdiğinizde arkada bir sunucu çökse bile ayakta kalan sağlam bir altyapıya sahip olursunuz. Merkezi oturum deposu ve yedekli dengeleyici katmanı ekledikçe kurulumunuz gerçek anlamda üretim sınıfına yaklaşır.

Bu mimariyi hayata geçirmek için sağlam bir altyapıya ihtiyacınız var. Yatay ölçekleme için birden çok sanal sunucu (VDS) veya esnek bulut sunucu seçeneklerimizle havuzunuzu istediğiniz kadar büyütebilir; kök erişimli sunucu paketlerimizle Nginx'i tam kontrolle yapılandırabilirsiniz. Yönetim yükünü üstlenmemizi isterseniz sunucu yönetimi hizmetimiz load balancer kurulumundan güvenlik güncellemelerine kadar her şeyi sizin adınıza üstlenir. Projenizi büyütmeye hazır olduğunuzda Clou.TR ekibi doğru mimariyi kurmanız için yanınızda.