Skip to main content
이 문서는 머신러닝 섹션의 일부입니다.

Serving UI 메트릭

Model Serving 엔드포인트 페이지에서 다음 메트릭을 실시간으로 확인할 수 있습니다.
🆕 Endpoint Telemetry (Beta): OpenTelemetry 기반의 관찰 가능성 기능이 추가되었습니다. OTLP(OpenTelemetry Protocol)로 외부 모니터링 시스템(Datadog, Grafana 등)과 연동할 수 있습니다.

알림 설정 (Alerting)

모니터링 메트릭에 기반한 알림을 설정하여, 문제가 발생하면 즉시 대응할 수 있습니다.

Databricks SQL Alert 활용

알림 채널 설정


대시보드 구축 (System 테이블 기반)

종합 모니터링 대시보드 쿼리

아래 쿼리들을 Databricks SQL 대시보드에 위젯으로 추가하면, 종합 모니터링 대시보드를 구축할 수 있습니다.

멀티 엔드포인트 비교 대시보드

여러 엔드포인트를 동시에 비교하는 운영 대시보드용 쿼리입니다.

모니터링 장단점과 트레이드오프

모니터링 체계를 설계할 때 비용과 가치 사이의 트레이드오프를 이해해야 합니다.

모니터링 수준별 비교

💡 비용은 트래픽 규모, 데이터 크기, 클러스터 구성에 따라 크게 달라집니다. 실제 비용은 Databricks Cost Management에서 확인하십시오.

Inference Table: 전수 기록 vs 샘플링

Lakehouse Monitoring 설정 트레이드오프


베스트 프랙티스와 흔한 실수

베스트 프랙티스 (Best Practices)

1. 모니터링을 배포 전에 설계하세요 모델 배포 후 모니터링을 추가하면 초기 데이터가 유실됩니다. Inference Table은 엔드포인트 생성 시 함께 활성화하십시오.
2. 기준 분포(Baseline)를 반드시 저장하세요 드리프트 감지는 기준 분포와의 비교로 이루어집니다. 모델 배포 시점의 입력 데이터 분포를 별도 테이블에 저장해두십시오.
3. 모델 버전을 요청 메타데이터에 포함하세요 A/B 테스트나 Canary 배포 시, 모델 버전별 성능을 분리하여 분석할 수 있습니다.
4. P99 기준으로 SLA를 설정하세요 평균 지연시간이 아닌 P99를 SLA 기준으로 사용해야 실제 사용자 경험을 보호할 수 있습니다. 5. 비용 알림을 일별 예산과 연동하세요 예상치 못한 트래픽 급증이나 프롬프트 길이 증가로 비용이 급등할 수 있습니다.

흔한 실수 (Common Mistakes)

실수 1: Inference Table을 date 파티션 없이 쿼리
실수 2: Ground Truth 없이 드리프트만 모니터링 데이터 드리프트(입력 분포 변화)만으로는 모델 성능 저하를 확인할 수 없습니다. 가능하면 Ground Truth 레이블을 수집하여 실제 정확도를 추적하십시오. 실수 3: Scale-to-Zero 엔드포인트에 너무 짧은 타임아웃 설정 Scale-to-Zero 엔드포인트는 콜드 스타트 시 10~30초가 소요될 수 있습니다. 클라이언트 타임아웃을 콜드 스타트 시간을 고려하여 설정하십시오.
실수 4: 모니터링 대시보드만 만들고 알림 미설정 대시보드는 사람이 직접 확인해야 합니다. 반드시 임계값 기반 자동 알림을 함께 설정하십시오. 실수 5: 너무 많은 알림으로 알림 피로(Alert Fatigue) 유발 알림이 너무 자주 발생하면 담당자가 알림을 무시하게 됩니다. 알림 임계값을 비즈니스 영향 기준으로 설정하고, 긴급/비긴급 알림을 분리하십시오.

트러블슈팅 가이드


정리

모니터링 설계 원칙 요약:
  1. 배포 전 설계 — Inference Table은 엔드포인트 생성 시 활성화합니다
  2. Percentile 기반 SLA — P99를 기준으로 서비스 수준을 정의합니다
  3. 계층적 알림 — 긴급/경고/정보로 구분하여 알림 피로를 방지합니다
  4. 비용과 가치 균형 — 트래픽 규모에 맞는 샘플링 전략을 선택합니다
  5. Ground Truth 연동 — 가능하면 실제 레이블을 수집하여 성능을 검증합니다

참고 링크