GoogleがCloud Spannerのパブリックベータを発表

GoogleはCloud Spannerのパブリックベータを発表した。Cloud Spannerは世界規模で分散しているリレーショナルデータベースサービスだ。Google Cloud Platformの一部として、ACIDトランザクションと高可用性の両方を提供する。CAP定理に反しているのが売りだ。

SpannerはすでにGoogleの内部で使われているが、この度公開された。Google Cloud Platformの一部として提供されるマネージドなクラウドデータベースであり、利用者は基盤になっているインフラへアクセスすることはない。

Spannerは従来のACIDトランザクションとSQLと関係スキーマがあるリレーショナルデータベースのように振舞う。しかし、Googleのインフラで水平にスケールすることで、増加する大規模なトランザクションのワークロードを処理する。にもかかわらず、強い一貫性を維持し、一桁ミリ秒のレイテンシでデータを提供する。

CAP定理は、データベースは可用性と一貫性と分断耐性のうち2つ以上を提供することはできない。リレーショナルデータベースは可用性を犠牲にしている。一方、NoSQLは高可用性の維持と引き換えに結果整合性を提供する。

Spannerは技術的にはCAP定理を破っていない。しかし、機能的にはあたかも破っているようになっている。Google Cloudのインフラ部門のバイスプレジデントであるEric Brewer氏は次のように説明している。

Eric Brewer: これは、SpannerがCAPでいうところのCAを担保したシステムということでしょうか。短い回答は、技術的には"no"、だが、実際には"yes"であり、ユーザーはCAを前提にできます。

Brewer氏によれば、Spannerのネットワーク分断の可能性は10⁵分の1だ。もし、これが発生したら、システムは一貫性を選ぶ。技術的にはCPだ。しかし、ほとんど発生しないため、可用性も担保しているように扱うことができる。

Brewer氏のホワイトペーパーによれば、このレベルの信頼性はGoogleのプライベートなネットワークでSpannerが動いていることに起因する。Spannerのパケットはパブリックなインターネットに到達しない。そして、高いレベルの冗長構成になっているため、断線のような破滅的な事故が発生してもサービス停止にはならない。

Clouderaの分散システムエンジニアであるHenry Robinson氏のような第三者もこの主張を検証している。氏は次のように説明している。

Henry Robinson: 次のように考えればいい。CAPによればすべてのシステムにはアキレス腱がある。クリプトナイトがあると言ってもいい。つまり、CかAをある時点で諦めるということだ。しかし、Googleはそのクリプトナイトをどこかのブラックホールに埋めてしまったというわけだ。

ACIDを保証するため、Spannerはツーフェーズコミットを実装している。Brewer氏によれば、この方式はすべての参加者が起動していることが必要なため"反可用性"なパターンだが、SpannerはPaxosグループを使うことでこれを回避している。これは言い換えると、いくつかの参加者が不能であったとしても有効な多数決だ。

また、SpannerはGoogleの世界規模の同期時計であるTrueTimeを使っている。氏によれば、TrueTimeはGPSのレシーバと原子時計を使って正確な時間を保証する。これは、正確にタイムスタンプされた分散トランザクションによる外部整合性を実現する。

Cloud Spannerはまだベータ。現時点では無料でオンラインで利用できる。