Disaster Recovery on Databricks - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricksにおけるディザスターリカバリー パート1
多くのアプリケーションとシステムに対する全体的な医療チームとして動作するディザスターリカバリー(DR)戦略を作成する際、優先度、機能、制限、コストに対する評価が必要となります。
この種の議論のスコープをさまざまなテクノロジー、ベンダー、クラウドプロバイダー、オンプレミスのシステムなどに拡大したい誘惑がありますが、ここではDatabricksワークスペースに関わるDRにのみフォーカスします。 AWS、Azure、GCPのクラウドインフラストラクチャ固有のDRの情報は、すでに他のソースからアクセスできるようになっています。
さらに、どのようにDRがビジネス継続性(BC)にフィットするのか、高可用性(HA)との関係は本シリーズのスコープ外です。HAサービスのみを活用するだけでは、包括的なDRソリューションとしては不十分であると言うだけで十分です。
これは、Databricksで実行する重要なワークロードとユースケースに対して適切なDR戦略と実装を決定することにフォーカスするシリーズの第一弾です。いくつかの一般的なDRのコンセクトを議論しますが、読者の皆様においては、DRの用語、ワークフロー、ソリューションを実装するためのハイレベルのステップに関して、最初に見る概要としてDatabricksのドキュメント(AWS | Azure | GCP)をご覧になることをお勧めします。
Databricksワークスペースにおけるディザスターリカバリーの計画
損失限界の定義
Databricksで実行するユースケースやワークロードに対するDR戦略を実装するに際して、許容可能な回復ポイント目標(RPO)、回復時間目標(RTO)を決定することが基本的なステップとなります。ここでRPOはデータが失われるであろう最大のターゲットの期間であり、RTOはビジネスプロスを回復しなくてはいけないターゲットの期間とサービスレベルとなります。RTOとRPOは例えばユースケースやワークロードレベルというような特定の文脈に基づいて決定される必要があります。これらは、災害イベントでのデータ損失の限界を定義し、適切なDR戦略につながり、DRの実装がどれだけ迅速に災害イベントから復旧すべきかを決定します。
DatabricksオブジェクトのRPO
DatabricksのオブジェクトはCI/CDやDRサイトへの複製のために用いるTerraform (TF)のようなInfrastructure as Code (IaC)で管理されるべきです。Databricks Repos(AWS | Azure | GCP)は、GitHubのような設定されたgitプロバイダーから一つ以上のワークスペースにソースコードをプルすることを促進するgit連携を提供します。
CI/CDパイプラインの最後でバージョン管理されたオブジェクトをDRサイトに公開するために、Databricks REST API(AWS | Azure | GCP)を利用できますが、このアプローチには2つの制限があります。第一に、REST APIではターゲットの状態を追跡できず、全てのオペレーションが安全かつ効率的であるようにするためには追加の工数が必要となります。第二に、必要な全てのAPI呼び出しをオーケストレートし、実行するには追加のフレームワークが必要となります。
Terraformを用いることで、バージョン管理とターゲットのワークスペースに必要な変更を適用によって、手動の状態追跡の必要がなくなり、宣言型の方法でユーザーの代わりに必要な変更を加えることができるようになります。TFの更なるメリットとして、DRソリューションに必要となるほぼ全てのDatabricksとクラウドリソースとやり取りできるDatabricks Terraform Providerがあります。最後になりますが、DatabricksはHashicorpの公式なパートナーであり、Terraformでマルチクラウドのデプロイメントをサポートすることができます。このシリーズの一部として、DR実装をデモンストレーションするためにDatabricks Terraform Providerを使用します。DB-Syncは、非TFユーザーでも複製管理を容易に行えるようにするDatabricks Terraform Provider向けのコマンドラインツールです。
DatabricksオブジェクトのRPOは、オブジェクトの状態の最新スナップショットと災害イベントの間の時間差となります。システムのRPOは全てのオブジェクトのRPOの最大値として決定されます。
データベースとテーブルのRPO
いかなるワークロードにおいても複数のストレージシステムが求められることがあります。Apache SparkがJDBC経由でアクセスするOLAPやOLTPシステムのようなデータソースでは、クラウドプロバイダーによって提供されるDRのためのオプションがあります。これらのシステムは DBRソリューションのスコープ内にあると考えるべきですが、それぞれのクラウドプロバイダーがバックアップと複製に関して異なるアプローチを取っているため、ここでは詳細を議論しません。それよりも、ここではオブジェクトストレージのファイルの上で作成される論理的データベースとテーブルにフォーカスします。
それぞれのDatabricksワークスペースはオブジェクトストレージに対する抽象化であるDatabricks File System (DBFS)を使用しています。重要かつプロダクsy本のソースコードやデータ資産をDBFSに格納すると言う使い方は推奨しません。DBFSルートを除き、DBFSにマウントされたオブジェクトストレージには、全てのユーザーが読み書きのアクセス権を持っています。さらに、DBFSルートはクラウドネイティブの複製サービスをサポートしておらず、データのエクスポートにはDeltaのDEEP CLONE、スケジュールされたSparkジョブ、DBFS CLIにのみ頼らざるを得ません。
DBFSにオブジェクトストレージをマウント(AWS | Azure | GCP)することができ、これによって外部ストレージに対するポインターを作成することができます。マウントはデータがDBFSローカルに同期されることを防ぎますが、マウントポイントはDRサイトにある別のおジェクトストレージに指定される必要があります。マウントは管理が難しく、間違ったストレージを指定しまう可能性があり、DRソリューションの一部として追加の自動化や検証が必要となります。外部テーブルを通じて直接オブジェクトストレージにアクセスすることで、複雑性とDRの障害地点の両方を削減することができます。
Apache Sparkを用いることで、ユーザーはマネージドあるいはアンマネージドのテーブルを作成することができます(AWS | Azure | GCP)。メタストアはマネージドテーブルのデータを管理し、マネージドテーブルのデフォルトの格納場所はDBFSの/user/hive/warehouseとなります。マネージドテーブルがDRを必要とするワークロードで使用されている場合、DBFSからデータは移行されるべきであり、デフォルトの格納場所を避けるために格納場所を指定された新規データベースを使うべきです。
アンマネージドテーブルは、CREATE TABLE文でLOCATIONパラメーターを指定することで作成されます。これによって、テーブルは指定された場所に保存され、メタストアからテーブルが削除されてもデータは削除されません。SparkSQLあるいはSparkSessionのtableメソッド(Python | Scala)を用いてメタストアに定義されたテーブルにソースコードがアクセスする場合、アンマネージドテーブルにおいても依然としてメタストアはDRで必要なコンポーネントとなります。
Amazon S3のようなオブジェクトストレージを直接利用することで、必要に応じて地理的に冗長性のあるストレージを活用でき、DBFSに関する懸念を回避することができます。
データの複製
DRにおける推奨ストレージフォーマットはDelta Lakeです。ParquetはCONVERT TO DELTAコマンドを用いて容易にDeltaフォーマットに変換することができます。Delta LakeのACID保証は事実上、フェイルオーバーおよびDRサイトからのフェイルバックにおけるデータ破損のリスクを排除します。さらに、すべてのDeltaテーブルを服せうするためにディープクローンを用いるべきです。不要なデータ転送コストを避けるインクリメンタルなアップデート機能を提供し、アベイラビリティゾーン、リージョンベースの地理的冗長レプリケーション(GRR)サービスでは利用できない追加のビルトインのデータ一貫性に対する保証を提供します。他のGRRのデメリットは、レプリケーション一方向であり、DRサイトからプライマリーサイトにフェイルバックする際には追加のプロセスが必要となると言うことです。一方、ディープクローンはプライマリーサイト、DRサイトの両方で双方向に動作します。
以下の図では、DeltaテーブルをGRRに用いることで生じる初期の欠点を示しています。
GRRとDeltaテーブルを活用するためには、DRサイトにおけるDeltaテーブルのバージョン(AWS | Azure | GCP)の完全性を保証するために追加のプロセスを作成しなくてはなりません。
上の図とDRとのレプリケーションをシンプルにするためにDeltaのDEEP CLONEを用いた場合を比較してみると、ディープクローンは最新のDeltaテーブル全体が複製されることを保証するので、ファイルの順序を保証し、複製を行うタイミングに対して更なるコントロールを行えるようになります。
このブログシリーズの中で、プライマリーからセカンダリーサイトにDeltaテーブルを複製するために、DeltaのDEEP CLONEを使用します。
Deltaに変換できないファイルはGRRを頼りにする必要があります。この場合、GRRとDeltaのDEEP CLONEの両方が実行することによる競合を避けるためにDeltaファイルとは別の場所にこれらのファイルを格納すべきです。DRサイトにおけるプロセスは、GRRを使用する際、ビジネスに対してデータセットの完全な可用性を保証するように配備される必要があります。しかし、これはディープクローンを用いる際には不要です。
オブジェクトストアのデータに対するRPOは、Deltaのディープクローンを用いて最後にいつ複製が取られたのか、あるいは、地理的冗長ストレージを用いた際にクラウドプロバイダーによって提供されるSLAに依存します。
メタストアの複製
Databricksデプロイメントではいくつかのメタストアの選択肢が提供されており、それぞれに関して簡単に検討していきます。
デフォルトのメタストアからスタートします。Databricksのデプロイメントでは、テーブルメタデータを永続化するために全てのクラスターとSQLエンドポイントからアクセスできる内部のUnity Catalog(AWS | Azure | GCP)、あるいはHiveメタストア(AWS | Azure | GCP)を利用できます。内部のHiveメタストアからテーブルとテーブルACLをエクスポートするためにはカスタムスクリプトが必要となります。これはDatabricksワークスペースのRPOと組み合わされ、マネージドテーブルに必要なメタデータのRPOは、これらの内部メタストアのテーブルとテーブルACLが最後にエクスポートされた時間と災害イベントの間の時間差であることを意味します。
クラスターは既存の外部メタストア(AWS | Azure | GCP)に接続することができます。外部メタストアを用いることで、背後のデータベースインスタンス向けのクラウドプロバイダーのサービスを活用することで、追加の複製オプションを手に入れることができます。例えば、メタストアを複製するためにAmazon AuroraのようなクラウドネイティブのデータベースやマルチAZデータベースインスタンスを活用することができます。このオプションは、Databricks on AWS、Azure Databricks、Databricks on GCPで利用することができます。RPOは、手動あるいは自動化されたエクスポートプロセスがない場合には、クラウドプロバイダーサービスによって提供されるSLAに依存します。
メタストアとしてGlueカタログを用いる機能は、AWSにおけるDatabricksデプロイメント固有のものです。GlueカタログのRPOはAWSで提供されるSLAあるいは複製ユーティリティに依存します。
Databricksにおける復旧時間目標(RTO)
プライマリーサイトのDatabricksワークスペースが利用できない時点から、DRサイトのワークスペースがクリティカルなアクティビティをサポートできる(事前に定義された)レベルのオペレーションに到達した時点までの時間でRTOを計測することができます。
一般的には、データは既に複製されていると仮定し、RTOに達する前には、ワークロード/ユースケースに必要なソースコードと依存関係が利用可能な状態となり、ライブなクラスター、SQLエンドポイント、(ファイルに直接アクセスするのではなく)データベースとテーブルのデータにアクセスする際にはメタストアが必要となります。
RTOは、ワークロード、ユースケースに対して選択されたDR戦略と実装に依存します。
ディザスターリカバリー戦略
ディザスターリカバリー戦略は広く2つのカテゴリーにブレークダウンされます。アクティブ/パッシブとアクティブ/アクティブです。アクティブ/パッシブ実装においては、プライマリーサイトは通常のオペレーションに使用され、アクティブであり続けます。しかし、DR(セカンダリー)サイトには、プライマリーに昇格するために必要な固有の実装に基づき、事前に計画されたステップが必要となります。一方アクティブ/アクティブ戦略では、両方のサイトが常に完全に稼働状態であり続けます。
アクティブ/パッシブ戦略
-
バックアップ&リストアはRTOの観点では非常に効率的でないと考えられています。プライマリーサイトでバックアップが作成され、DRサイトにコピーされます。地域間のフェイルオーバーにおいては、データパックアップからのリカバリーの実行に加え、インフラストラクチャもリストアされる必要があります。オブジェクトストアの場合、データもまたプライマリーサイトから複製される必要があります。このシナリオにおいては、DRサイトではインフラストラクチャとDatabricksオブジェクトに必要な全ての設定は利用できますが、配備はされません。ファイルベースのテーブルはバックフィルされる必要があり、他のデータソースは最新のバックアップからリストアされる必要があります。ビッグデータの観点では、RTOが遅延する可能性があります。
-
パイロットライト(Pilot Light) 実装においては、データストアとデータベースは定義されたRTOに基づいて最新に保たれ、サービスのワークロードで利用できるようになっています。その他のインフラストラクチャの要素は、通常はInfrastructure as Code (IaC)ツールで定義されますが、デプロイはされません。
パイロットライトとバックアップ&リストアの大きな違いは、読み書きがパスベースではな い場合にはメタストアを含むデータが即時に利用できるかどうかです。一般的にコストがほとんどかからないいくつかのインフラストラクチャは配備されます。Databricksワークスペースにおいては、必要なDatabricksオブジェクト(ソースコード、設定、インスタンスプロファイル、サービスプリンシパルなど)が配備された状態でワークスペースと必要なクラウドインフラストラクチャは配備されますが、クラスターやSQLエンドポイントは作成されないことを意味します。
-
ウォームスタンバイは最小構成のライブのデプロイメントに加えて、ライブのデータストアとデータベースを維持します。DRサイトでは全てのプロダクションワークロードをを捌けるようにスケールアップされる必要があります。パイロットライトを構築することに加え、ウォームスタンバイでは追加のオブジェクトがデプロイされます。例えば、後段のアプリケーションにデータを提供する際のRTOを削減するために、特定のクラスターやSQLエンドポイントが作成されますが起動はされません。また、これは、DRソリューションとDRサイトの健康状態における自信の度合いを増加させる継続テストを促進します。削除を回避するため、あるいはテストのため、さらには非常に厳しいRTOがある極端なケースにおいては、クラスターとSQLエンドポイントは定期的に起動されます。
アクティブ/アクティブ戦略
マルチサイトのDR実装においては、プライマリーとDRサイトの両方が完全にデプロイされ稼働状態となります。災害イベントの際には、新規のリクエストをプライマリーサイトではなく、シンプルにDRサイトにルーティングする必要があるだけです。マルチサイトはもっとも効率的なRTOを提供しますが、非常に高価で複雑となります。
プライマリーワークスペースとDRワークスペース間の、データ(テーブルやビューなど)、ユーザープロファイル、クラスター定義、ジョブ定義、ソースコード、ライブラリ、initスクリプト、その他のアーティファクトの同期によって複雑性が引き起こされます。さらに問題を複雑にしているのは、さまざまなスクリプトやコードに含まれるハードコードされた接続文字列、パーソナルアクセストークン(PATトークン)、APIコールのためのURIです。
適切なDR戦略の策定
分析システムはさらに重要となっており、障害はビジネスに多大なるインパクトを及ぼし、大きなコストを発生させ、潜在的な障害地点は環境がより複雑になり、互いに薄陽つくことで定常的に増加しています。結果として、DRが必要かどうかを決定するためにユースケースやワークロードに対するインパクト分析の実行や、そのような実装に対してチームの準備が整っていることを確認することは重要なアクティビティとなっています。
ここで列挙した戦略にはトレードオフが存在します。最終的には、RPOとRTOはワークロードやユースケースに対してどちらの戦略を選択すべきかを教えてくれます。そして、いかなる特定のDR戦略を実装、維持するためのコストに対して、災害イベントによる財務的、非財務的なダメージを用いて重みづけを行うべきです。推定した見積もりに基づき、災害が引き起こしたダメージに対してタイムリーな方法でサービス継続を保証するDR戦略を選択し、実装すべきです。
はじめてみる
Databricksのレイクハウスプラットフォームを用いたアプリケーションにDRソリューションが必要かどうかを判断することで、潜在的な損失を回避し、プラットフォームの利用者の信頼を保つことができます。適切なDR戦略と実装は、災害時において重要なアプリケーションと機能を再開するために必要なサービスを提供しつつも、コストが潜在的な(財務的、非財務的な)損失を上回らないことを確実にします。以下のアセスメントでは、適切なDR戦略と実装を判断するためにインパクト、準備状況の分析を実行するためのスタート地点とガイドを提供しています。