Azure Databricks の Disaster recovery（ディザスターリカバリー／DR） でまず押さえるべき結論は、「高可用性（HA）だけではリージョン全体の障害には備えられない。DRは、別リージョンのワークスペース、データ、構成、ジョブ、接続先まで含めて事前に設計・同期・テストするもの」 という点です。
Microsoft Learn の「Disaster recovery – Azure Databricks」は 2026年4月22日に更新され、Azure Databricks を中核にしたデータ分析基盤で、リージョン障害を想定した復旧設計をどう組むべきかが整理されています。特に data engineers、DBA、analytics leaders は、単に「バックアップがあるか」ではなく、RPO/RTO、フェールオーバー手順、フェールバック、ストリーミングのチェックポイント、CI/CDと同期の使い分けまで確認する必要があります。 (Microsoft Learn)
Azure DatabricksのDisaster recoveryで2026年4月更新から読むべきポイント
Azure Databricks の Disaster recovery は、ノートブックやジョブを別リージョンにコピーするだけの話ではありません。公式ドキュメントでは、Azure Databricks が ADLS、ストリーミング取り込み、BIツール、オーケストレーションツールなどを含むデータエコシステムの中核になりやすいことを前提に、リージョンをまたがる復旧パターンを設計する重要性が説明されています。 (Microsoft Learn)
今回の更新内容を実務目線で読むと、重要なのは次の4点です。
| 確認ポイント | 実務での意味 |
|---|---|
| HAとDRを混同しない | 可用性ゾーン障害への耐性と、リージョン全体の障害対策は別物として設計する |
| RPO/RTOを業務単位で決める | すべてのジョブを同じ復旧目標にせず、売上・監査・顧客影響で優先度を分ける |
| ワークスペース構成も同期対象にする | データだけでなく、ジョブ、権限、クラスター、プール、シークレット、接続先も管理する |
| 定期的にフェールオーバーをテストする | 手順書だけでは不十分。実際にセカンダリリージョンで稼働確認する |
特に注意したいのは、「Azure Databricks のデータはどこにあるのか」を正確に把握することです。メインの顧客データは Azure Databricks の中だけで完結せず、ADLS、外部データソース、Delta Lake、BIツール、ADFなど複数の場所に分散します。そのため、DR設計では「Databricksワークスペース」だけでなく、データフロー全体を対象にする必要があります。 (Microsoft Learn)
HAとDRの違いを間違えると復旧計画は破綻する
Azure Databricks の運用でよくある誤解が、「Databricksは高可用性があるからDRも大丈夫」という考え方です。公式ドキュメントでは、Databricks HA は可用性ゾーン冗長性によるリージョン内のアップタイムを提供する一方、DRは別リージョンへのフェールオーバーを可能にするために、セカンダリワークスペースを構成し、データと構成をレプリケートするものだと明確に分けています。 (Microsoft Learn)
つまり、HAは「同一リージョン内で止まりにくくする仕組み」、DRは「リージョン全体が使えない場合に別リージョンで業務を再開する仕組み」です。
| 項目 | HA | DR |
|---|---|---|
| 主な目的 | 同一リージョン内の継続稼働 | 別リージョンでの業務復旧 |
| 想定障害 | 可用性ゾーン障害、個別VM障害など | リージョン全体の障害、広域ネットワーク障害など |
| 主な準備 | サービス側の冗長性、ZRSなど | セカンダリワークスペース、データ同期、接続先切替、運用手順 |
| 利用者側の設計負荷 | 比較的小さい | 大きい |
| 代表的なリスク | 単一リージョン依存 | 同期漏れ、接続先ミス、データ重複、フェールバック失敗 |
Azure Databricks のコントロールプレーンはゾーン障害に対する回復性を持ち、ゾーン障害から約15分以内に自動復旧する設計が説明されています。ただし、この保証はあくまでリージョン内の高可用性に関するものであり、リージョン全体の停止に対するDRとは別に考える必要があります。 (Microsoft Learn)
実務では、次のように判断すると分かりやすくなります。
- 数時間の停止が許容でき、業務影響が限定的な分析環境なら、HA中心の設計で十分な場合がある
- 日次の売上集計、規制対応レポート、顧客向けデータ提供などが止まると重大な影響が出る場合は、DR設計が必要
- グローバル拠点で使うデータ基盤では、リージョン障害だけでなく、利用者・接続元・下流システムの切替も含めて検討する
まず決めるべきはRPOとRTO
DR設計で最初に決めるべきなのは、ツールではなく RPO と RTO です。
RPO（Recovery Point Objective）は「どの時点までのデータ損失を許容できるか」、RTO（Recovery Time Objective）は「どれくらいの時間で業務を再開する必要があるか」を示します。Azure Databricks の場合、ジョブやノートブックなどのワークスペースオブジェクトに加えて、ADLSなど外部にある顧客データのRPOも利用者側で定義する必要があります。 (Microsoft Learn)
たとえば、次のように業務単位で分けて考えます。
| 業務・ワークロード | RPOの例 | RTOの例 | DR優先度 |
|---|---|---|---|
| 顧客向けダッシュボード | 15分〜1時間 | 1〜2時間 | 高 |
| 日次売上集計 | 数時間〜1日 | 当日中 | 中〜高 |
| 社内探索分析 | 1日以上 | 数日 | 低〜中 |
| 開発・検証ワークスペース | 再構築可能 | 数日 | 低 |
| 監査・規制対応データ | 業務要件次第 | 業務要件次第 | 高 |
ここで失敗しやすいのは、すべてのワークロードに同じRPO/RTOを設定することです。すべてを最短で復旧しようとすると、セカンダリ環境のコスト、同期処理、監視、テスト負荷が一気に増えます。逆に、重要ワークロードまで低優先度として扱うと、障害時に経営判断や顧客対応が遅れます。
analytics leaders は、技術チームに「Databricksを復旧できるか」と聞くだけでは不十分です。次のように、業務影響に直結する問いに置き換える必要があります。
- どのレポートが何時間止まると事業影響が出るか
- どのデータパイプラインは手動再実行でよいか
- どのストリーミング処理は重複排除まで含めて復旧する必要があるか
- フェールオーバー判断は誰が、どの条件で行うか
- 下流のBI、API、外部連携先には誰が通知するか
DR戦略はアクティブ/パッシブが現実的な第一候補
Azure Databricks の Disaster recovery では、代表的な構成として アクティブ/パッシブ と アクティブ/アクティブ が整理されています。公式ドキュメントでは、アクティブ/パッシブが最も一般的で簡単なソリューションとして説明されており、アクティブ側からパッシブ側へデータやオブジェクト変更を同期し、障害時にセカンダリリージョンのパッシブ環境をアクティブ化します。 (Microsoft Learn)
多くの企業では、まずアクティブ/パッシブを検討するのが現実的です。理由は、通常時のコストと運用複雑性を抑えやすいからです。
| 戦略 | 向いているケース | 注意点 |
|---|---|---|
| アクティブ/パッシブ | 多くの分析基盤、日次・時間単位のパイプライン、通常時は片リージョン運用したい場合 | セカンダリ側の同期漏れ、起動手順、接続先切替のテストが必要 |
| アクティブ/アクティブ | 極めて高い継続性が必要なグローバル分析基盤、両リージョンで常時処理したい場合 | 両リージョンのジョブ完了判定、データ重複、コスト、CI/CD統制が難しい |
| 読み取り専用パッシブ活用 | セカンダリ側で参照クエリだけ実行したい場合 | ノートブックやジョブなどのオブジェクト変更を許可しない運用が必要 |
アクティブ/アクティブは魅力的に見えますが、両リージョンで常時ジョブを実行するため、費用が増えるだけでなく「どちらの結果を正とするか」「両方成功したときだけ完了とするか」「重複書き込みをどう防ぐか」といった設計が難しくなります。公式ドキュメントでも、アクティブ/アクティブは最も複雑な戦略で、追加コストが発生すると説明されています。 (Microsoft Learn)
同期対象はデータだけではない
Azure Databricks のDRで最も見落とされやすいのが、ワークスペースオブジェクトの同期です。データレイク上のファイルやDeltaテーブルだけを複製しても、ジョブ、権限、クラスター構成、シークレット、マウントポイント、メタストア定義が不足していれば、セカンダリリージョンで業務は再開できません。
公式ドキュメントでは、コントロールプレーン、コンピューティングプレーン、データソースにある正しいデータをレプリケートし、セカンダリワークスペースは別リージョンのコントロールプレーンにマップする必要があるとされています。また、同期ツールまたはCI/CDワークフローによるスクリプトベースの同期が推奨されています。 (Microsoft Learn)
実務で確認すべき同期対象は次の通りです。
| 同期対象 | 確認すべきこと | 失敗例 |
|---|---|---|
| ノートブック・ソースコード | GitやCI/CDで両リージョンへ展開できるか | 手作業で編集したノートブックがセカンダリに存在しない |
| ジョブ設定 | セカンダリでは不要な自動実行を防げるか | 障害前からセカンダリでもジョブが動き、二重書き込みが発生 |
| クラスター構成 | 同じRuntime、ライブラリ、ポリシーを再現できるか | ライブラリ不足でジョブが起動しない |
| プール設定 | セカンダリ側の待機インスタンス設定を制御できるか | 通常時から不要なコンピュート費用が発生 |
| ユーザー・グループ | IdP、SCIM、自動化で整合性を保てるか | 障害時に必要な担当者がログインできない |
| ACL・権限 | オブジェクトIDの対応関係を管理できるか | 権限だけ同期できず、ノートブックやジョブを実行できない |
| シークレット | リージョン差分を考慮して設定できるか | 接続文字列がプライマリのままで復旧後に失敗 |
| マウントポイント・接続先 | セカンダリのストレージエンドポイントを参照できるか | フェールオーバー後もプライマリADLSを読みに行く |
公式ドキュメントでは、プール構成ではセカンダリの min_idle_instances をDRイベントまでゼロにすること、ジョブ設定ではセカンダリ側のコンカレンシーを0にして余計な実行を防ぐこと、ACLではオブジェクトIDのマッピングが必要になることなど、かなり実務的な注意点が示されています。 (Microsoft Learn)
CI/CDと同期ツールは使い分ける
Azure Databricks のDRでは、すべてを単一の同期ツールでコピーしようとすると運用が複雑になります。公式ドキュメントでは、主な方法として「プライマリからセカンダリへコピーする同期クライアント」と「両リージョンへ同時に展開するCI/CDツール」が説明されています。 (Microsoft Learn)
実務では、次のように使い分けると管理しやすくなります。
| 対象 | 推奨アプローチ | 理由 |
|---|---|---|
| ノートブック、Python/Scalaライブラリ、SQLファイル | CI/CD | Gitで差分管理し、両リージョンに同時展開しやすい |
| ジョブ定義、クラスター定義、ポリシー | CI/CDまたはIaC | 環境差分をテンプレート化しやすい |
| ユーザー・グループ | IdP連携、SCIM、自動化 | 手動作成では差分が出やすい |
| ACL | APIによる同期 | オブジェクトIDの対応管理が必要 |
| シークレット | 自動化＋環境別値 | プライマリとセカンダリで値が異なる場合がある |
| データ | Azure側のレプリケーション、Delta Deep Cloneなど | データ形式・RPO・容量に応じて方式を選ぶ |
| ストリーミングチェックポイント | 顧客管理ストレージへの配置と複製 | 障害時の再開位置を制御するため |
独自の同期プロセスを作る場合は、Databricks Terraform Provider、Databricks Workspace Migration Tools、DBSync などが検討対象として挙げられています。特にTerraformのようなIaCを使うと、ワークスペース、権限、ジョブ、クラスター設定をコード化しやすく、セカンダリリージョンの再現性を高められます。 (Microsoft Learn)
ただし、IaC化しても「本番で手作業変更を許す」運用だとDRは崩れます。ノートブックの直接編集、ジョブ設定の手動変更、シークレットの個別更新などが積み重なると、障害時にセカンダリ側だけ設定が古いという状態になります。
DRを機能させるには、技術よりも先に運用ルールが必要です。
- 本番ワークスペースで直接編集しない
- 変更はGitからCI/CDで反映する
- 手動変更が必要な場合は、変更後に同期確認を行う
- セカンダリ側のジョブは通常時に勝手に動かないようにする
- 設定差分を定期的に検出する
geo冗長ストレージだけに頼らない
Azure Storage の冗長性は重要ですが、Azure Databricks のDRでは「geo冗長ストレージがあるから安心」と考えるのは危険です。公式ドキュメントでは、DRプロセスにおいて、Azure Databricks が各ワークスペース用に作成するADLSなどのリージョン間重複に geo冗長ストレージを使用しないことが推奨されています。DeltaテーブルではDeep Cloneを使い、可能であれば他形式のデータもDelta形式に変換してDeep Cloneを使う考え方が示されています。 (Microsoft Learn)
ここでのポイントは、ストレージの冗長性と、業務復旧に必要な整合性は同じではないということです。
たとえば、次のようなケースでは、単にファイルが複製されていても復旧できません。
- ジョブが参照するパスがプライマリリージョンのまま
- Deltaテーブルのメタデータがセカンダリ側で整合していない
- ストリーミングのチェックポイントが複製されていない
- 下流BIツールが旧ワークスペースURLを参照している
- ADFや外部スケジューラの linked service が切り替わっていない
DBAやデータ基盤担当者は、「データが複製されているか」ではなく、「セカンダリリージョンで同じジョブが同じ意味で再開できるか」を確認する必要があります。
ストリーミングワークロードはDR難易度が高い
バッチ処理は、比較的DRを設計しやすい領域です。入力ファイル、処理済みデータ、出力先をセカンダリリージョンに切り替えられれば、再実行や差分処理で復旧できる場合があります。
一方、ストリーミングワークロードは難易度が上がります。公式ドキュメントでは、Kafkaなどのメッセージキュー、CDCストリーム、ファイルベースの連続処理、trigger onceなどのストリーミング処理について、DRモードでセカンダリデプロイを使えるようデータソースを構成する必要があると説明されています。 (Microsoft Learn)
特に重要なのがチェックポイントです。ストリームライターは、処理済みデータに関する情報をチェックポイントに保存します。このチェックポイントにはデータの場所が含まれる場合があり、セカンダリリージョンで再起動するには、その場所を新しいストレージに合わせて調整する必要があります。 (Microsoft Learn)
実務では、ストリーミングDRについて次の項目を確認してください。
| 確認項目 | 具体的な確認内容 |
|---|---|
| チェックポイントの保存場所 | DBFS rootではなく、顧客管理ストレージで管理しているか |
| チェックポイントの複製 | RPOに合う間隔でセカンダリリージョンへ複製できるか |
| 再開位置 | 最後に処理済みのオフセットやファイル位置を特定できるか |
| 重複処理 | 再実行時に同じデータを二重処理しない仕組みがあるか |
| 出力先 | セカンダリ側のDeltaテーブル、ストレージ、キューに切り替わるか |
| 監視 | 遅延、失敗、重複、欠損を検知できるか |
ストリーミング処理では、「止まった時点から再開する」だけでなく、「どこから再開すればデータ欠損と重複を最小化できるか」を決める必要があります。Delta Lake を使う場合でも、重複排除キーや処理済み管理の設計が甘いと、フェールオーバー後に集計値がずれる可能性があります。
フェールオーバー時に実行すべき流れ
DR手順は、障害が起きてから考えるものではありません。公式ドキュメントでは、プライマリリージョンで障害が発生した場合、状況確認、セカンダリリージョンへのフェールオーバー判断、ワークスペース内アクティビティ停止、復旧手順の開始、テスト後の稼働宣言という流れが示されています。 (Microsoft Learn)
実務向けに整理すると、フェールオーバー手順は次のようになります。
| 手順 | 実施内容 | 判断者・担当者 |
|---|---|---|
| 障害確認 | Azure、Databricks、ネットワーク、ストレージ、外部データソースの状態を確認 | SRE、クラウド運用 |
| DR発動判断 | RTOを超える見込みか、業務影響が許容範囲を超えるか判断 | analytics leader、システム責任者 |
| プライマリ停止 | 可能な範囲でジョブ、クラスター、プール、ユーザー操作を停止 | Databricks管理者 |
| 同期状態確認 | 最新同期時刻、未反映データ、未反映オブジェクトを確認 | data engineer |
| セカンダリ起動 | クラスター、プール、ジョブ、接続先、スケジューラを有効化 | data platform team |
| データソース安定化 | ADLS、Delta Lake、外部DB、キューなどの参照先を確認 | DBA、data engineer |
| 検証 | 代表ジョブ、重要クエリ、BI接続、API接続を確認 | QA、業務担当 |
| 稼働宣言 | 利用者へ新URL、制限事項、再開範囲を通知 | 運用責任者 |
公式ドキュメントでは、フェールオーバー時にプライマリリージョンのプールやクラスターを無効化し、復旧後に意図せず新しいデータ処理が始まらないようにすることも示されています。また、外部ツールがAzure DatabricksワークスペースのURLやドメイン名を使っている場合は、新しいコントロールプレーンに合わせてREST APIやJDBC/ODBC接続のURL更新が必要です。 (Microsoft Learn)
この「URL切替」は意外と見落とされます。Power BI、Tableau、ADF、Airflow、社内API、JDBC接続、監視ツールなどがプライマリワークスペースを直接参照していると、Databricks側を復旧しても業務側では使えません。
フェールバックは軽視しない
DR計画では、セカンダリリージョンで動かすことに注目しがちですが、実際には フェールバック も同じくらい重要です。プライマリリージョンが復旧した後、どのデータと構成を戻すのか、どのタイミングで再びプライマリをアクティブにするのかを決めておかなければなりません。
公式ドキュメントでは、フェールバックはメンテナンスウィンドウで実施しやすいとされ、プライマリ復旧確認、セカンダリ側プール・クラスターの無効化、セカンダリで変更された資産やデータの同期、ワークロード停止、URL切替、テスト、再度のDR環境準備といった流れが示されています。 (Microsoft Learn)
フェールバックでよく起きる失敗は、次の3つです。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| セカンダリで作成されたデータを戻し忘れる | フェールオーバー中の更新範囲を記録していない | Deltaテーブル、ログ、監査証跡で変更範囲を把握する |
| プライマリとセカンダリでジョブが同時に動く | 切替手順に停止確認がない | クラスター、プール、ジョブコンカレンシーの確認を必須化する |
| 利用者が誤ったURLにアクセスする | 通知とDNS・接続設定の更新が不十分 | 接続先一覧と通知テンプレートを事前に作る |
フェールバックは「元に戻す」作業ではなく、セカンダリで発生した変更を正しく取り込み、再びプライマリを唯一のアクティブ環境にする作業です。ここを曖昧にすると、復旧後にデータの二重管理や整合性問題が残ります。
DBFS rootに本番データを置かない
DR設計の観点で特に避けたいのが、DBFS rootに本番データ、ライブラリ、設定ファイル、init scriptなどを置く運用です。公式ドキュメントでは、DBFS rootアクセスに使われるroot ADLS、または古いワークスペースでのAzure Blob Storageに本番顧客データを保存しないことがベストプラクティスとして示されています。DBFS root storage は本番顧客データ用途ではサポートされないと説明されています。 (Microsoft Learn)
実務では、次のように分離しましょう。
| 用途 | 推奨される管理方法 |
|---|---|
| 本番データ | ADLS上の明示的なコンテナ、Unity Catalog管理下のストレージ、Delta Lake |
| ライブラリ | パッケージリポジトリ、CI/CD、クラウドストレージ、アーティファクト管理 |
| init script | Git管理、明示的なクラウドストレージ、テンプレート化 |
| ジョブ設定 | Git、Terraform、Databricks Asset Bundlesなどの構成管理 |
| シークレット | Azure Key Vault連携やDatabricks Secretsの自動化管理 |
DBFS rootは便利ですが、属人的なファイル置き場になりやすく、DR時に「どのファイルが本番に必要なのか」が分からなくなります。特にグローバルチームでは、誰かが手元からアップロードしたJARや設定ファイルにジョブが依存していると、セカンダリリージョンで再現できません。
DRテストは「年1回の机上演習」では足りない
公式ドキュメントでは、DRソリューションを定期的にテストし、必要なときに使えないDRには価値がないと説明されています。企業によっては数か月ごとにリージョンを切り替え、想定やプロセスが復旧ニーズを満たすか確認するとされています。 (Microsoft Learn)
実務では、少なくとも次のレベルでテストを分けると効果的です。
| テスト種別 | 目的 | 実施頻度の目安 |
|---|---|---|
| 構成差分チェック | プライマリとセカンダリの設定差分を検出 | 週次〜月次 |
| ジョブ起動テスト | 代表ジョブがセカンダリで起動できるか確認 | 月次〜四半期 |
| データ整合性テスト | Deltaテーブル、外部データソース、集計結果の差分確認 | 月次〜四半期 |
| 接続テスト | BI、JDBC/ODBC、API、ADFなどの接続確認 | 四半期 |
| フルフェールオーバー演習 | 実際にセカンダリを稼働状態にする | 半期〜年次 |
| フェールバック演習 | プライマリへ戻す手順を検証 | フル演習とセット |
テストで見るべきなのは、「成功したか」だけではありません。次のような記録を残すと、次回の改善につながります。
- フェールオーバー判断までにかかった時間
- 最新同期時刻と実際のデータ損失見込み
- 起動できなかったジョブと原因
- 接続先の切替漏れ
- 権限不足で作業できなかった担当者
- 手順書と実作業の差分
- 利用者通知にかかった時間
- フェールバック後のデータ差分
DRは一度作って終わりではなく、データ基盤の変更に追随し続ける運用プロセスです。新しいジョブ、テーブル、コネクタ、BI接続、シークレット、外部APIが増えるたびに、DR対象に含めるか判断する必要があります。
data engineers、DBA、analytics leaders別の見直しポイント
Azure Databricks の Disaster recovery は、単一チームだけでは完結しません。役割ごとに確認すべき観点が異なります。
data engineersが確認すべきこと
data engineers は、パイプラインとワークスペースオブジェクトの再現性を中心に確認します。
| 確認項目 | 具体例 |
|---|---|
| ジョブ定義 | セカンダリ側でコンカレンシー0、DR時に有効化できるか |
| ノートブック・コード | Git管理され、両リージョンに展開できるか |
| ライブラリ | 手動アップロードに依存していないか |
| ストリーミング | チェックポイントと重複排除設計があるか |
| 監視 | セカンダリ側でもログ、アラート、メトリクスが取れるか |
| 接続先 | ストレージ、DB、キュー、BIのリージョン差分をパラメータ化しているか |
特に、ジョブ内にストレージパスやワークスペースURLを直書きしている場合は、早めに修正してください。DR時に最も壊れやすいのは、コードに埋め込まれた環境依存値です。
DBAが確認すべきこと
DBAは、外部データソース、CDC、データ整合性、復旧後のデータ品質を中心に見ます。
| 確認項目 | 具体例 |
|---|---|
| 外部DB | セカンダリリージョンから接続できるか |
| CDC | 障害時の再開位置を特定できるか |
| Deltaテーブル | タイムトラベル、監査ログ、差分確認が使えるか |
| データ重複 | 冪等な書き込み、重複排除キー、MERGE設計があるか |
| 権限 | セカンダリ側でも同等のアクセス制御があるか |
| フェールバック | セカンダリで更新されたデータを正しく戻せるか |
DRでは、復旧速度だけでなく「復旧後のデータが正しいか」が重要です。特に監査対象のデータでは、いつ、どのリージョンで、どのジョブが処理したかを説明できるログが必要です。
analytics leadersが確認すべきこと
analytics leaders は、技術詳細だけでなく、業務継続と意思決定の観点でDRを管理します。
| 確認項目 | 具体例 |
|---|---|
| 優先順位 | どのダッシュボード、データセット、パイプラインを先に復旧するか |
| RPO/RTO | 業務部門と合意済みか |
| コスト | セカンダリ環境の待機コスト、テストコストを予算化しているか |
| 体制 | 障害時の判断者、作業者、連絡先が明確か |
| 通知 | 利用者、経営層、外部連携先への通知テンプレートがあるか |
| 演習 | DR訓練の結果を改善サイクルに入れているか |
DRはIT部門だけの技術課題ではなく、事業継続の判断です。RTOを短くするほどコストと複雑性は増えるため、どの業務に投資するかを明確にする必要があります。
実務で使えるAzure Databricks DRチェックリスト
最後に、既存の Azure Databricks 環境を見直すためのチェックリストをまとめます。
| 分類 | チェック項目 | 状態 |
|---|---|---|
| 方針 | 重要ワークロードごとのRPO/RTOを定義している | 未確認なら最優先 |
| リージョン | プライマリとセカンダリのリージョンを決めている | 必須 |
| ワークスペース | セカンダリDatabricksワークスペースを用意している | 必須 |
| データ | ADLS、Delta Lake、外部DBのDR方針がある | 必須 |
| ジョブ | セカンダリ側で不用意に自動実行されない | 必須 |
| コード | ノートブックやライブラリをGit/CI/CDで管理している | 推奨 |
| 権限 | ユーザー、グループ、ACLを自動化している | 推奨 |
| シークレット | 環境別の値を安全に管理している | 必須 |
| ストリーミング | チェックポイントを顧客管理ストレージに置いている | 該当環境では必須 |
| 接続先 | REST API、JDBC/ODBC、BI、ADFの切替手順がある | 必須 |
| 監視 | セカンダリ環境でも監視・アラートが機能する | 推奨 |
| テスト | フェールオーバーとフェールバックを定期的に演習している | 必須 |
| 手順書 | 作業手順、判断基準、連絡先を最新化している | 必須 |
最初の一歩としては、すべてを完璧に自動化するより、「業務影響が大きい上位3つのパイプライン」を選び、RPO/RTO、同期対象、フェールオーバー手順、フェールバック手順を文書化してください。そのうえで、セカンダリリージョンで実際に代表ジョブを起動し、データと接続先を確認するのが現実的です。
Azure Databricks の Disaster recovery は、バックアップ製品を導入するだけでは完成しません。HAとDRを分けて考え、ワークスペース、データ、ジョブ、権限、ストリーミング、外部接続、利用者通知まで含めて設計することが重要です。2026年4月更新の公式ドキュメントをきっかけに、自社のDatabricks環境が「止まりにくい」だけでなく、「止まっても業務を再開できる」状態になっているかを確認しましょう。
コメント