PostgreSQLカンファレンス2015 に参加しました。

ごきげんよう。

PostgreSQLカンファレンス2015 に参加しました。

https://www.postgresql.jp/events/jpug-pgcon2015/


参加報告を簡潔に記載します。

■ハッシュタグ　#pgcon15j

#敬称は略

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

1、【 基調講演 】PostgreSQL 9.5 について

PostgreSQL 開発者
Michael Paquier



1-1、講演内容

(1)
掲題の通り、PostgreSQL9.5について講演なさってました。

(2)
来月中に9.5.0が出る見込みらしいです。

(3)
ここでも目玉機能は　UPSERT　でした。
INSERT文の拡張だと私はとらえていますが、
INSERT...ON CONFLICT文により
データ格納時に衝突が起きたらどんな動きをするか指定することができます。
かなり便利な機能かと。

(4)
あとの話は
・BRINインデックス
・GROUPING SETS
・JSONBの拡張
・RLS（Row-Level Security）
など

RLSはユーザによって検索できる行を制御できるというもの。

(5)
Streaming standbyとして

archive_mode = 'always'

が追加されます。
WALを制御するコマンドですが、この効果により
WALの欠損を防ぐことができる・・？　ような認識をしました。


(6)
pg_rewind

ベースバックアップをとったあとに
マスタとスレーブでWALの内容が異なっていく
そしてマスタが何らかの理由でマスタじゃなくなり
スレーブが昇格する際に
マスタのWALをRewind（巻き戻して）、ベースバックアップした時間まで戻り、
そこから昇格したスレーブのWALをたどっていくようです。

#　文字で表現するのがとても難しい・・

(7)
他にも
checkpoint_segmentsがなくなり
max_wal_sizeでコントロールするようになったらしいですが
これはソフトウェアでの制御になるので
実際は流れてくるwalの塊の量によって
サイズオーバーしてしまうことがあるので注意するべしとのこと。



■所感

WALまわりの変更が多い印象を受けました。
ストリーミングレプリケーションの欠点や
ベースバックアップの考慮などに力をいれている印象です。

RDBとしての機能として大きな変更はないように見受けられたので
PostgreSQLとしてどういう方向に今後力を入れていくかが
垣間見られた気がします。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

2、【 基調講演 】
企業における Postgres Way はこれだ
～ 6 年間の取り組みから語る失敗事例と成功パターン ～

株式会社アシスト
データベース技術本部
徳原 茂之


★スライドは後日アップロードされるそうです。


注意：
アシストさんは
「PostgreSQL」も「PostgresPlus」も
「Postgres」と呼ぶので、そこは注意が必要です。
聴いててどっちなのかわからないことが多々あり・・


＜＜議事メモそのまま載せます＞＞


2-1、講演内容

(1)
●アシスト社のPostgresへの取り組みの紹介

・パフォーマンスセラピー
　Oracleの性能情報をグラフで可視化するサービス

・勤怠管理
　社内の勤怠管理をPostgresを使ってシステム化した


(2)
●採用傾向の変化

OSS-DBを採用する動きが活発化

・ご相談傾向推移

2013年は新規システムの検討が多い
2015年は移行が多い
　どういうケースでPostgresを使うのか、
　どういう設定にするのか基準を作りたいという要望が多い

・ANAシステムズ様　事例
　Postgresの選定・構築・運用の基準を確立


・大和総研ビジネスイノベーション様　事例
　社会インフラ等クリティカルなシステムでの採用
　
　電力の管理、分析システムの根幹のエンジンにPostgres


(3)
●ヨーロッパにおけるPostgreSQLの取り組み

　EU全体におけるPostgreSQL開発と普及活動
　　AXLEプロジェクト
　　各種イベント
　　　カンファレンス
　　　Meet Up MTG


・大規模データベースへの対応
　AXLEプロジェクト
　　10～100TBのデータベースを対象
　　BI処置を高速かつセキュアに
　　9.5以降の機能開発に貢献
　　　BRINインデックス
　　　Tablesample
　　　双方向レプリケーション
　　　列単位での格納・圧縮（COAST）

・主要都市でのイベント開催
　PGDay UK
  　イギリス国内のカンファレンス1日
　　2015年度100名

　　物事をオープンにすることが、物事がよくなることだ
　　'Make things open: it makes things better.'

　London Meet up
　　年3-4回


・PostgreSQL Conference Europe
 ヨーロッパで最大のカンファレンス　4日間
　2015年度400名　過去最高
　多くの主要デベロッパーが参加


・主要都市でのイベント開催
　FOSDEM
　　OSCみたいな感じ　無料　オープンソース全体のイベント2日間
　　5000-6000名
　　PostgreSQL、MySQL、Virtulalization etc..


・ドイツ　Zalando社
　　ヨーロッパ最大のオンラインショッピングサイト

　導入背景
　　処理性能確保のためPHP+MｙSQLだったのがJava+PostgreSQLへ書き換え
　　データ規模　5TB　（12GB/1日増加）


・Adspert社ドイツ

　SaaS型のWeb広告系サービス

　導入背景
　　OLTP/OLAP用別のデータベースをPostgreSQLで統合
　　データ規模：3TB

　導入効果
　　顧客ユーザ事にデータベースを分割することでデータを水平分散

　　5台のサーバに1TBずつに分割してる

　　PostgreSQLはOracleのマルチテナントの思想を元からもっている


・TanTan社　中国
　スマートフォン向け出会い系アプリケーション

　PostGISの機能性を評価し、PostgreSQLを採用
　メモリ256GB　ストレージSSD　データ規模3TB


　8インスタンスへデータを水平分割し、ストリーミングレプリケーションで参照処理の負荷を分散
　大量の日時処理　1億6千万のINSERTや1200万のSELECT処理の性能を確保


(4)
■Postgreｓの製品評価

　柔軟&フレンドりなライセンス
　学びやすいDBアーキテクチャ
　エンタープライズ向け機能進化
　活発なコミュニティ活動

　1500件/年の問い合わせ
　障害解決率が高い


(5)
■なぜ企業への浸透・活用は進まないのか


失敗事例
　
A社　採用が進まない
　OSSの積極的な採用を会社方針としている

　失敗要因
　　稼働実績の多さからSIerが商用DBを提案する
　　DB選定に対する基準があいまいなため、提案内容への指摘ができない
　　スキル習得に要するコストが読めない
　　担当者が責任を負いたがらない


B社　コストメリットが得られない
　パッケージソフトのリポジトリを商用DBからPostgresに変更

　失敗要因
　　アプリケーション改修カ所が想定より多い
　　改修コストがライセンスコストの減額分を上回ってしまう
　　パッケージソフトの販売展開が見通せていない

C社　ヨコ展開が進まない
　展開効率化のため、事前に共通ドキュメントを整備（ガイドライン）

　
 失敗原因
　　推進役が不在
　　共通ドキュメントを効果的にアピールする場を作れない
　　ドキュメントが陳腐化し、メンテナンスに追われる


(6)
■企業・情報システム部門が抱える課題
　慢性的なヒト不足
　　工数・スキルに対する不安


「技術課題」以上に「ヒト課題」を解決することが企業への浸透に大事


展開に向けたステップ

　小さなハードルをまずはこえる

(7)
まとめ

　最初の一歩を踏み出そう
　一発もので終わらない
　サービスや製品をうまく活用しよう




■所感

タイトルが大げさすぎたような印象。
「失敗パターン」とはPostgresの導入ができなかったケースを指し
Postgresを入れてシステムを構築してからの失敗事例ではなかった。

また、
ヨーロッパ最大のオンラインショッピングサイトでも
データ規模は5TBで、データの増加も1日12GB程度とのこと。
1日数TBくらい増加するのかなと個人的には思っていたので
少し拍子抜けしました。
これらの数値は今後のシステム開発の指標として参考になるかもしれません。


================================================================
【K1】

3、あなたの知らない PostgreSQL 監視の世界
TIS 株式会社
中西 剛紀


3-1　講演内容

スライドがかなりしっかりしてるので
詳細はそれを確認してください。
#　公開されるかは不明

スライドが手に入らない場合は
pg_monz
を調べると良いと思います。


(1)
PostgreSQLの監視をどうするかという話

(2)
まずは「正しく動いてんの？」を監視する

(3)
PostgreSQLの監視に使える情報
・PostgreSQLの標準機能
　-コマンド：pg_isready など
　-関数：pg_is_in_recoverry()など
　-稼働統計情報：pg_stat～～～
　-ログ

(4)
PostgreSQLの監視に使えるツール
・pg_stat_statements
・pg_statsinfo（Oracleのstatspackのようなもの）
・pg_monz


(5)
ツールをうまく組み合わせましょう
・pg_monzは「監視」ツール
・pg_statsinfoは「性能分析」ツール
・PostgreSQLのサーバログ



■所感
このセッションではpg_monzが便利ということが伝わりました。
Zabbixと連動して監視が視覚的にできるようです。

pg_monzのページ
http://pg-monz.github.io/pg_monz/



================================================================


【M2】

4、PostgreSQL セキュリティ総復習

アップタイム・テクノロジーズ
永安 悟史


スライドはこちら
http://www.slideshare.net/uptimejp/postgresql-54761353


4-1、講演内容

スライドが公開されているのでメモを記載します。

(1)
PostgreSQLカンファレンスはSIerが多い

(2)
狙われてるのはデータベース
→　セキュリティが重要

(3)
クラウドになってDBサーバがいろんなところにある場合
平文でパスワード認証はネットの海に流れるので注意！

(4)
PostgreSQLはOracleほど細かくセキュリティ設定できない

Oracleは1台のインスタンスをみんなで使う設計？
PostgreSQLは1台のサーバを使うことは想定していない？

(5)
権限の棚卸、クリーニングはセキュリティの基本

(6)
いかにして「想定していないSQLの実行」を防ぐか
→　実行できるSQLを制限してしまえばいい
　→　sql_firewallを作った

学習していないSQLの実行を防止することができる

(7)
バックアップファイルは暗号化されないし
置きっぱなしになることが多々あるため気をつけましょう！



■所感

SQLの実行そのものを制御してしまおうという発想はなかった。
しかし、たしかにそれによってセキュリティは向上しそうです。

また、クラウド上にDBサーバを設置している場合は
ネットの海にさらされてるということを忘れてはいけません。

sql_firewall
使ってみたいと思いました。


================================================================

【M3】
5、監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性

日本電信電話株式会社
NTT オープンソースソフトウェアセンタ
DBMS 担当
大山 真実


5-1、講演内容


(1)
DBの監査は重要

(2)
DBAの1割が
DBに格納されている情報を売却するかもしれない、改ざんするかもしれない、破壊するかもしれない。
つい、むしゃくしゃしてしまうｗ

(3)
PostgreSQLには監査ログの出力機能がない？
→　log_statement = all がある

(4)
しかし
・監査するのが大変なログ問題
・性能低下問題
・運用ログと監査ログが混ざっちゃう問題
・スーパーユーザなんでもできちゃう問題
があげられる。

(5)
そこで
PostgreSQLの監査ログ出力ツール
pgaudit
の出番

(6)
pgauditはPostgreSQL9.5対応
※　複数のpgauditやpg_auditが存在しているので注意

(7)
pgauditの特徴
・サーバログより粒度の細かいログ出力が可能
・サーバログで取得できない情報を取得可能
・ログはサーバログに出力される
・設定値はすべてGUC


■QA.

(1)
pgauditいろいろある問題　それぞれの違いは？IFは同じ？
→　2ndはセッションログ
　使うにはどれが適するか確認してから使うこと

(2)
pgまじゃー？を使ってる　ログを解析するツール
それと合わせて使いたい
ログラインプレフィックスはPostgreSQLのログと同じ？
→　同じ

(3)
PostgreSQL本体がだすログと、auditのログをわけるには？
→　AUDITプレフィックスがつくのでそれで区分けしてください

(4)
auditは性能ダウンがどれくらい抑えられる？　むしろCPU負荷があがるのでは？
→　要件による　フィルタのオーバヘッドは測定してないI/Oが1番ネックなので多少マシにはなるはず


(5)
監査ログをだすとたくさんログがでる。ローテーションはできるの？実際に監査が必要な企業で使われてる事例
→　ローテートはサーバログのローテーション　サーバを起動したままできる
　　使ってる企業はあるかに対しては、むしろお客さんの要望があって作った。日本は言えない



■所感

ログ機能の強化としてpgauditを使うことは
十分に選択肢になりうると感じました。
いろいろと細かい設定で、多数の出力項目を有しているので
本当に詳細なログを出力・取得することができそうです。


スライドがかなり作りこまれていて
細かい情報が記載されているので
もし公開されるなら確認しても良いと思います。

================================================================

【K4】
6、PostgreSQLアンチパターン
JPUG 中国支部支部長
曽根 壮大

スライドはこちら
https://www.slideshare.net/secret/3GPc5Zqug0gIJk



6-1、講演内容

詳細はスライド参照

(1)
・削除フラグは悪
・配列型、JSON型を使うより、まずは正規化
・マテビューはリフレッシュの影響が大きい安易に作りすぎないこと

(2)
ちゃんと正規化・設計をしましょう


■所感
削除フラグのカラムの作成、配列やJSON型、マテビュー
どれも使う前には設計が怪しいと疑うこと。
正規化をめんどくさがらないで、ちゃんとやることの大切さを再認識しました。


================================================================

■全体的な所感

今年のPostgreSQLカンファレンスはセキュリティの話が多かった印象です。
これはPostgreSQLのRDBとしての機能も大事ですが
運用において注意するべき点が注目されてきたということであり
PostgreSQLがある程度成熟した技術になってきたのかと感じました。


以上