Spot/Preemptible Instance #
Cloud provider memiliki kapasitas komputasi yang tidak selalu terpakai penuh. Daripada membiarkan kapasitas ini idle, mereka menawarkannya dengan harga diskon besar — hingga 70-90% lebih murah dari harga on-demand — dengan satu kondisi: instance bisa diterminasi kapan saja saat provider membutuhkan kapasitas tersebut kembali. Inilah Spot Instance (AWS), Preemptible VM (GCP), atau Spot VM (Azure). Untuk workload yang tepat, ini adalah cara paling signifikan untuk memangkas biaya compute di cloud.
Cara Kerja Spot/Preemptible Instance #
Logika di Balik Spot Instance:
Cloud provider memiliki kapasitas fisik yang besar.
Tidak semua kapasitas terpakai setiap saat.
On-demand customers: membayar harga penuh, dijamin tersedia
Spot customers: menggunakan "sisa kapasitas", harga sangat murah
Ketika on-demand demand naik:
→ Provider butuh kapasitas yang sedang dipakai spot customer
→ Provider kirim sinyal interupsi ke spot instance
→ Instance punya waktu N menit untuk shutdown gracefully
→ Instance diterminasi
Karakteristik:
✓ Harga: 60-90% lebih murah dari on-demand
✗ Bisa diterminasi kapan saja dengan notice singkat
(biasanya 2 menit untuk AWS, 30 detik untuk GCP)
✗ Tidak tersedia selalu — tergantung ketersediaan kapasitas spare
✓ Jika tidak diterminasi, berjalan normal seperti on-demand
Interupsi — Risiko yang Harus Dipahami #
Interupsi adalah trade-off utama spot instance. Seberapa sering interupsi terjadi bergantung pada tipe instance, region, dan AZ yang dipilih.
Frekuensi Interupsi (estimasi industri):
Tipe instance populer di region sibuk:
→ Frekuensi interupsi bisa 5-15% per jam
→ Artinya: dari 100 instance, 5-15 mungkin diterminasi per jam
Tipe instance yang kurang populer di region yang lebih sepi:
→ Frekuensi interupsi bisa < 5% per bulan
→ Sangat jarang — hampir seperti on-demand dalam praktik
Strategi untuk mengurangi dampak interupsi:
1. Diversifikasi tipe instance dan AZ
→ Jangan hanya request satu tipe instance
→ Mix: m5.xlarge, m5a.xlarge, m4.xlarge, c5.xlarge
→ Jika satu tipe habis, autoscaling ambil tipe lain
→ Spread ke beberapa AZ
2. Tangani sinyal interupsi dengan graceful shutdown
→ Dengarkan sinyal terminasi
→ Selesaikan pekerjaan yang sedang berjalan jika bisa
→ Simpan progress ke checkpoint jika pekerjaan panjang
→ Kembalikan pesan ke queue jika belum selesai
3. Mix dengan on-demand untuk baseline
→ 20-30% on-demand sebagai baseline minimum
→ 70-80% spot untuk mengurangi biaya
→ Jika spot habis, on-demand masih menjaga minimum capacity
Workload yang Tepat untuk Spot #
Tidak semua workload cocok untuk spot instance. Kuncinya adalah: workload yang bisa toleran terhadap interupsi mendadak.
Sangat Cocok untuk Spot:
Batch Processing:
✓ Data pipeline, ETL yang bisa di-resume
✓ Video transcoding (checkpoint per segment)
✓ Image processing batch
✓ Jika diterminasi → checkpoint tersimpan → resume di instance lain
Machine Learning Training:
✓ Model training bisa di-checkpoint secara berkala
✓ Jika diterminasi → training resume dari checkpoint terakhir
✓ Penghematan sangat signifikan untuk training yang berjalan jam/hari
CI/CD Runners:
✓ Job CI yang gagal bisa di-retry
✓ Tidak ada state yang perlu di-preserve
✓ Cocok sekali — runner mati → job gagal → retry di runner baru
Rendering dan Simulasi:
✓ Setiap frame atau task independen
✓ Task yang belum selesai dikembalikan ke queue
✓ Di-assign ke instance lain yang tersedia
Stateless Web/API Server (dengan hati-hati):
✓ Bisa digunakan sebagai kapasitas tambahan di atas baseline on-demand
✓ Load balancer otomatis drain koneksi sebelum terminasi
✗ Jangan 100% spot untuk production web server
Tidak Cocok untuk Spot:
✗ Database primary node
→ Terminasi mendadak bisa menyebabkan data loss atau
waktu recovery yang lama
✗ Stateful application tanpa mekanisme checkpoint
→ Progress hilang saat terminasi
✗ Workload yang memerlukan availability yang ketat
→ SLA yang tidak bisa toleran terhadap interupsi
✗ Session-based application tanpa external session store
→ User session hilang saat instance diterminasi
Strategi Mix On-Demand dan Spot #
Pola paling umum adalah menggunakan campuran instance on-demand dan spot untuk mendapatkan keseimbangan antara penghematan dan keandalan.
Pola Mixed Instance Group:
Auto Scaling Group dengan mixed policy:
Baseline (On-Demand): 2 instance
→ Selalu tersedia, tidak pernah diterminasi
→ Menjaga minimum capacity
Burst (Spot): hingga 8 instance tambahan
→ Mengisi saat beban naik
→ Jauh lebih murah dari on-demand
→ Jika diterminasi, on-demand baseline masih jaga layanan
Contoh konfigurasi:
Minimum capacity: 2 (on-demand)
Desired capacity: 4 (2 on-demand + 2 spot)
Maximum capacity: 10 (2 on-demand + 8 spot)
On-demand base: 2 instance
On-demand percentage beyond base: 20% (dari burst)
Spot percentage: 80% (dari burst)
Estimasi penghematan:
Tanpa spot: 10 instance × $0.10/jam = $1.00/jam
Dengan mix: 2 × $0.10 + 8 × $0.025 = $0.40/jam
Penghematan: 60%
Spot untuk Kubernetes Node #
Di managed Kubernetes, spot instance bisa digunakan untuk worker nodes — dengan pertimbangan yang tepat.
Spot Nodes di Kubernetes:
Strategi yang umum:
System Node Pool (On-Demand):
→ Menjalankan system pods (CoreDNS, kube-proxy, monitoring)
→ Tidak boleh di-spot — system pods tidak boleh diterminasi sembarangan
Workload Node Pool (Spot):
→ Menjalankan application pods
→ Pods bisa di-schedule ulang ke node lain jika node diterminasi
Konfigurasi penting:
Pod Disruption Budget (PDB):
→ Tentukan berapa pod minimum yang harus selalu running
→ Platform tidak bisa terminate node jika akan melanggar PDB
Tolerations dan Node Affinity:
→ Label spot node dengan taint
→ Hanya pod yang toleran terhadap interupsi yang dijadwalkan ke spot node
→ System pods tidak perlu tolerant terhadap spot taint
Ringkasan #
- Spot/Preemptible instance menawarkan diskon 60-90% dengan trade-off bisa diterminasi kapan saja saat provider butuh kapasitas kembali.
- Frekuensi interupsi bervariasi — tipe instance populer lebih sering diinterupsi; diversifikasi tipe instance dan AZ mengurangi risiko.
- Batch processing, ML training, dan CI/CD adalah use case terkuat — workload yang bisa di-checkpoint dan di-retry tidak kehilangan banyak saat interupsi.
- Jangan gunakan 100% spot untuk production — selalu mix dengan on-demand sebagai baseline minimum (20-30%).
- Tangani sinyal interupsi dengan graceful shutdown — 2 menit notice cukup untuk checkpoint, drain koneksi, atau kembalikan task ke queue.
- Kubernetes + spot nodes membutuhkan Pod Disruption Budget — tentukan minimum pod yang harus selalu running untuk mencegah interupsi yang merusak.