データベースエンジニアから見たCloud Spanner
～ Cloud Spanner の特徴 ～
この記事は Google Cloud Japan Advent Calendar 2021 の 11日目の記事です。
はじめに
この記事ではGoogle Cloudの特徴的なサービスの1つであるCloud Spannerについて紹介しています。Cloud Spannerはその高可用性からミッションクリティカル用途に向く、水平方向へのスケーラビリティを持つリレーショナルデータベースです。
Cloud Spannerについて、従来のRDBMSを利用していたデータベースエンジニアやアプリケーションエンジニアが、知っておいたほうが良いと思われる知識をまとめてみました。
私自身もこれまでOracle Databaseを始めとして、SQL ServerやMySQL、PostgreSQLなどのオープンソースDB、DBアプライアンスのExadataやCloud NativeデータベースとよばれるAmazon Auroraなどをデータベースエンジニアとして担当してまいりました。Cloud Spannerは同じリレーショナルデータベースでありながら、これまでにない高可用性とスケーラビリティを有しており、またNoSQLから派生して誕生したというその技術的な特殊性からも、是非次に学ぶ技術としてオススメしたいデータベースです。
Cloud Spannerの特徴
Cloud Spannerについて特徴的な2つの点、高可用性とスケーラビリティについてお話したいと思います。
１．高可用性
Cloud Spannerは標準で複数のゾーンにデータベースのレプリカ（複製）が配置される高可用性構成がとられており、(シングル)リージョンの構成では 99.99 % (ダウンタイムが年間約50分を超えない) の可用性SLAが提供されています。また東京リージョンと大阪リージョンなど、複数のリージョンへ配置するマルチリージョン構成とした場合、99.999 % (ダウンタイムが年間約5分を超えない)の可用性SLAが提供されています。
Cloud Spannerのレプリカ間は常に同期的にレプリケーションが行われています。もし一部のレプリカに障害が起こった場合でも、システムから自動的に切り離され、障害から復旧するまで残りの過半数のレプリカにより継続的に処理を行うことが可能な高可用性構成がとられています(下図参照)。MySQLなどのマネージドデータベースサービスであるCloud SQL等では、高可用性構成をとった場合には、一般的にフェイルオーバー発生時にデータベースプロセスの再起動によるダウンタイムが発生しますが、Cloud Spannerではその様なダウンタイムが発生することもありません。
またレプリカを複数のリージョンへ配置するマルチリージョン構成(下図参照)とすることで、さらに高い可用性が提供されます。リージョン間は距離的に数百キロ以上離れていることから、自然災害に対するディザスタリカバリ構成とすることが出来、例えばアジアでは東京と大阪へレプリカを配置するマルチリージョン構成を取ることが出来ます。
マルチリージョン構成で選択できるリージョンは、高速な書き込みを可能とする低レイテンシな組み合わせのなかから、選択が可能となっています。選択可能な組み合わせは公式ドキュメントなどから確認することが出来ます。
２．スケーラビリティ
Cloud Spannerはデータベース性能を1ノードからスタートして無制限に水平スケール（スケールアウト／イン）することが出来ます(previewではありますが、現在は0.1ノードから構成することも可能)。スケール時には読み込み性能だけではなく、書き込み性能もともにスケールします。
そのためインターネットサービスなどの需要の予測をしづらいシステムでも、需要が増加した場合にノード数を拡張して応答遅延の発生を防いだり、需要の増減に応じてノード数の調整を柔軟に行う(下図参照)ことでコストを効果的に節約することが可能となります。またスケールアウト／イン時のダウンタイムも発生しないため、状況の変化のタイミングを逃さず柔軟なノード数の調整が可能です。
従来のRDBMSでは処理性能が不足する場合には、例えばマシン性能の増強による垂直スケール（スケールアップ）が行われます。しかしながら１つのマシンへ搭載可能なCPUやネットワークの処理性能には限界があり、無限にスケール出来るわけではありません。またスケールアップ／ダウンのためには一定のダウンタイムが必要となります。
また従来のRDBMSでリードレプリカ追加による読み込み性能の増強なども検討が可能ですが、スケールされるのは読み込み性能のみで、書き込み性能は一台のサーバで処理される点は変わりません。またソースデータベースの書き込み性能の劣化を防ぐため、レプリケーションは非同期となり、読み込まれるデータにタイムラグが発生してしまう点もデメリットとなります。
これら垂直スケールやリードレプリカによるスケールでは対応が難しくなった場合、①複数のデータベースインスタンスへデータを分割して保存し、処理を分散するシャーディングという手法や、②水平スケールが可能なNoSQLの利用を検討する必要が出てきます。
しかしながらシャーディングはアプリケーション開発側ではデータに応じてアクセス先のデータベースインスタンスが変更される点を意識して開発しなければならず、また複数のデータベースインスタンスにまたがったデータへアクセスするクエリが実行できなくなります。データベース管理側では管理するインスタンス数が増加し、またデータの増加や処理の偏りが発生した場合には作業負荷の高いリシャーディングという作業が必要となるなど、大きなデメリットがあります。
Cloud Spannerの興味深い点として、Google社内でも上記のスケール上の問題に直面し、その結論として開発された技術がSpannerと呼ばれるデータベースシステムである点です。（経緯については Spanner: Google’s Globally Distributed Database (解説ブログ)に詳しい記載があります。）当初はGmailなどのGoogleサービスのバックシステムにおいて利用されていたSpannerをもとに、2017年にGoogle Cloudのサービスの1つとしてリリースされたサービスが、Cloud Spannerとなります。
Cloud Spannerでは内部的にはシャーディングが行われていますが、その運用や調整は、マネージドサービス内部において自動的に行われます。またアプリケーションがアクセスするエンドポイントは常に一つであり、シャードをまたぐSQLの実行も（パフォーマンス上の考慮が必要ではありますが）可能であることから、シャーディングによるアプリケーション開発やデータベース管理への負担は少ないものとなります。整合性モデルとして強整合性が保証されていることや、トランザクションが利用可能な点、同期レプリケーションが行われている点も、アプリケーション開発の負担を下げます。
まとめ
まだここまで今回お伝えしようと思っていた内容の半分も記載できていないのですが、Cloud Spannerの特徴を記載しただけである程度の行数となってしまったので、今回はここまでとさせていただきます。今回の残りを含めて、今後も定期的にCloud Spannerについて紹介する記事を書いていきたいと思っています。
最後に次の記事が待てない方向けに、参考となりそうな記事を下記に紹介します。
Google Cloud ブログ：Cloud Spanner とは
Google Cloud ブログ：Cloud Spanner のマルチリージョン構成について理解する
Google Cloud ブログ：みんなの銀行：日本初の「デジタルバンク」として Google Cloud に勘定系を構築。Cloud Spanner で銀行基幹システムで求められる可用性を実現
Google Cloud ブログ：Pokémon GO が数百万ものリクエストへの対応を実現している方法
