BigQueryのバックアップの裏技かもしれない方法

2024.03.09 XIMIX 江口

日本情報通信の江口です。

はじめに

Google Cloudのサービスの中で、BigQueryを利用している方は多いと思います。

私自身、フルマネージドでスケーラブルであるというBigQueryの使いやすさゆえに、多くのシステム開発で利用しています。

その中で、災害対策の観点でバックアップが必要になった際に困ったのと、それを一部解決できそうなことがあったので、ご紹介します。

BigQueryのデータ保存

BigQueryは99.99% の可用性と非常に高い耐久性を備えたサービスです。また、バックアップ機構としてもタイムトラベルやテーブルスナップショットの機能を有しており、オペレーションミスをしたり重篤なバグがない限りはデータを永続的に消失することはないように思えます。

DRを考える

そんな中で今回課題にしたのは、「リージョン障害があったときに、別リージョンのDR(Disaster Recovery)サイトでシステムを稼働させる」というシナリオを考えた場合です。

前提として、DRを検討する場合には、RPO(目標復旧時点)やRTO(目標復旧時間)といった障害復旧要件の定義をしたうえで、インフラ・アプリケーション・人的体制など複数の切り口からそれを実現するための設計を行うこととなります。

とはいえ、フルマネージドなインフラ側で可能な限り高いRPO/RTOを実現したい、とGoogle Cloudに期待したいのが正直なところでしょう。それが実現出来れば、アプリケーション・人的体制の負担は相対的に軽くなり、信頼性の高いシステムを構築できます。

BigQueryのロケーション

リージョンの中での耐障害性については無類の強さを誇るBigQueryですが、複数リージョンとなると状況が変わります。2023/12/22現在、マルチリージョンで利用できるのはUS, EUのみであり、日本を含むASIAではシングルリージョンでのみの構成になってしまいます。

したがって、例えば東京リージョンで障害が起きた際に大阪リージョンにDRサイトを構築する要件がある場合には、東京リージョンで動いているものと別のBigQueryデータセットが必要です。

BigQueryのリージョン間同期

BigQueryをシングルリージョンののリソースとして構築しなければならないとしても、ほぼリアルタイムの同期が取れるのであれば、さほど大きな問題はありません。

ですが、2023/12/22現在提供されているリージョン間でのBigQuery同期は、ベータ版機能のデータセットコピー、またはBigQuery Data Transfer Serviceを用いた定期コピージョブの作成で、いずれも最小頻度が12時間と定義されています。

データセットコピーの場合: 公式ページより

コピージョブ間の最小頻度は 12 時間です。
BigQuery Data Transfer Serviceの場合: 設定画面より

つまり、この機能を単体で実現できるRPOは12時間ということになります(＝少なくとも12時間前のデータまでは復元できる)。さらに短いRPOを実現したいとしたら、12時間からの差分時間を埋め合わせられるように、更新ファイルをCloudStorageにも取っていてそれを取り込む、などの仕組みが必要になりそうです。

裏技かもしれない方法

概要

この12時間という最小頻度をどうにかできないか、を試してみたのが今回の本題です。

前述の画像

0_bq_transfer_ng

という通り、Data Transfer Serviceを1つ設定する時には、12時間が最小頻度です。

ただし、転送設定自体を複数設定すれば、12時間より短いスパンで設定できるのでは？と思いました。

実施事項

まずは、asia-northeast1とasia-northeast2それぞれにデータセットを用意しました。

asia-northeast1(東京)にデータセットと、コピー確認用のテーブルを2つ用意しました。

1_source_bq

そしてコピー先にはasia-northeast2(大阪)にデータセットを、テーブル無しで作成しました。

1_dest_bq-1

この状態で、複数のTransfer Serviceジョブを作ってみます

2-1-transfer_job-1

2-2-transfer_job-2

それぞれ、最小頻度が12時間は変えられないものの、時間をずらしてコピーする転送設定を2つ用意してみました。少なくとも作成時点で、「同一設定の転送設定があるため作成できません」のようなエラーはありませんでした。

3-transfer-job-list

検証結果

実際に動作するか見てみます。

14:30 (1つ目の転送設定)

転送は成功しています。

4-first-copy-result

BigQueryを見ても、14:30の起動を受けてasia-northeast2(大阪)のデータセットにコピーされたデータセットが作られています。

4-first-copy

15:30 (2つ目の転送設定)

こちらも転送が成功しています。

5-second-copy-result

BigQueryを見ても、15:30の起動を受けてasia-northeast2(大阪)のデータセットにコピーされたことが、最終更新から見て取れます。

5-second-copy

つまりこの動きからすると、「Transfer Serviceの1設定単位で12時間単位なだけであり、リージョン間コピーの実行最小頻度が12時間というわけではない」のが分かります。

注意事項

この動きを活用し、RTOに応じた単位でTransfer Serviceの設定を入れれば、12時間よりも短い単位でバックアップを取れるというのが分かります。動作上も特に問題は見られません。

ただし、公式としてこのような使い方を明示していないことからすると、保証されないこともありそうです。

例えば、1回のコピーに2時間以上かかるほどのデータを、1時間単位でコピーするようTransefer Serviceの設定をした場合(1時間ごとの設定を12作った場合)、コピーが重複することになります。

この時にどのような挙動をとなるかまでは今回確認できていませんが、期待と異なるコピー操作が行われるか、コピー自体が実行されないか、などの動作が考えられます。

この点においては、RTOとデータ量を勘案したうえで、頻度の設定は必要になると考えます。

まとめ

インフラとしてより簡単にDRに備えたいという思いから、やや裏技的な方法を試してみたのが今回の内容です。障害への要件を検討すべきシステムが、どれだけの安定性を求めるか、どこにコストをかけられるかによってくるので、今回の検証結果をすべてのシステムに導入できるわけではありません。その点をご承知の上、それぞれのシステムでのDR設計における案の一つとして、こちらを加えていただけたら幸いです。