BigQueryのリージョンをusから東京に引っ越した際の備忘録

こんにちは エージェンシー事業部でデータ基盤の保守/運用を担当しているシニアデータエンジニアの内田です。

今回は、BigQueryのリージョンをusから東京に引っ越した際の話になります。

リージョンを切り替える動機

東京GCPリージョンでBigQueryの提供が開始されてから、アドウェイズではusリージョンと東京リージョンでリージョンが統一されておらず、テーブルをJOINさせる際など不都合が生じていました。

そのため東京リージョンに統一する意思決定をし、東京リージョンへの移行作業を行いましたのでその際のリージョン移行の手順を共有します。

クロスリージョンデータセットレプリケーションの利用

previewの機能ではありますが、 クロスリージョン データセット レプリケーション  |  BigQuery  |  Google Cloud を利用すればBigQueryのリージョン移行は下記3ステップで非常に速やかに終わります。

1.東京リージョンにレプリカを作成

ALTER SCHEMA my_dataset
ADD REPLICA `asia-northeast1`
OPTIONS(location='asia-northeast1');

2.東京リージョンに作成したレプリカをプライマリに昇格

ALTER SCHEMA my_dataset SET OPTIONS(primary_replica = 'asia-northeast1')

3.不要になったusリージョンのレプリカを削除

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `us`;

クロスリージョンデータセットレプリケーションの課題と対策

テーブル、ビューしか存在しない場合これでリージョン移行は完了ですが、リモート関数、外部テーブル、ストアド プロシージャ、UDFなどを使用している場合いくつかの作業を行う必要があります。

クロスリージョンデータセットレプリケーションの制約については下記のドキュメントを参照ください。

cloud.google.com

弊社の場合「外部テーブル」を使用していたため

外部テーブル定義のみが複製されます。Cloud Storage バケットがレプリカと同じロケーションに配置されていない場合、クエリは失敗します。

上記制約のため東京リージョンで外部テーブルに対してSQLを実行するとクエリは失敗し下記のエラーが発生します。

Cannot read and write in different locations: source: US, destination: asia-northeast1

この課題を解決するためにはCloud Storage(GCS)のリージョン変更も行う必要がある為合わせてGCSのリージョン変更も行いました。

GCS以外のS3などの外部テーブル、ストアドプロシージャ、リモート関数などのリージョン変更の際の対応方法は本記事の範囲外の為別途検証お願い致します。

Storage Transfer Serviceの利用

移行対象となっているGCSには10TB以上のデータが蓄積されているため、大容量のGCSを転送する手段として、Googleの推奨事項にも記載がある通り現状最有力なのがStorage Transfer Serviceになります。

cloud.google.com

Storage Transfer Serviceを利用したGCSのリージョン移行手順

1.GCPのサービスからStorage Transferを選択

Storage Transferを選択

2.転送ジョブを作成を押下

転送ジョブ

3.スケジュール モードはバッチを選択

スケジュール モードはバッチを選択

4.ステップに沿ってソース、転送先などを入力

転送ジョブのステップ

この状態で「作成」ボタンを押下すれば後はバッチ処理が完了するのを待つだけです。 1TBほどのデータ量ならおおよそ10分ほどで転送完了するかと思います。

まとめ

従来BigQueryのリージョン移行作業は非常に工数がかかりましたが、2023年8月からクロスリージョンデータセットレプリケーションが提供されてからは、リージョン移行が非常にやり易くなったなと感じます。あまり機会は無いかもしれませんがBigQueryのリージョンを切り替える機会がもしあった場合は参考になれば幸いです。

最後までお読み頂きありがとうございました!