pgpool-II とは
SRA OSS, Inc
古跡 智仁
はじめに
本記事では、pgpool-II を使用した PostgreSQL の様々なクラスタ構成を紹介します。pgpool-II は PostgreSQL サーバとクライアントの間に入ってプロキシサーバとして動作するソフトウェアで、多彩な機能をもちます。
第1回目の本編では、pgpool-II の概要について紹介します。
pgpool-II の誕生
pgpool-II の歴史は、2003年ごろ石井達夫氏により PostgreSQL 専用のコネクションプールソフトウェア pgpool が開発されたことに始まります。pgpool の pool はコネクションプールのプールです。その後、レプリケーション機能、フェイルオーバー機能、負荷分散機能など次々に機能が追加されていきます。
2006年には、もう一段の機会に恵まれます。IPA の OSS活用基盤整備事業に採択されて、pgpool を強化した pgpool-II の開発が行われます。パラレルクエリ機能やオンラインリカバリ機能 (以前は停止しないと障害ノードを復旧させることができませんでした)、Webベース管理インターフェイス、3ノード以上のクラスタ構成への対応 (以前は2ノード構成限定でした) は、ここで実現されました。これ以降、開発の中心は pgpool-II に移ります。pgpool-II でない方の pgpool は基本的にはもうリリースしない方針となっています。開発プロジェクト全体の呼称や実行プロセス名として pgpool という呼び名は残りますが、多くの場合それは pgpool-II を指しています。
現在 pgpool-II は「PgPool Global Development Group」の手によって開発が継続されています。世界中の開発者からしばしばパッチが投稿され、また、適用されています。とはいえ同開発グループの中核には石井達夫氏が健在です。pgpool-II は PostgreSQL 関連ツールの開発サイト pgFoundry にて配布されています。同サイトにある PostgreSQL のクラスタ・ソフトウェアの中では、最多のダウンロード数となっています。
pgpool-II の機能
pgpool-II の主要な機能には以下があります。pgpool-II はそれ単体で PostgreSQL のクラスタを構成することもできますし、一部の機能だけを利用して、様々なクラスタ構成のパーツとすることもできます。
コネクションプール
コネクションプールはデータベースへの新規接続を減らすために接続を保持して使いまわす仕組みです。新規接続の受け付けはデータベースサーバにとってコストが高い処理です。再利用を行うことで接続によるオーバーヘッドを低減できます。
PostgreSQL のクライアントが Tomcat のようなアプリケーションサーバであれば、アプリケーションサーバ側でコネクションプールを用意することができます。しかし、Webサーバ上の PHP や Perl では、各 HTTP セッションを処理するプロセスの間で共通に使用できるコネクションプールを作ることは簡単ではありません。例えば PHP 言語で「永続的」な pconnect の機能がありますが、あくまで、Webサーバの単一プロセス内で接続を保持するだけです。pgpool-II は独立したサーバプロセスとして提供されるため、このようなケースでも複数のセッションで共用できるコネクションプールを実現できます。
接続数の制限
PostgreSQL では同時接続数を増やしていくと、あるところからトータル処理性能が低下していきます。各接続を処理するプロセスの使用メモリ量の合計が大きなものになり、また、処理の競合による待ちも増えていくためです。したがって、同時接続数を一定レベルに抑える必要があります。ところが PostgreSQL は設定した最大接続数を超えた接続要求に対してエラーを返す振る舞いをします。これではアプリケーションの配置に制約が生じます。Webサーバであれば、Web側で受け付ける同時接続数を PostgreSQL の同時接続数を下回るようにしなければいけません。
pgpool-II では、pgpool-II に設定した最大同時接続数を超えた接続要求に対して、エラーではなく待たせる動作をします。PostgreSQL とアプリケーションの間に pgpool-II を挟むことで、データベースサーバの同時接続数をエラーを出さずに一定数に抑えることができるようになります。
レプリケーション
レプリケーションとはデータベースの複製を作って、その後にデータ更新処理があっても、同じデータ状態を維持していく機能です。
pgpool-II では、複数の PostgreSQL サーバをバックエンド・ノードとして、アプリケーションからの SQL をノード毎に送ることで、レプリケーションを実現します。全てのノードで SQL がコミットされてからアプリケーションに処理を返すので、データの一致に遅れのない同期レプリケーションとなります。
負荷分散
レプリケーション構成にしている場合、複数ノードで同じデータベースの内容を保持しています。そのため、データベースへのリクエストを分担して処理させることにより、ノードあたりの負荷軽減をねらうことができます。データを書き換える処理は全てのノードで実行しなくてはいけませんが、参照しかしないのであればどれか一つで実行すれば十分です。
pgpool-II では SQL の内容によって参照処理か更新処理かを自動的に区別し、参照の問い合わせについては処理を振り分けて実行させることができます。SQL にヒントのコメントを付けて明示的に全ノード実行か、振り分けかを指定することもできます。参照処理が中心で多数の問い合わせが発生する場合には、負荷分散を効果的に実現できます。
パラレルクエリ
パラレルクエリ (並列問い合わせ) は、1つの SQL について対象となるテーブルを分散配置しておき、各ノードで並列に処理を行い、統合した結果を返すようにする機能です。前節の負荷分散機能では、巨大なテーブルに対して処理をする一つだけの重い SQL を高速化することはできません。振り分けるのは SQL 単位なので、結局どれか1つのノードで処理が行われることになります。
pgpool-II ではパラレルクエリを実行する、パラレルモードを選択することができます。パラレルモードでは、各バックエンドノードは同一のデータではなく、分割されたデータの一部を持ちます。各テーブルをカラムの値で任意の方式でノードに分散配置することができます。また、一部のテーブルについては、分散配置でなく、レプリケーションをさせることもできます。pgpool-II は設定された各テーブルの配置方式にしたがって、SQL を各ノードむけの問い合わせに書き換え、並列実行したうえで結果を統合して返します。アプリケーションからは単一のデータベースにアクセスしているように、すなわち透過的に SQL を実行できます。
関連ツール
pgpool-II に対応した Webベースの GUI管理ツールに pgpoolAdmin があります。PHP で記述され、pgpool-II の状態をモニタしたり、各種運用操作を対話的に行うことができます。名称は pgpoolAdmin ですが、対象は pgpool でなく pgpool-II です。
pgpoolAdmin を使う場合には、どのバージョンの pgpool-II をサポートしているかに注意する必要があります。pgpool-II の設定ファイルはバージョンアップとともに少しずつ変わっていますので、時期によっては pgpool-II の最新版に pgpoolAdmin が対応していないケースがあります。
オープンソースの HA ソフトウェア Heartbeat むけに書かれた pgpool-II のリカバリエージェントスクリプトが pgpool-ha という名前で公開されています。OCF (Open Cluster Framework) 形式で記述されているため、他の OCF 形式に対応したクラスタソフトウェアにも転用できます。pgpool-II は振り分けを行う部分を担うため、pgpool-II が落ちるとデータベースクラスタ全体が止まってしまいます。そこで、pgpool-II 部分の可用性を高めることが考えられ、HA ソフトウェアで pgpool-II を保護するという構成がよく組まれます。
おわりに
pgpool-II とその関連ツールは pgFoundry で配布されています。pgpool-II に関するメーリングリスト、開発リポジトリもここでホストされています。
http://pgfoundry.org/projects/pgpool/
pgpool-II のユーザマニュアルはソフトウェア一式の中に含まれますが、オンラインでも公開されています。
http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-ja.html
本章では概要説明に留めましたが、次回以降は pgpool-II を活用した各種構成を具体的な設定方法、導入方法とともに紹介します。次回はレプリケーション構成です。