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