Cloud Spot Instance: Avantajlar ve Riskler (Net Rehber)

Cloud spot instance (bulut spot örneği), aynı donanım türünde kiralama maliyetini düşürmek için kullanılan bir kapasite modelidir. Standart (on-demand) sunuculara göre daha ucuza çalışır; ancak sağlayıcı kapasiteyi geri çektiğinde aniden kesilebilir. Bu yazıda spot instance avantajlarını fiyat/performans ekseninde, risklerini ise kesinti yönetimi ve mimari dayanıklılığı üzerinden net şekilde ele alıyoruz. Sonunda, hangi iş yüklerinde spot kullanacağınızı ve hangi önlemlerle kesintiyi yönetebileceğinizi kontrol listesiyle belirlersiniz.

Spot instance neyi ifade eder? On-demand’tan farkı net mi?

Cloud spot instance, sağlayıcının atıl olmayan kapasitesini daha düşük fiyattan kiraladığı, fiyatın arz-talebe göre dalgalandığı bir hizmettir. Temel fark şudur: - On-demand: Kapasite süreklidir; fiyat daha yüksektir; kesinti beklenmez. - Spot instance: Daha ucuzdur; fakat kapasite geri çekildiğinde instance durur/sonlandırılır.

Spot modelin kritik tarafı şudur: Maliyet avantajı, “beklenmedik duruş” riskini kabullenmenize dayanır. Bu yüzden spot’u uygulama tasarımınızda bir “olası başarısızlık senaryosu” olarak ele almalısınız.

Spot fiyatı nasıl “risk”e dönüşür?

Fiyat düşse bile sağlayıcı kapasite ihtiyacı doğduğunda spot instance’ı sonlandırabilir. Yani iki ayrı etki vardır: 1. Fiyat dalgalanması (maliyet sürprizi) 2. Kapasite geri çekilmesi (kesinti sürprizi)

Bu nedenle spot instance’ta karar sadece “birim saat ucuz” değildir; kesinti olduğunda işi kaybetmeyecek bir sistem tasarlayıp tasarlamadığınızdır.

Avantajlar: Spot’u hangi senaryolarda gerçek değer yaratır?

Spot instance’ın getirisi, kesintiye tolerans gösterebilen iş yüklerinde somutlaşır. Aşağıdaki senaryolarda spot genellikle anlamlıdır: - Önbelleği yenilenebilen batch işler: Görsel yeniden boyutlandırma, rapor üretimi, ETL (extract-transform-load). - Paralel çalışma: Kuyruk üzerinde çalışan çok sayıda worker (ör. video transcode pipeline). - Durumu dışarıda tutan sistemler: Stateless (durumsuz) uygulamalar; state’i veri tabanı/queue üzerinde tutan tasarımlar. - Kısa ömürlü veya yeniden başlatılabilir servisler: CI/CD runner, test job’ları. - Yedekleme ve veri işleme: Tam yedekten incremental (artımlı) iş akışlarına geçildiğinde kesintiler genellikle yönetilebilir.

Net maliyet kazanımı nasıl hesaplanır?

Kesinti riskini “bütçeye” çevirmek gerekir. Pratik hesap şablonu: - Spot birim maliyeti: C_spot (ör. on-demand’ın %40-70’i seviyeleri) - On-demand maliyeti: C_od - Kesintiden sonra yeniden başlatma maliyeti: M_restart (süre, otomasyon, yeniden işleme) - Kesinti olduğunda iş kaybı maliyeti: M_loss (olası veri/iş kaybı)

Basit net kazanç: - Net tasarruf ≈ (C_od - C_spot) - M_restart - M_loss

Buradaki M_loss, “tasarımınız kayıp yaşamayacak mı?” sorusunun karşılığıdır.

Riskler: Spot’ta en sık görülen 7 problem

Spot instance avantajı kadar riskleri de nettir. Özellikle yeni başlayan ekipler şu başlıklarda hata yapar.

1) Kesinti aniden gelir

Instance durduğunda: - CPU/RAM üzerindeki geçici işlem durur - uygulama servisleri beklenmedik şekilde kesilir - bazı job’lar yarım kalabilir

Bu yüzden “kesinti olursa ne olur?” sorusuna uygulama seviyesinde cevap vermelisiniz.

2) Instance store / geçici disk verisi kaybolur

Bazı bulutlarda instance üzerindeki geçici disk veya geçici dosya sistemleri kesintide kalıcı olmaz. Bu durumda: - geçici dosyalar - cache katmanı - temporary output (ara çıktı)

… kalıcı olmayabilir.

3) IP adresi ve bağlantılar etkilenebilir

Instance yeniden kurulduğunda: - özel IP / public IP değişebilir - firewall kuralları güncellenmeden çalışmayabilir - load balancer arkasında otomasyon yoksa servis dışı kalabilir

4) Worker ölçeği tutarsızlaşır

Spot kaybı yaşandığında worker sayısı düşer. Bu da: - kuyruk (queue) birikmesine - gecikmenin artmasına - SLA hedeflerinin (hizmet seviyesi) kaçmasına yol açar.

5) Otomasyon eksikse “manuel toparlama” başlar

Kesinti tek seferlik değil, döngüsel olabilir. Otomasyon yoksa her kesintide manuel müdahale gerekir; bu da maliyeti tekrar on-demand seviyelerine yaklaştırabilir.

6) Veri tabanı spot instance’ta tutulursa risk büyürür

Veri tabanı state’i spot üzerinde barındırılırsa kesinti: - veri kaybı - daha uzun toparlanma - tutarsızlık

… yaratabilir. Veri katmanı mutlaka dayanıklı tasarlanmalıdır.

7) Fiyat dalgalanması tahmin edilemez bütçe yaratır

Spot fiyatı anlık artabilir. “Kârlılık” sadece ortalama değil; bütçe tavanı ve kontrol mekanizmalarıyla yönetilmelidir.

Doğru mimari: Spot kesintisini sistem tasarımının bir parçası yapmak

Spot instance kullanacaksanız hedefiniz “kesinti olduğunda sistemin iş kaybetmeden toparlanması” olmalıdır. Bunun için en etkili yaklaşım katmanlı dayanıklılıktır.

Stateless uygulama + dışarıda state

• Uygulama sunucularını durumsuz tutun.
• Oturum (session), kullanıcı verisi, job durumu gibi şeyleri dışarıda saklayın:
• veri tabanı (DB)
• cache (silmeye hazır şekilde)
• kuyruk (queue)
• object storage (S3 benzeri)

Bu yaklaşımın avantajı şudur: Instance kesilse bile iş akışı dış katmanlarda devam eder veya yeniden alınır.

Queue/Job sistemiyle “yeniden deneme” (retry) tasarlayın

• İşleri tek tek instance ömrüne bağlamayın.
• Job’ları kuyruk üzerinden yönetin.
• Idempotent (aynı iş tekrar çalıştırıldığında sonucu bozmayan) tasarım kurun.

Örnek düşünce: - Aynı dosya iki kez işlenirse çakışma yaşamamalı. - İş çıktısı object storage’a belirli anahtarlarla yazılmalı. - İş tamamlanınca job durumu tekillikle işaretlenmeli.

Persistant depolama ve “cache’i görebilirsin ama kaybedebilirsin” yaklaşımı

Spot kullanırken cache katmanını “performans artırıcı, zorunlu değil” olarak konumlandırın. - Şunu hedefleyin: Cache kaybolursa sistem çalışmaya devam etsin. - Geçici dosyalar kaybolabilir; ama son çıktı kalıcı depoda olmalı.

Otomatik ölçekleme ve yeniden oluşturma

Kesintiler döngüsel olacağı için: - otomatik yeniden başlatma - otomatik ölçekleme - altyapı (IaC) ile tekrarlanabilir kurulum

… kritik olur.

Spot vs VDS: Ne zaman spot, ne zaman klasik VDS?

Net karar için iş yükü karakterini ayırın. Aşağıdaki tablo pratik bir yön verir.

Net kural: “Sistem kesildiğinde iş devam edecek mi?”

Spot kullanma eşiği için tek cümlelik test: - İş devam ediyor veya yeniden üretim mümkün mü?

Eğer evetse spot değerlidir. Değilse klasik VDS veya daha kararlı instance modeli doğru seçenektir.

Riskleri azaltmak için kontrol listesi

Spot kullanmadan önce aşağıdaki maddeleri “tamam”lamadan karar vermeyin.

Mimaride

• [ ] Uygulama stateless veya kesinti sonrası yeniden başlatmaya hazır
• [ ] Job’lar queue üzerinden ilerliyor
• [ ] İşler idempotent (aynı job tekrar çalıştırılınca bozulmuyor)
• [ ] Kalıcı veri object storage / DB gibi dayanıklı katmanda
• [ ] Instance üzerindeki geçici disk kritik değil

Maliyet ve bütçede

• [ ] Spot fiyat dalgalanması için bütçe tavanı ve limit stratejisi var
• [ ] Yeniden deneme/retry maliyeti (CPU, storage egress) hesaplandı
• [ ] Ortalama tasarruf + risk maliyeti birlikte değerlendirildi

Operasyonda

• [ ] Otomatik yeniden kurulum / yeniden ölçekleme mevcut
• [ ] İzleme (metrics), log ve alarm kuruldu
• [ ] Kesinti sonrası toparlanma süresi (RTO) hedeflendi
• [ ] Yedek (backup) ve veri geri alma planı çalışıyor

Son karar: Spot’u “tasarladığınız kadar” ucuz kullanın

Cloud spot instance, doğru mimariyle önemli maliyet avantajı sağlar; yanlış mimariyle ise kesintiler operasyon yükünü artırır ve fiili maliyet yükselir. Bugün atacağınız en net adım, önce iş yükünüzü sınıflandırmak ve “kesinti olursa ne olacak?” sorusuna queue + retry + dış state yaklaşımıyla cevap vermektir. Bu kontrol listesinde işaretleyemediğiniz maddeler varsa, spot’u tek başına maliyet hesabıyla değil, dayanıklılık planıyla birlikte değerlendirin ve spot’u yalnızca toparlanması kanıtlanmış bileşenlerde kullanın.