次の方法で共有

オペレーショナル エクセレンスのベスト プラクティス

  • [アーティクル]

この記事では、オペレーショナル エクセレンスのベスト プラクティスについて、以下のセクションで示すアーキテクチャの原則ごとにまとめて説明します。

1. ビルドとリリースのプロセスを最適化する

レイクハウス専門の運用チームを設ける

データ チームが 1 つまたは複数のデータ プラットフォームについて作業できるように、プラットフォーム運用チームを設けるのが一般的なベスト プラクティスです。 このチームは、内部的なブループリントとベスト プラクティスの用意を担当します。 インフラストラクチャの自動化やセルフサービス アクセスなどのためのツールを提供し、セキュリティとコンプライアンスのニーズが満たされていることを確認します。 このように、プラットフォーム データのセキュリティ保護の負担を中央のチームにまとめると、分散チームはデータの処理と新しい分析情報の生成に集中できます。

Databricks Git フォルダーを使用して Git にコードを格納する

Databricks Git フォルダーを使用すると、ユーザーはノートブックや他のファイルを Git リポジトリに格納でき、これにより、リポジトリのクローン、コミットとプッシュ、プル、ブランチ管理、ファイルの相違の表示などの機能が提供されます。 コードの可視性と追跡をより向上させるには、Git フォルダーを使用します。 「Git と Databricks Git フォルダーの統合」を参照してください。

DevOps プロセスを標準化する (CI/CD)

継続的インテグレーションと継続的デリバリー (CI/CD) とは、自動化パイプラインを使い、短いサイクルを頻繁に行うことで、ソフトウェアを開発してデリバリーすることです。 これは新しいプロセスではなく、従来のソフトウェア エンジニアリングで数十年にわたって広く見られたものですが、Data Engineering およびデータ サイエンスのチームにとって必要なプロセスになりつつあります。 データ製品が価値あるものであるには、適切なタイミングで配信される必要があります。 さらに、コンシューマーは、これらの製品で得られる結果の有効性を信頼している必要があります。 コードのビルド、テスト、デプロイを自動化することにより、開発チームは、Data Engineering とデータ サイエンスの多くのチームでいまだに広く用いられている手動プロセスより、頻繁かつ確実にリリースを配布できます。 「Azure Databricks の CI/CD とは」をご覧ください。

Databricks Git フォルダーを使用したコード開発に関するベスト プラクティスについて詳しくは、「Git と Databricks Repos を使用した CI/CD 手法」をご覧ください。 これと共に、Databricks REST API を使うことで、GitHub Actions、Azure DevOps パイプライン、または Jenkins ジョブによる自動デプロイ プロセスを構築できます。

MLOps プロセスで標準化する

ML モデルの構築とデプロイは複雑です。 これを実現するには多くのオプションがありますが、明確に定義された標準というものはほとんどありません。 その結果、ここ数年、機械学習の運用 (MLOps) が注目されるようになっています。 MLOps は、ML システムのパフォーマンスの安定性と長期的な効率を向上させるための、モデル、データ、コードの管理に関する一連のプロセスと自動化です。 それにおいては、データ準備、探索的データ分析 (EDA)、特徴エンジニアリング、モデル トレーニング、モデル検証、デプロイ、監視が扱われています。 「Azure Databricks での MLOps ワークフロー」を参照してください。

  • ビジネス目標を常に念頭に置く: ビジネスにおける ML の主な目的がデータ ドリブンの意思決定と製品を可能にすることであるのと同様に、MLOps の主な目的は、それらのデータ ドリブン アプリケーションが安定を保ち、最新の状態を維持し、ビジネスにプラスの影響を与え続けられるようにすることです。 MLOps での技術的な作業の優先順位を決めるときは、ビジネスへの影響を考慮します。それによって、新しいビジネス ユース ケースは有効になりますか。 データ チームの生産性は向上しますか。 運用コストやリスクは減りますか。
  • 専用ではあってもオープンなツールを使って ML モデルを管理する: ML モデルのライフサイクルを考慮して設計された MLflow を使って、ML モデルを追跡および管理することをお勧めします。 「MLflow を使用した ML ライフサイクル管理」を参照してください。
  • モジュール形式で MLOps を実装する: 他のソフトウェア アプリケーションと同様に、ML アプリケーションでもコードの品質が最も重要です。 コードをモジュール化すると、コンポーネントを個別にテストでき、将来コードをリファクタリングするときの難しさが軽減されます。 明確なステップ (トレーニング、評価、デプロイなど)、スーパー ステップ (トレーニングからデプロイへのパイプラインなど)、ML アプリケーションのモジュール構造を明確にする責任を定義します。

詳しくは、Databricks の MLOps に関するホワイトペーパーをご覧ください。

2. デプロイとワークロードを自動化する

コードとしてのインフラストラクチャをデプロイとメンテナンスに使用する

HashiCorp Terraform は、複数のクラウド プロバイダーにわたって安全で予測可能なクラウド インフラストラクチャを作成するためによく使用されるオープン ソース ツールです。 Databricks Terraform プロバイダーは、柔軟で強力なツールを使って、Azure Databricks ワークスペースとそれに関連するクラウド インフラストラクチャを管理します。 Databricks Terraform プロバイダーの目的は、すべての Azure Databricks REST API をサポートし、データ プラットフォームのデプロイと管理における最も複雑な側面の自動化をサポートすることです。 Databricks Terraform プロバイダーは、クラスターとジョブを確実にデプロイして管理し、Azure Databricks ワークスペースをプロビジョニングし、データ アクセスを構成するための推奨されるツールです。

クラスター ポリシーの使用

Databricks ワークスペース管理者は、使用可能なインスタンスの種類、Databricks のバージョン、インスタンスのサイズなど、スピンアップされるクラスターの多くの側面を、クラスター ポリシーを使って制御できます。 ワークスペース管理者は、いくつかの Spark 構成の設定を適用し、複数のクラスター ポリシーを構成することができます。これにより、特定のユーザー グループには小規模なクラスターまたはシングル ユーザー クラスターの作成を許可し、一部のユーザー グループには大規模なクラスターの作成を許可し、他のグループには既存のクラスターの使用のみを許可することができます。 「コンピューティング ポリシーの作成と管理」を参照してください。

ジョブに自動化されたワークフローを使用する

  • ジョブを含むワークフロー (内部オーケストレーション):

    ジョブを含むワークフローを使って、スケーラブルなリソースを含む Azure Databricks クラスターでのデータ処理とデータ分析のタスクをスケジュールすることをお勧めします。 ジョブは、単一のタスクでも、複雑な依存関係を持つ大規模なマルチタスク ワークフローでも構成できます。 Databricks が、すべてのジョブに関するタスク オーケストレーション、クラスター管理、監視、エラー レポートを管理します。 ジョブの実行は、すぐに、または使いやすいスケジューリング システムを使用して定期的に行えます。 ジョブ タスクは、ノートブック、JARS、Delta Live Tables パイプライン、または Python、Scala、Spark submit、Java のアプリケーションを使用して実装できます。 「Azure Databricks ワークフローの概要」を参照してください。

  • 外部オーケストレーター:

    外部オーケストレーターが Databricks の資産、ノートブック、ジョブを調整するには、包括的な Azure Databricks REST API が使われます。 参照トピック

自動ローダーを使用する

自動ローダーは、新しいデータ ファイルがクラウド ストレージに到着すると、それらを段階的かつ効率的に処理します。 JSON、CSV、PARQUET、AVRO、ORC、TEXT、BINARYFILE など、多くのファイル形式を取り込むことができます。 クラウド ストレージ上の入力フォルダーを使うと、自動ローダーは到着した新しいファイルを自動的に処理します。

1 回限りのインジェストの場合は、代わりに COPY INTO コマンドを使うことを検討してください。 「COPY INTO を使用してデータを読み込む」を参照してください。

Delta Live Tables を使用する

Delta Live Tables は、信頼性、保守性、テスト可能性に優れたデータ処理パイプラインを構築するための宣言型フレームワークです。 ユーザーは、お持ちのデータに対して実行するための変換を定義します。Delta Live Tables は、タスク オーケストレーション、クラスター、監視、データ品質、エラー処理についての管理を行います。

Delta Live Tables では、SQL または Python でエンド ツー エンドのデータ パイプラインを簡単に定義できます。データ ソース、変換ロジック、データの変換先の状態を指定します。 Delta Live Tables は依存関係を維持し、ジョブを実行するインフラストラクチャを自動的に決定します。

Delta Live Tables は、データの品質を管理するため、データ品質の傾向を経時的に監視し、定義済みのエラー ポリシーによる検証と整合性チェックを通して、不適切なデータがテーブルに流れ込むのを防ぎます。 「Delta Live Tables とは」を参照してください。

ML ワークロードのコードのデプロイ アプローチに従う

コードのデプロイ アプローチは、次の手順に従います。

  • トレーニング環境: トレーニング コードと補助コードを開発します。  次に、コードのレベルをステージングに上げます。
  • ステージング環境: データのサブセットでモデルをトレーニングし、補助コードをテストします。 次に、コードのレベルを運用に上げます。
  • 運用環境: 運用データでモデルをトレーニングし、モデルをテストします。 次に、モデルと補助パイプラインをデプロイします。

「モデルのデプロイ パターン」をご覧ください。

このモデルの主な利点は、次のとおりです。

  • Git や CI/CD システムなどの馴染みのツールを使って、従来のソフトウェア エンジニアリング ワークフローに適合します。
  • ロックダウンされた環境での自動再トレーニングをサポートします。
  • 運用環境でのみ、運用トレーニング データへの読み取りアクセスが必要です。
  • トレーニング環境を完全に制御できるため、再現性の簡素化に役立ちます。
  • データ サイエンス チームはモジュール式コードと反復テストを使用でき、これは大規模なプロジェクトでの調整と開発に役立ちます。

詳しくは、MLOps に関するホワイトペーパーをご覧ください。

モデル レジストリを使用してコードとモデルのライフサイクルを分離する

モデルのライフサイクルはコードのライフサイクルと 1 対 1 に対応していないため、モデルをそれ専用のサービスで管理することは理にかなっています。 MLflow とそのモデル レジストリでは、UI と API を介してモデル成果物を直接管理できます。 モデル成果物とコードの結合は緊密ではないため、コードを変更せずに運用モデルを柔軟に更新でき、多くの場合、デプロイ プロセスが簡素化されます。 モデル成果物は、MLflow のアクセス制御またはクラウド ストレージのアクセス許可を使ってセキュリティ保護されます。 「Unity Catalog 内でモデル ライフサイクルを管理する」をご覧ください。

MLflow Autologging を使用する

Databricks Autologging は、MLflow 自動ログ記録を拡張して、Azure Databricks 上の機械学習トレーニング セッションの自動実験追跡を提供する、ノーコード ソリューションです。 MLflow の追跡実行として記録されたトレーニング実行を使ってモデルをトレーニングすると、Databricks Autologging により、モデルのパラメーター、メトリック、ファイル、系列の情報が自動的にキャプチャされます。

同じインフラストラクチャを再利用して ML パイプラインを管理する

ML パイプラインは、他のデータ パイプラインと同じ手法の多くを使って自動化する必要があります。 デプロイを自動化するには、Databricks Terraform プロバイダーを使います。 ML では、推論ジョブ、サービス エンドポイント、特徴量化ジョブなどのインフラストラクチャをデプロイする必要があります。 すべての ML パイプラインはジョブを含むワークフローとして自動化でき、多くのデータ中心 ML パイプラインでは、さらに特殊な自動ローダーを使ってイメージや他のデータを取り込み、Delta Live Tables を使って特徴量の計算やメトリックの監視を行うことができます。

3. 監視、アラート、ログを設定する

Azure 監視ソリューションを使用したプラットフォームの監視

監視は、どのような運用レベル ソリューションでも重要なものです。Azure Databricks では、カスタム アプリケーション メトリック、ストリーミング クエリ イベント、アプリケーション ログ メッセージを監視するための堅牢な機能が提供されます。 Azure Databricks では、この監視データをさまざまなログ記録サービスに送信できます。 以下の記事では、Azure Databricks から Azure Monitor (Azure の監視データ プラットフォーム) に監視データを送信する方法が説明されています。

Ganglia を使用したクラスターの監視

クラスターを監視しやすいよう、Azure Databricks ではクラスターの詳細ページから Ganglia メトリックにアクセスでき、これには GPU メトリックが含まれます。 「Ganglia メトリック」をご覧ください。

SQL ウェアハウスの監視

SQL ウェアハウスの監視は、負荷プロファイルを経時的に把握し、SQL ウェアハウスを効率的に管理するために不可欠です。 SQL ウェアハウスの監視を使うと、ウェアハウスによって処理されたクエリの数や、ウェアハウスに割り当てられたクラスターの数などの情報を見ることができます。

自動ローダーの監視

自動ローダーは、ストリームの状態を検査するための SQL API を提供します。 SQL 関数を使って、自動ローダー ストリームによって検出されたファイルに関するメタデータを見つけることができます。 「自動ローダーの監視」をご覧ください。

Apache Spark のストリーミング クエリ リスナー インターフェイスを使うと、自動ローダー ストリームをさらに詳しく監視できます。

Delta Live Tables の監視

イベント ログは、すべての Delta Live Tables パイプラインに対して作成および管理されます。 イベント ログには、監査ログ、データ品質チェック、パイプラインの進行状況、データ系列など、パイプラインに関連するすべての情報が含まれています。 イベント ログを使用して、データ パイプラインの状態を追跡、把握、および監視することができます。 「Delta Live Tables パイプラインを監視する」をご覧ください。

ストリーミングの監視

ストリーミングは、インジェストと分析に関する最も重要なデータ処理手法の 1 つです。 これにより、分析およびアクションのトリガーのための低遅延でリアルタイムのデータ処理機能が、ユーザーと開発者に提供されます。 Databricks Data Intelligence Platform を使用すると、構造化ストリーミング クエリを簡単に監視できます。 「Azure Databricks で構造化ストリーミング クエリを監視する」をご覧ください。

専用の UI を使って、リアルタイムのメトリックと統計に関する付加的な情報を見つけることができます。 詳しくは、「Apache Spark 3.0 での新しい構造化ストリーミング UI の概要」をご覧ください。

セキュリティの監視

「セキュリティ、コンプライアンスおよびプライバシー - セキュリティ監視」を参照してください。

コストの監視

コスト最適化でのコストの監視と制御に関する記事をご覧ください。

4. 容量とクォータを管理する

サービスの制限とクォータを管理する

クラウドで起動されるすべてのサービスでは、アクセスのレート制限、インスタンスの数、ユーザー数、メモリ要件などの制限を考慮する必要があります。 クラウド プロバイダーで、クラウドの制限をチェックします。 ソリューションを設計する前に、これらの制限を理解する必要があります。

具体的には、Databricks プラットフォームにはさまざまな種類の制限があります。

Databricks プラットフォームの制限: これらは、Azure Databricks リソースに固有の制限です。 プラットフォーム全体の制限については、「リソース制限」をご覧ください。

Unity Catalog の制限:Unity Catalog のリソース クォータ

サブスクリプションとアカウントのクォータ: Azure Databricks は、そのサービスにクラウド リソースを活用します。 たとえば、Azure Databricks 上のワークロードはクラスターで実行され、そのために Databricks プラットフォームによってクラウド プロバイダーの仮想マシン (VM) が開始されます。 クラウド プロバイダーにより、同時に開始できる VM の数に対して既定のクォータが設定されています。 必要に応じて、これらのクォータの調整が必要になる場合があります。

詳しくは、「VM ファミリの vCPU クォータを増やす」をご覧ください。

同様に、ストレージ、ネットワーク、その他のクラウド サービスにも制限があり、理解して考慮する必要があります。

キャパシティ プランニングに投資する

予想される負荷では、ビジネスの急激な変化や世界の出来事などのいくつかの理由により変動が発生する可能性があるので、それに対する計画を立てます。 予期しないものなど、負荷の変動をテストして、ワークロードがスケーリングできることを確認します。 あるリージョンで障害が発生した場合に、全体の負荷をサポートするために、すべてのリージョンが適切にスケーリングできることを確認します。 次のことを考慮します。

  • テクノロジとサービスに関する制限およびクラウドの制限。 「容量とクォータを管理する」をご覧ください。
  • 設計で使用するサービスを決定する際の SLA。
  • コストを増やした場合に、アプリケーションでどの程度の改善が実現されるかを特定するコスト分析。 その価格に投資するだけの価値があるかどうかを評価します。