PostgreSQLエンタープライズ利用の指針が続々公開へ：Database Watch（2013年5月版）（1/2 ページ）

OSSながら、堅牢性やスケーラビリティの面からエンタープライズ用途でも採用されることの多いPostgreSQL。大規模運用のための指針や移行のノウハウを公開する動きが活発化しています。今回はPGECの活動成果をウォッチ！

[加山恵美，＠IT]

　4月22日、PostgreSQLエンタープライズ・コンソーシアム（以下、PGEC）は設立1周年を迎えるとともに、2012年度の活動成果を発表しました。活動成果は性能WGと設計運用WGから報告され、報告書は同会サイトにて公開（リンク）されています。いずれも企業へのPostgreSQL導入で直面する疑問をテーマとしており、とても実践的な内容となっています。

性能WG：スケールアップとスケールアウト検証結果

　性能WGからは大規模運用を想定し、PostgreSQL 9.2におけるスケールアップとスケールアウトの検証が行われました。報告したのは日立製作所の福岡博氏（写真）。

　まずはスケールアップから。

　近年のサーバはマルチコア化が進んでいるため、あらゆるアプリケーションにおいてコア数を増やした場合にリニアにスケールアップできるかどうかに関心が寄せられています。中間活動報告では40コアまでスケールすると報告されましたが、今回は80コアで検証されました。

　参照系のスケールアップ検証ではpgbenchを使用したベンチマークを実施しています。結果を分かりやすくするために、やや負荷が高くなるようなスクリプトで検証したところ、コア数と同じ、80クライアントまでリニアに性能が向上するのが確認できました。

参照系スケールアップ検証結果

　更新系スケールアップ検証では、JdbcRunnerを使用してベンチマークをとっています。コア数を固定した状態で同時接続数を増やしていくと、平均TPM（Transaction Per Minute）が向上するのが確認されました。参照系、更新系、いずれにしても期待通りの結果です。ただし40コア検証時の結果と合わせて比較すると、性能向上のようすは40コアと80コアのいずれでも確認できるものの、その性能自体はあまり変わりません。中には40コアが80コアを上回る性能を出したところも。

　リソース使用状況を見ると、40コア検証時点で既にサーバやクライアントのCPUは余っている状態でした。つまり、ボトルネックとなっているのはストレージのI/Oだったということです。80コアの検証でもやはりネックはストレージでした。こうとなるとコア数を増やしても、十分に処理能力を使い切れなくなってしまいます。SSDでボトルネック部分を改善するとどういった結果になるのかは気になるところです。

　スケールアウトについては、カスケードレプリケーション、pgpool-II、Postgres-XCを使った構成を組んで検証しています。

カスケードレプリケーション構成でのスケールアウト検証

　まずはカスケードレプリケーションでノード数を変化させ、マスタDBの更新性能を測定した場合について見ていきましょう。

　ノード数増加が性能に影響を与えるかどうかの確認です。結論としてはノード数を増やしても更新性能は安定しており、カスケードレプリケーションのノード数を増やすことでマスタの更新性能に影響を与えることはなさそうです。ただし、ネットワークやストレージなどがボトルネックとなる可能性は否定できないため、個別に実際の構成に応じた検証が必要であるとしています。

pgpool-IIを使ったスケールアウト検証は予想通り

　pgpool-IIでノード数増加に応じた性能を検証したところ、更新系ではノード数に応じて性能が劣化、参照系ではノード数に応じて性能が向上するのが確認できました。

　そもそも、pgpool-IIはサーバとクライアントの間でプロキシサーバ的に動作するものです。

　更新系処理の場合、ノード数が増えれば、各ノードに対して同期処理の負荷がかかるわけですから、そもそも性能的には不利です。検証チームによると「予想よりは健闘している（予想ほど劣化していない）」という印象だったようです。その一方で、参照系ではノードが増えることで応答速度は高まり、スケールメリットが生かせることが、数値的にも証明されることになりました。

Postgres-XCを使ったスケールアウト検証は

　Postgres-XCは大規模システムを想定したデータベースクラスタです。まだリリースされて間もなく、WGメンバーの間で関心が高まっていたため、検証対象となったようです。

　更新系ではノード数が増加すると（ノードごとの平均性能は若干劣化しますが）全体の性能は向上するのが確認できました。参照系ではノード数が増加するごとに性能向上は見られるものの、PostgreSQL単体のほうが優れた性能が出ていました。WGは「Postgres-XCに適した性能測定ではなかった可能性がある」と見ており、今後は条件を変えて測定することを検討しています。

　これらの結果から、pgpool-IIは参照系、Postgre-XCは更新系に強いという特徴があることが、数値的にも証明されたことになります。

　今回の検証に伴って、興味深いデータも開示されました。データのロード時間です。

　これらはシステム構成によって、大きく変動するものですが、検証環境で使用した構成では、100GBだと2時間半、250GBだと6時間20分、500GBだと13時間、1TBだとなんと28時間でした。

　検証時のシステム構成も数値も全て公開されている資料で確認できますから、今後、同様の検証を行う場合の目安として大いに参考になるでしょう。

　2013年度の活動はPostgreSQL 9.3の新機能や性能検証がテーマになりそうです。最新のPostgreSQLノウハウに接することができそうですね。