Cloud Server İçin Dikey ve Yatay Ölçekleme Nasıl Seçilir?

Cloud server üzerinde kaynak artırma kararı, yalnızca daha yüksek CPU veya RAM seçmekten ibaret değildir. Trafik kısa süreli olarak yükseliyorsa dikey ölçekleme, yani mevcut sunucuya daha fazla kaynak ekleme, daha basit olabilir. İstekleri birden fazla sunucuya dağıtmak gerekiyorsa yatay ölçekleme daha uygun hale gelir. Doğru seçim için önce darboğazın türünü, ardından uygulamanın birden fazla örnekle çalışıp çalışamayacağını belirleyin.

Cloud server ölçekleme seçenekleri arasındaki temel fark

Dikey ölçekleme, çalışan sunucunun işlemci, bellek veya disk kapasitesini artırmaktır. Uygulamanın tek sunucuda çalışmaya devam etmesi yönetimi kolaylaştırır; ancak kaynak değişikliği sağlayıcıya ve altyapıya bağlı olarak yeniden başlatma, kısa süreli erişim kesintisi veya plan değişikliği gerektirebilir. Bu nedenle üretim sisteminde değişiklik yapmadan önce bakım aralığını ve geri dönüş seçeneğini netleştirmek gerekir.

Yatay ölçekleme ise aynı uygulamanın birden fazla sunucu örneğinde çalıştırılması ve gelen isteklerin bu örneklere dağıtılmasıdır. Bunun için yük dengeleyici, ortak oturum yaklaşımı, paylaşımlı ya da merkezi veri erişimi gibi ek bileşenler gerekebilir. Uygulama yerel diske veya yalnızca tek sunucunun belleğine yazıyorsa sunucu sayısını artırmak, beklenen sonucu vermek yerine veri tutarsızlığı oluşturabilir.

İş yüküne göre hangi yaklaşım daha uygundur?

İşlemci kullanımı uzun süre yüksek, fakat uygulama tek örnekle sorunsuz çalışıyorsa ve trafik düzenli biçimde artmıyorsa dikey ölçekleme mantıklı bir ilk adımdır. Örneğin arka planda çalışan raporlama işi CPU’yu tüketiyor, web istekleri ise normal yanıt veriyorsa önce rapor işini ayrı bir çalışma sürecine taşımayı veya mevcut sunucunun işlemci kapasitesini artırmayı değerlendirin. Sorun bellek yetersizliği ise CPU eklemek çözüm olmaz; bellek kullanımı, takas alanı etkinliği ve uygulamanın bellek sınırları birlikte incelenmelidir.

İstek sayısı gün içinde değişiyor, uygulama birden fazla örnekle çalışabiliyor ve tek bir sunucunun kapasitesini aşan dönemler oluşuyorsa yatay ölçekleme daha uygun olabilir. Ancak veritabanı da aynı hızda çoğaltılamaz; çoğu yapıda önce uygulama katmanı ölçeklenir, veritabanı için ayrı bağlantı, sorgu ve depolama planı yapılır. Trafik artışının yalnızca statik dosyalardan kaynaklandığı durumda ise yeni uygulama sunucuları eklemek yerine önbellekleme veya içerik dağıtımı daha yerinde olabilir.

• Darboğaz CPU ise: Kullanım uzun süre yüksek kalıyor ve uygulama tek örnekle çalışıyorsa önce dikey kapasite artışını değerlendirin; kısa süreli sıçramalarda otomatik ölçekleme veya iş kuyruğu daha uygun olabilir.
• Darboğaz trafik yoğunluğu ise: İstekler bağımsız işleniyor, oturum ve dosya durumu merkezi tutulabiliyorsa yatay ölçekleme düşünülebilir; yerel oturum veya dosya bağımlılığı varsa önce uygulama mimarisini düzeltin.
• Darboğaz depolama ise: Sadece RAM veya CPU artırmayın. Disk doluluk oranı, I/O bekleme süresi ve büyüme hızını inceleyerek daha büyük disk, ayrı depolama veya arşivleme seçeneğini değerlendirin.

Karar vermeden önce yapılacak pratik değerlendirme

İlk olarak aynı zaman aralığında CPU, bellek, disk I/O, ağ trafiği, istek sayısı ve yanıt sürelerini izleyin. Tek bir anlık değere göre karar vermek yanıltıcıdır; normal dönem ile yoğun dönemi karşılaştırın. Örneğin CPU yüzde olarak düşük görünürken disk bekleme süresi ve yanıt süresi yükseliyorsa işlemci planını büyütmek yerine depolama katmanını incelemek gerekir.

Daha sonra uygulamanın durum bilgisini nerede tuttuğunu kontrol edin. Oturumlar yalnızca yerel bellekte, yüklenen dosyalar yalnızca sunucunun diskinde veya geçici işler yalnızca tek süreçte tutuluyorsa yatay çoğaltma öncesinde bu bağımlılıkları ele alın. Uygulama stateless, yani her sunucu örneğinin aynı isteği bağımsız işleyebildiği bir yapıya yaklaşıyorsa yük dengeleyici arkasında ek örnekleri değerlendirmek daha güvenli olur.

Diyelim ki bir ürün kataloğu uygulamasında kampanya saatlerinde web istekleri artıyor, uygulama sunucularında CPU ve bellek sınırına yaklaşılmıyor, fakat her istek aynı veritabanına gidiyor. Bu durumda daha büyük bir cloud server seçmek ilk bakışta doğrudan çözüm gibi görünmez; önce veritabanı sorgularını, bağlantı havuzunu ve önbellek kullanımını incelemek gerekir. Buna karşılık ölçümde uygulama süreçlerinin CPU sınırına dayandığı, veritabanının ise rahat çalıştığı görülürse uygulama örneklerini artırmak daha anlamlı bir seçenektir.

İlk uygulamada neyi doğrulamalısınız?

Değişiklikten önce mevcut kaynak planını, önemli ayarları ve geri dönüş adımlarını kaydedin. Tek seferde CPU, RAM, disk ve uygulama mimarisini değiştirmeyin; aksi halde hangi değişikliğin etkili olduğunu ayırt edemezsiniz. Önce seçtiğiniz darboğaza yönelik tek bir değişiklik uygulayın, ardından aynı yoğunlukta istek veya işi yeniden çalıştırın.

Başarılı bir değerlendirmede yalnızca sunucunun çevrimiçi olması yeterli değildir. Yanıt süresi, hata oranı, kuyruk uzunluğu, disk bekleme süresi ve veritabanı bağlantıları değişiklik öncesiyle karşılaştırılmalıdır. Dikey artıştan sonra CPU rahatlıyor fakat bellek baskısı sürüyorsa yalnız işlemci artırmak yeterli değildir. Yatay örnek ekledikten sonra hata oranı yükseliyorsa oturum, yerel dosya veya bağlantı havuzu bağımlılığını araştırın ve önceki çalışan ayara dönerek sorunu tek faktör üzerinden yeniden ele alın.

Planınızı sağlayıcının sunduğu yeniden boyutlandırma, anlık görüntü ve ağ özellikleriyle ayrıca doğrulayın; bu davranışlar altyapıya göre değişebilir. Sunucu planlarını karşılaştırırken teknik seçenekleri sunucu kiralama çözümleri arasında incelerken, özellikle kesinti gerekip gerekmediğini ve yedekleme sorumluluğunun kimde olduğunu netleştirin. İlk sonraki adım, yoğun saatten bir örnek alıp gerçek darboğazı ölçmek ve yalnız o bileşen için küçük, geri alınabilir bir değişiklik yapmaktır.