編集

Azure Databricks を使用して MLOps を調整する

Azure Databricks

ソリューションのアイデア

このアーティクルはソリューションのアイデアです。 このコンテンツにさらに多くの情報 (想定されるユース ケース、代替サービス、実装に関する考慮事項、価格ガイダンスなど) の掲載をご希望の方は、GitHub のフィードバックでお知らせください。

この記事では、Azure Databricks を使用する 機械学習操作 (MLOps) のアーキテクチャとプロセスについて説明します。 このプロセスでは、機械学習モデルとパイプラインを開発から運用環境に移動する標準化された方法を定義し、自動化された手動プロセスを含めるオプションを提供します。

アーキテクチャ

Diagram that shows a solution for using Azure Databricks for MLOps.

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

ワークフロー

このソリューションでは、Azure Databricks を使用した堅牢な MLOps プロセスが提供されます。 アーキテクチャ内のすべての要素はプラグ可能であるため、必要に応じて、アーキテクチャ全体で他の Azure とサードパーティのサービスを統合できます。 このアーキテクチャと説明は、電子書籍「MLOps のビッグ ブック」から適応されています。 この電子書籍では、ここで説明するアーキテクチャについて詳しく説明します。

  • ソース管理: このプロジェクトのコード リポジトリは、ノートブック、モジュール、パイプラインを整理します。 データ サイエンティストは、更新プログラムと新しいモデルをテストするための開発ブランチを作成します。 コードは、Azure Databricks ワークスペースと同期するための Databricks Repos 統合を使用して、Git によってサポートされるノートブックまたは IDE で開発されます。 ソース管理は、開発からステージング (テスト用)、運用環境 (デプロイ用) まで、機械学習パイプラインを昇格させます。

  • Lakehouse - 運用データ: データ サイエンティストは開発環境で作業し、運用環境のデータへの読み取り専用アクセス権を持ちます。 (または、データをミラー化または編集できます)。また、開発と実験のために、開発ストレージ環境への読み取り/書き込みアクセス権も持ちます。 データが Delta Lake 形式で Azure Data Lake Storage に格納されるデータには、Lakehouse アーキテクチャをお勧めします。 アクセス制御は、Microsoft Entra 資格情報パススルーまたはテーブル アクセス制御で定義されます。

開発

開発環境では、データ サイエンティストとエンジニアが機械学習パイプラインを開発します。

  1. 探索的データ分析 (EDA): データ サイエンティストは、対話型の反復的なプロセスでデータを探索します。 このアドホック作業は、ステージングまたは運用環境にデプロイされない可能性があります。 ツールには、Databricks SQL、dbutils.data.summarize、AutoML が含まれる場合があります。

  2. モデル トレーニングとその他の機械学習パイプライン: 機械学習パイプラインは、ノートブックや IDE のモジュール コードとして開発されます。 たとえば、モデル トレーニング パイプラインは、Feature Store やその他の Lakehouse テーブルからデータを読み取ります。 MLflow 追跡サーバーに対するログ モデルのパラメーターとメトリックのトレーニングとチューニング。 Feature Store API では、最終的なモデルがログに記録されます。 これらのログは、モデル、その入力、およびトレーニング コードをリンクします。

  3. コードのコミット: 機械学習ワークフローを運用環境に昇格させるために、データ サイエンティストは特徴付け、トレーニング、およびその他のパイプラインのコードをソース管理にコミットします。

ステージング

ステージング環境では、CI インフラストラクチャは、運用環境を模倣する環境で機械学習パイプラインへの変更をテストします。

  1. マージ要求: ソース管理のプロジェクトのステージング (メイン) ブランチに対してマージ (またはプル) 要求が送信されると、Azure DevOps などの継続的インテグレーションおよび継続的デリバリー (CI/CD) ツールによってテストが実行されます。

  2. 単体テストと CI テスト: 単体テストは CI インフラストラクチャで実行され、統合テストでは Azure Databricks でエンドツーエンドのワークフローが実行されます。 テストに合格すると、コードはマージに変更されます。

  3. リリース ブランチを構築する: 機械学習エンジニアは、更新された機械学習パイプラインを運用環境にデプロイする準備ができたら、新しいリリースをビルドできます。 CI/CD ツールのデプロイ パイプラインは、更新されたパイプラインを新しいワークフローとして再デプロイします。

Production

機械学習エンジニアは、機械学習パイプラインがエンド アプリケーションに直接対応する運用環境を管理します。 運用の主要なパイプラインは機能テーブルの更新、新しいモデルのトレーニングとデプロイ、推論またはサービスの実行、モデルのパフォーマンスの監視を行います。

  1. 特徴テーブルの更新: このパイプラインは、データを読み取り、特徴を計算し、Feature Store テーブルに書き込みます。 ストリーミング モードで継続的に実行されるか、スケジュールに従って実行されるか、トリガーされます。

  2. モデル トレーニング: 運用環境では、モデル トレーニングまたは再トレーニング パイプラインがトリガーされるか、最新の実稼働データで新しいモデルをトレーニングするようにスケジュールされます。 モデルは MLflow モデル レジストリに登録されます。

  3. 継続的デプロイ: 新しいモデル バージョンを登録すると、CD パイプラインがトリガーされます。これにより、テストが実行され、モデルが運用環境で適切に動作することが確認されます。 モデルがテストに合格すると、その進行状況はモデル ステージの遷移を介してモデル レジストリで追跡されます。 レジストリ Webhook は自動化に使用できます。 テストには、コンプライアンス チェック、新しいモデルと現在の運用モデルを比較する A/B テスト、インフラストラクチャ テストを含めることができます。 テスト結果とメトリックは、Lakehouse テーブルに記録されます。 必要に応じて、モデルを運用環境に移行する前に手動のサインオフを要求できます。

  4. モデル デプロイ: モデルが運用環境に入ると、スコア付けまたは提供のためにデプロイされます。 以下は最も一般的なデプロイ モデルです。

    • バッチまたはストリーミング スコアリング: 数分以上の待機時間では、バッチとストリーミングが最もコスト効率の高いオプションです。 スコアリング パイプラインは、フィーチャー ストアから最新のデータを読み取り、モデル レジストリから最新の実稼働モデル バージョンを読み込み、Databricks ジョブで推論を実行します。 Lakehouse テーブル、Java Database Connectivity (JDBC) 接続、フラット ファイル、メッセージ キュー、またはその他のダウンストリーム システムに予測を発行できます。
    • オンライン サービス (REST API): 待機時間の短いユース ケースでは、一般にオンライン サービスが必要です。 MLflow は、Azure Databricks での MLflow モデル提供、クラウド プロバイダー サービス システム、およびその他のシステムにモデルをデプロイできます。 いずれの場合も、サービス システムはモデル レジストリの最新の運用モデルで初期化されます。 要求ごとに、オンライン Feature Store から特徴をフェッチし、データをスコア付けし、予測を返します。

  5. 監視: 継続的または定期的なワークフローは、誤差、パフォーマンス、およびその他のメトリックの入力データとモデル予測を監視します。 Delta Live Tables を使用すると、監視パイプラインの自動化を簡素化し、メトリックを Lakehouse テーブルに格納できます。 Databricks SQL、Power BI、およびその他のツールは、これらのテーブルから読み取ってダッシュボードとアラートを作成できます。

  6. 再トレーニング: このアーキテクチャでは、手動再トレーニングと自動再トレーニングの両方がサポートされています。 スケジュールされた再トレーニング ジョブは、モデルを最新の状態に保つ最も簡単な方法です。

Components

  • Data Lakehouse。 Lakehouse アーキテクチャは、データ レイクとデータ ウェアハウスの最適な要素を統合し、データ ウェアハウスで一般的に見られるデータ管理とパフォーマンスを、データ レイクによって提供される低コストの柔軟なオブジェクト ストアと共に提供します。
    • Delta Lake は、レイクハウスのオープン ソース データ形式に推奨される選択肢です。 Azure Databricks は Data Lake Storage にデータを格納し、高パフォーマンスのクエリ エンジンを提供します。
  • MLflow は、エンド ツー エンドの機械学習ライフサイクルを管理するためのオープンソース プラットフォームです。 主なコンポーネントは次のとおりです。
    • 追跡では、実験を追跡し、パラメーター、メトリック、モデル成果物を記録および比較できます。
    • MLFlow モデルを使用すると、任意の機械学習ライブラリからさまざまなモデル サービスおよび推論プラットフォームに、モデルを格納およびデプロイできます。
    • モデル レジストリは、開発から運用へのモデル ライフサイクル ステージの移行を管理するための一元化されたモデル ストアを提供します。
    • モデルの提供では、MLflow モデルを REST エンドポイントとしてホストできます。
  • Azure Databricks。 Azure Databricks は、エンタープライズ セキュリティ機能、高可用性、および Azure Databricks の他のワークスペース機能との統合を備えたマネージド MLflow サービスを提供します。
    • Databricks Runtime for Machine Learning では、機械学習用に最適化されたクラスターの作成が自動化され、TensorFlow、PyTorch、XGBoost などの一般的な機械学習ライブラリが、AutoML や Feature Store クライアントなどの Machine Learning ツール用の Azure Databricks に加えてプレインストールされます。
    • Feature Store は、一元化された特徴リポジトリです。 これにより、機能の共有と検出が可能になり、モデルのトレーニングと推論の間のデータ スキューを回避するのに役立ちます。
    • Databricks SQL。 Databricks SQL は、Lakehouse データに対する SQL クエリと、視覚化、ダッシュボード、アラートに対する簡単なエクスペリエンスを提供します。
    • Databricks Repos は、Azure Databricks ワークスペース内の Git プロバイダーとの統合を提供し、ノートブックまたはコードの共同開発と IDE 統合を簡素化します。
    • Workflows とジョブは、Azure Databricks クラスターで非対話型コードを実行する方法です。 機械学習の場合、ジョブはデータの準備、特徴付け、トレーニング、推論、監視を自動化します。

代替

このソリューションは、Azure インフラストラクチャに合わせて調整できます。 一般的なカスタマイズには以下が含まれます。

  • 共通の運用ワークスペースを共有する複数の開発ワークスペース。
  • 既存のインフラストラクチャに対する 1 つ以上のアーキテクチャ コンポーネントの交換。 たとえば、Azure Data Factory を使用して Databricks ジョブを調整できます。
  • Git および Azure Databricks REST API を使用した既存の CI/CD ツールとの統合。

シナリオの詳細

MLOps は、機械学習と AI システムの障害のリスクを軽減し、コラボレーションとツールの効率を向上させるのに役立ちます。 MLOps の概要とこのアーキテクチャの概要については、Lakehouse での MLOps の設計に関するページを参照してください。

このアーキテクチャを使用すると、次の操作が可能になります。

  • ビジネス関係者を機械学習とデータ サイエンス チームに接続します。 このアーキテクチャにより、データ サイエンティストは開発にノートブックと IDE を使用できます。 これにより、ビジネス関係者は Databricks SQL のメトリックとダッシュボードをすべて同じ Lakehouse アーキテクチャ内で表示できます。
  • 機械学習インフラストラクチャをデータ中心にする。 このアーキテクチャでは、機械学習データ (特徴エンジニアリング、トレーニング、推論、監視からのデータ) は、他のデータと同様に扱われます。 これは、機械学習データ処理のために、運用パイプライン、ダッシュボード、およびその他の一般的なデータ処理用のツールを再利用します。
  • モジュールとパイプラインに MLOps を実装します。 他のソフトウェア アプリケーションと同様に、このアーキテクチャのモジュール化されたパイプラインとコードにより、個々のコンポーネントのテストが可能になり、将来のリファクタリングのコストが削減されます。
  • 必要に応じて MLOps プロセスを自動化します。 このアーキテクチャでは、生産性を向上させ、人的エラーのリスクを軽減するための手順を自動化できますが、すべてのステップを自動化する必要はありません。 Azure Databricks では、自動化のための API に加えて、UI と手動プロセスが許可されます。

考えられるユース ケース

このアーキテクチャは、あらゆる種類の機械学習、ディープ ラーニング、高度な分析に適用されます。 このアーキテクチャで使用される一般的な機械学習/AI 手法は次のとおりです。

  • 線形モデル、ツリー ベースのモデル、ブースティングなどの従来の機械学習。
  • TensorFlow や PyTorch などの最新のディープ ラーニング。
  • 統計、ベイジアン メソッド、グラフ分析などのカスタム分析。

このアーキテクチャでは、小さなデータ (単一コンピューター) と大きなデータ (分散コンピューティングと GPU アクセラレータ) の両方がサポートされています。 アーキテクチャの各段階で、コンピューティング リソースとライブラリを選択して、データと問題のディメンションに適応させることができます。

このアーキテクチャは、あらゆる種類の業界およびビジネス ユース ケースに適用されます。 このアーキテクチャと同様のアーキテクチャを使用している Azure Databricks のお客様には、次のような業界の小規模および大規模な組織が含まれます。

  • 消費財・小売サービス
  • 金融サービス
  • 医療とライフ サイエンス
  • 情報技術

例については、Databricks Web サイトを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Brandon Cowen | シニア クラウド ソリューション アーキテクト

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ