第25回しくみ＋アプリケーション勉強会レポート

第25回しくみ＋アプリケーション勉強会

AIIT building in Shinagawa 2013年2月9日に産業技術大学院大学にて第25回のしくみ+アプリケーション分科会の勉強会が開催されました。本レポートではその模様をお伝えしたいと思います。

perfを使ったPostgreSQLの解析(後編)

最初は、perfを使ったPostgreSQLの解析という題目でNTTデータの江川氏の講演でした。この講演は、昨年9月29日に実施された前回のしくみ+アプリケーション勉強会での同名講演の後半部分にあたります。前回は、最近注目されている Linuxの性能解析ツール(プロファイラ)であるperfの簡単な仕組み、およびperfとその周辺ツールの使い方がレクチャされました。後半の本編では、実際にPostgreSQLを対象とした解析について、実例を元に話が進められました。

Mr. Egawa at talk 解析の実例については、PostgreSQL8.4からcontribモジュールに加わったauto_explainのオーバーヘッドの解析に焦点をあてていました。auto_explainは、規定時間以上かかったSQLの実行計画を取得することができるモジュールですが、詳細な情報(EXPLAIN ANALYZE相当)を取得する場合にはそのオーバーヘッドに注意すべしとの文言がマニュアルに記載されています。そこで、実際にいくつかのパターンでauto_explainを有効にした場合にどのような類のオーバーヘッドが顕在化するかをperfで解析してみよう、というストーリーでした。

実際にpgbenchを使い、シンプルな参照負荷を大量にかけて全てのSQLの実行計画を吐き出した(ただしI/Oがノイズになるのでログは/dev/nullへ出力)場合、そこそこのオーバーヘッド(スループット低下)があったそうです。これをperf recordコマンドを使ってプロファイリングした場合、ログの整形部分の関数処理がSQL処理実行に占める割合が増加していることが分かりました。つまり、この条件下でのオーバヘッドの大部分はログ生成にあることが簡単に分かるようです。実際にログを吐き出さない状態では、大きなオーバヘッドは観測されなかったようです。

perfを使うことで、非常に軽量、かつ手軽に見えづらいオーバヘッドを俯瞰することができるようです。また、可視化することでその容疑者を分かりやすくあぶり出すことができるのもperfの魅力でした。

pgpool-IIとPostgreSQLストリーミングレプリケーションを組合わせた、高性能、高可用性クラスタの検証

Mr. Nakanishi at talk 次は、pgpool-IIとPostgreSQLを組み合わせた際の可用性に関する検証結果に関するTISの中西氏の講演でした。PostgreSQLは9.0からレプリケーションが可能となっており、スタンバイ側には参照処理を発行することができます。さらにpgpool-IIを組み合わせて、アプリケーションからマスタ/スタンバイへの処理振り分けを透過的に行い、性能をスケールさせることや、マスタ側の故障をpgpool-IIが検知し、自動的にフェールオーバなどを行うことができます。今回の講演では、複数のPostgreSQLでレプリケーションによるクラスタ構成とし、APサーバへpgpool-IIを配置した構成下における、様々な故障時の振る舞いの話となっていました。

今回の講演では、大きく以下の７つのケースに関する検証結果が話されました。

1: PostgreSQLマスタのフェイルオーバ
2: PostgreSQLスレーブのフェイルオーバ
3: 停止したPostgreSQLマスタのクラスタ復帰
4: PostgreSQLサーバ増加時のスケールアウト
5: PostgreSQLサーバ減少時の運用
6: マルチマスタ構成でのpgpool-II watchdog
7: PostgreSQL 9.2でのバックアップ方式

1〜3では、主にPostgreSQLの故障時に、pgpoo-IIが正しくフェイルオーバを起こせるか？またクラスタへの再組み込みができるかの機能検証がされていました。多少、ユーザ側でスクリプト等に手を入れる必要があったものの、概ね問題なく運用ができたそうです。4のスケールアウトでは、条件によってはスケール度合いは違い、特に重いSQLを分散させたケースでは良いスケール性を見せたとのことです。5は動的にクラスタから一つのPostgreSQLインスタンスを外すことが可能かの検証でしたが、pgpool-IIの現行仕様ではエラー無しでの動的ノード切り離しは難しかったようです。

6, 7はpgpool-II新機能とPostgreSQL9.2で可能となったスタンバイからのバックアップ取得に関する機能検証でした。pgpool-II3.2において、pgpool-IIの相互死活監視を行うwatchdog機能が実装されました。これを使ってpgpool-IIによるマルチマスタを組めるかの検証を行ったそうですが、残念ながらまだ現行ではマルチマスタ構成での運用は難しく、Act-Stb構成を推奨するとのことでした。スタンバイからのバックアップ取得については、マスタ性能に影響を与えずにオンラインバックアップが取得できており、効果的な運用が可能になるとのことです

他、HAクラスタソフトであるPacemakerとpgpool-IIとの比較の話あり、講演後の質問でのpgpool-II自体が故障した場合の振る舞いについての議論ありと、可用性の奥深さについて色々考えさせられる講演でした。

使ってみませんか？ pg_hint_plan

最後の講演は、NTTデータの藤井氏から、PostgreSQLで一部商用DBMSに見られるHINT句に相当する機能を利用可能にするpg_hint_planについての講演でした。PostgreSQL本体には、実行計画を直接制御する機能はありません。これは講演中にも話がありましたが、PostgreSQL本体のバグが顕在化しづらくなり、また安易なチューニングを提供することをコミュニティが良しとしていないためです。ただし、非常に高いレベルでSQLの処理性能の安定性が求められるシステムでは、HINT句などの機能が必要となるため、作成されたのがpg_hint_planだそうです。

Mr. Fujii talks on pg_hint_plan pg_hint_planは、某商用DBMSとほぼ同じ記述方法で使えるそうです。実際にデモでは、コミュニティに報告されたPostgreSQLのプランナ不備により最適な実行計画が作成されないSQLを例に、pg_hint_planによる実行計画の最適化が実演されました。

このような場合、従来のPostgreSQLでは、外部から実行計画を矯正するにはenable_seqscanなどのパラメータを変更し、特定のスキャンや結合方式のコストを変更することで可能でした。ただし、この方法では直接的なスキャン方法や結合方法を指定することができないため、間接的な矯正となり、実行はとても難しいものでした。一方、このpg_hint_planは直接どのテーブルにどのようなスキャンをさせるか、またはどのテーブル同士をどのような結合方法にするかをダイレクトに指定できるため、特にHINT句に慣れ親しんだ人には嬉しい機能に思えます。今後の発展がとても楽しみなモジュールです。

終わりに

Lecture scene at Shikumi and Application Seminar しくみ + アプリケーション分科会では、年に4回の勉強会を開催する予定だそうです。今後もPostgreSQLに関する様々なトピックでの勉強会を予定しており、また講演も募集中です。是非、PostgreSQLをお使いの方、または色々な調査や試行をされている方は、本勉強会でお話してみるのはいかがでしょうか？

(補足1)pgpool-IIとPostgreSQLストリーミングレプリケーションの講演に使われた資料はここにあります。
(補足2)pg_hint_planの講演に使われた資料はここにあります。
(補足3)当日の講演の模様はUStreamで配信しました。録画もありますのでご覧ください。

（2013 年 2 月 27 日公開）