Related Articles

Kubescape Nedir? Açık Kaynak Kubernetes Güvenlik Platformu Rehberi

5 gün ago

Kartla Ödeme Nasıl Çalışır? “Ödeme Başarılı” Mesajının Arkasında Ne Var?

5 gün ago

Grype Nedir? Container ve SBOM Zafiyet Tarama Rehberi

2 hafta ago

Modern internet uygulamalarında kullanıcı istekleri tek bir sunucuya yönlendirilirse kısa sürede performans, erişilebilirlik ve ölçeklenebilirlik sorunları oluşabilir.

Bu nedenle yüksek trafikli sistemlerde Load Balancer — Yük Dengeleyici kullanılır.

Kısa tanım:

Load Balancing = Gelen trafiği birden fazla sunucuya kontrollü şekilde dağıtma yöntemi

Amaç:

Tek sunucunun aşırı yüklenmesini önlemek
Uygulama performansını artırmak
Kesintisiz erişilebilirlik sağlamak
Sunucu arızalarında trafiği sağlıklı sunuculara yönlendirmek
Ölçeklenebilir mimari kurmak

---

Load Balancer Nedir?

Load Balancer, kullanıcıdan gelen istekleri arka taraftaki birden fazla sunucuya dağıtan ağ veya uygulama bileşenidir.

Genellikle şu yapı içinde konumlanır:

Kullanıcı
→ DNS
→ Firewall / WAF
→ Load Balancer
→ Uygulama Sunucuları
→ Veritabanı / Cache / API servisleri

Ancak bu sıralama her ortamda aynı olmak zorunda değildir.

Bazı mimarilerde:

Internet
→ Load Balancer + WAF
→ Firewall
→ Application Servers

veya:

Internet
→ Firewall
→ Load Balancer
→ WAF Policy
→ Application Servers

şeklinde farklı tasarımlar da olabilir.

---

1️⃣ Load Balancing Nasıl Çalışır?

Basit bir senaryo düşünelim.

Kullanıcılar www.example.com adresine erişmek istiyor.

İşleyiş genellikle şu şekildedir:

1. Kullanıcı tarayıcıdan www.example.com adresine gider.
2. DNS, bu alan adını Load Balancer VIP adresine çözer.
3. Kullanıcı isteği Load Balancer’a gelir.
4. Load Balancer isteği uygun backend sunucuya yönlendirir.
5. Uygulama sunucusu isteği işler.
6. Yanıt kullanıcıya geri döner.

Buradaki kritik kavram VIP — Virtual IP adresidir.

Kullanıcı Load Balancer VIP adresine bağlanır.
Gerçek uygulama sunucularının IP adreslerini bilmez.

Örnek:

www.example.com → 203.0.113.10

203.0.113.10 = Load Balancer VIP

Backend sunucular:
10.10.10.11
10.10.10.12
10.10.10.13

---

2️⃣ Round Robin Örneği

Round Robin, en basit yük dengeleme algoritmalarından biridir.

İstekleri sırayla sunuculara dağıtır.

Örnek:

Kullanıcı A → Uygulama Sunucusu 1
Kullanıcı B → Uygulama Sunucusu 2
Kullanıcı C → Uygulama Sunucusu 3
Kullanıcı D → Uygulama Sunucusu 1
Kullanıcı E → Uygulama Sunucusu 2
Kullanıcı F → Uygulama Sunucusu 3
Kullanıcı G → Uygulama Sunucusu 1

Bu yöntem basittir ve küçük/orta ölçekli yapılarda işe yarayabilir.

Ancak her zaman en doğru yöntem değildir.

Çünkü:

Her istek aynı sürede bitmeyebilir.
Her kullanıcı aynı miktarda kaynak tüketmeyebilir.
Bazı oturumlar uzun sürebilir.
Sunucuların donanım kapasiteleri farklı olabilir.

Bu nedenle gerçek üretim ortamlarında Round Robin dışında farklı algoritmalar da kullanılır.

---

3️⃣ Load Balancing Algoritmaları

Round Robin

İstekleri sırayla sunuculara dağıtır.

Sunucu 1
Sunucu 2
Sunucu 3
Sonra tekrar Sunucu 1

Avantajı:

Basittir.
Kolay anlaşılır.
Küçük yapılarda yeterli olabilir.

Dezavantajı:

Sunucu yükünü gerçek zamanlı dikkate almaz.
Uzun süren bağlantılarda dengesizlik oluşabilir.

---

Least Connections

En az aktif bağlantıya sahip sunucuya yeni isteği gönderir.

Sunucu 1 → 100 bağlantı
Sunucu 2 → 40 bağlantı
Sunucu 3 → 70 bağlantı

Yeni istek → Sunucu 2

Özellikle uzun süreli bağlantılar için daha uygundur.

---

Weighted Round Robin

Sunuculara ağırlık değeri verilir.

Örnek:

Sunucu 1 → Weight 5
Sunucu 2 → Weight 3
Sunucu 3 → Weight 1

Daha güçlü sunucu daha fazla trafik alır.

---

Weighted Least Connections

Hem aktif bağlantı sayısını hem de sunucu kapasitesini dikkate alır.

Bu yöntem farklı donanım kapasitesine sahip backend sunucular için daha uygundur.

---

IP Hash

Kullanıcının IP adresine göre aynı kullanıcıyı aynı backend sunucuya yönlendirmeye çalışır.

Kullanım amacı:

Session persistence
Kullanıcı oturumunu aynı sunucuda tutmak

Dezavantajı:

NAT arkasındaki çok sayıda kullanıcı aynı IP’den geliyorsa dengesizlik oluşabilir.

---

Least Response Time

En hızlı yanıt veren veya en düşük gecikmeye sahip sunucuyu tercih eder.

Özellikle performans odaklı mimarilerde değerlidir.

---

4️⃣ Layer 4 ve Layer 7 Load Balancing

Load balancer’lar farklı OSI katmanlarında çalışabilir.

Layer 4 Load Balancing

Layer 4, transport layer seviyesinde çalışır.

Karar verirken genellikle şunlara bakar:

Source IP
Destination IP
Source Port
Destination Port
TCP / UDP bilgisi

Avantajları:

Hızlıdır.
Daha az işlem yükü oluşturur.
TCP/UDP seviyesinde çalışır.
Yüksek performanslıdır.

Dezavantajı:

HTTP header, URL path, cookie gibi uygulama bilgilerine göre karar veremez.

Örnek:

TCP 443 trafiğini backend sunuculara dağıtmak
UDP tabanlı servisleri dengelemek

---

Layer 7 Load Balancing

Layer 7, application layer seviyesinde çalışır.

HTTP/HTTPS içeriğini anlayabilir.

Karar verirken şunları kullanabilir:

Host header
URL path
Cookie
HTTP header
User-Agent
API endpoint
Content type

Örnek:

/api      → API sunucuları
/images   → Static content sunucuları
/admin    → Admin backend
/mobile   → Mobil backend

Avantajı:

Daha akıllı yönlendirme yapabilir.
Uygulama bazlı karar verebilir.
WAF, SSL offload ve header manipulation ile entegre çalışabilir.

Dezavantajı:

Layer 4’e göre daha fazla işlem gücü gerektirir.
SSL/TLS termination varsa sertifika yönetimi gerekir.

---

5️⃣ Health Check Neden Kritiktir?

Load balancer yalnızca trafiği dağıtmaz; backend sunucuların sağlıklı olup olmadığını da kontrol eder.

Buna Health Check denir.

Örnek kontroller:

TCP port açık mı?
HTTP 200 OK dönüyor mu?
API health endpoint cevap veriyor mu?
Uygulama gerçekten çalışıyor mu?
Veritabanı bağlantısı sağlıklı mı?

Basit örnek:

GET /health

Beklenen cevap:
HTTP 200 OK

Eğer sunucu sağlıksızsa load balancer o sunucuya trafik göndermeyi durdurur.

Sunucu 1 → Healthy
Sunucu 2 → Unhealthy
Sunucu 3 → Healthy

Yeni trafik → Sunucu 1 ve Sunucu 3

---

6️⃣ Session Persistence — Sticky Session

Bazı uygulamalarda kullanıcının aynı backend sunucuda kalması gerekir.

Buna session persistence veya sticky session denir.

Kullanım yöntemleri:

Cookie persistence
Source IP persistence
SSL session ID persistence
Application session ID

Örnek:

Kullanıcı A ilk istekte Sunucu 2’ye gittiyse
sonraki istekleri de Sunucu 2’ye yönlendirilir.

Ancak sticky session dikkatli kullanılmalıdır.

Dezavantajları:

Yük dengesini bozabilir.
Sunucu arızasında oturum kaybı yaşanabilir.
Ölçeklenebilirliği azaltabilir.

Daha modern yaklaşım:

Session bilgisini Redis / database / distributed cache üzerinde tutmak
Uygulama sunucularını stateless tasarlamak

---

7️⃣ SSL/TLS Termination

HTTPS trafiğinde SSL/TLS işlemi load balancer üzerinde sonlandırılabilir.

Buna SSL termination veya SSL offload denir.

Akış:

Kullanıcı
→ HTTPS
→ Load Balancer SSL termination
→ HTTP veya HTTPS
→ Backend Server

Avantajları:

Sertifika yönetimi merkezileşir.
Backend sunucuların CPU yükü azalır.
Layer 7 inspection yapılabilir.
WAF entegrasyonu kolaylaşır.

Dikkat edilmesi gerekenler:

Backend trafiği tekrar şifrelenmeli mi?
Sertifika yenileme otomasyonu var mı?
TLS policy güçlü mü?
Eski protokoller kapalı mı?

Üretim ortamında özellikle hassas veri taşıyan uygulamalarda backend tarafında da TLS kullanılması tercih edilebilir.

---

8️⃣ Firewall, WAF ve Load Balancer İlişkisi

Load balancer güvenlik mimarisinin bir parçası olabilir; ancak firewall veya WAF’ın birebir alternatifi değildir.

Firewall

IP, port, zone ve policy seviyesinde erişim kontrolü yapar.

WAF

HTTP/HTTPS uygulama saldırılarına karşı koruma sağlar.
SQL Injection, XSS, command injection gibi saldırıları analiz eder.

Load Balancer

Trafiği backend sunuculara dağıtır.
Health check yapar.
SSL termination, persistence ve trafik yönlendirme sağlayabilir.

Doğru mimari çoğu zaman bu bileşenlerin birlikte çalışmasıdır.

Firewall
→ WAF
→ Load Balancer
→ Application Servers

veya entegre appliance/ADC yapılarda:

ADC = Load Balancer + SSL Offload + WAF + GSLB + Content Switching

---

9️⃣ Load Balancer Türleri

Hardware Load Balancer

Fiziksel appliance olarak çalışır.

Örnek kullanım:

Büyük veri merkezleri
Yüksek trafik
Kritik uygulamalar
Düşük latency ihtiyacı

Software Load Balancer

Sunucu veya VM üzerinde çalışır.

Örnekler:

HAProxy
NGINX
Envoy
Traefik
Apache Traffic Server

Cloud Load Balancer

Bulut sağlayıcının sunduğu yönetilen load balancer hizmetidir.

Örnek:

AWS ALB / NLB
Azure Load Balancer / Application Gateway
Google Cloud Load Balancing

Kubernetes Load Balancing

Kubernetes içinde farklı katmanlarda load balancing vardır:

Service
Ingress Controller
Gateway API
Service Mesh
External Load Balancer

---

🔟 DNS Load Balancing ve GSLB

Load balancing yalnızca tek veri merkezi içinde yapılmaz.

Global trafik yönlendirme için DNS tabanlı load balancing veya GSLB — Global Server Load Balancing kullanılabilir.

Örnek:

Türkiye kullanıcıları → İstanbul DC
Avrupa kullanıcıları → Frankfurt DC
ABD kullanıcıları → Virginia DC

GSLB karar verirken şunları dikkate alabilir:

Coğrafi konum
Latency
Data center health
Site availability
Policy
Disaster recovery durumu

---

1️⃣1️⃣ Load Balancer Failover

Load balancer tek başına kritik bileşense, kendisi de yedekli kurulmalıdır.

Yaygın yapı:

Active / Standby
Active / Active
Cluster
HA pair
VRRP / HA protocol

Amaç:

Bir load balancer arızalansa bile trafik devam etsin.

Dikkat edilmesi gerekenler:

Session sync
Config sync
Stateful failover
Health check
Floating IP / VIP failover
Monitoring

---

1️⃣2️⃣ Örnek Trafik Akışı

Örnek bir web uygulaması için akış:

1. Kullanıcı www.example.com adresine gider.
2. DNS, alan adını Load Balancer VIP IP’sine çözer.
3. Trafik firewall ve/veya WAF katmanından geçer.
4. Load Balancer HTTPS isteğini alır.
5. SSL termination yapılır.
6. HTTP Host ve URL path analiz edilir.
7. Health check sonucu sağlıklı olan backend seçilir.
8. Algoritmaya göre istek Sunucu 1, 2 veya 3’e yönlendirilir.
9. Uygulama sunucusu isteği işler.
10. Gerekirse cache veya veritabanına erişir.
11. Yanıt Load Balancer üzerinden kullanıcıya döner.

Not:

Bazı mimarilerde yanıt trafiği doğrudan sunucudan da dönebilir.
Buna Direct Server Return — DSR denir.

---

1️⃣3️⃣ Sık Yapılan Hatalar

1️⃣ Health Check Koymamak

Port açık olabilir ama uygulama çalışmıyor olabilir.

Sadece TCP 443 açık diye sunucuyu healthy kabul etmek her zaman doğru değildir.

2️⃣ Sticky Session’ı Gereksiz Kullanmak

Sticky session yük dengesini bozabilir. Uygulama mümkünse stateless tasarlanmalıdır.

3️⃣ Round Robin’i Her Ortam İçin Yeterli Sanmak

Round Robin basittir ama gerçek yükü ölçmez.

Uzun bağlantı, farklı sunucu kapasitesi veya ağır isteklerde Least Connections / Weighted algoritmalar daha uygun olabilir.

4️⃣ SSL Termination Sonrası Backend’i Şifresiz Bırakmak

Hassas ortamlarda backend trafiği de TLS ile korunmalıdır.

5️⃣ Load Balancer’ı Tek Nokta Arızası Bırakmak

Load balancer HA kurulmazsa tüm uygulama erişimi tek cihaza bağımlı kalır.

6️⃣ Gerçek Client IP’yi Kaybetmek

Proxy mode’da backend sunucu client IP yerine load balancer IP’sini görebilir.

Çözüm:

X-Forwarded-For
Proxy Protocol
Source IP preservation

7️⃣ Kapasite Planlaması Yapmamak

Load balancer için şu değerler planlanmalıdır:

Concurrent connection
SSL TPS
Throughput
HTTP request per second
New connection per second
Backend server kapasitesi
Session table
CPU / RAM kullanımı

---

1️⃣4️⃣ Load Balancer İzleme Metrikleri

Üretim ortamında şu metrikler izlenmelidir:

VIP trafiği
Backend server health
HTTP 4xx / 5xx oranı
Response time
Connection count
Request per second
SSL handshake sayısı
Queue length
Drop / reset oranı
Backend timeout
Pool member durumu
CPU / memory

Bu metrikler Grafana, Prometheus, ELK, Splunk, Zabbix, PRTG veya vendor monitoring araçlarıyla izlenebilir.

---

1️⃣5️⃣ 48s Mini-PoC Planı

1. Üç adet basit web sunucusu hazırlayın.
2. Her sunucuya farklı test sayfası koyun.
3. HAProxy veya NGINX ile bir load balancer kurun.
4. Backend sunucuları pool içine ekleyin.
5. Round Robin algoritmasını aktif edin.
6. Tarayıcıdan VIP adresine art arda istek gönderin.
7. İsteklerin farklı sunuculara dağıldığını doğrulayın.
8. Bir backend sunucuyu durdurun.
9. Health check sayesinde trafiğin diğer sunuculara aktığını gözlemleyin.
10. Least Connections algoritmasını test edin.
11. Sticky session açıp davranışı karşılaştırın.
12. Loglardan client IP ve backend seçimlerini analiz edin.

---

Kısa Özet

Load Balancer:
Gelen trafiği sunuculara dağıtır.

Health Check:
Sağlıksız sunucuya trafik göndermez.

Algorithm:
Trafiğin nasıl dağıtılacağını belirler.

Persistence:
Kullanıcıyı aynı sunucuda tutabilir.

L4:
IP/TCP/UDP seviyesinde çalışır.

L7:
HTTP header, URL, cookie gibi uygulama bilgileriyle karar verir.

---

Sonuç

Load balancing, modern uygulama mimarilerinin temel yapı taşlarından biridir.

Doğru yapılandırıldığında:

Performansı artırır.
Sunucu yükünü dengeler.
Kesintisiz erişilebilirlik sağlar.
Arıza durumunda trafiği sağlıklı sunucuya yönlendirir.
Ölçeklenebilirlik sağlar.
Kullanıcı deneyimini iyileştirir.

Ancak başarılı bir load balancing tasarımı yalnızca algoritma seçmekten ibaret değildir.

Dikkat edilmesi gereken ana başlıklar:

Doğru algoritma
Health check
Session persistence
SSL/TLS tasarımı
Firewall ve WAF entegrasyonu
Backend kapasitesi
HA / failover
Monitoring

Kısa ifade:

Load balancer trafiği dağıtır.
Health check sağlığı korur.
Algoritma dengeyi belirler.
Monitoring doğru çalıştığını kanıtlar.