信頼性のためのベストプラクティス
これらのベストプラクティスは、障害から回復し、稼働し続けるDatabricks上のシステムを構築するのに役立ちます。これらは、以下のセクションのアーキテクチャ原則に基づいて構成されています。
1. 失敗を想定した設計
ACIDトランザクションをサポートするデータ形式を使用する
ACIDトランザクションは、データの完全性と一貫性を維持するための重要な機能です。 ACIDトランザクションをサポートするデータ形式を選択すると、よりシンプルで信頼性の高いパイプラインを構築できます。
Delta Lake は、ACIDトランザクション、スキーマ強制、スケーラブルなメタデータ処理を提供し、ストリーミングとバッチ データ処理を統合するオープンソース ストレージ フレームワークです。Delta Lake は Apache Spark API と完全に互換性があり、構造化ストリーミングとの緊密な統合を実現するように設計されているため、バッチ操作とストリーミング操作の両方でデータの 1 つのコピーを簡単に使用し、大規模な増分処理を提供できます。
すべてのワークロードに回復力のある分散データエンジンを使用
DatabricksのコンピュートエンジンであるApache Sparkは、レジリエントな分散データ処理に基づいています。内部Sparkタスクが期待どおりに結果を返さない場合、Apache Sparkは不足しているタスクを自動的に再スケジュールし、ジョブ全体の実行を続行します。これは、短時間のネットワークの問題や失効したSpot VMのような、コード外の障害に役立ちます。SQL APIとSpark DataFrame APIの両方と連携することで、この回復力はエンジンに組み込まれています。
Databricksプラットフォームでは、完全に C++ で記述されたネイティブのベクトル化エンジンであるPhotonは、Apache Spark APIsと互換性のある高性能コンピュートです。
無効なデータや不適合なデータを自動的にレスキュー
無効なデータや不適合なデータがあると、確立されたデータ形式に依存するワークロードがクラッシュする可能性があります。 プロセス全体のエンドツーエンドの耐障害性を向上させるには、取り込み時に無効なデータや不適合なデータを除外することをお勧めします。 レスキューされたデータのサポートにより、取り込みやETL中にデータが失われたり見逃されたりすることはありません。 救出されたデータ列には、指定されたスキーマに存在しないか、型の不一致があったか、レコードまたはファイルの列本体がスキーマの列本体と一致しなかったために解析されなかったデータが含まれています。
-
Databricks Auto Loader: Auto Loader は、ファイル インジェストをストリーミングするための理想的なツールです。 JSONおよびCSVの レスキューされたデータ をサポートします。 たとえば、JSON の場合、救出されたデータ列には、指定されたスキーマに欠落していた、型の不一致があった、または列の大文字と小文字が一致しなかったなどの理由で解析されなかったデータが含まれます。 レスキューされたデータ列は、スキーマが推論されているときに Auto Loader によって返されるスキーマの一部
_rescued_dataデフォルトによって返されます。 -
パイプライン: レジリエンスのためのワークフローを構築するもう1つのオプションは、品質制約付きのLakeFlow Pipelinesを使用することです。パイプラインのエクスペクテーションを使用してデータ品質を管理するを参照してください。LakeFlow Pipelinesは、defaultで3つのモード、つまり無効なレコードの保持、削除、および失敗をサポートしています。識別された無効なレコードを隔離するため、無効なレコードが別のテーブルに保存（「隔離」）されるように、エクスペクテーションルールを特定の方法で定義できます。無効なレコードの検疫を参照してください。
自動再試行と終了のためのジョブの構成
分散システムは複雑であり、ある時点での障害がシステム全体に連鎖する可能性があります。
- Lakeflow Jobs は、失敗した実行を再試行するタイミングと回数を決定するタスクの再試行ポリシー をサポートしています。 再試行 ポリシーの設定を参照してください。
- タスクの 予想完了時間 やタスクの最大完了時間など、タスクの期間のしきい値をオプションで構成できます。
- LakeFlow Pipelines は、速度と信頼性のバランスを取るために、エスカレートする再試行を使用して障害復旧も自動化します。「ランの動作の更新」を参照してください。
一方、ハング タスクは、ジョブ全体を完了させず、コストが高くなる可能性があります。Lakeflow ジョブは、予想以上に時間がかかるジョブを強制終了するためのタイムアウト設定をサポートしています。
スケーラブルで本番運用グレードのモデルサービングインフラストラクチャを使用
バッチ推論とストリーミング推論の場合は、 Lakeflow ジョブと MLflow を使用してモデルを Apache Spark UDFとしてデプロイし、ジョブのスケジューリング、再試行、オートスケールなどを活用します。 バッチ推論とバッチ予測のためのモデルのデプロイを参照してください。
モデルサービング は、リアルタイム モデルサービングのためのスケーラブルな本番運用グレードのインフラストラクチャを提供します。 MLflow を使用して機械学習モデルを処理し、それらを REST API エンドポイントとして公開します。 この機能はサーバレス コンピュートを使用するため、エンドポイントと関連するコンピュート リソースは Databricks クラウド アカウントで管理および実行されます。
可能な場合はマネージドサービスを使用する
次のようなDatabricks Data + AIプラットフォームのマネージドサービス(Serverless コンピュート) を活用します：
これらのサービスは、Databricks によって信頼性と拡張性に優れた方法で運用されているため、ワークロードの信頼性が向上します。
2. データ品質を管理する
階層型ストレージアーキテクチャを使用する
階層構造を構築し、データが各階層を通過するにつれてデータ品質が向上するようにすることで、データをキュレーションします。このパターンはメダリオンアーキテクチャとして知られています。 一般的なレイヤリング手法は次のとおりです。
- 生データ層（ブロンズ）： ソースデータはレイクハウスの最初の層に取り込まれ、そこに永続化される必要があります。下流のすべてのデータが生データ層から作成される場合、必要に応じてこの層から後続の層を再構築することが可能です。テーブルが削除された場合でも生データを保持するには、ブロンズ レイヤー データに外部テーブルを使用します。
- キュレーション層（シルバー）： 第2層の目的は、クレンジング、精製、フィルタリング、集約されたデータを保持することです。このレイヤーの目的は、あらゆる役割と機能にわたる分析とレポート作成のための、堅牢で信頼性の高い基盤を提供することです。マネージドテーブルをスキーマ強制とデータ品質チェックとともに使用します。
- 最終層（ゴールド）： 第3層は、ビジネスまたはプロジェクトのニーズに基づいて構築されます。これは、他の事業部門やプロジェクトに対してデータ製品として異なる視点を提供し、セキュリティ要件（匿名化データなど）に合わせてデータを準備したり、パフォーマンスを最適化したり（事前集計ビューなど）します。この層のデータ製品は、ビジネスにおける真実とみなされます。ビジネス ロジックの検証とSLA保証を備えたマネージドテーブルを使用します。
最終レイヤーには、高品質のデータのみが含まれ、ビジネスの観点から完全に信頼されている必要があります。
実装上の考慮事項 ：
- Unity Catalogスキーマを使用してブロンズ、シルバー、ゴールドレイヤーを整理します (例:
sales.bronze_transactions、sales.silver_transactions、sales.gold_metrics) - Delta Lake のテーブルプロパティを
delta.enableChangeDataFeedのように設定して、レイヤー間の変更を追跡します。 - データがレイヤーを通過する際に最適なファイルサイズを維持するために、自動最適化を有効にします。
- Deltaライブ テーブルまたは構造化ストリーミングを使用して増分処理を実装し、レイヤーを効率的に更新します
- 各レイヤー境界で明確なデータ品質基準を設定する
メダリオンアーキテクチャの実装に関する詳細なガイダンスについては、 「メダリオンアーキテクチャの設計」を参照してください。
データの冗長性を減らすことでデータの完全性を向上させる
データをコピーまたは複製するとデータの冗長性が生じ、整合性の喪失、データリネージの喪失につながり、多くの場合、アクセス許可も異なります。これによりDatabricksのデータの品質が低下します。
データの一時的または使い捨てのコピーは、それ自体は有害ではありません - 敏捷性、実験、および革新性を高める必要がある場合があります。 しかし、これらのコピーが運用可能になり、ビジネス上の意思決定に定期的に使用されるようになると、データのサイロ化が進んでしまいます。 これらのデータ サイロが同期しなくなると、データの完全性と品質に大きな悪影響を及ぼし、「マスターはどのデータ セットですか」や「データ セットは最新ですか」などの疑問が生じます。
スキーマをアクティブに管理する
制御されていないスキーマの変更は、無効なデータや、これらのデータセットを使用するジョブの失敗につながる可能性があります。 Databricks には、スキーマを検証して適用するためのいくつかの方法があります。
- Delta Lake は、スキーマのバリエーションを自動的に処理して、インジェスト中に不適切なレコードが挿入されるのを防ぐことで、スキーマの検証とスキーマ強制をサポートします。 スキーマ強制を参照してください。
- Auto Loader は、データの処理中に新しい列の追加を検出します。デフォルトでは、新しい列を追加すると、ストリームは
UnknownFieldExceptionで停止します。 Auto Loader では、 スキーマ進化のためのいくつかのモードがサポートされています。
制約とデータのエクスペクテーションを使用する
Delta テーブルは、テーブルに追加されたデータの品質と整合性が自動的にチェックされるようにする標準 SQL 制約管理句をサポートしています。 制約に違反すると、Delta Lake は InvariantViolationException エラーをスローして、新しいデータを追加できないことを示します。Databricks の制約を参照してください。
この処理をさらに改善するために、LakeFlow Pipelinesは期待値をサポートしています：期待値は、データセットの内容に対するデータ品質制約を定義します。期待値は、説明、不変式、およびレコードが不変式に違反した場合に実行されるアクションで構成されます。クエリーに対するエクスペクテーションは、Python デコレータまたは SQL 制約句を使用します。パイプラインのエクスペクテーションを使用してデータ品質を管理するを参照してください。
機械学習にデータ中心のアプローチを取る
Databricks Data + AIプラットフォームのAIビジョンの核心であり続ける指針は、Machine Learningへのデータ中心アプローチです。AIが普及するにつれて、この視点は依然として重要です。
すべてのMLプロジェクトのコアコンポーネントはシンプルにデータパイプラインとして考えることができます: 特徴量エンジニアリング、トレーニング、モデルのデプロイメント、推論、監視パイプラインはすべてデータパイプラインです。そのため、 ML ソリューションを運用するには、予測結果、監視、および特徴量テーブルと他の関連データとマージする必要があります。 基本的に、これを実現する最も簡単な方法は、本番運用データの管理に使用されているのと同じプラットフォーム上で AIを活用したソリューションを開発することです。 データ中心の MLOps と LLMOps を参照してください。
3. オートスケールの設計
ETLワークロードのオートスケールを有効にする
オートスケール を使用すると、ワークロードに基づいてクラスターのサイズを自動的に変更できます。 オートスケールは、コストとパフォーマンスの両方の観点から、多くのユースケースとシナリオにメリットをもたらします。 ドキュメントには、オートスケールを使用するかどうか、および最大限のメリットを得る方法を決定するための考慮事項が記載されています。
ストリーミング ワークロードの場合、Databricks は Lakeflow pipelines をオートスケールとともに使用することをお勧めします。Databricks 強化されたオートスケールは、ワークロードのボリュームに基づいてクラスター リソースを自動的に割り当てることでクラスターの利用率を最適化し、パイプラインのデータ処理レイテンシへの影響を最小限に抑えます。
SQLウェアハウスのオートスケールの有効化
SQLウェアハウスの スケーリング パラメーターは、ウェアハウスに送信されたクエリが分散されるクラスターの最小数と最大数を設定します。デフォルトはオートスケールなしの1つのクラスターです。
特定のウェアハウスでより多くの並列ユーザーを処理するには、クラスターの数を増やします。 Databricks でウェアハウスにクラスターを追加する方法とウェアハウスからクラスターを削除する方法については、「ウェアハウスのサイズ設定、スケーリング、キューイングの動作SQL」を参照してください。
4. 回復手順をテストします
構造化ストリーミング クエリの失敗からの復旧
構造化ストリーミングは、ストリーミング クエリのフォールト トレランスとデータの一貫性を提供します。Lakeflowジョブを使用すると、失敗したときに自動的に再起動するように構造化ストリーミングクエリを簡単に構成できます。ストリーミング クエリのチェックポイント設定を有効にすると、失敗後にクエリを再起動できます。再開されたクエリは、失敗したクエリが中断したところから続行されます。構造化 ストリーミングについては、構造化ストリーミング チェックポイント および 本番運用に関する考慮事項を参照してください。
データタイムトラベル機能を使用した ETL ジョブの回復
徹底的なテストにもかかわらず、ジョブが本番運用で失敗したり、予期しないデータや無効なデータが生成されたりすることがあります。 これは、問題の原因を理解し、最初に問題の原因となったパイプラインを修正した後で、追加のジョブで修正できる場合があります。 ただし、多くの場合、これは簡単ではなく、問題のジョブをロールバックする必要があります。 Deltaのタイムトラベル を使用すると、ユーザーは変更を古いバージョンまたはタイムスタンプに簡単にロールバックし、パイプラインを修復し、固定パイプラインを再開できます。
これを行う便利な方法は、 RESTORE コマンドです。
組み込みリカバリを備えたジョブ自動化フレームワークを活用
Lakeflowジョブはリカバリ用に設計されています。マルチタスク ジョブ内のタスク (およびすべての依存タスク) が失敗した場合、ジョブは、エラーの原因となった問題を調査できる実行のマトリックス ビューを提供します。「 1 つのジョブの実行を表示する」を参照してください。 それが短いネットワークの問題であったか、データ内の実際の問題であったかにかかわらず、それを修正して Lakeflow ジョブで修復実行を開始できます。 失敗したタスクと依存タスクのみを実行し、以前の実行の成功した結果を保持し、時間とコストを節約します ( 「ジョブの失敗のトラブルシューティングと修復」を参照してください)。
高可用性とディザスタリカバリを構成する
高可用性戦略を実施する
ダウンタイムを最小限に抑え、事業継続性を確保するために、高可用性を考慮したDatabricksの導入設計を行いましょう。
コントロールプレーンの高可用性 ： Databricks 、お客様による設定を必要とせずに、コントロールプレーンに対して99.9%のSLAを提供します。 コントロールプレーンは、複数の可用性ゾーンに自動的に展開されます。
コンピュート高可用性 : 異なるゾーンにサブネットを提供することで、複数の可用性ゾーンにクラスター ノードを展開します。 Databricksは、耐障害性を確保するためにノードを自動的に分散します。一時的な障害から自動的に復旧するように、ジョブの再試行を設定します。
ストレージの高可用性 ：クラウドプロバイダーの冗長化オプション（AzureのZRS、AWS/GCPのマルチAZレプリケーションなど）を使用して、ゾーン障害から保護します。
ネットワークの高可用性 ：単一障害点を排除するために、ネットワークインフラストラクチャ（サブネット、NATゲートウェイ、VPN接続）を複数の可用性ゾーンに展開します。
HA 構成の展開ガイダンスについては、 「フェーズ 10: 高可用性の設計とディザスタリカバリ」を参照してください。
ディザスタリカバリパターンを構成する
Databricksのようなクラウドネイティブ データ分析プラットフォームでは、明確なディザスタリカバリ パターンが重要です。ハリケーン、地震、その他の発生源などの地域災害によって引き起こされたかどうかにかかわらず、クラウド サービス プロバイダーが地域的なサービス全体で停止するというまれな場合でも、データ チームが Databricks プラットフォームを使用できることが重要です。
Databricks は、多くの場合、アップストリーム データ取り込み サービス (バッチ/ストリーミング)、 Amazon S3などのクラウドネイティブ ストレージ、ビジネスインテリジェンス アプリなどのダウンストリーム ツールとサービス、オーケストレーション ツールなど、多くのサービスを含む全体的なデータ エコシステムの中核部分です。 ユースケースの中には、リージョン全体のサービス停止に特に敏感なものがあります。
ディザスタリカバリには、自然災害または人為的災害後に重要なテクノロジーインフラストラクチャとシステムの回復または継続を可能にする一連のポリシー、ツール、および手順が含まれます。 AWS のような大規模なクラウド サービスは、多くの顧客にサービスを提供し、1 つの障害に対する保護を組み込みます。たとえば、リージョンは、1 回の停電によってリージョンがダウンしないように、異なる電源ソースに接続された建物のグループです。 ただし、クラウドリージョンの障害が発生する可能性があり、障害の重大度とビジネスへの影響は異なる場合があります。
ディザスタリカバリの実装 :
- 組織の復旧時間目標（RTO）と復旧ポイント目標（RPO）を定義してください。
- インフラストラクチャ・アズ・コード（Terraform、アセットバンドル）を使用して、DRリージョンでワークスペースを迅速に再構築します。
- メタストアのバックアップとインポート手順を使用して、 Unity Catalogメタデータを複製します。
- 重要なデータセットにディープクローンを使用して DR リージョンへのDeltaテーブル レプリケーションを実装する
- クラウドプロバイダーのストレージレプリケーションを設定して、データの自動レプリケーションを実現する
- 災害復旧手順を定期的にテストして、準備状況を確認し、復旧プロセスを改善します。
ステップバイステップの DR 構成ガイダンスについては、 「フェーズ 10: 高可用性とディザスタリカバリの設計」を参照してください。
5. デプロイとワークロードを自動化する
オペレーショナル エクセレンス - デプロイとワークロードの自動化を参照してください。
6. システムとワークロードを監視する
オペレーショナル・エクセレンス - モニタリング、アラート、ロギングの設定を参照してください。