次の方法で共有

機械学習の操作

  • [アーティクル]

この記事では、エンドツーエンドの継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインと再トレーニング パイプラインを備えた 機械学習操作用の 3 つの Azure アーキテクチャについて説明します。 これらのアーキテクチャは、以下の AI アプリケーションに適しています。

  • 古典的機械学習
  • Computer Vision (CV)
  • 自然言語処理

これらのアーキテクチャは MLOps v2 プロジェクトの成果です。 これらには、ソリューション アーキテクトがさまざまな 機械学習ソリューションを開発するプロセスで特定したベスト プラクティスが組み込まれています。 結果として、デプロイ可能で、反復可能で、保守のしやすいパターンが得られました。 これらすべてのアーキテクチャで Azure Machine Learning service を使用します。

MLOps v2 のサンプル デプロイ テンプレートを使用した実装については、 Azure MLOps v2 GitHub リポジトリを参照してください。

考えられるユース ケース

  • 従来の機械学習: 表形式の構造化データに対する時系列予測、回帰、分類は、このカテゴリの最も一般的なユース ケースです。 以下に例を示します。

    • 二項分類とマルチ ラベル分類。

    • 線形、多項式、リッジ、なげなわ、分位点、ベイズ回帰。

    • ARIMA、自己回帰 (AR)、SARIMA、VAR、SES、LSTM。

  • CV: この記事で提示する MLOps フレームワークでは、主にセグメント化と画像分類の CV ユース ケースに焦点を当てています。

  • 自然言語処理: 次の MLOps フレームワークを使用して実装できます。

    • 名前付きエンティティの認識:

    • テキスト分類

    • テキスト生成

    • センチメント分析

    • 翻訳

    • 質問応答

    • 概要

    • 文検出

    • 言語検出

    • 品詞のタグ付け

AI シミュレーション、深層強化学習、その他の形式の AI については、この記事では説明しません。

Architecture

MLOps v2 アーキテクチャ パターンには、MLOps ライフサイクルの 4 つの主要なモジュール コンポーネント (フェーズ) があります。

  • データ資産
  • 管理と設定
  • モデル開発、または内部ループ フェーズ
  • モデル デプロイ、または外部ループ フェーズ

前述のコンポーネント、それらの間の接続、および関連する一般的なペルソナは、すべての MLOps v2 シナリオ アーキテクチャで標準です。 各コンポーネントの詳細はシナリオによって異なります。

機械学習向けの MLOps v2 の基本アーキテクチャは、表形式データに対する従来の機械学習のシナリオです。 CV および NLP アーキテクチャは、この基本アーキテクチャをベースに改変を加えたものです。

MLOps v2 では、この記事で説明する次のアーキテクチャについて説明します。

古典的機械学習アーキテクチャ

従来の機械学習アーキテクチャを示す図。

このアーキテクチャの Visio ファイル をダウンロードします。

古典的機械学習アーキテクチャのワークフロー

  1. データ資産

    このコンポーネントは、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこのコンポーネントの主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 緑色のチェックマークは、お客様のユースケースに基づいて推奨されるベスト プラクティスを表すデータ ソースとターゲットを示します。

  2. 管理と設定

    このコンポーネントは、MLOps v2 ソリューションのデプロイの最初の手順です。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 たとえば、インフラストラクチャ チームは次のことを行います。

    1. プロジェクト ソース コード リポジトリを作成します。
    2. Bicep または Terraform を使用して Machine Learning ワークスペースを作成します。
    3. モデルの開発とデプロイのためのデータセットとコンピューティング リソースを作成または変更します。
    4. プロジェクト チーム ユーザー、各ユーザーのロール、他のリソースへのアクセス制御を定義します。
    5. CI/CD パイプラインを作成します。
    6. 監視コンポーネントを作成して、モデルとインフラストラクチャのメトリックのアラートを収集して作成します。

    このフェーズに関連する主なペルソナはインフラストラクチャ チームですが、組織にはデータ エンジニア、機械学習エンジニア、データ サイエンティストがいる場合もあります。

  3. モデル開発 (内部ループ フェーズ)

    内部ループ フェーズは、セキュリティで保護された専用の Machine Learning ワークスペース内で作用する、反復的なデータ サイエンス ワークフローで構成されます。 上の図は、一般的なワークフローを示しています。 このプロセスはデータ インジェストから始まり、探索的データ分析、実験、モデルの開発と評価を経て、本番環境で使用するモデルを登録します。 このモジュール式コンポーネントは、データ サイエンス チームがモデルの開発に使用するプロセスに依存せず、適応可能です。

    このフェーズに関連するペルソナには、データ サイエンティストと機械学習エンジニアが含まれます。

  4. Machine Learning レジストリ

    データ サイエンス チームは、本番環境にデプロイできるモデルを開発した後、そのモデルを Machine Learning ワークスペース レジストリに登録します。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

    このステージに関連するペルソナは通常、機械学習エンジニアです。

  5. モデル デプロイ (外部ループ フェーズ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用環境のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 モデルが組織とユースケースの基準を満たすと、CD パイプラインは、モデルと関連資産をプロダクション、監視、および潜在的な再トレーニングを通じて促進します。

    このフェーズに関連するペルソナは、主に機械学習エンジニアです。

  6. ステージングとテスト

    ステージングとテストのフェーズは、お客様のプラクティスによって異なります。 このフェーズには、通常、運用データに対するモデル候補の再トレーニングとテスト、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用配置

    モデルがステージングおよびテスト段階を通過すると、機械学習エンジニアは人間参加型のゲート承認を使用して、モデルを本番環境に昇格させることができます。 モデル デプロイ オプションには、バッチ シナリオ用のマネージド バッチ エンドポイント、またはオンラインのほぼリアルタイムのシナリオ用の Azure Arc を使用するマネージド オンライン エンドポイントまたは Kubernetes デプロイが含まれます。 通常、運用は 1 つ以上の専用の安全な Machine Learning ワークスペースで行われます。

  8. 監視

    機械学習エンジニアは、ステージング、テスト、本番環境のコンポーネントを監視して、モデル、データ、インフラストラクチャのパフォーマンスの変化に関連するメトリックを収集します。 これらのメトリックを使用してアクションを実行できます。 モデルとデータの監視には、モデルやデータ ドリフトのチェック、新しいデータに対するモデルのパフォーマンス、責任ある AI の問題などが含まれる場合があります。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、またはネットワークの問題を特定できます。

  9. データとモデルの監視: イベントとアクション

    自動化されたトリガーと通知では、メトリックのしきい値やスケジュールなど、モデルとデータの懸念事項に関する基準に基づいて、実行する適切なアクションを実装できます。 たとえば、トリガーは、新しい運用データを使用するようにモデルを再トレーニングし、その後、本番前の評価のためにモデルをステージングとテストにループバックする場合があります。 あるいは、モデルまたはデータの問題によって、データ サイエンティストが問題を調査し、場合によっては新しいモデルを開発できるモデル開発フェーズへのループバックを必要とするアクションがトリガーされる可能性があります。

  10. インフラストラクチャの監視: イベントとアクション

    自動化されたトリガーと通知により、エンドポイントの応答遅延やデプロイのコンピューティング不足などのインフラストラクチャ基準に基づいて、適切なアクションを実装できます。 自動トリガーと通知により、セットアップと管理フェーズへのループバックがトリガーされ、インフラストラクチャ チームが問題を調査し、コンピューティング リソースとネットワーク リソースを再構成できる場合があります。

Machine Learning CV アーキテクチャ

Computer Vision アーキテクチャを示す図。

このアーキテクチャの Visio ファイル をダウンロードします。

CV アーキテクチャのワークフロー

Machine Learning CV アーキテクチャは従来の機械学習アーキテクチャに基づいていますが、教師あり CV シナリオに特有の変更が加えられています。

  1. データ資産

    このコンポーネントは、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこのコンポーネントの主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 CV シナリオの画像は、さまざまなデータ ソースに由来する可能性があります。 機械学習を使用して CV モデルを開発およびデプロイする場合の効率を高めるために、Azure データ ソースとしては Azure Blob Storage と Azure Data Lake Storage を推奨しています。

  2. 管理と設定

    このコンポーネントは、MLOps v2 デプロイの最初の手順です。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 CV シナリオの場合、MLOps v2 環境の管理とセットアップは、従来の機械学習の場合とほとんど同じですが、追加の手順が含まれます。 インフラストラクチャ チームは、機械学習または別のツールのラベル付け機能を使用して、画像のラベル付けと注釈プロジェクトを作成します。

  3. モデル開発 (内部ループ フェーズ)

    内部ループ フェーズは、セキュリティで保護された専用の Machine Learning ワークスペース内で作用する、反復的なデータ サイエンス ワークフローで構成されます。 このワークフローと古典的機械学習シナリオの主な違いは、画像のラベル付けと注釈がこの開発ループの重要なコンポーネントであるという点です。

  4. Machine Learning レジストリ

    データ サイエンス チームは、本番環境にデプロイできるモデルを開発した後、そのモデルを Machine Learning ワークスペース レジストリに登録します。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

  5. モデル デプロイ (外部ループ フェーズ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用環境のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 モデルが組織とユースケースの基準を満たすと、CD パイプラインは、モデルと関連資産をプロダクション、監視、および潜在的な再トレーニングを通じて促進します。

  6. ステージングとテスト

    ステージングとテストのフェーズは、お客様のプラクティスによって異なります。 このフェーズには、通常は、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 CV シナリオの場合、リソースと時間の制約により、機械学習エンジニアはモデル候補を運用データで再トレーニングする必要がありません。 データ サイエンス チームは、代わりにモデル開発に運用データを使用できます。 開発ループから登録された候補モデルは、運用環境で評価されます。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用配置

    モデルがステージングおよびテスト段階を通過すると、機械学習エンジニアは人間参加型のゲート承認を使用して、モデルを本番環境に昇格させることができます。 モデル デプロイ オプションには、バッチ シナリオ用のマネージド バッチ エンドポイント、またはオンラインのほぼリアルタイムのシナリオ用の Azure Arc を使用するマネージド オンライン エンドポイントまたは Kubernetes デプロイが含まれます。 通常、運用は 1 つ以上の専用の安全な Machine Learning ワークスペースで行われます。

  8. 監視

    機械学習エンジニアは、ステージング、テスト、本番環境のコンポーネントを監視して、モデル、データ、インフラストラクチャのパフォーマンスの変化に関連するメトリックを収集します。 これらのメトリックを使用してアクションを実行できます。 モデルとデータの監視には、新しい画像に対するモデルのパフォーマンスのチェックを含めることができます。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、またはネットワークの問題を特定できます。

  9. データとモデルの監視: イベントとアクション

    自然言語処理向けの MLOps で、従来の機械学習との重要な違いは、データとモデルモニタリング、およびイベントとアクションのフェーズです。 CV シナリオでは通常、新しい画像に対してモデルのパフォーマンスの低下が検出されても、自動再トレーニングは行われません。 この場合、パフォーマンスが低いモデルの新しいテキスト データをレビューして注釈を付けるには、人間が関与するプロセスが必要です。 次のアクションでは、多くの場合、モデル開発ループに戻り、新しい画像でモデルを更新します。

  10. インフラストラクチャの監視: イベントとアクション

    自動化されたトリガーと通知により、エンドポイントの応答遅延やデプロイのコンピューティング不足などのインフラストラクチャ基準に基づいて、適切なアクションを実装できます。 自動トリガーと通知により、セットアップと管理フェーズへのループバックがトリガーされ、インフラストラクチャ チームが問題を調査し、環境、コンピューティング リソース、ネットワーク リソースを再構成できる場合があります。

Machine Learning の自然言語処理アーキテクチャ

自然言語処理アーキテクチャの図。

このアーキテクチャの Visio ファイル をダウンロードします。

自然言語処理アーキテクチャのワークフロー

Machine Learning 自然言語処理アーキテクチャは従来の機械学習アーキテクチャに基づいていますが、NLP シナリオに特有の変更がいくつか加えられています。

  1. データ資産

    このコンポーネントは、組織のデータ資産と、データ サイエンス プロジェクトにおけるデータの潜在的なソースとターゲットを示しています。 データ エンジニアは、MLOps v2 ライフサイクルのこのコンポーネントの主な所有者です。 この図の Azure データ プラットフォームは、網羅的でも規範的でもありません。 緑色のチェックマークは、顧客のユースケースに基づいて推奨されるベスト プラクティスを表すデータ ソースとターゲットを示します。

  2. 管理と設定

    このコンポーネントは、MLOps v2 デプロイの最初の手順です。 プロジェクトに関連付けられたリソースとロールの作成と管理に関連するすべてのタスクで構成されています。 自然言語処理シナリオでは、MLOps v2 環境の管理とセットアップは従来の機械学習の場合とほぼ同じですが、Machine Learning または別のツールのラベル付け機能を使用して、画像のラベル付けと注釈プロジェクトを作成するという追加の手順があります。

  3. モデル開発 (内部ループ フェーズ)

    内部ループ フェーズは、セキュリティで保護された専用の Machine Learning ワークスペース内で作用する、反復的なデータ サイエンス ワークフローで構成されます。 一般的な NLP モデル開発ループは、このシナリオの一般的な開発手順に文の注釈とテキスト データのトークン化、正規化、埋め込みが含まれるという点で、従来の機械学習シナリオとは異なります。

  4. Machine Learning レジストリ

    データ サイエンス チームは、本番環境にデプロイできるモデルを開発した後、そのモデルを Machine Learning ワークスペース レジストリに登録します。 モデル登録によって自動的に、または人間参加型のゲート承認によってトリガーされる CI パイプラインにより、モデルと、その他のモデル依存関係がモデル デプロイ フェーズに昇格します。

  5. モデル デプロイ (外部ループ フェーズ)

    モデル デプロイまたは外部ループ フェーズを構成するのは、運用環境のステージングとテスト、運用環境へのデプロイ、そして、モデル、データ、インフラストラクチャの監視です。 モデルが組織とユースケースの基準を満たすと、CD パイプラインは、モデルと関連資産をプロダクション、監視、および潜在的な再トレーニングを通じて促進します。

  6. ステージングとテスト

    ステージングとテストのフェーズは、お客様のプラクティスによって異なります。 このフェーズには、通常、運用データに対するモデル候補の再トレーニングとテスト、エンドポイント パフォーマンスのためのテスト デプロイ、データ品質チェック、単体テスト、モデルとデータの偏りに関しての責任ある AI チェックなどのオペレーションが含まれます。 このフェーズは、セキュリティで保護された 1 つ以上の専用の Machine Learning ワークスペースで行われます。

  7. 運用配置

    モデルがステージングおよびテスト段階を通過すると、機械学習エンジニアは人間参加型のゲート承認を使用して、モデルを本番環境に昇格させることができます。 モデル デプロイ オプションには、バッチ シナリオ用のマネージド バッチ エンドポイント、またはオンラインのほぼリアルタイムのシナリオ用の Azure Arc を使用するマネージド オンライン エンドポイントまたは Kubernetes デプロイが含まれます。 通常、運用は 1 つ以上の専用の安全な Machine Learning ワークスペースで行われます。

  8. 監視

    機械学習エンジニアは、ステージング、テスト、本番環境のコンポーネントを監視して、モデル、データ、インフラストラクチャのパフォーマンスの変化に関連するメトリックを収集します。 これらのメトリックを使用してアクションを実行できます。 モデルとデータの監視には、モデルやデータ ドリフトのチェック、新しいテキスト データに対するモデルのパフォーマンス、責任ある AI の問題などが含まれる場合があります。 インフラストラクチャの監視では、低速なエンドポイント応答、コンピューティング容量の不足、ネットワークなどの問題を特定できます。

  9. データとモデルの監視: イベントとアクション

    CV アーキテクチャと同様に、自然言語処理向けの MLOps で、古典的機械学習との重要な違いは、データとモデルモニタリング、およびイベントとアクションのフェーズです。 自然言語処理シナリオでは通常、新しいテキストに対してモデルのパフォーマンスの低下が検出されても、自動再トレーニングは行われません。 この場合、パフォーマンスが低いモデルの新しいテキスト データをレビューして注釈を付けるには、人間が関与するプロセスが必要です。 多くの場合、モデル開発ループに戻り、新しいテキスト データを使用してモデルを更新することが次のアクションとなります。

  10. インフラストラクチャの監視: イベントとアクション

    自動化されたトリガーと通知により、エンドポイントの応答遅延やデプロイのコンピューティング不足などのインフラストラクチャ基準に基づいて、適切なアクションを実装できます。 自動トリガーと通知により、セットアップと管理フェーズへのループバックがトリガーされ、インフラストラクチャ チームが問題を調査し、コンピューティング リソースとネットワーク リソースを再構成できる場合があります。

コンポーネント

  • Azure Machine Learning は、機械学習モデルの大規模なトレーニング、スコア、デプロイ、管理に使用できるクラウド サービスです。

  • Azure Pipelines は、このビルドおよびテスト システムは Azure DevOps に基づいており、ビルドおよびリリース パイプラインに使用されます。 Azure Pipelines ではこれらのパイプラインを タスクと呼ばれる論理的ステップに分割します。

  • GitHub は、バージョン管理、コラボレーション、CI/CD ワークフローのためのコード ホスティング プラットフォームです。

  • Azure Arc は、Azure Resource Manager を使用して Azure リソースとオンプレミス リソースを管理するプラットフォームです。 リソースには、仮想マシン、Kubernetes クラスター、およびデータベースを含めることができます。

  • Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するのに使用できるオープンソース システムです。

  • Azure Data Lake Storage は、Hadoop と互換性のあるファイル システムです。 これには、階層型名前空間が統合されており、Blob Storage の大規模なスケールと経済性を備えています。

  • Azure Synapse Analytics は、データ統合、エンタープライズ データウェア ハウス、およびビッグ データ分析が 1 つにまとめられた無制限の分析サービスです。

  • Azure Event Hubs は、クライアント アプリケーションが生成するデータ ストリームを取り込むサービスです。 そして、受信したイベントのシーケンスを保持したまま、ストリーミング データを取り込み、保存します。 コンシューマーはハブ エンドポイントに接続して、処理するメッセージを取得できます。 このアーキテクチャでは、Data Lake Storage 統合が使用されます。

その他の考慮事項

前述の MLOps v2 アーキテクチャ パターンには、ビジネス関係者に合わせたロールベースのアクセス制御 (RBAC)、効率的なパッケージ管理、堅牢な監視メカニズムなど、いくつかの重要なコンポーネントがあります。 これらのコンポーネントは総合的に、機械学習ワークフローの実装と管理の成功に貢献します。

ペルソナベースの RBAC

機械学習のデータとリソースへのアクセスを管理することが重要です。 RBAC は、ソリューション内の特定のアクションを実行できるユーザーや特定の領域にアクセスできるユーザーを管理するのに役立つ強力なフレームワークを提供します。 Machine Learning の機械学習モデルとプロセスに含まれるペルソナのライフサイクルに合わせて、ID セグメント化戦略を設計します。 各ペルソナには、RBAC ロールとグループ メンバーシップに反映される特定の責任セットがあります。

ペルソナの例

機械学習ワークロードで適切なセグメント化をサポートするには、 識別ベースの RBAC グループ設計を通知する次の一般的なペルソナを検討してください。

データ サイエンティストおよび機械学習エンジニア

データ サイエンティストと機械学習エンジニアは、プロジェクトのソフトウェア開発ライフサイクル全体にわたって、さまざまな機械学習およびデータ サイエンスのアクティビティを実行します。 それらの職務には、探索的データ分析とデータの前処理が含まれます。 データ サイエンティストと機械学習エンジニアは、モデルのトレーニング、評価、および展開を担当します。 これらの役割の責任には、機械学習モデル、パッケージ、およびデータの修理アクティビティも含まれます。 これらの職務は、プラットフォームのテクニカル サポート チームの範囲外です。

タイプ: 個人
プロジェクト固有: はい

データ アナリスト

データ アナリストは、ビジネス インテリジェンス用の SQL クエリの実行など、データ サイエンス アクティビティに必要な入力を提供します。 このロールの責任には、データの操作、データ分析の実行、モデル開発とモデル デプロイのサポートが含まれます。

タイプ: 個人
プロジェクト固有: はい

モデル テスト担当者

モデル テスト担当者は、テスト環境とステージング環境でテストを実施します。 このロールは、CI/CD プロセスからの機能分離を提供します。

タイプ: 個人
プロジェクト固有: はい

業務の利害関係者

マーケティング マネージャーなどのビジネス関係者がプロジェクトに関係します。

タイプ: 個人
プロジェクト固有: はい

プロジェクト リードまたはデータ サイエンス リード

データ サイエンス リードは、Machine Learning ワークスペースのプロジェクト管理ロールです。 このロールは、機械学習モデルとパッケージの破壊的修正アクティビティも行います。

タイプ: 個人
プロジェクト固有: はい

プロジェクトまたは製品の所有者 (ビジネス所有者)

ビジネス関係者は、データの所有権に応じて Machine Learning ワークスペースに対して責任を負います。

タイプ: 個人
プロジェクト固有: はい

プラットフォームのテクニカル サポート

プラットフォームのテクニカル サポートは、プラットフォーム全体の中断修正アクティビティを担当するテクニカル サポート スタッフです。 このロールはインフラストラクチャまたはサービスをカバーしますが、機械学習モデル、パッケージ、またはデータはカバーしません。 これらのコンポーネントはデータ サイエンティストまたは機械学習エンジニアの役割の下にあり、プロジェクト リードの責任となります。

タイプ: 個人
プロジェクト固有: いいえ

エンド ユーザーのモデル化

モデルのエンド ユーザーは、機械学習モデルのエンド コンシューマーです。

タイプ: 個人またはプロセス
プロジェクト固有: はい

CI/CD プロセス

CI/CD プロセスは、プラットフォーム環境全体で変更をリリースまたはロールバックします。

タイプ: プロセス
プロジェクト固有: いいえ

Machine Learning ワークスペース

Machine Learning ワークスペースでは、 マネージド ID を使用して Azure の他の部分とやり取りします。 このペルソナは、機械学習の実装を構成するさまざまなサービスを表します。 これらのサービスは、開発データ ストアに接続する開発ワークスペースなど、プラットフォームの他の部分と対話します。

タイプ: プロセス
プロジェクト固有: いいえ

監視プロセス

監視プロセスは、プラットフォームのアクティビティに基づいて監視およびアラートを行うコンピューティング プロセスです。

タイプ: プロセス
プロジェクト固有: いいえ

データ ガバナンスのプロセス

データ ガバナンス プロセスは、機械学習プロジェクトとデータ ストアをスキャンしてデータ ガバナンスを行います。

タイプ: プロセス
プロジェクト固有: いいえ

Microsoft Entra グループ メンバーシップ

RBAC を実装すると、 Microsoft Entra グループ は、さまざまなペルソナにわたるアクセス許可を管理するための柔軟でスケーラブルな方法を提供します。 Microsoft Entra グループを使用して、制限されている可能性があるアプリやサービスなどのリソースに対して、アクセスとアクセス許可を全員同じにする必要があるユーザーを管理することができます。 個々のユーザーに特別なアクセス許可を追加するのではなく、グループを作成し、そのグループのすべてのメンバーにその特別なアクセス許可を適用します。

このアーキテクチャ パターンでは、プロジェクト、チーム、部門などの Machine Learning ワークスペースのセットアップにこれらのグループを結合することができます。 ユーザーを特定のグループに関連付けて、きめ細かいアクセス ポリシーを定義できます。 ポリシーは、職務、プロジェクト要件、またはその他の基準に基づいて、さまざまな Machine Learning ワークスペースへのアクセス許可を付与または制限します。 たとえば、特定のユース ケースについて、すべてのデータ サイエンティストに開発ワークスペースへのアクセスを許可するグループを作成できます。

Identity RBAC

次の組み込みの Azure RBAC ロールを使用して、運用環境と運用前の環境に RBAC を適用する方法を検討してください。 この記事の アーキテクチャ では、運用環境にはステージング環境、テスト環境、運用環境が含まれます。 運用前環境には開発環境が含まれます。 次の RBAC ロールは、この記事で前述したペルソナに基づいています。

標準ロール

コンポーネント固有のロール

これらの Azure RBAC ロールの省略形は、次の表に対応します。

運用環境
ペルソナ Machine Learning ワークスペース Azure Key Vault Container Registry Azure ストレージ アカウント Azure DevOps Azure Artifacts Log Analytics ワークスペース Azure Monitor
データ科学者 R LAR MR
データ アナリスト
モデル テスト担当者
業務の利害関係者 MR
プロジェクト リード (データ サイエンス リード) R R, KVR R LAR MR
プロジェクト/製品の所有者 MR
プラットフォームのテクニカル サポート O O、KVA DOPCA O O O
エンド ユーザーのモデル化
CI/CD プロセス O O、KVA AcrPush DOPCA O O O
Machine Learning ワークスペース R C C
監視プロセス R LAR MR
データ ガバナンスのプロセス R R R R R
運用前環境
ペルソナ Machine Learning ワークスペース Key Vault Container Registry ストレージ アカウント Azure DevOps Azure Artifacts Log Analytics ワークスペース Azure Monitor
データ科学者 ADS R, KVA C C C C LAC MC
データ アナリスト R C LAR MC
モデル テスト担当者 R R, KVR R R R R LAR MR
業務の利害関係者 R R R R R
プロジェクト リード (データ サイエンス リード) C C、KVA C C C C LAC MC
プロジェクト/製品の所有者 R R MR
プラットフォームのテクニカル サポート O O、KVA O O DOPCA O O O
エンド ユーザーのモデル化
CI/CD プロセス O O、KVA AcrPush O DOPCA O O O
Machine Learning ワークスペース R, KVR C C
監視プロセス R R R R R R LAC
データ ガバナンスのプロセス R R R

Note

プラットフォーム テクニカル サポートを除くすべてのペルソナは、プロジェクトの期間中、アクセス権を保持します。プラットフォーム テクニカル サポートには、一時的またはジャストインタイムの Microsoft Entra Privileged Identity Management (PIM) アクセス許可が付与されます。

RBAC は、MLOps ワークフローのセキュリティ保護と合理化において重要なロールを果たします。 RBAC は、割り当てられたロールに基づいてアクセスを制限し、承認されていないユーザーが機密データにアクセスするのを防ぎ、セキュリティ リスクを軽減します。 機密データには、トレーニング データやモデル、および運用パイプラインなどの重要なインフラストラクチャが含まれます。 RBAC を使用して、データ プライバシー規制に確実に準拠できます。 RBAC はアクセスとアクセス許可の明確な記録も提供するため、監査が簡素化され、セキュリティのギャップを簡単に特定でき、ユーザー アクティビティを追跡できます。

パッケージの管理

さまざまなパッケージ、ライブラリ、バイナリへの依存関係は、MLOps ライフサイクル全体で共通です。 これらの依存関係は、多くの場合コミュニティによって開発され、急速に進化しており、適切に使用および理解するには、主題に関する専門知識が必要です。 適切な人がパッケージやライブラリなどのさまざまな資産に安全にアクセスできるようにする必要がありますが、脆弱性も防止する必要があります。 データ サイエンティストは、機械学習ソリューション用の特殊な構築ブロックを組み立てるときにこの問題に直面します。 従来のソフトウェア管理アプローチはコストがかかり、非効率的です。 他のアプローチの方が価値が高くなります。

これらの依存関係を管理するには、 検疫パターンに基づいた安全なセルフサービスパッケージ管理プロセスを使用できます。 このプロセスを設計することで、データ サイエンティストが厳選されたパッケージのリストからセルフサービスで利用し、パッケージが安全で組織の標準に準拠していることを保証できるようになります。

ここのアプローチには、業界標準の機械学習パッケージ リポジトリである Microsoft Artifact Registry、Python Package Index (PyPI)、Conda の 3 つの安全リストへの登録が含まれます。 セーフリストにより、個々の Machine Learning ワークスペースからのセルフサービスが可能になります。 次に、デプロイ中に自動テスト プロセスを使用して、結果のソリューション コンテナーをスキャンします。 失敗すると、デプロイ プロセスが適切に終了し、コンテナーが削除されます。 次の図とプロセス フローは、このプロセスを示しています。

セキュリティで保護された機械学習パッケージのアプローチを示す図。

プロセス フロー

  1. ネットワーク構成 を持つ Machine Learning ワークスペースで作業するデータ サイエンティストは、機械学習パッケージ リポジトリからオンデマンドで機械学習パッケージをセルフサービスで利用できます。 集中化された機能を使用してシードおよび維持される プライベート ストレージ パターンを使用すると、その他すべてに例外プロセスが必要になります。

  2. 機械学習は、Docker コンテナーとして機械学習ソリューションを提供します。 これらのソリューションが開発されると、Container Registry にアップロードされます。 Microsoft Defender for Containers は、コンテナー イメージの脆弱性アセスメントを生成します。

  3. ソリューションのデプロイは、CI/CD プロセスを通じて行われます。 Microsoft Defender for DevOps は、スタック全体で使用されて、セキュリティ体制管理と脅威保護を提供します。

  4. ソリューション コンテナーは、各セキュリティ プロセスに合格した場合にのみデプロイされます。 ソリューション コンテナーがセキュリティ プロセスに失敗した場合、エラー通知と完全な監査証跡とともにデプロイが失敗します。 ソリューション コンテナーは破棄されます。

前のプロセス フローは、データ サイエンティストに安全なセルフサービス パッケージ管理プロセスを提供し、パッケージが安全で組織の標準に準拠していることを保証します。 イノベーションとセキュリティのバランスをとるために、データ サイエンティストに、運用前の環境での一般的な機械学習パッケージ、ライブラリ、バイナリへのセルフサービス アクセスを許可できます。 あまり一般的でないパッケージには例外が必要です。 この戦略により、データ サイエンティストは開発中に生産性を維持でき、配信時の大きなボトルネックを防ぐことができます。

リリース プロセスを効率化するには、運用環境で使用する環境をコンテナー化します。 コンテナー化された環境では、脆弱性のスキャンを通じて、問題を軽減し、継続的なセキュリティを確保します。 このプロセス フローは、ユース ケース間で配信時まで使用できる反復可能なアプローチを提供します。 企業内で機械学習ソリューションを構築およびデプロイするための全体的なコストを削減します。

監視

MLOps では、機械学習システムの健全性とパフォーマンスを維持し、モデルが効果的であり、ビジネス目標と一致していることを確認するために、監視が非常に重要となります。 監視では、内部ループ フェーズ中のガバナンス、セキュリティ、およびコスト制御がサポートされます。 また、外側のループ フェーズでソリューションをデプロイする際のパフォーマンス、モデルの低下、使用状況の監視可能性も提供します。 監視アクティビティは、データ サイエンティスト、ビジネス ステークホルダー、プロジェクト リーダー、プロジェクト オーナー、プラットフォーム テクニカル サポート、CI/CD プロセス、監視プロセスなどのペルソナに関連します。

Machine Learning ワークスペースのセットアップ (プロジェクト、チーム、部署など) に応じて、監視と検証のプラットフォームを選択します。

モデルのパフォーマンス

モデルのパフォーマンスを監視して、モデルの問題とパフォーマンスの低下を早期に検出します。 パフォーマンスを追跡して、モデルの正確性と信頼性を維持し、ビジネス目標に沿ったものであることを確認します。

データ ドリフト

データ ドリフト は、モデルのトレーニング データまたは最近の過去の生産データと比較して、モデルの入力データの分布の変化を追跡します。 これらの変更は、市場の動向の変化、機能変換の変更、またはアップストリーム データの変更の結果です。 このような変更によりモデルのパフォーマンスが低下する可能性があるため、ドリフトを監視してタイムリーな修復を確保することが重要です。 比較を実行するには、データ ドリフト リファクタリングに最新の運用データセットと出力が必要となります。

環境: 運用
Azure ファシリテーション: 機械学習 – モデルモニタリング

予測ドリフト

予測ドリフトは、モデルの予測出力を検証データ、テストラベル付きデータ、または最近の運用データと比較することで、モデルの予測出力の分布の変化を追跡します。 比較を実行するには、データ ドリフト リファクタリングに最新の運用データセットと出力が必要となります。

環境: 運用
Azure ファシリテーション: 機械学習 – モデルモニタリング

リソース

エンドポイント メトリックを提供するいくつかのモデルを使用して、CPU やメモリ使用量などの品質とパフォーマンスを示します。 このアプローチは、運用から学び、将来の投資や変更を促進するのに役立ちます。

環境: すべて
Azure ファシリテーション: モニター - オンライン エンドポイント メトリック

使用状況メトリック

エンドポイントの使用状況を監視して、組織固有またはワークロード固有の主要業績評価指標を満たしていることを確認し、使用パターンを追跡し、ユーザーが経験する問題を診断して修復します。

クライアントの要求

モデル エンドポイントへのクライアント要求の数を追跡して、エンドポイントのアクティブな使用状況プロファイルを把握します。これは、スケーリングやコスト最適化の取り組みに影響を与える可能性があります。

環境: 運用
Azure ファシリテーション: モニター - オンライン エンドポイント メトリック (RequestsPerMinute など)。 注:

  • ワークロードのニーズに合わせて、許容可能なしきい値を T シャツのサイズ設定や異常値に合わせることができます。
  • 使用されなくなったモデルを運用環境から廃止します。
調整の遅延

調整の遅延 は、データ転送の要求と応答の速度低下です。 調整は、Resource Manager レベルとサービス レベルで行われます。 両方のレベルでメトリックを追跡します。

環境: 運用
Azure ファシリテーション:

注: 許容可能なしきい値を、ワークロードのサービス レベル目標 (SLO) またはサービス レベル契約 (SLA) とソリューションの非機能要件 (NFR) に合わせて調整します。

エラーの生成

応答コード エラーを追跡することで、サービスの信頼性を測定し、サービスの問題を早期に検出できるようになります。 たとえば、500 server error 応答が突然増加した場合は、すぐに対処する必要がある重大な問題が発生している可能性があります。

環境: 運用
Azure ファシリテーション: 機械学習 - オンライン エンドポイント トラフィック ログ を有効にして、要求に関する情報を確認します。 たとえば、ModelStatusCode または ModelStatusReason を使用して XRequestId の数を確認できます。 ログ分析ワークスペースを使用してログを処理できます。
注:

  • 400 から 500 の範囲内のすべての HTTP 応答コードは、エラーとして分類されます。

コストの最適化

クラウド環境でのコスト管理と最適化は、ワークロードの費用を制御し、リソースを効率的に割り当て、クラウド サービスからの価値を最大化するのに役立つため、非常に重要です。

ワークスペース コンピューティング

月間運営費が定義済みの金額に達するか超過すると、ワークスペース設定の境界に基づいて、プロジェクト リードやプロジェクト所有者などの関連する関係者に通知するアラートを生成します。 プロジェクト、チーム、または部門関連の境界に基づいて、 ワークスペースのセットアップ を決定できます。

環境: すべて
Azure ファシリテーション: Microsoft Cost Management - 予算アラート
注:

  • 初期 NPR とコスト見積もりに基づいて、予算のしきい値を設定します。
  • 複数のしきい値レベルを使用します。 複数のしきい値レベルにより、利害関係者は予算を超える前に適切な警告を受け取ります。 これらの利害関係者には、組織またはワークロードに応じて、ビジネス リード、プロジェクト所有者、またはプロジェクト リードが含まれる場合があります。
  • 一貫性のある予算アラートは、より大きな需要をサポートするためのリファクタリングのトリガーになる可能性もあります。
ワークスペースの制約

Machine Learning ワークスペースが、意図したユースケースに関連するコンピューティング使用量に基づいてアクティブに使用されているという兆候を示さない場合、プロジェクト所有者は、特定のプロジェクトで不要になったワークスペースを廃止することができます。

環境: 運用前
Azure ファシリテーション:

注:

  • アクティブ コアの数は、集計すると 0 になります。
  • 日付のしきい値をプロジェクト スケジュールに合わせます。

セキュリティ

適切なセキュリティ制御とベースラインからの逸脱を検出して監視し、Machine Learning ワークスペースが組織のセキュリティ ポリシーに準拠していることを確認します。 定義済みポリシーとカスタム定義ポリシーの組み合わせを使用できます。

環境: すべて
Azure ファシリテーション: 機械学習用の Azure Policy

エンドポイントのセキュリティ

ビジネスクリティカルな API を可視化するには、すべての機械学習エンドポイントを対象にしたセキュリティ監視を実装します。 API のセキュリティ態勢の調査と改善、脆弱性の修正の優先度付け、アクティブなリアルタイムの脅威のすばやい検出を可能にします。

環境: 運用
Azure ファシリテーション: Microsoft Defender for APIs は、APIの広範なライフサイクル保護、検出、応答カバレッジを提供します。 注: Defender for APIs は、Azure API Management で公開される API にセキュリティを提供します。 Defender for APIs は、Microsoft Defender for Cloud ポータルまたは Azure portal の API Management インスタンス内でオンボードできます。 Machine Learning オンライン エンドポイントを API Management と統合する必要があります。

デプロイ監視

デプロイの監視により、作成したエンドポイントがワークロードまたは組織のポリシーに準拠し、脆弱性から解放されます。 このプロセスでは、デプロイの前後に Azure リソースにコンプライアンス ポリシーを適用し、脆弱性スキャンを通じて継続的なセキュリティを提供し、運用中にサービスが SLO を満たしていることを確認する必要があります。

標準とガバナンス

適切な標準からの逸脱を検出し、ワークロードがガードレールに準拠していることを確認するために監視します。

環境: すべて
Azure ファシリテーション:

  • Azure Pipelines を通じてポリシーの割り当てとライフサイクルを管理し、ポリシーをコードとして扱います。
  • PsRule for Azure は、Azure インフラストラクチャのコードとしてのテスト フレームワークを提供します。
  • コードとしての Azure エンタープライズ ポリシー は、CI/CD ベースのシステム デプロイ ポリシー、ポリシー セット、割り当て、ポリシー免除、およびロールの割り当てのコードとして使用できます。

注: 詳細については、「機械学習の規制コンプライアンスに関する Azure ガイダンス」を参照してください。

セキュリティ スキャン

自動化された統合およびデプロイ プロセスの一部として、自動セキュリティ スキャンを実装します。

環境: すべて
Azure ファシリテーション: Defender For DevOps
注: Azure Marketplace のアプリを使用して、このプロセスを Microsoft 以外のセキュリティ テスト モジュール用に拡張できます。

進行中のサービス

パフォーマンスの最適化、セキュリティ、リソースの使用状況について、API の継続的なサービスを監視します。 タイムリーなエラー検出、効率的なトラブルシューティング、標準への準拠を保証します。

環境: 運用
Azure ファシリテーション:

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパルの作成者:

  • Scott Donohoo | シニア クラウド ソリューション アーキテクト
  • Moritz Steller | シニア クラウド ソリューション アーキテクト

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ