Serving UI 메트릭
Model Serving 엔드포인트 페이지에서 다음 메트릭을 실시간으로 확인할 수 있습니다.| 메트릭 | 설명 |
|---|---|
| QPS (Queries Per Second) | 초당 처리 요청 수 |
| Latency (P50, P99) | 응답 시간 분포 |
| Error Rate | 실패한 요청 비율 |
| GPU Utilization | GPU 엔드포인트의 리소스 활용도 |
| Provisioned Concurrency | 동시 처리 가능한 요청 수 |
| Scale-to-Zero Events | 0으로 축소/복원된 횟수 |
| Token Throughput | LLM 엔드포인트의 초당 토큰 처리량 |
🆕 Endpoint Telemetry (Beta): OpenTelemetry 기반의 관찰 가능성 기능이 추가되었습니다. OTLP(OpenTelemetry Protocol)로 외부 모니터링 시스템(Datadog, Grafana 등)과 연동할 수 있습니다.
알림 설정 (Alerting)
모니터링 메트릭에 기반한 알림을 설정하여, 문제가 발생하면 즉시 대응할 수 있습니다.Databricks SQL Alert 활용
알림 채널 설정
| 채널 | 설정 방법 | 적합한 용도 |
|---|---|---|
| SQL Alert에서 직접 지정 | 일일 리포트, 비긴급 알림 | |
| Slack | Webhook URL 연동 | 팀 채널 실시간 알림 |
| PagerDuty | Webhook URL 연동 | 긴급 장애 대응 (On-call 연동) |
| Microsoft Teams | Webhook URL 연동 | 팀 채널 실시간 알림 |
대시보드 구축 (System 테이블 기반)
종합 모니터링 대시보드 쿼리
아래 쿼리들을 Databricks SQL 대시보드에 위젯으로 추가하면, 종합 모니터링 대시보드를 구축할 수 있습니다.멀티 엔드포인트 비교 대시보드
여러 엔드포인트를 동시에 비교하는 운영 대시보드용 쿼리입니다.모니터링 장단점과 트레이드오프
모니터링 체계를 설계할 때 비용과 가치 사이의 트레이드오프를 이해해야 합니다.모니터링 수준별 비교
| 수준 | 구성 | 월 추가 비용 (예시) | 탐지 가능 문제 |
|---|---|---|---|
| 기본 | Serving UI만 활용 | $0 | 인프라 장애, 지연시간 급증 |
| 중간 | + Inference Table (100%) | $50~200 | 스키마 오류, 입력 이상 |
| 고급 | + Lakehouse Monitoring | $200~500 | 데이터 드리프트, 모델 성능 저하 |
| 완전 | + Ground Truth 연동 | $500~2,000 | 실제 예측 정확도, 비즈니스 영향 |
💡 비용은 트래픽 규모, 데이터 크기, 클러스터 구성에 따라 크게 달라집니다. 실제 비용은 Databricks Cost Management에서 확인하십시오.
Inference Table: 전수 기록 vs 샘플링
| 항목 | 전수 기록 (100%) | 샘플링 (10%) |
|---|---|---|
| 비용 | 높음 | 낮음 (약 1/10) |
| 드리프트 감지 정확도 | 높음 | 중간 (통계적으로 충분) |
| 희귀 이벤트 캡처 | 모두 캡처 | 누락 가능 |
| 규정 준수 감사 | 완전한 감사 추적 | 불완전 |
| 적합한 환경 | 금융, 의료, 법규 준수 | 추천 시스템, 일반 ML |
Lakehouse Monitoring 설정 트레이드오프
| 항목 | 빠른 갱신 주기 (1시간) | 느린 갱신 주기 (1일) |
|---|---|---|
| 드리프트 탐지 속도 | 빠름 (1시간 이내) | 느림 (최대 24시간) |
| 컴퓨팅 비용 | 높음 | 낮음 |
| 통계적 신뢰도 | 낮음 (샘플 수 부족 시) | 높음 |
| 적합한 환경 | 실시간 의사결정 시스템 | 배치 예측 시스템 |
베스트 프랙티스와 흔한 실수
베스트 프랙티스 (Best Practices)
1. 모니터링을 배포 전에 설계하세요 모델 배포 후 모니터링을 추가하면 초기 데이터가 유실됩니다. Inference Table은 엔드포인트 생성 시 함께 활성화하십시오.흔한 실수 (Common Mistakes)
실수 1: Inference Table을date 파티션 없이 쿼리
| 알림 유형 | 채널 | 임계값 기준 |
|---|---|---|
| P1 긴급 | PagerDuty (On-call) | 에러율 > 10%, 서비스 중단 |
| P2 경고 | Slack #ml-alerts | 에러율 > 5%, P99 > 2초 |
| P3 정보 | Email 일일 리포트 | 드리프트 감지, 비용 임계값 |
트러블슈팅 가이드
| 증상 | 가능한 원인 | 확인 방법 | 해결 방안 |
|---|---|---|---|
| 지연 시간 급증 | 모델 크기 증가, 입력 길이 증가 | P99 지연 시간 트렌드 확인 | 모델 최적화, 인스턴스 크기 증가 |
| 에러율 상승 | 입력 스키마 불일치, 메모리 부족 | 에러 로그 샘플 확인 | 입력 유효성 검증 추가, 리소스 확대 |
| Scale-to-Zero 후 콜드 스타트 | 트래픽 불규칙 | 스케일링 이벤트 로그 확인 | 최소 프로비저닝 동시성 설정 |
| 토큰 비용 급증 | 프롬프트 길이 증가, 트래픽 급증 | 일별 토큰 사용량 확인 | 프롬프트 최적화, Rate Limiting |
| 드리프트 알림 | 입력 데이터 분포 변화 | Lakehouse Monitor 대시보드 확인 | 모델 재학습, 피처 파이프라인 점검 |
| Inference Table 미기록 | Auto Capture 미활성화 | 엔드포인트 설정 확인 | auto_capture_config 활성화 |
정리
| 핵심 기능 | 설명 |
|---|---|
| Inference Table | 모든 요청/응답을 Delta 테이블에 자동 기록합니다 |
| Lakehouse Monitoring | 데이터 드리프트와 모델 품질을 자동으로 감지합니다 |
| MLflow Tracing | LLM/에이전트의 실행 경로를 단계별로 추적합니다 |
| 시스템 테이블 | 모든 엔드포인트의 운영 메트릭을 중앙에서 조회합니다 |
| 비용 모니터링 | 토큰 사용량과 DBU 기반 비용을 추적합니다 |
| 알림 | SQL Alert + Webhook으로 실시간 알림을 받을 수 있습니다 |
- 배포 전 설계 — Inference Table은 엔드포인트 생성 시 활성화합니다
- Percentile 기반 SLA — P99를 기준으로 서비스 수준을 정의합니다
- 계층적 알림 — 긴급/경고/정보로 구분하여 알림 피로를 방지합니다
- 비용과 가치 균형 — 트래픽 규모에 맞는 샘플링 전략을 선택합니다
- Ground Truth 연동 — 가능하면 실제 레이블을 수집하여 성능을 검증합니다