 |
＠ITアンケート調査結果レポート |
ここ数年で、ごく一般的なIT技術としてすっかり認知されるようになったサーバ仮想化だが、果たして実際にはどれほどの企業が導入に踏み切っているのだろうか？ あるいは、実際に仮想化を導入した企業では、具体的にどのような課題に直面しているのだろうか？ こうした状況を探るべく、＠IT編集部では2010年7月、＠ITの読者を対象に仮想化に関するアンケート調査を行った。その結果、仮想化の意外な現状と今後に向けた課題が浮き彫りとなった。
本調査の結果レポート（完全版）は、こちらのキャンペーンから入手できます。
（設問数：全19問 ページ数：66ページ ファイル形式：PDF）
 |
仮想化の導入による新たな課題 |
|
 |
||
まず、「当該企業の情報システムでは、サーバの仮想化を実施していますか？」というアンケート項目に対しては、急速に仮想化の導入が進みつつある現状がうかがえた。
上記の質問に対して、41.8％の回答者が「すでに実施している」と答えており、16.2％が「まだ実施していないが実施の予定がある」と回答している。さらに、その内の60％以上が、「1年以内に仮想化導入を予定している」と答えている。逆に、「仮想化の実施予定はなく、興味もない」と答えた回答者は8.5％に過ぎなかった（図1）。
 |
| 図1 グラフ「当該企業の情報システムでは、サーバの仮想化を実施していますか？」 |
しかし、仮想化を導入したものの、新たな課題に直面している企業も少なくない。一般的に仮想化を導入する目的は、物理サーバを集約することによるコスト削減や、仮想サーバの特性を生かした柔軟なITリソース管理の実現などだ。しかし、仮想化を導入した結果、運用管理が複雑化してしまい、逆にコストや手間が増えてしまうケースが出てきているのだ。
では、なぜ運用管理が複雑になってしまうのか。これを考えるうえでポイントになるのが「非機能要求」だ。
企業がITを運用する目的は、利便性や業務効率の向上のためである。具体的には、業務アプリケーションの機能をユーザーが利用できるようにするためだ。これがいわゆる「機能要求」と呼ばれるものであり、バックエンドのIT基盤が物理環境であろうと仮想環境であろうと、求められる内容に変わりはない。
一方、非機能要求とは、IT基盤の変化によって、その影響を大きく受けるものであり、システムの「信頼性・可用性」「性能・拡張性」「運用・保守性」が該当する。仮想化の導入における運用管理の難しさとは、この非機能要求を物理環境と同等以上に満たさなくてはいけない点にある。
|
「信頼性・可用性」「性能・拡張性」「運用・保守性」 |
|
|
||
非機能要求を高いレベルで実現するにはさまざまな方法があるが、ITツールの活用も、その1つだ。これは仮想環境に限らず物理環境でも同様で、これまでにも多くのベンダからさまざまなツールが提供されてきたが、昨今ではこれらツールにも仮想化対応機能が装備されつつある。その中でも今回は、日立製作所の統合システム運用管理「JP1」と、同社のアプリケーションサーバ製品「Cosminexus」を例に取り、アンケート結果から明らかになった課題の解決に「ITツールがどう役立つのか」を考察してみたい。
【1】障害影響範囲の迅速な把握と復旧
再びアンケート結果に戻ろう。「仮想化を導入した結果、障害発生時の原因や影響範囲の特定に掛かる手間や時間が増えたか？ あるいは減ったか？」という問いに対して、60.2％の回答者が「どちらともいえない」と答えた一方で、29.5％が「増えた」と回答している（図2）。
 |
| 図2 グラフ「仮想化を導入した結果、障害発生時の原因や影響範囲の特定に掛かる手間や時間が増えたか？ あるいは減ったか？」 |
これはある意味、当然の結果だといえよう。なぜなら、仮想環境においては物理環境では存在しなかった「仮想マシン」という新たな層が加わる分、システム構成が複雑になるからだ。しかも厄介なことに、仮想マシンは特定の物理サーバに縛られることなく、異なる物理サーバ間で移動させることもできる。これでは、障害が発生したときの切り分け作業は、煩雑になってしまう。
では、運用管理ツールを導入すると、どのような改善効果があるのか。仮に、システムを3層に分けて考えてみよう。最上位層が業務アプリケーションが稼働する「業務サービス」層、中間に仮想マシンの稼働環境である「仮想環境」層、そして最下層が物理サーバの「物理環境」層だ。仮想化を導入すると、これら3層の間のマッピングが動的に変化するため、管理が複雑になり障害の切り分け作業も困難になる。そこでJP1とCosminexusは、このマッピング情報をリアルタイムに管理し、運用管理担当者がコンソール上で一目で把握できるようにしている（図3）。
 |
| 図3 仮想環境における迅速な障害対応で信頼性を向上（【略称】 JP1/IM：JP1/Integrate Management , JP1/IM-RL：JP1/Integrated Management - Rule Operation）（画像をクリックすると拡大します） |
例えば、ある業務アプリケーションの反応が急に遅くなった場合、そのアプリケーションがその時点で稼働している仮想マシンと物理マシンを即座に特定し、障害個所を迅速に突き止められる。さらに、ほかに影響が及ぶ可能性のあるアプリケーションの迅速な特定も可能だ。
こうして障害原因を特定できたら、次は復旧作業だ。ここでは、Cosminexusの機能が役立つことになる。Cosminexusは、仮想マシン上のアプリケーション動作環境を自動的に構築する機能を持っている。これを活用すれば、仮想マシンの作成からアプリケーションのデプロイ、負荷分散装置への加入まで、アプリケーションを退避させる動作環境を作成するための一連の作業を一括して自動実行でき、障害からの迅速な復旧が可能になる。
【2】Full GC発生の抑止とワークロード管理
「CPUやネットワーク、メモリの管理やサイジングの難易度が上がったか？ それとも下がったか？」という問いに対しては、34.7％の回答者が「難易度が上がった」と答えた。一方、「難易度が下がった」と答えた回答者の数は、この半分だった（図4）。
 |
| 図4 グラフ「仮想化を導入した結果、CPUやネットワーク、メモリの管理やサイジングの難易度が上がったか？ それとも下がったか？」 |
CPUやメモリなどの物理リソース、特にメモリリソースの管理は仮想化の導入でよく問題になる個所だ。物理サーバを集約して、1台のサーバ上で多くの仮想サーバを稼働させるようになれば、サーバに搭載されているメモリが逼迫（ひっぱく）してくるのは、ある意味必然の結果といえる。
では逆に、メモリを十分に多く確保すれば済むのかというと、問題はそう単純ではない。高性能な物理サーバに集約するからといって、従来の数倍のメモリを仮想サーバに割り当てると何が起こるだろうか？ 実は、逆に性能が不安定になる恐れがあるのだ。
Javaアプリケーションの場合、使用済みのメモリがたまってくるとガベージ・コレクション（GC）処理で「Full GC」と呼ばれる現象が発生し、アプリケーションの応答が停止してしまう。その停止時間は割り当てたメモリ量が大きいほど長くなり、性能確保のつもりで割り当てた大容量のメモリがあだとなってしまう。その点、CosminexusはFull GCの発生を抑止するための独自のJavaヒープ管理機能を備えており、仮想環境におけるメモリリソース管理を極めて簡素化できる。
さらにJP1の稼働監視ツールを活用すれば、物理サーバごとにリソースの利用状況を監視できるだけでなく、アプリケーションごとにも負荷の統計を取得できる。これにより、どのようなメリットがあるのだろうか。
例えば、日中に負荷が高まるオンライン型のアプリケーションと、夜間に負荷が高まるバッチ型アプリケーションを上手く組み合わせて物理サーバ上に配置することで、物理サーバに掛かる負荷を平準化してリソースの利用効率を向上できる。さらに、こうした統計情報を基に、将来のリソース増強のためのプロビジョニングも正確に行うことが可能になる。
【3】業務アプリケーションの配置を気にすることなく運用・保守を
今回行ったアンケートでは、「仮想化導入の目的」について「これまでの目的」と「これからの目的」の2通りに分けて回答を得ている。その結果、いくつかの興味深い結果が出ている（図5）。
 |
| 図5 グラフ「仮想化の目的これまでとこれから」（画像をクリックすると拡大します） |
その1つが、「信頼性／可用性／セキュリティの向上」を目的に「これまで」仮想化を導入したとする回答が26％なのに対して、「これから」同じ目的で仮想化を導入したいとする回答が46.4％も寄せられた点だ。コスト削減を目的として導入するフェイズから、信頼性／可用性の向上に期待して導入するフェイズに移っていると予測される。
また、「すでに仮想化を導入したサーバの役割」について聞いたアンケート項目では、「開発・テスト用サーバ」「Webサーバ」という回答が多かった一方で、「業務アプリケーション」と答えた回答者は約4割に留まった（図6）。
 |
| 図6 グラフ「仮想化されているサーバの役割」 |
この2つのアンケート結果から、今後は業務アプリケーションを稼働する本番環境への仮想化導入に伴い、信頼性や可用性の課題がクローズアップされてくることが予想できる。この場合、常に問題になるのが、「業務アプリケーションがどの仮想マシン、どの物理サーバ上で動いているのか分からなくなってしまう」ことだ。
前述のようにJP1では、アプリケーションと仮想マシン、そして物理サーバ間のマッピングを可視化する機能を備えている。そしてCosminexusでは、仮想／物理サーバを業務アプリケーション単位でグループ化し、一括して起動・停止する機能がある。そのため、「業務を継続したままソフトウェアのアップデートや、パッチ適用を行う「ローリングアップデート」の場合にも、アプリケーション単位で指定するだけで自動的に実施できる。
このように、アプリケーションが仮想マシンや物理サーバ上にどのように配置されているかを一切気にすることなく運用・保守作業ができるため、仮想環境へ移行する際に信頼性や可用性が低下するリスクを大幅に低減できるのだ。
|
プライベートクラウドの運用に向けて |
|
|
||
以上で見てきたように、仮想環境の運用管理にまつわる課題を解決するための機能を、JP1とCosminexusの連携によって提供している。さらにその一方で、「クラウドコンピューティング」のIT基盤を前提としたソリューションの提供も始めている。
事実、今回行ったアンケートの結果にもそれは如実に表れている。「プライベートクラウドの構築、またはその布石」を目的に「これまで」仮想化を導入してきたとする回答は9.7％に過ぎなかったのに対して、同じ目的で「これから」仮想化を導入していきたいとする回答は33.7％あった（既出の図5参照）。ここから、クラウド活用を見据えた第1のステップとして仮想化導入を考えているユーザーが多いことが分かる。
日立製作所では、ITリソースの効率的な活用を支援するITリソース管理基盤製品「JP1/IT Resource Management - Manager（JP1/ITRM）」により、ITリソースの利用をスケジューリングし、リソースの割り当てが可能だ。例えば、次のようなケースだ。
ユーザー部門で仮想サーバ環境が必要になったら、自分たちでサーバ環境を構築するのではなく、システム管理部門にリソースの確保と予約を依頼する。システム管理部門はJP1/ITRMを使って空いているITリソースを検索し、要求されたスペックに見合うリソースを予約する。そして実際にリソースの割り当てが行われたら、ユーザー部門に仮想サーバの配備完了を知らせる。
さらにCosminexusを使えば、割り当てられた仮想サーバ上でのアプリケーションのデプロイや負荷分散装置への加入などが、ユーザー部門で可能になる。この場合、「リソース管理と割り当てはシステム管理部門が行い、仮想サーバ上のアプリケーション環境の管理はユーザー部門が行う」という棲み分けがきれいにできる（図7）。
 |
| 図7 「JP1/ITRM」と「Cosminexus」を使った運用管理（画像をクリックすると拡大します） |
こうしたシステム運用の仕組みは、まさにプライベートクラウドそのものだといっても過言ではないだろう。このように同社では、JP1とCosminexusの組み合わせによって直近の仮想環境の課題のみならず、来るべきクラウドコンピューティングの世界も射程にとらえている。こうした意味でも、この両製品は長期的な展望に基づき、長く安心して使えるソリューションといえるのではないだろうか。
なお、今回示したアンケートの結果は、ほんの一部のものだ。結果のすべてが気になった読者は、以下のリンクから入手できるので、申し込んでみてはいかがだろうか。
 |
提供：株式会社 日立製作所 ソフトウェア事業部
企画：アイティメディア 営業本部
制作：＠IT 編集部
2010年9月23日
| 関連リンク | ||||||||
|
| アンケート | ||||
|
||||
| ＠IT関連記事 | ||||||||||||||||||||||||
|
