Databricksワークスペースのディザスターリカバリーの実装

Original: Implementing Disaster Recovery for a Databricks Workspace

翻訳: junichi.maruyama

この投稿はDisaster Recovery Overview, Strategies, and Assessment や Disaster Recovery Automation and Tooling for a Databricks Workspaceの続きです。

ディザスタリカバリとは、自然災害や人為的な災害の後に、重要な技術インフラやシステムの復旧や継続を可能にする一連の方針、ツール、手順のことを指します。AWS、Azure、Google Cloud、SaaS企業などのクラウドサービスプロバイダーが単一障害点に対する安全策を構築しても、障害は発生します。障害の深刻度や組織への影響はさまざまです。クラウドネイティブなワークロードの場合、明確な災害復旧パターンが重要です。

Disaster Recovery Setup for Databricks

このDRブログシリーズのこれまでのブログ記事で、計画、DRソリューション戦略の設定、自動化のステップ1から4までをご覧ください。このブログ記事のステップ5と6では、DRセットアップを監視、実行、検証する方法について説明します。

Disaster Recovery ソリューション

典型的なDatabricksの実装には、ノートブックのソースコード、クエリ、ジョブ設定、クラスタなどの重要な資産が多数含まれており、中断を最小限に抑え、エンドユーザーへのサービス継続を保証するために、スムーズに復旧する必要があります。

ハイレベルなDRの考慮事項:

• Terraform (TF)によりアーキテクチャが複製可能であることを確認し、この環境を別の場所で作成および再作成できるようにします。
• Databricks Repos (AWS | Azure | GCP) を使用して、サポートされている任意のファイル (AWS | Azure | GCP) の Notebooks とアプリケーションコードを同期します。
• Terraform Cloud を使用して、状態を維持しながらインフラとアプリのパイプラインのTF run（planとapply）をトリガーします。
• Amazon S3、Azure ADLS、GCSなどのクラウドストレージアカウントからDRリージョンにデータをレプリケートする。AWSの場合、S3 Multi-Region Access Pointsを使用してデータを保存し、データが異なるAWSリージョンの複数のS3バケットにまたがるようにすることも可能です。
• Databricksのクラスタ定義には、アベイラビリティゾーンに固有の情報を含めることができます。AWSでDatabricksを実行する場合は、“auto-az”クラスタ属性を使用し、リージョナルフェイルオーバー時の問題を回避します。
• DRリージョンでの構成ドリフトを管理する。インフラ、データ、構成がDRリージョンで必要な状態にあることを確認する。
• 本番用のコードとアセットについては、本番システムへの変更を両方のリージョンに同時にプッシュする CI/CD ツーリングを使用します。例えば、ステージング/開発から本番環境にコードや資産をプッシュする場合、CI/CDシステムにより、両方のリージョンで同時に利用できるようにする。
• Gitを使用して、TFファイルとインフラのコードベース、ジョブ設定、クラスタ設定を同期します。
  • セカンダリーリージョンでTF `apply`を実行する前に、リージョン固有の設定を更新する必要があります。.

モニタリングと検出

ワークロードが健全な状態でないことをできるだけ早く知ることは、災害を迅速に宣言し、インシデントから回復するために極めて重要です。この応答時間と適切な情報が、積極的な復旧目標を達成するために重要です。インシデントの検出、通知、エスカレーション、発見、宣言などを計画や目標に組み込んで、現実的で達成可能な目標を提供することが重要です。

サービス状況通知

Databricks ステータスページでは、コントロールプレーン用のすべてのコア Databricks サービスの概要が表示されます。ステータスページを表示することで、特定のサービスのステータスを簡単に確認することができます。オプションで、個々のサービスコンポーネントのステータスアップデートを購読することもでき、購読しているステータスが変更されるたびにアラートが送信されます。

データプレーンに関するステータスチェックは、AWS Health Dashboard, Azure Status Page,  GCP Service Health Pageを使用して監視する必要があります。

AWSとAzureは、ツールがステータスチェックのインジェストとアラートに使用できるAPIエンドポイントを提供しています。

インフラストラクチャの監視とアラート

インフラからデータを収集・分析するツールを使用することで、チームは長期的にパフォーマンスを追跡することができます。これにより、ダウンタイムやサービス低下を最小限に抑えることができます。さらに、長期的なモニタリングにより、最適化とアラートの基準として必要となるピークパフォーマンスのベースラインが確立されます。

DRの文脈では、組織はサービスプロバイダーからのアラートを待つことができないかもしれません。RTO/RPO要件がサービスプロバイダーからのアラートを待つほど寛容であっても、ベンダーのサポートチームにパフォーマンスの低下を事前に通知することで、より早い段階でコミュニケーションラインを開くことができます。

DataDog と Dynatraceは、AWS、Azure、GCP、Databricksクラスタ用の統合とエージェントを提供する人気のモニタリングツールです。

Health Checks

最も厳しいRTO要件の場合、Databricksサービスや、ワークロードがデータプレーンで直接インターフェースする他のサービス（オブジェクトストアやクラウドプロバイダのVMサービスなど）のヘルスチェックに基づいて、自動フェールオーバーを実装できます。

ユーザーエクスペリエンスを代表する、主要業績評価指標に基づく健全性チェックを設計する。浅いハートビート・チェックでは、システムが動作しているかどうか、つまりクラスタが稼働しているかどうかを評価できます。一方、個々のノードのCPU、ディスク使用量、各アクティブステージまたはキャッシュされたパーティションにわたるSparkメトリクスなどのシステムメトリクスなどのディープヘルスチェックは、浅いハートビートチェックを超えて、パフォーマンスの著しい劣化を判断する。ワークロードの機能性とベースライン性能に応じて、複数のシグナルに基づくディープヘルスチェックを使用します。

ヘルスチェックを使用してフェイルオーバーの決定を完全に自動化する場合は、注意が必要です。誤検知やアラームが発生しても、ビジネスがその影響を吸収できるのであれば、フェイルオーバーする必要はない。誤ったフェイルオーバーは、可用性のリスクやデータ破損のリスクをもたらし、時間的にも高価な操作となります。アラームが作動した場合の判断は、オンコールのインシデント・マネージャーなど、人間が行うことが推奨されます。不必要なフェイルオーバーは大惨事になる可能性があり、追加レビューはフェイルオーバーが必要かどうかの判断に役立ちます。

DRソリューションの実行

ディザスターリカバリーソリューションには、高いレベルで2つの実行シナリオが存在します。最初のシナリオでは、DR サイトは一時的なものと見なされます。プライマリサイトでサービスが回復したら、DRサイトから恒久的なプライマリサイトへのフェイルオーバーをオーケストレーションする必要があります。DRサイトがアクティブな間は、新しい成果物の作成を制限することは、一時的であり、このシナリオのフェイルバックを複雑にするため、推奨されません。逆に、2番目のシナリオでは、DRサイトが新しいプライマリサイトに昇格するため、ユーザーはサービスの復旧を待つ必要がなく、より早く作業を再開することができます。さらに、このシナリオではフェイルバックは不要ですが、旧プライマリサイトを新しいDRサイトとして準備する必要があります。

いずれのシナリオでも、DRソリューションの範囲内の各領域は、必要なサービスをすべてサポートする必要があり、安全策として、ターゲットワークスペースが良好な動作状態にあることを検証するプロセスが存在する必要があります。検証には、模擬認証、自動クエリ、APIコール、ACLチェックが含まれる場合があります。

フェイルオーバー

DR サイトへのフェイルオーバーをトリガーする場合、システムを優雅にシャットダウンすることが可能である と仮定することはできない。プライマリサイトで実行中のサービスのシャットダウンを試み、各サービスのシャットダウンステータスを記録し、定義された時間間隔で適切なステータスを持たないサービスのシャットダウンを継続する必要があります。これにより、プライマリサイトとDRサイトの両方でデータが同時に処理されるリスクを低減し、データの破損を最小限に抑え、サービスが復旧した後のフェイルバックプロセスを容易にすることができます。

DRサイトを起動するためのハイレベルな手順は以下の通りです：

1. プライマリ サイトでシャットダウン プロセスを実行し、プール、クラスタ、およびプライマリ リージョブのスケジュール ジョブを無効にして、障害のあるサービスがオンラインに戻った場合にプライマリ リージョンが新しいデータの処理を開始しないようにします。
2. DRサイトのインフラストラクチャと構成が最新であることを確認します。
3. 最新の同期されたデータの日付を確認します。ディザスターリカバリー業界用語を参照してください。このステップの詳細は、データの同期方法と独自のビジネス・ニーズによって異なります。
4. データソースを安定させ、それらがすべて利用可能であることを確認します。オブジェクトストレージ、データベース、パブ/サブシステムなど、重要な外部データソースをすべて含めます。
5. プラットフォームユーザーに情報を提供する。
6. 関連するプールを開始する（またはmin_idle_instancesを関連する数字に増やす）
7. 関連するクラスタ、ジョブ、およびSQL Warehousesを開始します（終了していない場合）
8. ジョブの同時実行を変更し、関連するジョブを実行する。これらは1回限りの実行または定期的な実行となる可能性があります。
9. ジョブスケジュールを有効にする。
10. DatabricksワークスペースのURLまたはドメイン名を使用している外部ツールについて、新しいコントロールプレーンを考慮し、設定を更新します。例えば、REST API や JDBC/ODBC 接続の URL を更新します。Databricks Web アプリケーションの顧客向け URL は、コントロール・プレーンが変更されると変更されるため、組織のユーザーに新しい URL を通知してください。

Failback

Failback中にPrimaryサイトに戻ることは、制御が容易であり、メンテナンスウィンドウで行うことができます。FailbackはFailoverと非常によく似たプランに従いますが、4つの大きな例外があります。:

1. ターゲットリージョンはプライマリーリージョンとなります。
2. フェイルバックは制御されたプロセスであるため、シャットダウンは1回限りのアクティビティであり、オンラインに戻ったサービスをシャットダウンするためのステータスチェックは必要ありません。
3. DR サイトは、今後のフェイルオーバーのために必要に応じてリセットする必要があります。
4. 得られた教訓は、DRソリューションに反映させ、将来の災害発生時に備えてテストする必要があります。

まとめ

ディザスタリカバリのセットアップが適切に機能するよう、実際の環境下で定期的にテストしてください。必要なときに使えないディザスタリカバリ・ソリューションを持っていても、あまり意味がありません。組織によっては、数カ月ごとに地域間のフェイルオーバーとフェイルバックを実行してDRインフラをテストしています。定期的にDRサイトへのフェイルオーバーを行うことで、前提条件とプロセスがRPOとRTOの面で復旧要件を満たしているかどうかをテストします。また、組織の緊急時のポリシーと手順が最新であることを確認します。一般的なプロセスや構成に必要な組織の変更をテストします。ディザスタリカバリプランは展開パイプラインに影響を与えるので、同期を保つ必要があるものをチームに認識させるようにします。