Model Registry Chaos Engineering —

Model Registry คืออะไร

Model Registry เป็นระบบจัดการ Machine Learning models แบบ centralized เก็บ model versions, metadata, artifacts, lineage และ deployment status ทำให้ทีม Data Science และ ML Engineers จัดการ ML lifecycle ได้อย่างเป็นระบบ ตั้งแต่ training ไปจนถึง production deployment

เครื่องมือ Model Registry ที่นิยมได้แก่ MLflow Model Registry (open source, most popular), Weights and Biases (W&B) Registry, Amazon SageMaker Model Registry, Google Vertex AI Model Registry, Azure ML Model Registry แต่ละตัวมีจุดเด่นต่างกัน MLflow เหมาะสำหรับเริ่มต้นเพราะ open source และ flexible

Chaos Engineering สำหรับ ML systems สำคัญมากเพราะ ML pipelines มีจุดที่อาจล้มเหลวหลายจุด ตั้งแต่ data ingestion, feature extraction, model serving, prediction caching จนถึง fallback mechanisms การทำ chaos experiments ช่วยค้นพบจุดอ่อนก่อนที่จะเกิดปัญหาจริง

ติดตั้ง Model Registry

Setup MLflow Model Registry

เนื้อหาเกี่ยวข้อง — LlamaIndex RAG Cost Optimization ลดค่าใช้จ่าย

Chaos Engineering สำหรับ ML Systems

Chaos Engineering concepts สำหรับ ML

# === Chaos Engineering for ML ===

# 1. ML System Failure Points
# ===================================
# Data Layer:
#   - Data source unavailable
#   - Data schema changed unexpectedly
#   - Data quality degradation (drift)
#   - Feature store latency spike
#
# Model Layer:
#   - Model registry unreachable
#   - Model artifact corrupted
#   - Model version mismatch
#   - OOM during inference (large batch)
#
# Serving Layer:
#   - Model server crash
#   - GPU failure
#   - High latency under load
#   - Prediction cache miss storm
#
# Pipeline Layer:
#   - Training pipeline failure
#   - Feature pipeline delay
#   - Orchestrator (Airflow) down
#   - Storage full

# 2. Chaos Experiment Types
# ===================================
# Infrastructure chaos:
#   - Kill model server pod
#   - Network partition between services
#   - CPU/memory stress on inference nodes
#   - Disk I/O latency injection
#
# Application chaos:
#   - Inject invalid model version
#   - Corrupt feature values
#   - Simulate model registry timeout
#   - Send malformed prediction requests
#
# Data chaos:
#   - Inject data drift
#   - Remove feature columns
#   - Delay data pipeline
#   - Corrupt training data

# 3. Steady State Hypothesis
# ===================================
# Before chaos: define what "normal" looks like
# Metrics to monitor:
#   - Prediction latency p99 < 100ms
#   - Error rate < 0.1%
#   - Model serving throughput > 1000 RPS
#   - Fallback activation rate < 5%
#   - Feature freshness < 5 minutes

# 4. Tools
# ===================================
# Chaos Mesh (Kubernetes): pod kill, network chaos, IO chaos
# Litmus Chaos: workflow-based chaos experiments
# Gremlin: commercial, easy to use
# Toxiproxy: network-level chaos (latency, packet loss)
# Custom scripts: application-level chaos

echo "Chaos engineering concepts"

เขียน Chaos Experiments

Implement chaos experiments

แนะนำเพิ่มเติม — สัญญาณเทรดรายวัน XM Signal

Resilience Testing Pipeline

สร้าง pipeline สำหรับ resilience testing

เนื้อหาเกี่ยวข้อง — ดูเพิ่มเติมเรื่อง Airflow DAG Design Community Building

# === Resilience Testing Pipeline ===

# 1. Chaos Mesh Experiment (Kubernetes)
cat > chaos/pod-kill.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: model-server-pod-kill
  namespace: ml-serving
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - ml-serving
    labelSelectors:
      app: model-server
  duration: "60s"
  scheduler:
    cron: "@every 24h"
EOF

# 2. Network Chaos
cat > chaos/network-delay.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: registry-network-delay
  namespace: ml-serving
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - ml-serving
    labelSelectors:
      app: mlflow-registry
  delay:
    latency: "3000ms"
    jitter: "1000ms"
  duration: "120s"
EOF

# 3. IO Chaos (Disk latency)
cat > chaos/io-stress.yaml << 'EOF'
apiVersion: chaos-mesh.org/v1alpha1
kind: IOChaos
metadata:
  name: model-storage-io-delay
  namespace: ml-serving
spec:
  action: latency
  mode: one
  selector:
    labelSelectors:
      app: model-server
  volumePath: /models
  delay: "500ms"
  duration: "120s"
EOF

# 4. Apply experiments
kubectl apply -f chaos/pod-kill.yaml
kubectl apply -f chaos/network-delay.yaml

# 5. Monitor during chaos
# Watch metrics:
# - kubectl top pods -n ml-serving
# - linkerd viz stat deploy -n ml-serving
# - curl http://model-server/health
# - curl http://model-server/metrics

# 6. CI/CD Integration
# Run chaos tests as part of staging deployment:
# deploy to staging → run chaos experiments → verify steady state → promote to production

# 7. Game Day Checklist
# ===================================
# [ ] Notify team about game day
# [ ] Verify monitoring dashboards ready
# [ ] Confirm rollback procedures documented
# [ ] Run experiments in staging first
# [ ] Start with smallest blast radius
# [ ] Gradually increase scope
# [ ] Document all findings
# [ ] Create action items for failures
# [ ] Schedule follow-up to verify fixes

echo "Resilience testing pipeline configured"

Monitoring และ Recovery

Monitor ML systems during chaos

FAQ คำถามที่พบบ่อย

Q: Chaos Engineering ปลอดภัยหรือเปล่า?

A: ปลอดภัยถ้าทำถูกวิธี เริ่มจาก staging environment ก่อนเสมอ ใช้ blast radius เล็กที่สุด (เช่น kill 1 pod ไม่ใช่ทั้ง deployment) มี rollback plan พร้อม มี monitoring ดูผลกระทบ real-time ทำใน business hours ที่ทีมพร้อม ค่อยๆ เพิ่ม scope เมื่อมั่นใจ ไม่ทำใน production จนกว่าจะผ่าน staging ทุก experiment Netflix, Google, Amazon ทำ chaos engineering ใน production ทุกวัน แต่พวกเขามี mature observability และ rollback systems

แนะนำเพิ่มเติม — หนังสือเทรดที่ SiamCafeBook

Q: Model Registry ควรมี features อะไรบ้าง?

เนื้อหาเกี่ยวข้อง — ทำความเข้าใจ บริษัท jmt network คือ บริษัท อะไร

A: Must-have Model versioning (เก็บทุก version), Stage management (staging, production, archived), Metadata tracking (metrics, parameters, training data), Artifact storage (model files, configs), API สำหรับ programmatic access Nice-to-have Model lineage (data → training → model), A/B testing integration, Approval workflow, Automated deployment trigger, Model comparison dashboard สำหรับเริ่มต้น MLflow ฟรีและมี features ครบ สำหรับ enterprise อาจต้อง managed service เช่น SageMaker หรือ Vertex AI

Q: Chaos experiment ควรทำบ่อยแค่ไหน?

A: ขึ้นกับ maturity ของระบบ เริ่มต้น ทำ quarterly (ทุก 3 เดือน) เป็น game day event ทีมร่วมกัน Intermediate ทำ monthly เป็น automated experiments ใน staging Advanced ทำ weekly หรือ continuous ใน production (automated) ทุกครั้งที่ deploy version ใหม่ ควรรัน chaos experiments ใน staging ก่อน promote สำหรับ ML systems ที่มีการ retrain model บ่อย ควรทำ chaos test ทุกครั้งที่ deploy model version ใหม่

เนื้อหาเกี่ยวข้อง — oVirt Virtualization Testing Strategy QA

Q: Fallback strategy สำหรับ ML serving ทำอย่างไร?

A: ควรมีหลายระดับ Level 1 ใช้ cached predictions สำหรับ requests ที่เคย predict แล้ว (Redis cache), Level 2 ใช้ simpler model ที่ inference เร็วกว่า (เช่น logistic regression แทน deep learning), Level 3 ใช้ rule-based system (business rules ที่ไม่ต้องใช้ ML), Level 4 return default/safe values ที่ไม่ก่อให้เกิดความเสียหาย ตั้ง circuit breaker ที่ model serving layer ถ้า error rate สูงให้ switch ไป fallback อัตโนมัติ monitor fallback rate ถ้าสูงกว่าปกติแสดงว่ามีปัญหา