急な肝機能障害で参加が危ぶまれましたが、とりあえず朝の通院で強制入院や自宅療養にはならなかったので、そのまま新幹線に乗って午後のセッションに参加してきました(前日の MySQL Innovation Day 2018 秋は泣く泣くキャンセル…ふとももってなんだ…?)。
PostgreSQL Conference Japan 2018 (2018-11-22) | 日本PostgreSQLユーザ会
最近の流れに沿って(?)ツイートで実況してたので(今回は PC すら持って行かず)、適当に混ぜつついつもの箇条書きを(不評かな?)。
【A1】 MySQL から PostgreSQL への移行と DB リファクタリング(株式会社オミカレ/高橋 一騎さん)
MySQLからPostgreSQLへの移行とDBリファクタリング/postgresqlJapan2018 - Speaker Deck
- とりあえずこれをメインに聞きに来た(ので、朝の診察が時間通りに終わって嬉しかった)。
- オンプレ MySQL ~ Aurora 移行のとき、DMS 使うのを早々に断念したので。
- 移行とリファクタリングを同時に行う話。
- 誰も知らないテーブルがある。知らない子ですね。
- 性別カラムの値ドメインが奇妙に拡張されていく。
MySQLだとCHECK制約ないしトリガ使うまでもないからENUM型かな…自分で使ったことないから知らんけど。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
複製しながら、書き込みはMySQL、参照はPostgreSQLの形でリファクタリングを進めた。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018- CQRS っぽい?(ちょっと違う)。
- DMS の受け側の PostgreSQL でトリガを使って値などの変換もする。
- トリガは PL/V8で。
- DMS 用インスタンスはメモリ不足にならないようにする。
レプリケーションインスタンスはAWSが勧めるc4ではなくてメモリ重視のr4インスタンスを使用。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
タスクを小さくしてトラブルの影響範囲を限定するの大事(でも人手が足りないとつい「えいやっ!」とまとめてやってしまいがち)。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018移行途中の監視、移行作業を始める前に仕込んでおくべし。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018「思ってるよりも想定外のデータは入る」#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018- 食わず嫌いせずに DMS も使ってみよう(先日 AWS の人は「慎重に判断した上でどうしても必要なら使ってね」というスタンスだったけど)。
【B2】 Database Encryption and Key Management for PostgreSQL - Principles and Considerations.(NTT OSS センタ/文 仁誠さん・澤田 雅彦さん)
※スライドは後日公開予定とのこと。会場で配布された冊子にダイジェスト版が収録されていた。
- TDE だけでなくて、様々な範囲(行レベル、表レベルなど)での暗号化について言及。
- 暗号化と鍵管理はセットで考える。
鍵の保管場所とローテーション大事。#pgcon18j #pgcon18j_B
— hmatsu47(まつ) (@hmatsu47) November 22, 2018- つい先走ってツイートしてしまった(後半のテーマだった)。
- アプリケーションの実装は面倒。
アプリケーションでうっかり鍵をハードコーディングしてしまうあるある #pgcon18j #pgcon18j_B
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
- 結局 TDE(透過的暗号化)に落ち着く?
- でもあまり進展はない。
TDEの実装があまり進展しないこととクラウド利用の増加に関連はないのだろうか。#pgcon18j #pgcon18j_B
— hmatsu47(まつ) (@hmatsu47) November 22, 2018MySQLを参考にしてTDEを実装していく(提案する?)予定。#pgcon18j #pgcon18j_B
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
【A3】Best Practices for Running PostgreSQL on AWS -Amazon RDS for PostgreSQL/Aurora with PostgreSQL Compatibility のご紹介-(Amazon Web Service, Inc./江川 大地さん)
Best Practices for Running PostgreSQL on AWS
- 「マネージドでアプリケーションに集中しよう」のお話。
- 設定できるパラメータグループ、使える拡張モジュールの話など。
- Redshift(ベースは同じ PostgreSQL)との間の dblink の話も。
- Aurora への言及は控えめだった印象。
- PGConf.ASIA 2018 でのお楽しみ?
【A4】運用が大分変わるよ。オンプレ PostgreSQL から AWS のマネージド PostgreSQL の担当になっての知見(オイシックス・ラ・大地株式会社/林 如弥さん)
- こちらは実際に運用されているユーザ側からのお話。
- 分析用の DB を MySQL から PostgreSQL へ移行した。
- 分析系は PostgreSQL のほうが強いため。
- データのソースは Oracle。DMS で複製して PostgreSQL へ持ってきている。
- こっちの DMS 採用事例も(A1 セッションと同様)ある種の CQRS 部分採用例?
- オンプレのつらみが次々と…。
- DB のクラウド移行でわたし(登壇者ではない)が強く訴えたいのはこれ。
DBのクラウド移行、NWのレイテンシ(AZ跨ぎ)への対応がハマりポイント。そこが問題にならないぐらい疎結合なシステムならそんなに苦労しないかも。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
- バックアップの取得(とリストア)も大事なポイント。
- オンプレつらい。
- クラウドでは札束で殴る、の話へ。
- とはいえ Aurora は IO 課金が高すぎて断念、普通の RDS へ戻った。
AuroraはIO料金がそこそこ掛かるので注意。ストレージもそれなりに掛かるけれど、構造を考えれば割安かな?#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
※LT も面白かったのですが省略。皆さん無駄(?)に気合いが入っていらっしゃる…。
Linux に触れた当初、RDBMS は PostgreSQL を使っていたのですが(7.4 あたりまで)「夜中の VACUUM」が辛くて MySQL に鞍替えしてしばらく遠ざかっていました。
ただ、
実際、長くMySQLを使い続けてるにもかかわらず、MySQLが苦手なクエリを大量生産してしまう開発チームはまれによくある(うちのことだ)。#pgcon18j #pgcon18j_A
— hmatsu47(まつ) (@hmatsu47) November 22, 2018
という事情もあり、CQRS 的に「書き込みは Aurora MySQL 互換、参照は Aurora MySQL 互換と PostgreSQL 互換の使い分け」もアリかな、と思っていたところなので、それに近い話を 2 本も聞くことができて個人的には満足です。
参加できて良かった。健康って大事!(治ってないけど)。
さて、来週からは Internet Week 2018 からの地元名古屋(Code One 報告会)→鳥取(倉吉/中国地方 DB 勉強会)→ 1 日休んで再び東京(MyNA の望年 LT 大会)なので、これ以上悪化させないよう気を付けながら備えたいと思います(といいつつ今日 11/23 は休日出勤…)。