PMLE 学習ハブ
🎯 公式メトリクス全集 + SRE 実践

Deep Dive: 運用・保守 / SRE — Observability と FinOps

本番 ML システムの SRE 観点を、Cloud Monitoring の aiplatform.googleapis.com 全メトリクスGoogle SRE Workbook の SLI/SLO フレームワークFinOps の実践 で深掘り。

📌 なぜ ML 運用は通常システムより難しいか

❶ 失敗が "silent"

「コードは正常」「200 を返す」のに「予測精度が下がっている」が起きる。通常の HTTP 監視では検知不能 → 専用 ML メトリクス + Model Monitoring が必須。

❷ コスト構造が特殊

GPU/TPU は CPU 比 10〜100 倍。1 行のミス(プロビジョン放置 / 大型モデル選定)で月数百万円。常時 FinOps 観点で監視する。

❸ データ品質が SLA を決める

「コード変更ゼロ」でもデータドリフトで品質劣化。データパイプライン健全性も SLO 対象

❹ ロールバックが複雑

「旧モデルに戻す」だけでは不十分。旧 Feature Store・旧前処理・旧 Endpoint 設定 がセットでないと再現できない。Model Registry + Lineage が前提。

📡 オブザーバビリティの 4 シグナル + ML 拡張

SRE の伝統的「Four Golden Signals」に、ML 特有の指標を加える。

カテゴリシグナル説明ML での測定方法
基本 4 シグナルLatencyレスポンス時間(成功/失敗別)prediction/online/prediction_latencies (p50/p95/p99)
Traffic需要量prediction/online/prediction_count
Errors失敗率prediction/online/error_count, response_count{response_code}
Saturationリソース飽和度cpu/utilization, accelerator/duty_cycle, memory/bytes_used
ML 拡張Drift入力分布変化model_monitoring/feature_drift_deviation
Attribution Drift特徴量寄与度変化model_monitoring/feature_attribution_deviation
Prediction Drift予測値分布変化model_monitoring/prediction_output_drift_deviation
Feature Freshness特徴量の鮮度featureonlinestore/serving_data_ages
Accuracy真の精度(要ラベル)カスタムメトリクス + Continuous Evaluation

📊 Cloud Monitoring メトリクス全集(aiplatform.googleapis.com

以下は本番監視で使う 130+ メトリクスの中から、PMLE 運用で必須のもの を抜粋・整理。すべて aiplatform.googleapis.com/ プレフィックス。

🚦 Endpoint / DeployedModel メトリクス

メトリクス種別用途
prediction/online/prediction_countDELTA INTQPS(per deployed_model_id / endpoint_display_name
prediction/online/prediction_latenciesDELTA DISTp50/p95/p99 レイテンシ(per latency_type
prediction/online/error_countDELTA INTエラーカウント(error_rate = error/prediction)
prediction/online/response_countDELTA INTレスポンスコード別カウント(HTTP 5xx / 4xx の比率)
prediction/online/replicasGAUGE INT現在のアクティブレプリカ数
prediction/online/target_replicasGAUGE INTオートスケールが目指す目標値(current < target なら scale out 中)
prediction/online/machine_countGAUGE INTVM 数
prediction/online/cpu/utilizationGAUGE DBLCPU 使用率(per replica)
prediction/online/memory/bytes_usedGAUGE INTメモリ使用量
prediction/online/accelerator/duty_cycleGAUGE DBLGPU/TPU 利用率(低いと過剰プロビジョン)
prediction/online/accelerator/memory/bytes_usedGAUGE INTHBM/VRAM 使用量(OOM の前兆)
prediction/online/network/received_bytes_countDELTA INT受信帯域
prediction/online/network/sent_bytes_countDELTA INT送信帯域
prediction/online/private/prediction_latenciesDELTA DISTPrivate Endpoint 専用レイテンシ
ラベル spot の威力 上記メトリクスのほとんどに spot=true/false ラベルがあり、Spot VM 利用分とオンデマンド分のコスト/性能を分離できる。「Spot 採用で 60% コスト削減、レイテンシ p99 は + 5%」のような可視化が可能。

必須アラート(Endpoint)

# 例:error_rate > 1% (5 分間) で warn
fetch aiplatform.googleapis.com/Endpoint
| metric 'aiplatform.googleapis.com/prediction/online/error_count'
| align rate(5m)
| every 1m
| group_by [resource.endpoint_id], sum(value)
| join (
    fetch aiplatform.googleapis.com/Endpoint
    | metric 'aiplatform.googleapis.com/prediction/online/prediction_count'
    | align rate(5m)
    | every 1m
    | group_by [resource.endpoint_id], sum(value)
)
| value [val(0) / val(1) * 100]
| condition val() > 1.0

🌟 Publisher(Gemini / 生成 AI)メトリクス

生成 AI 専用メトリクス群。トークン課金体系の可視化に必須

メトリクス種別用途
publisher/online_serving/token_countDELTA INT入出力トークン累積(per type, modality, explicit_caching
publisher/online_serving/character_countDELTA INT文字数累積(Gemini の char-based pricing)
publisher/online_serving/consumed_throughputDELTA INT消費スループット(chars/sec)
publisher/online_serving/consumed_token_throughputDELTA INT消費トークン スループット
publisher/online_serving/model_invocation_countDELTA INT呼び出し回数(per response_code, error_category
publisher/online_serving/model_invocation_latenciesDELTA DIST全体レイテンシ(per latency_type, explicit_caching
publisher/online_serving/first_token_latenciesDELTA DISTTTFT (Time To First Token) — ストリーミング UX の KPI
publisher/online_serving/dedicated_token_limitGAUGE INTProvisioned Throughput の枠(tokens/sec)
publisher/online_serving/dedicated_token_project_max_limitGAUGE INTプロジェクト最大上限
explicit_caching ラベルの活用 token_count{explicit_caching=true}token_count 全体で割れば、Context Caching のヒット率 が算出できる。ヒット率が下がってきたら GCS 元データの更新事故(silent invalidation)を疑う。

🗂 Featurestore(旧版)メトリクス

レガシー Feature Store 用。新規プロジェクトは Feature Online Store を使うが、既存資産の監視は引き続き重要。

メトリクス用途
featurestore/online_serving/request_countサービング QPS(per entity_type_id, method, error_code
featurestore/online_serving/latenciesサービングレイテンシ
featurestore/online_serving/response_sizeレスポンスサイズ(大きいと帯域消費)
featurestore/storage/stored_bytesストレージ容量(per storage_type
featurestore/node_countオンラインノード数
featurestore/cpu_load平均 CPU 負荷
featurestore/cpu_load_hottest_node最も負荷の高いノード(ホットスポット検知)
featurestore/online_entities_updated更新エンティティ数
featurestore/streaming_write/offline_write_delaysオフライン反映遅延

🟦 Feature Online Store(新版・Bigtable)メトリクス

メトリクス用途
featureonlinestore/online_serving/request_countQPS(per feature_view_id, storage_type
featureonlinestore/online_serving/serving_latenciesサーバ側レイテンシ(ms)
featureonlinestore/online_serving/serving_bytes_countレスポンス bytes
featureonlinestore/serving_data_ages特徴量の鮮度(秒)。本番 ML の KPI
featureonlinestore/serving_data_by_sync_timesync 時刻別データ分布
featureonlinestore/running_sync実行中の sync 数(多すぎ = sync 詰まり)
featureonlinestore/storage/bigtable_cpu_loadBigtable ノードの平均 CPU 負荷
featureonlinestore/storage/bigtable_cpu_load_hottest_nodeホットスポット監視
featureonlinestore/storage/bigtable_nodesBigtable ノード数(オートスケール監視)
featureonlinestore/storage/stored_bytesストレージ容量
Feature Freshness SLO の例 serving_data_ages の p95 が 3600 秒(1 時間)以下を月間 99% で維持。 これを満たさないなら:sync スケジュール頻度↑、ETL 高速化、または許容鮮度の見直し。

⛓ Pipelines メトリクス

メトリクス用途
executing_vertexai_pipeline_jobs実行中ジョブ数(同時実行の上限管理)
executing_vertexai_pipeline_tasks実行中タスク数(並列度の可視化)
pipelinejob/durationジョブ作成→完了の秒数
pipelinejob/task_completed_count累積完了タスク数

📡 Model Monitoring メトリクス

メトリクス用途
model_monitoring/feature_drift_deviation特徴量ドリフト値(per feature_name, algorithm
model_monitoring/feature_attribution_deviation特徴量寄与度のドリフト
model_monitoring/prediction_output_drift_deviation予測値分布のドリフト
online_evaluator/evaluations_count継続評価ジョブ数
online_evaluator/scores評価スコア分布(LLM-as-a-judge 結果など)

🔍 Vector Search (Matching Engine) メトリクス

メトリクス用途
matching_engine/query/request_countクエリ QPS(per is_private_endpoint, response_code
matching_engine/query/latenciesクエリレイテンシ(per index_type
matching_engine/current_replicas現在のレプリカ数
matching_engine/current_shardsシャード数
matching_engine/stream_update/request_countストリーミング更新の QPS
matching_engine/stream_update/datapoint_countupsert/remove 成功カウント
matching_engine/cpu/request_utilizationCPU 利用率
matching_engine/memory/used_bytesメモリ使用量

⚠️ Quota メトリクス

各種 quota の /usage, /limit, /exceeded を監視。「上限の 80% で warn、95% で critical」が定石。

🎯 SLI / SLO / Error Budget — ML 向け実践

Google SRE Workbook より:「An SLI is the ratio of two numbers: the number of good events divided by the total number of events.」シンプルな ratio で表現するのが最強。

100% SLO は禁忌 公式 SRE:「The number one source of outages is change ... that will impact that 100% target.」 100% を目指すと全変更が止まり、新機能・セキュリティパッチ・スケールも禁止になる。 必ず 100% 未満の目標を設定し、残りを Error Budget として変更に投資する

📐 ML 向け SLI の型

SRE Workbook の 3 分類 + ML 拡張:

コンポーネント型主要 SLIML での具体例
Request-driven(Online Inference)AvailabilityHTTP 2xx 数 / 全リクエスト数 ≥ 99.9%
Latency200 ms 以内のリクエスト数 / 全リクエスト数 ≥ 95%
Quality(生成 AI)Safety filter pass / 全生成数 ≥ 99%
Pipeline(訓練・ETL)Freshness特徴量の age が 1 時間以内のリクエスト ≥ 99%
Correctnessパイプライン出力が data validation 合格 ≥ 99.9%
Coverage処理成功レコード / 全入力レコード ≥ 99.5%
Storage(Model Registry / Feature Store)Durability書き込みアーティファクトが後で取得成功 ≥ 99.999%
Retrieval特徴量取得が < 50ms ≥ 99%
ML 特有Accuracy本番 accuracy が baseline の 95% 以上を維持する日数 ≥ 月の 95%
Fairness属性間の FPR 差が 0.05 以内である日数 ≥ 月の 95%

具体的な ML SLO 設計例

# 例:商品レコメンデーション API の SLO 文書
SLO Title: Recommendation API Reliability
Approved by: Eng Lead, PM, SRE
Review cadence: 四半期

SLI 1: Availability
  - Formula: count(response_code in [200, 304]) / count(all responses)
  - Source: aiplatform.googleapis.com/prediction/online/response_count
  - Window: rolling 28 days
  - Target: ≥ 99.9% (error budget = 0.1% ≈ 2,419 errors per 3M requests)

SLI 2: Latency
  - Formula: count(latency < 100ms) / count(all responses)
  - Source: aiplatform.googleapis.com/prediction/online/prediction_latencies
  - Window: rolling 28 days
  - Target: ≥ 95%

SLI 3: Feature Freshness
  - Formula: count(serving_data_ages < 3600s) / count(all requests)
  - Source: aiplatform.googleapis.com/featureonlinestore/serving_data_ages
  - Window: rolling 28 days
  - Target: ≥ 99%

Error Budget Policy:
  - 25% 消費: PM/Eng/SRE に通知
  - 50% 消費: 全 feature work 一時停止、信頼性 backlog 優先
  - 75% 消費: 全変更 freeze、必須 fix のみ
  - 100% 消費: 経営層エスカレーション、リスク再評価

🔥 バーンレート アラート(Multi-burn-rate, Multi-window)

従来の「閾値割れで即 page」だと false positive 多発 + 検知遅延。SRE Workbook 推奨は multi-burn-rate

バーンレートの基本

推奨 2-window / 2-burn-rate 構成

Severity長い window短い windowバーンレート閾値消費予算
Critical(PagerDuty)1 時間5 分≥ 14.42% in 1h
Warning(Slack)6 時間30 分≥ 65% in 6h
Slow burn(チケット)3 日6 時間≥ 110% in 3 days

2 window 必須の理由:短い window の急変だけで page すると瞬間的スパイクで誤発火、長い window だけでは検知遅延。両方が条件を満たした時のみ page。

📋 エラーバジェット・ポリシー

SRE Workbook:「Establishing an SLO creates measurement; an error budget policy creates accountability.」SLO を作っても、ポリシーがなければ "ただのダッシュボード"。

典型的なポリシー条項

  1. 予算 50% 消費:dev チームは信頼性バグを feature より優先
  2. 予算 100% 消費:feature freeze、信頼性復旧まで release 禁止
  3. 予算枯渇でも例外的に変更が必要:senior leadership 承認 + 文書化
  4. 四半期に 1 回 review:SLO が緩すぎないか、厳しすぎないか

📜 ログとトレース

Cloud Logging

Endpoint コンテナの stdout/stderr が自動収集。Custom Training は /var/log-storage/output*.log も。log-based metrics で「ERROR を含む log の rate」を Cloud Monitoring メトリクス化。

Cloud Trace

分散トレース。「API Gateway → モデル → DB」の各段階レイテンシを可視化。ボトルネック特定に必須。

Cloud Audit Logs

「誰がいつどのモデルを deploy したか」「誰が VPC SC を変更したか」が全て記録。監査・コンプライアンス対応の基盤。

Error Reporting

stack trace を集約してエラー単位でグループ化。「新エラー発生」を自動検知。

Cloud Profiler

CPU / Heap のサンプリングプロファイラ。「推論コードのどこが遅いか」 を本番で見られる。

Vertex AI TensorBoard

訓練ジョブのスカラ・分布・画像を可視化。本番モデルにも custom run を上げる ことで再現性確保。

推奨ログ設計

# 構造化ログを stdout に出す(Cloud Logging が自動取り込み)
import json, sys, time

def log(severity, message, **fields):
    entry = {
        "severity": severity,
        "message": message,
        "timestamp": time.time(),
        **fields,
    }
    print(json.dumps(entry), file=sys.stdout, flush=True)

log("INFO", "prediction_completed",
    model_version="v3.2",
    latency_ms=87,
    feature_age_seconds=420,
    request_id=request_id,
    user_segment="premium")

💰 コスト管理 (FinOps) — 本番運用の最大課題

4 つの防衛ライン

[ライン 1: Quota] サービス側で物理的に制限(quota 超過で API 拒否) [ライン 2: Budget] 予算超過で alert(請求書には到達するが通知される) [ライン 3: Labels] コスト分解で異常な team/env を即特定 [ライン 4: Reviews] 週次/月次の cost review

1. Quota の活用(最強の予防策)

2. Budget Alerts

# 例:月次 budget $10,000 で 50/90/100% アラート
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="ML Production Monthly" \
  --budget-amount=10000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0,basis=current-spend \
  --notifications-rule-pubsub-topic=projects/PROJECT/topics/budget-alerts \
  --notifications-rule-monitoring-notification-channels=...

3. Resource Labels によるコスト分解

4. サービス別コスト最適化レシピ

サービス主要レバー削減幅目安
Custom TrainingSpot VM + checkpoint, DWS, BF16 mixed precision60〜80%
TPU 訓練v5e(推論寄り)/ v5p(訓練)の使い分け、Multislice 活用30〜50%
Endpointmin_replicas 適正化、L4 / TPU v5e、量子化、Cloud Run 代替50〜70%
Gemini APIFlash / Pro 使い分け、プロンプトキャッシング、Batch API、ファインチューニングで短プロンプト化70〜90%
Pipelinescaching 適切な有効化、failure_policy で早期停止、並列度制限20〜40%
Feature Storenode 数最小化、不要 sync スケジュール削除30〜50%
BigQuery MLpartition / cluster、dry run でコスト見積もり、Reserved Slots40〜70%
Workbenchidle shutdown 30 分、GPU 不要なら CPU、Persistent Disk サイズ最小50〜80%
Cloud Logging不要ログを除外フィルタで sink せず、保持期間短縮30〜60%
FinOps の鉄則
  1. 「念のため min_replicas=10」は最大の浪費。SLO から逆算した最小値を設定
  2. 本番でも Spot VM + チェックポイント でバッチ推論コスト 60% 削減
  3. Gemini Pro 固定は怠惰。Flash 7 割 + Pro 3 割の使い分け でコスト 1/5
  4. Pipelines 並列実行は quota の見積もり ありき。GPU quota より並列度↓に
  5. BQ ML.GENERATE_TEXT は必ず dry run + 小サンプル試算

📈 キャパシティ計画

本番 ML のキャパシティ計画は通常 Web より 遥かに難しい

計画プロセス

  1. 需要予測:traffic の季節性・キャンペーン・新機能 launch を反映
  2. per-replica capacity:負荷試験で「1 replica = X QPS @ p95 100ms」を実測
  3. 必要 replica 数の計算:peak QPS / per-replica capacity × 安全係数 1.5
  4. Quota & Reservation 確保:3 ヶ月先まで Committed Use Discount で押さえる
  5. Spot Pool 併用:ベース負荷をオンデマンドで、スパイクを Spot で

🚨 インシデント対応プレイブック

共通の対応フロー

[Alert 発火 (PagerDuty)] ↓ [Incident Commander 指名 / Slack に専用チャネル] ↓ [初動 5 分] ├─ Cloud Monitoring ダッシュボードを開く ├─ Cloud Logging で errors を検索 ├─ 直近 1 時間の変更ログ (deploy/config) を確認 └─ Status Page で GCP インシデント有無確認 ↓ [判断] ├─ 即座にロールバック可能 → traffic_split で旧 version に戻す ├─ 根本原因不明 → 影響緩和を優先(rate limit / circuit breaker / scale up) └─ サードパーティ起因 → エスカレーション、ユーザ周知 ↓ [復旧確認] SLI 復帰、error budget 消費量算出 ↓ [Postmortem (Blameless)] 24 時間以内に root cause, action items 文書化

ML 特有の典型シナリオ別プレイブック

症状初動復旧
p99 レイテンシ急増replica 数確認、accelerator/duty_cycle 確認min_replicas↑、コールドスタート防止
error_rate 急増response_code 別カウント、最近の deploy 確認旧 model_version へ traffic_split で戻す
OOM kill 多発memory/bytes_used 確認、新モデルのサイズ確認machine_type 拡大、量子化検討
data drift alertfeature_drift_deviation でどの特徴量か特定再訓練 pipeline trigger、上流データ確認
quota exceededquota usage 確認、超過した API 特定緊急 quota 引き上げ申請、rate limit 強化
Gemini レイテンシ悪化first_token_latencies, cached token ratio 確認Flash へ fallback、別 region へルーティング
Pipeline 連続失敗Cloud Logging で失敗 task ログ、ML Metadata で lineage 確認scheduled run pause、修正後再走

🛡 セキュリティ運用

Audit Logs の定期 review

四半期に 1 回、Cloud Audit Logs で「予期せぬ deploy」「IAM 変更」「VPC SC 変更」を review。 Cloud Logging の log-based metric 化で異常を自動検知。

IAM の最小権限と Access Reviews

月次で IAM Recommender の提案を review。Service Account の キーローテーション(推奨:90 日)。 Workload Identity Federation で長期キー排除。

Secrets 管理

Secret Manager で集中管理。Notebook や訓練コードに 絶対に 平文書き込み禁止。 Secret Manager 自動ローテーション設定。

VPC SC 監視

境界違反は Audit Logs で全て記録。Dry-run モードで事前検証してから enforce。 境界変更は change management 必須。

Model Armor 運用

Inspect Only ログを 週次レビュー、誤検知パターンを抽出して閾値調整。 Block 化は段階的に。

OSS モデル監査

Model Garden の suspicious flag を org policy で deny。 独自に HuggingFace モデルをロードする場合は事前スキャンを義務化。

🔁 Toil(繰り返し作業)削減

SRE Workbook:「If high toil accompanies SLO misses, reduce toil through automation or loosen objectives—but never accept both simultaneously.

ML 運用の典型的 Toil と自動化

Toil自動化
毎週の再訓練を手動 triggerCloud Scheduler + Pipelines
data drift を毎日目視確認Model Monitoring + alert → 自動再訓練
release 前にメトリクス手動比較Pipelines にモデル検証ステップ + 条件分岐
本番デプロイ後の手動カナリア観察Cloud Monitoring + automatic rollback(バーンレート連動)
毎月のコストレポート作成BQ Billing export + 定期 query + Looker dashboard
Workbench 起動の手動停止Idle shutdown
quota 超過の都度申請定期キャパシティ計画 + Reservation
Audit log 監視log-based metric + alert
Toil の上限ルール Google SRE の慣行:1 人あたり週の作業時間の 50% を超えて toil に使わない。50% を超えたら自動化プロジェクトを最優先化、または人員追加。

📊 推奨ダッシュボード構成(4 階層)

Layer 1: Executive(経営層・週次レビュー)

Layer 2: Service Owner(モデルオーナー・日次)

Layer 3: On-call(オンコール対応・リアルタイム)

Layer 4: ML Engineer(モデル開発・週次)

📚 参考リンク(一次情報)