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以降で解説します。
