v2 にアップグレードする

[アーティクル]
03/05/2024

Azure Machine Learning の v2 REST API、Azure CLI 拡張機能、Python SDK では、運用環境の機械学習ライフサイクルを高速化するための一貫性と一連の新機能が導入されています。この記事では、v2 へのアップグレードの概要と、v1、v2、またはその両方を決定するために役立つ推奨事項について説明します。

前提条件

Azure Machine Learning と v1 Python SDK に関する一般的な知識。
v2 に関する理解

v2 を使用すべき場合

新しい機械学習プロジェクトまたはワークフローを開始する場合は、v2 を使用する必要があります。 v2 で提供される新機能を使用する場合は、v2 を使用する必要があります。機能は、次のとおりです。

マネージド推論
再利用可能なパイプラインのコンポーネント
パイプラインのスケジュール設定の改善
責任ある AI ダッシュボード
資産のレジストリ

新しい v2 プロジェクトでは、ワークスペースやコンピューティングなどの既存の v1 リソースや、v1 を使用して作成されたモデルや環境などの既存の資産を再利用できます。

v2 の機能のギャップには、次のようなものがあります。

ジョブでの Spark のサポート - 現在、v2 ではプレビュー段階です。
エンドポイントとしてのジョブ (v1 のパイプライン) の公開。ただし、公開しないでパイプラインをスケジュールすることもできます。
SQL/データベースデータストアのサポート。
v2 を使用してデザイナーで従来の事前構築済みコンポーネントを使用する機能。

次に、v2 で必要な機能が、一般に利用可能であるなど、組織の要件を満たしていることを確認する必要があります。

重要

Azure Machine Learning の新機能は v2 でのみ起動されます。

使用すべき v2 API はどれか

v2 では、REST API、CLI、Python SDK を介してインターフェイスを使用できます。使用すべきインターフェイスは、シナリオと設定によって異なります。

API	メモ
REST	最小限の依存関係とオーバーヘッドです。 Azure Machine Learning でアプリケーションを構築するためのプラットフォームとして使用できます。SDK を使用せずにプログラミング言語で直接使用することもできれば、個人の好みに従って使用することもできます。
CLI	CI/CD を使用した、または個人の好みによる自動化に推奨されます。 YAML ファイルを使用したすばやいイテレーションと、Azure Machine Learning と ML モデルコードの簡単な分離を可能にします。
Python SDK	複雑なスクリプト作成 (プログラムによる大規模なパイプラインジョブの生成など) または個人の好みに応じて推奨されます。 YAML ファイルを使用したすばやいイテレーションまたは Python のみでの開発を可能にします。

Python SDK v1 から v2 へのマッピング

SDK v1 と v2 の比較コードマッピングについては、次の各記事を参照してください。

リソースと資産	記事
ワークスペース	SDK v1 と SDK v2 でのワークスペース管理
データストア	SDK v1 と SDK v2 でのデータストア管理
データ	SDK v1 と v2 のデータ資産
Compute	SDK v1 と SDK v2 でのコンピューティング管理
トレーニング	[スクリプトの実行]
トレーニング	ローカル実行
トレーニング	ハイパーパラメーターの調整
トレーニング	並列実行
トレーニング	パイプライン
トレーニング	AutoML
モデル	SDK v1 と SDK v2 でのモデル管理
展開	デプロイエンドポイントを SDK v2 にアップグレードする

v1 と v2 のリソースと資産

このセクションでは、Azure Machine Learning の特定のリソースと資産の概要について説明します。 v2 での各エンティティの使用法について詳しくは、それぞれの概念に関する記事を参照してください。

ワークスペース

ワークスペースは v2 でアップグレードする必要はありません。 v1 と v2 のどちらを使用しているかに関係なく、同じワークスペースを使用できます。

自動化を使用してワークスペースを作成する場合は、ワークスペースを作成するためのコードを v2 にアップグレードすることを検討してください。通常、Azure リソースは、Azure Resource Manager (および Bicep) または同様のリソースプロビジョニングツールを使用して管理されます。または、CLI (v2) と YAML ファイルを使用することもできます。

SDK v1 と v2 のコードの比較については、「SDK v1 と SDK v2 でのワークスペース管理」を参照してください。

重要

ワークスペースでプライベートエンドポイントを使用している場合は、v2 API が使用されなないように、自動的に v1_legacy_mode フラグが有効になります。詳しくは、v2 でネットワーク分離を構成する方法に関するページを参照してください。

接続 (v1 のワークスペース接続)

v1 からのワークスペース接続はワークスペースに保持され、v2 で完全に使用できます。

SDK v1 と v2 のコードの比較については、「SDK v1 と SDK v2 でのワークスペース管理」を参照してください。

データストア

v1 で作成されたオブジェクトストレージデータストアの種類は、v2 で完全に使用できます。データベースデータストアはサポートされていません。オブジェクトストレージ (通常は Azure Blob) へのエクスポートが推奨される移行パスです。

SDK v1 と v2 のコードの比較については、「SDK v1 と SDK v2 でのデータストア管理」を参照してください。

データ (v1 のデータセット)

データセットの名前がデータ資産に変更されます。 下位互換性 が提供されています。つまり、V2 で V1 データセットを使用できます。 V2 ジョブで V1 データセットを使用すると、次のように V2 の型に自動的にマップされます。

V1 FileDataset = V2 Folder (uri_folder)
V1 TabularDataset = V2 Table (mltable)

上位互換性が提供されていないことに注意してください。つまり、V1 で V2 データ資産を使用することはできません。

この記事では、v2 でのデータの処理について詳しく説明します。 - ジョブ内のデータの読み取りと書き込み

SDK v1 と v2 のコードの比較については、「SDK v1 と v2 のデータ資産」を参照してください。

Compute

型 AmlCompute と ComputeInstance のコンピューティングは、v2 で完全に使用できます。

SDK v1 と v2 のコードの比較については、「SDK v1 と SDK v2 でのコンピューティング管理」を参照してください。

ジョブ (v1 の実験、実行、パイプライン)

v2 では、"実験"、"実行"、"パイプライン" がジョブに統合されます。ジョブには種類があります。ほとんどのジョブは、python main.py のようなコマンドを実行する command ジョブです。ジョブで実行されるものはどのプログラミング言語にも依存しないため、bash スクリプトの実行、python インタープリターの呼び出し、一連の curl コマンドの実行などが行えます。もう 1 つの一般的な種類のジョブは pipeline です。これは、入出力リレーションシップを持つ可能性のある子ジョブを定義し、有向非巡回グラフ (DAG) を形成します。

SDK v1 と v2 のコードの比較については、次を参照してください。

デザイナー

デザイナーを使用して、独自の v2 カスタムコンポーネントとレジストリの新しい事前構築済みコンポーネントを使用してパイプラインを構築できます。このような場合は、パイプラインで v1 データ資産または v2 データ資産を使用できます。

デザイナーを引き続き使用して、従来の事前構築済みコンポーネントと v1 データセットの種類 (表形式、ファイル) を使用してパイプラインを構築できます。 v2 データ資産では、既存のデザイナーの従来の事前構築済みコンポーネントを使用することはできません。

既存のデザイナーの従来の事前構築済みコンポーネントと v2 カスタムコンポーネントの両方を使用してパイプラインを構築することはできません。

モデル

v1 から作成されたモデルは v2 で使用できます。

SDK v1 と v2 のコードの比較については、「SDK v1 と SDK v2 でのモデル管理」を参照してください。

エンドポイントとデプロイ (v1 のエンドポイントと Web サービス)

SDK/CLI v1 を使用すると、ACI または AKS に Web サービスとしてモデルをデプロイできます。既存の v1 モデルデプロイと Web サービスはそのまま機能し続けますが、SDK/CLI v1 を使用して ACI または AKS に Web サービスとしてモデルをデプロイすることは、従来の機能とみなされるようになりました。新しいモデルデプロイの場合、v2 にアップグレードすることをお勧めします。 v2 では、マネージドエンドポイントまたは Kubernetes エンドポイントが用意されています。次の表に、推奨事項を示します。

v2 のエンドポイントの種類	アップグレード前のバージョン	メモ
ローカル	ACI	運用環境ではなく、ローカルでモデルデプロイを簡単にテストします。
マネージドオンラインエンドポイント	ACI、AKS	ほぼリアルタイムの応答と実稼働のための大規模なスケーリングを備えたエンタープライズグレードのマネージドモデルデプロイインフラストラクチャ。
マネージドバッチエンドポイント	バッチスコアリング用のパイプラインの ParallelRunStep	実稼働用の超並列バッチ処理を備えたエンタープライズグレードのマネージドモデルデプロイインフラストラクチャ。
Azure Kubernetes Service (AKS)	ACI、AKS	モデルデプロイ用に独自の AKS クラスターを管理し、IT オーバーヘッドを犠牲にして柔軟性ときめ細かな制御を提供します。
Azure Arc Kubernetes	該当なし	他のクラウドまたはオンプレミスで独自の Kubernetes クラスターを管理し、IT オーバーヘッドはかかるものの柔軟性ときめ細かな制御を提供します。

SDK v1 と v2 のコードの比較については、「デプロイエンドポイントを SDK v2 にアップグレードする」を参照してください。既存の ACI Web サービスからマネージドオンラインエンドポイントへの移行手順については、アップグレードガイドの記事とブログを参照してください。

環境

v1 から作成された環境は v2 で使用できます。 v2 には、環境をローカル Docker コンテキストから作成するなどの新機能があります。

シークレットを管理する

Key Vault シークレットの管理は、V2 では V1 と比較して大きく異なります。 V1 の set_secret SDK メソッドおよび get_secret SDK メソッドは V2 では使用できません。代わりに、Key Vault クライアントライブラリを使用した直接アクセスを使用する必要があります。

Key Vault の詳細については、「Azure Machine Learning トレーニングジョブで認証資格情報シークレットを使用するを参照してください。

機械学習ライフサイクル全体のシナリオ

Azure Machine Learning を使用する機械学習ライフサイクル全体で共通するシナリオがいくつかあります。いくつかを紹介し、v2 へのアップグレードに関する一般的な推奨事項を示します。

Azure のセットアップ

Azure では、リソースを作成するために Azure Resource Manager テンプレート (多くの場合、Bicep 経由で使用) が推奨されています。 Azure Machine Learning リソースを作成する場合も、同じ方法が適しています。

チームが Azure Machine Learning のみを使用している場合は、代わりに YAML ファイルと CLI を使用してワークスペースとその他のリソースをプロビジョニングすることを検討できます。

モデルのプロトタイプ作成

モデルのプロトタイプ作成には v2 をお勧めします。モデルトレーニングコードが Python またはその他のプログラミング言語である場合は、Azure Machine Learning の対話形式の使用に CLI を使用することを検討できます。または、Azure Machine Learning SDK のみを使用する Python でフルスタックアプローチ、または Azure Machine Learning Python SDK と YAML ファイルを使用する混合アプローチを採用することもできます。

運用モデルのトレーニング

運用モデルのトレーニングには v2 をお勧めします。ジョブは用語を統合し、一連の一貫性を提供します。これにより、型間の切り替え (command から sweep など) と、ジョブを YAML ファイルにシリアル化するための GitOps に適したプロセスが容易になります。

v2 では、機械学習コードをコントロールプレーンコードから分離する必要があります。この分離により、イテレーションが容易になり、ローカルとクラウド間の切り替えが容易になります。また、追跡とモデルのログ記録に MLflow を使用することをお勧めします。詳しくは、MLflow の概念に関する記事を参照してください。

運用モデルデプロイ

運用モデルデプロイには v2 をお勧めします。マネージドエンドポイントは IT オーバーヘッドを抽象化し、オンライン (凖リアルタイム) とバッチ (超並列) の両方のシナリオでモデルをデプロイおよびスコア付けするためのパフォーマンスの高いソリューションを提供します。

Kubernetes デプロイは、AKS または Azure Arc を通じて v2 でサポートされており、ご自分の組織が管理する Azure クラウドとオンプレミスのデプロイを有効にします。

機械学習の運用 (MLOps)

MLOps ワークフローには、通常、外部ツールを介した CI/CD が含まれます。通常、CLI は CI/CD で使用されますが、代わりに Python を呼び出すか、REST を直接使用することもできます。

v2 を使用した MLOps のソリューションアクセラレータは、https://github.com/Azure/mlops-v2 で開発されており、参照として使用したり、機械学習ライフサイクルのセットアップと自動化に採用したりできます。

v2 を使用した GitOps に関するメモ

v2の重要なパラダイムは、機械学習エンティティを git を使用したソース管理用の YAML ファイルとしてシリアル化して、v1 よりも優れた GitOps アプローチを可能にすることです。たとえば、CI/CD パイプラインで使用されるサービスプリンシパルのみが一部またはすべてのエンティティを作成/更新/削除できるポリシーを適用して、変更が、必要なレビュー担当者による pull request などの管理されたプロセスを通過するようにします。ソース管理のファイルは YAML であるため、時間の経過に伴う変更を簡単に比較および追跡できます。 v2 にアップグレードする際に、ご自分とチームで、このパラダイムに移行することを検討できます。

CLI を使用して az ml <entity> show --output yaml を介して任意のエンティティの YAML 表現を取得できます。この出力には、システムによって生成されるプロパティが含まれます。これは無視または削除できます。

既存の v1 コードを v2 にアップグレードする必要があるかどうか

v2 ワークフローで既存の v1 資産を再利用できます。たとえば、v1 で作成されたモデルを使用して、v2 でマネージド推論を実行できます。

必要に応じて、既存の v1 コードの特定の部分を v2 にアップグレードする場合は、このドキュメントに記載されている比較リンクを参照してください。

v1 と v2 を一緒に使用できる場合?

v1 と v2 は、ワークスペースに共存できます。 v2 ワークフローで既存の資産を再利用できます。たとえば、v1 で作成されたモデルを使用して、v2 でマネージド推論を実行できます。ワークスペース、コンピューティング、データストアなどのリソースは、例外を除いて、v1 と v2 で機能します。ユーザーは v1 Python SDK を呼び出してワークスペースの説明を変更してから、v2 CLI 拡張機能を使用してもう一度変更できます。ジョブ (v1 の実験/実行/パイプライン) は、v1 または v2 Python SDK から同じワークスペースに送信できます。ワークスペースには、v1 と v2 の両方のモデルデプロイエンドポイントを含めることができます。

v1 と v2 のコードを一緒に使用する

同じコードで v1 SDK と v2 SDK を一緒に使用することはお勧めしません。技術的には、同じコードで v1 と v2 を使用できます。これは、v1 と v2 が異なる Azure 名前空間を使用するためです。ただし、これらの名前空間 (ワークスペース、モデルなど) には同じ名前のクラスが多数存在するため、混乱を招き、コードの読みやすさとデバッグが困難になる可能性があります。

重要