Tantangan Deployment Model Inference pada CPU

Menjalankan beban kerja Machine Learning inference pada arsitektur CPU memperkenalkan tantangan konkurensi dan manajemen memori yang berbeda dibandingkan GPU. Library eksekusi numerik seperti PyTorch, ONNX Runtime, atau OpenVINO sangat bergantung pada kompilasi graf dinamis (JIT), thread pool OpenMP, dan alokasi memori matriks yang masif di fase inisialisasi.

Masalah paling umum saat deployment model baru adalah kegagalan pod akibat OOM (Out Of Memory) saat pemanasan (warmup) atau lonjakan drastis pada p99 latency akibat perebutan thread CPU. Menerapkan canary release bertahap yang dipadukan dengan konfigurasi healthcheck probe yang presisi mencegah lalu lintas dialihkan ke container sebelum runtime mencapai kondisi stabil.

Konfigurasi Kubernetes Probe dan Startup Synchronization

Kegagalan routing traffic sering terjadi karena Kubernetes menganggap pod siap (ready) segera setelah server HTTP membuka port, padahal model runtime masih mengompilasi graf bobot atau mengalokasikan tensor buffer. Gunakan pemisahan ketat antara startupProbe, readinessProbe, dan livenessProbe.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cpu-inference-service-canary
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: inference-engine
        image: inference-service:v2.1.0
        resources:
          limits:
            cpu: "4"
            memory: "8Gi"
          requests:
            cpu: "4"
            memory: "8Gi"
        startupProbe:
          httpGet:
            path: /health/startup
            port: 8080
          failureThreshold: 30
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          periodSeconds: 5
          failureThreshold: 2
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          periodSeconds: 10
          failureThreshold: 3

Logika endpoint /health/startup harus menjalankan inferensi sintetis satu kali secara internal (dummy batch) untuk memicu kompilasi kernel CPU sebelum mengembalikan status HTTP 200. Endpoint /health/ready hanya memeriksa ketersediaan thread pool, bukan memicu warmup ulang.

Metrik Kunci Observasi dan Runtime Profiling

Saat canary pod menerima sebagian traffic (misal 5% hingga 10%), pantau tiga metrik utama ini via Prometheus/Grafana:

  • CPU Throttling (container_cpu_cfs_throttled_periods_total): Terjadi jika thread OpenMP/MKL melebihi alokasi CFS quota Linux. Hindari menyetel jumlah thread internal model lebih besar daripada limits.cpu kontainer. Setel environment variable OMP_NUM_THREADS=4 sesuai alokasi core riil.
  • Resident Set Size (RSS) Footprint: Alokasi memori runtime harus stabil setelah fase warmup. Kenaikan linier menandakan tensor leak di memori sistem (C-level buffer tidak dilepas oleh garbage collector runtime).
  • p99 Latency Spikes: Lonjakan latency pada persentil 99 menandakan adanya task contention antar thread eksekusi atau proses swapping memori.

Kriteria Otomatis Rollback

Rollback otomatis harus terikat pada toleransi ambang batas (SLO) yang ketat selama fase canary berjalan. Deployment otomatis dibatalkan dan traffic dikembalikan 100% ke versi stabil jika kondisi berikut terpenuhi:

  1. OOMKilled Event: Munculnya status exit code 137 pada pod canary dalam rentang 15 menit deployment.
  2. Breach p99 Latency: p99 latency pada canary melebihi baseline versi stabil sebesar lebih dari 25% selama interval evaluasi 3 menit berturut-turut.
  3. Error Rate: HTTP status 5xx melebihi 1% dari total traffic canary.
# Contoh query prometheus untuk trigger rollback via Argo Rollouts / Flagger
sum(rate(http_requests_total{status=~"5.*", role="canary"}[2m])) 
/ 
sum(rate(http_requests_total{role="canary"}[2m])) > 0.01

Postmortem Insiden: Latency Degradation Akibat CPU Oversubscription

Konteks Masalah

Pada evaluasi canary versi model klasifikasi teks, pod lolos startup probe tetapi p99 latency melonjak dari 45ms ke 480ms setelah menerima 10% traffic live.

Akar Masalah (Root Cause)

Aplikasi dikonfigurasi dengan alokasi resource limits 2 CPU core, namun dependency backend mendeteksi 32 logical core dari host node Kubernetes underlying. Secara default, runtime runtime menginisialisasi 32 thread worker OpenMP. Akibatnya, terjadi context switching masif antar thread yang saling berebut kuota CFS 200ms kernel CPU (tercatat CPU throttled periods mencapai 72%).

Solusi dan Tindakan Korektif

Terapkan penegakan thread eksplisit pada entrypoint container dan pastikan flag environment selalu disinkronisasikan dengan resource limits Kubernetes:

export OMP_NUM_THREADS=2
export MKL_NUM_THREADS=2
export OPENBLAS_NUM_THREADS=2

Tambahkan automated canary analysis yang memvalidasi metrik throttling sebelum traffic canary dinaikkan ke fase berikutnya.