変更ストリームの概要

Bigtable は、変更ストリーム機能により変更データキャプチャ（CDC）を実現します。変更ストリームは、変更が発生すると Bigtable テーブルにデータ変更をキャプチャします。これにより、処理または分析のために変更をストリーミングできます。

このドキュメントでは、Bigtable 変更ストリームの概要について説明します。このドキュメントを読む前に、Bigtable の概要を理解する必要があります。

変更ストリームは次のような CDC ユースケースに役立ちます。

指定された変更が発生したときにダウンストリームアプリケーションロジックをトリガーする
データ分析パイプラインと統合する
監査とアーカイブの要件をサポートする

変更ストリームとは

変更ストリームは、通常はいずれかの Cloud Bigtable クライアントライブラリを使用して、ユーザーまたはアプリケーションによって行われたテーブルレベルの変更を追跡します。ガベージコレクションの変更もキャプチャされます。

変更ストリームが有効になっているテーブルに適用された変更はすべてデータ変更レコードとして保存されます。データ変更レコードには、以下に示す処理で適用されるデータ変更が含まれます。

Cloud Bigtable API メソッド MutateRow、MutateRows、CheckAndMutateRow、ReadModifyWriteRow を使用して送信された書き込み、削除、更新
ガベージコレクションによる削除
Admin API の DropRowRange メソッドによる行の削除

Bigtable テーブルに送信できる変更の種類の詳細については、読み取り、書き込み、削除、ガベージコレクションの概要をご覧ください。

変更ストリームは、列ファミリーの追加や変更、クラスタの追加や削除などのレプリケーショントポロジといったスキーマの変更を追跡しません。

テーブルで変更ストリームを有効にし、保持期間を 1～7 日間で指定します。

データ変更レコードの内容

データ変更レコードには、1 つの RPC 呼び出しの一部としてアトミックに適用された行の変更がすべて含まれます。

値が上書きされると、新しく書き込まれた値がデータ変更レコードに記録されます。データ変更レコードには古い値は含まれていません。

データ変更レコードは、変更を受信する最初のクラスタに変更が適用された時刻に、commit タイムスタンプというタイムスタンプを受信します。たとえば、2 つのクラスタを持つインスタンスについて考えてみましょう。クラスタ A のテーブル 1 に書き込みリクエストを送信すると、クラスタ A で書き込みを受信した際に、データ変更レコードの commit タイムスタンプが割り当てられます。この書き込みのため、クラスタ B のデータ変更レコードにも同じ commit タイムスタンプがあります。

各データ変更レコードには以下のものが含まれます。

エントリ - 行に加えられた変更。以下に示す対象の 1 つ以上が含まれます。
- 書き込み
  - 列ファミリー
  - 列修飾子
  - タイムスタンプ
  - 値
- セルの削除
  - 列ファミリー
  - 列修飾子
  - タイムスタンプの範囲
- 列ファミリーの削除
  - 列ファミリー
  - 行からの削除 - 行にデータのある列ファミリーごとに、行からの削除が列ファミリーからの削除リストに変換されます。
行キー - 変更された行の識別子
変更タイプ - ユーザー開始またはガベージコレクション
変更を受け取ったクラスタの ID
commit タイムスタンプ - 変更がテーブルに commit された時点のサーバー側の時間
タイブレーカー - ストリームを読み取るアプリケーションが、Bigtable の組み込みの競合解決ポリシーを使用できるようにする値。
トークン - ストリームが中断された場合に、使用側のアプリケーションがストリームを再開するために使用します。
低いウォーターマークの見積もり - レコードのパーティションがクラスタ全体のレプリケーションに追いついた後の推定時間。詳細については、パーティションとウォーターマークをご覧ください。

データ変更レコードのフィールドの詳細については、ReadChangeStream の API リファレンスをご覧ください。

変更ストリームのストレージ

テーブルとその変更ストリームは、ノードやストレージなど、同じクラスタレベルのリソースを共有します。そのため、変更ストリームのデータストレージはテーブルのストレージの一部になります。レプリケーションを使用するインスタンスでは、変更ストリームのデータのコピーが、変更ストリームが有効なテーブルを含むインスタンスのすべてのクラスタに保存されます。

変更ストリームデータに使用されるストレージは、ストレージの合計使用率（最大 %）にはカウントされません。その結果、変更ストリームデータが消費するストレージ量の増加に対応するためにノードを追加する必要はありません（ただし、コンピューティング能力を向上させるためにノードの追加が必要になる場合があります）。変更ストリームデータが使用するストレージは課金対象となります。詳しくは、費用に関する考慮事項をご覧ください。

変更ストリームの読み取り

変更ストリームを読み取り（ストリーミング）するには、単一クラスタのルーティング用に構成されたアプリケーションプロファイルを使用する必要があります。ルーティングポリシーの詳細については、アプリプロファイルの概要をご覧ください。

変更ストリームの読み取りのために渡すパラメータの詳細リストについては、ReadChangeStream をご覧ください。

変更ストリームメソッドは、Cloud Bigtable API（Data API）によって提供されます。クライアントライブラリやコネクタを使用せずに API を呼び出すのではなく、次のいずれかのオプションを使用することをおすすめします。これにより、分割とマージによるパーティションの変更を追跡して処理する必要がなくなります。

Dataflow テンプレート

Google 提供の Dataflow テンプレートを使用できます。

Bigtable Beam コネクタ

Bigtable Dataflow Beam コネクタを使用して、パイプラインを構築できます。

Bigtable Beam コネクタ

独自のパイプラインを構築しない場合は、コードの出発点として、Bigtable のチュートリアルまたはクイックスタートのコードサンプルを使用できます。

Java クライアントライブラリ

Java 用 Cloud Bigtable クライアント

パーティション

高い書き込み / 変更レートに適した高い読み取りスループットを維持するため、Bigtable では、変更ストリームを複数のパーティションに分割し、変更ストリームの並列読み取りを行うことができます。各変更ストリームパーティションはタブレットに関連付けられています。タブレットは、テーブルのリクエストワークロードのバランスをとるために、必要に応じて再配布されるテーブルのサブセクションです。詳細については、ロードバランシングをご覧ください。

Java クライアントライブラリを使用すると、各パーティションの変更を照会し、分割とマージによるパーティションの変更の管理に必要な情報を取得できます。

ウォーターマーク

ウォーターマークとは、すべてのクラスタでパーティションがレプリケーションに追いついた推定される時点の直近のタイムスタンプです。パーティションのウォーターマークは、レプリケーションが行われると継続的に更新され、時間とともに前に進みます。

各 ChangeStreamMutation（データ変更レコード）には estimatedLowWatermark フィールドがあり、これはデータ変更レコードに関連付けられたパーティションのウォーターマークです。この estimatedLowWatermark は推定値であり、ストリームにまだ到着していないデータがある可能性があります。

レプリケートされたテーブルのウォーターマーク

レプリケーションがパーティションに対して完全に追いついていない場合、パーティションの estimatedLowWatermark（低ウォーターマーク）は前に進みません。パーティションのウォーターマークが前に進んでいなければ、ストリーム全体の低ウォーターマーク（すべてのパーティションレベルの推定低ウォーターマークの中で最も低いもの）も進まなくなります。進まなくなったウォーターマークは停止しているとみなされます。その場合、パイプラインで変更ストリームをストリーミングすると、パイプラインが停止します。

1 つ以上のパーティションレベルのウォーターマークが一定の時間停止することがあります。その原因はさまざまですが、次のような要因が考えられます。

クラスタがトラフィックで過負荷状態になり、1 つ以上のパーティションでレプリケーションの処理速度が低下している
ネットワークの遅延
クラスタを利用できない

Bigtable Beam コネクタは、すべてのデータの出力タイムスタンプを 0 に設定することで、これを処理します。詳細については、イベント時間のないデータのグループ化をご覧ください。

モニタリング

変更ストリームを有効にすると、変更ストリームが有効に設定されたテーブルを含むインスタンスの CPU とストレージ使用率にどのような影響があるかを把握できるように、変更ストリーム固有の指標が 2 つ提供されます。これらの指標は、Bigtable のモニタリングページで確認できます。また、Cloud Monitoring の一連のツールを使用して確認することもできます。

変更ストリームレコードが使用するバイト数（change_stream_log_used_bytes）
変更ストリームごとの CPU 使用率（cpu_load_by_app_profile_by_method_by_table を使用）

これらの指標の詳細については、モニタリングをご覧ください。

費用に関する考慮事項

テーブルで変更ストリームを有効にすると、ノードとストレージの費用が増加します。特に、より多くのストレージ費用が発生する可能性があります。

ノード

通常、データ変更レコードの有効化と処理によって発生する追加のトラフィックを処理するには、クラスタにノードを追加する必要があります（自動スケーリングを使用している場合は最大ノード数を増やします）。

変更ストリームを有効にすると、処理を開始する前であっても、CPU 使用率が約 10% 増加する可能性があります。Dataflow パイプラインを使用して変更ストリームを読み取るなど、変更ストリームを処理すると、変更アクティビティのレベルとストリームデータの読み取り方法によっては、CPU 使用率が約 20～30% 増加する可能性があります。

ストレージ

テーブルのデータ変更レコードの保存に関する標準の Bigtable ストレージ料金が適用されます。また、変更ストリームのメタデータをトラッキングするために作成されたテーブルの保存も課金対象となります。保持期間はストレージ費用に直接影響します。

一般に、1 日分のデータ変更レコードには、その日に発生したミューテーションのみが反映されており、その日にディスクに書き込まれたデータが消費するストレージ容量の約 1.5 倍の容量を消費します。

ネットワークデータ転送

リージョン間で変更ストリームを読み取ると、そのトラフィックで費用が発生する可能性があります。ネットワークデータ転送率の一覧については、Bigtable の料金のネットワークセクションをご覧ください。

処理費用

データ変更レコードの読み取り方法によっては、Bigtable 以外のサービスで追加費用が発生する場合があります。たとえば、Dataflow を使用する場合は、処理されたバイト数とジョブを処理するワーカーマシンに対して課金されます。詳細については、Dataflow の料金をご覧ください。

行範囲の削除

可能であれば、変更ストリームが有効になっているテーブルから行範囲を削除しないでください。範囲を削除すると、Bigtable がオペレーションを完了するまでに時間がかかり、処理中に CPU 使用率が高くなる可能性があります。