Cloud Spanner：分散データベースの「常識」を破壊する、エンジニアのための最終回答
多くのエンジニアが「RDBの拡張性」と「分散システムの整合性」の間で苦悩してきた歴史は、Cloud Spannerの登場によって幕を閉じた。
「水平スケーラビリティ」と「強整合性（ACID）」を両立させる。これは従来のデータベース設計の文脈では禁じ手とされてきた。しかし、GoogleはこれをTrueTimeという時刻同期技術を核にしたインフラで解決した。
本稿では、教科書的な説明は割愛する。現場でSpannerを使い倒すために知っておくべき、設計の「急所」を語る。
—
1. 「Split」を制する者がSpannerを制する
Spannerの真髄は、データを物理的に分割する「Split」にある。運用で最も頻発するパフォーマンス低下の原因は、このSplitの不均衡だ。
ホットスポットを回避する設計
Spannerは主キーの昇順（タイムスタンプなど）でデータを並べるため、単調増加するキーを主キーに設定すると、特定のノードに書き込みが集中する「ホットスポット」が発生する。
【アンチパターン】
— ユーザーIDが単調増加する場合、全ての書き込みが最後のノードに集中する
CREATE TABLE Users (
UserId INT64 NOT NULL,
…
) PRIMARY KEY (UserId);
【プロの設計】
UUID v4を採用するか、キーの先頭にハッシュ値を付与して書き込みを分散させる。
— UUIDまたはハッシュ付与により、Split境界をまたいで書き込みを分散させる
CREATE TABLE Users (
UserId STRING(36) NOT NULL, — UUIDの使用を推奨
…
) PRIMARY KEY (UserId);
※補足：もしUUIDの衝突が気になるなら、`BIT_REVERSE`関数を使用してキーを分散させる工夫も検討すべきだ。
—
2. 読み取りの哲学：Stale Readを恐れるな
Spannerのデフォルトである強整合性（Strong Read）は強力だが、コストとレイテンシを伴う。Webアプリケーションのアーキテクチャ設計において、「全読み取りを強整合性にする必要はあるか？」と常に自問せよ。
- Strong Read: 最新データを保証するが、リーダーノードとの通信が発生する。
- Stale Read: 指定した時間分だけ過去のデータを読む。リーダーノードへの問い合わせが不要な場合が多く、劇的に速い。
例えば、ユーザーのプロフィール表示など、数秒前のデータでも許容できる画面には `read_timestamp` を指定したStale Readを適用する。これだけで、システムのピークタイムの負荷を大幅に削減できる。
—
3. トランザクションの「行儀」
Spannerのトランザクションは、ロック競合が起きると即座にアボートする。アプリケーション側でリトライ処理を書くのは当然だが、「トランザクションを短く保つ」ための設計が不可欠だ。
ロック範囲を最小化する
不要な読み取りをトランザクション内で行うと、ロック期間が伸び、システム全体のTPSを低下させる。
// 良い例：書き込み前に必要な読み取りだけを行い、処理を完結させる
_, err := client.ReadWriteTransaction(ctx, func(ctx context.Context, txn spanner.ReadWriteTransaction) error {
// 読み取り（最小限）
row, _ := txn.ReadRow(…)
// 更新
m := spanner.Update(…)
return txn.BufferWrite([]spanner.Mutation{m})
})
もし、トランザクションが頻繁にリトライ（Aborted）されるなら、それはコードのバグではなく「設計の怠慢」だ。
—
4. 運用上の「やってはいけない」リスト
1. 過剰なインデックス: インデックスは書き込み性能を直撃する。不要なインデックスは削除し、必要なものだけを厳選せよ。
2. 巨大なトランザクション: 1トランザクションで数千行の更新を行おうとするな。分割してバッチ処理せよ。
3. モニタリングの軽視: `Cloud Monitoring`で`CPU Utilization`だけでなく、`High Priority Latency`と`Lock Stats`を常に監視せよ。特にLock Statsを見れば、どのクエリが競合の原因になっているか一目瞭然だ。
—
最後に：Spannerは「銀の弾丸」か？
Spannerは最強のデータベースだが、万能ではない。複雑な結合が必要な分析クエリを無理やりSpannerで回すのではなく、BigQueryへのエクスポート（Dataflowを使用）を組み合わせるのが、Google Cloudにおける「正解」の構成だ。
データベースは、単なるデータの箱ではない。ビジネスの成長を支える骨格だ。Spannerのアーキテクチャを理解し、その特性に寄り添った設計を行うこと。それが、エンジニアとしての格を一段引き上げる。
さあ、設計を見直そう。あなたのシステムは、もっと速く、もっと強くなれる。
コメント