信頼性のためのベスト プラクティス
この記事では、次のセクションでアーキテクチャの原則ごとに記載された 信頼性 のベスト プラクティスについて説明します。
1. 対障害設計
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として返されるスキーマの一部です。 - Delta Live Tables: 回復性のあるワークフローを構築するもう 1 つのオプションは、品質制約を持つ Delta Live Tables を使用することです。 「Delta Live Tables を使用してデータ品質を管理する」を参照してください。 Delta Live Tables では、無効なレコードについて保持、削除、および失敗という 3 つのモードがサポートされており、すぐに使用できます。 無効として識別されたレコードを検疫するためには、予想ルールを特定の方法で定義して、無効なレコードが別のテーブルに格納 (検疫) されるようにします。 「無効なデータの検疫」を参照してください。
ジョブの自動再試行と終了を構成する
分散システムは複雑であり、1 か所での障害がシステム全体に連鎖する可能性があります。
- Azure Databricks ジョブでは、失敗した実行を再試行するタイミングと回数を決定する、タスクの再試行ポリシーがサポートされています。 「再試行ポリシーの設定」を参照してください。
- タスクの想定完了時間や最大完了時間など、タスクに関する任意の期間しきい値を構成できます。
- Delta Live Tables でも、再試行のエスカレーションを使用して速度と信頼性のバランスを取ることで、エラーの回復を自動化します。 「開発と運用のモード」を参照してください。
一方、ハングアップしているタスクはジョブ全体の完了を妨げ、結果としてコストが高くなるおそれがあります。 Databricks ジョブでは、想定よりも長い時間がかかっているジョブを強制終了するための、タイムアウト構成がサポートされています。
スケーラブルな本番環境グレードのモデル サービング インフラストラクチャを使用する
バッチ推論とストリーミング推論の場合に、ジョブのスケジュール設定、再試行、自動スケーリングなどを活用するには、Azure Databricks ジョブと 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 の制約」を参照してください。
この処理をさらに改善するために、Delta Live Tables にはエクスペクテーション (期待値) のサポートがあります。 エクスペクテーションによって、データ セットの内容に対するデータ品質制約が定義されます。 エクスペクテーションは、説明と不変条件のほか、レコードが不変条件を満たさない場合に行われるアクションから構成されます。 クエリに対するエクスペクテーションには、Python デコレーターまたは SQL 制約句を使用します。 「Delta Live Tables を使用してデータ品質を管理する」を参照してください。
機械学習にデータ中心のアプローチを取り入れる
Databricks Data Intelligence プラットフォームにおける AI ビジョンの中核をなす基本原則は、機械学習に対するデータ中心のアプローチです。 生成 AI が一層普及するなかで、この観点は依然として重要です。
ML プロジェクトのコア コンポーネントは、データ パイプラインであると単純に捉えることができます。特徴エンジニアリング、トレーニング、モデル デプロイ、推論、監視パイプラインはすべてデータ パイプラインです。 そのため、ML ソリューションを運用するには、予測、監視、特徴のテーブルのデータを他の関連データとマージする必要があります。 基本的に、これを実現する最も簡単な方法は、運用データの管理に使用しているのと同じプラットフォームで AI 搭載ソリューションを開発することです。 「データ中心の MLOps と LLMOps」を参照してください
3. 自動スケーリングを設計する
ETL ワークロードの自動スケーリングを有効にする
自動スケーリングを使用すると、クラスターのサイズをワークロードに基づいて自動的に変更できます。 自動スケーリングは、コストとパフォーマンスの視点から、多くのユース ケースとシナリオにメリットをもたらします。 このドキュメントでは、自動スケーリングを使用するかどうかの判断、および最大のベネフィットを得る方法を決定する上での考慮事項について説明します。
ストリーミング ワークロードの場合、Databricks は、Delta Live Tables での自動スケーリングの使用を推奨しています。 Databricks 拡張自動スケーリングでは、ワークロード ボリュームに基づいてクラスター リソースを自動的に割り当てることでクラスター使用率が最適化され、パイプラインのデータ処理待機時間への影響が最小限に抑えられます。
SQL ウェアハウスの自動スケーリングを有効にする
SQL ウェアハウスのスケーリング パラメーターは、ウェアハウスに送信されたクエリが分散されるクラスターの最小数と最大数を指定します。 既定値では自動スケーリングなしで、クラスターの数はともに 1 です。
特定のウェアハウスでより多くの同時実行ユーザーを処理するには、クラスター数を増やします。 Azure Databricks によるウェアハウスのクラスターの追加または削除の方法については、「SQL ウェアハウスのサイズ設定、スケーリング、およびキューの動作」をご覧ください。
4. 復旧プロシージャをテストする
構造化ストリーミングのクエリ エラーから復旧する
構造化ストリーミングは、ストリーミング クエリのためのフォールト トレランス性とデータの一貫性を提供します。 Databricks ジョブを使用すると、障害時に自動で再起動するように、構造化ストリーミング クエリを簡単に構成できます。 ストリーミング クエリに対してチェックポイントを有効にすると、失敗後にクエリを再起動できます。 再開されたクエリは、失敗したクエリが中断した場所から続行されます。 「構造化ストリーミングのチェックポイント」と「構造化ストリーミングの生産に関する考慮事項」を参照してください。
データのタイム トラベル機能を使用して ETL ジョブを回復する
徹底的なテストを行なったとしても、運用環境でジョブが失敗したり、予期しない、無効なデータを生成したりすることがあります。 問題の原因をつきとめ、この問題を最初に引き起こしたパイプラインを修正した後に、追加のジョブを行うことで、これを解決できる場合があります。 ただし、多くの場合、この作業は単純ではなく、問題となっているジョブをロールバックする必要が生じます。 Delta タイム トラベルを使用すれば、ユーザーは古いバージョンまたはタイムスタンプに簡単に変更をロールバックし、パイプラインの修復を行なった上で、そのパイプラインを再起動できます。
これを行うための便利な方法は、RESTORE コマンドの使用です。
組み込みの回復機能を備えたジョブ自動化フレームワークを活用する
Databricks ジョブ は回復用に設計されています。 マルチタスク ジョブ内のタスク (およびその結果としてすべての依存タスク) が失敗した場合、Azure Databricks ジョブの実行マトリックス ビューを利用して、失敗の原因となった問題を調べることができます。「ジョブの実行を表示する」を参照してください。 短時間のネットワークの問題であったか、データ内の実際の問題であったかにかかわらず、それを修正し、Azure Databricks ジョブで修復の実行を開始できます。 そこでは、失敗したタスクと依存タスクのみが実行され、それより前の実行から得られた適切な結果は保持されるので、時間とコストを節約できます。「ジョブの失敗のトラブルシューティングと修復」を参照してください
ディザスター リカバリー パターンを構成する
Azure Databricks のようなクラウドネイティブな Data Analytics プラットフォームにとって、明確なディザスター リカバリー パターンは極めて重要です。 ハリケーンや地震などの地域的災害またはその他の事象が原因で、ある地域でクラウド サービス プロバイダーのサービス全体が停止するといったまれな状況下でも、データ チームが Azure Databricks プラットフォームを使用できることは必須といえます。
Azure Databricks は、多くの場合、アップストリームのデータ インジェスト サービス (バッチ/ストリーミング)、Azure Data Lake Storage Gen2 のようなクラウド ネイティブ ストレージ、ビジネス インテリジェンス アプリのようなダウンストリームのツールとサービス、オーケストレーション ツールといった多くのサービスを含むデータ エコシステム全体の中核部分です。 ユース ケースによっては、地域的なサービス全体の停止にとりわけ影響を受けやすい場合があります。
ディザスター リカバリーには、自然災害や人為的な災害が発生した後も、重要なテクノロジ インフラストラクチャおよびシステムの復旧または継続を可能にする一連のポリシー、ツール、手順が含まれます。 Azure のような大規模クラウド サービスは、多くの顧客にサービスを提供しており、1 つの障害に対する保護機能が組み込まれています。 たとえば、リージョンは複数の異なる電源に接続している建物のグループであり、その目的は、1 つの電源が失われてもリージョンが稼働を停止しないようにするためです。 ただし、クラウド リージョンの障害が発生する可能性はあり、障害の重大度とそのビジネスへの影響はさまざまに異なる場合があります。
5. デプロイとワークロードを自動化する
「オペレーショナル エクセレンス - デプロイとワークロードを自動化する」を参照してください。
6.システムとワークロードを監視する
「オペレーショナル エクセレンス - 監視、アラート、ログを設定する」を参照してください。