Azure Machine Learning 環境とは?

Azure Machine Learning 環境は、機械学習のトレーニングまたは推論が行われる環境をカプセル化します。 トレーニング スクリプトとスコアリング スクリプトの Python パッケージとソフトウェア設定を指定します。 Machine Learning ワークスペースは、これらの環境を管理およびバージョン管理し、さまざまなコンピューティング ターゲット間で再現可能で監査可能でポータブルな機械学習ワークフローを可能にします。 Environment オブジェクトを使用して、次の目的で使用します。

• トレーニング スクリプトを開発します。
• 大規模なモデルのトレーニング用に Azure Machine Learning コンピューティングで同じ環境を再利用します。
• その同じ環境を使ってモデルをデプロイします。
• 既存のモデルがトレーニングされた環境を見直します。

次の図は、ジョブ構成 (トレーニング用) と推論およびデプロイ構成 (Web サービス デプロイ用) の両方で、どのように 1 つの Environment オブジェクトを使用できるかを示しています。

環境、コンピューティング先、およびトレーニング スクリプトが一体となって、トレーニング ジョブの完全な仕様であるジョブ構成を形成します。

環境の種類

環境は、キュレーション、ユーザー管理、システム管理の 3 つのカテゴリに分類されます。

キュレートされた環境は Azure Machine Learning から提供され、既定でお使いのワークスペースで利用できます。 そのまま使用します。 これらには、さまざまな機械学習フレームワークの使用を開始するのに役立つ Python パッケージと設定のコレクションが含まれています。 これらの事前に作成された環境を利用すると、デプロイ時間の短縮も可能です。 Azure Machine Learning は、Microsoft がホストする機械学習レジストリである AzureML レジストリでキュレーションされた環境をホストします。 完全な一覧については、AzureML レジストリの環境を参照してください。

ユーザー管理環境では、ユーザーが環境を設定し、トレーニング スクリプトで必要なすべてのパッケージをコンピューティング先にインストールする必要があります。 また、モデル デプロイに必要な依存関係を必ず含めるようにしてください。 ユーザー管理環境では、イメージの具体化を Azure Machine Learning に委任する BYOC (Bring Your Own Container) または Docker Build Context をベースとすることができます。 キュレーションされた環境と同様に、作成して管理する機械学習レジストリを使用して、ワークスペース間でユーザー管理環境を共有できます。

conda で Python 環境を管理する場合は、システム管理環境を使用します。 新しい Conda 環境は、Docker のベース イメージ上の Conda 仕様から具体化されています。

環境を作成および管理する

Azure Machine Learning Python SDK、Azure Machine Learning CLI、Azure Machine Learning スタジオ、VS Code 拡張機能などから環境を作成できます。 各クライアントでは、必要に応じて基本イメージ、Dockerfile、Python レイヤーをカスタマイズできます。

特定のコード サンプルについては、環境の使用方法に関するページの「環境の作成」セクションを参照してください。

ワークスペースを使用して環境を管理することもできます。 ワークスペースでは、次のことができます。

• 環境を登録する。
• ワークスペースから環境をフェッチして、トレーニングまたはデプロイに使用する。
• 既存のインスタンスを編集して、環境の新しいインスタンスを作成する。
• 環境へのこれまでの変更を確認し、再現性を確保する。
• 環境から Docker イメージを自動的に構築する。

実験を送信すると、サービスによってワークスペースに "匿名" 環境が自動的に登録されます。 これらの環境は一覧に表示されませんが、バージョンを使用して取得できます。

コード例については、環境の使用方法に関するページの「環境の管理」セクションを参照してください。

環境のビルド、キャッシュ、再利用

Azure Machine Learning では、Docker イメージに環境定義が組み込まれます。 また、環境をキャッシュするため、後続のトレーニング ジョブとサービス エンドポイントのデプロイで再利用できます。 トレーニング スクリプトをリモートで実行するには、Docker イメージを作成する必要があります。 既定では、Azure Machine Learning は、ワークスペースの専用コンピューティング セットがない場合、使用可能なワークスペース サーバーレス コンピューティング クォータでイメージ ビルド ターゲットを管理します。

注

Azure Machine Learning ワークスペースのネットワーク制限には、専用のユーザー マネージド イメージ ビルド コンピューティングのセットアップが必要な場合があります。 ワークスペース リソース をセキュリティで保護する手順に従ってください。

環境を利用してジョブを送信する

環境を使用してリモート ジョブを最初に送信したり、環境インスタンスを手動で作成したりする場合、Azure Machine Learning は指定された仕様のイメージを構築します。 結果のイメージは、ワークスペースに関連付けられているコンテナー レジストリ インスタンスにキャッシュされます。 キュレーションされた環境は、Azure Machine Learning レジストリに既にキャッシュされています。 ジョブ実行の開始時に、コンピューティング先によって関連するコンテナー レジストリからイメージが取得されます。

Docker イメージとしての環境のビルド

Azure Machine Learning ワークスペースに関連付けられているコンテナー レジストリ インスタンスに特定の環境定義のイメージがまだ存在しない場合、サービスは新しいイメージをビルドします。 システム管理環境の場合、イメージのビルド プロセスは次の 2 つの手順で構成されます。

1. 基本イメージのダウンロードと、Docker 手順の実行
2. 環境定義で指定されている Conda の依存関係に従った Conda 環境の構築

ユーザーが管理する環境の場合、サービスは提供された Docker コンテキスト ビルドをそのまま使用します。 この場合、Python パッケージを基本イメージに含めるか、カスタム Docker ステップを指定して、Python パッケージをインストールする必要があります。

イメージのキャッシュと再利用

別のジョブに同じ環境定義を使用する場合、Azure Machine Learning は、ワークスペースに関連付けられているコンテナー レジストリからキャッシュされたイメージを再利用します。

キャッシュされたイメージの詳細を表示するには、Azure Machine Learning スタジオの環境ページを確認するか、MLClient.environments を使用して環境を調べます。

キャッシュされたイメージを再利用するか、新しいイメージをビルドするかを決定するため、Azure Machine Learning では、環境定義からハッシュ値が計算されます。 次に、そのハッシュが既存の環境のハッシュと比較されます。 ハッシュは、環境の一意識別子として機能し、環境定義に基づいています。

• TestVM
• カスタム Docker イメージ
• Python パッケージ

環境の名前とバージョンはハッシュに影響しません。 環境の名前を変更するか、別の環境と同じ設定とパッケージを使用して新しい環境を作成した場合、ハッシュ値は変わりません。 ただし、Python パッケージの追加や削除、パッケージ バージョンの変更など、環境定義が変更されると、結果のハッシュ値が変更されます。 環境内の依存関係の順序やチャネルの順序を変更すると、ハッシュも変更され、新しいイメージのビルドが必要になります。 同様に、キュレーションされた環境を変更すると、カスタム環境が作成されます。

注

環境の名前を変更しないと、キュレーションされた環境にローカルの変更を送信することはできません。 プレフィックス "AzureML-" と "Microsoft" は、キュレーションされた環境専用に予約されており、いずれかの名前で始まる場合、ジョブの送信は失敗します。

環境の計算されたハッシュ値は、ワークスペース コンテナー レジストリのハッシュ値との比較が行われます。 一致するものがある場合は、キャッシュされたイメージがプルされて使用されます。 それ以外の場合は、イメージ ビルドがトリガーされます。

次の図は、3 つの環境定義を示しています。 それらのうちの 2 つは、名前とバージョンが異なりますが、ベース イメージと Python パッケージが同じであるため、ハッシュと対応するキャッシュ イメージが同じになります。 3 番目の環境は Python パッケージとバージョンが異なるため、異なるハッシュとキャッシュされたイメージになります。

ワークスペース コンテナー レジストリに実際にキャッシュされているイメージの名前は、azureml/azureml_e9607b2514b066c851012848913ba19f のような名前になり、ハッシュは最後に表示されます。

重要

• numpy など、パッケージの依存関係を固定せずに環境を作成した場合、その環境では、"その環境の作成時に使用可能だった" パッケージのバージョンが使用されます。 一致する定義を使用する将来の環境では、元のバージョンが使用されます。

  パッケージを更新するには、バージョン番号を指定してイメージのリビルドを強制します。 この変更の例として、 numpy を numpy==1.18.1 に更新しています。 入れ子になった依存関係を含む新しい依存関係がインストールされ、以前に動作していたシナリオが壊れる可能性があります。

• 環境定義で mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04 のような固定されていない基本イメージを使用すると、 latest タグが更新されるたびにイメージが再構築される可能性があります。 この動作は、イメージが最新のパッチとシステム更新プログラムを受け取るのに役立ちます。

イメージの修正

Microsoft は、既知のセキュリティ脆弱性の基本イメージに修正プログラムを適用します。 サポートされているイメージの更新プログラムは 2 週間ごとにリリースされ、最新バージョンのイメージには 30 日より前の修正プログラムが適用されていない脆弱性はありません。 修正プログラムが適用されたイメージは、新しい変更できないタグを使用してリリースされ、 :latest タグはパッチが適用されたイメージの最新バージョンに更新されます。

新しくパッチが適用されたイメージを使用するには、関連付けられている Azure Machine Learning アセットを更新する必要があります。 たとえば、マネージド オンライン エンドポイントを使用する場合は、修正プログラムが適用されたイメージを使用するようにエンドポイントを再デプロイする必要があります。

独自のイメージを提供する場合は、それらを更新し、それらを使用する Azure Machine Learning アセットを更新する必要があります。

ベース イメージの詳細については、次のリンクを参照してください。

• Azure Machine Learning ベース イメージ GitHub リポジトリです。
• カスタム コンテナーを使用してモデルをオンライン エンドポイントにデプロイする
• 環境とコンテナー イメージの管理

関連するコンテンツ

• Azure Machine Learning で環境を作成および使用する方法を確認します。
• 環境クラスについては、Python SDK 参照ドキュメントを参照してください。