🔥

Spannerは、CAP定理を覆したのか？

2024/03/09に公開

Spannerとは

Spannerとは、一般的なRDBと同様に、信頼性（ACID特性）のあるトランザクションをサポートしつつ、スケールアウトもサポートするデータベースです。つまり、負荷に応じて物理的なマシンの台数を増やすことが可能なRDBです。

従来のRDBでは、信頼性のあるトランザクションをサポートしつつ、スケールアウトすることができなかったために、マシンのスペック自体をあげるスケールアップで対応していました。

スケールアップでは、マシンの性能の上限から、さらに上げようとした場合、ダウンタイムを許容して、マシン自体を替える必要があります。つまり、サービスが一時的に中断してしまいます。

スケールアウトは、性能の上限に達したとしても、マシンの台数を増やせばよいだけなので、ダウンタイムは発生しません。

このように、Spannerは、負荷が増えた場合でも、スケールアウト可能なRDBであるという点がユニークであるため、NewSQLという新しいデータベースのジャンルに分類されたりもします。

次に、Spannerのように、複数のマシンで構成される分散データベースを語る上で避けては通れないCAP定理について解説します。

分散データベースにおいて、以下の望まれる３つの特性のうち、同時に満たすことができる特性は２つしかないという定理です。

一貫性（Consistency）
分散データベースを構成するどのマシンのデータにアクセスしても、最新のデータが返ってくること。
可用性（Availability）
必ずデータにアクセスできること。
一部のマシンがダウンしても、別のマシンが動いていて、対象のデータにアクセスすることができるなら、可用性があると言える。
ネットワークの分断を許容（Partition Tolerance）
分散データベースを構成する複数のマシン間のネットワークが分断される状態を許容するかどうか。
分断耐性と訳されることが多いが、個人的には、分断を許容するの方がすんなり理解ができた。

この３つの特性の内、どれを満たすかでCA・CP・AP型のデータベースに分類することができます。

CA（一貫性 + 可用性）
ネットワークが分断されていない状態のとき（または単一のマシン上で動いているとき）のみ、一貫性も可用性も得ることができます。
CA型のDB例：一般的なRDB
CP（一貫性 + ネットワークの分断を許容）
ネットワークの分断が発生したとき、一貫性を考えて2つのサーバーで同じデータにするには、システムを一時停止するしかありません。
つまり、可用性が失われます。
CP型のDB例：HBase、MongoDB
AP（可用性 + ネットワークの分断を許容）
ネットワークの分断が発生したとき、可用性を考えて片方のサーバーにだけ最新の書き込みをしてしまうと、2つのサーバーでは同じデータを持つことができません。
つまり、一貫性が失われます。
AP型のDB例：Cassandra、DynamoDB

このように多くのデータベースは、３つの特性のうち、同時に満たすことができる特性は２つしかないのですが、Spannerは、３つの特性を同時に満たすことができます。

それゆえに、信頼性（ACID特性）のあるトランザクションをサポートしつつ、スケールアウトもサポートするRDBと言えるのです。

では、SpannerがCAP定理を覆した仕組みを見ていきましょう。

Google Cloud の公式ブログによると、Spannerは技術的に見ると、CP型のDBのようです。
つまり、ネットワークの障害が発生したら、可用性を失います。

では、どのようにしてCAP定理を覆したのかというと、Googleは、自分たちのネットワークに自信があるため、そもそもネットワークの分断なんて発生しないよ、が答えです。
正確には、CAP定理を覆したわけではないんですね。

Googleの何年にもわたるオペレーションの結果、堅牢なネットワークを構成することができるようになったようです。

ちなみに、マルチリージョン構成のSpannerの可用性（SLO）は、99.999 %に設定されています。