仮想環境をプライベートクラウド化する

　なぜ仮想環境をクラウド化する必要があるのかは第1回で説明しているが、ここでおさらいをしておこう。

　ビジネス状況の急激な変化に追随し、ビジネスの伸長を後押しするために必要なシステムがクラウド基盤だと説明をした。ビジネス部門が主導となって、必要なときに、必要なだけ迅速に、ITリソースを確保／解放できるIT基盤を実現しなければならない。

クラウド基盤に求められる機能
・標準化／メニュー化
・自動化／ワークフロー化
・課金管理／（ビジネス部門にとって）サービス化されたITの利用

　クラウド基盤に求められる機能を実現するためには、一貫性を持って環境全体を制御する基盤ソフトウェアであるクラウドOSが必要となる。クラウドOSの定義は曖昧だが、本稿では下記のようなソフトウェアをクラウドOSと定義する。

　クラウドOSとは、サーバやストレージ、ネットワークなどのITインフラ資源（リソース）を抽象化して、それらを統一されたインタフェースで管理・制御でき、ユーザー管理、ワークフロー、スケジューリング、管理用APIなどの機能を備えたプラットフォーム基盤として利用することができるソフトウェアである。

クラウドOSに求められる機能
・マルチテナント管理
・プロビジョニング管理（物理マシン、仮想マシン、アプリケーション）
・ユーザー認証
・セルフサービスポータル
・自動スケール
・課金管理

　詳細な機能を挙げていくときりがないが、現時点ではプライベートクラウド基盤をコントロールし、パブリッククラウドとの橋渡しを行う機能が提供される。

　クラウド基盤に求められる要望の追加に合わせ、さまざまな機能が現在も拡張されている。とりわけ、複数のクラウド環境を管理するための機能もクラウドOSには期待されている。理想的なクラウド環境を考えると、パブリッククラウドとの連係や、パブリッククラウドのサービスが適切に稼働しているかを監視する機能もクラウドOSには必要になるからだ。

　では、クラウドOSを選定する上で考慮すべきことは何か。ハイパーバイザーでも同様の話題を出したが、管理者はパブリッククラウド事業者がどのクラウドOSを用いているかを抑えておく必要がある。パブリッククラウドをどのように活用するかにも依存してくるが、複数のパブリッククラウドを使い分ける場合でも、異なるパブリッククラウド事業者のクラウドOSが同じか近しいものなら、管理・運用用APIに互換性があるケースも多く、同一の運用管理ツールを利用できる。クラウドOSによっては、プライベートクラウド基盤を含め、異なる複数のクラウド事業者のクラウドをまたいだサービスを一元管理したり、移行したりするのが容易になる。

　主要なクラウドOSには、「Openstack」「CloudStack」「VMware vCloud」、Microsoftのクラウド製品（Hyper-V、「Windows Server」「Microsoft System Center」）、サーバベンダーなどが提供するクラウドOSなどが存在する。どのクラウドOSが適しているのかは、現在の基盤使用法やこれまでの経験に依存してくるところが大きい。

※1　OpenStackをベースにしたソフトウェア
※2　2015年9月9日現在、著者調べ

　クラウドOSは、Openstackなどのようにマルチハイパーバイザーに対応するものもあるが、どの仮想環境を中核にしてプライベートクラウド基盤に組み込んでいくのかは検討する必要がある。もし既に、オンプレミスに複数の仮想環境があり、それぞれ異なるハイパーバイザーで稼働しているのであれば、それらに適したクラウドOSを使用するのがいいだろう。また、複数のクラウドOSをさらに上位で管理・連係するするのもクラウドOSの仕事になる。

　そのため、プライベートクラウド基盤に、どのハイパーバイザーを軸とするのか、どのクラウドOSに対応してシステム運用の仕組みを作っていくかが選定の重要な鍵となる。

もう1つの選択肢、アプリケーション実行環境におけるコンテナ

　最近、「Docker」などのコンテナ技術が注目されている。クラウド基盤の中においても、同技術に注目が集まっている。

　急激なビジネス変化に対応するため、一部サービスのシステム開発手法がアジャイル開発へ変化していることもあり、アプリケーション開発者視点から見られることも多いコンテナ技術だが、基盤側から見た場合にもコンテナを活用するメリットがある。

　コンテナを使用することで、リソースのオーバーヘッドを現在より少なくすることが可能だ。仮想マシンでは、仮想マシン単位でリソースを分割しているため、OSなどに掛かるリソースも仮想マシン単位で必要となる。コンテナの場合、必要な機能だけに絞ったコンテナ実行環境を提供したり、複数のアプリケーションコンテナを1つのコンテナ実行環境で実行できるため、仮想マシンと比較するとより少ないリソースでサービスを提供することが可能だ。

　また、今後のプライベートクラウド基盤の方向性を考えた上で最も重要な点として、クラウド基盤上に標準的なコンテナ実行環境があれば、ハイパーバイザーが異なるクラウド間でサービスをシームレスに移動できない問題を、一部解決することができる点だ。

　互換性のあるコンテナ実行環境がクラウド基盤上にあれば、コンテナを移動するのみでサービスの移動が可能となるため、プライベート／パブリック間のハイパーバイザーは異なっていても問題ない。

図4　《クリックで拡大》

　気を付けたいのは、ビジネス部門がどのようにコンテナを利用しているかを情報システム部門が把握ができず、セキュリティやコンプライアンスで統制が取れない状況だ。また、クラウド環境、コンテナ環境を一元的に管理できるソフトウェアがないため、管理が複雑化してしまうことも課題だ。

　もちろん、全てのサービスがコンテナに適合できるわけではないため、稼働させられるサービスは限られてくる。コンテナ環境として動かしやすく、比較的リソース変動の多いWebフロント系アプリケーションがターゲットとなるため、上手く活用できれば効果は大きい。

　物理マシン、仮想マシン、コンテナを適材適所で選び、プライベートクラウド／パブリッククラウドをサービスや用途によって適宜使い分けることが、クラウド管理者に課せられた課題だ。ハイパーバイザーとクラウドOSはクラウド基盤の根幹になる部分なので、慎重に選定したい。

藤澤好民（ふじさわ よしたみ）

伊藤忠テクノソリューションズ

ＩＴサービス事業グループ　製品・保守事業推進本部　ＩＴインフラ技術推進第１部　プラットフォーム技術推進課

幾つかの業種を経て2006年、伊藤忠テクノソリューションズ（CTC）に入社。

主にサーバ分野、UNIX／Linuxおよび仮想化技術を担当し、案件支援や社内外への啓蒙（けいもう）活動を行う。

最近は、マイクロサービスやコンテナ技術の活用方法について研さんの日々。