Sunucunuzu büyütmeye devam ettiniz ama bir noktada daha fazla büyütmek ya mümkün olmuyor ya da mantıklı gelmiyor. Sıradaki adım ikinci bir sunucu eklemek — ve bu, tek sunucu büyütmekten temelde farklı bir iş.
Bu yazı, yatay ölçeklemeye geçişin gerçek gereksinimlerini ele alıyor.
Ne Zaman Yatay Ölçekleme?
Dikey büyütmenin sınırına gelmenin işaretleri:
- Paket yükseltme maliyeti orantısız artıyor.
- Tek sunucu arızası kabul edilemez hâle geldi.
- Bakım için kesinti veremiyorsunuz.
- Trafik zirveleri öngörülemez hâle geldi.
İkinci madde çoğu zaman asıl gerekçedir: yatay ölçeklemeye geçenlerin çoğu performans için değil, kesintiyi ortadan kaldırmak için geçer.
Tek sunucuda ne kadar güçlü donanım olursa olsun, o sunucu yeniden başlatıldığında siteniz kapalıdır. İki sunucuyla bu sorun tamamen ortadan kalkar.
Ön Koşul: Durumsuzluk
İkinci sunucu eklemeden önce uygulamanızın hazır olması gerekir:
- Oturum verisi diskte tutulmamalı.
- Yüklenen dosyalar paylaşılmalı.
- Önbellek merkezî olmalı.
- Zamanlanmış görevler tek yerden çalışmalı.
- Günlükler merkezîleştirilmeli.
Birinci madde en hızlı fark edilen sorundur: oturum dosyaları yerel diskte duruyorsa, kullanıcı ikinci sunucuya düştüğünde çıkış yapmış görünür.
Dördüncü madde ise sessiz ama tehlikeli bir hata üretir. Aynı zamanlanmış görev iki sunucuda birden çalışırsa, e-postalar iki kez gönderilir ve raporlar bozulur.
Oturum Yönetimi Çözümleri
Oturumu paylaşmanın yolları:
| Yöntem | Özelliği |
|---|---|
| Yapışkan oturum | Kolay ama sunucu düşerse oturum gider |
| Veritabanında saklama | Güvenilir, veritabanına yük bindirir |
| Bellek deposunda saklama | Hızlı, ayrı bir servis gerektirir |
| Şifreli çerezde taşıma | Sunucu tarafı depolama gerekmez |
Birinci satır geçiş dönemi için pratiktir ama gerçek bir çözüm değildir: yapışkan oturumda kullanıcı hep aynı sunucuya gider, o sunucu düştüğünde oturumu kaybolur.
Üçüncü satır çoğu yapı için doğru dengedir. Dördüncü satır ise dikkat gerektirir — çerez boyutu sınırlıdır ve içine konan her şey her istekte ağdan geçer.
Dosya Paylaşımı
Kullanıcı yüklemeleri için seçenekler:
- Ağ dosya sistemi. Basit ama tek nokta oluşturur.
- Nesne depolama. Ölçeklenebilir, uygulama değişikliği gerektirir.
- Çift yönlü senkronizasyon. Çakışma riski taşır.
Üçüncü seçenek cazip görünür ama sorunludur: iki sunucu aynı anda aynı dosyayı değiştirirse senkronizasyon çakışması oluşur ve hangi sürümün doğru olduğu belirsizleşir.
İkinci seçenek uzun vadede en sağlamıdır. Uygulamanızda dosya yolları yerine bir depolama katmanı kullanmak, ilerideki tüm ölçekleme adımlarını kolaylaştırır.
Yük Dengeleyici
Trafiği dağıtan katmanın yapması gerekenler:
- Sunucular arasında istekleri dağıtmak.
- Sağlık kontrolü yapmak. Ölü sunucuya trafik göndermemek.
- Şifreli bağlantıyı sonlandırmak. Genellikle burada yapılır.
- Gerçek istemci adresini iletmek.
Dördüncü madde atlanırsa uygulamanız kör kalır: yük dengeleyici arkasındaki sunucular, tüm istekleri dengeleyicinin adresinden geliyor görür — gerçek ziyaretçi adresi kaybolur.
Bu, günlük analizini, hız sınırlamayı ve coğrafi işlevleri bozar. Dengeleyicinin ilettiği başlığı okumak ve ona güvenmek için yapılandırma gerekir.
Veritabanı Tarafı
Uygulama sunucularını çoğaltmak kolaydır; veritabanı farklıdır:
| Yaklaşım | Uygunluk |
|---|---|
| Tek veritabanı sunucusu | Çoğu ölçek için yeterli |
| Okuma kopyaları | Okuma ağırlıklı yükler |
| Bölümleme | Çok büyük ölçek, karmaşık |
Birinci satır önemli bir gerçeği hatırlatır: iki uygulama sunucusu tek bir veritabanına rahatlıkla hizmet edebilir — veritabanını bölmek genellikle çok daha sonra gereken bir adımdır.
Bu yüzden yatay ölçeklemeye uygulama katmanından başlamak, en yüksek getiriyi en düşük karmaşıklıkla sağlar.
Gerçek Maliyet
İkinci sunucunun maliyeti yalnızca kira bedeli değildir:
- Yük dengeleyici maliyeti
- Paylaşılan depolama veya bellek servisi
- Dağıtım süreçlerinin karmaşıklaşması
- İzlemenin çoğalması
- Yapılandırma tutarlılığı çabası
Beşinci madde uzun vadede en çok zaman alanıdır: iki sunucunun yapılandırması elle yönetilirse zamanla farklılaşır ve "bir sunucuda çalışıyor, diğerinde çalışmıyor" tipi sorunlar başlar.
Bu yüzden yatay ölçeklemeye geçmeden önce yapılandırmayı betiklerle yönetmeye başlamak gerekir. Kaynak ekleme esnekliği sunan VDS sunucu altyapısı üzerinde ikinci bir örnek açmak kolaydır; asıl iş, iki örneği aynı tutmaktır.
Sonuç
Yatay ölçeklemeye geçenlerin çoğu performans için değil, kesintiyi ortadan kaldırmak için geçer — tek sunucu ne kadar güçlü olursa olsun, yeniden başlatıldığında siteniz kapalıdır. Geçişin ön koşulu uygulamanın durumsuz hâle getirilmesidir: oturum diskten çıkarılmalı, dosyalar paylaşılmalı, zamanlanmış görevler tek yerden çalışmalıdır. Yük dengeleyici kurarken gerçek istemci adresini iletmeyi unutmayın, aksi hâlde günlükleriniz kör kalır. Veritabanını bölmek ise genellikle çok daha sonra gereken bir adımdır.
Sıkça Sorulan Sorular (SSS)
Ne zaman ikinci sunucuya geçmeliyim?
Genellikle performans değil kesinti gerekçesiyle. Paket yükseltme maliyeti orantısız artıyorsa, bakım için kesinti veremiyorsanız veya tek sunucu arızası kabul edilemez hâle geldiyse zamanı gelmiş demektir.
Kullanıcılar rastgele çıkış yapıyor, neden?
Oturum verisi yerel diskte tutuluyor demektir. Kullanıcı ikinci sunucuya yönlendirildiğinde oturumu orada bulunamaz. Çözüm oturumu merkezî bir yerde tutmaktır — bellek deposu çoğu yapı için doğru tercihtir.
Veritabanını da çoğaltmam gerekir mi?
Genellikle hayır. İki uygulama sunucusu tek bir veritabanına rahatlıkla hizmet edebilir. Veritabanını bölmek çok daha büyük ölçeklerde gereken karmaşık bir adımdır; önce uygulama katmanını ölçeklendirin.
Zamanlanmış görevleri nasıl yönetmeliyim?
Tek bir sunucuda çalışacak şekilde. Aynı görev iki sunucuda birden çalışırsa e-postalar iki kez gönderilir ve raporlar bozulur. Ya görevleri belirli bir sunucuya sabitleyin ya da bir kilit mekanizmasıyla tek çalıştığından emin olun.
