Cloud Spot Instance: Avantajlar, riskler ve net kullanım planı

Cloud Spot Instance, bulut altyapısında maliyeti düşürmek isteyen ekiplerin sık baktığı bir seçenektir. Ancak “daha ucuz” ifadesi, kesintilerin teknik olarak ne anlama geldiğini ve hangi mimaride sorun çıkarmayacağını bilmeden yanlış kararlara götürebilir. Bu rehberde Spot Instance mantığını, kesinti riskinin türlerini, ölçüm metriklerini ve kesintisiz çalışmayı hedefleyen pratik tasarım adımlarını net şekilde ele alıyorum. Son bölümde de hangi yükler için Spot kullanılır, hangilerinde kullanılmaz sorusunu somut kontrol maddeleriyle cevaplıyorum.

Spot Instance tam olarak ne demek?

Spot Instance (bulut sağlayıcıya göre değişen isimlerle: Spot VM / Spot capacity), talep azaldığında veya kapasite “boşta”yken daha düşük fiyata sunulan geçici kapasite modelidir. Bu kapasite, normal (On-Demand) sunuculardan farklı olarak sağlayıcının kaynak ihtiyacına göre kesilebilir.

Bu yüzden Spot Instance ile çalışırken iki gerçeği kabul etmeniz gerekir: - Fiyat avantajı vardır: Talep düştüğünde birim maliyet ciddi azalabilir. - Kapasite geri alınabilir: Sağlayıcı, belirli bir noktada instance’ı durdurma/sonlandırma kararı verebilir.

“Kesinti” beklentisi nasıl olmalı?

Spot kesintileri her zaman anlık “tamamen kapandı” şeklinde olmaz; sağlayıcı bazı senaryolarda ön bildirim (termination notice) verebilir. Yine de bu bildirim sürelerini ve davranışı planlamak gerekir.

Net hedef şu olmalı: “İşimi kaybetmeden devam edebilirim” veya “kayıp tolere edilebilir” olsun.

Avantajlar: Spot’u gerçek değer yapan şeyler

Spot Instance’ın avantajlarını tek bir başlıkta özetlemek yerine, maliyet ve işletme etkisi olarak ayırmak daha sağlıklı olur.

1) Birim maliyet düşüşü (en net avantaj)

Spot’un temel çekimi fiyattır. On-Demand ile karşılaştırıldığında aynı CPU/RAM profilinde daha düşük maliyetle çalışabilirsiniz. NetKıyas’ta kullanıcıların en çok sorduğu konu “oran” olduğundan, karar yaklaşımı şöyle olmalı: - Elde edeceğiniz kazanç, kesinti nedeniyle oluşacak iş kaybı/yeniden kurulum maliyetini geçiyorsa Spot mantıklıdır.

Pratik değerlendirme için şu formülü düşünün: - Net tasarruf = Spot maliyeti - (kesinti başına yeniden çalıştırma + veri kaybı maliyeti + operasyon süresi)

2) Büyük ölçekli, esnek işlerde kapasite bulma

Batch işler, derleme (build), kod testleri, log işleme gibi işlerde Spot “esneklik” sağlar. Aynı işi farklı zamanlarda dağıtabilen sistemler Spot’tan daha iyi yararlanır.

3) Otomasyon ve ölçekleme ile maliyeti optimize etme

Spot’un avantajı sadece “daha ucuz” değil; otomasyonla doğru kullanıldığında sisteminiz maliyeti sürekli optimize eder. Bu noktada tercih edilen yaklaşımlar: - Otomatik ölçekleme (autoscaling) - Kuyruk tabanlı iş dağıtımı (queue) - Stateless (durumsuz) servis tasarımı - Harici depolama (S3/Blob benzeri) ile kalıcılık

Riskler: Spot’u tehlikeli yapan teknik noktalar

Spot Instance riskleri tek başlık değildir; her biri farklı mimari karar gerektirir.

1) Beklenmedik kesinti ve çalışma kaybı

En temel risk, instance’ın sonlandırılmasıdır. Bu durumda: - Uygulamanın RAM/yerel disk üzerinde tuttuğu durum kaybolabilir. - Süreçler yarım kalabilir. - Servis kesintisi yaşanabilir.

Net kural: Spot kullanacağınız iş, kesintiyi tolere edebilecek tasarımda olmalı.

2) Ön bildirim (termination notice) her zaman “yeterli süre” değildir

Bazı bulutlar kesinti öncesi kısa süreli bir bildirim verebilir. Ancak bu süre, yaptığınız işe göre değişir: - Yüksek veri işleyen işlemlerde geri alma/temiz kapatma yeterli olmayabilir. - “Durmadan önce kaydet” yaklaşımı mutlaka test edilmelidir.

3) Veri kalıcılığı (durable storage) yoksa sorun büyür

Local disk’te tutulan veriler kesinti sonrası geri gelmeyebilir. Bu yüzden veri kalıcılığı için: - Nesne depolama (S3/R2/B2 benzeri) - Yönetilen veritabanı (Managed DB) - Kapsayıcı/pipeline içinde tekrar üretebilirlik (reproducibility)

şarttır.

4) IP, oturum ve kimlik doğrulama gibi durumlar

Spot ile gelen instance değişimi, şu alanlarda değişiklik yaratabilir: - Dinamik IP değişimi - Sunucuya bağlı oturumların bozulması - Load balancer arkasında yeni instance yönetimi

Bu risk, özellikle web uygulamalarında “sessiz” şekilde performans düşüşü olarak görülebilir. Net çözüm: oturumu instance’ta değil, paylaşılan katmanda yönetmek (session store vb.).

5) Kapasite bulma (kimin bulduğu, kimin beklediği)

Spot her zaman hemen alınamayabilir. Arz/talep dengesine göre: - Bekleme süresi uzayabilir - Aynı tür kapasiteye her zaman ulaşılamayabilir

Bu durum, iş zamanlaması yapan ekiplerde (ör. akşam 22:00’de job bitmeli) planlama hatası üretir.

Spot Instance için doğru mimariyi seçme

Spot’ta riskleri azaltan en önemli şey, tasarımın kesintiye uyumlu olmasıdır. Aşağıdaki kontrol maddeleri “tek seferde” karar vermeyi kolaylaştırır.

Kullanım için “net uygun” senaryolar

Aşağıdaki iş yükleri Spot için tipik olarak uygundur: - Batch (toplu) işler: log analizi, ETL, derleme (CI build) - State’i dışarıda tutan servisler: durumsuz web worker’lar - Kuyruk tabanlı işleme: her job idempotent (tekrar çalıştırılabilir) ise - Yeniden üretilebilir işler: sonuçlar yeniden hesaplanabiliyorsa - Paralelleştirilebilen işler: ölçek arttıkça toplam süre düşüyorsa

Kullanım için “net riskli/uygunsuz” senaryolar

Aşağıdaki senaryolarda Spot kullanımı ciddi mimari yeniden tasarım gerektirir: - Veri kaybını tolere edemeyen, anlık tutarlılık gerektiren canlı sistemler - Oturumu instance üzerinde tutan uygulamalar - “Tek server üzerinden sürekli çalışan” ve yeniden başlatma maliyeti çok yüksek yapılar - Senkron kullanıcı deneyimi odaklı servisler (kesinti hissi ciddi problem yaratır)

Kesinti riskini azaltan net uygulama adımları

Aşağıda Spot Instance kullanırken pratikte en çok işe yarayan adımları veriyorum. Hepsinin ortak hedefi: kesinti olduğunda işin kaybolmaması ve toparlama süresinin kısa kalması.

1) State’i instance dışına taşı

Spot durdurulsa bile işin devam etmesini istiyorsanız, state’i şu katmanlarda tutun: - Kuyruk (queue) ve job durumu - Nesne depolama (outputları burada saklayın) - Managed DB (ör. uygulama verisi)

Net hedef: Instance kapansa bile job yeniden başlayabilsin.

2) Job’ları idempotent yap

Aynı işi tekrar çalıştırınca sonuç aynı kalıyorsa, Spot kesintisi çok daha yönetilebilir olur.

• Her job için unique iş anahtarı (id) kullanın.
• “Daha önce işlendi mi?” kontrolü yapın.
• Çıktı yazarken atomik güncelleme veya yazım politikasını belirleyin.

3) Otomatik ölçekleme + kapasite stratejisi kur

Kapasite gelmediğinde iş birikebilir. Bunu önlemek için: - Queue uzunluğu ile ölçekleme (workers) - Maksimum bekleme süresi tanımı - On-Demand/Reserved gibi yedek kapasite planı

Kritik karar: “Spot kapasite bulamadığında işin SLA’ı (hizmet seviyesi) bozuluyor mu?” - Bozuluyorsa hibrit mimari kurun.

4) Sonlandırma ön bildirimi (termination notice) ile graceful shutdown

Eğer sağlayıcınız sonlandırma ön bildirimi veriyorsa, bu bildirimi yakalayıp: - İşin checkpoint (kontrol noktası) verisini yazmasını sağlayın - Yarıda kalan adımları iş kuyruğuna geri bırakın - Logları merkezi sisteme aktarıp sonra çıkın

şeklinde aksiyon alın.

5) İzleme (monitoring) ve alert kurgusunu netleştir

Spot kesintileri “normal” sayılabileceği için, izleme sadece uptime’a değil yeniden denemelere odaklanmalı.

Ölçmeniz gereken net metrik örnekleri: - Instance churn oranı (birim zamanda kesilen instance sayısı) - Worker yeniden başlatma sayısı - Job failure rate - Queue backlog (iş kuyruğu birikimi) - Ortalama job tamamlama süresi ve tail latency (yükün en zor kısmı)

6) Maliyet kontrolü için maliyet metrikleri + limitler

Spot ile maliyet düşerken kontrolsüz kullanımda sürpriz artışlar görülebilir. Net yaklaşım: - Worker sayısı için maksimum sınır - Job başına maliyet tahmini - Ay sonu sürprizlerini engellemek için bütçe/limit alarmları

Spot vs On-Demand: Net karar modeli

Spot’un mantıklı olup olmadığını anlamanın hızlı yolu “maliyet + toparlama” dengesidir.

Aşağıdaki tablo, karar çerçevesini pratik hale getirir:

Türkiye’de ekiplerin yaptığı 3 tipik hata ve net düzeltme

Hata 1: “Ucuza aldık, sorun olmaz” yaklaşımı

Spot için doğru tasarım yoksa kesintiler hızla maliyeti geri alır. Net düzeltme: Job idempotentliği ve queue/checkpoint zorunlu bir adımdır.

Hata 2: Local disk ile kalıcılık varsayımı

Local disk yaklaşımı, kesinti sonrası verinin geri gelmemesi nedeniyle pahalı hale gelir. Net düzeltme: çıktıları nesne depolamada saklayın, DB katmanını yönetilen servis kullanın.

Hata 3: İzleme sadece instance sağlığına bakar

Instance sağlığına bakmak tek başına yeterli değildir. Spot kesintisi “beklenen” olduğundan, asıl metrik iş tamamlanması ve backlog olmalıdır. Net düzeltme: job success/failure ve queue backlog alarmları tanımlayın.

Sonuç: Spot’u kullanın ama net şartlarla kullanın

Cloud Spot Instance, doğru iş yüklerinde ciddi maliyet avantajı sağlar. Ancak kesinti riski “sadece teknik detay” değil; mimari kararların sonucudur. Bu rehberdeki kontrol maddelerini uygulayın: state’i instance dışına taşıyın, job’ları idempotent tasarlayın, termination bildirimine göre graceful shutdown ekleyin ve maliyeti queue/backlog metrikleriyle birlikte yönetin.

Aksiyon önerisi: Önce tek bir batch işini (ör. CI build worker veya log işleme) Spot ile çalıştırıp kesinti oranı, job başarısı ve ortalama toparlanma süresini ölçün. Bu ölçüm netleşince Spot’u ilgili üretim işlerine kademeli yaygınlaştırın.