Oturum Durumlarını Ölçeklendirme: Redis İçin Dosya Sürücülerinden Vazgeçin

Stateless Sunucu Tuzakları

Bir SaaS platformu geliştirirken, Laravel varsayılan olarak kullanıcı oturum durumlarını yerel sabit disk üzerindeki düz dosyalara kaydeder (storage/framework/sessions). Küçük ölçeklerde bu disk tabanlı yaklaşım gayet iyi çalışır. Ancak, web uygulamanız bir Load Balancer’ın arkasında genişlemeye başladığında, mimari bir krizle karşılaşabilirsiniz.

İki ayrı sunucu düğümü üzerinde yatay ölçeklendirmeyi hayal edin: Sunucu A ve Sunucu B. Bir kullanıcı oturum açtığında, oturum dosyası Sunucu A’nın yerel diskine yazılır. İki dakika sonra, bir kontrol paneli bağlantısına tıkladığında, Load Balancer bu isteği Sunucu B’ye yönlendirir. Sunucu B, Sunucu A’nın fiziksel dosya sistemine erişimi olmadığı için kullanıcının kimlik doğrulaması yapılmamış olduğunu varsayar. Kullanıcı aniden oturum açma ekranına gönderilir. Stateless yatay otomatik ölçeklemenin sorunsuz bir şekilde yönetilmesi için, oturumlarınızı merkezi bir Redis Memory Store‘a geçirmeniz gerekiyor.

Çözüm: Dağıtılmış Bellek İçi Oturumlar

Oturum durumlarını izole sunucu diskleri içine kilitlemek yerine, kurumsal bir mimari, oturum takibini hızlı ve paylaşılan bir bellek katmanına merkezileştirir.

Oturum sürücülerini merkezi bir Redis kümesine yönlendirerek, otomatik ölçeklendirilmiş her uygulama konteyneri, iç ağ üzerinden tam aynı RAM havuzunu sorgular. Gelen HTTP isteğini hangi sunucu düğümünün işlediği artık önemli değildir; kullanıcı durumu evrensel olarak erişilebilir, güvenli ve okuma süreleri milisaniyenin bir kısmında gerçekleşir.

Adım 1: Redis Altyapı Yapılandırmalarını Tasarlama

Laravel, oturum sürücülerini taşımayı son derece kolay hale getirir. İlk olarak, ana ortam değişkenlerimizin oturum işlemlerini dosya IO’dan uzaklaştırıp, Redis ağ havuzumuza yönlendirdiğinden emin oluruz.

// .env

# ❌ ANTI-PATTERN (Yerel Depolama Darboğazı)
# SESSION_DRIVER=file

# ✅ GİRİŞİMCİ PATERNI (Merkezi RAM)
SESSION_DRIVER=redis
REDIS_HOST=10.0.0.5 # Merkezi Redis iç IP adresi

Adım 2: Oturum Verisi Katmanlarının İzolasyonu

Yüksek hacimli oturum okumalarının uygulamanızın temel arka uç önbellek işlemlerini kontamine etmemesi için, oturum verilerini veritabanı yapılandırmanızda kendi özel bağlantı bloğu içinde izole etmelisiniz.

// config/database.php

'redis' => [
    'client' => env('REDIS_CLIENT', 'phpredis'),

    // Varsayılan uygulama önbellek havuzu
    'default' => [
        'url' => env('REDIS_URL'),
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD'),
        'port' => env('REDIS_PORT', '6359'),
        'database' => env('REDIS_DB', 0),
    ],

    // ✅ GİRİŞİMCİ PATERNI: Ayrı Oturum Veritabanı
    // Geçici kimlik doğrulama oturumlarını mükemmel şekilde izole eder
    'session' => [
        'host' => env('REDIS_HOST', '127.0.0.1'),
        'password' => env('REDIS_PASSWORD'),
        'port' => env('REDIS_PORT', '6359'),
        'database' => env('REDIS_SESSION_DB', 1), // İzole bir Redis dizini kullanılır
    ],
],

Mühendislik ROI

Oturum mimarinizi yerel dosya ağlarından ayırıp, özel bir Redis veritabanı yapılandırmasına taşıdığınızda, kullanıcılarınızı tek makinelere bağlayan bağı tamamen kırarsınız. Bu, gerçek bir stateless yatay ölçeklenmeyi sınırsız konteyner pod’larında mümkün kılar, oturum IO arama gecikmenizi neredeyse sıfıra indirir ve hızlı dağıtım kod güncellemeleri sırasında sorunsuz, kesintisiz kullanıcı deneyimleri garanti eder.