【実務・中級編】オンラインスキーマ更新 – Cloud Spanner

Cloud Spannerのオンラインスキーマ更新：その「魔法」と「代償」を正しく理解する

Cloud Spannerを触るエンジニアが最初に驚くのは、「巨大なトラフィックを捌きながら、無停止でスキーマを変更できる」という事実だろう。従来のRDBMSで深夜のメンテナンス枠を確保し、テーブルロックの恐怖と戦いながら`ALTER TABLE`を打っていた日々を思えば、これは魔法に近い。

だが、この魔法の裏側には、分散データベース特有の制約と「痛み」がある。今日は、Spannerのオンラインスキーマ更新におけるアーキテクチャの真実を、実戦的な観点から解剖する。

—

1. スキーマ更新の「魔法」の正体：Paxosとバージョン管理

Spannerのスキーマ更新が停止不要なのは、スキーマがデータの一部として「バージョン管理」されているからだ。

Spannerは、すべてのノードで一斉にスキーマを切り替えるような乱暴なことはしない。各ノードは、自分自身が認識しているスキーマバージョンを使ってトランザクションを処理する。新しいスキーマへの移行は、バックグラウンドで各スプリット（データの断片）が非同期に新しいバージョンへ追従していくことで行われる。

この設計により、読み取り・書き込みを遮断することなく、徐々に（かつ一貫性を保ちながら）スキーマの変更が浸透していく。これが、無停止更新の原理だ。

—

2. 実務上の「罠」：バックフィル処理のコスト

「無停止だから安全」と考えるのは早計だ。特に危険なのは、「既存データに対するインデックスのバックフィル（埋め込み）処理」である。

新しいインデックスを追加すると、Spannerは裏で既存の全データに対してインデックスエントリを作成するタスクを走らせる。

パフォーマンスへの影響: このプロセスはSpannerの内部リソースを消費する。急激にインデックスを大量追加すれば、CPU使用率がスパイクし、ユーザーリクエストのレイテンシに悪影響を及ぼす可能性がある。
堅牢な設計: 大規模なテーブルに対して複数のインデックスを一度に追加するのは避けるべきだ。影響を最小限にするには、「オフピーク時の実施」はもちろん、「インデックス追加のバッチ処理」を意識し、負荷状況を見ながら段階的に適用する戦略が求められる。

— テーブルにインデックスを追加する際は、そのコストを常に意識せよ
CREATE INDEX UsersByEmail ON Users(Email) STORING (DisplayName);

— 成功しても、裏では巨大なデータセットに対するバックフィルが走っている
— 実行直後のCPUメトリクスを監視するのは、エンジニアの「義務」である

—

3. 「オンライン」が許さない制約

オンライン更新は万能ではない。特に「既存カラムの型変更」は、多くのケースで`ALTER`一発では解決できない。

例えば、`INT64`から`STRING`へ型を変更したい場合、Spannerは直接的な型変換を許容しないことが多い。この場合、以下の設計パターンが推奨される。

1. カラムの追加: `New_Column`を追加する。
2. ダブル書き込み（Double Write）: アプリケーション側で`Old_Column`と`New_Column`の両方に書き込む。
3. データ移行: 既存データをバッチで`New_Column`にコピーする。
4. 切り替え: アプリケーションの参照先を`New_Column`に切り替える。
5. 削除: 不要になった`Old_Column`を削除する。

この「サーキットブレーカー」のようなアプローチこそ、大規模システムで安全にスキーマを進化させるための定石だ。

—

4. 現場で「死なない」ための3つの鉄則

最後に、私がコードレビューで必ず指摘する3つのポイントを授ける。

① スキーマ更新をアプリケーションと分断するな

スキーマ更新とアプリケーションコードのデプロイは、密結合であるべきだ。新しいインデックスを前提としたクエリを、インデックスが有効化される前にデプロイしてはならない。Spannerのスキーマ更新完了を検知するまで、クエリを走らせないような制御（あるいは冪等なデプロイパイプライン）を構築すること。

② 削除・変更は「論理的」に考えよ

`DROP COLUMN`や`DROP INDEX`は一瞬で終わるが、一度消すと戻せない。特にインデックスの削除は、特定のクエリが急激にタイムアウトを引き起こすリスクがある。削除前に、Query Statistics（クエリ統計）を見て、そのインデックスを使用しているクエリが他に存在しないかを徹底的に調査せよ。

③ インデックスの「STORING」を過信するな

`STORING`句は便利だが、インデックスサイズを肥大化させる。不要なカラムをすべてインデックスに詰め込むと、書き込み時のコスト（インデックス維持コスト）が無視できなくなる。インデックスは「検索性能」と「書き込み負荷」のトレードオフだ。

—

結論：Spannerは「生き物」である

Cloud Spannerのスキーマ管理は、データベースを「静的な箱」から「進化し続けるシステム」へと変貌させた。しかし、その進化を支えるのは、「背後で何が起きているか」を論理的に推論できるエンジニアの洞察力だ。

「無停止だから何をやってもいい」という怠慢を捨て、Paxosの仕組みとリソース消費を想像しながらスキーマを定義せよ。そうすれば、あなたのシステムは、数年後も美しく、かつ強固な姿を保ち続けているはずだ。

次は、[Query Optimizerの癖とインデックス戦略]について語ることにしよう。準備はいいか？