マルチクラウド環境で高可用性を実現するデータベースサービスとは：クラウドネイティブ時代のデータベース（3）

クラウドネイティブ時代に求められるデータベースを解説する本連載。第1回でデータベースの要件として求められる「アジリティ、可用性、拡張性」を解説し、第2回で具体例としてPostgreSQL on Kubernetesを紹介した。今回はマルチクラウドを目的としたデータベースサービスを概観する。

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

マルチクラウド環境におけるデータ複製をどう実現するか

　前回記事では、PostgreSQLをコンテナオーケストレータのKubernetesと組み合わせて使うことで、運用管理の自動化や可用性、拡張性の向上を実現する方法を紹介した。クラウドネイティブの中核となるコンテナ技術を用いて、データベースでも構成管理などのアジリティを高めることができる。

　今回は、さらに高い可用性を実現して事業継続性を支えるデータベースサービスについて論じる。

　連載初回で挙げたように、クラウドネイティブなシステムでは基盤となるクラウド事業者の障害やその原因となる広域災害に備える必要が生まれてきている。以前から一部の大企業ではアプリケーションを地理的に分散し、複数のクラウド事業者間にまたがってデータを保護する取り組みを行っているが、その実現には非常にコストがかかってきた。また、障害が発生した際の運用も煩雑で同様の構成を取るのは容易でなかった。

　しかし、ここ1年で状況は大きく変わりつつある。

　まず、クラウドベンダーやその他の事業者により、複数のクラウドにまたがってKubernetesクラスタを管理する機能の提供が始まっている。「Google Anthos」（参考記事）や「Cast.ai」などがその例となる。こうしたサービスでは、Amazon Web Services（AWS）やGoogle Cloud、Microsoft Azureなどの主要パブリッククラウドはもちろん、オンプレミスやエッジなどの環境にKubernetesクラスタを展開して管理可能になっている。ユーザーは使い慣れたコンソールから複数のクラウド事業者や自社データセンター上のクラスタをモニタリングし、障害発生時にはKubernetesがもたらすアプリケーションのポータビリティを生かして復旧作業が可能になる。

　そして、この「マルチクラウドにおけるクラスタ管理」という文脈で、特筆すべきデータベースサービスを展開しているのが、Microsoftの「Azure Arc」だ（サービス内容は後半で詳述する）。

　マルチクラウドの観点でもう一歩踏み込むと、複数クラウドのクラスタを効率的に管理するだけではビジネスに求められる復旧時間の目標、つまり事業継続性を満たせないケースが出てくる。データがメインのクラウド事業者から定期的に退避されていたとしても、障害時にビジネス再開まで24時間以上かかる（つまり、サービスが24時間停止する）状況を許容できないとしたら、どのような対応が取れるだろうか。

　この場合、リアルタイムに近い形でデータを異なる地域、そして異なるクラウド事業者に複製する必要性が生じる。そうした「マルチクラウドにおけるデータ複製」をマネージドサービスとして提供する例として、今回は「Crunchy Bridge」を紹介する。

　ここまでの話をおさらいしておこう。マルチクラウドにおけるデータベースサービスでは、クラスタ管理とデータ複製という2つの視点があり、それぞれが実現する可用性と事業継続性は異なる。その関係は下図のようになる。当記事の後半ではそれぞれの例となるサービスを一つずつ紹介していく。

マルチクラウドにおける「クラスタ管理」と「データ複製」のイメージ

コラム：マルチクラウドおよびマルチリージョンの必要性

　初回記事を公開後「当連載で対象とするような高い可用性が必要なユースケースはどれ程あるのか？」という疑問の声を聞くことがあった。今回紹介するサービスを用いても、マルチクラウドやマルチリージョンの構成は依然として高コストで運用も複雑となるため、全てのビジネスで考慮すべき必要はないという指摘はその通りだ。

　しかし、障害がクラウド事業者に起因するとしても、データ消失や長時間のサービス停止が起きた際には事業の信用を大きく損なうケースがあると筆者は考える。

　こちらの記事ではBox Zones Japanの例が紹介されている。コンプライアンスに主眼を置いた記事だが、日本国内で東京のAWSをメイン、大阪のAzureをバックアップとして構成していることが分かる。事業継続性を重視して、マルチクラウドおよびマルチリージョンでデータ複製を行っている好例といえるだろう。

クラスタ管理を実現する「Azure Arc対応データサービス」とは

　まずはマルチクラウドにおけるデータベースのクラスタ管理を実現する「Azure Arc対応データサービス」を紹介する（2021年5月時点ではプレビューとなっている）。

　Azure ArcはMicrosoftが提供している、Linuxサーバ／Windowsサーバ／Kubernetesクラスタの統合管理を実現するサービスだ。その対象はAzureを含むパブリッククラウドやオンプレミス、エッジなど広範にわたる。Azure Arcの詳細な解説は割愛するが、こちらの紹介が分かりやすい。その中にあるAzure Arc対応データサービスは簡単にいえば「Hyperscale（Citus）」などのAzureのデータベースサービスを「Kubernetesがあればどこででも」稼働させるものだ。

　先ほど図示したように、Azure Arc対応データサービスでは、データベースのデプロイと運用はAzure Arcで行うものの、実際にそれらが稼働するKubernetesクラスタはAzureの外側に配置することができる。つまり、マネージドサービス自体が「Database on Kubernetes」の形で実現している。

　2021年5月末現在、Azure Arc対応データサービスで利用可能なのは「Azure SQL Managed Instance」と「Azure PostgreSQL Hyperscale」の2種類である。また、複数のクラウド事業者にまたがってデータを自動で複製する構成、例えばAzureとAWSでデータ同期する構成を構築することはできない。しかし、パブリッククラウドでも、オンプレミスでも同様の管理コンソールから大規模データに対応したDBaaS（Database as a Service）を構築、運用するメリットは大きい。特に、特定地域外にデータを持ちだせない要件や、すでに他クラウドにアプリケーションを構築済であってもAzure固有のデータサービスを利用したいケースなどで有用となる。

　なお「Azure Database for PostgreSQL」には、シングルサーバ／フレキシブルサーバ／Hyperscale（Citus）の3つのデプロイモデルがあり、中でもHyperscale（Citus）はシャーディングの技術に基づく拡張性に優れた分散型データベースである。このような数十のノードからなる大規模なデータベースクラスタを、Azure以外のクラウド事業者やオンプレミスなどを対象として管理可能とするのがAzure Arc対応データサービスの大きなメリットとなるだろう。同様の構成は第2回で紹介したPostgreSQL on Kubernetesの形でも実現できる可能性はあるものの、それには分散データベースとKubernetesの両方を理解する高度な技術者が必要となる。

フルマネージドのPostgreSQLをデプロイできるCrunchy Bridge

　ここまで述べたようにAzure Arc対応のデータベースサービスではクラスタ管理を一元化するものの、クラウド事業者間のデータ複製を自動で実行することや、データ複製をサポートする機能を有していない。そのため、データベースクラスタが構築されたクラウド事業者で大規模な障害が発生すれば、システムのダウンタイムは長くなってしまう。また、マルチリージョンに対応したマネージドサービスとして、AWSの「Aurora Global Database」やGoogleの「Cloud Spanner」などがあるが、こちらも同じようにクラウド事業者の障害で不安定となるケースがある。

　マルチクラウドにおけるデータベースのクラスタ管理はもちろん、複数クラウド事業者をまたいだデータ複製を現時点で実現しているサービスとして筆者が注目しているのが「Crunchy Bridge」だ。これはPostgreSQLの開発、サポートで世界有数の企業であるCrunchy Dataが提供するPostgreSQLのマネージドサービスだ。Crunchy Data社は第2回で紹介した「PostgreSQL Operator」を開発するなど、Database on Kubernetesの構成の普及について積極的な情報発信をしている。

　Crunchy BridgeではAWSやAzure、Google CloudにフルマネージドのPostgreSQLをデプロイできる。そうした意味ではAzure Arc対応データサービスのように、データベースクラスタを一元管理するサービスともいえるが、さらにマルチリージョンおよびマルチクラウドでクロスクラウドのレプリケーションを構成できることが大きな特徴だ。特定地域やクラウド事業者の障害が発生した際には、スタンバイを昇格させることでシステムのダウンタイムを抑えることが可能となる（なお、クロスクラウドのレプリケーションは現在限定された顧客で提供中とのこと）。

Crunchy Bridgeのクラウドとリージョンの選択画面

　クラウドネイティブの実現が求められる今でも、マルチリージョンかつマルチクラウドのデータベースをユーザーが自前で準備するのは大きな投資が必要だった。しかし、Crunchy Bridgeのようなサービスを上手に利用することで、Box Zones Japanのように事業継続性を重視したシステム構成に近づけていていくことが可能となる。

　なお、ここまでに紹介したAzure Arc対応データサービスもCrunchy BridgeもデータベースとしてはPostgreSQL（とその拡張機能）を提供するものだ。そのため、プラットフォームがクラウドネイティブ化された恩恵を十分に生かしているとは言えない部分はどうしても存在する。そうした課題に関しては、次回の連載最終回で触れる予定だ。

まとめ

　今回は、マルチクラウドで展開が可能なデータベースサービスを解説した。これらはクラウドネイティブなアプリケーションの可用性を高め、事業継続性を維持するために必要なコンポーネントだ。

　全ての場面でこうしたサービスが必要となるわけではないが、クラウドのメリットを生かした管理が容易で低コストのマルチクラウドに適したマネージドサービスの登場により、一部の大企業しか実現できていなかった構成を広く普及させる可能性を秘めている。

　現状でも特定のクラウド事業者でしか利用できないサービスは多く存在するが、Kubernetesがプラットフォームとなってそれらを他の場所（オンプレミスやマルチクラウドなど）で展開する構成も出てきており、データベースサービスの選択肢はさらに広がっていくものだと筆者は考えている。

　なお、今回記事では従来型のリレーショナルデータベースの可用性を高めたサービスを紹介したが、それ以外にも新しい形のサービスを提供する事例が見られるようになってきている。

　最終回ではそうしたデータベースを「NewSQL」として整理し、これまでの技術との違いや使いどころなどを解説していく予定だ。