FileBench: FS パフォーマンス測定のための新時代ツール (Eric Kustarz's Weblog)より。

FileBenchというファイルシステムのためのベンチマークツールがOpenSolarisに入るそうです。岡崎はSun Java CAPSやGlassFishなど導入をしていただくために提案をしたり、技術的な質問に回答するのが主な仕事としています。これらの活動の中にはたびたびベンチマークやサイジング作業を必要とする提案や質問が含まれます。

あるJava EEアプリケーションのサイジングを考えた場合、最も簡単に手に入るサイジングの基礎情報はCPU性能とワークロードの関係を示したものです。たとえばSPECjAppServer 2004のようなスタンダードベンチマークは、ある特定のベンチマーク結果に対してサーバのノード数、CPU数(コア数, チップ数)が主に比較されるようなテーブルにまとめられています。ここで注目しておくところは、SPECjAppServer 2004ベンチマークではJ2EEアプリケーションサーバとデータベースサーバを含めたシステム全体としてのワークロードをベンチマークしますが、評価の主体がJ2EEアプリケーションサーバノード側にあることです。

J2EEアプリケーションサーバ側はJ2EEサーバノード数、インスタンス数、CPUの情報などがリストされていますが、DBサーバ側はノード数のみです。別に意図的に隠している訳ではなくて、単に見栄え上の問題だと思いますが、弊社を含め各社がSPECjAppServerのようなベンチマーク結果について言及する場合、やはりJ2EEサーバ側を取り上げて比較する傾向にあります。さて、少し前置きが長くなりましたが、ポイントはJava EEアプリケーションのワークロードについてCPU性能による影響が支配的だろう、というイメージを意図的ではないにせよ植え付けられていることです。

SPECjAppServer 2004のアプリケーションは現実のアプリケーションをモデルに作成されたアプリケーションとなっていますが、現実に使われるアプリケーションの要件とは少し違う点もいくつかあります。たとえば、近年セキュリティや内部統制の観点から様々な情報を監査証跡のためにログとして保存しておかなければならないという要件があげられます。このログはデータベースに保存される場合もありますが、ファイルシステム上のファイルとして保存される場合もあります。どこに保存されるにせよ、今まではあまり意識しなかった大量のシーケンシャル書き込みが発生するわけです。

このような状況もあって、最近はあらかじめ想定されたシステム構成で、CPUの性能に対してファイルシステムの性能(ディスクやキャッシュ、OSのファイルシステム全体で)が不足していると感じることが増えています。最近のCPUはマルチコア化、マルチスレッド化によって倍々ゲームで飛躍的に性能を伸ばしていますが、そのような倍々ゲームのような進歩はすくなくともローエンドなストレージではあまり実現されていません。たとえば10年前にSun Enterprise 10000のような64CPU搭載可能な大型サーバのワークロードは、CPUの性能だけで比較した場合、Sun SPARC Enterprise T2000やSun SPARC Enterprise T5120のような小型サーバによって置き換えることができます。

Sun Enterprise 10000のような大型サーバが導入されていた頃は、それに見合う十分強力なストレージが導入されることがほとんどでしたが、Sun SPARC Enterprise T2000やT5120のような小型のサーバを導入される場合には、初期の要件でストレージに対する要件が明らかでない限り、小型のサーバに見合う大きさのストレージか、場合によっては内蔵ハードディスクのみでシステムが構成されます。当然、ストレージの性能も10年前と比べれば飛躍的に向上していますのですべてのケースで性能が不足している訳ではありませんが、それは事前によくサイジングをした結果というよりは運良く不足がみられないと言っても言い過ぎではないと思います。

ですので、冒頭にとりあげたFileBenchのように自由にワークロードをデザインできるベンチマークツールは非常に強力なツールになります。またもちろん、ツールだけではなくアプリケーションがどのように振る舞うか、あるいは、その場合のファイルシステム利用の傾向を収集し、それぞれに対するベンチマーク結果を集積していくことが正確なサイジング作業には不可欠と言えるでしょう。