前回まで,SAP SDベンチマークが,今のところは現実のアプリケーション環境に最も近い性能ベンチマーク・テストであると述べてきた。そして,SAP SDベンチマークの弱点として,基本的に1つのタイプのトランザクション処理が稼働している環境の性能測定しかできないという点を挙げた。

◆混合ワークロード処理という課題

 ところが現実のハイエンド・サーバー環境では,オンラインやバッチなどのさまざまなタイプのアプリケーションが同時並行的に稼働しているのが通常である(科学技術計算に使用されている場合は別かもしれないが)。

 このような「混合ワークロード」の効率的処理は,ハード的にもソフト的にも厳しい要件である。ハード的に言えば,アプリケーションが切り替わったときに,キャッシュの内容が一気に無効化されることが多いため,このような場合でもキャッシュのヒット率を下げないようにしたり,キャッシュ・ミス時のメモリ・アクセスのレイテンシ(遅延)を下げないようにする設計が必要である。このあたりは,CPUの数やクロック周波数などのスペックからは分からない,ベンダーの真の実力の見せ所である。

 また,OS的にも,特定のアプリケーションがCPUやメモリーのリソースを使い尽くして,他のアプリケーションの性能を著しく悪化させることのないような設計が必要である。アプリケーションごとに使用リソースの上限を設定するという単純な方法もあるが,理想的には,各アプリケーションの資源使用量とサービス・レベルを定期的に監視し,その結果に従って資源使用の優先順位を動的に調整するワークロード管理の機能があるべきである。

 このような観点から言えば,テクノロジ的に最も優れているサーバー製品は,IBM系メインフレームである。メインフレームは,ハードとしてもソフトとしても,混合ワークロード環境の効率的実行を目標に長年にわたり機能強化されてきた。CPUパワーだけを取ってみるとたいしたことがなくとも,現実世界で大規模な業務アプリケーションが稼働しているのはほとんどがメインフレームであるという事実はこれを裏付けている。

◆混合ワークロードの性能をどう評価すべきか?

 さて,ここで問題は,このような混合ワークロード環境における性能をどうすれば正当に評価できるかということである。

 かなり昔のことになるが,1997年に米Sun MicrosystemsがDB2の稼働するEnterprise 6000サーバー上でのTPC-CとTPC-Dの同時並行稼働の結果を公表したことがある。TPC-CはOLTP系の,そして,TPC-Dは意思決定支援アプリケーション系の標準ベンチマークであり,それらを同時並行稼働しても性能が大きく悪化しないことから,Sun社のサーバー環境の混合ワークロード処理能力をデモしたものである。おもしろい試みとは思うが,TPC-CもTPC-Dも比較的シンプルなアプリケーションであるため,現実の混合ワークロード環境の再現性という点では十分とはいえないだろう。

 IBMメインフレームの世界では,LSPR(Large System Performance Reference)と呼ばれる混合ワークロードのベンチマークが長年の間使用されてきた。LSPRは,典型的メインフレーム・ユーザーの混合ワークロード環境を再現しており,OLTP,バッチ,開発などのワークロードを一定の比率で同時並行稼働することが求められている。LSPRによる性能評価の正確性はかなり高く,それゆえ,IBMメインフレームの世界では容量計画のミスが比較的少ない(もちろん,皆無とは言えないが)。

 残念ながらLSPRはIBM社内のみで使用されるベンチマークであり,その内容はオープンではない。また,DB2やCICSなどのIBM製ミドルウエアが使用されていることから,そのままではベンダー独立な標準ベンチマークとすることは難しい。あくまでも,IBMメインフレーム間の相対的な性能比較という目的に限定されている。

 これもかなり昔の話になるが,TPC(Transaction Processing Performance Council)において,エンタープライズの混合ワークロード環境を再現するためのベンチマークであるTPC-E(“enterprise”)を検討していたことがあった。TPC-EのアイデアはLSPRに大きく依存していたようである。TPC-Eは仕様が固まり,1996年に正式リリース直前までいったのだが,TPCのメンバー企業(ほとんどの主流システム・ベンダー)の投票で充分な得票数を獲得できず,立ち消えになってしまった。特定のベンダーに有利なベンチマーク・テストであり公平ではないというのが大きな理由だったようだ。要するに,メインフレーム・ベンダーに有利ということであろう。

 しかし,最近においては,サーバー統合などによってWindowsやUnix環境でもメインフレーム的な混合ワークロード処理の要請が増えている。そして,各ベンダーもOSのワークロード管理機能を強化している。そうしてみると,混合ワークロード向けのベンチマークの必要性は再度高まっていると言ってよいのではないだろうか? TPC-E的なアイデアが再度持ち上がっても不思議はないだろう。

 では,実際問題として,ユーザーはどうすればよいかというと,今の段階で混合ワークロード処理における正確な性能測定を行おうとするならば,実際にアプリケーションを稼働させて評価するしかないということになる。手間がかかる作業だが,数億円以上のハイエンド・サーバーの商談であれば,当然,行っておくべき作業の1つであろう。

◆デッドヒートはまだまだ続く

 ところで,HP superdomeとIBM p690のTPC-Cベンチマーク・レースだが,前回の時点ではHPがトップの座を奪回後,IBMが抜き返し,またHPが抜き返すという状況だった。その後,6月30日にまたまたIBMがトップの座を奪回した。まさにデッドヒートである。

 しかし,ユーザーとしては,TPC-Cという制限がゆるいベンチマークのわずかな差を気にする必要性は小さいだろう。より重要な点は,このようなベンダー間の競争が最終的に価格性能比の向上をもたらすということだ。ベンダーにとっては厳しい状況だが,ユーザーにとっては望ましいと言えるだろう。

 ベンチマークについての連載は今回で終了である。次回からは「Itaniumはなぜ速いのか?」を巡って考察したいと思う。