Özel Sunucularla Yük Dengeleme: Mimari, Algoritmalar ve Gerçek Dünya Uygulaması

Yük dengeleme, gelen ağ trafiğini birden fazla sunucuya dağıtarak hiçbir düğümün darboğaz haline gelmemesini sağlayan, tutarlı performans, hata toleransı ve yatay ölçeklenebilirlik sunan bir süreçtir. Özel sunucu ortamında, bir yük dengeleyici sunucu havuzunuzun önünde konumlanır ve sunucu sağlığı, aktif bağlantılar, yanıt gecikmesi veya özel politika kurallarına göre gerçek zamanlı yönlendirme kararları alır.

Gecikmeye duyarlı iş yükleri çalıştıran her altyapı için — e-ticaret platformları, SaaS uygulamaları, yüksek trafikli API’ler veya medya akışı — yük dengeleme isteğe bağlı değildir. Kırılgan tek hata noktası kurulumunu üretim kalitesinde, dayanıklı bir sistemden ayıran mimari temeldir.

Yük Dengeleme Gerçekte Nasıl Çalışır: Teknik Akış

Yük dengelemeyi anlamak, yalnızca “trafiği dağıtma” soyut kavramını değil, tam istek yaşam döngüsünü anlamayı gerektirir.

İstek Yönlendirme Hattı

1. DNS çözümlemesi, istemciyi herhangi bir sunucuya değil, yük dengeleyicinin IP adresine (veya anycast kurulumunda sanal bir IP’ye) yönlendirir.
2. Yük dengeleyici bağlantıyı alır; OSI modelinin Layer 4 (TCP/UDP) veya Layer 7 (HTTP/HTTPS) katmanında.
3. Dengeleyici yönlendirme tablosunu değerlendirir, yapılandırılmış algoritmayı uygular ve her arka uç düğümünün mevcut sağlık durumunu kontrol eder.
4. İstek seçilen arka uç sunucusuna iletilir. Moda bağlı olarak (NAT, Direct Server Return veya IP tünelleme), yanıt yolu dengeleyiciden geçebilir veya geçmeyebilir.
5. Sağlık kontrolü arka plan programları paralel olarak çalışır; TCP ping, HTTP durum kodları veya özel betikler aracılığıyla her arka ucu sürekli olarak yoklar. Başarısız olan bir düğüm saniyeler içinde havuzdan çıkarılır.

Layer 4 ve Layer 7 Yük Dengeleme

Bu ayrım, yapacağınız en kritik mimari kararlardan biridir.

Özel Sunucularda barındırılan çoğu web uygulaması için Layer 7 doğru seçimdir; çünkü akıllı yönlendirme, SSL boşaltma ve ham TCP bağlantısı yerine HTTP yanıt kodlarına dayalı ayrıntılı sağlık kontrollerine olanak tanır.

Yük Dengeleme Algoritmaları: Doğru Stratejiyi Seçmek

Algoritma, her gelen isteğin hangi arka uç sunucusuna gönderileceğini belirler. İş yükü profiliniz için yanlış algoritmayı seçmek, dengesiz kaynak kullanımının yaygın bir kaynağıdır.

Round Robin

İstekler tüm sağlıklı düğümlere sırayla dağıtılır. Tüm sunucuların özdeş donanım özelliklerine sahip olduğu ve istek işleme sürelerinin kabaca eşit olduğu durumlarda basit ve etkilidir.

Tuzak: Bir istek 10 saniye, bir sonraki 10 milisaniye sürüyorsa, round robin bu eşitsizliği hesaba katmaz. Yavaş bir arka uç kuyruk biriktirirken diğerleri boşta bekler.

Ağırlıklı Round Robin

Her sunucuya sayısal bir ağırlık atanır. 3 ağırlığına sahip bir sunucu, 1 ağırlığına sahip olandan üç kat daha fazla istek alır. Havuzunuzda heterojen donanım bulunduğunda — örneğin 32 çekirdekli bir düğümü 16 çekirdekli bir düğümle karıştırırken — bunu kullanın.

En Az Bağlantı

Dengeleyici, her arka uca yönelik aktif bağlantı sayısını takip eder ve yeni istekleri en az açık bağlantıya sahip sunucuya yönlendirir. Bu, veritabanı destekli web uygulamaları gibi değişken istek sürelerine sahip iş yükleri için en uygun varsayılan algoritmadır.

En Düşük Yanıt Süresi

Ölçülen arka uç gecikmesini de hesaba katan, en az bağlantının bir uzantısıdır. Aktif bağlantı ve ortalama yanıt süresinin en düşük kombinasyonuna sahip sunucu kazanır. Bu, dengeleyicinin gecikme metriklerini tutmasını gerektirir; bu da küçük bir ek yük ekler ancak karma yük altında dağıtım kalitesini önemli ölçüde artırır.

IP Hash (Kaynak Yakınlığı)

İstemcinin kaynak IP adresi, bir arka ucu belirleyici biçimde seçmek için hash’lenir. Havuz üyeliği değişmediği sürece aynı istemci her zaman aynı sunucuya ulaşır. Bu, paylaşılan oturum depolaması gerektirmeden ilkel bir oturum kalıcılığı biçimi sağlar.

Kritik uç durum: Trafiğinizin büyük bir kısmı kurumsal bir NAT’ın veya mobil operatörün ağ geçidinin arkasından geliyorsa, binlerce kullanıcı tek bir kaynak IP’yi paylaşabilir ve bu durum ciddi dengesizliğe yol açar. Üretimde IP hash’e güvenmeden önce her zaman trafik dağılımınızı denetleyin.

İki Seçenekli Rastgele (İkinin Gücü)

Dengeleyici rastgele iki aday sunucu seçer ve daha az aktif bağlantıya sahip olana yönlendirir. Bu olasılıksal yaklaşım, büyük havuzlarda (50+ düğüm) son derece iyi ölçeklenir; çünkü küresel en az bağlantı taramasının koordinasyon yükünden kaçınırken saf rastgele seçimin en kötü durum dengesizliğini de önler.

Oturum Kalıcılığı: Durumsuzluğun Seçenek Olmadığı Durumlar

Birçok eski uygulama, oturum durumunu sunucuda yerel olarak depolar (örneğin diske yazılan PHP $_SESSION). Bu durumlarda, dönen bir kullanıcıyı farklı bir arka uca yönlendirmek oturum kaybına neden olur; bu da beklenmedik oturum kapatmaları veya kayıp alışveriş sepeti verisi olarak kendini gösterir.

Yük dengeleyiciler bunu yapışkan oturumlarla çözer; şu yollarla uygulanır:

• Çerez enjeksiyonu: Dengeleyici HTTP yanıtına bir çerez (örn. SERVERID=node2) enjekte eder. O istemciden gelen sonraki istekler çerezi taşır ve dengeleyici aynı düğüme geri yönlendirmek için onu okur.
• Kaynak IP yakınlığı: Yukarıda açıklandığı gibi, daha az güvenilirdir ancak uygulamadan çerez desteği gerektirmez.

Doğru uzun vadeli çözüm, oturum depolamasını paylaşılan bir arka uca — Redis veya Memcached — dışsallaştırmaktır; böylece herhangi bir arka uç düğümü herhangi bir kullanıcıya hizmet verebilir. Bu, yapışkan oturumlara olan bağımlılığı tamamen ortadan kaldırır ve havuzunuzu tamamen durumsuz hale getirir; bu da ölçeklendirmeyi ve yük devretmeyi önemli ölçüde basitleştirir. Yeni bir uygulama geliştiriyorsanız, başından itibaren durumsuz arka uçlar için tasarım yapın.

Sağlık Kontrolleri: Otomatik Yük Devretmenin Arkasındaki Mekanizma

Bir yük dengeleyici, yalnızca sağlık kontrolü yapılandırması kadar güvenilirdir. Yanlış yapılandırılmış sağlık kontrolleri, gerçek dünya yük dengeleyici olaylarının önemli bir bölümünden sorumludur.

Sağlık Kontrolü Türleri

• TCP kontrolü: Arka uç portuna bir TCP bağlantısı açar. Sürecin dinlediğini doğrular ancak uygulama düzeyinde doğruluğu doğrulamaz.
• HTTP/HTTPS kontrolü: Tanımlı bir uç noktaya (örn. /health) bir HTTP isteği gönderir ve belirli bir durum kodu (genellikle 200 OK) bekler. Bu, web uygulamaları için kabul edilebilir minimum standarttır.
• Özel betik kontrolü: Bir veritabanını sorgulayabilen, disk alanını kontrol edebilen veya uygulama durumunu doğrulayabilen rastgele bir betik çalıştırır. Sağlıklı için 0, sağlıksız için sıfır dışı bir değer döndürür.

Kritik Yapılandırma Parametreleri

• interval: Kontrolün ne sıklıkla çalıştığı (örn. her 5 saniyede bir).
• timeout: Kontrolü başarısız olarak işaretlemeden önce yanıt bekleme süresi.
• rise: Bir düğümü sağlıklı olarak işaretlemek için gereken ardışık başarılı kontrol sayısı (titreşimi önler).
• fall: Bir düğümü havuzdan çıkarmak için gereken ardışık başarısız kontrol sayısı.

HAProxy için yaygın bir üretim yapılandırması şöyle görünür:

backend web_servers
    balance leastconn
    option httpchk GET /health HTTP/1.1rnHost: example.com
    http-check expect status 200
    default-server inter 5s fall 3 rise 2 slowstart 60s
    server node1 192.168.1.10:80 check weight 10
    server node2 192.168.1.11:80 check weight 10
    server node3 192.168.1.12:80 check weight 5

slowstart 60s yönergesi özellikle değerlidir: bakımdan sonra çevrimiçi gelen bir arka uca tam yük göndermek yerine, yeni kurtarılan bir düğüme trafiği 60 saniye boyunca kademeli olarak artırır; bu da bir arka uç yeniden çevrimiçi olduğunda sürü sorununun önüne geçer.

SSL Sonlandırma ve TLS Boşaltma

TLS şifreleme ve şifre çözme işlemlerini gerçekleştirmek hesaplama açısından maliyetlidir. Naif bir kurulumda, her arka uç sunucu bu işi bağımsız olarak gerçekleştirir. Yük dengeleyicide SSL sonlandırma, dengeleyicinin gelen HTTPS trafiğini şifresini çözdüğü ve güvenilir bir iç ağ üzerinden arka uçlara düz HTTP ilettiği anlamına gelir.

Faydaları:

• Arka uç sunuculardaki CPU yükünü azaltır, uygulama mantığı için döngüleri serbest bırakır.
• Sertifika yönetimini merkezileştirir — her düğümde değil, dengeleyicide tek bir sertifikayı yenileyin.
• İstek içeriğinin Layer 7 incelemesini mümkün kılar (şifreli geçişle imkânsızdır).

Güvenlik değerlendirmesi: Yük dengeleyici ile arka uçlar arasındaki trafik şifresiz olarak iletilir. Tüm düğümler izole bir özel VLAN veya özel bir yönetim ağında olduğunda bu kabul edilebilir. Uyumluluk gereksinimleriniz (PCI-DSS, HIPAA) uçtan uca şifrelemeyi zorunlu kılıyorsa, SSL yeniden şifreleme kullanın: dengeleyici istemci taraflı TLS oturumunu sonlandırır ve her arka uca yeni bir TLS oturumu kurar. Bu, Layer 7 yönlendirmeyi etkinleştirirken tam şifrelemeyi korur.

SSL sonlandırmayı doğru şekilde verilmiş SSL Sertifikaları ile eşleştirmek, yük dengeli altyapınızın hem performans hem de uyumluluk gereksinimlerini karşılamasını sağlar.

Yük Dengeleyicinin Kendisi için Yüksek Kullanılabilirlik

Kendisi tek hata noktası olan bir yük dengeleyici, tüm mimarinin amacını boşa çıkarır. Üretim dağıtımları, yüksek kullanılabilirliğe sahip yük dengeleyici çifti gerektirir.

VRRP/Keepalived ile Aktif-Pasif

İki yük dengeleyici düğümü bir Sanal IP (VIP) paylaşır. Aktif düğüm VIP’yi tutar ve tüm trafiği işler. Pasif düğüm, aktif düğümü kalp atışı aracılığıyla izler. Aktif düğüm başarısız olursa, keepalived bir VRRP yük devretmesi tetikler ve pasif düğüm VIP’yi 1–3 saniye içinde devralır.

# Install keepalived on both load balancer nodes (Debian/Ubuntu)
apt-get install keepalived

# /etc/keepalived/keepalived.conf on the MASTER node
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass securepassword
    }
    virtual_ipaddress {
        203.0.113.10/24
    }
}

Yedek düğümde state BACKUP ve priority 90 ayarlayın. Daha yüksek önceliğe sahip düğüm VIP seçimini kazanır.

DNS Round Robin veya Anycast ile Aktif-Aktif

Her iki yük dengeleyici düğümü de trafiği aynı anda aktif olarak işler. DNS birden fazla A kaydı döndürerek istemcileri her iki dengeleyiciye dağıtır. Bu, aktarım kapasitesini iki katına çıkarır ancak yapışkan oturumlar kullanıyorsanız dikkatli durum senkronizasyonu gerektirir.

Özel Sunucularda büyük ölçekli dağıtımlar için, BGP anycast yönlendirmeli aktif-aktif yapılandırma en yüksek aktarım hızını ve coğrafi yedekliliği sağlar.

Yük Dengeleyici Katmanında DDoS Azaltma

Ağ kenarında konumlanan bir yük dengeleyici, kötü amaçlı istekler uygulama sunucularınıza ulaşmadan önce trafik temizleme ve hız sınırlama uygulamak için doğal bir yerdir.

Bağlantı Hızı Sınırlama (HAProxy)

frontend http_in
    bind *:80
    bind *:443 ssl crt /etc/haproxy/certs/
    stick-table type ip size 100k expire 30s store conn_rate(3s),http_req_rate(10s)
    tcp-request connection track-sc0 src
    tcp-request connection reject if { sc_conn_rate(0) gt 100 }
    http-request deny if { sc_http_req_rate(0) gt 300 }

Bu yapılandırma, yapışkan tabloda kaynak IP başına bağlantı hızlarını takip eder ve 3 saniyede 100’den fazla yeni TCP bağlantısı veya 10 saniyede 300’den fazla HTTP isteği aşan istemcileri reddeder — bu eşikler, meşru ani trafik artışlarına izin verirken çoğu hacimsel HTTP taşkın saldırısını engeller.

SYN Taşkın Koruması

Bağlantı tablosunu tüketmeden SYN taşkın saldırılarını ele almak için yük dengeleyici düğümlerinizde çekirdek düzeyinde SYN çerezlerini etkinleştirin:

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sysctl -w net.ipv4.tcp_synack_retries=2

Bunları /etc/sysctl.conf‘e ekleyerek kalıcı hale getirin.

Layer 7 Yük Dengeleyici Olarak NGINX: Üretim Yapılandırması

NGINX, özellikle uygulama düzeyindeki özelliklerle sıkı entegrasyon ihtiyacı duyduğunuzda HTTP yük dengeleme için yaygın olarak kullanılan bir seçenektir.

upstream backend_pool {
    least_conn;
    keepalive 32;

    server 192.168.1.10:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.11:8080 weight=3 max_fails=3 fail_timeout=30s;
    server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
    server 192.168.1.13:8080 backup;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    location / {
        proxy_pass         http://backend_pool;
        proxy_http_version 1.1;
        proxy_set_header   Connection "";
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
        proxy_next_upstream   error timeout http_502 http_503;
    }
}

Bu yapılandırmadaki temel ayrıntılar:

• keepalive 32, arka uçlara kalıcı bağlantılar sağlayarak yüksek frekanslı istekler için TCP el sıkışma yükünü ortadan kaldırır.
• proxy_next_upstream, başarısız istekleri otomatik olarak bir sonraki sağlıklı arka uçta yeniden dener.
• backup yönergesi, node4‘yi yalnızca tüm birincil düğümler kullanılamaz olduğunda trafik alan bir yedek olarak belirler.
• X-Forwarded-For, arka uç uygulamalarının dengeleyicinin IP’si yerine gerçek istemci IP’sini görmesini sağlar.

Yük Dengeleyici Yazılım Seçeneklerinin Karşılaştırması

Kendi kendine yönetilen Özel Sunucular için HAProxy ve NGINX, üretim kullanım durumlarının büyük çoğunluğunu karşılar. Traefik, otomatik servis keşfi nedeniyle Docker Swarm veya Kubernetes iş yükleri için pragmatik seçimdir.

Gerçek Dünya Mimarisi: Yoğun Yük Altında E-Ticaret Platformu

Somut bir senaryo düşünün: promosyon etkinliği sırasında 50.000 eş zamanlı kullanıcı bekleyen bir e-ticaret platformu.

Altyapı düzeni:

• Keepalived aracılığıyla VIP paylaşan aktif-pasif yapılandırmada 2x HAProxy düğümü
• Web katmanını çalıştıran 6x uygulama sunucusu
• 2x özel veritabanı sunucusu (yük dengeleyici havuzunda değil — kendi replikasyonlarını kullanırlar)
• Paylaşılan oturum depolaması için 1x Redis kümesi (yapışkan oturum bağımlılığını ortadan kaldırır)
• Kullanıcı tarafından yüklenen varlıklar için paylaşılan NFS veya nesne depolama

Trafik akışı:

1. İstemci DNS, aktif HAProxy düğümü tarafından tutulan VIP’ye çözümlenir.
2. HAProxy, leastconn algoritmasını uygulayarak istekleri 6 uygulama sunucusuna dağıtır.
3. Her uygulama sunucusu Redis’ten oturum verilerini okur/yazar — oturum yakınlığı gerekmez.
4. Statik varlıklar, CDN aracılığıyla doğrudan nesne depolamadan sunulur; yük dengeleyiciyi tamamen atlayarak yükünü %60–70 azaltır.
5. Bir uygulama sunucusunun sağlık kontrolü üst üste üç kez başarısız olursa, HAProxy onu 15 saniye içinde havuzdan çıkarır. Kalan 5 sunucu trafiğini emer.
6. Aktif HAProxy düğümü başarısız olursa, Keepalived VIP’yi 2 saniye içinde pasif düğüme aktarır — tüm istemciler için şeffaf.

Bu mimari, herhangi bir tek bileşenin darboğaz haline gelmesine izin vermeden promosyon artışını karşılar ve sıfır kesinti süresiyle HAProxy havuzuna daha fazla uygulama sunucusu eklenerek yatay olarak ölçeklenir.

Bir yük dengeleyicinin arkasında GPU hızlandırmalı çıkarım iş yükleri çalıştırıyorsanız — örneğin ML model sunma isteklerini dağıtmak — aynı ilkeler geçerlidir; ancak arka uç sağlık kontrolleri yalnızca HTTP erişilebilirliğini değil, GPU kullanılabilirliğini ve VRAM kapasitesini doğrulamalıdır. GPU Hosting altyapısı, farklı istek türlerinde çıkarım gecikmesindeki yüksek varyans nedeniyle en düşük yanıt süresi dengelemesinden önemli ölçüde yararlanır.

Yük Dengeli Altyapıyı İzleme

Gözlemlenebilirlik olmadan bir yük dengeleyici dağıtmak, kör olarak çalışmak demektir. Önem taşıyan metrikler şunlardır:

• Arka uç başına aktif bağlantılar: Dağıtım algoritmasındaki dengesizliği veya yapışkan oturum yoğunlaşmasını ortaya koyar.
• Arka uç başına istek hızı (RPS): Sunucu ağırlıklarıyla orantılı olmalıdır.
• Arka uç yanıt süresi (p50, p95, p99): Bir düğümdeki p99 gecikme artışları, sağlık kontrolleri tetiklenmeden önce bir sorunu işaret eder.
• Sağlık kontrolü başarısızlık oranı: Sağlıklı ve sağlıksız arasında gidip gelen (titreyen) bir arka uç, araştırılması gereken temel bir kararsızlığa işaret eder.
• Bağlantı kuyruğu derinliği: Dengeleyicinin kuyruğu büyüyorsa, arka uç havuzunuz mevcut trafik için yetersiz boyutlandırılmıştır.
• SSL el sıkışma hızı: Yüksek hızlar, olası bir TLS tükenme saldırısına veya agresif biçimde yeniden deneyen yanlış yapılandırılmış bir istemciye işaret eder.

HAProxy bir istatistik sayfası sunar (ön uçta stats enable ile etkinleştirin) ve programatik sorgular için bir Unix soketi sağlar. Bu metrikleri haproxy_exporter aracılığıyla Prometheus’a aktarın ve eksiksiz bir gözlemlenebilirlik yığını için Grafana’da görselleştirin.

Pratik Karar Kontrol Listesi

Yük dengeli bir mimari dağıtmadan veya değiştirmeden önce bu matrisi kullanın:

• Durumlu uygulama? Yük dengelemeyi etkinleştirmeden önce oturum depolamasını Redis veya Memcached’e taşıyın. Yapışkan oturumlara kalıcı çözüm olarak güvenmeyin.
• TLS gerekli mi? SSL’yi yük dengeleyicide sonlandırın. Arka uç ağının izole olduğundan emin olun. Sertifikaları SSL Sertifikaları aracılığıyla merkezi olarak edinin ve yönetin.
• Değişken istek süresi? Round robin yerine leastconn kullanın.
• Heterojen donanım? Sunucu kapasitesiyle orantılı weight değerleri uygulayın.
• Yük dengeleyici HA? Keepalived/VRRP ile iki dengeleyici düğümü dağıtın. Üretimde hiçbir zaman tek bir yük dengeleyici çalıştırmayın.
• DDoS maruziyeti? Çekirdek ve dengeleyici katmanlarında bağlantı hızı sınırlama ve SYN çerez koruması uygulayın.
• Sağlık kontrolü derinliği? Yalnızca TCP port kullanılabilirliğini değil, veritabanı bağlantısını doğrulayan özel bir /health uç noktasına karşı HTTP kontrolleri kullanın.
• Ölçeklendirme planı? HAProxy veya NGINX havuzuna yeni bir arka uç düğümü eklemek, yapılandırma yeniden yüklemesi gerektirir (sıfır kesinti süreli yeniden yükleme için haproxy -sf $(cat /var/run/haproxy.pid)) — değişiklik yönetimi sürecinizi buna göre planlayın.
• İzleme? Bir olaydan sonra değil, canlıya geçmeden önce HAProxy veya NGINX’i Prometheus dışa aktarıcılarıyla donatın.
• Kontrol paneli tercihi? Manuel yük dengeleyici yapılandırmasının yanı sıra GUI tabanlı sunucu yönetimini tercih ediyorsanız, bireysel düğümlerdeki yönetim görevleri için VPS Kontrol Panellerini değerlendirin.

SSS

Yük dengeleyici ile ters proxy arasındaki fark nedir?

Ters proxy, istemci isteklerini bir veya daha fazla arka uç sunucusuna iletir ve yanıtı istemciye döndürür — yönlendirme, önbelleğe alma ve SSL sonlandırmayı yönetir. Yük dengeleyici, birincil işlevi tanımlı bir algoritma kullanarak istekleri birden fazla arka uç arasında dağıtmak olan özel bir ters proxy türüdür. Tüm yük dengeleyiciler ters proxy’dir, ancak tüm ters proxy’ler yük dengeleme yapmaz.

Yük dengeleme tek bir özel sunucuyla çalışabilir mi?

Teknik olarak evet — SSL sonlandırma, önbelleğe alma ve hız sınırlama için tek bir sunucunun önüne bir yük dengeleyici koyabilirsiniz. Ancak hata toleransı ve yatay ölçeklendirme faydaları yalnızca iki veya daha fazla arka uç düğümüyle gerçekleşir. Yük dengeleyicinin arkasındaki tek sunucu kurulumu, gelecekteki ölçeklendirmeyi operasyonel olarak önemsiz hale getiren geçerli bir basamak taşı mimarisidir.

Yük dengeleyici WebSocket bağlantılarını nasıl yönetir?

WebSocket’ler kalıcı, uzun ömürlü TCP bağlantıları gerektirir. Layer 7 yük dengeleyiciler, HTTP Upgrade el sıkışmasını yönetmek ve ardından WebSocket oturumunun süresi boyunca bağlantı yakınlığını korumak için açıkça yapılandırılmalıdır. NGINX’te proxy_http_version 1.1 ve proxy_set_header Connection "upgrade" ile proxy_set_header Upgrade $http_upgrade ayarlayın. HAProxy’de option http-server-close kullanın ve uzun ömürlü bağlantılar için uygun zaman aşımı değerlerini (timeout tunnel 1h) yapılandırın.

Bir arka uç sunucu başarısız olduğunda uçuştaki isteklere ne olur?

NGINX’teki proxy_next_upstream veya HAProxy’deki retries ile dengeleyici, ilk denemede bir bağlantı hatası veya zaman aşımı algılar ve isteği hemen bir sonraki sağlıklı arka uçta yeniden dener. Bu yeniden deneme istemci için şeffaftır. Idempotent istekler (GET, HEAD) otomatik olarak yeniden denenebilir. Idempotent olmayan istekler (POST, PUT) dikkatli yeniden deneme gerektirir — bir ödeme veya form gönderiminin çift işlenmesini önlemek için POST rotaları için http_500‘yi hariç tutmak üzere proxy_next_upstream yapılandırın.

Yük dengelemenin anlamlı fayda sağlaması için kaç arka uç sunucu gereklidir?

İki sunucu anında yük devretme kapasitesi sağlar ve kapasiteyi yaklaşık olarak iki katına çıkarır. Üç veya daha fazla sunucu anlamlı istatistiksel dağıtım sağlar ve kademeli bakıma olanak tanır (diğerleri trafiği emerken güncellemeler için bir düğümü çevrimdışı alın). Üretim iş yükleri için üç düğüm, dayanıklı bir havuz için pratik minimumdur — iki düğüm, tek bir arızanın kapasitenizi %50 düşürdüğü anlamına gelir; bu da yoğun yük altında performans SLA’nızı ihlal edebilir.