Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Related Articles
Modern uygulamalarda performans, süreklilik ve ölçeklenebilirlik için yük dengeleme kritik bir bileşendir.
Load balancer’ın temel görevi, gelen istemci isteklerini arka taraftaki birden fazla sunucuya dağıtmaktır. Ancak bu dağıtım rastgele yapılmaz. Kullanılan algoritmaya göre trafik; sırayla, bağlantı sayısına göre, sunucu kapasitesine göre, yanıt süresine göre veya istemci IP bilgisine göre yönlendirilebilir.
Doğru algoritma seçimi; uygulama performansını, kullanıcı deneyimini ve sistem dayanıklılığını doğrudan etkiler.
Load Balancing Algoritması Nedir?
Load balancing algoritması, gelen trafiğin backend sunucular arasında nasıl paylaştırılacağını belirleyen karar mekanizmasıdır.
Amaç:
- Sunucular arasında yükü dengelemek
- Tek bir sunucunun aşırı yüklenmesini önlemek
- Uygulama performansını artırmak
- Kesintisiz servis sağlamak
- Kaynak kullanımını optimize etmek
- Kullanıcı deneyimini iyileştirmek
Ancak her uygulama aynı algoritmayla en iyi sonucu vermez. Kısa süreli web istekleri, uzun süreli TCP bağlantıları, video trafiği, API çağrıları veya stateful oturumlar farklı load balancing stratejileri gerektirebilir.
1️⃣ Round Robin — Dairesel Sırayla Dağıtım
Round Robin, gelen her yeni isteği sırayla bir sonraki sunucuya yönlendirir.
Örnek:
1. istek → Server-1
2. istek → Server-2
3. istek → Server-3
4. istek → Server-1Avantajları
- Basittir.
- Kurulumu kolaydır.
- Benzer kapasitedeki sunucular için dengeli çalışır.
- Küçük ve orta ölçekli web uygulamaları için uygundur.
Dezavantajları
- Sunucu kapasitesini dikkate almaz.
- Aktif bağlantı sayısını bilmez.
- Bir sunucu yavaşlamışsa yine trafik gönderebilir.
- Uzun süreli bağlantılarda dengesizlik oluşabilir.
Nerede Kullanılır?
- Benzer donanım gücüne sahip web sunucuları
- Kısa süreli HTTP istekleri
- Basit web uygulamaları
- Stateless servisler
2️⃣ Least Connections — En Az Bağlantıya Sahip Sunucu
Least Connections, yeni isteği o anda en az aktif bağlantıya sahip backend sunucuya gönderir.
Avantajları
- Dinamik trafiklerde Round Robin’e göre daha akıllıdır.
- Uzun süreli bağlantılarda daha dengeli sonuç verebilir.
- Aktif connection sayısını dikkate alır.
- WebSocket, API veya uzun oturumlu servislerde faydalıdır.
Dezavantajları
- Bağlantı sayısı her zaman gerçek yükü göstermez.
- CPU, RAM veya disk kullanımı dikkate alınmayabilir.
- Çok kısa süreli bağlantılarda Round Robin kadar basit ve yeterli olabilir.
Nerede Kullanılır?
- API servisleri
- Uzun süreli TCP bağlantıları
- WebSocket uygulamaları
- Dinamik trafik alan web sistemleri
3️⃣ Weighted Round Robin — Ağırlıklı Dairesel Dağıtım
Weighted Round Robin, her sunucuya kapasitesine göre ağırlık verir. Daha güçlü sunucular daha fazla istek alır.
Örnek:
Server-1 weight 5
Server-2 weight 3
Server-3 weight 1Bu durumda Server-1, Server-3’e göre daha fazla trafik alır.
Avantajları
- Farklı kapasitedeki sunucular arasında daha adil dağıtım sağlar.
- Güçlü sunucular daha fazla yük alabilir.
- Basit Round Robin’e göre daha esnektir.
Dezavantajları
- Ağırlıkların doğru belirlenmesi gerekir.
- Gerçek zamanlı performans değişimini otomatik anlamayabilir.
- Yanlış weight tasarımı dengesizliğe yol açabilir.
Nerede Kullanılır?
- Farklı CPU/RAM kapasitesindeki backend sunucular
- Kademeli kapasite artırımı yapılan ortamlarda
- Eski ve yeni nesil sunucuların birlikte çalıştığı yapılarda
4️⃣ Weighted Least Connections — Ağırlıklı En Az Bağlantı
Weighted Least Connections, hem aktif bağlantı sayısını hem de sunucu ağırlığını dikkate alır.
Bu algoritma, güçlü sunucuların daha fazla bağlantı taşımasını sağlarken, bağlantı sayısı yüksek olan sunuculara yeni istek göndermeyi azaltır.
Avantajları
- Hem kapasite hem aktif yük dikkate alınır.
- Heterojen sunucu ortamları için uygundur.
- Yoğun ve değişken trafiklerde daha sağlıklı dağıtım sağlar.
Dezavantajları
- Round Robin’e göre daha karmaşıktır.
- Doğru weight belirlenmezse beklenen fayda alınamaz.
- Her load balancer ürünü aynı şekilde hesaplama yapmayabilir.
Nerede Kullanılır?
- Farklı kapasiteli sunucular
- Uzun süreli bağlantılar
- Değişken trafik alan uygulamalar
- Kurumsal uygulama havuzları
5️⃣ IP Hash — İstemci IP’sine Göre Dağıtım
IP Hash, istemcinin IP adresini hash’leyerek her kullanıcıyı belirli bir backend sunucuya yönlendirir.
Bu yöntem genellikle sticky session veya session persistence ihtiyacı olan yapılarda kullanılır.
Avantajları
- Aynı istemci genellikle aynı sunucuya gider.
- Stateful uygulamalarda oturum sürekliliği sağlar.
- Session store olmayan eski uygulamalarda pratik çözüm olabilir.
Dezavantajları
- NAT arkasındaki çok sayıda kullanıcı aynı sunucuya yığılabilir.
- Kullanıcının IP’si değişirse eşleşme bozulabilir.
- Mobil ağlarda veya proxy arkasında dengesizlik oluşabilir.
- Gerçek sticky session ihtiyacı varsa cookie-based persistence daha doğru olabilir.
Nerede Kullanılır?
- Session state’i backend üzerinde tutan eski uygulamalar
- Basit persistence ihtiyacı
- Kullanıcıyı aynı backend’e yönlendirme gereksinimi
- Proxy/NAT etkisi düşük olan ağlar
6️⃣ Least Response Time — En Düşük Yanıt Süresi
Least Response Time, backend sunucuların yanıt süresini ölçer ve yeni istekleri en hızlı yanıt veren sunucuya yönlendirir.
Avantajları
- Gerçek zamanlı performansa göre karar verir.
- Sadece bağlantı sayısına değil, yanıt kalitesine de bakar.
- Kullanıcı deneyimini iyileştirebilir.
- Yavaşlayan sunuculara daha az trafik gönderilebilir.
Dezavantajları
- Sürekli health check ve performans ölçümü gerekir.
- Ölçüm hataları yanlış yönlendirme yapabilir.
- Ağ gecikmesi, sunucu yükü ve uygulama gecikmesi birlikte değerlendirilmelidir.
Nerede Kullanılır?
- Gerçek zamanlı uygulamalar
- API gateway arkasındaki servisler
- Performans hassasiyeti yüksek web uygulamaları
- Coğrafi olarak dağıtık backend yapıları
7️⃣ Random — Rastgele Dağıtım
Random, gelen her isteği rastgele bir backend sunucuya yönlendirir.
Avantajları
- Çok basittir.
- Ek ölçüm veya karmaşık hesaplama gerektirmez.
- Küçük ve basit sistemlerde yeterli olabilir.
Dezavantajları
- Kısa vadede yük dengesizliği oluşabilir.
- Sunucu kapasitesini dikkate almaz.
- Aktif bağlantı veya response time bilgisi kullanmaz.
- Büyük ve kritik sistemler için genellikle tek başına ideal değildir.
Nerede Kullanılır?
- Basit test ortamları
- Düşük trafikli servisler
- Homojen backend havuzları
- Kritik olmayan uygulamalar
8️⃣ Least Bandwidth — En Az Bant Genişliği Kullanan Sunucu
Least Bandwidth, o anda en az network trafiği kullanan backend sunucuya yeni istekleri yönlendirir.
Avantajları
- Trafik hacmine göre daha bilinçli dağıtım sağlar.
- Büyük dosya transferi veya streaming benzeri senaryolarda faydalı olabilir.
- Sadece connection sayısına bakmaz.
Dezavantajları
- Ölçüm ve izleme maliyeti vardır.
- Her ürün tarafından aynı şekilde desteklenmeyebilir.
- Bant genişliği düşük olan sunucu her zaman “en uygun” sunucu olmayabilir.
- CPU/RAM/uygulama gecikmesi ayrıca izlenmelidir.
Nerede Kullanılır?
- Video streaming
- Dosya indirme servisleri
- Backup/replication trafiği
- Büyük veri transferi yapılan sistemler
Karşılaştırma Tablosu
| Algoritma | Karar Kriteri | En Uygun Kullanım |
|---|---|---|
| Round Robin | Sırayla dağıtım | Basit ve stateless web servisleri |
| Least Connections | En az aktif bağlantı | Uzun süreli bağlantılar, API, WebSocket |
| Weighted Round Robin | Sunucu ağırlığı | Farklı kapasiteli backend’ler |
| Weighted Least Connections | Bağlantı + kapasite | Heterojen ve yoğun trafik |
| IP Hash | İstemci IP hash’i | Sticky session ihtiyacı |
| Least Response Time | En hızlı yanıt veren sunucu | Performans hassas uygulamalar |
| Random | Rastgele seçim | Basit/test ortamları |
| Least Bandwidth | En az trafik kullanan sunucu | Streaming, dosya transferi |
Algoritma Seçerken Dikkat Edilmesi Gerekenler
1️⃣ Uygulama Stateful mı Stateless mı?
Stateless uygulamalarda Round Robin veya Least Connections yeterli olabilir. Stateful uygulamalarda session persistence gerekebilir.
2️⃣ Sunucular Aynı Kapasitede mi?
Sunucular farklı donanım veya kaynak gücüne sahipse weighted algoritmalar daha doğru seçimdir.
3️⃣ Bağlantılar Kısa mı Uzun mu?
Kısa HTTP isteklerinde Round Robin yeterli olabilir. Uzun TCP/WebSocket bağlantılarında Least Connections daha sağlıklı olabilir.
4️⃣ Kullanıcı Aynı Sunucuya Gitmeli mi?
Oturum bilgisi backend üzerinde tutuluyorsa IP Hash veya cookie-based persistence gerekebilir.
5️⃣ Health Check Doğru mu?
Load balancer algoritması ne kadar iyi olursa olsun, health check yanlışsa trafik hatalı sunucuya gönderilebilir.
Health check yalnızca port açık mı diye bakmamalıdır. Mümkünse uygulama seviyesinde kontrol yapılmalıdır.
Örnek:
/health
/status
/api/healthcheckSık Yapılan Hatalar
❌ Sadece Round Robin Kullanmak
Her uygulama için Round Robin seçmek doğru değildir. Dinamik ve uzun süreli bağlantılarda dengesizlik oluşabilir.
❌ Health Check Tanımlamamak
Sunucu portu açık olabilir ama uygulama çalışmıyor olabilir. Bu durumda load balancer trafiği hatalı backend’e göndermeye devam eder.
❌ Sticky Session’ı Gereksiz Kullanmak
Sticky session bazı uygulamalarda şarttır; ancak gereksiz kullanılırsa yük dağılımını bozar.
❌ Weight Değerlerini Rastgele Vermek
Weighted algoritmalarda ağırlıklar gerçek CPU, RAM, worker sayısı ve performans testine göre belirlenmelidir.
❌ SSL/TLS Offload Etkisini Hesaba Katmamak
TLS termination load balancer veya backend üzerinde ciddi CPU etkisi yaratabilir. Algoritma seçimi bu mimariyle birlikte değerlendirilmelidir.
48s Mini-PoC Planı
- 3 backend sunucu oluşturun.
- İlk testte Round Robin kullanın.
- Her sunucuya gelen istek sayısını ölçün.
- Uzun süreli bağlantı simülasyonu yapın.
- Least Connections algoritmasına geçin.
- Farklı kapasite senaryosu için bir sunucuya düşük weight verin.
- Response time ölçümüyle Least Response Time davranışını test edin.
- Session persistence için IP Hash veya cookie persistence test edin.
- Health check başarısızlığında trafik yönlendirmesini doğrulayın.
Sonuç
Load balancing algoritması seçimi sadece trafik dağıtımı değildir. Doğru algoritma; uygulamanın state yapısına, bağlantı süresine, backend kapasitesine, health check kalitesine ve kullanıcı deneyimi hedeflerine göre belirlenmelidir.
Genel yaklaşım:
Basit web servisleri → Round Robin
Uzun bağlantılar → Least Connections
Farklı kapasiteli backend’ler → Weighted algoritmalar
Sticky session ihtiyacı → IP Hash / Cookie Persistence
Performans hassas uygulamalar → Least Response Time
Streaming / büyük veri transferi → Least BandwidthDoğru yapılandırılmış bir load balancer, yalnızca trafiği dağıtmaz; uygulama sürekliliğini, performansı ve kullanıcı deneyimini korur.
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
