BigQuery Transfer Service を用いたデータ連携 〜 リージョン × 暗号化方式における可否 〜
こんにちは、クラウドエース第四開発部に所属している笠原です。
今回は BigQuery (以下、 BQ) のデータ連携について、案件で直面した課題に対し、調査の結果得た示唆を記載したいと思います。
リージョン間をまたぐデータセットの同期を取ろうとした時に、送信元と受信元のデータセットのリージョンと暗号化方式において、BigQuery Data Transfer Service (以下、BQ Transfer) が使用できるケースとそうでないケースがあり、その整理の内容を本記事で解説したいと思います。
はじめに
プロジェクトで実装しようとした要件は、以下の図の内容です。
- 顧客の業務要件（BCP）に対応するため、もともと東京リージョン単一で作成していた各処理を大阪リージョンにも冗長化し、災害対策用の環境を構築しました。
- 当初稼働していたプロジェクトに別リージョンのリソースを追加しました。図でいうと SFTP サーバーや、Cloud Storage の部分が該当します。
- 上記に付随して、リソースの種別を変更しました。例えば、Cloud Load Balancing は、もともと単一リージョンの SFTP サーバーにのみトラフィックを送信するリージョンロードバランサーを採用していましたが、上記の変更を実施し、複数リージョンにトラフィックを送信する必要が発生したため、グローバルロードバランサーに種別を切り替えました。
- データ処理プロジェクト、ML 処理プロジェクトは、プロジェクト内で稼働するプログラムコードへの影響を鑑み、リソース名を通常時処理と災害時処理のそれぞれのプロジェクトで揃える前提で設計を行いました。そのため、災害時処理用のプロジェクトを新規に作成し、Composer などのコンピューティングリソース、BQ などのデータリソースを別途新プロジェクトに構築しました。
本記事でフォーカスを当てるポイント
新たにプロジェクトを作成して、災害対策用のリソースを作成しましたが、災害がいつ起こっても対応できるように、処理済みのデータを通常時処理プロジェクトと災害時処理プロジェクトそれぞれで同期を取る必要がありました。
図で言うと赤線の部分で、通常時には定期的に通常時に使う BQ から災害時に使う BQ にデータを連携する必要があり（赤実線）、災害時には災害時に使う BQ から通常時に使う BQ にデータの連携を行う必要がありました（赤破線）。
今回の要件では、冒頭に記載した BQ Transfer を用いて実装を進めることを想定していました。
BQ Transfer とは
Google Cloud が提供するフルマネージド型のデータ転送サービスで、使用することで様々なデータソースから BQ へのデータの転送を自動化できます。
主な特徴としては、以下の点が挙げられます。
- 広範囲なデータソースに対応: BQ だけでなく、Google 広告、Google アナリティクス、YouTube などの Google サービスに加え、Amazon S3 や Teradata などの外部サービスからもデータ転送が可能です。
- スケジュール設定: データ転送のスケジュールを日次、週次、月次などで設定可能。また、単発のオンデマンド実行も設定可能です。
- 監視とロギング: 転送状況の監視やログの確認が可能です。
（参考）
直面した課題
当初の想定では、もともと存在していた通常時の BQ は、顧客管理の鍵（以下、CMEK）で暗号化されており、そこから新たに作成した CMEK で暗号化された災害対策側の BQ に、BQ Transfer を用いてデータ転送設定を追加する想定でした。
一方、以下公式ドキュメントの記載を見て、CMEK を用いた場合に、リージョンが異なるデータセット（例: 大阪の CMEK → 東京の CMEK）での BQ Transfer 設定の追加は不可能であると取れる記載があり、制約を回避した構成を取る必要がありました。
そのため、通常時に稼働するリソースが存在するプロジェクトに、暗号化方式が Google 管理の鍵（以下、GMEK）で異なるデータセットを配置し、そこを経由することで同期が可能かを検証する方針を取りました。
東京リージョンに存在する通常時に使う想定の BQ と新たに作成した災害対策の BQ で、リソースのリージョンと、暗号化方式の組み合わせに応じて、どのような場合においては BQ Transfer 設定が追加可能か、不可能かについて詳細内容を整理し、実現方式の策定を行いました。
検証結果
転送元/転送先の BQ のリージョンと暗号化方式で、BQ Transfer 検証結果の表を作成しました。縦軸が転送元の BQ で、横軸が転送先の BQ を表しています。
| 転送元/転送先 | 東京リージョン(GMEK) | 大阪リージョン(GMEK) | 東京リージョン(CMEK) | 大阪リージョン(CMEK) |
|---|---|---|---|---|
| 東京リージョン(GMEK) | ○ | ○ | ○ | × |
| 大阪リージョン(GMEK) | ○ | ○ | × | ○ |
| 東京リージョン(CMEK) | ○ | × | ○ | ○ |
| 大阪リージョン(CMEK) | × | ○ | ○ | ○ |
結果としては、リージョンが異なり、暗号化方式も異なるケース（例えば大阪の CMEK → 東京の GMEK）で BQ Transfer 設定の追加が不可で、それ以外は BQ Transfer 設定の追加が可能でした。
※ 当該ケースでは、BQ Transfer ジョブの実行時に以下のエラーが発生します。
Failed to start job for table transfertest with error INVALID_ARGUMENT: Cannot copy a table without a customer-managed encryption key to a destination that uses a customer-managed encryption key.; JobID: xxxxxxxxxxxx:yyyy_yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
Google サポートに、上記の検証結果をもって当初リージョン違いの CMEK のデータセット間の BQ Transfer 設定の追加が不可であると解釈できたドキュメントの見解を確認しました。
回答は、CMEK を利用して暗号化されたデータセットに BQ Transfer 設定を追加する場合には、少なくともコピー先のデータセットが暗号化されている必要があるが、暗号化がされていればリージョンを跨いだ BQ Transfer 設定の追加は可能であると回答をいただきました。
今回の検証を踏まえた結果として、このケースでは当初実現が厳しいと判断していた、通常時の BQ（CMEK） → 災害時の BQ（CMEK）で BQ Transfer 設定を追加することが可能であると確認でき、その通りに実装を進める形をとることができました。
おわりに
エンタープライズのシステムでは、今回取り組んだ BCP 対応のような文脈で、複数リージョン間のデータ連携や処理を設計する機会が一定数想定されると思います。
今回は題材として BQ Transfer を取り上げましたが、リージョンを跨いだ際の制約を受けるリソースや機能は他にも存在していると思います。
今回のように、ドキュメントの記載から迷う内容もあると思いますが、ドキュメントだけ見て制約事項を諦めず、ぜひ一度実際に検証を行ったり、可能であればサポートに問い合わせるなどのアクションをとった上で、仕様を判断することを推奨します。
本記事の内容が、他の事例の参考になり、結果として Google Cloud を用いた開発がよりスムーズになることを願っています。
Discussion