グローバルなOLTPを可能にするグーグルのRDBサービス、「Cloud Spanner」とは

　米グーグルは2017年5月16日（米国時間）、パブリッククラウドサービスGoogle Cloud Platformで、2017年2月にパブリックベータテストを開始していたリレーショナルデータベースサービス「Cloud Spanner」の本格提供を開始した。実際にアクセスしてみたところ、2017年5月17日現在、ロケーションとして選択できるのは台湾（asia-east1）、ベルギー（europe-west1）、米アイオワ州（us-central1）。

　本記事では、2017年3月に開催されたGoogle Cloud Next 17のセッションと、2017年5月に発表された論文から、Cloud Spannerとは何かをあらためて紹介する。

参考記事：米グーグル、GCPでACID特性と拡張性を兼ね備えたデータベースサービス「Cloud Spanner」を発表

グーグルのビジネスを支えてきたデータベースをサービス化

　Cloud Spannerは、一言で表現すれば「グローバルに水平スケーリング可能なリレーショナルデータベースサービス」。一般的なリレーショナルデータベースと同様にデータの一貫性を保ちながら、世界中に単一のデータベースを展開できるアーキテクチャを備える。可用性は99.999％という。

　グーグルが好んで紹介する想定用途に、アーティストのワールドツアーチケットの世界的な販売がある。任意の会場における任意の席を、世界中の誰もがいつでも購入できるようなシステムを支えられるという。オリンピックやサッカーワールドカップの、（国ごとに販売枠を設定しない）チケット販売システムも構築できるということだろう。

 
グローバルなライブツアーの世界的な販売は、分かりやすい用途

　Cloud Spannerは、2005年ごろからグーグルが社内で開発を進めてきたSpannerというデータベースをサービス化したもの。

　Cloud SpannerのプロダクトリードであるDominic Preuss（ドミニク・プリウス）氏は、AdWordsがSpanner開発のきっかけだったと説明している。

　グーグルの主要な収益源であるAdWordsでは、当初MySQLをデータベースに使っていた。「カスタマーIDに基づき手作業でシャーディングを行っていたが、再シャーディングが必要となり、これに数年かかることが分かると、別の方法があるはずだと考えるようになった」（Preuss氏）。そこでSpannerの開発を始めたという。

　同社はAdWordsの他にGoogle PlayやGoogle Cloud Platformのための基幹データベースとして、Cloud Spannerを広範に活用しているという。Google Playではユーザーのアカウントや購入トランザクションの管理に使われている。

　「Google Cloud Platformも、Cloud Spanner上に構築されている。Google Cloud Platformにおける全ての仮想マシンやサービスは、Spannerによって管理されている」（Preuss氏）

　Spannerは、当初強い一貫性とグローバルな分散を可能としたkey-valueデータベースだったが、OLTP用途に利用する社内ユーザーの強い要望により、SQLインタフェースを開発。現在では、ANSI SQLでアクセスできるリレーショナルデータベースとして提供されている。

Cloud Spannerはどのようなアーキテクチャになっているか

　Cloud Spannerでは、データベースが単一データセンター内の複数の仮想インスタンスにまたがって自動的にシャーディングされる。これらのシャードを、物理的に離れた他のゾーンやリージョンへ自動的に同期複製できる。

　執筆時点では単一リージョン内の複数ゾーンへの同期複製に限定されており、これによって99.99％の可用性を担保しているという。現時点では単一リージョン内でのスケーリングに限定され、複数リージョンにまたがるデータベースの同期複製は、2017年中に提供予定となっていて、これにより99.999％の可用性を実現するという。

　スケーリングという観点では、Cloud Spannerはノード数を増やすことで、水平スケーリングによりパフォーマンスを向上できる。事実上無制限にノード数を増やせるという。一般的なリレーショナルデータベースでもリードレプリカを作成することで水平スケーリングに近いことができるが、これは完全な同期複製ではない。対してCloud Spannerでは、複数リージョンをまたがる場合でも、全ての読み出しが最新のデータであることを保証している。

　グローバルなデータの一貫性を保持するためには、次のような仕組みを実装している。

　いずれかのレプリカに対し、データの更新が行われようとすると、更新対象となるデータを持つレプリカ全てに通知され、データが送られる。書き込みには、Paxos合意アルゴリズムをカスタマイズしたものを使っているという。2相コミットは必要な場合にのみ利用しているとする。

　グローバルなデータの一貫性を保ちながら、2相コミットを可能な限り避けてパフォーマンスを確保するため、Cloud Spannerではテーブルのインターリーブ（挟み込み）を行えるようにしていると、Preuss氏は説明している。

 
このような親と子のテーブルで構成するデータベースでは……

　上図のような親テーブル（左）と子テーブル（右）の構成となっている場合、Cloud Spannerは下図のように、主キーに基づき子テーブルのデータを文字通り親テーブルに挟み込む。これによって複数のテーブルのデータを同一ノードに集約できる。結果として、2相コミットに大きく依存することなく、一般的なクエリに対する高速なレスポンスを実現しているという。

 
子テーブルを親テーブルにインターリーブする

　Cloud Spannerには「マスターノード」「スレーブノード」の概念がなく、完全に分散型のアーキテクチャとなっている。従って、ソフトウェアアップグレードやパッチのためにマスターノードを停止したり、スレーブにフェイルオーバーする必要がない。グーグルが何らかのメンテナンスを行っていても、パフォーマンスの低下はないという。