メインコンテンツまでスキップ
に最終更新

フェーズ 10: 高可用性とディザスタリカバリの設計

このフェーズでは、事業継続性と回復力を確保するために、高可用性（HA）と災害復旧（DR）戦略を設計します。

高可用性 (HA) とディザスタリカバリ (DR) はレイクハウスの重要な側面であり、多くの組織が両方を実装して、 Databricksで重要なユースケースを実稼働化しています。

高可用性戦略を設計する​

高可用性とは、単一のクラウドゾーンに影響を与える障害が発生した場合でも、ユーザーへの影響を最小限に抑え、かつ透過的に復旧できる能力のことです。これは、安定した稼働時間または稼働率（SLA）として測定され、復旧時間は通常、秒または分単位で計測されます。

制御プレーンの高可用性​

Databricksコントロール プレーンは、フロントエンド ホスティングや認証からクラスター管理やエンドポイント展開に至るまで、数十のサービスで構成されています。 2025年初頭の時点で、コントロールプレーンの中核サービスはマルチゾーン化されており、クラウドリージョン内の単一ゾーンで障害が発生した場合でも、コントロールプレーンはこれらのサービスを別のゾーンに復旧させ、運用を継続できる。

制御プレーンHA特性

  • 自動フェイルオーバー ：サービスは正常なゾーンに自動的にフェイルオーバーします。
  • 15分RTO ：フェイルオーバーは通常15分以内に完了します。
  • 0 RPO ：ゾーン障害発生時にデータ損失なし。
  • マルチゾーン対応 ：複数のアベイラビリティゾーンを持つクラウドリージョンに対応します。
注記

これは、単一ゾーンのクラウドリージョンには適用されません。単一ゾーン地域では、ゾーン停電は地域停電と同等である。

コンピュートプレーンの高可用性​

クラシックコンピュートの高可用性

  • ワークスペースサブネットは、少なくとも2つの可用性ゾーン（推奨：3つ）に展開してください。
  • Databricks 、可用性ゾーン全体にクラスター ノードを自動的に分散します。
  • 一時的な障害発生時には、指数バックオフを使用してジョブの再試行を設定します。
  • 可用性ゾーンの状態を監視し、ゾーンの劣化時にワークロードを再分配します。

サーバレスコンピュートの高可用性

  • サーバレス コンピュートは、マルチゾーン フェイルオーバーを自動的に提供します。
  • 追加の設定は不要です。
  • ゾーン障害発生時にワークロードを自動的に再分配します。

コンピュート HA のベスト プラクティス

  • 自動マルチゾーン フェイルオーバーにはサーバレス コンピュートを使用します。
  • クラシック コンピュートの場合、サブネットが複数のアベイラビリティ ゾーンにまたがることを確認してください。
  • 一時的な障害発生時にジョブを自動的に再試行するよう設定します。
  • HA構成を検証するために、フェイルオーバー手順を定期的にテストしてください。
  • ゾーンの健全性メトリクスを監視し、それに応じて容量計画を調整します。

ディザスタリカバリ戦略を設計する​

ディザスタリカバリは、クラウド リージョン全体に影響を与える停止から回復し、セカンダリ リージョンで業務を継続する機能です。 これは、許容可能なダウンタイム（RTO）とデータ損失（RPO）によって測定され、通常は時間単位で表されます。

レイヤーごとのDRに関する考慮事項​

データプラットフォームのすべてのレイヤーにおいて、災害復旧（DR）に関する検討を行う必要があります。

クライアント

  • クライアントは、フェイルオーバーワークスペースのURLに変更できる必要があります。
  • 自動フェイルオーバーのために、DNSまたはロードバランサーの設定を更新してください。

コードとワークスペースオブジェクト

  • プラットフォームインフラストラクチャのデプロイには、IaC/Terraformを使用します。
  • ノートブックなどのすべてのコードにはバージョン管理システムを使用してください。
  • CI/CDを使用して両方のサイトにデプロイします。
  • セカンダリリージョンへのデプロイを自動化する。

アイデンティティ

  • ユーザー、サービスプリンシパル、グループ。
  • アカウントレベルでSCIM同期を使用する。
  • ID連携により、地域をまたいだ一貫したアクセスが保証されます。

Unity Catalog

  • Terraformまたはスクリプトを使用して、Unity Catalogインフラストラクチャをデプロイまたはコピーします。
  • Terraformまたはスクリプトを使用してメタデータ（テーブル定義、ACLなど）をコピーします。
  • Terraformまたはスクリプトを使用して、 Delta Sharing設定をコピーします。
  • メタストアをプライマリリージョンとセカンダリリージョンの両方にデプロイします。

データ

  • 外部データおよび管理対象データ ：地理的に冗長なレプリケーション（例：生データ、データソース）。
  • Deltaテーブル : リージョン間でテーブルをレプリケートするためのDeltaディープク ローン。
  • 着陸ゾーン ：着陸ゾーンのデータをセカンダリーリージョンに複製します。

ストリーミングエンドポイント

  • チェックポイント情報は、地域間で同期される必要がある。
  • 二重書き込みまたはチェックポイントレプリケーションを設定します。

DR設計パターン​

能動的・受動的DR

  • プライマリ リージョンはすべての本番運用トラフィックを処理します。
  • セカンダリーリージョンはフェイルオーバーのために待機中です。
  • データは定期的に（例えば、1時間ごと、1日ごと）複製される。
  • プライマリリージョン障害発生時の手動または自動フェイルオーバー。

アクティブ-アクティブDR

  • どちらのリージョンも本番運用トラフィックを処理します。
  • データは継続的に、またはほぼリアルタイムで複製される。
  • 地域間で負荷分散を行う。
  • コストは高いが、性能とRTO（復旧時間）は優れている。

バックアップと復元

  • セカンダリリージョンへの定期的なバックアップ。
  • プライマリ領域障害発生時の手動復旧プロセス。
  • コストは最低だが、RTOとRPOは最高。
  • 重要度の低いワークロードに適しています。

RTOおよびRPOの要件を定義する​

復旧時間目標（RTO）

  • 事業はどのくらいの期間、操業停止に耐えられるのか？
  • フェイルオーバー自動化の要件を決定します。
  • インフラ投資に影響を与える。

復旧目標時点（RPO）

  • どの程度のデータ損失が許容範囲か？
  • 複製頻度を決定します。
  • バックアップおよびレプリケーション戦略に影響を与える。

RTO/RPO要件の例

  • 重要なワークロード ：RTO < 1時間、RPO < 15分（アクティブ-アクティブ構成またはアクティブ-パッシブ構成、継続的なレプリケーション）。
  • 重要なワークロード ：RTO < 4時間、RPO < 1時間（1時間ごとのレプリケーションによるアクティブ/パッシブ構成）。
  • 標準ワークロード ：RTO < 24時間、RPO < 24時間（バックアップとリストア）。

DRテスト戦略の設計​

災害復旧手順は、必要な時に確実に機能するように、定期的にテストする必要がある。貴社のRTO/RPO要件に適した災害復旧テスト戦略を設計してください。

DRテストパターン

  • 四半期ごとの災害復旧テスト ：セカンダリリージョンへの完全なフェイルオーバー、すべてのシステムの検証。
  • 月次ランブック検証 ：災害復旧手順を確認し、更新する。
  • 継続的な自動テスト ：個々のコンポーネントを定期的にテストします。
  • 机上演習 ：関係者とともに災害復旧シナリオをシミュレーションする。

DRテストのベストプラクティス

  • 詳細な災害復旧手順書を作成し、手順を段階的に説明してください。
  • ピーク時以外の時間帯にDR（災害復旧）手順をテストしてください。
  • フェイルオーバー後にデータの完全性を検証します。
  • テスト中に実際のRTOとRPOを測定します。
  • 試験結果に基づいて手順を更新する。
  • DR 手順について運用チームをトレーニングする。

HAおよびDRの推奨事項​

推奨

  • IaC（Terraform）を使用して、プライマリリージョンとセカンダリリージョンの両方にインフラストラクチャをデプロイします。
  • HA のために複数のアベイラビリティ ゾーンにわたってクラシック コンピュートを展開します。
  • 自動マルチゾーン フェイルオーバーにはサーバレス コンピュートを使用します。
  • 生データおよびデータソースに対して、地理的に冗長なレプリケーションを実装する。
  • Deltaディープクローンを使用して、リージョン間で重要なテーブルをレプリケートします。
  • 地域をまたいで一貫したID管理を行うには、SCIM同期を使用してください。
  • すべての重要なワークロードについて、RTO（目標復旧時間）とRPO（目標復旧時点）の要件を文書化する。
  • 可能な限り、災害復旧（DR）のフェイルオーバー手順を自動化する。
  • 災害復旧手順を定期的に（少なくとも四半期に一度）テストする。
  • 詳細な災害復旧手順書を作成する。

要件に基づいて評価する

  • 厳格なRTO要件を持つミッションクリティカルなワークロードに対して、アクティブ/アクティブ型の災害復旧（DR）を評価する。
  • 災害復旧への投資を、事業の重要度およびRTO/RPO要件とバランスよく配分する。
  • 最高の復元力を実現するには、マルチクラウド DR を検討してください (ただし、複雑さとコストは最高になります)。

第10相の結果​

フェーズ10を完了すると、以下のものが得られます。

  • 高可用性戦略の設計 (クラシック コンピュート向けのマルチゾーン展開)。
  • 操縦翼面のHA特性が理解された（15分以内のRTO、0 RPO）。
  • ディザスタリカバリ戦略の設計 (アクティブ/パッシブ、アクティブ/アクティブ、またはバックアップ/復元)。
  • 重要なワークロードに対して、RTO（目標復旧時間）とRPO（目標復旧時点）の要件が定義されています。
  • 要件に基づいて選択されたDR設計パターン。
  • 定期的なテストスケジュールに基づいて定義されたDRテスト戦略。
  • プライマリリージョンとセカンダリリージョンへの展開のために定義されたIaCアプローチ。
  • 設計されたデータ複製戦略 (地理的冗長ストレージ、 Deltaディープクローンなど)。
  • アイデンティティ管理戦略を設計しました（SCIM同期）。
  • 災害復旧手順書には、詳細な手順が記載されている。

Databricks導入ガイドのすべての段階を完了しました。