メインコンテンツまでスキップ

ディザスタリカバリ

明確なディザスタリカバリ パターンは、 Databricks. ハリケーンや地震などの地域災害によるものであれ、別のソースによるものであれ、地域全体のクラウドサービスプロバイダーの停止というまれなケースでも、データチームが Databricks プラットフォームを使用できることが重要です。

Databricks は、多くの場合、アップストリーム データ取り込み サービス (バッチ/ストリーミング)、 Google Cloud Storageなどのクラウドネイティブ ストレージ、ビジネスインテリジェンス アプリなどのダウンストリーム ツールとサービス、オーケストレーション ツールなど、多くのサービスを含む全体的なデータ エコシステムの中核部分です。 ユースケースの中には、リージョン内のサービス全体の停止に特に敏感なものがあります。

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

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

このトピックの残りの部分では、リージョン間ディザスタリカバリの実装に焦点を当てていますが、 GCP Databricks が 1 つのリージョン内で提供する高可用性の保証を理解することが重要です。 リージョン内の高可用性保証は、次のコンポーネントを対象としています。

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

Databricks コントロール プレーンはゾーン障害に対する回復性があり、ゾーン障害から ~15 分以内に自動的に回復する必要があります。これは、定期的なゾーン故障テストで検証されます。すべてのステートレス コントロール プレーン サービスは、個々の VM だけでなく、ゾーン全体のすべての VM の損失を自動的に処理できます。ワークスペース データは、リージョン内のゾーン間でレプリケートされたデータベースに格納されます。Databricks Runtime イメージの提供に使用されるストレージ アカウントもリージョン内で冗長であり、すべてのリージョンには、プライマリがダウンしたときに使用されるセカンダリ ストレージ アカウントがあります。

ゾーン障害の耐障害性は、1 つのリージョンでダウンしているゾーンを最大で 1 つだけサポートします。

ゾーンレジリエンスは、GCP リージョンでまだ有効になっていない可能性があります。詳細については、利用可能な地域のページをご覧ください。 サポートされていないリージョンでゾーン回復性が必要な場合は、Databricks アカウント チームにお問い合わせください。

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

ワークスペースの可用性は、コントロールプレーンの可用性によって異なります(前述のとおり)。DBFSルート上のデータは影響を受けません。GCS データは、ゾーン間でデータの冗長性を持つリージョン化されます。

クラスタリング用のノードはすべて、 GCP コンピュートプロバイダーから 1 つの AZ に割り当てられます。 ノードが失われた場合、クラスタリングマネージャーは、同じ AZ 内の GCP コンピュートプロバイダーに交換ノードをリクエストします。 唯一の例外は、ドライバー ノードが失われた場合です。この場合、クラスタリング マネージャーはジョブとクラスタリングを再開します。 クラスタリングを含む AZ がゾーン障害の影響を受けている場合、クラスタリングマネージャーは別の AZ でジョブとクラスタリングを再起動します。

ディザスタリカバリ overview​

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

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

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

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

用語​

地域の用語​

この記事では、地域について次の定義を使用します。

  • プライマリ リージョン : ユーザーが一般的な日常的な対話型で自動化されたデータ分析ワークロードを実行する地理的リージョン。 セカンダリ リージョン : プライマリ リージョンの停止中に IT チームがデータ分析ワークロードを一時的に移動する地理的リージョン。

  • geo 冗長ストレージ : Google Cloud は、非同期ストレージ レプリケーション プロセスを使用して、永続化された GCS バケットに対して リージョン間で geo 冗長ストレージ を提供します。

important

ディザスタリカバリ プロセスの場合、Databricks GCSでは、Google Cloud アカウント内の 2 つの バケット (Databricks ワークスペースごとに作成される) など、リージョンをまたいでのデータ重複に geo 冗長 ストレージに依存しないことを おすすめします。一般に、 Delta テーブルにはディープクローンを使用し、他のデータ形式には可能であればデータを Delta 形式に変換してディープクローンを使用します。

デプロイ状態の用語​

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

  • アクティブなデプロイ : ユーザーは、Databricks ワークスペースのアクティブなデプロイに接続し、ワークロードを実行できます。ジョブは、Databricks スケジューラまたはその他のメカニズムを使用して定期的にスケジュールされます。このデプロイメントでは、データ・ストリームも実行できます。一部のドキュメントでは、アクティブなデプロイメントを ホットデプロイメント と呼んでいる場合があります。

  • パッシブ デプロイ : プロセスはパッシブ デプロイでは実行されません。IT チームは、コード、構成、およびその他の re:[Databricks] オブジェクトをパッシブ デプロイにデプロイするための自動化された手順を設定できます。デプロイメントがアクティブになるのは、現在アクティブなデプロイメントがダウンしている場合 のみです 。一部のドキュメントでは、パッシブ展開を コールド展開 と呼んでいる場合があります。

important

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

通常、チームは一度に 1 つのアクティブ展開のみを持ち、 アクティブ/パッシブ ディザスタリカバリ戦略と呼ばれます。 あまり一般的ではないディザスタリカバリ ソリューション戦略は 、アクティブ/アクティブと呼ばれ、2 つのアクティブ展開が同時に存在します。

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

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

  • 目標復旧時点 : 目標復旧時点 (RPO) は、重大なインシデントによって IT サービスからデータ (トランザクション) が失われる可能性がある最大目標期間です。Databricks のデプロイには、主要な顧客データは保存されません。これは、Google Cloud Storageやお客様の管理下にある他のデータソースなど、別のシステムに保存されます。Databricks コントロール プレーンには、ジョブやノートブックなど、一部のオブジェクトが一部または全部格納されます。Databricks の場合、RPO は、ジョブやノートブックの変更などのオブジェクトが失われる可能性のある最大目標期間として定義されます。また、Google Cloud Storage またはお客様の管理下にある他のデータソース内のお客様ご自身の顧客データの RPO を定義する責任もお客様にあります。

  • 目標復旧時間 : 目標復旧時間 (RTO) は、災害後にビジネス プロセスを復旧する必要がある目標期間とサービス レベルです。

    ディザスタリカバリのRPOとRTO

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

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

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

Databricksディザスタリカバリシナリオは、通常、次のように展開されます。

  1. プライマリリージョンで使用している重要なサービスで障害が発生しました。 これは、 Databricks デプロイに影響を与えるデータソース サービスまたはネットワークである可能性があります。

  2. クラウドプロバイダーと状況を調査します。

  3. プライマリ リージョンで問題が修復されるのを会社が待てないと結論付けた場合は、セカンダリ リージョンにフェールオーバーすることを決定する可能性があります。

  4. 同じ問題がセカンダリ リージョンにも影響しないことを確認します。

  5. セカンダリ リージョンにフェールオーバーします。

    1. ワークスペース内のすべてのアクティビティを停止します。ユーザーはワークロードを停止します。ユーザーまたは管理者は、可能であれば最近の変更のバックアップを作成するように指示されます。ジョブは、停止のためにまだ失敗していない場合、シャットダウンされます。
    2. セカンダリ リージョンで復旧手順を開始します。復旧手順では、ルーティングが更新され、接続とネットワーク トラフィックの名前がセカンダリ リージョンに変更されます。
    3. テスト後、セカンダリ リージョンが動作可能であることを宣言します。 本番運用ワークロードを再開できるようになりました。 ユーザーは、現在アクティブなデプロイメントにログインできます。 スケジュールされたジョブまたは遅延したジョブを再トリガーできます。

    Databricks のコンテキストでの詳細な手順については、「 テスト フェールオーバー」を参照してください。

  6. ある時点で、プライマリ リージョンの問題が軽減され、この事実を確認します。

  7. プライマリ リージョンに復元 (フェールバック) します。

    1. セカンダリ リージョンのすべての作業を停止します。
    2. プライマリリージョンでリカバリ手順を開始します。 復旧手順では、接続とネットワーク トラフィックのルーティングと名前の変更がプライマリ リージョンに処理されます。
    3. 必要に応じて、データをプライマリ リージョンにレプリケートします。複雑さを軽減するには、レプリケートする必要があるデータの量を最小限に抑えます。たとえば、一部のジョブをセカンダリデプロイで実行したときに読み取り専用になる場合、そのデータをプライマリリージョンのプライマリデプロイにレプリケートし直す必要がない場合があります。ただし、本番運用 ジョブが 1 つあり、そのジョブを実行する必要があり、プライマリ リージョンへのデータ レプリケーションが必要になる場合があります。
    4. プライマリ リージョンでデプロイをテストします。
    5. プライマリ リージョンが運用可能であり、それがアクティブなデプロイであることを宣言します。 本番運用ワークロードを再開します。

    プライマリ リージョンへの復元の詳細については、「 テスト復元 (フェールバック)」を参照してください。

important

これらの手順では、データが失われる可能性があります。 組織は、許容されるデータ損失の量と、この損失を軽減するために何ができるかを定義する必要があります。

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

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

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

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

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

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

  • ネットワーク構成を迅速に変更するために、どのようなツールを使用しますか?
  • 構成を事前に定義し、モジュール化して、自然で保守可能な方法でディザスタリカバリソリューションに対応できますか?
  • ディザスタリカバリのフェイルオーバーとフェイルバックの変更について、社内のチームとサードパーティ(インテグレーション、ダウンストリームの消費者)に通知するコミュニケーションツールとチャンネルはどれですか? 彼らの承認をどのように確認しますか?
  • どのようなツールや特別なサポートが必要ですか?
  • 完全な復旧が完了するまで、どのサービスがシャットダウンされますか?

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

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

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

ディザスタリカバリ - 何をレプリケートする必要がありますか?

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

ディザスタリカバリ計画を成功させるための一般的なベストプラクティスには、次のようなものがあります。

  1. ビジネスにとって重要で、ディザスタリカバリで実行する必要があるプロセスを理解します。

  2. どのサービスが関係しているか、どのデータが処理されているか、データフローは何か、どこに保存されているかを明確に特定します。

  3. サービスとデータを可能な限り分離します。 たとえば、ディザスタリカバリ用のデータ用の特別なクラウドストレージコンテナを作成したり、ディザスタ時に必要なDatabricksオブジェクトを別のワークスペースに移動したりします。

  4. Databricks コントロール プレーンに格納されていない他のオブジェクトのプライマリ デプロイとセカンダリ デプロイ間の整合性を維持するのは、お客様の責任です。

警告

ベスト プラクティスは、ワークスペースのルート アクセスに使用されるルート GCS バケットにデータを格納しないこと DBFS。 DBFSルート ストレージは、本番運用 顧客データではサポートされていません。 また、ライブラリ、設定ファイル、initスクリプトをこの場所に保存しないこともDatabricks推奨しています。

  1. データソースについては、可能な場合は、レプリケーションと冗長性のためにネイティブの Google Cloud ツールを使用して、データをディザスタリカバリ リージョンに複製することをおすすめします。

リカバリソリューション戦略の選択​

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

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

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

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

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

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

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

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

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

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

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

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

プライマリリージョンとセカンダリリージョンのワークスペース間でデータを可能な限り類似させるためのツールには、主に 2 つの方法があります。

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

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

ディザスタリカバリオプション

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

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

説明

CI/CDツールでの処理方法

同期ツールでの扱い方

ソース code: ノートブック ソース exports と ソース code for packaged ライブラリ

プライマリとセカンダリの両方に共同デプロイします。

ソース コードをプライマリからセカンダリに同期します。

ユーザーとグループ

メタデータを Git で config として管理します。 または、両方のワークスペースに同じ ID プロバイダー (IdP) を使用します。 ユーザーとグループのデータをプライマリとセカンダリのデプロイに共同デプロイします。

両方のリージョンで SCIM またはその他の自動化を使用します。手動で作成することはお勧め しません が、使用する場合は両方に対して同時に行う必要があります。手動セットアップを使用する場合は、スケジュールされた自動プロセスを作成して、2 つのデプロイメント間でユーザーとグループのリストを比較します。

プールの構成

Git のテンプレートにすることができます。 プライマリとセカンダリに共同デプロイします。 ただし、セカンダリの min_idle_instances は、ディザスタリカバリ イベントまで 0 である必要があります。

任意の min_idle_instances で作成されたプールは、API または CLI を使用してセカンダリ ワークスペースに同期されます。

ジョブ構成

Git のテンプレートにすることができます。プライマリ・デプロイメントの場合は、ジョブ定義をそのままデプロイします。セカンダリ デプロイの場合は、ジョブをデプロイし、コンカレンシーを 0 に設定します。これにより、このデプロイメントのジョブが無効になり、余分な実行が防止されます。コンカレンシー値は、セカンダリ デプロイがアクティブになった後に変更します。

何らかの理由で既存の <interactive> クラスターでジョブが実行された場合、同期クライアントはセカンダリワークスペース内の対応する cluster_id にマップする必要があります。

アクセスコントロールリスト (ACL)

Git のテンプレートにすることができます。 ノートブック、フォルダー、クラスターのプライマリデプロイとセカンダリデプロイに共同デプロイします。 ただし、ジョブのデータはディザスタリカバリイベントまで保持します。

Permissions APIでは、クラスター、ジョブ、プール、ノートブック、およびフォルダーのアクセス制御を設定できます。同期クライアントは、セカンダリ ワークスペース内の各オブジェクトの対応するオブジェクト ID にマップする必要があります。 Databricks では、アクセス制御をレプリケート する前に 、プライマリ ワークスペースからセカンダリ ワークスペースへのオブジェクト ID のマップを作成し、それらのオブジェクトを同期することをお勧めします。

ライブラリ

ソース コード テンプレートとクラスター/ジョブ テンプレートに含めます。

一元化されたリポジトリ、DBFS、またはクラウドストレージ(マウント可能)からカスタムライブラリを同期します。

クラスター initスクリプト

必要に応じて、ソース コードに含めます。

同期を簡単にするには、initスクリプトをプライマリワークスペースの共通フォルダに保存するか、可能であれば小さなフォルダセットに保存します。

マウントポイント

ノートブックベースのジョブまたは コマンド APIのみで作成された場合は、ソース コードに含める .

ジョブを使用します。 ワークスペースが異なるリージョンにあるため、ストレージ エンドポイントは変更される可能性があることに注意してください。 これは、データディザスタリカバリ戦略にも大きく依存します。

テーブルのメタデータ

ノートブックベースのジョブまたはコマンド API.これは、内部 Databricks メタストアまたは外部構成メタストアの両方に適用されます。

Spark Catalog API を使用するか、ノートブックまたはスクリプトを使用して Show Create Table を使用して、メタストア間のメタデータ定義を比較します。基になるストレージのテーブルはリージョンベースにすることができ、メタストア インスタンス間で異なることに注意してください。

シークレット

コマンド コードAPI のみを使用して作成された場合は、ソース コードに含める.一部のシークレット コンテンツは、プライマリ コンテンツとセカンダリ コンテンツの間で変更する必要があることに注意してください。

シークレットは、API を介して両方のワークスペースで作成されます。 一部のシークレット コンテンツは、プライマリ コンテンツとセカンダリ コンテンツの間で変更する必要があることに注意してください。

クラスター構成

Git のテンプレートにすることができます。 プライマリ デプロイとセカンダリ デプロイに共同デプロイしますが、セカンダリ デプロイのデプロイは、ディザスタリカバリ イベントが発生するまで終了する必要があります。

クラスターは、 API または CLIを使用してセカンダリ ワークスペースに同期された後に作成されます。 これらは、自動終了の設定に応じて、必要に応じて明示的に終了できます。

ノートブック、ジョブ、フォルダーのアクセス許可

Git のテンプレートにすることができます。 プライマリ展開とセカンダリ展開に共同展開します。

Permissions API を使用してレプリケートします。

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

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

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

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

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

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

その後のコピーおよび同期アクションは、最初の 1 回限りのコピー操作の後の方が高速です。ツールからのログ記録には、いつ、何が変更されたかも記録されます。

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

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

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

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

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

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

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

データストリーム​

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

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

いずれの場合も、ディザスタリカバリモードを処理し、セカンダリリージョンでセカンダリデプロイを使用するようにデータソースを設定する必要があります。

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

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

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

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

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

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

important

ディザスタリカバリ ソリューションを実際の条件で定期的にテストしてください。

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

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

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

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

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

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

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

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

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

  1. テストを実行して、プラットフォームが最新の状態であることを確認します。

  2. プライマリ リージョンでプールとクラスターを無効にして、障害が発生したサービスがオンラインに戻った場合にプライマリ リージョンが新しいデータの処理を開始しないようにします。

  3. 回復プロセス:

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

  4. 関連するプールを開始します (または、 min_idle_instances を関連する数に増やします)。

  5. 関連するクラスターを開始します (終了していない場合)。

  6. ジョブの並列実行を変更し、該当するジョブを実行します。 これらは、1 回限りの実行または定期的な実行です。

  7. DatabricksワークスペースのURLまたはドメイン名を使用する外部ツールの場合は、新しいコントロールプレーンの構成をアカウントに更新します。たとえば、 REST API 接続と JDBC/ODBC 接続のURLを更新します。 コントロール プレーンが変更されると、Databricks Web アプリケーションの顧客向け URL が変更されるため、組織のユーザーに新しい URL を通知してください。

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

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

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

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

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

追加のリソース​

に最終更新