次の方法で共有

信頼性のためのベスト プラクティス

この記事では、次のセクションでアーキテクチャの原則ごとに記載された 信頼性 のベスト プラクティスについて説明します。

故障を見越した設計

ACID トランザクションをサポートするデータ形式を使用する

ACID トランザクションは、データの整合性と一貫性を維持するうえで重要な機能です。 ACID トランザクションをサポートするデータ形式を選択することは、よりシンプルで信頼性の高いパイプラインを構築するのに役立ちます。

Delta Lake はオープンソースのストレージ フレームワークで、ACID トランザクションのほか、スキーマの適用と、スケーラブルなメタデータ処理を提供し、さらに、ストリーミングとバッチ データ処理を統合します。 Delta Lake は Apache Spark API と完全に互換性があり、構造化ストリーミングと緊密に連携するように設計されているため、データの 1 つのコピーをバッチ操作とストリーミング操作の両方で容易に使用することが可能で、大規模な増分処理を提供できます。

回復性のある分散型データ エンジンをすべてのワークロードで使用する

Apache Spark は、Azure Databricks レイクハウスのコンピューティング エンジンであり、回復性のある分散データ処理をベースにしています。 内部の Spark タスクから想定どおりに結果が返されない場合、Apache Spark は欠落したタスクを自動的に再スケジュールし、ジョブ全体の実行を継続します。 これは、短期的なネットワークの問題やスポット VM の割り当て解除など、コード外のエラーに役立ちます。 SQL API と Spark DataFrame API の両方の操作において、この回復性はエンジンに組み込まれています。

Databricks レイクハウスでは、全体が C++ で記述されたネイティブのベクター化エンジンである Photon が、Apache Spark API と互換性のあるハイ パフォーマンス コンピューティングです。

無効なデータまたは不適合のデータを自動的に復旧する

無効なデータや不適合なデータは、確立されたデータ形式に依存するワークロードをクラッシュさせる可能性があります。 プロセス全体でエンドツーエンドの回復性を高めるには、データを取り込む際に、無効なデータや不適合なデータを除外することがベスト プラクティスです。 復旧されたデータをサポートすることで、データを取り込む際や ETL 中に、データが失われたり、欠落したりすることがなくなります。 復旧されたデータ列には解析されなかったデータが含まれます。これは、指定されたスキーマからこのデータが欠落したため、型の不一致があるため、あるいは、レコードまたはファイル内の列の内容がスキーマ内のものと一致しなかったためなどが原因です。

  • Databricks Auto Loader:Auto Loader は、ファイル インジェストをストリーミングするための理想的なツールです。 このツールでは、JSON と CSV のために 復旧されたデータ をサポートしています。 たとえば JSON の場合、復旧されたデータ列には、解析されなかったデータが含まれます。これは、指定されたスキーマからデータが欠落したため、型の不一致があったため、大文字と小文字の区別がこの列のものと一致しなかったためなどが原因と考えられます。 復旧されたデータ列は、スキーマが推論されるときに、自動ローダーによって既定で _rescued_data として返されるスキーマの一部です。

  • パイプライン： 回復性のためのワークフローを構築するもう 1 つのオプションは、品質の制約がある Lakeflow 宣言パイプラインを 使用することです。 パイプラインの期待を使用してデータ品質を管理する方法については、を参照してください。 Lakeflow 宣言型パイプラインでは、無効なレコードの保持、削除、および失敗という 3 つのモードが既定でサポートされています。 無効として識別されたレコードを検疫するためには、予想ルールを特定の方法で定義して、無効なレコードが別のテーブルに格納 (検疫) されるようにします。 「無効なレコードの検疫」を参照してください。

ジョブの自動再試行と終了を構成する

分散システムは複雑であり、1 か所での障害がシステム全体に連鎖する可能性があります。

  • Lakeflow ジョブは、失敗した実行を再試行するタイミングと回数を決定するタスクの再試行ポリシーをサポートします。 「再試行ポリシーの設定」を参照してください。
  • タスクの想定完了時間や最大完了時間など、タスクに関する任意の期間しきい値を構成できます。
  • Lakeflow 宣言型パイプラインでは、 速度と信頼性のバランスを取るために、エスカレート再試行を使用して障害復旧も自動化されます。 「開発と運用のモード」を参照してください。

一方、停止しているタスクはジョブ全体の完了を妨げ、結果として高コストが発生することがあります。 Lakeflow ジョブでは、予想以上に時間がかかるジョブを強制終了するためのタイムアウト構成がサポートされています。

スケーラブルな本番環境グレードのモデル サービング インフラストラクチャを使用する

バッチ推論とストリーミング推論の場合は、Lakeflow ジョブと MLflow を使用してモデルを Apache Spark UDF としてデプロイし、ジョブのスケジュール設定、再試行、自動スケーリングなどを活用します。 バッチ推論と予測については、 モデルのデプロイに関するを参照してください。

モデル サービングでは、リアルタイムのモデル サービング向けのスケーラブルな本番環境グレードのインフラストラクチャを提供します。 この機能では、MLflow を使用して機械学習モデルを処理し、それを REST API エンドポイントとして公開します。 この機能ではサーバーレス コンピューティングを使用しています。つまり、エンドポイントおよび関連するコンピューティング リソースは Azure Databricks クラウド アカウントで管理され、実行されます。

可能な場合にマネージド サービスを使用する

Databricks Data Intelligence プラットフォームで、次のようなマネージド サービス (サーバーレス コンピューティング) を活用します。

これらのサービスは、Databricks によって信頼性が高くスケーラブルな方法で運用され、ワークロードの信頼性が高くなります。

2. データ品質を管理する

階層型ストレージ アーキテクチャを使用する

階層型アーキテクチャを作成することでデータをキュレーションし、データがレイヤー間を移動するにつれてデータの品質が向上するようにします。 一般的な階層型アプローチは次のとおりです。

  • 未加工レイヤー (ブロンズ):ソース データはレイクハウスの最初のレイヤーに取り込まれ、そこで永続化します。 すべてのダウンストリーム データが生レイヤーから作成されると、必要に応じて、このレイヤーから後続のレイヤーを再構築できます。
  • キュレーションされたレイヤー (シルバー): 2 番目のレイヤーの目的は、クレンジング、精製、フィルター処理、および集計されたデータを保持することです。 このレイヤーの目的は、役割と機能の全体で、分析とレポートのための確実で信頼性の高い基盤を提供することです。
  • 最終レイヤー (ゴールド): 3 番目のレイヤーは、ビジネスまたはプロジェクトのニーズを中心に構築されます。 ここでは、他の事業単位やプロジェクトに対して異なる視点をデータ製品として提供し、セキュリティ ニーズに沿ったデータ (匿名化されたデータなど) を準備したり、パフォーマンスのために最適化 (事前集計ビューを使用するなど) したりします。 このレイヤーのデータ製品は、ビジネスにおける事実と見なされます。

最終レイヤーには高品質のデータのみを含め、ビジネスの観点からは完全に信頼できるものとするようにします。

データの冗長性を削減することでデータの整合性を向上させる

データをコピーまたは複製するとデータの冗長性が生じ、データ整合性とデータ系列の喪失につながります。また多くの場合、それぞれのアクセス許可が異なります。 これにより、レイクハウス内のデータの品質が低下します。

一時的または使い捨て用のデータのコピーは、それ自体として有害ではありません。機敏性、実験、イノベーションを促進するために、時として必要なことです。 ただし、これらのコピーが運用上利用可能になり、ビジネス上の意思決定に定期的に使用される場合は、これらがデータのサイロとなります。 これらのデータ サイロの同期が行われなくなると、「どのデータ セットがマスターなのか?」 といった疑問が生じ、データの整合性と品質に大きな悪影響を及ぼします。 また、「データ セットは最新の状態なのか?」ということも問題になります。

スキーマを積極的に管理する

スキーマの管理されていない変更により、無効なデータが発生し、これらのデータ セットを使用するジョブが失敗する可能性があります。 Azure Databricks には、スキーマを検証して適用するためのメソッドがいくつかあります。

  • Delta Lake では、インジェスト中に不適切なレコードが挿入されないように、スキーマの変化を自動的に処理することで、スキーマの検証とスキーマの適用をサポートしています。 「スキーマの適用」を参照してください。
  • 自動ローダーは、データを処理する際に新しい列が追加されたことを検出します。 既定では、新しい列が追加されたストリームは、UnknownFieldException で停止します。 自動ローダーでは、 スキーマの展開のためのいくつかのモードがサポートされています。

制約とデータの期待値を使用する

Delta テーブルでは、テーブルに追加されたデータの品質と整合性を確実に自動で検証するための標準の SQL 制約管理句がサポートされています。 制約に違反すると、Delta Lake は InvariantViolationException エラーをスローして、新しいデータを追加できないことを通知します。 「Azure Databricks の制約」を参照してください。

この処理をさらに改善するために、Lakeflow 宣言型パイプラインは期待値をサポートしています。期待値は、データ セットの内容に対するデータ品質の制約を定義します。 エクスペクテーションは、説明と不変条件のほか、レコードが不変条件を満たさない場合に行われるアクションから構成されます。 クエリに対するエクスペクテーションには、Python デコレーターまたは SQL 制約句を使用します。 パイプラインの期待を使用してデータ品質を管理する方法については、を参照してください。

機械学習にデータ中心のアプローチを取り入れる

Databricks Data Intelligence プラットフォームにおける AI ビジョンの中核をなす基本原則は、機械学習に対するデータ中心のアプローチです。 生成 AI が一層普及するなかで、この観点は依然として重要です。

ML プロジェクトのコア コンポーネントは、データ パイプラインであると単純に捉えることができます。特徴エンジニアリング、トレーニング、モデル デプロイ、推論、監視パイプラインはすべてデータ パイプラインです。 そのため、ML ソリューションを運用するには、予測、監視、特徴のテーブルのデータを他の関連データとマージする必要があります。 基本的に、これを実現する最も簡単な方法は、運用データの管理に使用しているのと同じプラットフォームで AI 搭載ソリューションを開発することです。 「データ中心の MLOps と LLMOps」を参照してください

3. 自動スケーリングを設計する

ETL ワークロードの自動スケーリングを有効にする

自動スケーリングを使用すると、クラスターのサイズをワークロードに基づいて自動的に変更できます。 自動スケーリングは、コストとパフォーマンスの視点から、多くのユース ケースとシナリオにメリットをもたらします。 このドキュメントでは、自動スケーリングを使用するかどうかの判断、および最大のベネフィットを得る方法を決定する上での考慮事項について説明します。

ストリーミング ワークロードの場合、Databricks では、自動スケーリングで Lakeflow 宣言パイプラインを使用することをお勧めします。 Databricks 拡張自動スケーリングでは、ワークロード ボリュームに基づいてクラスター リソースを自動的に割り当てることでクラスター使用率が最適化され、パイプラインのデータ処理待機時間への影響が最小限に抑えられます。

SQL ウェアハウスの自動スケーリングを有効にする

SQL ウェアハウスのスケーリング パラメーターは、ウェアハウスに送信されたクエリが分散されるクラスターの最小数と最大数を指定します。 既定値は自動スケーリングなしで、1 つのクラスターです。

特定のウェアハウスでより多くの同時実行ユーザーを処理するには、クラスター数を増やします。 Azure Databricks によるウェアハウスのクラスターの追加または削除の方法については、「SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作」をご覧ください。

4. 復旧プロシージャをテストする

構造化ストリーミングのクエリ エラーから復旧する

構造化ストリーミングは、ストリーミング クエリのためのフォールト トレランス性とデータの一貫性を提供します。 Lakeflow ジョブを使用すると、障害発生時に自動的に再起動するように Structured Streaming クエリを簡単に構成できます。 ストリーミング クエリに対してチェックポイントを有効にすると、失敗後にクエリを再起動できます。 再起動されたクエリは、失敗したクエリが中断された場所から続行されます。 「構造化ストリーミングのチェックポイント」と「構造化ストリーミングの生産に関する考慮事項」を参照してください。

データのタイム トラベル機能を使用して ETL ジョブを回復する

徹底的なテストを行なったとしても、運用環境でジョブが失敗したり、予期しない、無効なデータを生成したりすることがあります。 問題の原因をつきとめ、この問題を最初に引き起こしたパイプラインを修正した後に、追加のジョブを行うことで、これを解決できる場合があります。 ただし、多くの場合、この作業は単純ではなく、問題となっているジョブをロールバックする必要が生じます。 Delta タイム トラベルを使用すれば、ユーザーは古いバージョンまたはタイムスタンプに簡単に変更をロールバックし、パイプラインの修復を行なった上で、そのパイプラインを再起動できます。

これを行うための便利な方法は、RESTORE コマンドの使用です。

組み込みの回復機能を備えたジョブ自動化フレームワークを活用する

Lakeflow ジョブ は復旧用に設計されています。 マルチタスク ジョブのタスクが失敗した場合 (および、すべての依存タスクなど)、ジョブは実行のマトリックス ビューを提供します。これにより、エラーの原因となった問題を調査できます。 1 つのジョブの実行の表示を参照してください。 短いネットワークの問題であったか、データの実際の問題であったかにかかわらず、それを修正し、Lakeflow ジョブで修復実行を開始できます。 失敗したタスクと依存タスクのみが実行され、以前の実行の成功結果が保持され、時間とコストが節約されます。ジョブ の失敗のトラブルシューティングと修復に関するページを参照してください。

ディザスター リカバリー パターンを構成する

Azure Databricks のようなクラウドネイティブな Data Analytics プラットフォームにとって、明確なディザスター リカバリー パターンは極めて重要です。 データ チームは、ハリケーン、地震、その他のソースなどの地域的な災害によって引き起こされたかどうかにかかわらず、クラウド サービス プロバイダーがサービス全体でリージョン全体で停止するまれな場合でも、Azure Databricks プラットフォームを使用できることが重要です。

多くの場合、Azure Databricks は、アップストリーム データ インジェスト サービス (バッチ/ストリーミング)、Azure Data Lake Storage などのクラウドネイティブ ストレージ、ビジネス インテリジェンス アプリなどのダウンストリーム ツールとサービス、オーケストレーション ツールなど、多くのサービスを含む、全体的なデータ エコシステムの中核となる部分です。 ユース ケースによっては、地域的なサービス全体の停止にとりわけ影響を受けやすい場合があります。

ディザスター リカバリーには、自然災害や人為的な災害が発生した後も、重要なテクノロジ インフラストラクチャおよびシステムの復旧または継続を可能にする一連のポリシー、ツール、手順が含まれます。 Azure のような大規模クラウド サービスは、多くの顧客にサービスを提供しており、1 つの障害に対する保護機能が組み込まれています。 たとえば、リージョンは複数の異なる電源に接続している建物のグループであり、その目的は、1 つの電源が失われてもリージョンが稼働を停止しないようにするためです。 ただし、クラウド リージョンの障害が発生する可能性はあり、障害の重大度とそのビジネスへの影響はさまざまに異なる場合があります。

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

「オペレーショナル エクセレンス - デプロイとワークロードを自動化する」を参照してください。

6.システムとワークロードを監視する

「オペレーショナル エクセレンス - 監視、アラート、ログを設定する」を参照してください。