データ永続化と構築運用の自動化を実現する「PostgreSQL on Kubernetes」の仕組み：クラウドネイティブ時代のデータベース（2）

クラウドネイティブ時代のデータベース設計で考慮すべきポイントを検討する本連載。第2回はKubernetesでPostgreSQLを扱う「PostgreSQL on Kubernetes」の仕組みを解説する。

[彭 博，SRA OSS, Inc.]

　アプリケーションやWebサーバ、データベース（DB）などシステムを構成するためのプラットフォーム統一が不可欠となる中、本番利用に耐えられるまで十分成熟しているのがKubernetesだ。大手クラウドプロバイダーがマネージドサービスを提供するなどトレンドになっている。

　連載第1回では、クラウドネイティブ時代のDBに求められる3つの要件として「アジリティ、可用性、拡張性」を紹介した。第2回はKubernetesでPostgreSQLを扱うことでどのようにアジリティ、可用性、拡張性およびDB固有の要件を実現できるか解説する。

Kubernetesの特徴

　あらためてKubernetesとは、コンテナ管理を自動化するためのプラットフォームだ。Kubernetesはマニフェストを用いて宣言された「あるべき状態」を維持するために、自律的に動作する。定期的に「現在の状態」を監視し、「あるべき状態」と「現在の状態」を比較。その差分がなくなるように自律的に動き続ける。これらの動作の繰り返しを「Reconciliation Loop（突き合わせループ）」と呼ぶ。この特徴を生かすことで、システム管理者によるサーバの構築や管理を自動化でき、作業の手間が大幅に削減される。

　Kubernetesでは、ステートレスなアプリケーションの場合にはレプリカを複数用意することで簡単に高可用性や負荷分散を実現できるが、DBのようなステートフルアプリケーションを運用管理するためには、専用のOperatorが必要になる。

　Operatorとは、Kubernetesで動作するアプリケーションの各種管理を自動化するための機能だ。管理が複雑であるPostgreSQLのようなステートフルアプリケーションの場合は、プライマリーとレプリカの役割と、DB固有の要件（自動フェイルオーバー、バックアップ、データの永続化など）を考慮する必要があるため、Kubernetesの標準的な機能だけでPostgreSQLクラスタを構築、管理するのは難しい。

　そこで、PostgreSQL専用のOperatorを利用すれば、PostgreSQLクラスタをKubernetesで簡単にデプロイ、管理できるようになる。手作業だった監視、障害時の対応、バックアップ、スケーリングといったさまざまな運用管理をコード化してKubernetesに組み込み、Kubernetesの本来の機能を拡張することで、DBの管理も容易になる。

　PostgreSQL Operatorは各社が開発を進めている。その中でも代表的なものが「Zalando PostgreSQL Operator」と「Crunchy PostgreSQL Operator」だ。Zalando PostgreSQL Operatorはドイツのeコマース企業Zalando SEが開発しており、MITライセンスで公開されている。Crunchy PostgreSQL OperatorはPostgreSQL関連サービスを提供する米国のCrunchy Dataが開発し、Apache License 2.0で公開されている。各PostgreSQL Operatorにはそれぞれに特徴があるが、基本的な機能は共通しており、PostgreSQLクラスタの管理に必要な機能が一通り用意されている。

　ここからは、各PostgreSQL Operatorの共通機能を用いたPostgreSQLの構築、運用の自動化を見ていく。

PostgreSQL on Kubernetesの基本構成

　PostgreSQL Operatorの機能を解説する前に、まずKubernetesでPostgreSQLを運用する際の基本構成を紹介する。構成図は以下の通りだ。

　上記構成において、KubernetesクラスタにPostgreSQL OperatorのPodがデプロイされており、PostgreSQLクラスタのデプロイ、バックアップ、障害時の自動フェイルオーバー、監視などの管理はPostgreSQL Operatorで自動的に実行される。マニフェストまたは専用の管理コマンドを用いてDBクラスタの「あるべき状態」を定義し、Operatorが自動的にPostgreSQLクラスタをデプロイする。PostgreSQLクラスタでは、1台のプライマリーと複数台のレプリカでストリーミングレプリケーションが構成されており、プライマリーとレプリカそれぞれに接続するためのServiceも自動的に作成される。

　PostgreSQLのストリーミングレプリケーションは、1つのプライマリーが書き込みクエリを受け付け、データ変更をリアルタイムで複数のレプリカに転送することで、プライマリーとレプリカを同期できる。プライマリーは書き込みクエリと読み取りクエリを処理でき、レプリカは読み取りクエリのみ処理できる。

　Serviceとは、同じ種類のPodを1つのリソースにグループ化するための機能のことだ。Serviceには単一のIPアドレスが割り当てられ、アプリケーションがServiceを使ってPostgreSQLのプライマリーPodとレプリカPodと通信する。レプリカPodが複数存在する場合は、レプリカService宛てのクエリが自動的に複数レプリカPodに負荷分散される。

　Kubernetesでは簡単にPodを作成、削除できるが、Podを削除するとPodのデータも削除されてしまう。そのためデータを扱うアプリケーションは、データ永続化の仕組みが必要になる。Kubernetesでは、Persistent Volume（PV）、Persistent Volume Claim（PVC）を利用することで、Podのデータを永続化できる。PostgreSQL Operatorを使ってPostgreSQLを構築すると、PVとPVCが自動的に作成され、PostgreSQLのPodが削除された後にもデータを保持し続けられる。

高可用性

　DBの運用においては、サービスのダウンタイムを最小限に抑えるため高可用性が求められる。Kubernetesでは、自動的にPostgreSQL Podの障害を検出し、復旧させることで、継続的にシステムを安定稼働できる。

　PostgreSQLのプライマリーPodに障害が発生すると、自動的にフェイルオーバーして1つのレプリカがプライマリーに昇格する。また、Kubernetesでは定義した状態を維持するという特徴があるため、定義したPodの数を満たすように、新たなレプリカが生成され、復旧する。DB管理者が手作業でフェイルオーバーの手間がなくなり、迅速に復旧できる点は大きなメリットである。

　フェイルオーバーが発生しても、プライマリーServiceの接続先は自動的に昇格後の新しいプライマリーPodを指しているため、アプリケーション側でDBの接続先を変更する手間がないという特徴もある。

バックアップ、リカバリーの自動化

　PostgreSQL Operatorの機能を利用することで、定期的にバックアップを取得ができる。また、取得したバックアップやWAL（Write Ahead Log）アーカイブはクラウドストレージに保存できる。保存しておいたWALアーカイブを利用して、PostgreSQLクラスタを以前の時点に復元することもできる。

　DBの運用中に、開発環境やテスト環境を作成する必要もよくある。PostgreSQLクラスタを作成する際に、作成したい本番環境のクラウドストレージの詳細情報を指定すれば、バックアップから本番環境と同一の別環境をすぐに用意できる。Kubernetesを利用することで手間がかかるテスト環境の準備も容易だ。

スケーリング

　PostgreSQL Operatorの機能を利用することで、DBのようなステートフルアプリケーションでも簡単にスケーリングできるようになる。レプリカの数を変更するだけで、定義した数を満たすように、PostgreSQL Operatorが自動的にレプリカのPodを作成したり、削除したりできる。

　アクセスが集中して、DBの負荷が上昇した場合は、レプリカの台数を増やして、負荷分散することで、DBの性能を向上させることができる。

読み取りクエリの負荷分散

　PostgreSQL Operatorを利用して、Kubernetes上で PostgreSQLのクラスタを構築できるが、既存のPostgreSQL Operatorは書き込みクエリと読み取りクエリを振り分ける機能が提供されていない。

　そこでクエリを振り分けるためのツールとして「Pgpool-II」がよく使われている。Pgpool-IIはPostgreSQL専用のミドルウェアで、PostgreSQLのSQLパーサが移植されており、クエリを解析できる。Pgpool-IIがアプリケーションとPostgreSQLの間に位置し、アプリケーションからのクエリを解析し、書き込みクエリをプライマリーに送り、読み取りクエリをプライマリーとレプリカのいずれかに送って負荷分散する。

　Pgpool-IIは読み取りクエリの負荷分散以外にも自動フェイルオーバー、コネクションプーリング、オンラインリカバリー、Watchdogなどの機能も提供する。Kubernetesでは、PostgreSQLおよびPgpool-IIの状態はKubernetesが管理するため、Pgpool-IIは読み取りクエリの負荷分散とコネクションプーリング機能のみを提供すればよい。また、KubernetesではServiceを経由してアプリケーションに接続するのが一般的であるため、Pgpool-IIのデータベース接続情報設定パラメーターにはプライマリーServiceとレプリカServiceを指定する。

アプリケーションから送られるクエリの処理

　アプリケーションのクエリはPgpool-II Serviceに送られる。Pgpool-IIがService経由で送られたクエリを解析し、書き込みクエリであれば、プライマリーServiceに送り、読み取りクエリであれば、プライマリーServiceとレプリカServiceのいずれかに送る。また、レプリカServiceに対して送信された読み取りクエリが自動的に複数のレプリカ間で負荷分散される。

　Pgpool-IIをKubernetesクラスタに導入することで、アプリケーションのソースコードを変更せず、各PostgreSQL Podの負荷を分散させ、システム全体のスループットを改善できる。

まとめ

　今回は、Kubernetes上でPostgreSQLを動作させるPostgreSQL on Kubernetesの基本構成と仕組みを解説した。Kubernetesと専用のOperatorを用いることで運用管理の自動化、可用性と拡張性の向上などのメリットを享受できる。

　またKubernetesを利用することで多数のPostgreSQLクラスタを迅速に構築したり、PostgreSQL クラスタをサービスごとに隔離し、セキュリティを向上させたりするなど、さまざまな活用方法が考えられる。

　現状はシステムを構築する際にマネージドサービスを用いてDBを構築することが考えられるが、PostgreSQL Operatorの開発が活発に行われていることから、今後の発展や新たな活用方法が期待できるため、Kubernetes上にDBを構築することも現実的な選択肢の一つといえるだろう。

　次回はマルチクラウドまたはマルチリージョンを実現するマネージドサービスの利用方法を解説する予定だ。

筆者紹介

彭 博

PostgreSQLをはじめとしたオープンソースソフトウェアの構築から運用まで高品質かつ迅速なサポートサービスを提供するSRA OSS, Inc. 日本支社で、インフラ系ソフトウェアのサポートを担当。Pgpool-IIの開発にも携わる。