Belajar MLOps - Cloud ML Platforms

#Pendahuluan

Setelah governance di episode 15 rapi, ada pilihan arsitektur yang harus diambil: membangun platform ML sendiri di atas Kubernetes, atau memakai managed cloud ML platform. Untuk tim yang tidak mau (atau belum punya kapasitas) mengelola server, GPU, dan layanan terkait, managed platform adalah jalan pintas yang sah — bukan jalan "yang kurang keren".

Mengapa episode ini penting? Karena di industri, mayoritas tim produksi ML memakai kombinasi: eksperimen di lokal (episode 5-7), lalu training dan serving di managed platform (SageMaker, Vertex AI, atau Azure ML). Memahami mental model platform ini — pipeline, model registry, endpoint, traffic split — membuat kalian bisa langsung produktif di tempat kerja mana pun. Episode ini membandingkan ketiganya dan mempraktikkan deployment yang benar.

#Managed vs Self-Managed

Managed platform kini hampir selalu menyediakan: experiment tracking, pipeline orchestration, model registry, serving endpoint dengan auto-scaling, dan monitoring — persis komponen yang kalian bangun manual di episode 5-14.

#AWS SageMaker

SageMaker menawarkan alur: training job → model artifact di S3 → model registry → endpoint. Semua berbasis boto3 atau konsol.

import boto3
 
sm = boto3.client("sagemaker")
 
sm.create_model(
    ModelName="churn-v2",
    PrimaryContainer={
        "Image": "763104351884.dkr.ecr.ap-southeast-1.amazonaws.com/sagemaker-xgboost:1.7-1",
        "ModelDataUrl": "s3://mlops-bucket/churn/v2/model.tar.gz",
    },
    ExecutionRoleArn="arn:aws:iam::123456789012:role/sagemaker-exec",
)
 
sm.create_endpoint(
    EndpointName="churn-endpoint",
    EndpointConfigName="churn-v2-config",
)

Model di-package sebagai model.tar.gz di S3; image inference memuatnya. Endpoint siap dipanggil lewat REST.

#GCP Vertex AI

Vertex AI dibangun di atas Kubeflow Pipelines — ini nilai lebihnya: pipeline yang kalian pelajari di episode 7 bisa jalan di sini hampir apa adanya. Training dan serving dilakukan dengan artefak di GCS.

gcloud ai models upload --region=asia-southeast1 \
  --display-name=churn-v2 \
  --artifact-uri=gs://mlops-bucket/churn/v2/ \
  --container-image-uri=us-docker.pkg.dev/vertex-ai/prediction/sklearn-cpu.1-6
 
gcloud ai endpoints deploy-model <ENDPOINT_ID> \
  --model=<MODEL_ID> --traffic-split=0=100

Perhatikan --traffic-split: di sinilah blue-green/canary (episode 10) dijalankan — beberapa model versi dideploy ke satu endpoint dengan pembagian traffic.

#Azure ML

Azure ML berbasis workspace — pusat dari jobs (training), environments, dan endpoints. Konsep kuncinya adalah managed online endpoint dengan deployments di dalamnya.

az ml online-endpoint create --name churn-endpoint \
  --resource-group ml-rg --workspace-name ml-workspace
 
az ml online-deployment create --name blue --endpoint churn-endpoint \
  --model azureml:churn-v2:2 --color blue --all-traffic

--color blue menandai deployment sebagai "produksi"; deployment lain bisa ditambahkan sebagai canary lalu dialihkan trafficnya.

#Memilih Platform

Pertimbangan penting: jangan memilih karena "paling banyak tutorial" — pilih berdasarkan stack cloud yang sudah dipakai tim untuk data warehouse, CI/CD, dan security. MLOps platform tidak hidup sendirian.

#Praktik: Deploy di Managed Platform

Pola yang benar hampir selalu blue-green via traffic split, bukan deploy langsung:

ProductionVariants:
  - VariantName: blue
    ModelName: churn-v2
    InitialVariantWeight: 100
    InstanceType: ml.m5.xlarge
    InitialInstanceCount: 2
  - VariantName: green
    ModelName: churn-v2-canary
    InitialVariantWeight: 0
    InstanceType: ml.m5.xlarge
    InitialInstanceCount: 1

Alur produksi yang disarankan:

1. Canary (green) dideploy dengan weight 0 — belum menerima traffic, tapi siap.
2. Naikkan weight bertahap (5% → 25% → 100%) sambil memantau metrik endpoint.
3. Jika metrik buruk, kembalikan weight ke 100% blue — rollback instan.
4. Setelah stabil, jadikan green sebagai varian produksi.

Integrasi CI/CD tetap berlaku (episode 8): pipeline cloud di-trigger dari commit, menjalankan test, lalu memanggil API cloud untuk training dan deploy.

#Common Pitfalls

• Langsung deploy tanpa uji endpoint — perbedaan versi library antara lokal dan image platform; selalu smoke test.
• Mengabaikan biaya auto-scaling — instance menganggur di malam hari tetap ditagih; atur min_instances dan schedule.
• Semua komponen dibangun di platform vendor — containerize model (episode 4) supaya tetap portabel bila pindah cloud.
• Tidak memakai traffic split — platform sudah punya blue-green/canary built-in; gunakan, jangan deploy paksa.
• Registry cloud tidak dipakai — versi endpoint tidak terhubung ke data dan kode training; audit (episode 15) jadi sulit.

#Penutup

Pada episode 16 ini, kalian telah mengenal managed cloud ML platforms.

Inti yang harus dibawa pulang:

• Managed platform = training pipeline + registry + endpoint + monitoring dalam satu layanan.
• SageMaker, Vertex AI, dan Azure ML punya mental model serupa: artifact + endpoint + traffic split.
• Pilih platform berdasarkan stack cloud tim, bukan tren.
• Blue-green/canary via traffic split adalah pola deployment yang benar.
• Managed ≠ nol tanggung jawab; monitoring dan cost tetap di tangan kalian.

Di episode 17 selanjutnya kita akan membahas Kubernetes untuk ML — GPU scheduling, HPA untuk inference, dan serving model berskala — bagi kalian yang ingin kontrol penuh dan portabilitas lintas cloud. Sampai jumpa di episode 17!