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


* ※当日の生メモです(校正していませんm(_ _)m
* ※資料は入手可能なので、特に気になった事をメモしています

## ■当日の資料
https://www.pgecons.org/2015/09/11/3706/


## ■事例1：「音楽配信・音楽データを取扱うレコチョクの挑戦」 by レコチョク
### 1.会社概要
### 2.レコチョクの挑戦
* インディーズの領域へ
* アーティストの発掘

### 3.音楽配信を支えるレコチョクのシステム
* 通信量
	* サービス毎の音源
	* 1曲あたりのサイズが増えた
	* ハイレゾ、ますます増加する
* データ容量
	* PBオーダーまでデータが増えた
	* 7年間で9倍
* サーバ台数
	* 独自の検索エンジン
		* 24台
	* プライベートクラウド
		* スケールアウトしやすく
	* 1千台(6年間で5倍)
* システム概要
	* 数字はサブシステム数
	* マテビューはデータ連携で使用←？？？
	* リプレース前、Oracle RACが標準構成だった
* PostgeSQLの構成
	* 楽曲配信管理
		* TPS: 4,600(pgbench)
	* Oralceからの移行
		* データ移行検証
			* Postgres Plus
	* 楽曲情報API
		* サーバーハングアップ(2node構成時代)
			* (対応)Huge Pageを使用しないように

### 4.PostgreSQLへの挑戦
* サポートは3rdベンダー

### QA
* バイナリ(楽曲データは)PostgreSQLに格納しているの？(Blob?(bytea))
	* No.(Oralce時代からBlobではない)
* オブジェクトストレージは使っているの？
	* Yes.(現在はAmazon S3で楽曲データを管理)

## ■事例2：「紺屋の白袴にならない！自社活用事例をお客様へ」 by アシスト, マインド
* 採用経緯、利用の状況
* 自社サービス:パフォーマンスセラピー
	* Oralceのstatspackデータ
	* 最初はOracle=>トップダウンでOSS
	* 開発時から移植性を考慮
		* 標準SQLを意識、ストアド使わない
* 自社:勤怠システム(MosPパッケージ)
	* 最初はOracle=>トップダウンでOSS
	* 性能面の理由で、Plusへ移行
* MosP: マインド
	* All OSS
	* 選定理由は標準パッケージであること
		* MySQL < MariaDB < PostgreSQL
* チューニング事例
	* PEMの使用
	* SQL Profiler
	* Index Advisor

##■事例3：「料金系基幹システムへのPostgreSQL導入事例　～成功までの道のり～」 by NTTコムウェア, NTT OSSセンタ
###ご紹介するシステムの概要
* 数百万契約
* 100種類以上のサービス

### 今回の開発内容
* レガシーシステム(Unix,Oracle,COBOL)
* 完全な作り直し
* アーキテクチャ刷新
* プライベートクラウド

### 性能特性の異なる業務が互いに影響しないよう設計せよ
* 方式
	* ストリーミングレプリケーションによるリードレプリカ
* ポイント
	* OLTPとDSS系で異なるパラメータ
* 実機検証
	* 1ヶ月
	* 現行のバッチ特性を分析
	* クリティカルな部分を抽出
	* 6/5000を対象とした
	* ディスクI/Oが必要と判明

### 運用に耐えうるバッチ処理時間を担保せよ
* 自動ANALYZE問題
* 130/5000ジョブに手動統計情報取得

### PostgeSQLとNTT OSSセンタの関わり
* MC=ミッション・クリティカル
* 年間パッチ等で貢献
* pg_hint_plan github by NTT OSSセンタ

## ■パネルディスカッション
### 質問1:コストが安くなるって本当？
* SRA石井さん
	* 経営戦略に活用できるか？という観点
		* 商用の拘束が無い
		* 製造業の例
			* ライフスパンが10年
			* 商用だとバージョンアップ追従がコスト圧迫
		* 目先のコストだけではない
		* 初めての導入だと経営そう向けの観点、OSSというくくりで提案が必要となる
* NTT西村さん
	* ミッション・クリティカルほどライセンスコストメリット
	* 「手間がかかって」という話はあるがトレードオフだである

### 質問2:商用と違ってサポートに不安があります。バグやトラブルが発生した際には、誰がどのように対応するの？
* NTT西村さん
	* 200-300/年間のSRのうち、PostgreSQLが根本原因のバグは1,2件
* SRA石井さん
	* アルファ版の検証報告の例だと半日でコミュニティが回答
	* そもそもバグが少ない

### 質問3:可用性・信頼で不安がある
* 富士通山本さん
	* SymfoWAREはPostgreSQLベースであるが不安はない(クラスタツールで)
* NEC白石さん
	* 長年使っているが
	* ClusterProで対応(HA構成)
	* システムの特性(要件)を抑えた上で検討すべき

### 質問4:パフォーマンスは商用と比べて劣る？使いわけるポイントは？
* NTT西村さん
	* 遜色無い
	* 厳密にいうと(ベンチマーク結果どおり)更新系でガクッと落ちるが、参照系は上回る
	* が、製品選定に影響するほどでは
* SRA石井さん
	* CPUスケーラビリティ(80c)、メモリ1TB活かせる
	* 物量で殴れる
	* リソースを使い倒せるかは改良の余地がある
	* バキューム問題の誤解(自動バキューム停止が必要になる等)、数百GBなら問題ない

### 質問5:セキュリティについて問題ありませんか？
* NEC白石さん
	* 暗号化は9.5でrowレベルで対応
	* 認証もLDAP
	* クレジット会社の想定したセキュリティ要件検証報告を参照
		* OS機能使いながらシステム全体で
	* 監査と暗号化はもう少し
		* カラムレベル暗号化をOSS提供
		* pg_auditが次に出る
* SRA石井さん
	* Symfoは、CPUのANSI機能を使っている
* NTT西村さん
	* OS機能からめて
	* 監査の観点だと大量ログなど、実用性で改善の余地がある

### 質問6:技術者がいない
* SRA石井さん
	* 需要が増えているということ
	* 認定制度
	* Oracle技術者は移行が容易
* NEC白石さん
	* どんな技術でもそうだが、何か1つを押させていれば応用がきく
* 富士通山本さん
	* お客さんがソースを見ててドキッとした事がある
* NTT西村さん
	* どちらかというと最近の技術者がC言語を押さえていない方が問題

### 質問7:MySQLではない理由
* SRA石井さん
	* 開発スタイルがコミュミニティベース
	* 参入障壁が低い
* 富士通山本さん
	* PostgreSQLのI/Fでカラムナを実装していたりとか拡張性が高い
	* MySQLは候補に挙がらなかった
* NEC白石さん
	* MySQLサポートは昔やってた
	* サポートが早い
	* パッケージに組み込んだ場合ライセンス問題で利がある
* NTT西村さん
	* 対OracleとしてMySQLは無い

### 質問8:今後の課題
* NTT西村さん
	* ユーザが増えて欲しい
* NEC白石さん
	* EP領域で使う場合は、商用同様アプローチを。サービスレベル見極め、検証すべき
* 富士通山本さん
	* 上位ソリューションでの利用拡大を図ってほしい
* SRA石井さん
	* クラスタリング、分散処理が今後の課題
	* クラウド、リージョン間の問題、技術的課題がある
	* 「使いやすさ」を取り込んで行きたい。MySQLから学ぶべきところもある