Belajar MLOps - Model Deployment Patterns

#Pendahuluan

Setelah di episode 9 model kalian sudah menjadi API, sekarang pertanyaannya: bagaimana cara memperbarui model tanpa menghentikan layanan? Model tidak lahir sempurna — versi baru datang setiap beberapa minggu, dan mengganti model di produksi adalah operasi yang berisiko: bisa menurunkan kualitas, menaikkan latensi, atau memperkenalkan bug yang tidak muncul di staging.

Mengapa deployment pattern penting? Karena model yang salah di-deploy lebih berbahaya daripada tidak di-deploy. Pilihan pola yang tepat menentukan seberapa cepat kalian bisa mendeteksi masalah, seberapa kecil dampaknya terhadap pengguna, dan seberapa mudah rollback. Episode ini membedah tiga bentuk serving dan tiga strategi deployment.

#Tiga Bentuk Serving

Cara model dipanggil menentukan arsitekturnya. Tiga pola utama:

#1. Online Serving (REST/gRPC)

Model dipanggil real-time per-request — pengguna menunggu respons saat itu juga.

• REST — sederhana, berbasis JSON, cocok untuk integrasi umum.
• gRPC — protobuf binary, lebih cepat & hemat bandwidth, cocok untuk internal dan beban tinggi.

curl -X POST https://api.churn.example/predict \
  -H "Content-Type: application/json" \
  -d '{"age": 45, "monthly_charges": 89.9}'

#2. Batch Serving

Prediksi dihitung untuk banyak record sekaligus, sesuai jadwal. Contoh: skor churn untuk semua pelanggan setiap malam, atau rekomendasi harian.

python -m churn.batch_score --input s3://data/customers.csv \
  --output s3://output/predictions/2026-08-16.parquet

#3. Streaming Serving

Prediksi dilakukan pada event real-time dalam pipeline streaming (Kafka, Kinesis) — model menjadi satu tahap dalam alur event. Cocok untuk fraud detection atau monitoring sensor.

Event (Kafka) → Consumer → Predict → Keputusan → Publish hasil

#Membandingkan Ketiganya

#Strategi Deployment: Blue-Green

Blue-Green adalah strategi yang paling sederhana dan aman secara konsep: dua environment identik (blue = versi lama, green = versi baru), dan perpindahan traffic terjadi sekali switch.

┌────────────┐     ┌────────────────┐
│  Router/   │     │ Blue: model v1 │  ← menerima traffic sekarang
│  LB        ├────►│ Green: model v2│  ← di-deploy, diuji, belum dipakai
└────────────┘     └────────────────┘

Alurnya:

1. Deploy green (v2) berdampingan dengan blue (v1).
2. Jalankan smoke test ke green — pastikan model sehat.
3. Pindahkan semua traffic ke green (switch router).
4. Jika masalah muncul, switch balik ke blue — rollback instan.

Kekuatannya: rollback yang instan dan deterministik. Kelemahannya: biaya ganda (dua environment berjalan), dan switch penuh berarti jika v2 bermasalah, semua pengguna terdampak sekaligus.

#Strategi Deployment: Canary

Canary adalah strategi bertahap: traffic dialihkan sedikit demi sedikit, sambil membandingkan metrik antara versi lama dan baru. Jika metrik memburuk di 5% traffic, canary dihentikan sebelum mempengaruhi 95% sisanya.

Untuk model, "metrik ok" bisa berupa: latensi p95, error rate, dan — khusus untuk ML — kualitas prediksi jika ada umpan balik cepat.

#Praktik Canary dengan Weighted Routing

Di Kubernetes, weight-based routing mudah dilakukan dengan Istio atau Linkerd. Contoh VirtualService Istio:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: churn-svc
spec:
  hosts:
    - churn-svc
  http:
    - route:
        - destination:
            host: churn-svc
            subset: v1
          weight: 95
        - destination:
            host: churn-svc
            subset: v2
          weight: 5

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: churn-svc
spec:
  host: churn-svc
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Alur canary model yang baik:

1. Deploy v2 dengan weight 5%.
2. Pantau latensi, error, dan metrik kualitas selama 15-60 menit.
3. Naikkan bertahap: 25% → 50% → 100%.
4. Jika metrik melanggar SLO kapan pun → rollback dengan mengembalikan weight ke 100% v1.

#Rolling Deployment

Rolling menggantikan pod secara bertahap tanpa dua environment penuh — strategi default di Kubernetes. Cocok untuk model yang kompatibel ke belakang (schema input sama). Kelemahannya untuk ML: kalian tidak mudah membandingkan dua versi secara langsung, dan rollback butuh redeploy.

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

#Kapan Memakai Yang Mana

Prinsip utamanya: deploy model yang bisa kita ukur dan bisa kita tarik. Apa pun strateginya, tanpa monitoring (episode 12) dan registry yang rapi (episode 11), rollback adalah menebak-nebak.

#Common Pitfalls

• Canary tanpa metrik kualitas → hanya membandingkan "apakah server hidup", bukan "apakah model masih bagus".
• Switch penuh tanpa rollback plan → blue-green kehilangan artinya jika router tidak bisa dibalik.
• Rollback tanpa versioning model → tidak tahu versi mana yang "sebelumnya"; registry menyelesaikan ini.
• Canary 50% langsung → sampel terlalu besar untuk "mencoba"; mulai dari 5-10%.
• Membandingkan v1 dan v2 pada traffic yang beda → metrik tidak adil; pastikan splitting acak dan merata.

#Penutup

Pada episode 10 ini, kalian telah menguasai pola deployment model.

Inti yang harus dibawa pulang:

• Serving punya tiga bentuk: online (REST/gRPC), batch, dan streaming — pilih sesuai latency yang dibutuhkan.
• Blue-green = switch instan dengan rollback deterministik, biaya ganda.
• Canary = traffic bertahap dengan gate kualitas, paling cocok untuk model.
• Rolling = penggantian bertahap default K8s, untuk perubahan kompatibel.
• Deployment tanpa monitoring dan registry adalah menebak.

Di episode 11 selanjutnya kita akan membahas model registry & versioning — MLflow Model Registry, siklus hidup model (staging → production → archived), promotion yang terotomasi, dan lineage model → data → kode. Sampai jumpa di episode 11!