Azure Machine Learning 環境とは?

  • [アーティクル]

Azure Machine Learning 環境は、機械学習トレーニングが行われる環境をカプセル化したものです。 そこでは、トレーニングとスコアリングのスクリプト周りの Python パッケージ、およびソフトウェア設定を指定します。 環境は、Machine Learning ワークスペース内で管理およびバージョン管理されるエンティティであり、さまざまなコンピューティング先で再現、監査、移植が可能な機械学習ワークフローを実現します。

Environment オブジェクトは、次の用途に使用できます。

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

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

Diagram of an environment in machine learning workflow

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

環境の種類

環境は、キュレーション、ユーザー管理、システム管理の 3 つのカテゴリに大別できます。

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

ユーザー管理環境では、ユーザーが環境を設定し、トレーニング スクリプトで必要なすべてのパッケージをコンピューティング先にインストールする必要があります。 また、モデル デプロイに必要な依存関係を必ず含めるようにしてください。 ユーザー管理環境では、イメージの具体化を AzureML に委任する BYOC (Bring Your Own Container) または Docker Build Context をベースとすることができます。

Python 環境を Conda で自動的に管理したいときは、システム管理環境を使用します。 新しい 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 イメージを作成する必要があります。 既定では、AzureML は、ワークスペースの専用コンピューティング セットがない場合、使用可能なワークスペース サーバーレス コンピューティング クォータでイメージ ビルド ターゲットを管理します。

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

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

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

Diagram of environment caching and Docker images

ワークスペース コンテナー レジストリに実際にキャッシュされているイメージの名前は、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 アセットを更新する必要があります。

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

次のステップ