Disaster recovery — Databricks Documentation [2022/8/1時点]の翻訳です。
Databricksのようなクラウドネイティブのデータ分析プラットフォームにおいては、明確なディザスターリカバリーパターンは重要となります。ハリケーン、地震などによって地域レベルの災害が起きた結果、地域レベルでのクラウドサービスの停止が仮に起きたとしても、いくつかの企業においては、データチームがDatabricksを使い続けられるようにすることは重要となります。
Databricksが、上流のデータ投入サービス(バッチ、ストリーミング)、AWS S3のようなクラウドネイティブストレージ、下流のインテリジェンスアプリケーションなのどのツール、サービス、そしてオーケストレーションツールを含む多数のサービスのエコシステムのコアとなることはよくあることです。いくつかのユースケースにおいては、地域レベルの障害に対して特に敏感になるかもしれません。
本書では、Databricks統合分析プラットフォームにおけるディザスターリカバリーの概念とベストプラクティスを説明します。組織によって状況は異なりますので、ご自身のソリューションをデプロイする際に疑問があれば、Databricks担当者にお問い合わせください。
重要！
本書では、Databricksプラットフォームの計算レイヤーであるデータプレーンという用語が出てきます。本書の文脈ではお使いのAWSアカウントのクラシックデータプレーンを指します。Serverless SQL warehouses (Public Preview)をサポートするサーバレスデータプレーンはDatabricksのAWSアカウントで稼働します。詳細は、Databricksのサーバーレスコンピュートをご覧ください。
ディザスターリカバリー概論
ディザスターリカバリーには、自然災害あるいは人為的な災害に対して、重要なインフラストラクチャ、システムの継続及び復旧を可能とする一連のポリシー、ツール、手順が含まれます。多数の顧客にサービスを提供しているAWSのような大規模なクラウドサービスは、単一の障害に対するビルトインの防御策を講じています。例えば、単一の電源の障害が地域全体に波及しないように、地域にあるそれぞれの建物は異なる電源に接続されています。しかし、クラウドの地域レベルの障害は起こり得るものですし、障害の規模及び組織への影響度合いは組織によって異なります。
ディザスターリカバリープランを実装する前に、ディザスターリカバリー(DR)と高可用性(HA)を理解することが重要です。
高可用性はシステムの回復特性です。高可用性は、一貫性のある稼働時間あるいは稼働時間の割合によって定義される稼働パフォーマンスの最低限のレベルを定めるものです。高可用性は主系システムの機能として設計され(主系システムと同じ地域に)実装されるものです。例えば、AWSのようなクラウドサービスは、AWS S3のような高可用性サービスを持っています。高可用性はDatabricksのユーザーに対して特別な準備を求めません。
一方、ディザスターリカバリープランは、重要なシステムの地域レベルの障害に対応するために、それぞれの組織に対してソリューション及び意思決定を求めるものです。本書では、一般的なディザスターリカバリーに関する用語、一般的なソリューション、Databricksにおけるディザスターリカバリープランのベストプラクティスを説明します。
用語
地域に関する用語
本書では地域に関する以下の用語を用います：
- プライマリリージョン: 典型的な日々のインタラクティブ、自動化データ分析作業を行うリージョン
- セカンダリリージョン: プライマリリージョンでの障害の期間一時的にデータ分析作業を行うリージョン
- 地理冗長化ストレージ: AWSには非同期ストレージ複製プロセスを用いてバケットを永続化するgeo-redundant storage across regionsがあります。
重要！
ディザスターリカバリープロセスにおいては、ルートS3バケットのようなデータのリージョン間複製に地理冗長化ストレージを用いないことをお勧めします。通常は、Deltaテーブルにはディープクローンを用い、他のデータフォーマットに関しては可能であればDeltaフォーマットに変換してください。
デプロイメント(配備)ステータスに関する用語
本書ではデプロイメントステータスに関する以下の用語を用います：
-
アクティブデプロイメント: ユーザーはDatabricksワークスペースのアクティブデプロイメントに接続し、作業を行うことができます。Databricksのスケジューラや他の機構を用いてジョブが定期的に実行されます。このデプロイメントでは、データのストリーミングも実行できます。いくつかの文書ではホットデプロイメントとも呼ばれます。
-
パッシブデプロイメント: パッシブデプロイメントではプロセスは実行されません。ITチームは、コード、設定などのDatabricksのオブジェクトを、パッシブデプロイメントに自動的にデプロイするように設定することができます。アクティブデプロイメントがダウンした時にのみ、パッシブデプロイメントはアクティブになります。いくつかの文書ではコールドデプロイメントとも呼ばれます。
重要!
プロジェクトによっては、リージョンでの障害に対してさらなる選択肢を加えるために、異なるリージョンに複数のパッシブデプロイメントを持つこともあります。
一般的には単一のアクティブデプロイメントを持ち、これはディザスターリカバリー戦略においてアクティブ・パッシブデプロイメントと呼ばれます。同時に二つのアクティブデプロイメントが存在するアクティブ・アクティブデプロイメントもありますが、あまり一般的ではありません。
ディザスターリカバリー分野における用語
ディザスターリカバリーにおいては、理解すべき二つの用語があります。
- リカバリーポイント目標: 目標リカバリーポイント(RPO)は、ITサービスが重大な障害によってデータ(トランザクション)が喪失する最長の目標期間となります。あなたのDatabricksデプロイメントは主要な顧客情報を格納しません。顧客情報は、AWS S3のようにあなたの制御下にある別のシステムに格納されます。Databricksのコントロールプレーンはジョブやノートブックなどのオブジェクトを格納します。DatabricksにおけるRPOは、最大でどのくらいの期間のジョブ、ノートブックの変更が失われるのかということになります。加えて、AWS S3などあなたの制御下にあるデータソースにある顧客データのRPOを定義するのはあなたの責任となります。
-
リカバリータイム目標： 目標リカバリータイム(RTO)は、災害からビジネスプロセスが復旧するまでの時間とサービスレベルの目標値となります。
ディザスターリカバリーとデータ破損
ディザスターリカバリーソリューションはデータ破損を軽減しません。プライマリーリージョンで破損したデータはセカンダリーリージョンに複製され、両方のリージョンのデータが破損します。例えば、Deltaのタイムトラベルのように、この種の障害を軽減する手段が存在しています。
典型的なリカバリーワークフロー
Databricksのディザスターリカバリーシナリオは以下のようになります：
- プライマリーリージョンで重要なサービスに障害が発生します。これは、データソースのサービスかもしれませんし、Databricksデプロイメントに影響を与えるネットワークかもしれません。
- あなたはクラウドプロバイダーとともに調査を行います。
- プライマリーリージョンでの復旧を待てないとあなたの組織が判断した場合には、セカンダリリージョンへのフェイルオーバーを決断します。
- セカンダリーリージョンで同様の問題が起きていないことを検証します。
- セカンダリーリージョンにフェイルオーバーします。
- ワークスペースでの活動を全て停止します。ユーザーも作業を止めます。可能であれば管理者は最近の変更のバックアップを取ります。障害によりジョブが止まっていない場合にはそれらを停止します。
- セカンダリーリージョンでのリカバリー手順を開始します。リカバリー手順においては、セカンダリーリージョンへのネットワークトラフィック、接続名、ルーティングをアップデートします。
- テストの後、セカンダリーリージョンの稼働を宣言します。プロダクションのワークロードを再開します。ユーザーはアクティブデプロイメントにログインできます。予定されていた、あるいは遅延したジョブを再実行します。
- Databricksにおける詳細な手順に関しては、フェイルオーバーのテストを参照ください。
- ある時点で、プライマリーリージョンの問題が解決されたことを確認します。
- プライマリーリージョンに復帰(フェイルバック)します。
- セカンダリーリージョンでの全ての作業を止めます。
- プライマリリージョンでのリカバリー手順をスタートします。リカバリー手順においては、プライマリーリージョンへのネットワークトラフィック、接続名、ルーティングをアップデートします。
- 必要であればプライマリーリージョンにデータをコピーします。複雑にしないためには、コピーするデータを最小限にしたほうがいいかもしれません。例えば、あるジョブがセカンダリーリージョンで読み取りしか行わなかったのであれば、それらをプライマリーリージョンにコピーする必要はないかもしれません。しかし、プライマリーリージョンにデータをコピーして実行するプロダクションのジョブもあるかもしれません。
- プライマリーリージョンでテストを行います。
- プライマリーリージョンがアクティブデプロイメントであり稼働状態になったことを宣言します。プロダクションワークロードを再開します。
- 詳細な手順に関しては、復旧(フェイルバック)のテストを参照ください。
重要！
これらのステップにおいてはいくつかのデータ損失が起こりえます。あなたの組織では、どの程度のデータ損失を許容できるのか、データ損失をどのように防ぐのかを定義する必要があります。
ステップ1: ビジネス要件を理解する
最初に行うことはビジネス要件を理解し定義することです。どのデータサービスが重要で、期待すべきRPOとRTOが何であるかを定義します。
個々のシステムに対してどの程度許容できるのかを実例を調査します。フェイルオーバー、フェイルバックにはコストを要し、他のリスクも含むことを理解する必要があります。他のリスクとしては、データ破損、誤ったストレージロケーションに書き込むことによるデータ重複、誤ったワークスペースにログインしてしまい変更を加えてしまう、などが挙げられます。
ビジネスに影響を及ぼすDatabricksのコンポーネントを全てマッピングします：
- あなたのディザスターリカバリーソリューションは、インタラクティブなプロセス、あるいは自動化プロセスと調整を行う必要がありますか？
- どのサービスを使用していますか？いくつかはオンプレミスかもしれません。
- 入力データはどのようにクラウドに投入されますか？
- 誰がデータを使用しますか？下流のどのプロセスがデータを使用しますか？
- ディザスターリカバリーの変更に留意すべきサードパーティサービスは存在しますか？
ディザスターリカバリープランをサポートするコミュニケーション、ツールに対する戦略を決定します：
- 迅速にネットワーク設定を変更するためにどのようなツールを使いますか？
- ディザスターリカバリーソリューションが自然かつ維持可能な形で、設定を事前定義し、モジュール化することができますか？
- ディザスターリカバリーにおけるフェイルオーバー、フェイルバックの変更を、どのようなコミュニケーションツール、チャネルを用いて内部チーム、サードパーティに通知しますか？
- どのようなツール、特別なサポートが必要になりますか？
- 完全に復旧するまでにシャットダウンするサービスは存在しますか？
ステップ2: ビジネス要件に合致するプロセスを選択する
あなたのソリューションは両方のコントロールプレーン、データプレーン、データソースにあるデータを正しく複製しなくてはなりません。異なるリージョンにある異なるコントロールプレーンに対して、ディザスターリカバリーのために冗長化されたワークスペースをマッピングする必要があります。同期ツールあるいはCI/CDワークフローによる、スクリプトベースのソリューションを用いて定期的にデータを同期する必要があります。
カスタマーマネージドVPCを使用しているのであれば、Terraformのようなテンプレートベースのツールを用いて、両方のリージョンのネットワークに一貫性を持ってデプロイを行うことができます。
加えて、あなたはデータソースが両方のリージョンで複製されていることを確認する必要があります。
一般的なベストプラクティス
ディザスターリカバリープランにおける一般的なディザスターリカバリープランには以下が含まれます：
-
どのプロセスがビジネスにおいて重要で、ディザスターリカバリーにおいても実行すべきであるのかを理解します。
-
どのサービスが必要で、どのデータが処理され、どのデータフローが必要で、どこに格納されるのかを明確にします。
-
可能な限りサービスとデータを分離します。例えば、ディザスターリカバリー専用のクラウドストレージを作成し、災害時にDatabricksオブジェクトを移動します。
-
Databricksコントロールプレーンに格納されない他のオブジェクトについては、あなたがプライマリー、セカンダリーで整合性が保たれていることに対して責任を持つ必要があります。
警告!
ワークスペースのDBFSルートとして使われているAWS S3にデータを格納しないことがベストプラクティスとなります。DBFSルートのストレージはプロダクションの顧客データをサポートしていません。しかし、ライブラリ、設定ファイル、initスクリプトなどのデータを格納しても構いません。これらのオブジェクトを複製するプロセスを自動化するか、セカンダリーデプロイメントに手動で複製する手順を確立します。 -
データソースに対しては、可能であれば、ディザスターリカバリーリージョンにデータを複製するネイティブのAWSツールを使うことをお勧めします。
リカバリーソリューション戦略を選択します
典型的なディザスターリカバリーソリューションは二つ(あるいはそれ以上)のワークスペースを内包します。選べる戦略はいくつかあります。潜在的な障害の期間(数時間あるいは１日)、ワークスペースが完全に復旧するのに必要な作業、プライマリーリージョンに復旧(フェイルバック)する作業を検討します。
アクティブ・パッシブソリューション戦略
アクティブ・パッシブソリューションは最も一般的で容易なソリューションであり、本書がフォーカスしているものです。アクティブ・パッシブソリューションは、アクティブデプロイメントからパッシブデプロイメントにデータとオブジェクトの変更を同期します。必要であれば、異なるリージョンで複数のパッシブデプロイメントを持つことも可能です。ディザスターリカバリーの際には、セカンダリーリージョンでのパッシブデプロイメントがアクティブデプロイメントとなります。
この戦略には二つの派生形があります：
- 統合(企業規模)ソリューション: 組織全体をサポートするアクティブ・パッシブのセットを一つ持ちます。
- プロジェクト、部署ごとのソリューション: それぞれの部署、プロジェクトが分離したディザスターリカバリーのソリューションを持ちます。いくつかの組織においては、部門ごとに異なるディザスターリカバリーの詳細手順を持ち、それぞれのチームの要求に応じたプライマリー、セカンダリーリージョンを持ちたいケースがあります。
パッシブデプロイメントを読み取り専用にするような他の派生形もあります。クエリなどワークロードが読み取りのみである場合、それらがノートブックやジョブなどのDatabricksオブジェクトを更新しないのであればパッシブソリューションを常に稼働させることができます。
アクティブ・アクティブソリューション戦略
アクティブ・アクティブソリューションにおいては、常に全てのデータプロセスを両方のリージョンで並行で動作させます。あなたの組織のオペレーションチームは、両方のリージョンで処理が成功した場合にのみ、ジョブのようなプロセスが完了とマークされることを保証する必要があります。プロダクションにあるオブジェクトは更新されず、必ずデベロップメント・ステージングからプロダクションへの厳密なCI/CDプロモーションに従う必要があります。
両方のリージョンでジョブが実行されるため、アクティブ・アクティブソリューションは最も複雑な戦略であり、追加のコストも発生します。
アクティブ・パッシブ戦略と同様に、企業全体のソリューションあるいは部署単位のソリューションとして実装できます。
ワークフローによっては、全てのワークスペースがセカンダリーのシステムに複製される必要がないかもしれません。例えば、デベロップメント、ステージングのワークスペースは複製の必要がないかもしれません。適切に設計された開発パイプラインがあれば、必要に応じてこれらのワークスペースを容易に再構築できる場合があります。
ツールの選択
プライマリー、セカンダリーリージョンでワークスペースの同期をとるためのツールに関しては、大きく二つのアプローチがあります：
- プライマリーからセカンダリーにコピーを行う同期クライアント: 同期クライアントはプロダクションのデータと資産をプライマリーリージョンからセカンダリーリージョンにコピーを行います。
- 並列デプロイメントのためのCI/CDツール: プロダクションのコード、資産に対して、両方のリージョンに同時にプロダクションの変更を反映するCI/CDツールを使用します。例えば、ステージング、デベロップメントからプロダクションにコードや資産がプッシュされる際、CI/CDシステムは同時に両方のリージョンに変更を反映します。根本となる考え方は、Databricksワークスペースにおける全ての成果物をインフラストラクチャ・アズ・コードとして取り扱うというものです。いくつかの成果物はディザスターリカバリー後にのみデプロイされる必要がありますが、ほとんどの成果物はプライマリー、セカンダリー両方に同時にデプロイされます。ツールに関しては、自動化ツール、サンプル、プロトタイプを参照ください。
以下の図は二つのアプローチを比較したものとなっています。
必要に応じて、これらのアプローチを組み合わせることができます。例えば、ノートブックに対してCI/CDを使用し、プールやアクセス制御の設定に関しては同期を行うなどです。
以下の表では、それぞれのツールで、どのようなタイプのデータが取り扱えるかをまとめています。
| 説明 | CI/CDツールでの取り扱い | 同期ツールでの取り扱い |
|---|---|---|
| ソースコード：ノートブックのソース、ライブラリパッケージのソースコード | プライマリー、セカンダリー両方にデプロイ | プライマリーからセカンダリーにソースコードを同期 |
| ユーザー、グループ | Gitでメタデータを管理。あるいは、両方のワークスペースに同じIDプロバイダ(IdP)を使用する。プライマリー、セカンダリー両方にユーザー、グループデータをデプロイ | 両方のリージョンでSCIMあるいは他の自動化ツールを使用する |
| プール設定 | Gitにテンプレートを保存する。プライマリー、セカンダリー両方にデプロイする。しかし、セカンダリーのmin_idle_instancesは、ディザスターリカバリーが発生するまで0にしておくこと |
APIあるいはCLIを使ってセカンダリーに同期された際には任意のmin_idle_instancesでのプールが作成される |
| ジョブ設定 | Gitにテンプレートを保存する。プライマリーでのデプロイでは、そのままの状態とする。セカンダリーでのデプロイでは、同時実行数をゼロにする。これによりジョブは実行されなくなる。セカンダリーデプロイメントがアクティブになった際には同時実行数を変更する | ジョブが<インタラクティブ>クラスターで実行されている場合には、同期クライアントは対応するcluster_idにマッピングを行う必要がある |
| アクセス制御リスト(ACL) | Gitにテンプレートを保存する。ノートブック、フォルダー、クラスターに対するACLをプライマリー、セカンダリーに設定する。ジョブに関するものに関しては、ディザスターリカバリーが発生するまで待つこと。 | Permissions APIにより、クラスター、ジョブ、プール、ノートブック、フォルダーのアクセス権を設定できる。同期クライアントはオブジェクトのIDをセカンダリーワークスペースにマッピングする必要がある。アクセス権を複製する前に、プライマリーからセカンダリーへのオブジェクトIDのマッピングを作成することを推奨する |
| ライブラリ | ソースコード、クラスター、ジョブテンプレートに含める | 集中管理されたリポジトリ、DBFSあるはマウント可能なクラウドストレージからカスタムライブラリを同期する |
| クラスターinitスクリプト | 必要ならソースコードに含める | 単純な同期に関しては、initスクリプトをプライマリーのワークスペースの単一あるいは数個のフォルダーに格納する |
| マウントポイント | ノートブックベースのジョブあるいはCommand APIで作成された場合にはソースコードに含める | ジョブを使う。ワークスペースのリージョンが異なる場合には、ストレージのエンドポイントが変化する場合があることに注意する。これはあなたのデータのディザスターリカバリー戦略に依存する |
| テーブルメタデータ | ノートブックベースのジョブあるいはCommand APIで作成された場合にはソースコードに含める。これは内部Databricksメタストア、外部メタストア両方に適用される | Spark Catalog APIあるいはノートブック、スクリプトでShow Create Tableを使ってメタデータ定義を比較する。利用しているストレージによってはテーブルがリージョン依存となりメタストアインスタンス間でテーブルが異なるケースがあることに注意する |
| シークレット | ノートブックベースのジョブあるいはCommand APIで作成された場合にはソースコードに含める。いくつかのシークレットはプライマリーとセカンダリーで異なる場合があることに注意する | APIを通じて両方のワークスペースにシークレットが作成される。いくつかのシークレットはプライマリーとセカンダリーで異なる場合があることに注意する |
| クラスター設定 | Gitでテンプレートにする。プライマリー、セカンダリー両方にデプロイする。セカンダリーのクラスターはディザスターリカバリーが発生するまで停止しておくこと | API、CLIを用いてセカンダリーワークスペースに同期された後にクラスターが生成される。自動停止設定によっては、必要であれば明示的にクラスターは停止される |
| ノートブック、ジョブ、フォルダのアクセス権 | Gitでテンプレートにする。プライマリー、セカンダリー両方にデプロイする。 | Permissions API 2.0を用いて複製する |
セカンダリーワークスペースのリージョンの選択
あなたには、ディザスターリカバリーを実行するためのフルコントロールが必要です。あなたはあらゆる理由、あらゆるタイミングで実行をスタートできます。フェイルバックモード（通常状態）での再起動を行う前に、ディザスターリカバリーの安定性に対してあなたは責任を持つ必要があります。すなわち、ディザスターリカバリー、プロダクションの要件に応じて、あなたは複数のDatabricksワークスペースを作成し、セカンダリーのフェイルオーバーリージョンを選択する必要があります。
AWSにおいては、あなたはセカンダリーリージョンにおいてフルコントロールを有します。EC2のようなリソース、製品が利用可能であることを確認してください。いくつかのDatabricksは、特定のリージョンでのみ利用可能です。あなたのDatabricksアカウントがE2バージョンであれば、E2バージョンのプラットフォームをサポートしているAWSリージョンを選択する必要があります。
ステップ3: ワークスペースを準備しワンタイムコピーを行う
ワークスペースがプロダクション環境である場合には、アクティブデプロイメントとパッシブデプロイメントで同期を行う際にはワンタイムコピーを行うのが一般的です。ワンタイムコピーは以下のことを行います。
- データの複製: クラウドの複製ソリューションあるいはDeltaのディープクローンオペレーションを用いて複製を行います。
- トークンの生成: 複製と以降のワークロードを自動化するためにトークン生成を活用します。
- ワークスペースの複製: ステップ4: データソースを準備するで説明されている方法を用いてワークスペースの複製を行います。
- ワークスペースの検証: ワークスペースとプロセスが成功し、期待された結果となっていることを確認するためにテストを行います。
最初のワンタイムコピーの実行後は、以降のコピー、同期操作は高速となり、ツールのログは、どのような変更がいつ発生したのかのログにもなります。
ステップ4: データソースを準備する
Databricksはバッチ処理、ストリーミング処理を通じて流入する様々な種類のデータを取り扱うことができます。
データソースに対するバッチ処理
バッチでデータが処理される際、他のリージョンに容易に複製できるデータソースを用いるのが一般的です。
例えば、データはクラウドストレージに定期的にアップロードされます。セカンダリーリージョンにディザスターリカバリーする際には、セカンダリーリージョンのストレージにファイルがアップロードされていることを確認する必要があります。ワークロードはセカンダリーリージョンのストレージを読み取り、セカンダリーリージョンのストレージに書き込みを行う必要があります。
データストリーム
データストリームを処理することはさらなるチャレンジとなります。ストリーミングデータは様々なソースから投入され、処理後にストリーミングソリューションに送信されます：
- Kafkaのようなメッセージキュー
- データベース変更データキャプチャストリーム
- ファイルベースの継続的処理
- ファイルベースのスケジュール処理
これら全てのケースで、ディザスターリカバリーモードで、セカンダリーリージョンでのデプロイメントを利用するために、データソースを設定する必要があります。
ストリームライターは、処理された地点を管理するチェックポイントを格納します。このチェックポイントは、ストリームが再開した際に正しくデータを更新するために、データの場所(一般的にはクラウドストレージ)を保持します。例えば、チェックポイント配下のsourceサブフォルダーはファイルベースのクラウドフォルダーを格納します。
このチェックポイントは遅延なく複製される必要があります。いかなる新たなクラウド複製ソリューションに対して、チェックポイントの同期周期を検討して下しあ。
チェックポイントの更新はライターの機能であり、データストリームの投入、処理、別のストリーミングソースへの格納にも適用できます。
ストリーミングのワークローにおいては、障害復旧時から適切にワークロードを再開できるように、チェックポイントがセカンダリーリージョンのお客様管理のストレージに複製されることを確認する必要があります。また、並行してプライマリープロセスに対するセカンダリーのストリーミングプロセスを実行することを選択することもできます。
ステップ5: ソリューションを実装しテストする
ディザスターリカバリーが適切に設定されているのかを定期的にテストします。必要となった時に利用できないのであれば、ディザスターリカバリーソリューションを維持することに価値はありません。いくつかの企業では、数ヶ月おきにリージョンを切り替えています。定期的にリージョンを切り替えることは、仮説とプロセスを検証でき、復旧要件を満たしているかどうかをテストできます。また、これにより自身の組織で緊急事態のポリシーと手順を訓練することができます。
重要!
実世界の環境で定期的にディザスターリカバリーソリューションをテストしてください。
オブジェクトあるいはテンプレートが足りず、依然としてプライマリーワークスペースに蓄積されている情報に依存しなくてはならないことが明らかになったら、これらの障害を取り除き、セカンダリーシステムに情報が複製されるようにするか、別の方法で利用できるようにしてください。
設定、プロセスに対する組織変更をテストしてください。あなたのディザスターリカバリープランはデプロイメントパイプラインに影響を及ぼしますので、あなたのチームは何が同期されるべきかを知ることが重要です。ディザスターリカバリーワークスペースをセットアップした後で、あなたのインフラストラクチャ(手順書、コード)、ジョブ、ノートブック、ライブラリ、その他のワークスペースのオブジェクトがセカンダリーリージョンで利用できることを検証してください。
変更を全てのワークスペースに反映するために、あなたのチームと、どのように標準作業プロセス、設定パイプラインを拡張するのかを議論してください。全てのワークスペースでユーザIDを管理してください。ジョブの自動化、新規のワークスペースをモニタリングするツールを設定することを忘れないでください。
設定ツールに対する変更をテストする計画を立ててください：
- 取り込み: データソースがどこにあるか、データソースはどこからデータを持ってくるのかを理解します。可能であれば、セカンダリーリージョンにおけるセカンダリーデプロイメントで作業するための設定テンプレートを持てるようにソースの部分をパラメータ化してください。フェイルオーバーのプランを立て、仮説を検証してください。
- 処理の変更: ジョブやアクションを実行するスケジューラーをもっているのであれば、セカンダリーデプロイメントで動作するようにスケジューラを設定する必要があります。フェイルオーバーのプランを立て、仮説を検証してください。
- インタラクティブな接続性: JDBC/ODBCのような他のサービス、CLIツール、REST APIの利用において、リージョン障害によってどのような設定、認証、ネットワーク接続が影響を受けるのかを検討します。フェイルオーバーのプランを立て、仮説を検証してください。
- オートメーションの変更: 全てのオートメーションツールに対して、フェイルオーバーのプランを立て、仮説を検証してください。
- 出力: 出力データ、ログを生成する全てのツールに対して、フェイルオーバーのプランを立て、仮説を検証してください。
フェイルオーバーのテスト
ディザスターリカバリーは、様々なシナリオで発生します。予期されない障害によって引き起こされます。クラウドネットワーク、クラウドストレージなどいくつかの主要機能がダウンするかもしれません。安全にシステムをシャットダウンできずに、リカバリをトライしなくてはならないかもしれません。しかし、シャットダウンや計画停止、二つのリージョン間のアクティブデプロイメントの切り替えによっても引き起こされるかもしれません。
フェイルオーバーをテストする際には、システムに接続しシャットダウンプロセスを実行してください。全てのジョブが停止し、クラスターが停止されたことを確認してください。
同期クライアント(あるいはCI/CDツール)がセカンダリーワークスペースに適切なDatabrikcsオブジェクトを複製します。セカンダリーワークスペースを有効化するには、以下のいずれかあるいは全てのプロスが必要になります：
- プラットフォームが最新の状態にあることを確認するためにテストを実行します
- 障害のあるサービスが復旧した際に、プライマリーリージョンが新たなデータを処理し始めないようにプライマリーリージョンのクラスター、プールを停止しておきます
- 復旧プロセス：
- 最新の同期データの日付を確認する。ディザスターリカバリー分野の用語を確認してください。このステップの詳細は、あなたがどのようにデータを同期するのか、ビジネス特有の要件によって変化します。
- データソースを安定化させ、全てのデータが利用可能であることを確認します。これには、AWS RDSのような外部データソースに加え、Delta Lake、Parquet、その他のファイルが含まれます。
- ストリーミングの回復ポイントを見つけます。その地点から処理を再開し、潜在的なデータ重複を排除します(Delta Lake箱の作業を容易にします)。
- データフロープロセスを完了し、ユーザーに通知します。
- 適切な数のプールを起動(あるいは
min_idle_instancesを適切な数に増やします)します。 - (停止されていない場合には)適切な数のクラスターを起動します。
- ジョブに対する同時実行数を変更し、適切なジョブを実行します。これらは一度限りのものもあれば、定期実行のものもあります。
- Databricksワークスペースのドメイン名、URLを使う外部ツールに対して、新たなコントロールプレーンに更新します。例えば、REST APIのURLやJDBC/ODBC接続を更新します。コントロールプレーンが変更した際には、ユーザーが利用するDatabricksのウェブアプリケーションURLも変更になりますので、新たなURLをユーザーに通知します。
復旧(フェイルバック)のテスト
フェイルバックは容易にメンテナンス期間中に実行できます。このプランは以下のいずれか、あるいは全てを含みます：
- プライマリーリージョンが回復したことを確認します。
- 新たなデータを処理しないようにセカンダリーリージョンのプールとクラスターを停止します。
- セカンダリーワークスペースにおいて更新されたアセットをプライマリーデプロイメントに同期します。フェイルオーバースクリプトの設計によっては、セカンダリー(ディザスターリカバリー)からプライマリーリージョン(プロダクション)にコピーするために同じスクリプトを実行できるケースがあります。
- 新規データをプライマリーデプロイメントに更新します。データ損失を防ぐために監査ログとDeltaテーブルを活用できます。
- ディザスターリカバリーリージョンでの全てのワークロードを停止します。
- ジョブとユーザーのURLをプライマリーリージョンに切り替えます。
- プラットフォームが最新の状態にあることをテストします。
- 適切な数のプールを起動(あるいは
min_idle_instancesを適切な数に増やします)します。 - (停止されていない場合には)適切な数のクラスターを起動します。
- ジョブに対する同時実行数を変更し、適切なジョブを実行します。これらは一度限りのものもあれば、定期実行のものもあります。
- 必要であれば、将来の障害に備えてセカンダリーリージョンを再度ディザスターリカバリーとして利用できるように設定します。
自動化スクリプト、サンプル、プロトタイプ
あなたのディザスターリカバリープロジェクトでの活用を検討すべき自動化スクリプトです。
- 同期プロセス開発を容易にするためにDatabricks Terraform Providerを活用することをお勧めします。
- 自動化のサンプル、プロトタイプのスクリプトに関してはDatabricks Workspace Migration Toolsも参照ください。
- Databricks Sync (DBSync)プロジェクトは、Databrikcsワークスペースのバックアップ、リストア、同期を行うオブジェクト同期ツールです。