レイクハウスにおけるMLOpsのアーキテクチャ設計

Databricksでは、これまでに数千社のお客様がMachine Learning (ML)を本番環境に導入するのを支援してきました。Shell社は、160以上の有効なAIプロジェクトを稼働させ、数百万ドルを削減しています。Comcast社は、MLflowを活用して数百もの機械学習モデルを容易に管理しています。そして、その他多くの企業が、MLを活用したソリューションの構築に成功しています。

Databricksを採用する前、多くのお客様がMLの本番環境への導入に苦労されていました。それにはもっともな理由があります。Machine Learning Operations (MLOps)の実現は容易ではないからです。MLOpsでは、本番環境への移行プロセスにおいて、コード（DevOps）、データ（DataOps）、モデル（ModelOps）を共同で管理する必要があります。私たちが目にしてきた最も一般的で深刻な課題は、データとMLの間のギャップです。これらは、連携の不十分なツールやチーム間で分断されていることが少なくありません。

この課題を解決するため、Databricks Machine Learningはレイクハウスアーキテクチャを基盤とし、その主なメリットである「シンプルさ」と「オープンさ」をMLOpsへと拡張しています。

当社のプラットフォームは、DevOps、DataOps、ModelOpsのベストプラクティスを統合したデータ中心のワークフローを定義することで、MLをシンプルにします。機械学習パイプラインは、本質的にはデータパイプラインであり、データは複数のペルソナの手を経て流れていきます。データエンジニアがデータを取り込んで準備し、データサイエンティストがデータからモデルを構築し、MLエンジニアがモデルのメトリクスを監視し、ビジネスアナリストが予測を検証します。Databricksは、これらのデータチームがサイロ化されることなく、単一のプラットフォーム上でコラボレーションし、この膨大なデータを管理できるようにすることで、本番環境での機械学習をシンプルにします。例えば、当社のFeature Storeを使用すると、モデルと特徴量を共同で本番環境に導入できます。データサイエンティストは必要な特徴量を「認識」したモデルを作成できるため、MLエンジニアはよりシンプルなプロセスでモデルをデプロイできます。

MLOpsに対するDatabricksのアプローチは、業界全体のオープンな標準に基づいています。DevOpsについては、GitやCI/CDツールと連携します。DataOpsについては、オープンでパフォーマンスの高いデータ処理のデファクトアーキテクチャであるDelta Lakeとレイクハウスを基盤としています。ModelOpsについては、モデル管理で最も人気のあるオープンソースツールであるMLflowを基盤としています。オープンなフォーマットとAPIに基づくこの基盤により、お客様は多様な要件に合わせて当社のプラットフォームを適応させることができます。例えば、当社のMLflow製品を中心にモデル管理を一元化しているお客様は、ニーズに応じて、組み込みのモデルサービングやその他のソリューションを使用できます。

このブログ投稿で、当社のMLOpsアーキテクチャをご紹介できることを嬉しく思います。ここでは、DevOps、DataOps、ModelOpsを共同で管理する際の課題について議論し、当社のソリューションの概要を説明し、リファレンスアーキテクチャについて解説します。詳細については、『The Big Book of MLOps』をダウンロードし、まもなく開催されるData+AI Summit 2022のMLOpsトークにご参加ください。

コード、データ、モデルの共同管理

MLOpsとは、MLシステムにおける安定したパフォーマンスと長期的な効率性という2つの目標を達成するために、コード、データ、モデルを管理する一連のプロセスと自動化のことです。簡単に言えば、MLOps = DevOps + DataOps + ModelOpsです。

開発、ステージング、本番

ビジネス向けまたは顧客向けのアプリケーションへと移行する過程で、ML資産（コード、データ、モデル）は一連のステージを通過します。それらは、開発（「開発」ステージ）、テスト（「ステージング」ステージ）、デプロイ（「本番」ステージ）される必要があります。この作業は、Databricksワークスペースなどの実行環境内で行われます。

上記のすべて（実行環境、コード、データ、モデル）は、dev、staging、prodに分割されます。これらの区分は、品質保証とアクセス制御の観点から理解できます。開発中の資産は、より広くアクセスできる可能性がありますが、品質保証はありません。本番環境の資産は、一般的にビジネスに不可欠であり、テストと品質が最大限に保証されますが、変更できるユーザーは厳しく制限されます。

主な課題

上記の要件は、複雑さが容易に増大する可能性があります。開発、テスト、本番にわたり、複数のチーム間で、アクセス制御や複数のテクノロジーの関与といった複雑な要素を抱えながら、コード、データ、モデルをどのように管理すべきでしょうか。私たちは、この複雑さがいくつかの主な課題につながることを目の当たりにしてきました。

運用プロセス
DevOpsの考え方は、MLOpsにそのまま当てはまるわけではありません。DevOpsでは、実行環境、コード、データの間に密接な対応関係があります。例えば、本番環境では本番レベルのコードのみが実行され、本番レベルのデータのみが生成されます。MLモデルは話を複雑にします。なぜなら、モデルとコードのライフサイクルフェーズは非同期で動作することが多いからです。コードの変更をプッシュする前に新しいモデルバージョンをプッシュしたい場合や、その逆の場合もあります。次のシナリオを考えてみましょう。

• 不正取引を検知するために、モデルを毎週再学習させるMLパイプラインを開発します。コードの更新は四半期ごとに行いますが、毎週新しいモデルが自動的に学習、テストされ、本番環境に移行されます。このシナリオでは、モデルのライフサイクルはコードのライフサイクルよりも高速です。
• 大規模なニューラルネットワークを使用してドキュメントを分類する場合、コストの関係上、モデルの学習とデプロイは通常1回限りのプロセスになります。しかし、下流のシステムが定期的に変更されるため、それに合わせてサービングと監視のコードを更新します。このシナリオでは、コードのライフサイクルはモデルのライフサイクルよりも高速です。

コラボレーションと管理
MLOpsは、データサイエンティストがモデルを開発・維持するための柔軟性と可視性を必要とする一方で、MLエンジニアが本番システムを制御する必要があるという、相反するニーズのバランスを取る必要があります。データサイエンティストは、本番データでコードを実行し、本番システムからのログ、モデル、その他の結果を確認する必要があります。MLエンジニアは、安定性を維持し、場合によってはデータのプライバシーを保護するために、本番システムへのアクセスを制限する必要があります。単一のアクセス制御モデルを共有しない、複数のばらばらなテクノロジーをつなぎ合わせてプラットフォームが構築されている場合、これらのニーズを解決することはさらに困難になります。

統合とカスタマイズ
ML用の多くのツールは、オープンに設計されていません。例えば、一部のMLツールは、JARファイルなどのブラックボックス形式でのみモデルをエクスポートします。多くのデータツールはML向けに設計されていません。例えば、データウェアハウスではデータをMLツールにエクスポートする必要があり、ストレージコストの上昇やガバナンスの悩みの種になります。これらのコンポーネントツールがオープンなフォーマットやAPIに基づいていない場合、それらを統合されたプラットフォームに統合することは不可能です。

レイクハウスによるMLOpsのシンプル化

MLOpsの要件を満たすため、Databricksはそのアプローチをレイクハウスアーキテクチャの上に構築しました。レイクハウスは、データレイクとデータウェアハウスの機能を単一のアーキテクチャの下に統合します。このシンプル化は、両方のタイプのデータワークロードを駆動するオープンなフォーマットとAPIを使用することで可能になります。同様に、MLOpsについても、オープンなデータ標準を中心にMLOpsを構築しているため、よりシンプルなアーキテクチャを提供できます。

アーキテクチャアプローチの詳細に入る前に、その概要を説明し、主なメリットを明らかにします。

運用プロセス
当社のアプローチは、DevOpsの考え方をMLに拡張し、コード、データ、モデルにとって「本番環境への移行」が何を意味するのかについて、明確なセマンティクスを定義します。既存のDevOpsツールやCI/CDプロセスを再利用して、MLパイプラインのコードを管理できます。特徴量の計算、推論、その他のデータパイプラインは、モデル学習コードと同じデプロイプロセスに従うため、運用がシンプルになります。指定されたサービスであるMLflow Model Registryを使用すると、コードとモデルを独立して更新できるため、DevOpsの手法をMLに適応させる際の大きな課題が解決されます。

コラボレーションと管理
Databricksのアプローチは、データエンジニアリング、探索的データサイエンス、本番環境のML、ビジネスアナリティクスをサポートする統合プラットフォームに基づいており、これらすべてが共有のレイクハウスデータレイヤーによって支えられています。MLデータは、他のデータパイプラインで使用されるものと同じレイクハウスアーキテクチャの下で管理されるため、ハンドオフ（引き継ぎ）が簡素化されます。実行環境、コード、データ、モデルに対するアクセス制御により、適切なチームが適切なレベルのアクセス権を取得できるようになり、管理が容易になります。

統合とカスタマイズ
Databricksのアプローチは、オープンなフォーマットとAPI（Gitと関連するCI/CDツール、Delta Lakeとレイクハウスアーキテクチャ、MLflow）に基づいています。コード、データ、モデルは、オープンなフォーマットでお客様のクラウドアカウント（サブスクリプション）に保存され、オープンなAPIを提供するサービスによって支えられています。以下で説明するリファレンスアーキテクチャはDatabricks内で完全に実装できますが、各モジュールをお客様の既存のインフラストラクチャと統合してカスタマイズすることも可能です。たとえば、モデルの再トレーニングは、完全に自動化することも、部分的に自動化することも、手動で行うこともできます。

MLOpsのリファレンスアーキテクチャ

それでは、Databricksレイクハウスプラットフォーム上でMLOpsを実装するためのリファレンスアーキテクチャを見ていきましょう。このアーキテクチャ（およびDatabricks全般）はクラウドに依存せず、単一または複数のクラウドで使用できます。そのため、これはお客様の特定のニーズに合わせてカスタマイズすることを前提としたリファレンスアーキテクチャとなっています。アーキテクチャの詳細やカスタマイズの可能性については、『The Big Book of MLOps』を参照してください。

概要

このアーキテクチャは、DatabricksのMLOpsプロセスの概要を示しています。以下では、アーキテクチャの主要なコンポーネントと、MLパイプラインを本番環境に移行するための段階的なワークフローについて説明します。

コンポーネント

Databricksでは、実行環境、コード、データ、モデルといういくつかの主要な資産の管理という観点からアプローチを定義しています。

実行環境は、コードによってモデルやデータが作成または消費される場所です。環境は、開発、ステージング、本番用のDatabricksワークスペース（AWS、Azure、GCP）として定義され、役割の分離を強制するためにワークスペースのアクセス制御が使用されます。
アーキテクチャ図では、青、赤、緑の領域がこれら3つの環境を表しています。

環境内では、各MLパイプライン（図の小さなボックス）は、Databricksのクラスターサービス（AWS、Azure、GCP）によって管理されるコンピューティングインスタンス上で実行されます。これらのステップは、手動で実行することも、WorkflowsとJobs（AWS、Azure、GCP）を介して自動化することもできます。各ステップでは、デフォルトでライブラリがプリインストールされたDatabricks Runtime for ML（AWS、Azure、GCP）を使用する必要がありますが、カスタムライブラリ（AWS、Azure、GCP）を使用することもできます。

MLパイプラインを定義するコードは、バージョン管理のためにGitに保存されます。MLパイプラインには、特徴量作成、モデルのトレーニングとチューニング、推論、モニタリングを含めることができます。大まかに言えば、「MLの本番環境への移行」とは、開発ブランチからステージングブランチ（通常は`main`）、そして本番用のリリースブランチへとコードを昇格させることを意味します。このようにDevOpsと連携させることで、ユーザーは既存のCI/CDツールを統合できます。上記のアーキテクチャ図では、このコードの昇格プロセスが上部に示されています。

MLパイプラインを開発する際、データサイエンティストはノートブックから始めて、必要に応じてモジュール化されたコードに移行し、DatabricksまたはIDEで作業することができます。Databricks ReposはGitプロバイダーと統合され、ノートブックとソースコードをDatabricksワークスペース（AWS、Azure、GCP）と同期します。Databricksの開発者ツールを使用すると、IDEや既存のCI/CDシステムから接続できます（AWS、Azure、GCP）。

データはすべてお客様のクラウドアカウント内のレイクハウスアーキテクチャに保存されます。特徴量作成、推論、モニタリングのパイプラインは、すべてデータパイプラインとして扱うことができます。たとえば、モデルのモニタリングは、生のクエリイベントからダッシュボード用の集計テーブルまで段階的にデータを精製する、メダリオンアーキテクチャに従う必要があります。上記のアーキテクチャ図では、データは下部に一般的な「レイクハウス」データとして示されており、開発、ステージング、本番レベルのデータへの分割は非表示になっています。

デフォルトでは、パフォーマンスと整合性を保証するために、生データと特徴量テーブルの両方をDeltaテーブルとして保存する必要があります。Delta Lakeは、構造化データおよび非構造化データ向けのオープンで効率的なストレージレイヤーを提供し、Databricks内の最適化されたDelta Engine（AWS、Azure、GCP）を備えています。Feature Storeテーブルは、リネージなどの追加のメタデータを持つ単なるDeltaテーブルです（AWS、Azure、GCP）。生のファイルとテーブルはアクセス制御下にあり、必要に応じてアクセス権を付与または制限できます。

モデルはMLflowによって管理されます。これにより、Databricksの内外を問わず、あらゆるMLライブラリのモデルを、あらゆるデプロイモードで一元管理できます。Databricksは、アクセス制御、数百万のモデルへのスケーラビリティ、およびオープンソースMLflow APIのスーパーセット（上位互換）を備えた、マネージド版のMLflowを提供します。

開発段階では、MLflow Trackingサーバーが、コードのスナップショット、パラメータ、メトリクス、その他のメタデータとともにプロトタイプモデルを追跡します（AWS、Azure、GCP）。本番環境でも、同じプロセスによって再現性とガバナンスのための記録が保存されます。

継続的デプロイ（CD）において、MLflow Model Registryはモデルのデプロイステータスを追跡し、ウェブフック（AWS、Azure、GCP）やAPI（AWS、Azure、GCP）を介してCDシステムと連携します。Model Registryサービスは、コードのライフサイクルとは別にモデルのライフサイクルを追跡します。このようにモデルとコードを疎結合にすることで、コードを変更せずに本番モデルを更新したり、その逆を行ったりできる柔軟性が得られます。例えば、自動再学習パイプラインは、本番環境内で、更新されたモデル（「開発」モデル）の学習、テスト（「ステージング」モデル）、デプロイ（「本番」モデル）をすべて行うことができます。

以下の表は、コード、データ、モデルにおける「開発」、「ステージング」、「本番」の意味をまとめたものです。

ワークフロー

上記のアーキテクチャの主要コンポーネントを説明したところで、ここからはMLパイプラインを開発から本番へと移行するワークフローについて説明します。

開発環境：データサイエンティストは主に開発環境で作業し、特徴量の計算、モデルの学習、推論、モニタリングなどを含むMLパイプラインのコードを構築します。

1. 開発ブランチの作成：新規または更新されたパイプラインは、Gitプロジェクトの開発ブランチでプロトタイプが作成され、Reposを介してDatabricksワークスペースと同期されます。
2. 探索的データ解析（EDA）：データサイエンティストは、ノートブック、可視化ツール、Databricks SQLを使用して、インタラクティブかつ反復的なプロセスでデータを探索および分析します。
3. 特徴量テーブルの更新：特徴量化ロジックはパイプラインとしてカプセル化され、Feature Storeやその他のレイクハウスのテーブルから読み取り、Feature Storeに書き込みます。特徴量パイプラインは、特に別のチームが所有している場合、他のMLパイプラインとは別に管理されることがあります。
4. モデルの学習およびその他のパイプライン：データサイエンティストは、読み取り専用の本番データ、または秘匿化されたデータや合成データを使用して、これらのパイプラインを開発します。このリファレンスアーキテクチャでは、モデルではなくパイプラインが本番環境へと昇格されます。必要に応じてモデルを昇格させる方法については、ホワイトペーパーの全文を参照してください。
5. コードのコミット：新規または更新されたMLパイプラインがソース管理にコミットされます。更新は、単一のMLパイプラインに影響を与えることもあれば、同時に多くのパイプラインに影響を与えることもあります。

ステージング環境：MLエンジニアがステージング環境を所有し、ここでMLパイプラインがテストされます。

6. マージ（プル）リクエスト：ステージングブランチ（通常は「main」ブランチ）へのマージリクエストにより、継続的インテグレーション（CI）プロセスがトリガーされます。
7. ユニットテスト（CI）：CIプロセスは、まずデータや他のサービスと相互作用しないユニットテストを実行します。
8. 統合テスト（CI）：次に、CIプロセスは、MLパイプラインを共同でテストする、より長時間の統合テストを実行します。モデルを学習させる統合テストでは、速度向上のために少量のデータや少ないイテレーション回数を使用する場合があります。
9. マージ：テストに合格すると、コードをステージングブランチにマージできます。
10. リリースブランチの作成：準備が整ったら、コードリリースを作成し、CI/CDシステムをトリガーして本番ジョブを更新することで、コードを本番環境にデプロイできます。

本番環境：MLエンジニアが本番環境を所有し、ここでMLパイプラインがデプロイされます。

11. 特徴量テーブルの更新：このパイプラインは、新しい本番データを取り込み、本番のFeature Storeテーブルを更新します。これは、スケジュール設定、トリガー、または継続的に実行されるバッチジョブまたはストリーミングジョブにすることができます。
12. モデルの学習：モデルは完全な本番データで学習され、MLflow Model Registryにプッシュされます。学習は、コードの変更または自動再学習ジョブによってトリガーされます。
13. 継続的デプロイ（CD）：CDプロセスは、新しいモデル（Model Registryの「stage=None」）を取得し、テストし（「stage=Staging」に移行）、成功した場合はデプロイします（「stage=Production」に昇格）。CDは、Model Registryのウェブフックや独自のCDシステムを使用して実装できます。
14. 推論とサービング：Model Registryの本番モデルは、複数のモードでデプロイできます。高スループットのユースケース向けのバッチジョブおよびストリーミングジョブ、低レイテンシ（REST API）のユースケース向けのオンラインサービングなどです。
15. モニタリング：どのデプロイモードでも、モデルの入力クエリと予測はDeltaテーブルに記録されます。そこから、ジョブはデータとモデルのドリフトを監視でき、Databricks SQLダッシュボードでステータスを表示し、アラートを送信できます。開発環境では、データサイエンティストにログやメトリクスへのアクセス権を付与して、本番環境の問題を調査させることができます。
16. 再学習：モデルは、シンプルなスケジュール設定を介して最新のデータで再学習させることも、モニタリングジョブによって再学習をトリガーすることもできます。

MLOpsアーキテクチャの実装

このブログを通じて、レイクハウスのパラダイムを中心としたデータ中心のMLOpsアーキテクチャが、コード、データ、モデルの共同管理をどのように簡素化するかをご理解いただけたでしょうか。このブログは要約されているため、多くの詳細が省略されています。MLOpsアーキテクチャの実装または改善を開始するには、以下をお勧めします。

• eBookの全文を読む：ワークフローのステップの詳細や、オプション、カスタマイズに関する議論が掲載されています。ダウンロードはこちらから。
• 6月27〜30日に開催されるData+AI Summit 2022のMLOpsに関する講演に参加する。おすすめのセッションは以下の通りです。
  • ハイレベルな講演
    • 2日目のオープニングキーノート：共同創設者とプロダクトマネージャーが、DSおよびMLに関するオープンソースおよびDatabricksプロジェクトの最新のビジョンとロードマップを共有します。
    • ML on the Lakehouse: Bringing Data and ML Together to Accelerate AI Use Cases：Databricksのプロダクトマネージャーとお客様が、レイクハウスアーキテクチャにおける機械学習の概要を説明します。
  • DatabricksによるMLOpsのディープダイブ
    • MLOps on Databricks: A How-To Guide：このブログ記事の著者が、eBookのガイダンスの詳細を説明し、DatabricksでのMLOpsプロセスをデモします。
    • MLflow Pipelines: Accelerating MLOps from Development to Production：Databricksのエンジニアが、MLflowにおけるこの最新のイノベーションについて詳しく解説します。
    • Enable Production ML with Databricks Feature Store：Databricksのエンジニアがフィーチャーストアについて詳しく解説します。
  • 自社のMLプラットフォームについて語るお客様
    • 世界最大のビール醸造会社における機械学習ベースの製品の構築とスケーリング
    • DoorDashにおけるデータサイエンス向けレイクハウスの構築
• Databricksのアカウントチームにご相談ください。お客様の要件についてのご相談を承り、このリファレンスアーキテクチャをお客様のプロジェクトに適応させるお手伝いをいたします。また、必要に応じてトレーニングや実装のための追加リソースを手配いたします。

MLOpsに関する詳細な背景情報については、以下を参照することをお勧めします。

• データ中心のMLプラットフォームの必要性 → この記事では、MLOpsとデータ中心主義の必要性について詳しく説明し、データチームが新しいML搭載アプリケーションを開発する具体的な例を紹介しています。
• 機械学習プラットフォームを選定するための3つの原則 → この記事は、本記事よりも一歩進んだ内容となっています。MLプラットフォームの技術選定について議論し、ハイレベルなガイドラインを提示するとともに、関連するお客様の事例を紹介しています。
• フィーチャーストア総合ガイド → フィーチャーストアはそれ自体が独立した大きなテーマです。このガイドでは、その詳細を深く掘り下げています。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事