Load Balancer Nedir? Health Check ve Sticky Session

Birden fazla web sunucusuna geçmeyi düşündüğünüzde ilk beklenti genellikle basittir: Gelen trafiği sunucular arasında paylaştırmak. Ancak kullanıcıların oturumdan düşmesi, alışveriş sepetlerinin boş görünmesi veya arızalı bir sunucuya istek gitmeye devam etmesi, yalnızca trafik dağıtımının yeterli olmadığını gösterir.

Bu nedenle “load balancer nedir health check” sorusunun yanıtı, tek bir cihazın görev tanımından daha geniştir. Load balancer istekleri seçer, health check uygun hedefleri belirler, sticky session ise oturum durumunun sunucular arasında nasıl davranacağını etkiler. Bu kararları üç parçayı birlikte düşünerek verebilirsiniz.

Load balancer nedir ve hangi sorunu çözer?

Load balancer, istemcilerden gelen ağ bağlantılarını veya HTTP isteklerini birden fazla arka uç sunucuya yönlendiren bileşendir. Arka uç, isteği gerçekten işleyen web sunucusu, uygulama sunucusu ya da servis anlamına gelir. Kullanıcı tek bir alan adı görür; arka planda ise istekler sunucu havuzundaki uygun hedeflere dağıtılır.

Tek sunuculu bir yapıda donanım arızası, bakım veya işlem kapasitesinin dolması doğrudan siteyi etkiler. Load balancer, havuzdaki sunuculardan biri kullanılamadığında diğer hedeflere yönlendirme yapabilir. Ayrıca yeni bir sunucuyu havuza eklemek, trafiği kademeli olarak yaymak veya bakım sırasında bir hedefi geçici olarak çıkarmak daha kolay hale gelir.

Bu yapı tek başına daha hızlı bir site garantisi vermez. Trafik dağıtıcının kendisi, ağ bağlantısı, veritabanı, dosya depolama veya uygulama kodu darboğaz olabilir. Sunucu sayısını artırmadan önce istek türlerini, oturum verisini, yükü ve ortak dosya ihtiyacını inceleyin.

L4 ve L7 dağıtım arasındaki fark

Katman 4 (L4) dağıtım, TCP veya UDP bağlantısı gibi ağ bilgileriyle karar verir. Genellikle daha az uygulama bilgisi kullanır ve protokol seviyesinde çalışır. Katman 7 (L7) dağıtım ise HTTP yöntemi, host adı, URL yolu veya çerez gibi uygulama katmanı verilerini değerlendirebilir.

Statik dosyaları bir hedef grubuna, API isteklerini başka bir gruba göndermek L7 kurallarıyla yapılabilir. TLS bağlantısını load balancer üzerinde açmadan yalnızca bağlantı bilgilerine göre geçirmek ise L4 veya TLS passthrough yaklaşımına daha yakındır. Seçim, yönlendirme ihtiyacınıza ve sertifika yönetiminin nerede yapılacağına bağlıdır.

Load balancer’ın önünde DNS, arkasında web sunucuları bulunabilir. DNS bir alan adını belirli bir IP adresine çözer; her HTTP isteğinin sağlıklı bir hedefe ulaşıp ulaşmadığını tek başına denetlemez. DNS yönlendirmesi ile load balancer health check mekanizmasını aynı görev gibi değerlendirmeyin.

Health check nedir, neyi gerçekten kontrol eder?

Health check, load balancer’ın arka uç sunuculara belirli aralıklarla gönderdiği sağlık denetimidir. Denetim başarılıysa hedef havuzda tutulur; başarısızlık belirli bir eşiği aşarsa hedef geçici olarak devre dışı bırakılır. Böylece normal kullanıcı istekleri, cevap veremeyen veya hatalı cevap üreten bir sunucuya gönderilmez.

Basit bir TCP kontrolü yalnızca portun bağlantı kabul ettiğini gösterir. HTTP kontrolü ise belirli bir URL’ye istek göndererek durum kodunu ve gerekirse yanıt içeriğini doğrular. Web sunucusu çalışıyor görünürken PHP-FPM, veritabanı veya uygulamanın kritik bağımlılığı bozulmuş olabilir. Bu durumda yalnızca TCP kontrolüne güvenmek, uygulama hazır değilken hedefi sağlıklı gösterebilir.

İyi bir sağlık uç noktası nasıl olmalı?

Sağlık uç noktası, uygulamanın trafik almaya hazır olup olmadığını hızlı ve öngörülebilir biçimde yanıtlamalıdır. Örneğin /healthz veya /ready gibi bir yol kullanılabilir. Bu adlar örnektir; uygulamanızın yönlendirme yapısına ve operasyon politikanıza göre farklı bir yol seçebilirsiniz.

İki farklı kontrolü ayırmak yararlıdır. Liveness, sürecin çalıştığını; readiness ise isteği karşılamak için gerekli bağımlılıkların hazır olduğunu anlatır. Load balancer çoğu web sitesi için readiness benzeri bir kontrol kullanır. Her kontrolde ağır rapor sorguları, tam sayfa üretimi veya dış servislere uzun beklemeli çağrılar çalıştırmak yeni bir yük oluşturabilir.

Veritabanını kontrol etmek gerekiyorsa salt okunur, küçük ve zaman aşımı olan bir sorgu tercih edin. Ödeme servisi gibi harici bir bağımlılık geçici olarak kullanılamıyorsa uygulamanızın trafik kabul politikasını önceden belirleyin. Her dış servisi health check’e eklemek, kısa süreli bir bağımlılık sorununda tüm sunucuların hatalı biçimde havuzdan çıkmasına neden olabilir.

Başarısızlık eşikleri neden önemlidir?

Tek bir başarısız istekte sunucuyu havuzdan çıkarmak, geçici ağ gecikmelerinde gereksiz yön değiştirmeye yol açabilir. Çok fazla başarısızlık beklemek ise arızalı hedefe daha uzun süre trafik gönderir. Interval, timeout, unhealthy threshold ve healthy threshold değerleri birlikte değerlendirilmelidir.

Örneğin 5 saniyelik aralıkla yapılan kontrollerde zaman aşımı 2 saniye olabilir; fakat bu yalnızca açıklayıcı bir örnektir. Gerçek değerleri ağ gecikmenizi, uygulamanın normal yanıt süresini ve hata toleransınızı ölçerek belirleyin. Değişiklikten sonra hedefin gerçekten havuza girip çıktığını ve kullanıcı isteklerinin davranışını gözlemleyin.

Teşhis ve dar kapsamlı düzeltme

Bir sunucu health check’te başarısız oluyorsa önce load balancer’ın kontrol adresinden ilgili hedefe erişip erişemediğini test edin. Ardından aynı URL’yi hedef sunucuda yerel olarak ve doğru Host başlığıyla çağırın. Böylece ağ, web sunucusu yönlendirmesi ve uygulama katmanı sorunlarını birbirinden ayırabilirsiniz.

curl -i --max-time 3 -H "Host: example.test" http://127.0.0.1/healthz

Bu komut yalnızca gözlem içindir; alan adını ve yolu kendi yapınıza göre değiştirin. Önkoşul olarak hedef sunucuda curl bulunmalı, yerel web sunucusu HTTP isteğini dinlemeli ve health check yolu tanımlı olmalıdır. Yanıt beklenen durum kodunu vermiyorsa önce health check yolunu ve web sunucusunun ilgili konum kuralını düzeltin; uygulamanın diğer ayarlarını aynı anda değiştirmeyin.

Düzeltme sonrasında üç noktayı doğrulayın: Hedef sunucudan beklenen durum kodu geliyor mu, load balancer hedefi healthy olarak işaretliyor mu ve gerçek bir kullanıcı isteği doğru yanıtı alıyor mu? Değişiklik veri veya yönlendirme kuralı içeriyorsa önce yapılandırma yedeği alın ve önceki dosyaya dönme adımını hazır tutun.

Sticky session nedir ve ne zaman gerekir?

Sticky session, aynı istemciyi sonraki isteklerde mümkün olduğunca aynı arka uç sunucuya yönlendirme yöntemidir. “Oturum yapışkanlığı” olarak da adlandırılır. Load balancer bunu kendi ürettiği bir çerez, uygulama çerezi, kaynak IP adresi veya benzeri bir yönlendirme anahtarıyla sağlayabilir.

Bu ihtiyaç genellikle oturum verisinin yalnızca kullanıcının ilk bağlandığı sunucuda tutulmasından doğar. Kullanıcı giriş yaptığında oturum birinci sunucunun yerel dosyasına yazılır; sonraki istek ikinci sunucuya giderse ikinci sunucu bu oturumu bulamayabilir. Kullanıcı yeniden giriş ekranına gönderilebilir veya sepeti boş görünebilir.

Sticky session bu sorunu hızlıca azaltır, ancak sorunun veri mimarisini ortadan kaldırmaz. Yapışkan yönlendirme nedeniyle bazı sunucular diğerlerinden daha fazla oturum taşıyabilir. Sunucu arızalanırsa o sunucuya bağlı kullanıcıların oturumu yine kaybolabilir. Ayrıca otomatik ölçekleme, bakım ve yük dağılımı daha az esnek hale gelir.

Çerez temelli ve IP temelli yapışkanlık

Çerez temelli yöntemde load balancer veya uygulama, istemciye hangi hedefe bağlanacağını belirleyen bir çerez verir. Bu yöntem, aynı ortak ağ arkasındaki çok sayıda kullanıcının tek bir kaynak IP olarak görünmesi sorununu azaltır. Çerez silinir, süresi dolarsa veya istemci farklı bir politika uygularsa yapışkanlık bozulabilir.

IP temelli yöntemde kaynak IP, hedef seçimi için anahtar olarak kullanılır. Mobil ağlar, kurumsal proxy’ler ve NAT kullanan kullanıcılar nedeniyle aynı IP birden fazla kişiyi temsil edebilir. IP değiştiğinde kullanıcı başka sunucuya gidebilir. Bu nedenle IP yapışkanlığını oturum güvenliği veya veri tutarlılığı için tek başına güvenilir bir çözüm saymayın.

Sticky session yerine ortak oturum depolama

Daha ölçeklenebilir yaklaşım, oturum verisini tüm uygulama sunucularının erişebildiği ortak bir depoya taşımaktır. Redis, Memcached veya paylaşımlı veritabanı bu amaçla kullanılabilir; doğru seçim veri kalıcılığı, erişim süresi ve kayıp toleransına bağlıdır. Oturum verisinin hangi bileşende tutulacağını belirlerken erişim yetkilerini ve silinme politikasını da tanımlayın.

WordPress, WooCommerce veya özel bir PHP uygulamasında dosya tabanlı oturumlar sunucuya özgü kalıyorsa, önce uygulamanın oturum ve önbellek davranışını doğrulayın. Ortak depolama yapılandırmasına geçmeden önce mevcut oturumların nasıl sonlandırılacağını ve bağlantı bilgilerinin nasıl geri alınacağını planlayın. Yapılandırma değişikliği öncesinde ilgili dosyaların ve verilerin yedeğini alın.

Bu konu için PHP oturum ve önbellek depolama seçeneklerini karşılaştıran PHP Session ve Cache Depolamasını Doğru Seçmek yazısı, dosya, Redis ve Memcached arasındaki farkları değerlendirmenize yardımcı olabilir. İçeriğinizin gerektirdiği depolama seçimini uygulama belgeleri ve mevcut hosting sınırlarıyla birlikte kontrol edin.

TLS sonlandırma ve istek yönlendirme kararı

TLS, istemci ile servis arasındaki bağlantıyı şifreleyen protokoldür. TLS sonlandırma, şifreli bağlantının bir noktada açılması ve HTTP isteğinin sonraki bileşene iletilmesi anlamına gelir. Bu işlem load balancer üzerinde yapılırsa sertifikalar burada yönetilir; arka uç sunuculara HTTP veya yeniden şifrelenmiş HTTPS bağlantısı kurulabilir.

Load balancer üzerinde sonlandırmanın avantajı, sertifika yenileme ve L7 yönlendirme kurallarını tek noktada yönetmektir. Ancak load balancer ile arka uç arasındaki ağın güvenilirliği, iç ağ politikası ve hassas veri gereksinimleri ayrıca değerlendirilmelidir. İç bağlantıda da TLS kullanacaksanız sertifika doğrulaması, isim çözümleme ve güven zinciri planlanmalıdır.

Uygulamanın istemci IP’si, protokolü ve host bilgisi için iletilen başlıkları doğru işlediğini doğrulayın. Güvenilmeyen istemcilerin bu başlıkları doğrudan taklit etmesine izin vermeyin; yalnızca güvenilir proxy katmanından gelen bilgileri kabul edecek şekilde web sunucusunu ve uygulamayı yapılandırın.

Web sunucuları ve iş yükü nasıl ayrılmalı?

Load balancer web isteklerini dağıtır; fakat arka plandaki her iş aynı kaynağı tüketmez. PHP-FPM web işçileri, gelen HTTP isteğini işler. CLI ile çalışan cron görevleri, kuyruk tüketicileri veya planlanmış komutlar ise HTTP çağrısı yapmadıkları sürece PHP-FPM işçisi tüketmez. Bu iki işçi türünü aynı kapasite hesabında karıştırmak yanlış teşhise yol açar.

Örneğin health check yanıtı hızlı olsa bile uzun süren kuyruk işleri CPU, bellek veya veritabanı bağlantılarını tüketebilir. Bu durumda load balancer arızalı değildir; web ve arka plan iş yükleri aynı sunucuda kaynak rekabeti yaşıyor olabilir. PHP Session ve Queue İşçileri İçin Ayrı PHP-FPM İşlem Havuzu Kurmak başlığındaki ayrım, web istekleriyle kuyruk görevlerini ayrı kaynak politikalarıyla ele almanız için ilgili bir sonraki okumadır.

Teşhis sırasında PHP-FPM durumunu, web sunucusu erişim günlüklerini, uygulama hata günlüklerini ve kuyruk çalışma durumunu ayrı inceleyin. Health check için uygulama süreçlerinin hazır olması gerekir; ancak kuyruk işçisinin çalışması, tek başına web hedefinin healthy veya unhealthy olduğunu belirlememelidir.

Load balancer kurulumu öncesi test ve gözlem

İki sunucuyu üretim trafiğine almadan önce hangi hedefin hangi istekleri karşılayacağını yazılı hale getirin. Statik dosyaların her sunucuda aynı olup olmadığını, yüklemelerin nerede tutulduğunu, oturumun nasıl paylaşıldığını ve veritabanı bağlantılarının nasıl yönetildiğini kontrol edin. Bir sunucuda oluşan dosya diğerinde bulunmuyorsa, yalnızca trafik dağıtmak tutarsız yanıt üretebilir.

Ardından kontrollü bir kapasite testi yapın. Tek bir sanal kullanıcıyla yapılan istek testi, gerçek eşzamanlılık ve kuyruk davranışını göstermez. Trafik patlamasından Önce Load Test Yapmak: k6, JMeter ve Locust ile Kapasite Ölçme Rehberi başlığındaki yaklaşımları inceleyerek test senaryosunu oturum açma, ürün görüntüleme, sepet ve ödeme gibi iş akışlarına göre düzenleyebilirsiniz.

Testte yalnızca ortalama yanıt süresini izlemeyin. Hata oranı, 95. veya 99. yüzdelik yanıt süresi, health check başarısızlıkları, bağlantı havuzları, CPU, bellek ve veritabanı gecikmesini birlikte değerlendirin. Sayısal eşikleri kendi uygulamanızın normal çalışma ölçümlerinden türetin; burada evrensel bir değer yoktur.

Arızalı hedefi kontrollü çıkarma

Bir hedefi bakım için devre dışı bırakmadan önce yeni bağlantı kabulünü durdurma veya draining özelliği varsa bunu kullanın. Draining, mevcut bağlantıların tamamlanmasına izin verirken yeni istekleri başka hedeflere yönlendirmektir. Sticky session kullanıyorsanız, mevcut çerezlerin ve uzun süreli bağlantıların nasıl davranacağını ayrıca test edin.

Ardından tek hedefli bir arıza senaryosu uygulayın. Hedefin health check’te başarısız olmasını, havuzdan çıkarılmasını ve kalan sunucunun isteklere cevap vermesini gözlemleyin. Geri dönüşte hedefi doğrudan tam trafikle açmak yerine önce health check sonucunu, uygulama günlüklerini ve kaynak kullanımını kontrol edin.

Sık Sorulan Sorular

Load balancer tek sunucu için gerekli midir?

Tek sunucuda genellikle ek bir dağıtım katmanı şart değildir. Ancak TLS sonlandırma, merkezi yönlendirme veya ileride yapılacak yatay ölçekleme için kullanılabilir. Ek bileşenin bakım ve hata alanını da hesaba katın.

Health check yanıtı hangi HTTP durum kodunu vermeli?

Çoğu yapılandırmada hazır hedef için 2xx aralığında bir yanıt kullanılır. Kesin kabul edilen kod, load balancer ürününün ayarlarına ve uygulamanızın readiness politikasına bağlıdır. Yanıt gövdesinden çok durum kodu ve zaman aşımı davranışı önemlidir.

Sticky session güvenlik özelliği midir?

Hayır. Sticky session yönlendirme davranışıdır; kimlik doğrulama, yetkilendirme veya oturum çerezinin korunması yerine geçmez. Oturum çerezlerini güvenli niteliklerle üretmek ve sunucu tarafı oturum politikasını ayrıca uygulamak gerekir.

Bir health check adresini herkese açabilir miyim?

Açmak zorunda değilsiniz. Load balancer’ın kontrol kaynaklarından erişime izin verip genel internet erişimini sınırlandırabilirsiniz. Dönen yanıt, altyapı bileşenleri veya hata ayrıntıları hakkında gereksiz bilgi vermemelidir.

Uygulanabilir kontrol listesi

• Arka uç sunucuların görevini, ortak veri ihtiyacını ve trafik akışını yazılı olarak belirleyin.
• TCP kontrolü ile uygulamanın hazır olma kontrolünü birbirinden ayırın.
• Health check yolunun hızlı, düşük maliyetli ve gerekli bağımlılıklarla sınırlı olduğunu doğrulayın.
• Kontrol uç noktasına erişimi yalnızca güvenilir load balancer kaynaklarıyla sınırlandırın.
• Oturum verisinin yerel dosyada mı, ortak depoda mı tutulduğunu doğrulayın.
• Sticky session kullanıyorsanız sunucu arızasında oturum kaybı ve yük dengesizliği riskini belgelendirin.
• TLS sertifikalarının nerede sonlandırılacağını ve arka uç bağlantısının nasıl korunacağını kararlaştırın.
• PHP-FPM web işçilerini CLI cron ve kuyruk işçilerinden ayrı izleyin.
• Bir hedefi draining ile çıkarma, health check ile geri alma ve önceki yapılandırmaya dönme adımlarını test edin.
• Gerçek kullanıcı akışlarını içeren kapasite ve arıza testlerini üretim öncesinde tekrarlayın.

İlk sonraki adımınız, mevcut sunuculardan birinde yalnızca salt okunur bir readiness uç noktası hazırlamak ve bunu yerel istekle doğrulamak olabilir. Ardından load balancer üzerinde tek hedefli bir test yapın; health check sonucu, oturum davranışı ve geri dönüş adımı netleşmeden tüm trafiği yeni mimariye taşımayın.