NTT DATA と PostgreSQL が挑んだ総力戦

Copyright © 2014 NTT DATA Corporation
2014年12月5日
株式会社NTT DATA
笠原辰仁、澤田雅彦
NTT DATA と PostgreSQL が挑んだ総力戦～ PostgreSQL を極限まで使い切ったその先に見たものとは？～
PostgreSQLカンファレンス2014

2
ＩＮＤＥＸ
PostgreSQLとNTT DATA
事例概要
立ちはだかる壁
その先に
おわりに

3
OSSが世の中一般に広まり、活用され始める。 NTT DATA 含め、NTTグループとして戦略的にOSSを活用していく体制を整え、OSS適用も活発化。
認知・活用へ(199x - 2007頃)
年度
主な出来事
1999
【コミュニティ】日本PostgreSQLユーザ会(JPUG)設立
2001
【PG】 PostgreSQL 7.1 (ログ先行書き込み(WAL)の実装)
2005
【PG】 PostgreSQL8.0 (Windows対応・PITR)
2006
【NTTG】 NTT OSSセンタ設立

4
OSSというだけで適用が進む時代が終わる。 NTT DATAでは全社展開のためモデル作成を実施。
エンタープライズ分野での弱点をカバーすべく研究開発、新規ソリューション開拓も活発に。
普及・継続的取り組みへ(2008 - 2013頃)
年度
主な出来事
2008
【PG】 PostgreSQL 8.3(autovacuum 標準装備)
2011
【PG】 PostgreSQL 9.1(同期レプリケーション機能の採用)
2012
【コミュニティ】 PGECons 設立
2013
【NTTD】 GresCube 販売開始

5
そして今(2014～)
NTT DATA では、OSSスタックが高い利用頻度に。 PostgreSQLのコモディティ化が進む。
大規模システムでも、当たり前にPostgreSQLを使う今。従来のPostgreSQLの当たり前の使い方だけでは太刀打ちできない要件が立ちはだかる。

6
メインサイト
今回ご紹介する事例
認証
データ
システム基幹部分
災対サイト
業務・集計
データ
小売店
モバイル
POS
POS
PC
社内外の他システム
モバイル向け
Web/AP
社内向け
Web/AP
集配信
認証盤
オンライン
APサーバ
オンライン
帳票サーバ
バッチ
APサーバ
モバイル向け
Web/認証基盤
オンライン
APサバ
オンライン
帳票ーバ
バッチ・取引
APサバ
業務・集計
データ
非同期
レプリケーション
PostgreSQL
販売店舗情報など
売上請求情報など
PostgreSQL
世界有数のエネルギー元売会社の情報系システム
販売情報等をもとに、集計等をほぼリアルタイムで行う

7
特徴(2) OSSメイン & 拡張機能をフル活用
PostgreSQLの拡張機能
pg_statsinfo
性能情報監視用
pg_stat_statement
実行SQLの性能情報監視用
auto_explain
スロークエリの実行計画捕捉用
pg_hint_plan
実行計画制御用
pg_dbms_stats
統計情報固定化用
pg_bigm
全文検索(2-gram)用
pg_reorg
オンラインテーブル再編成メンテ用
pgfincore (試験時のみ)
キャッシュヒット効率向上用
ミドルウェア
OS
RHEL 6.2
DBMS
PostgreSQL9.2
AP
Tomcat
およそ利用可能な拡張モジュールは全て取り入れた

8
迫りくる要件・トラブル
無停止
メンテを
DRサイト
用意！
リスクと対峙
プラットフォーム
トラブル
守れ！
大量SQL
の性能

9
リスクと
対峙
無停止メンテを
無停止
メンテを
DRサイト
用意！
トラブル
守れ！
大量SQL
の性能
無停止
メンテを
ハードなメンテもオンラインで実施したい
VACUUM FULL、REINDEX
はどうしよう？

10
どうするメンテナンス設計！？
～数GBの
小規模テーブル
数百GB以上の
大規模テーブル
システム性能への影響小
→auto vacuumに任せる
システム性能への影響
→メンテナンス枠にて手動
で実施
VACUUM
24時間DBアクセス
昼夜問わず大量バッチ
何は無くともまずVACUUM設計システムへの影響をミニマムに！

11
万が一に備えて
そこで、外部モジュール！地味に、便利なコマンド！
pg_reorg
オンラインVACUUM FULL
オンラインCLUSTER
自作ツール
CREATE INDEX CONCURRENTLY ALTER INDEX
でスワップ！
VACUUMができなかったら？インデックスが荒れてしまったら？
排他ロック要らず！

12
無停止メンテの実現に向けて
必要なメンテナンスと影響を見極める
想定外の事態にも備えておく
想定外のリソース枯渇を抑える。
VACUUMをユーザの制御下に！
いざという時にオンラインでメンテ！
外部モジュール等でPostgreSQLをカバー

13
無停止
メンテを
リスクと
対峙
トラブル
守れ！
大量SQL
の性能
DRサイト用意！
DRサイト
用意！
DRサイト用意！
東日本、西日本間でDR
PostgreSQLのDRはどのように実現する？

14
災害対策（Disaster Recovery)を検討せよ
災害時にも止められない！
→災害の被害を受けてもサービスを継続するために、遠隔地にメインサイトのコピー(災対サイトの構築)を作る！
東日本(メインサイト) から西日本(災対サイト)
DR対象は(ほぼ)システム全体
課題はPostgreSQLのメイン->災対へのデータ同期・・・
DBデータ
西日本
DBデータ
東日本

15
やっぱり Streaming-Replication !
アーカイブログ転送
ＳＲ
ＨＷレベルでの
レプリケーション
決
○高機能 (運用楽そう)
△実績がない… 検証必要
×運用が面倒
△実績がない…
検証必要
×価格が高い
運用
導入
○運用楽 !
頼れるサポート
(Fujii Masao)

16
・・・でも本当に大丈夫か？SR
データ
アーカイブログ
WAL
圧縮して高速に転送
解凍・リカバリ
マスタ
スタンバイ
最大負荷量から必要な帯域をサイジング
初期同期はNW経由・・でもOKそうだ
・・もしレプリケーションが追いつかなくなったら？
データ
WAL
PostgreSQLが自動でアーカイブログからの復旧に切り替え！想定時間内にキャッチアップ！

17
すごかった！SR
今のところレプリケーション起因の問題はなし
PostgreSQLのSRは
DR用途にも十分実用的！
いいね！Streaming-Replication！

18
守れ！大量SQLの性能！
無停止
メンテを
DRサイト
用意！
リスクと
対峙
トラブル
守れ！
大量SQL
の品質
守れ！
大量SQL
の性能
対象は数万本のSQL
性能を守るのは
数名のPG有識者

19
10Mにおよぶ AP
シビアな状況が我々を悩ませた…
数万の SQL
1000人規模の開発体制
タイトな
スケジュール
ポスグレ経験者少な目
SQL性能どう守る？
迅速な SQL チューン?

20
10Mにおよぶ AP
シビアな状況が我々を悩ませた…
数万の SQL
1000人規模の開発体制
タイトな
スケジュール
ポスグレ経験者少な目
SQL性能どう守る？
迅速な SQL チューン?
 複雑すぎるSQLを書いてしまう → SQLのメンテナンス性、可読性低下
 SQLは書いたけど、多くのSQLで性能問題が発生 → 期間内にすべての性能問題を解決できない性能要件を満たさず、トラブルを引き起こすSQL(= 問題SQL)を撲滅するために、我々が用意したものは…？

21
5つの関門を用意
？
1
？
2
3
？
4
？
5
SQLは1～5の関門を通り、
一人前のSQL(=使用可能なSQL)になる
!?
？

22
1つ目 - ＳＱＬガイドライン
PJが持っていたSQLガイドラインで、SQLのメンテナンス性を担保
PostgreSQLのノウハウで、“PostgreSQL向けのSQL”に
SQLガイドライン
•1行当たり最大○○文字
•コメントには/*…*/を使用する
•ORDER BYには列名を記載する：
PostgreSQLのノウハウ
•NULLと文字列を連結すると空文字になる
•異なるデータ型で比較しないこと：

23
チェック項目
結果
テーブルのJOIN数チェック
OK
直積使用チェック
OK
同じテーブルを複数回見ているかチェック
OK
中間一致使用チェック
中間一致はフルスキャンになり性能問題を起こす可能性があります。
pg_bigmインデックスを利用しましょう
：
：
2つ目 - ＳＱＬチェックツール
とはいえ、ヒューマンエラーはある(´Д｀lli)
“ＳＱＬガイドラインに従ったＳＱＬ“になっているか20以上の項目を自動で判別
NGの場合は、チェック観点を表示
■SQL静的チェック結果（イメージ図）

24
3つ目 - 実行計画チェックツール
サービス開始後、SQLの性能問題が起きないために、
“実行計画”をチェック
<実行計画>
Sort
->Nested Loop (cost = …
-> Index Scan (cost = …
-> Seq Scan (cost = …
：
見積もりコストは高くなりすぎていない？
インデックス使われてる？
ただし！
サービス開始後に生成される“リアル”な実行計画が必要！

25
4つ目 - HINT句でアジリティチューニング
HINT句を使い直接実行計画を制御することで、
アジリティなSQLチューニングを可能に
○ HINT句を使用するメリット
SQLを書き換えるよりも改修時間が短い！
•実行計画を確認して、使用するインデックスやスキャン方法を変えるだけ
SQLの実行結果の内容は変わらない！
•HINTを付与するだけなので、SQLのリテスト不要
/*+ IndexScan(hoge) */
SELECT * FROM hoge
WHERE id = 9999;

26
大量SQLの性能を守れました
1
SQLチェックツール
2
3
アジリティSQLチューニング
4
SQL書き換え
5
チェック済みの実行計画をサービス開始後も使用
ドキュメントとツールによる性能問題防止
遅いSQLの
性能問題解決

27
リアルな実行計画？PGを騙す？
実行計画チェックの実現、大量SQLの性能担保にあった
2つの課題
■ 2つの課題
1.ダミーの統計情報を生成しPostgreSQLに設定する仕組みがない → PostgreSQLを騙す仕組み
2.PostgreSQLを騙すことができても一時的な効果でしかない → PostgreSQLを騙し続ける仕組み

28
「統計情報カスタマイズ機能」作りました
ユーザがテーブルに“任意の統計情報”を設定することが可能
BIG!!
大規模テーブルを
スキャンする実行計画
実行計画
作成
<統計情報>
•20億件
•500GB ：
空
DBA
統計情報設定
統計情報カスタマイズ
設定する統計情報は
「業務Tmへのヒアリングで見積もる」
+
「一部は機械的に生成」

29
プランナ
pg_dbms_stats
PostgreSQL
本来の
統計情報
実行計画
“独自に設定された”
“固定化された”
統計情報
生成
pg_dbms_stats × 統計情報カスタマイズ機能
統計情報カスタマイズ機能はpg_dbms_statsの
追加機能として開発しました
DBA
・テーブル行数
・テーブルサイズ
・列幅
・列の固有値
・列のヒストグラム、MCV
など
■pg_dbms_stats × 統計情報カスタマイズ機能
直接設定！

30
プラットフォームトラブル
無停止
メンテを
DRサイト
用意！
リスクと
対峙
トラブル
守れ！
大量SQL
の性能
プラット
フォーム
トラブル
様々なトラブルが発生！
原因はPG？
それとも…？

31
リソース使用量に異常発生！
PostgreSQLの
サーバログ確認
APサーバの
ログ確認
DBサーバの
カーネルログ
確認
他のリソース使用
状況確認
OK
OK
OK
OK
試験中にDBサーバに異変が(´Д｀lli)
CPUのsysが高騰している(常に80%以上)
→PostgreSQLに問題はなさそうなので、
Linuxの性能解析ツール(perf)で調べてみることに

32
カーネルサイドからのアプローチ
perf topの状況を見ると、PostgreSQL以外に原因がありそう
■perf top結果(一部抜粋)
320878.00 29.0% SpinPause /usr/java/…/libjvm.so
187781.00 17.0% _spin_lock_irq [kernel.kallsyms]
143784.00 13.0% read_hpet [kernel.kallsyms]
109362.00 9.9% ParallelTaskTerminator /usr/java/…/libjvm.so
35295.00 3.2% native_write_msr_safe [kernel.kallsyms]
33563.00 3.0% intel_idle
25783.00 2.3% _spin_lock
19725.00 1.8% _spin_lock_irqsave
11848.00 1.1% find_busiest_group
2835.00 0.3% compaction_alloc [kernel.kallsyms]
2782.00 0.3% unmap_vmas [kernel.kallsyms]
2603.00 0.2% rb_next
•調べてみるとRHEL6.2にあったTransparent Huge Page(THP) のバグを踏んでいたよう
•THPを無効にすることによりCPUのsys高騰が解消した
もしかして、
HugePage関連？
Linuxカーネル
技術者

33
再び異常発生！また！？
試験中にDBサーバのレスポンスが急激に悪化ヽ(ヽ゜ロ゜)
vmstatを見るとswapが大量発生
vmstatの結果(一部抜粋)
procs -------------memory------------ --swap-- ---io---
r b swpd free buff cache si so bi
00:13:39 22 6 1446440 23304532 108560 66972348 504 1374 15280 …
00:13:44 11 6 1451608 23112444 108648 67165456 786 1281 19406 …
00:13:49 10 6 1457416 23168188 108800 67330992 125 1184 18972 …
00:13:54 14 6 1466048 22865104 108892 67517832 660 1794 22452 …
00:13:59 28 5 1471792 22766112 108980 67579072 130 1203 14629 …
00:14:04 11 3 1475952 22519940 109068 67685576 46 842 10079 …
00:14:09 27 1 1482372 22400092 109180 67703616 182 1323 6529 …

34
DBサーバのメモリ使用量が多い事は、これまでも話題に上がっていた
なので、まずはメモリ使用量を削減する対策を実施
shared_buffersを小さくする
work_memを小さくする
コネクション数削減
PostgreSQL以外のプロセスのメモリ使用量も確認・削減
など
メモリの使過ぎが原因かも！

35
え！？あれ！？
メモリが空いているにも関わらず、swapが起きている！
これには別の原因がありそう！
vmstatの結果(一部抜粋)
procs -------------memory------------ --swap-- ---io---
r b swpd free buff cache si so bi
00:13:39 22 6 1446440 23304532 108560 66972348 504 1374 15280 …
00:13:44 11 6 1451608 23112444 108648 67165456 786 1281 19406 …
00:13:49 10 6 1457416 23168188 108800 67330992 125 1184 18972 …
00:13:54 14 6 1466048 22865104 108892 67517832 660 1794 22452 …
00:13:59 28 5 1471792 22766112 108980 67579072 130 1203 14629 …
00:14:04 11 3 1475952 22519940 109068 67685576 46 842 10079 …
00:14:09 27 1 1482372 22400092 109180 67703616 182 1323 6529 …
最近コミュニティで、
似たような事象が
報告されていたような。
PostgreSQL技術者

36
リモートのメモリが使えない！空いているのに！
メモリ (32GB)
メモリ (32GB)
メモリ (32GB)
メモリ (32GB)
メモリを確保する際、設定状況によってはリモートのメモリを使うことができず、ローカルメモリをスワップしてしまう
CPU
CPU
CPU
CPU
メモリの余りがない…
メモリインタリーブを有効にすることで解決！
ローカルメモリ
リモートメモリ

37
解決に至るアクティビティ
他の技術者との連携
コミュニティの情報をキャッチアップ

38
リスクと対峙
無停止
メンテを
DRサイト
用意！
ラスト
リゾート
トラブル
守れ！大量SQL の性能
リスクと対峙
新規機能盛りだくさん
色々便利だけど・・・

39
チャレンジにはリスクが伴う
例えば
最終テストに差し掛かっていたある日、
PostgreSQLがSEGVで落ちた。
→ 再現も難しい・・
→ PostgreSQLに懸念の目が・・
新しい機能！
新しい仕組み！
＋
＝
未知の
トラブル
PostgreSQL 大丈夫？・・・
周りの人

40
リスクに立ち向かう
そこはOSS
ソースコードとコアダンプがある。開発元と共に原因を特定。
パッチを書いて、根本対処
Program received signal SIGSEGV, Segmentation fault.
pg_detoast_datum_packed (datum=0x2) at fmgr.c:2273
2273 if (VARATT_IS_COMPRESSED(datum) || VARATT_IS_EXTERNAL(datum))
(gdb) bt
#0 pg_detoast_datum_packed (datum=0x2) at fmgr.c:2273
#1 0x00000000006d5c24 in bpchargt (fcinfo=0x7fffdc6b4f80) at varchar.c:801
#2 0x000000000072127f in FunctionCall2Coll (flinfo=<value optimized out>, collation=<value optimized out>,
arg1=<value optimized out>, arg2=<value optimized out>) at fmgr.c:1327
#3 0x00000000006c972f in ineq_histogram_selectivity (root=0xfca988, vardata=0x7fffdc6b54a0,
opproc=0x7fffdc6b5410, isgt=1 '¥001', constval=16558024, consttype=1042) at selfuncs.c:836
・
・
・
(gdb) p *(Form_pg_statistic) ((char *) vardata->statsTuple->t_data + vardata->statsTuple- >t_data->t_hoff)
$2 = {starelid = 900400380, staattnum = 12, stainherit = 0 '¥000', stanullfrac = 0, stawidth = 4, stadistinct = 2, stakind1 = 1, stakind2 = 3,
stakind3 = 0, stakind4 = 0, stakind5 = 0, staop1 = 1752, staop2 = 1754, staop3 = 0, staop4 = 0, staop5 = 0}
・
・
・
hash = hash_create("dbms_stats relation statistics cache",
MAX_REL_CACHE,
&ctl, HASH_ELEM | HASH_CONTEXT);
・
・

41
リスクを制御する
エンジニアの力
自力解決・サポート連携でリスクと対峙・軽減する → とても大事
必要以上にリスクを背負わない → これも大事
エンジニアの力が試されるところ
有益な
効果
リスク

42
跳ね返した
無停止
メンテを
DRサイト
用意！
リスクと
対峙
トラブル
守れ！
大量SQL
の性能

43
限界まで使い倒した後に見えたもの
「ポテンシャルを引き出すこと」 PostgreSQLの魅力の一つは豊富な拡張機能外部モジュールは最大限活用すべし
「石橋を叩いて備えること」問題はどうしても発生してしまう捕捉手段と効果的な対策を持っておくことが大事
「OSSであることを生かすこと」機能がなくとも、開発でカバーできる最後に求められるのは製品能力ではなく、現場能力
ミッションクリティカルな環境で、強く感じた3か条

44
PostgreSQLとNTTデータ - この先に -
パラレルクエリカラムナストア
BlockRange INdex
双方向レプリケーション FDW+JOIN Pushdown パーティション機能強化
監査強化権限分掌プロファイラ
より強固に
より高速に
より広大に
進化を続ける PostgreSQL を武器に
さらに高いハードルに挑んでいる

45
PostgreSQLオリジナルの機能・性能
RDBMSとしての機能・性能
PostgreSQLとNTTデータ – 新領域へ -
商用の代替ではない
PostgreSQL オンリーの領域に挑んでいる
？
異種製品 + FDW
JSON型
Custom Plan API

46
おわりに
PostgreSQL
×
NTT DATA はこれからも
PostgreSQL & コミュニティ
とともに歩んでいきます

NTT DATA と PostgreSQL が挑んだ総力戦

NTT DATA と PostgreSQL が挑んだ総力戦

More Related Content

What's hot

Similar to NTT DATA と PostgreSQL が挑んだ総力戦

More from NTT DATA OSS Professional Services

NTT DATA と PostgreSQL が挑んだ総力戦