MENU

Cloud Spanner — グローバル分散RDBMS

Cloud Spanner アイキャッチ
Cloud Spanner

Cloud SpannerはGoogleが2017年5月に一般提供を開始した、グローバル分散型のリレーショナルデータベースサービスである。源流は2012年のSpanner論文で示されたGoogle社内の分散DBで、AdWordsの広告基盤を支える役割を担っていた。リージョンをまたいで強整合(serializable)トランザクションを成立させるために、「TrueTime」と呼ばれる原子時計とGPSを組み合わせた時刻同期APIを基盤に持つことで知られる。本記事ではSpannerの内部技術、運用モデル、そしてBigQueryやFirestoreとの位置取りを整理する。

目次

この記事の目次

  1. TrueTimeが支える強整合トランザクション
  2. ノードからProcessing Unitへの単位刷新
  3. PostgreSQL互換でアクセスの間口を広げる
  4. BigQuery・Firestoreとの使い分け
  5. まとめ

TrueTimeが支える強整合トランザクション

TrueTimeが支える強整合トランザクション

Spannerが他のグローバルDBと一線を画す理由は、Google独自の時刻APIである「TrueTime」にある。TrueTimeは各データセンタに配置された原子時計とGPS受信機から、誤差の上限を保証した「区間としての時刻」を提供する。これにより複数リージョンに分散したノード間で、コミット時刻の前後関係を厳密に判断でき、serializable(直列化可能)なトランザクションを地球規模で実現している。

データはPaxosプロトコルでリージョン間に複製され、行レンジは負荷に応じて自動的にSplitされて再配置される。障害発生時もリーダー再選出が高速で、可用性99.999%という極めて高いSLAを謳う構成が可能だ。従来「グローバル分散かつ強整合かつリレーショナル」は両立しないとされてきたCAPの常識を、エンジニアリングで押し切った稀有な事例として知られている。

ノードからProcessing Unitへの単位刷新

ノードからProcessing Unitへの単位刷新

登場初期のSpannerは「ノード」という単位でリソースを確保し、1ノードでも比較的高額だったため、大企業向けという印象が強かった。近年は「Processing Unit(PU)」という小さな単位が導入され、100PU(1ノードの1/10)から契約できるようになり、スタートアップや中規模サービスでも採用しやすくなっている。PU数をオンラインで増減できるため、トラフィックの増減に追随したスケールが可能だ。

ストレージは別建てで、利用したGiB-month単位で課金される。リードレプリカやリージョン構成は「リージョナル」「デュアルリージョナル」「マルチリージョナル」から選択でき、用途に応じて整合性と地理分散のバランスを取れる。「アジア・北米・欧州にまたがるサービスで、どこからアクセスしても同じデータが見える」という要件は、Spannerの最も得意とする領域である。

PostgreSQL互換でアクセスの間口を広げる

PostgreSQL互換でアクセスの間口を広げる

Spannerは元々独自の「Google SQL方言」を提供していたが、近年はPostgreSQL互換のSQL方言にも対応し、移行や標準化の選択肢が広がった。PostgreSQLクライアントツールやORMから、ほぼ修正なしでSpannerを叩けるようになり、「PostgreSQLの皮を被ったグローバル分散RDB」として採用しやすくなっている。管理UIである「Spanner Studio」もブラウザからクエリやスキーマ管理ができ、開発者体験は年々向上している。

バックアップやポイントインタイムリカバリ、変更イベントを抽出する「Change Streams」など、エンタープライズ運用に必要な機能も整いつつある。Change StreamsはDataflowやPub/Subと組み合わせてイベント駆動アーキテクチャの起点にもでき、トランザクショナルDBとイベントストアの境界を曖昧にする使い方も増えている。決して安価なサービスではないが、「グローバル一貫性が必須」というシナリオでは他に代えがたい存在だ。

BigQuery・Firestoreとの使い分け

BigQuery・Firestoreとの使い分け

Google CloudのDB群は役割が明確に分かれている。BigQueryは大量データの分析(OLAP)向きで、ジョブ単位の重いクエリに最適化されている。Firestoreはモバイル/Webアプリ向けのドキュメントDBで、リアルタイム同期とオフライン対応が強み。対するSpannerは、銀行口座や予約システムのように「整合性を絶対に崩したくないトランザクション処理(OLTP)」と「グローバル展開」の両立が必要なときに選ぶ存在である。

とはいえSpannerはコストや管理難易度の面でハードルがあり、小規模サービスからすぐに導入するのは過剰なケースも多い。「最初はCloud SQLやFirestoreで始め、スケール上限や整合性要件が顕在化したらSpannerに移行する」という段階設計が現実的だ。AdWordsやGmailと同じ基盤を、自分のサービスに使うという感覚は、Spannerの大きな魅力の一つだろう。

まとめ

Cloud SpannerはGoogle社内で広告基盤を支えてきた分散DBを2017年から外部公開したもので、TrueTimeとPaxosを軸にグローバル強整合トランザクションを成立させる極めて野心的なRDBMSである。Processing UnitモデルやPostgreSQL互換、Change Streamsといった機能拡張により、近年は中規模サービスからも採用しやすい姿に整えられてきた。「リレーショナル」「グローバル」「強整合」のすべてが要件になる場面で、まず候補に挙がる稀有な選択肢として位置付けられる。

※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

コメント

コメントする

目次