Cloud Spot Instance: %70-90 İndirim mi, Risk mi? Net Karar Rehberi

Cloud sağlayıcıları veri merkezlerindeki atıl kapasiteyi "spot" adıyla piyasaya sürer — normal fiyatının çok altında, ama istediği zaman geri alabilir. Bu denklemi doğru okuyanlar için spot instance ciddi bir maliyet avantajıdır; yanlış okuyanlar için ise gece yarısı kapanan bir sunucu ve yarıda kalan işler demektir. Bu rehberde somut rakamlar, gerçek kesinti oranları ve hangi iş yükünün spot'a uyup uymadığını doğrudan söyleyen bir karar çerçevesi bulacaksınız.

Spot Instance Nedir ve Neden Bu Kadar Ucuz?

AWS, GCP ve Azure, veri merkezlerinde her zaman bir miktar kullanılmayan kapasite bulundurur. Bu kapasiteyi spot (AWS), Spot VM (GCP) veya Azure Spot adıyla düşük fiyata kiraya verirler. Talep arttığında — yani normal müşteri kapasiteye ihtiyaç duyduğunda — sağlayıcı bu instance'ı kısa uyarıyla (genellikle 2 dakika) kapatır.

İndirim oranları somut olarak şöyle seyir eder:

Örnek olarak AWS'de c5.xlarge (4 vCPU, 8 GB RAM) instance'ına bakalım. On-demand fiyatı yaklaşık $0.17/saat, aylık 720 saatte $122 tutar. Aynı instance'ın spot fiyatı $0.017–$0.05/saat arasında dalgalanır; aylık maliyet $12–$36 civarında kalır. Yani aynı hesaplama gücü için aylık $80–$110 tasarruf söz konusudur.

Spot Instance'ın Gerçekten Değer Verdiği İş Yükleri

Batch ve Kuyruk Tabanlı İşlemler

Spot instance'ın en sağlam kullanım alanı, başlangıç ve bitiş noktası net olan, kesintiye toleranslı iş yükleridir:

• Makine öğrenmesi model eğitimi: PyTorch veya TensorFlow ile her epoch sonunda checkpoint (kontrol noktası) yazılıyorsa, instance kapandığında eğitim kaldığı yerden devam eder. GPU instance'ları on-demand'de saatte $3–$5 tutarken spot ile $0.30–$1'e iner.
• Büyük veri işleme: Spark veya Flink cluster'larında worker node (işçi düğüm) kaybedildiğinde görev otomatik yeniden dağıtılır. Doğru yapılandırılmış bir cluster'da %80 maliyet düşüşü gerçekçidir.
• Video ve görüntü işleme: Render veya transcoding kuyruğu yönetiliyorsa, yarıda kesen instance'tan çıkan iş kuyruğa geri döner.
• CI/CD pipeline build'leri: Self-hosted GitHub Actions runner veya Jenkins agent olarak çalışan spot instance tamamen stateless'tır (durumsuz). Build başarısız olduğunda yeniden tetiklenir, veri kaybı yoktur.

Kapasite ve Performans Testleri

50 node'luk bir cluster'ı iki saatliğine test etmek on-demand ile $300 tutacaksa, spot ile $30–60'a iner. Test bitince cluster silinir. Hem maliyet hem de hız açısından spot bu senaryoda tartışmasız kazanır.

Spot Instance'ın Gerçek Riskleri

Aniden Kapatma (Interruption) Riski

En kritik risk, instance'ın önceden haber vermeden devre dışı bırakılmasıdır. AWS 2 dakika önceden bildirim gönderir — bu sürede checkpoint yazılmazsa çalışan her şey kaybolur.

AWS'nin yayımladığı verilere göre kesinti sıklığı bölgeye ve instance tipine göre büyük farklılık gösterir:

GPU instance'ları talebin yüksek ve arzın kısıtlı olduğu dönemlerde çok daha sık kesilir. Bir ML pipeline kurarken bunu hesaba katmak gerekir.

Fiyat Oynaklığı

Spot fiyatları saatlik değişir. AWS'de maksimum fiyat sınırı (max price) belirleyebilirsiniz; spot fiyatı bu eşiği geçtiğinde instance otomatik kapanır. Bütçe hesabı yaparken anlık değil, 7 günlük ortalama spot fiyatına bakın — AWS ve GCP bu veriyi konsol üzerinden sunar.

Durum Gerektiren İş Yüklerinde Veri Kaybı

Veritabanı sunucusu olarak spot instance kullanmak doğrudan veri bütünlüğü riskidir. Bağlantılar kopar, yazma işlemleri yarıda kesilir. Benzer şekilde aşağıdaki iş yükleri spot'a uygun değildir:

• Aktif kullanıcı oturumu tutan web uygulamaları
• Ödeme, form veya anlık veri yazan servisler
• NFS veya Samba dosya sunucusu

Kesinti Riskini Yönetmek için 4 Yöntem

1. Checkpointing

İş yükünün düzenli aralıklarla durumunu kalıcı depolamaya (S3, GCS, Azure Blob) yazması gerekir. 2 dakikalık uyarı penceresine güvenmek zorunda kalmazsınız:

# Her 10 epoch sonunda checkpoint S3'e yaz
if epoch % 10 == 0:
    torch.save(model.state_dict(), "s3://bucket/model_ckpt.pt")

2. Karışık Filo (Mixed Fleet)

AWS Auto Scaling Group veya GCP Managed Instance Group'ta on-demand ve spot karışımı tanımlanabilir. Örnek bir yapı:

• %20 on-demand — temel kapasite, her zaman ayakta
• %80 spot — maliyet optimizasyonu

Tüm spot instance'lar aynı anda kapansa bile on-demand tabakası ayakta kalır.

3. Çoklu Bölge ve Instance Tipi

Tek bir availability zone'da tek bir instance tipiyle çalışmak, o havuzun tükenmesinde her şeyi durdurur. AWS Spot Fleet, birden fazla instance tipi ve bölge üzerinden otomatik seçim yapar; biri kapandığında alternatife geçer.

4. Kesinti Bildirimi Handler

AWS metadata endpoint'ini polling ederek 2 dakikalık uyarıyı yakalamak mümkündür:

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

while true; do
  STATUS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/spot/termination-time)
  if [ "$STATUS" != "" ]; then
    echo "Spot kesintisi: $STATUS — checkpoint yazılıyor"
    # burada checkpoint tetiklenir
  fi
  sleep 5
done

Sağlayıcı Karşılaştırması: AWS, GCP, Azure

GCP'nin 30 saniyelik uyarı penceresi ve 24 saatlik ömür sınırı, batch iş yükleri için ek planlama gerektirir. AWS'nin 2 dakikası, basit bir checkpoint için yönetilebilir bir penceredir. Azure Spot ise fiyat açısından rekabetçi olmakla birlikte aynı 30 saniyelik pencereyle gelir.

Spot Kesinlikle Kullanmayın: Kırmızı Çizgiler

Şu senaryolarda spot instance kullanmak maliyeti değil, riski artırır:

• Üretim veritabanı (PostgreSQL, MySQL, MongoDB): Tek node ise asla spot
• SLA taahhüdü olan web servisi: Kesinti süreniz SLA ihlali yaratıyorsa spot değil
• Gerçek zamanlı işlem: Canlı yayın encode, borsa verisi işleme, anlık ödeme servisi
• Lisans bağlı yazılım: Instance kapandığında lisans aktivasyonu sorun çıkarabilir

Ne Zaman Spot Kullanmalı? Üç Soruluk Karar Çerçevesi

1. İş yükü kesintiye toleranslı mı? Hayır → Spot değil.

2. Durum kalıcı depolamaya yazılabiliyor mu? Hayır → Önce checkpointing mekanizması ekleyin, sonra değerlendirin.

3. İş yükü ne kadar sürecek?

Spot instance, doğru kullanıldığında yıllık bulut faturasını ciddi ölçüde düşüren güçlü bir araçtır. Yanlış kullanıldığında ise maliyet tasarrufu değil, veri kaybı ve sistem durması üretir. Karar noktası tek bir soruya iner: iş yükünüz, beklenmedik bir an sonlanmaya hazır mı? Cevap "evet" ise spot; "hayır" ise on-demand ya da reserved instance değerlendirin.