クラウドネイティブで変わる「NewSQL」の意味――地球規模でデータ分散を可能にする合意プロトコルの仕組みと課題：クラウドネイティブ時代のデータベース（終）

クラウドネイティブ時代に求められるデータベースの3要件を満たすべく開発が進められているNewSQLの基本概念と、データの可用性を高める仕組みを解説する。

[小林隆浩，野村総合研究所]

　本連載第2回では、クラウドネイティブ化で高速化したアプリケーション開発と同様に、データベースもアジリティを獲得するためにKubernetesを利用する手法を紹介した。第3回では、クラウド事業者の障害も超えた可用性を獲得するために、マルチクラウドでデータベースを管理する手法を紹介した。

　クラウドネイティブでもう一つ重要とされるスケーラビリティ、いわゆる水平方向の拡張性はこれまで部分的にしか言及してきていない。これは長い歴史を持つRDBMS（リレーショナルデータベースマネジメントシステム）において、単純にプラットフォームをKubernetesやクラウドにシフトすれば実現できるというようなものではないためでもある。

　ではクラウドネイティブなプラットフォームや現在の分散システムの基礎研究上に、新しい発想でデータベースを開発したらどうだろうか。本連載最終回の今回は、SQLインタフェースを持ち、高い可用性と水平方向の拡張性を併せ持つ「NewSQL」といわれるデータベースを解説する。

NewSQLが示す概念とは

　NewSQLというデータベースの1カテゴリーを指す用語は、当時流行していた「NoSQL」に対する概念として2011年ごろに登場してきた。NoSQLはSQLインタフェースを持たない代わりに、高い可用性と拡張性を実現していたが、普及するにつれてアプリケーション開発に負担を強いる例も見られるようになっていた。

　2011年当時のNewSQLは、NoSQLとRDBMSの良い所取りを目指して一から開発された幾つかの製品群を指していた。その特徴はSQLインタフェースを持ち、従来のRDBMSでは難しかった水平方向の拡張性と高い可用性を同時に実現していた。当時、それらはインメモリ技術とシェアードナッシング型の水平クラスタリングで実装されていた（参考：2010年当時のVoltDBの紹介記事）。

　こうした流れはパブリッククラウドの隆盛で変化していったが、NewSQLの方向性を大きく決定付けたのが2012年のSpanner論文の発表、そして2017年のGoogle Cloud Spannerの登場だった。

　第1回で紹介したように、Cloud Spannerは3つのリージョンにレプリカを持ち（つまりマルチリージョンでビジネス継続性を確保し）、無制限とされる拡張性を実現している。さらにNoSQLでは妥協の対象であった、分散環境における強い一貫性を実現し、厳密性を求められながら可用性や拡張性も必要なアプリケーションで利用されている。

　Spannerの論文に影響を受けて、その後幾つかの分散SQLデータベースが開発された。下表にそれらの大まかなリリース時期や、従来のRDBMSとの互換性をまとめる。

名称	開発元	リリース年	SQLインタフェース
Cloud Spanner	Google	2017年※	独自（ANSI 2011 SQL相当）
CockroachDB	Cockroach Labs	2017年（v1.0）	PostgreSQL互換
TiDB	PingCAP	2017年（v1.0.0）	MySQL互換
YugabyteDB	Yugabyte	2018年（v1.0.0）	PostgreSQL互換
分散SQLデータベースの一例（※ただしSpannerはGoogle社内で以前から大規模に利用されていた）

　上表のうち、Cloud Spanner以外のデータベースは基本的にOSS（オープンソースソフトウェア）として開発されている。可用性や拡張性などの観点で従来RDBMSの課題を解消しながら、アプリケーション開発で広く利用されているMySQLやPostgreSQLと互換性を持ち、Google Cloud以外のプラットフォームで利用可能である点で、Cloud Spannerとの差別化が図られている。

　なお、いずれのベンダーも自社の製品をNewSQLとは呼称していない。彼らはそれぞれの製品を「Distributed SQL Database」と呼んだり、Cloud NativeやHigh-Performanceなどの形容詞で説明したりすることが多い印象だ。

　本記事の後半ではSpannerに影響を受けて開発された分散SQLデータベースを、海外メディアでよく使われる分類にならいNewSQLと呼ぶことにする。

　Spanner以降のNewSQLにはそれ以前の特徴に加えて、広域の地理的分散という特徴が加わる。つまりパブリッククラウドやオンプレミスにおいて、複数地域のデータセンターにまたがったデータ複製を実現している。この特徴は以前よりプロプライエタリのRDBMSやエンタープライズ向けのストレージ機器で実現していたが、それらをソフトウェアレベル、しかもOSSで実現している点にNewSQLの価値がある。

　以降ではNewSQLがどのようなアーキテクチャで、ここまで解説してきた特徴である「高い可用性と水平方向の拡張性を持ち、地球規模で分散可能なSQLデータベース」を実現しているかを解説していこう。

NewSQLの設計思想

　Cloud Spannerおよびその影響を受けた分散SQLデータベースは類似したアーキテクチャを持つ。

　実装によってコンポーネントの細かな違いはあるが、コンピュートノードとストレージノードを分離した構成と、全てのノードが同じコンポーネントを持つ一体型の構成が存在している。先ほどの表で示したNewSQLの例で言えば、Cloud SpannerとTiDBが分離型、CockroachDBとYugabyteDBが一体型の構成となる。

　それぞれの違いを示すと下図のようになる。

NewSQLの構成パターン

　次に図中の各コンポーネントも解説をしていく。

　まず分離型の構成でコンピュートノードに含まれているのが、複数ノードにまたがる処理をコントロールするコーディネーターと、ステートメントの解析やプラン作成や実行自体をつかさどるSQLエンジンだ。これらは状態を保持しないコンポーネントであり、データを保持する部分と分割できる。

　先ほどの表でどのデータベースがどのようなSQLインタフェースを持つかを示したが、これはSQLエンジンの実装によるものだ。採用を検討する際には、どのRDBMSとどこまでの互換性を持つかの観点で確認が必要となるだろう。

　図中の他の部分、つまり分離型でストレージノードに含まれているコンポーネントはまとめて、ストレージエンジンとも呼ばれる。各データベースの実装を詳細に見ていくと、この部分にNewSQLの特徴が現れている。

　NewSQLではノード間でデータ複製をすることで可用性を高めているが、従来のRDBMSで用いられてきたデータ同期のプロトコルではなく、合意に基づいたプロトコルが使われている。Cloud SpannerではPaxos、その他ではRaftといわれる合意プロトコルが使われているが、それらの特徴として一度合意に至ったデータは障害が起きても覆ることがない。これはトランザクションログを非同期で転送してデータ複製をする処理では発生する、データ損失の可能性がないことを意味する。

　またNewSQLでは、複数レコード（より厳密に言えば複数パーティション）の間でACID特性を守りながら更新していく必要があり、それはNoSQLがこれまで苦手としてきた（制限が存在した）部分でもある。このような分散トランザクションにおいても、上記の合意プロトコルの利用を前提として、各NewSQLが独自に最適化を行い、応答時間の改善とデータベースとしての高い拡張性を同時に実現している。

　詳細な解説は今回省略するが、分散トランザクションのプロトコルとして前述のSpannerやPercolator、Calvinといった論文が参照され、実装されている例を見ることができる。

NewSQLが持つ課題

　ここまで大まかにNewSQLの概念とアーキテクチャを解説してきた。最後に現状のNewSQLが持つ課題を2点ほど示して結びとしたい。

　まず一点目は、NewSQLの構成の複雑さと管理性に関する課題である。先ほどの構成パターンで見たように、これまではRDBMS内部に隠されていたコンポーネントが、分散環境でそれぞれ連携して動作するために、設計や構築作業が複雑となる。分離型に見られるように、役割の異なるノードをシステムの性能要件に応じて準備するのも容易とは言い難い。

　一点目の課題に対しては、各社はクラウドネイティブなアプローチで対応を進めている。つまりプラットフォームとしてのKubernetesの活用と、パブリッククラウド上でのマネージドサービスの提供である。

　前述のCockroachDBやTiDB、YugabyteDBはいずれもKubernetesにデプロイが可能である。また各社がAmazon Web ServicesやMicrosoft Azure、Google Cloud Platformでマネージドサービスを展開している。これにより、管理が複雑になりがちなNewSQLをユーザーは手間をかけずに利用できる。

　二点目は、NewSQLが実現する「高い可用性と水平方向の拡張性、地球規模での分散」を必要とするアプリケーションがどれほど存在するのかという点である。これは連載第3回で指摘した、非常に高い事業継続性を実現する必要はあるのかという疑問とも重なる。

　現在、NewSQLが利用されている市場は北米や中国などがメインであり、広大な地域に広がるビジネスを支えるために、その特徴が重視されていることは事実である。一方で日本国内に限れば、災害対応で冗長化の対象となる東京と大阪間の距離は比較的近く、従来の技術でも事業継続性を担保することは可能ともいえる。

　しかし、筆者は他の観点で各企業がNewSQLに取り組むべき価値があると考えている。

　本連載で述べてきたように、クラウドネイティブなアプリケーションを支えるために、これからのデータベースはアジリティを獲得し、要求される可用性と拡張性をビルトインで実現する必要がある。ビジネスの成長に伴って、その都度性能要件を満たすデータベースにリプレースすることで発生する機会損失を避けるために、初期の製品選定が重要だ。

　ビルトインによる拡張性は、連載第3回で紹介したHyperscale（Citus）の場合「scale-out-ready」というコンセプトで説明している。これはアプリケーションの開発当初から高い拡張性と可用性を持つデータベースを使うことで、ビジネスが成長した際にもシームレスに、つまりアプリケーションを変更することなく必要な拡張ができる状況を指す。

　NewSQLの採用がプロジェクト計画段階では過剰な高機能、高性能に思えるケースはある。しかし、SQLインタフェースの互換性がもたらす開発生産性の向上や、scale-out-readyでのスモールスタートを検討することは、プロジェクトに大きな恩恵をもたらす可能性がある。

まとめ

　本連載ではクラウドネイティブ時代のデータベースに求められる要件を整理し、3つのソリューションを紹介してきた。アプリケーションの開発に大きな変革をもたらしたKubernetesをプラットフォームとしてデータベースにおいても利用することで、アジリティを獲得し運用の容易性などのメリットを享受できることを実例とともに紹介した。

　次に、クラウドネイティブなアプリケーションにおいては、クラウド事業者や広域災害などにおいても事業の継続性を高める構成を取る必要があり、データベースの観点でそうした構成に用いることができるマネージドサービスを紹介した。

　最後に、アジリティと可用性、そして水平方向の拡張性を実現するデータベースの新しい潮流としてNewSQLを紹介し、それらの基本概念と採用における課題点を示した。

　本連載でも分かる通り、データベースは歴史が古いが今なお革新の続く新しい技術でもある。クラウドやKubernetesなどのプラットフォームの変化に柔軟に対応し、かつ最新研究からのフィードバックを得て、今日も進化が続いている。

　クラウドネイティブが当たり前な時代となった今だからこそ、データベースの進化に注目して新しい技術を評価し、今後も情報発信をしていく所存だ。

参考情報

　本連載では省略した、分散SQLデータベース内で使われている要素技術を紹介した書籍『詳説 データベース』（【著】Alex Petrov、【監訳】小林 隆浩、【訳】成田 昇司）をオライリー・ジャパンより2021年7月に上梓した。

　この書籍は、ストレージエンジンと分散データストアという観点で多くの基礎研究や実装を紹介し、最新の分散SQLデータベースを理解する一助となるように構成されている。今回簡単に紹介した合意プロトコルを用いたデータの複製や、分散トランザクションの詳細な解説がされているため、ご興味をお持ちの方は一読をおすすめする。

筆者紹介

小林隆浩

野村総合研究所でデータベースを中心としたインフラ設計を担当。