Azure Machine Learning 環境の整理とセットアップ

エンタープライズ環境で Azure Machine Learning のデプロイを計画するときは、ワークスペースを作成する方法に影響を与えるいくつかの一般的な意思決定ポイントがあります。

• チーム構造: ユース ケースとデータの分離、またはコスト管理の要件に応じて、データ サイエンス チームが編成される方法と、プロジェクトでコラボレーションを行う方法
• 環境: 運用から開発を分離するために、開発およびリリース ワークフローの一部として使用される環境
• リージョン: 機械学習ソリューションを提供するために必要なデータの場所と対象ユーザー

チーム構造とワークスペースの設定

ワークスペースは、Azure Machine Learning の最上位のリソースです。 ここには、機械学習、マネージド コンピューティング、アタッチされた関連リソースへのポインターを操作するときに生成される成果物が格納されます。 管理性の観点から見ると、ワークスペースを Azure Resource Manager リソースとして使用すると、Azure のロールベースのアクセス制御 (Azure RBAC) およびポリシーによる管理がサポートされ、コスト レポートの単位として使用できます。

通常、組織は、管理容易性の要件に従うために、次のソリューション パターンの 1 つまたは組み合わせを選択します。

チームあたりのワークスペース: チームのすべてのメンバーがデータと実験資産に同じレベルのアクセスを必要とする場合は、チームごとに 1 つのワークスペースを使用します。 たとえば、3 つの機械学習チームを持つ組織は、チームごとに 1 つずつ、3 つのワークスペースを作成できます。

チームごとに 1 つのワークスペースを使用するベネフィットは、チームのプロジェクトのすべての機械学習成果物が 1 か所に格納されることです。 チーム メンバーは実験結果に簡単にアクセスし、探索し、再利用できるため、生産性の向上が把握できます。 チームごとにワークスペースを編成すると、Azure の占有領域が削減され、チーム別のコスト管理が簡素化します。 実験資産の数は急速に増加する可能性があるため、名前付けおよびタグ付け規則に従って成果物を整理しておくことができます。 リソースに名前を付ける方法に関する推奨事項については、「Azure リソースの名前付けおよびタグ付けの戦略を作成する」を参照してください。

このアプローチでは、各チーム メンバーには類似したデータ アクセス レベルのアクセス許可が必要です。 データ ソースと実験資産の詳細なロールベースのアクセス制御 (RBAC) とアクセス制御リスト (ACL) は、ワークスペース内で制限されます。 ユース ケースのデータ分離要件を設定することはできません。

プロジェクトごとのワークスペース: プロジェクトごとにデータと実験資産を分離する必要がある場合、またはプロジェクト レベルでコスト レポートと予算の要件がある場合は、プロジェクトごとに 1 つのワークスペースを使用します。 たとえばある組織で、それぞれが 3 つのプロジェクトを実行する 4 つの機械学習チームを持ち、合計 12 個のワークスペース インスタンスを持つことができます。

プロジェクトごとに 1 つのワークスペースを使用するベネフィットは、プロジェクト レベルでコストを管理することです。 チームは通常、同じような理由で Azure Machine Learning と関連リソース専用のリソース グループを作成します。 たとえば、外部の共同作成者と協力して作業する場合、外部ユーザーにはチーム リソースではなくプロジェクト リソースへのアクセスのみを許可する必要があるため、プロジェクト中心のワークスペースによってプロジェクトのコラボレーションが簡略化されます。

このアプローチの考慮事項は、実験結果と資産を分離することです。 複数のワークスペース インスタンスに資産が分散しているため、資産の検出と再利用が困難になることがあります。

1 つのワークスペース: チーム外または非プロジェクト関連の作業の場合、または研究開発などの特定の請求単位にコストを直接関連付けることができない場合、1 つのワークスペースを使用します。

この設定のベネフィットは、個々のプロジェクトに関連しない作業のコストをプロジェクト関連のコストから分離できることです。 すべてのユーザーが個別の作業を行うために 1 つのワークスペースを設定すると、Azure の占有領域が減少します。

このアプローチでは、多くの機械学習の実践者が同じインスタンスを共有している場合に、ワークスペースが急速に乱雑になる点があります。 ユーザーは、リソースを効果的に検索するために、資産の UI ベースのフィルター処理を行わなければならない場合があります。 ビジネス部門ごとに共有の機械学習ワークスペースを作成して、スケールの問題を軽減したり、予算を分割したりできます。

環境とワークスペースの設定

環境とは、アプリケーションのライフサイクルの段階に基づいてデプロイ対象となるリソースのコレクションです。 環境名の一般的な例として、開発、テスト、QA、ステージング、運用があります。

組織内の開発プロセスは、環境の使用に関する要件に影響します。 環境は、Azure Machine Learning と、接続されたコンピューティングなどの関連するリソースの設定に影響します。 たとえば、データの可用性によって、環境ごとに機械学習インスタンスを使用可能にする管理容易性が制約される場合があります。 一般的なソリューション パターンは次のとおりです。

単一環境ワークスペースのデプロイ: 1 つの環境ワークスペースのデプロイを選択すると、Azure Machine Learning が 1 つの環境にデプロイされます。 この設定は、複数の環境にわたりライフサイクル ステージに基づいて 機械学習成果物をリリースする必要がない、研究中心のシナリオで一般的です。 この設定が理にかなっているもう 1 つのシナリオは、機械学習パイプラインではなく、推論サービスのみが環境間でデプロイされる場合です。

研究中心の設定のベネフィットは、Azure 占有領域が小さくなり、管理オーバーヘッドが最小限に抑えられることです。 この作業方法は、各環境に Azure Machine Learning ワークスペースをデプロイする必要がないことを意味します。

このアプローチでは、1 つの環境のデプロイがデータの可用性の影響を受けます。 そのため、データストアを設定するときは注意が必要です。 たとえば、運用データ ソースでのライター アクセスなど、広範なアクセスを設定した場合、データ品質に意図しない損害を与える可能性があります。 開発が行われる同一環境で作業の運用を開始する場合、開発作業と運用作業の両方に同じ RBAC 制限が適用されます。 この設定によって、両方の環境の柔軟性が低くなりすぎるか高くなりすぎる可能性があります。

複数環境ワークスペースのデプロイ: 複数環境ワークスペースのデプロイを選択すると、環境ごとに 1 つのワークスペース インスタンスがデプロイされます。 この設定の一般的なシナリオが、環境間で職務が明確に分離され、それらの環境へのリソース アクセスを持つユーザーを対象とした、規制のあるワークプレースです。

この設定のベネフィットは次のとおりです。

• 機械学習のワークフローと成果物の段階的ロールアウト。 たとえば、環境全体のモデル化により、機敏性が向上し、デプロイの時間が短縮される可能性があります。
• ダウンストリーム環境でより多くのアクセス制限を割り当てることができるため、強化されたリソースのセキュリティと制御。
• 選択したユーザー グループにアクセスを付与できるため、開発環境以外の環境での運用データのトレーニング シナリオ。

このアプローチでは、管理とプロセスのオーバーヘッドが増えるリスクがあります。 このセットアップには、ワークスペース インスタンス間の機械学習成果物に、詳細な開発およびロールアウト プロセスが必要です。 さらに、運用データを開発環境でのトレーニングで使用できるようにするために、データ管理とエンジニアリング作業が必要になることがあります。 アクセス管理では、運用環境でインシデントを解決および調査するためのアクセスをチームに付与することが必要です。 最後に、自動化ワークフローを実装するために、Azure DevOps と機械学習エンジニアリングに関する専門知識がチームに必要です。

データ アクセスが制限された 1 つの環境と、運用データにアクセスできるもう 1 つの環境: この設定を選択すると、Azure Machine Learning がデプロイされる環境は、データ アクセスが制限されているものと、運用データにアクセスできるものの 2 つです。 この設定は、開発と運用の環境を分離する必要がある場合に一般的です。 たとえば、運用データを任意の環境で使用できるようにするために組織の制約の下で作業している場合、またはメンテナンス コストが高いために必要以上にデータを複製せずに、運用作業から開発作業を分離する必要がある場合などです。

この設定のベネフィットは、開発と運用の環境間で職務とアクセスが明確に分離されることです。 別のベネフィットとして、複数環境のデプロイ シナリオと比べて、リソース管理のオーバーヘッドが低くなります。

このアプローチでは、ワークスペース間の機械学習成果物に定義された開発およびロールアウト プロセスが必要です。 さらに、運用データを開発環境でのトレーニングで使用できるようにするために、データ管理とエンジニアリング作業が必要になることがあります。 ただし、このアプローチでは、複数環境ワークスペースのデプロイよりも、必要な労力が比較的少なくなる可能性があります。

リージョンとリソースの設定

リソース、データ、またはユーザーの場所によっては、複数の Azure リージョンに Azure Machine Learning ワークスペース インスタンスと関連リソースを作成することが必要になる場合があります。 たとえば、1 つのプロジェクトのリソースが、パフォーマンス、コスト、コンプライアンス上の理由から、西ヨーロッパと米国東部の Azure リージョンにまたがっている場合があります。 一般的なシナリオを次に示します。

リージョンのトレーニング: Machine Learning のトレーニング ジョブは、データが配置されているのと同じ Azure リージョンで実行されます。 この設定では、データが配置されている各 Azure リージョンに機械学習ワークスペースがデプロイされます。 このシナリオは、コンプライアンスを満たす必要がある場合や、複数のリージョンにわたるデータ移動の制約がある場合に一般的です。

この設定のベネフィットは、データが配置されているデータ センターで、最も短いネットワーク待機時間で実験を行えることです。 このアプローチでは、機械学習パイプラインを複数のワークスペース インスタンスで実行すると、管理の複雑さが増すという点があります。 これにより、インスタンス間で実験結果を比較することが困難になり、クォータとコンピューティング管理のオーバーヘッドが増加します。

複数のリージョン間でストレージを接続しても、コンピューティングを 1 つのリージョンから使用する場合、Azure Machine Learning では、ワークスペースではなくリージョンにストレージ アカウントをアタッチするシナリオがサポートされます。 メトリックなどのメタデータは、ワークスペースのリージョンに格納されます。

リージョンでの提供: Machine Learning サービスは、対象ユーザーが住んでいる場所に近い場所にデプロイされます。 たとえば、対象ユーザーがオーストラリアにいて、メイン ストレージと実験リージョンが西ヨーロッパである場合は、実験用の機械学習ワークスペースを西ヨーロッパにデプロイします。 そして、推論エンドポイントのデプロイ用の AKS クラスターをオーストラリアにデプロイします。

この設定のベネフィットは、新しいデータが取り込まれるデータ センターで推論の機会を得ることができ、待機時間とデータ移動を最小限に抑えて、現地の規制に準拠させることができる点です。

このアプローチでは、複数リージョンの設定にいくつかの利点があるほか、クォータとコンピューティング管理のオーバーヘッドも増加します。 バッチ推論の要件がある場合、リージョンでの提供では複数ワークスペースのデプロイが必要になることがあります。 推論エンドポイントを介して収集されたデータは、再トレーニングのシナリオのためにリージョン間で転送しなければならない場合があります。

リージョンの微調整: 基本モデルは、パブリック データやすべてのリージョンのデータなどの初期データセットでトレーニングされ、その後、リージョンのデータセットを使用して微調整されます。 リージョンのデータセットは、コンプライアンスまたはデータ移動の制約により、特定のリージョンにのみ存在する場合があります。 たとえば、基本モデルのトレーニングはリージョン A のワークスペースで行われ、リージョン B のワークスペースでは微調整が行われることがあります。

このセットアップの利点は、データが存在するデータ センターで準拠しながら実験できることです。 また、以前のパイプライン ステージの大きなデータセットに対して、基本モデルのトレーニングを引き続き利用することもできます。

このアプローチでは複雑な実験パイプラインがサポートされますが、より多くの課題が発生する可能性があります。 たとえば、リージョン間で実験の結果を比較すると、クォータとコンピューティング管理のオーバーヘッドが増える可能性があります。

リファレンス実装

より大きな設定で Azure Machine Learning のデプロイを説明するために、このセクションでは、組織の制約、レポート、予算の要件に基づいて組織 'Contoso' がどのように Azure Machine Learning を設定するかを示します。

• Contoso では、コスト管理とレポート作成の理由により、ソリューションごとにリソース グループを作成します。
• IT 管理者は、予算の要件を満たすために、資金調達ソリューション用のリソース グループとリソースのみを作成します。
• データ サイエンスには探索的で不確定な性質があるため、ユーザーには、ユース ケースやデータ探索について実験して作業するための場所が必要です。 一般に探索作業は特定のユース ケースに直接関連付けることができず、関連付けできるのは R&D 予算に対してだけです。 Contoso では、すべてのユーザーが探索目的で使用できる、いくつかの機械学習リソースを一元的に資金調達したいと考えています。
• 機械学習のユース ケースが探索環境で成功することが判明したら、チームはリソース グループを要求できます。 たとえば企業では、反復的な実験プロジェクト作業のための開発、QA、運用環境と、運用データ ソースへのアクセスを設定できます。
• データの分離とコンプライアンスの要件により、ライブ運用データは開発環境には存在できません。
• 環境ごとの IT ポリシーによって、さまざまなユーザー グループに対して異なる RBAC 要件が存在します。たとえば、運用環境ではアクセスがより制限されています。
• すべてのデータ、実験、および推論は、1 つの Azure リージョンで実行されます。

上記の要件に準拠するために、Contoso では次のようにリソースが設定されます。

• 予算とユース ケースの分離要件に従うために、プロジェクトごとに範囲指定される Azure Machine Learning のワークスペースとリソース グループ。
• Azure Machine Learning および関連するリソースがコスト管理、RBAC、データ アクセスの要件に対応するための複数環境の設定。
• 探索専用の 1 つのリソース グループと機械学習ワークスペース。
• ユーザー ロールと環境ごとに異なる Microsoft Entra グループ。 たとえば、データ科学者が運用環境で実行できる操作は、開発環境の場合とは異なり、ソリューションごとにアクセス レベルが異なる場合があります。
• 1 つの Azure リージョンに作成されるすべてのリソース。

次のステップ

Azure Machine Learning を使用した機械学習の DevOps のベスト プラクティスについて説明します。

Azure Machine Learning で予算、クォータ、コストを管理する際の考慮事項について説明します。