IT コミュニティでは仮想化がどんどん普及してきていますが、それは当然と言えるでしょう。そして、普及すればするほど、警戒するべきことも増えていきます。
仮想化が一般的になってきており、クラウドだけでなくオンプレミスのネットワークも含めて、仮想化はネットワークのあらゆる場所に浸透してきています。ある CIO の言葉を借りるなら、仮想化は、コストを抑えられる利点に加え、エンドユーザーにとっての使いやすさとマシンのカスタマイズ化の点で多大なメリットがありますが、留意事項も数多くあります。
仮想マシンはかなり古くから存在していましたが、15年ほど前にメインストリームに登場したときは、データセンター内でハードウェアの統合が可能になるなんて、ちょっと奇跡のようにも思えたものです。最近では、サーバーのスピンアップに必要な ROI が大幅に改善されています。しかし、仮想マシンのガバナンスはまだ成熟しておらず、その数は劇的に増加しました。
時間の経過とともに、多くの組織で膨大な数のサーバー・インスタンスを管理する必要に迫られるようになりました。これに対処するため、仮想マシンの製造元は、仮想環境を視覚化して簡単に管理できるよう、多様な仮想マシン管理システムを開発しました。
可視性と管理だけでは、VM インスタンスをコントロールするには十分ではありません。サーバーの環境、それが仮想環境であっても、に関してコストをコントロールし、価値を最大限に活用するには、優れたガバナンスモデルが不可欠です。
このブログでは、仮想化の初期の歴史を簡単にまとめた後、可能なオプション（「クラウド」または「オンプレミス」）とそれらのベストプラクティスについて述べ、ネットワークへの「優れたガバナンス」に配慮しながらプロセス全体を最適に管理する方法について説明します。
仮想化：初期の簡単な歴史
最初の仮想化システムと呼ぶべきもの (CP/CMS) は、1960年代後半にIBMで 開発されました。
当初のユースケースは、複数のユーザーが同じコンピュータを同時に使用できるようにタイムシェアリングするものでした。各プログラムがマシンに同時にアクセスしているように見えながら、実際には、ハードウェアシステムがプログラムを「時分割」して切り替え、順番に保存・復元していました。
初期の仮想マシンの次のユースケースには、抽象的な中間言語プラットフォームの作成が含まれていました。このプラットフォームは、バックエンドアーキテクチャのわずかな調整だけで、異なるマシンにコード変換するコンパイラとして使用できます。この機能は、コンテナ化の形ではまだ存在しますが、もうあまり使われなくなってきています。
私自身が仮想マシンを初めて体験したのは、Mac と PC がまだ相互交換していなかった1990年代後半でした。両方を使いたい場合、２台のマシンを購入するか、Apple が提供していた Mac と PC の両方を保持するためにパーティションされたハードドライブを有するマシンを利用するか、「Windows エミュレータ」を購入するといった選択肢がありました。その時代を覚えている人はいるでしょうか？
仮想化：概要
古き、Windows と PC のネットワークが支配していた時代は終わり、IT 管理者はマシンからマシンへと走り回って、個々のマシンごとにネットワーク上のソフトウェアをインストールします。
このような設定は非常に骨が折れ、対処が追い付かなくなってしまうこともあります。そのため、ネットワークを「オンプレミス」で運用することを選択する組織もあります。基本的には、組織の敷地内に「プライベートクラウド 」を構築します。周囲に防御壁を設け、すべてのデータを内部に置くようにしなければならないという、セキュリティ基準からしても意味のあることです。
今日では、数万の物理マシン、数十のイメージテンプレート、数千ではないにしても数百ものイメージパッケージに対処する膨大な数のストレージアレイを社内にかかえる組織さえ存在します。このようなシステムでは、ソフトウェアはハードウェアのように機能し、IT部門は強大なコントロール力を持つことになりますが、ネットワーク上のさまざまな種類の仮想化を管理することは大変困難な課題です。
ITインフラストラクチャのほとんどを「（パブリック）クラウド」に移行した企業もあります。Microsoft Azure や Amazon Web Services（AWS）などの大規模クラウド・プロバイダは、クラウドベースの仮想化のホスティングを提供しています。
もっと複雑な場合は、ハイブリッドとして運用される場合で、一部がクラウド、一部がオンプレミスになります。
仮想マシンを使用すると、OSごとに、そしてアプリケーションのニーズに応じてより高度なカスタマイズを行うことができます。これらのアプリケーション（その他のデータも含め）の「パッケージ」は、経営幹部、IT 部門、経理、人事、マーケティング、セールス、顧客サービスやサポートなど、あらゆる部門向けにカスタマイズできます。
IT 部門は、ネットワークを最適化する最良の方法が何か検討する際に、いくつかの選択肢を考慮する必要があります。
組織独自のクラウド環境：オンプレミスか、パブリッククラウドか？
組織がまず検討しなければならないことは、オンプレミス環境で稼働させるのか、パブリッククラウドを利用するのかという問題です。この二つのクラウド環境にはそれぞれ、長所と短所があります。次のポイントから考えていきましょう。
- コスト: クラウド環境は非常に複雑になる可能性があります。ライセンス料金そのものは比較的簡単に計算することができますが、さまざまなベンダーが多くの選択肢を提案してくるので、いろいろと組み合わせていくとコスト計算に非常に複雑になります。リソースを頻繁に使用すれば、それだけ費用も上昇します。
- セキュリティ: クラウドのプロバイダは、今日ではかなり安全性に配慮しているところも多いですが、プライバシー規制などの各種規制へのコンプライアンスを徹底したい場合や、何らかのセキュリティ上の懸念がある場合は、オンプレミスのソリューションを選択した方がいいかもしれません。クラウド・ベースのソリューションには、たいていセキュリティは組み込まれていますが、オンサイトのソリューションで設定できる冗長性をクラウドのデータに対して設定するのは簡単ではありません。クラウドで使用するサービスへのAPI呼び出しもまた精査する必要があります。
- 柔軟性: クラウド・ベースのサービスであれば、ライセンスを再設定し設定情報を変更するだけで、いつでも簡単に拡張できます。拡張だけでなく、もちろん減らすこともできます。組織によっては（季節変動の大きい組織など）、重要な考慮事項になり得ます。
仮想化ソリューションは多彩で、いろいろな使い方ができます。ソリューションをオンプレミス（プライベートクラウド）でホストすることも、パブリッククラウド（AWS、Azure、Rackspace など）でホストすることも可能です。さらに、ハイブリッドクラウドと呼ばれる両者の組み合わせも可能です。
ビジネス上の観点からは、新しいソリューションを開発するハイテク企業は、オンプレミスのハードウェアを使って社内インフラストラクチャを構築する必要がないことがあります。クラウドで始めればずっとシンプルです。
テクノロジー系でない大多数の企業の場合は、オンプレミスのインフラストラクチャを維持する必要性が高いでしょう。ただ、仮想化の普及が急速に進んだことで、混乱を最小限に抑えながら既存の環境にクラウドを統合することが簡単にできるようになりました。
いずれにしても、様々なオプション、組み合わせが可能になっています。
パブリッククラウド： Microsoft Azure か、Amazon Web Services (AWS) か？
オンプレミスのハードウェア・ソリューションについて議論することはこのブログの範囲を超えていますが、選択したソリューションはクラウドベースのオプションと競合することになります。疑いもなく、Microsoft と Amazon がクラウド・プロバイダの両雄で、それぞれ、Azure クラウドソリューションと Amazon Web Services（AWS）を提供しています。
AWS は、2つのクラウドベースのサービスの中でより古い（そしてより確立された）ものですが、Microsoft はマーケットリーダーに追いつくのに十分な多くの経験を持っています。複雑なネットワークソリューションでの幅広い優位性もあるので、Microsoft が後発ながらも恐るべき挑戦者であることは間違いありません。
Azure の主要な課題の1つは、「現実世界」のアイテム（Microsoft のアクティブディレクトリなど）を、マシン・インタラクションのアクティブなディレクトリタイプといった指定が必ずしも機能しない仮想世界に拡張することです。
Business.com に、2つのクラウドベース・サービスを比較する有用な記事 が記載されています。システム自体を比較するだけでなく、自社のビジネスニーズに照らし合わせて評価する必要があります。
Microsoft を好んで多用している IT 部門は、おそらく最終的には Azure を選んだ方がよりうまくいくでしょう。新しいインフラストラクチャを構築しようとしている組織、オープンソース・ソリューションやその他の Microsoft 以外のソリューションが稼働している組織は、AWS を選択することで便宜が得やすいかもしれません。
機能ごとに比較しようとすると、考慮するべき点は本当に様々で数十にも及びます。どちらのソリューションも限定的な無料サービスを提供しているので、「購入する前に試してみる」ことができます。
オンプレミスの VM ネットワーク：Microsoft Hyper-V か、VMware か？
Azure と AWS は独自のオペレーティングシステム上で動作しますが、内部の VM の場合は、仮想ネットワークを操作するための「ハイパーバイザ 」が必要になります。
サーバーやサーバー・アレイで機能するハイパーバイザとしては、Microsoft の Hyper-V と、VMware の各種製品が、主要な2つのハイパーバイザになります。両方とも内部ネットワーク上でホストとゲストの広範な仮想化を実行できますが、それぞれ特徴があります。
Microsoft の Hyper-V は、使用しているハードウェア上で直接実行できる「タイプ1」のハイパーバイザであり、その上にどのOSをインストールしても機能します。Microsoft は、Microsoft Hyper-V 仮想マシンを管理するために設計された独自ブランドの “system center virtual machine manager (scvmm)” ツールも提供しています。
VMware のほとんどの製品は、実際にハードウェアを操作する他のOS上で動作する必要がある「タイプ２」のハイパーバイザ・ソフトウェアです（ただし、VMware でも VMware ESX と呼ばれるタイプ1のハイパーバイザを作っています）。
Oracle や Red Hat なども独自の製品を提供していますが、それほど普及しているとは言えません。Red Hat の Openshift ソフトウェアは、Linux アプリケーションを容易にデリバリーできる Linux コンテナ・アプリケーションです。
Hyper-V と VMware 両システムの概要を簡単に説明したこの記事 も参考になります。
仮想化の利点と注意点
上述のように、仮想化にはメリットに加えて特有の注意するべき点があります。
- セキュリティ： 仮想化では、セキュリティは直接のコントロール対象ではありません。これは、データの可用性だけでなく、（HIPAA、CASL、GDPR などにより規制が強化され）データセキュリティとデータプライバシーを維持することが求められる医療機関や金融機関などの組織は、慎重な検討を要する問題かもしれません。
- 災害復旧： 仮想化は、冗長システムを採用した場合は特に、災害復旧に関しては優位性があります。しかし、データのバックアップに関しては、内部ネットワーク上のデータのバックアップをするようなレベルのことは行われていません。実際、組織外にホストされている情報のバックアップをとっていない組織も多くあるようです。
- 事業継続性：合併や買収が行われた場合、合併後の企業や買収先の企業で仮想化システムをマージするのはそれほど簡単なことではないので、事業継続性における問題が生ずる可能性があります。
- スプロール： 仮想マシンは簡単に追加できるので、例えば、テスト用に作成した仮想マシンが、必要でなくなった後も長くアクティブなままになるなど、見境なく VM があふれる VM スプロールが起きてしまうことがあります。スプロールは、物理サーバーから仮想マシンへのマッピングをほとんど視覚確認できなくしてしまう可能性があります。リソースの無駄遣いにもつながります。
ガバナンスのベストプラクティス
システムが複雑化し、多種多様なオプションが用意されるようになったため、できるだけ早い時期にガバナンスポリシーを策定することが重要になってきています。ガバナンスポリシーは、行っているネットワーク管理のタイプに応じて、慎重に検討を重ねて策定されるべきです。
優れたガバナンスポリシーは、（金融、医療、プライバシー/マーケティングなどの）強化される規制の法的コンプライアンス、内部の懸念事項、事業継続性（特に合併や買収などの際）、ベンダー、リスク管理など、IT 関連以外の懸念事項も含めて広範に及ぶリスクを最小限に抑えるのに役立ちます。
データのバックアップ、組織全体がポリシーを遵守できるような業務手続きの作成、自動フェイルオーバー（システム侵害などが発生した場合は、データ管理をスタンバイ・システムに移行させることが可能）などの自動機能の使用といったことも、ガバナンスポリシーに含めることができます。
企業が成長しシステムが拡張されるのに伴って、仮想マシン、ソフトウェア（およびライセンス）、さらにはユーザーが増大する過程を十分把握し、そのパターンを追跡し、管理する方法を理解しておくことが大切です。
WhatsUp Gold
旧来の IT 管理システムのほとんどは、伝統的なIT世界のものを基準にして構築されています。サーバーと PC には固有の ID があり、いったん設定されれば移動することはありません。オンかオフか（アップかダウンか）の状態を把握すれば事足りる場合が多いです。これらの特性は、仮想世界にはほぼ適用できません。
そこで効力を発揮するのは、仮想環境での仮想マシンのユニークな特性を扱えるように特別に設計された、仮想環境用の管理ツールです。WhatsUp Gold の仮想環境監視モジュールは、その１つです。
WhatsUp Gold の仮想環境監視モジュール は、ホスト、ゲスト、ホスト/ゲスト関係、クラスタとリアルタイムのステータスを表示する Hyper-V および VMware インフラストラクチャの動的マップを自動生成します。VMware と Hyper-V をリアルタイムで監視して、すべての仮想ホストと属性のリストを最新状態に保ちます。ホストとゲストの CPU、メモリ、ディスク、インタフェース使用量などのリソース消費量、サーバーの可用性とパフォーマンスを監視し、移行状況をリアルタイムで追跡します。
また、WhatsUp Gold には、クラウド監視機能 も含まれています。イプスイッチの Mark Amick 上級製品コンサルタントは、クラウド監視の正確性に関して、「ベンダーからのデータを直接獲得しますから、モニターを誤設定することはあり得ません。」と述べています。このツールは、AWS と Azure の両クラウドに対してアクティブ監視とパフォーマンス監視を行います。WhatsUp Gold は、Amazon AWS または Microsoft Azure API を介して利用可能な、どのような統計データにもアクセスして監視できます。