Load balancer ne işe yarar?

Load balancer, bir uygulamaya gelen istemci isteklerini birden fazla sunucuya dağıtan bileşendir. Amaç; tek sunucunun aşırı yüklenmesini önlemek, kullanılabilirliği artırmak ve gerektiğinde kapasiteyi yeni sunucular ekleyerek büyütmektir. Bir sunucu arızalandığında load balancer, uygun şekilde yapılandırılmışsa yeni istekleri çalışan sunuculara yönlendirebilir.

Nasıl çalışır?​

Kullanıcı genellikle uygulamanın gerçek sunucu adresini değil, load balancer’ın erişim noktasını kullanır. Load balancer isteği alır, arka uç sunucuların durumunu değerlendirir ve seçtiği sunucuya iletir. HTTP ters vekil örneğinde istemci ve arka uç bağlantıları ayrı yönetilir, yanıt istemciye iletilir. Katman4 veya doğrudan sunucu dönüşü mimarisinde trafik yolu farklı olabilir.

Sunucu seçimi; sırayla dağıtım, en az bağlantıya sahip sunucuyu seçme veya ağırlık tanımlama gibi yöntemlerle yapılabilir. Sağlık kontrolü ayrıca önemlidir. Örneğin bir sunucu ağ üzerinden erişilebilir olsa bile uygulama işlemi çalışmıyorsa, yalnızca port kontrolü arızayı fark etmeyebilir. Bu nedenle mümkünse uygulamanın gerçekten yanıt verdiği bir kontrol uç noktası kullanılmalıdır.

Load balancer her sorunu kendiliğinden çözmez. Veritabanı, dosya depolama, oturum yönetimi ve uygulama yapılandırması birden fazla sunucuyla çalışmaya uygun değilse, yalnızca istekleri dağıtmak yeni hatalar oluşturabilir.

Somut örnek​

Bir web uygulamasının iki arka uç sunucusu olduğunu varsayalım: Sunucu A ve Sunucu B. Kullanıcıların tamamı doğrudan Sunucu A’ya bağlanırsa A’daki CPU, bellek veya bağlantı sayısı sınırına ulaşabilir; B ise boşta kalabilir. Load balancer isteklere göre trafiğin bir bölümünü A’ya, kalanını B’ye gönderir.

Uygun sağlık kontrolü A’daki arızayı algılarsa A geçici olarak dağıtım listesinden çıkarılır. Aktif/pasif kontrol desteği ürüne ve sürüme bağlıdır. Böylece yeni istekler B’ye gider. Ancak B’nin tek başına tüm trafiği karşılayacak kaynaklara sahip olup olmadığı ayrıca kontrol edilmelidir. Load balancer kesintiyi azaltabilir, fakat yetersiz kapasiteyi ortadan kaldırmaz.

Hangi yaklaşım ne zaman uygundur?​

Aşağıdaki karar, gereksinimi doğru bileşenle eşleştirmeye yardımcı olur:


Bu tablo, “daha fazla sunucu ekleyeyim” kararından önce uygulamanın durum tutup tutmadığını da incelemeniz gerektiğini gösterir. Oturumlar yerel bellekte tutuluyorsa kullanıcı başka sunucuya geçtiğinde oturum kaybolabilir. Tercih edilen çözüm, oturumları ortak bir depoda tutmak veya uygulamayı sunucu değişiminden etkilenmeyecek şekilde tasarlamaktır.

Kurulum ve doğrulama sırası​

1. Arka uç sunucuların aynı uygulama sürümünü, yapılandırmayı ve gerekli dosyaları sunduğunu doğrulayın. Tek sunucuda çalışan ancak diğerinde bulunmayan bir dosya, dağıtım sonrası aralıklı hatalara yol açar.
2. Load balancer’a arka uç sunucuları ekleyin ve her biri için gerçek bir uygulama sağlık kontrolü tanımlayın. Kontrol adresi yalnızca sunucunun açık olduğunu değil, uygulamanın kullanılabilir olduğunu göstermelidir.
3. İstemci trafiğini load balancer’a yönlendirin. HTTPS kullanılıyorsa TLS sertifikasının nerede sonlandırılacağını ve istemci IP bilgisinin uygulamaya nasıl aktarılacağını belirleyin.
4. Önce sınırlı bir istek grubuyla test yapın. Yanıt kodlarını, gecikmeyi, hata günlüklerini ve iki arka uç sunucusundaki trafik dağılımını karşılaştırın.
5. Kendi yalıtılmış deneme ortamınızda bir arka uç sunucuyu kontrollü olarak erişilemez duruma getirip yeni isteklerin diğer sunucuya ulaştığını doğrulayın. Başarısız olursa sağlık kontrolü, ağ erişimi veya yönlendirme kuralını inceleyin.
6. Son olarak kapasite sınırlarını belirleyin ve load balancer’ın, arka uçların ve varsa ortak oturum/veritabanı bileşenlerinin izlenmesini kurun.

Beklenen sonuç, kullanıcıların tek bir arka uç sunucuya bağımlı kalmadan hizmet alması ve arızalı sunucunun yeni isteklerden çıkarılmasıdır. Arızalı sunucu tekrar listeye alınmadan önce uygulama günlükleri ve sağlık kontrolü yanıtı incelenmelidir; aksi durumda hatalı sunucu sürekli olarak trafiğe geri dönebilir.

Sık yapılan hatalar​

Sağlık kontrolünü yanlış tanımlamak: Her zaman başarılı yanıt veren basit bir statik dosya, uygulamanın veritabanına veya temel bağımlılıklarına erişemediğini fark etmeyebilir.

Oturumları yerel sunucuda bırakmak: İstekler farklı sunuculara dağıtıldığında kullanıcıların oturumu düşebilir. Ortak oturum deposu veya stateless uygulama tasarımı değerlendirilmelidir.

Load balancer’ı tek hata noktası yapmak: Tek bir load balancer, kendi arızasında hizmeti kesebilir. Kritik ortamlarda bileşenin yedekliliği, DNS davranışı ve yönetim planı ayrıca ele alınmalıdır.

Sadece trafik dağılımına bakmak: Trafiğin eşit bölünmesi, sunucuların eşit yükte olduğu anlamına gelmez. Yanıt süresi, hata oranı, CPU, bellek ve bağlantı sayısı birlikte izlenmelidir.

Sık sorulan sorular​

Load balancer yeni sunucuları kendisi oluşturur mu?​

Tek başına yük dengeleme bunu yapmaz. Otomatik ölçeklendirme ayrı politika ve altyapı bileşenidir; bazı yönetilen ürünler birlikte sunar. Yeni sunucunun gruba kaydı, hazır olma kontrolü ve çıkarken bağlantıların boşaltılması ayrıca tasarlanır. Yük dengeleyicinin varlığı sonsuz kapasite anlamına gelmez.

Arızalı isteği başka sunucuda tekrarlamak her zaman doğru mu?​

Hayır. Ödeme veya sipariş gibi bir POST arka uçta tamamlanmış, yanıt kaybolmuş olabilir. Kör tekrar çift işlem oluşturabilir. Yeniden deneme politikası yöntem ve uygulama davranışıyla birlikte belirlenmeli; gerektiğinde idempotency anahtarı gibi tekrar kontrolü uygulanmalıdır. Sağlık kontrolü kaybolan yanıtı geri getirmez.