G-gen の杉村です。BigQuery の可用性を高めるためのクロスリージョン・データセットレプリケーション (Cross-region dataset replication) について解説します。

クロスリージョン・データセットレプリケーションとは

クロスリージョン・データセットレプリケーション (Cross-region dataset replication) は、BigQuery のデータセットに読み取り専用のセカンダリ・レプリカを追加することで、別のリージョンにデータを非同期レプリケーションし、データの読み取り可用性を高める機能です。

クロスリージョン・データセットレプリケーションを用いると、指定した別リージョンに読み取り専用のセカンダリ・レプリカが作成され、データが非同期でレプリケーション (複製) されます。これにより元のリージョンの BigQuery サービスに障害があってもデータの可用性を確保することができます。

またこうして作られたセカンダリ・レプリカはプライマリへの昇格が可能なため、当機能をデータセットのリージョン間移行に用いることもできます。

参考 : Cross-region dataset replication

なお当機能は2023年8月現在は Preview リリースです。本番環境での利用は推奨されないため、ご注意ください。

仕組み

BigQuery の可用性

当機能を使わない通常状態のデータセットでも、単一リージョンの中で2つゾーンにデータが複製されています。そのためデータの堅牢性は高いものの、リージョン単位で BigQuery サービスがダウンした際には、一時的にデータを利用することができなくなります。これは US マルチリージョンなどのマルチリージョンを選択しても同様です。マルチリージョンを選択しても、データはそのマルチリージョン内のいずれかのリージョンのうちの2つのゾーンにのみ複製されます。マルチリージョンを選択するメリットは可用性ではなく、より大きい割り当て (Quota) が得られることにあります。

一方でクロスリージョン・データセットレプリケーションを用いると、メインのリージョンでサービスがダウンしても、複製先のセカンダリ・レプリカに対して読み取りジョブを実行することが可能です。

参考 : ロケーションとリージョン
参考 : 可用性と耐久性

データのレプリケーション

当機能を有効化すると、指定したリージョンにセカンダリ・レプリカが作成されます。セカンダリ・レプリカのあるリージョンをセカンダリ・リージョンと呼びます。セカンダリ・レプリカは読み取り専用です。

反対に、もともとのデータセットはプライマリ・レプリカ、それが存在するリージョンをプライマリ・リージョンと呼びます。

プライマリからセカンダリへのデータの複製は非同期で行われます。すなわち、プライマリでデータの INSERT や UPDATE が完了しても、その変更がセカンダリに反映されるまでにはラグがあります。ラグはデータの量や通信状況、リージョン間の距離にも依存するため一概には言えませんが、数分のオーダーと考えられます。

セカンダリ・リージョンでは、プライマリと同じく、データは2つのゾーンに複製されて保存されます。

なお、セカンダリ・リージョンは複数作成することができます。つまり東京リージョンのデータセットを「ソウル」「大阪」「シンガポール」のように複数リージョンへレプリケーションできます。

参考 : Dataset replication

セカンダリ・レプリカの昇格

セカンダリ・レプリカをプライマリ・レプリカに昇格させることができます。

ただし、昇格を実行できるのはプライマリ・レプリカが利用可能なときだけです。すなわち、プライマリ・リージョン (レプリカ) が障害でダウンしているときは、昇格を行うことができません。

あくまでプライマリの障害時は、セカンダリに読み取りのみが可能です。すなわち当機能で確保可能なのはデータの読み取り可用性のみであることになります。

参考 : Promote the secondary replica

料金

データサイズに応じた BigQuery ストレージ料金が、セカンダリ・レプリカにも発生します。また当然、セカンダリ・レプリカに対して読み取りクエリを実行すれば、その分の BigQuery コンピュート料金が発生します。

また、リージョン間のデータ複製に伴い、GiB あたりのネットワーク転送料金が発生します。単価は複製元・先のリージョンが存在する大陸によって異なりますので、詳細は以下のドキュメントをご参照ください。

参考 : Data replication pricing

制限

ロケーションの考慮事項

ビュー、マテリアライズド・ビュー等はレプリケーションされてもテーブル定義が複製されるだけです。セカンダリ・リージョンにあるビュー等にクエリしても、ベーステーブルのロケーションが異なればクエリは失敗します。

また外部テーブルや BigLake テーブルなどは Cloud Storage などのデータソースとテーブルが同じリージョンに存在している必要があるという制限があり、リージョンが異なればクエリは失敗します。

その他に、US マルチリージョンと EU マルチリージョンには、特定のリージョンにレプリカを作成できない制限があります。

リソースごとに様々な制限がありますので、詳細は以下のドキュメントをご参照ください。

参考 : Location considerations
参考 : Resource behavior

その他の制限

その他にもいくつかの制限があります。

Storage Write API で書き込まれるデータはコミットされてからレプリケーションが始まる。またラグが大きい場合がある
ポリシータグ (列レベルのセキュリティや動的データマスキングで使われる) はレプリケーションされない
- セカンダリ・レプリカではポリシータグを参照する列へのクエリは失敗する。昇格しても使えるようにはならない
帯域はベストエフォートで 3 GB/秒 (プロジェクトあたり・大陸間ペアあたり)

上記は特に影響が大きそうなもののみピックアップしています。データセットの要件にあわせ、詳細は以下の公式ドキュメントを参照してください。

参考 : Limitations

セカンダリ・レプリカへのクエリ

仕様

セカンダリ・レプリカは読み取り専用です。

後述の 利用方法 の章をご覧頂ければ分かるように、セカンダリ・レプリカを作成してもユーザからはデータセットは1個に見えます。セカンダリ・レプリカへのクエリを実行するには、クエリ実行時に実行ロケーションを明示的に指定します。

コンソールであればクエリエディタの歯車マークから、bq コマンドや SDK であればオプションで指定することができます。

スロット

セカンダリ・リージョンでクエリを実行すると、セカンダリ・リージョンのスロットを消費します。当該リージョンでオンデマンドクエリを実行するか、プライマリとは別で Editions を購入しておく必要があります。

参考 : Compute capacity in the secondary region

障害時の挙動

プライマリ・リージョンが障害でダウンしても、セカンダリ・リージョンへの読み取りクエリを実行することができます。

セカンダリは読み取り専用のため、書き込みは実行できません。また前述の通りプライマリのダウン中はセカンダリを昇格させることもできません。

セカンダリ・リージョンが障害でダウンした場合、プライマリへの影響はありません。

参考 : Outage scenarios

利用方法

レプリカの作成

データセットに対してセカンダリ・レプリカを作成するには ALTER SCHEMA 文を実行します。

ALTER SCHEMA my_dataset
ADD REPLICA `replica-in-seoul`
OPTIONS(location='asia-northeast3');

上記は asia-northeast1 (東京) に存在するデータセット my_dataset に対して replica-in-seoul という名称のセカンダリ・レプリカを asia-northeast3 (ソウル) に作成する DDL です。

なおこのようにしてデータセットに対してセカンダリ・レプリカを作成しても、コンソール画面や bq コマンドではデータセットは1個に見えます。ロケーションもプライマリ・リージョンしか表示されません。

レプリカ作成後は、以下のクエリで INFORMATION_SCHEMA を参照することで、レプリカの存在を確認することができます。

SELECT * FROM `region-asia-northeast1`.INFORMATION_SCHEMA.SCHEMATA_REPLICAS;

以下のような結果が表示されます。

+----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+
|  catalog_name  | schema_name |   replica_name   |    location     | replica_primary_assigned | replica_primary_assignment_complete |    creation_time    | creation_complete | auxiliary | replication_time | placement_location |
+----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+
| my-project-id  | my_dataset  | replica-in-seoul | asia-northeast3 |                    false |                               false | 2023-08-19 00:51:44 |              true |     false |             NULL | NULL               |
| my-project-id  | my_dataset  | asia-northeast1  | asia-northeast1 |                     true |                                true | 2023-08-19 00:49:10 |              true |     false |             NULL | asia-northeast1    |
+----------------+-------------+------------------+-----------------+--------------------------+-------------------------------------+---------------------+-------------------+-----------+------------------+--------------------+

クエリの実行

セカンダリ・レプリカにクエリを実行する際は、ロケーションを明示的に指定します。プライマリに実行するときと SQL 文は全く同じですが、実行時にロケーションを明示的に指定します。

Web コンソールでは以下のような手順になります。

my_dataset は asia-northeast1 (東京) にあるので、通常ではエラーになるはずですが、上記のケースではレプリカを asia-northeast3 (ソウル) に作成済みでしたので、クエリを実行することができました。

bq コマンドでは以下のように、オプションでロケーションを指定するだけです。

bq query --nouse_legacy_sql --location=asia-northeast3 \
  'select * from `my-project-id.my_dataset.my_table`;'

昇格

セカンダリ・レプリカをプライマリへ昇格させるには、以下の DDL を実行します。なお DDL 実行時は、ジョブ実行ロケーションをセカンダリ・リージョン側に設定する必要があります。

ALTER SCHEMA my_dataset
SET OPTIONS(primary_replica = 'replica-in-seoul')

なお昇格後は以下のようになります。

コンソールや bq コマンドでデータセットを describe したときのロケーション表記は、昇格後のリージョンになる
もともとプライマリだったリージョンはセカンダリになり、読み取り専用になる

レプリカの削除

セカンダリ・レプリカを削除させるには、以下の DDL を実行します。なお DDL 実行時は、ジョブ実行ロケーションをプライマリ・リージョン側に設定する必要があります。

ALTER SCHEMA my_dataset
DROP REPLICA IF EXISTS `replica-in-seoul`;