編集

次の方法で共有


多モデル アプローチを使用して機械学習モデルをスケーリングする

Azure Data Factory
Azure Data Lake
Azure Databricks
Azure Machine Learning
Azure Synapse Analytics

この記事では、Azure Machine Learning とコンピューティング クラスターを使用する多くのモデルのアーキテクチャについて説明します。 複雑なセットアップが必要な状況に対して汎用性を提供します。

Architecture

多くのモデル アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

次のデータフローは、前の図に対応しています。

  1. データ インジェスト:

    1. Azure Data Factory は、ソース データベースからデータを取得し、Azure Data Lake Storage にコピーします。

    2. その後、データは、表形式のデータセットとして Machine Learning データ ストアに格納されます。

  2. モデルトレーニング パイプライン:

    1. データの準備:

      1. トレーニング パイプラインは、データ ストアからデータを取得し、必要に応じて変換します。

      2. データは、モデルをトレーニングするためのデータセットにグループ化されます。

    2. モデルのトレーニング:

      1. パイプラインは、データ準備中に作成されたすべてのデータセットのモデルをトレーニングします。

      2. ParallelRunStep クラスを使用して、複数のモデルを並列でトレーニングします。

      3. モデルがトレーニングされると、パイプラインによってモデルとそのテスト メトリックが Machine Learning に登録されます。

  3. モデル昇格パイプライン:

    1. モデルの評価:

      1. 昇格パイプラインは、トレーニング済みのモデルを運用環境に移行する前に評価します。

      2. DevOps パイプラインがビジネス ロジックを適用して、モデルがデプロイの条件を満たしているかどうかを判断します。 たとえば、テスト データの精度が 80%を超えているかどうかを確認できます。

    2. モデルの登録:

      1. 昇格パイプラインは、対象となるモデルを運用環境の Machine Learning ワークスペースに登録します。
  4. モデルのバッチ スコアリング パイプライン:

    1. データの準備:

      1. バッチ スコアリング パイプラインは、データ ストアからデータを取得し、必要に応じて各ファイルを変換します。

      2. データは、スコア付けのためにデータセットにグループ化されます。

    2. モデルのスコア付け:

      1. パイプラインでは、ParallelRunStep クラスを使用して複数のデータセットを並列にスコア付けします。

      2. モデル タグを検索して、Machine Learning の各データセットに適したモデルを識別します。

      3. モデルがダウンロードされ、データセットのスコア付けに使用されます。

      4. DataTransferStep クラスは、結果を Azure Data Lake に書き戻します。

      5. 予測は、提供のために Azure Data Lake から Synapse SQL に渡されます。

      6. マネージド オンライン エンドポイントは、リアルタイム スコアリングを提供します。

      7. モデルの数が多いため、事前に読み込まれるのではなく、必要に応じて読み込まれます。

  5. 結果:

    • 予測: バッチ スコアリング パイプラインでは、予測を Synapse SQL に保存します。

    • メトリック: Microsoft Power BI モデル予測に接続して、プレゼンテーションの結果を取得して集計します。

コンポーネント

  • Azure Data Factory は、データ移動と変換を調整および自動化するためのデータドリブン ワークフローを作成できるクラウドベースのデータ統合サービスです。 このアーキテクチャでは、Azure Data Factory はエンタープライズ データとサードパーティのメタデータを Data Lake Storage に取り込みます。

  • Azure DevOps は、アプリケーションとインフラストラクチャの包括的なライフサイクル管理を提供する一連の開発者サービスです。 継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン、作業追跡、ソース管理、ビルド パイプライン、パッケージ管理、テスト ソリューションのためのツールが含まれています。 このアーキテクチャでは、Azure DevOps を使用して、モデルの昇格、テスト、運用環境へのデプロイを自動化するための CI/CD パイプラインを管理します。

  • azure SQL Database は、フル マネージドのリレーショナル クラウド データベースです。 このアーキテクチャでは、SQL Database を使用して、データ パイプラインの一部としてクエリまたは分析される可能性がある構造化データを格納します。

  • Azure Stream Analytics は、大量の高速ストリーミング データを分析して処理するように設計された、リアルタイム分析および複雑なイベント処理サービスです。 このアーキテクチャでは、Stream Analytics を使用してリアルタイムのデータ処理を行うことができます。

  • Azure Synapse Analytics は、データ統合、エンタープライズ データ ウェアハウジング、ビッグ データ分析を統合した分析サービスです。 このアーキテクチャでは、バッチ スコアリングの結果を格納するために使用されます。 このアプローチにより、レポートまたは分析のための予測の効率的なクエリと取得が可能になります。 Synapse SQL は、ダウンストリーム アプリケーションに予測を提供し、Power BI などの視覚化ツールが集計結果にアクセスできるようにするために使用されます。

  • Data Lake Storage は、高パフォーマンスの分析ワークロード用の非常にスケーラブルで安全なストレージ サービスです。 このアーキテクチャでは、Data Lake Storage は、未加工のデータセットと変換されたデータセットのプライマリ ストレージ レイヤーとして機能し、スコアリング パイプラインからの結果を格納するために機能します。

  • Machine Learning は、モデルをすばやく構築およびデプロイするためのエンタープライズ レベルの機械学習サービスです。 低コード デザイナー、自動化された機械学習、さまざまな統合開発環境をサポートするホスト型 Jupyter Notebook 環境などのツールを、すべてのスキル レベルのユーザーに提供します。 このアーキテクチャでは、Machine Learning を使用して、トレーニング、評価、デプロイなどのモデルのライフサイクルを管理します。 また、トレーニング、昇格、スコア付けなどのタスクのパイプラインを調整します。

    • マネージド オンライン エンドポイント は、リアルタイム スコアリングに使用される Machine Learning の機能です。 このアーキテクチャでは、マネージド オンライン エンドポイントは、機械学習モデルをオンデマンドで読み込むことで、ほぼリアルタイムで予測を提供するスケーラブルで安全な方法を提供するのに役立ちます。

    • ParallelRunStep クラス は、並列ジョブを効率的に実行するために使用される Machine Learning パイプラインのコンポーネントです。 これにより、多数のモデルを同時にトレーニングまたはスコア付けするなど、バッチ タスクのスケーラブルな処理が可能になります。 このアーキテクチャでは、モデル トレーニング パイプラインとバッチ スコアリング パイプラインの両方で ParallelRunStep クラスを使用して、複数のデータセットまたはモデルを並列でトレーニングまたはスコア付けし、これらの操作の実行時間を大幅に削減します。

  • Power BI は、関連のないデータ ソースを一貫性のある視覚的にイマーシブな対話型の分析情報に変換するために連携するソフトウェア サービス、アプリ、コネクタのコレクションです。 このアーキテクチャでは、Power BI は Synapse SQL に接続して、対話型ダッシュボードを使用して予測と集計メトリックを取得して提示します。

代替

  • ソース データには任意のデータベースを使用できます。

  • マネージド オンライン エンドポイントではなく、リアルタイム推論に Azure Kubernetes Service (AKS) を使用できます。 AKS を使用すると、コンテナー化されたモデルをデプロイし、デプロイをより詳細に制御できます。 これらの機能を使用すると、リソースを使い果たすことなく、受信要求を処理するモデルの動的読み込みが可能になります。

シナリオの詳細

機械学習の問題の多くは、単一の機械学習モデルで解決するには複雑すぎます。 すべての店舗のすべてのアイテムの売上を予測する場合でも、何百もの油井のメンテナンスをモデル化する場合でも、インスタンスごとにモデルを使用すると、多くの機械学習の問題に対する結果が向上する可能性があります。 この "多数モデル" のパターンは、さまざまな業界で共通しており、現実に多くのユース ケースがあります。 Machine Learning を使用すると、エンドツーエンドの多くのモデル パイプラインに、モデルトレーニング、バッチ推論デプロイ、リアルタイムデプロイを含めることができます。

多くのモデル ソリューションでは、トレーニングとスコアリング中にモデルごとに異なるデータセットが必要です。 たとえば、タスクがすべてのストア内の各項目の売上を予測する場合、各データセットは一意のアイテム ストアの組み合わせに対応します。

考えられるユース ケース

  • 小売: 食料品店チェーンは、店舗と品目ごとに個別の収益予測モデルを作成する必要があり、店舗ごとに合計 1,000 を超えるモデルを作成する必要があります。

  • サプライ チェーン: 配送会社は、倉庫と製品の組み合わせごとに、在庫を最適化する必要があります。

  • レストラン: 数千のフランチャイズを持つチェーンは、各フランチャイズの需要を予測する必要があります。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Well-Architected Framework」を参照してください。

  • データ パーティション: データをパーティションに分割することは、多くのモデル パターンを実装するために不可欠です。 ストアごとに 1 つのモデルが必要な場合、各データセットには 1 つのストアのすべてのデータが含まれているため、ストアと同じ数のデータセットがあります。 店舗別に製品をモデル化する場合は、製品と店舗の組み合わせごとにデータセットがあります。 ソース データ形式によっては、データのパーティション分割が簡単な場合や、広範なデータのシャッフルや変換が必要になる場合があります。 Spark と Synapse SQL はこれらのタスクに対して適切にスケーリングされますが、Python pandas は単一のノードとプロセスで実行されるため、スケーリングされません。

  • モデル管理: トレーニング パイプラインとスコアリング パイプラインは、各データセットに対して適切なモデルを識別して起動します。 これを行うには、データセットを特徴付けるタグを計算し、タグを使用して一致するモデルを見つけます。 タグは、データ パーティション キーとモデル バージョンを識別し、他の情報を提供することもあります。

  • 適切なアーキテクチャを選択する:

    • Spark は、トレーニング パイプラインに複雑なデータ変換とグループ化の要件がある場合に適しています。 製品の店舗や場所などの特性の組み合わせによってデータをグループ化する柔軟な分割とグループ化の手法を提供します。 結果は、後続の手順で使用するために Spark DataFrame に配置できます。

    • 機械学習のトレーニングアルゴリズムとスコアリング アルゴリズムが単純な場合は、scikit-learn などのライブラリを使用してデータをパーティション分割できる場合があります。 このシナリオでは、Spark が不要な場合があるため、Azure Synapse Analytics または Azure Databricks をインストールするときに発生する可能性のある複雑さを回避できます。

    • トレーニング データセットが既に作成されている場合 (個別のファイルに格納されている場合や、個別の行または列に編成されている場合など)、複雑なデータ変換には Spark は必要ありません。

    • Machine Learning およびコンピューティング クラスター ソリューションは、複雑なセットアップが必要な状況に対して汎用性を提供します。 たとえば、カスタム Docker コンテナーを使用したり、ファイルをダウンロードしたり、事前トレーニング済みモデルをダウンロードしたりできます。 コンピューター ビジョンと自然言語処理のディープ ラーニングは、この汎用性を必要とする可能性があるアプリケーションの例です。

  • 個別のモデル リポジトリ: デプロイされたモデルを保護するには、トレーニング パイプラインとテスト パイプラインがアクセスしない独自のリポジトリに格納することを検討してください。

  • ParallelRunStep クラス: Python ParallelRunStep クラス は、多くのモデルのトレーニングと推論を実行するための強力なオプションです。 さまざまな方法でデータをパーティション分割し、パーティションの要素に機械学習スクリプトを並列で適用できます。 他の形式の Machine Learning トレーニングと同様に、Python パッケージ インデックス (PyPI) パッケージにアクセスできるカスタム トレーニング環境、または標準の PyPI 以上を必要とする構成用のより高度なカスタム Docker 環境を指定できます。 選択可能な CPU と GPU は多数存在します。

  • オンライン推論: パイプラインが最初からすべてのモデルを読み込んでキャッシュすると、モデルによってコンテナーのメモリが枯渇する可能性があります。 そのため、待機時間が若干長くなる可能性がある場合でも、run メソッドでモデルをオンデマンドで読み込む必要があります。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

Azure でこのシナリオを実行するためのコストを理解するには、料金計算ツールを使用します。 次のことを想定する必要があります。

  • サービス モデルは、最新の状態を維持するために毎日トレーニングされます。

  • 10,000 の一意の店舗と製品の組み合わせの 4,000 万行を含むデータセットを処理するには、約 30 分必要です。 データセットは、Ls16_v2 インスタンスを使用する 12 台の仮想マシン (VM) でプロビジョニングされたクラスターを使用して、Azure Databricks 上でトレーニングします。 同じデータのセットを使用したバッチ スコアリングでは、約 20 分かかります。

  • 機械学習を使用してリアルタイムの推論をデプロイすることができます。 要求ボリュームに応じて、適切な種類の VM とクラスター サイズを選択します。

  • AKS クラスターは、必要に応じて自動的にスケーリングされ、毎月平均 2 つのアクティブ ノードになります。

ユース ケースでの価格の違いを確認するには、価格計算ツールの変数を、予想されるデータ サイズとサービスの負荷要件に合わせて変更します。 トレーニング データのサイズを拡大または縮小する場合は、Azure Databricks クラスターのサイズを増減させます。 モデルの処理中に同時実行ユーザーを増やすには、AKS クラスターのサイズを増やします。

共同作成者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

プリンシパル作成者:

  • James Nguyen | プリンシパル クラウド ソリューション アーキテクト

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ