IBMは最近、今日の顧客の環境では一般的な大量トランザクション処理を計測する業界ベンチマークにおいて競合他社に37パーセントの差をつけた。IBM WebSphere Application ServerはSPECjAppServer2004ベンチマークの性能とスケーラビリティの計測結果(source)において新たな高みを確立した。
InfoQは計測結果についてAndrew Spyker氏とJohn Stecher氏に話を聞くことができた。Andrew Spyker氏はIBM ® WebSphere Application Serverパフォーマンスチームを率いるシニア・テクニカル・スタッフ・メンバー（STSM）で、WEBサービスとSOAを専門としている。John Stecher氏はWebSphere Application ServerのJEEパフォーマンスチームのリーダーである。彼は現バージョンおよび今後のバージョン両方におけるSPECjAppServerベンチマークのリードデベロッパ兼アーキテクトで、ここ5年ほどSPECｊAppServerを用いて仕事をしている。
IBM内部におけるあなたたちのグループについて少し聞かせてほしい。
WebSphere Application Serverパフォーマンスチームはミネソタ州のロチェスターとノースカロライナ州のリサーチ・トライアングル・パークを拠点としている。私たちのチームはWebSphere Application Serverのコードベースで業界トップのパフォーマンスを顧客に提供することに尽力している。私たちはSPECjAppServerのような標準ベンチマークと連携するだけでなく、自社内で開発したさまざまなベンチマークの作成にヒントを与えてくれた「現実の」顧客のシナリオにフォーカスを当て、顧客がパフォーマンスや製品の配布に何を求めているのかを理解するよう努めている。チームはセグメントに分割されている。セグメントは、パフォーマンス面においてWebSphere Application Serverが引き続き顧客の要求を満たし更ににその上を行くことを確実に実現するほか、将来的な技術を担当するセグメントや現在のプロダクトリリースサイクルを担当するセグメントがある。パフォーマンスチームは、WebSphere Application Server上で動作する顧客のアプリケーションでどうやって最高のパフォーマンスを実現すればよいかを顧客自身に知ってもらうため、パフォーマンスチューニングガイドとベストプラクティスを作成している。また、最近AndrewはWebSphereコミュニティブログ(source)を通じて顧客と共に自らパフォーマンスの問題に取り組んでいる。
ベンチマーク実行の開始から終了までには組織的な観点から見てどのくらい時間がかかったか(自分が目指した順位に最初に到達するまで)？何もチューニングしない状態での計測結果に対してどのくらいの改善が達成できたか？
今回のような小規模なハードウェア設定で実行するのに、新しいハードウェアの荷解きからSPECに最終結果を提出するまでベンチマークは2～3週間かかった。もっと多くのハードウェアと複雑なネットワークやデータベース設定を用いた大規模な計測結果を得るには1ヶ月から3ヶ月かかるはずだ。何もチューニングしない状態での計測結果は一般にかなり高い。なぜなら、現在市場に流通しているほとんど全てのソフトウェアプロダクトは、古いハードウェア上でも最新ハードウェア上と同じように動作するよう初期状態で構築されているし、それにデフォルト値が広い範囲で適切であれば、特定のハードウェア設定の上でなくても、何のチューニングもなしですばらしい性能を得ることができるからだ。しかし、物理メモリの総力を使って作業するために主にJVMのヒープサイズなどいくつかパラメータを調整をすれば、よりよい結果を得ることが可能である。通常、一旦ヒープサイズを正しく設定すれば、他のパラメータを調整することによって、この特定のベンチマークにおいて20～25パーセントの性能アップが期待できる。
もっとも最適化が可能な場所は？
チューニングに関して言えば、私たちがベンチマークにおいてもっとも最適化した場所はIBM ® JVM (JVM)とスレッドプールだ。おそらくJVMが一番重要だ。ヒープサイズとガベージコレクションのポリシーについてJVMを正しくチューニングすることで、パフォーマンスの劇的な改善を実現することができる。それから、WebSphere Application Server内部のスレッドプールをチューニングすることがこのベンチマークでは重要だが、これは顧客のアプリケーションにおいて最高のパフォーマンスを得るという目的ではほとんどのケースで重要ではない。ベンチマークでシステムからトランザクションをひとつ残らず搾ろうとすると、実際には特定のハードウェア自体をチューニングすることになってしまう。
SPECjAppServerベンチマークはJEEコンテナの全体に渡って積極的な最適化をリードしてくれた。SPECjAppServerのベンチマークに参加した数年間で、WEBコンテナ・JSPエンジン・RMI・ORB・EJBコンテナ・永続化・トランザクションマネージャ・ワークロード管理・ネットワーキングコードにおいて重要な最適化が実現した。また、私たちが後ほど言及するように、最適化はJDKとWebSphere Application Serverの内でも行われ、サーバクラスのハードウェア上でのピーク性能を達成する一助となった。
チューニングにはどういったツールを使ったか？それらは手軽に利用可能か？
このベンチマークをチューニングするのに私たちが利用したもっとも重要なツールは手軽に利用することが可能だ。そのツールは WebSphere Application Serverと同梱のJVMに付属している。ヒープサイズとJVMパラメータを正しく知るために、私たちは単純にVerbose Garbage Collectionを使ってガベージコレクションの停止時間やインターバルを調べ、停止時間を最小化してガベージコレクションの実行間隔を最大化するためにヒープの調整を試みる。それから、WebSphere Application Server自体の内部についてはPerformance Monitoring Infrastructure（PMI）とTivoli ® Performance Viewer（TPV）を使ってスレッドプールの効率とコネクションプールの利用量を他のWebSphere実行動態と同じようにモニタリングする。
これらのパフォーマンス向上のために犠牲にしなければならなかったもっとも大きな機能は？
まず、標準ベンチマークに参加するにあたってWebSphere Application Serverのコードベースで犠牲にしたものは何もないと強調しておきたい。SPECjAppServerを設定する際にすべてのベンダーが犠牲にするもっとも大きなものは、現実的な高可用性ハードウェアトポロジー構成だ。これらのベンチマークにおいて最小のハードウェアで最高のパフォーマンスを達成するために、計測結果を提出しているすべてのベンダーは各ハードウェアで CPU利用量を100%に近い状態にして実行している。これは通常ベンチマークが障害発生というシナリオを含まないからだ。現実の世界では、高可用性を実現したいなら障害に対処するためハードウェアを余分に準備することになるだろう。もし未来のベンチマークが負荷のもとでの障害への対処や決まったサービスレベルを要求するなら面白くなりそうだ。しかし現時点ではこれは標準ベンチマークと顧客が必要とする典型的なトポロジーとのギャップである。
私たちが定期的な性能テストをしているときは、これらのコードパスが確実に顧客の運用環境でも最適化されるように、「顧客の現実的な」高可用性を再現するようなシナリオを設定している。
SPECの計測結果が現実のアプリケーションにちゃんと反映されないと一部の人々は感じているが、それについてどう思うか？
SPECの計測結果は現実に反映される。ベンチマークにおける競争は今日のすべてのベンダーのアプリケーションサーバを信じられないほど高速化したし、私たちの計測結果だけが単一の4コアのハードウェアシステム上で毎秒1200件近い複雑なビジネスレベルのトランザクションを処理している。SPEC ベンチマークの競争によって、ベンダーは顧客が毎日利用するWebSphere Application Serverやソフトウェアスタックのさまざまな部分にわたって共通のコードパスを最適化した。これらのベンチマークはウェブページ上で示されているパフォーマンス計測結果よりも目に見えないところではるかに顧客に対する価値を生み出している。これらのベンチマークが現実に反映されないのは、SPECjAppServer2004の順位を獲得するだけでは、それと同じチューニングのアプリケーションから同じ性能を得るのを期待することはできないからだ。大抵の場合、アプリケーションはさまざまなプログラミング手法やデータベースアクセスパターンなどを利用するが、それらは最高のパフォーマンスを引き出すために特有のチューニングを必要とする。WebSphere Application ServerはサポートしていてもSPECベンチマークではテストされない機能的領域も他にたくさんある。これこそが、私たちがすべてのコードパスを改善するためにSPECのだけでなく多くの異なるベンチマークを内部で開発して用いる理由であり、SPECjAppServerの次期バージョンと新たな標準ベンチマークに懸命に取り組む理由でもある。それらのベンチマークは、すべての顧客にフォーカスを当てたシナリオにおけるパフォーマンスの向上をはかるという私たちのコミットメントを守り続けてくれる。
総体的に見ると、SPECｊAppServerの順位は参考として扱う必要がある。これらの順位は、ベンダーから中立な討論の場とオープンな視野の中で、アプリケーションサーバ性能の総体的な潜在能力を示してくれる。公的にはSPECとその他の標準ベンチマーク団体はもっとも信頼できるパフォーマンス情報のソースであるが、自分自身でそれと同等の性能を得るには、自分のアプリケーションの振る舞いとパターンに合わせてランタイムをチューニングすることに力を注がなくてはならない。これは私たちがいつも推奨しているベストプラクティスだ。自分のアプリケーションは迅速にそして頻繁にパフォーマンステストを行い、しかるべきチューニングをすべきである。
今回のベンチマークがIBM以外の類似ハードウェアやソフトウェアを抑えることになると思うか？
ベンチマークによってIBM以外の類似ハードウェアやソフトウェアスタックの採用が妨げられるのはわずかだと考えている。私たちは、サポートしているハードウェアとOSスタックの上でソフトウェアがうまく実行できることを保証するため、それらハードウェアメーカーやOSベンダーのパフォーマンスエンジニアとともに懸命の努力を行っているし、また、サポートしているデータベースのアクセスメカニズムがうまく動作するのを保証するためにデータベースベンダーとも同様の努力を行っている。
ベンチマークにもっとも影響を及ぼすのはどこ（JVM、CPU、データベースなど）か？
それは非常に難しい質問だ。ベンチマーク計測結果はすべてハードウェア（CPU、メモリ、ネットワークなど）とソフトウェアスタック（JVM、データベース、アプリケーションサーバ、ベンチマークコードなど）の両方のパフォーマンスに影響される。ちょうど実世界でのパフォーマンス計測結果のように。最近のベンチマーク計測結果のほとんどでは最新ハードウェアの存在が目立つ。ハードウェア性能の増大はWebSphere Application Serverのソフトウェアスタックの高速化に直接つながる。しかし、このより新しいハードウェアを利用するため、私たちはそのハードウェア用にソフトウェアスタック（JVMとWebSphere Application Server両方）の状態を整え、ハードウェアの能力を最大限に活かすことに集中した。ハードウェアの変更とソフトウェアの活用に関する2つのよい例は、 64bitとマルチコアのCPUだ。私たちが64bitとマルチコアに焦点を定めたのは、このハードウェアが一般的な顧客のもとで普通に利用されるようになる前のことだった。
WebSphere Application Serverのコードも同様にベンチマーク性能に強い影響力をもっている。すでに議論したように、WebSphere Application Serverのコードはこのベンチマークが示す性能を達成するために積極的な最適化を経てきた。スタック全体がベンチマーク性能に貢献するという事実を踏まえると、IBM ® がハードウェアとソフトウェアスタックの全体にわたってSPECjAppServerパフォーマンスにおいて業界をリードするのを手伝ってくれたすべてのパフォーマンスチーム（システムとサーバのチーム、ＪＶＭ/JITチーム、DB2 ® チーム）に、私たちは感謝しなくてはならない。
WebSphere Application Server V6.1の評価版はこちら(サイト・英語)からダウンロードできる。
SPECは最新世代の高性能コンピュータの性能を計測する標準ベンチマークを策定、管理、承認する非営利団体で、世界中の大手コンピュータメーカーやソフトウェアベンダー、大学、研究機関によって構成されている。ベンチマーク計測結果とStandard Performance Evaluation Corporation（標準性能評価法人）の詳細についてはwww.spec.orgで確認することができる。この記事中で公開データをもとに SPECjAppServer2004のCPUコアあたりJOPS@Standardを比較している箇所は、2007年10月3日現在 www.spec.org上で公開されている計測結果に基づいている。