ソリューションのアイデア
この記事ではソリューションのアイデアについて説明します。 クラウド アーキテクトはこのガイダンスを使用すると、このアーキテクチャの一般的な実装の主要コンポーネントを視覚化しやすくなります。 ワークロードの特定の要件に適合する、適切に設計されたソリューションを設計するための出発点として、この記事を使用してください。
この記事では、Azure Databricks を使用する 機械学習操作 (MLOps) のアーキテクチャとプロセスについて説明します。 データ サイエンティストとエンジニアは、この標準化されたプロセスを使用して、機械学習モデルとパイプラインを開発から運用に移行できます。
このソリューションでは、完全な自動化、継続的な監視、堅牢なコラボレーションを利用できるため、レベル 4 の MLOps 成熟度を目標とします。 このアーキテクチャでは、promote モデルアプローチではなく、モデルアプローチを生成するコードを使用します。 モデルを生成する コード アプローチでは、機械学習モデルを生成するコードの記述と管理に重点を置いています。 この記事の推奨事項には、自動化されたプロセスまたは手動プロセスのオプションが含まれています。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
次のワークフローは、上の図に対応しています。 ソース管理コンポーネントとストレージ コンポーネントを使用して、コードとデータを管理および整理します。
ソース管理: このプロジェクトのコード リポジトリは、ノートブック、モジュール、パイプラインを整理します。 開発ブランチを作成して、更新プログラムと新しいモデルをテストできます。 Git でサポートされているノートブックまたは統合開発環境 (IDE) でコードを開発し、 Git フォルダーと統合 Azure Databricks ワークスペースと同期できるようにします。 ソース管理は、開発環境から、ステージング環境でのテスト、運用環境でのデプロイまで、機械学習パイプラインを昇格させます。
Lakehouse の運用データ: データ サイエンティストとして、開発環境の運用データに読み取り専用でアクセスできます。 開発環境では、ミラー化されたデータと編集された機密データを含めることができます。 また、開発と実験のために、開発ストレージ環境で読み取りと書き込みのアクセス権を持っています。 Lakehouse アーキテクチャを使用して、Delta Lake 形式のデータを Azure Data Lake Storage に格納することをお勧めします。 Lakehouse は、データ管理のための堅牢でスケーラブルで柔軟なソリューションを提供します。 アクセス制御を定義するには、 Microsoft Entra ID 資格情報パススルー または テーブル アクセス制御を使用します。
次の環境が主要なワークフローを構成します。
開発
開発環境では、機械学習パイプラインを開発します。
探索的データ分析 (EDA) の実行: 対話型の反復プロセスでデータを探索します。 この作業をステージングまたは運用環境にデプロイしない場合があります。 Databricks SQL、dbutils.data.summarize コマンド、Databricks AutoML などのツールを使用します。
モデル トレーニングおよびその他の機械学習パイプラインを開発する: 機械学習パイプラインのモジュールコードを開発し、Databricks Notebook または MLFlow プロジェクトを使用してコードを調整します。 このアーキテクチャでは、モデル トレーニング パイプラインは、フィーチャ ストアやその他の Lakehouse テーブルからデータを読み取ります。 パイプラインは、ログ モデルのパラメーターとメトリックをトレーニングし、 MLflow 追跡サーバーにチューニングします。 feature ストア APIは最終的なモデルをログに記録します。 これらのログには、モデル、その入力、トレーニング コードが含まれます。
コードのコミット: 機械学習ワークフローを運用環境に昇格するには、特徴量化、トレーニング、およびその他のパイプラインのコードをソース管理にコミットします。 コード ベースでは、チーム メンバーが同時にコードを開発できるように、機械学習コードと運用コードを異なるフォルダーに配置します。 機械学習コードは、モデルとデータに関連するコードです。 運用コードは、Databricks のジョブとインフラストラクチャに関連するコードです。
コードを記述してテストするときに実行するアクティビティのこのコア サイクルは、 innerloop プロセスと呼ばれます。 開発フェーズの innerloop プロセスを実行するには、開発コンテナー CLI と Databricks CLI と組み合わせて Visual Studio Code を使用します。 コードを記述し、ローカルで単体テストを行うことができます。 また、ローカル開発環境からモデル パイプラインを送信、監視、分析する必要もあります。
ステージング
ステージング環境では、継続的インテグレーション (CI) インフラストラクチャは、運用環境を模倣する環境で機械学習パイプラインへの変更をテストします。
要求のマージ: ソース管理のプロジェクトのステージング (メイン) ブランチに対してマージ要求またはプル要求を送信すると、継続的インテグレーションと継続的デリバリー (CI/CD) ツール ( Azure DevOps がテストを実行します。
単体テストと CI テストの実行: 単体テストは CI インフラストラクチャで実行され、統合テストは Azure Databricks 上のエンドツーエンドの ワークフロー で実行されます。 テストに合格すると、コードはマージに変更されます。
リリース ブランチの構築: 更新された機械学習パイプラインを運用環境にデプロイする場合は、新しいリリースをビルドできます。 CI/CD ツールのデプロイ パイプラインは、更新されたパイプラインを新しい ワークフローとして再デプロイします。
Production
機械学習エンジニアは、機械学習パイプラインがエンド アプリケーションに直接対応する運用環境を管理します。 運用の主要なパイプラインは機能テーブルの更新、新しいモデルのトレーニングとデプロイ、推論またはサービスの実行、モデルのパフォーマンスの監視を行います。
機能テーブルの更新: このパイプラインは、データを読み取り、特徴を計算し、 機能ストア テーブルに書き込みます。 このパイプラインは、ストリーミング モードで継続的に実行するか、スケジュールに従って実行するか、トリガーで実行するように構成できます。
モデル トレーニング: 運用環境では、最新の運用データで新しいモデルをトレーニングするために、トリガーまたはスケジュールで実行するようにモデル トレーニングまたは再トレーニング パイプラインを構成できます。 モデルは自動的に Unity カタログに登録されます。
モデルの評価と昇格: 新しいモデル バージョンが登録されると、CD パイプラインがトリガーされ、テストが実行され、運用環境でモデルが適切に動作することを確認します。 モデルがテストに合格すると、Unity カタログはモデル ステージの遷移を使用してその進行状況を追跡します。 テストには、コンプライアンス チェック、新しいモデルと現在の運用モデルを比較する A/B テスト、インフラストラクチャ テストが含まれます。 Lakehouse テーブルには、テスト結果とメトリックが記録されます。 必要に応じて、モデルが運用環境に移行する前に手動によるサインオフを要求できます。
モデルのデプロイ: モデルが運用環境に入ると、スコア付けまたは提供のためにデプロイされます。 最も一般的な展開モードは次のとおりです。
バッチまたはストリーミング スコアリング: 待機時間が分以上の場合は、 バッチとストリーミング が最もコスト効率の高いオプションです。 スコアリング パイプラインは、機能ストアから最新のデータを読み取り、Unity カタログから最新の実稼働モデル バージョンを読み込み、Databricks ジョブで推論を実行します。 予測は、lakehouse テーブル、Java Database Connectivity (JDBC) 接続、フラット ファイル、メッセージ キュー、またはその他のダウンストリーム システムに発行できます。
オンライン サービス (REST API): 待機時間の短いユース ケースでは、一般的にオンライン サービスが必要です。 MLflow では、モデルを Mosaic AI Model Serving、クラウド プロバイダー サービス システム、およびその他のシステムにデプロイできます。 いずれの場合も、サービス システムは Unity カタログの最新の実稼働モデルを使用して初期化します。 要求ごとに、オンライン機能ストアから特徴をフェッチし、予測を行います。
監視: 継続的または定期的な ワークフロー は、誤差、パフォーマンス、およびその他のメトリックの入力データとモデル予測を監視します。 Delta Live Tables フレームワークを使用して、パイプラインの監視を自動化し、メトリックを lakehouse テーブルに格納できます。 Databricks SQL、 Power BI、およびその他のツールは、これらのテーブルから読み取ってダッシュボードとアラートを作成できます。 アプリケーションメトリック、ログ、インフラストラクチャを監視するために、Azure Monitor と Azure Databricks を統合することもできます。
ドリフト検出とモデルの再トレーニング: このアーキテクチャでは、手動と自動の両方の再トレーニングがサポートされています。 モデルを最新の状態に保つために、再トレーニング ジョブをスケジュールします。 検出されたドリフトが監視手順で設定した構成済みのしきい値を超えた後、再トレーニング パイプラインはドリフトを分析し、再トレーニングをトリガーします。 パイプラインを自動的にトリガーするように構成することも、通知を受信してパイプラインを手動で実行することもできます。
コンポーネント
data lakehouse アーキテクチャは、データ レイクとデータ ウェアハウスの要素を統合します。 Lakehouse を使用して、通常はデータ ウェアハウスに存在するが、データ レイクが提供する低コストで柔軟なオブジェクト ストアを備えたデータ管理機能とパフォーマンス機能を取得します。
- Delta Lake は、レイクハウスに推奨されるオープン ソース データ形式です。 Azure Databricks は Data Lake Storage にデータを格納し、高パフォーマンスのクエリ エンジンを提供します。
MLflow は、エンド ツー エンドの機械学習ライフサイクルを管理するためのオープンソース プラットフォームです。 MLflow には、次のコンポーネントがあります。
追跡機能は実験を追跡するため、パラメーター、メトリック、モデル成果物を記録して比較できます。
- Databricks の自動ログ記録MLflow 自動ログ記録を拡張して機械学習の実験を追跡し、モデル パラメーター、メトリック、ファイル、系列情報を自動的にログに記録します。
MLflow モデル は、任意の機械学習ライブラリからさまざまなモデルサービスおよび推論プラットフォームにモデルを格納およびデプロイするために使用できる形式です。
Unity Catalog は、Azure Databricks ワークスペース全体で一元化されたアクセス制御、監査、系列、およびデータ検出機能を提供します。
Mosaic AI Model Serving は、MLflow モデルを REST エンドポイントとしてホストします。
Azure Databricks は、エンタープライズ セキュリティ機能、高可用性、および他の Azure Databricks ワークスペース機能との統合を備えたマネージド MLflow サービスを提供します。
Databricks Runtime for Machine Learning では、機械学習用に最適化されたクラスターの作成が自動化され、TensorFlow、PyTorch、XGBoost などの一般的な機械学習ライブラリがプレインストールされます。 また、AutoML や機能ストア クライアントなどの Machine Learning ツール用の Azure Databricks もプレインストールされます。
機能ストアは、機能の一元化されたリポジトリです。 特徴ストアを使用して特徴を検出して共有し、モデルのトレーニングと推論の間のデータ スキューを防ぎます。
Databricks SQL はさまざまなツールと統合されているため、新しいプラットフォームに調整することなく、お気に入りの環境でクエリやダッシュボードを作成できます。
Git フォルダー は、Azure Databricks ワークスペース内の Git プロバイダーとの統合を提供し、ノートブックまたはコードのコラボレーションと IDE の統合を向上させます。
Workflows と ジョブ は、Azure Databricks クラスターで非対話型コードを実行する方法です。 機械学習の場合、ジョブはデータの準備、特徴付け、トレーニング、推論、監視を自動化します。
代替
このソリューションは、Azure インフラストラクチャに合わせて調整できます。 次のカスタマイズを検討してください。
共通の運用ワークスペースを共有する複数の開発ワークスペースを使用します。
既存のインフラストラクチャに対して 1 つ以上のアーキテクチャ コンポーネントを交換します。 たとえば、 Azure Data Factory を使用して Databricks ジョブを調整できます。
Git および Azure Databricks REST API を使用して、既存の CI/CD ツールと統合します。
機械学習機能の代替サービスとして、 Microsoft Fabric または Azure Synapse Analytics を使用します。
シナリオの詳細
このソリューションでは、Azure Databricks を使用した堅牢な MLOps プロセスが提供されます。 アーキテクチャ内のすべての要素を置き換えることができるため、必要に応じて他の Azure サービスとパートナー サービスを統合できます。 このアーキテクチャと説明は、電子書籍「MLOps のビッグ ブック」から適応されています。 電子書籍では、このアーキテクチャについて詳しく説明しています。
MLOps は、機械学習と AI システムの障害のリスクを軽減し、コラボレーションとツールの効率を向上するのに役立ちます。 MLOps の概要とこのアーキテクチャの概要については、lakehouse の Architect MLOps を参照してください。
このアーキテクチャを使用して、次の操作を行います。
ビジネス関係者を機械学習とデータ サイエンス チームに接続します。 このアーキテクチャを使用して、開発用のノートブックと IDE を組み込みます。 ビジネス関係者は、Databricks SQL のメトリックとダッシュボードを、すべて同じ Lakehouse アーキテクチャ内で表示できます。
機械学習インフラストラクチャをデータ中心にする。 このアーキテクチャでは、機械学習データが他のデータと同様に扱われます。 機械学習データには、特徴エンジニアリング、トレーニング、推論、監視のデータが含まれます。 このアーキテクチャでは、機械学習データ処理のために、運用パイプライン、ダッシュボード、およびその他の一般的なデータ処理用のツールが再利用されます。
モジュールとパイプラインに MLOps を実装します。 他のソフトウェア アプリケーションと同様に、このアーキテクチャのモジュール化されたパイプラインとコードを使用して、個々のコンポーネントをテストし、将来のリファクタリングのコストを削減します。
必要に応じて MLOps プロセスを自動化します。 このアーキテクチャでは、生産性を向上させ、人的エラーのリスクを軽減するための手順を自動化できますが、すべての手順を自動化する必要はありません。 Azure Databricks では、自動化のための API に加えて、UI と手動プロセスが許可されます。
考えられるユース ケース
このアーキテクチャは、あらゆる種類の機械学習、ディープ ラーニング、高度な分析に適用されます。 このアーキテクチャの一般的な機械学習と AI 手法は次のとおりです。
- 線形モデル、ツリー ベースのモデル、ブースティングなどの従来の機械学習。
- TensorFlow や PyTorch などの最新のディープ ラーニング。
- 統計、ベイジアン メソッド、グラフ分析などのカスタム分析。
このアーキテクチャでは、小さなデータ (単一コンピューター) と大きなデータ (分散コンピューティングと GPU アクセラレータ) の両方がサポートされています。 アーキテクチャの各ステージでは、シナリオのデータと問題のディメンションに合わせてコンピューティング リソースとライブラリを選択できます。
このアーキテクチャは、あらゆる種類の業界およびビジネス ユース ケースに適用されます。 このアーキテクチャを使用する Azure Databricks のお客様には、次の業界の小規模および大規模な組織が含まれます。
- 消費財・小売サービス
- 金融サービス
- 医療とライフ サイエンス
- 情報技術
例については、 Databricks のお客様を参照してください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Brandon Cowen | シニア クラウド ソリューション アーキテクト
- プラバルデブ |プリンシパル ソフトウェア エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。