Spannerのユニークインデックス：分散トランザクションの「聖杯」と「呪い」
Cloud Spannerにおいて、`UNIQUE INDEX`は単なるデータ整合性の制約ではない。それは、分散システムにおける「一貫性」と「スループット」の果てしない綱引きの最前線である。
多くのエンジニアが「RDBMSと同じ感覚」でユニーク制約を貼るが、Spannerの分散アーキテクチャにおいて、それはアーキテクチャの根幹を揺るがすコストになり得る。今日は、カタログスペックの裏側にある、真のエンジニアだけが理解すべき「ユニークインデックスの深淵」について語ろう。
—
1. 分散環境における一意性保証のジレンマ
単一ノードのRDBMSであれば、インデックスはローカルメモリ上のB-tree操作で完結する。しかし、Spannerは異なる。
ユニークインデックスへの書き込みは、暗黙的に「書き込み時の読み取り（Read-before-write）」を強制する。新しい値がインデックス空間に存在しないことを確認するために、Spannerは以下のプロセスを分散トランザクションとして実行する。
1. インデックスキーの計算: 書き込まれる値からインデックスキーを生成。
2. Read Phase: 該当キー範囲を保持するSplit（スプリット）に対して「この値は存在しないか？」を確認するロックを取得。
3. Write Phase: 値が存在しないことが確定すれば、インデックスレコードを書き込む。
ここで重要なのは、「ユニークインデックスのデータは、ベーステーブルとは異なるSplitに配置される可能性が高い」という事実だ。これにより、単一の行更新が、ベーステーブルとインデックステーブルという「2つ以上の異なるノード間での分散トランザクション」へと昇華される。これが書き込みレイテンシの増大を招く真因である。
—
2. 内部メカニズム：Paxosとインデックスの再同期
Spannerのすべてのインデックスは、それ自体が独立したテーブルとして扱われる。
— ユニークインデックスの定義例
CREATE UNIQUE INDEX UsersByEmail ON Users(Email);
この定義により、`Users`テーブルの更新時、`UsersByEmail`インデックスも強整合性モデル（Paxosグループ）の下で更新される。もしユニークインデックスが多用され、かつホットスポットとなる値（例: 連番やタイムスタンプ）が含まれるとどうなるか？
- Paxosオーバーヘッド: インデックスの更新が発生するたびに、Paxosのログ複製と合意形成が必要になる。
- Contention（競合）: ユニークインデックスは「値の重複不可」を保証するために、特定のインデックスキーに対するロックを非常に厳格に管理する。高頻度な挿入が発生すると、ロック待機時間が指数関数的に増大する。
—
3. チーフアーキテクトからの警告：設計の最適化
大規模システムにおいて、ユニークインデックスを「思考停止」で貼るのは罪である。以下の観点で設計を再考せよ。
A. スパースインデックス（Sparse Indexing）の検討
不要なインデックスは悪だ。`WHERE`句でフィルタリングできるのであれば、インデックス自体を分割するか、そもそもユニーク制約をアプリケーション層（あるいは別の整合性チェックメカニズム）にオフロードすることを検討すべきだ。
B. インデックスキーの分散（Interleaving）
Spannerの真価は、テーブルのインターリーブ（親・子関係の物理的隣接）にある。しかし、ユニークインデックスは通常インターリーブできない。
もし、ユニーク制約が必要なカラムが特定のパーティションに依存しているなら、インデックスキー自体にそのパーティションキーを含めることで、ネットワークホップを最小化できる場合がある。
C. 「書き込み前チェック」の分離
どうしても高スループットが必要な場合、ユニークインデックスを諦め、以下のアプローチを取ることがある。
1. ブルームフィルタの活用: 非常に高速だが、厳密な一意性は保証できない（キャッシュ的利用）。
2. 分散ロックサービスの併用: Spannerの外側で一意性を管理する（複雑性が増すが、Spannerの負荷を下げられる）。
—
4. パフォーマンス測定の「罠」
`gcloud`やコンソールでレイテンシを見るだけでは不十分だ。Spannerの内部メトリクスにおいて注目すべきは以下の指標である。
- `spanner.googleapis.com/api/request_latencies`: 特に`Commit`リクエストのレイテンシ。
- `spanner.googleapis.com/lock/conflict_count`: ユニークインデックスへの書き込み競合が起きていないか、秒単位で監視せよ。
もしレイテンシが期待値を超えているなら、それはインデックスの制約によるロック待ちか、あるいは分散トランザクションによるネットワーク往復がボトルネックになっている。
—
結びに：エンジニアの誇りとして
Cloud Spannerは「魔法の箱」ではない。物理的なネットワーク遅延と、Paxosによる合意形成という「現実」の上に構築された精密機械だ。
ユニークインデックスは強力な武器だが、それを抜くときは、その一撃がシステム全体にどのような波紋（レイテンシの増大）を広げるかを計算しなければならない。「制約をどこで担保するか」、これこそが分散システム設計におけるアーキテクトの真の腕の見せ所だ。
君たちが設計するシステムが、論理的整合性と極限のパフォーマンスを両立することを期待している。コードを書く前にもう一度、そのインデックスが本当に不可欠なのか、自問自答してほしい。
コメント