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

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

  • チーム構造: ユース ケースとデータの分離、またはコスト管理の要件に応じて、Machine Learning チームが編成される方法と、プロジェクトでコラボレーションを行う方法。

  • 環境: 運用から開発を分離するために、開発およびリリース ワークフローの一部として使用される環境。

  • リージョン: Machine Learning ソリューションを提供するために必要なデータの場所と対象ユーザー。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

単一環境のデプロイ

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

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

  • Machine Learning のワークフローと成果物の段階的ロールアウト。 たとえば、環境全体のモデル化により、機敏性が向上し、デプロイの時間が短縮される可能性があります。

  • ダウンストリーム環境でより多くのアクセス制限を割り当てることができるため、強化されたリソースのセキュリティと制御。

  • 選択したユーザー グループにアクセスを付与できるため、開発環境以外の環境での運用データのトレーニング シナリオ。

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

複数環境のデプロイ

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

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

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

1 つの環境ではデータ アクセスが制限され、1 つの環境では運用データ アクセスがある

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

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

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

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

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

リージョンのトレーニング

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

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

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

リージョンでの提供

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

この設定のベネフィットは、データが存在するデータ センターに応じて実験を使用でき、以前のパイプライン ステージのより大規模なデータセットで基本モデルのトレーニングを引き続き利用できることです。

このアプローチの考慮事項は、複雑な実験パイプラインを実現できても、さらに多くの課題が生じる可能性があることです。 たとえば、複数のリージョン間で実験結果を比較すると、クォータとコンピューティング管理のオーバーヘッドが増加します。

リージョンの微調整

リファレンス実装

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

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

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

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

Contoso リファレンス実装