Zero-to-Scale ML: FastAPI와 HPA를 이용한 Kubernetes에 ONNX 모델 배포

Source: Dev.to

확장 가능한 ML 배포 경로는 고성능 API와 견고한 오케스트레이션을 필요로 합니다. 이 글에서는 FastAPI를 사용한 속도와 Kind를 활용한 Kubernetes 오케스트레이션을 통해 로컬에서 고가용성 및 자동 스케일링 추론 서비스를 설정하는 과정을 단계별로 살펴봅니다.

Phase 1: The FastAPI Inference Service

우리의 Python 서비스는 ONNX 모델 추론을 담당합니다. K8s 안정성을 위한 핵심 요소는 /health 엔드포인트입니다:

# app.py snippet
# ... model loading logic ...

@app.get("/health")
def health_check():
    # K8s Probes will hit this endpoint frequently
    return {"status": "ok", "model_loaded": True}

# ... /predict endpoint ...

Phase 2: Docker and Kubernetes Deployment

이미지(clothing-classifier:latest)를 빌드하고 Kind에 로드한 뒤, Deployment를 정의합니다. 여기서는 중요한 리소스 제한과 프로브 설정을 강조합니다.

# deployment.yaml (Snippet focusing on probes and resources)
resources:
  requests:
    cpu: "250m"   # For scheduling
    memory: "500Mi"
  limits:
    cpu: "500m"   # To prevent monopolizing the node
    memory: "1Gi"
livenessProbe:
  httpGet: {path: /health, port: 8000}
  initialDelaySeconds: 5
readinessProbe:
  httpGet: {path: /health, port: 8000}
  initialDelaySeconds: 5  # Gives time for the ONNX model to load

Phase 3: Implementing Horizontal Pod Autoscaler (HPA)

확장성은 HPA에 의해 관리되며, 이를 위해 Metrics Server가 실행 중이어야 합니다.

# hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: clothing-classifier-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: clothing-classifier-deployment
  minReplicas: 2
  maxReplicas: 5
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50  # Scale up if CPU exceeds 50%

Result: 부하가 걸리면 HPA가 복제본 수를 동적으로 조정합니다. 이것이 탄력적이며 비용 효율적인 MLOps의 정의입니다.

전체 가이드는 여기에서 확인하세요.