Cloud Spannerの「オンラインスキーマ更新」を解剖する：分散合意とメタデータ同期の極致
Cloud Spannerにおける「オンラインスキーマ更新」は、単なる機能ではない。それは、分散システムにおける「カオスな並列性と厳密な整合性」を両立させるための、エンジニアリングの結晶だ。
多くのエンジニアは「`ALTER TABLE`がロックなしで通る魔法」と思っているかもしれないが、その裏側では、Spannerの核となるPaxosベースのメタデータ更新プロトコルが、数千のノード間で極めて緻密な調和を保っている。
今日は、その深淵を覗こう。
—
1. スキーマ更新の真実：Spannerが「停止」しない理由
RDBMSにおいてスキーマ変更がなぜ重いのか。それは、カタログ情報の更新とデータ構造の再構築を「単一のトランザクション」として同期的にロックするからだ。
Spannerはこれを、「Spanner Schema Change Protocol」とでも呼ぶべき独自の非同期合意メカニズムで解決している。
- 非ブロッキングの設計: スキーマ変更の実行中、アプリケーションの読み書きトランザクションは停止されない。
- タイムスタンプベースのバージョン管理: 全ノードが「どのバージョンのスキーマを使用して、どのトランザクションを処理すべきか」という定義を、Paxosの合意形成を経て保持している。
内部メカニズムの核心
スキーマ変更が発行されると、SpannerのPlacement Driver (PD) が主導権を握る。これは単なるメタデータの更新ではなく、「全スプリット（データ分割単位）に対するスキーマバージョンの伝搬」という分散タスクだ。
1. Preparation Phase: 新しいスキーマ定義がPaxosで複製され、全ノードで「将来のスキーマ」として認識される。
2. Backfill Phase: インデックス追加など、既存データとの整合性が必要な場合、バックグラウンドで分散処理が走る。この際、CPUやIOを叩きすぎないよう、システムは適宜スロットリングを行う。
3. Commit Phase: 全ノードが新しいスキーマを適用可能な状態になったことを確認し、グローバルにスイッチする。
2. メモリとクエリ最適化：インデックス変更の代償
インデックスを追加する際、開発者が最も懸念すべきは「CPU/IO負荷」ではなく、「クエリ実行プランの再構築コスト」だ。
Spannerのクエリエンジンは、カタログが更新されると、即座に既存の実行プランを無効化（Invalidate）する。インデックスが追加されると、次回のクエリ発行時にオプティマイザが「より効率的なインデックス」を探し出し、実行プランを再生成する。
— インデックス追加時の注意点：
— 大規模テーブルに対してインデックスを追加する場合、
— 内部的に ‘Backfill’ が発生し、バックグラウンドでフルスキャンが走る。
CREATE INDEX UsersByEmail ON Users(Email) STORING (DisplayName);
【極限の知見】:
インデックス追加時のバックフィルは、データのサイズが数テラバイトを超えると、それ自体がメモリ上の統計情報（Histogram）を一時的に書き換える可能性がある。頻繁なインデックスの追加・削除は、クエリ実行計画を不安定にさせ、「予測不能なレイテンシの揺らぎ」を引き起こす。スキーマ変更は、単なる「構造の変更」ではなく、「クエリの最適化戦略の再定義」であると認識せよ。
3. なぜ「制限」が存在するのか？
ドキュメントにある「制限事項」は、単なる仕様ではない。それは物理法則との妥協だ。
- 一度に複数の変更: Spannerは一度の `ALTER` 文で複数の変更を許容するが、それらを一つのトランザクションとして安全にコミットするための複雑さが、システム全体の負荷を高める。
- バックフィルの副作用: インデックス追加中の書き込み負荷が高いテーブルでは、トランザクションの競合が発生しやすくなる。これは、バックフィルによる内部的なIOリソース消費が、Paxosの投票（Voting）の遅延を招く場合があるからだ。
4. アーキテクトとしてのアドバイス：真の運用戦略
Spannerでのスキーマ設計は、「やり直しが効くから適当でいい」という甘えを許さない。
1. インデックスの追加は「トラフィックの谷間」を狙う:
バックフィル中のI/O負荷を考慮し、アプリケーションのピーク時を避けるのは基本中の基本だ。
2. `STORING`句の過度な利用を避ける:
`STORING`はクエリの高速化に寄与するが、テーブルの再構築コストを増大させる。将来を見越した設計が必要だ。
3. オンラインでの型変更には細心の注意を:
例えば `STRING` から `INT64` への型変換は、実際には「カラムの作成・データ変換・古いカラムの削除」という多段階のプロセスを踏む必要がある。これを一気にやろうとせず、アプリ層での二重書き込み（Dual Write）と段階的なマイグレーションを組み合わせることが、大規模システムにおける唯一の「生存戦略」だ。
—
結び
Cloud Spannerのオンラインスキーマ更新は、「止まらないこと」への執念が実装されたものだ。しかし、この裏側に隠された「分散合意の重み」を理解せずして、真にスケーラブルな設計はできない。
技術は常に進化するが、分散システムにおける「データ整合性と可用性のトレードオフ」という本質は変わらない。Spannerを使いこなすということは、この本質を制御下に置くということと同義である。
諸君、Spannerの深淵を楽しみたまえ。それができるのは、我々エンジニアだけなのだから。
コメント