[Google Cloud Next '25 Las Vegas] セッション参加レポート: BigQueryの地理的冗長性を確保するには？

2025.04.11 XIMIX 江口

keyvisual

Google Cloud Next '25 Las Vegasとは

Google Cloud Next '25は、2025年4月9日から4月11日の3日間、アメリカ・ラスベガスのMandalay Bayにおいて開催されるGoogleのクラウドサービスに関する世界最大級のイベントです。「今回は、これまでで一番多彩なデベロッパーコンテンツを用意します。デベロッパー専用のエクスペリエンスやコンテンツを充実させ、アプリ開発や AI のほか、スケーラブルで安全なデータ駆動型アプリケーションの学習や開発に役立つ重要なトピックを網羅します。」と銘打っており、AIコンテンツで大いに盛り上がった昨年や一昨年にも勝るとも劣らないイベントとなることが期待されます。

私たち日本情報通信株式会社も、Google Cloudに精通した専門家として、技術イノベーションの最新動向を取り入れ、顧客に対するソリューション提供に活かしていくことを目指して参加しています。

このような貴重な機会ですので、現地からいち早くブログで最新情報や熱量を発信してまいります。

本記事で紹介するセッション概要

講演日時：2025年4月10日
セッションタイトル：Enterprise resilience with BigQuery: Cross-region disaster recovery
セッション内容のサマリ

地理的な冗長性は、復元力のあるデータアーキテクチャの重要な柱です。BigQuery のクロスリージョンデータセットレプリケーションとマネージドディザスタリカバリを活用すれば、リージョンレベルのインフラストラクチャ障害といった万一の事態においても、ミッションクリティカルなアプリの可用性を確保できます。この組み込み機能が、リージョンレベルの障害からデータとワークロードを保護し、組織へのデータアクセスを中断なく確保する方法をご覧ください。

このセッションで期待できること

個人的に大変気になっていたセッションです。

BigQueryにおけるDisaster Recovery(以下DR)の対応が長らく悩みとなっていたためです。データを永続保存させる場所としてBigQueryは多くのシステムにおいて最適な選択肢かと思われますが、現時点でのアジアリージョンにおける地理的冗長性は提供されていないという課題があります。障害に備えるには、定期的なバックアップだったり、平時からの冗長化という選択肢を採らなければなりません。レプリケーションという方法はあるものの、こちらも災害対策をオペレーションとして実施が必要です。Cloud Storageが、デュアルリージョンという形で意図したリージョンにて冗長性を確保できているだけに、BigQueryで確保できていないことは不満と言える部分でした。

こういった不満を解決できるセッションになることに期待をしています。

セッション内容

DRについて

セッション冒頭では、DRが必要となる3つの主要な理由（規制遵守、自然災害、予期せぬ事態）を述べたうえで、実際には70% の組織がDRの十分な対策ができていないという現状についても調査報告が引用されました。

BigQuery Managed Disaster Recovery

GoogleCloudマネージドで、別リージョンへのBigQuery移行が出来るサービスとして紹介されたのが、このBigQuery Managed Disaster Recoveryです。

以下の機構により、コンピューティングリソース、データリソース、およびその他の関連リソースが自動的にセカンダリーリージョンに移行し、ワークロードが継続される仕組みです。

マネージド障害復旧のアーキテクチャ。

ユーザーがフェイルオーバーを開始すると、コンピューティングリソース、データリソース、およびその他の関連リソースが自動的にセカンダリーリージョンに移行し、ワークロードが継続される仕組みです。アンマネージドな方法でのDisaster Recoveryと比較して、手動でのデータコピー、コンピューティングリソースのプロビジョニング、クエリのルーティングなどが不要です。

性能としては、RPO 15分、RTO 5分という目標が設定されています。アンマネージドなDR手順よりもはるかに迅速な復旧が期待できます。

デモンストレーションでは、地理的に異なるリージョンへのレプリケーションが実現できている様子が紹介されました。

一つのデータセットに対して、クロスリージョンのレプリカおよびDR予約を設定しておくと、上記の通りユーザーが「フェイルオーバー」をクリックすることですぐにレプリカのリージョンから読み込みを行っている様子が示されました。

また、「フェイルオーバー」をしたときに、レプリカのリージョンがプライマリとして利用できるようになると、元のプライマリがレプリカに切り替わる様子が示されました。

BigQuery Managed Disaster Recoveryの導入実績

Charles Schwab社における BigQuery マネージドディザスタリカバリソリューションの活用事例紹介がありました。Charles Schwab は大規模な金融サービス企業であり、高い可用性、堅牢性、信頼性が不可欠とのことです。Google Cloud への移行後、ゾーンおよびリージョンレベルの保護は標準で提供されていたものの、ペタバイト規模のデータを扱う同社にとって、クロスリージョンでのDRが必須であると認識した経緯が説明されました。
クロスリージョンレプリケーションが必要とされた理由として、金融規制当局からの要求、地域的な災害の発生、ランサムウェア攻撃の増加、そして個別のアプリケーションごとのディザスタリカバリ対策に伴うコストと複雑性の増大が挙げられました。 BigQuery Managed Disaster Recoveryは、自動化された効率的な集中型ソリューションとして、課題を解決する上で重要な役割を果たしたという評価を受けているようです。

まとめ・感想

DRについては前述の通りずっと課題を抱えていたため、この機能は非常に画期的であると感じました。これまで私が把握していたDRの方法だと、定期的なコピーによる別リージョンにあるデータセットへのデータ退避というものでした。この場合、定期的なコピーの頻度がRPO/RTOの大きなボトルネックとなりますし、データセット自体が異なることから読み出し元もこのDRに基づくオペレーションを必要とすることになります。そういった課題は、この機能により解消できると考えています。

ただし、現在の時点では実際に使う上では留意すべきことがあります。

BigQuery Enterprise Plusエディションが必要
フェイルオーバー予約にリージョンの縛りがあり、すべてのリージョンで利用できるわけではない (※ リージョン一覧は公式ドキュメントに記載ありとなっていますが、ドキュメントに記載されていないasia-northeast1,asia-northeast2も選択可能なようです)。
あくまでデータセットとしてレプリケーションされるだけのため、関連リソースが退避先リージョンに無いとそのまま使うことは出来ない(例: 顧客管理の鍵 CMEK でデータを保護をしている場合に、CMEKのリソースが退避先にも存在していないと実際にはデータ利用は出来ない)。
レプリカのセカンダリリージョンでは、クエリ実行のためのコンピュートコストはかからないが、ストレージコストはかかる。そのためプライマリージョンと合わせて、実際のデータの倍量のストレージコストになる。

エディションも含めたうえでのコスト面についてはある程度やむを得ない点だと考えます。システムによっては、そのコスト見合うだけのDR対策が求められることもあるでしょう。DRをしなければならないという緊急的な状況下においては、このようにマネージドで提供されるサービスがあることは非常に心強く感じられるでしょう。