Spot/Preemptible Instance #

Di dalam pusat data fisik penyedia cloud publik, terdapat jutaan server fisik yang beroperasi setiap saat. Karena pola penggunaan sumber daya komputasi oleh pengguna bersifat fluktuatif (misalnya sepi di malam hari dan padat di siang hari), cloud provider selalu memiliki sejumlah besar kapasitas komputasi cadangan (spare capacity) yang sedang tidak terpakai (idle). Daripada membiarkan server fisik tersebut menyala tanpa menghasilkan pendapatan, cloud provider menawarkannya dengan potongan harga yang sangat fantastis — berkisar 70% hingga 90% lebih murah dari harga sewa normal (On-Demand) — dengan satu syarat mutlak: instans tersebut dapat ditarik kembali secara paksa oleh provider sewaktu-waktu jika kapasitas fisik tersebut dibutuhkan oleh pengguna On-Demand yang membayar harga penuh. Layanan inilah yang disebut sebagai Spot Instance (di AWS), Preemptible VM (di Google Cloud), atau Spot VM (di Azure). Jika dipadukan dengan jenis beban kerja (workload) yang tepat, Spot Instance adalah perkakas paling ampuh untuk memotong pengeluaran finansial komputasi kita secara drastis.

Cara Kerja dan Ekonomi Kapasitas Cadangan (Spare Capacity) #

Model penetapan harga Spot Instance didasarkan pada dinamika penawaran (supply) dan permintaan (demand) kapasitas cadangan di setiap lokasi zona ketersediaan (Availability Zone) cloud provider.

flowchart TD
    Request["Permintaan Komputasi Baru"] --> CheckType{"Tipe Permintaan?"}
    CheckType -- "1. On-Demand / Reserved (Bayar Penuh)" --> Priority["Prioritas Utama:<br>Alokasikan Kapasitas Langsung"]
    CheckType -- "2. Spot (Harga Diskon)" --> CheckSpare{"Kapasitas Cadangan Tersedia?"}
    
    CheckSpare -- "Ya" --> RunSpot["Jalankan Spot Instance<br>(Diskon 70-90%)"]
    CheckSpare -- "Tidak" --> Reject["Tolak Permintaan (Out of Capacity)"]
    
    Priority -->|"Jika kapasitas fisik kurang, tarik paksa Spot"| Reclaim["Kirim Sinyal Interupsi & Terminate Spot"]
    Reclaim --> RunSpot

Logika Alokasi Kapasitas #

1. Prioritas On-Demand: Pengguna On-Demand membayar tarif sewa penuh dan mendapatkan jaminan ketersediaan instans (SLA availability guarantee).
2. Pemanfaatan Sisa: Pengguna Spot memanfaatkan kapasitas sisa yang sedang menganggur. Tarif sewa Spot bersifat dinamis, berubah secara berkala berdasarkan seberapa banyak sisa kapasitas yang tersedia di AZ tersebut untuk tipe instans tertentu.
3. Proses Reclaim (Interupsi): Ketika terjadi lonjakan permintaan dari pengguna On-Demand (atau ketika alokasi kapasitas cadangan di AZ tersebut menipis), hypervisor cloud provider akan segera mengirimkan sinyal perintah pengambilalihan paksa (reclaim signal) ke instans Spot kita untuk diterminasi dalam hitungan detik hingga menit.

Memahami Risiko Interupsi dan Sinyal Terminasi #

Satu-satunya trade-off dari harga murah Spot Instance adalah ketidakpastian siklus hidupnya (lifetime volatility). Instans kita bisa berjalan mulus selama berminggu-minggu tanpa gangguan jika kita menggunakan tipe server yang kurang populer di AZ sepi, namun bisa juga diinterupsi dalam waktu 1 jam setelah dinyalakan jika kita memilih tipe server yang sangat diminati di AZ utama.

Waktu Toleransi Sinyal Interupsi #

Ketika provider memutuskan untuk menarik kembali kapasitas fisik Spot kita, hypervisor tidak langsung mematikan VM secara mendadak tanpa pemberitahuan. Kita diberikan waktu toleransi yang sangat singkat untuk melakukan pembersihan data (graceful cleanup):

• AWS Spot: Memberikan notifikasi 2 menit sebelum pemutusan.
• Google Cloud Preemptible: Memberikan notifikasi 30 detik sebelum pemutusan.
• Azure Spot VM: Memberikan notifikasi 30 detik sebelum pemutusan.

Mengkoding Handler Sinyal Interupsi #

Pemberitahuan interupsi ini dikirimkan oleh kontroler cloud ke server metadata internal instans. Aplikasi di dalam VM kita wajib memantau server metadata tersebut secara konstan agar dapat segera menghentikan proses transaksi, menyimpan data sementara (checkpointing), dan mematikan diri secara aman sebelum server mati.

# Contoh skrip Bash untuk memantau sinyal interupsi Spot AWS dari dalam instans
# Jalankan skrip ini sebagai daemon (background process) di dalam VM
#!/bin/bash

METADATA_URL="http://169.254.169.254/latest/meta-data/spot/instance-action"

while true; do
  # Menggunakan IMDSv2 Token Keamanan
  TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 60")
  
  # Cek apakah endpoint spot instance-action mengembalikan status HTTP 200 OK
  HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -H "X-aws-ec2-metadata-token: $TOKEN" $METADATA_URL)
  
  if [ "$HTTP_CODE" -eq 200 ]; then
    # Sinyal Interupsi Terdeteksi!
    ACTION_DETAILS=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" $METADATA_URL)
    log "PERINGATAN: Sinyal interupsi Spot terdeteksi! Detail: $ACTION_DETAILS"
    
    # 1. Pemicu skrip penyelamatan data (Save Checkpoint)
    /usr/local/bin/save-app-state.sh
    
    # 2. Beri tahu Load Balancer untuk menghentikan traffic (Deregister target)
    /usr/local/bin/deregister-from-lb.sh
    
    # 3. Keluar dari loop dan biarkan OS shutdown
    exit 0
  fi
  
  # Lakukan pengecekan berkala setiap 5 detik
  sleep 5
done

Workload yang Tepat vs Tidak Tepat untuk Spot Instances #

Kunci sukses pemanfaatan Spot Instance terletak pada kemampuan kita memilah jenis beban kerja aplikasi yang toleran terhadap interupsi mendadak.

Tabel Klasifikasi Workload #

Strategi Campuran: Mixed Instance Groups (Spot & On-Demand) #

Untuk mendapatkan keandalan tinggi dengan biaya minimal di lingkungan produksi, kita tidak boleh menggunakan 100% instans Spot. Strategi terbaik adalah menggunakan Mixed Instance Groups (Kelompok Instans Campuran) di dalam Auto Scaling Group kita.

Visualisasi Komposisi Cluster Produksi yang Aman:
┌────────────────────────────────────────────────────────┐
│  BURST CAPACITY (70% SPOT INSTANCES)                    │  <-- Hemat biaya saat trafik padat
│  [Spot VM 1] [Spot VM 2] [Spot VM 3] [Spot VM 4]        │
├────────────────────────────────────────────────────────┤
│  BASELINE CAPACITY (30% ON-DEMAND INSTANCES)           │  <-- Menjamin layanan tidak pernah mati total
│  [On-Demand VM 1] [On-Demand VM 2]                     │
└────────────────────────────────────────────────────────┘

Simulasi Kalkulasi Matematika Penghematan Biaya #

Mari kita hitung efisiensi biaya bulanan menggunakan strategi campuran untuk mengelola kluster berisi 10 instans VM yang berjalan selama 730 jam dalam sebulan.

• Tarif On-Demand: $0.10 / jam
• Tarif Spot (Diskon 80%): $0.02 / jam

Opsi A: 100% On-Demand #

$$\text{Biaya Opsi A} = 10\text{ VM} \times 730\text{ jam} \times $0.10 = $7.300 / \text{bulan}$$

Opsi B: Campuran (30% On-Demand Baseline + 70% Spot Burst) #

• Biaya On-Demand (3 VM): $3\text{ VM} \times 730\text{ jam} \times $0.10 = $2.190$
• Biaya Spot (7 VM): $7\text{ VM} \times 730\text{ jam} \times $0.02 = $1.022$
• Total Biaya Opsi B: $$$2.190 + $1.022 = $3.212 / \text{bulan}$$

Hasil Evaluasi Finansial: #

Dengan menggunakan strategi campuran, kita berhasil memotong tagihan bulanan sebesar 56% sambil tetap memastikan bahwa jika terjadi penarikan massal Spot oleh provider cloud, kita masih memiliki 3 VM On-Demand yang siaga melayani trafik dasar.

Kunci Sukses: Diversifikasi Tipe Instans #

Ketika kita menyusun kluster Spot, aturan nomor satu adalah: Jangan pernah bergantung pada satu tipe instans saja. Jika kita mengonfigurasi kluster Auto Scaling hanya meminta tipe c5.xlarge, dan pada waktu tertentu kapasitas cadangan c5.xlarge di AZ tersebut habis, kluster kita tidak akan bisa melakukan scale-out.

• Solusi: Aktifkan fitur diversifikasi instans (Instance Diversification). Konfigurasikan grup agar dapat menerima tipe alternatif yang setara, misalnya: c5.xlarge, c4.xlarge, c5a.xlarge, dan m5.xlarge. Sistem autoscaling cloud secara otomatis akan memilih tipe alternatif yang memiliki tingkat interupsi paling rendah saat itu.

Spot Instances di Lingkungan Kubernetes (Spot Worker Nodes) #

Kubernetes sangat ideal dipadukan dengan Spot Instance karena Kubernetes dirancang sejak awal untuk menangani beban kerja yang dinamis dan toleran terhadap kegagalan node (fault-tolerant orchestrator).

Di dalam Kubernetes, kita menerapkan pemisahan kelompok node (Node Pools) untuk menjaga stabilitas kluster:

# Contoh konfigurasi deployment pod aplikasi yang membatasi agar dideploy hanya ke Spot node pool
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stateless-web-app
spec:
  replicas: 5
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "intent"
                operator: In
                values:
                - "spot-workers" # ✓ BENAR: Arahkan pod ke Node Pool Spot
      tolerations:
      - key: "sku"
        operator: "Equal"
        value: "spot"
        effect: "NoSchedule" # Menoleransi taint NoSchedule pada node spot

Konfigurasi Penting Kubernetes untuk Spot: #

1. Taints dan Tolerations: Kita menandai node pool Spot dengan taint (misal: sku=spot:NoSchedule). Hal ini mencegah pod sistem yang kritis (seperti database kube-system, CoreDNS, Ingress Controller) agar tidak secara tidak sengaja dijadwalkan berjalan di node Spot yang tidak stabil. Hanya pod aplikasi stateless yang memiliki toleration yang diizinkan berjalan di sana.
2. Pod Disruption Budget (PDB): Kebijakan untuk membatasi jumlah pod yang boleh mati secara bersamaan selama proses penggusuran node (eviction). Ini menjamin bahwa Kubernetes tidak akan mengizinkan penggusuran jika jumlah pod aktif tersisa akan melanggar batas kuorum minimum aplikasi kita.
3. K8s Node Termination Handler: Sebuah kontroler open-source kecil yang kita pasang di kluster. Kontroler ini memantau sinyal pemutusan metadata cloud provider. Begitu sinyal interupsi 2 menit terdeteksi, kontroler akan langsung mengeksekusi perintah pengosongan node secara otomatis:

   # Langkah 1: Tandai node agar tidak menerima pod baru (Cordon)
   kubectl cordon <node-name-spot>
   
   # Langkah 2: Pindahkan pod berjalan ke node sehat lain secara aman (Drain)
   kubectl drain <node-name-spot> --ignore-daemonsets --delete-emptydir-data
   

   Langkah pengosongan otomatis ini memastikan bahwa pod aplikasi kita sudah berhasil dipindahkan ke VM On-Demand sehat lainnya sebelum VM Spot tersebut benar-benar dimatikan secara paksa oleh hypervisor cloud.

Ringkasan #

• Spot / Preemptible VM menawarkan diskon sewa hingga 90% dengan kompromi instans dapat diterminasi secara paksa oleh provider sewaktu-waktu.
• Provider cloud memberikan waktu toleransi singkat sebelum interupsi — berkisar antara 30 detik (GCP/Azure) hingga 2 menit (AWS) yang dapat kita pantau melalui server metadata internal.
• Sangat ideal untuk pemrosesan batch, CI/CD runners, dan ML training — beban kerja yang aman untuk dihentikan sesaat dan dilanjutkan kembali melalui sistem checkpoint.
• Jangan gunakan Spot untuk database utama — kehilangan pasokan listrik mendadak di server database sangat rentan memicu kerusakan integritas berkas biner data.
• Gunakan kombinasi campuran (Mixed Instance Groups) — pertahankan pilar baseline On-Demand (20-30%) untuk menampung traffic minimum dan gunakan Spot (70-80%) untuk menangani traffic dinamis.
• Implementasikan Node Termination Handler di Kubernetes — agar kluster dapat secara otomatis melakukan perintah cordon dan drain memindahkan pod ke node lain sebelum VM Spot dihapus.

← Sebelumnya: Autoscaling   Berikutnya: IAM →