Otomatik Ölçekleme (Auto Scaling) Nedir

Trafiğin gün içinde üç kat, kampanya günlerinde on kat dalgalanıyorsa iki kötü seçenekle karşı karşıyasın demektir: ya en yüksek yüke göre sunucu tutup zamanın %90'ında boş kapasiteye para ödersin ya da ortalama yüke göre kurgulayıp zirve saatlerde sitenin yavaşlamasını izlersin. Otomatik ölçekleme (auto scaling) bu ikilemi ortadan kaldırmak için vardır: sunucu sayısını gerçek yüke göre kendiliğinden artırır ve yük düştüğünde geri azaltır.

Bu rehberde otomatik ölçeklemenin gerçekte neyi otomatikleştirdiğini, hangi metriği tetikleyici seçmen gerektiğini (ipucu: CPU çoğu zaman yanlış seçimdir), bekleme sürelerinin neden en kritik ayar olduğunu, yeni açılan sunucunun trafiği karşılamaya hazır hâle gelene kadar geçen sürenin bütün planı nasıl bozabileceğini ve maliyetin nasıl kontrol altında tutulacağını anlatacağım. Kendi altyapında bulut API'si olmadan çalışan basit bir ölçekleme döngüsünün nasıl kurulacağını da göstereceğim.

Otomatik Ölçekleme Neyi Otomatikleştirir#

Otomatik ölçekleme, yeni bir teknoloji değil; yatay ölçeklemenin elle yapılan adımlarının bir kontrol döngüsüne bağlanmasıdır. Döngü dört parçadan oluşur: bir metrik kaynağı (yük ne durumda), bir politika (hangi eşikte ne yapılacak), bir eylemci (sunucu açan/kapatan API ya da betik) ve bir kayıt (hangi sunucu havuzda). Bu dördü yerine oturmadan otomatik ölçekleme kurmaya çalışmak, sonu tahmin edilemeyen bir sisteme yol açar.

Kritik nokta şudur: otomatik ölçekleme yatay ölçeklemenin yerine geçmez, üstüne kurulur. Yani uygulamanın önce durumsuz olması, oturumların ortak bir depoda tutulması, yüklenen dosyaların yerel diskte durmaması gerekir. Bu ön koşulları yatay mı dikey mi ölçekleme yazısında ayrıntılı anlattım; oradaki dört maddeyi karşılamadan bu rehberdeki hiçbir şey işine yaramaz, çünkü sistem her ölçek değişikliğinde rastgele kullanıcı oturumlarını uçurur.

Yeni açılan düğümün trafiği alması ise yük dengeleyicinin işidir. Ölçekleyici sunucuyu açar, sunucu kendini havuza kaydeder, dengeleyici sağlık kontrolünü geçtiğini görünce trafik göndermeye başlar. Bu zincirin nasıl kurulduğunu yük dengeleyici nedir yazısında bulabilirsin.

Doğru Tetikleyici Metriği Seçmek#

Neredeyse her otomatik ölçekleme örneği "CPU %70'i geçerse sunucu ekle" ile başlar ve bu, çoğu web uygulaması için yanlış metriktir. Sebebi basit: PHP-FPM ya da Node.js tabanlı bir uygulamada kullanıcı deneyimi genellikle CPU dolmadan çok önce bozulur — istekler kuyrukta beklerken CPU %40'ta görünüyor olabilir, çünkü darboğaz veritabanı beklemesi ya da tükenmiş bir iş parçacığı havuzudur.

Pratikte en sağlam tetikleyici, sunucu başına düşen eşzamanlı aktif istek sayısıdır. Tek bir düğümün rahatça kaç eşzamanlı isteği kaldırdığını yük testiyle ölçer, hedefi bunun %60–70'ine koyarsın; ölçekleyici toplam eşzamanlı istek sayısını bu hedefe bölerek gereken düğüm sayısını hesaplar. Bu yöntem CPU eşiğinden çok daha öngörülebilir davranır çünkü doğrudan kapasiteyi ölçer.

Arka plan işçileri (worker) için ise metrik nettir: kuyruk derinliği. Kuyrukta bekleyen iş sayısı belirli bir eşiği aşarsa işçi ekle, kuyruk boşaldıysa azalt. Burada yanıt süresi ya da CPU'ya bakmak gereksizdir.

# Nginx stub_status ile anlık aktif bağlantı sayısını okuma
curl -s http://127.0.0.1/nginx_status
# Active connections: 143
# server accepts handled requests
#  98211 98211 412884
# Reading: 0 Writing: 12 Waiting: 131

# Sadece "Active connections" değerini çek
curl -s http://127.0.0.1/nginx_status | awk '/Active/ {print $3}'

Politika Ayarları: Eşik, Bekleme ve Histerezis#

Otomatik ölçeklemede en çok soruna yol açan konu eşik değeri değil, eşiğin ne kadar süre aşılınca eyleme geçileceği ve iki eylem arasında ne kadar bekleneceğidir. Bu ayarlar yanlışsa sistem salınıma girer: sunucu açar, yük düşer, sunucu kapatır, yük çıkar, tekrar açar. Buna "flapping" denir ve hem maliyeti hem riski artırır.

Sağlıklı bir politikanın üç bileşeni vardır:

1. Değerlendirme penceresi. Eşiğin anlık değil, sürekli aşılmasını iste. Örneğin "3 ardışık ölçümde (yaklaşık 3 dakika) hedefin üstünde" gibi. Anlık ani yükselmeler (bir arama motoru taraması, bir sağlık kontrolü dalgası) böylece sunucu açtırmaz.
2. Bekleme süresi (cooldown). Bir ölçekleme eyleminden sonra belirli bir süre yeni karar alma. Yeni sunucunun yükü almasının etkisi metriklere yansımadan ikinci sunucuyu açarsan gereksiz kapasite ödersin.
3. Asimetrik eşikler (histerezis). Büyütme eşiği ile küçültme eşiği aynı olmamalı. Örneğin hedef %70 ise, büyütmeyi %70'te, küçültmeyi %40'ta tetikle. Aradaki bant salınımı engeller.

Ölçek azaltma her zaman ölçek artırmadan daha yavaş ve daha temkinli olmalıdır. Fazladan bir sunucuyu on dakika fazla çalıştırmanın bedeli birkaç liradır; erken kapatmanın bedeli ise yavaşlayan bir sitedir. Pratik bir kural: artırma penceresi 2–3 dakika, azaltma penceresi 10–15 dakika.

Isınma Süresi: Ölçeklemenin Görünmeyen Gecikmesi#

Otomatik ölçeklemede kimsenin ilk anda hesaba katmadığı şey, "sunucu ekle" kararı ile "yeni sunucu gerçekten trafik karşılıyor" anı arasındaki süredir. Bu süre şu adımların toplamıdır: sanal makinenin sağlanması, işletim sisteminin açılması, uygulamanın kurulması ya da konteynerin indirilmesi, bağımlılıkların bağlanması, önbelleğin ısınması ve sağlık kontrolünün geçmesi. Toplamda birkaç dakikayı bulur.

Sorun şudur: trafik iki dakikada zirveye çıkıyorsa, beş dakika sonra hazır olan bir sunucu zirveyi kaçırır. Bu yüzden otomatik ölçekleme ani sıçramalara karşı tek başına yeterli değildir. Üç pratik önlem var:

• Altın imaj kullan. Her açılışta paket kurmak yerine, uygulaması kurulu bir imajdan makine aç. Hazır olma süresi dakikalardan saniyelere iner.
• Öngörülü ölçekle. Kampanya saatini biliyorsan, metriği beklemeden zamanlanmış bir kural ile önceden büyüt. Bu, otomatik ölçeklemenin en az bilinen ama en etkili biçimidir.
• Tabanı yüksek tut. Minimum düğüm sayısını, ani sıçramanın ilk dalgasını karşılayacak kadar bırak.

Bir de sunucunun "açık" olması ile "hazır" olmasını ayırt etmen gerekir. Yeni düğüm henüz JIT derlemesini yapmamış, bağlantı havuzlarını doldurmamış ve önbelleğini ısıtmamışken tam trafik alırsa, ilk isteklerin yanıt süresi çok kötü olur ve bazen düğüm sağlıksız işaretlenip döngüye girer. Yük dengeleyicinin yavaş başlangıç (slow start) özelliği tam olarak bunun içindir: yeni üyeye trafiği kademeli olarak artırarak verir.

Kendi Altyapında Basit Bir Ölçekleme Döngüsü#

Yönetilen bir otomatik ölçekleme hizmetin yoksa, mantığı kendin de kurabilirsin. Aşağıdaki iskelet, dengeleyicideki toplam aktif bağlantıyı okuyup düğüm sayısını hesaplayan bir kontrol döngüsünün özüdür. Gerçek kurulumda sunucu açma/kapatma komutunu sağlayıcının API'siyle değiştirirsin.

#!/usr/bin/env bash
set -euo pipefail

HEDEF_PER_NODE=200      # bir düğümün rahat taşıdığı eşzamanlı istek
MIN_NODE=2
MAX_NODE=8              # maliyet tavanı - bu satır olmadan çalıştırma
STATE=/var/lib/olcekleyici/son_islem

aktif=$(curl -fsS http://127.0.0.1/nginx_status | awk '/Active/ {print $3}')
mevcut=$(ls /etc/haproxy/nodes.d/*.cfg 2>/dev/null | wc -l)

# Gereken düğüm sayısını yukarı yuvarlayarak hesapla
gereken=$(( (aktif + HEDEF_PER_NODE - 1) / HEDEF_PER_NODE ))
[ "$gereken" -lt "$MIN_NODE" ] && gereken=$MIN_NODE
[ "$gereken" -gt "$MAX_NODE" ] && gereken=$MAX_NODE

# Bekleme süresi: son işlemden bu yana 300 sn geçmediyse karar alma
if [ -f "$STATE" ] && [ $(( $(date +%s) - $(stat -c %Y "$STATE") )) -lt 300 ]; then
  echo "cooldown: karar atlandı"; exit 0
fi

if [ "$gereken" -gt "$mevcut" ]; then
  echo "buyut: $mevcut -> $gereken"
  # dugum_ac.sh $(( gereken - mevcut ))
  touch "$STATE"
elif [ "$gereken" -lt "$mevcut" ]; then
  echo "kucult: $mevcut -> $gereken"
  # dugum_kapat.sh $(( mevcut - gereken ))   # önce drain, sonra kapat
  touch "$STATE"
fi

Bu betikte iki satır hayati: MAX_NODE maliyet tavanıdır ve asla kaldırılmamalıdır; küçültme yorumunda geçen "önce drain" ise sunucuyu kapatmadan önce dengeleyiciden çıkarıp açık bağlantıların bitmesini beklemek anlamına gelir. Bu adım atlanırsa her küçültme işlemi kullanıcıların ortasında kesilen istekler üretir. Yapılandırmayı düğümler arasında tutarlı tutmak için Ansible ile sunucu otomasyonu yaklaşımı burada da geçerli.

Maliyeti Kontrol Altında Tutmak#

Otomatik ölçekleme maliyeti düşürmek için kurulur ama yanlış yapılandırıldığında tam tersini yapar. Faturanın kontrolden çıkmasının üç klasik yolu var ve üçü de önlenebilir.

Birincisi üst sınır koymamaktır. Bir hata döngüsü, bir bot saldırısı ya da sonsuz yeniden deneme yapan bir istemci metriği tavana yapıştırır ve ölçekleyici sunucu açmaya devam eder. Her ölçekleme grubunun bir max değeri olmalı ve bu değere ulaşıldığında uyarı üretilmelidir. İkincisi küçültmeyi hiç test etmemektir; pek çok kurulumda büyütme çalışır, küçültme sessizce başarısız olur ve haftalar sonra fark edilir. Üçüncüsü saatlik faturalamayı unutmaktır: dakikalar için açılıp kapanan sunucular çoğu sağlayıcıda başlanan saat üzerinden ücretlendirilir, yani salınım doğrudan paraya dönüşür.

Trafik ve kaynak projeksiyonunu somut rakamlara çevirmek için bant genişliği hesaplayıcı aracını kullanabilir, kapasite planını sabit ve esnek katman olarak ikiye bölerek tabanı VDS üzerinde, dalgalanan kısmı bulut sunucu üzerinde tutabilirsin. Bu karma model çoğu Türk e-ticaret projesinde saf bulut modelinden belirgin biçimde ucuza gelir.

Sık Yapılan Hatalar#

Sağlık kontrolü olmadan ölçeklemek. Yeni açılan düğüm hazır olmadan havuza girerse kullanıcıların bir kısmı 502 alır. Düğüm ancak sağlık kontrolünü geçtikten sonra trafik almalı.

Veritabanını unutmak. Web katmanı ikiden sekize çıkarken her düğüm kendi bağlantı havuzunu açar; veritabanı max_connections sınırına toslar ve ölçekleme sistemi kendi kendini çökertir. Düğüm başına havuz boyutu × maksimum düğüm sayısı, veritabanı sınırının altında kalmalı.

Ölçek azaltmada drain yapmamak. Sunucuyu doğrudan kapatmak, o an işlenen istekleri keser. Önce dengeleyiciden çıkar, açık bağlantılar bitene kadar bekle, sonra kapat.

Metriği düğüm üzerinden ortalamak. Sekiz düğümün ortalama CPU'su %50 görünürken bir düğüm %100'de olabilir. Ortalama yerine doygunluk göstergelerine ve p95 değerlerine bak.

Ölçekleme olaylarını kaydetmemek. Ne zaman, hangi metrik yüzünden, kaç düğüm eklendiğini kaydetmiyorsan, bir hafta sonra faturayı açıkladığında elinde veri olmaz. Her ölçekleme kararı bir kayıt satırı üretmeli.

Sıkça Sorulan Sorular#

Otomatik ölçekleme her uygulama için uygun mu#

Hayır. Otomatik ölçekleme, trafiği belirgin biçimde dalgalanan ve durumsuz çalışabilen uygulamalar için anlamlıdır. Trafiği gün boyu kararlı seyreden bir kurumsal site için ek karmaşıklık getirir, hiçbir tasarruf sağlamaz. Uygulaman oturumu ya da dosyaları yerel diskte tutuyorsa, otomatik ölçekleme faydadan çok zarar verir; önce mimariyi durumsuzlaştırman gerekir.

CPU eşiği kaç olmalı#

Tek bir doğru değer yok ve çoğu web uygulaması için CPU zaten yanlış metrik. Yine de CPU kullanacaksan hedefi %60–70 aralığında tutmak makuldür; daha yükseği yeni düğüm hazır olana kadar geçen sürede kullanıcıyı yavaşlığa maruz bırakır, daha düşüğü gereksiz maliyet üretir. Mümkünse eşzamanlı istek sayısı ya da kuyruk derinliği gibi doygunluk metriklerine geç.

Otomatik ölçekleme kesintisiz mi çalışır#

Doğru kurulduğunda kullanıcı hiçbir şey fark etmez, ama bu kendiliğinden olmaz. Yeni düğüm sağlık kontrolünü geçmeden trafik almamalı, kapatılacak düğüm önce dengeleyiciden çıkarılıp açık bağlantıların bitmesi beklenmelidir. Bu iki adımdan biri eksikse kullanıcılar ölçekleme anlarında rastgele hatalarla karşılaşır.

Ölçek azaltma neden büyütmeden daha riskli#

Çünkü hata yönü asimetriktir. Gereğinden fazla sunucu çalıştırmanın bedeli birkaç saatlik ek ücrettir; gereğinden erken sunucu kapatmanın bedeli ise trafiğin kalan düğümlere yığılıp sitenin yavaşlaması, hatta zincirleme çökmesidir. Bu yüzden küçültme kararı daha uzun bir pencerede, daha düşük bir eşikte ve tek seferde tek düğüm olacak biçimde alınır.

Otomatik ölçekleme maliyeti gerçekten düşürür mü#

Trafiği belirgin dalgalanan iş yüklerinde evet, çünkü zirve kapasitesini 7/24 kiralamaktan kurtulursun. Ancak üst sınır koymadığında, salınıma izin verdiğinde ya da saatlik faturalamayı hesaba katmadığında maliyeti artırabilir. Tasarruf, doğru yapılandırmanın sonucudur; teknolojinin kendiliğinden getirdiği bir şey değildir.

Zamanlanmış ölçekleme mi metrik tabanlı ölçekleme mi daha iyi#

İkisi birbirinin alternatifi değil, tamamlayıcısıdır. Trafiğin ne zaman artacağını biliyorsan (kampanya, mesai başlangıcı, akşam saatleri) zamanlanmış kural ile önceden büyütmek, metrik tabanlı ölçeklemenin kaçınılmaz gecikmesini ortadan kaldırır. Metrik tabanlı kural ise tahmin edemediğin durumlar için güvenlik ağı olarak arkada çalışmaya devam eder.

Minimum düğüm sayısını 1 yapabilir miyim#

Teknik olarak yapabilirsin ama önermem. Minimum bir düğümle çalışan bir grup, o düğüm çöktüğü anda tamamen erişilemez hâle gelir ve yeni düğüm ayağa kalkana kadar site kapalı kalır. Minimum iki düğüm, hem tek hata noktasını ortadan kaldırır hem de ölçekleme sırasında her zaman trafik karşılayacak bir üye bulunmasını garanti eder.

Kapanış#

Otomatik ölçekleme, doğru kurulduğunda hem maliyeti hem gece uyanmalarını azaltan bir mekanizmadır; yanlış kurulduğunda ise faturayı ve hata oranını birlikte yükseltir. Aklında kalması gereken dört alışkanlık: CPU yerine doygunluk metriği seç, büyütmeyi hızlı küçültmeyi yavaş yap, her ölçekleme grubuna sert bir üst sınır koy ve düğüm kapatmadan önce mutlaka drain uygula.

Bu yapıyı kurarken tabanı sabit, esnek kısmı değişken tutmak isteyen ekipler için VDS ve bulut sunucu paketlerimiz birlikte iyi çalışır; ölçekleme politikalarının kurulumu, izleme ve uyarı zincirini bize devretmek istersen sunucu yönetimi hizmetimiz bu işi üstlenir, kampanya günlerinde önüne çıkan istenmeyen trafiği ayıklamak içinse DDoS koruma katmanını değerlendirebilirsin.