ディザスタリカバリ

明確なディザスタリカバリパターンは、 Databricksなどのクラウドネイティブデータ分析プラットフォームにとって重要です。ハリケーンや地震などの地域的な災害、またはその他の原因によって、地域全体のクラウドサービスプロバイダーが停止するというまれな事態が発生した場合でも、データチームがDatabricksプラットフォームを使用できることが重要です。

Databricks 、上流のデータ取り込みサービス (バッチ/ストリーミング)、Google Google Cloud Storageインテリジェントアプリなどの下流のツールとサービス、オーケストレーションツールなど、多くのサービスを含む全体的なデータエコシステムの中核となることがよくあります。一部のユースケースは、地域全体のサービス停止の影響を特に受けやすい場合があります。

この記事では、 Databricksプラットフォームの地域間ディザスタリカバリソリューションを成功させるための概念とベストプラクティスについて説明します。

ディザスタリカバリの概要

ディザスタリカバリには、自然災害や人為的災害が発生した後に重要な技術インフラストラクチャとシステムを復旧または継続できるようにする一連のポリシー、ツール、および手順が含まれます。 Google クラウドのような大規模なクラウドサービスは、多くの顧客にサービスを提供しており、単一の障害に対しても防御力を発揮します。たとえば、リージョンとは、単一の電源喪失によってリージョンがシャットダウンされないことを保証するため、異なる電源に接続された建物のグループです。ただし、クラウドリージョンの障害が発生する可能性があり、その中断の程度と組織への影響はさまざまです。

ディザスタリカバリ計画を実施する前に、ディザスタリカバリ(DR) と高可用性(HA) の違いを理解することが重要です。

高可用性は、システムの回復力特性です。高可用性は、通常、一貫したアップタイムまたはアップタイムの割合の観点から定義される最小レベルの運用パフォーマンスを保証します。高可用性は、プライマリシステムの機能として設計することによって、(プライマリシステムと同じリージョンに)実装されます。たとえば、Google クラウドのようなクラウドサービスにはGoogle Cloud Storageなどの高可用性サービスがあります。高可用性を実現するために、Databricks の顧客による特別な明示的な準備は必要ありません。

対照的に、ディザスタリカバリ計画では、重要なシステムのより大規模な地域的停止に対処するために、特定の組織に適した決定とソリューションが必要です。この記事では、一般的なディザスタリカバリの用語、一般的なソリューション、およびDatabricksを使用したディザスタリカバリプランのベストプラクティスについて説明します。

用語

地域の用語

この記事では、リージョンに次の定義を使用します。

プライマリリージョン: ユーザーが典型的な毎日のインタラクティブおよび自動データ分析ワークロードを実行する地理的リージョン。
セカンダリリージョン: プライマリリージョンの停止中に IT チームがデータ分析ワークロードを一時的に移動する地理的リージョン。
地理的に冗長化されたストレージ : Google クラウドには、非同期ストレージ GCSレプリケーションプロセスを使用して、永続化されたバケット用のリージョン間で地理的に冗長化されたストレージがあります。

重要

ディザスタリカバリプロセスの場合、 Databricksでは、Google クラウドアカウント内のワークスペースごとに Databricks が作成する 2 つのGCSバケットなど、データのリージョン間複製に地理的に冗長化Databricksれたストレージに依存しないことを推奨しています。一般的に、 Deltaテーブルにはディープクローンを使用し、可能であればデータをDelta形式に変換して、他のデータ形式でもディープクローンを使用します。

展開状態の用語

この記事では、デプロイの状態の次の定義を使用します。

アクティブなデプロイメント: ユーザーは、Databricks ワークスペースのアクティブなデプロイメントに接続し、ワークロードを実行できます。ジョブは、Databricks スケジューラまたはその他のメカニズムを使用して定期的にスケジュールされます。このデプロイメントでもデータストリームを実行できます。一部のドキュメントでは、アクティブな展開を ホット展開と呼ぶ場合があります。
パッシブ展開: パッシブ展開ではプロセスは実行されません。 IT チームは、コード、構成、およびその他の Databricks オブジェクトをパッシブ展開に展開するための自動化された手順を設定できます。デプロイがアクティブになるのは、現在アクティブなデプロイがダウンしている場合のみです。一部のドキュメントでは、パッシブ展開を コールド展開と呼ぶ場合があります。

重要

プロジェクトには、必要に応じて、異なるリージョンに複数のパッシブデプロイを含めて、リージョンの停止を解決するための追加オプションを提供できます。

一般的に、アクティブ/パッシブディザスタリカバリ戦略では、チームには一度に 1 つのアクティブなデプロイメントしかありません。あまり一般的ではないディザスタリカバリソリューション戦略として、アクティブ-アクティブと呼ばれるものがあります。この戦略では、2 つのアクティブなデプロイメントが同時に存在します。

ディザスタリカバリ業界用語

チームのために理解し、定義する必要がある 2 つの重要な業界用語があります。

リカバリポイント目標: リカバリポイント目標 (RPO) は、重大なインシデントにより IT サービスからデータ (トランザクション) が失われる可能性がある最大の目標期間です。 Databricks の展開では、主要な顧客データは保存されません。これは、 Google Cloud Storageなどの別のシステムや、ユーザーが管理するその他のデータソースに保存されます。 Databricks コントロールプレーンは、ジョブやノートブックなどの一部のオブジェクトを部分的または全体的に保存します。 Databricks の場合、RPO は、ジョブやノートブックの変更などのオブジェクトが失われる可能性がある最大の目標期間として定義されます。さらに、Google Cloud Storage または管理下にある他のデータソース内の独自の顧客データの RPO を定義する責任はお客様にあります。
目標復旧時間: 目標復旧時間 (RTO) は、災害発生後にビジネスプロセスを復旧するために必要な目標時間とサービスレベルです。

ディザスタリカバリとデータ破損

ディザスタリカバリソリューションでは、データ破損を軽減することはできません。プライマリリージョンの破損したデータは、プライマリリージョンからセカンダリリージョンにレプリケートされ、両方のリージョンで破損します。この種の障害を軽減する方法は他にもあります。たとえば、 Deltaタイムトラベルなどです。

一般的な回復ワークフロー

Databricksリカバリのシナリオは、通常、次のように進行します。

プライマリリージョンで使用する重要なサービスで障害が発生します。これは、 Databricks展開に影響を与えるデータソースサービスまたはネットワークである可能性があります。
クラウドプロバイダーと状況を調査します。
プライマリリージョンで問題が修復されるのを待つことができないと判断した場合は、セカンダリリージョンへのフェールオーバーが必要であると判断できます。
同じ問題がセカンダリリージョンにも影響しないことを確認します。
セカンダリリージョンにフェールオーバーします。
1. ワークスペース内のすべてのアクティビティを停止します。ユーザーがワークロードを停止します。ユーザーまたは管理者は、可能であれば、最近の変更のバックアップを作成するように指示されます。ジョブは、停止が原因でまだ失敗していない場合、シャットダウンされます。
2. セカンダリリージョンで回復手順を開始します。復旧手順では、セカンダリリージョンへの接続とネットワークトラフィックのルーティングと名前変更が更新されます。
3. テスト後、セカンダリリージョンが操作可能であることを宣言します。本番運用ワークロードを再開できるようになりました。ユーザーは、現在アクティブな展開にログインできます。スケジュールされたジョブや遅延されたジョブを再トリガーできます。
Databricksコンテキストでの詳細なステップについては、「テストフェールオーバー」を参照してください。
ある時点で、プライマリリージョンの問題が軽減され、この事実を確認します。
プライマリリージョンに復元 (フェールバック) します。
1. セカンダリリージョンでのすべての作業を停止します。
2. プライマリリージョンで回復手順を開始します。回復手順では、接続とネットワークトラフィックのルーティングと名前変更が処理され、プライマリリージョンに戻されます。
3. 必要に応じて、プライマリリージョンにデータをレプリケートして戻します。複雑さを軽減するには、レプリケートする必要があるデータの量を最小限に抑えます。たとえば、セカンダリデプロイメントで実行するときに一部のジョブが読み取り専用である場合、そのデータをプライマリリージョンのプライマリデプロイメントにレプリケートする必要がないことがあります。ただし、実行する必要がある本番運用ジョブが 1 つあり、プライマリリージョンへのデータレプリケーションが必要になる場合があります。
4. プライマリリージョンでデプロイをテストします。
5. プライマリリージョンが運用可能であり、それがアクティブなデプロイであることを宣言します。本番運用ワークロードを再開します。
プライマリリージョンへの復元の詳細については、「テスト復元 (フェイルバック)」を参照してください。

重要

これらのステップ中に、データ損失が発生する可能性があります。組織では、許容できるデータ損失の量と、この損失を軽減するために何ができるかを定義する必要があります。

ステップ1: ビジネスニーズを理解する

最初のステップは、ビジネスニーズを定義して理解することです。どのデータサービスが重要か、またそれらの予想されるRPO と RTO は何かを定義します。

各システムの実際の許容範囲を調査し、ディザスタリカバリのフェイルオーバーとフェイルバックにはコストがかかり、その他のリスクも伴うことに留意してください。その他のリスクとしては、データの破損、間違った保存場所に書き込んだ場合のデータの重複、ユーザーがログインして間違った場所で変更を行うなどがあります。

ビジネスに影響するすべての Databricks 統合ポイントをマップします。

ディザスタリカバリソリューションでは、対話型プロセス、自動プロセス、またはその両方に対応する必要がありますか?
どのデータサービスを使用していますか? 一部はオンプレミスの場合もあります。
入力データはどのようにしてクラウドに送られるのでしょうか?
誰がこのデータを使用しますか? どのプロセスがダウンストリームでそれを消費しますか?
ディザスタリカバリの変更を認識する必要があるサードパーティ統合はありますか?

ディザスタリカバリ計画をサポートできるツールまたはコミュニケーション戦略を決定します。

ネットワーク構成をすばやく変更するために、どのようなツールを使用しますか?
ディザスタリカバリソリューションを自然かつ保守しやすい方法で収容できるように、構成を事前に定義してモジュール化できますか?
ディザスタリカバリのフェイルオーバーとフェイルバックの変更を社内チームとサードパーティ（統合、下流の消費者）に通知するコミュニケーションツールとチャンネルはどれですか? そして、彼らの謝辞をどのように確認しますか?
どのようなツールや特別なサポートが必要ですか?
完全な復旧が完了するまで、どのようなサービスが停止されますか?

ステップ2: ビジネスニーズに合ったプロセスを選択する

ソリューションでは、コントロールプレーン、コンピュートプレーン、およびデータソースの両方で正しいデータを複製する必要があります。ディザスタリカバリの冗長ワークスペースは、異なるリージョンの異なるコントロールプレーンにマップする必要があります。同期ツールまたは CI/CD ワークフローのいずれかのスクリプトベースのソリューションを使用して、そのデータを定期的に同期する必要があります。 Databricks Runtimeワーカーなど、コンピュートプレーンネットワーク自体の内部からデータを同期する必要はありません。

さらに、データソースが必要に応じてリージョン間で複製されるようにする必要があります。

一般的なおすすめの方法

ディザスタリカバリ計画を成功させるための一般的なベストプラクティスは次のとおりです。

どのプロセスがビジネスにとって重要であり、ディザスタリカバリで実行する必要があるかを理解します。
関係するサービス、処理されるデータ、データフロー、保存場所を明確に特定する
サービスとデータを可能な限り分離します。たとえば、ディザスタリカバリのデータ用に特別なクラウドストレージコンテナーを作成したり、災害時に必要となるDatabricksオブジェクトを別のワークスペースに移動したりします。
Databricks コントロールプレーンに保存されていないその他のオブジェクトについては、プライマリ展開とセカンダリ展開間の整合性を維持する責任はお客様にあります。

警告

ワークスペースの DBFS ルートアクセスに使用されるルートバケットにデータを保存しないことがベストプラクティスです。GCSその DBFS ルートストレージは本番運用顧客データではサポートされていません。 Databricks 、ライブラリ、構成ファイル、または init スクリプトをこの場所に保存しないことも推奨されています。
データソースについては、可能な場合は、レプリケーションと冗長性のためにネイティブの Google クラウドツールを使用して、データをディザスタリカバリリージョンに複製することをおすすめします。

回復ソリューション戦略を選択する

典型的なディザスタリカバリソリューションには、2 つ (またはそれ以上) のワークスペースが含まれます。選択できる戦略はいくつかあります。中断の潜在的な長さ (数時間または 1 日)、ワークスペースが完全に動作していることを確認するための労力、プライマリリージョンに復元 (フェールバック) するための労力を考慮してください。

アクティブ・パッシブソリューション戦略

アクティブ/パッシブソリューションは最も一般的で最も簡単なソリューションであり、このタイプのソリューションがこの記事の焦点です。アクティブ/パッシブソリューションは、アクティブ展開からパッシブ展開にデータとオブジェクトの変更を同期します。必要に応じて、異なるリージョンに複数のパッシブデプロイを行うこともできますが、この記事では、単一のパッシブデプロイアプローチに焦点を当てます。ディザスタリカバリイベント中は、セカンダリリージョンのパッシブデプロイメントがアクティブデプロイメントになります。

この戦略には、主に 2 つのバリエーションがあります。

統合された (企業全体の) ソリューション: 組織全体をサポートするアクティブ展開とパッシブ展開の 1 セット。
部門またはプロジェクト別のソリューション: 各部門またはプロジェクトドメインは、個別のディザスタリカバリソリューションを維持します。一部の組織では、部門間でディザスタリカバリの詳細を切り離し、各チームの固有のニーズに基づいて、チームごとに異なるプライマリリージョンとセカンダリリージョンを使用したいと考えています。

読み取り専用のユースケースにパッシブデプロイを使用するなど、他のバリエーションもあります。ユーザークエリなどの読み取り専用のワークロードがある場合、データや、ノートブックやジョブなどの Databricks オブジェクトを変更しない限り、いつでもパッシブソリューションで実行できます。

アクティブ・アクティブソリューション戦略

アクティブ/アクティブソリューションでは、両方のリージョンのすべてのデータプロセスを常に並行して実行します。運用チームは、ジョブなどのデータ処理が両方のリージョンで正常に終了した場合にのみ完了としてマークされるようにする必要があります。本番運用ではオブジェクトを変更することはできず、開発/ステージングから本番運用への厳格なCI/CDプロモーションに従う必要があります。

アクティブ/アクティブソリューションは最も複雑な戦略であり、ジョブが両方のリージョンで実行されるため、追加の財務コストが発生します。

アクティブ/パッシブ戦略と同様に、これを統合組織ソリューションとして、または部門ごとに実装できます。

ワークフローによっては、すべてのワークスペースに対してセカンダリシステムに同等のワークスペースが必要ない場合もあります。たとえば、開発ワークスペースやステージングワークスペースでは複製が必要ない場合があります。適切に設計された開発パイプラインを使用すると、必要に応じてそれらのワークスペースを簡単に再構築できる可能性があります。

ツールの選択

プライマリリージョンとセカンダリリージョンのワークスペース間でデータを可能な限り類似した状態に保つツールには、主に 2 つのアプローチがあります。

プライマリからセカンダリにコピーする同期クライアント: 同期クライアントは、プライマリリージョンからセカンダリリージョンに本番運用データとアセットをプッシュします。通常、これはスケジュールに従って実行されます。
並列デプロイメント用のCI/CDツール: 本番運用コードとアセットの場合は、本番運用システムへの変更を両方のリージョンに同時にプッシュするCI/CDツールを使用してください。たとえば、コードとアセットをステージング/開発から本番運用にプッシュする場合、 CI/CDシステムにより、両方のリージョンで同時に利用できるようになります。基本的な考え方は、 Databricksワークスペース内のすべての成果物をInfrastructure-as-Codeとして扱うことです。ほとんどのアーティファクトはプライマリワークスペースとセカンダリワークスペースの両方に同時にデプロイできますが、一部のアーティファクトはディザスタリカバリイベントの後にのみデプロイする必要がある場合があります。ツールについては、「自動化スクリプト、サンプル、プロトタイプ」を参照してください。

次の図は、これら 2 つのアプローチを対比したものです。

ニーズに応じて、アプローチを組み合わせることができます。たとえば、ノートブックのソースコードには CI/CD を使用し、プールやアクセス制御などの構成には同期を使用します。

次の表は、各ツールオプションでさまざまな種類のデータを処理する方法を示しています。

説明	CI/CDツールでの処理方法	同期ツールでの処理方法
ソースコード: ライブラリソースエクスポートとパッケージ化されたライブラリのソースコード	プライマリとセカンダリの両方に共同デプロイします。	プライマリからセカンダリにソースコードを同期します。
ユーザーとグループ	Git でメタデータを構成として管理します。または、両方のワークスペースに同じ ID プロバイダー (IdP) を使用します。ユーザーとグループのデータをプライマリ展開とセカンダリ展開に共同展開します。	両方のリージョンでSCIMまたはその他の自動化を使用します。手動で作成することはお勧めしませんが、使用する場合は両方に対して同時に行う必要があります。手動セットアップを使用する場合は、スケジュールされた自動プロセスを作成して、2 つの展開間でユーザーとグループのリストを比較します。
プールの構成	Git のテンプレートにすることができます。プライマリとセカンダリに共同デプロイします。ただし、ディザスタリカバリイベントまではセカンダリの`min_idle_instances`ゼロである必要があります。	API または CLI を使用してセカンダリワークスペースに同期されるときに、任意の`min_idle_instances`を使用して作成されたプール。
ジョブ構成	Git のテンプレートにすることができます。プライマリ展開の場合は、ジョブ定義をそのまま展開します。セカンダリデプロイメントの場合は、ジョブをデプロイし、同時実行数をゼロに設定します。これにより、このデプロイメント内のジョブが無効になり、追加の実行が防止されます。コンカレンシー値は、セカンダリデプロイがアクティブになった後に変更します。	何らかの理由でジョブが既存の`<interactive>`クラスターで実行される場合、同期クライアントはセカンダリワークスペース内の対応する`cluster_id`にマップする必要があります。
アクセス制御リスト (ACL)	Git のテンプレートにすることができます。ノートブック、フォルダー、クラスターのプライマリ展開とセカンダリ展開に共同展開します。ただし、ジョブのデータはディザスタリカバリイベントまで保持してください。	Permissions API を使用すると、クラスター、ジョブ、プール、ノートブック、フォルダーのアクセス制御を設定できます。同期クライアントは、セカンダリワークスペース内の各オブジェクトの対応するオブジェクト ID にマップする必要があります。 Databricks では、アクセス制御を複製する前に、オブジェクトを同期しながらプライマリワークスペースからセカンダリワークスペースへのオブジェクト ID のマップを作成することをお勧めします。
ライブラリ	ソースコードとクラスター/ジョブテンプレートに含めます。	集中リポジトリ、DBFS、またはクラウドストレージ (マウント可能) からカスタムライブラリを同期します。
クラスター init スクリプト	必要に応じてソースコードに含めます。	同期を簡単にするために、可能であれば、init スクリプトを共通フォルダー内のプライマリワークスペースまたは少数のフォルダーに保存します。
マウント・ポイント	ノートブックベースのジョブまたはコマンド APIを通じてのみ作成された場合は、ソースコードに含めます。	ジョブを使用します。ワークスペースが異なるリージョンにある場合、ストレージエンドポイントが変更される可能性があることに注意してください。これは、データディザスタリカバリ戦略にも大きく依存します。
テーブルメタデータ	ノートブックベースのジョブまたはコマンド APIを通じてのみ作成された場合は、ソースコードに含めます。これは、内部 Databricks メタストアと外部構成メタストアの両方に適用されます。	Spark Catalog APIを使用するか、ノートブックまたはスクリプトを使用してテーブルの作成を表示し、メタストア間のメタデータ定義を比較します。基になるストレージのテーブルはリージョンベースにすることができ、メタストアインスタンス間で異なることに注意してください。
シークレット	コマンド APIを通じてのみ作成された場合はソースコードに含めます。一部のシークレットコンテンツは、プライマリとセカンダリの間で変更する必要があることに注意してください。	シークレットは、API を介して両方のワークスペースに作成されます。一部のシークレットコンテンツは、プライマリとセカンダリの間で変更する必要があることに注意してください。
クラスター構成	Git のテンプレートにすることができます。プライマリデプロイメントとセカンダリデプロイメントに共存しますが、セカンダリデプロイメント内のデプロイメントはディザスタリカバリイベントまで終了する必要があります。	クラスターは、API または CLI を使用してセカンダリワークスペースに同期された後に作成されます。これらは、自動終了設定に応じて、必要に応じて明示的に終了できます。
ノートブック、ジョブ、フォルダの権限	Git のテンプレートにすることができます。プライマリとセカンダリのデプロイに共同デプロイします。	Permissions APIを使用して複製します。

地域と複数のセカンダリワークスペースを選択する

ディザスタリカバリトリガーを完全に制御する必要があります。これは、いつでも、いかなる理由でもトリガーできます。フェイルバック（通常の本番運用）モードで運用を再開する前に、ディザスタリカバリの安定化に責任を持つ必要があります。通常、これは、本番運用とディザスタリカバリのニーズに対応するために複数のDatabricksワークスペースを作成し、セカンダリフェールオーバーリージョンを選択する必要があることを意味します。

Google クラウドでは、選択したセカンダリリージョンを完全に制御できます。すべてのリソースと製品がそのリージョンで利用可能であることを確認します。一部のDatabricksサービスは、一部のGoogle クラウドリージョンでのみご利用いただけます。

ステップ3: ワークスペースを準備し、1回限りのコピーを実行する

ワークスペースがすでに本番運用中の場合は、通常、1 回限りのコピー操作を実行して、パッシブなデプロイメントをアクティブなデプロイメントと同期します。この 1 回限りのコピーでは、次の処理が行われます。

データレプリケーション: クラウドレプリケーションソリューションまたは Delta Deep Clone 操作を使用してレプリケートします。
トークン生成: トークン生成を使用して、レプリケーションと将来のワークロードを自動化します。
ワークスペースレプリケーション:ステップ 4: データソースの準備で説明されている方法を使用して、ワークスペースレプリケーションを使用します。
ワークスペースの検証: - ワークスペースとプロセスが正常に実行され、期待どおりの結果が得られるかを確認するためのテスト。

最初の 1 回限りのコピー操作の後、後続のコピーと同期のアクションはより高速になり、ツールからのログは、変更内容と変更日時のログにもなります。

ステップ4: データソースを準備する

Databricks 、バッチ処理またはデータストリームを使用して、さまざまなデータソースを処理できます。

データソース用のシステムを実装する前に、 GCSとBigQueryのレプリケーションの違いを理解することが重要です。

BigQuery の場合、データは複製されます。破損したデータは、最大 7 日間回復できます (バックアップがない場合)。
Delta Lake を使用する GCS の場合、レプリケーションは、シングル、デュアル、マルチなどのバケットタイプによって異なります。破損したデータは、 Vacuum の保持期間に応じて回復できます。

データソースからのバッチ処理

データがバッチで処理される場合、通常、そのデータは簡単に複製したり別のリージョンに配信したりできるデータソースに存在します。

たとえば、データは定期的にクラウドストレージの場所にアップロードされる場合があります。セカンダリリージョンのディザスタリカバリモードでは、ファイルがセカンダリリージョンストレージにアップロードされるようにする必要があります。ワークロードは、セカンダリリージョンストレージを読み取り、セカンダリリージョンストレージに書き込む必要があります。

データストリーム

データストリームの処理はさらに大きな課題です。ストリーミングデータはさまざまなソースから取り込まれ、処理されてストリーミングソリューションに送信できます。

KafkaやPub/Sub Liteなどのメッセージキュー
データベースチェンジデータキャプチャストリーム
ファイルベースの連続処理
ファイルベースのスケジュールされた処理 (トリガーワンスとも呼ばれます)

これらすべてのケースでは、ディザスタリカバリモードを処理し、セカンダリリージョンでセカンダリデプロイメントを使用するようにデータソースを構成する必要があります。

ストリームライターは、処理されたデータに関する情報を含むチェックポイントを保存します。このチェックポイントには、ストリームを正常に再開するために新しい場所に変更する必要があるデータの場所 (通常はクラウドストレージ) が含まれる場合があります。たとえば、チェックポイントの下のsourceサブフォルダーには、ファイルベースのクラウドフォルダーが格納されている場合があります。

このチェックポイントは、適切なタイミングでレプリケートする必要があります。新しいクラウドレプリケーションソリューションでは、チェックポイント間隔の同期を検討してください。

チェックポイントの更新はライターの機能であるため、データストリームの取り込みや、別のストリーミングソースでの処理と保存に適用されます。

ストリーミングワークロードの場合、最後の障害発生時点からワークロードを再開できるように、チェックポイントが顧客管理ストレージに構成されていることを確認します。プライマリプロセスと並行してセカンダリストリーミングプロセスを実行することもできます。

ステップ5: ソリューションを実装してテストする

ディザスタリカバリのセットアップを定期的にテストして、正しく機能することを確認します。必要なときに使用できないのであれば、ディザスタリカバリソリューションを維持しても意味がありません。一部の企業は、数か月ごとに地域を切り替えます。定期的なスケジュールでリージョンを切り替えると、前提条件とプロセスがテストされ、復旧のニーズが満たされていることが確認されます。これにより、組織が緊急事態に関するポリシーと手順に精通していることも保証されます。

重要

ディザスタリカバリソリューションを実際の状況で定期的にテストします。

オブジェクトまたはテンプレートが不足していることがわかり、プライマリワークスペースに保存されている情報に依拠する必要がある場合は、計画を変更してこれらの障害を取り除き、この情報をセカンダリシステムに複製するか、他の方法で利用できるようにします。

プロセスと一般的な構成に必要な組織的な変更をテストします。ディザスタリカバリ計画はデプロイメントパイプラインに影響を与えるため、チームが何を同期させる必要があるかを把握することが重要です。ディザスタリカバリワークスペースをセットアップした後、インフラストラクチャ (手動またはコード)、ジョブ、ワークスペース、ライブラリ、およびその他のワークスペースオブジェクトがセカンダリリージョンで使用可能であることを確認する必要があります。

標準の作業プロセスと構成パイプラインを拡張して、すべてのワークスペースに変更を展開する方法についてチームと話し合ってください。すべてのワークスペースでユーザー ID を管理します。新しいワークスペース用に、ジョブ自動化やモニタリングなどのツールを設定することを忘れないでください。

構成ツールの変更を計画し、テストします。

取り込み: データソースがどこにあり、それらのソースがデータをどこから取得するかを理解します。可能な場合は、ソースをパラメーター化し、セカンダリデプロイメントとセカンダリリージョンを操作するための別の構成テンプレートがあることを確認します。フェールオーバーの計画を準備し、すべての前提条件をテストします。
実行の変更: ジョブやその他のアクションをトリガーするスケジューラがある場合は、セカンダリデプロイメントまたはそのデータソースで動作する別のスケジューラを構成する必要がある場合があります。フェールオーバーの計画を準備し、すべての前提条件をテストします。
インタラクティブな接続: REST APIs 、 CLIツール、 JDBC / ODBCなどのその他のサービスを使用する場合、地域的な混乱によって構成、認証、ネットワーク接続がどのように影響を受けるかを検討します。フェールオーバーの計画を準備し、すべての前提条件をテストします。
自動化の変更: すべての自動化ツールについて、フェールオーバーの計画を準備し、すべての前提条件をテストします。
出力: 出力データまたはログを生成するツールについては、フェールオーバーの計画を準備し、すべての前提条件をテストします。

テストのフェールオーバー

ディザスタリカバリはさまざまなシナリオによって起動できます。予期せぬ中断によって引き起こされる可能性があります。クラウドネットワーク、クラウドストレージ、その他のコアサービスなど、一部のコア機能がダウンしている可能性があります。システムを正常にシャットダウンするためのアクセス権がないため、回復を試みる必要があります。ただし、このプロセスは、シャットダウンや計画的な停止によって、あるいは 2 つのリージョン間でアクティブなデプロイを定期的に切り替えることによってトリガーされる可能性があります。

フェイルオーバーをテストするときは、システムに接続してシャットダウンプロセスを実行します。すべてのジョブが完了し、クラスターが終了していることを確認します。

同期クライアント (または CI/CD ツール) は、関連する Databricks オブジェクトとリソースをセカンダリワークスペースに複製できます。セカンダリワークスペースをアクティブ化するには、次のプロセスの一部またはすべてを実行する必要があります。

テストを実行して、プラットフォームが最新であることを確認します。
プライマリリージョンのプールとクラスターを無効にして、障害が発生したサービスがオンラインに戻った場合にプライマリリージョンが新しいデータの処理を開始しないようにします。
回復プロセス:
1. 最新の同期データの日付を確認します。ディザスタリカバリの業界用語を参照してください。このステップの詳細は、データの同期方法と固有のビジネスニーズによって異なります。
2. データソースを安定させ、すべてが利用可能であることを確認します。 Google クラウドSQL 、 BigQuery 、Pub/Sub などのすべての外部データソースと、 Delta Lake 、 Parquet 、その他のファイルを含めます。
3. ストリーミング回復ポイントを見つけます。そこから再開するプロセスを設定し、潜在的な重複を識別して排除するプロセスを準備します (Delta Lake を使用すると、これが簡単になります)。
4. データフロープロセスを完了し、ユーザーに通知します。
関連するプールを開始します (または、 min_idle_instancesを関連する数に増やします)。
関連するクラスターを起動します (終了していない場合)。
ジョブの並列実行と関連するジョブの実行を変更します。これらは、1 回限りの実行または定期的な実行である可能性があります。
Databricksワークスペースの URL またはドメイン名を使用する外部ツールの場合は、新しいコントロールプレーンのアカウントに構成を更新します。たとえば、 REST APIsおよびJDBC / ODBC接続の URL を更新します。コントロールプレーンが変更されると、Databricks Web アプリケーションの顧客向け URL も変更されるため、組織のユーザーに新しい URL を通知します。

テスト復元 (フェールバック)

フェールバックは制御が容易で、メンテナンス期間内に実行できます。このプランには、次の一部またはすべてを含めることができます。

プライマリリージョンが復元されたことの確認を取得します。
新しいデータの処理が開始されないように、セカンダリリージョンのプールとクラスターを無効にします。
セカンダリワークスペース内の新規または変更されたアセットをプライマリデプロイメントに同期します。フェイルオーバースクリプトの設計によっては、同じスクリプトを実行して、セカンダリ (ディザスタリカバリ) リージョンからプライマリ (本番運用) リージョンにオブジェクトを同期できる場合があります。
新しいデータ更新をプライマリ展開に同期します。ログとDeltaテーブルの監査証跡を使用して、データが失われないことを保証できます。一部の管理対象データソースでは、自動ログインを使用した回復の時間枠が限られていることに注意してください。たとえば、Google BigQuery ではデータの復元に 7 日間の制限があります。
ディザスタリカバリ領域内のすべてのワークロードをシャットダウンします。
ジョブとユーザーの URL をプライマリリージョンに変更します。
テストを実行して、プラットフォームが最新であることを確認します。
関連するプールを開始します (またはmin_idle_instancesを適切な数に増やします)。
関連するクラスターを起動します (終了していない場合)。
ジョブの並列実行を変更し、関連するジョブを実行します。これらは、1 回限りの実行または定期的な実行である可能性があります。
必要に応じて、将来のディザスタリカバリのためにセカンダリリージョンを再度設定します。

自動化スクリプト、サンプル、プロトタイプ

ディザスタリカバリプロジェクトで検討すべき自動化スクリプト:

Databricks では、独自の同期プロセスを開発するためにDatabricks Terraform プロバイダーを使用することをお勧めします。
サンプルの自動化およびプロトタイプスクリプトについては、 Databricks Workspace移行ツールも参照してください。
Databricks Sync (DBSync)プロジェクトは、Databricks ワークスペースをバックアップ、復元、同期するオブジェクト同期ツールです。