図1●PGClustgerによる3ノードのクラスタとPostgreSQL単体の性能比較(<a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-cls.pdf" target="_blank">「DB層~DBMSクラスタ評価編~」</a>図 5.2-1)
図1●PGClustgerによる3ノードのクラスタとPostgreSQL単体の性能比較(<a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-cls.pdf" target="_blank">「DB層~DBMSクラスタ評価編~」</a>図 5.2-1)
[画像のクリックで拡大表示]
図2●MySQL ClusterとMySQL単体の性能比較。青と赤がMySQL単体,MySQL Cluster SQLノード1ノードが黄色,2ノードが水色,3ノードが紫,4ノードがピンク(&lt;a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-cls.pdf" target="_blank"&gt;「DB層~DBMSクラスタ評価編~」&lt;/a&gt;図 8.3-19)
図2●MySQL ClusterとMySQL単体の性能比較。青と赤がMySQL単体,MySQL Cluster SQLノード1ノードが黄色,2ノードが水色,3ノードが紫,4ノードがピンク(<a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-cls.pdf" target="_blank">「DB層~DBMSクラスタ評価編~」</a>図 8.3-19)
[画像のクリックで拡大表示]
図3●PostgreSQL 8.1と8.0の性能比較(&lt;a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-dbt.pdf" target="_blank"&gt;「DB層~OSDL DBT-1/3によるDBMS評価編~」&lt;/a&gt;図 2.2-4)
図3●PostgreSQL 8.1と8.0の性能比較(<a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/db-dbt.pdf" target="_blank">「DB層~OSDL DBT-1/3によるDBMS評価編~」</a>図 2.2-4)
[画像のクリックで拡大表示]
図4●カーネル・パニックの障害解析フロー(&lt;a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-Tools.pdf" target="_blank"&gt;「OS層~障害解析の手順・ツール評価編~」&lt;/a&gt;図 2.2-5)
図4●カーネル・パニックの障害解析フロー(<a href="http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-Tools.pdf" target="_blank">「OS層~障害解析の手順・ツール評価編~」</a>図 2.2-5)
[画像のクリックで拡大表示]

 独立行政法人 情報処理推進機構(IPA)は11月16日,オープンソース・ソフトウエアの性能や信頼性の評価と,障害解析手順書や支援ツールなどを公開した。障害解析手順書はカーネルやアプリ,ネットワークなどの障害解析方法について300ページ以上にわたり解説。PostgreSQLやMySQLのクラスタ,JBoss,Linuxカーネルの検証やツール整備も実施,「PostgreSQL 8.1は8.0より1.5倍速い」などの結果が得られた。

 このプロジェクトは,IPAが日本OSS推進フォーラムと協力し「OSS性能・信頼性評価/障害解析ツール開発」プロジェクトとして2004年度(関連記事)に引き続き実施したもの。日立製作所が幹事会社となり11社が共同で行った。

 PGClusterによるPostgreSQLのクラスタリングでは,負荷分散により検索は高速になるが,更新ではオーバーヘッドが発生する。DBノード3台構成の場合,検索処理だけなら3倍高速だが,更新では10分の1以下になる。検索が9,更新が1の比率の時に,PostgreSQL単体の性能とほぼ等しくなる(図1)。

 MySQL Clsuterは複数ノードで処理を行う。SQLノードが2台の場合,クラスタリングを行わない場合より性能は低くなる。3台にするとMySQL単体より性能が高くなった(図2)。

 ただしPGCluster,MySQL Clsuterとも「基本的には性能よりも可用性を向上させるためのソリューション」(日立製作所 OSSテクノロジセンタ,日本OSS推進フォーラム開発基盤ワーキング・グループ主査 鈴木友峰氏)。MySQL Clsuterではサーバーに障害が発生しても5秒程度しか処理が停止せず,復旧途中も長期間の性能劣化はなかったという。

 また「この半年でPostgreSQLとMySQLの性能はかなり向上した」(鈴木氏)。PostgreSQLは,マルチプロセッサ環境(Xeon 3.06GHz 2CPU,HyperThreading On)で,バージョン8.1ベータは8.0に比べ約1.5倍の性能を示した(図3)。

 JBossについては2004年度の調査で高負荷時にスループットが伸びなくなるなどの課題が指摘されており,精緻な検証結果を得るための解析ツールの開発が行われた。新版の4.0.2でも「クラスタリングで高負荷時にJBossのセッション同期機構を使用すると性能が得られないなどの問題があるため,Tomcatの機能を使用するべき」(鈴木氏)。

 ただし「JBossは高負荷でない用途には十分適用できる」(鈴木氏)とする。JBossコミュニティもこのプロジェクトで得られた結果に高い関心を示しており,11月末には共同でのベンチマークやチューニングを行う。また日本からJBossコミュニティに問題点の報告とパッチを提供しており,次バージョンで対策が行われる見込みだ。

 Linuxカーネルに関しては障害解析の手順を詳細に解説した手順書「OS層~障害解析の手順・ツール評価編~」を公開した。カーネル,アプリケーション,ネットワークなどの障害が発生した際に,どのようなデータを取得し,ツールをどのように使用し解析するかを300ページ以上にわたり解説している(図4)。

 Linuxカーネルのスケーラビリティを評価する過程では,カーネルの性能を向上させるパッチがミラクル・リナックスの吉岡弘隆氏により作成され,Linuxカーネルに正式に採用された。報告書「OS層~CPUスケーラビリティ評価編~」には,パッチが採用されるまでの,Linuxカーネル・メーリングリストにおける約1カ月間の議論の過程が掲載されている。「ミスを削減しカーネルのコミュニティからの指摘に一つ一つ答えていくことによってコードがどんどんシンプルになり一般性を持っていくプロセスを体感した。ソフトウエアバザールモデルの強さを実感した瞬間であった。ネットワークの向こう側にいるLinux Kernel Hackersによる peer reviewが機能しているということを感じた。メールに対するすばやい反応,特に一日に何通もやり取りするというのは片手間ではできない。コードをすばやく修正して頻繁にリリース。それを繰り返すことがバザールモデルの本質だということを実感した」(「OS層~CPUスケーラビリティ評価編~ 付録 5.1 LKMLでの議論について」より)

【訂正】
図3において掲載当初,図 2.2-4ではなく図2.2-1の画像を掲載しておりました。お詫びして訂正いたします(2005年11月17日)