Azure でクラウド規模の分析を使用するデータ サイエンス プロジェクトのベスト プラクティス

  • [アーティクル]

Microsoft Azure でクラウド規模の分析を使用してデータ サイエンス プロジェクトを運用化する方法について、以下のベスト プラクティスをお勧めします。

ブループリントを開発する

データ サイエンス プロジェクトのための一連のサービスをバンドルするブループリントを開発することは、さまざまなデータ サイエンス チームのユース ケース間で一貫性を実現するために不可欠です。 企業内のさまざまなデータ サイエンス プロジェクトに使用できるテンプレート リポジトリの形式で、一貫性のあるブループリントを開発し、デプロイ時間を短縮できるようにすることをお勧めします。

データ サイエンス テンプレートのガイドライン

次のガイドラインを使用して、組織のためのデータ サイエンス テンプレートを開発します。

  • Azure Machine Learning ワークスペースをデプロイするためのコードとしてのインフラストラクチャ テンプレート セットを開発します。 キー コンテナー、ストレージ アカウント、Azure Application Insights、コンテナー レジストリなどのリソースを含めます。

  • これらのテンプレートに、コンピューティング インスタンス、コンピューティング クラスター、Azure Databricks などのデータ ストアとコンピューティング ターゲットの設定を含めます。

デプロイのベスト プラクティス

リアルタイム

  • テンプレートと Azure Cognitive Services に Azure Data Factory または Azure Synapse のデプロイを含めます。

  • テンプレートには、データ サイエンスの探索フェーズとモデルの初期運用を実行するために必要なすべてのツールを指定する必要があります。

初期設定の考慮事項

場合によっては、組織内のデータ サイエンティストが、迅速なオンデマンド分析のための環境を必要とすることがあります。 このような状況は、データ サイエンス プロジェクトが正式に設定されていない場合によくあります。 たとえば、Azure 内のクロス請求に必要なプロジェクト マネージャー、コスト コード、コスト センターが、欠落している要素の承認が必要なために存在しない場合があります。 場合によっては、組織またはチームのユーザーがデータ サイエンス環境にアクセスしてデータを理解し、プロジェクトの実現性を評価する必要があります。 また、プロジェクトによっては、データ製品数が少ないため、完全なデータ サイエンス環境が必要ではない場合もあります。

また、専用の環境、プロジェクト管理、コスト コード、コスト センターを備えた完全なデータ サイエンス プロジェクトが必要になる場合もあります。 完全なデータ サイエンス プロジェクトは、複数のチーム メンバーが共同作業を行い、結果を共有し、探索フェーズが成功した後にモデルを運用化する必要がある場合に役立ちます。

設定プロセス

テンプレートは、設定後にプロジェクトごとにデプロイする必要があります。 開発環境と運用環境を分けるために、各プロジェクトには少なくとも 2 つのインスタンスを用意する必要があります。 運用環境では、個人がアクセスできないようにし、すべてを継続的インテグレーションまたは継続的開発パイプラインとサービス プリンシパルを使用してデプロイする必要があります。 これらの運用環境の原則が重要なのは、Azure Machine Learning にはワークスペース内できめ細かいロールベースのアクセス制御モデルが用意されていないためです。 実験、エンドポイント、またはパイプラインの特定のセットにユーザー アクセスを制限することができません。

通常、同じアクセス権が異なる種類の成果物に適用されます。 運用環境のパイプラインまたはエンドポイントがワークスペース内で削除されないように、開発と運用を分離することが重要です。 テンプレートと共に、データ製品チームが新しい環境を要求できるようにするためのプロセスを構築する必要があります。

Azure Cognitive Services などのさまざまな AI サービスを、プロジェクトごとに設定することをお勧めします。 プロジェクトごとに異なる AI サービスを設定することで、データ製品リソース グループごとにデプロイが行われます。 このポリシーにより、データ アクセスの観点からの明確な分離が確立され、不適切なチームによる未承認のデータ アクセスのリスクが軽減されます。

ストリーミングのシナリオ

リアルタイムとストリーミングのユース ケースでは、ダウンサイズした Azure Kubernetes Service (AKS) 上でデプロイをテストする必要があります。 運用の AKS またはコンテナー用 Azure App Service にデプロイする前に開発環境でテストすることで、コストを節約することができます。 単純な入出力テストを実行して、サービスが期待どおりに応答することを確認する必要があります。

次に、モデルを目的のサービスにデプロイします。 このデプロイ コンピューティング ターゲットは、一般提供され、AKS クラスターの運用ワークロードに推奨されている唯一のものです。 この手順は、グラフィックス プロセッシング ユニット (GPU) やフィールドプログラマブル ゲート配列のサポートが必要な場合にさらに必要になります。 これらのハードウェア要件をサポートする他のネイティブ デプロイ オプションは、現在、Azure Machine Learning では使用できません。

Azure Machine Learning には、AKS クラスターへの 1 対 1 のマッピングが必要です。 Azure Machine Learning ワークスペースに新たに接続するたびに、AKS と Azure Machine Learning 間の以前の接続は切断されます。 この制限が緩和されたら、中央の AKS クラスターを共有リソースとしてデプロイし、それぞれのワークスペースにアタッチすることをお勧めします。

モデルを運用 AKS に移行する前にストレス テストを実行する必要がある場合は、別の中央テスト AKS インスタンスをホストする必要があります。 運用環境と同等の結果が得られるように、テスト環境には運用環境と同じコンピューティング リソースを用意する必要があります。

バッチ シナリオ

すべてのユース ケースで AKS クラスターのデプロイが必要なわけではありません。 大量のデータが定期的なスコアリングのみを必要とする場合、またはイベントに基づいている場合、ユース ケースでは AKS クラスターのデプロイは必要ありません。 たとえば、大量のデータが、データが特定のストレージ アカウントにドロップされるタイミングに基づいている場合があります。 このようなシナリオでは、Azure Machine Learning パイプラインと Azure Machine Learning コンピューティング クラスターをデプロイに使用する必要があります。 このようなパイプラインは、Data Factory 内で調整し、実行する必要があります。

適切なコンピューティング リソースを特定する

Azure Machine Learning のモデルを AKS にデプロイする前に、ユーザーはそれぞれのモデルに割り当てる必要がある CPU、RAM、GPU などのリソースを指定する必要があります。 これらのパラメーターを定義することは、複雑で面倒なプロセスになる可能性があります。 適切なパラメーターのセットを特定するために、さまざまな構成でストレス テストを実行する必要があります。 Azure Machine Learning のモデル プロファイリング機能を使用することでこのプロセスを簡略化できます。これは、さまざまなリソース割り当ての組み合わせをテストし、特定された待機時間とラウンド トリップ時間 (RTT) を使用して最適な組み合わせを推奨する、実行時間の長いジョブです。 この情報は、AKS 上での実際のモデル デプロイに役立ちます。

Azure Machine Learning のモデルを安全に更新するには、チームが制御されたロールアウト機能 (プレビュー) を使用してダウンタイムを最小限に抑え、モデルの REST エンドポイントの一貫性を保つ必要があります。

MLOps のベスト プラクティスとワークフロー

データ サイエンスのリポジトリにサンプル コードを含める

チームに特定の成果物とベスト プラクティスがある場合は、データ サイエンス プロジェクトを簡素化し、高速化できます。 すべてのデータ サイエンス チームが Azure Machine Learning とデータ製品環境のそれぞれのツールで作業するときに使用できる成果物を作成することをお勧めします。 データ エンジニアと機械学習エンジニアが、成果物を作成して提供する必要があります。

これらの成果物には以下が含まれます。

  • 次の方法を示すサンプル ノートブック。

    • データ製品の読み込み、マウント、操作。
    • ログのメトリックとパラメーター。
    • コンピューティング クラスターへのトレーニング ジョブの送信。

  • 運用化に必要な成果物:

    • サンプル Azure Machine Learning パイプライン
    • サンプル Azure パイプライン
    • パイプラインの実行に必要なその他のスクリプト

  • ドキュメント

適切に設計された成果物を使用してパイプラインを運用化する

成果物により、データ サイエンス プロジェクトの探索と運用のフェーズが高速になります。 DevOps のフォーク戦略は、これらの成果物をすべてのプロジェクトでスケーリングするのに役立ちます。 この設定によって Git の使用が促進されるので、提供された成果物により自動化プロセス全体が恩恵を受けることができます。

ヒント

Azure Machine Learning のサンプル パイプラインは、Python ソフトウェア開発キット (SDK) を使用するか、YAML 言語をベースにして構築する必要があります。 新しい YAML エクスペリエンスはより将来性のあるものになります。これは、Azure Machine Learning 製品チームが、現在、新しい SDK とコマンドライン インターフェイス (CLI) に取り組んでいるからです。 Azure Machine Learning の製品チームは、YAML が Azure Machine Learning 内のすべての成果物の定義言語として機能することに自信を持っています。

サンプル パイプラインは、そのままでは各プロジェクトに使用できませんが、ベースラインとしては使用できます。 プロジェクトに合わせてサンプル パイプラインを調整できます。 パイプラインには、各プロジェクトの最も関連性の高い部分を含める必要があります。 たとえば、パイプラインで、コンピューティング先を参照したり、データ製品を参照したり、パラメーターを定義したり、入力を定義したり、実行手順を定義したりできます。 同じプロセスを Azure Pipelines についても行う必要があります。 Azure Pipelines には、Azure Machine Learning SDK または CLI を使用する必要があります。

パイプラインは、次の方法を示すものにする必要があります。

  • DevOps パイプライン内からワークスペースに接続する。
  • 必要なコンピューティングが使用可能かどうかを確認する。
  • ジョブを送信する。
  • モデルを登録してデプロイする。

成果物は、すべてのプロジェクトに常に適合するわけではなく、カスタマイズが必要になる場合もありますが、基礎があることで、プロジェクトの運用化やデプロイを迅速に実行できるようになります。

MLOps リポジトリの構造

ユーザーが成果物を検索したり格納したりできる場所が分からなくなってしまうことがあります。 このような状況を回避するために、標準リポジトリの最上位フォルダー構造の話し合いと構築により多くの時間をかけるように要求する必要があります。 すべてのプロジェクトはこのフォルダー構造に従う必要があります。

Note

このセクションで説明した概念は、オンプレミス、アマゾン ウェブ サービス、Palantir、Azure の各環境で使用できます。

MLOps (機械学習の運用) リポジトリの最上位フォルダー構造の提案を次に図示します。

MLOps のリポジトリの構造の図。

リポジトリ内の各フォルダーには、次の目的が適用されます。

Folder 目的
.cloud クラウド固有のコードと成果物をこのフォルダーに格納します。 成果物には、コンピューティング ターゲットの定義、ジョブ、登録モデル、エンドポイントなど、Azure Machine Learning ワークスペースの構成ファイルが含まれます。
.ado/.github YAML パイプラインやコード所有者などの Azure DevOps または GitHub の成果物をこのフォルダーに格納します。
code プロジェクトの一部として開発された実際のコードをこのフォルダーに含めます。 このフォルダーには、機械学習パイプラインの各手順に使用される Python パッケージといくつかのスクリプトを含めることができます。 このフォルダーで実行する必要のある個々の手順を分けることをお勧めします。 一般的な手順は、前処理、モデルのトレーニング、モデルの登録です。 各フォルダーに対して、Conda の依存関係、Docker イメージなどの依存関係を定義します。
docs このフォルダーはドキュメントのために使用します。 このフォルダーには、プロジェクトを説明するマークダウン ファイルとイメージが格納されています。
pipelines YAML または Python の Azure Machine Learning パイプライン定義をこのフォルダーに格納します。
tests プロジェクトの初期段階でバグと問題を発見するために実行する必要がある単体テストおよびや統合テストをこのフォルダーに作成します。
notebooks このフォルダーを使用して、Jupyter ノートブックを実際の Python プロジェクトから分離します。 このフォルダー内には、各個人にサブフォルダーを用意して、自分のノートブックをチェックインし、Git のマージの競合を防ぐ必要があります。

次の手順

Azure でのクラウド規模の分析データ製品