PR

 クラウドコンピューティングには、パブリック/プライベート、企業外/内とさまざまな定義があるが、「仮想化技術や分散処理フレームワークなどを用い、共有システム資源(リソースプール)を効率的に使う」というコンセプトは共通だろう。

 サーバーやストレージは年々、高性能・大容量化している。それらを用いて構築するリソースプールに既存のシステム資産を移行する際、最も大きなテーマとなるのは「いかに集約度を高められるか」だ。当然、コストパフォーマンスの最大化が要求される。既存資産と比較して、どれだけサーバーやストレージの台数を削減できたかが成功指標となるのは自然の流れである。

 しかし、企業が既存システムのアプリケーションの変更を行わず、リソースプールを構築して移行するとき、重要な検討要素が欠けることがある。それは、ネットワークである。

配線ポリシーがバラバラなシステムが出来上がる

 基盤を設計するアーキテクトは、集約対象とする保有サーバー、ストレージのスペックと利用率に関する情報を集め、それを基に必要なリソースを積み上げる。集約度が最重要指標であるため、CPU、メモリー、ディスクといった“性能・容量”の観点でリソースプール設計を進める。

 なぜか、この過程でネットワークの検討が抜けてしまう。原因は、「足りなければ、従来通り後からNICとケーブルを追加すればなんとかなるだろう」「サーバーやストレージの担当部門とネットワークの担当部門が分かれているから」などさまざまだ。

 だが、ネットワーク設計を後回しにしてはいけない。後からなんとかなる、と考えてはいけないのだ。

 いざ集約の詳細検討に入って気付くことは、システムごとにネットワーク設計は実に多様であることだ。その設計の背後にはさまざまな背景や歴史があり、職人技で構築されたネットワークも多い。得てして、ドキュメントも残っていない。結局、リスクを考慮し、従来のネットワーク設計を特定のサーバーに盛り込むことになる。

 またセキュリティを理由に「このシステムは、ほかのシステムとネットワークだけは明確に分離したい」と要望されることもある。このように、次々とボトムアップで要件が追加される。加えて、冗長化や内部通信、管理系セグメントも考慮しなければならない。一般的な1GbE(ギガビットイーサネット)では帯域が足りなくなることもしばしばだ。その結果、サーバーごとに配線ポリシーがバラバラなシステムが出来上がる(図1)。

図1●ボトムアップの要件でネットワーク構成が決まってしまう
図1●ボトムアップの要件でネットワーク構成が決まってしまう
[画像のクリックで拡大表示]

 高密度なサーバー、ストレージは、ケーブルを密集させる。取り回しによっては熱だまりとなり、冷却効率の低下にもつながる。そして運用が始まってしまうと、その影響範囲の大きさから、誰も手を出したがらず追加どころではない。その結果、活躍するはずのリソースプールは、そのまま塩漬けとなる。サーバーごとに物理ネットワーク構成がバラバラであれば、共有化が進まない。そもそも何のためのクラウドか、ということになりかねない。

ライフサイクル、テクノロジー、ガバナンスを考える

 このような本末転倒を避けるために、ライフサイクル、テクノロジー、ガバナンスを意識することが重要だ。まず、リソースプールの構築から廃棄まで何年間利用するのかというライフサイクルを定義すること。次に、そのライフサイクル内で効果的・実用的なテクノロジーがないかを検討する。例えば、2010年時点で、10GbEによるネットワーク集約、配線の簡素化は有効な対策として検討に値する。

 最後に、そのテクノロジーに基づいた設計ポリシーを徹底し、ガバナンスを利かせることだ。もちろん、ユーザーの共感を得られるだけのビジネス上の、あるいは技術的な根拠が必要だが、そこはアーキテクトの腕の見せどころだろう。これからのアーキテクトは、サーバーとストレージ、ネットワークを総合的にデザインしなければならない。


真壁 徹(まかべ とおる)
日本ヒューレット・パッカード ESSプリセールス統括本部 インダストリソリューション本部/通信・メディアソリューション部 シニアITスペシャリスト
1997年に金融系シンクタンクに入社し、保険システムのアプリケーションと基盤開発に従事。2001年、日本ヒューレット・パッカードに入社。アプリケーション開発部門を経て、現在は主に通信事業者向けシステム基盤の提案、設計を担当している。