【実務・中級編】 ACID特性の保証 – Cloud Spanner

Cloud SpannerのACID保証：分散データベースという「幻想」を現実に変えるエンジニアリング

世の中には「分散データベースは可用性と引き換えに整合性を捨てるものだ」という古い格言がある。だが、Cloud Spannerの登場によって、その常識は完全に過去の遺物となった。

多くのエンジニアが「Spannerは速い」とか「勝手にスケールする」という表面的な利点に目を奪われる。しかし、我々のようなアーキテクトがSpannerを愛するのは、「地球規模の分散環境で、なぜこれほどまでに堅牢なACID特性を両立できているのか」という、その狂気じみた設計の深淵にある。

今日は、SpannerのACID保証を単なる概念としてではなく、実務でどう「武器」にすべきか、その核心を紐解いていく。

—

1. 分散環境でのACID：Spannerが切り拓いた地平

分散システムにおいて、ACIDを保証する最大の敵は「時刻」と「通信遅延」だ。Spannerはこれを、物理インフラとプロトコルの融合で解決した。

Atomicity（原子性）: 複数のスプリット（データ分割単位）にまたがるトランザクションであっても、2フェーズコミット(2PC)とPaxosプロトコルを統合することで、「すべて成功か、すべて失敗か」を厳密に保証する。
Consistency（一貫性）: データベースの制約（外部キーやCheck制約）を分散環境下で維持する。これは、Spannerが単なるKVストアではなく、厳格なRDBであることを意味する。
Isolation（独立性）: TrueTime APIの採用。これがSpannerの心臓部だ。原子時計とGPS受信機を組み合わせることで、グローバルなデータに「確かなタイムスタンプ」を付与し、外部整合性（External Consistency）を保証する。
Durability（永続性）: Paxosによるレプリケーション。過半数のレプリカが書き込みを完了しなければトランザクションは確定しない。

—

2. 実務設計の指針：パフォーマンスを殺さないための「読み方」

ACIDを保証する仕組みは強力だが、当然ながら「コスト」が存在する。設計レビューで私が最も注意するのは、「トランザクションの肥大化」だ。

アンチパターン：長すぎるトランザクション

Spannerのトランザクション内で重い読み取りや外部API呼び出しを行えば、ロック時間が延び、排他制御によってスループットが劇的に低下する。

正しい設計パターン：
読み取りは「読み取り専用トランザクション（Stale Read）」を活用せよ。

— 5秒前までのデータを読み取ることで、ロックを回避し性能を最大化する
— 厳密な最新値が不要な分析や集計には、これを強制する設計を推奨する
SELECT FROM Users@{FORCE_INDEX=UsersByCreatedAt}
— 指定したタイムスタンプ時点の一貫したスナップショットを取得
— 読み取り専用トランザクションで実行することで、書き込み側を阻害しない
WHERE CreatedAt > ‘2023-10-01T00:00:00Z’

—

3. 堅牢な設計を支える「書き込み」の極意

Spannerの書き込みは、Paxosによる合意形成を待つ。そのため、「ホットスポット」を作らないことがエンジニアの腕の見せ所だ。

主キーの設計（ここが勝負所）

シーケンシャルなID（連番やタイムスタンプの先頭付与）は、特定のリージョン（スプリット）に書き込みを集中させ、Spannerの真価を殺す。

NG: `User_001`, `User_002`…（インデックスの末尾に負荷が集中）
GOOD: UUIDの利用、または主キーの先頭にハッシュ値を付与する手法。

— 推奨される主キー設計例：
— 負荷分散のために、論理的なIDの前にシャードキー（Hash値のモジュロなど）を付与する
CREATE TABLE Orders (
ShardId INT64, — 負荷分散用のハッシュ値
OrderId STRING(MAX),
Data JSON,
) PRIMARY KEY (ShardId, OrderId);

—

4. チーフアーキテクトからの提言

Spannerを扱う際、君たちが心に刻むべきことは以下の3点だ。

1. 「整合性はタダではない」: 必要のない場所で強整合性を求めるな。読み取り専用トランザクションとStale Readを使いこなすことが、システム全体のパフォーマンスを左右する。
2. 「ロック待ちを恐れるな、しかし管理せよ」: トランザクションは最小範囲で実行し、コミットまでを極限まで短くせよ。特にアプリ側のロジックがトランザクション内に混入しないよう徹底すること。
3. 「モニタリングは嘘をつかない」: Cloud Monitoringで「Lock Wait Time」や「CPU Utilization by Priority」を常に監視せよ。Spannerはボトルネックを可視化しやすい。そこから逃げるな。

最後に

Cloud Spannerは、エンジニアに「分散システムにおける整合性の悪夢」から解放してくれる魔法の杖ではない。それは、物理学と数学を用いて、エンジニアに「正しく設計する責任」を突きつける最強のツールだ。

ACID特性の保証という基盤があるからこそ、我々はビジネスロジックの複雑さに集中できる。その恩恵を最大限に引き出すのは、他でもない、君たちの設計だ。

次のレビューでは、君たちが書いた「美しく、かつ強固なトランザクション」を見せてもらうことを期待している。健闘を祈る。