障害復旧

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

Azure Databricks は、多くの場合、アップストリームのデータ インジェスト サービス (バッチ/ストリーミング)、ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) のようなクラウド ネイティブのストレージ、ビジネス インテリジェンス アプリのようなダウンストリームのツールとサービス、オーケストレーション ツールといった多くのサービスを含むデータ エコシステム全体の中核部分です。 ユース ケースによっては、地域的なサービス全体の停止にとりわけ影響を受けやすい場合があります。

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

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

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

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

• ほとんどのコントロール プレーン サービスは Kubernetes クラスターで実行されていて、特定の AZ 内の VM の損失を自動的に処理します。
• ワークスペース データは、Premium Storage を持つデータベースに格納され、リージョン全体にレプリケートされます。 データベース (単一サーバー) のストレージは、異なる AZ またはリージョンにはレプリケートされません。 ゾーンの停止がデータベースのストレージに影響を与える場合は、バックアップから新しいインスタンスを起動することでデータベースが復旧されます。
• DBR イメージの提供に使用されるストレージ アカウントもリージョン内で冗長であり、すべてのリージョンに、プライマリがダウンしたときに使用されるセカンダリ ストレージ アカウントがあります。 「Azure Databricks のリージョン」を参照してください。
• 一般に、コントロール プレーン機能は、可用性ゾーンが復旧してから約 15 分以内に復元するはずです。

コンピューティング プレーンの可用性

• ワークスペースの可用性は、コントロール プレーンの可用性に依存します (前述のとおり)。
• DBFS ルートのストレージ アカウントが ZRS または GZRS (既定値は GRS) で構成されている場合、DBFS ルート上のデータは影響を受けません。
• クラスターのノードは、Azure コンピューティング プロバイダーからノードを要求することによって、異なる可用性ゾーンからプルされます (残りのゾーンの容量が要求を満たすために十分な場合)。 ノードが失われた場合、クラスター マネージャーが Azure コンピューティング プロバイダーに交換ノードを要求し、それによって使用可能な AZ からノードがプルされます。 唯一の例外は、ドライバー ノードが失われた場合です。 この場合、ジョブまたはクラスター マネージャーによって再起動されます。

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

ディザスター リカバリーには、自然災害や人為的な災害が発生した後も、重要なテクノロジ インフラストラクチャおよびシステムの復旧または継続動作を可能にする一連のポリシー、ツール、手順が含まれます。 Azure のような大規模クラウド サービスは、多くの顧客にサービスを提供し、1 つの障害に対する保護機能が組み込まれています。 たとえば、リージョンは複数の異なる電源に接続した建物のグループであり、その目的は、1 つの電源が失われてもリージョンがシャットダウンしないことの保証です。 それでも、クラウド リージョンの障害は起こりうるものであり、中断の程度や組織への影響はさまざまです。

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

高可用性は、システムの回復性の特性です。 高可用性は、安定した稼働時間または稼働時間の割合で定義されるのが通例である最小レベルの運用パフォーマンスを保証するものです。 高可用性は、プライマリ システムの機能として設計することによって (プライマリ システムと同じリージョンに) 実装されます。 たとえば、Azure などのクラウド サービスには、ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) などの高可用性サービスがあります。 高可用性は、大規模で明示的な準備を Azure Databricks の顧客に要求するものではありません。

これに対し、ディザスター リカバリー計画には、クリティカルなシステムがリージョンのレベルで大規模に停止する事態に対処するために、特定の組織にとって有効である意思決定とソリューションが必要です。 この記事では、一般的なディザスター リカバリーの用語、一般的なソリューション、Azure Databricks を使用したディザスター リカバリー計画のベスト プラクティスについて説明します。

用語

リージョンの用語

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

• プライマリ リージョン: 一般的で日常的な Data Analytics ワークロードを、ユーザーが対話形式および自動化された形式で実行する地理的リージョン。

• セカンダリ リージョン: プライマリ リージョンの停止中に IT チームが Data Analytics ワークロードを一時的に移動する地理的リージョン。

• geo 冗長ストレージ: Azure では、非同期のストレージ レプリケーション プロセスを使用したストレージ永続化のために、リージョン横断の geo 冗長ストレージが用意されています。

  重要

  ディザスター リカバリー プロセスに関して、Azure サブスクリプション内の各ワークスペースに対して Azure Databricks が作成する ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) などのデータのリージョン間複製を geo 冗長ストレージに依存 "しない" ことを Databricks では推奨しています。 一般に、Delta テーブルには Deep Clone を使用してください。その他のデータ形式に関しては、可能であれば Delta 形式にデータを変換して Deep Clone を使用してください。

デプロイ状態の用語

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

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

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

  重要

  プロジェクトでは、必要に応じて、異なるリージョンに複数のパッシブ デプロイを含めて、リージョンの停止を解決するための選択肢を増やすことができます。

一般的に、アクティブ/パッシブと呼ばれるディザスター リカバリー戦略では、同時に 1 つのアクティブ デプロイのみをチームで運用します。 あまり一般的ではありませんが、2 つのアクティブ デプロイを同時に運用する、アクティブ/アクティブと呼ばれるディザスター リカバリー ソリューション戦略もあります。

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

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

• 目標復旧時点: 目標復旧時点 (RPO) は、メジャー インシデントの発生時に、超過すると IT サービスからデータ (トランザクション) が失われる可能性がある最長の目標期間です。 Azure Databricks デプロイには、メインの顧客データは格納されません。 これは、ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) などの別個のシステム、または制御下にある他のデータ ソースに格納されます。 Azure Databricks コントロール プレーンには、ジョブやノートブックなどの一部のオブジェクトが部分的または完全に格納されます。 Azure Databricks の場合、RPO は、超過するとジョブやノートブックの変更などのオブジェクトが失われる可能性がある最長の目標期間として定義されます。 これに加えて、ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) や、制御下にある他のデータ ソース内の独自の顧客データの RPO も定義する必要があります。

• 目標復旧時間: 目標復旧時間 (RTO) は、災害発生後にビジネス プロセスを復旧しなければならない期限を表す時間とサービス レベルの目標です。

  

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

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

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

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

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

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

3. プライマリ リージョンで問題が解決するまで会社は待つことができないという結論に至った場合、セカンダリ リージョンへのフェールオーバーが必要であると判断することができます。

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

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

   1. ワークスペース内のすべてのアクティビティを停止します。 ユーザーがワークロードを停止します。 ユーザーまたは管理者は、可能であれば最近の変更のバックアップを取るように指示されます。 停止が原因でまだ失敗していないジョブはシャットダウンされます。
   2. セカンダリ リージョンで復旧手順を開始します。 復旧手順では、セカンダリ リージョンへの接続とネットワークトラフィックのルーティングと名前が更新されます。
   3. テストが終了したら、セカンダリ リージョンの稼働を宣言します。 これで、実稼働ワークロードを再開できます。 ユーザーは、新しくアクティブになったデプロイにログインできます。 スケジュールまたは遅延していたジョブをもう一度トリガーできます。

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

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

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

   1. セカンダリ リージョンでのすべての作業を中止します。
   2. プライマリ リージョンで復旧手順を開始します。 復旧手順では、プライマリ リージョンへの接続とネットワーク トラフィックのルーティングと名前変更が処理されます。
   3. 必要に応じて、プライマリ リージョンにデータをレプリケートします。 複雑さを減らすために、レプリケートする必要があるデータの量を最小限にします。 たとえば、セカンダリ デプロイでの実行時に読み取り専用であるジョブに関しては、そのデータをプライマリ リージョンのプライマリ デプロイにレプリケートする必要はないかもしれません。 一方で、実行する必要がある実稼働ジョブに関しては、プライマリ リージョンへのデータ レプリケーションが必要な場合があります。
   4. プライマリ リージョンでデプロイをテストします。
   5. プライマリ リージョンが稼働状態であり、アクティブ デプロイであることを宣言します。 実稼働ワークロードを再開します。

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

重要

これらの手順の間に、データの損失が発生する可能性があります。 組織では、許容できるデータ損失の規模と、この損失を軽減するための可能な対策を定義する必要があります。

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

最初のステップは、ビジネス ニーズを定義して理解することです。 クリティカルなデータ サービスと、各サービスの RPO と RTO の期待値を定義します。

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

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

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

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

• ネットワーク構成をすばやく変更するために、どのツールを使用しますか?
• 自然で保守しやすい形でディザスター リカバリー ソリューションを組み込めるよう、構成を事前に定義し、モジュール化することができますか?
• ディザスター リカバリーのフェールオーバーとフェールバックの変更について、どの通信ツールとチャネルによって内部のチームとサードパーティ (統合、ダウンストリームのコンシューマー) に通知しますか? 通知先の受信確認をどのようにして確かめますか?
• どのようなツールまたは特別なサポートが必要になりますか?
• 復旧が完了するまでシャットダウンされるサービスがある場合、どのようなサービスですか?

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

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

VNet インジェクション機能 (すべてのサブスクリプションとデプロイの種類で使用できるわけではありません) を使用する場合、Terraform のようなテンプレートベースのツールを使用して、両方のリージョンにこれらのネットワークを整合性のある形でデプロイすることができます。

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

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

ディザスター リカバリー計画を成功に導くための一般的なベスト プラクティスには、以下のものがあります。

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

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

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

4. Databricks コントロール プレーンに格納されていないその他のオブジェクトに関して、プライマリ デプロイとセカンダリ デプロイの間で整合性を維持する必要があります。

   警告

   ワークスペースの DBFS ルート アクセスに使用されるルート ADLS gen2 (2023 年 3 月 6 日より前に作成されたワークスペースの場合は Azure Blob Storage) にはデータを保存 "しない" ことがベスト プラクティスです。 その DBFS ルート ストレージは、実稼働の顧客データに対してはサポートされていません。 また、Databricks は、この場所にライブラリ、構成ファイル、または init スクリプトを保存しないように推奨しています。

5. データ ソースの場合、可能であれば、レプリケーションと冗長性のためのネイティブ Azure ツールを使用して、ディザスター リカバリー リージョンにデータをレプリケートすることをお勧めします。

リカバリー ソリューションの戦略を選択する

典型的なディザスター リカバリー ソリューションには、2 つ (以上) のワークスペースが関係します。 複数の戦略から選択できます。 中断の潜在的な長さ (数時間、場合によっては 1 日)、ワークスペースが完全に動作可能な状態を確保するための取り組み、プライマリ リージョンに復元 (フェールバック) するための取り組みを検討します。

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

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

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

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

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

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

アクティブ/アクティブ ソリューションでは、両方のリージョンのすべてのデータ プロセスを常に並列実行します。 運用チームは、ジョブなどのデータ プロセスについて、両方のリージョンで正常に終了した時点ではじめて完了とマークされることを保証する必要があります。 オブジェクトは実稼働では変更できず、開発/ステージングから実稼働への厳密な CI/CD 昇格に従う必要があります。

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

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

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

ツールを選択する

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

• プライマリからセカンダリにコピーする同期クライアント: 同期クライアントにより、実稼働のデータとアセットをプライマリ リージョンからセカンダリ リージョンにプッシュします。 通常、これはスケジュールに基づいて実行されます。
• 並列デプロイ用の CI/CD ツール: 実稼働のコードとアセットに対して、実稼働システムへの変更を両方のリージョンに同時にプッシュする CI/CD ツールを使用します。 たとえば、ステージング/開発から実稼働にプッシュされたコードとアセットは、CI/CD システムの働きによって同時に、両方のリージョンで使用可能になります。 中核となる考え方は、Azure 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 スクリプトをプライマリ ワークスペースの共通フォルダーまたは (可能であれば) フォルダーの小さなセットに保存します。
マウント ポイント	ノートブックベースのジョブまたはコマンド API のみを使用して作成された場合は、ソース コードに含めます。	Azure Data Factory (ADF) アクティビティとして実行できるジョブを使用します。 ワークスペースが異なるリージョンにある場合、ストレージのエンドポイントが変わる可能性があることに注意してください。 これは、データのディザスター リカバリー戦略にも大きく依存します。
テーブルのメタデータ	ノートブックベースのジョブまたはコマンド API のみを使用して作成された場合は、ソース コードと共に含めます。 これは、内部の Azure Databricks メタストアと、外部で構成されたメタストアのどちらにも当てはまります。	Spark Catalog API を使用するか、ノートブックまたはスクリプトから Show Create Table を使用して、メタストア間でメタデータ定義を比較します。 基になるストレージのテーブルはリージョンベースである可能性があり、メタストア インスタンス間で異なることに注意してください。
シークレット	コマンド API のみを使用して作成された場合は、ソース コードに含めます。 一部のシークレット コンテンツについては、プライマリとセカンダリの間で変更が必要な場合があることに注意してください。	シークレットは、API を使用して両方のワークスペースに作成されます。 一部のシークレット コンテンツについては、プライマリとセカンダリの間で変更が必要な場合があることに注意してください。
クラスター構成	Git でテンプレートにすることができます。 プライマリ デプロイとセカンダリ デプロイに同時デプロイしますが、セカンダリ デプロイではディザスター リカバリーイベントまで終了する必要があります。	クラスターは、API または CLI を使用してセカンダリ ワークスペースに同期された後に作成されます。 自動終了の設定によっては、必要に応じて明示的に終了することができます。
ノートブック、ジョブ、フォルダーのアクセス許可	Git でテンプレートにすることができます。 プライマリ デプロイとセカンダリ デプロイに同時デプロイします。	Permissions API を使用してレプリケートします。

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

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

Azure で、使用可能な製品と VM の種類に加えて、データ レプリケーションを確認します。

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

ワークスペースが既に実稼働である場合、1 回限りのコピー操作を実行して、パッシブ デプロイをアクティブ デプロイと同期させるのが一般的です。 この 1 回限りのコピーにより、以下が処理されます。

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

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

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

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

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

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

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

データ ストリーム

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

• Kafka などのメッセージ キュー
• データベース変更データ キャプチャ ストリーム
• ファイルベースの連続処理
• ファイルベースのスケジュールされた処理 (トリガー ワンスとも呼ばれる)

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

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

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

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

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

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

ディザスター リカバリーのセットアップを定期的にテストして、正しく機能することを確認します。 必要なときに使用できないディザスター リカバリー ソリューションは、維持する価値がありません。 企業によっては、数か月ごとにリージョンを切り替えます。 定期的なスケジュールでリージョンを切り替えることによって、想定とプロセスをテストし、それらが復旧のニーズを満たしていることを確認できます。 これにより、緊急事態に備えたポリシーと手順を組織が理解していることも保証されます。

重要

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

オブジェクトまたはテンプレートが不足しており、プライマリ ワークスペースに格納されている情報にまだ依存する必要があることがわかった場合は、計画を変更してこれらの障害を除去するか、セカンダリ システムにこの情報をレプリケートするか、他の何らかの手段で入手できるようにしてください。

プロセスと構成全般に合わせて組織の変更が必要であれば、テストします。 ディザスター リカバリー計画はデプロイ パイプラインに影響を及ぼすため、同期を維持する必要がある要素をチームが認識していることが重要です。ディザスター リカバリー ワークスペースを設定したら、インフラストラクチャ (手動またはコード)、ジョブ、ノートブック、ライブラリ、その他のワークスペース オブジェクトがセカンダリ リージョンで使用可能であることを確認する必要があります。

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

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

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

フェールオーバーをテストする

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

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

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

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

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

フェールバックは制御が容易で、メンテナンス期間中に実行できます。 この計画には、以下の一部または全部が含まれる可能性があります。

1. プライマリ リージョンが復元されたことを確認します。
2. セカンダリ リージョンのプールとクラスターを無効にして、新しいデータの処理を開始しないようにします。
3. 新しいアセットや変更されたアセットがセカンダリ ワークスペースにある場合、プライマリ デプロイに同期します。 フェールオーバー スクリプトの設計によっては、同じスクリプトを実行して、セカンダリ (ディザスター リカバリー) リージョンのオブジェクトをプライマリ (実稼働) リージョンに同期できる場合があります。
4. 新しいデータ更新がある場合、プライマリ デプロイに同期します。 ログの監査証跡と Delta テーブルを使用して、データの損失がないことを保証できます。
5. ディザスター リカバリー リージョンのすべてのワークロードをシャットダウンします。
6. ジョブとユーザーの URL をプライマリ リージョンに変更します。
7. テストを実行して、プラットフォームが最新であることを確認します。
8. 関連するプールを開始します (または、min_idle_instances を適切な数に増やします)。
9. 関連するクラスターを開始します (終了していない場合)。
10. ジョブの同時実行を変更し、関連するジョブを実行します。 これらは、1 回限りの実行または定期的な実行である可能性があります。
11. 必要に応じて、将来のディザスター リカバリーのためにセカンダリ リージョンをもう一度設定します。

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

ディザスター リカバリー プロジェクトで検討する自動化スクリプトには、次のようなものがあります。

• Databricks では、独自の同期プロセスの開発に役立つ Databricks Terraform プロバイダーを使用することを推奨しています。
• サンプル スクリプトとプロトタイプ スクリプトについては、Databricks ワークスペース移行ツールに関するページも参照してください。 Azure Databricks オブジェクトに加えて、関連する Azure Data Factory パイプラインをレプリケートして、セカンダリ ワークスペースにマップされているリンクされたサービスをオブジェクトが参照するようにします。
• Databricks Sync (DBSync) プロジェクトは、Databricks ワークスペースをバックアップ、復元、同期するオブジェクト同期ツールです。