ディザスタリカバリ

Databricks のディザスタリカバリ（DR）は、ワークスペース、データ、構成をクラウドリージョン間でレプリケートすることで、リージョン障害によってプライマリデプロイがオフラインになった場合でも、チームが作業を継続できるようにします。完全なDRプランは、Databricksだけでなく、接続するデータソース、取り込みツール、BIツール、スケジューラもカバーします。

このページでは、クロスリージョン DR ソリューションをデザインし、実行するために必要な概念、戦略、ツール、テスト手順について説明します。

DRプランニングは初めてですか？RPOとRTOの定義については、ディザスタリカバリ業界用語を参照してください。

リージョン内高可用性保証

このページではクロスリージョンDRについて説明していますが、Databricksは単一のリージョン内でも高可用性 (HA) を提供しています。まず、これらの保証を理解する必要があります。別の DR 戦略が必要かどうかを決定します。

HA と DR は異なる問題を解決：

HA はリージョン内でアベイラビリティーゾーン (AZ) の冗長性を利用します。あるゾーンで障害が発生しても、他のゾーンではサービスが稼働し続けます。
ディザスタリカバリはリージョン間のレプリケーションを利用します。別のリージョンでセカンダリのDatabricksワークスペースを運用し、データと構成をそれらにレプリケートします。その後、リージョン障害発生時にフェイルオーバーします。

複数リージョンDRが不要な場合、Databricks HAで十分かもしれません。HA はクロスリージョンの複雑さを回避しますが、完全なリージョン障害からは保護しません。DRでHAのみに依存している場合は、クラウドリージョンの分離と冗長性を確認してください。

同一リージョン内 HA保証は、コントロールプレーンとコンピュートプレーンを対象とします。

Databricks コントロールプレーンの可用性

Databricks のコントロールプレーンはゾーン障害に対して回復力があり、ゾーン障害発生後約 15 分以内に自動的に復旧します。定期的なゾーン障害テストがこれを検証します。

すべてのステートレスなコントロールプレーンサービスは、サービスを停止することなく、個々のVM、またはゾーン全体のすべてのVMを失う可能性があります。ワークスペースデータは、リージョン内のゾーン間でレプリケートされたデータベースに保存されています。Databricks Runtime イメージを提供するストレージアカウントは、リージョン内でも冗長性が確保されており、プライマリが停止した際には引き継ぐセカンダリストレージアカウントがすべてのリージョンにあります。

注記

The control plane guarantees above apply to Databricks-managed infrastructure. You are responsible for compute-plane zone redundancy, for example, choosing zone-redundant storage for the workspace root bucket and using instance pools that span availability zones.

ゾーン障害のレジリエンスでは、リージョン内で同時にダウンできるゾーンは最大1つです。

Google Cloud リージョンでは、ゾーンの耐障害性が有効になっていない場合があります。詳細については、「Databricks のクラウドとリージョン」を参照してください。サポートされていないリージョンでゾーンレジリエンスが必要な場合は、Databricks アカウントチームにお問い合わせください。

コンピュートプレーンの可用性

コンピュート飛行機の可用性

ワークスペースの可用性はコントロールプレーンの可用性に依存します。

DBFSルートデータは影響を受けません。GCSデータはデフォルトでリージョン別であり、ゾーン間でデータ冗長性を備えています。

クラスターノードは、Google Cloud コンピュートプロバイダーの単一のAZに割り当てられます。ノードが失われた場合、クラスターマネージャーは同じAZ内のGoogle Cloud コンピュートプロバイダーから代替ノードを要求します。例外は、ドライバーノードが失われた場合です。その場合、クラスターマネージャーはジョブとクラスターを再起動します。クラスターを含むAZでゾーン障害が発生した場合、クラスターマネージャーは別のAZでジョブとクラスターを再起動します。

用語

DRについてチームと議論する際には、これらの定義を一貫してご使用ください。

地域用語

地域の用語

このページは以下のリージョン定義を使用します。

プライマリリージョン：ユーザーが日常的に対話型および自動化されたデータ分析ワークロードを実行する地域です。
セカンダリリージョン ：ITチームがプライマリリージョンの停止中に一時的にワークロードを移動させるリージョンです。
地理的に冗長化されたストレージ ：永続化されたストレージの非同期リージョン間レプリケーションお使いのクラウドのドキュメントを参照してください：

リージョン間での地理的に冗長化されたストレージ（Google Cloud）

重要

Do not rely on geo-redundant storage to duplicate Databricks root storage (such as the GCS bucket Databricks creates for each workspace) across regions. To replicate managed table data, use Delta Deep Clone, and for non-Delta data, convert to Delta first where possible.

展開ステータスの用語

デプロイ状態の用語

このページでは、次のデプロイメントステータスの定義を使用しています。

アクティブなデプロイメント（ホットデプロイメントとも呼ばれます）：ユーザーはそれに接続して、ワークロードを実行します。ジョブとデータストリームはここでスケジュールに従って実行されます。
**パッシブデプロイメント**（ コールドデプロイメント とも呼ばれます）：プロセスは実行されていません。ITチームは、コード、設定、およびその他のDatabricksオブジェクトを自動でデプロイすることで、常に準備万端の状態に保っています。パッシブデプロイメントは、アクティブなデプロイが停止した場合にのみアクティブになります。

重要

プロジェクトは、追加の回復性のために、異なる地域に複数のパッシブデプロイメントを含めることができます。

ほとんどのチームは、アクティブ-パッシブ戦略に基づき、一度に1つのアクティブなデプロイメントを実行しています。あまり一般的ではないアクティブ-アクティブ戦略では、2つのアクティブなデプロイメントを同時に実行します。

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

これらの2つの業界用語をチームで定義してください。

復旧時点目標（RPO） ：主要なインシデント発生時にサービスが許容できるデータ損失の最大期間です。「RPO」を参照してください。

Databricksは主要な顧客データを保存しません。それが Google Cloud Storage またはお客様が管理する他のシステムに格納されます。Databricks のコントロールプレーンは、いくつかのオブジェクト（ジョブやノートブックなど）を保存します。そのため、Databricks RPOは、これらのオブジェクトに対する変更が失われる可能性のある最大期間です。お客様には、Google Cloud Storage およびお客様が管理するその他のデータソースに保存されている顧客データの RPO を定義する責任があります。
目標復旧時間（RTO） ：災害発生後、ビジネスプロセスを復旧しなければならない最大時間。「RTO」を参照してください。

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

DRソリューションはデータの破損を軽減しません。プライマリリージョンで破損したデータはセカンダリリージョンにレプリケートされ、両方のリージョンで破損します。この種の障害を軽減するには、Delta タイムトラベル、同様のツール、またはデータバックアップツールを使用してください。

一般的なリカバリワークフロー

DatabricksのDRシナリオは、通常、以下のとおりです：

プライマリリージョンで、Databricksデプロイが依存する重要なサービス（データソース、ネットワーク、またはその他の依存関係）に障害が発生します。
クラウドプロバイダーと調査します。
待機が許容できない場合、セカンダリリージョンにフェイルオーバーすることを決定します。
同じ問題がセカンダリリージョンに影響しないことを確認してください。
フェイルオーバー（詳細な手順については、「テストフェイルオーバー」を参照してください）：
1. すべてのワークスペースアクティビティを停止します。ワークロードを停止し、可能な限り最近の変更をバックアップしてください。ジョブはシャットダウンされます（既にシステム停止によって失敗していない場合）。
2. ルーティングを更新し、接続とネットワークトラフィックをリダイレクトするために、セカンダリリージョンの回復手順を実行します。
3. ダウンストリームシステム（BIツール、スケジューラ、サードパーティ統合）をセカンダリワークスペースに向け直し、接続を再開します。
4. テスト後、セカンダリリージョンを運用可能と宣言します。ユーザーは現在アクティブなデプロイにログインし、スケジュールされたジョブまたは遅延したジョブを再トリガーします。
プライマリリージョンの問題が解消された後、修正を確認してください。
フェールバック（詳細については、「テスト復元（フェールバック）」を参照してください。）
1. セカンダリリージョン内のすべての作業を停止してください。
2. ルーティングを元に戻すために、プライマリリージョン回復手順を実行します。
3. 新しいデータをプライマリリージョンに同期します。複製が必要なものを最小限にします。たとえば、セカンダリデプロイで実行された読み取り専用ジョブでは、書き戻しが不要な場合があります。
4. プライマリリージョンデプロイメントをテストします。
5. プライマリリージョンを有効にし、本番運用ワークロードを再開します。

重要

これらのステップにおいて、データ損失が発生する可能性があります。組織が許容する損失量を定義し、その軽減方法を策定します。

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

どのデータサービスが重要であるかを特定し、それらのターゲットRPOおよびRTOを定義します。各システムのリアルワールドの許容範囲を調査してください。

災害復旧（DR）、フェイルオーバー、およびフェイルバックには、データ破損、データ重複（誤ったストレージの場所への書き込み）、ならびにユーザーが誤ったリージョンで変更を行うことなど、実際のコストとリスクが伴います。

ビジネスに影響するDatabricksのすべての統合ポイントをマッピングし、プランで使用するツールとコミュニケーションチャンネルを選択してください。

マッピングする連携ポイント

DRソリューションでは、インタラクティブなプロセス、自動化されたプロセス、それとも両方に対応する必要がありますか？
どのデータサービスを利用していますか？一部はオンプレミスである可能性があります。
入力データはどのようにしてクラウドにたどり着くのですか?
このデータは誰が消費しますか? どのプロセスがダウンストリームでそれを消費しますか?
DRの変更を認識する必要があるサードパーティ統合はありますか？

計画用ツールとコミュニケーション

設定を事前に定義し、自然かつ保守可能な方法で DR ソリューションに対応できるようにモジュール化することは可能ですか？
DRフェイルオーバーおよびフェイルバックの変更について、どのコミュニケーションツールとチャンネルが社内チームおよびサードパーティ（統合、ダウンストリームコンシューマー）に通知しますか？どのように承諾を確認しますか？
完全な復旧が完了するまで、どのようなサービス（もしあれば）がシャットダウンされますか？

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

DIYソリューションは、コントロールプレーン、コンピュートプレーン、およびデータソース間で正しいデータを複製する必要があります。冗長なワークスペースは、異なるリージョンの異なるコントロールプレーンに対応しているため、同期ツールまたはCI/CDワークフローのいずれかであるスクリプトベースのソリューションで同期を保ちます。データ自体については、ほとんどのチームがDatabricksジョブ（多くの場合スケジュールされたジョブ）またはDelta ディープクローンを使用して、リージョン間でテーブルをコピーします。コンピュートプレーン内からデータを同期する必要はありません（Databricks Runtimeワーカーなどから）。

顧客管理VPC機能（すべてのサブスクリプションおよびデプロイタイプでは利用できません）を使用している場合は、両方のリージョンにわたって、Terraformのようなテンプレートベースのツールを使用して、ネットワークを一貫してデプロイしてください。

必要に応じて、データソースをリージョン間で複製してください。

DRソリューションは、通常、2つ（またはそれ以上）のワークスペースを伴います。許容可能な中断期間、運用上の労力、およびプライマリリージョンへのフェイルバックにかかるコストに基づいて、以下の戦略の中から選択してください。

一般的なベストプラクティス

DR計画を成功させるための一般的なベストプラクティスには、次のものが含まれます：

ビジネスにとって重要なプロセス、およびDRで実行する必要があるプロセスを理解します。
どのサービスが関係しているか、どのデータが処理されているか、データフローは何か、どこに保存されているかを明確に特定します。
可能な限り、サービスとデータを分離するようにしてください。例えば、DR データ用に専用のクラウドストレージコンテナを作成するか、災害時に必要な Databricks オブジェクトを別のワークスペースに移動します。
Databricks コントロールプレーンに保存されていないオブジェクトについては、プライマリデプロイメントとセカンダリデプロイメント間の整合性を維持する必要があります。
データソースについては、可能な場合は、ネイティブの Google Cloud ツールを使用して、データをディザスタリカバリリージョンに複製することをおすすめします。

警告

Don't store data in the root GCS bucket used for DBFS root access. DBFS root storage is unsupported for production customer data. Databricks also recommends against storing libraries, configuration files, or init scripts there.

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

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

本セクションでは、最も一般的で、最もシンプルで、最も費用対効果の高いアクティブ/パッシブ戦略について説明します。アクティブ-パッシブソリューションは、アクティブなデプロイメントからセカンダリリージョンのパッシブなデプロイメントにデータとオブジェクトの変更を同期します。DRイベント発生時、パッシブなデプロイメントはアクティブになります。

2 つの一般的なバリアント:

統合（組織全体） ：1組のアクティブおよびパッシブなデプロイメントが組織全体をサポートします。
部門またはプロジェクト別：各ドメインは、ニーズに合わせて調整されたプライマリおよびセカンダリリージョンを備えた独自のDRソリューションを維持しています。

データまたはDatabricksオブジェクトを変更しない、ユーザークエリなどの読み取り専用ワークロードにも、パッシブデプロイメントを利用できます。

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

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

アクティブ-アクティブソリューションでは、すべてのデータプロセスが両方のリージョンで常に並列で実行されます。運用チームは、両方のリージョンで各ジョブが成功した後にのみ、完了とマークする必要があります。本番運用ではオブジェクトを変更できません。開発/ステージング環境から本番運用環境への厳格なCI/CDプロモーションに従う必要があります。

Active-active は最も複雑な戦略であり、ジョブが両方のリージョンで実行されるため、コストは高くなりますが、RTOとRPOを最小限に抑えることができます。

アクティブ-アクティブを企業全体で、または部門ごとに実装できます。ワークロードごとに重複したワークスペースは必要ありません。たとえば、開発またはステージングワークスペースは、同期を維持するよりも、開発パイプラインから再構築する方が多くの場合より簡単です。

ツールの選択

ツーリングをお選びください

プライマリおよびセカンダリリージョンにあるワークスペース間でデータを同期させるには、主に2つのアプローチがあります。

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

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

次の表では、各ツールオプションでの各データタイプの処理方法について説明します。

Description	How to handle with CI/CD tooling	How to handle with sync tool
Source code: notebook source exports and source code for packaged libraries	Co-deploy both to primary and secondary.	Synchronize source code from primary to secondary.
Users and groups	Manage metadata as config in Git. Alternatively, use the same identity provider (IdP) for both workspaces. Co-deploy user and group data to primary and secondary deployments.	Use SCIM or other automation for both regions. Manual creation is not recommended, but if used must be done for both at the same time. If you use a manual setup, create a scheduled automated process to compare the list of users and groups between the two deployments.
Pool configurations	Can be templates in Git. Co-deploy to primary and secondary. However, `min_idle_instances` in secondary must be zero until the DR event.	Pools created with any `min_idle_instances` when they are synced to a secondary workspace using the API or CLI.
Job configurations	Use Databricks Asset Bundles with per-environment targets (for example, `prod` and `dr`) to deploy the same job definition to both regions. For the secondary deployment, set concurrency to zero so the job is staged but doesn't run. Change the concurrency value after the secondary deployment becomes active.	If the jobs run on existing `<interactive>` clusters for some reason, then the sync client needs to map to the corresponding `cluster_id` in the secondary workspace.
Access control lists (ACLs)	Can be templates in Git. Co-deploy to primary and secondary deployments for notebooks, folders, and clusters. However, hold the data for jobs until the DR event.	The Permissions API can set access controls for clusters, jobs, pools, notebooks, and folders. A sync client needs to map to corresponding object IDs for each object in the secondary workspace. Databricks recommends creating a map of object IDs from primary to secondary workspace while syncing those objects before replicating the access controls.
Libraries	Include in source code and cluster/job templates.	Sync custom libraries from centralized repositories, DBFS, or cloud storage (can be mounted).
Cluster init scripts	Include in the source code if you prefer.	For simpler synchronization, store init scripts in the primary workspace in a common folder or in a small set of folders if possible.
Mount points	Include in source code if created only through notebook-based jobs or Command API.	Use jobs. Note that the storage endpoints might change, given that workspaces would be in different regions. This depends a lot on your data DR strategy as well.
Table metadata	For Unity Catalog objects (catalogs, schemas, tables, volumes, and grants), co-deploy with the Databricks Terraform provider or Databricks Asset Bundles. For legacy Hive metastore tables, include create-table statements with source code if created through notebook-based jobs or the Command API.	For Unity Catalog objects, read source metadata from system tables or `information_schema` and replicate to the secondary workspace using the Databricks SDK. For legacy Hive metastore tables, compare metadata definitions between metastores using the Spark Catalog API or `SHOW CREATE TABLE` via a notebook or scripts. Underlying storage paths can be region-based and might differ between metastore instances.
Secrets	Include in source code if created only through Command API. Note that some secrets content might need to change between the primary and secondary.	Secrets are created in both workspaces via the API. Note that some secrets content might need to change between the primary and secondary.
Cluster configurations	Can be templates in Git. Co-deploy to primary and secondary deployments, although the ones in secondary deployment should be terminated until the DR event.	Clusters are created after they are synced to the secondary workspace using the API or CLI. Those can be explicitly terminated if you want, depending on auto-termination settings.
Notebook, job, and folder permissions	Can be templates in Git. Co-deploy to primary and secondary deployments.	Replicate using the Permissions API.

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

DR がいつトリガーされるか、およびどのセカンダリリージョンにフェイルオーバーするかを制御できます。通常の運用を再開する前に、DR環境を安定させることも必要です。これは通常、本番運用とDR向けに複数のDatabricksワークスペースを作成し、その後、セカンダリフェイルオーバーリージョンを選択することを意味します。

セカンダリリージョンを選択する前に、依存するすべてのリソースとサービス（コンピュートタイプ、製品、統合）がそこで利用可能であることを確認してください。一部のDatabricksサービスは、特定のリージョンでのみご利用いただけます。

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

まず、選択したセカンダリリージョンに、セカンダリのDatabricksワークスペース（複数可）と、それらをサポートするメタストアを構築します。セカンダリワークスペースにデータまたはアセットをレプリケートする前に、セカンダリワークスペースはプライマリのアカウント、リージョン、およびID構成と一致している必要があります。

管理対象DRの範囲外で実行されている本番運用ワークスペースの場合、パッシブデプロイメントをアクティブデプロイメントと同期させるために、**ワンタイムコピー**を実行します。このコピーは以下を処理します：

データレプリケーション : クラウドレプリケーションソリューションまたはDelta ディープクローンを使用してください。
トークンの生成 ：生成されたトークンを使用して、レプリケーションと今後のワークロードを自動化します。
ワークスペースレプリケーション ：ステップ 4: データソースを準備するに記載されている方法を使用してレプリケートします。ワークスペース構成、データ、AI/機械学習アセットのエクスポートに関する包括的なガイダンスについては、ワークスペースデータのエクスポートを参照してください。
ワークスペースの検証 ：ワークスペースとプロセスをテストし、正常に実行され、期待される結果を生成することを確認します。

後続の同期は初回コピーよりも高速に実行され、ツールログには変更内容と日時が記録されます。

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

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

GCS と BigQuery は異なってレプリケートします。データソースを設計する前に、違いを把握してください：

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

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

バッチデータは通常、別のリージョンに複製または配信できるソースに存在します。

例えば、データはスケジュールに基づいてクラウドストレージに頻繁にアップロードされます。DR モードでは、これらのアップロードをセカンダリリージョンのストレージに向け、そのストレージからの読み取りと、そのストレージへの書き込みを行うようにワークロードを更新します。

データストリーム

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

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

これらのすべての場合、DRモードに対応し、セカンダリリージョンでセカンダリデプロイメントを使用するようにデータソースを設定する必要があります。

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

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

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

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

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

DRセットアップを定期的にテストしてください。テストされていないDR計画は、必要なときによく失敗します。一部のチームは、仮説の検証、プロセスの実践、およびチームがランブックに習熟できるよう、数か月ごとにスケジュールに従ってアクティブなリージョンを切り替えています。

重要

DRソリューションを現実世界の条件で定期的なスケジュールでテストしてください。

テストで欠落しているオブジェクトまたはテンプレートが明らかになった場合は、計画を更新してください：依存関係を削除するか、セカンダリワークスペースにレプリケートするか、あるいは別の方法で利用可能にしてください。

組織と設定の変更もテストしてください。DRプランはデプロイパイプラインに影響を与えるため、チームは、何を同期させるべきかを把握しておく必要があります。DRワークスペースをセットアップしたら、インフラストラクチャ、ジョブ、ノートブック、ライブラリ、その他のワークスペースオブジェクトがセカンダリリージョンで利用可能であることを確認してください。

すべてのワークスペースに変更をデプロイするために、標準の作業プロセスと構成パイプラインを拡張します。複数のワークスペース間でユーザー ID を管理し、新しいワークスペース向けにジョブの自動化とモニタリングを設定します。

設定ツールへの変更を計画し、テストします。

設定変更の計画およびテスト

以下について：フェイルオーバーの計画を準備し、すべての前提条件をテストします。

取り込み : データソースがどこにあるか、そしてそれらのデータソースがどこからデータを取得するかを把握します。可能な場合は、ソースをパラメータ化し、セカンダリデプロイメントとリージョンには個別の構成テンプレートを使用します。
実行の変更： ジョブや他のアクションをトリガーするスケジューラを使用している場合、セカンダリデプロイメントまたはそのデータソースで動作する別のスケジューラが必要になる場合があります。
対話型接続 ：REST APIs、CLI ツール、または JDBC/ODBC などの他のサービスの使用について、構成、認証、およびネットワーク接続が地域的な障害によってどのように影響を受けるかを検討します。
自動化の変更点 ：すべての自動化ツールについて。
出力：出力データやログを生成するツール向け
ダウンストリームの変更 : Databricksから読み取りまたはDatabricksに書き込むBIツール、ダッシュボード、スケジューラ、およびサードパーティ統合については、セカンダリワークスペースに再ポイントする方法を計画し、その所有者に通知してください。

フェイルオーバーをテスト

テストフェールオーバー

DRをトリガーするシナリオは多岐にわたります。クラウドネットワーク、クラウドストレージ、または正常にシャットダウンできないその他のコアサービスにおける予期せぬ停止、計画的なシャットダウンや停止、あるいはテストサイクルの一環としてのリージョン間の定期的な切り替えなどが考えられます。

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

同期クライアント（または CI/CD ツール）は、関連する Databricks オブジェクトとリソースをセカンダリワークスペースにレプリケートします。セカンダリワークスペースを有効にするには、以下のプロセスの一部またはすべてが含まれる場合があります。

テストを実行して、プラットフォームが最新の状態であることを確認します。
プライマリリージョンでプールとクラスターを無効にして、障害が発生したサービスがオンラインに戻った場合にプライマリリージョンが新しいデータの処理を開始しないようにします。
データソースの回復プロセスを実行します（下記を参照してください）。
関連するプールを開始します (または、 min_idle_instances を関連する数に増やします)。
関連するクラスターを開始します (終了していない場合)。
ジョブの並列実行を変更し、該当するジョブを実行します。これらは、1 回限りの実行または定期的な実行です。
DatabricksワークスペースのURLまたはドメイン名を使用する外部ツールの場合は、新しいコントロールプレーンの構成をアカウントに更新します。たとえば、 REST API 接続と JDBC/ODBC 接続のURLを更新します。コントロールプレーンが変更されると、Databricks Web アプリケーションの顧客向け URL が変更されるため、組織のユーザーに新しい URL を通知してください。

リカバリプロセスの詳細

最後に同期されたデータの日付を確認します。ディザスタリカバリ業界用語を参照してください。このステップの詳細は、データの同期方法と固有のビジネスニーズによって異なります。
データソースを安定させ、すべてのデータソースが使用可能であることを確認します。Google Cloud SQL、BigQuery、Pub/Sub などのすべての外部データソースと、Delta Lake、Parquet、その他のファイルを含めます。
ストリーミングの復旧ポイントを見つけます。そこから再開するようにプロセスを設定し、潜在的な重複を特定して排除する準備ができているプロセスを用意します (Delta Lake を使用すると、これが容易になります)。
データフロープロセスを完了し、ユーザーに通知します。

テスト復元（フェイルバック）

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

フェイルバックは制御が容易で、メンテナンス期間中に実行できます。以下のステップの一部またはすべてについて計画します

プライマリリージョンが復元されたことを確認します。
セカンダリリージョンでプールとクラスターを無効にして、新しいデータの処理が開始されないようにします。
セカンダリワークスペース内の新規および変更されたアセットをプライマリ展開に同期します。フェイルオーバースクリプトの設計によっては、セカンダリ（DR）リージョンからプライマリ（本番運用）リージョンへオブジェクトを同期するために、同じスクリプトを実行できる場合があります。
新しいデータ更新をプライマリ展開に同期します。ログとDeltaテーブルの監査証跡を使用して、データが失われないことを保証できます。一部のマネージドデータソースでは、自動ログインを使用した回復の 時間枠が限られて いることに注意してください。たとえば、Google BigQuery ではデータの復元に 7 日間の制限があります。
DR リージョン内のすべてのワークロードをシャットダウンする。
ジョブとユーザーのURLをプライマリリージョンに変更し、ダウンストリーム接続（BIツール、スケジューラ、サードパーティ連携）をそこに戻します。
テストを実行して、プラットフォームが最新の状態であることを確認します。
関連するプールを開始します (または、 min_idle_instances を関連する数に増やします)。
関連するクラスターを開始します (終了していない場合)。
ジョブの並列実行を変更し、該当するジョブを実行します。これらは、1 回限りの実行または定期的な実行です。
必要に応じて、今後のDRのためにセカンダリリージョンを再度設定してください。

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

DIY DR パイプラインの場合は、Databricks Terraform プロバイダーを使用してワークスペース資産をコードとして管理し、プライマリおよびセカンダリリージョンに同時にデプロイします。

リージョン内高可用性保証​

Databricks コントロールプレーンの可用性​

コンピュート飛行機の可用性​

用語​

地域の用語​

デプロイ状態の用語​