イベント登録数2,789

【PGECons 主催】第4回PGEConsセミナー ~2012年度活動成果発表会~

PostgreSQLはエンタープライズで使えるのか?~第4回PGEConsセミナーレポート
TIS株式会社 溝口則行 2013/7/18  2013年4月22日、PostgreSQLエンタープライズコンソーシアム(PGECons)が、第4回目のセミナーとして活動成果発表会を行った。会場は、日本ヒューレット・パッカード本社(東京・江東区大島)で、司会進行はアシストの加藤義和氏が務めた。 講演中の様子  成果発表に先立って、PGECons技術部会長である富士通の吉田正敏氏が登壇。PGEConsの活動を振り返った。およその要旨をまとめると次のようになる。  PGEConsでは、PostgreSQLをミッションクリティカル性の高いエンタープライズ領域に適応するために、現状の問題を整理し、コンソーシアムとして解決可能な実効性の高い課題を議論してきた。第1期は、その課題の中から会員企業の関心が高かった「性能」と「互換性」についてワーキンググループを設置して活動してきた。  PostgreSQLは過去、「64コアまでしか性能が伸びない」といわれる時期もあった。そこで、性能ワーキンググループ(WG1)では80コアまでの性能検証を実施し成果を上げることができた。設計運用ワーキンググループ(WG2)では、他のデータベースからPostgreSQLへの移行を行うための調査研究内容が成果物としてまとまった。  そして、10社の発起人企業でスタートしたPGEConsが、約1年を経て、現在は会員企業39社にまで拡大。吉田氏は、さらに会員企業を増やして、大きな勢力にしていきたいという意向を表明した。  吉田氏のスピーチに続いて、成果報告会では、性能、互換性のワーキンググループ(以下、WG)の活動成果をそれぞれ発表したので、本稿ではその内容の記録をあらためて紹介したい。 性能WG:大規模DBを見据えたPostgreSQLの性能検証  WG1:性能ワーキンググループ「大規模DBを見据えたPostgreSQLの性能検証」と題した発表では、日立製作所の福岡博氏が登壇、成果を報告した。性能ワーキンググループでは、PostgreSQLのエンタープライズ利用を見据えたスケールアップとスケールアウトの性能検証を実施している。 スケールアップの検証  スケールアップの検証では次の点を検証項目としている。 メニーコアCPUを使って高い性能値を出すことができるかを確認すること 現時点の最新バージョンである PostgreSQL 9.2 での最高到達点を知ること  スケールアップ検証では、サーバのCPUコア数を80コアまで増やしたときに、参照系中心の場合、更新処理がある場合それぞれにおいて、どの程度性能向上が見られるかを測定した。  参照系の処理では、PostgreSQL 9.2が80コアという高い処理能力を活用できていると推測するに足る検証結果が得られていた。  また更新系処理では、DBに接続するセッション数を増やしていった場合、処理量はセッション数に正比例するところまでは伸びないものの、全体で処理している更新トランザクション数はセッション数に応じて増えていることが確認できた。  しかし、課題も見つかっており、80コアCPUを十分に活用しきれていない状況が確認された。80コアCPUとその半分の40コアCPUを比較すると、性能はほとんど変わらない。実は40コアCPUの段階で、CPU稼働率にはすでに空きがあり、それに対してストレージのI/Oではほぼ100%の負荷状態になっていた。CPUよりもI/Oが先にボトルネックになっている様子が見て取れる。  その他、スケールアップ検証での検証項目として、DBに格納するデータ量の増加に伴う性能特性や大容量データのロードに要する時間の測定、checkpointや自動VACUUMに関するパラメータ値の影響なども検証された。  検証項目によっては特別なチューニングを施していない測定結果もあるようだが、PostgreSQLの性能特性を知ることができる有益な情報源である。 スケールアウトの検証  続いてスケールアウトでの検証結果が報告された。スケールアウト検証では下記の3方式での性能特性を測定したとのこと。 PostgreSQL 9.2 カスケードレプリケーション pgpool-II(レプリケーションモード)とPosgtreSQL 9.2の組み合わせ Postgre-XC  1つ目のPostgreSQL 9.2におけるカスケードレプリケーションについて。レプリケーションノード数を1台から4台まで増やした測定結果では、マスタノードでの更新トランザクション量が減少することはなかった。さまざまな条件によって変わる可能性はあるものの、基本特性としてカスケードレプリケーションによるマスタノードへの影響は小さいといえる。  2つ目は、pgpool-II(レプリケーションモード)とPosgtreSQL 9.2の組み合わせについて。pgpool-IIはアーキテクチャの特徴から、更新処理は1ノード単独で実行するよりもオーバーヘッドが大きいので、ノード数を増やすと性能が悪化する可能性があるが、負荷分散できる参照系処理ではノード数に応じた性能向上が見込める。  検証の結果では、更新系はやはり性能劣化が見られたが、4ノードまで増やしても、全体性能が極端に悪化するほどではなかった。また、参照系処理ではノード数にきれいに比例する理想的な性能スケーラビリティが見られた。測定結果グラフの直線があまりに真っすぐなので、発表者が「本当に実測値ですよ」と念を押したほどであった。 参照系の結果  3つ目が、ノード数を増加することで更新処理の性能を向上させる方式である、Postgre-XCによるスケールアウトについて。ノード数を1台から4台まで増やして行った検証では、期待したように更新系処理のトランザクション量が増加している結果が確認できていた。ただし、pgpool-IIとは反対に、参照系処理が不利な状況が見て取れる。 Postgre-XCとは  今回発表にあったPostgreSQLの性能検証の成果は、最適なDBサーバ構成を考える際の検討材料となるだろう。特に複数台のサーバを並べてスケールアウトさせる場合には、処理内容によって適切な方式を選択する必要があることがよく分かる。 設計運用WG:適用するための検討ポイントについて  WG2:設計運用ワーキンググループは「PostgreSQLを適用するための検討ポイントについて」と題して、TISの中西剛紀氏が発表した。  DBサーバを設計・構築し、適切に運用していくためには、WG1のテーマである性能以外にも、保守性や運用性、セキュリティなどさまざまな要求事項が挙げられる。この期では、参加メンバの関心が最も高かった、異種DBMSからPostgreSQLへの移行がテーマとして取り上げられた。  DBMSの移行だけにテーマを絞っても、移行に際して必要な検討事項は多岐にわたる。今回は、ワーキンググループ参加各社(12社)が作業を分担しながら、PostgreSQLへの移行に必要なノウハウを集大成している。1社だけでは手が回らないであろう範囲をカバーしており、有力企業が集まった活動にふさわしい成果になっている。  成果物に折り込まれている事項は次の通りだ。 DB移行フレームワーク 移行作業の内容と手順 システム構成 異種DB間連携 スキーマ移行 SQL移行 ストアドプロシージャ移行 組み込み関数移行 アプリケーション移行 移行作業のトライアル結果 DB移行フレームワーク  例えば、「DB移行フレームワーク」は、DBサーバをPostgreSQLに移行するにはどんな作業が必要になるのかの作業項目をリストアップしたもの。やみくもに移行に取り掛かるのではなく、このフレームワークに沿って移行検討と実施を進めることで、無用なトラブルを避けることができるという。 異種DB間連携  また、異種DB間連携調査では、全てをPostgreSQLに乗り換えてしまうのではなく、異なるDBMSも併存している中でどのように連携を実現するかという、現実的な解決策に役立つであろう調査がされている。 スキーマ移行、SQL移行、ストアドプロシージャ移行、組み込み関数移行  システムを移行する際、移行元の採用製品と移行先(今回はPostgreSQL)の両方を熟知しているとは限らない。スキーマ移行、SQL移行、ストアドプロシージャ移行、組み込み関数移行のパートでは、他のDBMSとのデータ型やSQLなどの違いを整理している。 代表的な書き換え例 アプリケーション移行  今回の報告の中で特徴的な点の1つが、移行作業を実際に試行してみた結果が示されている点だろう。アプリケーションとデータを他のDBMSからPostgreSQLに実際に移行させた結果が報告されているのだ。  中でも特に興味深いのは、アプリケーションの変更(SQLの書き換えなど)は、移行ツールを使うことでかなり省力化できたものの、テストとエラー修正は省力化が難しく、試行した際の作業工数の9割以上がテストとエラー修正で占められた点である。  前述の通り、SQLの文法的な書き換えはツールの自動検出が効果を発揮するものの、DBMSの違いによる、トランザクションライフサイクルの違いがあり、この影響は書き換わったアプリケーションを動かしながらエラーを取り除いていくことになったとのこと。移行を計画する際には、新規の開発とは異なる部分に工数が掛かることを理解しておくべきだろう。  必要となる作業もその作業量も、移行するアプリケーションやデータ、環境などの諸条件によって大きく異なるのは当然である。そのため、今回の移行トライアルと同じ結果が得られるわけではない点に注意が必要だ。それでも、机上の検討では見落としがちな点に気づかせてくれる報告である。 データ移行調査および実践編 泥臭くはあるが、実用性が高い  今回の性能運用WGの活動ではDBMS移行という、泥臭くはあるが、実用性の高いテーマが取り上げられた。PostgreSQLのエンタープライズシステムでの利用を促進するためには、今回の報告で示されたようなベストプラクティスを積み上げていくことが必要であろう。 運営委員会「12年度活動状況と13年度活動計画」  PGECons運営委員会、日本電気の川畠輝聖氏より2012年度活動の全体的な要約と、2013年度の計画概要について説明があった。  2012年度の活動は、上述のワーキンググループ成果の発表の通りであるが、これらの成果物は、すでにPGEConsのWebサイトで公開されている。設計運用WGで行われた移行トライアルで取り上げた移行対象アプリケーションのソースコードなども全て公開されている点が、OSS関連コンソーシアムらしい。  イベント関連では、今回の成果発表を6月には大阪でも実施することと、5月にカナダで開催される「PGCon」に、同コンソーシアムとして参加し発表を行うことが決まっている。海外も含めたPostgreSQLのコミュニティの中で、当コンソーシアムが「チーム・ジャパン」として日本を代表する位置付けになりつつあるようだ。  2013年度活動のポイントは、技術部会のワーキンググループ構成を3つにする点にある。  性能WGは継続し活動することになる。2013年度はPostgreSQL 9.3がリリースされる予定であり、この9.3が検証で取り上げられるという。移行WGは、移行というテーマが重要であることから、旧「設計運用WG」から名称を変更し、さらにノウハウを充実させていく。設計運用WGは、可用性確保や性能監視などのテーマを新たに取り上げて活動を始める予定だ。  講演の最後に、「現在、正会員と一般会員を合わせて39社で活動しているが、さらに会員企業を増やし、WG活動にも参加してほしい」と呼び掛けがあった。 休憩中の様子 関連リンク 成果報告書ダウンロードページ 「イベントカレンダー+ログ」レポート投稿募集中! このレポート記事が掲載されている本サービス「イベントカレンダー+ログ」では、イベント登録者がレポートを投稿したり、資料を一覧できるまとめページを作成できます。新着レポートは一覧に表示され、こちらのRSSにも配信されるので、ぜひご活用ください。