Daha Büyük Sunucular Satın Almayı Bırakın: Laravel Yük Dengeleyici Mimarisi Kurma

Dikey Ölçekleme Tuzağı

Bir SaaS ürününüz viral hale geliyor. Trafik artıyor, CPU kullanımı %100’e ulaşıyor ve uygulamanız çöküyor. Çoğu geliştirici için ilk refleks, hosting sağlayıcınıza giriş yapıp “Planı Yükselt” butonuna tıklamaktır. Daha fazla RAM ve CPU çekirdeği için iki katı ücret ödüyorsunuz. Buna Dikey Ölçekleme denir.

Dikey ölçeklemenin sert bir sınırı vardır. Nihayetinde, daha büyük bir sunucu alamazsınız. Daha kötüsü, eğer o tek büyük sunucu bakım nedeniyle veya donanım arızası nedeniyle çevrimdışı olursa, tüm işiniz karanlıkta kalır. Kurumsal düzeyde güvenilirlik için yatay ölçekleme yapmalısınız.

Yatay Mimari

Yatay ölçekleme, daha büyük sunucular eklemek yerine daha fazla sunucu eklemektir. $80/aylık bir sunucu yerine, dört $20/aylık sunucu çalıştırıyorsunuz. Onların önünde bir Yük Dengeleyici var (genellikle Nginx, AWS ELB veya Cloudflare üzerinden yönetilir).

Bir kullanıcı API isteği yaptığında, yük dengeleyici bunu keser ve “Dört Laravel sunucumdan hangisi şu anda en az trafik alıyor?” diye sorar. İsteği o sunucuya yönlendirir. Eğer Sunucu A çökse, yük dengeleyici hemen onu havuzdan çıkarır ve trafiği Sunucular B, C ve D’ye yönlendirir. Gerçek Sıfır Kesinti sağlarsınız.

Korku: Durumsuzluk ve Laravel’i Kırmak

Sadece Laravel kodunuzu dört sunucuya kopyalayıp işin kolayına kaçamazsınız. Yük dengeleyiciyi tanıttığınız anda, standart Laravel mimarisi tamamen bozulur.

• Oturum Problemi: Kullanıcı Sunucu A’ya giriş yapar. Oturumu Sunucu A’nın sabit diskine kaydedilir. Bir sonraki tıklama Sunucu B’ye yönlendirilirse, Sunucu B kim olduklarını bilmez ve onları çıkış yaptırır.
• Dosya Yükleme Problemi: Bir kullanıcı avatar yükler. Bu Sunucu C’nin storage/app/public klasörüne kaydedilir. Ertesi gün Sunucu A’ya girdiğinde, avatar resmi kaybolur (404 hatası).

Mimariyi Düzeltmek

Yatay ölçeklemek için Laravel uygulamanız tamamen Durumsuz hale gelmelidir. Hiçbir sunucu kendi yerel sabit diskine güvenemez.

Bunu uygulama sunucularından durumu ayrıştırarak düzeltiriz:

1. Oturumları ve Önbelleği Merkezileştir: .env dosyanızda SESSION_DRIVER=redis olarak değiştirmeli ve dört sunucuyu tek bir merkezi Redis örneğine yönlendirmelisiniz. Artık hangi sunucu isteği işlerse işlesin, hepsi aynı paylaşılmış bellek havuzundan oturumu okur.
2. Depolamayı Merkezileştir: FILESYSTEM_DISK=s3 olarak değiştirin. Kullanıcı bir dosya yüklediğinde, sunucu hemen bunu bir Amazon S3 bucket’ına (veya daha uygun bir alternatif olan DigitalOcean Spaces gibi) gönderir. Flutter uygulamanız resmi talep ettiğinde, bunu S3 CDN’den alır ve tamamen Laravel sunucularınızı atlayarak gerçekleştirilir.

Sonuç

Monolitik bir sunucudan yük dengelemeli, durumsuz bir mimariye geçmek önemli bir mühendislik zorluğudur. Ancak oturumlarınızı, önbelleğinizi ve depolamanızı ayrıştırduğunuzda, uygulamanız sonsuz ölçeklenebilirlik kazanır. Sunucu sınırları konusunda endişelenmeyi bırakır ve ürün büyümesine odaklanmaya başlarsınız.