これに対してImmutable Infrastructureでは、デプロイのたびに新しいインフラを構築するため、既存のサーバの状態によるデプロイの失敗が発生しない。また、サーバの状態管理が不要になるため、作業量を大幅に削減できる。そして、本番環境の状態が不変であるため、開発環境を本番環境に近づけることが容易である。

　デプロイに失敗してもサービスを停止させないようにする「Blue Green Deployment」というデプロイ方式がある。この方式は、Immutable Infrastructureで活用できる。本方式では、現システムが稼働しているインフラとは別に、新システムを稼働させるインフラを新たに構築し、デプロイを行う。新システムの動作検証が完了し次第、ルータやロードバランサの宛先を新システムへ切り替える。もし新システムのデプロイが失敗しても、現システムには影響がないため、安全にシステムを切り替えることができる。

　また、Immutable Infrastructureはシステムのスケーラビリティにも大きく貢献する。デプロイ時に自動でインフラを構築することになるため、サーバをスケールアウトさせるときのサーバ構築作業がほぼ不要になる。これにより、数十台規模のスケールアウトでも非常に小さい作業量で対応できる。そのため、使いたいときに使いたいだけコンピューティングリソースを使うことができる、というクラウドの利点を十分に活用できる。

　しかし、メリットばかりではない。基本的に、Immutable Infrastructureを実現するためには、できるだけインフラ構成を静的にする必要がある。そして、その上で動作するアプリケーションはインフラ構成に依存しない／させないように設計する必要がある。つまり、アプリケーションアーキテクチャが制限されてしまう。

Immutable Infrastructureを実現しているMicrosoft Azureクラウドサービス

　これまでの話を踏まえると、Microsoft Azureを知っている読者であれば、「Microsoft Azure クラウドサービス」がImmutable Infrastructureを実現していることに気付いたのではないだろうか。Microsoftが提供するPaaS（Platform as a Service）であるクラウドサービスは、2010年の「Windows Azure」サービス開始当初から提供されている。つまり、4年前から既にImmutable Infrastructureを実現していることになる。

　ユーザーは、開発したアプリケーションと、インフラ設定（サーバ数、サイズなど）を含めたパッケージを、クラウドサービスへデプロイする。すると、Microsoftが管理するハイパーバイザー（Hyper-V）で、インフラ設定に従ってサーバ（Windows Server）が自動で作成され、作成後、デプロイしたアプリケーションが稼働する。サーバはパッケージをデプロイするたびに作成され、古いサーバは破棄される。

　アプリケーションの開発環境については、Microsoftからエミュレータが提供されているため、本番環境との差異が極めて小さい環境で開発することができる。これにより、環境の差異によるデプロイ失敗の可能性を小さくすることができる。

　デプロイ先としては、運用環境とステージング環境が存在する。運用環境はユーザーへ公開するための環境であり、ステージング環境は公開前に動作確認を行うための環境として利用する。両環境の入れ替えは、「VIPスワップ」という機能を利用する。この機能を利用すると、両環境のVIP（仮想IP）をダウンタイムなしで瞬時に入れ替えることができる。

　サーバのスケールイン／アウトについては、管理ポータルの操作で簡単に行うことができる。また、サーバの負荷や、あらかじめ指定したスケジュールに応じて自動スケールさせることもできる。

　サーバのOSがWindows Serverであるなど、インフラ構成がある程度固定されているため、アプリケーションアーキテクチャに制限はある。しかし、インフラ構成を静的にすることで、インフラを意識しない開発や、サーバの自由自在なスケールを実現している。インフラは稼働率99.95％がサポートされているため、ほぼ心配する必要はない。開発者はコードにだけ集中することができる。これにより、開発の高速化と、システムの品質向上を実現する。

クラウドサービスでの開発

　クラウドサービスとは、名前の通り、複数のアプリケーションがクラウド上で稼働するサービスである。1つのクラウドサービスにつき、「運用」と「ステージング」の2つのデプロイメントを持つ。各デプロイメントは、アプリケーションの実行形態に当たるロールを複数持つ。ロールは「Workerロール」と「Webロール」の2種類が存在する。Workerロールはバッチ処理を行い、WebロールはWebアプリケーション／Web APIを動作させる。各ロールは、アプリケーションの実行サーバに当たるインスタンスを複数持つ。ロールに対する通信は、自動で構築されるロードバランサによって、各インスタンスに振り分けられる。

図1　クラウドサービスの構成

　クラウドサービスへのアプリケーションデプロイは、サービス構成ファイル（.cscfg）とクラウドサービスパッケージファイル（.cspkg）を展開することで実現する。サービス構成ファイルは、インスタンスのOSファミリ、OSバージョン、インスタンス数、アプリケーション設定などを記述したものである。クラウドサービスパッケージファイルは、プログラムのソースコードとサービス定義ファイル（*.csdef）で構成される。サービス定義ファイルは、インスタンスサイズやエンドポイントなどを記述したものである（第3回「使い勝手はどんな感じ？　『Microsoft Azure 仮想マシン』を解説」を参照）。

　クラウドサービスで稼働させるアプリケーションを開発するには、Microsoftから提供されている“Windows Azure SDK”を利用する必要がある。SDKはこのURLからダウンロードすることができる。

　開発言語は.NETとJavaに、WebロールのみであればPHPに対応している。SDKを用いることで、アプリケーションのパッケージングとクラウドサービスへのデプロイが、IDE（Visual Studio、Eclipse）で可能になる。また、デプロイ自体は、管理ポータルでクラウドサービスパッケージとサービス構成ファイルをアップロードすることでも可能である。これにより、開発者からの本番環境へのデプロイを禁止にし、デプロイできるのは検証済みパッケージを受け取った運用管理者のみにする、といったデプロイ管理を厳密に行う運用が可能になる。

　管理ポータルでは、クラウドサービスのパフォーマンス情報の確認や、インスタンス数の変更ができる。インスタンス数については、CPU負荷率や、参照しているキューのメッセージ数、スケジュールに応じた自動スケールを設定できる。

図2　管理ポータルでのインスタンスのスケール設定《クリックで拡大》

　また、インスタンス起動時に実行するスクリプト（スタートアップタスク）を指定することで、OSの設定など、実行環境のカスタマイズができる。OSには、リモートデスクトップ接続でログインすることも可能である。これらにより、クラウドサービスの開発では、ミドルウェア以下の管理が不要である、というPaaSのメリットを享受しながら、実行環境のカスタマイズも可能である。そのため、アプリケーション開発の拡張性も十分持っているといえる。

　クラウドサービスの開発には幾つかの注意点がある。デプロイのたびにインスタンスが再生成されるため、ローカルディスクに存在するファイルが消失してしまう。そのため、アプリケーションのログファイルなどはMicrosoft Azureストレージなどの外部に保存するべきである。

　また、1つのロールにつき、インスタンスは2つ以上の起動が強く推奨されている。1つしか起動していない場合、稼働率99.95％が保証されない。クラウドサービスでは、インスタンスのOSに対して自動的にパッチが適用されるが、その際にインスタンスの再起動が発生する。2つ以上起動している場合は、必ず1つ以上のインスタンスが起動しているように、段階的にパッチが適用されるため、サービスが停止することはない。しかし、1つしか起動していない場合はそれができず、数分程度であるが停止してしまう。サービスの停止が許されないシステムであれば、各ロールのインスタンス数を2つ以上にする必要がある。

クラウドサービスの活用シーン

　クラウドサービスの活用シーンとして、処理要求量が大量かつ動的に変化する分散コンピューティングシステムや、ユーザーアクセス数が予測しづらく、急増する可能性があるキャンペーンサイトなどが挙げられる。

　活用シーンの例として、ユーザーのリクエストに応じて、比較的負荷の高い処理が行われるWebアプリケーションでの活用を紹介する。もしWebアプリケーション側で負荷の高い処理を行うと、ユーザーリクエスト数が突発的に急増した場合にコンピューティングリソースが足りなくなり、レスポンスをさばききれなくなる。最悪、サーバがダウンしてリクエストがロストする可能性がある。

　そこで、クラウドサービスのWebロールおよびWorkerロールを活用する。ユーザーからのリクエスト受付はWebロールに、負荷の高い処理はWorkerロールに行わせるようにする。分離した2つのロールの連携は、Microsoft Azureストレージの「キュー」を用いて行う。

図3　キューを用いたロール間の非同期処

　リクエストを受けたWebロールは、「キュー」にリクエスト情報を含めたメッセージをエンキューする。エンキューされたメッセージは、バックグラウンドで稼働するWorkerロールでデキューして処理する。「キュー」を使うことにより、処理の非同期化を実現している。

　もしリクエスト数が突発的に急増しても、Webロールでは負荷の高い処理を行わないため、ダウンせずさばき切ることができる。リクエストは、既定で3本のディスクに複製して管理されている「キュー」に投入しているため、ロストする心配がない。

　Workerロールはたまっているリクエスト数に応じて、自動的にスケールイン／アウトさせることができる。そのため、無駄なコストを掛けず、効率的に処理することが可能だ。また、Workerロールでの処理が成功した場合にのみ、リクエストをキューから削除できる。よって、万が一処理に失敗した場合も、リクエストがロストすることはない。

　このアーキテクチャは、処理データをロストすることが許されないエンタープライズシステムで活用することができる。

Webサイトとの使い分け

　本連載の第2回「IaaSとの違いは？　Microsoft AzureのWebサイト実行基盤を解説」で説明した通り、「Microsoft Azure Webサイト」はクラウドサービスと同じPaaSである。そして、このWebサイトとクラウドサービスのWebロールは、“Webサイト／アプリケーション実行基盤”として用途が同じである。この2つの違いは、アプリケーションアーキテクチャに対する制限の違いである。

　クラウドサービスがデプロイ時にサーバを新規作成するのに対して、WebサイトはMicrosoftが提供する既存のWebサーバ（IIS）にサイトを新規作成する。クラウドサービスではスタートアップタスクなどでOSやWebサーバ（IIS）の設定を変更することが可能であるが、WebサイトではOSどころか、Webサーバの設定をすることさえ困難である。

　しかし、クラウドサービスがデプロイに5～10分程度要するのに対して、Webサイトはサーバを新規作成する手間がないため、数秒でデプロイすることができる。また、サイトのスケールイン／アウトも数秒で完了する。つまりWebサイトは、より徹底して手軽さや高速なスケール能力を追求したPaaSといえる。

　どちらのサービスを用いるかは、開発するWebシステムに応じて決定する必要がある。OSやミドルウェアの拡張を要する高度な要件のWebシステムであればクラウドサービスを、ミドルウェア以下に依存する必要のないWebシステムであればWebサイトを用いるのが良いだろう。

クラウドのメリットを十分に活用できるPaaS

　もしインフラに依存せざるを得ないWebシステムであれば、IaaS（Infrastructure as a Service）である仮想マシンを利用する必要がある。

　しかしその場合、インフラ構築／管理作業が発生し、PaaSと比べるとサーバのスケールイン／アウトを行う際の作業が大きく発生し、自由自在にスケールすることが困難になってしまう。

　使いたいときに使いたいだけコンピューティングリソースを使うことができる、というクラウドのメリットを十分に活用したいのであれば、インフラに依存しないWebシステムを設計して、PaaSを利用することを強くお勧めする。

図4　Microsoft AzureにおけるWebサイト実行環境の選択

日山雅之（ひやま まさゆき）

株式会社FIXER Enterprise Cloud Unit クラウドエンジニア

学生時代に地元のITベンチャー企業にてプログラミングのアルバイトを行い、そこでプログラミングの奥深さに魅了され、スーパープログラマを目指す。大学院を卒業後、現日立システムズに入社し、App Bridgeシリーズの開発に携わる。その後、プログラミング技術をより高めるべく株式会社FIXERに入社。Microsoft Azureの虜になる。マイクロソフト認定ソリューションデベロッパー（WebApplication）およびAWS認定ソリューションアーキテクト（アソシエイト）。

【FIXER公式サイト】http://www.fixer.co.jp/

【cloud.config公式サイト】http://www.cloud-config.jp/

【Blog】http://www.cloud-config.jp/category/programmer_hiyama