Cloud Spanner Change Streams: 分散DBの「不可逆な時間軸」をいかに制御するか
Cloud SpannerのChange Streamsは、単なる「CDC（Change Data Capture）の機能」と片付けるにはあまりに惜しい。これは、Spannerの真髄である「TrueTimeによる外部整合性」を、いかにして非同期の外部世界へ流し込むかという、分散システムにおける「因果律の転送」そのものだ。
アーキテクトとして、この機能をどう設計し、実装すべきか。表面的な仕様ではなく、その深淵にあるメカニズムと、エンジニアが直面する現実的な限界について語ろう。
—
1. 物理的実態：Change Streamsは「ログの投影」である
多くのエンジニアが誤解しているが、Change Streamsはトリガーのような実行時フックではない。Spannerの内部ログ（Commit Log）に対する、非同期の読み取り専用レプリカに近い実装だ。
Spannerは、すべてのトランザクションをPaxosグループ単位でシーケンシャルにコミットする。Change Streamsは、このPaxosのログストリームを専用のバックグラウンドプロセスでキャプチャし、構成された保持期間（デフォルト1日〜最大7日）の間、内部的なストレージ領域にメタデータとして保持する。
アーキテクトの視点：なぜ「パフォーマンス劣化」が起きないのか
Change Streamsが既存のワークロードに極めて低いオーバーヘッドしか与えないのは、これが「インプロセスでの同期実行」を一切行わないからだ。 ログのキャプチャは、Paxosのリーダーが書き込みを完了させた後、非同期的にストリームへとマージされる。したがって、書き込みのレイテンシを悪化させるのは、ストリームそのものではなく、その先の「読み取り処理」の設計ミスである。
—
2. 消費側の設計：Dataflowをどうチューニングするか
Change Streamsのデータを読み取る際の「極限の最適化」において重要なのは、「Partitionの動的再構成」の概念だ。
Dataflowの`ReadChangeStream`コネクタを使用する場合、Spannerは内部的に変更ログを複数のパーティションに分割して提供する。ここで重要なのは、「スループットを上げたいときにどうスケールさせるか」だ。
メモリと並列度の黄金律
// Dataflowパイプラインでの最適化の要諦
PCollection
SpannerIO.readChangeStream()
.withInstanceId(instanceId)
.withDatabaseId(dbId)
.withChangeStreamName(streamName)
// ここで重要なのは、パーティションの動的再割り当てを阻害しない設定
.withMetadataInstance(instanceId)
.withMetadataDatabase(dbId)
);
多くのアーキテクトが陥る罠は、過度なバッファリングだ。Change Streamsは順序保証が厳格だが、Dataflowのワーカー間で負荷が偏った場合、特定のシャードに偏ったデータ流入がボトルネックとなる。「データの一様性（Uniformity）」を維持するキー設計が、Spanner側のスキーマ設計と密結合していることを忘れてはならない。
—
3. 「時間」という概念の取り扱い：TrueTimeとの共存
SpannerのChange Streamsが他のDBのCDCと決定的に異なるのは、出力されるレコードに`commit_timestamp`が含まれる点だ。これはTrueTimeの恩恵を受けており、グローバルに順序付けられたタイムスタンプである。
陥りがちなアンチパターン：
- イベントの重複処理: ネットワーク分断やDataflowのワーカー再起動により、同じタイムスタンプのレコードが再送される可能性がある。これに対処するために、必ずべき等（Idempotent）なシンク処理を実装すること。
- 外部システムとの時刻同期: 外部システム側で、Spannerのタイムスタンプをそのまま「信頼できる時刻」として利用してはならない。あくまで順序のためのインデックスとして扱い、外部システム側で独自のウォーターマークを管理する「二段構えの防壁」が、大規模システムの鉄則である。
—
4. 運用上の極限：ストレージコストと保持期間のジレンマ
Change Streamsを有効にすると、その分のデータ保持コストが発生する。これは「データの実体」ではなく「変更差分」を保持するストレージだが、書き込み頻度が高いテーブルでは、保持期間が長くなるほどバックグラウンドのストレージ使用率を押し上げる。
チーフアーキテクトの知見：
不要なカラムの追跡は即座に停止せよ。SpannerのChange Streamsは、特定の列のみを追跡する設定が可能だ。すべての変更を追跡するのではなく、業務上必要な「状態遷移のトリガー」のみを抽出するフィルタリングを徹底すること。これにより、ストレージコストだけでなく、Dataflow側の処理負荷も指数関数的に削減できる。
—
結びに：分散システムの「一貫性」をどこで担保するか
Change Streamsは、Spannerという最強の「整合性ある閉じた世界」から、外部の「非同期なカオス」への橋渡しだ。
この橋を渡る際、「分散システムには完璧な同期など存在しない」という現実を直視しなければならない。Change Streamsの先にあるのは、必ずしもリアルタイムではない。それは「確定した過去」の順序だ。
この順序性を、いかにビジネスロジックへと昇華させるか。それが、君たちアーキテクトに課せられた、唯一にして最大の問いである。
設計に妥協するな。Spannerのログは、嘘をつかない。
コメント