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

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

1. 対障害設計

Delta Lake の使用

Delta Lake は、オープンソースのストレージ形式であり、データ レイクに信頼性を提供します。 Delta Lake は、ACID トランザクション、スキーマの適用と、スケーラブルなメタデータ処理を提供し、また、ストリーミングとバッチ データ処理を統合します。 Delta Lake は既存のデータ レイク上で実行され、Apache Spark API と完全に互換性があります。 Delta Lake on Azure Databricks を使用すると、ワークロードのパターンに基づいて Delta Lake を構成できます。 「Delta Lake とは」を参照してください。

分散コンピューティングに Apache Spark または Photon を使用する

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

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

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

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

• Databricks 自動ローダー: 自動ローダー は、ファイルのインジェストをストリーミングするための理想的なツールです。 このツールでは、JSON と CSV のために 復旧されたデータ をサポートしています。 たとえば JSON の場合、復旧されたデータ列には、解析されなかったデータが含まれます。これは、型の不一致のために指定されたスキーマから欠落したか、この列での大文字と小文字に不一致があったことが原因です。 復旧されたデータ列は、スキーマが推論されるときに、自動ローダーによって既定で _rescued_data として返されるスキーマの一部です。
• Delta Live Tables: 回復性のためにワークフローを構築するもう 1 つのオプションは、品質制約付きの Delta Live Tables を 使用することです。 「Delta Live Tables を使用してデータ品質を管理する」を参照してください。 Delta Live Tables では、無効なレコードについて保持、削除、および失敗という 3 つのモードがサポートされており、すぐに使用できます。 無効として識別されたレコードを検疫するためには、予想ルールを特定の方法で定義して、無効なレコードが別のテーブルに格納 (検疫) されるようにします。 「無効なデータの検疫」を参照してください。

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

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

• Databricks ジョブでは、失敗した実行を試行しなおすタイミングと回数を決定する、自動再試行ポリシー がサポートされています。
• また Delta Live Tables では、再試行のエスカレーションを使用して速度と信頼性のバランスを取ることで、障害復旧を自動化します。 「開発と運用のモード」を参照してください。

一方、ハングしているタスクはジョブ全体の終了を妨害するので、高いコストが発生する可能性があります。 Databricks ジョブでは、想定よりも長い時間がかかっているジョブを終了するための、タイムアウト構成がサポートされています。

スケーラブルで実稼働グレードのモデル提供用インフラストラクチャを使用する

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

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

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

可能な場合は、Databricks Data Intelligence プラットフォームの管理サービス (サーバーレス コンピューティング、モデル サービス、Delta Live Tables など) を活用します。 これらのサービスは、Databricks により (ユーザーによる余分な作業はなく) 信頼性の高いスケーラブルな手法で操作されることで、ワークロードの信頼性を高めます。

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

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

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

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

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

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

データをコピーまたは複製するとデータの冗長性が生じ、整合性とデータ系列性が失われます。また多くの場合、それぞれのアクセス許可が異なります。 これにより、レイクハウス内のデータの品質が低下します。 一時的または使い捨て用のデータのコピーは、それ自体が有害ではありません。これは時として、機敏性、実験、イノベーションを促進するために必要です。 ただし、これらのコピーが操作可能で、ビジネス上の意思決定に定期的に使用される場合は、これらがデータのサイロとなります。 これらのデータ サイロが相互の同期から外れていく場合、「どのデータ セットがマスターなのか?」 という疑問が生じ、データの整合性と品質に大きな悪影響を及ぼします。 また、「データの状態は最新に設定されているのか?」ということも問題になります。

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

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

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

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

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

この処理をさらに改善するために、Delta Live Tables には期待値のサポートがあります。 期待値によって、データ セットの内容に対するデータ品質制約が定義されます。 期待値は、説明とインバリアントのほか、レコードがインバリアントに失敗した場合に行われるアクションから構成されます。 クエリに対する期待値は、Python デコレーターまたは SQL 制約句を使用します。 「Delta Live Tables を使用してデータ品質を管理する」を参照してください。

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

特徴エンジニアリング、トレーニング、推論、監視パイプラインは、それぞれデータ パイプラインです。 これらは、他の運用 Data Engineering プロセスと同様に堅牢である必要があります。 すべての ML アプリケーションはデータ品質を重要視するため、ML データ パイプラインでは、データ品質の問題を監視および軽減するための体系的なアプローチを採用する必要があります。 ML 予測やモデル監視などからのデータを、他のデータと結合することを困難にするようなツールは避けてください。 これを実現する最も簡単な方法は、運用データの管理に使用されるのと同じプラットフォームで ML アプリケーションを開発することです。 たとえば、結果の管理と再現が困難なラップトップにトレーニング データをダウンロードする代わりに、クラウド ストレージ内でデータを保護し、そのストレージをトレーニング プロセスに対し使用可能にします。

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

バッチ ワークロード用に自動スケーリングを有効にする

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

ストリーミング ワークロードの場合、Databricks は、Delta Live Tables での自動スケーリングの使用を推奨しています。 「自動スケーリングを使用して効率を高め、リソースの使用量を削減する」を参照してください。

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

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

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

Delta Live Tables の拡張自動スケーリングを使用する

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

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

定期的なバックアップを作成する

障害から復旧するためには、定期的なバックアップが使用可能である必要があります。 Databricks Labs プロジェクトを 移行 することで、ワークスペース管理者は、ワークスペースのほとんどの資産をエクスポートしてバックアップを作成できます (このツールでは、バックグラウンドで Databricks CLI/API を使用します)。 「Databricks 移行ツール」を参照してください。 バックアップは、ワークスペースの復元、または移行の場合における新しいワークスペースへのインポートのどちらかに使用できます。

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

構造化ストリーミングは、ストリーミング クエリのためのフォールト トレランス性とデータの一貫性を提供します。 Azure Databricks ワークフローを使用すると、障害時に自動で再起動する構造化ストリーミング クエリを簡単に構成できます。 再起動されたクエリは、クエリが失敗したところから続行します。 「ワークフローを使って構造化ストリーミングのクエリ エラーから復旧する」を参照してください。

Delta のタイム トラベルに基づいて ETL ジョブを復旧する

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

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

Databricks ワークフローと組み込みの復旧機能を使用する

Databricks ワークフローは復旧用に構築されています。 マルチタスク ジョブ内のタスク (および、すべての依存タスクなど) が失敗した場合は、Azure Databricks Workflows の実行マトリックス ビューが利用できます。これにより、失敗の原因となった問題を調べることができます。 「ジョブの実行を表示する」を参照してください。 短時間のネットワークの問題であったか、データ内の実際の問題であったかにかかわらず、それを修正し、Azure Databricks ワークフローで修復の実行を開始できます。 これにより、失敗したタスクと依存タスクのみが実行され、前の実行からの適切な結果は保持されるので、時間とコストを節約します。

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

Azure Databricks のようなクラウド ネイティブの Data Analytics プラットフォームにとって、明確なディザスター リカバリー パターンは非常に重要です。 一部の企業にとっては、ハリケーンや地震などの地域的災害またはその他の事象が原因で、地域的なクラウド サービス プロバイダーのサービス全体が停止するといったまれな状況下でも、データ チームが Azure Databricks プラットフォームを使用できるということが非常に重要です。

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

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

ディザスター リカバリー戦略の根幹的な部分とは、戦略 (アクティブ/アクティブまたはアクティブ/パッシブ) の選択、適切なツールセットの選択、そして フェールオーバー と復元の両方をテストすることです。

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

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

6. モニター、アラート、ログ記録を設定する

オペレーショナル エクセレンスのベスト プラクティスに関する記事で、「 オペレーショナル エクセレンス - モニター、アラート、ログ記録を設定する」を参照してください。