マルチクラウド環境で高可用性を実現するデータベースサービスとは：クラウドネイティブ時代のデータベース（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対応データサービス」とは