めもめも

データエンジニアリング、機械学習について書いてます

Spannerは、いかにしてCAP定理を覆したのか

Spannerとは

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

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

そもそも、スケールアウトは、スケールアップよりも優れているのか?

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

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

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

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

CAP定理とは

分散データベースにおいて、以下の望まれる3つの特性のうち、同時に満たすことができる特性は2つしかないという定理です。 1. 一貫性(Consistency) 分散データベースを構成するどのマシンのデータにアクセスしても、最新のデータが返ってくること。

  1. 可用性(Availability) 必ずデータにアクセスできること。 一部のマシンがダウンしても、別のマシンが動いていて、対象のデータにアクセスすることができるなら、可用性があると言える。

  2. ネットワークの分断を許容(Partition Tolerance) 分散データベースを構成する複数のマシン間のネットワークが分断される状態を許容するかどうか。
    分断耐性と訳されることが多いが、個人的には、分断を許容するの方がすんなり理解ができた。

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

  1. CA(一貫性 + 可用性) ネットワークが分断されていない状態のとき(または単一のマシン上で動いているとき)のみ、一貫性も可用性も得ることができます。 CA型のDB例:一般的なRDB

  2. CP(一貫性 + ネットワークの分断を許容) ネットワークの分断が発生したとき、一貫性を考えて2つのサーバーで同じデータにするには、システムを一時停止するしかありません。
    つまり、可用性が失われます。
    CP型のDB例:HBase、MongoDB

  3. AP(可用性 + ネットワークの分断を許容) ネットワークの分断が発生したとき、可用性を考えて片方のサーバーにだけ最新の書き込みをしてしまうと、2つのサーバーでは同じデータを持つことができません。
    つまり、一貫性が失われます。
    AP型のDB例:Cassandra、DynamoDB

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

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

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

Spannerは、いかにしてCAP定理を覆したのか

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

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

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

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

参考

CAP定理の説明がわかりやすい https://www.teracloud.co.jp/special_cap-theorem.html Google Cloud 公式ブログ https://cloud.google.com/blog/ja/products/gcp/inside-cloud-spanner-and-the-cap-theorem