Cloud Server Ölçekleme Kararı Nasıl Verilir?

Cloud server seçerken asıl soru yalnızca kaç GB RAM gerektiği değildir; uygulamanın yükünün ne zaman ve nasıl değiştiğini anlamaktır. Trafik kısa süreli artıyor, uygulama birden fazla örnekte çalışabiliyor ve izleme yapılabiliyorsa esnek kapasite yaklaşımı uygun olabilir. Ancak veritabanı, lisans veya uygulama mimarisi ölçeklemeyi sınırlıyorsa daha büyük tek bir sunucuya geçmek daha yönetilebilir olabilir.

Cloud server ölçekleme ne anlama gelir?

Ölçekleme, artan iş yükünü karşılamak için uygulamaya daha fazla işlemci, bellek veya ağ kapasitesi sağlamaktır. Dikey ölçekleme, mevcut cloud server örneğini daha yüksek kaynaklı bir plana taşımaktır. Bu yöntem uygulamanın tek sunucuda çalıştığı, ancak mevcut kaynakların zaman zaman yetersiz kaldığı sistemlerde daha basit olabilir. İşletim sistemi, uygulama ayarları ve veri depolama yapısı aynı kaldığı için mimari değişiklik daha sınırlıdır.

Yatay ölçekleme ise aynı uygulamanın birden fazla sunucu örneğinde çalıştırılmasıdır. İstekleri bu örneklere dağıtmak için yük dengeleyici, oturumların ortak tutulması ve dosyaların paylaşılan veya dış bir depolama katmanında saklanması gerekebilir. Bu nedenle trafik artıyor diye otomatik olarak yatay ölçekleme yapılmaz. Uygulama sunucuda yerel dosyaya veya bellekteki oturuma bağlıysa önce bu bağımlılıkların ele alınması gerekir.

İş yüküne göre doğru yaklaşımı seçme

İşlem süresi uzun, ancak aynı anda çalışan istek sayısı düşük bir uygulamada önce dikey ölçekleme değerlendirilir. Çünkü daha fazla işlemci veya bellek, mevcut uygulama yapısını koruyarak darboğazı azaltabilir. Buna karşılık kısa süreli ziyaretçi artışlarında istek sayısı hızla çoğalıyor ve uygulama örnekleri birbirinden bağımsız çalışabiliyorsa yatay ölçekleme daha uygun bir yol olabilir. Burada kabul edilebilir sonuç yalnızca sunucunun ayakta kalması değil, yanıt sürelerinin yoğunluk sırasında da hedeflenen aralıkta kalmasıdır.

Veritabanı tek bir düğümde çalışıyor ve tüm yazma işlemleri ona gidiyorsa uygulama sunucularını çoğaltmak veritabanı darboğazını ortadan kaldırmaz. Böyle bir durumda uygulama katmanını büyütmeden önce sorgu süreleri, bağlantı sayısı ve disk gecikmesi ayrı izlenmelidir. Sonuç veritabanının sınırına işaret ediyorsa yalnızca cloud server sayısını artırmak yerine sorgu optimizasyonu, uygun önbellekleme veya veritabanı için farklı bir kapasite planı değerlendirilir.

Kararı kullanım biçimine bağlayın

• Yük uzun süre yüksek kalıyorsa: Mevcut örneğin işlemci veya belleği sürekli sınıra yaklaşıyorsa daha büyük bir planın toplam yönetim yükünü azaltıp azaltmadığına bakın. Trafik tek bir uygulama örneğinde kalacaksa yatay yapı kurmadan önce dikey seçeneği değerlendirin.
• Yük kısa ve öngörülebilir aralıklarla artıyorsa: Uygulama örnekleri arasında oturum ve dosya bağımlılığı yoksa yatay çoğaltma düşünülebilir. Bu bağımlılıklar varsa önce uygulamanın durum bilgisini dışarı alacak tasarım değişikliği gerekir.
• Kaynak kullanımı düşük, yanıt süresi yüksekse: Sorunu doğrudan daha fazla CPU ile çözmeye çalışmayın. Ağ gecikmesi, veritabanı bekleme süresi veya dış servise yapılan çağrılar aynı belirtiyi oluşturabilir.

Cloud server seçimini ölçerek doğrulama

İlk değerlendirme için uygulamaya ve sunucuya erişim, temel izleme metrikleri ve mümkünse gerçek trafiği temsil eden kontrollü bir test gerekir. Sağlayıcıya göre metrik adları ve ölçekleme seçenekleri değişebilir; bu nedenle panelde işlemci kullanımı, bellek tüketimi, disk gecikmesi, ağ trafiği, hata oranı ve yanıt süresi gibi değerlerin gerçekten sunulup sunulmadığını kontrol edin.

1. Mevcut sınırı kaydedin: Normal ve yoğun dönemlerde yanıt süresi, hata oranı ve kaynak kullanımını aynı zaman aralıklarında not edin. Tek bir anlık CPU değeri yerine birkaç yoğunluk döngüsünü karşılaştırmak daha anlamlıdır.
2. Darboğazı ayırın: CPU sürekli yüksek, bellek kullanımı dengeli ve disk beklemesi düşükse işlemci ağırlıklı daha büyük bir örnek denenebilir. Bellek tükeniyor veya sistem takas alanına yöneliyorsa bellek kapasitesi ele alınmalıdır; disk gecikmesi yüksekse yalnızca CPU artırmak hedefi karşılamaz.
3. Tek değişkeni uygulayın: Orijinal planı ve uygulama ayarlarını kaydedip yalnızca bir kapasite değişikliği yapın. Aynı test isteğini veya aynı iş akışını tekrarlayın; yanıt süresi düşüyor ve hata oranı değişmiyorsa gözlenen iyileşmenin ilgili kaynakla bağlantısı güçlenir.
4. Yatay seçeneği sınayın: Uygulamayı ikinci bir örnekte çalıştırmadan önce oturum, yüklenen dosya ve geçici veri davranışını kontrol edin. İkinci örneğe yönlenen istek oturumu kaybediyor veya dosyayı bulamıyorsa mimari bu aşamada yatay çoğaltmaya hazır değildir; önce ilgili durum bilgisini ortak bir katmana taşıyın.
5. Sonucu yeni kanıtla doğrulayın: Değişiklikten sonra aynı başarısız veya yavaş işlemi yeniden çalıştırın ve değişiklik sonrasına ait yeni metrikleri inceleyin. Belirti sürüyorsa önceki planı geri yükleyin, değişikliği not edin ve veritabanı ya da dış servis beklemelerini ayrı inceleyin.

Diyelim ki çevrim içi bir raporlama uygulamasında gün sonunda yanıt süresi uzuyor. Ölçümde CPU orta düzeyde kalırken veritabanı sorgu bekleme süresi yükseliyorsa daha güçlü bir cloud server seçmek ilk çözüm değildir; sorgu ve veritabanı kapasitesi incelenmelidir. Buna karşılık aynı saatlerde CPU sürekli sınıra dayanıyor, veritabanı beklemesi değişmiyor ve uygulama oturumları ortak depolamada tutuluyorsa önce daha güçlü bir örnek, ardından kontrollü yatay çoğaltma değerlendirilebilir. Bu, yalnızca varsayımsal bir değerlendirme örneğidir; gerçek seçim kendi ölçümlerinizle yapılmalıdır.

Cloud server seçerken sağlayıcı bağımlı noktalar

Bir sağlayıcının plan değiştirme, disk büyütme, ağ kapasitesi, anlık görüntü alma ve birden fazla örneği yük dengeleyici arkasında çalıştırma yöntemleri farklı olabilir. Bazı değişiklikler yeniden başlatma veya kısa süreli erişim kesintisi gerektirebilir; bazıları ise çevrim içi yapılabilir. İşlemi uygulamadan önce paneldeki etki açıklamasını okuyun, mevcut yapılandırmayı ve verileri uygun şekilde yedekleyin. Test edilmemiş yedeği güvence kabul etmeyin.

Cloud server kararını yalnızca başlangıç kaynaklarına göre vermek yerine büyüme biçimiyle eşleştirin. Değişken web trafiği olan ve durumsuz çalışabilen uygulama için yatay esneklik anlamlı olabilir; tek düğüme bağlı, yoğun veritabanı kullanan veya kalıcı yerel dosyalara dayanan uygulama için dikey kapasite ya da önce mimari düzenleme daha uygun olabilir. İhtiyaç duyduğunuz altyapı seçeneklerini karşılaştırmak için sunucu kiralama çözümleri sayfasını inceleyebilir, ardından kendi metriklerinizle küçük ve geri alınabilir bir test planı oluşturabilirsiniz.

İlk sonraki adım

Uygulamanızın en yavaş işlemini ve bu işlem gerçekleştiği anda CPU, bellek, disk, ağ ve veritabanı ölçümlerini birlikte kaydedin. Hangi kaynak aynı anda sınırına yaklaşıyorsa yalnızca o boyutu değiştirerek başlayın; belirgin bir kaynak baskısı yoksa kapasite artırmak yerine uygulama ve bağımlılık gecikmelerini araştırın.