この記事は 3-shake Advent Calendar 2025 (5日目) の投稿です．
はじめに
Cloud Spanner の内部アーキテクチャ (シャーディングやタイムスタンプなど) を深掘りする記事を書いており，職場の Tech Blog にて近日中の公開を予定しています．(記事リンクは後日追記します)
この過程で Google Cloud の DB サービスを改めて見渡してみて，ハイエンドな選択肢として AlloyDB for PostgreSQL と Cloud Spanner の双璧について考えさせられました．どちらも高い可用性と性能を誇る一方で設計思想は対照的です．特に「書き込み性能をどう拡張するか」というアプローチにおいて，両者は決定的に異なる道を歩んでいます．
この記事では「スケーラビリティの境界」について，これらをアーキテクチャの観点から整理します．
AlloyDB：単一ライター構成でベストを尽くす
AlloyDB は，PostgreSQL 完全互換でありながら，ストレージ層とコンピュート層を分離し，ログ処理 (WAL) をオフロードすることで大幅な高速化を実現しています．クラスタを構成することで，リードレプリカの増設による「読み取り」の水平スケールが可能で，大規模な参照負荷にも柔軟に対応できます．
ただし「書き込み」については，Amazon Aurora などと同様に，プライマリインスタンスが一手に引き受ける単一ライター構成を取ります．インスタンスのリソースを垂直方向に最大まで拡張したり，AlloyDB 独自の最適化エンジンを駆使したりしても，あくまで書き込み性能の上限は，単一のプライマリインスタンスにおける CPU やメモリリソースに依存します．
このように「読み取りはスケールアウト」して「書き込みはスケールアップ」するアーキテクチャには，後述する Spanner のような分散システムに対して明確な強みもあります．コミット時に複数ノード間の分散合意プロセスを経る必要がないため，ネットワークホップが小さく，単発のクエリレイテンシにおいては有利になるケースが多いです．
Cloud Spanner：単一ノードの物理的な制約を超える
Cloud Spanner は，読み書きのスケールアウト (水平分散) に徹底しています．テーブルデータは，主キーの範囲に基づいて自動的に分割 (シャーディング) され，数千台規模の物理サーバに分散配置されます．書き込み負荷が増大した場合でもノードを追加すれば，データは自動的に再配置されて負荷を分散します．
ゆえに，適切なキー設計で負荷を均等に分散できれば，書き込みスループットに理論上の上限が存在しません．AlloyDB が「データの地理的な配置を局所化してレイテンシを極小化する」設計だとすれば，Spanner は「データの広域分散で並列度を高めてスループットを青天井にスケールする」設計です．
ただし，離れたノード間で整合性を保つため，書き込み時には必然的に分散合意アルゴリズムやネットワーク通信のオーバーヘッドが発生します．単発のレイテンシに目を瞑る代わりに青天井のスループットを得るのが，Spanner の構造的な特性です．
どちらを選択すべきか
これらの特性を踏まえると，選定基準は「書き込みのスケール」という境界線で明確です．
AlloyDB が適した領域
- PostgreSQL のエコシステムをそのまま活用したい
- 単発のクエリに対するレイテンシを最重視したい (分散合意に伴うオーバーヘッドを避ける)
- 最大スペックの単一ノードで書き込み負荷を捌ける (大半のユースケースはここに収まります)
Cloud Spanner が適した領域
- 単発のレイテンシよりも圧倒的なスループット (処理量) が求められる
- 書き込みリクエストが単一ノードの限界 (秒間数万〜数百万オーダー) に達する可能性がある
- グローバル規模での可用性が求められる (特定のゾーンやリージョンの障害時でも書き込みを継続)
整合性を保つには (予告)
両者のコミットにおける整合性について考えてみましょう．AlloyDB のような単一ライター構成であれば，整合性を保つのは (相対的に) 容易です．順序を管理するプライマリが一つしか存在しないからです．
その一方で，Spanner のように (特にマルチリージョン構成において) 書き込みを行うノードが世界中に点在する場合は，システム全体で「どちらの書き込みが先だったか」という順序をどうやって厳密に保証するのでしょうか？ ここで，分散システムにおける「CAP 定理」の壁が立ちはだかりますが，Spanner はハードウェア投資とアルゴリズムによって，この制約を技術的に克服しています．
なぜ Spanner は分散システムでありながら RDB のように振る舞えるのか．Spanner の「分散環境での整合性担保」という困難な課題へのアプローチに興味があれば，後日の解説記事もぜひご覧ください．
まとめ
単一ライター構成のポテンシャルを引き出そうとする AlloyDB と，分散システムとして単一ノードのリソース制約を突破しようとする Spanner は，どちらが優れているという問題ではなく，それぞれの設計とワークロードの特性 (レイテンシかスループットか) を照らし合わせながら使い分けるべきでしょう．
参考文献
- AlloyDB overview - Google Cloud Documentation.
- What is Cloud Spanner? - Google Cloud Blog.