#13 Recap: PgConf.Asia 2018

本記事は[PostgreSQL on Kubernetes Advent Calendar 2018](https://qiita.com/advent-calendar/2018/postgresonk8s)の13日目です。
昨日は「[ストレージ on Kubernetesの紹介](https://qiita.com/tzkoba/private/0db30d8ea8c630e61ce5)」ということで、Kubernetesから利用可能なストレージソフトウェアをいくつか紹介しました。

今日は12/11、12/12の2日間にかけて参加した**PGConf.Asia 2018**の振り返りをしていきたいと思います。

#TL;DR

+ ZHeapが実装されたらPostgreSQLもだいぶ変わりそう。
+ Auroraのセッションはポスグレ技術者から見ても素晴らしかった。資料公開されたら是非読みたい。

#興味深いセッションたち
PostgreSQLの技術者としても、PostgreSQL on Kubernetesで登壇する立場としても、参考になるセッションが沢山ありました。それらを少しだけ紹介したいと思います。

## 12/11（火）のセッション
### PostgreSQL replication in 2018
PostgreSQLの開発者・コミッタであるMagnus Haganderさんのセッション、北欧からいらしてたようですよ。
このセッションが素晴らしかったのは、狭義のレプリケーションに限定せず、可用性とデータ分散の観点で、Linux-HAやストレージレプリケーションから丁寧に解説していたところです。

要点をまとめると以下のような感じでした。

+ streaming replicationはあくまで可用性のためのもの。
+ **リード・クエリ・オフローディング**が必要なら、streaming replicationが答えになるだろう。
+ 自動フェイルオーバーなどのクラスタ管理機能はPostgreSQLにはない。
+ PostgreSQLのクラスタ管理機能として使えるものとして、patoroniやrepmgr、PFAなどがある。
+ PFAはPaceMakerとCorosyncを既に使っている人ならおすすめ。
+ ロジカルレプリケーションはデータを分散コピーするためのもの。
+ ロジカルレプリケーションはSQL文単位ではなく、レコード単位でレプリケーションする。

結構知らないことが多かったです。

ロジカルレプリケーションはOracleでいうGoldenGateに相当するもののようなので、複数行の更新を一気にするとレプリカ側で詰まるという問題も同様におきそうですね。

### Bloat and Fragmentation in PostgreSQL
NTT OSSセンタの澤田さんのセッションでした。PostgreSQLにおいてはいつもテーブルの**肥大化**が問題になりますが、それらのメカニズムを丁寧に解説してくれていました。

私もPostgreSQL8.3の頃からさわっていますが、VacuumやHOTの内容を知ったときはOracleとの違いに驚きました。このあたりは10、11となっても大きく変わっていないようなので、折に触れて、こうしたテーマを扱っていくことは重要だと思います。

また、後半ではVacuumのパラレル化など今後の展望を語って頂きました。
私も知らなかったのですが、バージョン12に向けて**ZHeapという機能**が提案されているようで、これはいわゆるOracleのUNDOセグメントをPostgreSQLでも実装し、Vacuumを不要にする取り組みのようです。Vacuumがなくなるとしたら、それはもはやポスグレと呼べるのか。衝撃的ですよね。

さらにキーノートスピーチでも少し話がありましたが、PostgreSQLの**pluggable storage**についても議論が続いているようです。これはバージョン10の頃に話は聞いていたのですが、追記型MVCC以外に具体的なデータ格納方式を聞いていなかったので、実現性には懐疑的だったのでした。
これもZHeapが実装されて選択式になるとしたら、PostgreSQLには大きな、大きな変化になると思います。

## 12/12（水）のセッション
### A guide of Postgresql on Kubernetes – In terms of storage –
登壇して、このAdvent Calenderで扱っている**PostgreSQL on Kubernetes**の話をしてきました。
内容はこちらに[スライド](https://www.slideshare.net/t8kobayashi/a-guide-of-postgresql-on-kubernetes)がありますのでご覧下さい。

前半のペース配分をミスってしまって、時間をだいぶ余らせしまうところだったのですが、逆にStatefulSetでフェイルオーバしない理由と根本的な対応について突っ込んで話せたのは良かったかなと思います。

PostgreSQL ConferenceのLTで雰囲気は察していたのですが、PostgreSQLコミュニティとKubernetesの間には、まだまだ距離があると感じました。

### Caught up in bloat? Over to ZHeap!
12/11に気になった、**ZHeap**のセッションを聞いてみました。
ZHeapの細かな実装について、開発者の方が説明してくれていました。

ZHeapの実装により、PostgreSQLのページレイアウト（[これのこと](http://www.nminoru.jp/~nminoru/postgresql/pg-table-and-block-structure.html#block-structure)）が大きく変わるとのことでした。が、ページ内に発生したトランザクションを同じページ内のトランザクションスロットで管理するというのは実装のメリットが理解し切れませんでした。

当然、トランザクションが重複するとスロットが足りなくなるので、そこは同じページ？別ページ？に確保していくそうだけど、ここは理解できていません。

質問もOracleのUNDOログと違うの？みたいなものが出ていましたが、このセッションを聞くとそう思いますよね。まだまだ採用には時間がかかりそうな機能だと感じました。

### Deep Dive on Amazon Aurora with PostgreSQL Compatibility
Amazonの方が**Aurora PostgreSQL互換エディション**の内部動作について説明していました。 
セッション名の通り、Deep Diveな内容で私もAuroraのここまで深い話は聞いたことがなかったので参考になりました。

なるほどと思ったのは、AuroraはAWSのストレージと一緒に作りこんできた（作りこんでいける）ので、チェックポイントやWALなどの仕組みを大きく手を入れているという点でした。

+ Auroraでチェックポイントはない（！）
+ full_page_writesが不要になり、IOも減らせて性能アップ。

Vacuumについても管理を容易にしており、XID周回問題もCloudWatchでモニタできるらしいです。これ、もしやRDS for PostgreSQLでもそうなんでしょうか。知らなかったです。

ボリューム満点だったので、資料が公開されたらもう一度読み返したいですね。
※12/13時点で公開されていました。[こちら](https://www.slideshare.net/AmazonWebServicesJapan/pgconfasia-2018deep-dive-on-amazon-aurora-with-postgresql-compatibility)です。

#PGConf.Asia 2018を終えて
当然ですが、かなりテクニカルなセッションが多かったです。ただ、その中でも皆さん基本構造の説明から始めて深いところに至るように工夫されていて、大変参考になりました。

登壇者の一人として思うことは、勢いがついて喋り出すと40分もあっという間（当然準備はすごく大変）なのですが、その中でペースを調整して話したいところの周辺も掬って説明するって、簡単ではないなーということです。

これを皆でやっていくという姿勢には大きく共感できました。
来年もぜひ参加（何かテーマあれば登壇も）したいと思います。

よろしくお願いします。