- ※当日の生メモです(校正していませんm(_ _)m
- ※資料は入手可能なので、特に気になった事をメモしています
■当日の資料
■事例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を使用しないように
- サーバーハングアップ(2node構成時代)
- 楽曲配信管理
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から学ぶべきところもある