Load Balancer: Layer 4/7 Yük Dengeleme, HAProxy ve Nginx

Load Balancer: Layer 4/7 Yük Dengeleme, HAProxy ve Nginx

Tek bir web sunucusu, dakikada birkaç bin isteği rahatlıkla karşılayabilir. Ancak trafiğin ani şekilde 10 katına çıktığı bir kampanya günü, sunucunun yanmış bir disk üzerinden açılmaya çalışması ya da güncelleme sırasında 30 saniyelik bir restart penceresinin yaratacağı zarar düşünüldüğünde, "tek sunucu" yaklaşımı işin niteliğine göre kabul edilemez hale gelir. Load balancer (yük dengeleyici), gelen trafiği birden fazla backend sunucuya dağıtarak hem performansı ölçeklendiren hem de tekil arıza noktasını (single point of failure) ortadan kaldıran ağ bileşenidir.

Bu rehber, "Nginx upstream block'u nasıl yazılır" örneğini aşan bir referans niteliğinde. Bir sistem yöneticisinin sırasıyla karşılaştığı kararları anlatır: yük dengelemeye gerçekten ihtiyacım var mı, Layer 4 (TCP/UDP) ile Layer 7 (HTTP/HTTPS) arasındaki seçim nasıl yapılır, hangi algoritmayı (Round Robin, Least Connections, IP Hash, Consistent Hashing, Power of Two Choices) ne zaman seçerim, HAProxy ve Nginx arasındaki güçlü/zayıf yönler nelerdir, sticky session ihtiyacımı stateful uygulamadan nasıl kurtarırım, health check derinliğini nasıl artırırım, keepalived + VRRP ile load balancer'ın kendisini nasıl HA yaparım ve Buyukweb VDS altyapısı üzerinde 3 backend + 1 frontend mimarisini nasıl kurarım.

Buyukweb perspektifi: Bursa Tier 3 veri merkezimizdeki VDS E5-V4 sunucuları (₺250-600/ay aralığı), KVM tam virtualization ve root erişimi ile HAProxy veya Nginx kümeleri için ideal platformdur. 3 backend + 1 HAProxy frontend kurmak isteyen bir KOBİ için aylık ₺1.000 civarında bir bütçeyle, yurtiçi düşük gecikme ve %99.8 datacenter uptime SLA'sı ile çalışan bir HA mimarisi kurabilirsiniz. DDoS L3+L4+L7 korumamız standart, root erişimi sayesinde HAProxy/Nginx + keepalived + Redis session store gibi tüm bileşenleri kurabilir, 17+ yıl tecrübemizle mimari kararlarınızda destek alabilirsiniz. 0850 302 60 70 numaralı destek hattımızdan yük dengeleme planlamanız için bizimle iletişime geçebilirsiniz.

Yük Dengeleme Neden Gerekli? HA Mimarisi ve SPOF

Tek sunucu mimarisi (single instance) basit ve ucuz görünür, ama dört kritik açığı vardır:

1. Donanım/yazılım arızası — disk SMART hatası, RAM ECC, kernel panic, OOM kill. Tek sunucu çökerse hizmet tamamen düşer.
2. Bakım pencerelendirilemez — kernel update, paket yükseltme, uygulama deployment için restart gerektiğinde mecburen "downtime" oluşur.
3. Ölçeklenememe — CPU/RAM tek makinenin sınırlarına dayandığında scale up (daha güçlü tek sunucu) belli bir noktadan sonra mantıksız hale gelir.
4. Coğrafi yedeklilik yok — datacenter bazlı bir kesinti (fiber kesilmesi, soğutma arızası, elektrik) tüm hizmeti durdurur.

Load balancer, bu açıkları kapatmanın ilk ve en yaygın katmanıdır. Bir LB + 2 backend mimarisi:

İstemci → Load Balancer → Backend 1 (sağlıklı)
                       → Backend 2 (sağlıklı)

Backend 1 çökerse:
İstemci → Load Balancer → Backend 1 (DOWN — trafik almaz)
                       → Backend 2 (tüm trafiği alır)

LB, periyodik health check ile her backend'in sağlıklı olup olmadığını izler. Sağlıksız bir backend tespit edilirse trafiği otomatik olarak diğer backend'lere yönlendirir; kullanıcı genelde bunu hiç fark etmez.

Single Point of Failure (SPOF): LB'nin Kendisi

Burada hemen ortaya çıkan soru şu: "Yedek backend'ler var ama LB tek başına çalışıyorsa, LB çöktüğünde ne olur?" Cevap: tüm hizmet düşer. LB kendisi de SPOF'tur. Bu nedenle profesyonel HA mimarileri iki LB (primary + standby) ve aralarında keepalived + VRRP ile virtual IP devretme mekanizması kurarlar. İlerleyen bölümlerde bu yapıyı detaylandırıyoruz.

Layer 4 vs Layer 7 Load Balancer: Hız mı, Zekâ mı?

Load balancer'ları sınıflandırırken kullanılan en kritik ayrım, OSI katman seviyesinde hangi katmanda çalıştığıdır. İki temel kategori vardır: Layer 4 (Transport) ve Layer 7 (Application).

OSI Katmanları Hatırlatma

Layer 7 — Application (HTTP, FTP, SMTP, DNS, SSH)
Layer 6 — Presentation (TLS/SSL, encoding)
Layer 5 — Session
Layer 4 — Transport (TCP, UDP — port numarası)
Layer 3 — Network (IP — adres)
Layer 2 — Data Link (Ethernet, MAC adresi)
Layer 1 — Physical (kablo, sinyal)

Layer 4 LB: Hızlı, Şeffaf, İçeriği Görmeyen

Layer 4 yük dengeleyici, paketleri TCP/UDP başlıkları seviyesinde işler. Yani hangi IP'den hangi porta doğru bir bağlantı geliyor görür; bağlantı içeriğinin ne olduğunu (HTTP request body, URL, header) okumaz, sadece paketi backend'e iletir.

Avantajlar:

• Çok hızlı — paket inspection yok, sadece NAT veya DSR (Direct Server Return) ile iletme
• Protokol bağımsız — TCP üzerinde çalışan herhangi bir uygulama (MySQL, PostgreSQL, MQTT, Redis, SSH, RDP) için kullanılabilir
• CPU tasarrufu — SSL handshake yapmaz, body parse etmez
• Düşük gecikme — ekstra Layer 7 processing yok

Dezavantajlar:

• URL/path tabanlı routing yapamaz — /api/* ve /static/* ayrı backend'e gönderilemez
• HTTP header üzerinden cookie tabanlı sticky session yapamaz
• SSL termination yapamaz (yapacak şekilde de kurulamaz — encryption seviyesini görmez)
• WAF (Web Application Firewall) entegrasyonu yapılamaz

Tipik kullanım: MySQL replication cluster önünde, MQTT broker önünde, SSH bastion kümesi önünde, HAProxy TCP mode veya ticari bulut Layer 4 LB hizmetleri (yurt dışı sağlayıcıların TCP/UDP LB'leri).

Layer 7 LB: Zeki, Esnek, HTTP Bilen

Layer 7 yük dengeleyici, HTTP istek detayını parse eder: URL path, query string, header'lar, cookie'ler, hatta gerekirse body. Bu bilgilerle akıllı routing kararları alır.

Avantajlar:

• Path tabanlı routing — /api/* → backend grubu A, /static/* → backend grubu B, /admin/* → ayrı sıkı korunan grup
• Header tabanlı routing — User-Agent: mobile → mobil backend, X-Tenant: musteri42 → o müşterinin backend'i
• Cookie tabanlı sticky session — Set-Cookie: SERVERID=web1 ile aynı kullanıcı hep aynı backend'e
• SSL termination — LB üzerinde TLS sonlandırma → backend'ler düz HTTP konuşur, sertifika tek noktada yönetilir
• Content rewriting — header ekle/sil, response body düzenle, redirect üret
• WAF entegrasyonu — ModSecurity gibi modüller HTTP request inceleyebilir
• HTTP/2, HTTP/3 desteği — backend'ler eski HTTP/1.1 konuşsa bile LB modern protokoller sunabilir

Dezavantajlar:

• L4'e göre daha yavaş (her isteği parse etmesi gerekir)
• CPU yoğun (özellikle SSL termination + WAF varsa)
• Sadece desteklenen protokoller (HTTP/HTTPS, gRPC, WebSocket) için çalışır — generic TCP/UDP için kullanılmaz

Tipik kullanım: Web uygulamaları, mikroservis API gateway, e-ticaret platformları, Nginx, HAProxy HTTP mode, Traefik, Envoy.

Hibrit Yaklaşım: L4 + L7 Birlikte

Modern büyük mimarilerde sıklıkla iki katmanlı yapı görülür: dış katmanda Layer 4 LB (saniyede 1M+ paket dengeleme), iç katmanda Layer 7 LB (uygulama routing). Bu yapı request başına maliyeti düşürürken esnekliği korur.

Yük Dengeleme Algoritmaları: Karşılaştırma Matrisi

Hangi algoritma hangi senaryoda doğru? Aşağıda en yaygın algoritmaların özellikleri ve "ne zaman kullan" senaryoları:

Algoritma	Çalışma Şekli	Ne Zaman Kullan	Dezavantaj
Round Robin	S1→S2→S3→S1... sırayla	Backend'ler eşit kapasiteli, istekler eşit ağırlıkta	Backend kapasiteleri farklıysa zayıf
Weighted Round Robin	Ağırlık oranında dağıt (S1:3, S2:1)	Backend kapasiteleri farklı (yeni güçlü makine + eski makine)	Bağlantı sayısını dikkate almaz
Least Connections	En az aktif bağlantısı olan backend'e	İstek süreleri farklı (uzun WebSocket + kısa HTTP karışık)	Hesaplama yükü hafif ama Round Robin'den fazla
Weighted Least Conn	Ağırlık + bağlantı sayısı kombine	Karma kapasite + karma istek süresi	En karmaşık tuning
IP Hash	Client IP hash → sabit backend	Sticky session gerekli ama cookie kullanılamıyor (TCP, mobil app)	IP değişen istemciler (NAT, mobile) sticky kaybeder
URI Hash	URL hash → sabit backend	CDN cache, statik dosya cache locality	Backend ekle/sil → cache miss patlaması
Random + Power of Two Choices	Rastgele 2 seç, az yüklü olanı	Yüksek ölçekli sistemler, basit ama etkili	Tam optimal değil ama yakın
Least Response Time	En hızlı yanıt veren backend	Backend'lerden bazıları yavaşladığında otomatik kaçınma	HAProxy'de mevcut; Nginx OSS'te yerleşik değil (ticari Nginx sürümlerinde var)
Consistent Hashing	Hash ring, backend ekle/sil → minimum yeniden hashing	Cache cluster (memcached, Redis), distributed system	Karmaşık, az kullanılır web LB'de
Source Hash	Client IP + port kombine	Daha granüler sticky (NAT arkasındaki çoklu istemciyi ayır)	IP hash benzeri sınırlar

Önerilen Pratik Seçimler

• Stateless web uygulaması (Laravel API, Express.js REST) → Round Robin veya Least Connections
• WebSocket / uzun bağlantılar → Least Connections veya Least Time
• Stateful eski uygulama (PHP session dosyada) → IP Hash veya Cookie sticky
• CDN / cache cluster → Consistent Hashing veya URI Hash
• Mikroservis mesh içi → Random + Power of Two Choices (Envoy default)

HAProxy: Tarihçe, Mimari ve Konfigürasyon

HAProxy, 2001 yılında Willy Tarreau tarafından C dilinde yazılmaya başlanan ve günümüzde dünyanın en yaygın açık kaynak yük dengeleyicilerinden biri olan event-driven proxy yazılımıdır. epoll sistem çağrısı üzerine kurulu, HAProxy 2.x sürümüyle multi-thread mimariye geçmiştir (önceden tek process / tek thread'ti).

Neden HAProxy?

• Yüksek performans — 100k+ eşzamanlı bağlantı tek makinede
• Düşük bellek — bağlantı başına ~10 KB
• Aktif geliştirme — yıllık major release
• Zengin metrik — runtime stats interface, Prometheus exporter
• L4 + L7 birlikte — TCP mode ve HTTP mode aynı binary
• Gelişmiş ACL — istek detayına göre routing
• Health check derinliği — TCP, HTTP, custom expect, agent-check

Konfigürasyon Yapısı

HAProxy konfigürasyon dosyası (/etc/haproxy/haproxy.cfg) genelde beş bölümden oluşur:

global       — Process-level ayarlar (user, daemon, log, ulimit, maxconn)
defaults     — Ortak frontend/backend ayarları (timeout, mode, options)
frontend     — Dinleyici (gelen trafiği karşılayan)
backend      — Hedef sunucu havuzu
listen       — frontend + backend birleşik kısa form (basit kurulumlar için)

Tipik HAProxy Konfigürasyonu

global
    log /dev/log local0 info
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    maxconn 50000
    ssl-default-bind-ciphers ECDHE+AESGCM:ECDHE+CHACHA20
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11

defaults
    log     global
    mode    http
    option  httplog
    option  dontlognull
    option  forwardfor
    option  http-server-close
    timeout connect 5s
    timeout client  60s
    timeout server  60s
    timeout http-request 10s
    timeout http-keep-alive 15s

frontend https_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/buyukweb.pem alpn h2,http/1.1
    redirect scheme https code 301 if !{ ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    http-request set-header X-Forwarded-Port %[dst_port]

    # Path tabanlı routing
    acl is_api    path_beg /api/
    acl is_static path_beg /static/
    acl is_admin  path_beg /admin/

    use_backend api_backend    if is_api
    use_backend static_backend if is_static
    use_backend admin_backend  if is_admin
    default_backend web_backend

backend web_backend
    balance roundrobin
    option httpchk GET /healthz HTTP/1.1\r\nHost:\ buyukweb.com
    http-check expect status 200
    cookie SERVERID insert indirect nocache
    server web1 10.0.1.10:8080 check inter 5s rise 2 fall 3 cookie web1
    server web2 10.0.1.11:8080 check inter 5s rise 2 fall 3 cookie web2
    server web3 10.0.1.12:8080 check inter 5s rise 2 fall 3 cookie web3
    server web_backup 10.0.1.13:8080 backup

backend api_backend
    balance leastconn
    option httpchk GET /api/health
    http-check expect status 200
    server api1 10.0.2.10:9000 check inter 3s rise 2 fall 3
    server api2 10.0.2.11:9000 check inter 3s rise 2 fall 3

backend static_backend
    balance uri whole
    hash-type consistent
    server cdn1 10.0.3.10:80 check
    server cdn2 10.0.3.11:80 check

backend admin_backend
    balance source
    server admin1 10.0.4.10:8080 check
    server admin2 10.0.4.11:8080 check backup

listen stats
    bind *:8404
    mode http
    stats enable
    stats uri /stats
    stats refresh 5s
    stats auth admin:GUCLU_PAROLA_BURAYA
    stats hide-version

Kritik Direktiflerin Açıklaması

• bind *:443 ssl crt /etc/haproxy/certs/buyukweb.pem alpn h2,http/1.1 — TLS sertifikası ve HTTP/2 (h2) ALPN desteği
• acl is_api path_beg /api/ — request path /api/ ile başlıyorsa is_api true
• use_backend api_backend if is_api — koşulu sağlayan istekleri yönlendir
• option httpchk GET /healthz — backend health check için HTTP GET /healthz
• http-check expect status 200 — sadece 200 sağlıklı kabul
• cookie SERVERID insert indirect nocache — sticky cookie ekle, indirekt mod (önceki cookie korunur), cache'de tutma
• server web1 ... cookie web1 — bu backend'in cookie değeri web1
• backup — sadece tüm normal sunucular DOWN ise devreye girer
• inter 5s rise 2 fall 3 — 5 sn aralıkla check, 2 başarılı = UP, 3 başarısız = DOWN

Stats Interface

http://lb.buyukweb.com:8404/stats

Browser üzerinden HAProxy'nin canlı dashboard'ına bakabilirsiniz: hangi backend kaç istek aldı, ne kadar bayt aktardı, son N saniyede kaç bağlantı, hangi backend DOWN. Production'da auth + IP whitelist ile koruyun.

HAProxy SSL Termination + SNI + Map Dosyaları

Birden fazla domain için tek HAProxy üzerinde TLS sonlandırma:

frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/ alpn h2,http/1.1
    # /etc/haproxy/certs/ dizini içinde her domain için ayrı .pem
    # HAProxy SNI'ya göre otomatik doğru sertifikayı seçer

    use_backend %[req.hdr(host),lower,map(/etc/haproxy/maps/hosts.map,default_backend)]

hosts.map dosyası:

buyukweb.com         web_backend
api.buyukweb.com     api_backend
shop.buyukweb.com    shop_backend
admin.buyukweb.com   admin_backend

Map dosyası sayesinde yüzlerce domain tek frontend altında yönetilebilir; yeni domain eklemek hosts.map'e bir satır eklemekten ibaret.

Nginx Load Balancer: Web Sunucu + LB Birlikte

Nginx, Igor Sysoev tarafından 2004'te yazılmış, başlangıçta yüksek concurrency web sunucu olarak tasarlanmış ve sonradan reverse proxy + load balancer olarak da yaygınlaşmış event-driven bir HTTP sunucusudur. HAProxy'den farklı olarak Nginx aynı zamanda statik dosya servisi, caching, mod_php-FPM proxy gibi web sunucu rollerini de tek başına üstlenebilir.

Nginx upstream Bloğu

upstream backend {
    least_conn;
    server 10.0.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 weight=2;
    server 10.0.1.12:8080 weight=1;
    server 10.0.1.13:8080 backup;
    server 10.0.1.14:8080 down;   # geçici devre dışı

    keepalive 32;
    keepalive_timeout 60s;
    keepalive_requests 1000;
}

upstream api_servers {
    ip_hash;
    server 10.0.2.10:9000;
    server 10.0.2.11:9000;
}

upstream cache_servers {
    hash \$request_uri consistent;
    server 10.0.3.10:80;
    server 10.0.3.11:80;
    server 10.0.3.12:80;
}

upstream mobile_api {
    random two least_conn;
    server 10.0.4.10:9000;
    server 10.0.4.11:9000;
    server 10.0.4.12:9000;
}

Nginx Server + location Bloğu

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name buyukweb.com www.buyukweb.com;

    ssl_certificate     /etc/letsencrypt/live/buyukweb.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/buyukweb.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

    location / {
        proxy_pass         http://backend;
        proxy_http_version 1.1;
        proxy_set_header   Connection "";
        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_set_header   X-Forwarded-Host  \$host;
        proxy_set_header   X-Forwarded-Port  \$server_port;

        proxy_connect_timeout 5s;
        proxy_send_timeout    60s;
        proxy_read_timeout    60s;

        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;
        proxy_next_upstream_timeout 10s;
    }

    location /api/ {
        proxy_pass http://api_servers;
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
    }

    location /static/ {
        proxy_pass http://cache_servers;
        proxy_cache_key "\$scheme\$request_method\$host\$request_uri";
        expires 1d;
        add_header Cache-Control "public, immutable";
    }
}

server {
    listen 80;
    server_name buyukweb.com www.buyukweb.com;
    return 301 https://\$host\$request_uri;
}

Önemli Nginx Direktifleri

• least_conn — en az aktif bağlantısı olan backend'e dağıt
• ip_hash — client IP hash'i ile aynı backend'e (sticky session)
• hash \$request_uri consistent — URL hash + consistent hashing (cache)
• random two least_conn — Power of Two Choices algoritması
• keepalive 32 — upstream'e 32 kalıcı bağlantı havuzu (latency düşer)
• max_fails=3 fail_timeout=30s — 30 sn içinde 3 hata = DOWN say (passive health check)
• backup — sadece normal backend'ler DOWN ise devreye
• proxy_next_upstream error timeout http_502 — backend hatasında otomatik diğer backend'e dene

Active Health Check: ngx_http_upstream_check_module

Nginx open-source sürümünün yerleşik active health check özelliği yoktur (sadece passive: istek başarısız olursa fail say). Aktif kontrol (periyodik /health probe) için iki seçenek:

1. ngx_http_upstream_check_module (3rd party patch) — Tengine projesinden derive, kaynak koddan compile gerektirir
2. Ticari Nginx sürümleri — yerleşik aktif health check + canlı dashboard (lisans gerektirir)

KOBİ için en pratik yaklaşım: backend kendi /healthz endpoint'ini açar, monitoring servisinden (Prometheus blackbox exporter, healthchecks.io vb.) bağımsız izleme yapılır, Nginx passive fail mekanizması kullanılır.

Sticky Session: Stateful Uygulama Sorunu ve Çözümleri

Bazı eski uygulamalar user session bilgisini server local diskte veya RAM'inde tutar (PHP'nin default session handler'ı, eski Java app session). Bu durumda kullanıcının her isteğinin aynı backend'e gitmesi gerekir, yoksa "neden sürekli logout oluyorum?" sorusu doğar.

Sticky Session Yöntemleri

1. Cookie tabanlı sticky (En yaygın)

HAProxy:
cookie SERVERID insert indirect nocache
server web1 10.0.1.10:8080 cookie web1
server web2 10.0.1.11:8080 cookie web2

Nginx (sticky modülü OSS'te 3rd party, ticari sürümlerde yerleşik):
upstream backend {
    sticky cookie srv_id expires=1h domain=.buyukweb.com path=/;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
}

LB cookie'ye backend ID koyar, sonraki isteklerde aynı backend'e iletir. En esnek yöntem.

2. IP Hash

Nginx: ip_hash;
HAProxy: balance source;

Client IP'ye göre sabit backend. Avantaj: cookie gerekmez. Dezavantaj: NAT arkasındaki tüm istemciler aynı backend'e gider (load dağılmaz), mobile IP değişimi sticky'yi kırar.

3. Application-level token (JWT)

Modern stateless yaklaşım. Backend session bilgisini DB'ye yazar veya JWT içine encode eder. Hangi backend istek alırsa alsın aynı şekilde davranır. Sticky'ye ihtiyaç kalmaz.

4. Redis (veya benzeri) session store (Önerilen en iyi pratik)

[Client] → [LB Round Robin] → [Backend1, Backend2, Backend3]
                                       ↓
                              [Shared Redis Session Store]

Uygulama, session bilgisini local disk yerine Redis cluster'a yazar. Tüm backend'ler aynı Redis'e bakar; sticky'ye gerek yok, kullanıcı hangi backend'e düşse session'ı bulur. PHP, Laravel, Django, Rails için redis session driver paketleri standarttır.

Sticky session mecbur kalmadıkça kaçınılması gereken bir patterndir. HA mimaride bir backend çöktüğünde o backend'e bağlı tüm kullanıcılar session'larını kaybeder. Stateless app + Redis session store kombinasyonu modern ve dirençli yaklaşımdır.

Sağlık Kontrolü (Health Check): Derinlik Seviyeleri

LB'nin backend'leri "sağlıklı/sağlıksız" değerlendirme şekli, mimarinin dayanıklılığında kritik rol oynar:

Seviye 1: TCP Health Check (En Yüzeysel)

HAProxy: server web1 10.0.1.10:8080 check

LB sadece TCP bağlantı açabiliyor mu kontrol eder. Sorun: uygulama proses crash olmuş, ama port açık (örneğin nginx hayatta ama PHP-FPM ölü) durumunu yakalamaz.

Seviye 2: HTTP GET / Health Check

HAProxy:
option httpchk GET /
http-check expect status 200

LB GET / yapar, 200 dönmesini bekler. Sorun: ana sayfa cache'lenebilir, gerçek backend probleminin (DB connection lost) farkına varmaz.

Seviye 3: HTTP GET /healthz Custom Endpoint (Önerilen)

HAProxy:
option httpchk GET /healthz HTTP/1.1\r\nHost:\ backend.local
http-check expect status 200

Backend'de /healthz endpoint'i şunları kontrol eder:

GET /healthz response:
{
  "status": "ok",
  "checks": {
    "db_connection": "ok",
    "redis_connection": "ok",
    "disk_space": "ok (85%)",
    "memory": "ok"
  }
}

Backend kendi bağımlılıklarını (DB, cache, queue) test eder; hepsi tamamsa 200, biri bozuksa 503. LB gerçek sağlığı görür.

Seviye 4: Deep Application Check (Aşırı)

Health endpoint ağır iş yapar: gerçek query, gerçek cache yazma. Risk: health check'in kendisi backend'i yorar. Kullanmayın — ölçülü tutun.

Seviye 5: gRPC Health Checking Protocol

Mikroservisler için gRPC Health Checking Protocol standartlaşmıştır (grpc.health.v1.Health/Check RPC). HAProxy 2.4+ option httpchk ile h2c üzerinden gRPC check yapabilir; Envoy native destekli.

Health Check Tuning

inter 5s     — Kontrol aralığı (5 saniye normal, 1-2 sn agresif)
timeout check 3s  — Tek bir check'in maksimum süresi
rise 2       — 2 başarılı check sonrası UP (false positive azalır)
fall 3       — 3 başarısız sonrası DOWN (false negative azalır)

Çok agresif (1 sn check, fall 1) flapping yaratabilir; çok yavaş (60 sn check) gerçek arızayı geç fark eder. 5s inter / fall 3 / rise 2 standart başlangıç.

Failover ve HA: keepalived + VRRP + Virtual IP

LB'nin kendisinin SPOF olmaması için iki LB kurulur ve aralarında virtual IP (VIP) dolaşır:

[ İstemci ]
    ↓ DNS → 195.85.100.100 (Virtual IP)
    ↓
[ VIP: 195.85.100.100 ]
    ↓ ↓ (VRRP advertisement)
[ LB1 MASTER ]   [ LB2 BACKUP ]
    ↓                  (LB1 öldüğünde VIP buraya geçer)
    ↓
[ Backend1, Backend2, Backend3 ]

keepalived Konfigürasyonu

# /etc/keepalived/keepalived.conf — LB1 (MASTER)

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass paylasilan_parola
    }
    virtual_ipaddress {
        195.85.100.100/24
    }
    track_script {
        chk_haproxy
    }
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
}

# /etc/keepalived/keepalived.conf — LB2 (BACKUP)

vrrp_instance VI_1 {
    state BACKUP
    interface eth0
    virtual_router_id 51
    priority 90        # Master'dan düşük
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass paylasilan_parola
    }
    virtual_ipaddress {
        195.85.100.100/24
    }
}

VRRP Nasıl Çalışır?

VRRP (Virtual Router Redundancy Protocol), RFC 5798 ile tanımlanmış bir HA protokolüdür:

1. MASTER her saniye multicast advertisement gönderir ("Ben hayatta, VIP bende")
2. BACKUP advertisement'ları dinler
3. BACKUP 3 saniye boyunca advertisement alamazsa kendini MASTER ilan eder
4. ARP gratuitous gönderir → switch'lere "VIP artık benim MAC adresimde"
5. Trafik LB2'ye akmaya başlar

Tipik failover süresi: 3-4 saniye. Bu sürede yarım kalan TCP bağlantılar düşer; yeni bağlantılar LB2'ye gider.

conntrackd: TCP State Senkronizasyonu

Daha sıfır kayıplı bir failover için conntrackd (conntrack daemon) ile iki LB arasında TCP bağlantı tablosu senkronize edilebilir. Master'da aktif olan TCP bağlantılar Backup'a sürekli replicate edilir; failover sırasında Backup bağlantıları sürdürür. Karmaşık ama sıfır downtime hedefleyen sistemler için tercih edilir.

Anycast DNS Alternatifi

VRRP + VIP tek datacenter içindir. Birden fazla datacenter'da LB çalıştıran büyük operasyonlar Anycast DNS kullanır: aynı IP adresi birden fazla coğrafyada duyurulur, BGP routing en yakın olana yönlendirir. Bu yaklaşım CDN dağıtım modelidir ve KOBİ ölçeğinde nadir tercih edilir.

Layer 7 Traffic Management: Canary, Blue-Green, A/B Testing

Layer 7 LB'nin gücü sadece routing değil; deployment stratejilerini mümkün kılmasıdır:

Canary Deployment (Aşamalı Sürüm)

Yeni sürümü tüm trafiğe değil, küçük bir oranına yönlendirip metrikleri izleyerek aşamalı genişletme:

%5  → yeni sürüm (canary)   |   %95 → eski sürüm
↓ izlemeden sonra
%25 → yeni                   |   %75 → eski
↓ hala iyi
%50 → yeni                   |   %50 → eski
↓ son kontrol
%100 → yeni                  |   eski sunucular kaldırılır

HAProxy ile:

frontend http_in
    bind *:80
    acl is_canary rand(100) lt 5
    use_backend canary if is_canary
    default_backend stable

backend canary
    server canary1 10.0.5.10:8080 check

backend stable
    server stable1 10.0.1.10:8080 check
    server stable2 10.0.1.11:8080 check

rand(100) lt 5 → her isteğin %5'i canary'ye yönlendirilir.

Blue-Green Deployment

İki paralel ortam (Blue = mevcut, Green = yeni). Geçiş anlık:

Mevcut: LB → Blue (canlı)         Green (deploy edildi, test ediliyor)

Geçiş:  LB → Green (yeni canlı)   Blue (geri dönüş için bekliyor)

LB konfigürasyonunda backend pointer değiştirilir; geri dönüş 1 saniyede mümkündür.

A/B Testing

Aynı anda iki versiyon çalıştırma, kullanıcıların belirli bir özelliği (yeni ödeme butonu, yeni navigasyon) görme oranını ayarlayıp dönüşüm oranlarını kıyaslama. Cookie tabanlı sticky ile her kullanıcı aynı variant'ı görür.

Request Mirroring (Shadow Traffic)

Production trafiğin kopyasını test ortamına paralel gönderme:

location /api/ {
    mirror /mirror;
    proxy_pass http://prod_backend;
}

location = /mirror {
    internal;
    proxy_pass http://test_backend\$request_uri;
}

Test backend gerçek production yükü altında test edilir; cevabı kullanıcıya gitmez, sadece izlenir. Yeni sürümün performansını gerçek trafikte ölçmek için ideal.

Database Load Balancing: ProxySQL ve pgpool-II (Kavramsal)

Veritabanı yük dengeleme web LB'den farklıdır. Genel yaklaşım:

• MySQL için ProxySQL (gelişmiş query routing, sharding, query rewriting) veya HAProxy TCP mode (basit round robin)
• PostgreSQL için pgpool-II (connection pooling + read/write split) veya PgBouncer (pool) + HAProxy (write/read ayrımı)
• Read replica'lar arasında SELECT dağıtımı, INSERT/UPDATE/DELETE master'a sabit
• Health check SQL query bazlı: SELECT 1 (basit) veya SHOW SLAVE STATUS (replication gecikmesi kontrolü)

HAProxy MySQL read replica örnek:

backend mysql_read
    balance leastconn
    option mysql-check user haproxy_check
    server replica1 10.0.10.10:3306 check
    server replica2 10.0.10.11:3306 check
    server replica3 10.0.10.12:3306 check

KOBİ ölçeğinde MySQL/MariaDB master + 1-2 replica + ProxySQL kombinasyonu yaygındır. VDS üzerinde tam root erişimle bu mimari kurulabilir.

Geliştirici Alternatifleri: Traefik, Caddy, Envoy, Service Mesh

HAProxy ve Nginx dışında kavramsal olarak bilinmesi gereken modern alternatifler:

Traefik

• Docker reverse proxy + auto-discovery
• Yeni container ayağa kalktığında otomatik routing kuralı oluşturur
• Label tabanlı konfigürasyon
• Let's Encrypt entegre, otomatik sertifika
• Modern dashboard
• Container ortamları için ideal; bare-metal'de daha az yaygın

Caddy

• Otomatik HTTPS (Let's Encrypt out-of-the-box)
• Çok basit syntax (Caddyfile)
• HTTP/3 yerleşik
• Performans HAProxy/Nginx'ten düşük ama yapılandırma çok kolay
• Küçük projelerde, hızlı setup için tercih

Envoy Proxy

• Cloud Native Computing Foundation projesi
• L4 + L7 + service mesh data plane
• Observability güçlü (out-of-box Prometheus metrics, tracing)
• Karmaşık YAML konfigürasyon (control plane gerektirir)
• Kubernetes ortamlarında istio/linkerd ile yaygın

Istio Service Mesh

• Envoy sidecar + control plane
• Mikroservis dünyasında mTLS, circuit breaker, retry policy, distributed tracing otomatik
• Kubernetes üzerinde çalışır
• Operasyonel karmaşıklık yüksek; ekibin DevOps olgunluğu gerekir

Bu rehberde HAProxy + Nginx odağında self-host kurulum anlatıldı çünkü Buyukweb VDS'te en pratik ve dökümante yaklaşım budur. Service mesh çözümleri Kubernetes cluster gerektirir ve farklı bir kategoride değerlendirilmelidir.

Buyukweb VDS Mimari Örneği: 3 Backend + 1 HAProxy Frontend

KOBİ ölçeğinde tipik bir HA mimari:

                    [ İnternet ]
                          ↓
                  [ Cloudflare (opsiyonel CDN/WAF) ]
                          ↓
                  [ VDS-LB1: HAProxy + keepalived ]
                  10.0.0.10  ← VIP: 195.85.100.100
                          ↓
            ┌─────────────┼─────────────┐
            ↓             ↓             ↓
        [ VDS-W1 ]    [ VDS-W2 ]    [ VDS-W3 ]
        10.0.0.21     10.0.0.22     10.0.0.23
        Nginx+PHP-FPM Nginx+PHP-FPM Nginx+PHP-FPM
            │             │             │
            └─────────────┼─────────────┘
                          ↓
                  [ VDS-DB: MariaDB + Redis ]
                          10.0.0.30

Buyukweb Paket Önerisi

Rol	Paket	Aylık	Detay
LB Frontend (VDS-LB1)	VDS E5-V4 Orta	~₺350	2 vCPU, 4 GB RAM, 80 GB NVMe
Web Backend × 3 (VDS-W1/2/3)	VDS E5-V4 Performans	~₺350 × 3 = ₺1.050	4 vCPU, 8 GB RAM, 160 GB NVMe
DB + Redis (VDS-DB)	VDS E5-V4 Pro	~₺550	4 vCPU, 16 GB RAM, 240 GB NVMe
Toplam aylık		~₺1.950	5 VDS, HA + ölçeklenebilir

Fiyatlar tahminidir, güncel için VDS sunucu sayfasına bakınız. KDV dahildir. Yüksek trafik durumunda Dedicated/Fiziksel Sunucu paketlerimize geçiş daha uygun olabilir.

Mimari Avantajları

• 3 backend → bir tanesi çökerse %33 kapasite kaybı, ama hizmet kesintisiz
• HAProxy frontend → SSL termination + path routing + sticky cookie + canary
• Aynı datacenter (Bursa Tier 3) → backend'lerle LB arasında düşük gecikme (<1ms)
• DDoS L3+L4+L7 standart → datacenter seviyesi koruma
• Geliştirme aşamasında ikinci LB (VDS-LB2) eklenip keepalived ile VIP HA yapılabilir

Bir Sonraki Adım: LB HA İçin İkinci Frontend

Yukarıdaki mimari LB-SPOF içerir. Tamamen HA hale getirmek için:

VDS-LB1: HAProxy + keepalived (MASTER)  → 10.0.0.10
VDS-LB2: HAProxy + keepalived (BACKUP)  → 10.0.0.11
VIP: 195.85.100.100 (her ikisinde de tanımlı)

Bir VDS daha ekleyerek (~₺350/ay), LB SPOF'u ortadan kaldırırsınız. Toplam aylık ~₺2.300.

Performance Tuning: HAProxy ve Nginx Sistem Ayarları

Yüksek trafikte LB'nin gerçek limitlerini açmak için sistem seviyesi tuning gerekir:

HAProxy Tuning

# /etc/security/limits.conf
haproxy soft nofile 200000
haproxy hard nofile 200000

# /etc/haproxy/haproxy.cfg global
global
    maxconn 100000
    nbthread 4         # CPU core sayısı kadar (2.x+)
    cpu-map 1/1 0
    cpu-map 1/2 1
    cpu-map 1/3 2
    cpu-map 1/4 3

Linux Sysctl

# /etc/sysctl.d/99-haproxy.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 100000
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# sysctl -p uygula

Nginx Tuning

# /etc/nginx/nginx.conf
worker_processes auto;        # CPU core sayısı
worker_rlimit_nofile 200000;

events {
    worker_connections 50000;
    use epoll;
    multi_accept on;
}

http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    open_file_cache max=200000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    open_file_cache_errors on;
}

Observability: Metrik, Log, Trace

Production LB'nin gözünüzün önünde olması kritik:

HAProxy Prometheus Exporter

HAProxy 2.0+ yerleşik Prometheus endpoint sunar:

frontend prometheus
    bind *:8405
    mode http
    http-request use-service prometheus-exporter if { path /metrics }
    no log

Prometheus tarafından scrape edilen örnek metrikler:

haproxy_backend_current_sessions{backend="web_backend"}
haproxy_backend_http_responses_total{backend="web_backend",code="5xx"}
haproxy_backend_response_time_average_seconds{backend="web_backend"}
haproxy_server_status{backend="web_backend",server="web1"}

Nginx VTS Module

vts (Virtual host Traffic Status) modülü:

http {
    vhost_traffic_status_zone;
}
server {
    location /status {
        vhost_traffic_status_display;
        vhost_traffic_status_display_format json;
    }
}

JSON dashboard veya Grafana panel ile bağlanır.

Log Analizi

HAProxy log örneği:
Mar 15 10:23:11 lb1 haproxy[1234]: 10.0.0.1:54321 [15/Mar/2026:10:23:11.123]
    https_in~ web_backend/web2 0/0/1/45/46 200 1234
    - - ---- 1/1/0/0/0 0/0

Anlamı: Client IP, timestamp, frontend/backend/server, timing (Tq/Tw/Tc/Tr/Tt), HTTP status, byte count, connection count.

Response time histogramı çıkarın: P50, P95, P99 metrikleriniz hangi backend yavaşlamış görmenizi sağlar.

10 Yaygın Yanlış ve Doğru Yaklaşım

1. SSL termination yapılan LB arkasında HTTP/2 server push beklenmesi — SSL kesildikten sonra backend düz HTTP/1.1, server push çalışmaz. Backend'lere HTTPS ile gidin veya server push'tan vazgeçin.
2. X-Forwarded-For zincirinin doğrulanmaması — Backend bu header'ı körce trust ediyorsa, Internet üzerinden gelen sahte X-Forwarded-For ile IP spoofing mümkün. LB'den önceki trusted proxy'leri whitelist tutun.
3. Tek LB SPOF olarak bırakılması — Production'da en az 2 LB + VRRP zorunludur.
4. Sticky session yerine stateless app yapılmaması — Backend çöktüğünde session kaybı. Redis session store kullanın.
5. Health check'in TCP düzeyinde kalması — Backend uygulama crash olduğu halde port açık → LB sağlıklı sanır. HTTP /healthz endpoint zorunlu.
6. Maxconn limitinin düşük bırakılması — Trafik artışında "queue tıkalı, 503" yaşanır. global maxconn 50000+ koyun.
7. Backend timeout'ların LB'den uzun olması — LB 30s, backend 60s ise LB önce kopar, isteğin durumu belirsiz. Backend timeout < LB timeout.
8. Cache header'ların upstream'de set edilmemesi — LB önünde Cloudflare/CDN varsa Cache-Control backend'den gelmeli.
9. TLS sertifikalarının auto-renew kurulmaması — Sertifika expire olduğunda LB tüm trafiği reddeder. Let's Encrypt + cron.
10. Stats/admin endpoint'in public açık bırakılması — /stats HTTP Basic Auth + IP whitelist + dedicated port gerektirir.

Sık Sorulan Sorular (SSS)

"Load balancer'a gerçekten ihtiyacım var mı? Tek VDS yetmiyor mu?"

Tek VDS şu durumlarda yeterlidir: günlük tekil ziyaretçi <5.000, RPS <50, planlı bakım pencereleri için kullanıcı toleransı var, gelir kaybına neden olmayan bir blog/kurumsal site. LB gereksinimi: kesintisiz hizmet zorunluluğu (e-ticaret, SaaS, API), trafik dalgalanması büyük (kampanya, viral), 50+ RPS sürekli, A/B test/canary deployment ihtiyacı, ölçeklenebilirlik planı (yıl içinde 5x trafik beklentisi).

"cPanel paylaşımlı hostingde load balancer var mı?"

cPanel paylaşımlı paketler tek sunucu üzerinde çalışır; arka planda LB değil, paylaşımlı kaynak modelidir. Yüksek erişilebilirlik ve yük dengeleme için VDS veya Dedicated/Fiziksel Sunucu üzerinde HAProxy/Nginx self-host kurulumu gereklidir. Buyukweb VDS paketlerinde KVM tam virtualization + root erişimi ile her türlü LB stack'i kurabilirsiniz.

"CDN load balancer sayılır mı?"

CDN (Cloudflare gibi) edge'de cache + DDoS koruma + bazı routing yapar; tam anlamıyla LB değildir ama bazı işlevleri örtüşür. CDN sadece statik içerik (resim, CSS, JS) ve cache'lenebilir dinamik içeriği hızlandırır. Dinamik backend'leriniz arasında yük dağıtımı için yine CDN + LB (HAProxy/Nginx) ikili mimari önerilir. Cloudflare → LB → Backends akışı yaygındır.

"HAProxy mi Nginx mi?"

Kısa cevap: HAProxy salt LB için, Nginx web sunucu + LB karması için. HAProxy daha derin LB özellikleri (gelişmiş health check, ACL, observability, ProxySQL-like DB LB) sunar; Nginx HAProxy kadar derin değil ama aynı zamanda statik dosya servis, PHP-FPM proxy, reverse proxy + cache yapar. Karma çözüm: HAProxy frontend + Nginx backend — HAProxy SSL termination ve routing, Nginx uygulama sunucusu olarak.

"HAProxy/Nginx kurulumunu siz mi yapıyorsunuz?"

Açık konuşalım: Buyukweb VDS altyapısını sağlar (KVM tam virtualization, root erişim, %99.8 datacenter SLA, DDoS L3+L4+L7 koruma). HAProxy/Nginx kurulumunu siz veya sistem yöneticiniz yapar. Sıfırdan kurulumda Ubuntu 22.04 LTS / Debian 12 gibi temiz işletim sistemi imajı veriyoruz; konfigürasyon, sertifika yönetimi, monitoring sizin sorumluluğunuzda. Karmaşık LB mimarisi için kurulum danışmanlığı isterseniz 0850 302 60 70 numaralı destek hattımızdan görüşebilirsiniz.

"Yönetilen load balancer hizmetiniz var mı?"

Buyukweb şu an itibariyle yönetilen LB hizmeti vermiyor. VDS üzerinde self-host HAProxy veya Nginx kurmanız gerekir. Yönetilen LB SaaS'i bekliyorsanız mevcut paketlerimiz size uygun olmayabilir; ancak self-host yaklaşım daha kontrollü ve özelleştirilebilirdir. KVM tam virtualization sayesinde tüm root yapılandırması elinizde.

"Failover sırasında oturumlar düşer mi?"

VRRP + keepalived ile MASTER → BACKUP geçişi yaklaşık 3-4 saniye sürer. Bu sürede yarım kalan TCP bağlantılar düşer; ancak yeni gelen istekler hemen BACKUP'a yönlenir. Tarayıcı tipik bir refresh ile devam eder, kullanıcı kısa bir gecikme veya tek bir 502 hatası görebilir. conntrackd ile TCP state replikasyonu kurulursa bu da minimum seviyeye iner. Stateless app + Redis session store ile session kaybı tamamen ortadan kalkar.

"Buyukweb VDS'te yüksek trafik nasıl kaldırılır?"

VDS E5-V4 paketlerimiz orta-yüksek trafik için tasarlanmıştır. RPS bazında: tek VDS (4 vCPU, 8 GB RAM) optimize edilmiş Nginx + PHP-FPM ile 200-500 RPS sürekli kaldırır. 3 backend + 1 LB mimarisinde 800-1.500 RPS mümkün. Daha yüksek trafik (5.000+ RPS sürekli, milyon ziyaretçi/gün) için Dedicated/Fiziksel Sunucu paketlerimizi öneririz — fiziksel donanım ile sanallaştırma overhead'i ortadan kalkar, performans tam donanım hızında.

Sonuç ve Sonraki Adımlar

Load balancer, modern bir web altyapısının HA ve ölçeklenebilirlik ayağıdır. Doğru mimari seçimi şu adımlardan oluşur:

1. Layer 4 mi Layer 7 mi? — HTTP routing/SSL termination gerekiyorsa Layer 7 (HAProxy HTTP mode, Nginx); sadece TCP/UDP yük dağıtımı yeterliyse Layer 4 (HAProxy TCP mode).
2. Algoritma seçimi — Stateless web için Round Robin / Least Connections, sticky gerekiyorsa Cookie / IP Hash, cache cluster için Consistent Hashing.
3. HAProxy mi Nginx mi? — Sadece LB istiyorsanız HAProxy daha derin; web sunucu + LB birlikte istiyorsanız Nginx.
4. Sticky session — Mümkün olduğu kadar stateless app + Redis session store ile sticky'den kaçının.
5. Health check — TCP yetmez; HTTP /healthz custom endpoint kurun, backend bağımlılıklarını içeride kontrol etsin.
6. LB HA — Tek LB SPOF'tur; 2 LB + keepalived + VRRP + VIP ile yüksek erişilebilirlik sağlayın.
7. Observability — HAProxy Prometheus exporter + Grafana dashboard + log analizi.
8. Performance tuning — maxconn, somaxconn, worker_connections sistem ayarları + sertifika auto-renew + monitoring.

Buyukweb VDS altyapısı, KVM tam virtualization + root erişim + Bursa Tier 3 datacenter + DDoS L3+L4+L7 standart koruma ile bu mimariyi kurmanız için ideal platformdur. 3 backend + 1 frontend yapısı ~₺1.000-2.000/ay bütçeyle erişilebilir; ihtiyaç büyüdükçe Dedicated/Fiziksel Sunucu paketlerine geçişle ölçek artırılabilir.

---

İlgili Büyükweb Hizmetleri

• VDS Sunucu — KVM tam virtualization, root erişim, HAProxy/Nginx kurulumu için ideal
• Dedicated/Fiziksel Sunucu — Yüksek trafikte sanallaştırma overhead'siz tam donanım
• Paket Karşılaştırma — VDS / Dedicated arasında kaynak bazlı seçim
• Sunucu Barındırma — Kendi donanımınızı Bursa Tier 3 veri merkezine yerleştirme

Load balancer mimarisi, HAProxy/Nginx self-host kurulum danışmanlığı veya 3 backend + LB HA planlamanız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz. Bursa Tier 3 veri merkezimizden 17+ yıllık tecrübemizle yurtiçi düşük gecikme + DDoS L3+L4+L7 koruma + %99.8 datacenter uptime ile çalışan bir altyapı sağlıyoruz.