【実務・中級編】チェンジストリームの設計 – Cloud Spanner

Cloud Spanner Change Streams：銀の弾丸ではない「真のデータジャーニー」を設計せよ

Cloud SpannerのChange Streamsがリリースされて久しいが、現場のレビューをしていると、未だに「とりあえず有効化しておけば何とかなる」という甘い設計に出くわすことがある。

Change Streamsは強力だ。だが、安易な実装はSpannerの最強の武器である「水平スケーラビリティ」と「トランザクション整合性」を台無しにする可能性がある。今日は、私が大規模分散システムを構築する際に、どのような視点でChange Streamsを設計しているか、その「極限の知見」を共有する。

—

1. Change Streamsは「同期」ではなく「非同期のパイプライン」であると認識せよ

まず心に刻んでほしい。Change Streamsは、データベースの変更ログを外部へ運び出すための「非同期のストリーム」だ。これを「直前の処理と連動した同期的な更新」として設計してはならない。

データ変更をキャプチャし、Dataflowを介してBigQueryや外部キャッシュへ同期する場合、必ず「レイテンシ」が発生する。これを許容できないビジネスロジックをアプリケーション層に組み込んでしまうと、悲劇が始まる。

設計の鉄則：

冪等性（Idempotency）の担保: ストリームからのメッセージが二重配送される可能性を必ず考慮する。ダウンストリーム（受け取り側）の処理は必ず冪等にする必要がある。
順序保証の限界: 同じパーティション内では順序が保証されるが、異なるパーティション間での厳密な順序付けをロジックの前提にしてはならない。

2. パフォーマンスを殺さないための「フィルタリング戦略」

すべてのテーブル、すべてのカラムを無思考にモニタリングするのは、システムのCPUリソースをドブに捨てるようなものだ。

特に、更新頻度が極めて高い「カウンターテーブル」や「状態フラグ」をストリームに乗せてはいけない。SpannerのChange Streamsは非常に効率的だが、それでもシステム全体のスループットには影響する。

— 悪い設計例：全カラムをキャプチャし、Dataflowで不要なデータを捨てている
— これではDataflowのコストが無駄に嵩む

— 良い設計例：必要なカラムのみを明示的に指定し、抽出量を絞る
CREATE CHANGE STREAM UserProfileChanges
FOR UserProfiles(Name, Email) — 変更頻度の高い ‘LastLogin’ 等は除外
OPTIONS (
retention_period = ’24h’ — 復旧要件に応じて適切に設定する
);

設計の極意：

必要なデータだけを射影する: `FOR` 句でカラムを限定せよ。
Retention Periodの最適化: 長期間保持すればそれだけストレージコストが増える。データパイプラインが停止した際のリカバリ時間を考慮しつつ、最短で運用可能な期間を設計せよ。

3. 「データベースの設計変更」をストリームの設計と同期せよ

SpannerのChange Streamsの最大の罠は、スキーマ変更（DDL）との衝突だ。

テーブル定義を変更した際、チェンジストリームが拾うデータ型がアプリケーションの期待する形式と乖離することがある。特に、カラムの削除や型変更が発生した場合、Dataflow側の変換ロジックが即座にクラッシュする。

現場での防衛策：

スキーマレジストリの導入: 変更データをAvroやProtobuf形式でシリアライズし、スキーマ定義を別管理せよ。
デッドレターキュー（DLQ）の必須化: パイプラインで処理できなかった変更ログは、迷わずDLQへ送れ。再試行ロジックをパイプライン本体に詰め込むと、システム全体が詰まる（バックプレッシャー）。

4. 監視なきストリームは「時限爆弾」

Change Streamsの「ラグ（遅延）」を監視していないチームは、運用資格がないと断言する。

Cloud Monitoringで「`change_stream_data_lag_seconds`」を監視せよ。この値が右肩上がりになっているということは、あなたのデータパイプラインが「システムのボトルネック」になっていることを意味する。

運用チェックリスト：
1. 消費レートの監視: Dataflowの処理能力が、Spannerの書き込みスループットを上回っているか？
2. パーティション分割の確認: 変更が特定の範囲に集中していないか？（ホットスポットの検知）
3. データ欠損の警告: ストリームが予期せず停止した際のアラート設定は完備しているか？

—

結論：チェンジストリームは「システムの対話」である

Change Streamsは、Spannerという「静的なデータの砦」に「動的な命」を吹き込むものだ。

しかし、それは同時に、アプリケーションの責務を広げることを意味する。ストリームを設計する際は、「データが変更された瞬間」から「どこでどのように消費されるか」というデータの一生（データライフサイクル）を設計図に描き切ること。

コードレビューでこの設計が見えてこないなら、それはまだ設計が終わっていないということだ。

さあ、次は君の番だ。Spannerの可能性を最大限に引き出し、堅牢で美しいデータストリームを実装してくれ。質問があれば、いつでもコードを持ってきていい。