Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説

Cloud Spannerは、リレーショナルデータベースの強整合性・SQL・トランザクションと、NoSQLのような水平スケールを一台で両立する、Google Cloudのフルマネージド分散データベースです。もとはGoogleが広告や決済といった社内の基幹システムを支えるために作った仕組みで、そのマネージド版が公開されました。「リレーショナルなのにグローバルにスケールする」という触れ込みは聞くものの、Cloud SQLやBigtableとの違い、そして自社の規模で本当に必要なのかで判断が止まる技術者は多いはずです。本記事は、外部整合性を支えるTrueTimeやPaxos同期レプリケーションの仕組み、スプリット単位の水平スケールと容量モデル、リージョナル／マルチリージョナルの可用性、GoogleSQLとPostgreSQL方言やエディション、Cloud SQL・Bigtableとの使い分け、ホットスポットを避ける主キー設計、そしてSpannerが見合う企業と別のデータベースが適する企業の条件までを、実装の解像度で整理します。

まとめ：Cloud Spannerの要点と採用判断を分ける軸

先に結論を置きます。Cloud Spannerは、リレーショナルデータベースの一貫性とNoSQLの水平スケールという、従来は二者択一だった性質を両立させたデータベースです。SQLでスキーマを定義し、複数行・複数テーブルにまたがるトランザクションを、地球規模に分散した環境でも強い整合性を保ったまま実行できます。核心にあるのが、GPSと原子時計を使った分散時計TrueTimeです。

混同されやすいCloud SQLとは、狙う規模が違います。Cloud SQLはMySQLやPostgreSQLをそのままマネージドで動かす縦スケール中心の選択肢で、単一リージョンの標準的な業務システムに向きます。対してSpannerは、単一サーバーの限界を超えて水平にスケールし、複数リージョンでも強整合を保ちたい場面のためのものです。両者は競合ではなく、規模と要件で棲み分けます。

採用判断の軸は明快です。「リレーショナルの整合性とトランザクションが要る」「かつ単一DBサーバーでは容量やスループットが頭打ちになる、またはグローバルに一貫した可用性が要る」——この二つが重なるほどSpannerの価値が出ます。逆に、データもトラフィックも中規模で単一リージョンで足りるならCloud SQLが、単一キーの超高スループットならBigtableが、その都度違う切り口の分析ならBigQueryが適します。まず「Cloud SQLで収まらない規模・整合性要件か」を先に問うのが、過剰なインフラ投資を避ける順序です。

Cloud Spannerの定義と分散リレーショナルがGoogleから生まれた背景

Spannerを理解する近道は、それが何のために作られたかから入ることです。もとは製品ではなく、Googleが社内で広告システム（AdWords）やGoogle Playを支えるために作った分散データベースでした。2012年に発表された論文が原型で、そのマネージド版が2017年にCloud Spannerとして一般提供されました。狙いは一貫していて、「リレーショナルの使い勝手を捨てずに、グローバル規模へスケールさせる」ことにあります。

リレーショナルの整合性とNoSQLの水平スケールを両立する位置づけ

データベースの分野では長く、強い整合性を持つリレーショナル（RDB）は縦にしかスケールしにくく、水平にスケールするNoSQLは整合性を緩める、というトレードオフが前提でした。Spannerはこの前提を崩し、SQL・スキーマ・二次インデックス・ACIDトランザクションといったRDBの機能を保ちながら、ノードを足して水平にスケールする設計を採ります。読者がまずつかむべきは、Spannerが「速いNoSQL」でも「大きなMySQL」でもなく、両者の良い部分を組み合わせるために別のアーキテクチャで作られた第三の選択肢だという点です。リレーショナルとNoSQLの一般的な選び分けはCloud Bigtableの仕組みと採用判断でワイドカラム型NoSQLの側から対比しており、Spannerはその反対側、強整合とSQLを守る側に立ちます。

TrueTimeと外部整合性がグローバルなトランザクション順序を作る仕組み

Spannerを他の分散DBと分ける核心が、TrueTimeという分散時計です。ふつうのシステムでは、離れたサーバー同士の時計は微妙にずれるため、「どちらの書き込みが先か」を全体で一意に決めるのが困難でした。TrueTimeは、各データセンターに置いたGPS受信機と原子時計を使い、時刻を単一の値ではなく「不確実性のある区間」（最も早い時刻と最も遅い時刻の幅）として返します。Spannerはトランザクションのコミット時に、この区間が確実に過ぎ去るまでごく短い時間だけ待つ（commit-wait）ことで、時計のずれを吸収します。結果として、地理的に分散したサーバーで並行して走るトランザクションでも、まるで一列に順番に実行したかのように振る舞う——これが外部整合性（external consistency）です。データベース理論でいう線形化可能性にあたり、分散環境でここまで強い保証を提供できる点がSpannerの技術的な支柱になっています。

Paxos同期レプリケーションとMVCCによるブロックしない一貫読み取り

整合性と可用性を同時に成り立たせるのが、レプリケーションと同時実行制御の仕組みです。データはスプリット（split）と呼ぶ範囲に分割され、各スプリットが複数のレプリカを持つPaxosグループを構成します。書き込みはリーダーレプリカが受け、過半数のレプリカへ同期的に複製できてはじめてコミットが確定する仕組みです。一部のレプリカやゾーンが落ちても、過半数が生きていれば処理を続けられるため、可用性が保たれます。読み取り側は多版型同時実行制御（MVCC）を採り、各データは複数のバージョンをタイムスタンプ付きで持ちます。これにより、読み取りは進行中の書き込みをブロックせず、逆に読み取りが書き込みを止めることもありません。過去の一貫した断面（スナップショット）に対する読み取りが、複数リージョンを跨いでも待たされずに走る——この非ブロッキングな一貫読み取りが、大規模なトランザクション処理を支えます。

Cloud Spannerの水平スケール・構成・SQL方言とエディション

採用を検討する段では「どこまで伸び、どんな構成が組め、既存資産をどう活かせるのか」が判断材料になります。仕組みと選択肢で押さえます。

コンピュートとストレージの分離とスプリットによる無停止の水平スケール

Spannerのスケーラビリティは、コンピュート層とストレージ層を切り離した構造に由来します。データの実体は分散ファイルシステムColossus上にあり、ノード自体はデータを持ちません。テーブルは負荷や容量に応じてスプリット単位へ自動で分割・再配置（リシャーディング）され、ノードはその処理を担当するだけです。ノードとデータが分かれているため、容量やスループットが足りなくなったらノードを追加するだけで、アプリを止めずに水平スケールできます。閑散期は逆にノードを減らせば費用を抑えられる構造です。コンピュート容量はノード（node）またはプロセッシングユニット（processing units）で表し、1ノードが1000プロセッシングユニットに相当する容量モデルです。100プロセッシングユニットの粒度で細かく増減できるため、小さく始めて需要に合わせて伸ばせます。オートスケーリングを設定すれば、この増減を負荷に追従させて自動化できます。

リージョナルとマルチリージョナル構成が決める可用性と整合性の関係

Spannerの可用性は、レプリカをどこに置くかで決まります。リージョナル構成は、単一リージョン内の複数ゾーンへレプリカを分散し、稼働率の目安は99.99%です。マルチリージョナル構成は、複数のリージョンへレプリカを配置し、一つのリージョン全体が落ちても運用を続けられます。稼働率の目安は99.999%（いわゆるファイブナイン）まで上がり、地理的に離れた利用者への低遅延と、リージョン障害への耐性を同時に得られます。ここで効くのが前述のTrueTimeで、複数リージョンに分散していても外部整合性が保たれるため、可用性を上げるために整合性を諦める必要がありません。この「グローバルに分散しても強整合を崩さない」点が、一般的なリードレプリカ構成や結果整合のマルチリージョンDBとSpannerを分ける決定的な差になります。どの構成を選ぶかは、許容できる停止時間と、利用者の地理的な広がりから逆算するのが実務の順序です。

GoogleSQL・PostgreSQL方言と3つのエディションの選び分け

既存資産の活かしやすさは、SQL方言とエディションで変わります。SpannerはGoogleSQLとPostgreSQL互換という二つのSQLインターフェースを備える構成です。前者はSpanner独自の方言でBigQueryやBigtableと同系、後者は既存のPostgreSQLの知識やツールを流用でき、移行の摩擦を下げます。エディションは2024年9月からの階層型課金で、Standard・Enterprise・Enterprise Plusの3層に整理されました。Standardは基本的なGA機能に加え、BigQueryへのreverse ETLやスケジュールバックアップなどをリージョナル構成で提供します。Enterpriseはこれを土台に、グラフ探索のSpanner Graph・全文検索・ベクトル検索といったマルチモデル機能を追加し、一つのSpannerでリレーショナルとグラフ、検索を扱えるようにします。Enterprise Plusは99.999%SLAと最高水準の性能・コンプライアンス対応を備えた最上位で、ミッションクリティカルな用途向けです。必要な機能と可用性の水準から、下位エディションで足りるかを見極めるのが費用配分の勘所になります。

Cloud SpannerとCloud SQL・Bigtableなど他DBとの使い分け

Spannerの採用で最も多い誤解が、Cloud SQLや他のマネージドDBとの混同です。役割の違いを具体で切り分けます。

Cloud SQLとの住み分けは規模と強整合・グローバル分散の要否

SpannerとCloud SQLは、どちらもSQLを話すリレーショナルDBですが、狙う規模が違います。Cloud SQLはMySQL・PostgreSQL・SQL Serverをマネージドで動かすサービスで、基本は単一サーバーを縦にスケール（CPUやメモリを増やす）させて使う形です。単一リージョンの標準的な業務システムやWebアプリなら、Cloud SQLの方が安く、運用も慣れた形で回せます。Spannerが要るのは、その縦スケールが頭打ちになる規模か、複数リージョンにまたがって強整合を保ちたい要件が出てきたときです。判断の目安はこうです。「単一のPostgreSQLインスタンスで捌き切れるか」がイエスならCloud SQL、書き込みスループットや容量が単一サーバーの限界を超える、あるいはグローバルに一貫したトランザクションが要るならSpanner、という順序で検討します。最初からSpannerを選ぶと、小規模では明らかに過剰投資になります。

Bigtable・Aurora・Cosmos DBとの比較で見るSpannerの立ち位置

マネージドDBは製品ごとに役割が分かれます。整理すると次の通りです。

同じGCP内では、単一キーで大量の読み書きをさばく用途はワイドカラム型NoSQLのCloud Bigtableの領分で、SQLや結合、複数行トランザクションが要るならSpannerに寄せます。他クラウドの近い製品としては、AWSのマネージドリレーショナルであるAmazon Auroraの仕組みと料金モデルが挙がりますが、Auroraが単一リージョンでの高性能なMySQL/PostgreSQL互換に主眼を置くのに対し、Spannerは複数リージョンでの強整合と無停止の水平スケールに踏み込む点で立ち位置が分かれます。この違いはグローバル分散と強整合をどこまで求めるかで決まる分岐点です。マルチクラウドで基盤を比較する際は、この軸で製品を選ぶのが実務の勘所になります。

Cloud Spannerの料金構造とスキーマ設計で失敗しない実装の勘所

Spannerの費用と運用の成否は、容量計画とスキーマ設計でほぼ決まります。ここは判断が分かれるので具体で示します。

コンピュート×時間×レプリカ＋ストレージの課金構造とエディション選択

Spannerの料金は、大きく三つの合算です。第一にコンピュート（ノード数、またはプロセッシングユニット数×時間単価×レプリカ数）、第二にストレージ量、第三にバックアップとネットワークです。時点の目安として、Standardエディションはコンピュートが100プロセッシングユニット・時・レプリカあたり数セント台からで、Enterprise、Enterprise Plusと上位ほど単価が上がります。ただし単価はリージョン・エディション・時期で改定されるため、金額は公式のSpanner pricingで確認してください（本記事では単価を断定しません）。費用計画の勘所は二つです。一つは、マルチリージョナル構成にするとレプリカ数が増える分だけコンピュートとストレージが増える点を織り込むこと。もう一つは、必要な機能から逆算してエディションを選ぶことで、グラフやベクトル検索を使わないならStandardで足り、上位エディションの費用を避けられます。トラフィックの波が大きいなら、オートスケーリングでプロセッシングユニットを需要に追従させ、ピーク固定の無駄を削るのが定石です。既存4096の機能記事では、Cloud SpannerとBigQueryを連携させたパフォーマンス面の作り込みを扱っており、運用に踏み込む段ではCloud Spannerのスピード・スケーラビリティ・BigQuery連携の詳細もあわせて参照できます。

ホットスポットを避ける主キー設計とインターリーブによる局所性

Spannerで最も多い失敗が、主キー設計に起因するホットスポットです。データは主キーの順序でスプリットに分割されるため、連番IDやタイムスタンプをそのまま主キーの先頭に置くと、書き込みが常に末尾の同じスプリット（＝同じノード）へ集中し、水平スケールの効果が出ません。これを避ける定石は次の通りです。

• 連番やタイムスタンプを主キーの先頭に単独で置かず、分散する値（ユーザーIDなど）を前方に組み合わせる
• 主キーにハッシュやUUIDを用い、書き込みを複数スプリットへ散らす
• タイムスタンプは必要ならビット反転などで単調増加を崩し、末尾集中を防ぐ
• 取得したいアクセスパターンから逆算して主キーを決める（先に検索方法を固定してからキーを設計する）

あわせて押さえたいのがインターリーブ（interleave）です。親テーブルと子テーブルを主キーで関連づけ、物理的に近い場所へ格納する仕組みで、親と子を一緒に読む処理の局所性が上がり、結合のコストを抑えられます。注文と注文明細のように必ずセットで扱うデータで効くのが利点です。設計時点の一手が、後々のレイテンシとノード費用に直結する点がSpanner運用の要になります。

Cloud Spannerを採用すべき企業と別のデータベースが適する企業の条件

ここは立場を明確にします。Spannerは強力ですが、万能ではありません。要件との相性で採否がはっきり分かれます。

Cloud Spannerの投資が見合うグローバル規模・強整合・水平スケールの要件

次の条件が重なるほど、Spannerの価値が出ます。

• リレーショナルの強整合・SQL・複数行トランザクションが要り、かつ単一DBサーバーの容量やスループットでは頭打ちになる
• 複数リージョンにまたがって、一貫したトランザクションと高い可用性（リージョン障害への耐性）を同時に求める
• トラフィックの成長やスパイクが読みにくく、無停止でスケールさせたい

この条件が揃う典型が、グローバルに展開する決済・金融・在庫・広告の基盤や、利用者が世界中に散らばる大規模SaaSのマルチテナントデータベースです。単一のRDBをシャーディング（手動でDBを分割）して無理に伸ばしてきた組織が、その運用負荷とデータ整合の難しさから解放される目的でSpannerへ寄せる、という移行も現実的な動機になります。GCPを軸にした大規模データ基盤の設計・実装・移行は、クラウドインフラ構築（AWS・Google Cloud・Azure）で対応しています。

Cloud Spannerを選ぶべきでない小規模・単一リージョン・単純KV・分析用途

逆に、次の場合はSpannerを選ぶべきではありません。第一に、データ量もトラフィックも中規模までで、単一リージョンで足りる構成です。Spannerは最小構成でも一定のコンピュート費用が常時かかり、この規模ではCloud SQLの方が安く、運用も慣れた形で軽く済みます。標準的な業務システムやWebアプリの多くはこちらに当てはまります。第二に、単一キーでの超高スループットな読み書きが主役で、SQLや結合を必要としない用途です。時系列やIoT、監視メトリクスのようなデータは、リレーショナルの機能を持つSpannerより、それに特化したBigtableの方が費用対効果で勝ります。第三に、その都度違う切り口で大量データを集計するアドホック分析です。これはBigQueryの領域で、SpannerでフルスキャンのOLAPを回すのは性能にも費用にも見合いません。まず要件を「強整合・グローバル分散・単一サーバー超えの規模」の物差しで測り、一つも当てはまらないなら、より軽いマネージドDBを先に検討する。この順序が過剰投資と設計のやり直しを防ぎます。

Cloud Spannerの仕組み・料金・使い分けについてのよくある質問

検討段階でよく挙がる質問をまとめます。概念と採用判断に絞って答えます。

Cloud SpannerとCloud SQLの違いは何ですか？

狙う規模が違います。Cloud SQLはMySQLやPostgreSQLを単一サーバーでマネージド運用する縦スケール中心のサービスで、単一リージョンの標準的な業務システムに向きます。Spannerはノードを足して水平にスケールし、複数リージョンでも強整合を保つ分散リレーショナルDBです。単一サーバーで捌けるならCloud SQL、その限界を超える規模やグローバルに一貫したトランザクションが要るならSpanner、という順序で選びます。小規模で最初からSpannerを選ぶと過剰投資になります。

Cloud SpannerはNoSQLですか、リレーショナルですか？

リレーショナルデータベースです。SQL・スキーマ・二次インデックス・複数行のACIDトランザクションを備えます。NoSQLと混同されがちなのは、水平スケールという従来リレーショナルが苦手だった性質を持つためですが、整合性やSQLを緩めているわけではありません。むしろ、RDBの整合性を保ったまま水平スケールを実現した点が特徴で、単一キー中心のワイドカラム型NoSQLであるBigtableとは種別が異なります。

TrueTimeとは何で、なぜ必要なのですか？

TrueTimeは、GPSと原子時計に基づく分散時計で、時刻を単一値ではなく不確実性のある区間として返すAPIです。分散したサーバー間では時計が微妙にずれるため、「どの書き込みが先か」を全体で一意に決めるのが難しいという問題があります。Spannerはコミット時にこの不確実性区間が過ぎるまでごく短く待つことで、地理的に離れたトランザクションでも一列に順序づけられた（外部整合性のある）振る舞いを保証します。これがグローバルな強整合を成り立たせる土台です。

Cloud Spannerの料金はどのように決まりますか？

コンピュート（ノードまたはプロセッシングユニット数×時間単価×レプリカ数）、ストレージ量、バックアップとネットワークの合算で決まります。マルチリージョナル構成はレプリカが増える分だけコンピュートとストレージが増えます。単価はリージョン・エディション（Standard／Enterprise／Enterprise Plus）・時期で変わるため、正確な金額は公式のSpanner pricingで確認してください。波のあるワークロードではオートスケーリングでプロセッシングユニットの無駄を抑えるのが定石です。

Cloud Spannerで既存のPostgreSQLアプリは動きますか？

PostgreSQL互換インターフェースが用意されており、既存のPostgreSQLの知識やツール、SQLをある程度流用して移行の摩擦を下げられます。ただしSpannerは分散DBという性質上、主キー設計やインターリーブといったSpanner固有の考え方が性能を左右するため、既存スキーマをそのまま載せれば十分に動くわけではありません。ホットスポットを避ける主キー設計を前提に、アクセスパターンから逆算した設計の見直しが移行の勘所になります。

関連記事

• Cloud Spannerが提供するスピード・スケーラビリティ・信頼性とBigQuery連携：本記事の定義を踏まえた、機能面とパフォーマンス・分析連携の深掘り
• Cloud Bigtableとは？GCPのワイドカラム型NoSQLの仕組みと採用判断：単一キーの超高スループット向けNoSQL。SQL・結合が要らない用途との使い分け
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル：他クラウドのマネージドRDBとの比較で見るSpannerの立ち位置