Azure Databricksのディザスター リカバリー (DR) では、ワークスペース、データ、および構成がクラウド リージョン間でレプリケートされるため、リージョンの障害によってプライマリ デプロイがオフラインになったときにチームが作業を続けることができます。 完全な DR プランでは、Azure Databricksだけでなく、接続するデータ ソース、インジェスト ツール、BI ツール、スケジューラも対象としています。
このページでは、リージョンをまたがる DR ソリューションを設計して実行するために必要な概念、戦略、ツール、およびテスト手順について説明します。
DR 計画を初めて使用する場合 RPO と RTO の定義に関する ディザスター リカバリー業界の用語 から始めます。
重要
マネージド ディザスター リカバリーを使用します。 Azure Databricksでは、AWS とAzureでのリージョン間 DR のマネージド ディザスター リカバリーをお勧めします。 これにより、Unity カタログメタデータ、マネージド テーブル データ、ワークスペース資産が継続的なスケジュールでレプリケートされ、フェールオーバー後も存続する安定した URL が提供され、アカウント コンソールからフェールオーバーをトリガーできます。 書き込みまたは保守するレプリケーション スクリプトはありません。 このページの DIY ガイダンスは、マネージド DR がレプリケートしないリソース、またはアクティブ/アクティブ トポロジ、クロスクラウド レプリケーション、またはレプリケーション パイプラインのきめ細かい制御が必要な場合にのみ使用します。
リージョン内の高可用性の保証
このページの残りの部分ではリージョン間 DR について説明しますが、Azure Databricksでは単一リージョン内の高可用性 (HA) も提供されます。 これらの保証を最初に理解します。 個別の DR 戦略が必要かどうかを判断します。
HA と DR は、さまざまな問題を解決します。
- HA では、リージョン内の可用性ゾーン (AZ) 冗長性が使用されます。 1 つのゾーンで障害が発生した場合、サービスは他のゾーンで引き続き実行されます。
- DR はリージョン間レプリケーションを使用します。 セカンダリ Azure Databricks ワークスペースを別のリージョンで実行し、データと構成をレプリケートしてから、リージョンの停止中にフェールオーバーします。
複数リージョンの DR が不要な場合は、Azure Databricks HA で十分な場合があります。 HA はリージョン間の複雑さを回避しますが、リージョン全体の停止から保護しません。 DR に対して HA だけに依存している場合は、クラウド リージョンの分離と冗長性を確認します。
リージョン内 HA の保証は、コントロール プレーンとコンピューティング プレーンをカバーします。
Azure Databricks コントロール プレーンの可用性
Azure Databricks コントロール プレーンの可用性
Azure Databricksコントロール プレーンはゾーン障害に対する回復力があり、ゾーン障害から約 15 分以内に自動的に回復します。 通常のゾーン障害テストでは、これを検証します。
ステートレス コントロール プレーン サービスはすべて、サービスを停止することなく、個々の VM またはゾーン全体のすべての VM を失う可能性があります。 ワークスペース データは、リージョン内のゾーン間でレプリケートされたデータベースに格納されます。 Databricks ランタイム イメージにサービスを提供するストレージ アカウントもリージョン内で冗長であり、すべてのリージョンにはプライマリがダウンしたときに引き継ぐセカンダリ ストレージ アカウントがあります。
Note
上記のコントロール プレーンの保証は、Azure Databricks マネージド インフラストラクチャに適用されます。 ワークスペース ルート バケットのゾーン冗長ストレージを選択し、可用性ゾーンにまたがるインスタンス プールを使用するなど、コンピューティング プレーン ゾーンの冗長性を担当します。
一部のAzureリージョンでは、ペアリージョンにデプロイされたコントロール プレーンが使用されます。 Azure Databricks リージョン を参照してください。
ゾーン障害の回復性は、最大 1 つのゾーンがダウンしていることをサポートし、複数のゾーンをサポートするAzureリージョンでのみ使用できます。
コンピューティング プレーンの可用性
コンピューティング プレーンの可用性
ワークスペースの可用性は、コントロール プレーンの可用性によって異なります。
ストレージ アカウントがゾーン冗長ストレージ (ZRS) または geo ゾーン冗長ストレージ (GZRS) で構成されている場合、DBFS ルート データは影響を受けません。 既定値は Geo 冗長ストレージ (GRS) です。
クラスター ノードは、残りのゾーンで十分な容量を想定して、Azure コンピューティング プロバイダーにノードを要求することで、異なる可用性ゾーンからプルされます。 ノードが失われた場合、クラスター マネージャーが Azure コンピューティング プロバイダーに交換ノードを要求し、それによって使用可能な AZ からノードがプルされます。 例外は、ドライバー ノードが失われた場合です。 その場合、クラスター マネージャーはジョブとクラスターを再起動します。
マルチ AZ のサポートを確認するには、Azureリージョンの一覧を参照してください。 コンピュート プレーンの複数の可用性ゾーン (AZ) に対する耐性を確保するには、ゾーン冗長ストレージを使用します。
用語
DR についてチームと話し合うときは、これらの定義を一貫して使用してください。
リージョンの用語
リージョンの用語
このページでは、次のリージョン定義を使用します。
プライマリ リージョン: ユーザーが毎日対話型で自動化されたデータ分析ワークロードを実行するリージョン。
セカンダリ リージョン: IT チームがプライマリ リージョンの停止中にワークロードを一時的に移動するリージョン。
地理冗長ストレージ: 永続ストレージのリージョン間での非同期レプリケーション。 クラウドのドキュメントを参照してください。
重要
Azure Databricks が各ワークスペースに対して作成するルート ストレージ（ADLS。2023 年 3 月 6 日より前に作成されたワークスペースでは Azure Blob Storage など）をリージョン間で複製するために、geo 冗長ストレージに依存しないでください。 マネージド テーブル データをレプリケートするには、Delta Deep Clone を使用し、差分データ以外の場合は、可能な場合は最初に Delta に変換します。
展開状態の用語
デプロイメントのステータス用語
このページでは、次の展開状態の定義を使用します。
アクティブなデプロイ ( ホット デプロイとも呼ばれます): ユーザーはそれに接続し、ワークロードを実行します。 ジョブとデータ ストリームは、スケジュールに従ってここで実行されます。
パッシブデプロイ ( コールド デプロイとも呼ばれます): ここで実行されるプロセスはありません。 IT チームは、コード、構成、およびその他のAzure Databricks オブジェクトのデプロイを自動化することで、準備を整えます。 パッシブ デプロイは、アクティブなデプロイがダウンした場合 にのみ アクティブになります。
重要
プロジェクトには、回復性を高める目的で、異なるリージョンに複数のパッシブ デプロイを含めることができます。
ほとんどのチームは、アクティブ /パッシブ 戦略であるアクティブデプロイを一度に 1 つずつ実行します。 あまり一般的でない アクティブ/アクティブ 戦略では、2 つの同時アクティブデプロイが実行されます。
ディザスター リカバリー業界の用語
ディザスター リカバリーの業界用語
チームで次の 2 つの業界用語を定義します。
目標復旧ポイント (RPO): サービスが重大なインシデント中に許容できるデータ損失の最大期間。 RPO を参照してください。
Azure Databricksでは、主要な顧客データは格納されません。 これは、ADLS (2023 年 3 月 6 日より前に作成されたワークスペース、Azure Blob Storage) または制御する他のシステムに存在します。 Azure Databricks コントロール プレーンには一部のオブジェクト (ジョブやノートブックなど) が格納されるため、Azure Databricks RPO は、それらのオブジェクトへの変更が失われる可能性がある最大期間です。 ADLS の顧客データの RPO (2023 年 3 月 6 日より前に作成されたワークスペース、Azure Blob Storage) と、制御するその他のデータ ソースの RPO を定義する責任があります。
目標復旧時間 (RTO): 障害発生後にビジネス プロセスを復元する必要がある最大時間。 RTO を参照してください。
ディザスター リカバリーとデータの破損
ディザスター リカバリーとデータの破損
DR ソリューションでは、データの破損 は軽減されません 。 プライマリ リージョンの破損したデータはセカンダリ リージョンにレプリケートされ、両方のリージョンで破損しています。 この種の障害を軽減するには、 デルタタイムトラベル、類似のツール、またはデータバックアップツールを使用します。
一般的な復旧ワークフロー
Azure Databricks DR シナリオは、通常、次のように再生されます。
- プライマリ リージョンの重要なサービス (データ ソース、ネットワーク、またはAzure Databricksデプロイが依存する別の依存関係) に障害が発生しました。
- クラウド プロバイダーを使用して調査します。
- 待機が許容できない場合は、セカンダリ リージョンにフェールオーバーすることにします。
- 同じ問題がセカンダリ リージョンに影響しないことを確認します。
- フェールオーバー (詳細な手順については、 フェールオーバーのテストを参照してください)。
- すべてのワークスペース アクティビティを停止します。 ユーザーはワークロードを停止し、可能な限り最近の変更をバックアップします。 ジョブは停止します（障害によってまだ失敗していない場合）。
- セカンダリ リージョンの復旧手順を実行して、ルーティングを更新し、接続とネットワーク トラフィックをリダイレクトします。
- ダウンストリーム システム (BI ツール、スケジューラ、サードパーティ統合) をセカンダリ ワークスペースに再ポイントし、接続を再開します。
- テストが終了したら、セカンダリ リージョンの稼働を宣言します。 ユーザーは現在アクティブなデプロイにログインし、スケジュールされたジョブまたは遅延したジョブを再トリガーします。
- プライマリ リージョンの問題が軽減されたら、修正プログラムを確認します。
- フェールバック (詳細については、 復元のテスト (フェールバック) に関するページを参照してください)。
- セカンダリ リージョンのすべての作業を停止します。
- プライマリ リージョンの復旧手順を実行して、ルーティングをリダイレクトします。
- 新しいデータをプライマリ リージョンにレプリケートします。 レプリケートする必要がある内容を最小限に抑えます。 たとえば、セカンダリ 展開で実行された読み取り専用ジョブでは、書き戻しが不要な場合があります。
- プライマリ リージョンのデプロイをテストします。
- プライマリ リージョンをアクティブに宣言し、運用ワークロードを再開します。
重要
一部のデータ損失は、これらの手順中に発生する可能性があります。 組織で許容される損失の量と、それを軽減する方法を定義します。
ステップ 1: ビジネス ニーズを理解する
重要なデータ サービスを特定し、そのターゲット RPO と RTO を定義します。 各システムの実際の許容度を調査します。
DR、フェールオーバー、フェールバックは、データの破損、データの重複 (間違ったストレージの場所への書き込み)、ユーザーが間違ったリージョンで変更を加えるなど、実際のコストとリスクを伴います。
ビジネスに影響を与えるすべてのAzure Databricks統合ポイントをマップし、プランで使用するツールとコミュニケーション チャネルを選択します。
マップする統合ポイント
- DR ソリューションは、対話型プロセス、自動化されたプロセス、またはその両方に対応する必要がありますか?
- どのデータ サービスを使用していますか? 一部はオンプレミスの場合があります。
- 入力データはどのようにしてクラウドに到達しますか?
- 誰がこのデータを使用しますか? ダウンストリームではどのプロセスが消費しますか?
- DR の変更を認識する必要があるサードパーティの統合はありますか?
計画するツールとコミュニケーション
- 構成を事前に定義し、DR ソリューションを自然かつ保守可能な方法で対応できるようにモジュール化することはできますか?
- DR フェールオーバーとフェールバックの変更について、内部チームとサード パーティ (統合、ダウンストリーム コンシューマー) に通知する通信ツールとチャネルはどれですか? 彼らの確認はどのように行いますか?
- 完全な復旧が行われるまで、どのサービス (ある場合) をシャットダウンしますか?
ステップ 2: ビジネス ニーズを満たすプロセスを選択する
既定では マネージド ディザスター リカバリーです。 カスタム スクリプトを使用せずに、ワークスペース レプリケーション、Unity カタログ メタデータ、マネージド テーブル データ、フェールオーバー オーケストレーションを処理します。 以下の DIY ガイダンスは、マネージド DR がレプリケートされないリソース、アクティブ/アクティブ トポロジ、クラウド間レプリケーション、レプリケーション パイプラインに対するきめ細かな制御など、その範囲外の場合にのみ使用してください。
DIY ソリューションでは、コントロール プレーン、コンピューティング プレーン、およびデータ ソース全体で正しいデータをレプリケートする必要があります。 冗長ワークスペースは、異なるリージョンの異なるコントロール プレーンにマップされるため、 同期ツールまたは CI/CD ワークフローのいずれかのスクリプト ベースのソリューションと同期を維持します。 データ自体の場合、ほとんどのチームは、Azure Databricks ジョブ (多くの場合、スケジュール済み) または Delta Deep Clone を使用して、リージョン間でテーブルをコピーします。 コンピューティング プレーン内 (Databricks ランタイム ワーカーなど) からデータを同期する必要はありません。
VNet インジェクション機能 (一部のサブスクリプションとデプロイの種類では使用できない) を使用する場合は、 Terraform などのテンプレート ベースのツールを使用して、両方のリージョンで一貫してネットワークをデプロイします。
必要に応じて、リージョン間でデータ ソースをレプリケートします。
DR ソリューションには通常、2 つ (またはそれ以上) のワークスペースが含まれます。 許容する必要がある中断の長さ、運用作業、プライマリ リージョンにフェールバックするコストに基づいて、次のいずれかの戦略を選択します。
一般的なベスト プラクティス
一般的なベスト プラクティス
成功した DR 計画の一般的なベスト プラクティスは次のとおりです。
- ビジネスにとって重要であり、DR で実行する必要があるプロセスを理解します。
- 関係するサービス、処理されているデータ、データ フローの内容、格納場所を明確に特定します。
- 可能な限りサービスとデータを分離します。 たとえば、DR データ用の特別なクラウド ストレージ コンテナーを作成したり、障害発生時に必要なオブジェクトAzure Databricks別のワークスペースに移動したりします。
- Azure Databricks コントロール プレーンに格納されていないオブジェクトのプライマリデプロイとセカンダリデプロイの間の整合性を維持する責任があります。
- データ ソースの場合は、ネイティブ Azure ツールを使用して、可能な限り DR リージョンにデータをレプリケートします。
警告
DBFS ルート アクセスに使用されるルート ADLS (Azure Blob Storage 2023 年 3 月 6 日より前に作成されたワークスペースの場合) にはデータを格納しないでください。 DBFS ルート ストレージは、運用環境の顧客データではサポートされていません。 Azure Databricks では、ライブラリ、構成ファイル、または init スクリプトをそこに保存することも推奨していません。
アクティブ/パッシブ ソリューション戦略
アクティブ/パッシブ ソリューションの戦略
このセクションでは、最も一般的で、最も単純で、最もコスト効率が高いため、アクティブ/パッシブ戦略に焦点を当てます。 アクティブ/パッシブ ソリューションは、アクティブなデプロイからセカンダリ リージョンのパッシブ デプロイにデータとオブジェクトの変更を同期します。 DR イベント中に、パッシブ デプロイがアクティブになります。
2 つの一般的なバリエーション:
- 統合 (エンタープライズ全体): 1 セットのアクティブデプロイとパッシブデプロイが組織全体をサポートします。
- 部門またはプロジェクト別: 各ドメインは、ニーズに合わせて調整されたプライマリ リージョンとセカンダリ リージョンを備えた独自の DR ソリューションを維持します。
また、データやAzure Databricks オブジェクトを変更しないユーザー クエリなどの読み取り専用ワークロードにパッシブデプロイを使用することもできます。
アクティブ/アクティブ ソリューション戦略
アクティブ-アクティブ ソリューション戦略
アクティブ/アクティブ ソリューションでは、すべてのデータ プロセスが常に両方のリージョンで並列に実行されます。 運用チームは、両方のリージョンで成功 した後 にのみ、各ジョブを完了としてマークする必要があります。 オブジェクトは運用環境では変更できません。また、開発/ステージングから運用環境への厳密な CI/CD 昇格に従う必要があります。
アクティブ-アクティブは最も複雑な戦略であり、ジョブが両方のリージョンで実行されるため、コストも最も高くなりますが、最も低い RTO と RPO を実現できます。
アクティブ-アクティブ構成は、全社規模または部門単位で導入できます。 ワークロードごとに重複するワークスペースは必要ありません。 たとえば、開発ワークスペースやステージング ワークスペースは、多くの場合、同期を維持するよりも開発パイプラインから再構築する方が簡単です。
ツールを選択する
ツールを選択する
プライマリ リージョンとセカンダリ リージョンのワークスペース間でデータの同期を維持するには、主に次の 2 つの方法があります。
- プライマリからセカンダリにコピーする同期クライアント: 同期クライアントは、プライマリ リージョンからセカンダリ リージョンに運用データと資産をプッシュします。 通常、これはスケジュールに基づいて実行され、スケジュールの頻度はターゲットの RTO と RPO によって異なります。
- 並列デプロイ用の CI/CD ツール: 実稼働のコードとアセットに対して、実稼働システムへの変更を両方のリージョンに同時にプッシュする CI/CD ツールを使用します。 たとえば、ステージング/開発から実稼働にプッシュされたコードとアセットは、CI/CD システムの働きによって同時に、両方のリージョンで使用可能になります。 中核となる考え方は、Azure Databricks ワークスペース内のすべての成果物を infrastructure-as-code (コードとしてのインフラストラクチャ) として扱うことです。 ほとんどの成果物はプライマリ ワークスペースとセカンダリ ワークスペースの両方に共同デプロイできますが、一部の成果物は DR イベントの後にのみデプロイする必要がある場合があります。 ツールについては、「オートメーション スクリプト、サンプル、プロトタイプ」を参照してください。
ニーズに応じて、アプローチを組み合わせることができます。 たとえば、ノートブックのソース コードには CI/CD を使用し、プールやアクセス制御などの構成には同期を使用します。
次の表では、各ツール オプションを使用して各種類のデータを処理する方法について説明します。
| 説明 | CI/CD ツールでの処理方法 | 同期ツールを使用して処理する方法 |
|---|---|---|
| ソース コード: ノートブック ソースのエクスポートとパッケージ化されたライブラリのソース コード | プライマリとセカンダリの両方に同時デプロイします。 | プライマリからセカンダリにソース コードを同期します。 |
| ユーザーとグループ | Git でメタデータを設定として管理します。 または、両方のワークスペースに同じ ID プロバイダー (IdP) を使用します。 ユーザーとグループのデータをプライマリ デプロイとセカンダリ デプロイに同時デプロイします。 | 両方のリージョンで SCIM またはその他の自動化を使用します。 手動作成は "非推奨" ですが、使用する場合は両方で同時に行う必要があります。 手動セットアップを使用する場合は、スケジュールされた自動プロセスを作成して、2 つのデプロイ間のユーザーとグループの一覧を比較します。 |
| プール構成 | Git でテンプレートにすることができます。 プライマリとセカンダリに同時デプロイします。 ただし、セカンダリ内の min_idle_instances は、DR イベントまで 0 である必要があります。 |
API または CLI を使用してセカンダリ ワークスペースに同期されるときに、任意の min_idle_instances で作成されたプール。 |
| ジョブ設定 | 環境ごとのターゲット (やprodなど) で drを使用して、同じジョブ定義を両方のリージョンにデプロイします。 セカンダリ デプロイの場合は、ジョブがステージングされるが実行されないようにコンカレンシーを 0 に設定します。 セカンダリ デプロイがアクティブになったら、コンカレンシーの値を変更します。 |
ジョブが何らかの理由で既存の <interactive> クラスターで実行される場合、同期クライアントはセカンダリ ワークスペース内の対応する cluster_id にマップする必要があります。 |
| アクセス制御リスト (ACL) | Git でテンプレートにすることができます。 ノートブック、フォルダー、クラスターの場合、プライマリ デプロイとセカンダリ デプロイに同時デプロイします。 ただし、DR イベントまでジョブのデータを保持します。 | Permissions API では、クラスター、ジョブ、プール、ノートブック、およびフォルダーのアクセス制御を設定できます。 同期クライアントは、セカンダリ ワークスペース内の各オブジェクトの対応するオブジェクト ID にマップする必要があります。 Databricks では、アクセス制御をレプリケートする "前" に、これらのオブジェクトの同期と並行して、プライマリ ワークスペースからセカンダリ ワークスペースへのオブジェクト ID のマップを作成することが推奨されています。 |
| ライブラリ | ソース コードとクラスター/ジョブ テンプレートに含めます。 | 一元化されたリポジトリ、DBFS、またはクラウド ストレージからカスタム ライブラリを同期します (マウントできます)。 |
| クラスター初期化スクリプト | 必要に応じて、ソース コードに含めます。 | より簡単な同期を行う場合は、可能であれば、プライマリ ワークスペースの共通フォルダーまたは少数のフォルダーに init スクリプトを格納します。 |
| マウント ポイント | ノートブックベースのジョブまたはコマンド API のみを使用して作成された場合は、ソース コードに含めます。 | Azure Data Factory (ADF) アクティビティとして実行できるジョブを使用します。 ワークスペースが異なるリージョンにある場合、ストレージのエンドポイントが変わる可能性があることに注意してください。 これは、データ DR 戦略にも大きく依存します。 |
| テーブル メタデータ | Unity カタログ オブジェクト (カタログ、スキーマ、テーブル、ボリューム、および許可) の場合は、 Databricks Terraform プロバイダー または Databricks アセット バンドルと共同デプロイします。 従来の Hive メタストア テーブルの場合は、ノートブック ベースのジョブまたは Command API を使用して作成された場合は、ソース コードを含む create-table ステートメントを含めます。 | Unity カタログ オブジェクトの場合は、 システム テーブル または information_schema からソース メタデータを読み取り、 Databricks SDK を使用してセカンダリ ワークスペースにレプリケートします。 従来の Hive メタストア テーブルの場合は、 Spark Catalog API を 使用してメタストア間でメタデータ定義を比較するか、ノートブックまたはスクリプトを使用して SHOW CREATE TABLE します。 基になるストレージ パスはリージョンベースで、メタストア インスタンス間で異なる場合があります。 |
| シークレット | コマンド API のみを使用して作成された場合は、ソース コードに含めます。 一部のシークレット コンテンツについては、プライマリとセカンダリの間で変更が必要な場合があることに注意してください。 | シークレットは、API を使用して両方のワークスペースに作成されます。 一部のシークレット コンテンツについては、プライマリとセカンダリの間で変更が必要な場合があることに注意してください。 |
| クラスター構成 | Git でテンプレートにすることができます。 プライマリデプロイとセカンダリデプロイに共同デプロイしますが、セカンダリデプロイのデプロイは DR イベントまで終了する必要があります。 | クラスターは、API または CLI を使用してセカンダリ ワークスペースに同期された後に作成されます。 自動終了の設定によっては、必要に応じて明示的に終了することができます。 |
| ノートブック、ジョブ、フォルダーのアクセス許可 | Git でテンプレートにすることができます。 プライマリ デプロイとセカンダリ デプロイに同時デプロイします。 | Permissions API を使用してレプリケートします。 |
リージョンと複数のセカンダリ ワークスペースを選択する
リージョンと複数のセカンダリ ワークスペースを選択する
DR をトリガーするタイミングと、どのセカンダリ リージョンにフェールオーバーするかは、あなたが制御します。 また、通常の操作を再開する前に、DR 環境を安定させる必要もあります。 これは通常、運用と DR 用に複数のAzure Databricks ワークスペースを作成し、セカンダリ フェールオーバー リージョンを選択することを意味します。
セカンダリ リージョンを選択する前に、依存するすべてのリソースとサービス (コンピューティングの種類、製品、統合) が使用可能であることを確認します。 一部のAzure Databricks サービスは、特定のリージョンでのみ使用できます。
また、 データ レプリケーション と VM の種類の可用性も確認します。
ステップ 3: ワークスペースを準備して 1 回限りのコピーを実行する
まず、セカンダリ Azure Databricks ワークスペース (またはワークスペース) と、そのサポートするメタストアを選択したセカンダリ リージョンに立ち上げてください。 セカンダリ ワークスペースには、データまたは資産をレプリケートする前に、プライマリのアカウント、リージョン、ID の構成をミラーリングする必要があります。
マネージド ディザスター リカバリーを使用する場合、フェールオーバー グループの作成時に、Azure Databricksはスコープ内カタログとワークスペース資産の初期ブートストラップを処理します。 これらのリソースに対して 1 回限りコピーを実行する必要はありません。 DR がレプリケートしないデータ ソースまたは資産については、このセクションの残りの部分に進んでください。
マネージド DR のスコープ外で実行されている運用ワークスペースの場合は、 1 回限りのコピー を実行して、パッシブ デプロイをアクティブなデプロイと同期します。 このコピーは次の処理を処理します。
- データ レプリケーション: クラウド レプリケーション ソリューションまたは Delta Deep Clone を使用します。
- トークンの生成: 生成されたトークンを使用して、レプリケーションと将来のワークロードを自動化します。
- ワークスペース レプリケーション: 手順 4: データ ソースを準備する方法を使用してレプリケートします。 ワークスペースの構成、データ、AI/ML 資産のエクスポートに関する包括的なガイダンスについては、「 ワークスペース データのエクスポート」を参照してください。
- ワークスペースの検証: ワークスペースとプロセスをテストして、それらが正常に実行されたことを確認し、期待される結果を生成します。
後続の同期は最初のコピーよりも高速に実行され、ツール ログには変更日時が記録されます。
ステップ 4: データ ソースを準備する
Azure Databricks では、バッチ処理またはデータ ストリームを使用して、さまざまなデータ ソースを処理できます。
データ ソースからのバッチ処理
データ ソースからのバッチ処理
バッチ データは通常、別のリージョンにレプリケートまたは配信できるソースに存在します。
たとえば、多くの場合、データはスケジュールに従ってクラウド ストレージにアップロードされます。 DR モードでは、セカンダリ リージョンのストレージでそれらのアップロードをポイントし、ワークロードを更新して、そのストレージの読み取りと書き込みを行います。
データ ストリーム
データ ストリーム
データ ストリームの処理は、より大きな課題です。 ストリーミング データは、さまざまなソースから取り込み、処理し、ストリーミング ソリューションに送信できます。
- Kafka などのメッセージ キュー
- データベースの変更データをキャプチャするストリーム
- ファイルベースの連続処理
- ファイルベースのスケジュールされた処理 (トリガー ワンスとも呼ばれる)
いずれの場合も、DR モードを処理し、セカンダリ リージョンでセカンダリ デプロイを使用するようにデータ ソースを構成する必要があります。
ストリーム ライターは、処理されたデータに関する情報をチェックポイントに格納します。 このチェックポイントにはデータの場所 (通常はクラウド ストレージ) を含めることができ、ストリームの再起動が確実に成功するよう、この場所を新しい場所に変更する必要があります。 たとえば、チェックポイント配下の source サブフォルダーには、ファイルベースのクラウド フォルダーが格納されている場合があります。
このチェックポイントを、適切なタイミングでレプリケートする必要があります。 チェックポイントの間隔を新しいクラウド レプリケーション ソリューションと同期することを検討してください。
チェックポイントの更新はライターの機能であるため、データ ストリームの取り込みまたは処理、および別のストリーミング ソースへの格納に適用されます。
ストリーミング ワークロードの場合、顧客が管理するストレージでチェックポイントが構成されていることを確認して、最後の障害の時点からワークロードを再開するためにチェックポイントをセカンダリ リージョンにレプリケートできるようにします。 プライマリ プロセスと並行してセカンダリ ストリーミング プロセスを実行することもできます。
ステップ 5: ソリューションを実装してテストする
マネージド ディザスター リカバリーを使用する場合は、アカウント コンソールから計画されたフェールオーバーをトリガーして、セットアップがエンド ツー エンドで動作することを検証できます。 同じ手順では、DR テストと実際の停止の両方について説明します。 「フェールオーバーとフェールバック」を参照してください。
DR セットアップを定期的にテストします。 テストされていない DR プランは、多くの場合、必要なときに失敗します。 一部のチームは、数か月ごとにスケジュールに従ってアクティブなリージョンを切り替え、前提条件の検証、プロセスの演習、Runbook に関するチームの理解を維持します。
重要
通常のスケジュールで、実際の状態で DR ソリューションをテストします。
不足しているオブジェクトまたはテンプレートがテストで明らかになった場合は、プランを更新します。依存関係を削除するか、セカンダリ ワークスペースにレプリケートするか、別の方法で使用できるようにします。
組織と構成の変更もテストします。 DR プランはデプロイ パイプラインに影響するため、チームは同期を維持する必要がある内容を把握する必要があります。DR ワークスペースを設定したら、インフラストラクチャ、ジョブ、ノートブック、ライブラリ、およびその他のワークスペース オブジェクトがセカンダリ リージョンで使用可能であることを確認します。
標準の作業プロセスと構成パイプラインを拡張して、すべてのワークスペースに変更をデプロイします。 ワークスペース間でユーザー ID を管理し、新しいワークスペースのジョブの自動化と監視を構成します。
構成ツールの変更を計画してテストします。
計画とテストの構成変更
次のそれぞれに対して、フェールオーバーの計画を準備し、すべての前提条件をテストします。
- インジェスト: データ ソースの場所と、それらのソースがデータを取得する場所を理解します。 可能であれば、ソースをパラメーター化し、セカンダリ デプロイとリージョンに別の構成テンプレートを使用します。
- 実行の変更: ジョブまたはその他のアクションをトリガーするスケジューラがある場合は、セカンダリ デプロイまたはそのデータ ソースで動作する別のスケジューラが必要になる場合があります。
- 対話型接続: REST API、CLI ツール、またはその他のサービス (JDBC/ODBC など) を使用する場合のリージョンの中断によって、構成、認証、およびネットワーク接続がどのように影響を受ける可能性があるかを検討します。
- オートメーションの変更: すべてのオートメーション ツールに対して。
- 出力: 出力データまたはログを生成するツールの場合。
- ダウンストリームの変更: Azure Databricksに対する読み取りまたは書き込みを行う BI ツール、ダッシュボード、スケジューラ、サードパーティの統合の場合は、セカンダリ ワークスペースで再ポイントし、所有者に通知する方法を計画します。
テスト フェールオーバー
フェールオーバーをテストする
多くのシナリオで DR がトリガーされる可能性があります。クラウド ネットワーク、クラウド ストレージ、または正常にシャットダウンできない別のコア サービスでの予期しない停止。計画的なシャットダウンまたは停止。また、テスト サイクルの一部としてリージョン間の定期的な切り替えも行います。
フェールオーバーをテストするには、システムに接続し、シャットダウンを実行します。 すべてのジョブが完了し、クラスターが停止することを確認してください。
同期クライアント (または CI/CD ツール) は、関連するAzure Databricksオブジェクトとリソースをセカンダリ ワークスペースにレプリケートします。 セカンダリ ワークスペースをアクティブ化するには、プロセスに次の一部またはすべてを含めることができます。
- テストを実行して、プラットフォームが最新であることを確認します。
- プライマリ リージョンのプールとクラスターを無効にして、障害が発生したサービスがオンラインに戻ってもプライマリ リージョンで新しいデータの処理が開始しないようにします。
- データ ソースの復旧プロセスを実行します (以下を参照)。
- 関連するプールを開始します (または、関連する数に
min_idle_instancesを増やします)。 - 関連するクラスターを開始します (終了していない場合)。
- ジョブの同時実行を変更し、関連するジョブを実行します。 これらは、1 回限りの実行または定期的な実行である可能性があります。
- Azure Databricks ワークスペースの URL またはドメイン名を使用する外部ツールの場合は、新しいコントロール プレーンを考慮するように構成を更新します。 たとえば、REST API と JDBC/ODBC 接続の URL を更新します。 コントロール プレーンが変更されると、Azure Databricks Web アプリケーションの顧客向け URL が変更されるため、組織のユーザーに新しい URL を通知します。
復旧プロセスの詳細
- 最も新しく同期されたデータの日付を確認します。 ディザスター リカバリー業界の用語を参照してください。 この手順の詳細は、データの同期方法と固有のビジネス ニーズによって異なります。
- データ ソースを安定させ、それらがすべて使用可能であることを確認します。 Azure Cloud SQL、Delta Lake、Parquet、またはその他のファイルなど、すべての外部データ ソースを含めます。
- ストリーミング復旧ポイントを見つけます。 そこから再起動し、潜在的な重複を特定して排除する準備ができているプロセスを設定します (Delta Lake を使用すると、この作業が容易になります)。
- データ フロー プロセスを完了し、ユーザーに通知します。
復元のテスト (フェールバック)
復元のテスト (フェールバック)
フェールバックは制御が容易で、メンテナンス期間に実行できます。 次の手順の一部またはすべてを計画します。
- プライマリ リージョンが復元されたことを確認します。
- 新しいデータの処理が開始されないように、セカンダリ リージョンのプールとクラスターを無効にします。
- セカンダリ ワークスペース内の新規または変更された資産をプライマリ デプロイに同期します。 フェールオーバー スクリプトの設計によっては、同じスクリプトを実行して、セカンダリ (DR) リージョンからプライマリ (運用) リージョンにオブジェクトを同期できる場合があります。
- 新しいデータ更新をプライマリ デプロイに同期します。 ログとデルタ テーブルの監査証跡を使用して、データの損失を保証できます。
- DR リージョン内のすべてのワークロードをシャットダウンします。
- ジョブ URL とユーザー URL をプライマリ リージョンに変更し、下流側の接続先（BI ツール、スケジューラ、サードパーティ統合）が再びそのリージョンを参照するように再設定します。
- テストを実行して、プラットフォームが最新であることを確認します。
- 関連するプールを開始します (または、関連する数に
min_idle_instancesを増やします)。 - 関連するクラスターを開始します (終了していない場合)。
- ジョブの同時実行を変更し、関連するジョブを実行します。 これらは、1 回限りの実行または定期的な実行である可能性があります。
- 必要に応じて、将来の DR のためにセカンダリ リージョンをもう一度設定します。
自動化スクリプト、サンプル、プロトタイプ
AWS とAzureの場合、マネージド ディザスター リカバリーは、カスタム自動化なしでワークスペースとマネージド テーブルのレプリケーションを処理します。 以下の参照は、マネージド DR のスコープ外で DIY ソリューションを構築している場合にのみ適用されます。
DIY DR パイプラインの場合は、 Databricks Terraform プロバイダー を使用して、ワークスペース資産をコードとして管理し、プライマリ リージョンとセカンダリ リージョンに共同デプロイします。
Azure Data FactoryからAzure Databricksを調整する場合は、関連する ADF パイプラインをレプリケートして、セカンダリ ワークスペースにマップされたリンクされたサービスを参照します。