Load Balancer Nedir? Nginx ile Yük Dengeleme Nasıl Kurulur?

Load balancer nedir ve tam olarak ne işe yarar?

Load balancer (yük dengeleyici), gelen istekleri tek bir sunucuya yığmak yerine birden fazla arka uç sunucusuna paylaştıran ara katmandır. Amacı, hiçbir sunucunun tek başına boğulmaması, bir sunucu çöktüğünde trafiğin sağlam olanlara akması ve ziyaretçinin bu değişikliği hiç fark etmemesidir.

Basit bir benzetme yapalım: Kalabalık bir bankada tek gişe varsa kuyruk uzar, gişe memuru hastalanırsa da işlem tamamen durur. Ancak girişte bir görevli müşterileri boş gişelere yönlendirirse hem bekleme süresi kısalır hem de bir gişenin kapanması işi durdurmaz. Load balancer, web trafiği için bu görevlinin rolünü üstlenir.

Bu yazıda yük dengelemenin mantığını, L4 ile L7 farkını, Nginx'in resmi dokümanında geçen algoritmaları ve gerçek bir upstream yapılandırmasını adım adım anlatıyoruz. Biz Talha Aslan ve ekibi olarak dijital pazarlama ve web tarafında çalışıyoruz; hosting firması değiliz. Bu yüzden teknik ayrıntıları Nginx'in kendi belgelerine dayandırıyor, emin olmadığımız hiçbir varsayılan değeri yazmıyoruz.

Yük dengeleme bir web sitesine hangi faydaları sağlar?

Yük dengelemenin faydası yalnızca hız değildir. Asıl kazanç, sitenin tek bir makineye bağımlı olmaktan kurtulmasıdır. Özellikle kampanya dönemlerinde trafiği birden artan e-ticaret siteleri için bu fark doğrudan ciroya yansır.

• Trafik dağıtımı: İstekler birden fazla sunucuya yayılır, böylece tek bir makinenin işlemcisi ya da belleği darboğaz olmaz.
• Yüksek erişilebilirlik: Bir arka uç sunucusu yanıt vermezse load balancer onu devreden çıkarır ve trafiği diğerlerine aktarır.
• Kesintisiz bakım: Bir sunucuyu güncellemek için onu havuzdan geçici olarak çıkarırsınız; site bu sırada diğer sunucularla çalışmaya devam eder.
• Yatay ölçekleme: Daha güçlü tek bir makine almak yerine havuza yeni sunucu eklersiniz.
• Merkezi giriş noktası: SSL sertifikası, başlık düzenlemesi ve erişim kayıtları tek bir katmanda toplanır.

Öte yandan yük dengeleme, yavaş bir uygulamayı tek başına hızlandırmaz. Sayfa, veritabanı sorgusu yüzünden üç saniyede açılıyorsa, aynı sorguyu üç sunucuda çalıştırmak her ziyaretçi için süreyi kısaltmaz. Bu nedenle önce sunucu kaynaklı yavaşlık nedenlerini elemenizi, ardından ölçekleme kararını vermenizi öneriyoruz.

Load balancer ile reverse proxy arasındaki fark nedir?

Bu iki kavram sık sık karışır, çünkü Nginx ikisini de aynı yazılımla yapar. Reverse proxy, istemci ile arka uç arasında duran ve istekleri arka uca ileten ara sunucudur. Load balancer ise bu iletme işini birden fazla hedef arasında bir kurala göre paylaştırır.

Yani her load balancer pratikte bir reverse proxy gibi çalışır; ancak her reverse proxy yük dengelemez. Tek bir Node.js uygulamasının önüne Nginx koyup SSL ve önbellek işini ona bırakıyorsanız bu bir reverse proxy kurulumudur. Aynı uygulamanın üç kopyasını çalıştırıp Nginx'in istekleri bunlar arasında dağıtmasını istiyorsanız artık yük dengelemeden söz ederiz.

Nginx'in temel kurulumunu ve tek hedefli reverse proxy ayarlarını bu partideki ayrı yazılarımızda ele alıyoruz; burada aynı adımları tekrar etmiyoruz. Bu yazıda Nginx'in sunucunuzda kurulu ve çalışır durumda olduğunu varsayıyoruz. Odak noktamız, upstream bloğu ile birden fazla sunucuyu nasıl yöneteceğiniz.

L4 ve L7 load balancer arasındaki fark ne?

Yük dengeleyiciler, trafiğe ağ katmanlarının hangi seviyesinden baktıklarına göre ikiye ayrılır. L4 (taşıma katmanı) dengeleyici yalnızca IP adresi ve port gibi bağlantı bilgilerini görür. L7 (uygulama katmanı) dengeleyici ise HTTP isteğinin içine bakar: adres yolu, başlıklar, çerezler ve alan adı onun karar verirken kullandığı verilerdir.

Web siteleri için çoğu zaman L7 doğru seçimdir, çünkü yönlendirme kararını içeriğe göre verebilirsiniz. Nginx'in resmi TCP ve UDP yük dengeleme rehberi, L4 tarafının stream bağlamında ayrı bir yapılandırmayla çalıştığını belirtir. Açık kaynak Nginx'te bu modül derleme sırasında etkinleştirilmeli ya da dinamik modül olarak yüklenmeli; dağıtımınızın paketinde hazır gelip gelmediğini kontrol edin.

Nginx hangi yük dengeleme algoritmalarını destekler?

Nginx'in resmi yük dengeleme belgesi ve upstream modülü sayfası, açık kaynak sürümde kullanabileceğiniz yöntemleri net biçimde listeler. Hiçbir yöntem belirtmezseniz Nginx varsayılan olarak round robin kullanır.

1. Round robin (varsayılan): İstekleri sunuculara sırayla dağıtır. Ayrıca weight parametresiyle güçlü sunucuya daha fazla pay verebilirsiniz.
2. least_conn: Yeni isteği o anda en az aktif bağlantısı olan sunucuya gönderir. Uzun süren isteklerde dengeyi daha iyi kurar.
3. ip_hash: İstemcinin IP adresinden bir anahtar üretir; aynı istemci, sunucu ayakta olduğu sürece hep aynı sunucuya düşer.
4. hash: Anahtarı siz seçersiniz (örneğin istek adresi). consistent parametresi eklerseniz havuza sunucu ekleyip çıkardığınızda daha az anahtar yer değiştirir.
5. random: Sunucuyu rastgele seçer. two parametresiyle önce iki aday seçip bunlardan daha az yüklü olanı alır.

Belgede geçen least_time yöntemi ise yanıt süresine bakar ve ticari NGINX Plus aboneliğine aittir. Dolayısıyla açık kaynak bir kurulumda bu yönergeyi yazarsanız yapılandırma testi hata verir. Kısacası kullanacağınız her yönergeyi, sürümünüzle birlikte resmi sayfada kontrol etmeniz en güvenli yoldur.

Hangi algoritmayı ne zaman seçmelisiniz?

Algoritma seçimi, uygulamanızın nasıl çalıştığına bağlıdır. Sunucularınız aynı donanıma sahipse ve istekler kısa sürüyorsa round robin çoğu zaman yeterlidir. Kurulumu en basit yöntem budur ve beklenmedik davranış üretmez.

Öte yandan isteklerin süresi çok farklıysa, örneğin bir kısmı anında yanıt verirken bir kısmı rapor üretip saniyelerce sürüyorsa, least_conn daha adil bir dağılım sağlar. Çünkü sıraya değil, sunucunun o anki yüküne bakar. Dosya yükleme, uzun API çağrıları ve WebSocket bağlantıları bu senaryoya örnektir.

ip_hash ise oturum verisini sunucunun kendi diskinde ya da belleğinde tutan eski uygulamalar için hızlı bir çözümdür. Ancak aynı ofisten, aynı mobil operatörden ya da aynı kurumsal ağdan gelen çok sayıda kullanıcı tek bir IP arkasında toplanabilir. Bu durumda bir sunucu aşırı yüklenirken diğerleri boş kalır.

hash yöntemini genellikle önbellek sunucularında görürsünüz: aynı adres hep aynı önbellek düğümüne giderse isabet oranı artar. Son olarak random two, birden fazla load balancer aynı arka uç havuzunu paylaştığında anlam kazanır; belgeler de bu yöntemi özellikle dağıtık ortamlar için önerir.

Nginx ile load balancer nasıl kurulur?

Nginx'te yük dengeleme iki parçadan oluşur: sunucu havuzunu tanımlayan upstream bloğu ve gelen istekleri bu havuza yollayan proxy_pass satırı. Aşağıdaki örnekte üç uygulama sunucusu var; IP adresleri yalnızca dokümantasyon için ayrılmış 192.0.2.x bloğundandır, kendi adreslerinizle değiştirin.

upstream app_backend {
    least_conn;
    server 192.0.2.11:8080 weight=2;
    server 192.0.2.12:8080;
    server 192.0.2.13:8080 backup;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://app_backend;
        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;
    }
}

Bu dosyayı genellikle /etc/nginx/conf.d/ altına ya da dağıtımınızın site dizinine koyarsınız. Ardından sudo nginx -t ile söz dizimini test edin, hata yoksa sudo systemctl reload nginx ile yapılandırmayı yeniden yükleyin. Reload komutu mevcut bağlantıları koparmadan yeni ayarları devreye alır.

Başlık satırları önemlidir. Bunlar olmadan arka uç uygulaması her isteği load balancer'ın IP adresinden geliyormuş gibi görür. Bu da kayıtları, güvenlik kurallarını ve IP tabanlı analizleri yanıltır.

Ağırlık, backup ve down parametreleri ne işe yarar?

Upstream bloğundaki her server satırı, davranışını değiştiren parametreler alabilir. Resmi upstream sayfasına göre en sık kullandığınız parametrelerin anlamı şöyledir:

• weight: Sunucunun dağıtımdaki payını belirler; varsayılan değer 1'dir. Belgedeki örnekte ağırlığı 3 olan sunucu, her beş yeni isteğin üçünü alır.
• backup: Sunucuyu yedek olarak işaretler. Ana sunucuların hepsi erişilemez olduğunda trafik bu sunucuya geçer.
• down: Sunucuyu kalıcı olarak devre dışı sayar. Bakım öncesinde sunucuyu havuzdan çıkarmanın en temiz yolu budur.
• max_conns: Sunucuya aynı anda açılabilecek bağlantı sayısını sınırlar; varsayılan 0, yani sınırsızdır.

Burada önemli bir kısıt var: Belgeye göre backup parametresini hash, ip_hash ve random yöntemleriyle birlikte kullanamazsınız. Bu nedenle yedek sunucu planlıyorsanız round robin ya da least_conn tercih etmelisiniz.

Bakım akışı pratikte şöyle işler: Önce güncelleyeceğiniz sunucuya down eklersiniz, yapılandırmayı test edip yeniden yüklersiniz. Sunucudaki aktif istekler bitince güncellemeyi yaparsınız, ardından down ifadesini kaldırıp tekrar yüklersiniz. Böylece ziyaretçi açısından site hiç kapanmamış olur.

Nginx sağlık kontrolünü nasıl yapar?

Açık kaynak Nginx pasif sağlık kontrolü yapar. Yani arka uca ayrıca test isteği göndermez; gerçek ziyaretçi isteklerinin sonucuna bakar. Belirli bir süre içinde yeterince başarısız deneme olursa sunucuyu geçici olarak devre dışı bırakır.

Bu davranışı iki parametre yönetir. max_fails, belirlenen süre içinde kaç başarısız denemenin sunucuyu erişilemez saydıracağını belirler; varsayılan değer 1'dir ve 0 yazarsanız sayım kapanır. fail_timeout ise hem bu denemelerin sayıldığı süreyi hem de sunucunun devre dışı kalacağı süreyi belirler; varsayılan değeri 10 saniyedir.

upstream app_backend {
    server 192.0.2.11:8080 max_fails=3 fail_timeout=30s;
    server 192.0.2.12:8080 max_fails=3 fail_timeout=30s;
}

Peki "başarısız deneme" tam olarak nedir? Bunu proxy_next_upstream yönergesi tanımlar. Bağlantı hatası ve zaman aşımı varsayılan olarak bu kapsama girer. İsterseniz belirli HTTP yanıt kodlarını da ekleyebilirsiniz, örneğin proxy_next_upstream error timeout http_502 http_503; satırıyla.

Dikkat etmeniz gereken bir nokta var: Nginx, POST gibi idempotent olmayan istekleri, istek arka uca bir kez ulaştıysa varsayılan olarak başka sunucuda tekrar denemez. Bu sayede bir sipariş formu iki kez işlenmez. Bu güvenlik ayarını gerçekten ne yaptığınızı bilmeden değiştirmeyin.

Aktif sağlık kontrolü neden ayrı bir konu?

Pasif kontrolün zayıf noktası şudur: Nginx bir sunucunun bozulduğunu ancak gerçek bir ziyaretçi o sunucuya düşüp hata aldığında anlar. Dolayısıyla en az bir kullanıcı hatayı görmüş olur. Aktif kontrol ise trafikten bağımsız olarak belirli aralıklarla her sunucuya test isteği yollar ve sorunu kullanıcıdan önce yakalar.

NGINX'in resmi HTTP sağlık kontrolü rehberi bu ayrımı açıkça yapar: Pasif kontrol hem açık kaynak Nginx'te hem de NGINX Plus'ta vardır; health_check yönergesiyle çalışan aktif kontrol ise yalnızca ticari NGINX Plus'a aittir. Rehbere göre aktif kontrol için upstream grubunda bir zone paylaşımlı bellek alanı da tanımlamanız gerekir.

Açık kaynak tarafta bu boşluğu kapatmanın birkaç yolu var. Uygulamanıza basit bir /health adresi ekleyip bunu dışarıdan bir izleme servisiyle düzenli olarak yoklayabilirsiniz. Ayrıca HAProxy gibi aktif kontrolü yerleşik sunan başka bir yük dengeleyiciyi değerlendirebilir ya da bulut sağlayıcınızın yönetilen yük dengeleyicisine geçebilirsiniz. Hangisinin doğru olduğu, bütçenize ve ekibinizin yönetim kapasitesine bağlıdır.

Oturum yapışkanlığı (sticky session) sorunu nedir?

Birçok uygulama, kullanıcının giriş bilgisini ya da sepetini sunucunun kendi belleğinde veya diskinde tutar. Tek sunucuda bu sorun çıkarmaz. Ancak load balancer devreye girdiğinde kullanıcının ilk isteği A sunucusuna, ikinci isteği B sunucusuna gidebilir. B sunucusu bu oturumu tanımadığı için kullanıcı aniden çıkış yapmış görünür ya da sepeti boşalır.

Bu soruna iki yaklaşım vardır. Birincisi oturum yapışkanlığıdır: Load balancer, aynı kullanıcıyı hep aynı sunucuya gönderir. Açık kaynak Nginx'te bunun en bilinen yolu ip_hash yöntemidir. Resmi upstream sayfası, çerez tabanlı sticky yönergesinin uzun süre yalnızca ticari abonelikte olduğunu, sayfadaki nota göre ise 1.29.6 sürümünden itibaren açık kaynak sürümde de yer aldığını belirtir. Sunucunuzdaki sürümü nginx -v ile kontrol etmeden bu yönergeye güvenmeyin.

Yapışkanlığın bedeli de var. Bir sunucu çöktüğünde ona bağlı kullanıcıların oturumu yine kaybolur. Üstelik yük, kullanıcı dağılımına göre dengesizleşebilir. Bu yüzden yapışkanlığı kalıcı çözüm değil, geçiş dönemi önlemi olarak görmenizi öneriyoruz.

Oturumları Redis ile paylaşmak neden daha sağlam bir çözüm?

İkinci yaklaşım, oturumu sunuculardan tamamen çıkarıp ortak bir depoya taşımaktır. Bu durumda hangi sunucu isteği alırsa alsın, oturum bilgisini aynı yerden okur. Arka uç sunucuları "durumsuz" hale gelir; herhangi birini kapatıp açmak kullanıcıyı etkilemez.

Ortak depo olarak en sık tercih edilen araç Redis'tir, çünkü bellekte çalışır ve çok hızlı yanıt verir. Laravel gibi çatılarda oturum sürücüsünü Redis olarak ayarlamak bir yapılandırma değişikliğidir. PHP tarafında da uygun eklentiyle oturum işleyicisini Redis'e yönlendirebilirsiniz. Redis'in önbellek ve oturum tarafındaki kullanımını Redis ve Memcached ile önbellekleme yazımızda ayrıntılı anlattık.

Bununla birlikte Redis'i tek bir makinede çalıştırırsanız bu kez Redis tek hata noktası olur. Kritik projelerde Redis için de yedekli bir yapı düşünmelisiniz. Aynı mantık dosya yüklemeleri için de geçerli: Kullanıcının yüklediği görsel yalnızca A sunucusunun diskinde kalırsa B sunucusu onu gösteremez. Bu nedenle yüklemeleri ortak bir depolama alanına ya da nesne depolamaya yazmak gerekir.

SSL sonlandırma load balancer üzerinde nasıl yapılır?

SSL sonlandırma, HTTPS bağlantısının şifresini load balancer üzerinde çözmek ve arka uca iç ağ üzerinden iletmek demektir. Böylece sertifikayı tek yerde yönetirsiniz; her uygulama sunucusuna ayrı ayrı kurmanız gerekmez. Sertifikanın temellerini SSL sertifikası rehberimizde bulabilirsiniz.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    location / {
        proxy_pass http://app_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Burada X-Forwarded-Proto başlığı kritik rol oynar. Arka uç, bağlantıyı düz HTTP olarak alır; bu başlık olmadan kullanıcının HTTPS ile geldiğini bilemez ve yönlendirme döngüsüne girebilir. Uygulama çatınızda güvenilir vekil ayarını da yalnızca load balancer'ın IP adresini kapsayacak şekilde yapın.

Load balancer ile arka uç arasındaki ağ ortak ya da güvenilmez bir ağsa, iç trafiği de şifrelemelisiniz. Bu durumda proxy_pass içinde https kullanırsınız. Kurulumdan sonra sertifika zincirini SSL sorgulama aracımızla kontrol etmeyi unutmayın.

Load balancer tek hata noktası olursa ne olur?

Yük dengeleme kurduktan sonra çoğu ekibin gözden kaçırdığı gerçek şudur: Arka uçta üç sunucunuz olsa bile önlerinde tek bir load balancer varsa, o makine çöktüğünde site tamamen kapanır. Yani tek hata noktasını ortadan kaldırmadınız, yalnızca yerini değiştirdiniz.

Bunun klasik çözümü, iki load balancer'ı aktif ve pasif olarak çalıştırmaktır. İki makine, aralarında paylaştıkları sanal bir IP adresini VRRP protokolüyle yönetir; keepalived bu iş için yaygın bir açık kaynak araçtır. Aktif makine düşerse sanal IP pasif olana geçer ve trafik kısa bir kesintiyle devam eder. Bu kurulum aynı ağ segmentinde iki makine gerektirdiği için her VPS sağlayıcısında desteklenmeyebilir; önce sağlayıcınıza sorun.

Daha büyük ölçekte DNS ve anycast tabanlı yöntemler de devreye girer; bunun mantığını anycast DNS yazımızda anlattık. Kurulumdan sonra alan adınızın doğru IP'ye çözümlendiğini DNS sorgulama aracıyla doğrulayabilirsiniz. Bu düşünce biçiminin genel adı N+1 yedekliliktir: İhtiyacınız olan kapasiteye en az bir yedek bileşen eklemek. Konuyu veri merkezi ölçeğinde ayrı bir yazıda inceliyoruz.

Bulut sağlayıcıların yük dengeleyicileri Nginx'ten nasıl farklı?

Büyük bulut sağlayıcıları, yönetilen yük dengeleyici hizmeti sunar. Bu hizmetlerde load balancer'ın kendi yedekliliğini, aktif sağlık kontrolünü ve çoğu zaman sertifika yenilemesini sağlayıcı üstlenir. Siz yalnızca kuralları tanımlarsınız.

Kendi Nginx load balancer'ınızı kurmanın avantajı ise tam kontrol ve öngörülebilir maliyettir. Yapılandırmanın her satırını görürsünüz, istediğiniz modülü eklersiniz ve tek bir sağlayıcıya bağımlı kalmazsınız. Dezavantajı, güncelleme, izleme ve yedeklilik sorumluluğunun tamamen sizde olmasıdır.

Seçim yaparken şu soruları sorun: Ekibinizde gece çıkan bir arızaya müdahale edecek biri var mı? Trafiğiniz ani sıçramalar yapıyor mu? Altyapınız zaten tek bir bulut sağlayıcıda mı duruyor? Bu soruların cevabı çoğunlukla "evet" ise yönetilen hizmet daha mantıklıdır. VPS, VDS ve bulut sunucu farkı yazımız bu kararın altyapı tarafını netleştirmenize yardım eder. Konteyner kullanıyorsanız Kubernetes ile Docker farkını da okuyun; Kubernetes kendi servis katmanında yük dağıtımı yapar.

Ne zaman tek sunucu yeter, load balancer gereksiz olur?

Dürüst olalım: Kurumsal tanıtım sitelerinin, blogların ve küçük e-ticaret mağazalarının büyük çoğunluğu iyi yapılandırılmış tek bir sunucuyla rahatça çalışır. Load balancer eklemek, sunucu sayısını, yapılandırma karmaşıklığını ve aylık maliyeti artırır. Bu yükü ancak gerçek bir ihtiyaç karşılığında almalısınız.

Tek sunucunun yeterli olduğu tipik durumlar şunlardır:

• Sunucunun işlemci ve bellek kullanımı yoğun saatlerde bile rahat bir seviyede kalıyorsa.
• Kısa bir planlı bakım kesintisi işinize ciddi zarar vermiyorsa.
• Darboğaz sunucu değil, optimize edilmemiş sorgular, büyük görseller ya da önbellek eksikliği ise.
• Uygulamanız oturumu ve dosyaları yerel diskte tutuyor ve bunu değiştirecek geliştirme bütçeniz yoksa.

Örneğin sayfa hızınız düşükse önce önbellekleme, görsel optimizasyonu ve kod iyileştirmesi çok daha ucuz bir kazanç sağlar. Hosting seçim rehberimiz de kaynak ihtiyacını doğru tahmin etmenize yardım eder. Load balancer, bu adımlar tükendiğinde ya da kesintisizlik iş için gerçekten kritik hale geldiğinde gündeme gelmelidir.

Bu kurulumu ne zaman kendiniz yapmamalısınız?

Nginx ile yük dengeleme kurmak teknik olarak zor değildir; zor olan, onu yıllarca güvenli ve güncel tutmaktır. Paylaşımlı hosting kullanıyorsanız zaten Nginx yapılandırmasına erişiminiz yoktur ve bu işi hosting sağlayıcınız yönetir. Yönetilen VPS paketlerinde de altyapı değişikliğini önce sağlayıcıyla konuşmanız gerekir.

Şu durumlarda işi hosting sağlayıcınıza ya da deneyimli bir sistem yöneticisine bırakmanızı öneriyoruz:

• Ekibinizde Linux sunucu yönetimi ve izleme konusunda deneyimli kimse yoksa.
• Site ödeme alıyor ve birkaç dakikalık kesinti bile ciddi kayıp yaratıyorsa.
• Veritabanı çoğaltma, ortak dosya depolama ve oturum taşıma gibi uygulama değişiklikleri de gerekiyorsa.
• Güvenlik duvarı, DDoS koruması ve kayıt yönetimi aynı anda planlanmalıysa.

Biz web tarafında uygulamanın yük dengelemeye hazır olmasını, yani oturum ve dosya yapısının durumsuz çalışmasını sağlarız. Altyapının işletilmesi ise sağlayıcınızın ya da sistem ekibinizin sorumluluğunda kalmalıdır. Özel yazılım geliştirme projelerinde bu ayrımı en baştan netleştiriyoruz.

Kurulumdan sonra neleri test etmelisiniz?

Yapılandırmayı yeniden yükleyip siteyi tarayıcıda açmak yeterli bir test değildir. Load balancer'ın asıl değeri, bir şeyler ters gittiğinde ortaya çıkar. Bu yüzden canlıya almadan önce arızayı bilerek taklit etmelisiniz.

1. Her arka uç sunucusuna geçici olarak farklı bir yanıt başlığı ekleyin ve isteklerin gerçekten dağıldığını doğrulayın.
2. Bir arka uç sunucusundaki uygulamayı durdurun; sitenin açılmaya devam ettiğini ve Nginx hata kaydında ilgili uyarıyı gördüğünüzü kontrol edin.
3. Giriş yapıp sepete ürün ekleyin, ardından birkaç sayfa gezin; oturumun kaybolmadığından emin olun.
4. Arka uç kayıtlarında ziyaretçinin gerçek IP adresinin göründüğünü doğrulayın.
5. HTTPS ile gelip HTTP ile yanıtlanan bir yönlendirme döngüsü olmadığını test edin.
6. Durdurduğunuz sunucuyu tekrar başlatın ve fail_timeout süresinden sonra havuza döndüğünü izleyin.

Bu testleri bir kontrol listesine dönüştürüp her büyük güncellemeden sonra tekrarlamanızı öneriyoruz. Ayrıca yük dengeleyici yapılandırma dosyalarınızı da yedekleme stratejinize dahil edin; sunucu çöktüğünde ilk ihtiyacınız olacak dosyalar bunlardır.

Load balancer kurarken en sık yapılan hatalar nelerdir?

Yük dengeleme kurulumlarındaki hataların çoğu Nginx'ten değil, uygulamanın yük dengelemeye hazır olmamasından kaynaklanır. Bu yüzden yapılandırma kadar uygulama tarafını da gözden geçirmelisiniz.

İlk sık hata, oturum ve dosyaları yerel diskte bırakmaktır; sonuç, rastgele çıkış yapan kullanıcılar ve kaybolan görsellerdir. İkincisi, X-Forwarded-For ve X-Forwarded-Proto başlıklarını unutmaktır. Bu durumda analizler ve güvenlik kuralları yanlış IP görür, HTTPS yönlendirmesi de döngüye girer. Üçüncüsü, zamanlanmış görevleri her sunucuda çalıştırmaktır. Örneğin aynı bülten gönderim görevi üç sunucuda birden tetiklenirse kullanıcılar üç e-posta alır.

Bir diğer hata, yeni sunucuya kodun eski sürümünü yüklemektir. Tüm sunucuların aynı sürümü çalıştırması için dağıtımı otomatikleştirmelisiniz. Son olarak load balancer'ın kendisini izlememek de yaygındır. Arka uçları izleyip önlerindeki tek makineyi unutmak, yukarıda anlattığımız tek hata noktası sorununu yeniden yaratır.

Yük dengeleme kararını nasıl vermelisiniz?

Özetle load balancer, trafiği dağıtarak hem kapasiteyi artıran hem de tek sunucu arızasını kullanıcıdan gizleyen bir katmandır. Nginx bu işi açık kaynak sürümde round robin, least_conn, ip_hash, hash ve random yöntemleriyle, pasif sağlık kontrolüyle birlikte sunar. Aktif sağlık kontrolü ise NGINX Plus tarafında kalır.

Karar sırası şöyle olmalı: Önce tek sunucunuzu ölçün ve optimize edin. Ardından uygulamanızı durumsuz hale getirin; oturumları Redis gibi ortak bir depoya, dosyaları ortak depolamaya taşıyın. Ancak bundan sonra load balancer ekleyin ve onun da yedeğini planlayın.

Web sitenizin altyapısı ile pazarlama hedeflerinin uyumlu ilerlemesini istiyorsanız web tasarım ve geliştirme sürecinde bu soruları birlikte ele alabiliriz. Biz uygulama tarafını yük dengelemeye hazır hale getiririz; altyapı işletimini ise hosting sağlayıcınızla birlikte planlarız.