 |
|
| オープンソースソフトウェアの性能・信頼性評価手法
|
第１回：開発基盤ワーキンググループインタビュー
2005/5/17
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
評価手順の中で3つのツールを開発されていますが、これらは当初から予定されていたのですか？
菅原氏
何を取り上げましょうかという話に始まって、各社がやりたいことを持ち寄って、その中から優先度やニーズに応じて削り落としていった、という感じですね。
|
鈴木氏
評価手法の話はあったんだけど、それだけじゃ物足りないよねって（笑）。やっぱり障害解析のノウハウについてもやろう、テーマになり得るよね、と。
|
三浦氏
障害解析のノウハウについては、ツールを開発して障害解析ができるようにするというだけでなく、ツールを触媒にしていろんな会社のエンジニアリングのノウハウが集まってきて、さらに生産性が上がるとか、解析が速くなるとか。そういう効果を狙っているところがあります。
|
 ユニアデックス（株）
高橋 秀樹氏
高橋氏
インフラを提供するみたいなところがありますよね。解析手順は誰でも作れるところなので、それがスキルとして貯まっていけば、みんながハッピーになれるんじゃないかと。そこが狙いのひとつだった。
三浦氏
ベンチマーク結果を秘密にしても意味がないのと同じように、障害解析を他の会社ができなくしたり、妨害することになんら意味はない。障害解析やトラブルシューティングする人は、お互いに助け合ってでもすばらしい仕事をして、「安心して使えるね」となるほうが何十倍といい。そういうノウハウというのはそんなに簡単に手にできないものですし。
|
鈴木氏
それでみんなで取り組んでもいいよね、ということで、最初はダンプ（ダンプデータ解析ツール「Alicia」）とトレース（カーネル性能評価ツール「LKST」）が出てきたんです。そこに、DAV（ディスク割当評価ツール）も加わった。DAVが出てきた経緯は面白いよね。
|
三浦氏
DAVについては、ニーズというか、とても困った実例というのがあったんですね。そういう事例に、遅かれ早かれ私たちも直面するに違いないと。DAVは問題を直接解くようなツールじゃないんですよ。ベンチマークの手順を作ることに通じるところがあって、あれ、要するにビューワなんだよね。
|
杉田氏
そう。いま何が起こっているかを示すだけのものです。でもツールで見えるデータというのは、読み手が次に何をすべきかを考えるヒントを与えるものなんです。そして「次はこういうツールが必要だ」「こんな風にカーネルを変えなきゃ」と、そういう発想を促すきっかけになるわけですね。
|
松田氏
DB層のDBT-3には謎の現象があって、検証を始めたときにディスクフォーマットしてからベンチマークをとって、2、3ヶ月たってからまったく同じ環境で測定したら、前よりスピードが遅くなった。原因がわからず、とりあえずファイルシステムのフラグメントを疑ってDAVでデータをとってみたんですね。結局、フラグメントが原因では無かったのですが、それがわかることだけでも有難い。原因についてはその後の調査で特定しまして、報告書のDB層の第6章を読んでみてください（笑）。
|
杉田氏
DAVはアメリカ、ヨーロッパでも公開していて、メーリングリストの参加者も増えてきています。他の国の方がパッチや、改善の提案を送ってきたりという反応もありますね。
|
三浦氏
ツールというのは、使ってくれる人が多くなるほどメリットも増えてくるものなんですよ。こういう場で、こういう事例があったという蓄積がプラスになりますし。LKSTも、弊社で問題があったとき使ってみようと。この場を通してツール経験者の数が増えましたね。
|
高橋氏
Aliciaの開発についても、NTTデータさんに使ってもらったり、ミラクル・リナックスさんにいろいろ調べてもらって、実際にかなりシェイプアップされたと思うんですよね。その辺も一緒にやってよかったなと感じています。
|
OSSの性能を評価する手順をまとめたり、実際に評価するにあたって苦労した点はありますか？
|
三浦氏
Java層でいうと、SPEC.orgが規定しているSPECjAppServer2004の試験環境作りが大変でしたね。評価するのはJavaアプリケーションサーバのJBossなんですが、SPEC.orgのレギュレーションルールだとか複雑ですから、それを動かすための準備に苦労しました。
|
 新日鉄ソリューションズ（株）
稲木 宏一郎氏
稲木氏
まじめに測定結果を公開しようとすると、もの凄く大変なんですよ。ハードウェアひとつとっても、SPEC.orgに公開する場合は、24時間対応で3時間以内のサポートを提供するようなものでなければならない。なぜかというと、誰でも手に入れられるものである必要がある、つまりGeneral Availabilityが求められるからです。ソフトウェアについても同じです。
結局どうしても公開は難しい、ということでSPEC.orgから結果の公開には至らなかったんです。報告書のベンチマークのデータは絶対値でなく相対値なんですが、これはそういった要因もあるんです。
|
鈴木氏
そういう意味じゃ、手順書というのは価値があると。とりあえず、書いてある環境では、書いてあるように動きますからね。
|
稲木氏
Javaの評価も、2台でやろうと思えばやれるんですけど、実践的ではないですね。最低でも5台くらいないとできない。でも、ハードウェアさえ用意できれば、OSのインストールから始めても数日程度で評価はできますよ。
|
菅原氏
DB層の評価に使ったDBT-1は、もともとSAP DB用に作られていて、何年か前にPostgreSQL用に変わっているんです。で、PostgreSQLの評価と、Oracle用のコーディングをNRIさんにやっていただいて、弊社ではMySQL用の検証を計画していたんですけれども、まず動かない（笑）。コンパイラが通らない。よく見るとソースが欠けている。古いバージョンを探していくと使えるコードが残っていたので、仕方がないのでそれをかき集めて作り直したんです。その点で当初より工数が多くなってしまった。
吉岡氏
この類のベンチマークのツールは、個人レベルで作るというのはちょっと想像できないものですよね。従来の牧歌的なOSSの開発スタイル、その、夜中にハッカーがコツコツ作るというフェイズから、企業がLinuxをはじめとするOSSにコミットするというフェイズに移るとき、最初に必要になるのはベンチマークなどの環境系のツール群なんですよ。
そこはまさに8社で集まってやることに意義があって、各社が個々に似たようなものを作ってもしょうがない。リソースをシェアすべきということにインセンティブが働く。で、OSDLのDBTという元があったので、それをベースにやってみたら実は結構ボロボロだった。そこで私たちが、険しい山を最初に登って、道をならしている面もあるわけです（笑）。
|
鈴木氏
ちゃんと評価した人がいなかったということですよね、第三者として。そういう意味で、今回の取り組みでOSSの世界に貢献ができたのではないかと。
そもそもベンチマークには、最大性能を測るというところに力点があったけど、我々が違うことをやり始めた。チューニング前と後でどれくらい変わるのか、商用でどこまで使えるものなのか、そういった観点でベンチマークを使ってOSSを評価した。そこがOSDL側の人にも興味を持たれているようですね。
|
菅原氏
日本語のドキュメントとして、まとめて出せたってのも結構大きいことだと思います。今まではあちこちバラバラになっていたんで、かなり使い勝手がよくなったのではないかと。
|
鈴木氏
単にソフトを入れただけでは平凡なスピードしか出ませんが、チューニングすればそこそこパフォーマンスは出ますよ、ベンチマークでそういうことがわかったわけです。商用ソフトだったら、そういったチューニングのノウハウはメーカーに聞けばいいんですけど、OSSは聞く先がどこなのかわからないですからね。
|
前のページ 1 2 3 4 次のページ
|