Geliştiriciler, yeni yayına aldıkları uygulamalarının birkaç bin kullanıcı “başlat” butonuna tıkladığı anda tıkanıp kaldığını izlerler; bu yavaşlama nadiren koddaki bir hatadan kaynaklanır – genellikle sunucunun CPU ve RAM kaynaklarının yer kapmak için birbiriyle mücadelesidir. Darboğaz; daha uzun sayfa yükleme süreleri, zaman aşımı hataları veya doğrudan çökmeler şeklinde kendini gösterir; bu da kullanıcı deneyimine, gelire ve marka güvenine zarar verir.

Laboratuvarda sorunsuz çalışan bir sunucu neden canlı ortamda durma noktasına gelebilir?

Geliştirme aşamasında tek bir geliştirici sadece birkaç istek gönderir, bu nedenle sunucu kaynakları çoğu zaman boşta bekler. Uygulama canlıya geçtiğinde, her ziyaretçi iki temel bileşene ihtiyaç duyan bir istek oluşturur:

  • CPU (merkezi işlem birimi) – her döngüyü, fonksiyonu ve hesaplamayı çalıştıran işlemci. Bunu, aynı anda yalnızca sınırlı sayıda yemek hazırlayabilen bir aşçı gibi düşünebilirsiniz. Bir sipariş anında servis edilir; ancak yüz sipariş geldiğinde aşçı yine aynı hızda çalışır, fakat müşteriler daha uzun süre beklemek zorunda kalır.
  • RAM (rastgele erişimli bellek) – CPU'nun bir isteği işlerken ihtiyaç duyduğu veriler için kullanılan geçici depolama alanı. Bu, aşçının her yemek için gerekli malzemeleri üzerinde tuttuğu bir tezgah gibidir. Eğer tezgah dolarsa, aşçı alan açılana kadar yeni sipariş almayı durdurmak zorundadır.

Binlerce kullanıcı aynı anda giriş yaptığında, her bir istek CPU süresinden kendi payını ve RAM'den kendi kısmını talep eder. Sunucunun her iki kaynağın da sınırlı havuzu istekler arasında bölünür ve kuyruk büyür. Sunucunun kendisi yavaşlamamıştır; her bir istek için bekleme süresi artmıştır.

“Sadece daha büyük bir kutu satın alma” cazibesi

Yaygın ilk tepki, makineyi yükseltmektir; bu uygulamaya dikey ölçeklendirme (vertical scaling) denir. Daha fazla CPU çekirdeği veya daha fazla RAM eklemek kapasiteyi artırır: 4 çekirdekten 16 çekirdeğe veya 8 GB'tan 64 GB'a geçmek, herhangi bir kodu değiştirmeden daha büyük bir trafik dalgasını absorbe edebilir.

Ancak dikey ölçeklendirmenin sert bir sınırı vardır:

  • Fiziksel sınırlar – her anakart yalnızca belirli sayıda çekirdeğe ve sınırlı miktarda belleğe ev sahipliği yapabilir.
  • Azalan verim – her ek çekirdek veya gigabayt bir öncekinden daha maliyetlidir, ancak performans kazanımı giderek küçülür.
  • Tek hata noktası (single point of failure) – eğer aşırı boyutlandırılmış sunucu çökerse, tüm hizmet ortadan kalkar.

Bu kısıtlamalar nedeniyle, sektörün devleri – yayın platformları, arama motorları, e-ticaret siteleri – tek bir devasa makineden uzaklaşmıştır.

Alternatif: Yükü birçok küçük kutuya yaymak

Daha yüksek bir kule inşa etmek yerine, operatörler mütevazı boyutlarda daha fazla sunucu ekler ve trafiği paylaşmalarına izin verirler. Bu yatay ölçeklendirme (horizontal scaling) yaklaşımı, her makineyi konforlu bir performans aralığında tutar ve dikey yükseltmelerin üstel maliyet eğrisinden kaçınır.

Birçok makineyi koordine etmek bir yük dengeleyici (load balancer) gerektirir; bu, gelen her isteği alan ve onu en fazla boş kapasiteye sahip sunucuya ileten bir yazılım veya donanımdır. Yük dengeleyici, karmaşıklığı istemciden gizler; kullanıcının bakış açısına göre site hala tek bir uç nokta (endpoint) gibi görünür.

Yatay ölçeklendirme aynı zamanda dayanıklılık da sağlar. Eğer bir düğüm (node) çökerse, yük dengeleyici trafiği basitçe kalan sağlıklı düğümlere yönlendirerek hizmetin devam etmesini sağlar.

Makine eklemeye başladığınızda dikkat etmeniz gerekenler

  • Durumsuz (stateless) tasarım – istekler yalnızca belirli bir sunucunun belleğinde saklanan verilere dayanmamalıdır; aksi takdirde bir kullanıcı, gerekli bağlama sahip olmayan bir düğüme yönlendirilebilir. Paylaşımlı önbellekler (cache) veya veritabanları kullanmak bu sorunu çözer.
  • Sağlık kontrolleri (health checks) – yük dengeleyici, arızalanan bir sunucuyu hızlıca tespit edebilmeli ve ona trafik göndermeyi durdurmalıdır.
  • Otomatik ölçeklendirme politikaları (auto-scaling policies) – birçok bulut platformu, maliyetleri talebe göre ayarlamak için örnekleri (instances) otomatik olarak başlatan veya kapatan eşikler (CPU kullanımı, istek gecikmesi) tanımlamanıza olanak tanır.

Karşı görüş: Dikey ölçeklendirme ölmedi

Küçük ekipler veya düşük trafikli uygulamalar için tek bir güçlendirilmiş sunucu en basit ve en ucuz çözüm olabilir. Eğer trafik artışı öngörülebilir ise (örneğin, planlanmış bir ürün lansmanı), geçici bir dikey yükseltme, tamamen yeni bir örnek filosu kurmaktan daha pratik olabilir.

Asıl mesele, “daha büyük kutu” taktiğinin ne zaman orantılı değer sağlamayı bıraktığını fark etmek ve dağıtım (distribution) için plan yapmaya başlamaktır.

Özet

Yayına alındıktan sonra yaşanan sunucu yavaşlaması genellikle bir kod hatası değil, bir kaynak rekabeti (resource-contention) sorunudur. CPU döngüleri ve RAM yuvaları sınırlıdır ve birçok istek aynı anda geldiğinde kuyruğa girerek yanıt sürelerini uzatırlar. Dikey ölçeklendirme (vertical scaling) size biraz daha hareket alanı sağlar ancak kısa süre sonra fiziksel ve ekonomik sınırlara takılır. Yatay ölçeklendirme —bir yük dengeleyici (load balancer) arkasına daha mütevazı sunucular eklemek— trafik arttıkça daha ucuz ve daha dayanıklı bir yol sunar. Kuyruğun uzadığını fark ettiğiniz an, birkaç çekirdeğin yeterli olup olmayacağını veya yükü birçok makineye yaymaya başlayıp başlamamanız gerektiğini değerlendirme zamanı gelmiş demektir.

Kaynak: dev.to makalesi “Why Servers Slow Down – CPU, RAM and the hidden cost of every request.”