Load Balancing Rehberi

Load balancing, gelen istekleri birden fazla uygulama veya web sunucusu arasında dağıtma yöntemidir. Türkçede yük dengeleme ya da yük dağıtımı olarak da kullanılır. Amaç tek bir sunucuya daha fazla RAM eklemek değildir; uygulamanın birden fazla kopyasını çalıştırıp ziyaretçileri uygun kopyaya yönlendirmektir.

Bu yapı özellikle trafik artışının öngörülemediği, kesintinin maliyetli olduğu veya tek bir sunucu arızasının tüm siteyi etkilemesini istemediğiniz projelerde anlamlıdır. Yine de her web sitesi için zorunlu bir mimari değildir. Az trafikli bir kurumsal siteyi iki uygulama sunucusuna bölmek, bakım maliyetini ve hata ihtimalini gereksiz yere artırabilir.

Ben load balancing’i “sunucu sayısını artırma”dan çok, uygulamayı tek makineden bağımsız çalıştırabilme işi olarak görüyorum.

Load balancing nasıl çalışır?

En yaygın web mimarisinde ziyaretçi önce bir load balancer ile konuşur. Load balancer isteği arka taraftaki sunuculardan birine iletir; yanıtı da kullanıcıya geri döner.

Ziyaretçi
    │
    ▼
Nginx load balancer
    │
    ├── Uygulama sunucusu 1
    ├── Uygulama sunucusu 2
    └── Uygulama sunucusu 3
             │
             ▼
     Paylaşılan veritabanı / oturum / dosya altyapısı

Nginx burada reverse proxy olarak çalışır. Ziyaretçi uygulama sunucularının özel IP adreslerini bilmez; alan adı Nginx’e gider. Nginx de arka uçtaki upstream grubundan bir sunucu seçer.

Bu sayede iki temel kazanım sağlanır:

• Uygulama sunucularından biri hizmet veremez hâle gelirse, sağlıklı olanlar istek almaya devam edebilir.
• Tek sunucunun kaldırabileceğinden fazla eşzamanlı iş yükü birden çok sunucuya yayılabilir.

Ancak yük dengeleyici her sorunu çözmez. Veritabanı yavaşsa, üçüncü taraf ödeme servisi yanıt vermiyorsa veya uygulama tüm sunucularda aynı hatayı üretiyorsa istekleri bölmek tek başına çözüm değildir.

Önce uygulamayı yatay çalışmaya hazır hale getirin

İki web sunucusunun aynı siteyi sunması için yalnızca aynı kodun kopyalanması yetmez. Kullanıcının hangi sunucuya gittiğinden bağımsız olarak aynı sonucu görmesi gerekir.

Dosyalar

Tema, uygulama kodu ve statik dosyalar her node’da aynı sürümde olmalıdır. Bunun için sürüm kontrollü bir dağıtım süreci kullanmak, elle FTP ile tek tek dosya kopyalamaktan daha güvenlidir.

Kullanıcıların yüklediği dosyalar ise ayrı bir konudur. Bir kullanıcı fotoğrafı yalnızca birinci sunucunun diskine yazılırsa, sonraki isteği ikinci sunucuya düştüğünde dosya bulunamayabilir. Bu tür dosyalar için ortak depolama, nesne depolama veya dikkatle yönetilen bir senkronizasyon katmanı gerekir. Çalışan sistemde anlık rsync kopyalamak, çakışma ve gecikme oluşturabileceği için tek başına sağlam bir mimari sayılmaz.

Oturumlar

PHP veya uygulama oturumları her sunucunun yerel diskinde tutuluyorsa kullanıcı her istekte farklı bir sunucuya düştüğünde oturumdan çıkmış görünebilir. En sağlıklı yaklaşım, oturumları Redis veya veritabanı gibi ortak bir depoda saklamaktır. İmzalı, sunucusuz cookie tabanlı oturumlar da uygulamanın güvenlik modeline uygunsa bir seçenektir.

Sticky session yaklaşımı, aynı kullanıcıyı bir süre aynı arka uca göndererek sorunu gizleyebilir. Ancak sunucu devre dışı kalırsa oturum yine kaybolabilir; yük dağılımını da bozabilir. Bu yüzden mümkün olduğunda oturum durumunu paylaşmak daha dayanıklı bir çözümdür.

Veritabanı ve arka plan işleri

Birden fazla uygulama sunucusu çoğu zaman aynı veritabanına bağlanır. Böylece web katmanı yatay ölçeklenirken veritabanı ayrı bir darboğaz veya tek hata noktası hâline gelebilir. Bağlantı sınırları, ağır sorgular, indeksler, yedekleme ve yüksek erişilebilirlik planı bu nedenle ayrıca değerlendirilmelidir.

Zamanlanmış görevler de dikkat ister. Her sunucuda aynı cron görevi çalışırsa e-posta iki kez gönderilebilir veya veri iki kez işlenebilir. Cron işlerini tek bir sunucuda çalıştırmak ya da dağıtık kilit mekanizması kullanmak gerekir.

Nginx ile basit bir upstream tanımı

Aşağıdaki örnekte Nginx, 10.0.0.11 ve 10.0.0.12 adreslerindeki iki uygulama sunucusuna istek yönlendiriyor. Bu IP’ler yalnızca özel ağ örneğidir; gerçek ortamda sunucularınızı ve portunuzu kullanmalısınız. upstream tanımı http bağlamında yer alır; bir server bloğunun içine yazılmaz.

upstream uygulama_sunuculari {
    least_conn;

    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name siteadi.com www.siteadi.com;

    location / {
        proxy_pass http://uygulama_sunuculari;
        proxy_http_version 1.1;

        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 yapıdaki least_conn, yeni isteği aktif bağlantısı daha az olan sunucuya vermeyi dener. Uygulama istek süreleri çok değişkense, basit sırayla dağıtıma göre daha dengeli sonuç verebilir. Nginx’in varsayılan upstream yöntemi ise ağırlıklı round robin’dir: sunucular eşit ağırlıktaysa istekler sırayla paylaştırılır.

Sunucuların kapasitesi farklıysa weight parametresi kullanılabilir. Daha güçlü sunucuya daha yüksek ağırlık vermek mümkündür. Aynı istemciyi IP adresine göre tutarlı biçimde yönlendirmek için ip_hash vardır; fakat NAT arkasındaki çok sayıda kullanıcı aynı dış IP’yi paylaşabileceği için bu yöntemi performans çözümü olarak görmek doğru değildir.

Örnekteki max_fails ve fail_timeout, arka uca bağlanma denemelerinde hata görülürse Nginx’in o sunucuyu geçici olarak kullanmamasına yardımcı olan pasif bir mekanizmadır. Uygulamanın kendi sağlık uç noktasıyla düzenli aktif kontrol, daha kapsamlı gözlemleme ve uyarı tasarımı ise ayrıca kurulmalıdır.

Proxy başlıkları neden önemlidir?

Nginx arada olduğunda uygulama gelen isteği load balancer’dan gelmiş görür. Host, istemci IP’si ve asıl protokol bilgisi doğru iletilmezse uygulama yanlış URL oluşturabilir, HTTPS yönlendirme döngüsüne girebilir veya güvenlik kayıtlarında gerçek ziyaretçi IP’si görünmeyebilir.

Bu nedenle örnekteki proxy başlıkları yer alıyor. Uygulama tarafında da yalnızca kendi proxy’nizden gelen başlıklara güvenecek şekilde yapılandırma yapılmalıdır. İnternete açık bir uygulamanın, herhangi bir ziyaretçinin gönderdiği X-Forwarded-For başlığını sorgusuz gerçek IP kabul etmesi güvenli değildir.

HTTPS sonlandırmasını Nginx üzerinde yapacaksanız 443 dinleyen ayrı bir server bloğu, sertifika ayarları ve HTTP’den HTTPS’e yönlendirme gerekir. Bu ayrıntıları örnekte bilerek kısa tuttum; sertifika dosya yollarını ve TLS politikasını kopyala-yapıştır bir blokla genellemek doğru olmaz.

Sağlık, hata toleransı ve yüksek erişilebilirlik

İki uygulama sunucusu kullanmak, tek başına yüksek erişilebilirlik anlamına gelmez. Nginx yalnızca bir makinede çalışıyorsa, bu makinenin veya önündeki ağ bağlantısının kesilmesi hâlâ tüm giriş trafiğini durdurabilir.

Gerçekten kesintiye dayanıklı bir tasarımda load balancer katmanının da yedeği veya yönetilen bir karşılığı bulunur. Sanal IP, birden çok load balancer, L4/L7 hizmeti, DNS yönlendirmesi ve sağlık kontrolleri; ihtiyaca göre farklı seçeneklerdir. Hangi yöntemin uygun olduğu trafik miktarı, RTO/RPO hedefi, bütçe ve operasyon ekibinin yönetebileceği karmaşıklığa bağlıdır.

Öte yandan bir node’u kapatmadan önce trafik dışına almak da planın parçası olmalı. Uygulamayı güncelleyeceğiniz sunucuyu upstream tanımında down durumuna alıp yapılandırmayı doğrulayarak yeniden yüklemek, yeni isteklerin o node’a gitmesini durdurur. Ardından mevcut isteklerin tamamlanması için uygulamanın yapısına uygun bir bekleme süresi uygulanabilir.

nginx -t
systemctl reload nginx

Komutların çalışması, sunucuda Nginx’in hangi servis yöneticisiyle kurulduğuna ve yetkilerinize bağlıdır. Canlı ortamda doğrudan değişiklik yapmak yerine aynı yapılandırmayı önce test ortamında denemek daha sağlıklıdır.

Hangi durumda load balancing kullanmalısınız?

Şu durumlar yük dengelemeyi gündeme getirir:

• Tek uygulama sunucusunun CPU, bellek veya bağlantı sınırına düzenli olarak ulaşması,
• Kampanya, bilet satışı veya yoğun içerik anlarında ani trafik artışı,
• Uygulama sunucusu bakımı sırasında sitenin erişilebilir kalması ihtiyacı,
• Tek sunucu arızasının kabul edilemez olduğu kritik iş süreçleri.

İlk adım her zaman ikinci sunucu açmak olmayabilir. Sorgu optimizasyonu, sayfa önbelleği, CDN, kuyruk sistemi veya daha uygun tekil sunucu kaynakları daha basit ve ekonomik çözüm olabilir. Sorunun hangi katmanda olduğunu ölçmeden load balancer eklemek, mimariyi yalnızca karmaşıklaştırır.

Sunucu nedir? yazısında temel altyapı bileşenlerini ayrı ele almıştık. Load balancing bu bileşenlerin yerine geçen bir ürün değil; uygulamanızı doğru tasarladıysanız ölçeklenebilirlik ve süreklilik sağlayan bir katmandır.