このページの本文へ

「やっぱり、自分の会社は自分の子供みたいなものなんです」─米Mountain View Data Cliff Miller氏

2003年03月14日 07時14分更新

文● 編集部 阿蘇直樹

  • この記事をはてなブックマークに追加
  • 本文印刷

コモディティのハードウェアでクラスタリングする

[編集部] 『PowerCockpit』の競合製品についてはどうお考えでしょうか。たとえば、伊藤忠テクノサイエンス(株)が米Egeneraの『BradeFrame』を日本で販売するといった発表が先日あったわけですが、使い方によっては同じようなソリューションも可能になるのではないでしょうか。
[Miller氏] そうですね。競合といいますか、似ている部分は確かにあります。実際Egeneraさんとはお話しさせて頂いています。彼らの場合、CPUなどは米Intelのパーツを使用していますが、かなり特殊なハードを使用しています。ですから、ものとしては確かにいいです。我々の『PowerCockpit』は、コモディティパーツ、ホワイトボックスのPCですとか、ごく普通にあるPCサーバのクラスタに向いています。また『PowerCockpit』は、ブレードサーバを利用したプロビジョニング(ハードウェアリソースを準備し、必要に応じてシステムを切り替えること)だけでなく、グラフィックのレンダリングやシミュレーションといったHPC(High Performance Computing)にも非常に向いています。また、先ほど説明したビデオオンデマンドのシステムとか、そういったインターネットアプライアンスのクラスタにも向いています。プロビジョニングは『PowerCockpit』の機能の1つですが、それだけではないんですね。
[編集部] HPC分野ではどういった活用の方法があるのでしょうか。
[Miller氏] 通常、クラスタの上に何らかのアプリケーションを乗せて動かすわけですが、まずそのアプリケーションをインストールしなければならないわけですね。そのときに1台ずつCDやフロッピーで入れると面倒ですし、失敗することもよくあります。『PowerCockpit』はアプリケーションのインストールにまず有効です。それから、アプリケーションを走らせているときに、たとえば1つのノードが落ちただけで、クラスタ全体の処理が止まったり、アプリケーション自体が止まってしまうことがあります。『PowerCockpit』だと、そういった場合にもすぐに分かるし対応することもできるわけです。『PowerCockpit』はモジュールがベースですので、アプリケーションが『PowerCockpit』のモジュールであれば、クラスタの情報をアプリケーションが知ることもできます。ですから、『PowerCockpit』は1つのフレームワークですね。『PowerCockpit』のSDK(Software Development Kit)は非常によくできていて、クラスタの情報をデータベースに入れて、いろいろなアプリケーションとコミュニケーションがとれるようになっています。

SDKは19万5000ドルで1本も売れなかった。我々は0円で19万5000人に使ってもらう

[編集部] ソフトウェア開発キットについてですが、これはパートナー戦略ともからんで重要になるかと思います。今後の戦略についてはどのようにお考えでしょうか。
[Miller氏] 『PowerCockpit』の買収によって、確かに我々の製品ラインナップ、ビジネスの可能性が広がってきたと思います。クラスタの技術、これはかなり優れた技術ですので、基本的にはクラスタコンピューティングの難しい部分を簡単にして、普及を図りながら新しいビジネスを展開しようと思っています。
具体的には、本来のHPCのマーケットももちろんですが、ほかにもISPですとか、データセンターのようなビジネス、それからもう1つは、インターネットアプライアンスのクラスタシステムですね、こういったあたりをねらっていきます。これは我々の力だけではできませんので、パートナープログラムを作って、『PowerCockpit』の特徴を生かしたプラグインモジュールを作って頂くことによって実行します。『PowerCockpit』の将来はかなり明るいのではないかと思います。Turbolinuxの時には、SDKを19万5000ドルで販売していたそうです。日本円だと2000万円くらいでしょうか。結局1本も売れなかったらしいのですが、記者発表会でも申しましたとおり、我々はこのSDKを0円で19万5000本提供したいと考えています。ほかにも、4月くらいにパートナー戦略について改めて発表する予定です。これは我々のマーケティング戦略の柱になりますね。

オープンソースからノウハウを得て製品を作る

[編集部] パートナー戦略とは異なりますが、オープンソースコミュニティとの関係についてはどのようにお考えでしょうか。
[Miller氏] Linuxコミュニティの開発者の方々との関係は非常に大事だと思っています。我々の開発チームにも、そういった開発プロジェクトのメーリングリストに参加している人がいて、『MVD Snap』や『MVD Powered NAS』ではXFSのファイルシステムを使っていますので、そのあたりのバグフィックスなどはかなり提供しています。ほかにも色々なメーリングリストに参加しているエンジニアもおります。
[編集部] コミュニティの関わりが御社のビジネスにとってはどういった形で結びつくのでしょうか。今、XFSの開発に御社のエンジニアが参加していらっしゃるとおっしゃいましたが、そういった作業に対しても当然給料が支払われているわけでしょうし、そういった投資を回収することについてはどのようにお考えでしょうか。
[Miller氏] XFSはおもにSGIがメインに開発していまして、当然SGIの方も給料をもらって開発しているだろうと思います。XFSの開発に参加されている方々の多くは企業のエンジニアのようです。ですがそれはオープンソースで、誰でもがフリーで使えるようになっています。ですから、たとえばディストリビューションにバンドルしてNASに利用することもできるわけです。そういった形でも出せなくはないのですが、製品にはならないでしょう。企業で使おうとは思わないはずです。
いろんなパーツだけを集めてパッケージにすることはできますが、肝心なデータがなくなるかもしれないとか、クラッシュしたらどうするとか、そういった問題があるわけです。ですからやはり、製品を作ることはものすごく大変なんですよね。ほかの会社でも、数百人のチームを作っているところもあるようで、大手では、フリーなもので、たとえばLinuxをベースにしても、結局、企業が使う製品を作ろうと思ったら、かなり手を入れないといいものができないわけです。もちろんフリー、オープンですから、ほかの企業が参考にすることはできます。そういうことを考えると、競争のしかたが変わってくるんですよね。製品のレベルでは、他社との差別化と、安定性です。やはり長くやっていないと、安定しないんです。ストレステストなどのテストもしっかりやっていないと、本当の製品にはならないですよね。
オープンソースの製品はパーツの数が非常に増えますので、テストの工数はこれまでよりも多くなります。組み合わせが結構大変なんです。すべて自分でコントロールできればいいのですが、それはどこもできていないんですね。ですが、我々のエンジニアがコミュニティでの開発作業に参加することで、製品に採用するパーツに関するノウハウを得ることができるということは重要だと思います。

カテゴリートップへ