仮想化技術を使いこなす!「インターナル・クラウド」の奨め

中村輝雄 - 2009年3月16日(月) 13:00

システム需要の増減に柔軟に対応し、セキュリティの向上や運用コストを削減できる─
それを実現するシステム基盤の姿の一つとして、関心を集め始めているのが「インターナル（企業内）クラウド・コンピューティング」だ。仮想化技術とブレードサーバーなどを活用し、社内のコンピュータ資源を”クラウド化“する。この方向の必然性と現時点における実用性を明らかにする（本誌）。

多くのITリーダーの方々にとって今や、仮想化技術は馴染みのある技術になりつつあるはずだ。具体的にはVMwareやXenServer、Windows Server 2008 Hyper-Vといった仮想化ソフトを使ったシステム基盤である。かつて大型汎用機に限られていた仮想マシン（VM）をより気軽に構築できるようになり、サーバー台数の削減や運用性向上を目的にしたサーバー統合を実践できるようになった。だが仮想化技術のメリットは、それだけではない。

「クラウド・コンピューティング」─。2008年、一気に広まったITキーワードの一つだ。コンピュータ資源やネットワーク資源をインターネットの”向こう側”に任せ、ハードウェアや時にはミドルウェアさえも気にせずに、システムを構築できる。データセンターに用意した数多くのPCサーバーを仮想化技術によって一つであるかのように見せ、ハードウェア資源を気にせずにシステムを開発したり運用したりできる（図1）。

まだ実用には遠い技術に思われるかも知れないが、仮想化技術を利用すればクラウド・コンピューティングとほぼ同等の利点があるコンピューティング環境を自社内に構築できる。すなわち“インターナル・クラウド（企業内クラウド）”である。

筆者らは、2年以上前の2006年秋に仮想化、そしてクラウドに関わる技術の可能性を捉え、2007年1月に「日立ソフトSecureOnline」というクラウドセンターを立ち上げた。これ自体は、一般企業やIT企業にクラウド環境を月額課金で提供するサービス用のセンターだが、社内でも当然、活用している。

本レポートではこの時の経験をもとに、企業内の新しいIT基盤としてクラウド・コンピューティングがどう役立つのか、その可能性を明らかにしたい。新しいITインフラが2009年以降、企業の情報システム基盤を大きく変えるポテンシャルを持つことを把握していただけるはずだ。

20世紀はスケールアップの時代

インターナル・クラウドは決して突飛でも、不可思議な技術でもない。それを理解していただくために、歴史をざっと振り返っておこう。

企業が情報処理業務にコンピュータを盛んに利用するようになったのは約50年前の1960年頃のこと。拡大する需要に応えるべく1964年には、メインフレーム（汎用大型計算機）である「IBM System/360」が登場した。360はハードウェアのアーキテクチャを統一すると同時に、本格的なオペレーティングシステム「OS/360」を搭載し、さまざまなアプリケーションを実行できる、当時としては画期的なコンピュータだった。

ところがユーザーの要求が多様になるに従い、それに応えるために絶えず性能を強化する必要に迫られた。結果として1台のメインフレームは、アーキテクチャ上の互換性を保ちながら性能を上げていくようになった。「スケールアップ」と呼ばれるものである（図2）。

System/360では、仮想マシン（VM）技術も導入された。ただし本格的に利用されるようになったのは、1970年に登場したSystem/370において、仮想記憶が完全サポートされてからだ。

そうなるとさらなるCPU性能、メモリーアドレス空間が求められるようになる。1983年に登場したSystem/370-XAでは、メモリーアドレス空間が24ビットから31ビットに拡張され、1990年にはハードウェアの性能をさらに高めたESA/390（通称、S/390）が登場した。2000年のzSeries（後にSystem z）では、メモリーアドレス空間は64ビットにまで拡張されている。

このようにIBMはユーザーの要望に応えるためにほぼ10年単位でメインフレームをスケールアップさせており、このことから「20世紀はスケールアップの時代だった」と位置づけられる（図3）。当然のことだが、これは日立製作所や富士通、NECといった、国産コンピュータメーカーの機種も同じである。

スケールアップから分散処理へ

一方、ユーザー企業では情報システム部門が中心になって、計画的にメインフレームをスケールアップし、さまざまなアプリケーションを稼働させてきた。しかし高価なメインフレームを何台も導入できないといった予算の制限や、システム要員の不足から爆発的な情報化ニーズに応えられない事態が生じた。いわゆる“バックログ問題”である。

こうした中、1982年に米Sun MicrosystemsがOSにUNIXを採用したコンピュータの販売を開始。メインフレームとは異なり、オープンかつ手軽に利用できるUNIX機は、現場部門の中核的なサーバーとして幅広く普及した。情報処理をメインフレームだけでこなす集中処理から、メインフレームやUNIXサーバーに処理を分担する、分散処理の到来である。

1984年、IBMはCPUにIntel 80286を、OSにマイクロソフトMS-DOSを採用したIBM PC/AT（現在のPCの原型）を発売した。こちらはメインフレームのグリーン端末を置き換えるとともに、いわゆるオフィスオートメーションの起爆剤になった。1993年のWindows 3.1や、1995年のWindows 95の登場で1人1台の時代をもたらしたもした。

分散処理がもたらしたコスト負担

1996年にはパソコンをサーバー機として使えるようにするOS、Windows NT Server 4.0がリリースされ、UNIXサーバーに取って代わる勢いで部門サーバーとして広く使われ始めた。この結果、分散処理が加速。大企業では事業所や営業所に数台、合計すると数千台、中堅企業でも数十台から数百台のPCサーバーが社内に溢れることになった（図4）。

結果として、UNIXサーバーやPCサーバーを使った分散処理は、ここ数年、大きな問題をもたらすようになった。

導入時点ではあまり意識されなかった問題に、OSのサポート切れがある。1996年に販売されたWindows NT Server 4.0はMicrosoftのWebページによれば、2004年から段階的にサポート範囲が限定された。2000年に発売された後継のWindows 2000 Serverも、2005年から段階的にサポートが終了している。さらに2003年発売のWindows Server 2003も、Windows Server 2008の発売でやがてサポート切れを迎える。

サーバー・ハードウェアのサポート問題も悩ましい。サーバーベンダーにとっては複数バージョンのOSの動作を保証するのはかなり厳しいため、最近のPCサーバーでは、Windows NT Server 4.0やWindows 2000 Serverの動作を保証していないケースがほとんどだ。

そうなるとMicrosoftがサポート期間を延長しても、ユーザーが現在保有しているサーバーが壊れてしまえば、それを修理しない限り、システムを復旧できない。ユーザーがリスクを負って、旧OSを稼働させる場合は別にして、昔のOSを稼働させられるサーバーは手に入らないのである（図5）。

仮想化ソフトの魅力

そんな中で、PCサーバーの高性能化が進んでいる。とりわけCPUは2コアから4コア、8コアと進化しており、PCサーバーに仮想マシン（VM）技術を適用する必然性は高い。VMwareのVMware Infrastructure 3やXenSource（現在はCitrixが買収）のXenServer、MicrosoftのWindows Server 2008 Hyper-Vなど、仮想化ソフトの選択肢も増えている。

PCサーバーに仮想化ソフトをインストールすると、そのVM上で過去のOSを稼働させることができる。VMwareを例にすると、Windows NT Server 4.0、Windows 2000 Server、Windows Server 2003、Windows Server 2008、さらにRedHat LinuxやCentOSのようなLinuxや、NetWare、Solarisもサポートしている。過去のOSをサポートしていない最新のPCサーバーに仮想化ソフトをインストールすれば、過去のOSでしか動かないアプリケーションを走らせることができる（図6）。

これはユーザー企業にとっては朗報だろう。企業内のシステムには、毎日稼働するものもあれば、月に1度しか動かさないものもある。社員全員が使うシステムもあれば、特定の部門しか使わないシステムもある。過去のOSで動かしているものは、特定の部門しか使わない使用頻度の少ないシステムであることが多く、塩漬けになっているシステムである。どの企業でも、こうしたシステムはかなりの数に上るはずだ。

仮想化ソフトを使うことでその問題を解消でき、サーバーベンダーのサポート期間にとらわれることなく、使い続けられる。またOSのサポートが終了し、新しいバージョンに移行しなければいけないが、仮にアプリケーションを移行する予算を確保できない場合でも、OSのサポートを受けずにシステムを塩漬けにする覚悟さえあれば、しばらくは使い続けられる。このようにすれば、システムのリプレース時期をユーザーが自ら、決定できるようになるのである。もちろんシステム資源を柔軟に用意できるようになる利点も大きい。

インターナル・クラウドとは？

仮想化ソフトを導入すると、１台のPCサーバーで複数の仮想マシン（VM）を用意できる。では、それはどの程度か？最新のPCサーバー（4コアのCPU、16GBのメモリー搭載）を例に考えよう。

まず仮想化ソフトそのものを稼働させるためのメモリーは2GBあれば十分なため、14GBのメモリーをVMに割り当てることができる。一方、理論上も筆者らの経験上でも、Windows Server 2003上でWebサーバーを走らせる場合、1GBのメモリーで足りる。したがって1台のPCサーバーで14のVMを稼働できる。余裕をみて以下では12のVMを走らせることを想定する。

CPUは4コアなので、1コアで３つのVMの面倒をみることになる。通常、PCサーバーにおけるCPU利用率は30%に満たないから、性能的には問題は起きない。実際、筆者らの経験では、1台のPCサーバーで12のVMを走らせた場合、性能上の問題は起きていない。

したがって企業のデータセンターに10台のPCサーバーを用意すれば、120のVMを稼働できる計算になる。38Uのラックに30台の1Uの大きさのPCサーバーを搭載すれば、1ラックのスペースで360（30台×12）のVMが稼働する。

このように社内向けに大量のシステム環境を提供するデータセンターを、筆者は「インターナル・クラウド・センタ（略して、インターナル・クラウド）」と呼んでいる。これに対し、GoogleやAmazonのように、社外ユーザー向けにVMを提供するクラウドセンターを、「オープン・クラウド・センタ（略して、オープン・クラウド）」と呼んで区別する。

インターナル・クラウドの利点

インターナル・クラウドの利点には何があるのか。一つは、社内各所に散らばっているPCサーバーの集約である。VMのIPアドレスは、物理的なPCサーバーに割り当てるのと同じく、社内のIPアドレスだ。このため物理的なPCサーバー上のアプリケーションを、インターナル・クラウドのVMに移行するのはそれほど難しくはない。移行の結果として、スペース効率の向上や総消費電力量の削減といったメリットがある。

ただ、これは「クラウド」という言葉を持ち出すまでもなく、仮想化技術の典型的なメリットである。より大きいのは、コンピュータ資源の柔軟性の向上だ。新システムを開発する際に、ゼロからシステム基盤を設計する負担を大幅に減らせるし、あるVMの負荷が重くなったとき、より多くのCPU資源を割り当てることができるなど運用性も高められる。

インターナル・クラウドのVMを開発環境に割り当てれば、開発環境の統一も容易だ。具体的には、開発者用のツールをインストールしたディスクイメージをあらかじめ用意しておく。新規の開発者がプロジェクトに参加した時、そのディスクイメージをコピーして開発環境を提供すれば、すべての開発者の開発環境を統一できるのだ。

当然、オープン・クラウドと同様に、社内のPCをシンクライアントにすることもできる。PCのデスクトップ環境をインターナル・クラウドに移行させれば、情報漏えい対策や、運用性の向上がやりやすくなる。

信頼性の確保に向けて

サーバー集約にしろ、シンクライアント化にしろ、インターナル・クラウドの成否は信頼性、あるいは可用性が重要である。実際のところどうなのか。ここでは、筆者らが利用しているブレードサーバー「BS320」とディスクアレイ「AMS2100」、イーサネットスイッチ「AlaxalA」を、具体例に挙げて検証しよう（図7）。当然だが、他社のブレードサーバーでも理論的には同じである。

（1）BS320のブレードが壊れたとき

BS320では、10枚のブレードがそれぞれ、LANコントローラを経由してLANスイッチモジュールと、それにFCコントローラを経由してFCスイッチモジュールに接続されている。仮想化ソフトでは、これら10枚のブレードを1つのクラスタ単位としてHA（ハイアベイラビリティ）構成をとることができる。

このため、たとえ1枚のブレードが壊れたとしても、その上で稼動していたVMを動的に他の9枚のどこかのブレードで再起動して稼働させることができる。ただしデータは失われるので、それを防ぐには物理サーバーの時と同じく、2つのVMで同じアプリケーションを走らせておく必要がある。

（2）BS320のFCスイッチモジュールが壊れたとき

BS320では、2つのFCスイッチモジュールからAMS2100の2つのRAIDコントローラに接続しており、通常はデータをやりとりする主系と、主系が壊れたときに切り替わる副系に設定する。主系が何らかの障害で切断されたとしても、副系のアクセスルートに自動的に切り替わるので、VM上のOSやアプリケーションは障害に影響されずに動き続ける。

（3）BS320のLANスイッチモジュールが壊れたとき

BS320では、2つのLANスイッチモジュールからそれぞれ2本、AlaxalAのL2スイッチに接続しており、FCスイッチモジュール同様、LANスイッチモジュールも主系と副系に設定できる。このため、主系のアクセスルートが切断されても、副系に自動的に切り替わる。

耐障害で効果の大きい増設

ところで、図7のBS320の環境は、論理的には独立したPCサーバー10台をクラスタ構成にしたのと同じだ。1枚のブレードが故障しても、他の9枚のブレードでアプリケーションは動き続ける。1枚のブレードで12VMを提供できるので、9枚で108VMを引き続き提供できる。つまり、ブレードが2枚壊れない限り、インターナル・クラウドに集約した100台のサーバーは動き続けることができる。

では、ここでブレードを9枚だけ使って100台のサーバーを集約したときの稼働率と、ブレードを10枚使って100台のサーバーを集約したときの稼働率を計算してみよう。1枚のブレードの障害率（1年間で1回壊れる確率）をαとする。

まず9枚の場合、1枚でも壊れればその瞬間、100台すべてのサーバーを走らせることはできないので、稼働率は（1−α）⁹であり、91.4%になる。一方、10枚の場合、1枚が壊れても100台のサーバーを走らせることができるので、稼働率は2枚が同時に壊れない確率となり、次の式で計算すると99.6%となる。

2枚が同時に壊れない確率

＝（1枚も壊れない確率）＋（1枚だけ壊れる確率）

＝（1枚も壊れない確率）＋（1枚目だけ壊れる確率）＋（2枚目だけ壊れる確率）＋・・・＋（10枚目だけ壊れる確率）

＝（1−α）¹⁰＋（α×（1 − α）⁹）×10

このように、1枚予備のブレードを足すだけで、稼働率は91.4%から99.6%に跳ね上がる。もう1枚足したとすると、稼働率は同時に3枚が壊れない確率となり、次の式で計算すると99.98%となる。

（1−α）¹¹＋（α×（1−α）¹⁰）×11＋（α×α×（1−α）⁹）×₁₁C₂　

21世紀はスケールアウトの時代

100台のサーバーを集約するとき、9枚のブレードで性能的には十分だが、信頼性の確保の観点から1枚を足すと稼働率を99.6%に高められる。さらに1枚を足せば99.98%になる。性能が足りない場合には、ブレードを増設すればいい─これはあくまで論理的な計算だが、多くの読者には、実感としても理解いただけるはずだ。

このような方法で性能と信頼性を向上させるやり方を「スケールアウト」と呼ぶ（図8）。米Googleなどは、このようなやり方をベースに、ミドルウェアや運用面で独自の工夫を凝らし、数億人のユーザーをサポートしている。一般のユーザー企業がそこまでやる必要はないが、汎用の安価なプロセサを使ったスケールアウトにIT基盤の未来像の一つがあることは間違いない。

20世紀を「メインフレームを中心としたスケールアップの時代」とすれば、「21世紀は仮想化によるスケールアウトの時代になる」と言える。読者の皆さんもこの可能性を信じ、社内にインターナル・クラウドセンターを立ち上げ、IT基盤を構築してみてはいかがだろうか。

Column
インターナル・クラウドを普及させる取り組み

社内でインターナル・クラウドを普及させるのは決して簡単ではない。社外のクラウドのように、セキュリティや可用性を含めたサービスレベルの問題はないにせよ、既存のITインフラからすると大きな変化になるからだ。そこで筆者が勤務する日立ソフトで実施してきた普及策を紹介しよう。いずれも当然の策だが、これらを地道に実施することが大切である。

(1) 導入の狙いの明確化

情報システム部門の担当者はまだしも、現場部門のIT／IS担当者からすると、よく分からない余計なサービスを提供するぐらいなら、高性能なサーバーの予算を割り当てて欲しいと考える可能性が高い。特に当社のようなソフト会社ではその傾向が強かった。つまりインターナル・クラウドを普及させる上での障害は、社内のIT/IS担当者なのだ。

この壁を乗り越えるには、全社方針としてインターナル・クラウドの導入をうたい、同時に目的を明確にすることが必要になる。日立ソフトでは、次のような項目をもって社内展開している。

災害発生時のサーバー転倒による人的被害、および破損によるデータ消失の防止
職場内のスペース効率向上、フロア移転時の省力化
開発環境立ち上げの早期化と省力化
物理的なセキュリティリスクの回避
新規設備投資の抑止、サーバー管理コストの削減

(2) 取りまとめ部署の設置

日立ソフトでは、インターナル・クラウドのために「サービス基盤グループ」という専任組織を設置。現在、2名で100以上のVMを提供している。

この組織の担当業務の一つは、社内開発部門に対するサービス窓口役である。VM利用申し込みの受付、VM構築依頼と完了通知、使用後のVM削除受付などである。実際のVMの構築、運用、削除は、インターナル・クラウドセンターという別の部署が担当している。

もう1つは、VMの利用促進のために、VMをうまく活用したプロジェクトをベストプラクティスとして全社に紹介することだ。社内のIT/IS担当者は、手元にサーバーを保有したがる傾向があるので、啓蒙活動はサービス基盤グループの重要なタスクになっている。

(3) サービス内容と課金単位

サービス基盤グループが提供するサービスとしては、VMとソフトウェア・ラインセンスの提供がある。VMについては、メモリーとディスク容量を指定できる。CPUを1個から2個に増やすこともできる。ライセンスについては、WindowsやOfficeなどは、サービス基盤グループで一括契約して提供している。ただしプロジェクト固有のラインセンスについては、個々のプロジェクトで予算化し手配をかけている。

課金は原則として月単位。VMについては、インターナル・クラウドセンターと話し合い、センターが保有する資産の償却費を、ある期間で利用が見込まれるVM数で割って1つのVMあたりの想定原価を決め、課金する。ライセンスはソフトのベンダーと交渉の上、実費をプロジェクトに課金している。

一方、月々の課金とは別に、VM利用申し込み時や変更時に一時経費としてプロジェクトに課金するものがある。VMを新規に構築する作業費や、既存のVMのメモリーやディスク容量を変更する作業費などである。VMのバックアップ費用やリストアのための作業費も、課金している。

(4)啓蒙活動

前述のように、サービス基盤グループにとっては啓蒙活動が一番重要なタスクかもしれない。日立ソフトの場合、インターナル・クラウドセンターを立ち上げた当初の1年間で、利用されたVM数が想定の3割程度という状態が続いたからだ。

理由の一つには、VMの料金がレンタルのサーバーより高いという事情があった。会社としては、VMを利用すればサーバーの設置スペースや運用に関わる費用を削減できるのだが、現場からすればそれらのコストを負担している実感がない。つまり、会社の幹部は全社でコストが削減できるので前向きなのだが、現場サイドは自分の席の隣からPCがなくなるというだけで何となく不便さを感じ、後ろ向きになる。

こうした“抵抗勢力”を味方につけるには、VMがあったからこそプロジェクトがうまくいったという成功事例をコツコツと紹介するのが最も効果的だ。特に当社のようなソフトウェア会社の場合、開発を進めていて性能が足りなくなった時にVMだったので簡単にメモリーやディスクを増やすことができたという事例や、テスト工程でエンジニアを急遽増員することになった時にVMだったので簡単にサーバーを追加することができたといった事例は、現場の支持を得る近道だった。そのためには地道な啓蒙活動が必要である。