Nginx ile Load Balancer (Yük Dengeleme) Kurulumu

Tek bir sunucu artan trafiği karşılayamadığında, gelen istekleri birden çok sunucuya dağıtmak gerekir. İşte bu işe yük dengeleme (load balancing) denir ve Nginx bunu yapmanın en yaygın ve güçlü yollarından birini sunar. Nginx, upstream bloğunda tanımladığınız sunucu grubuna istekleri dağıtarak hem performansı hem de erişilebilirliği artırır. Bu rehberde Nginx ile load balancer kurulumunu, dağıtım yöntemlerini, sağlık kontrollerini ve üretim ortamı için kritik ayarları adım adım anlatıyoruz.

Yük dengeleme mimarisi için birden çok sunucu ve önlerinde bir Nginx katmanı kullanılır. İhtiyacınız büyüdükçe bu katmanı ayrılmış kaynaklı bir bulut sunucu üzerinde konumlandırarak yatay olarak ölçekleyebilirsiniz.

Load Balancer Nasıl Çalışır?

Nginx önde bir “dağıtıcı” (reverse proxy) olarak konumlanır: kullanıcı isteği önce Nginx’e gelir, Nginx de bu isteği arkadaki uygulama sunucularından birine yönlendirir. Bir sunucu çökerse trafik otomatik olarak diğerlerine kayar; böylece tek bir sunucunun arızası tüm hizmeti durdurmaz. Aynı zamanda yük birden çok makineye yayıldığı için her isteğe daha hızlı yanıt verilir ve toplam kapasite artar.

Bu mimaride üç temel kazanım vardır:

• Yatay ölçeklenebilirlik: Daha güçlü tek bir makine almak yerine, gruba yeni sunucu ekleyerek kapasiteyi büyütürsünüz.
• Yüksek erişilebilirlik: Bir düğüm bakıma alınsa veya arızalansa bile hizmet devam eder.
• Bakım kolaylığı: Sunucuları tek tek sıradan çıkarıp güncelleyebilir, sıfır kesintiyle (rolling update) yayın yapabilirsiniz.

Önkoşullar ve Kurulum

Başlamadan önce elinizde, Nginx katmanı için bir sunucu ve arkasında çalışacak en az iki uygulama (backend) sunucusu bulunmalıdır. Nginx’i AlmaLinux/Rocky Linux ailesinde şu komutla kurabilirsiniz:

# AlmaLinux / Rocky Linux / RHEL
dnf install -y nginx
systemctl enable --now nginx

# Debian / Ubuntu
apt update && apt install -y nginx

# Sürüm kontrolü
nginx -v

Yapılandırma dosyalarını genellikle /etc/nginx/conf.d/ altında tutmak, ana nginx.conf dosyasını sade bırakmanın en temiz yoludur. Her değişiklikten sonra önce sözdizimini test edin, sonra yeniden yükleyin:

nginx -t          # yapilandirmayi dogrula
systemctl reload nginx   # kesintisiz yeniden yukle

Temel upstream Yapılandırması

Sunucu grubunu bir upstream bloğunda tanımlayıp proxy_pass ile yönlendirirsiniz (varsayılan yöntem round-robin):

upstream myapp {
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

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

    location / {
        proxy_pass http://myapp;
        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;
    }
}

Buradaki proxy_set_header satırları çoğu zaman atlanır ama kritiktir: bunlar olmadan arka sunucularınız tüm istemcileri Nginx’in IP’si olarak görür. X-Forwarded-For ve X-Real-IP başlıkları, gerçek ziyaretçi IP’sinin loglara ve uygulamaya doğru ulaşmasını sağlar.

Yük Dengeleme Yöntemleri

Nginx birkaç dağıtım yöntemi sunar. Doğru yöntemi seçmek, uygulamanızın oturum (session) yapısına ve sunucularınızın eşit güçte olup olmamasına bağlıdır:

# Round-robin: VARSAYILAN, istekler sirayla dagitilir (direktif gerekmez)
upstream myapp { server srv1; server srv2; }

# Least connections: en az aktif baglantili sunucuya gonder
upstream myapp { least_conn; server srv1; server srv2; }

# IP hash: ayni istemci hep ayni sunucuya (oturum yapiskanligi)
upstream myapp { ip_hash; server srv1; server srv2; }

# Random two: iki sunucu rastgele secilir, az baglantili olan kazanir
# ("Power of Two Choices" - buyuk gruplarda neredeyse optimal dagilim)
upstream myapp { random two least_conn; server srv1; server srv2; server srv3; }

Sunucu ağırlığı için server srv1 weight=3; kullanılır; ağırlığı 3 olan sunucu, varsayılan (weight=1) sunuculara kıyasla 3 kat fazla istek alır. Bu, gruptaki sunucular farklı güçteyse dengeli bir dağıtım sağlar.

Hangi Yöntemi Ne Zaman Kullanmalı?

Sağlık Kontrolü ve Otomatik Yük Devretme

Bir sunucunun “çalışıyor görünmesi” yetmez; gerçekten yanıt verdiğinden emin olmak gerekir. Açık kaynak Nginx, pasif sağlık kontrolü sunar: arka sunucu bir isteğe hata döndürdüğünde Nginx onu bir süreliğine “arızalı” işaretler ve yeni istekleri ona göndermez. Bu davranışı max_fails ve fail_timeout ile ayarlarsınız:

upstream myapp {
    least_conn;
    server srv1.example.com  max_fails=3 fail_timeout=15s;
    server srv2.example.com  max_fails=3 fail_timeout=15s;
    server srv3.example.com  weight=2 max_fails=3 fail_timeout=15s;
    server srv-yedek.example.com  backup;   # sadece tum aktifler dusunce devreye girer
    server srv-bakim.example.com  down;      # bakim icin gecici devre disi
}

Yukarıdaki örnekte bir sunucu 15 saniye içinde 3 kez başarısız olursa, sonraki 15 saniye boyunca devre dışı bırakılır. backup ile işaretli sunucu yalnızca tüm birincil sunucular düştüğünde trafik alır; down ise bir sunucuyu bakıma alırken kullanılır. proxy_next_upstream direktifiyle de hangi hatalarda (örneğin error timeout http_502) isteğin bir sonraki sunucuya devredileceğini belirleyebilirsiniz.

Not: Düzenli aralıklarla istek atarak kontrol eden aktif sağlık kontrolü (health_check direktifi) yalnızca ticari Nginx Plus sürümünde bulunur. Açık kaynak sürümde aynı işlevi pasif kontroller ve harici izleme araçlarıyla elde edersiniz.

keepalive ile Performansı Artırma

Her istekte arka sunucuya yeni bir TCP bağlantısı kurmak gecikme yaratır. keepalive direktifi, Nginx ile arka sunucular arasında kalıcı bağlantı havuzu tutarak bu maliyeti ortadan kaldırır. Yoğun trafikte fark belirgindir:

upstream myapp {
    least_conn;
    server srv1.example.com;
    server srv2.example.com;
    keepalive 32;          # her worker icin acik tutulacak bos baglanti sayisi
}

server {
    location / {
        proxy_pass http://myapp;
        proxy_http_version 1.1;       # keepalive icin sart
        proxy_set_header Connection "";   # "close" basligini temizle
    }
}

proxy_http_version 1.1; ve boş Connection başlığı olmadan keepalive havuzu çalışmaz; bu iki satır çoğu zaman unutulur.

SSL Sonlandırma (HTTPS)

Sertifikayı genellikle Nginx katmanında sonlandırmak en pratik yöntemdir: şifre çözme yükü tek noktada toplanır, arka sunucular sade HTTP ile konuşur ve sertifika yönetimi merkezîleşir. Bu yaklaşıma SSL termination denir:

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/nginx/ssl/app.crt;
    ssl_certificate_key /etc/nginx/ssl/app.key;

    location / {
        proxy_pass http://myapp;
        proxy_set_header X-Forwarded-Proto https;
    }
}
server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;   # HTTP'yi HTTPS'e yonlendir
}

Üretim ortamında geçerli bir SSL sertifikası kullanmanız, hem güvenlik hem de SEO açısından zorunludur. Çok hassas senaryolarda Nginx ile arka sunucular arasındaki trafiği de şifrelemek isterseniz “SSL passthrough” veya uçtan uca TLS yapılandırması tercih edebilirsiniz.

Uygulama Katmanı ve Taşıma Katmanı Yük Dengeleme

Yukarıdaki örnekler HTTP üzerinde, yani uygulama katmanı yük dengelemedir; Nginx istek başlıklarını, URL’yi ve içeriği görebilir. Nginx ayrıca stream modülüyle taşıma katmanı (TCP/UDP) yük dengeleme de yapabilir; bu, veritabanı, MQTT veya özel protokoller için kullanışlıdır:

Dikkat Edilmesi Gerekenler

• least_conn ve ip_hash gibi yöntem direktifleri server satırlarının üstüne, upstream bloğu içine yazılır.
• Oturum (session) gerektiren uygulamalarda round-robin oturumu bozabilir; ip_hash ile yapışkanlık sağlayın. Daha sağlam çözüm, oturumları Redis gibi paylaşımlı bir depoda tutarak uygulamayı durumsuz hale getirmektir.
• backup ve down parametreleriyle yedek sunucu ve bakım modu tanımlanabilir.
• Sağlık kontrolü ve proxy_next_upstream ile arızalı sunucuların devre dışı bırakılması yönetilir.
• Nginx’in kendisi tek nokta arızasına (single point of failure) dönüşmesin diye, kritik sistemlerde iki Nginx düğümünü Keepalived/VRRP ile yedekli kurmak iyi bir pratiktir.
• Her değişiklikten sonra mutlaka nginx -t ile test edip systemctl reload nginx ile kesintisiz uygulayın.

Alastyr Altyapısında Yük Dengeli Mimari

Yük dengeleme mimarisinin gerçek değeri, altındaki ağ ve donanımın kalitesiyle ortaya çıkar. Alastyr’ın İzmir’deki kendi veri merkezi N+1 yedekli güç ve soğutmaya, RIPE NCC üyesi bağımsız AS3188 ağına ve Turk Telekom ile TurkNet üzerinden 40 Gbit yedekli bağlantıya sahiptir. Arka sunucularınızı bu altyapıdaki ayrılmış kaynaklı VPS veya bulut sunucular üzerinde konumlandırdığınızda, Nginx katmanınızın dağıttığı her isteğe düşük gecikmeyle yanıt alırsınız. Voxility ile sağlanan 1 Tbps üzeri ağ tabanlı anti-DDoS koruması da yük dengeli yapınızı hacimsel saldırılara karşı korur. KVM tabanlı sanallaştırma, düğümlerinizi hızla çoğaltıp mimarinizi yatay olarak büyütmenizi kolaylaştırır.

Sıkça Sorulan Sorular

Load balancer ne zaman gerekir?

Tek sunucu trafiği karşılayamadığında veya yüksek erişilebilirlik (kesintisizlik) gerektiğinde gerekir. Bir bakım ya da arıza anında bile hizmetin ayakta kalmasını istiyorsanız, en az iki arka sunucu ve önlerinde bir yük dengeleyici şarttır.

Round-robin nedir?

İstekleri sunuculara sırayla, eşit şekilde dağıtan varsayılan yöntemdir. Hiçbir direktif yazmazsanız Nginx bu yöntemi kullanır ve eşit güçteki durumsuz sunucular için genellikle yeterlidir.

Oturumlar bozulur mu?

Round-robin’de bozulabilir, çünkü aynı kullanıcı her istekte farklı sunucuya düşebilir. ip_hash ile aynı kullanıcı hep aynı sunucuya yönlendirilir; en kalıcı çözüm ise oturumları Redis gibi paylaşımlı bir depoda saklamaktır.

Nginx tek başına yeter mi?

Çoğu web ve API senaryosu için fazlasıyla yeter. Çok büyük ölçekte ya da Nginx katmanının kendisini yedeklemek için bulut load balancer veya Keepalived/VRRP ile ikinci bir Nginx düğümü eklenir.

SSL’i nerede sonlandırmalıyım?

Genellikle Nginx katmanında (SSL termination); şifre çözme tek noktada toplanır, sertifika yönetimi kolaylaşır ve arka sunuculara HTTP ile iletilir. Daha hassas durumlarda Nginx ile arka sunucular arasını da TLS ile şifreleyebilirsiniz.

max_fails ve fail_timeout ne işe yarar?

max_fails, bir sunucunun fail_timeout süresi içinde kaç kez başarısız olunca arızalı sayılacağını belirler. Varsayılan değer 1 deneme ve 10 saniyedir; üretimde genellikle max_fails=3 fail_timeout=15s gibi daha toleranslı değerler tercih edilir.

Açık kaynak Nginx aktif sağlık kontrolü yapar mı?

Hayır, düzenli aralıklarla istek atan aktif sağlık kontrolü (health_check) yalnızca ticari Nginx Plus sürümünde bulunur. Açık kaynak sürümde pasif sağlık kontrolü (max_fails/fail_timeout) ve harici izleme araçları kullanılır.

keepalive neden önemli?

keepalive, Nginx ile arka sunucular arasında kalıcı bağlantı havuzu tutarak her istekte yeni TCP bağlantısı kurma maliyetini ortadan kaldırır. Yoğun trafikte gecikmeyi belirgin biçimde düşürür; ancak çalışması için proxy_http_version 1.1; ve boş Connection "" başlığı gerekir.

Sunucuları farklı güçte ise dağıtımı nasıl dengelerim?

weight parametresini kullanın. Örneğin server srv1 weight=3; yazarsanız bu sunucu, varsayılan ağırlıktaki (weight=1) sunuculara göre 3 kat fazla istek alır; böylece güçlü makinelere orantılı yük binersiniz.