分散DBの聖杯：Cloud Spannerがいかにして「妥協なきACID」を実装したか
多くの分散データベースが「CAP定理」という名の妥協を強いられる中、なぜCloud Spannerだけが、グローバルスケールでACID特性を完璧に維持できるのか。
「最終的な一貫性（Eventual Consistency）」という甘美な響きでスケーラビリティを確保したつもりになっている諸君へ。真のアーキテクトならば、Spannerの内部で行われている「物理的な時間の制約」と「分散合意アルゴリズム」の極限の融合を理解せねばならない。
今日は、Spannerの核である「TrueTime」と「Paxos」の深淵に触れる。
—
1. 原子性と永続性の基盤：Paxosによる多重化
Spannerの原子性（Atomicity）と永続性（Durability）は、単なるレプリケーションではない。各スプリット（データ分割単位）はPaxosグループとして管理される。
重要なのは、Spannerのログの書き込み手順だ。
1. リーダーが提案を各レプリカに送る。
2. 過半数（Quorum）の合意が得られた時点で、その変更は「永続化」されたとみなされる。
3. 障害発生時も、Paxosによる多数決が自動的に継続性を担保する。
ここで重要なのが、「Paxosは同期プロトコルである」という点だ。書き込みのレイテンシは、ネットワークの往復時間（RTT）に依存する。この物理的な制約をどう隠蔽し、可用性を保つか。これがSpannerのエンジニアリングの第一の戦場である。
—
2. 一貫性と分離の限界突破：TrueTime APIの秘密
分散システムにおける最大の敵は「時刻の不一致」だ。異なるノード間で順序をどう保証するか？ 多くのDBは論理クロックやベクトルクロックに逃げるが、Spannerは物理的な正確性を追求した。
TrueTime APIこそが、Spannerを他の分散DBと一線を画す存在にしている。
- 絶対時間の定義: GPS時計と原子時計を用いて、各ノードの時刻の不確実性（$\epsilon$）を常に計算している。
- コミット待機（Commit Wait）: トランザクションのコミット時に、システムは「現在の時刻 $t$ が、実際に発生した時刻の最大値よりも確実に後である」と断言できるまで、あえてコミットをブロックする。
— Spannerが内部で行っているコミットの概念的擬似コード
— コミットタイムスタンプ s を割り当てる際：
— s = max(s, current_time + uncertainty)
— この「不確実性分を待つ」という行為が、分散環境における外部整合性(External Consistency)を保証する
この「あえて待つ」という判断が、直列化可能性（Serializable）を担保する。ユーザーがクエリを投げた際、その結果が常に最新の「コミット済みデータ」であることを保証できるのは、このミリ秒単位の物理的な同期のおかげだ。
—
3. 分離レベル：スナップショット隔離と直列化可能性
Spannerは、読み取りに対してスナップショット隔離（Snapshot Isolation）をデフォルトで提供する。これにより、書き込みトランザクションが読み取りをブロックすることはない。
ここでアーキテクトが留意すべきは、「読み取り専用トランザクションのコスト」だ。
— 読み取り専用トランザクションの最適化例
— タイムスタンプを指定することで、Paxosの合意をスキップし、
— 各レプリカのローカルデータから読み取りが可能になる
SET TRANSACTION READ ONLY AS OF SYSTEM TIME ‘-10s’;
— これにより、レプリカの負荷分散と読み取りの高速化を両立する
「過去の特定の時点」を指定することで、分散合意の手間を省き、低レイテンシで整合性の取れたデータを取得する。この設計思想は、読み取りが頻発する大規模なサービスにおいて、システム全体のI/O負荷を劇的に軽減する。
—
4. アーキテクトへの提言：性能を最大化するために
Spannerを使いこなす者は、そのACIDの裏側にあるコストを理解している。
1. 書き込みの集中を避ける: Paxosグループのリーダーに負荷が集中するようなキー設計（単調増加するIDなど）は、物理的なボトルネックとなる。インターリーブやキーのハッシュ化を検討せよ。
2. 読み取りの最適化: 可能な限り `ReadOnly` トランザクションを活用せよ。最新性が厳密に不要な場面では、 `Exact Staleness` を許容することで、パフォーマンスは劇的に向上する。
3. ネットワークトポロジー: レプリカの配置は、Paxosのレイテンシに直結する。グローバル展開する場合、TrueTimeの不確実性が大きくなることを念頭に置き、リージョン選定を行う必要がある。
—
最後に：データベースは「物理」の投影である
Cloud Spannerは、分散システムにおける「魔法」ではない。むしろ、物理学とネットワークエンジニアリングの限界に真正面から挑んだ「力技」の結晶だ。
ACID特性を犠牲にすることなく、数千台のノードでデータベースを動かす。この難題を、TrueTimeという物理的基盤と、Paxosという数学的合意の組み合わせで解き明かした設計には、敬意を払わざるを得ない。
諸君、Spannerを触るということは、Googleのインフラエンジニアが戦ってきた「分散環境における時間と空間の歪み」との闘いに参加するということだ。その重みを知り、コードを書け。
コメント