クラウド導入における「モデル」と「場所」の組み合わせ

前回、進化を続けるAzureとそれに追随するAzure Stackが持つメリットとリスク、そのリスクを補うためにAzure Packという選択肢が既に存在することを解説しました。今回は、さらに掘り下げてみようと思います。

クラウドとは、モデルの話であって場所の話ではない?

一般的に「クラウド」と言えばパブリッククラウドを指し、自社内ではない別の場所にあるITを使うことを指すケースが多いでしょう。でも、マイクロソフトは少し違う感覚でクラウドという言葉をとらえ始めています。例えば、昨年9月にアトランタで開催したイベント「Ignite 2016」のなかで、マイクロソフトが出したメッセージの1つに「Cloud is a model, not just a place.」という言葉があります。

ご存じのとおり、クラウドはITの利用の仕方を変えました。これまで数カ月かかっていたことでもクラウドだと数分・数十分でできてしまいますし、サービスがどんどん進化するので、支払う金額は同じでも数カ月後には違うシステムが使えたり、作れたりします。

また、クラウド登場以前は、自社基盤のリソースや運用の都合に合わせてアプリケーションやシステムを作るのが一般的でした。しかし、今どきのPaaS指向なエンジニアはクラウド上にあるさまざまなサービスを使い、仮想マシンに依存せずにスケーラブルで高い可用性を持つシステムを作り上げます。従量課金を意識して、リソースコントロールまで自動化しているケースもあるでしょう。クラウドを理解すればするほど、これまでの開発とは何もかもが違ってくるわけです。

けれども、企業がITを選択する際には、システムを配置する場所が重要な要素になっています。パブリックなクラウドは使えないというだけで、非常にゆっくりと仮想マシンだけが提供される社内IT基盤を使わなければならない企業も多いでしょう。

Azure Stackは、そうした問題を解決するために開発されています。そう、Azure Stackは「クラウドという新しい利用形態(モデル)を社内に持ち込めるプライベートクラウド基盤」なのです。そして、前回の内容を思い出してもらいたいのですが、社内には「どんどん進化する」というクラウドのモデルが合わないシステムも存在しています。それを整理したのが、こちらの図です。

今後のハイブリッドクラウド基盤を考慮した「場所」と「モデル」の整理

パブリックが良いのか、プライベートが良いのか、その使い方はクラウドっぽいのが良いのか変化しないことを良しとするのか。いろいろと考慮する点があるなかで、その全てが必要だということは、「上記3つの組み合わせを検討する必要がある」ということです。

3つの要素を実現するマイクロソフトの基盤技術

3つの要件に応じて、それぞれにマイクロソフトが提供するクラウド基盤を当てはめると次のようになります。

場所とモデルの3つの組み合わせとマイクロソフトのソリューション

まずは「Microsoft Azure」があり、Azure Stackがそのモデルをプライベートで提供し、「Azure Pack」は従来型のモデルをカバーしていることがおわかりいただけると思います。一時期、Azure Packは最新のプライベートクラウドツールであるAzure Stackによって置き換えられていくというイメージでとらえられていました。そうした要件を満たすために、最新のサーバOS「Windows Server 2016」や仮想化管理製品「System Center 2016」にも対応し、2027年までサポートが継続されることになっています。

ただし、このままではAzure StackとAzure Packという2種類のプライベートクラウド基盤がバラバラに社内に存在することになります。それぞれが提供するサービスのモデルが違うわけですから、社内に2つ存在させることに問題はありません。けれども、利用者の負荷が高くなってしまう可能性があるのも事実です。

そこで現在、Azure Stackの画面からAzure Packのリソースをコントロールできるツールを開発中です。最終的にどのようなツールが提供されるのかはわかりませんが、現時点では、ユーザーが利用するのはAzure Stackの画面だけで、そこからAzure Pack環境を選択してリソースを作ったり、制御したりできるような仕組みになっています。

Azure StackのメニューからAzure Packを選択しようとしているところ（開発中のため、画面はサンプル）

いずれはパブリックなクラウドUIとの統合も期待したいところですが、現時点で発表されているのはここまでです。これを、先ほどのスライドに重ねるとこのようになります。

Azure StackとAzure PackのUIが統合できた場合の場所とモデルの組み合わせ

Azure StackやAzure Packでは、H/Wを含めたシステム導入自体に進化あり

これまでのデータセンターでは、仮想化基盤を作るにせよ、プライベートクラウドを作るにせよ、さまざまな技術要素を個別に調査・検証し、導入するベンダーを選び、組み合わせによる不具合を乗り越えながら長い時間をかけて実稼働にこぎつけていたことでしょう。昨今、ハイパーコンバージドインフラがはやり始め、ストレージとサーバはセットで考えられるようになってきたとは言え、ネットワークについては自動化が進んでいない企業もありますし、別途SDN（Software Defined Networking）を検討することも多いと思います。

Azure Stackも、検証が不要だとは言いません。現時点ではAzure Stack自体が開発中なので、フィードバックのための技術検証を依頼していますし、Azure Stackにかかわるエンジニアであれば、技術的な側面からAzure Stackを理解することも必要です。

ただし、少なくとも最初にリリースされるAzure Stackは、動作することが確約されたハードウェアと共に出荷されます。きちんと稼働するかどうかを社内で一生懸命検証する必要はありません。導入すれば確実に動くはずです。しかも、SDS(Software Defined Storage)が動くとか、SDNがバラバラと動くとかいう話ではなく、それら全てを包含したAzure Stackというプライベートクラウドが動くのです。おそらく、一般のユーザーによる検証は、自社内の運用プロセスとの兼ね合いやAzure Stack上に自社システムを展開するための検証がメインになるでしょう。

実は、この「導入したらすぐに動くプライベートクラウド」という方式は既に始まっており、Azure Packが動作するプライベートクラウド基盤込みのハードウェアパッケージは今すぐに日本で購入することができます。こうなると、企業はAzure Packの導入を決め、ハードウェアベンダーと契約し、後はハードウェアが運ばれてくるのを待つだけです。

届いたハードウェアを設置したら、電源を入れてネットワークを接続し、自社の環境用に情報(例えば社内のADのドメイン名など)を入力してスクリプトを実行すれば、数時間後にはプライベートクラウドが動き出します。もちろんAzure Stackもこの考え方を踏襲しているので、流れは大きく変わらないはずです。

まだ開発途中のため不安定な部分も残っていますが、実際、Azure Stack TP2はスクリプト1つで仮想マシン十数台と物理サーバの設定まで全て完了した状態で起動しますし、TP2からはPaaS環境の追加もスクリプト1つで完了するようになっています。仮想マシンの立ち上げから、その上で動くデータベースの設定やサービス化も含めて自動化されているのです。また、Azure StackはWindows Server 2016のハイパーコンバージドインフラをベースに構成されるため、理論の上では物理サーバも横にどんどん並べていくことで追加できるようになります。

もし、「プライベートクラウドの導入にはすごく時間がかかる」と危惧しているのであれば、まずは従来のモデルを受け止めるAzure Packの導入から検討してみるとよいでしょう。お待ちかねのAzure Stackが登場した際には、クラウドモデルと従来のモデルの2つを受け止めるプライベートクラウド基盤へと進化させればよいのですから。

*　*　*

今回は、クラウド基盤導入における場所とモデルについて解説しました。次回からは、Azure Stackに話を戻して、利用者目線で見るAzure Stack TP2について説明する予定です。お楽しみに。