「シングル・パラレル・クロス」各クラウドの構成パターンを解説──自社に適したマルチクラウド環境は？

用語の定義

　「マルチクラウド」という用語はデータベース以外の文脈でも使われる、意味の広い用語です。これを詳細化して定義します。

　すでに同様の定義を行っている例は海外を中心に存在しますが、最近のレポートとしてCockroach Labsが公開している“The State of Multi-Cloud 2024”があります。

　Cockroach Labsの定義によれば、Multi-cloudとは「少なくとも2つの異なるパブリッククラウドコンピューティングの環境を使用すること」であり、その中のアプリケーションの構成やデータ連携などについては何も言及されません。同レポートでは、Multi-cloudの中でも同一のアプリケーションの範囲内で異なるパブリッククラウドを使うことをIntercloudと定義しています。ここで言うアプリケーションにはさまざまなワークロードが含まれ、このワークロードごとに異なるクラウドを利用する状況、例えばOLTPではAWS、分析やレポート業務ではGoogle Cloudを利用するなどが想定されています。

　さらに狭義のMulti-cloudの定義として、Single-workload multi-cloud（SWMC）という概念も示されており、単一のワークロードを複数クラウドに展開する形を指しています。これはChapter4で示した「クラウド障害に対応した高い可用性」を示したマルチクラウドに近いものと言えるでしょう。

　このように、同レポートでは「Multi-cloud ＞ Intercloud ＞ SWMC」という包含関係が示されています。また、「クラウドストラテジー: クラウド移行を成功に導く意思決定に基づくアプローチ」という書籍では、マルチクラウドの選択肢として次のような分類を行っています。

　同書籍では、マルチクラウドを採用している企業でも最初からその形態を意図して始まるわけではなく、さまざまな経緯を経て統制の取れた（あるいは混乱期で無統制の）構成になっていることが示唆されています。つまり、マルチクラウドに任意に踏み出した後に、目的を明確化して分割や選択を行い、複数のクラウドにまたがる利用について並列と可搬の方式を検討していきます。

　Chapter4で解説したデータベースベンダーが各クラウドで同じサービスを利用可能にする展開は、上記の並列にあたります。また、「クラウド障害に耐える高い可用性」のために複数クラウドでデータを同期して切り替え可能とする構成は可搬にあたります。

　ここまで見てきた先行文献とChapter4までに整理してきた要件から、このChapterではデータベースサービスの文脈におけるマルチクラウド関連用語を次のように定義します。

　シングルクラウドの意味付けは簡単で、単一のクラウドベンダーにシステムすべてを配置することであり、データベースの文脈では単一クラウドでしか使えないDBaaSを使うことを指します。

　その反対の用語がマルチクラウドとなりますが、これはすでに書いてきたとおり、複数のクラウドをシステムにおいて活用する構成を指します。とくにデータベースだけに限定される用語でもなく、Section5-2で説明するアプリケーションサーバとデータベースが別々のクラウドに展開された構成もマルチクラウドです。

　パラレルクラウドについては、本書ではデータベースの文脈に限定して用います。複数のクラウドにデータベースを配置する構成を意味しますが、それぞれが連携しているか、データベース間でデータが同期されているかなどは問いません。この際、異なるクラウドに同じDBMSを用いたDBaaSが展開されており、例えば、PostgreSQLのDBaaSがAWSやAzure、Google Cloudで利用されているという状況を想定します。つまり、Chapter4でポータビリティがあると説明したDBaaSが展開されている状況を指して、パラレルクラウドと定義します。

　クロスクラウドは、「クラウド障害に対応した高い可用性」を実現するために、異なるクラウド間でデータを同期する構成を指します。こちらもパラレルクラウドと同様にデータベース文脈に限定して本書では用います。なお、クロスクラウドの構成であっても、その中に展開されるデータベースクラスターの配置、つまりノードやインスタンスをどのクラウドに配置するのかなど、さまざまなパターンがあります。

　以降で実際の構成例を解説していきます。

5-1-1 シングルクラウド

　まずはシングルクラウド、今回の文脈では単一のクラウドのみで構成されるDBaaSについて解説をします。つまり、AWSなどのベンダーが自クラウド内のみで利用することを前提に提供しているDBaaSが対象となりますが、これらの高可用性構成をパターンとして紹介するのには下記の理由があります。

　最終的にクラウド障害に耐える高い可用性を備えたクロスクラウドの構成に行きつくために、さまざまな構成パターンが考えられますが、実はそれらは技術的にはすでにシングルクラウドで実現されているものがほとんどです。クラウドベンダーがその技術を用いてクロスクラウド展開に乗り出さないのは、Chapter4で触れたようにDBaaS自体がクラウドの利用者を引き付ける差別化要因となっているからです。

　ここでは後ほど解説するクロスクラウドの理解を容易にするために、シングルクラウドにおける次の4つの高可用性パターンについて解説します。

• マルチデータセンターの同期レプリケーション
• クロスリージョンバックアップ＆リストア
• クロスリージョンリードレプリカ
• グローバルデータベース

マルチデータセンターの同期レプリケーション

　まず、1つめはマルチデータセンターの高可用性構成です。これはDBaaSにおける可用性向上パターンの代表的なものであり、多くのクラウドでマルチノードの構成パターンもここに含まれます。複数のデータセンターに配置されたノードを用いる構成で、センター間の距離は数10から100キロ圏内、レイテンシーとして1～5ms程度が想定されます。

　この比較的低いレイテンシーを前提にマルチデータセンターのパターンでは、障害発生時にもデータ消失が発生しない同期レプリケーションが採用されます。データベースの同期レプリケーションには、DBMSに実装された機能やストレージに実装されたものがあることはChapter4で説明しましたが、クラウドベンダーがマルチデータセンターで採用する方式はストレージによるレプリケーションが多いのが実情です。

　この構成を取る多くのDBaaSではRPOがゼロ、RTOが1～2分程度と高い可用性を実現できます。ただし、広域災害で対象のデータセンターがまとめて被災した場合にはデータが失われる可能性があります。

　クラウドベンダーが1つのリージョン内に複数のデータセンターを準備する必要があったり、それらの距離も上記のように限定されたりすることから、すべてのDBaaSで実現されるものではありませんが、シンプルでコスト対効果の高い可用性オプションです。

　クラウドベンダーにより機能名は異なりますが、マルチAZと呼ばれることが多い構成になります。ベンダーごとの機能名や詳細についてはChapter3をご参照ください。

クロスリージョンバックアップ＆リストア

　次に、マルチリージョンの構成が可能で、障害時の復旧時間やデータ消失の発生する期間が長いものの、コスト対効果の高いパターンとして考えられるのが、クロスリージョンバックアップとリストアを組み合わせた方法です。

　これはバックアップをデータベースが稼働しているリージョンで取得し、別リージョンにバックグラウンド処理で転送します。その後、復旧が必要なタイミングで別リージョン側でデータベースをリストアして起動します。この方式では別リージョン側のデータはバックアップ取得時点のものとなり、その後の障害時点までのデータが消失するため、RPOは数時間から1日程度となります。障害からの復旧時間もデータベースのリストアが必要になるため、RTOは30分から1時間以上となるケースが多いでしょう。

　こちらはデータベースのマルチリージョンというより、広域災害に備えたデータの退避や保護が主目的となる構成です。それでも、バックアップのインスタンスを起動する必要がないというコストメリットや構成の容易さから、最低限のマルチリージョン構成として選択される手法です。各クラウドのバックアップツールには、データのクロスリージョン転送機能を備えたものもあり、そちらもこの手法を採用する際に有用です。

クロスリージョンリードレプリカ

　バックアップ＆リストアから一歩進めたマルチリージョン構成がクロスリージョンリードレプリカです。この構成では別リージョンにリードレプリカが稼働しており、メインのリージョンから非同期でデータが更新されます。

　バックアップとの違いは、リードレプリカは独立したデータベースとして読み取り専用で起動している点です。リストアと起動の作業が不要となるため、障害復旧時間も短縮されます。非同期ではありますが、継続して同期されているため、障害発生の数秒前までのデータ復旧が可能です。

　また、別リージョンのリージョンで読み取りクエリを処理でき、アプリケーションの構成によってはリージョン間通信が減少するなど、性能向上に用いられます。

　このようにRPOは数秒から数分、RTOも別リージョンのデータベースを昇格させる処理だけであれば10分程度と、広域災害に備えた構成としてバランスに優れた構成に見えます。一方で、次のような点に注意が必要です。

　クロスリージョンリードレプリカの構成では、コスト削減のためにリソースを縮退しているケースが多く、また別リージョン側のデータベースはシングルインスタンスなど可用性を備えていない構成が取られます。そのため、次のように②の時点でデータの読み書きは可能になりますが、メインリージョンと同等の性能および可用性を備えるために、③の追加手順が必要となります。

① 障害発生

② クロスリージョンリードレプリカの昇格

③ 昇格後のデータベースのスケールアップ／高可用性構成

　もちろん、クロスリージョンリードレプリカ側にメインリージョン相当の構成を準備することも可能です。ただし、その場合はこの構成のコストメリットを放棄することになり、次のグローバルデータベース構成に近づきます。

グローバルデータベース

　シングルクラウドで提供されているマルチリージョン構成のうち、データをリージョンをまたがったクラスター間で非同期に更新しながら、障害時に迅速に切り替え可能とする方式がグローバルデータベースです。

　この例として、Chapter3で解説したAWSのAurora Global Databaseがあります。Global Databaseではメインリージョンにプライマリクラスター、その他のリージョンにセカンダリクラスターが配置されます。これは先述したクロスリージョンリードレプリカと異なり、切り替え後にもプライマリと同じサービスレベルでシステムを即時復旧させることが可能です。

　このようにグローバルデータベースはクロスリージョンリードレプリカと比較しても、RPOやRTOが一段階向上しており、可用性レベルが高いマルチリージョン構成に最適です。

　また、Google Cloud Spannerは方式こそ異なりますが、Chapter3で説明したようにマルチリージョンな配置が可能なデータベースの1つです。Cloud SpannerはChapter4で解説したように合意プロトコルを用いてレプリケーションを行うため、必ず3つ以上の奇数個のノードを必要とします。

　構成としてシングルリージョンのマルチゾーン配置をサポートしており、この場合はマルチデータセンターの同期レプリケーションのパターンと類似した可用性を持ちます。

　さらに広域災害に備えた構成として、マルチリージョンの構成をサポートします。この構成では少なくとも5つ以上のデータのレプリカを準備し、3つ以上のリージョンに分散して配置します。そのうち、2つのリージョンは読み取りと書き込みが可能ですが、3つめのリージョンにはWitnessという特殊なレプリカが配置されます。Witnessの役割については、後ほど解説します。

　3つのリージョンに分かれていることから、2つまでのリージョン障害に耐えられるように見えますが、合意プロトコルの仕組み上、1リージョンの障害に耐えることしかできず、Cloud Spannerのマルチリージョン構成は2つのリージョンにまたがるグローバルデータベースと同等の可用性となります。

　なお、Google CloudのブログではCross-Cloud InterConnectを通して、AWSからCloud Spannerを使う構成を紹介していますが、このようにInterConnectを使う構成はデータベースサービスの配置場所や可用性に影響を与えないため、シングルクラウドでの提供パターンと考えてよいでしょう。

　ほかのクラウドでのグローバルデータベースの例として、Azureではアクティブgeoレプリケーションと呼ばれる高い可用性を持ったデータベースを構成することが可能です。

　さて、シングルクラウドでの高可用性構成を4パターン説明してきましたが、原理的には同様の技術を用いて、複数クラウドにまたがるデータベースクラスターを構築することは可能です。

　例えば、同じ地域内にあるAWSとGoogle Cloudのデータセンターでレイテンシーの低い接続を実現できるのであれば、同期レプリケーションによる高可用性構成を組むのは難しいことではありません。同様に、一定時間のデータ消失（巻き戻し）や復旧時間が長時間掛かることが許容できるのであれば、AzureからOCIにバックアップデータを送ってリストアを行うことも可能です。

　このようにマルチクラウドの中でも実現が難しいと思われるクロスクラウドの構成についても、ここまで説明した4つのパターンを元に高可用性構成を検討することができます。その詳細については次のSection以降で解説します。

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つの可用性オプションについて解説します。

1. Single node
2. Primary/Standby high-availability
3. 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を組み合わせた構成が描かれています。

　執筆時点でマルチリージョンで高い可用性を実現するデータベースクラスターを構成できませんが、クロスリージョンレプリカの機能を提供しており、広域災害に備えてデータ退避を行うことができます。

5-1-3 クロスクラウド

　広域災害に備えたマルチリージョンや複数クラウドでDBaaSを展開するパラレルクラウドを超えて、「クラウド障害に対応した高い可用性」を実現する構成を当書籍ではクロスクラウドと定義しています。

　具体的には単一のクラウドだけでなく他のクラウドにもデータを何らかの方法・タイミングでレプリケーションし、クラウド障害が発生した際には別クラウドにデータベースをフェイルオーバーできなければなりません。

　このクロスクラウドは多くのデータベースで簡単な構成ではありません。そして、コストや運用面でマルチリージョンと同等以上の負担が発生するため、すべての企業で導入すべき必須の可用性構成かというと現時点でそうではありません。

　しかし、このような状況であっても、一部の（ハイエンドな）利用者の要望に応えて、「クラウド障害に対応した高い可用性」を備えたクロスクラウドなDBaaSがすでに登場しています。また、ここまで何度も登場しているNewSQLでは地理分散が主要な機能となっていることから、クロスクラウドにも高い親和性があります。

　ここからはその提供パターンを紹介し、実際にクロスクラウドを実現可能な構成について分析していきます。

Crunchy Bridge

　Crunchy BridgeはPostgreSQLを利用可能なDBaaSで、Crunchy Data社が運営しています。同社はPostgreSQLの高度なサポートも展開しており、DBaaSにもそれらのノウハウが盛り込まれています。

　基本的なDBaaSとして機能がそろっており、マルチデータセンターやマルチリージョンにも対応しているCrunchy Bridgeですが、珍しい機能として、PostgreSQLを分散データベースとして利用可能な拡張機能 Citusをサポートしています。これはChapter3で紹介したAzure Cosmos DBのAPI for PostgreSQLの中でも利用されており、非常に簡単に言えば、そちらと同等のスケーラビリティを提供します。

　また、Crunchy Data社はPostgreSQLをコンテナで稼働させるという取り組みを長年行ってきており、前述したKubernetes Operatorも開発しています。そうした技術力はCrunchy Bridgeにも活かされており、Postgres Container Appsという非常に変わった機能を提供しています。

　この機能はpgpodmanという拡張を利用して、「PostgreSQL内からコンテナを直接起動して実行」できます。PostgreSQL内のコンテナに何のメリットがあるのかと感じるかも知れませんが、通常のDBaaSではデータベースとしての接続はできるものの、OSレベルでアクセスしたり、データベースと同じサーバにソフトウェアをインストールすることはできません。

　Postgres Container Appsはこの制約を一部緩和するもので、例えばPostgreSQL内に管理ツールであるpgAdminのコンテナを起動することで、追加でノードを必要としない構成が紹介されています。

マルチクラウド観点でのCrunchy Bridge

　Crunchy BridgeはAWSやAzure、Google Cloudなどマルチクラウドなサービス展開を行っています。そして、Crunchy Bridgeの特徴として、Cross-cloud replication and redundancyをうたっていることがあげられます。

　Crunchy Bridgeのクロスクラウドは、執筆時点では「クロスクラウドリードレプリカ」です。シングルクラウドの項でクロスリージョンリードレプリカのパターンを紹介しましたが、それと同様に非同期のリードレプリカを、メインのデータベースクラスターが存在するクラウドとは別のクラウドに作成できます。

　メインのクラウドで障害が発生した際には、クロスクラウドリードレプリカをデタッチ（切り離し）することで、独立したデータベースインスタンスとして稼働させることができます。デタッチ後のインスタンスに高可用性を持たせたり、アプリケーションの接続データベースを変更したりするなどの手順は必要ですが、異なるクラウドでデータの復旧とシステムの再稼働が実現可能です。

　スタンバイとなるクラウド側に切り替え可能なデータベースクラスターを準備や、フェイルオーバーの自動化などは実現されていませんが、クロスクラウドでRPOの小さい（非同期のためゼロではありません）リードレプリカを運用する機能は、こうしたDBaaSとしては非常に貴重で価値の高いものとなっています。

クロスクラウドの可能性を拓くNewSQL

　残念ながら、以降で説明するものは執筆時点でクロスクラウドを実現したDBaaSではありません。しかし、Chapter4でその仕組みを解説したNewSQLには地理分散という特徴があり、これはマルチリージョン構成にとどまらず、クロスクラウドを実現する技術的な下地を持つものがいくつか見られます。

　ここではNewSQLの構成パターンをいくつか紹介し、それらがどのようにクロスクラウド展開されうるかについて解説します。

YugabyteDB

　最初に紹介するのは、Yugabyte社が開発している分散SQLデータベースのYuga byteDBです。DBMSとしてのYugabyteDBは後述するさまざまな可用性パターンを備えており、クロスクラウドにデータベースクラスターを構成できる能力があります。

　TiDBと同様にNewSQLの代表となるYugabyteDBは、PostgreSQLと高い互換性を持ち、高い可用性とスケーラビリティ、そしてデータを地理的に離れた箇所に分散可能なデータベースです。さらにほかのデータベースと異なる点としては、Cassandra互換のインターフェースを持ち、そちらに対応したアプリケーションからの接続も可能です。

　YugabyteDBの内部も複雑なコンポーネントに分かれており、メタデータの管理や構成管理を行うYB-Masterと、利用者からのリクエストを受け付けてデータ処理を行うYB-TServerが存在します。YB-TServerの中にはSQLおよびCassandraからのリクエストを処理するクエリエンジンと、ストレージエンジンとしてデータ格納を担当するDocDBが含まれます。ほかのNewSQLと同様に、ストレージ層のDocDBではRaftによるデータ複製が行われ、スケーラビリティと高い可用性を実現します。

　このYugabyteDBをDBaaSとして提供するのが、YugabyteDB Managedです。AWS、Azure、Google Cloudで利用できるパラレルクラウドの形で提供されています。DBaaSとしての基本的な機能を備え、マルチデータセンターやマルチリージョンなどで要求される可用性に応えるさまざまな構成が可能です。しかし、YugabyteDB Managedには「クラウド障害に備えた高い可用性を実現」する構成オプションは、執筆時点ではありません。

マルチクラウド観点でのYugabyteDB

　以降ではYugabyteDBの構成オプションを紹介し、それぞれがクロスクラウドに有用か否かについて解説します。

　1つめの可用性構成オプションは「ストレッチクラスター」です。これはもっとも基本的な構成で、YugabyteDBのクラスター（ユニバースとも呼ばれます）を複数のリージョンやクラウドにまたがって構成します。

　NewSQLの地理分散機能として一般的に紹介されるのもこの構成で、Raftによるデータ複製がリージョンやクラウドの境界を超えて行われます。その特性として過半数からの応答で処理を進められるため、構成次第ではActive-Standbyの同期レプリケーションと比較してレイテンシーが改善します。

　この構成では、Raftの特性により障害ノード数が許容数より少ない場合にはデータ消失が発生しません（RPO=0）。ただし、広域災害やクラウド障害で障害ノード数がその閾値を超えた場合には、データベースとして正常稼働を継続できないケースがあります。

　ストレッチクラスターを採用可能なのはレイテンシーの要件がシビアでないシステムで、そうしたケースではクロスクラウドで同期レプリケーションを行う構成は十分に有用です。要件次第ではインターネットVPN経由での接続が許容される可能性はありますが、低レイテンシーな閉域ネットワーク接続が望ましい構成です。

　ストレッチクラスターの派生形として考えられるのが、「Geoパーティショニング」の構成です。こちらでも1つのクラスターを複数のリージョンやクラウドにまたがって構成しますが、配置するデータを利用者が明示的にコントロールします。例えば、東京の顧客がアクセスするデータレコードは東京に配置し、大阪の顧客であれば大阪に配置します。

　この構成は利用者からのアクセスレイテンシーが改善するためにパフォーマンスの向上をもたらします。また、慎重に各リージョンやクラウドに配置するノード数を検討することで、例えば東京側に障害が発生した際に大阪での利用には影響を与えない構成とすることができます。

　この構成は同期レプリケーションであり、ストレッチクラスターと同様の条件でRPO=0を実現できます。データベース設計は難しくなりますが、構成次第でストレッチクラスターと比較してもレイテンシーをさらに改善でき、障害発生時にも全地域でサービス停止となることを防ぎます。

　次に紹介するのはYugabyteDBではxClusterと呼ばれる、「非同期クラスターレプリケーション」の機能です。この構成では、異なるリージョンやクラウド間でデータを非同期に更新し合います。各リージョン等には独立したデータベースクラスターが構成され、データの更新が発生するとそれを別クラスターに送信します。xClusterでは単方向と双方向でレプリケーションを構成できますが、双方向のレプリケーションを設定する際には更新の競合が発生する可能性があります。

　非同期クラスターレプリケーションの構成では、リージョンの障害発生時にデータ消失が発生する可能性があります。一方で各リージョンなどに整合性を保ったデータベースクラスターが稼働しているため、アプリケーションの切り替えは容易で、障害復旧時間は短縮できます。

　なお、非同期のため、クロスクラウドで採用してもシビアなレイテンシー要件を求められない構成でもあります（更新量に応じた帯域確保は必要）。この構成はシングルクラウドの項で説明したグローバルデータベースによく似ているため、そちらと同じ要件のシステムで採用可能です。

　最後のパターンは「リードレプリカ」です。これはここまでで説明した、クロスリージョン／クロスクラウドのリードレプリカと同じものです。非同期でデータを更新するため、リージョン障害時にデータ消失が発生する構成ですが、非同期クラスターレプリケーションよりもシンプルでコストも安価となります。復旧時に高可用性の組み込み手順が必要になる点なども同様で、障害復旧時間は長くなりますが、別リージョンやクラウドにデータを退避しておく用途としては最適です。

　マネージドサービスの実装の難易度としても比較的低いため、YugabyteDB Managedでもクロスクラウドな対応として、こちらが実装される可能性はあります。

　ここまで見てきたように、YugabyteDBはクロスクラウドのDBaaSを提供できる機能を十分に備えたデータベースです。YugabyteDB Managedでもクロスクラウドが実現されることを期待して待ちたいと思います。

CockroachDB

　NewSQLとしてもう1つ紹介するのは、Cockroach Labsが開発する分散SQLデータベースのCockroachDBです。CockroachDB CloudとしてDBaaSの形でも提供されていますが、YugabyteDBと同様に執筆時点ではクロスクラウドでの構成とはなっていません。

　CockroachDBはPostgreSQLとの互換性を持ち、高い可用性とスケーラビリティを実現したNewSQLの先駆け的な存在です。海外を中心に多くの導入実績があり、米国でマルチリージョンやマルチクラウドで構成された事例が同社ホームページで紹介されています。

　CockroachDBを利用する際の注意点としては、有償のエンタープライズ機能が提供されている点をあげておきます。エンタープライズ機能の中にはマルチリージョンに関わる機能や増分バックアップなど運用時にほぼ必須と思われる機能もあります。ライセンスについても、BSL（Bisiness Source License）とCCL（Cockroach Community License）のデュアルライセンスによる提供となっており、各バージョンのBSL部分がリリースから3年後にApache 2.0 Licenseに変換される形を取っています。

　CockroachDB CloudはDBaaSとして利用可能なCockroachDBの提供形態です。AWS、Azure、Google Cloudで利用可能なCockroachDB Cloudには2つの利用形態があり、1つはDedicatedとしてサーバを占有してクラスターを構築する方法、そしてもう1つがサーバレスで利用する方法です。本番稼働としての利用にはDedicatedの利用が推奨されており、サーバレスでは使えるクラウドベンダーがAWSとGoogle Cloudに限定されていたり、その他利用できない機能があったりします。

マルチクラウド観点でのCockroachDB

　CockroachDBは可用性構成オプションとして、YugabyteDBとほぼ同等の機能を備えています。

　同期レプリケーションであるストレッチクラスターはCockroachDBのマルチリージョン構成でよく用いられるパターンであり、Geoパーティショニングもレコードやテーブルなどの単位で柔軟に設定が可能です。

　なお、データの地理分散の観点で、CockroachDBは他DBMSと比較しても豊富で興味深い機能を有しています。例えば、執筆時点ではプレビューのスーパーリージョンという機能がありますが、これは例えばAWSなどのリージョンをヨーロッパなどの特定地域でグルーピングしてデータの保護に利用します。

　具体例として、アメリカ‐イギリス‐オーストラリアの3リージョンでストレッチクラスターを組んだ場合にはデータがEU圏外に複製され、コンプライアンスの要件を満たさないケースがあります。この際にEUでイギリス‐スウェーデン‐イタリアから成るスーパーリージョンを構成します。これにより、イギリスで書き込まれたデータはEU圏内の3つのリージョンで複製され、障害にも耐える可用性が担保されます。もちろん、アメリカやオーストラリアにデータの複製は行われません。そして、スーパーリージョンはアメリカ、オーストラリアとも接続されるストレッチクラスターの構成に含まれ、グローバルなデータベース展開はそのまま維持されます。

　ほかにも非同期クラスターレプリケーションの機能は、CockroachDBではPhysical Cluster Replicationと呼ばれており、執筆時点ではプレビューです。機能もYugabyteDBのxClusterと若干の違いがあり、Physical Cluster Replicationでは各データベースクラスターがActiveとStandbyの役割を持ち、双方向に更新を同期しあう構成は取ることができません。

　なお、執筆時点ではCockroachDBにリードレプリカの機能はありません。NewSQLの特性として、Leaderを1ノードとFollowerを2ノード（全体で3ノード）で構成した場合にFollowerに少し古いデータを読みに行くStale Readと呼ばれる機能がありますが、これを利用したレプリカ自体は可能です。YugabyteDBのようなRaftに参加しないシンプルな非同期のリードレプリカは備えていません。

　YugabyteDBとアプローチに若干の違いがあるものの、CockroachDBにはスーパーリージョンのようにかゆい所に手が届く機能を用意し、マルチリージョンと真っ向から向き合う姿勢が見られます。これはすなわち、クロスクラウドでもそのまま活かせる機能群をすでに持っており、マネージドサービスへの展開を待っている状況だと筆者は考えています。

5-1-4 現実的なクロスクラウドの選択肢

　前のセクションではマルチクラウドなデータベースでも、難度が高く、多くのベンダーでサービス化が実現していないクロスクラウドの構成について、NewSQLがもたらす新たな可能性に言及しました。

　ここでは先ほど紹介したNewSQLの可用性構成パターンをベースに、クロスクラウドなDBaaSが現実的にどのような構成を取りうるかについて、いくつかの種類に分けて解説していきます。この分類にはクロスクラウドという軸に加えて、リージョンの概念を追加します。つまり、次の2つに大きく分かれます。

• シングルリージョン＋クロスクラウド
• マルチリージョン＋クロスクラウド

　それぞれの構成で推奨される可用性構成パターンについて、解説をしていきます。

シングルリージョン＋クロスクラウド

　まず、クロスクラウドの構成で考えられるのが、シングルリージョンにデータベースクラスターがすべて収まる構成です。シングルクラウドの節で見たように、同一リージョン内のマルチデータセンター間では同期レプリケーションが多く使われます。これにより、障害時にもデータ消失が発生しないという大きなメリットを享受できます。

　これをクロスクラウドに拡張した場合も基本的な考え方は同様で、クラウド間をつなぐ低レイテンシーな閉域ネットワーク接続（1-5ms程度のレイテンシー）を活かして、同期レプリケーションを構成します。ここで、クロスクラウドで利用するクラウドベンダーを2つにするのか3つにするのか、それぞれにいくつのノードを配置するかは重要な検討ポイントとなります。

　まず、シングルリージョン＋クロスクラウドでクラウドベンダーは2社である場合について考えてみましょう。NewSQLの仕組みとして説明したように、データベースクラスターに必要なノード数は最小3の奇数台です。この場合、メインとなるクラウドベンダーに2つ（過半数）のノードを配置し、スタンバイに残り1つを配置します。同一のリージョン内で異なるクラウド間を高速に接続する閉域ネットワーク接続が利用できる場合には現実的な構成です。

　この構成のメリットは、通常時はメインとなるクラウド内の合意で高速に処理が進み、クラウド障害に備えてデータの複製もされる点です。そして、1台のノード障害時ではメインからサブへクラウドの切り替えも発生しません（DB②がLeaderとなる場合）。

　一方、デメリットとして、メインクラウドの障害時にはデータベースの稼働に必要なノード数が確保できません。メインクラウドが全く使えない場合にはデータベースクラスターを再構成する必要があります。

　シングルリージョン＋クロスクラウドでベンダー2社のケースでは、データ消失の発生を許容し、障害復旧時間を短縮するために非同期クラスターレプリケーションを用いることは次善の選択肢です。つまり、メインとサブのクラウドに1つずつ独立したデータベースクラスター（最低3ノード）を配置することになります。

　また、障害復旧時間はある程度長くても許される場合には、シングルリージョンであっても別クラウドにリードレプリカを配置して、データの退避のみを行うという考え方もあります。

　データ消失もなし、障害復旧時間も最短で考える場合に有力な選択肢は、シングルリージョン＋クロスクラウドの構成でクラウドベンダーを3社にするパターンです。この場合、クラウドベンダーに2つまたは1つのノードを配置して、最低5台でデータの複製を行います。

　ここでクラウドベンダーが2社から3社に増えると、なぜ合計ノード数が3台から5台になるのか、不思議に思うかも知れません。これはノード1台で障害が発生した際にメインからサブのクラウド切り替えが発生してしまうことを防止するためです。例えば、DB①が障害となった場合、DB②がLeaderとなることで、クラウド1からクラウド2や3への切り替えは不要になります。

　こちらの構成は、シングルクラウドのグローバルデータベース例として紹介したGoogleのCloud Spannerのマルチリージョンによく似た構成となります。特性も同様で、クラウドベンダー2社のパターンと比較して常にクラウド間の合意を待つためにレイテンシーは劣化しますが、可用性は向上します。この構成を取る場合、単一のクラウドベンダー障害はデータベースの稼働に影響を与えません。

マルチリージョン＋クロスクラウド

　クロスクラウドで考えられるもう1つの構成が、マルチリージョンかつクロスクラウドというデータベース構成です。

　この場合、クラウド間のレイテンシーは構成決定の主因ではなく、リージョン間のレイテンシーの影響が大きくなります。そのため、マルチリージョンでよく採用される非同期クラスターレプリケーションが有用な選択肢となります。

　メインクラウド（メインリージョン）にプライマリのデータベースクラスターを配置し、別クラウド（サブリージョン）のクラスターに非同期でデータを更新します。この場合、クラウドベンダーは最低限の2社で十分で、3社に分散しても可用性向上には余り寄与しません。クラウド間で非同期レプリケーションを用いることから、シングルクラウドのグローバルデータベースのケースと同様に、データ消失が発生する可能性はあります。しかし、クラウド／リージョン間のレイテンシーがパフォーマンスに影響を与えないため、バランスの取れた構成と言えます。

　次善の選択肢となるのは、マルチリージョン＋クロスクラウドでもストレッチクラスターを採用する構成です。リージョン間のレイテンシーがパフォーマンスに与える影響を許容でき、加えて構成には3つのリージョンを準備する必要があります。次に紹介するのは、3つのクラウドベンダーと3つのリージョンに2つまたは1つのノードを配置する構成です。

　ここで全体のノード数が3台から5台に増えているのは、シングルリージョン＋クロスクラウドの項での説明と同様の理由になります。

　この構成ではクラウドベンダーの障害も、1リージョンが全断する広域災害でもデータベースの稼働が可能です。しかし、合意に必要な通信が必ずクラウドとリージョンをまたぐため、レイテンシーがパフォーマンスに与える影響は大きくなります。可用性を非常に重視するパターンで採用に値する構成です。

　なお、ここまでで説明したシングルリージョン＋クロスクラウド、マルチリージョン＋クロスクラウドの構成は、執筆時点で存在するDBaaSでは実現されていません。しかし、ベンダーが今後発表する新しい可用性構成オプションを評価する際に有用な指標となりますので、現時点で検討を行うことは無駄にはなりません。

クロスクラウド構成の注意点

　ここまでクロスクラウドを「クラウド障害に対応した高い可用性」を実現するものとして、メリットばかりを紹介してきましたが、ほかの技術がそうであるようにすべての人がデメリットなく取り入れられる構成ではありません。

　まず、考えられるクロスクラウドのデメリットはコストの増大です。Chapter2で紹介したように、現在のクラウドの料金体系ではアウトバウンド通信にコストが掛かります。異なるAZやリージョンへの通信にもコストが掛かるケースがありますので、そちらも利用するクラウドの料金体系を確認してください。

　とくにレイテンシーを小さくするために、ここまでの構成ではインターコネクト（閉域ネットワーク接続）を利用することを推奨してきましたが、この場合は通信料金が最も高額になります。クロスクラウドの構成を取るにあたって、通信料金はデータベースのノード間で同期されるデータ量に大きく依存します。データ保護の観点からは遅延を許容して、更新をまとめて同期することもできません。

　このコストを下げるために現状で可能なことは、このChapterで何度か説明しているWitnessノードの利用です。クロスクラウドの構成でもWitnessノードが配置されたクラウドにデータを送る必要はなく、その分のコスト削減が可能です。

　ただし、執筆時点でWitnessノードを利用可能なデータベースはGoogle Cloud SpannerやEDB Postgres Distributedなどに限定されており、クロスクラウドに展開したいNewSQLの多くで実装されていません。

　もう1つ考えられるクロスクラウドのデメリットは、データベースのセキュリティです。セキュリティの観点では、クロスクラウドの構成を取る場合にクラウド間接続の経路安全性について慎重に検討する必要があります。通信の傍受のリスクも高まりますし、ノード間のレプリケーションで暗号化通信が行われているかも確認すべきポイントです。

　また、複数のクラウドを利用するにあたって、権限付与などのアカウントに関する設定が異なっている場合があります。一方のクラウドでは適切な権限が与えられているアカウントしかデータが見えない状態になっていても、クロスクラウドで複製されている別のクラウドで同様の制御ができているかは、利用者の責任で確認すべき事項となります。

マルチクラウドは万人のものか？

　コストの増加とセキュリティ以外にも、運用の煩雑さなどクロスクラウドのデメリットはいろいろと考えられます。そこで読者は次のような疑問を抱くはずです。

• 「マルチクラウドは誰にでも必要になるのか？」
• 「マルチクラウドは自分の会社に必要なのか？」

　筆者は「現時点で必要な企業は限られるが、備えておくべき」だと考えています。

　データベースに限らず多くの技術がそうであったように、登場してすぐに利用に踏み切る企業は多くありません。しかし、当該技術の発展により導入の敷居が下がり、気づくと一般化している事例はこれまでにも多くありました。

　NewSQLもこのような発展が現在進行形で続いています。

　筆者も数年前には「NewSQLって数ペタバイトの巨大なデータを持つ、グローバルな企業が使うものでしょう？」という質問を受けました。その際に、「備えておくべき技術です。データベースの移行はビジネス拡大後に行うにはリスクが高く、当初からscale-out readyなデータベースを評価しておくことには価値があります」と回答していましたが、2023年には実際にNewSQLの導入や検証を行う企業が増加し、当時考えていた未来は実現しつつあります。

　同じことはマルチクラウドにも言えます。現在、重要なシステムのデータベースでマルチデータセンターの構成を取らない利用者はほとんどいないと思いますが、技術の進展やコスト体系の変化などに後押しされて、同様の意識の変化がマルチクラウドに訪れる可能性はあります。

Amazon

SEshop

マルチクラウドデータベースの教科書 クラウドロックインを乗り越えるデータベース構築ノウハウ

朝日英彦、小林隆浩、矢野純平 著
出版社：翔泳社
発売日：2024年8月6日
価格：3,740円（税込）

本書について

　マルチクラウドにおける、現代的なデータベース構築・設計を解説する書籍です。4大クラウド（AWS, Microsoft Azure, Google Cloud, Olacle Cloud Infrastructure）のDBaaSの解説はもちろん、データベースの観点からマルチクラウドの優位性や課題を紹介します。

本書の特徴

• マルチクラウドジャーニーを徹底解説：データベースという視点から一段登って、システム全体を俯瞰してマルチクラウドを推進する際に必要な点を整理しています
• DBaaSを網羅的に紹介：発行時点でのDBaaSの特徴を保存したスナップショットとして、クラウド選定時やDBaaS選定時に活用いただけます
• マルチクラウドで利用可能なDBaaS、その構成パターンを紹介：現時点で採用可能な構成パターンを本書にまとめました。マルチクラウドデータベースのもたらす価値も丁寧にまとめています