Auto-scaling nedir? Cloud’da VDS/VPS ile kurulumu

Auto-scaling, uygulamanın yük artınca otomatik olarak kapasite ekleyip yük düşünce kapasiteyi azaltmasıdır. Doğru kurulmadığında maliyet artar, yanlış metrik seçildiğinde ise “salınım” (scale-up/scale-down döngüsü) yaşanır. Bu rehberde auto-scaling mantığını, hangi metriklerin doğru olduğunu ve Cloud ortamında (load balancer + birden fazla instance) pratik kurulum adımlarını net şekilde öğreneceksiniz.

Auto-scaling nedir ve neden tek başına “VDS büyütmek” değildir?

Auto-scaling (otomatik ölçekleme), belirlediğiniz kurallara göre sunucu sayısını veya instance boyutunu otomatik değiştirir. Mantık şudur: Sisteminizin iş yükü belirli bir eşiği aşınca yeni instance’lar devreye girer; iş yükü düştüğünde instance’lar azaltılır.

Tek bir VDS’yi sürekli yükseltmek yerine auto-scaling şunları hedefler: - Yük piklerinde kesintiyi önleme: Trafik aniden artınca kapasite gecikmeden eklenir. - Boş kapasiteyi azaltma: Düşük kullanım döneminde maliyeti düşürürsünüz. - Hata toleransı: Bir instance problem yaşarsa trafik diğerlerine dağıtılır.

Auto-scaling hangi “katmanda” yapılır?

Auto-scaling iki yaygın şekilde uygulanır: 1. Instance sayısı (scale out/in): Aynı konfigürasyondan birden fazla instance çalışır; yük dengeleyici önlerinde durur. 2. Ölçek/worker sayısı (uygulama seviyesinde): Örneğin queue worker sayısı otomatik arttırılır. (Bu rehberde ana odak instance ölçeklemedir.)

Önemli nokta: Auto-scaling yalnızca “yeni sunucu açma” değildir. Gerçek fayda, trafiğin load balancer (yük dengeleyici) üzerinden doğru instance’lara dağıtılması ve instance’ların hazır olduğunun anlaşılmasıyla ortaya çıkar.

Net karar: Hangi metrikle ölçeklemelisiniz?

Auto-scaling kuralı yazarken en sık hata, CPU kullanımına körü körüne dayanıp ölçeklemektir. CPU yükselmesi her zaman “trafik arttı” demek değildir; CPU düşükken de örneğin veritabanı darboğazı yüzünden istekler uzayabilir.

Aşağıdaki metrikler, tipik web uygulamaları için daha anlamlıdır: - CPU kullanım yüzdesi: Basit ve hızlı sinyal. - Request rate (istek hızı): Trafik artışını doğrudan yansıtır. - Response time / latency (yanıt süresi): Kullanıcı deneyimi ile birebir ilişkilidir. - Kuyruk (queue) uzunluğu: Background işlerde (e-posta, resim işleme, sipariş işleme) net sinyaldir. - Health check (sağlık kontrolü) durumu: Bozuk instance trafiğe alınmaz.

Aşağıdaki tablo, farklı uygulama senaryolarında “varsayılan” yaklaşımı özetler:

Scale-down (azaltma) ayarı niçin kritiktir?

Ölçekleme yalnızca artırma değil, azaltma tarafında da maliyeti belirler. Yanlış scale-down ayarı şu probleme yol açar: - Instance sayısı azalmaya başlar. - Trafik azalmamıştır; sistem tekrar yavaşlar. - Otomatik tekrar scale-up olur.

Bunu önlemek için: - Scale-down cool-down süresi ekleyin. - Ölçeklemeyi anlık tek ölçüme değil, kısa bir zaman aralığına (ör. 1-5 dakika ortalaması) bağlayın.

Cloud ortamında auto-scaling mimarisi: Minimum sağlam kurulum

Auto-scaling doğru çalışması için temel parçalar şunlardır: 1. Bir load balancer: Trafiği instance’lara dağıtır. 2. Birden fazla instance (VDS/VPS): Aynı uygulama çalışır. 3. Paylaşımlı veya dışarı taşınmış durum (state): Oturum, dosya, cache gibi veriler instance’larda bağımlı olmamalıdır. 4. Health check: Hazır olmayan veya hatalı instance trafiğe alınmaz. 5. Otomasyon (autoscaler): Instance sayısını kurala göre arttırır/azaltır.

State (durum) problemi: “Yatayda tutarlılık”

Auto-scaling yatay ölçekleme yapar. Yani istekler farklı instance’lara gidebilir. Bu yüzden: - Oturum (session) verisi instance’a bağlı olmamalı. - Dosya upload’lar instance diskinde kalmamalı. - Cache tutarlılığı için tasarım net olmalı.

Net öneriler: - Session için merkezi bir çözüm (ör. Redis) kullanın. - Upload için obje depolama mantığı (S3 uyumlu servis, cloud storage) ya da paylaşımlı depolama kullanın.

Adım adım: Load balancer + auto-scaling ile ölçekleme kurulum planı

Bu bölüm, Cloud’da (ör. VDS/VPS sağlayıcı cloud ortamı) tipik bir kurulum akışını verir. Sağlayıcı arayüzü değişebilir; mantık aynıdır.

1) Instance şablonu hazırlayın (aynı konfigürasyon)

Önce tek bir “çekirdek” instance hazırlayın: - Uygulama (web server + uygulama) - Güvenlik duvarı kuralları (LB’den gelen trafik) - Monitor/agent (varsa) - Health check endpoint’i (örn: /healthz)

Health check örneği (basit mantık): - Uygulama ayağa kalkınca HTTP 200 dönen endpoint. - Veritabanı bağlantısı gerekiyorsa, sadece uygulama “up” olduğunda 200 döndürün.

2) Instance’ların “hazır” olduğundan emin olun

Autoscaler instance’ları açar ama trafik gönderimi için load balancer’ın “healthy” sinyalini beklemesi gerekir. - Load balancer’da health check path belirleyin. - Health check aralığı ve eşiği ayarlayın (çok agresif yapmayın).

3) Load balancer ayarlarını yapın

LB tarafında net hedef: - Gelen HTTP/HTTPS trafiğini instance’lara yönlendirmek - “Sticky session” kullanmak yerine mümkün olduğunca state’i merkezileştirmek

Önerilen yaklaşım: - TLS/sertifika yönetimini merkezi yapın (LB tarafı). - Instance’lar sadece LB’den gelen trafiği kabul etsin.

4) Auto-scaling kuralını belirleyin (min/max ve metrik)

Aşağıdaki başlangıç değerleri, birçok web uygulaması için pratik bir başlangıç çerçevesidir: - Minimum instance: 2 (tek instance arızasında kesinti riskini düşürür) - Maksimum instance: Bütçeye göre (ör. 6-10) - Ölçekleme tetikleyicisi: - p95 latency veya request rate - Zaman penceresi: - 1-3 dakika ortalama - Cool-down: - scale-up için kısa (ör. 2-5 dk) - scale-down için daha uzun (ör. 5-15 dk)

5) Veritabanı/queue tasarımını ölçeklemeye uygun hale getirin

Instance sayısı artınca veritabanı veya queue da yüklenir. Auto-scaling yalnızca web katmanını artırır; DB bağımsız ölçeklenmiyorsa darboğaz olabilir. Net kontrol noktaları: - DB bağlantı havuzu (connection pool) boyutu instance sayısıyla birlikte artmalı. - Çoklu instance senaryosuna uygun migration/lock stratejisi olmalı. - Queue kullanıyorsanız worker instance sayısı ile uyumlu plan yapın.

Test ve doğrulama: Kurulumdan sonra “doğru çalışıyor” nasıl kanıtlanır?

Auto-scaling’te en büyük hata, kuralların yazılması ama sistemin davranışının ölçülmemesidir. Net test adımları:

Yük testi senaryoları

• Trafik piki testi: 10-15 dakika yüksek trafik simüle edin.
• Durum testi: Trafik düşerken scale-down’un ne zaman gerçekleştiğini gözleyin.
• Instance arızası testi: Bir instance’ı durdurun; LB’nin health check ile trafikten çekip çekmediğini doğrulayın.

İzlenecek metrikler

• Instance sayısı değişimi (scale event)
• Response time (özellikle p95)
• Error rate (HTTP 5xx)
• LB sağlıklı instance sayısı
• DB/queue metrikleri (bağlantı, CPU, kuyruk uzunluğu)

Bu metriklerden sadece CPU’ya bakarsanız yanıltıcı sonuç alırsınız. Örneğin latency yükseliyorken CPU düşük kalabilir (veritabanı beklemesi gibi).

Maliyet kontrolü: Auto-scaling maliyeti nasıl yönetilir?

Auto-scaling, maliyeti azaltmak için kurulur; ancak yanlış sınırlar maliyeti artırır. Net maliyet yönetim adımları: - Maksimum instance limit tanımlayın. - Scale-up cool-down’u çok kısa yapmayın. - Trafik metrikleri ile ölçekleyin; CPU tek başına “her zaman” doğru değildir. - Gece/hafta sonu için farklı ölçek profilleri (saat bazlı kural) uygulayın.

Ek olarak bant genişliği ve yük dengeleme maliyetlerini ayrı kalem olarak düşünün. Instance sayısı artarken sadece compute değil, trafik maliyeti de yükselir.

Yaygın hatalar ve net düzeltmeler

Aşağıdaki hatalar, auto-scaling kurulumlarında en sık görülür:

1) Yanlış metrik: CPU’dan ölçekleme

Belirti: Trafik artınca latency yükseliyor ama scale tetiklenmiyor. Düzeltme: Request rate veya p95 latency ile kuralı güncelleyin.

2) Health check zayıf tanımlanmış

Belirti: Hazır olmayan instance trafiğe giriyor; 5xx artıyor. Düzeltme: /healthz endpoint’ini uygulamanın gerçekten çalıştığı anı yansıtacak şekilde düzenleyin.

3) State instance diskinde

Belirti: Ölçek artınca bazı kullanıcılar oturumu kaybediyor, upload’lar “kayboluyor” gibi görünüyor. Düzeltme: Session ve upload’ı merkezi/harici depolara taşıyın.

4) Scale-down çok hızlı

Belirti: Instance sayısı sık sık artıp azalıyor; hata oranı dalgalanıyor. Düzeltme: Scale-down cool-down’u uzatın ve daha uzun zaman penceresi kullanın.

Sonuç: Uygulamanız için net bir auto-scaling planı çıkarın

Auto-scaling’i başarıyla kurmak için tek adım “instance sayısını otomatik arttırmak” değildir. Önce load balancer + health check ile trafiği doğru instance’a yönlendirmeli, sonra latency/request rate gibi anlamlı metriklerle scale kuralını yazmalısınız. İlk etapta min 2 instance, maks limit ve p95 latency veya request rate temelli bir kural ile başlayın; ardından yük testiyle davranışı doğrulayın. Kurulumdan sonra 1-2 haftalık metrik gözlemi yapıp scale-up/scale-down zamanlarını ayarlayın.

İsterseniz NetKıyas’ta kullandığınız Cloud/VDS-VPS sağlayıcı türünü ve mevcut kaynak metriklerinizi (CPU, latency, istek sayısı) yazın; buna göre “min/max + metrik + cool-down” için net bir başlangıç değer seti önerebilirim.