この記事では、機械学習とコンピューティング クラスターを使用する多くのモデルのアーキテクチャについて説明します。 複雑なセットアップが必要な状況に対応する大きな多様性を提供します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
データ インジェスト:
- Azure Data Factory は、ソース データベースからデータをプルし、Azure Data Lake Storage にコピーします。
- その後、データは、表形式データセットとして Machine Learning データストアに格納されます。
Model-Training パイプライン:
-
データの準備:
- トレーニング パイプラインはデータストアからデータをプルし、必要に応じてさらに変換します。
- データは、モデルをトレーニングするためのデータセットにグループ化されます。
-
モデルのトレーニング:
- パイプラインは、データ準備中に作成されたすべてのデータセットのモデルをトレーニングします。
-
ParallelRunStep
クラスを使用して、複数のモデルを並列でトレーニングします。 - トレーニング後、パイプラインは、テスト メトリックと共に Machine Learning にモデルを登録します。
-
データの準備:
Model-Promotion パイプライン:
-
モデルの評価:
- 昇格パイプラインは、トレーニング済みのモデルを運用環境に移行する前に評価します。
- DevOps パイプラインでは、ビジネス ロジックを適用して、モデルがデプロイの条件を満たしているかどうかを判断します (たとえば、テスト データの精度が 80%を超えているかどうかの確認など)。
-
登録モデル:
- 昇格パイプラインは、対象となるモデルを運用環境の Machine Learning ワークスペースに登録します。
-
モデルの評価:
モデル Batch-Scoring パイプライン:
-
データの準備:
- バッチ スコアリング パイプラインはデータストアからデータをプルし、必要に応じて各ファイルをさらに変換します。
- データは、スコア付けのためにデータセットにグループ化されます。
- モデルのスコア付け :
- パイプラインでは、
ParallelRunStep
クラスを使用して複数のデータセットを並列にスコア付けします。 - モデル タグを検索して、Machine Learning の各データセットに適したモデルを識別します。
- モデルがダウンロードされ、データセットのスコア付けに使用されます。
-
DataTransferStep
クラスは、結果を Azure Data Lake に書き戻すために使用されます。 - その後、提供のために予測が Azure Data Lake から Synapse SQL に渡されます。
- パイプラインでは、
-
データの準備:
Real-Time スコアリング:
- マネージド オンライン エンドポイントは、リアルタイム スコアリングを提供するために使用されます。
- モデルの数が多いため、事前に読み込まれるのではなく、必要に応じて読み込まれます。
結果:
- 予測: バッチ スコアリング パイプラインでは、予測を Synapse SQL に保存します。
- メトリック: Power BI がモデルの予測に接続し、表示のために結果を取得して集計します。
コンポーネント
Azure Data Factory は、データ移動と変換を調整および自動化するためのデータドリブン ワークフローを作成できるクラウドベースのデータ統合サービスです。 このアーキテクチャでは、Azure Data Factory を使用して、エンタープライズ データとサードパーティのメタデータを Azure Data Lake Storage に取り込みます。
Azure Stream Analytics は、大量の高速ストリーミング データを分析して処理するように設計された、リアルタイム分析および複雑なイベント処理サービスです。 このアーキテクチャでは、Azure Stream Analytics をリアルタイムのデータ処理に使用できる可能性がありますが、ワークフローには明示的に表示されません。
Azure Machine Learning は、モデルをより迅速に構築し、デプロイするためのエンタープライズレベルの機械学習サービスです。 低コード デザイナー、自動 ML (AutoML)、さまざまな IDE をサポートするホスト型 Jupyter Notebook 環境などのツールを、すべてのスキル レベルのユーザーに提供します。 このアーキテクチャでは、Azure Machine Learning を使用して、トレーニング、評価、デプロイ、トレーニング、昇格、スコアリングなどのパイプラインの調整など、機械学習モデルのライフサイクルを管理します。
マネージド オンライン エンドポイント は、リアルタイム スコアリングに使用される Azure Machine Learning の機能です。 このアーキテクチャでは、機械学習モデルをオンデマンドで読み込むことで、ほぼリアルタイムで予測を提供するスケーラブルで安全な方法を提供します。
ParallelRunStep は、並列ジョブを効率的に実行するために使用される Azure Machine Learning パイプラインのコンポーネントです。 これにより、多数のモデルを同時にトレーニングまたはスコア付けするなど、バッチ プロセスのスケーラブルな実行が可能になります。 このアーキテクチャでは、モデル トレーニング パイプラインとバッチ スコアリング パイプラインの両方で
ParallelRunStep
を使用して、複数のデータセットまたはモデルを並列でトレーニングまたはスコア付けし、これらの操作の実行時間を大幅に短縮します。Azure Data Lake Storage は、高パフォーマンスの分析ワークロード用の非常にスケーラブルで安全なストレージ サービスです。 このアーキテクチャでは、Azure Data Lake Storage は、未加工のデータセットと変換されたデータセットのプライマリ ストレージ レイヤーとして機能し、スコアリング パイプラインからの結果を格納するためにも機能します。
Azure Synapse Analytics は、データ統合、エンタープライズ データ ウェアハウジング、ビッグ データ分析を統合した分析サービスです。 このアーキテクチャでは、バッチ スコアリングの結果を格納するために使用され、レポートまたは分析のための予測の効率的なクエリと取得が可能になります。 Synapse SQL は、ダウンストリーム アプリケーションに予測を提供し、Power BI などの視覚化ツールが集計された結果にアクセスできるようにするために特に使用されます。
Azure SQL Database は、サービスとしてのフル マネージド リレーショナル データベースです。 このアーキテクチャでは、Azure SQL Database を使用して、データ パイプラインの一部としてクエリまたは分析できる構造化データを格納します。
Azure DevOps は、アプリケーションとインフラストラクチャの包括的なライフサイクル管理を提供する一連の開発者サービスです。 これには、作業の追跡、ソース管理、ビルドと CI/CD、パッケージ管理、およびテスト ソリューション用のツールが含まれています。 このアーキテクチャでは、Azure DevOps を使用して、モデルの昇格、テスト、運用環境へのデプロイを自動化するための CI/CD パイプラインを管理します。
Microsoft Power BI はソフトウェア サービス、アプリ、コネクタのコレクションであり、これらが連携して、関連のないデータ ソースを、一貫性があり視覚的に没入型で対話形式の分析情報に変換します。 このアーキテクチャでは、Power BI は Synapse SQL に接続して、対話型ダッシュボードを使用して予測と集計メトリックを取得して提示します。
代替
- ソース データは、任意のデータベースから取得できます。
- マネージド オンライン エンドポイントではなく、リアルタイム推論に Azure Kubernetes Service (AKS) を使用できます。 AKS を使用すると、コンテナー化されたモデルをデプロイでき、デプロイをより詳細に制御できるため、リソースを使い果たすことなく、受信要求を処理するモデルの動的読み込みが可能になります。
シナリオの詳細
機械学習の問題の多くは、単一の機械学習モデルで解決するには複雑すぎます。 すべての店舗のすべてのアイテムの売上を予測する場合でも、何百もの油田のメンテナンスをモデル化する場合でも、各インスタンスのモデルを使用すると、多数の機械学習に関する問題の結果が改善される可能性があります。 この "多数モデル" のパターンは、さまざまな業界で共通しており、現実に多くのユース ケースがあります。 Azure Machine Learning を使用すると、エンドツーエンドの多くのモデルのパイプラインに、モデル トレーニング、バッチ推論デプロイ、リアルタイム デプロイを含めることができます。
多くのモデル ソリューションでは、トレーニングとスコアリング中にモデルごとに異なるデータセットが必要です。 たとえば、すべての店舗のすべてのアイテムの売上を予測するタスクの場合、それぞれのデータセットはアイテムと店舗の一意の組み合わせに対応します。
考えられるユース ケース
- 小売り: 食料品店チェーンでは、店舗と商品ごとに個別の収益予測モデルを作成する必要があり、店舗ごとに合計 1,000 個を超えるモデルがあります。
- サプライ チェーン: 配送会社は、倉庫と製品の組み合わせごとに、在庫を最適化する必要があります。
- レストラン: 何千ものフランチャイズ店があるチェーンでは、それぞれの需要を予測する必要があります。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
- データ パーティション:データのパーティション分割は、多くのモデル パターンを実装するための鍵です。 店舗ごとに 1 つのモデルが必要な場合、データセットは 1 つの店舗のすべてのデータで構成され、店舗と同じ数のデータセットがあります。 店舗別に製品をモデル化したい場合は、製品と店舗の組み合わせごとにデータセットがあります。 ソース データ形式によっては、データのパーティション分割が簡単な場合や、広範なデータのシャッフルや変換が必要になる場合があります。 Spark と Synapse SQL は、このようなタスクに対して非常に適切にスケーリングできますが、Python pandas は、1 つのノードとプロセスでのみ実行されるため、適していません。
- モデル管理: トレーニング パイプラインとスコアリング パイプラインは、各データセットに対して適切なモデルを識別して起動します。 これを行うには、データセットを特徴付けるタグを計算し、タグを使用して一致するモデルを検索します。 タグは、データ パーティション キーとモデル バージョンを識別し、他の情報を提供することもあります。
-
適切なアーキテクチャの選択:
- Spark は、トレーニング パイプラインに複雑なデータ変換とグループ化の要件がある場合に適しています。 製品の店舗や場所などの特性の組み合わせによってデータをグループ化する柔軟な分割とグループ化の手法を提供します。 結果は、後続の手順で使用するために Spark DataFrame に配置できます。
- 機械学習のトレーニングとスコアリングのアルゴリズムが単純な場合は、Scikit-learn などのライブラリを使用してデータをパーティション分割できる場合があります。 このような場合は、Spark を必要としない場合があり、Azure Synapse または Azure Databricks をインストールするときに発生する可能性のある複雑さを回避できます。
- トレーニング データセットが既に作成されている場合 (たとえば、個別のファイルまたは個別の行や列に含まれている場合)、複雑なデータ変換のために Spark は必要ありません。
- 機械学習とコンピューティング クラスター ソリューションは、複雑なセットアップが必要な状況に対して大きな多様性を提供します。 たとえば、カスタム Docker コンテナーの使用、ファイルのダウンロード、または事前トレーニング済みのモデルのダウンロードを行うことができます。 コンピューター ビジョンと自然言語処理 (NLP) ディープ ラーニングは、このような多様性を必要とするアプリケーションの例です。
- 個別のモデル リポジトリ: デプロイされたモデルを保護するために、トレーニング パイプラインとテスト パイプラインが接続できない専用のリポジトリにモデルを格納することを検討してください。
- ParallelRunStep クラス: Python ParallelRunStep クラスは、多くのモデルのトレーニングと推論を実行するための強力なオプションです。 さまざまな方法でデータをパーティション分割し、パーティションの要素に機械学習スクリプトを並列で適用できます。 他の形式の機械学習トレーニングと同様に、Python Package Index (PyPI) パッケージにアクセスできるカスタム トレーニング環境を指定するか、または標準の PyPI 以外のものも必要とする構成用のより高度なカスタム Docker 環境を指定できます。 選択可能な CPU と GPU は多数存在します。
- オンライン推論: パイプラインが最初にすべてのモデルを読み込んでキャッシュする場合、モデルのためにコンテナーのメモリが使い果たされる可能性があります。 そのため、待機時間が若干長くなる可能性がある場合でも、run メソッドでモデルをオンデマンドで読み込む必要があります。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
Azure でのこのシナリオの実行コストを詳しく知るには、料金計算ツールを使用します。 最初は次の前提で検討することをお勧めします。
- サービス モデルは、最新の状態を維持するために毎日トレーニングされます。
- 店舗と製品の組み合わせが 10,000 の 4,000 万行のデータセットの場合、Ls16_v2 インスタンスを使用する 12 の VM がプロビジョニングされたクラスターを使用して Azure Databricks でトレーニングするには、約 30 分かかります。
- 同じデータのセットを使用したバッチ スコアリングでは、約 20 分かかります。
- 機械学習を使用してリアルタイムの推論をデプロイすることができます。 要求ボリュームに応じて、適切な VM の種類とクラスター サイズを選択してください。
- AKS クラスターは必要に応じて自動スケーリングし、その結果平均して 1 か月あたり 2 個のノードがアクティブになります。
自分のユース ケースでは価格がどのように違うかを確認するには、自分の予想されるデータ サイズとサービス負荷の要件に合わせて変数を変更します。 トレーニング データのサイズを拡大または縮小する場合は、Azure Databricks クラスターのサイズを増減させます。 モデルの処理中に同時実行ユーザーを増やすには、AKS クラスターのサイズを増やします。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- James Nguyen | プリンシパル クラウド ソリューション アーキテクト
次のステップ
- Azure Machine Learning のための Kubernetes クラスターを構成する
- 多くのモデル ソリューション アクセラレータ GitHub リポジトリ
- ParallelRunStep Class
- DataTransferStep Class
- Azure のストレージ サービスに接続する
- Azure Synapse Analytics とは
- Azure Kubernetes Service クラスターにモデルをデプロイする