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

[アーティクル]
04/27/2023

エンタープライズ環境で 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 のベストプラクティスについて説明します。

機械学習の DevOps ガイド

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

組織規模での Azure Machine Learning の予算、コスト、クォータを管理する