Cloud Spannerは「DynamoDB + Aurora」なのか？

最近勉強のために初めてCloud Spannerを使い始めましたが、AWS慣れしすぎてどうしてもDynamoやAuroraと比べてしまいます。結論から言うと、かなり近いが、完全に同じではありません。

自分の解釈では、Google Cloud Spannerは、AWSで言えば DynamoDBのような水平スケール性 と、AuroraのようなSQL・トランザクション・リレーショナル性 を一つに寄せたサービス、と捉えると理解しやすいです。

ただし、現在のAWS側には Amazon Aurora DSQL という、Spannerにかなり近い分散SQL系サービスもあります。そのため、正確に比較するなら「DynamoDB + Aurora」だけでなく、Aurora DSQLも含めて見ようと思いました。

ざっくり比較

観点	Google Cloud Spanner	Amazon DynamoDB	Amazon Aurora
タイプ	分散SQL / マルチモデルDB	NoSQL / Key-Value・Document	マネージドRDB
強み	グローバルスケール + 強い整合性 + SQL	超高スケール、低運用、単純アクセスが速い	MySQL/PostgreSQL互換、既存RDB移行しやすい
データモデル	Relational, key-value, graph, search など	Key-value / document	Relational
SQL	対応	基本なし	対応
JOIN	対応	非対応	対応
トランザクション	強い。外部整合性を提供	ACID transactions対応。ただしNoSQL設計前提	RDBとして対応
グローバル構成	同期レプリケーション、強整合性が特徴	Global Tablesでmulti-active	Aurora Global Databaseは基本 primary write / secondary read
向く用途	金融、在庫、ID、グローバルSaaSなど一貫性が重要な大規模OLTP	セッション、カート、ゲーム、イベント、単純アクセスの大規模処理	一般的なRDBアプリ、MySQL/PostgreSQL移行

なぜ「DynamoDB + Auroraっぽい」と言われるのか

SpannerがDynamoDBに似ている点は、水平スケールです。

DynamoDBは、アクセスパターンを明確に設計したうえで、非常に大きなトラフィックを低運用でさばくためのNoSQLデータベースです。キーアクセス中心のワークロード、イベント、セッション、カート、ゲーム、IoTなどに向いています。

一方で、SpannerはRDB的なSQL、スキーマ、トランザクションを持ちながら、分散環境でスケールすることを狙っています。ここがAuroraに近い部分です。

つまりSpannerは、単純にDynamoDBとAuroraを足したものというより、「RDBの開発体験を保ちながら、NoSQL級の水平スケールを狙うDB」 と言ったほうが正確です。

DynamoDBとの違い

DynamoDBは、基本的に「アクセスパターンに合わせてテーブルを設計する」サービスです。

そのため、DynamoDBでは以下のような設計がよく求められます。

• JOINを前提にしない
• 正規化よりも非正規化を使う
• クエリしたい形に合わせてパーティションキーやソートキーを設計する
• 後から自由に複雑な検索をするより、事前にアクセスパターンを決める

これは非常に強力ですが、RDBに慣れた開発チームにとっては設計の考え方が大きく変わります。

Spannerは、ここが違います。SQL、JOIN、トランザクションを使いながら、分散スケールを狙えます。つまり、アプリケーション側でNoSQL流のデータモデリングに大きく寄せなくても、大規模なOLTPを扱える可能性があります。

Auroraとの違い

Auroraは、MySQL/PostgreSQL互換のマネージドRDBとして非常に使いやすいサービスです。既存アプリケーションをAWSへ移行する場合や、一般的なRDBワークロードには強い選択肢です。

ただし、通常のAuroraは基本的にRDBクラスタの延長にあります。Aurora Global Databaseを使えばグローバルな読み取りレプリカ構成は作れますが、書き込みは基本的にprimary Regionが中心です。

Spannerは、最初から分散SQLとして設計されている点が違います。グローバルに分散しながら強い整合性を保つ、という設計思想が中心にあります。

Spannerの本質

Spannerの強さは、分散しているのに単一DBのような強い整合性を提供しようとすること です。

Googleはこれを external consistency と呼び、TrueTimeを使ってトランザクションの順序を保証します。

これは、以下のような領域で特に価値があります。

• 金融取引
• 在庫管理
• 予約システム
• ID・権限管理
• グローバルSaaSのテナント管理
• 複数リージョンで動くが整合性を崩したくないOLTP

単に「大量に読み書きできる」だけではなく、大量に読み書きしながら、整合性も強く保ちたい という用途に向いています。

AWSで一番近いのは何か

昔ながらのAWSサービスで考えるなら、Spannerは「DynamoDB + Aurora」のように説明できます。

しかし、現在のAWSでより近い比較対象を挙げるなら、Amazon Aurora DSQL も見るべきです。

Aurora DSQLは、PostgreSQL互換を持つサーバーレス分散SQLデータベースとして位置づけられています。つまり、AWS側でもSpannerに近い「分散SQL」の選択肢が出てきています。

整理すると、こうです。

• DynamoDB: スケール最優先のNoSQL
• Aurora: 互換性重視のクラウドRDB
• Aurora DSQL: AWS側の分散SQL
• Spanner: Googleの本命分散SQL。SQL、強整合性、グローバルスケールを統合

使い分け

Spannerを選ぶべきケース

• グローバルまたは大規模なOLTPが必要
• SQLやトランザクションを捨てたくない
• シャーディングを自前でやりたくない
• 整合性のズレが許されない
• NoSQL的なスケールも欲しいが、後から複雑な問い合わせもしたい

DynamoDBを選ぶべきケース

• アクセスパターンが明確
• キーアクセス中心

Auroraを選ぶべきケース

• 既存のMySQL/PostgreSQLアプリを自然に移行したい
• 一般的なRDBワークロード
• チームがRDB運用・SQLに慣れている
• グローバル強整合性よりも互換性や移行容易性が重要

Aurora DSQLを検討すべきケース

• AWS上で分散SQLを使いたい
• PostgreSQL互換を重視したい
• 通常のAuroraよりも分散・マルチリージョン性を重視したい
• Spanner的な設計思想をAWS内で実現したい

まとめ

「Spanner = DynamoDB + Aurora」は、直感的な説明としてはかなり良いです。

ただし、正確にはSpannerは「DynamoDBのようなNoSQL」と「AuroraのようなRDB」を単純に足したものではありません。

Spannerは、NoSQL的な水平スケール と RDB的なSQL・トランザクション・強整合性 を、最初から一つの分散データベースとして設計したサービスです。

AWSで近い構成を考えるなら、従来は「DynamoDB + Aurora」と表現すると分かりやすかったはずです。現在は、それに加えて Aurora DSQL も比較対象に入れるのが自然です。