本記事はPostgreSQL on Kubernetes Advent Calendar 2018の25日目です。
25日間のアドベントカレンダーもいよいよ最終日です。ここ一週間はギリギリアウト気味の投稿状況でしたが、何とか完走といって良いのではないでしょうか。
PostgreSQL on Kubernetesで目指してきたところ
#2で説明したように、当アドベントカレンダーでは、レプリケーションをk8s上に展開したマルチインスタンスDBではなく、ストレージ・レイヤで冗長化を担保するActive-StandbyのDBクラスタを構築することを目的としてきました。
この構成で解決したかった最大の課題は「複雑性の排除」でしたが、検証結果が示したのは引き換えにサービスレベル低下を招いてしまうという、残念な内容でした。
データベースをk8sで動かす事にこだわる訳
では、現時点でデータベースをKubernetes上で動かす利点はあるでしょうか。
率直に言って、#1で書いたようなことも含めて、あまりメリットはなさそうです。
2018年時点のベストプラクティスとしては、アプリケーションをコンテナ化・k8s化したとしても、データベースはマネージドなDBサービス（RDSなど）を使うのが良いでしょうし、多くの方はそうしているかと思います。
それでも尚、私がPostgreSQL on Kubernetesというテーマに現時点で着手したのは、自身のキャリアに由来しています。
幸いにも私は2000年初頭から18年近くに渡り、データベースを中心としたインフラエンジニアのキャリアを積んでくることが出来ました。その中でDBのプラットフォームは以下のように変遷してきています。
- 商用UNIX＋ベアメタルの時代
- Linux＋ベアメタルの時代
- Linux＋仮想化の時代
- クラウドDBの時代（今）
1.や2.の頃、性能にこだわるデータベースは少しでもオーバーヘッドを減らすべく、ベアメタルが当たり前でした。OSレイヤにおいても、ジャーナルファイルシステムなどを通さずにRawデバイスを使うことが一般的な時代がかつてありました。
しかし、この頃の構成に自身を最適化させた結果、3.の知識体系が私の中で抜け落ちた状況になっていることを2013年頃に気付きました。HW性能向上や運用性のために、VMを使うことが当たり前になっていた下層レイヤの勉強を怠っていたのです。
そして、今年2018年に入ってからKubernetesの現状を知り、既視感におそわれました。今すぐではなくても将来的にコンテナ・k8sは新たなDBプラットフォームになるかもしれない。仮想化に続いて、また技術獲得を怠ればDBエンジニアのキャリアの終焉になるかもしれない、と。
これが今回検証の大きなモチベーションになっています。
できた検証
さて、ポエムはこれぐらいにして、25日間のアドベントカレンダーを振り返ってみます。
まずは今回の検証で出来たこと、です。
| 参考リンク | 出来たこと |
|---|---|
| #4 #5 #14 | StatefulSetを用いたDBクラスタの構築 |
| #3 #12 | 分散ストレージRookの構築 |
| #7 #8 #9 | StatefulSetを用いたDBクラスタの障害時の挙動整理 |
| #15 #16 | DBクラスタの運用手順の整理 |
| #22 #23 | PostgreSQL on Kubernetesのベンチマーク取得と考察 |
できなかった検証
2週間でPGConfで発表した内容（つまり検証済のコンテンツ）を使い切り、残り1週間と少しは実機検証と記事投稿を同時進行で行うことになりました。結果、当初予定していたが検証を行わなかったものや検証失敗でお蔵入りになったコンテンツが発生しています。
今後のためにも整理しておくことにします。
- Probeの調整によるクラスタ復旧の迅速化：#9で書いたように最短化は出来ておらず。
- PostgreSQL exporterの導入：#19で書いたようにメトリックが取れず。
- Helmチャートの作成：#24で書いたようにHelm化には着手できず。
- Operatorの実装：こちらを参考にやってみるつもりでいたが実装できず。
- ElasticSearch/Fluentd/Kibanaを使ったログ分析：ブログに出来るレベルに至らず。
PostgreSQL on Kubernetesの可能性
上記の出来なかった検証の中でも、特にOperatorはPostgreSQL on Kubernetesの可能性を大きく拡げてくれるものになると考えています。
紹介した先行事例のようにストリーミングやDBオペレーションの自動化にももちろん意味がありますが、以下のような要素もKubernetesとOperator Frameworkを用いて実装することで、これまでなかった価値を提供できる可能性があります。
- Sharding機能の提供
- 大量の、microなデータベースの効率的管理
1.はスケールするPostgreSQLをKubernetes上にどのように実装するかという課題であり、やはり意識するのはVitessです。PostgreSQLにも昔からCitusというシャーディングの仕組みがありますが、最近ではFDW Shardingが流行りつつあるように見えます。Shardingに付き物の、複数インスタンスの管理とデータ分散をKubernetesで効率的に扱う事は一つの大きな方向性になるでしょう。
2.はMicroserviceにおけるデータベースの立ち位置に関わります。
サービスを分割していった時にそのバックエンドであるデータレイヤは同じ粒度で分割されていくのか。それとも、先に書いたShardingの例に見られるように超巨大データベースとなるのか。現時点で答えに出会っていません。
前者の分割されたサービス・バックエンドとしてのPostgreSQLは、こちらも追及の余地があるテーマだと考えています。そして、高可用性を担保した大量のMicroデータベースが生まれるとしたら、それを管理するのがKubernetesの役割になっていくでしょう。
まとめ
アドベントカレンダー最終日の本日は全体的にポエム調でお送りしました。
25日間の記事の中にはそれなりに知見として使えそうなものから、情報共有にしてもレベルが低いものもあったかと思います。そんな中でデータベース on Kubernetesを検討する方々にとって、多少なりとも役立つコンテンツが見つかれば幸いです。
ありがとうございました。