本記事はPostgreSQL on Kubernetes Advent Calendar 2018の2日目です。
昨日は「データベース on Kubernetesの現在地点」ということで、Kubernetesの現状とデータベースの対応状況を整理しました。
本日は今回主題として取り上げるPostgreSQL on Kubernetesの具体的構成と目指すところについて書きたいと思います。
TL;DR
- PostgreSQL on Kubernetesって複雑すぎない？
- データの冗長化はストレージレイヤで。
- PostgreSQL on Rookの紹介。
問題点：現在のPostgreSQL on Kubernetes
昨日は事例としてStolonをご紹介しました。
同様の事例として、Crunchy DataのPostgreSQL on Kubernetesの事例があります。
これらはいずれもPostgreSQLのレプリケーション機能を用いて、1台のmasterと2台以上のstandbyをKubernetes上に展開しています。
これらの構成のメリットとして、以下があげられるでしょう。
- 複数DBインスタンスによる耐障害性の確保
- standbyのスケールアウトによる読み取り性能の向上
しかし、一方で問題点として複雑な構成（＝障害ポイントの増加）とそれによる運用性の低下があげられると思います。
Vitessの例も挙げましたが、Youtubeほどスケールさせる必要は多くのシステムでないでしょうし、リードレプリカさえ必要ないというシステムも多いでしょう。
PGEconsが提示するPostgreSQLの代表的な構成
少し古い資料になりますが、PGEconsという団体が「PostgreSQLの代表的な構成」を整理しています。
この中でまとめられているのは、大きく分けて以下の5つのパターンになります。
- シングルサーバ構成
- HAクラスタ構成（共有ストレージ方式）
- HAクラスタ構成（シェアードナッシング方式）
- ストリーミングレプリケーション
- pgpoolやSlony-Iを利用したソフトウェアレプリケーション
StolonはいわばKubernetesと上記の4.を合わせた構成です。
PostgreSQLのレイヤでデータの冗長性を担保しています。
しかし、より低レイヤで冗長性を担保し、よりシンプルな構成を取ることは出来ないのでしょうか？
つまり、上記の2.や3.とKubernetesを掛け合わせた構成は取れないのでしょうか。
PostgreSQL on Rookの実装
今回、Kubernetes上にシェアードナッシング型の分散ストレージであるRookを稼動させ、それをPostgreSQLのストレージとして利用する方式を検討してみました。
上図にあるようにPostgreSQL自体は単純なStatefulSetとしてスケジューリングされ、他にoperatorなどを必要としません。
詳細は後日説明しますが、RookによってデプロイされたCeph RBDのボリュームをPVとしてマウントすることで、データの冗長性を担保します。
RookやCephを含むこと自体がシンプルなのか？という疑問はあると思いますが、複数DBインスタンス間でプロモーション時の調停が不要になるなど、メリットは大きいと考えます。
もちろん、現時点ではジャストアイデアで実際の稼動イメージを抱くには検証が必須ですが、それを今回のAdvent Calenderで少しずつ紹介していければと思います。
まとめ
昨日に引き続き、今回も概念的な話が多くなりました。
明日からは今回お話しする構成に必須の、Rookを稼動させる準備をしていきたいと思います。
よろしくお願いします。