Tech Sketch Bucket of Technical Chips by TIS Inc.

PGECons活動成果発表会参加レポート

Pocket

PostgreSQLエンタープライズ・コンソーシアム(略称:PGECons)の2013年度活動成果発表会が2014/4/25に開催されました。ここでは活動成果報告会の様子や、正会員として1年間活動してみた感想を書いてみようと思います。


PostgreSQLエンタープライズコンソーシアム(PGECons)とは

PostgreSQLエンタープライズコンソーシアム (以下PGECons)は、エンタープライズの業務システムでの利用を想定したPostgreSQL本体および各種ツールの情報収集と提供、整備といった活動を通じて、ミッションクリティカル性の高いエンタープライズ領域へのPostgreSQLの普及を推進することを目的として設立された団体です。国内でPostgreSQLの普及促進を行う団体としては 日本PostgreSQLユーザ会 (JPUG)が有名ですが、PGEConsはより企業ユースでの普及促進をターゲットに活動しており、企業単位での参加が前提となっている点が異なります。

2012年4月に10社で発足したPGEConsは、2014/4/17現在で正会員16社、一般会員27社の会員企業が活動を行っています。2年目となる2013年度は、性能について検証を行う「性能ワーキンググループ(WG1)」と、データベース移行の考慮点や移行方法を検討する「移行ワーキンググループ(WG2)」、データベース設計や運用について検討などを行う「設計運用ワーキンググループ(WG3)」という3グループにて活動が行われ、2014/4/17に PGECons のWebサイト 上で活動成果ドキュメントが公開されるに至りました。なお、実際の活動成果ドキュメントはWG1~WG3の本編だけで合計500ページを超える大作で、読者側にも気合と体力が要求されるシロモノとなっていますのでご注意ください。。。

2013年度活動成果発表会

活動成果のサマリーや重要なエッセンスを紹介するセミナーとして、2014/4/25に活動成果発表会が開催されました。会場は昨年と同じく日本ヒューレット・パッカード株式会社の本社ビルです。ここはドラマ「半沢直樹」のロケ現場としても有名で、PGECons理事長のNTT OSS岩田センター長も早速半沢ネタを交えた開会の挨拶で場を盛り上げておられました。なお、セミナー会場は200名程度収容できる大きな会場でしたが、セミナー開始時点でほぼ満席の状態で、PGEConsの活動成果に対する関心の高さが感じられました。

PGECons.JPG

WG1:性能ワーキンググループ活動成果報告

富士通株式会社の菅原さんから性能ワーキンググループ(WG1)の成果が報告されました。WG1の2013年度の活動テーマは、スケールアップ検証、パーティショニング検証、ハードウェア活用(SSD)検証、スケールアウト検証(Postgres-XC)の4つで、それぞれのテーマの検証結果について解説されました。

スケールアップ検証

ここでは80コアCPUのマシンを使ったPostgreSQLのスケールアップ性能の検証結果が報告されました。80コアCPUマシンにおける性能検証は2012年度にPostgreSQL 9.2を使って一度実施されましたが、この1年の間にリリースされたPostgreSQL 9.3で傾向が変わっていないかを確かめる定点観測の位置づけで今年度改めて検証が行われました。PostgreSQLサーバに接続するクライアント数を変化させながら9.2と9.3の参照性能を比較した所、コア数と同じ80クライアントまでは線形に性能が向上する傾向は一致しましたが、32クライアント以降で9.3の方が最大14%ほど性能が出なかったという結果が報告されました1

PGECons_WG1_92_93.png

次に9.3の新機能として追加された「ページチェックサム」が参照性能に与える影響について報告されました。「ページチェックサム」はPostgreSQLのデータブロックの中身が壊れた時に早期に検出するための仕組みでデータ保護の観点で有用ですが、性能に与える影響が気になる機能です。検証ではクライアント数が60を超えたあたりから性能劣化が見られる結果となっていましたが、コンパイルオプションを変更2することで性能劣化が緩和された結果も紹介されており、性能チューニングの奥深さを感じられる検証となっていました。

PGECons_WG1_93checksum.png

パーティショニング検証

PostgreSQLのパーティショニング機能はテーブルの継承、トリガ関数、CHECK制約を組合せて実現されるため、データ更新、参照時のパーティション選択にかかる計算コストが高く、一般的に100パーティション以上は非推奨と言われています。ここではパーティションテーブルに対する挿入、検索、削除性能についての検証結果が報告されました。

挿入性能は、データ挿入先のパーティション選択処理を

  • PL/pgSQLで静的関数として実装
  • PL/pgSQLで動的関数として実装
  • C言語関数として実装
  • 単表:トリガー関数を使用せず、対象パーティションへ直接挿入

の4通りの方法で実装して測定され、(性能良)単表>C言語関数>動的関数>>>静的関数(性能悪)という結果が紹介されました。ただ、パーティションへの直接挿入やC言語関数はアプリケーション側の実装負荷が高くなるので、要求性能、データ量と実装負荷がトレードオフの関係になるということでした。

PGECons_WG1_partition.png

検索性能は約180パーティションに分割したテーブルと単表のテーブルで測定され、いずれもパーティション表の方が高速という結果から、100パーティション以上だからといって性能不利になることはないという報告がされていました。また、削除性能として、

  • データを削除するDELETE文を実行後にVACUUM、ANALYZE処理を行う
  • 削除データの格納パーティションをTRUNCATEする

の2通りのデータ削除性能が測定され、こちらは後者の方法が圧倒的に優位という結果が得られていたので、大量のデータをバッチ処理等で1度に削除する運用が必要なら、積極的にパーティションを活用するべきだと思いました。

ハードウェア活用(SSD)検証

ここではHDDの代わりにSSDを使った場合の性能について報告されました。PostgreSQLのデータディレクトリ配下のデータのみ、インデックスのみ、WALのみ、といった様々なデータ配置が試されましたが、結果として「WALのみといった一部分をSSDに配置しても性能改善は限定的で、全ての資源をSSDに配置しないと劇的な性能向上効果は得られない」とのことでした。また、更新直後のインデックスオンリースキャンでは大きく性能が落ち込むという結果も紹介されていました。

PGECons_WG1_indexonly.png

インデックスオンリースキャンに失敗するとヒープからもデータを参照しますが、この際更新後のVACUUMが実行されていないとPage Pruning処理(ページに閉じたVACUUM処理)が実行され、WAL書き込みが発生し遅くなる、ということのようです。検索処理でもWALへの書き込みが発生しうるというのはあまり知られていない事実だと思いますので、この辺りの話は実際の検証結果からしか得られない深いノウハウだなと感じました。

スケールアウト検証(Postgres-XC)

Postgres-XCを使ったスケールアウト検証は2012年度にも実施されましたが、PostgreSQL単一ノードの性能よりも悪くなる等十分な検証結果が得られなかったため、2013年度も継続して実施されました。その結果、ノード数増加(1→4)に伴ってスループットが参照系で約24倍、更新系で約3倍向上する結果が得られていました。また、ノード数増加(1→4)に伴ってデータベースサイズを増加させた場合でも参照系のスループットは約2.8倍向上し、更新系でもほぼスループットが一定となり、期待した結果が得られていたようです。

PGECons_WG1_xc.png

WG2:移行ワーキンググループ活動成果報告

NECソリューションイノベータ株式会社の岩浅さんから移行ワーキンググループ(WG2)の成果が報告されました。WG2の活動テーマである「異種DBMSからPostgreSQLへの移行を検討するガイドライン作成」は2012年度に一度ドキュメントが公開されていますが、2013年度は検討が不足していた箇所の掘り下げ、未着手だったサブテーマの解消という観点で活動が行われ、バージョンアップされたドキュメントが公開されました。

データ移行

データベースに格納されたデータをPostgreSQLに移行する「データ移行」ではOracle以外にSQL Server、DB2が移行元のDBMSとして検証対象とされました。一つ興味深かったのはPostgreSQLにデータをロードするツールとしてCOPYコマンドとpg_bulkloadを使った時の性能測定結果です。pg_bulkloadは高速なデータロードツールとして知られているので、データ投入時に文字コード変換を行うとCOPYコマンドより時間がかかるという結果は意外に思えましたし、移行ツールを選択する新たな知見が得られたと感じました。

PGECons_WG2_load.png

ストアドプロシージャ

「ストアドプロシージャの移行」では、2012年度に行われたOracleのPL/SQLからPostgreSQLのPL/pgSQLへの移行調査に加えて、2013年度はSQL ServerのTransact-SQL、DB2からの移行が調査されており、構文の違いや移行方法についての調査結果がドキュメントに記載されているとのことでした。ストアドプロシージャはスキーマ定義やSQLの様に機械的に変換するのが難しく、PostgreSQLへの移行の鬼門となる部分ですが、2012年度、2013年度と着実にノウハウが整理されていることが感じられました。

チューニング

2013年度に追加された「チューニング編」ではDBMSによるチューニング手法の違いについて紹介されました。商用DBMSに備わっている「自動パラメータチューニング」「ヒント情報」「統計情報のセーブ/ロード」「バッファ固定」といった機能が備わっていないことがPostgreSQLのウィークポイントとして紹介されていましたが、ヒント情報や統計情報のセーブ/ロードといった機能を提供するアドインツールが徐々に登場しており、今後も運用面のツールやノウハウの拡充を期待したいところです。

PGECons_WG2_tuning.png

バージョンアップ

最後に「バージョンアップ編」としてPostgreSQLのバージョンアップ手法について紹介があり、マイナーバージョンアップやメジャーバージョンアップ時にどのような手法、ツールを利用できるのかがわかりやすく整理され、解説されていました。バージョンアップはどのような手順で行えばよいか、整理された情報も存在しないのが現状で、今回のドキュメントは運用者に有用なものと感じられました。

PGECons_WG2_vup.png

WG3:設計運用ワーキンググループ活動成果報告

NTT OSSセンタの黒岩さんから設計運用ワーキンググループ(WG3)の成果が報告されました。WG3はPostgreSQLを安定稼働させるための運用性、可用性確保への期待に応えるべく2013年度から新設されたワーキンググループですが、PGECons参加企業の中でも関心が高かったようで正会員16社中14社が参加するという充実した陣容となっていました。

講演では企業システムに求められる非機能要求からDBMSに求められる要求が整理され、その要求に対してPostgreSQLがどのようなシステム構成、機能で対応できるのか、という流れで解説されていましたが、「OSSのDBを使って大丈夫なのか」という漠然とした不安感を払拭するには「PostgreSQLで何ができて、何ができないのか」を細分化して把握する必要があると感じられました。

PGECons_WG3_requirement.png

また、運用技術検証として、

  • pgpool-IIとPostgreSQLストリーミングレプリケーションを組み合わせたクラスタ構成での障害検証
  • バックアップ方式によるバックアップ取得、リカバリの実行時間計測
  • PostgreSQLストリーミングレプリケーション環境でのバックアップ運用手順
  • PostgreSQLを監視するポイント、アラート発生時の対処方針を整理したケーススタディ

についても紹介されました。

PGECons_WG3_test1.png

PGECons_WG3_test2.png

PostgreSQLは運用ノウハウに関する情報が少ないのが課題だと思われるので、実際の検証を通じて整理された運用ノウハウが公開されることは、PostgreSQLの普及に向けた有用な知見になると思います。

PGEConsでの活動について

弊社(TIS)も2012年度から正会員企業としてPGEConsに参加し、2012年度はWG2、2013年度はWG3の調査、検証活動に携わってきました。この2年間の活動を振り返って、PGEConsについて感じていることを書いてみます。

コンソーシアム活動の様子

実機検証の期間以外は活動の中心となるのが月2回開催される検討会という場です。検討会は参加企業のメンバーが集まって、活動方針の検討、調査、検証時の課題対応、作成したドキュメントのレビューといったテーマで議論が行われています。この場にはPostgreSQLに精通したエンジニアが集結しており、PostgreSQLに関して濃い議論や技術ノウハウを共有し合える場を得られるのは非常に貴重だと思います。ただ、メンバー同士で求める要求が高くなってしまいがちで、PostgreSQLにまだ詳しくないメンバーには敷居が高く、参入しづらい環境になりつつあると反省する部分もあります。

PGEConsの今後の展望

次年度に向けたPGEConsの活動方針でも「定着から発展へ」というキーワードが挙げられています。これはPostgreSQLの高いレベルの情報発信、共同検証だけではなく、エンドユーザやPostgreSQL未経験のエンジニアといった幅広い層を巻き込まなければ、PostgreSQLの普及も拡大しないという問題意識があるように思います。とはいえ、日頃はビジネスで競合しそうなベンダ、SIerが集まって発足した団体としてはこの2年うまく一致団結して成果を残せてきたと思います。次年度以降も息切れしないよう気をつけながら、PostgreSQLの普及に寄与できるようにより活動範囲を広げていきたいと思います。

 


1 ただ、計測後の分析で9.3の方がPostgreSQLサーバのCPUidleの割合が高く負荷クライアント(pgbench)側に問題があったかもしれないということで、9.3の方が性能上不利であるかどうかは結論付けられなかったということでした。

2 MakefileのCFLAGSに-msse4.1 -funroll-loops -ftree-vectorize を付与

エンジニア採用中!私たちと一緒に働いてみませんか?