第13回PostgreSQLエンタープライズ・コンソーシアムセミナー メモ

ということで、2015年9月11日 第13回PostgreSQLエンタープライズ・コンソーシアムセミナーに行ってきましたよ。

---

事例1:レコチョク

• スライドはこれ⇒事例1：「音楽配信・音楽データを取扱うレコチョクの挑戦」

• 講師紹介
  • レコチョクは3社目。
  • 元はOracleのサポートしていた人。
  • 2社目もデータベース関係の仕事。

• レコチョク
  • 各レコード会社の共同出資による事業運営。
  • 着うたサービス、dヒッツなど。

音楽マーケットの状況

• 定額制音楽配信が伸びていくという状況

PostgreSQLへの挑戦

• 楽曲配信管理システムをPostgreSQLにリプレースした。
• 各システム用のDB間でも連携していた。
• ダウンタイム5分が許容できる範囲のシステムにPostgreSQLを採用。

　そのシステムでは、スケールアウトを実施。

• スケールアウトにはpgpool-IIを使用。

不具合など

• THPの不具合のためサーバハングアップが発生
• このシステムではpg_stastinfo/reporterを使っている。

今後

• 今後はクラウト(AWS/RDS)を利用
• とはいOracle RAC相当にはできない。

QA

• 楽曲データはPostgreSQL内では管理はしていない。Oracleのころから。
• 巨大なバイナリデータ管理として何を使っている？今はS3上に楽曲データをおいている。

---

事例：マインド／アシスト

• スライドはこれ⇒ 事例2：「紺屋の白袴にならない！自社活用事例をお客様へ」

パフォーマンス・セラピー

• OracleのStatpack等パフォーマンス統計を可視化。Oracleユーザ向けのサービス。
• ただ、ユーザデータはPostgreSQLに格納している。(Oracleを使う予定だったが、社長命令でPostgreSQLになったｗ)
  • ただ、Oracleへの移行も見据えた開発を行った。
• PostgreSQLのパーティションを使って性能改善を図った。
  • パーティションキーはユーザID
• PostgreSQLは安定しているという印象を持っている。
  • この経験がPostgreSQLサポート業務の開始や、PostgreSQL Plus販売にもつながった。

勤怠システム(MosP)

• 以前はAccessを使っていた。でもワークフローが煩雑など問題あり。
• これも元々、Oracleで作ろうとしていたが、やっぱり社長命令で(以下略
• ただ、性能問題やチューニングの敷居の高さが問題になっていた。
  • PostgreSQL Plusへ移行することになった。
  • PostgreSQL PlusだとDBAでなくてもチューニングができるのが狙い
• 冗長化はVM自体のACT-STB化で対応(?)

• MosPはオープンソースの業務アプリケーション
  • MosPは依存ソフトウェアも全てOSSで構築
  • MosP V4からはDBMSはPostgreSQLのみ使用(V3まではMySQL、Oracleも併用していた)
  • 以前は「Oracleに対応してないの？」と聞かれていたが、最近はそうでもなくなった。PostgreSQLが認知されてきたのだという認識。

• 性能問題に対する対応
  • pg_stats_statement → EXPLAINで分析・・・
  • 承認する件数が多くなると性能問題が発生するなど、使い方によって問題が発生することも。
• PostgreSQL 9.3からPostgreSQL Plus 9.4に移行。PEMを使ったチューニング方式の改善を共有。

• 今後は大規模データ向けに。クラスタリングや負荷分散なども。

性能問題への取り組み

• 一括登録、一括表示、月〆処理などで性能問題が発生
• PEMの利用。
  • 稼働統計情報の表示
  • プロセスの待機イベントを見る。
    • PostgreSQLにはないが、PostgreSQL Plusでそれを取得する機能を追加している。
  • SQL Profiler
  • Index Advisor
• PostgreSQLの既存のツール群でもできるが、ハードルを下げる意味でPostgreSQL Plusが役にたった。

---

NTTグループの発表

• スライドはこれ⇒事例3：「料金系基幹システムへのPostgreSQL導入事例　〜成功までの道のり〜」

NTTコムウェアからの発表

• システム全体、アーキテクチャの刷新の一部として商用DBMSからPostgreSQLに変更。
• データベースは数TB、5000のジョブ、バッチ処理が終わらないと日中業務ができない、オンライン系/分析系の共存・・・

• SRを使ってオンライン系/分析系を分割。
  • 分析クエリを動かすときにパラメータチューニングでSQL処理が中断していた・・・
  • しかし、分析対象のデータが古いという問題が・・・後半へつづく

• 仮想化基盤を使えるかどうか→ジョブを分析し、リスクの高いジョブを6つ選択して実証実験を実施。

• SQL実行時間のコントロール
  • 手動でANALYZE(自動収集を待たない)
  • pg_hint_plan → 実行計画の安定化

• 開発を通じてわかったPostgreSQLへの要望
  • ディスクI/O量削減
  • パーティショニング機能改善

NTT OSSセンタからの発表

• スライドはこれ⇒https://www.pgecons.org/wp-content/uploads/2015/09/PGECons3_NTT_20150911.pdf

• レプリケーションが進まなくなった問題
  • max_standby_streaming_delay と hot_standby_feedback のチューニングで解決
• SQL実行計画のコントロール(pg_hint_plan)
  • 最適なプランでなくてもいい。安定したプランが必要。

---

パネルディスカッション PostgreSQLはどこまで普及するのか？現実と未来

モデレータ＆パネラー

• モデレータ
  • 谷川耕一さん＠翔泳社
• パネラー
  • 西村剛さん＠NTT OSSセンタ
  • 白石雅巳さん＠NEC
  • 山本明範さん＠富士通
  • 石井達夫さん＠SRA OSS

質問：コストは本当に安くなるのか？

• (石井)
  • コストが下げるというのは、経費削減か投資なのかという観点で異なる。
  • 商用システムだと技術面以外の制約(ライセンス等)を考えないといけない。
  • 製造業のように数十年継続するようなシステムではOSSのメリットは大きい。
  • 目先だけのコストを見ない。
• 手間がかからない？実はお金がかからない？
• (西村)
  • 新規でシステムを構築する場合、ライセンス費用は大きいので、まずは候補に上げるべき。
  • 逆に商用システムからPostgreSQLへの移行は、それほど簡単ではない。
  • 安い商用DBMSエディションであれば、無理に移行しなくてもいいんじゃないか。
• OSSを選定するときのコスト感は？
  • (西村)
    • 設備系・基幹系は長期間考えないといけない部門もあるし、短期間で判断するものもある。一概にはいえない。
  • (白石)
    • 設計の話などはPostgreSQLだからといって安くはならない。どのDBMSも同じ。
  • (山本)
    • 5年くらいで回収できるかどうか、という基準はある。

質問：サポートって本当に大丈夫なのか？バグ対応とかどうするの？

• (西村)
  • OSSセンタ内では、200〜300くらいの問いあわせは受けるが、バグというのはほとんどないと思う。
  • 今は、いろんな会社でサポートもやってる。

最近、バグ対応ってあった？

• (石井)
  • 安定版はそんなにバグはない。開発版のバグは見つけたが、すぐにコミュニティで反応して議論、パッチが出来た。
  • むしろ、マニュアルの不親切さ、使い方がわかりにくいとかのほうが問題。

質問：可用性と信頼性

• (山本)
  • PostgreSQLを自社製品に取り込むときの決め手はStreaming Replicationがあること。
  • 三重化構成も作れる。台数が増えてもライセンス料が増えないのもメリット。
• (白石)
  • 可用性はDBMS単体で考えるというより、システム全体で考えるもの。
  • NECでもクラスタリング製品もある。
  • 2010年ころからはほとんどがクラスタリング構成を適用。

質問：パフォーマンス

• (西村)
  • ワークロード次第ではある。
  • 製品選定において性能は今やそれほど問題はない。
• (石井)
  • 最近はマルチコア環境にも対応できるので、いざとなったらハードウェア強化で対応できる。
  • ただ、HWリソースをきちんと使い切れていない部分はあるが、コミュニティでも議論。

＊ VACUUM問題は？

• (石井)
  • 今日の発表にあったようなMCな例でない、普通のシステムなら自動VACUUM任せで十分だろう。

質問：セキュリティ

• (白石)
  • 普通の権限まわりは商用DBMSと十分。
  • 認証方式も遜色はない。
  • クレジット会社のセキュリティ要件については、OS機能と組み合わせて適応はできる。
  • 足りないのは監査と暗号化。透過的暗号化はTEDなど対応策あり。
  • 監査はpg_auditがコミュニティでも議論されている。
• (山本)
  • Synfowareでも暗号化は取り組んでいる(オープンにはしてないが)。
• (西村)
  • OSも含めてトータルで見ていけばいいのでは。
  • 監査については運用面を考慮しないといけない。他の製品との連携がまだ弱い？

質問：PostgreSQLのエンジニアがいない！

• (石井)
  • エンジニアが少ないのは、需要が多くなっているから。
  • LPI Japanの試験やトレーニングをうまくつかってほしい。
  • Oracleの技術者であればPostgreSQLと親和性は良い。
• (白石)
  • 1つ知っていれば他のDBMSの習得も早いはず。
• (山本)
  • Synfowareのケースだと、ソースレベルでお客さんと話すようなケースもある。
  • PostgreSQLにはメッセージのIDがない、バージョン毎にメッセージがころころ変わるのがちょっとツラいという経験はあった。
• (西村)
  • NTT-G内ではOSS系のスキルの立ち上がりは早いので、あんまり心配していない。
  • 実は、C言語とか基本的な話を若い人があんまりやってない、みたいな心配がある。

質問：MySQLじゃなくてPostgreSQLを選ぶべき理由はあるのか？

• (石井)
  • 開発スタイル(コミュニティ)が良いところ。
  • 競争の中で開発が進められること。新規機能・新規開発者が参入しやすい。
• (山本)
  • PostgreSQLの拡張性があるところ。
• (白石)
  • トラブルなどに対するコミュニティの反応が早いこと。
  • パッケージに組み込みときにMySQLはライセンス料が必要になるが、PostgreSQLはそれがない。
• (西村)
  • MySQL自体はNTT内でも使っている。
  • 商用DBMS対応という視点ではMySQLは対象にならない。

質問：エンタープライズ領域での課題

• (西村)
  • ニワトリと卵。エンタプライズ領域で使うためには、もっと多くの人に使ってもらわないといけない。
• (白石)
  • 大規模対応はまだ改善の余地がある？
  • 現場の声をどんどんコミュニティに届けないといけない。
  • 「OSSだから簡単に使える」というノリで使ってはいけない。事前の実機検証等、やっていれば大丈夫では。
• (山本)
  • 商用DBMSと変わらず使えるものだと思う。
  • 移行は巧くやらないといけない・・・。
  • DBMS単体ではなく、上位レイヤのソリューションで選ばれることがある。
  • ソリューションにももっとPostgreSQLを組み込まないといけない。
• (石井)
  • クラスタリング、分散処理にどううまく対応していくかが今後の課題。
  • ユーザから見て(分散等を意識させず)、使いやすいという観点も留意しないといけない。