Giriş
Yük dengeleme, modern uygulama tesliminin temel taşıdır. Binlerce—hatta milyonlarca—kullanıcı uygulamanıza aynı anda eriştiğinde, tek bir sunucu yükü kaldıramaz. Yük dengeleyiciler, gelen trafiği birden fazla backend sunucuya dağıtarak yüksek erişilebilirlik, optimal performans ve hata toleransı sağlar.
Peki bir yük dengeleyici, her isteği hangi sunucunun işleyeceğine nasıl karar verir? Cevap, yük dengeleme algoritmalarında yatmaktadır. Doğru algoritmayı seçmek, duyarlı bir uygulama ile zaman aşımları ve dengesiz sunucu yükleriyle boğuşan bir uygulama arasındaki farkı yaratabilir.
Bu rehber, yük dengeleme algoritmalarını iki kategoride incelemektedir: trafiğin sunuculara nasıl dağıtıldığını belirleyen dağıtım algoritmaları ve stateful uygulamalar için oturum sürekliliğini sağlayan kalıcılık yöntemleri.
Algoritma Seçimi Neden Önemli?
Doğru yük dengeleme algoritması, uygulama performansını, kullanıcı deneyimini ve altyapı verimliliğini doğrudan etkiler:
Optimal algoritma seçimi ile basit round robin'e kıyasla yanıt süresi iyileştirmesi
NGINX Performans ÇalışmasıKurumsal erişilebilirlik gereksinimi - yılda sadece 52 dakika kesinti
Endüstri Standardı SLASayfa 3 saniyeden uzun sürerse ayrılan kullanıcılar
Google Web Performans AraştırmasıAkıllı dağıtım ile tek sunucuya kıyasla throughput kazanımı
Yük Dengeleme En İyi UygulamalarıAlgoritma Kategorileri
Yük dengeleme algoritmaları, her biri farklı mimari ihtiyaçlara hizmet eden iki ana kategoriye ayrılır:
Dağıtım Algoritmaları
Trafiğin sunuculara nasıl yayıldığını belirler—sıralı, rastgele veya bağlantı sayısı ya da yanıt süresi gibi gerçek zamanlı sunucu metriklerine dayalı olarak.
Kalıcılık Yöntemleri
Aynı istemci, URI veya kullanıcı kimliğinden gelen istekleri tutarlı bir şekilde aynı sunucuya yönlendirerek oturum sürekliliğini sağlar.
Performans Tabanlı
Sunucu sağlık metriklerini—yanıt süresi, kuyruk derinliği, bağlantı hataları—optimal yönlendirme kararları için değerlendiren gelişmiş algoritmalar.
Hibrit Yaklaşımlar
Dağıtımı kalıcılık ile birleştirin veya gelişmiş yük dengeleme senaryoları için çok kriterli seçim (Fastest+ gibi) kullanın.
Dağıtım Algoritmaları
Dağıtım algoritmaları, trafiği sunucu havuzunuza yaymaya odaklanır. Seçim, sunucu altyapınıza, istek özelliklerine ve performans gereksinimlerinize bağlıdır.
Round Robin
Round Robin, en basit ve en yaygın dağıtılan yük dengeleme algoritmasıdır. Adından da anlaşılacağı gibi çalışır: istekler döngüsel, sıralı bir düzende sunuculara dağıtılır. İlk istek Sunucu 1'e, ikincisi Sunucu 2'ye ve bu şekilde devam eder. Son sunucuya ulaştıktan sonra döngü baştan başlar.
Bu algoritma, tüm sunucuların eşit kapasiteye sahip olduğunu ve tüm isteklerin benzer işlem gücü gerektirdiğini varsayar. Rotasyonda bir sonrakinin hangi sunucu olduğunu bilmenin ötesinde durum takibi gerektirmez, bu da onu minimum hesaplama yükü ile son derece verimli kılar.
Round Robin, sunucuların aynı özelliklere sahip olduğu ve isteklerin nispeten tek tip olduğu homojen ortamlarda mükemmeldir—statik içerik sunma, basit API endpoint'leri veya stateless mikroservisler gibi.
Round Robin: Bir Bakışta
| Özellik | Detaylar |
|---|---|
| Nasıl çalışır | Sıralı dağıtım: Sunucu 1 → Sunucu 2 → Sunucu 3 → tekrar |
| En uygun | Homojen sunucular, tek tip istek yükleri, stateless uygulamalar |
| Güçlü yönler | Basit, öngörülebilir, sıfır hesaplama yükü, hata ayıklaması kolay |
| Zayıf yönler | Sunucu yükünü ve kapasite farklılıklarını görmezden gelir |
| Kullanım senaryoları | Statik içerik, CDN edge node'ları, stateless API'lar |
Weighted Round Robin
Weighted Round Robin, temel algoritmayı her sunucuya kapasitesine göre bir ağırlık atayarak genişletir. Daha yüksek ağırlığa sahip sunucular orantılı olarak daha fazla trafik alır. Sunucu A'nın ağırlığı 3 ve Sunucu B'nin ağırlığı 1 ise, Sunucu A, Sunucu B'nin işlediği her istek için üç istek işler.
Bu algoritma, heterojen sunucu ortamları için gereklidir. Kuruluşlar genellikle bir donanım karışımı çalıştırır—güçlü yeni sunucular eski makinelerle birlikte veya farklı vCPU sayılarına sahip bulut instance'ları. Weighted Round Robin, 16 çekirdekli bir sunucunun 4 çekirdekli bir sunucudan daha fazla trafik işlemesini sağlar.
Ağırlıklar genellikle CPU çekirdekleri, bellek veya benchmark testlerine dayalı olarak yapılandırılır. Basit Round Robin'den daha esnek olmasına rağmen, bu algoritma hala gerçek zamanlı sunucu yükünü hesaba katmaz—yüksek yük altındaki ağır ağırlıklı bir sunucu, mevcut kapasitesine değil ağırlığına göre trafik almaya devam eder.
CPU çekirdekleri veya bellek ile orantılı ağırlıklarla başlayın. Örneğin, Sunucu A 8 çekirdeğe ve Sunucu B 4 çekirdeğe sahipse, 8 ve 4 (veya 2 ve 1) ağırlıklar atayın. Gerçek performans metriklerine—throughput, yanıt süreleri ve hata oranları—göre izleyin ve ayarlayın.
Least Connection
Least Connection dinamik bir yaklaşım benimser: her yeni istek, o anda en az aktif bağlantıya sahip sunucuya gider. Round Robin'in aksine, bu algoritma gerçek zamanlı koşullara uyum sağlar—eğer bir sunucu birçok yavaş isteği işliyorsa, yeni istekler daha az meşgul sunuculara yönlendirilir.
Bu algoritma özellikle uzun oturum sürelerine sahip sunucular için önerilir. Veritabanı bağlantıları (SQL), dizin hizmetleri (LDAP) ve kalıcı bağlantılı uygulamalar Least Connection dağıtımından önemli ölçüde faydalanır.
Yük dengeleyici, her backend sunucuya aktif bağlantıları takip eder. Yeni bir istek geldiğinde, bu bağlantı tablosunu sorgular ve en düşük sayıya sahip sunucuyu seçer. Bu küçük ek yük, bağlantı yoğun iş yükleri için performans faydalarına kıyasla ihmal edilebilir düzeydedir.
Least Connection: Bir Bakışta
| Özellik | Detaylar |
|---|---|
| Nasıl çalışır | En az aktif bağlantıya sahip sunucuya yönlendirir |
| En uygun | Uzun oturum süreleri, kalıcı bağlantılar, veritabanı iş yükleri |
| Güçlü yönler | Gerçek zamanlı yüke uyum sağlar, sunucu aşırı yüklenmesini önler, yavaş istekleri zarif şekilde işler |
| Zayıf yönler | Bağlantı takibi için hafif ek yük |
| Kullanım senaryoları | SQL veritabanları, LDAP dizinleri, WebSocket uygulamaları, uzun süren istekli API'lar |
First
First algoritması benzersiz bir yaklaşım benimser: havuzdaki ilk sunucu maksimum bağlantı sınırına ulaşana kadar tüm trafiği ona gönderir. Ancak o zaman trafik bir sonraki sunucuya akar.
Bu algoritma, bir birincil sunucunun tüm yükü işlemesini isterken diğerlerinin beklemede kalmasını istediğiniz aktif-pasif yapılandırmalar için kullanışlıdır. Ayrıca ek kapasite devreye girmeden önce tek bir lisanslı sunucunun kullanımını maksimize etmek istediğiniz lisanslama senaryoları için de değerlidir.
First, hangi sunucunun trafiği işlediğini tam olarak bildiğiniz için öngörülebilir davranış sağlar ve sorun gidermeyi basitleştirir. Ancak yük dağıtım avantajları sağlamaz ve tamamen failover için maksimum bağlantı sınırlarına bağlıdır.
First: Bir Bakışta
| Özellik | Detaylar |
|---|---|
| Nasıl çalışır | İlk sunucu maksimum bağlantıya ulaşana kadar tüm yükü alır |
| En uygun | Aktif-pasif kurulumlar, lisans optimizasyonu, öngörülebilir yönlendirme |
| Güçlü yönler | Basit, öngörülebilir, tek sunucu kullanımını maksimize eder |
| Zayıf yönler | Yük dağıtımı yok, maksimum bağlantı yapılandırmasına bağlı |
| Kullanım senaryoları | Birincil-yedek yapılandırmalar, lisanslı yazılım, kapasite taşma senaryoları |
Random
Random algoritması, her gelen istek için sunucuları rastgele seçer. Ancak, saf rastgeleleştirmenin aksine, bu uygulama seçim olasılığında hem sunucu ağırlıklarını hem de yanıt sürelerini dikkate alır.
Bu ağırlıklı rastgele yaklaşım, Round Robin'in öngörülebilir kalıplarından kaçınırken istatistiksel yük dağılımı sağlar. Zamanla sunucular ağırlıklarıyla orantılı trafik alır, ancak rastgele öğe periyodik yük artışlarına neden olabilecek senkronize istek kalıplarını önler.
Rastgele seçim, büyük sayılar yasasının eşit dağılımı sağladığı büyük sunucu havuzlarında özellikle etkilidir. Ayrıca birden fazla istemcinin aynı anda aynı sunucuyu hedeflediği "thundering herd" probleminden kaçınmak istediğinizde de kullanışlıdır.
Random: Bir Bakışta
| Özellik | Detaylar |
|---|---|
| Nasıl çalışır | Ağırlık ve yanıt süresini dikkate alan rastgele sunucu seçimi |
| En uygun | Büyük sunucu havuzları, senkronize kalıplardan kaçınma |
| Güçlü yönler | Thundering herd'i önler, istatistiksel olarak eşit dağılım, performansı dikkate alır |
| Zayıf yönler | Round Robin'den daha az öngörülebilir, kısa vadeli dengesizlikler olabilir |
| Kullanım senaryoları | Yüksek trafikli uygulamalar, büyük kümeler, önbellek sunucuları |
Fastest
Fastest algoritması, istekleri en iyi yanıt süresine sahip sunucuya yönlendirir. Yük dengeleyici sürekli olarak sunucu performansını izler ve trafiği o anda en hızlı yanıt veren sunucuya yönlendirir.
Bu yaklaşım, isteklerin en duyarlı sunucuya gitmesini sağlayarak kullanıcı deneyimini optimize eder. Değişen koşullara otomatik olarak uyum sağlar—yüksek CPU, bellek baskısı veya harici bağımlılıklar nedeniyle bir sunucu yavaşlarsa, trafik daha hızlı alternatiflere kayar.
Fastest, yanıt süresinin kullanıcı deneyimini veya iş metriklerini doğrudan etkilediği gecikmeye duyarlı uygulamalar için idealdir. E-ticaret ödeme akışları, gerçek zamanlı API'lar ve etkileşimli uygulamaların tümü yanıt süresine dayalı yönlendirmeden faydalanır.
Fastest+
Fastest+, yapılandırılabilir kriterlerle iki aşamalı optimizasyon sunan en gelişmiş algoritmadır. Sunucu seçimi için birincil bir metrik (Opt-1) ve birden fazla sunucu eşit birincil değerlere sahip olduğunda eşitliği bozan ikincil bir metrik (Opt-2) seçersiniz.
Mevcut optimizasyon kriterleri şunlardır: Least Response Time, Least Connection Time, Least Queue Time, Least Queues, Least Connection Error, Least Aborted Connections ve Least Used Connections. Bu esneklik, spesifik iş yükü özellikleriniz için ince ayarlı optimizasyon sağlar.
Örneğin, Opt-1'i "Least Response Time" ve Opt-2'yi "Least Connection Error" olarak yapılandırabilirsiniz. Algoritma önce en iyi yanıt sürelerine sahip sunucuları seçer, ardından bunlar arasından en az bağlantı hatasına sahip olanı seçer. Bu çok kriterli yaklaşım, tek metriklerin yetersiz kaldığı karmaşık üretim senaryolarını ele alır.
Fastest+ Optimizasyon Seçenekleri
| Seçenek | Açıklama | En Uygun |
|---|---|---|
| Least Response Time | İsteklere en hızlı yanıt veren sunucu | Gecikmeye duyarlı uygulamalar |
| Least Connection Time | Bağlantıları en hızlı kuran sunucu | Yüksek bağlantı değişimi olan iş yükleri |
| Least Queue Time | En kısa istek kuyruğu bekleme süresine sahip sunucu | Ani trafik kalıpları |
| Least Queues | En az kuyrukta bekleyen isteğe sahip sunucu | İstek birikimlerinden kaçınma |
| Least Connection Error | En az başarısız bağlantıya sahip sunucu | Güvenilirlik kritik uygulamalar |
| Least Aborted Connections | En az istemci kopmasına sahip sunucu | Uzun süren istek iş yükleri |
| Least Used Connections | En düşük bağlantı kullanımına sahip sunucu | Bağlantı havuzlu uygulamalar |
Fastest+, ikincil kriteri (Opt-2) yalnızca birden fazla sunucu birincil kriterde (Opt-1) eşit olduğunda kullanır. Bu, sunucuların genellikle benzer performans özelliklerine sahip olduğu homojen ortamlarda bile optimal seçimi sağlar.
Kalıcılık Yöntemleri (Self-Persistent)
Kalıcılık yöntemleri, aynı istemci, oturum veya bağlamdan gelen ilgili isteklerin her zaman aynı backend sunucuya ulaşmasını sağlar. Bu, oturum verilerini paylaşılan bir depoda değil yerel olarak saklayan stateful uygulamalar için gereklidir.
Source (IP Kalıcılığı)
Source kalıcılığı, sunucu seçimi için istemcinin kaynak IP adresinin hash'ini kullanır. Hash değeri, yönlendirmeyi belirlemek için sunucu ağırlıklarıyla birleştirilir. Aynı istemci IP'si her zaman aynı hash'i üretir ve aynı sunucuya tutarlı yönlendirme sağlar.
Bu yöntem, çerezler veya uygulama düzeyinde değişiklikler gerektirmeden oturum kalıcılığı sağlar. Belirli bir IP adresinden gelen tüm istekler aynı sunucuya gider ve o sunucuda saklanan oturum durumunu korur.
Source kalıcılığı, birden fazla kullanıcının bir IP adresini paylaştığı NAT ortamlarında ve IP adresleri değişebilen mobil kullanıcılarda sınırlamalara sahiptir. Bu senaryolar için, uygulama katmanı kalıcılık yöntemleri (URI, URL Param, HDR) daha iyi sonuçlar sağlar.
URI (Yol Kalıcılığı)
URI kalıcılığı, sunucu yönlendirmesini belirlemek için istek URI yolunu hash'ler. URI metni belirtilen uzunluğa kadar (veya sorgu parametreleri varsa '?' karakterine kadar) hash'lenir ve sunucu ağırlıklarıyla birleştirilir. Aynı URI'lar her zaman aynı sunucuya yönlendirilir.
Yapılandırma seçenekleri arasında URI karakter uzunluğu ve URI derinliği (dikkate alınacak yol segmentlerinin sayısı) bulunur. Örneğin, derinlik 2 ile, hem '/api/users/123' hem de '/api/users/456' aynı '/api/users' önekini hash'ler.
Bu yöntem, aynı kaynak için tüm isteklerin aynı sunucuya ulaşmasını ve önbellek verimliliğini maksimize etmesini istediğiniz önbellek senaryoları için mükemmeldir. Ayrıca farklı URI kalıplarının farklı veri bölümlerine eşlendiği parçalanmış backend'ler için de kullanışlıdır.
URL Param (Parametre Kalıcılığı)
URL Param kalıcılığı, URL'den (veya POST gövdesinden) belirtilen bir parametreyi çıkarır ve sunucu yönlendirmesi için değerini kullanır. Bu genellikle kullanıcı kimlikleri, oturum token'ları veya diğer uygulamaya özgü tanımlayıcıları izlemek için kullanılır. Aynı parametre değerleri her zaman aynı sunucuya yönlendirilir.
Çıkarılacak URL parametre adını yapılandırırsınız ve isteğe bağlı olarak form gönderimleri için POST parametre kontrolünü etkinleştirirsiniz. Bu, IP adresi değişikliklerinden bağımsız olarak kullanıcı oturumlarını takip eden uygulama duyarlı kalıcılık sağlar.
Bu yöntem, URL'lere veya form verilerine oturum veya kullanıcı tanımlayıcıları gömülü uygulamalar için idealdir. Mobil kullanıcılar veya NAT arkasındakiler için IP tabanlı yöntemlerden daha güvenilir kalıcılık sağlar.
HDR (Başlık Kalıcılığı)
HDR kalıcılığı, her istekte belirtilen bir HTTP başlığını inceler ve içeriğine göre yönlendirir. Aynı başlık değerine sahip istekler her zaman aynı sunucuya gider. Hangi başlık adının inceleneceğini yapılandırırsınız.
Yaygın kullanım senaryoları arasında özel oturum başlıkları, API anahtarları, çok kiracılı uygulamalarda kiracı tanımlayıcıları veya JWT token'larına dayalı yönlendirme bulunur. Bu, kendi oturum tanımlayıcılarını yöneten uygulamalar için maksimum esneklik sağlar.
HDR kalıcılığı, oturum durumunun çerezler yerine başlıklar aracılığıyla yönetildiği API öncelikli mimariler ve mikroservisler için özellikle değerlidir. Token tabanlı kimlik doğrulama sistemleriyle akıcı entegre olur.
Hash (Gelişmiş Özel Kalıcılık)
Hash kalıcılığı en güçlü ve esnek yöntemdir; trafik akışındaki hemen hemen her öğeden özel kalıcılık anahtarları oluşturmanıza olanak tanır. Yük dengeleyici, özel anahtar değerlerini backend sunuculara eşleyen bir hash tablosu (varsayılan olarak 3 milyon girişe kadar) tutar ve yapılandırılabilir süre sonu (varsayılan 7 gün) ile çalışır.
Hash anahtarı yüzlerce kullanılabilir değişkenden oluşturulabilir: istemci IP ve port, zaman damgaları, SSL sertifika alanları, frontend bilgisi, URL yolu ve method, HTTP başlıkları, istek gövdesi içeriği, WAF işleme sonuçları ve çok daha fazlası. Uygulamanızın gerektirdiği kalıcılık mantığını tam olarak oluşturmak için birden fazla değişkeni birleştirebilir ve dönüştürme fonksiyonları uygulayabilirsiniz.
Örneğin, şöyle bir hash anahtarı oluşturabilirsiniz: istemci IP'sinden ülkeyi çıkarır, belirli bir listede olup olmadığını kontrol eder, ardından bunu SSL istemci sertifikasındaki kullanıcı adıyla birleştirir. Bu kombinasyondan oluşan hash değeri aynı olan tüm istekler—yani aynı bölgeden ve aynı sertifika kimliğine sahip kullanıcılar—her zaman aynı backend sunucuya iletilir. Bu, uygulamanın oturum durumunu korurken son derece detaylı bir kalıcılık kontrolü sağlar. Diğer yük dengeleyicilerin gerçekleştiremeyeceği kalıcılık senaryolarını mümkün kılan bu özelleştirme düzeyi, TR7'nin fark yaratan yeteneklerinden biridir.
Hash Anahtar Yapı Taşları
Hash anahtarı bu trafik öğelerinin herhangi bir kombinasyonundan oluşturulabilir:
| Kategori | Kullanılabilir Değişkenler | Örnek Kullanım Senaryosu |
|---|---|---|
| Ağ Katmanı | İstemci IP, İstemci Port, Sunucu IP, Sunucu Port | Coğrafi tabanlı yönlendirme, ağ segmenti affinitesi |
| SSL/TLS | Sertifika CN, Sertifika DN, SNI, Cipher Suite | İstemci sertifikası tabanlı yönlendirme, mTLS senaryoları |
| HTTP İsteği | Method, Path, URL, Query Parametreleri, Host Header | İçerik tabanlı yönlendirme, API versiyonlama |
| HTTP Başlıkları | Herhangi bir başlık değeri (Authorization, X-Tenant-ID, vb.) | Çok kiracılı yönlendirme, API anahtarı affinitesi |
| İstek Gövdesi | POST parametreleri, JSON alanları, Form verileri | İşlem tabanlı kalıcılık |
| Bağlam | Zaman, Tarih, Frontend adı, WAF kararı, GeoIP ülke | Zaman tabanlı yönlendirme, uyumluluk yönlendirme |
Hash anahtarları dönüşüm için fonksiyonları destekler: string manipülasyonu (substring, regex), kodlama (base64, URL encode), aramalar (GeoIP ülke, ASN) ve koşullu mantık. Bunları birleştirerek karmaşık kalıcılık kuralları oluşturabilirsiniz. Örneğin: 'İstemci AB ülkelerinden VE geçerli istemci sertifikasına sahipse, sertifika CN'sinden hash anahtarı oluştur; aksi takdirde Authorization header'ından oluştur'—böylece aynı koşulları karşılayan istekler her zaman aynı backend sunucuya iletilir.
Kalıcılık Yöntemleri Karşılaştırması
| Yöntem | Dayanak | Yapılandırma | En Uygun |
|---|---|---|---|
| Source | İstemci IP adresi hash'i | Yok (otomatik) | Basit web uygulamaları, eski sistemler |
| URI | İstek yolu hash'i | URI uzunluğu, URI derinliği | Önbellek, içerik yönlendirme, parçalanmış backend'ler |
| URL Param | URL/POST parametre değeri | Parametre adı, POST kontrol seçeneği | Oturum takibi, kullanıcıya özgü yönlendirme |
| HDR | HTTP başlık değeri | Başlık adı | API kimlik doğrulama, çok kiracılı uygulamalar, JWT yönlendirme |
| New Cookie | LB yönetimli çerez | Çerez adı, max-idle, max-life | Uygulama değişikliği gerekmez, oturum timeout kontrolü |
| Current Cookie | Mevcut uygulama çerezi | Takip edilecek çerez adı | Mevcut uygulama oturumlarını kullan |
| Hash | Özel anahtar ifadesi | Anahtar değişkenleri, fonksiyonlar, 3M giriş, 7 gün TTL | Karmaşık çok faktörlü kalıcılık, sınırsız esneklik |
Algoritma Seçim Rehberi
Doğru algoritmayı seçmek, spesifik gereksinimlerinize bağlıdır. Bu karşılaştırma, temel ödünleşimleri vurgular:
| Algoritma | Yük Farkındalığı | Karmaşıklık | Kalıcılık | Birincil Kullanım Senaryosu |
|---|---|---|---|---|
| Round Robin | Yok | Minimum | Hayır | Homojen stateless iş yükleri |
| Weighted Round Robin | Statik (ağırlıklar) | Düşük | Hayır | Karışık sunucu kapasiteleri |
| Least Connection | Dinamik (bağlantılar) | Orta | Hayır | Uzun oturumlar, veritabanları |
| First | Yok | Minimum | Hayır | Aktif-pasif, lisans optimizasyonu |
| Random | Dinamik (yanıt süresi) | Düşük | Hayır | Büyük kümeler, önbellek sunucuları |
| Fastest | Dinamik (yanıt süresi) | Orta | Hayır | Gecikmeye duyarlı uygulamalar |
| Fastest+ | Çok kriterli | Yüksek | Hayır | Karmaşık üretim ortamları |
| Source | Ağırlıklar üzerinden | Düşük | Evet (IP) | Basit oturum kalıcılığı |
| URI | Ağırlıklar üzerinden | Orta | Evet (yol) | Önbellek, içerik yönlendirme |
| URL Param | Ağırlıklar üzerinden | Orta | Evet (kullanıcı kimliği) | Kullanıcı oturum takibi |
| HDR | Ağırlıklar üzerinden | Orta | Evet (başlık) | API yönlendirme, çok kiracılı |
Algoritmanızı Seçme
Dağıtım Algoritmalarını Ne Zaman Kullanmalı
- Uygulama stateless veya paylaşılan oturum deposu kullanıyor
- Yükü sunucu havuzuna yaymak gerekiyor
- Sunucular farklı kapasitelere sahip (Weighted kullanın)
- Yanıt süresi optimizasyonu kritik (Fastest/Fastest+ kullanın)
Kalıcılık Yöntemlerini Ne Zaman Kullanmalı
- Uygulama oturum verilerini sunucularda yerel olarak saklıyor
- Backend hizmetleri kullanıcı veya içeriğe göre parçalanmış
- Önbellek verimliliği tutarlı yönlendirme gerektiriyor
- Token veya başlık tabanlı kimlik doğrulama kullanılıyor
Fastest+'ı Ne Zaman Kullanmalı
- Tek metrik optimizasyon hedefinizi yakalamıyor
- Homojen sunucular için eşitlik çözme mantığı gerekli
- Hem performans hem de güvenilirlik önemli
- Karmaşık üretim ortamı ile çeşitli iş yükleri mevcut
Uygulama En İyi Uygulamaları
Seçilen algoritmadan bağımsız olarak, bu uygulamalar optimal yük dengeleme performansı sağlar:
Sağlam Sağlık Kontrolleri Uygulayın
Sadece TCP bağlantısını değil, uygulama işlevselliğini doğrulayan aktif sağlık kontrolleri yapılandırın. Ping'lere yanıt veren ancak 500 hataları döndüren bir sunucu rotasyondan çıkarılmalıdır.
Ağırlıkları İzleyin ve Ayarlayın
Weighted algoritmalar için, ağırlık atamalarını üç ayda bir veya altyapı değişikliklerinden sonra gözden geçirin. Doğru kapasite oranlarını belirlemek için sunucuları gerçekçi yük altında benchmark yapın.
Kalıcılığı Akıllıca Seçin
Mümkün olduğunda uygulamaları stateless olacak şekilde tasarlayın, oturumları Redis gibi harici depolarda saklayın. Kalıcılık gerekiyorsa, oturum tanımlayıcınızla en iyi eşleşen yöntemi seçin (IP, URI, parametre veya başlık).
Failover Senaryolarını Test Edin
Zarif failover'ı sağlamak için sunucu arızalarını düzenli olarak test edin. Sunucular havuzdan çıkarıldığında ve yeniden eklendiğinde algoritma davranışının doğru olduğunu doğrulayın.
Karmaşık Senaryolar için Fastest+ Kullanın
Tek metrikli algoritmalar ihtiyaçlarınızı karşılamadığında, Fastest+'ı birincil ve ikincil kriterlerle yapılandırın. Opt-1 olarak Least Response Time ve Opt-2 olarak Least Connection Error ile başlayın.
Sık Sorulan Sorular
Evet, kalıcılık yöntemleri (Source, URI, URL Param, HDR) zaten yönlendirme kararlarına sunucu ağırlıklarını dahil eder. Bu, hem oturum affinitesi hem de kapasite duyarlı dağıtım elde edeceğiniz anlamına gelir. Hash tabanlı seçim, sunucu yapılandırmalarına göre ağırlıklandırılır.
Yanıt süresi tek endişeniz olduğunda ve sunucuların açıkça farklı performans özellikleri varsa Fastest kullanın. Daha nüanslı seçim gerektiğinde Fastest+ kullanın—örneğin, yanıt süresini optimize etmek ama yanıt süreleri benzer olduğunda daha az hatalı sunucuları tercih etmek.
Kalıcı bir sunucu kullanılamaz hale geldiğinde, istekler kalıcılık algoritmasının hash yeniden dağıtımına göre başka bir sunucuya yönlendirilir. Arızalı sunucudaki oturum verileri, uygulamanız harici oturum depolaması kullanmıyorsa kaybolur. Sağlık kontrolleri, arızalı sunucuların havuzdan hızla çıkarılmasını sağlar.
Bağımsız bir algoritma olarak Least Connection, en az aktif bağlantıya sahip sunucuya yönlendirir. Fastest+'taki 'Least Used Connections', sunucunun kapasitesine göre bağlantı kullanımını dikkate alır, bu da onu heterojen sunucu ortamları için daha uygun kılar.
Mobil uygulamalar için Source (IP) kalıcılığından kaçının çünkü mobil cihazlar sık sık IP adresi değiştirir. Kullanıcı kimliği veya oturum token'ı ile URL Param kalıcılığı veya kimlik doğrulama başlığı ile HDR kalıcılığı kullanın. Bu yöntemler, ağ değişikliklerinden bağımsız olarak kullanıcının oturumunu takip eder.
Sonuç
Yük dengeleme algoritmaları, uygulama tesliminin temelini oluşturur, ancak mimari kararlar sırasında sıklıkla göz ardı edilir. Doğru algoritma, eşit sunucu kullanımı, optimal yanıt süreleri ve dayanıklı failover sağlar—yanlış seçim ise hot spot'lar oluşturabilir, performansı düşürebilir ve sorun gidermeyi zorlaştırabilir.
Çoğu üretim ortamı için, dinamik iş yükleri için Least Connection veya statik kapasite dağıtımı için Weighted Round Robin ile başlayın. İzleme yetenekleriniz olgunlaştıkça, çok kriterli optimizasyon için Fastest+'ı keşfedin. Kalıcılık yöntemlerini oturum yönetimi stratejinize göre seçin—basitlik için Source veya uygulama duyarlı yönlendirme için URI/URL Param/HDR.
Akıllı Trafik Dağıtımı
TR7 Load Balancer, çok kriterli optimizasyonlu gelişmiş Fastest+ dahil tüm önemli algoritmaları ve oturum duyarlı yönlendirme için esnek kalıcılık seçeneklerini destekler. Kurumsal düzeyde yük dengeleme ile uygulama tesliminizi optimize edin.
Load Balancer'ı Keşfet