MLOpsスクラップ

[masatakashiwagi]

MLOpsに関する記事をスクラップする

• Awesome MLOps
  • https://github.com/visenger/awesome-mlops

[masatakashiwagi]

Machine Learning Operations (MLOps)

Link

• https://www.datarobot.com/jp/wiki/machine-learning-operations-mlops/
• https://www.datarobot.com/jp/lp/why-you-need-mlops/
• https://www.datarobot.com/jp/mlops-101/

内容

• MLOpsの提供機能について，DataRobotのケース

  1. モデルのデプロイの簡素化
  2. 機械学習の監視

     • その主な機能には，重要な特徴量のデータドリフト検出とモデル固有の指標がある

  3. 本稼働環境のライフサイクル管理

     • ビジネスアプリケーション向けのサービスを中断することなく，本稼働環境でモデルのテストおよび更新を行える

  4. 本稼働環境でのモデルガバナンス

     • アクセス制御・トレーサビリティの確保・監査証跡を行ってリスクを最小限に抑え，規制に確実に準拠できる

• デプロイに関する問題

  • モデルを開発環境から本稼働環境に移すためのプロセスが標準化されていないか問題がある
  • デプロイプロセスでのモデルのトラブルシューティングに時間がかかる
  • モデルを本稼働環境にデプロイするために複数のシステムを更新する必要があり，プロセスが複雑である

• 監視に関する問題

  • モデルが本稼働環境で使用されているが，監視されていない
  • モデルが社内のさまざまなシステムにデプロイされているが，それらを一元的に監視する方法がない

• ライフサイクル管理の問題

  • 本稼働環境のモデルを更新するときに，データサイエンティストの負荷が高い

• モデルガバナンスに関する問題

  • 本稼働環境へのアクセス管理ができない
  • モデルの結果を追跡できない
  • モデルの監査証跡を取得できない
  • モデルのアップグレード承認ワークフローが複雑である

組織のMLOps基盤の成熟度は，一連のプロセスの完成度や運用のあり方によって測ることができます．たとえば以下の点を評価します．

• モデルの作成，トレーニング，承認方法
• モデルの保存先
• モデルのデプロイ方法
• 本稼働環境のモデルの評価および監視方法
• リスクを最小化するための本稼働環境のモデルの修正または削除方法
• 機械学習運用プロセスを繰り返すための，上記のプロセスの管理の方法

モデルのライフサイクルの全ステップを自動化して効率を向上し，プロセスを完全に可視化した状態

[masatakashiwagi]

MLOps Checklist | phData

Link

• https://offers.phdata.io/hubfs/Checklists/MLOps%20Checklist%20for%20Model%20Deployment.pdf

内容

• 全部で9個のチェック項目
• 項目:
  • Store models in a registry
  • Deduplicate effort with a feature store
  • Test code and validate assumptions
  • Use CI/CD to automate ML deployments
  • Automate model retrainin
  • Capture data and predictions from production
  • Monitor for drift
  • Architect for reliability
  • Evaluate models continually and iterate

[masatakashiwagi]

MLOps Principles

Link

• https://ml-ops.org/content/mlops-principles

内容

• Googleのやつと同じかも？

[masatakashiwagi]

Machine Learning Operations maturity model

Link

• https://docs.microsoft.com/en-us/azure/architecture/example-scenario/mlops/mlops-maturity-model

内容

• Microsoftが定義しているMLOpsのガイド
• MLOps成熟度モデルは，MLOps環境を構築する上で必要となるDevOpsのPrinciples ＆ Practicesを明示したもの
  • 現状と理想のギャップを特定することを目的としている
• MLOps成熟度モデルは，人/カルチャー・プロセス/構造・オブジェクト/技術を定性的に評価するもの
• MLOps成熟度モデルは5段階で評価される

Level 0 - No MLOps

Highlights

• 機械学習モデルのライフサイクル全体を管理できていない
• チームがバラバラで，リリースに時間がかかる
• ほとんどのシステムは「ブラックボックス」として存在し，導入時や導入後のフィードバックが少ない

Technology

• 手動でのビルドとデプロイ
• モデルとアプリケーションの手動テスト
• モデルのパフォーマンスを一元的に管理できていない
• モデルの学習は手動実行

Level 1 - DevOps but no MLOps

Highlights

• MLOpsを使わない場合に比べればリリースの手間は省けるが，新モデルが出るたびにデータチームに頼っている状態
• 本番環境でのモデルの性能に関するフィードバックが少ない
• 結果のトレース/再現が困難

Technology

• ビルドの自動化
• アプリケーションコードの自動テスト

Level 2 - Automated Training

Highlights

• 学習環境は完全に管理され，追跡可能な状態
• モデルの再現が容易
• リリースは手動だが，frictionが少ない

Technology

• モデル学習の自動化
• モデル学習のパフォーマンスを一元的に追跡可能な状態
• モデルの管理

Level 3 - Automated Model Deployment

Highlights

• リリースは少ないでfriction自動化されている状態
• デプロイメントからオリジナルデータへの完全なトレーサビリティ
• 環境全体の管理: 学習＞テスト＞本番

Technology

• デプロイ時のモデル性能のA/Bテストが実施されている状態
• 全てのコードのテストが自動化されている状態
• 実験結果が追跡可能でモデル性能を一元的に管理できている状態

Level 4 - Full MLOps Automated Operations

Highlights

• システム全体の自動化と容易なモニタリング
• プロダクションシステムは改善のための情報を提供し，場合によっては新しいモデルで自動的に改善される
• ダウンタイムゼロのシステムに近づける

Technology

• モデルの学習とテストの自動化
• デプロイしたモデルから取得できる詳細なメトリクスの管理

[masatakashiwagi]

Thirty-One Checks For Different Levels of Machine Learning Operation Maturity

Link

• https://towardsdatascience.com/thirty-one-checks-for-different-levels-of-machine-learning-operation-maturity-2ba19cc87be9

内容

• 31個のチェックリスト
• Apple, Google, IBM, and MicrosoftはLevel 4に達している

The generic steps of Machine Learning Operations (MLOps)

• Data Extraction
• Data Munging
• Data Version Control
• Model Training
• Model Testing
• (Model Debugging)
• Trained Model Version Control
• Model Deployment
• Logging Model Deployment
• Deployment Security Monitoring
• Model Logging
• Model Bias Monitoring
• Model Data Drift Monitoring
• Model Load, Resource Usage, and Cost Monitoring
• Model Security Monitoring
• other Types of Monitoring
• 参考論文: Challenges in Deploying Machine Learning: a Survey of Case Studies

Level Check

• MLOps Maturity Level 0
  • 開発・テスト・セキュリティ・システム運用・その他の役割が同じようなサイロ（容器/箱）に分かれている
  • コードがバージョン管理されていない
  • 手動でのビルドとデプロイ
  • コードの手動テスト
  • 対策:
    • MLOpsのプロセスステップごとにツールを選ぶ
• MLOps Maturity Level 1
  • データの抽出からMLアプリケーションのデプロイまで，すべてのステップでバージョン管理が存在しない
  • 対策:
    • サービスごとに1つの共有コードベースを使用する
    • 設定ファイルを含むすべてのコードはバージョン管理されている
    • コードビルドの自動化
    • コードのユニットテストの自動化
    • 完全なDevOpsプロセスの確立
  • 参考: Principles of DevOps
• MLOps Maturity Level 2
  • プロジェクトはDevOpsが確立された状態でスタート
  • MLアプリケーションのパイプラインのほとんどのステップは手動
  • 手動でのMLモデルの最適化
  • MLモデルのトレーニング・テスト・検証を手作業で行う
  • MLモデルのトレーニング・テスト・パフォーマンスの検証を一元的に追跡していない
  • MLモデルの結果を再現できない，または再現が難しい
  • MLモデルとMLアプリケーションの手動テスト
  • MLモデルのトレーニングの追跡・監視・記録が限られている
  • 対策:
    • 固定されたランダムシードがあれば，すべての出力は再現可能である
    • データ抽出からモデル検証までのモデル学習パイプラインは再現可能で，ほぼ完全に自動化されている
    • MLモデル学習のトラッキング・モニタリング・ロギング
    • モデル学習の最適化が追跡される
    • モデルの学習・テスト・検証のメトリクスが追跡される
    • データセットはバージョン管理されている
    • すべての学習モデルのバージョンは，たとえ開発中のモデルであっても．バージョン管理されている
    • データの特徴（メタデータ）はバージョン管理されている
  • 参考:
    • メタデータの管理においては，以下のような特徴があると使うのが良い
      • 大規模で多様なデータセットを持っている場合
      • または，データの様々なサブセットを使用する多くのMLモデルがある場合
      • データセットが時間とともに変化する場合
      • MLモデルからデータセットまでの再現性と監査証跡が必要な場合
• MLOps Maturity Level 3
  • データ抽出から本番のMLアプリケーションまでの監査証跡がないか，限定されている
  • 本番用MLアプリケーションのモニタリングが限定的または皆無である
  • データドリフトが検出されない
  • MLアプリケーションがコンピューティングリソースに分散されていない
  • MLアプリケーションの導入は手動で行われ，追跡されていない
  • デプロイメントから元のデータへの完全なトレーサビリティ（監査証跡）がない
  • 対策:
    • 本番用MLアプリケーションの自動ビルドとデプロイ
    • 計算機資源を仮想マシン（VM）に抽象化する -> Cloud Service
    • 計算ロジックを仮想サービス（VS）に抽象化する -> コンテナ化
    • コード・MLモデル・インフラの依存関係を明示的に宣言し，分離する
    • 可能であれば，モノリシックなアプリケーションをサービスに，サービスをマイクロサービスに変換する
    • 分散した計算資源のネットワークには分散オペレーティングシステムを使用する
    • アプリを1つまたは複数のステートレスプロセスとして実行する
    • 複製された仮想サービスでスケーラビリティを実装する
    • 回復可能な仮想サービスによるフォールト・トレランスの実現
    • ポートバインディング（エンドポイント）によるサービスのエクスポート
    • インフラのコードとインフラの環境変数はバージョン管理されている
• MLOps Maturity Level 4
  • 対策:
    • エンタープライズMLOpsのガバナンス検討開始
    • 開発コードと本番コードのステージの違いを最小化
    • ログをイベントストリームとして扱う
    • 変更管理の自動化のために，宣言的なステートメントパーサー（フォーマット）を使用する
    • ツール・アーキテクチャ・または開発手法を大幅に変更することなく，MLOpsの下でコンポーネントをスケールアップする
    • クラウドプラットフォームへの展開によるコストの最適化

[masatakashiwagi]

Continuous Integration and Deployment for Machine Learning Online Serving and Models

Link

• https://eng.uber.com/continuous-integration-deployment-ml/

内容

Introduction

• いくつかの課題
  1. リアルタイム予測サービスの高い可用性を維持しながら，大量のモデルのデプロイを毎日サポートすること
  2. 新たに再学習されたモデルがデプロイされると，Real-time Prediction Serviceのインスタンスに関連するメモリ負荷が大きくなる
  3. モデルのロールアウト戦略
  4. モデルデプロイ時に，モデルデプロイサービスはサンプルデータを用いて候補モデルに予測コールを行うことで検証を行うが，リアルタイム予測サービスにデプロイされた既存のモデルとの照合は行わない．モデルが検証に合格したとしても，そのモデルが本番のリアルタイム予測サービスのインスタンスに展開されたときに，（機能変換やモデル評価のために）使用できる，または同じ動作をするという保証はない

Model Deployment

Dynamic Model Loading

• モデルのアーティファクトをReal-time Prediction Serviceのdockerイメージに封入し，サービスと一緒にモデルをデプロイしていたが，モデルのデプロイが急激に増加したため，この重いプロセスがモデルの反復作業のボトルネックとなっていた．
• この問題を解決するために，動的なモデルのロードを実装した
  • Model Artifact & Configストアには，本番環境でどのモデルを提供すべきかというターゲットの状態が保持されている
  • Realtime Prediction Serviceは，このストアを定期的にチェックし，ローカルの状態と比較し，それに応じて新しいモデルのロードと外したモデルの削除をトリガーする
  • 動的なモデルのロードにより，モデルとサーバーの開発サイクルが切り離され，本番モデルのイテレーションを迅速に行うことができる

Model Deployment Workflow

• モデルデプロイでは，学習されたモデルを単にModel Artifact & Configストアにプッシュするだけではなく，self-containedでバリデーション済みのモデルパッケージを作成するためのステップを踏む
• Artifacts validation:
  • 学習したモデルに，サービスやモニタリングに必要な成果物がすべて含まれていることを確認する
• Compile:
  • すべてのモデルの成果物とメタデータを、リアルタイム予測サービスにロード可能なself-containedのパッケージにする
• Serving validation:
  • コンパイルされたモデルのjarファイルをローカルにロードし，トレーニングデータセットのサンプルデータを使ってモデル予測を実行する．このステップでは，モデルが実行可能であること，およびリアルタイム予測サービスとの互換性を確認する
• これはリアルタイム予測サービスの安定性を確保するためである
  • 複数のモデルが同じコンテナにロードされているため，良くないモデルが予測要求の失敗を引き起こし，同じコンテナ上のモデルが中断される可能性がある

Model Deployment Tracking

• Deployment progress tracking:
  • デプロイワークフローは，トラッキングを行うためにデプロイの進捗状況をメタデータストレージに投稿する
• Health check:
  • デプロイワークフローが終了したモデルは，モデルヘルスチェックの対象となる．このチェックはモデルの健全性と使用情報を追跡するために定期的に行われ，メタデータストレージに更新情報が送られる

Model Auto-Retirement

• 使われていないモデルをリタイアさせるためのAPIがあるが，往々にして忘れられていたり，使われていないことがある
  • これにより，メモリ負荷やストレージ負荷が発生し，メモリ不足のエラーになったりする可能性がある．これはサービスの品質に影響を与える事象である
• これを解決するために，モデルの自動引退プロセスを構築した
  • モデルの有効期限を設定することができ，有効期限を過ぎてもモデルが使用されていない場合，関連するユーザーに警告通知を行い，モデルをリタイアさせる．この機能を有効にすることでリソースの使用量を大幅に削減 することができる

Auto-Shadow

• よくわからなかったので，今後復習する

  Continuous Integration and Deployment

• いくつかの問題提起
  • Code change not compatible:
    • モデルが新しいバイナリをロードしたり予測したりできない場合，新しいリリースで動作が変更された場合
  • Dependencies not compatible:
    • 基本的な依存関係が変更されたため，サービスが開始できない
  • Build script not compatible:
    • ビルドスクリプトの変更により，リリースのビルドができない
• リアルタイム予測サービスの最新バイナリの検証とデプロイには，ステージング統合テスト・カナリア統合テスト・本番ロールアウトの3段階の戦略を採用

所感

• Model Auto-Retirementは非機能的な部分の負債であったりを減らすことができるので，良いと感じた
• また，古いモデルを淘汰したり，モデルを適切に管理していくという点でも有効な考え方だと思う

[masatakashiwagi]

MLOps: Comprehensive Beginner’s Guide

Link

• https://medium.com/sciforce/mlops-comprehensive-beginners-guide-c235c77f407f

内容

MLOps: Perks and Perils (特典と危険性)

• Data quality: データの質が高ければ高いほど，ビジネス上の問題を解決するためのモデルの出来も良くなる
• Model decay: 現実のデータは時間の流れとともに変化するので，その場で管理する必要がある
• Data locality: 異なるユーザーの人口統計に基づいて事前学習されたモデルは，他の市場に移行する際にそれぞれのパフォーマンスを発揮することができない

ML Workflow Lifecycle

• Data Engineering: MLアルゴリズムのためのデータセットの供給と学習
  • データの取り込み・探索と検証・クリーニング・ラベリング・分割（学習・検証・テストデータセットへの分割）などが含まれる
• Model Engineering: 最終モデルの準備
  • モデルの学習・評価・テスト，パッケージングが含まれる
• Model Deployment: 学習したモデルをビジネスアプリケーションに統合する
  • モデルのデプロイ，パフォーマンスの監視・記録などが含まれる

MLOps, Explained: When Data & Model Meet Code

• Continuous integration (CI): コードやコンポーネントだけでなく，データやスキーマ，モデルのテストや検証を行うことを指す
• Continuous deployment (CD): 単一のソフトウェアやサービスではなく，MLが提供する別のサービスをデプロイするというシステム全体を指す
• Continuous training (CT): MLモデルに特有のもので，モデルのサービスと再学習を意味する
• 成熟度について
  • データエンジニアリングの自動化，モデルエンジニアリング，デプロイといった各ステップのレベルが，MLOpsの全体的な成熟度を決定する
  • MLOps level 0: MLモデルの構築とデプロイのプロセスが全て手動で行われている状態
  • MLOps level 1: MLパイプラインの自動化によるモデルの継続的な学習，新しいデータに基づくモデルには適しているが，新しいMLのアイデアには適していない状態
  • MLOps level 2: CI/CDの自動化により，特徴量エンジニアリング，モデルアーキテクチャ，ハイパーパラメータなどの新しいアイデアを扱える状態
  • DevOpsと比較して，MLは時間の経過と共にmodel decaysが発生するので，モデルの再学習が必要になってくる．MLOpsでは，データとモデルのバージョニング管理がとても大切になってくる

Benefits and Costs

• MLOps Pros:
  • Automatic updating of multiple pipelines: 単純な1つのコードファイルの作業ではないため，非常に優れている
  • ML Models scalability and management: スコープによっては，数千のモデルを管理
  • CI and CD orchestrated: MLモデルをサービイングするため
  • ML Model’s health and governance: デプロイ後のモデルの管理を簡素化
  • A useful technique: MLプロダクトの開発を最適化するための人・プロセス・技術
• MLOps Costs:
  • Development: パラメータ・特徴量・モデルの操作がより頻繁に行われ，DevOpsと比較して非線形の実験的アプローチが行われる
  • Testing: データおよびモデルの検証，モデルの品質テストを含む
  • Production and Monitoring: MLOpsでは，精度を保つために継続的なモニタリングと監査が必要
  • memory monitoring: 予測実行時のメモリ使用量の監視
  • model performance monitoring: データが変化して結果に影響を与える可能性があるため，時間の経過とともにモデルの再学習が必要
  • infrastructure monitoring: 関連データの継続的な収集とレビュー
  • Team: データサイエンティストやエンジニアが採用できるよう時間と労力をかける

[masatakashiwagi]

Organizing machine learning projects: project management guidelines.

Link

• https://www.jeremyjordan.me/ml-projects-guide/

内容

[masatakashiwagi]

MLOps Architecture Guide

Link

• https://neptune.ai/blog/mlops-architecture-guide

内容

[masatakashiwagi]

MLflowで実験管理入門

Link

• https://future-architect.github.io/articles/20200626/

内容

[masatakashiwagi]

ゆるふわMLOps入門

Link

• https://www.nogawanogawa.com/entry/mlops

内容