Azure VM Scale Sets ile Otomatik Ölçeklendirme

Tarafındankomut
0 Comments

Production ortamında bir uygulama çalıştırıyorsunuz ve gece yarısı trafik aniden 10 katına çıkıyor. Sunucularınız çöküyor, müşteriler şikayet ediyor, siz de telefonunuza bakıyorsunuz. Bu senaryoyu yaşadıysanız, Azure VM Scale Sets’in neden bu kadar değerli olduğunu anlayacaksınız. Otomatik ölçeklendirme artık bir lüks değil, modern altyapının temel gereksinimi.

Azure VM Scale Sets Nedir?

Azure VM Scale Sets (VMSS), aynı konfigürasyona sahip sanal makineleri bir grup olarak yönetmenizi sağlayan Azure servisidir. Tek bir VM’den farklı olarak, Scale Sets ile yük arttığında otomatik olarak yeni VM’ler devreye alınır, yük azaldığında ise gereksiz VM’ler kapatılarak maliyet optimize edilir.

VMSS’in temel avantajları şunlardır:

  • Otomatik ölçeklendirme: CPU, bellek veya özel metrikler bazında otomatik scale-out/scale-in
  • Yüksek erişilebilirlik: VM’ler farklı fault domain ve availability zone’lara dağıtılır
  • Maliyet optimizasyonu: Sadece ihtiyaç duyulan kapasite kadar kaynak kullanılır
  • Merkezi yönetim: Tüm instance’lar tek bir kaynak üzerinden yönetilir
  • Load balancer entegrasyonu: Azure Load Balancer veya Application Gateway ile native entegrasyon

Ön Gereksinimler

Başlamadan önce şunlara ihtiyacınız var:

  • Azure CLI kurulu ve giriş yapılmış bir terminal
  • Aktif Azure aboneliği
  • Temel Azure networking bilgisi (VNet, Subnet, NSG)

Azure CLI versiyonunuzu kontrol edin:

az version
az account show
az account set --subscription "SubscriptionName"

Temel VMSS Oluşturma

Önce bir resource group ve gerekli ağ altyapısını oluşturalım:

# Resource group oluştur
az group create 
  --name rg-vmss-production 
  --location westeurope

# VNet ve subnet oluştur
az network vnet create 
  --resource-group rg-vmss-production 
  --name vnet-production 
  --address-prefix 10.0.0.0/16 
  --subnet-name subnet-vmss 
  --subnet-prefix 10.0.1.0/24

# Network Security Group oluştur
az network nsg create 
  --resource-group rg-vmss-production 
  --name nsg-vmss

# HTTP ve SSH kurallarını ekle
az network nsg rule create 
  --resource-group rg-vmss-production 
  --nsg-name nsg-vmss 
  --name allow-http 
  --protocol tcp 
  --priority 1000 
  --destination-port-range 80 443 
  --access allow

az network nsg rule create 
  --resource-group rg-vmss-production 
  --nsg-name nsg-vmss 
  --name allow-ssh 
  --protocol tcp 
  --priority 1001 
  --destination-port-range 22 
  --access allow

Şimdi asıl VMSS’i oluşturalım. Burada Ubuntu tabanlı bir web sunucusu kuruyoruz:

az vmss create 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --image Ubuntu2204 
  --vm-sku Standard_D2s_v3 
  --instance-count 2 
  --admin-username azureuser 
  --generate-ssh-keys 
  --vnet-name vnet-production 
  --subnet subnet-vmss 
  --nsg nsg-vmss 
  --lb-sku Standard 
  --public-ip-address pip-vmss-lb 
  --upgrade-policy-mode automatic 
  --custom-data cloud-init.txt 
  --zones 1 2 3

--zones 1 2 3 parametresi VM’leri üç availability zone’a dağıtır. Production ortamında bu parametreyi her zaman kullanın. --upgrade-policy-mode automatic ise image güncellemelerinin otomatik uygulanmasını sağlar.

Cloud-Init ile VM Hazırlama

VMSS’deki her yeni VM instance’ının uygulama kurulu ve hazır şekilde başlaması gerekir. Bunun için cloud-init kullanıyoruz:

cat > cloud-init.txt << 'EOF'
#cloud-config
package_update: true
package_upgrade: true
packages:
  - nginx
  - htop
  - curl

write_files:
  - owner: www-data:www-data
    path: /var/www/html/index.html
    content: |
      <html>
        <body>
          <h1>VM Scale Set Instance</h1>
          <p>Hostname: $(hostname)</p>
        </body>
      </html>

runcmd:
  - systemctl enable nginx
  - systemctl start nginx
  - echo "$(hostname)" > /var/www/html/hostname.txt
  - curl -s http://169.254.169.254/metadata/instance?api-version=2021-02-01 -H "Metadata:true" | python3 -c "import json,sys; d=json.load(sys.stdin); open('/var/www/html/instance-info.txt','w').write(d['compute']['name'])"

final_message: "VMSS instance hazir, sure: $UPTIME saniye"
EOF

Bu cloud-init dosyası her yeni instance açıldığında nginx kurar, başlatır ve temel bir web sayfası oluşturur. Gerçek dünyada burada uygulamanızın kurulum scriptini veya Ansible playbook çağrısını yaparsınız.

Otomatik Ölçeklendirme Kuralları

VMSS’in kalbi olan autoscale ayarlarını şimdi yapılandıralım. CPU bazlı basit bir kural ile başlayalım:

# Autoscale profili oluştur
az monitor autoscale create 
  --resource-group rg-vmss-production 
  --resource vmss-webfarm 
  --resource-type Microsoft.Compute/virtualMachineScaleSets 
  --name autoscale-vmss-webfarm 
  --min-count 2 
  --max-count 10 
  --count 2

# Scale-out kuralı: CPU %70 üzerine çıkarsa instance ekle
az monitor autoscale rule create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --condition "Percentage CPU > 70 avg 5m" 
  --scale out 2 
  --cooldown 5

# Scale-in kuralı: CPU %25 altına düşerse instance kaldır
az monitor autoscale rule create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --condition "Percentage CPU < 25 avg 10m" 
  --scale in 1 
  --cooldown 10

Burada dikkat edilmesi gereken birkaç nokta var. Scale-out işleminde 2 instance birden ekliyoruz çünkü yük aniden geldiğinde tek instance yetmeyebilir. Scale-in işleminde ise birer birer kaldırıyoruz, ani kapasite düşüşü yaşamamak için. Cooldown süreleri de önemli: scale-out için 5 dakika yeterli iken, scale-in için 10 dakika bekliyoruz çünkü yükün gerçekten düştüğünden emin olmak istiyoruz.

Zamanlama Bazlı Ölçeklendirme

CPU metrikleri dışında, öngörülebilir trafik patternleri için zamanlama bazlı ölçeklendirme çok daha etkilidir. Örneğin e-ticaret siteniz her sabah 09:00’da canlanıyor, gece 23:00’da sakinleşiyorsa:

# Mesai saatleri için profil (hafta içi 08:00-18:00)
az monitor autoscale profile create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --name "business-hours-profile" 
  --timezone "Turkey Standard Time" 
  --recurrence week mon tue wed thu fri 
  --start 08:00 
  --end 18:00 
  --min-count 4 
  --max-count 15 
  --count 4

# Gece profili
az monitor autoscale profile create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --name "off-hours-profile" 
  --timezone "Turkey Standard Time" 
  --recurrence week mon tue wed thu fri 
  --start 18:00 
  --end 08:00 
  --min-count 2 
  --max-count 6 
  --count 2

# Hafta sonu profili - minimum kapasitede tut
az monitor autoscale profile create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --name "weekend-profile" 
  --timezone "Turkey Standard Time" 
  --recurrence week sat sun 
  --start 00:00 
  --end 23:59 
  --min-count 1 
  --max-count 4 
  --count 1

Bu konfigürasyonla hafta içi mesai saatlerinde en az 4 instance garantilenirken, gece ve hafta sonları maliyet optimize edilmiş şekilde çalışılıyor. Bunu geçen ay bir müşteri projesinde uyguladık ve aylık Azure faturasında yaklaşık %30 düşüş gördük.

Rolling Update ve Instance Yönetimi

VMSS’in en pratik özelliklerinden biri rolling update desteğidir. Uygulama güncellemesi yaparken tüm instance’ları aynı anda kapatmak yerine sırayla güncelleyebilirsiniz:

# VMSS güncelleme politikasını kontrol et
az vmss show 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --query "upgradePolicy" 
  --output json

# Rolling update politikasını yapılandır
az vmss update 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --set upgradePolicy.mode=Rolling 
  --set upgradePolicy.rollingUpgradePolicy.maxBatchInstancePercent=25 
  --set upgradePolicy.rollingUpgradePolicy.maxUnhealthyInstancePercent=20 
  --set upgradePolicy.rollingUpgradePolicy.maxUnhealthyUpgradedInstancePercent=20 
  --set upgradePolicy.rollingUpgradePolicy.pauseTimeBetweenBatches=PT2M

# Manuel olarak belirli instance'ları güncelle
az vmss update-instances 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --instance-ids 0 1

# Tüm instance'ları güncelle
az vmss update-instances 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --instance-ids "*"

maxBatchInstancePercent=25 değeri, güncelleme sırasında aynı anda toplam instance’ların %25’inden fazlasının güncellenmeyeceğini belirtir. 8 instance’lı bir kurulumda bu demek oluyor ki en fazla 2 instance aynı anda güncelleniyor ve servis kesintisiz devam ediyor.

Instance Durumu İzleme ve Sorun Giderme

Günlük operasyonlarda VMSS instance’larını izlemek için kullandığım komutlar:

# Tüm instance'ları listele ve durumlarını gör
az vmss list-instances 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --output table

# Belirli bir instance'ın detaylı bilgisi
az vmss get-instance-view 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --instance-id 0

# Instance sağlık durumunu kontrol et
az vmss list-instances 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --query "[].{Name:name, State:provisioningState, Power:instanceView.statuses[1].displayStatus}" 
  --output table

# Sorunlu instance'ı yeniden başlat
az vmss restart 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --instance-ids 3

# Sorunlu instance'ı sil (yenisi otomatik oluşturulur)
az vmss delete-instances 
  --resource-group rg-vmss-production 
  --name vmss-webfarm 
  --instance-ids 3

# Autoscale aktivite loglarını görüntüle
az monitor activity-log list 
  --resource-group rg-vmss-production 
  --resource-id $(az vmss show --resource-group rg-vmss-production --name vmss-webfarm --query id -o tsv) 
  --start-time 2024-01-01T00:00:00Z 
  --query "[?operationName.value=='Microsoft.Insights/AutoscaleSettings/Scaleup/Action' || operationName.value=='Microsoft.Insights/AutoscaleSettings/Scaledown/Action'].{time:eventTimestamp, operation:operationName.value, status:status.value}" 
  --output table

Gerçek Dünya Senaryosu: Black Friday Hazırlığı

Geçen yıl büyük bir e-ticaret müşterisi için Black Friday altyapısını hazırladık. Normal günlerde 4 instance yeterliyken, kampanya döneminde 40-50 instance’a çıkmak gerekiyordu. Hem zamanlama hem de metrik bazlı hibrit bir yaklaşım kullandık:

#!/bin/bash
# black-friday-prep.sh

RESOURCE_GROUP="rg-ecommerce-prod"
VMSS_NAME="vmss-ecommerce"
AUTOSCALE_NAME="autoscale-ecommerce"

echo "Black Friday profili olusturuluyor..."

# Kampanya oncesi hazirlik: 1 gun once kapasiteyi artir
az monitor autoscale profile create 
  --resource-group $RESOURCE_GROUP 
  --autoscale-name $AUTOSCALE_NAME 
  --name "pre-blackfriday" 
  --timezone "Turkey Standard Time" 
  --start "2024-11-28T22:00:00" 
  --end "2024-11-29T08:00:00" 
  --min-count 15 
  --max-count 15 
  --count 15

# Black Friday ana profil
az monitor autoscale profile create 
  --resource-group $RESOURCE_GROUP 
  --autoscale-name $AUTOSCALE_NAME 
  --name "blackfriday-peak" 
  --timezone "Turkey Standard Time" 
  --start "2024-11-29T08:00:00" 
  --end "2024-11-30T02:00:00" 
  --min-count 20 
  --max-count 60 
  --count 20

# Black Friday icin agresif scale-out kurallari
az monitor autoscale rule create 
  --resource-group $RESOURCE_GROUP 
  --autoscale-name $AUTOSCALE_NAME 
  --profile-name "blackfriday-peak" 
  --condition "Percentage CPU > 60 avg 3m" 
  --scale out 5 
  --cooldown 3

az monitor autoscale rule create 
  --resource-group $RESOURCE_GROUP 
  --autoscale-name $AUTOSCALE_NAME 
  --profile-name "blackfriday-peak" 
  --condition "Percentage CPU < 30 avg 15m" 
  --scale in 2 
  --cooldown 15

echo "Kampanya sonrasi normal profile donecek, mevcut profil devrede kalacak"
echo "Profil tamamlandi. VMSS hazir."

Bu yaklaşımın güzelliği şu: kampanya başlamadan 2 saat önce 15 instance ayağa kaldırıyoruz ve warmup süresini tamamlamalarını bekliyoruz. Kampanya başladığında zaten hazır durumdalar. Ani spike geldiğinde ise hızlıca 60’a kadar çıkabiliyorlar.

Spot Instance ile Maliyet Optimizasyonu

VMSS’de Spot instance kullanmak, batch işler veya stateless uygulamalar için maliyet açısından büyük avantaj sağlar. Spot instance’lar normal fiyatın %60-80 altında olabilir:

# Spot instance destekli VMSS oluştur
az vmss create 
  --resource-group rg-vmss-production 
  --name vmss-batch-workers 
  --image Ubuntu2204 
  --vm-sku Standard_D4s_v3 
  --instance-count 0 
  --admin-username azureuser 
  --generate-ssh-keys 
  --priority Spot 
  --eviction-policy Deallocate 
  --max-price 0.05 
  --single-placement-group false 
  --lb "" 
  --public-ip-address ""

# Spot instance'lar icin autoscale: is varsa calistir, yoksa sifira indir
az monitor autoscale create 
  --resource-group rg-vmss-production 
  --resource vmss-batch-workers 
  --resource-type Microsoft.Compute/virtualMachineScaleSets 
  --name autoscale-batch-workers 
  --min-count 0 
  --max-count 20 
  --count 0

--eviction-policy Deallocate seçeneği, Azure’un Spot kapasitesine ihtiyaç duyduğunda instance’ları silmek yerine deallocate etmesini sağlar. Bu sayede veriler korunur. --max-price 0.05 ile saatlik maksimum fiyat belirliyoruz, bu fiyat aşılırsa Azure instance’ı deallocate ediyor.

Monitoring ve Alerting

VMSS’i production’da çalıştırırken monitoring olmadan körü körüne uçmak gibidir. Temel alert’leri kuralım:

# Action group oluştur (email bildirimi için)
az monitor action-group create 
  --resource-group rg-vmss-production 
  --name ag-vmss-alerts 
  --short-name vmssalerts 
  --action email oncall-team [email protected]

# Instance sayisi maksimuma ulastiginda uyar
az monitor metrics alert create 
  --resource-group rg-vmss-production 
  --name "alert-vmss-max-capacity" 
  --scopes $(az vmss show -g rg-vmss-production -n vmss-webfarm --query id -o tsv) 
  --condition "avg Percentage CPU > 85" 
  --window-size 5m 
  --evaluation-frequency 1m 
  --action ag-vmss-alerts 
  --description "VMSS CPU yuksek, kapasite sinira yaklasiliyor olabilir"

# Basarisiz instance provision alert
az monitor activity-log alert create 
  --resource-group rg-vmss-production 
  --name "alert-vmss-provision-failure" 
  --scopes /subscriptions/$(az account show --query id -o tsv)/resourceGroups/rg-vmss-production 
  --condition category=Administrative operationName=Microsoft.Compute/virtualMachineScaleSets/write status=Failed 
  --action-group $(az monitor action-group show -g rg-vmss-production -n ag-vmss-alerts --query id -o tsv) 
  --description "VMSS provision basarisiz oldu"

Yaygın Sorunlar ve Çözümleri

Production’da VMSS yönetirken karşılaşılan tipik sorunlar ve çözümleri:

Scale-out çalışmıyor gibi görünüyor:

  • Autoscale rule’daki cooldown süresi henüz dolmamış olabilir
  • az monitor autoscale show komutuyla mevcut profili ve son aksiyon zamanını kontrol edin
  • Azure portalda Autoscale run history’ye bakın

Yeni instance’lar healthy olmuyor:

  • Cloud-init veya custom script extension’da hata olabilir
  • Instance’ın boot diagnostics loglarını kontrol edin: az vmss get-instance-view --instance-id X
  • Load balancer health probe ayarlarını gözden geçirin

Instance’lar beklenenden yavaş ayağa kalkıyor:

  • VM image’ı çok büyük olabilir, custom image kullanmayı düşünün
  • Cloud-init script’inde paket indirme süresi uzun olabilir
  • Pre-provisioned custom image kullanmak başlangıç süresini dramatik şekilde kısaltır

Maliyet beklentiden yüksek:

  • Scale-in kurallarının düzgün çalıştığını doğrulayın
  • Minimum instance count’un gece için de optimize edildiğinden emin olun
  • Deallocated instance’lar için bile disk maliyeti devam ettiğini unutmayın

Custom Metrik ile Gelişmiş Ölçeklendirme

CPU ve bellek dışında uygulamaya özel metrikler de kullanabilirsiniz. Örneğin bir queue işleyici için queue derinliğine göre scale:

# Application Insights custom metric bazli autoscale
az monitor autoscale rule create 
  --resource-group rg-vmss-production 
  --autoscale-name autoscale-vmss-webfarm 
  --condition "customMetricNamespace == 'app/queue' and metricName == 'QueueDepth' and metricResourceId == '/subscriptions/.../queues/mainqueue' > 100 avg 5m" 
  --scale out 3 
  --cooldown 5

Bu özelliği kullanmak için uygulamanızın Azure Monitor’a custom metrik göndermesi gerekiyor. Application Insights SDK veya Azure Monitor REST API ile bunu yapabilirsiniz.

Sonuç

Azure VM Scale Sets, doğru kurulduğunda gerçekten “gece uyumanızı sağlayan” bir teknolojidir. Hem otomatik ölçeklendirme hem de yüksek erişilebilirlik konusunda sağlam bir temel sunar. Ancak birkaç kritik noktanın altını çizmek gerekiyor:

Öncelikle minimum instance sayısını asla sıfır bırakmayın, üretim ortamlarında en az 2 instance tutun. Bir instance güncelleme veya hata alırken diğeri ayakta kalsın.

Cooldown sürelerini iyi ayarlayın. Çok kısa cooldown “scale-out, scale-in, scale-out” döngüsüne yol açar ve maliyeti artırır. Çok uzun cooldown ise gerçek yük artışlarına geç tepki vermek demektir.

Custom image kullanın. Cloud-init ile her seferinde paket yüklemek yerine, gerekli tüm yazılımların kurulu olduğu bir custom image oluşturun. Başlangıç süresi 5 dakikadan 90 saniyeye düşebilir.

Son olarak, test edin. Chaos Engineering mantığıyla production benzeri bir ortamda load test yapın, scale-out ve scale-in davranışlarını gözlemleyin. Black Friday’de değil, öncesinde sürprizlerle karşılaşın.

VMSS, modern bulut altyapısının vazgeçilmez parçası haline geldi. Doğru konfigüre edilmiş bir VMSS kurulumu, hem müşterilerinize kesintisiz hizmet sağlar hem de bütçenizi kontrol altında tutar. İlk kurulum biraz zaman alabilir ama uzun vadede kazandırdığı operasyonel rahatlık kesinlikle değer.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir