PostgreSQLのプラットフォームについて解説してきました

2020/11/13に行われたJPUGの年次カンファレンス「PostgreSQL Conference Japan 2020」で登壇してきました。

当日のスライドはこちら。

何を話したか？

クラウド上でPostgreSQLを使う際に、どの稼働環境で動かすことが良いのか気になりますよね？

マネージドサービスが良いのか、EC2でインスタンス立てて、そこにPostgreSQLをインストールするのが良いのか。これは社内外で良く聞かれることなので、一度きちんとまとめてみようと思いました。

そもそも、RDSやAuroraはどんな用途で使うと良いのか？この話はAWSのイベント等でも話題になっており、クラスメソッドさんのブログにも素晴らしいまとめがあります。

普段の私のセッションはどうしてもDB on Kubernetesがメインテーマで、その技術的な内容や注意点を喋ることが多くなります。

ただ、より広い視野で見ると、私が追い続けているPostgreSQL on Kubernetesという流れと、マネージドサービスの流れは合流していくように見えます。

そのような視点から、以下のようにPostgreSQLプラットフォームを整理して、複雑なビジネス要件にフィットしたプラットフォーム選びの一助となるように論を進めています。

Amazon RDS、Auroraをどんな時に使うと良いのか？
PostgreSQL on Kubernetesを使うと良いケース、ダメなケース
新たな形のマネージドサービスの紹介（on Kubernetes、マルチクラウド）

補足解説

では、スライドで解説できなかったことを中心に少しずつ補足していきます。

1. PostgreSQLプラットフォームの現状整理

クラウドに限らず、オンプレミスも含めてPostgreSQLのプラットフォームを以下のように整理しました。

今回の説明の対象は、PostgreSQLのマネージドサービスと、Kubernetes上で稼働するPostgreSQL（ピュアKubernetesまたはEKSなどのマネージドKubernetes）ということになります。

2. RDS for PostgreSQLの使いどころ

下図は良く見るRDSを利用する際のメリットですが、これが全てだと思います。

オンプレミスではラック建てて、サーバ買って、OS入れてとやっていたところを、RDSなら全てAWSにお願いできます。
これは初期構築だけでなく運用も含めてなので、その効果は図り知れません。

そこでセッションでは 「どんな時に使うのか？RDS for PostgreSQL」 として、以下のポイントを説明しました。

クラウドでPostgreSQL使うならいつでも！
但し、特定バージョンやエクステンションが必要なケース、Auroraを使うケースなどを除く

リソース上限に関して

当日語っていない事として、RDS for PostgreSQLのリソース上限（CPU/メモリ/ストレージ）をどう考えるかという問題があります。

現在、RDS for PostgreSQLで利用可能な最大のインスタンスはr5.24xlargeとなり、インスタンスのスペックは以下となります。
（PIOPS、最大スループットはドキュメントから同サイズのインスタンスを参考にしている）

96vCPU
768GBメモリ
ストレージの最大容量は64TB
設定可能な最大のPIOPSは80,000、最大スループットは2,375MB/s

シングルインスタンスのPostgreSQLとしては、決して高いスペックとは言えません。
メモリはTBクラスというサーバも今では簡単に組めますし、何より数10TBのデータを持つDBではIOPS・スループットともに不足するケースがあるでしょう。

こうした観点でRDS for PostgreSQLを選ばず、オンプレミスでよりハイスペックな構成にしたり、分散DBを採用するということもあると思います。

DB on Kubernetesの人として

著書の個人的立場として、PostgreSQL on Kubernetesをテーマに話すことが多いため（例：2018年のアドベントカレンダー）、「RDSとかマネージドは使わない人なんでしょ？」 と誤解されることがあります。

もちろんそんなことはなく、DBエンジニアとして様々なプロジェクトに関わる際にはマネージドサービスの利用を推奨しますし、もしそれが出来ない場合、妥当な理由で他を選んでいるかは必ずチェックします。

また、構築時にはDBA（またはDBに詳しいエンジニア）がいても、運用時にそうした人々の支援を受けることが難しいプロジェクトも多数存在します。

そうした意味でも、

各クラウドのマネージドなデータベースサービスは第一候補として必ず検討しよう

ということを継続的に訴えていくつもりです。

3. そしてAuroraの世界へ

そして、RDS for PostgreSQLに続き、同じくAWSが提供するAuroraについて解説をしています。

Auroraのアーキテクチャ解説はここでは省略しますが、改めて調べてみるとAuroraファミリー（と呼んで良いのか分かりませんが）の特徴を理解する良い機会になりました。

私が知らなかったこととして、以下などがあります。

いわゆる通常のAuroraは、ドキュメント中でAurora Provisioned Clusterとされていた。
Aurora Serverlessではフェールオーバ時の目標時間が定義されていない。
Aurora Global Databaseのレプリケーションはストレージレイヤで行われている。
マルチマスタークラスタはPostgreSQLでは使えない。

その他の特徴も踏まえ、今回セッションではAuroraを使うべきケースとして以下の結論を導いています。

こちらのスライドについては異論がある方もいらっしゃることでしょう。

私個人の経験として、OracleからAurora PostgreSQL互換エディションへの移行について相談されることが多かったため、それを色濃く反映した内容になっています。
いわゆるWeb系と言われる企業でAuroraを使うユーザからは、別の意見が出てくるかも知れません。

4. PostgreSQL on Kubernetesという選択肢

RDS、Auroraとマネージドサービスを説明した後に、それらと差別化するアプローチでPostgreSQL on Kubernetesについて解説しました。

こちらについては当日のスライドと、昨年書いたこちらのブログを見て頂くのが分かりやすいと思います。

一貫して主張しているPostgreSQL on Kubernetesのメリットは下記です。

クラウドのマネージドDBより細かな粒度で、PostgreSQL as a Serviceを展開できる
本番環境では、PostgreSQL Operatorを利用してDBAの負荷を下げられる

上記からon Kubernetesで使うと良いケース、そして使うべきでないケースを以下のスライドのようにまとめています。

今回はPostgreSQLコミュニティに対してのセッションということで、当構成の最大の壁は「まずKubernetesを使っていること（自分ではない誰かが管理しているとしても）」になることを繰り返して説明しました。

マイクロサービスのバックエンドとして

上のスライドでも言及していますが、PostgreSQL on Kubernetesのメリットを活かせる箇所として、マイクロサービスにおけるDatabase per Serviceの形が考えられます。

但し、この議論は今回セッションから大きく離れることになるので、興味がある方はこちらの解説記事をご覧ください。

5. 新たな形のマネージドサービスの紹介

AWSのマネージドサービス、そしてPostgreSQL on Kubernetesを解説した後に、最近見られるマネージドサービス（DBaaS）の新たな形を紹介しました。

まず大きな流れとして、今年見られた新たなDBaaSには以下2つの特徴がありました。そして、これは今後も続くトレンドになると、私は予想しています。

マルチクラウド
on Kubernetes

マルチクラウドへの鏑矢：Crunchy Bridge

PostgreSQLのKubernetes Operator開発でも有名なCrunchy Dataは、今年9月にマルチクラウドでデータのレプリケーションが可能なPostgreSQL as a Service、Crunchy Bridgeを発表しました。
（発表時のCrunchy Dataのブログはこちら）

簡単に言えば、Crunchy Bridgeでは以下のような構成が可能になります。

但し、日本でのサービスは未展開であったり、まだまだこれからのDBaaSです。

Azure Arc enabled data services

DB on Kubernetesでマルチクラウド、2つの特徴を併せ持つのがAzure Arc enabled data servicesです。

これはまだ情報が少なく、私も正しい理解ができているか微妙な点がありますが、下図のような特徴を持ちます。

つまり、

Kubernetesがあればどのクラウドでも、オンプレミスでも
Azure Hyperscale(Citus)が動きます。

これはKubeConなどで言われていたKubernetesの "Platform for Platforms" という将来像をはっきりと、しかもデータベースで体現した形になっていると私は考えます。

さらにPostgreSQL as a Serviceという文脈でいえば、強力な分散DBであるHyperscale(Citus)を、AWSやGCPでも使えるということになります。

マルチクラウドとon Kubernetesという流れが加速すれば、各クラウドベンダが提供するのはマネージドサービスのコントロールプレーンのみ、データプレーンはユーザが好きな環境を選ぶことができる時代が到来するのかも知れません。

マネージドサービスを変えていくKubernetes

Azure Arcと同様に、DB on Kubernetesのコントロールプレーンとして稼働するマネージドサービスの形はPlanetScaleDBでも見られます。

MySQLの分散DBサービスを提供するPlanetScale社が、こちらの製品ページで紹介しているように、PlanetScaleDBとAzure Arc enabled data servicesはシステム構成が非常に似ています。

こうしたDBaaSが市場で成功を収めれば、この新たな形のマネージドサービスは各所に広まっていくかも知れません。

余談：マルチクラウドは本当に必要か？

今回のようにマルチクラウドという話をすると、「うちのビジネスでマルチクラウドなんて必要ないと思うけど？」という質問を良く頂きます。

今回のセッションではマルチクラウドの利用例として、Box Zonesの紹介をしました。

つまり、先ほどの質問へは「あなたのビジネスがBoxと同じぐらいグローバルに広がり、特定クラウドに依存しないことが重要であれば、マルチクラウドを採用する必要があります」が回答になります。

そこまで必要なビジネスは限られる、というご意見はその通りだと思います。

まとめ

依然として、クラウド利用時に各ベンダが提供するマネージドサービス（DBaaS）を使うのは最優先の選択肢です。

一方でマルチクラウドやマルチリージョンを前提としたその他のPostgreSQL as a Serviceも登場してきています。そして、そのプラットフォームとしてのKubernetes採用は、今後更に加速するでしょう。

つまり、我々は選ぶにしろ選ばないにしろ、いずれDatabase on Kubernetesを自然な形で利用することになります。

そうした未来でまごつかない様に、今後もこうした動きを取り上げて解説していく予定です。

Discussion