ntt data と postgresql が挑んだ総力戦

Copyright © 2014 NTT DATA Corporation

2014年12月5日株式会社NTT DATA

笠原辰仁、澤田雅彦

NTT DATA と PostgreSQL が挑んだ総力戦

～ PostgreSQL を極限まで使い切ったその先に見たものとは？～

PostgreSQLカンファレンス2014

2 Copyright © 2014 NTT DATA Corporation

ＩＮＤＥＸ

PostgreSQLとNTT DATA

事例概要

立ちはだかる壁

その先に

おわりに


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センタ設立


OSSというだけで適用が進む時代が終わる。 NTT DATAでは全社展開のためモデル作成を実施。エンタープライズ分野での弱点をカバーすべく研究開発、新規ソリューション開拓も活発に。

普及・継続的取り組みへ(2008 - 2013頃)

年度主な出来事

2008 【PG】 PostgreSQL 8.3(autovacuum 標準装備)

2011 【PG】 PostgreSQL 9.1(同期レプリケーション機能の採用)

2012 【コミュニティ】 PGECons 設立

2013 【NTTD】 GresCube 販売開始


そして今(2014～)

NTT DATA では、OSSスタックが高い利用頻度に。 PostgreSQLのコモディティ化が進む。

大規模システムでも、当たり前にPostgreSQLを使う今。

従来のPostgreSQLの当たり前の使い方だけでは太刀打ちできない要件が立ちはだかる。


メインサイト

今回ご紹介する事例

認証データ

システム基幹部分

災対サイト

業務・集計データ

小売店

モバイル

POS

POS

PC

社内外の他システム

モバイル向け Web/AP

社内向け Web/AP

集配信

認証基盤

オンライン APサーバ

オンライン帳票サーバ

バッチ APサーバ

モバイル向け Web/AP

認証基盤

オンライン APサーバ

オンライン帳票サーバ

バッチ・取引 APサーバ

業務・集計データ

非同期レプリケーション

PostgreSQL

販売店舗情報など

売上請求情報など

PostgreSQL

世界有数のエネルギー元売会社の情報系システム販売情報等をもとに、集計等をほぼリアルタイムで行う


特徴(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

およそ利用可能な拡張モジュールは全て取り入れた


迫りくる要件・トラブル

無停止メンテを

DRサイト用意！

リスクと対峙

プラットフォームトラブル

守れ！大量SQL の性能


リスクと対峙







ハードなメンテもオンラインで実施したい

VACUUM FULL、REINDEX はどうしよう？


どうするメンテナンス設計！？

～数GBの小規模テーブル

数百GB以上の大規模テーブル

システム性能への影響小 →auto vacuumに任せる

システム性能への影響

→メンテナンス枠にて手動で実施

VACUUM

24時間DBアクセス昼夜問わず大量バッチ

何は無くともまずVACUUM設計システムへの影響をミニマムに！


万が一に備えて

そこで、外部モジュール！地味に、便利なコマンド！

pg_reorg

オンラインVACUUM FULL オンラインCLUSTER

自作ツール

CREATE INDEX CONCURRENTLY ALTER INDEX でスワップ！

VACUUMができなかったら？インデックスが荒れてしまったら？

排他ロック要らず！


無停止メンテの実現に向けて

必要なメンテナンスと影響を見極める

想定外の事態にも備えておく

想定外のリソース枯渇を抑える。 VACUUMをユーザの制御下に！

いざという時にオンラインでメンテ！外部モジュール等でPostgreSQLをカバー



リスクと対峙






東日本、西日本間でDR

PostgreSQLのDRはどのように実現する？


災害対策（Disaster Recovery)を検討せよ

災害時にも止められない！

→災害の被害を受けてもサービスを継続するために、遠隔地にメインサイトのコピー(災対サイトの構築)を作る！

東日本(メインサイト) から西日本(災対サイト)

DR対象は(ほぼ)システム全体

課題はPostgreSQLのメイン->災対へのデータ同期・・・

DBデータ

西日本

DBデータ

東日本


やっぱり Streaming-Replication !

アーカイブログ転送

ＳＲＨＷレベルでのレプリケーション

決

○高機能 (運用楽そう)

△実績がない… 検証必要

×運用が面倒

△実績がない… 検証必要

×価格が高い

運用

導入

○運用楽 !

頼れるサポート (Fujii Masao)


・・・でも本当に大丈夫か？SR

データアーカイブログ

WAL

圧縮して高速に転送

解凍・リカバリ

マスタスタンバイ

最大負荷量から必要な帯域をサイジング初期同期はNW経由・・でもOKそうだ・・もしレプリケーションが追いつかなくなったら？

データ WAL

PostgreSQLが自動でアーカイブログからの復旧に切り替え！

想定時間内にキャッチアップ！


すごかった！SR

今のところレプリケーション起因の問題はなし

PostgreSQLのSRは

DR用途にも十分実用的！

いいね！Streaming-Replication！


守れ！大量SQLの性能！



リスクと対峙


守れ！大量SQL の品質


対象は数万本のSQL 性能を守るのは

数名のPG有識者


10Mにおよぶ

AP

シビアな状況が我々を悩ませた…

数万のSQL

1000人規模の

開発体制

タイトなスケジュール

ポスグレ経験者少な目

SQL性能どう守る？

迅速な SQL

チューン?


10Mにおよぶ

AP

シビアな状況が我々を悩ませた…

数万のSQL

1000人規模の

開発体制

タイトなスケジュール

ポスグレ経験者少な目

SQL性能どう守る？

迅速な SQL

チューン?

複雑すぎるSQLを書いてしまう → SQLのメンテナンス性、可読性低下

SQLは書いたけど、多くのSQLで性能問題が発生 → 期間内にすべての性能問題を解決できない

性能要件を満たさず、トラブルを引き起こすSQL(= 問題SQL)を撲滅するために、我々が用意したものは…？


5つの関門を用意

？ 1

？ 2

3

？ 4

？ 5

SQLは1～5の関門を通り、

一人前のSQL(=使用可能なSQL)になる

!?

？


1つ目 - ＳＱＬガイドライン

PJが持っていたSQLガイドラインで、SQLのメンテナンス性を担保

PostgreSQLのノウハウで、“PostgreSQL向けのSQL”に

SQLガイドライン

• 1行当たり最大○○文字 • コメントには/*…*/を使用する • ORDER BYには列名を記載する：

SQLガイドライン PostgreSQLのノウハウ

• NULLと文字列を連結すると空文字になる

• 異なるデータ型で比較しないこと：


チェック項目結果

テーブルのJOIN数チェック OK

直積使用チェック OK

同じテーブルを複数回見ているかチェック OK

中間一致使用チェック中間一致はフルスキャンになり性能問題を起こす可能性があります。 pg_bigmインデックスを利用しましょう

：：

2つ目 - ＳＱＬチェックツール

とはいえ、ヒューマンエラーはある(´Д｀lli)

“ＳＱＬガイドラインに従ったＳＱＬ“になっているか20以上の項目を自動で判別

NGの場合は、チェック観点を表示

■SQL静的チェック結果（イメージ図）


3つ目 - 実行計画チェックツール

サービス開始後、SQLの性能問題が起きないために、

“実行計画”をチェック

<実行計画> Sort ->Nested Loop (cost = … -> Index Scan (cost = … -> Seq Scan (cost = … ：

見積もりコストは高くなりすぎていない？

インデックス使われてる？

ただし！サービス開始後に生成される“リアル”な実行計画が必要！


4つ目 - HINT句でアジリティチューニング

HINT句を使い直接実行計画を制御することで、

アジリティなSQLチューニングを可能に

○ HINT句を使用するメリット

SQLを書き換えるよりも改修時間が短い！ • 実行計画を確認して、使用するインデックスやスキャン方法を変えるだけ

SQLの実行結果の内容は変わらない！ • HINTを付与するだけなので、SQLのリテスト不要

/*+ IndexScan(hoge) */ SELECT * FROM hoge WHERE id = 9999;


大量SQLの性能を守れました

SQLガイドライン 1

SQLチェックツール 2

3

アジリティSQLチューニング 4

SQL書き換え 5

チェック済みの実行計画をサービス開始後も使用

ドキュメントとツールによる性能問題防止

遅いSQLの性能問題解決


リアルな実行計画？PGを騙す？

実行計画チェックの実現、大量SQLの性能担保にあった

2つの課題

■ 2つの課題

1. ダミーの統計情報を生成しPostgreSQLに設定する仕組みがない

→ PostgreSQLを騙す仕組み

2. PostgreSQLを騙すことができても一時的な効果でしかない

→ PostgreSQLを騙し続ける仕組み


「統計情報カスタマイズ機能」作りました

ユーザがテーブルに“任意の統計情報”を設定することが可能

BIG!!

大規模テーブルをスキャンする実行計画

実行計画作成 <統計情報>

• 20億件 • 500GB

：

空

DBA

統計情報設定

統計情報カスタマイズ

設定する統計情報は「業務Tmへのヒアリングで見積もる」

+ 「一部は機械的に生成」


プランナ pg_dbms_stats

PostgreSQL

本来の統計情報

実行計画

“独自に設定された” “固定化された”

統計情報

生成

pg_dbms_stats × 統計情報カスタマイズ機能

統計情報カスタマイズ機能はpg_dbms_statsの

追加機能として開発しました DBA

・テーブル行数・テーブルサイズ・列幅・列の固有値・列のヒストグラム、MCV など

■pg_dbms_stats × 統計情報カスタマイズ機能

直接設定！





リスクと対峙




様々なトラブルが発生！

原因はPG？それとも…？


リソース使用量に異常発生！

PostgreSQLのサーバログ確認

APサーバのログ確認

DBサーバのカーネルログ確認

他のリソース使用状況確認

OK

OK OK

OK

試験中にDBサーバに異変が(´Д｀lli)

CPUのsysが高騰している(常に80%以上)

→PostgreSQLに問題はなさそうなので、 Linuxの性能解析ツール(perf)で調べてみることに


カーネルサイドからのアプローチ

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カーネル

技術者


再び異常発生！また！？

試験中に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 …


DBサーバのメモリ使用量が多い事は、これまでも話題に上がっていた

なので、まずはメモリ使用量を削減する対策を実施

shared_buffersを小さくする

work_memを小さくする

コネクション数削減

PostgreSQL以外のプロセスのメモリ使用量も確認・削減

など

メモリの使過ぎが原因かも！


え！？あれ！？

メモリが空いているにも関わらず、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技術者


リモートのメモリが使えない！空いているのに！

メモリ(32GB)

メモリ(32GB)

メモリ(32GB)

メモリ(32GB)

メモリを確保する際、設定状況によってはリモートのメモリを使うことができず、ローカルメモリをスワップしてしまう

CPU

CPU

CPU

CPU

メモリの余りがない…

メモリインタリーブを有効にすることで解決！

ローカルメモリ

リモートメモリリモートメモリ

リモートメモリ


解決に至るアクティビティ

他の技術者との連携

コミュニティの情報をキャッチアップ


リスクと対峙



ラストリゾート



リスクと対峙

新規機能盛りだくさん

色々便利だけど・・・


チャレンジにはリスクが伴う

例えば

最終テストに差し掛かっていたある日、

PostgreSQLがSEGVで落ちた。

→ 再現も難しい・・

→ PostgreSQLに懸念の目が・・

新しい機能！

新しい仕組み！＋＝

未知のトラブル

PostgreSQL 大丈夫？・・・

周りの人


リスクに立ち向かう

そこは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); ・・


リスクを制御する

エンジニアの力

自力解決・サポート連携でリスクと対峙・軽減する → とても大事

必要以上にリスクを背負わない → これも大事

エンジニアの力が試されるところ

有益な効果

リスク


跳ね返した



リスクと対峙




限界まで使い倒した後に見えたもの

「ポテンシャルを引き出すこと」 PostgreSQLの魅力の一つは豊富な拡張機能

外部モジュールは最大限活用すべし

「石橋を叩いて備えること」問題はどうしても発生してしまう

捕捉手段と効果的な対策を持っておくことが大事

「OSSであることを生かすこと」機能がなくとも、開発でカバーできる

最後に求められるのは製品能力ではなく、現場能力

ミッションクリティカルな環境で、強く感じた3か条


PostgreSQLとNTTデータ - この先に -

パラレルクエリカラムナストア

BlockRange INdex

双方向レプリケーション FDW+JOIN Pushdown パーティション機能強化

監査強化権限分掌

プロファイラ

より強固に

より高速により広大に

進化を続ける PostgreSQL を武器にさらに高いハードルに挑んでいる


PostgreSQLオリジナルの機能・性能

RDBMSとしての機能・性能

PostgreSQLとNTTデータ – 新領域へ -

商用の代替ではない PostgreSQL オンリーの領域に挑んでいる

？

異種製品 + FDW

JSON型

Custom Plan API


おわりに

PostgreSQL ×

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

ntt data と postgresql が挑んだ総力戦

Technology