Load balancer arkasında oturum sürekliliği nasıl sağlanır?

Load balancer arkasında çalışan bir uygulamada kullanıcı deneyiminin kesintisiz kalması, yalnızca trafiği birden fazla sunucuya dağıtmakla sağlanmaz. Kullanıcının giriş yaptıktan sonra sepetini, panel oturumunu, form ilerlemesini veya yetki bilgisini kaybetmemesi için oturum bilgisinin nasıl tutulduğu doğru tasarlanmalıdır. Aksi halde aynı kullanıcı her istekte farklı bir sunucuya yönlenebilir ve uygulama tarafında “oturum düştü”, “yeniden giriş yapın” veya “sepet boşaldı” gibi sorunlar ortaya çıkabilir.

Oturum sürekliliği neden bozulur?

Tek sunuculu yapılarda oturum bilgisi çoğu zaman yerel dosyada, bellek üzerinde veya uygulama sunucusunun kendi geçici alanında tutulur. Load balancer devreye girdiğinde ise aynı kullanıcıdan gelen istekler farklı arka uç sunuculara gidebilir. İlk istekte oturum A sunucusunda oluşmuşsa, ikinci isteğin B sunucusuna düşmesi durumunda B sunucusu bu oturumu tanımaz.

Bu durum özellikle e-ticaret, üyelik sistemi, yönetim paneli, ödeme adımı ve çok adımlı formlarda kritik hale gelir. Kurumsal bir hosting mimarisinde amaç sadece yüksek erişilebilirlik değil, aynı zamanda tutarlı kullanıcı deneyimidir.

Oturum sürekliliği için temel yaklaşımlar

1. Sticky session kullanmak

Sticky session, aynı kullanıcıyı belirli bir süre boyunca aynı arka uç sunucuya yönlendirme yöntemidir. Load balancer genellikle cookie, kaynak IP adresi veya özel bir yönlendirme anahtarı kullanarak bu eşleştirmeyi yapar.

Bu yöntem hızlı uygulanabilir ve mevcut uygulama kodunda büyük değişiklik gerektirmeyebilir. Ancak dikkat edilmesi gereken bir nokta vardır: Kullanıcının bağlı olduğu sunucu devre dışı kalırsa o sunucuda tutulan yerel oturum bilgisi de kaybolabilir. Bu nedenle sticky session, tek başına yüksek dayanıklılık çözümü olarak değerlendirilmemelidir.

2. Merkezi oturum deposu kullanmak

Daha ölçeklenebilir yaklaşım, oturum bilgisini uygulama sunucularının dışında ortak bir sistemde tutmaktır. Redis, Memcached, veritabanı tabanlı session store veya yönetilen cache servisleri bu amaçla kullanılabilir.

Bu yapıda kullanıcı hangi sunucuya giderse gitsin oturum bilgisi aynı merkezi depodan okunur. Böylece arka uç sunucu sayısı artırıldığında uygulama daha öngörülebilir çalışır. Özellikle yatay ölçekleme yapılan ortamlarda tercih edilmesi gereken yöntem çoğu zaman budur.

3. Stateless mimariye geçmek

Modern uygulamalarda JWT veya benzeri token tabanlı yaklaşımlar kullanılarak sunucu tarafında oturum tutma ihtiyacı azaltılabilir. Kullanıcının kimlik ve yetki bilgisi imzalı token içinde taşınır; uygulama her istekte bu token’ı doğrular.

Bu model ölçeklenebilirlik açısından güçlüdür fakat token süresi, yenileme mekanizması, iptal senaryosu ve güvenli saklama yöntemi doğru tasarlanmalıdır. Özellikle tarayıcı tarafında token saklama tercihleri XSS ve CSRF riskleriyle birlikte değerlendirilmelidir.

Sticky session ne zaman tercih edilmeli?

Sticky session, kısa vadeli geçiş projelerinde veya uygulamanın oturum mimarisini hemen değiştirmek mümkün değilse pratik bir çözümdür. Örneğin eski bir PHP uygulaması yerel session dosyalarını kullanıyorsa ve kısa sürede çoklu sunucuya geçilecekse, sticky session kesintiyi azaltabilir.

Ancak uzun vadede uygulamanın belirli bir sunucuya bağımlı kalması operasyonel risk oluşturur. Bakım, otomatik ölçekleme, sunucu arızası ve dağıtım süreçlerinde kullanıcıların oturum kaybetme ihtimali artar. Bu nedenle sticky session kullanılıyorsa bile merkezi oturum deposuna geçiş planı yapılmalıdır.

Merkezi oturum deposunda dikkat edilmesi gerekenler

Merkezi session store seçerken yalnızca performansa bakmak yeterli değildir. Aşağıdaki noktalar uygulamada sık karşılaşılan sorunları azaltır:

• TTL ayarı: Oturum süresi ile cache kayıt süresi uyumlu olmalıdır. Çok kısa TTL kullanıcıyı gereksiz yere sistemden düşürür.
• Yedeklilik: Redis veya benzeri servis tek noktadan arıza yaratmamalıdır. Replikasyon ve failover senaryosu planlanmalıdır.
• Serileştirme uyumu: Farklı uygulama sürümleri aynı session verisini okuyabiliyor olmalıdır.
• Güvenlik: Oturum anahtarları tahmin edilebilir olmamalı, servis erişimi ağ seviyesinde sınırlandırılmalıdır.
• Gözlemlenebilirlik: Oturum hataları, cache bağlantı sorunları ve gecikmeler log ve metriklerle takip edilmelidir.

Load balancer yapılandırmasında kritik ayarlar

Load balancer üzerinde cookie tabanlı sticky session kullanılacaksa cookie adı, yaşam süresi ve güvenlik bayrakları net belirlenmelidir. Kaynak IP tabanlı yönlendirme ise mobil ağlar, kurumsal proxy’ler ve NAT kullanılan ortamlarda beklenmedik sonuçlar üretebilir. Aynı IP’den çok sayıda kullanıcı geliyorsa trafik dengesiz dağılabilir.

Health check ayarları da oturum sürekliliğini etkiler. Sağlıklı görünmeyen bir sunucu yükten çıkarıldığında kullanıcıların oturum verisi yalnızca o sunucudaysa problem yaşanır. Bu yüzden health check yalnızca “port açık mı?” kontrolüyle sınırlı kalmamalı; uygulamanın gerçekten yanıt verebildiğini ölçmelidir.

Uygulama tarafında yapılması gereken kontroller

Oturum sürekliliği sadece altyapı ekibinin konusu değildir. Geliştirme tarafında session verisinin nerede tutulduğu, logout işleminin tüm sunucular için geçerli olup olmadığı ve kullanıcı yetkilerinin cache içinde ne kadar süre saklandığı kontrol edilmelidir.

Dağıtım sırasında eski ve yeni uygulama sürümleri bir süre birlikte çalışabilir. Bu durumda session şemasında yapılan değişiklikler geriye uyumlu olmalıdır. Aksi halde kullanıcı bir istekte eski sürüme, diğer istekte yeni sürüme denk geldiğinde oturum verisi bozulabilir.

Doğru yaklaşımı nasıl seçmelisiniz?

Küçük ve geçici ölçekleme ihtiyaçlarında sticky session yeterli olabilir. Trafiğin düzenli arttığı, otomatik ölçekleme kullanılan veya kesinti toleransı düşük sistemlerde merkezi oturum deposu daha sağlıklı bir tercihtir. Mikroservis ya da API ağırlıklı yapılarda ise stateless token mimarisi daha esnek sonuç verebilir.

Karar verirken uygulamanın mevcut kod yapısı, beklenen trafik, güvenlik gereksinimleri, bakım pencereleri ve ekip yetkinliği birlikte ele alınmalıdır. İyi tasarlanmış bir hosting altyapısında load balancer, cache, uygulama sunucusu ve gözlemleme araçları aynı mimarinin parçaları olarak değerlendirilir. Böylece kullanıcı hangi sunucuya yönlenirse yönlensin oturum bilgisi tutarlı kalır ve sistem büyüdükçe yönetilebilirliğini korur.