最近,オン・デマンドという言葉が気になっている。オン・デマンドといえば,「ビデオ・オン・デマンド」など,かつてよく使われた言葉だが,最近,また耳にする機会が増えているからだ。

 といってもビデオ・オン・デマンドではない。キャパシティ・オン・デマンド,ストレージ・オン・デマンドといった,システム構築・運用に近いレベルの話だ。中でも特に気になっているのは,サーバーの処理能力をオン・デマンドで借りられる「プロセッシング・キャパシティ・オン・デマンド」。

 要は,必要に応じて必要な分のリソース(処理能力あるいはCPU)を使えるようなサーバー運用環境である。面白いアイデアだと思っているのだが,実際にはユーザーに受け入れられづらいだろうという声もあり,ユーザーでもない自分が一人で期待と不安を募らせている。

 現状では,サーバーの「キャパシティ・オン・デマンド」と言えば,日本IBMやサン・マイクロシステムズ,日本ヒューレット・パッカード,コンパックコンピュータといったコンピュータ・メーカーが最近採用し始めた,一種のサーバー販売形態である。

 ユーザーにサーバーを納品する際に,あらかじめ予備分のCPUを搭載しておく。ユーザーのシステム負荷が高まり,より多くの処理能力が必要になった時点で予備のCPUを稼働させる。この時点ではじめて予備CPU分の料金をユーザーに課金するため,ユーザーはオン・デマンドで多くの処理能力を手に入れたように見える。

 言葉の解釈で言えば,処理能力をオン・デマンドで提供することに思えるが,実際にはそうではない。いったん予備CPUに火を入れてしまうと,それ以降,ユーザーは予備CPUも継続して運用しなければならず,スケール・ダウンはできない。つまり,ユーザーにとっては形を変えた追加購入ということになる。しかも,サーバーのキャパシティを増やすのに,数時間から数日を要する。「なあんだ。こういうのもオン・デマンドって言っちゃうんだあ」--。こう考えるのは私だけではないだろう。

 もちろん,私が期待をかけているのは,そんな程度のオン・デマンドではない。本当に必要なときにすぐさま処理能力を増やせるような,本当の意味でのオン・デマンドである。ユーザーの中には,ある一定期間だけ多くのサーバー・リソースが欲しくなるという場合がある。

 例えば災害や事故など,何かのイベントがあった場合,ポータル・サイトやニュース・サイト,あるいは交通機関のWebサイトなどには,状況を知りたいユーザーからのアクセスが殺到する。これは,災害時に電話がつながりにくくなくことを考えれば容易に想像がつく。Eコマース・サイトなどでも,「XX商戦」という時期にはアクセス数が通常の数倍になることもあるだろう。著名なアーティストのコンサート・チケット販売などでは,数倍どころではないかもしれない。

 この短期的なトラフィック急増に対応するためだけに多額のコストをかけてシステムを用意できるはずもなく,結局,システムはあっぷあっぷ。ユーザーは知りたい情報を手に入れられずに終わる。本当の意味でのキャパシティ・オン・デマンドが実現されれば,ユーザーはトラフィックの増加に合わせて動的にサーバーの処理能力を増減させてサービス・レベルを維持できる。しかも,サーバー・リソースを使った分しかコストはかからない。

 これはまんざら絵に描いた餅というわけでもない。技術的に見ると,最近は,ポリシー・ベースで負荷分散のパターンを変えられるロード・バランサが登場し,すぐにでも実現可能な状況にある。イベント時,ハプニング時だけサーバー・リソースを増やし,落ち着いたら元に戻すということも技術的には可能になっている。

 サーバー・ベンダーやホスティング事業者が,こうしたキャパシティ・オン・デマンドを実現してくれれば,ユーザーは必要なときにだけ必要なサーバー・リソースを利用でき,無駄なコストを省ける。実際,米国ではEjasentというベンチャ企業がサービスを計画している。国内でも,システム・インテグレータやデータセンター事業者が,サービスを企画しようとしている。

 では,どうしてまだ実際のサービスが登場していないのか。実は,問題が2つある。

 1つはサーバー・ソフトのライセンス。サーバー・ソフトの多くは,サーバー・プラットフォームやサーバー数,CPU数をベースに価格が決まる。ところがキャパシティ・オン・デマンドでは,サーバー数やCPU数は一定しない。今のままの価格体系では実現できないことになる。この点に関しては,サーバー・ライセンスにASP(アプリケーション・サービス・プロバイダ)モデルが生まれたのと同様に,時間が解決してくれるだろうが,裏を返せば,キャパシティ・オン・デマンド実現にはまだ時間がかかるということである。

 もう1つの問題は,ユーザーが定額の料金を望んでいるということである。システムの運用費は,月額固定が従来の常識。あるホスティング事業者は,「キャパシティ・オン・デマンドのように,稼働したプロセス数や利用時間に応じて毎月料金が変わるとなると,予算を組めないというユーザーが多いのが実情」だという。もしかすると,サービス提供者にとっては,こうしたユーザーの考え方の方が高いハードルになってしまうのかもしれない。利用者を見込めなければ,サービス化は難しい。

 しかし,ユーザーにとって本当に定額の方がいいのだろうか。この点については,どうしても首を傾げたくなる。

 従来の企業内システムのようにトラフィック・パターンが決まっているシステムと違って,eビジネスのインフラとなるインターネット・システムは,常に拡張を要求される。同時アクセス・ユーザー数がはっきりわからずシステム設計が難しい。しかも,ユーザーに対するサービス品質を高く維持しようと考えると,絶えずシステムとサービス品質を監視し,常に最適解を探さなければならない。当然,運用・管理のスタイルは,企業内システムのそれとは違うはず。とすれば,投資のスタイルも変わってしかるべきである。

 キャパシティ・オン・デマンド--。アクセス・トラフィックの変動が激しいインターネット・システムにはうってつけのサーバー運用形態だと思うのだが・・・。

(河井 保博=日経インターネット テクノロジー)