クラウドネイティブ時代、データベースに求められる要件を整理する：クラウドネイティブ時代のデータベース（1）

クラウドネイティブは、その要素技術としてコンテナやマイクロサービスなどを含んでおり、近年の開発において一般的となりつつある。では、データベースにもそうした技術要素は取り込まれていくのだろうか。本連載では、クラウドネイティブ時代のデータベース設計で考慮すべきポイントを検討する。

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

　クラウドネイティブとは、「スケーラブルなアプリケーションを構築および実行する能力を組織にもたらす」考え方として定義される（参考記事：「クラウドネイティブ」はどう誤解されているか）。そして、そこに含まれる技術要素として、コンテナ、サービスメッシュ、イミュータブルインフラストラクチャ、宣言型API、マイクロサービスアーキテクチャ（以後、MSA）があり、その採用はシステム構成に大きな変化をもたらす。

　MSAでは分割されたサービスがメッセージをやりとりしながら協調的に動作する。開発はサービス単位で進み、継続的インテグレーション／継続的デリバリー（CI/CD）と組み合わせることでアプリケーションを高頻度でリリースすることが可能になる。こうしたサービス単位の管理性とアジリティの向上がMSAの目的だ。また、障害発生時はサービス内に影響を閉じ込め、ボトルネックを個別に拡張できるなど、理想的に設計されたMSAは可用性と拡張性を備えている。

　では、本連載のテーマであるデータベース（DB）の観点で見ると、MSA採用で検討すべきポイントは何だろうか。

　それは「Database per Service」といわれる原則である。マイクロサービス1つに1つのDBを備える構成を指し、複数のサービスが単一DBを共用する形はアンチパターンになる。企業システムで使われてきたリレーショナルデータベース（RDB）はクラスタ機能により高い可用性や拡張性を実現してきたが、単一の巨大なDBのみで構成すると、アプリケーションの依存関係がDBに波及し、マイクロサービスの管理性、アジリティを損なってしまう。

　一方で、分割されたDBをサービスのリリース頻度にあわせて構築、改修して障害時に復旧できるように運用、管理することや、負荷に応じて拡張させるのは簡単なことではない。こうした問題認識を踏まえて、クラウドネイティブな時代に求められるDBの要件整理を試みる。

マイクロサービスアーキテクチャの概要と特徴

クラウドネイティブ時代に求められるDBの要件

アジリティ

　アプリケーションはクラウドネイティブへの対応を進め、開発のアジリティを向上できるサービス単位に分割できたと仮定しよう。さらにアプリケーションはコンテナ化され、CI/CDでさまざまな環境に安全にデプロイされる。

　だが、DBにおいて分割とコンテナ化を進めてCI/CDを実現するのは容易ではない。状態を保持しないアプリケーションとは異なり、DBはデータの整合性を保ち、永続化する責務を負うからだ。そのためバックアップなどの運用が必須で、デプロイ時もデータコピーといった特別な手順がセットとなる。

　端的にいえば、コンテナ技術で手間のかからない家畜（cattle）となったアプリケーションとは対称に、DBは手間のかかるペットであり、それらを省力化してアジリティを高めるプラットフォームがクラウドネイティブなDBには必要となる。

高い可用性

　今も昔もDBに求められるのは、企業の重要なデータを保護してサービスを継続するための冗長性と高い可用性だ。

　そのために、DBはレプリカを持ち、プライマリーDBの障害時には即座に切り替えられる仕組みが必要だ。多くのDBはこの機能を備えるが、クラウドネイティブなシステムでは新たな要件が加わる。つまりプラットフォームを提供するクラウド事業者の障害や、その原因となる広域災害に備える必要が生まれてきている。

　こうした可用性の要件を満たすのがマルチクラウドやマルチリージョンと呼ばれるアーキテクチャだ。しかし、距離のある環境間でデータを複製させて、さまざまな障害発生時にデータを失うことなく整合性を保証するのは技術的に困難かつパフォーマンスに悪影響を及ぼすこともある。

　こうした地理的な分散による可用性の向上はクラウドネイティブ時代のDBに求められることは増えつつあるものの、対応が十分ではない領域だ。

水平方向の拡張性

　クラウドネイティブやMSAといった文脈で、スケーラビリティは非常に重要な概念であり、システムが持つべき性質とされる。

　一方、RDBは、強い整合性と可用性を提供する反面、水平方向の拡張を苦手としてきた。特にプライマリー（データの読み書きが可能）とレプリカ（データの読み取りのみが可能）の間に明確な役割の違いがあり、読み取り性能は比較的簡単に拡張ができるものの、書き込みの性能向上が課題とされてきた。

　こうした課題を解消するためにNoSQLと呼ばれるスケールアウトを得意とするDBも存在するが、トランザクションの特性が異なるなど、RDBを置き換えるものよりも補完するものとしてシステム中に併存している。

　MSAの背後で局所的にスケールアウトでき、読み書き両方の柔軟な拡張性を備えたRDBがあれば、クラウドネイティブなシステムを構築する上で大きな助けとなるだろう。

アジリティ、可用性、拡張性を実現するために

　では、これまで述べてきた3つの要件をRDBで満たすには、どのような選択肢を取りえるだろうか。

　現実的な選択肢は、各クラウド事業者が提供するマネージドDBサービス（いわゆるDBaaS）を用いることである。例えば、Amazon Web Services（AWS）は「Amazon Relational Database Service」（RDS）を提供している。RDSを用いることでAPIを用いたコントロール、Multi-AZ構成やAurora Global Databaseなどが備える高い可用性、そしてリードレプリカなどによるオンデマンドな拡張を実現できる。

　Google CloudではマネージドDBサービスとして「Cloud SQL」の他に、99.999％の高い可用性（3つのリージョンにデータのレプリカを持つ）と無制限とされるスケーラビリティを持つ「Cloud Spanner」を提供している。

　AWS、Google Cloud、そしてMicrosoft AzureそれぞれのDBaaSの特徴を下表に簡単にまとめる。

クラウドプロバイダー	サービス名	可用性	拡張性
AWS	RDS	データセンターレベルの障害に耐える、マルチAZ構成が可能	スケールアップ、リードレプリカ
	RDS(Aurora)	リージョン障害に耐える、Global Databaseなどを構成可能	自動化されたスケールアップ、リードレプリカ
Google Cloud	Cloud SQL	別のゾーン／リージョンにスタンバイを配置し、HA（高可用性）構成が可能	スケールアップ、リードレプリカ
	Cloud Spanner	リージョン障害にも耐える、マルチリージョン構成	自動的なスケールアウト（データのリバランシングを含む）
Microsoft Azure	Azure Database	Single Serverでは、1つの可用性ゾーンに配置される	スケールアップ、リードレプリカ
		Flexible Serverでは、複数の可用性ゾーンにまたがった配置が可能	スケールアップ、リードレプリカ
		Hyperscale(Citus)では、1つの可用性ゾーン内でHA（高可用性）構成が可能	スケールアウトが可能

※表の対象はRDBに限定した。また、AzureについてはPostgreSQLをエンジンとするサービスに限定した。

　クラウドネイティブなアーキテクチャにおいて、こうしたDBaaSを活用することは必須条件であるが、一方でそれらが全てのアプリケーションの要件を満たすものではないと考える。そこで本連載では、オーソドックスなDBaaSとは少し異なる形の、クラウドネイティブ時代のDBに踏み込んで各回で紹介していく。

　ここからは、第2回以降の概要を説明していくこととしよう。

第2回：PostgreSQL on Kubernetes

　クラウドネイティブなプラットフォームで主流となったのが「Kubernetes」だ。コンテナ化されたアプリケーションを柔軟にデプロイでき、エコシステムとして開発されたツールを用いて機能拡張が可能である。

　第2回ではDBとして「PostgreSQL」を取り上げ、そのKubernetes対応について、日本で先進的な取り組みを続けているエンジニアが解説する。KubernetesはDBのようなステートフルなソフトウェアを管理するために、Operatorという仕組みが提供されている。これを用いて、ステートレスなアプリケーション同様のアジリティと、DBで必要とされる特別な手順・運用の省力化を実現している。

　もちろん、Operatorを用いた開発、サポートにはKubernetesとDBの高度な知識を持つ必要があり、長年オープンソースソフトウェア（OSS）サポートを担ってきたベンダーによる提供体制もポイントになる。こうした最新の動向も紹介する予定だ。

第3回：マルチクラウド＆マルチリージョン

　複数のクラウド事業者、そして複数の地域（リージョン）にDBを配置することは、ユーザー自身でも実現可能なものの、初期構築、運用ともに大きなコスト負担を強いられる。

　第3回では、マルチクラウドまたはマルチリージョンの高い可用性を実現しているマネージドサービスを幾つか紹介する。これらのサービスではユーザーが複数のクラウドリージョンを選んでDBを展開でき、特定のクラウド事業者に障害が発生しても、別クラウドに切り替えが可能である。

　また、これらのマネージドサービスの中には、プラットフォームとしてKubernetesを用いているものが存在する。そうした例として代表的な「Azure Arc Enabled Data Services」などの解説をする予定だ。

第4回：NewSQL

　連載最終回では、RDBとは異なる新しい形のDB、いわゆるNewSQLを紹介する。

　NewSQLという用語は、本連載のテーマでもあるアジリティ、可用性、拡張性を同時に実現するために、スクラッチで開発された分散SQL DBを指す。代表的なサービスは2017年に提供が開始されたGoogle Cloud Spanner（ただしGoogleはNewSQLという呼称は用いていない）であり、これに影響を受けたDBが複数誕生している。

　NewSQLは水平方向の拡張性を備えながら、地理的に離れた所へのレプリカ配置を可能とするなどNoSQLのような特徴を持ちつつ、ACID準拠のトランザクションを保証し、SQLが利用可能なRDBとしての特性も併せ持つ。それらの新規性を解説し、クラウドネイティブなアプリケーションのバックエンドとしての可能性を検討する予定だ。

まとめ

　今回は連載第1回として、クラウドネイティブなシステムにおけるDBの要件を整理した。

　DBはクラウドネイティブなアプリケーションが持つアジリティに追随できるように変化が求められているが、高い可用性を失うことも許されない。さらにRDBでは苦手としてきた水平方向の拡張性も、その要件に応える必要が生じている。

　そうした要件に応えるために、まずはマネージドサービスの利用から始めることが考えられるが、それ以外にも新たなプラットフォームでDBを展開する動きや、一からDBを設計し作り直したサービスなどが見られるようになってきている。

　第2回以降ではそれらの特徴を整理し、解説していく予定だ。

筆者紹介

小林隆浩

野村総合研究所でデータベースを中心としたインフラ設計を担当。