障害復旧

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

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

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

障害復旧の概要

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

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

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

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

用語

地域の用語

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

  • プライマリ リージョン: ユーザーが一般的な毎日の対話型および自動化されたデータ アナリティクス ワークロードを実行する地理的リージョン。

  • セカンダリ リージョン: プライマリ リージョンでの停止中に IT チームがデータ アナリティクス ワークロードを一時的に移動する地理的リージョン。

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

    重要

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

展開ステータスの 用語

この記事では、展開状態の次の定義を使用します。

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

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

    重要

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

一般に、チームには一度に 1 つのアクティブなデプロイのみがあり、いわゆる アクティブ/パッシブ 障害復旧戦略です。 アクティブ /アクティブと呼ばれるあまり一般的ではないディザスター リカバリー ソリューション戦略があり、2 つのアクティブなデプロイが同時に行われます。

災害復旧業界の用語

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

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

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

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

災害復旧とデータ破損

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

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

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

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

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

  3. プライマリ リージョンで問題が修復されるのを会社が待つことができないと判断した場合は、セカンダリ リージョンへのフェールオーバーが必要であると判断できます。

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

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

    1. ワークスペース内のすべてのアクティビティを停止します。 ユーザーがワークロードを停止します。 ユーザーまたは管理者は、可能であれば、最近の変更のバックアップを作成するように指示されます。 ジョブは、停止のためにまだ失敗していない場合、シャットダウンされます。

    2. 2 次領域でリカバリー手順を開始します。 回復手順では、セカンダリ リージョンへの接続とネットワーク トラフィックのルーティングと名前の変更が更新されます。

    3. テスト後、セカンダリ リージョンが動作可能であることを宣言します。 運用環境のワークロードを再開できるようになりました。 ユーザは、現在アクティブな展開にログインできます。 スケジュールされたジョブまたは遅延ジョブを再トリガーできます。

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

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

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

    1. セカンダリ リージョンでのすべての作業を停止します。

    2. 1 次リージョンでリカバリー手順を開始します。 回復手順では、プライマリ リージョンに戻る接続とネットワーク トラフィックのルーティングと名前変更を処理します。

    3. 必要に応じて、プライマリ リージョンにデータをレプリケートします。 複雑さを軽減するには、レプリケートする必要があるデータの量を最小限に抑えます。 たとえば、セカンダリデプロイで実行したときに一部のジョブが読み取り専用である場合、そのデータをプライマリリージョンのプライマリデプロイにレプリケートする必要がない場合があります。 ただし、実行する必要がある運用ジョブが 1 つあり、プライマリ リージョンへのデータ レプリケーションが必要になる場合があります。

    4. プライマリ リージョンでデプロイをテストします。

    5. プライマリ リージョンが動作可能であり、それがアクティブなデプロイであることを宣言します。 運用環境のワークロードを再開します。

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

重要

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

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

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

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

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

  • 災害復旧ソリューションは、対話型プロセス、自動プロセス、またはその両方に対応する必要がありますか?

  • どのデータサービスを使用していますか? 一部はオンプレミスである可能性があります。

  • 入力データはどのようにしてクラウドに届きますか?

  • 誰がこのデータを消費しますか? どのプロセスがそれを下流で消費しますか?

  • ディザスタリカバリの変更を認識する必要があるサードパーティの統合はありますか?

障害復旧計画をサポートできるツールまたはコミュニケーション戦略を決定します。

  • ネットワーク構成をすばやく変更するためにどのツールを使用しますか?

  • 構成を事前に定義し、モジュール化して、自然で保守可能な方法でディザスタリカバリソリューションに対応できますか?

  • どのコミュニケーションツールとチャンネルが、内部チームとサードパーティ(統合、ダウンストリームコンシューマー)にディザスタリカバリのフェイルオーバーとフェールバックの変更を通知しますか? そして、どのように彼らの承認を確認しますか?

  • どのようなツールや特別なサポートが必要ですか?

  • 完全な復旧が行われるまでシャットダウンされるサービスがある場合、どのサービスですか?

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

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

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

災害復旧 - 何をレプリケートする必要がありますか?

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

障害復旧計画を成功させるための一般的なベスト プラクティスは次のとおりです。

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

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

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

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

    警告

    ワークスペースのルート DBFS アクセスに使用されるルート GCS バケットにはデータ要素を保存し ない ことをお勧めします。 そのルート DBFS ストレージは、本番運用の顧客データではサポートされていません。 ただし、ライブラリ、構成ファイル、initスクリプト、および同様のデータなど、他のオブジェクトを格納することもできます。 これらのオブジェクトをレプリケートする自動化されたプロセスを開発するか、手動展開用にセカンダリ展開を更新するプロセスを忘れずに用意してください。

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

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

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

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

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

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

  • 統合された (エンタープライズごとの) ソリューション: 組織全体をサポートするアクティブおよびパッシブ展開の 1 セット。

  • 部門またはプロジェクトごとのソリューション: 各部門またはプロジェクト ドメインは、個別のディザスター リカバリー ソリューションを維持します。 一部の組織では、部門間でディザスター リカバリーの詳細を分離し、各チームの固有のニーズに基づいて、チームごとに異なるプライマリ リージョンとセカンダリ リージョンを使用する必要があります。

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

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

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

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

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

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

ツーリング の選択

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

  • プライマリからセカンダリにコピーする同期クライアント: 同期クライアントは、運用データと資産をプライマリ リージョンからセカンダリ リージョンにプッシュします。 通常、これはスケジュールに基づいて実行されます。

  • 並列デプロイ用の CI/CD ツール: 運用コードとアセットの場合は、運用システムへの変更を両方のリージョンに同時にプッシュする CI/CD ツール を使用します。 たとえば、コードと資産をステージング/開発から運用環境にプッシュする場合、CI/CD システムによって両方のリージョンで同時に使用できるようになります。 中心的な考え方は、Databricks ワークスペース内のすべての成果物をコードとしてのインフラストラクチャとして扱うことです。 ほとんどのアーティファクトはプライマリ ワークスペースとセカンダリ ワークスペースの両方に共同デプロイできますが、一部のアーティファクトはディザスター リカバリー イベントの後にのみデプロイする必要があります。 ツールについては 、「オートメーション スクリプト、サンプル、およびプロトタイプ」を参照してください。

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

障害復旧オプション

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

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

説明

CI/CD ツールで処理する方法

同期ツールでの対処方法

ソースコード: ノートブックのソースエクスポートとパッケージ化されたライブラリのソースコード

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

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

ユーザーとグループ

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

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

プール構成

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

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

ジョブ構成

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

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

アクセス制御リスト (ACL)

Git のテンプレートにすることができます。 ノートブック、フォルダー、クラスターのプライマリおよびセカンダリ デプロイに共同デプロイします。 ただし、障害回復イベントまでジョブのデータは保持してください。

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

ライブラリ

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

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

Cluster initスクリプト

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

同期を簡単にするには、initScript をプライマリ ワークスペースの共通フォルダーまたは可能であれば少数のフォルダーに格納します。

マウント ポイント

ノートブックベースのジョブまたは コマンド API を使用してのみ作成する場合は、ソース コードに含めます。

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

テーブル メタデータ

ノートブックベースのジョブまたは コマンド API を使用してのみ作成された場合は、ソース コードに含めます。 これは、内部 Databricks メタストアと外部構成済みメタストアの両方に適用されます。

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

secrets

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

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

クラスター構成

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

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

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

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

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

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

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

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

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

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

  • データレプリケーション:クラウドレプリケーションソリューションまたはディープクローン操作を使用して Delta レプリケーションします。

  • トークン生成: トークン生成を使用して、レプリケーションと将来のワークロードを自動化します。

  • ワークスペースレプリケーション: 「ステップ 4: データソースを準備する」で説明されている方法を使用して、ワークスペースレプリケーションを使用します。

  • ワークスペースの検証: - ワークスペースとプロセスが正常に実行され、期待される結果が得られることを確認するためにテストします。

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

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

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

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

  • BigQuery の場合、データは複製されます。 破損したデータは、最大 7 日間回復できます (バックアップがない場合)。

  • Delta Lake を使用する GCS の場合、レプリケーションはバケットタイプ (シングル、デュアル、マルチなど) によって異なります。 破損したデータは、 バキューム 保持に応じて回復できます。

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

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

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

データストリーム

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

  • Kafka や Pub/Sub Lite などのメッセージキュー

  • Database チェンジデータキャプチャ ストリーム

  • ファイルベースの連続処理

  • ファイルベースのスケジュールされた処理 (トリガー ワンスとも呼ばれます)

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

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

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

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

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

ステップ 5: ソリューション の実装とテスト

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

重要

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

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

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

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

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

  • インジェスト: データソースがどこにあり、それらのソースがどこでデータを取得するかを理解します。 可能であれば、ソースをパラメーター化し、セカンダリ デプロイとセカンダリ リージョンを操作するための個別の構成テンプレートがあることを確認します。 フェールオーバーの計画を準備し、すべての前提条件をテストします。

  • 実行の変更: ジョブやその他のアクションをトリガーするスケジューラがある場合は、セカンダリ デプロイまたはその Spec と連携する別のスケジューラを構成する必要がある場合があります。 フェールオーバーの計画を準備し、すべての前提条件をテストします。

  • 対話式接続: REST APIs、CLI ツール、または JDBC/ODBC などの他のサービスの使用に関するリージョンの中断によって、構成、認証、およびネットワーク接続がどのように影響を受けるかを検討します。 フェールオーバーの計画を準備し、すべての前提条件をテストします。

  • 自動化の変更: すべての自動化ツールについて、フェールオーバーの計画を準備し、すべての前提条件をテストします。

  • 出力: 出力データまたはログを生成するツールについては、フェールオーバーの計画を準備し、すべての前提条件をテストします。

テスト フェールオーバー

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

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

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

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

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

  3. 回復プロセス:

    1. 最新の同期データの日付を確認します。 災害復旧業界の用語を参照してください。このステップ の詳細は、データの同期方法と独自のビジネス ニーズによって異なります。

    2. データソースを安定させ、それらがすべて使用可能であることを確認します。 Google クラウド SQL、BigQuery、Pub/Sub などのすべての外部データ ソースと、Delta Lake、Parquet、その他のファイルを含めます。

    3. ストリーミング復旧ポイントを見つけます。 そこから再起動するようにプロセスを設定し、潜在的な重複を特定して排除するプロセスを準備します (Delta Lake Lake を使用すると、これが簡単になります)。

    4. データ フロー プロセスを完了し、ユーザーに通知します。

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

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

  6. ジョブの並列実行を変更し、関連するジョブを実行します。 これらは、1 回限りの実行または定期的な実行である可能性があります。

  7. Databricks ワークスペースに URL またはドメイン名を使用する外部ツールの場合は、新しいコントロール プレーンの構成を [アカウント] に更新します。 たとえば、REST APIs および 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. 必要に応じて、将来のディザスター リカバリーのためにセカンダリ リージョンを再度設定します。

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

災害復旧プロジェクトで考慮すべき自動化スクリプト: