当記事はみずほリサーチ&テクノロジーズ × G-gen エンジニアコラボレーション企画で執筆されたものです。

G-gen の片岩です。Google Cloud の Cloud Spanner について徹底解説します。Cloud Spanner は強整合性を持ちながらグローバルな負荷分散が可能なサービスです。高い可用性、データの完全性が求められる金融分野での活用が見込まれるサービスであり、仕様を調査することにしました。

Cloud Spanner の概要
ユースケース
料金
インスタンスと構成
読み取り方式
バックアップ
運用
データ処理の仕組み
- シャーディング
- インターリーブ
強整合性とスケーラビリティの両立
データブースト

Cloud Spanner の概要

Cloud Spanner とは

Cloud Spanner は強整合性を保証する RDB（リレーショナルデータベース）の特徴とグローバルに水平スケーリングできる NoSQL データベースの特徴を併せ持つデータベースです。そしてダウンタイムが最小限であり運用負荷の少ないフルマネージドのデータベースでもあります。

Cloud Spanner は強整合性 (RDB の強み) と、スケーラビリティ (NoSQL の強み) のいいとこどりのアーキテクチャを兼ね備えており、他クラウドにも類似サービスのない、ユニークなデータストアサービスです。

参考 : Cloud Spanner

強整合性と結果整合性

強整合性とは、読み取り処理で必ず最新の書き込み情報を読み取れる性質です。例えばECサイトでは必ず最新の在庫状況を取得できなければ、在庫がないにもかかわらずお客さまから商品の注文を受け付けてしまいます。勘定、決済などを取り扱う場合にも強整合性が必要なことは想像に難くないと思います。

対照的に、最新情報の読み込みを保証しない性質が結果整合性です。NoSQL データベースは、スケーラビリティとパフォーマンスが高い（後述）反面、結果整合性を持ちます。例えば自分の投稿にお気に入りをした人の数など、結果整合性で十分なデータでは NoSQL データベースの特性を十二分に活用できます。

水平スケーリング

NoSQL データベースの内部ではデータを分割して保存するため、簡単に水平スケーリングすることができます。

一方、RDB ではデータベースを分割しないため水平スケーリングは難しく、垂直スケーリングしか取れないため、性能上限に抵触しやすいです。

Cloud Spanner は強整合性という RDB の特徴を持ちながら、NoSQL の特徴である水平スケーリングも実現する、ユニークなデータベースサービスです。

インターフェイス

SQL

Cloud Spanner のデータは SQL で操作することができます。SQL の方言として GoogleSQL と PostgreSQL のいずれかから選択することができます。選択はデータベース作成時に行います。

GoogleSQL と PostgreSQL は完全互換ではありませんが、ほとんど同様に利用できます。開発チームが PostgreSQL に慣れていたり、あるいはクライアントとして psql などの PostgreSQL エコシステムのツールを利用したい場合は PostgreSQL を選択することが望ましいです。

参考 : PostgreSQL Interface
参考 : Dialect parity between GoogleSQL and PostgreSQL

API

SQL の他にも、各プログラミング言語用のクライアントライブラリを使ったり、Rest API / gRPC を使ったデータの読み書きを行うことができます。

クライアント

Spanner では以下のようなユーザーインターフェイスを通じて SQL を実行したり、ミューテーション（API コールによるデータの更新）を実行したりすることができます。

Google Cloud コンソール (Spanner Studio)
各言語用の Spanner クライアントライブラリ (Cloud SDK)
REST API
RPC API
PostgreSQL クライアント (PostgreSQL Interface モードの場合)

psql などのコマンドラインで Spanner に接続する場合、PGAdapter というプロキシソフトウェアを経由して接続します。PGAdapter は JVM の動作するスタンドアロンプロセスあるいは Docker イメージとして提供され、クライアントのローカル環境やサイドカーコンテナとして起動されます。psql 等のクライアントからこの PGAdapter に対して接続すると、PGAdapter は IAM 認証を経て、インターネット経由（gRPC プロトコル）で Spanner インスタンスに接続します。

ユースケース

Cloud Spanner が適したケース

以下のいずれかにあてはまる場合に Cloud Spanner が有力な選択肢となります。

強整合性とスケーラビリティがどちらも必要な場合
ダウンタイムを極力減らしたい場合
データベースの運用負荷を軽減したい場合

代表的な事例

Cloud Spanner を利用した、代表的な公開事例をご紹介します (Google Cloud 社の Web サイト)。

みんなの銀行 の勘定系システムで利用されています。東阪両現用を実現するデータストアとして Cloud Spanner を活用しています。
ポケモンGo で利用されています。1 秒あたり 100 万件近いトランザクションを処理することも可能です。
メルペイ で利用されています。信頼性の高い決済処理を数百万のユーザーに 24 時間 365 日提供しています。

類似サービスの使い分け

Google Cloud が提供する RDB のサービスには Cloud Spanner のほかに Cloud SQL と AlloyDB があります。

Cloud SQL

Cloud SQL は MySQL、PostgreSQL、SQLServer を扱える RDB です。規模が小さく、高可用性を必要としない場合は、コスト面で優位な Cloud SQL で十分と言えます。

AlloyDB

AlloyDB は 99.99% の可用性 (1 年間における停止時間の合計が約 53 分以内) を保証するパフォーマンスに優れたデータベースで、AWS の Aurora に相当するサービスです。 PostgreSQL 完全互換のため利用可能なライブラリが充実しています。規模が大きく、高パフォーマンスが要求され、PostgreSQL の豊富なライブラリを利用したい場合は AlloyDB が望ましいと言えます。

Cloud Spanner

Cloud Spanner ではマルチリージョン構成の場合に 99.999 % の可用性 (1 年間における停止時間の合計が約 5 分以内) を保証します。スケーラビリティにも優れているため、グローバルにサービスを展開したい場合や、サービスをほぼ無停止で展開したい場合に Cloud Spanner の利用が適切でしょう。

料金

Cloud Spanner は割り当てたコンピューティング容量と使用しているストレージ量に対して課金されます。例として 100 処理ユニット、ストレージ使用量を 100GB で 1 ヶ月間フル稼働すると、約 16,795 円 / 月です (2023年2月時点、東京リージョン、135円/ドル) 。

同一のコンピューティング容量であっても、シングルリージョンとマルチリージョン、さらにアメリカとアジアとヨーロッパをまたいだマルチリージョンで単価が異なります。

最新の利用料金は以下の公式ページでご確認ください。公式の見積もりツールで料金が試算できます。

また、Cloud Spanner には 確約利用割引 の仕組みがあります。 1 年間または 3 年間の利用を確約することで最大 40% の割引を受けることができます。詳細はこちらをご覧ください。

インスタンスと構成

インスタンス

Cloud Spanner はインスタンスという単位で管理します。 Cloud Spanner におけるインスタンスは各地に設置する仮想サーバー群のことです。インスタンスごとに構成 (リージョン構成またはマルチリージョン構成) とコンピューティング容量を選択します。

リージョン構成/マルチリージョン構成

リージョン構成では指定したリージョン内の複数のゾーンにクラスタが展開されます。マルチリージョン構成では指定した複数のリージョンにまたがってクラスタが構成されます。リージョン障害への対応が必要な場合や、東阪両現用のように複数のリージョンにまたがって高いパフォーマンスが要求される場合はマルチリージョン構成を選択します。

また、SLA にも違いがあります。リージョン構成では 99.99% 、マルチリージョン構成では 99.999% の可用性が保証されています。

運用開始後にダウンタイム無く構成を変更することができるため、最初はリージョン構成から開始し、規模が大きくなったタイミングでマルチリージョン構成に変更するといったこともできます。

コンピューティング容量

インスタンスのコンピューティング容量は、処理ユニットの割り当てで決定します。処理ユニットの値によって、データのスループットや秒間クエリ数、ストレージの上限が決まります。
また、テーブル数の上限も処理ユニットによって決定されます (10ユニット毎に１テーブル)。

処理ユニットの下限値は 100 で、100 処理ユニット単位でコンピューティング容量を指定できます。また、1,000 処理ユニットを 1 ノードと呼び、1,000 処理ユニット以上を指定したい場合はノード単位でコンピューティング容量を指定することになります。

読み取り方式

Cloud Spanner では強力な読み取りとステイル読み取りという2種類の読み取り方法があります。
デフォルトの読み取り方式は強力な読み取りです。強力な読み取りでは強整合性を持った読み取りが可能な反面、読み取りの都度最新のデータであるかチェックするため、内部通信が発生しレイテンシがおおきくなります。

必ずしも強整合成が必要のない読み取りの場合はステイル読み取りを使用します。 stale は新鮮ではない、というニュアンスの言葉です。

ステイル読み取りではレプリカ自身が持つ最新のデータであるかのチェックをスキップするため、より高速な読み取りが可能となります。

バックアップ

Cloud Spanner のバックアップでは、バックアップと復元 機能、もしくは インポート/エクスポート 機能が使用できます。

バックアップと復元機能

バックアップと復元機能では、インスタンスと同じ地理的ロケーションにバックアップを保管することができます。
また、バックアップはトランザクションの処理には直接関係しないため、インスタンスのパフォーマンスには影響しません。バックアップ機能は手軽に利用できる反面、以下のような制約があります。

バックアップの保存期間は最長 1 年間
インスタンス内のリソースになるため、同じ構成のインスタンスを作成する場合を除いてデータの持ち出し不可

基本的にはバックアップと復元機能の利用を検討し、上記の制約が許容できない場合はインポート/エクスポートを使用します。

インポート/エクスポート

インポート/エクスポートでは、Cloud Storage の CSV ファイルや Avro ファイルの読み取り/書き込みが可能です。バックアップはファイルとして出力されるので上記の形式に対応した外部のデータベースにデータを持ち出したり、ファイル自身のライフサイクルを管理して1年以上保管することができます。

[バックアップと復元]の機能と[インポートとエクスポート]の機能の比較については こちら をご確認ください。

ポイントインタイムリカバリ

マスタデータを誤って削除した場合など、一部データのみ復元したい場合には、 ポイントインタイムリカバリ機能 を利用できます。最長 7 日間の任意の時刻のスキーマとデータを復元することができます。

運用

従来のデータベースであれば、データ量が膨大になり 1 つのデータベースに収まりきらなくなると、以下のように複数のデータベースにデータを分割するといった作業が発生しました。

ユーザー ID が a 〜 m から始まる場合はデータベース 1 を利用
ユーザー ID が n 〜 z から始まる場合はデータベース 2 を利用

Cloud Spanner では全自動でデータの分割処理が実施されるため、上記のような作業は発生しません。必要に応じて以下の作業を行うだけとなります。

CPU 使用率をモニタリングする
ノードの追加や削除を実施する
バックアップ / リストアを実施する

このように運用負荷が少ないことも Cloud Spanner の強みです。

データ処理の仕組み

ここからは Cloud Spanner の内部的な仕組みをご紹介します。まずは大量のデータを高速に処理する仕組みです。

シャーディング

Cloud Spanner では PK のレンジに沿ってデータがいくつかに分割 (シャーディング) されてストレージに保存されます。この分割されたデータをスプリットと呼びます。各ノードは、それぞれ割り当てられたスプリットの読み込み処理や書き込み処理を担当します。ノードを増やすと 1 ノードあたりのデータ量が減り、それだけ負荷分散できることになります。

各データが均等にアクセスされる場合は、各スプリットのサイズも概ね均等になります。

各データが均等にアクセスされない場合、たとえば上記の図で y や z から始まるデータのアクセス量が多い場合は、各ノードの負荷が均等になるように、以下のように自動的にリシャーディングされます。

一時的なリシャーディングは問題ありませんが、継続的なリシャーディングが発生するとデータベースに無駄な負荷がかかってしまいます。たとえば上記の図で z から開始するデータだけが増え続けてしまうと、ノード 3 のみに負荷が集中することになり、継続的なリシャーディングが発生してしまいます。特定のノードに負荷が集中して継続的なリシャーディングが発生しないよう、データベースのスキーマ設計時はご留意ください。

インターリーブ

詳細は後述しますが、単一リージョン構成の場合はデータが 3 つのゾーンに 3 重に冗長化されています。以下は 2 つのテーブル①とテーブル②が 3 つのゾーンで冗長化されるイメージです。

それら 3 のゾーンのうち読み書きを実行するリーダーがスプリットごとに選ばれます。特段の指定をしない場合は、テーブル①とテーブル②はそれぞれ独立してスプリットに分割されます。

たとえば上の図の PK が b からはじまるデータに対してテーブル①とテーブル②に更新処理を実行すると、更新処理はリーダーを通して実行されるため、テーブル①ではゾーン a で処理し、テーブル②ではゾーン b で処理するといった事象が発生します。このようにJOIN したいテーブルのノードが異なると、ノード間の通信が必要になり、オーバーヘッドが発生してしまいます。

このオーバーヘッドを回避するために、関連するテーブルのデータを物理的に連続した同じ位置に配置することができる仕組みをインターリーブと呼びます。インターリーブを使用することにより、JOIN 時に異なるノード間の通信が発生することを抑えることができます。