İçeriğe atla
Bilgi Merkezi/Makale
Makale

Load Balancer (Yük Dengeleyici) Nedir, Nasıl Çalışır?

Load balancer, trafiği birden fazla sunucuya dağıtır ve arızalı sunucuyu devreden çıkarır. Layer 4 ve 7 farkını, algoritmaları ve retry riskini anlattık.

Oğuzhan Gerçek··6 dk okuma
Load Balancer (Yük Dengeleyici) Nedir, Nasıl Çalışır?

Kısa cevap: Load balancer (yük dengeleyici), bir uygulamaya gelen trafiği arkasındaki birden fazla sunucuya dağıtan bileşendir. Her isteğin hangi sunucuya gideceğine round robin ya da least connections gibi bir algoritmayla karar verir, sunucuları health check ile sürekli yoklar ve cevap vermeyeni devreden çıkarır. Böylece tek bir sunucunun arızası kullanıcıya kesinti olarak yansımaz, kapasite de sunucu eklenerek büyütülür. Layer 4 load balancer bağlantı bilgisine, Layer 7 load balancer HTTP isteğinin içeriğine bakarak karar verir.

Load balancer nedir?

Cloudflare yük dengelemeyi, iş yükünün iki ya da daha fazla bilgisayar arasında dağıtılması olarak tanımlıyor. Load balancer bu işi yapan bileşen: istemci uygulamanın adresine bağlandığını düşünür, ama bağlantıyı load balancer karşılar ve isteği arkadaki sunucu havuzundan birine iletir.

İki işi var: kapasite ve erişilebilirlik. AWS'in Elastic Load Balancing tanımı ikisini birlikte veriyor: gelen trafiği bir ya da daha fazla Availability Zone'daki hedeflere dağıtır, hedeflerin sağlığını izler ve trafiği yalnızca sağlıklı olanlara yönlendirir. Kısa tanımı sözlüğümüzde bulabilirsiniz.

Layer 4 ve Layer 7 load balancer farkı

Katman, load balancer'ın karar verirken neyi görebildiğini belirler:

  • Layer 4 (taşıma katmanı): IP adresi, port ve protokol bilgisine bakar, isteğin içeriğini görmez. AWS'in 4. katmanda çalışan Network Load Balancer'ı her TCP bağlantısını, bağlantı sürdüğü müddetçe tek bir hedefe yönlendiriyor. HTTP dışındaki protokolleri de taşır.
  • Layer 7 (uygulama katmanı): HTTP isteğini okur ve her istek için ayrı karar verir. AWS'in Application Load Balancer'ı bu katmanda çalışıyor ve istekleri URL yoluna, host başlığına, HTTP başlıklarına ya da sorgu parametrelerine göre farklı sunucu gruplarına gönderebiliyor.

Layer 7 load balancer bir reverse proxy'dir; HAProxy'nin anlatımıyla istemci ve sunucu tarafında iki ayrı bağlantı vardır. TLS sonlandırma ve çerezle oturum yapışkanlığı bu sayede mümkün olur. Reverse proxy'yi proxy yazımızda anlattık; TLS'in açıldığı bu katman, bir WAF'ın çalışabileceği yerdir.

Yük dengeleme algoritmaları

Cloudflare'e göre statik algoritmalar sistemin o anki durumuna bakmaz, dinamik olanlar sunucuların yükünü ve sağlığını hesaba katar. Yaygın algoritmalar şunlar:

  • Round robin: İstekler sırayla her sunucuya gider. NGINX'te ve AWS Application Load Balancer'da varsayılan yöntem bu. Ağırlık (weight) verilen sunucuya daha çok istek düşer.
  • Least connections: İstek, o an en az etkin bağlantısı olan sunucuya gider. HAProxy bu yöntemi uzun bağlantılar için, round robin'i kısa bağlantılar için öneriyor.
  • IP hash ve generic hash: Sunucu, istemcinin IP adresinden ya da URL, çerez gibi bir anahtardan hesaplanır. NGINX'e göre IP hash, aynı adresten gelen istekleri o sunucu devrede olduğu sürece aynı sunucuya gönderir.

Health check: arızalı sunucu nasıl devreden çıkar?

Load balancer arızalı sunucuyu health check ile fark eder. İki yöntem var:

  • Aktif health check: Load balancer her sunucuya belirli aralıklarla deneme isteği gönderir. AWS ALB'de varsayılan aralık 30 saniye; hedef üst üste 2 başarısız yoklamada sağlıksız, 5 başarılı yoklamada yeniden sağlıklı sayılıyor.
  • Pasif health check: Load balancer gerçek trafiği izler. NGINX'te varsayılan ayar, 10 saniye içindeki tek bir başarısız denemenin sunucuyu 10 saniyeliğine devre dışı bırakması.

ALB'nin varsayılan ayarlarıyla bozulan bir hedefin trafikten çıkması yaklaşık bir dakikayı bulabilir (2 × 30 saniye). Yoklamanın neyi ölçtüğü de önemli: yalnızca ana sayfanın 200 döndüğünü kontrol eden bir health check, veritabanına bağlanamayan bir uygulamayı sağlıklı gösterebilir.

Session persistence (oturum yapışkanlığı)

Bazı uygulamalar oturum bilgisini sunucunun belleğinde tutar. HAProxy'nin verdiği örnek alışveriş sepeti: her tıklama yeni bir bağlantı açıyorsa kullanıcı hep sepetinin durduğu sunucuya gönderilmeli. Session persistence (sticky session) bunu sağlar; bunun için IP hash ya da çerez kullanılır.

Bedeli var. AWS'in belgesine göre hedef sayısı belirgin biçimde arttığında yapışkanlık yükün eşit dağılmamasına yol açabiliyor. Sunucu arızalanınca kullanıcı yeni bir sunucuya taşınır, ama eski sunucunun belleğindeki oturum onunla gider. Kalıcı çözüm, oturum bilgisini sunucudan çıkarıp ortak bir depoda tutmak; o zaman her sunucu her isteği karşılayabilir.

Yüksek erişilebilirlik ve failover

Tek bir load balancer, korumaya çalıştığı sistemin tek arıza noktası olur. Kurum içi kurulumlarda çözümlerden biri, iki load balancer'ı aktif-pasif çalıştırmak: VRRP, ortak sanal IP adresinin hangi cihazda duracağını seçer, aktif cihaz düşerse adres diğerine geçer. VRRP'nin güncel tanımı Nisan 2024 tarihli RFC 9568; HAProxy'nin belgeleri de keepalived ile VRRP kullanımını öneriyor.

Bulut load balancer'ları yönetilen bir hizmet olarak gelir; AWS ELB trafiği bir ya da daha fazla Availability Zone'daki hedeflere dağıtıyor. Hedeflerin hepsi tek bir Availability Zone'daysa, oradaki bir arıza hepsini birden durdurur. Erişilebilirlik hedefinin nasıl ölçüldüğünü uptime yazımızda anlattık.

Donanım, yazılım ve bulut load balancer'lar

Cloudflare'in ayrımıyla donanım load balancer'ı özel bir cihaz gerektirir; yazılım load balancer'ı bir sunucuda, sanal makinede ya da bulutta çalışabilir:

  • Donanım: Örneğin F5 BIG-IP; F5 onu rSeries ve VELOS donanımlarında, ayrıca hypervisor ya da bulutta çalışan Virtual Edition olarak sunuyor.
  • Yazılım: NGINX ve HAProxy açık kaynak örnekler; ikisi de HTTP'nin yanında TCP trafiğini de dengeleyebiliyor.
  • Bulut: AWS'te Layer 7 için Application Load Balancer, Layer 4 için Network Load Balancer var; Azure Load Balancer da 4. katmanda çalışıyor.

Retry'lar backend yükünü nasıl katlar?

Load balancer başarısız bir isteği başka bir sunucuda yeniden deneyebilir. NGINX'te bu davranış proxy_next_upstream yönergesiyle gelir ve varsayılan olarak hata ve zaman aşımında devreye girer; deneme sayısını sınırlayan proxy_next_upstream_tries'ın varsayılan değeri 0, yani sınırsız. POST ve PATCH gibi idempotent olmayan istekler ise 1.9.13 sürümünden beri, sunucuya bir kez gönderildikten sonra açıkça izin verilmedikçe başka sunucuya aktarılmıyor.

Tek katmanda makul görünen retry, katmanlar üst üste bindiğinde çarpılır. İstemci 3 deneme yapıyor ve load balancer her denemeyi 3 kez deniyorsa backend aynı istek için 9 deneme görür; hesabı Reliability Friday 09 yazımızda adım adım yaptık. AWS'in örneğinde beş katmanlı bir çağrı zincirinde her katman kendi başına yeniden denediğinde veritabanına binen yük 243 katına çıkıyor. AWS'in önerisi, retry'ı stack'in tek bir noktasında yapmak ve yan etkisi olan API'leri idempotent olmadıkça yeniden denememek.

Load balancer'ların kurulumunu ve izlenmesini ağ ve trafik mühendisliği hizmetimizde ele alıyoruz.

Sık sorulan sorular

Load balancer ne demek? Yük dengeleyici demek: bir uygulamaya gelen trafiği birden fazla sunucuya dağıtan ve arızalı sunucuyu devreden çıkaran bileşen.

Load balancer ne işe yarar? Tek bir sunucunun aşırı yüklenmesini önler, arızalı sunucuyu devreden çıkarır ve sunucu eklenerek kapasitenin büyütülmesini sağlar.

Layer 4 ve Layer 7 load balancer arasındaki fark nedir? Layer 4 load balancer IP adresi, port ve protokole bakarak bağlantı bazında karar verir. Layer 7 load balancer HTTP isteğini okur; adrese, başlığa ya da çereze göre her istek için ayrı karar verebilir.

Sticky session nedir? Aynı kullanıcının isteklerinin oturum boyunca hep aynı sunucuya gönderilmesidir. Genellikle çerezle ya da istemcinin IP adresiyle sağlanır.

Load balancer ile reverse proxy aynı şey mi? Layer 7 load balancer bir reverse proxy türüdür, ama her reverse proxy yük dağıtmaz: reverse proxy tek bir sunucunun önünde de durabilir.

Kaynaklar