MLOpsの構成要素

MLOpsの全体アーキテクチャ

MLOpsシステムは複数のコンポーネントが連携して動作します。大きく5つのレイヤーに分けて理解しましょう。

┌─────────────────────────────────────────────┐
│            モニタリング・ガバナンス            │
├─────────────────────────────────────────────┤
│              サービング・推論                 │
├─────────────────────────────────────────────┤
│         パイプライン・オーケストレーション       │
├─────────────────────────────────────────────┤
│     実験管理  │  モデルレジストリ  │ 特徴量ストア │
├─────────────────────────────────────────────┤
│         データ管理・バージョニング              │
└─────────────────────────────────────────────┘

コンポーネント1: データ管理

MLシステムの根幹はデータです。データの品質管理、バージョニング、リネージ（系譜）追跡が必要です。

データ管理の構成要素

データバージョニングの仕組み

# DVC によるデータバージョニングの例
# Gitのようにデータをバージョン管理する

# 1. データファイルをDVC管理下に追加
# $ dvc add data/train.csv
# => data/train.csv.dvc が生成される（メタデータ）

# 2. .dvcファイルはGitで管理
# $ git add data/train.csv.dvc data/.gitignore
# $ git commit -m "Add training data v1"

# 3. データの実体はリモートストレージに保存
# $ dvc push

データバリデーションの重要性

学習データの品質が低いと、モデルの性能が劣化します。以下のチェックを自動化します：

コンポーネント2: 実験管理

データサイエンティストが行う実験（ハイパーパラメータ調整、特徴量選択など）を体系的に記録・比較する仕組みです。

実験管理で記録すべき情報

実験管理なしの場合

# ファイル名でバージョン管理している状態...
models/
├── model_v1.pkl
├── model_v2.pkl
├── model_v2_improved.pkl
├── model_v2_improved_final.pkl
├── model_v2_improved_final_really_final.pkl  # ← どれが本番？
└── model_best.pkl

実験管理ありの場合

# MLflow UI で一覧表示
Run ID     | Model    | LR    | Accuracy | F1    | Status
-----------|----------|-------|----------|-------|--------
a1b2c3d4   | XGBoost  | 0.01  | 0.923    | 0.891 | Production
e5f6g7h8   | XGBoost  | 0.05  | 0.918    | 0.885 | Archived
i9j0k1l2   | LightGBM | 0.03  | 0.915    | 0.878 | Staging

コンポーネント3: モデルレジストリ

学習済みモデルのライフサイクル（登録 → ステージング → 本番 → 退役）を管理するコンポーネントです。

モデルのライフサイクル

[登録] → [ステージング] → [本番] → [アーカイブ]
  │          │               │           │
  │    テスト・検証      推論サービング   退役・保管
  │
 実験完了後に
 レジストリ登録

モデルレジストリの機能

コンポーネント4: 特徴量ストア

特徴量（Feature）を一元的に管理・提供するコンポーネントです。学習時と推論時で同じ特徴量を使用することを保証します。

特徴量ストアが解決する問題

特徴量ストアのアーキテクチャ

[データソース] → [特徴量変換] → [オフラインストア]（学習用）
                                     ↓ 同期
                               [オンラインストア]（推論用）
                                     ↓
                               [推論サービス]

コンポーネント5: パイプラインオーケストレーション

データの取得からモデルのデプロイまでの一連のステップを自動化・管理するコンポーネントです。

パイプラインの構成ステップ

[データ取得] → [データ検証] → [前処理] → [特徴量生成]
     ↓                                      ↓
[モデル学習] → [モデル評価] → [モデル登録] → [デプロイ]
                                              ↓
                                         [モニタリング]

オーケストレーションツールの比較

コンポーネント6: サービング・推論

学習済みモデルを使って推論リクエストに応答する仕組みです。

サービング方式の比較

コンポーネント7: モニタリング・ガバナンス

本番環境でのモデルの性能とデータの品質を継続的に監視するコンポーネントです。

モニタリングの対象

コンポーネント間の連携

各コンポーネントは独立ではなく、密接に連携して動作します：

まとめ

チェックリスト

• MLOpsの7つの主要コンポーネントを列挙できる
• 各コンポーネントの役割と代表的なツールを説明できる
• Training-Serving Skewの問題を説明できる
• コンポーネント間の連携パターンを3つ以上挙げられる

次のステップへ

MLOpsの構成要素を理解しました。次は、これらを実現するツールのエコシステムを俯瞰しましょう。

推定読了時間：30分