5-1-2 パラレルクラウド
あるDBaaSが単一クラウドだけでなく、複数のクラウドに展開されている状況を考えてみましょう。
クラウド障害に備える高い可用性は実現せずとも、Chapter4で説明したように、ポータビリティに優れたDBaaSは利用者に高い利便性をもたらします。アプリケーション開発者とシステム運用者双方の視点から見て、複数のクラウドで同じ使い勝手でサービスを利用できることに価値があります。
そのような価値を提供するDBaaSをいくつかピックアップして、以下で特徴を簡単に紹介します。これらのサービスは現在パラレルクラウドを実現しているものの、クロスクラウドではありません。そのため、サービスがクロスクラウドに進化する技術的な素養があるのかについても、コメントをしていきます。
BigAnimal
パラレルクラウドで展開しているサービスとして、まず紹介するのがEDB社のBigAnimalです。EDB社はPostgreSQLの開発を長く牽引してきた企業で、OSSへの貢献はもちろん、PostgreSQLを商用利用するための各種拡張を提供しています。EDB Postgres Advanced Server（EPAS）というDBMSを開発しており、Oracleとの互換性を持つエンタープライズレベルのPostgreSQL準拠データベースとして評価を得ています。
※なお2023年5月に、EDB Postgres AIが発表され、BigAnimalもEDB Postgres AI Cloud Serviceにリブランドされることがアナウンスされました。現状は過渡期であることも踏まえ、本書ではBigAnimalでの記載を採用しています。
そうした有償のデータベース関連ソフトウェアのライセンス販売やサポートに加え、近年はクラウド上でDBaaSを提供する企業としても注目を集めるようになってきました。BigAnimalはPostgreSQL as a Serviceの1つで、執筆時点でAWS、Azure、Google Cloudの3つのクラウドベンダーに対応しています。OSSのPostgreSQL以外にも、前述のEPASをDBMSとして選択することもできます。PostgreSQLの標準機能以上の可用性やセキュリティ、運用を助ける各種ツールなどをマネージドサービスで利用したい場合にEPASは有力な選択肢となっています。
BigAnimalはUIから簡単にプロビジョニングが可能で、バックアップによるデータ保護、レプリカによるスケーラビリティと災害対策など、DBaaSとしての基本機能を一通り備えています。
マルチクラウド観点でのBigAnimal
BigAnimalは複数クラウドで展開されるパラレルクラウドのパターンを取っていますが、この観点で注目すべきポイントは、プラットフォームとしてのKubernetesの利用です。ここ数年の動きとして、データベースをKubernetes上で稼働させることは珍しい取り組みではなくなってきましたが、大規模なDBaaSの稼働環境として使いこなすのは簡単なことではありません。
KubernetesはOperatorという仕組みで拡張が可能で、特定のアプリケーションやサービスに関連する複雑な構築作業や管理を自動化することができます。EDBはOSSのPostgreSQL OperatorであるCloudNativePGの開発を主導しており、EPASなどの強力な独自機能を稼働させることが可能なEDB Postgres for Kubernetesも提供するなど、データベースに関するOperatorの開発・利用実績を豊富に持つ企業です。
これらのPostgreSQL Operatorは各クラウドのKubernetesクラスターにインストールされ、BigAnimalのコントロールプレーンとして動作します。利用者はBigAnimalのGUIやAPIを経由して、PostgreSQL Operatorにデータベースインスタンスの作成や変更をリクエストします。Operatorはリクエストに応じて、PostgreSQLのコンテナを起動してディスクなど必要なリソースの割り当てを行います。
利用者としては、KubernetesとOperatorが内部で動いている点を意識することはほぼありませんし、クラウドベンダーが提供するほかのDBaaS利用と違いを感じません。しかし、サービス提供者であるEDBには大きなメリットがあります。それがChapter4で解説したポータビリティです。
クラウドごとにIaaSと呼ばれる仮想マシンのデプロイ単位や起動方法、ストレージの割当などにも違いがありますが、Operatorを利用してKubernetesの上でデータベースを実行することで、「Kubernetesがあればどのクラウドでも同じようにDBaaSを展開する」ことができます。
EDBのBigAnimalは、コントロールプレーンおよびデータプレーンをKubernetes Operatorで管理する好例となっています。
以下ではBigAnimalが提供する3つの可用性オプションについて解説します。
- Single node
- Primary/Standby high-availability
- Distributed high-availability
Single nodeは可用性の低い単一インスタンスとなりますので、2.のPrimary/Standby high-availabilityの構成を詳しく見ていきましょう。
こちらはマルチデータセンターの可用性を提供し、1つのプライマリインスタンスと1つまたは2つのスタンバイインスタンスで構成されるデータベースクラスターとなります。スタンバイインスタンスにはPostgreSQLのストリーミングレプリケーションの機能を用いて、データの同期が行われます。デフォルトでは2つのスタンバイインスタンスのうち、1つは同期レプリケーション、もう1つへは非同期でデータが同期される構成となります。プライマリの障害時にはスタンバイが昇格し、データベースクラスターとして正常に稼働できます。
3.のDistributed high-availability はほかのDBaaSには見られないEDB独自の可用性構成です。この構成はマルチプライマリであり、可用性向上に用いられるすべてのノードが読み取りと書き込みを受付可能な構成で、障害時の復旧時間（RTO）に優れた構成です。内部的にはPostgreSQLの論理レプリケーションを拡張した仕組みを用いています。
次の図にあるように、Distributed high-availabilityの構成では、同期と非同期のレプリケーションを組み合わせて、広域災害に備えたマルチリージョンの高い可用性を実現することができます。
上記の構成図にWitnessと書かれたノードがあることに気付いたでしょうか。これは分散システムで用いられる用語で、「4-2-3 NewSQLが備える高可用性」と説明したRaftの仕組みにおいて、「合意プロトコルに参加するが、データの複製を持たない」ノードを指します。Raftではさまざまな処理でノードの過半数の合意が必要となり、そのため奇数個のノードでクラスターを構成します。しかし、データの複製負荷は高いため、2つのリージョン間のどちらかが利用できれば運用要件を満たす場合に、それぞれ距離がある3つのリージョンすべてにデータを保持するのは無駄が多くなります。
冗長なデータ保持を避け、かつRaftの高可用性を活かすため、2つのデータ保持ノードと1つのWitnessノードという構成が組まれるようになり、同様のパターンは先述したようにGoogle Cloud Spannerでも見られます。
BigAnimalでも内部的に用いられているEDB Postgres DistributedでRaftが用いられており、複数リージョン間で高可用性を組む際に上図のような構成が取られています。
そして、注目すべき点として、BigAnimalではクラウドベンダーの障害に備えたWitnessノードの配置を行うことができます。つまり、データ保持を行うノードをAWSの2つのリージョンに配置し、WitnessノードをAzureのリージョンに配置することができます。
残念ながら、この構成ではクラウド間のデータ複製を行わないため、今回のクロスリージョンの定義には当てはまりませんが、限りなくそれに近い構成となっています。
TiDB Cloud
もう1つ、パラレルクラウドで展開しているDBaaSとして、PingCAP社のTiDB Cloudがあります。TiDB Cloudで利用可能なTiDBはChapter4で紹介したようにNewSQLの1つで、MySQL互換でスケーラビリティに優れた分散SQLデータベースです。ほかのNewSQLと同様に、TiDBも下記の複数のコンポーネントを組み合わせた複雑な構成を持ちます。
- TiDB：MySQL互換のクエリエンジンが稼働するComputeノード。データは保持せず、読み取りリクエストをTiKVまたはTiFlashへ送信する
- PD：Placement Driverの略で、クラスターのメタデータを保存する。トランザクションIDを発行し、分散トランザクションのコアコンポーネントでもある
- TiKV：データの保存を担当するStorageノード。分散トランザクションやRaftによるデータ冗長化などを担当し、Key-Valueの形で行データを格納している
- TiFlash：列形式でデータを保存して分析用途のクエリを高速化する。執筆時点ではTiKVと組み合わせて利用する必要がある
利用者がTiDBのノードに接続してSQLクエリを投入すると、TiDBではPDにあるメタデータなどを基にデータが格納されたTiKVやTiFlashから読み取りを行って実行結果を返します。データの更新時にはPDからトランザクション制御に必要な情報を取得し、整合性を保って書き込みを行います。
このようにComputeノードであるTiDBとストレージであるTiKVを分離した構成を取ることで、必要な部分だけをスケールアウトすることでパフォーマンス向上が可能です。また、TiKVノードではChapter4で説明したRaftによるデータ複製が行われており、障害発生時には迅速にほかのノードがLeader（リーダー）となって処理を継続します。
PingCAPが提供するTiDB Cloudも基本的な機能のそろったDBaaSで、上記のような複雑なコンポーネントをすべてマネージドで管理し、NewSQLに慣れていない利用者であっても導入が容易です。例えば、OLTP用にTiDBとTiKVで利用を始めたデータベースクラスターにTiFlashノードを追加することも可能です。
また、TiDB Cloudの大きな特徴として、サーバレスモデルの提供があります。クラスター作成時に「サーバレス（デフォルト）」と「専用」から選ぶことができ、サーバレス選択時にはほぼ難しい設定をせずに、データベースの利用を開始できます。「専用」のクラスター作成時には、TiDBやTiKV/TiFlashのノードのサイズや台数をカスタマイズしてデータベースを起動できます。
マルチクラウド観点でのTiDB Cloud
TiDB Cloudは執筆時点ではAWSおよびGoogle Cloudで利用でき、パラレルクラウドのパターンに適合します。利用者は自身のアプリケーションを配置するVPCとTiDB Cloudが展開されたVPCを接続し、データベースサービスにアクセスします。
TiDBは前述のとおり、高い可用性とスケーラビリティを実現したNewSQLの1つですが、分散トランザクションの仕組みに制約があり、広域の地理分散には非同期のレプリケーションを使うことが想定されています。そのため、執筆時点ではTiDB Cloudで提供している高可用性オプションはマルチデータセンターに限定されます。
次にTiDB Cloudのサービス構成とそれらに含まれるAZの関係図を示します。なお、TiDB CloudでPDは利用者から隠蔽されているため、図には登場していません。
次の図ではTiDBのサービスを提供するVPCの内部構造を示していますが、実際にはここに利用者のVPCからVPC PeeringやPrivateLinkを利用して接続することになります（AWS利用の場合）。
なお、TiDBのドキュメントにはTiCDC（Change Data Captureを提供するツール）を使ってクラスター間で非同期にデータを連携したり、バックアップを利用したりして他クラウドにデータを移すなどの災害対策の構成が紹介されており、そうした機能を利用したマルチリージョンやクロスクラウドの構成がTiDB Cloudで今後提供される可能性はあります。
SkySQL
SkySQLもこれまで紹介した2つのサービス同様に、パラレルクラウドで展開されているDBaaSです。執筆時点でSkySQLはAWSおよびGoogle Cloudで利用が可能です。日本国内で利用事例を見ることは稀ですが、DBMSとしてMySQLからフォーク（派生）されたOSSのデータベースであるMariaDBを使うことができます。SkySQLの内部で利用されているMariaDBはさまざまなコンポーネントを組み合わせて、マルチデータセンターの高可用性を実現していますが、そのうちの注目機能を紹介します。
Xpandは、高い可用性や書き込みのスケーリングを備えた分散SQLデータベースです。Xpandではテーブルのデータをスライスという単位に分割して、複数台のノードに配置します。スライスはさらに異なるノード間でレプリケーションされ、ノード障害からデータを保護します。ノード追加時にはスライスを自動的に再配置してスケールアウトを実現します。
MaxScaleは、高機能なデータベースプロキシでMariaDBのさまざまな拡張機能と組み合わせて利用されます。次図では分散SQLデータベースとしての複数ノードからなるXpandと、それらのプロキシとしてスケーラビリティや高可用性を提供するMaxScaleを組み合わせた構成が描かれています。
執筆時点でマルチリージョンで高い可用性を実現するデータベースクラスターを構成できませんが、クロスリージョンレプリカの機能を提供しており、広域災害に備えてデータ退避を行うことができます。
MariaDBとSkySQLの状況
MariaDBはMySQLと互換性が高いだけでなく、高可用性やスケーラビリティ、分析用途向けの機能などを独自に備えた興味深いデータベースです。しかし、近年運営が非常に不安定になっており、採用時には最新情報に基づく判断が必要です。前述したSkySQLの運営主体であるSkySQL Inc.は2023年12月にMariaDB社からスピンオフしていますが、こうした混乱のさなかにいるサービスであることは認識しておきましょう。
