ユーティリティコンピューティングをアテにするのはまだ早い

　1980年代、米Digital Equipment Corp.（DEC）の社員たちは頭を悩ませていた。同社のVAXシステムは飛ぶように売れていたにもかかわらず、依然メインフレームのような大規模の処理能力を提供できていなかったのである。

　しかしDECに巨大な鉄の塊の製造を始める計画はなく、同社は既製品を活用しながら処理能力を向上させる方法を見つけようと動き始めた。そしてその研究の結果、VAXクラスタを開発し、ホリゾンタルスケーリングという概念を見出した。

　巨大化する一方のメインフレームを導入する代わりに、DECはコンピュータの負荷を複数のマシンに振り分ける方法を見出した。さらに、その複数のマシンはひとつのシステムのように動いていたので、IT管理者はそのクラスタを独立したひとつのものとして管理することができた。これにより、裏にある複雑さは覆い隠され、コストは下がり、日常業務が簡素化された。

　こうして過去を振り返ってみると、そこには今日のユーティリティコンピューティングの未来像と良く似た例が見られる。HPやIBM、Microsoft、Sun Microsystemsといった企業は、自社のユーティリティコンピューティングの複雑さを解消するため、重要な実行計画を押し進めている。（皮肉なことに、これらの企業こそが複雑さの構築に大いに貢献したのであるが、その話はまた別の機会に。）とはいえ、これらの企業は素晴らしい目的を掲げ、大勢のエンジニアを用意しているにもかかわらず、あのVAXクラスタのような成功を収めることはないだろう。

　思い出してみて欲しい。DECは垂直統合型企業、つまりハードウェアやOS、インターコネクト製品、データベースなど、全体を管理する企業であった。個々の業務を調和させ連携させるのは、ひとつの企業が全体を管理していた時でさえ非常に難しかった。複数の企業が組み合わさり、その組合せが文字どおり数千もある場合、調和と連携を実現するのはほとんど不可能だ。

　この難題にシステムベンダーはどのような手法で立ち向かうのか。共通のAPIかだろうか。それとも業界標準か、共同開発だろうか。この点について各社は、これまでのところ多くを語ろうとしていない。おそらくEMCやCisco Systems、Oracleなどの業界大手はは、各々のユーティリティコンピューティングモデルをサポートする商品を開発し、試験し、後押ししたいと考えているのではないかと思う。

　20年前の単純なアプリケーションとは違って、今日の階層化されたアプリケーションは複数のコンピュータ環境で稼動する。また、性能や運用に関する絶え間ない問題の影響を受けやすい。したがって、Solaris N1のユーティリティコンピューティング上で社内のMySQLデータベースが負荷分散しつつリソースを効率的に活用している一方で、IISベースのWebサーバが完全にダウンしているというような状況も容易に想像することができる。

　システムメーカーは、顧客が他社のユーティリティコンピューティングプラットフォームを離れ、自社のプラットフォームを選択してくれるとでも思っているのだろうか。そんな考えは甘い。今後、個々のベンダーのユーティリティコンピューティングソフトに複数の改訂版が混在し、今日以上に混乱した状況になっているかもしれないのだ。

　考慮すべき点はまだある。VAXクラスタは今よりもずっと単純な時代を生きた製品だ。当時は、IT組織の中核がコンピュータのリソースやコミュニケーション、そして限られた数の社内アプリケーションを管理していた。なんと、その組織には白衣を着た研究職員も数名いた。

　これとは対照的に今日のIT組織は、システムグループ、ネットワークグループ、アプリケーショングループ、運用グループ、セキュリティグループが寄せ集められた複合組織だ。そして、各グループがそれぞれに管理ツールを用意している。責任の一環として各グループは、ひとつひとつのサーバを定期的に管理しなければならない。人員追加なしでサーバを追加すれば、物事は必ずやり直しとなる。技術的な問題を解決することは、これらの異種のグループが一堂に会して協調することを意味する。全てのITマネージャーにとって、言うは易し行うは難し、といったところだろう。

　最高情報責任者（CIO）に告ぐ。素晴らしいユーティリティコンピューティングが今日のテクノロジーの複雑さと高コストに対する万能薬となるなんて考えちゃいけない。システムベンダーからの次の大発明を待っている間に、組織や運用に関する具体的な問題解決のためにどうすればいいか、考えたまえ。

ITマネージャーは何をすべきか

　まず始めに、IT機能グループの間の既存の壁を打ち砕き、重要な業務プロセス、サービス、そしてアプリケーションを中心としたIT組織を編成せよ。そしてこの混成チームに全ての方針・プロセス・手順の見直しを命じ、非効率な要素、重複する部分、また論点となるものを探させよう。壊されたプロセスを、明確に定義したIT管理及び基準で置き換えよ。これが、コミュニケーションを改善し、コストを削減し、テクノロジーの機能と能力を高めるのに役立つだろう。

　各ITグループも、各々の管理ツール一式を見直し、企業の中心となるものを支援する方法を見つけよう。BMC、Computer Associates、Smarts、Tivoliなどのツールは業務プロセス全体を見渡すよう設定することができる。システム及びネットワーク関連の機器を監視する代わりに、これらのツールが技術情報をアプリケーション環境の全体像へと統合してくれるだろう。コスト削減を進め、より良いサービスを提供するために、これらのツールをシステム及びネットワーク管理用に既に導入済みの企業も、利用方法の拡大を考慮すべきだ。

　最後に、ITマネージャーは、数ある運営管理用の新しいツールについて研究すべきだ。選択肢は広く、BladeLogicやOpswareのパッケージ商品から、問題のある分野に焦点をしぼった部分的ソリューションまであり、例えば、Configuresoftのサーバプロビジョン用ソフト、Citadelのパッチ管理用ソフト、Tripwireのセキュリティ用ソフトなどがある。この分野では、ベンチャーキャピタル投資やイノベーションが非常に盛んである。

　ある問題に対し、最も簡単で可能性のある解決策を試し見つけようとするのが人間の自然な行為だ。その精神に則れば、ユーティリティコンピューティングは現代の「金の卵を生むガチョウ」のようにも見える。しかし、その開発には数年を要するだろう。今後12カ月ないし18カ月の間にこの技術の進歩はあまり望めず、今までと同じ誇張された宣伝文句が飛び交うだけだろう。次の18カ月から36カ月の間には、進化したコンピューティングアーキテクチャが生まれるが、その適用は最先端のアプリケーションに限られる。そしてユーティリティコンピューティングの本当の進化は、2006年までは見られないだろう。つまり、有能なIT幹部ならば次なるVAXクラスタの出現を待たずに、むしろ組織や運営上の問題の修復に励むことだろう。そして組織や運営上の問題の修復に励むほうが、いつ発売になるかわからないソフトウェアを待ち続けたり、ベンダーの営業トークよりもはるかに役に立つだろう。