May 2009

Volume 24 Number 05

クラウド コンピューティング - Windows Azure を使用して、高い可用性、拡張性、およびコンピュータ処理能力を実現するためのパターン

Joshy Joseph | May 2009

コードは MSDN コード ギャラリーからダウンロードできます。
オンラインでのコードの参照

この記事は、Windows Azure のプレリリース版を基にしています。記載されている情報は変更される可能性があります。

目次

クラウド コンピューティング
Windows Azure の実装
クラウド アプリケーションの種類とパターン
実際の例
アプリケーションの設計と開発
サービスを配置する
管理
まとめ

この 10 年間で、分散システムの目標は、実装、スケーラブルなホスティング モデル、サービス指向、サブスクリプション ベースのコンピューティング、および増加する社会的な連携からインターフェイスを分離することへと変化しました。現在、社内アプリケーションに接続可能な、インターネットでホストされる分散アプリケーション (一般に "Software plus Services" (S+S) と呼ばれる) が普及しつつあります。企業は、ハードウェア、ソフトウェア、信頼性、および拡張性に関する懸念を軽減するために、サードパーティがホストするデータセンターを利用しています。これらは、拡張性、設備投資の削減、信頼性の向上を実現する相互運用可能なアプリケーションの開発に役立つアーキテクチャの新しいトレンドの一部です。クラウド コンピューティングには、こうした多くの利点があります。

クラウド コンピューティング プラットフォームを利用すると、インターネットにアクセス可能な仮想環境でアプリケーションをホストできます。必要なハードウェア、ソフトウェア、ネットワーク、ストレージ容量、セキュリティ、および信頼性が提供されるため、社内でハードウェアおよびソフトウェアを購入および管理する負担が大幅に軽減されます。クラウドでは、以前と同様にアプリケーションを開発、配置、および管理し、これらのサービスをオンプレミス アプリケーションに統合できます。使用する時間、リソース、および容量に対して支払うだけで、ビジネス ニーズの変化に応じてスケールアップできます。

この記事では、一般的なクラウド プラットフォーム アーキテクチャ、よく使用されるいくつかのアーキテクチャ パターン、およびマイクロソフトが提供する Windows Azure でそれらを実装する方法について説明します。

クラウド コンピューティング

一般的なクラウド コンピューティング プラットフォームのアーキテクチャを図 1 に示します。

図 1 クラウド プラットフォームの階層型アーキテクチャ (クリックすると拡大画像が表示されます)

このモデルでは、それぞれの層によって、その下位の層が抽象化され、その上位の層の基盤となるインターフェイスが公開されます。層の間に強い依存関係はなく、それぞれの層は他の層のサービスを使用して、構成可能なアーキテクチャやプラグ アンド プレイ アーキテクチャを提供します。それぞれの層は、必要に応じて水平方向に拡張できます。

ご覧のとおり、クラウド プラットフォームはさまざまなサブシステムで構成されています。では、1 つずつ見ていきましょう。

ホスティング プラットフォーム: ホスティング プラットフォームでは、物理資産、仮想資産、およびソフトウェア資産が提供されます。これらの資産には、物理コンピュータ、オペレーティング システム、ネットワーク システム、ストレージ システム、電源管理、および仮想化ソフトウェアが含まれます。ベアメタルなどの運用リソースは、上位層に対して、仮想リソースとして抽象化されます。

クラウド インフラストラクチャ サービス: この層の最も重要な役割は、ホスティング プラットフォームを一連の仮想リソースとして抽象化し、拡張性要件と可用性要件に基づいてそれらのリソースを管理することです。基本的に、この層ではコンピューティング、ストレージ、およびネットワークという 3 種類の抽象リソースが提供され、これらの抽象リソースのアクセスおよび管理を行うための一連の API が公開されます。そのため、基になるハードウェアとソフトウェアの詳細を意識せずに、基になる物理リソースにアクセスしたり、構成を通じてこれらのシステムを効率的に制御したりできます。このサブシステムによって提供されるサービスは、一般に IaaS (Infrastructure as a Service) と呼ばれています。

クラウド プラットフォーム サービス: クラウド コンピューティング向けのソフトウェアの開発と管理は複雑です。特に、クラウドのサービスとオンプレミス ソフトウェアを統合する場合は、非常に複雑になります。クラウド プラットフォーム サービスでは、そうした統合を支援する機能がサービスとして公開されます。たとえば、Azure Services Platform には、検出およびアクセスを支援する Microsoft .NET Service Bus や、ロールベースおよびルールベースのクレームの変換およびマッピングを支援する Microsoft .NET Access Control Service があります。利用できるプラットフォーム サービスは、クラウド プロバイダによって異なる場合があります。この層で提供されるサービスは、PaaS (Platform as a Service) と呼ばれています。

クラウド アプリケーション: この層には、クラウド コンピューティング向けに構築されたアプリケーションが格納されます。これらのアプリケーションは、エンド ユーザー用の Web インターフェイスおよび Web サービスを公開し、マルチテナント ホスティング モデルを実現します。機能には、異種システムの接続や、クラウド ストレージ インフラストラクチャを活用したドキュメントの格納などがあります。これらのサービスは、SaaS (Software as a Service) と呼ばれています。

セキュリティ サービス: セキュリティ サービスにより、トークンのプロビジョニング、ID フェデレーション、およびクレームの変換を確実に行うことができます。これらのサービスは、相互運用性を強化するために、オープン標準の WS-Security、WS-Trust、WS-Federation、SAML プロトコル、および OpenID に基づいて構築されます。

管理サービス: 管理インターフェイスは上記のすべての層に関係します。ホスティング プラットフォームでは、拡張性と可用性を自動的に管理するために、管理インターフェイスとエージェントを利用します。クラウドのホストおよび管理はデータセンターで行われますが、アプリケーションの管理と配置後の構成の管理、サービスの使用状況に関する分析、および企業管理システムの接続を簡単に行える機能を顧客が必要としている場合があります。

ツール: ツールは、アプリケーションを構築およびテストし、クラウドに配置するために使用します。これらのツールには、既存のツールの拡張機能 (たとえば、Visual Studio Tools for Windows Azure) や特定のクラウド プロバイダによってホストされるツールなどがあります。

クラウド コンピューティングのユーザーおよびプロバイダ: クラウド コンピューティングのユーザーは、クラウド プラットフォーム プロバイダ、クラウド コンシューマ、およびエンド ユーザーという 3 つのカテゴリに分けられます。クラウド プラットフォーム プロバイダは、ホスティング プラットフォームとクラウド インフラストラクチャ サービスを提供します。クラウド コンシューマはクラウド プラットフォームを利用して、エンド ユーザーが使用するアプリケーションおよびサービスを開発し、拡張性、可用性、およびセキュリティの各要件に応じてアプリケーションを構成します。エンド ユーザーは、クラウド コンシューマから提供されるサービスを利用します。クラウド コンピューティングのユーザーは、人間、組織、またはコンピュータです。ユーザーに対するホスティングは場所を選びません。

このコンテキストでは、Azure がクラウド プラットフォームを提供し、クラウド コンシューマ (企業または統合クラウド ソリューションを構築する ISV) がそのプラットフォームを利用してアプリケーションを構築します。たとえば、データ同期プラットフォームの Live Mesh では、Azure Services Platform および Windows Azure を利用して、エンド ユーザー向けの S+S サービスを開発およびホストします。

図 2 は、図 1 の階層型アーキテクチャによって Azure Services Platform を表しています。このプラットフォームでは、アプリケーション開発者に一連のサービスが提供されます。これらのサービスは、クラウドで実行するアプリケーションとローカル システムで実行するアプリケーションの両方で使用できます。クラウド用のオペレーティング システムである Windows Azure は、マイクロソフトのクラウド プラットフォーム環境の基盤です。図 2 に示すように、Azure Services Platform では、SQL Data Services、.NET Services、および Live Services という一連の共有サービスが提供されます。これらのサービスは個別に、または一緒に使用できます。また、マイクロソフトは、Exchange Online、SharePoint Online、CRM Online などの完成したさまざまなクラウド アプリケーションを提供しています。ただし、ここでは、Windows Azure オペレーティング システムと関連するパターンのみに焦点を当てて説明します。

図 2 階層型アーキテクチャにマッピングした Azure Services Platform

Windows Azure の実装

Windows Azure は、マイクロソフトのデータセンターから提供される Web アプリケーションおよびサービスを、インターネット上でホスト、拡張、および管理するためのオンデマンドのコンピューティング機能およびストレージ機能を提供します。

Windows Azure は、クラウド サービスのコンシューマが必要とする機能を備えています。たとえば、物理ハードウェア リソースは抽象化され、クラウド アプリケーションで利用できるコンピューティング リソースとして公開されます。物理ストレージはストレージ リソースで抽象化され、明確に定義されたストレージ インターフェイスを通じて公開されます。Windows の共通ファブリックによって、ハードウェアおよびソフトウェアの物理プラットフォームが抽象化され、仮想化されたコンピューティング リソースおよびストレージ リソースとして公開されます。また、アプリケーションの各インスタンスは自動的に管理され、その拡張性と可用性が監視されます。たとえば、あるインスタンスのアプリケーションが停止した場合、ファブリック コントローラ (図 3 を参照) が通知を受け取り、別の仮想マシン (VM) の別のインスタンスがインスタンス化されるため、エンド ユーザーへの影響は最小限に抑えられます。仮想化が大量に行われるため、コードを記述する際には、アプリケーションをホストするコンピュータの状態については一切仮定しないように注意する必要があります。Windows Azure では、サービスを新しい VM に簡単に移動することができます。Windows Azure では、モデル駆動型のサービス管理設計を採用しています。Azure ファブリック コントローラを使用して、宣言型サービスの仕様を利用可能なリソースにマッピングし、サービスのライフサイクルを管理します。

図 3 Windows Azure とロール

既定では、.NET で開発されたほとんどのアプリケーションを Azure でホストできますが、部分的に信頼されたモデル、データのストレージとアクセス、およびアプリケーション間の通信においていくつかの制限が発生します。機能が豊富な開発者用の SDK およびプログラミング ツールを使用することで、Azure プラットフォームに対応させることができます。

現時点では、Visual Studio でサポートされているツールを使用することで、.NET アプリケーション、ASP.NET アプリケーション、および WCF ベースの Web サービスを作成できます。

現在、Windows Azure には、Web ロールおよび Worker ロールという 2 つの処理メソッドが用意されています (図 3 を参照)。各ロールは別々の VM 上で実行され、エージェントを通じて Azure ファブリックと通信します。エージェントは、VM の使用状況、アプリケーションの状態、ログ、リソースの使用状況、例外、およびエラー状態を含む、リソース指標とノード指標を収集します。各 VM が 1 つの物理ホスト上または Windows 2008 のハイパーバイザ VM 上で実行される場合があることに注意してください。具体的なランタイム ホスト構成は、サービス レベル契約およびビジネス要件や技術要件に応じて、Windows Azure によって決定されます。Web ロールは、対話型 Web アプリケーションをホストし、受信接続および送信接続 (要求/応答パターン) を提供します。高可用性を実現するために、受信呼び出しは、Azure によって提供されるロード バランサを通じてルーティングされます。既におわかりのように、そのためには、ファブリックが要求をクラスタ内の任意の Web ロールにルーティングできるように、各 Web ロールのインスタンスがステートレスである必要があります。

Worker ロールは、バックグラウンドで .NET アプリケーションを実行する特殊なアプリケーションです。これらのアプリケーションは、外部アプリケーションからの受信接続を受け付けません。しかし、外部サービスにメッセージを送信することはできます。Web ロールと対話している間、Worker ロールは Windows Azure Queue ストレージ サービスを使用してメッセージを送受信します。もう 1 つ興味深い点として、ロールのスケールアウト機能があります。アプリケーションを配置する管理者は、構成に必要なロールのインスタンスの数を指定できます。Azure ファブリックは、システムのスケールアウト要件に応じて、これらのインスタンスを実行するかどうかを決定します。つまり、Windows Azure では、配置およびエラー処理は常時、オンデマンドで実行されます。

ここまでは、クラウド プラットフォームについての一般的な概念と Windows Azure の具体的な機能について説明してきました。次は、クラウド プラットフォーム向けのアプリケーションを開発する際によく使用する基本的なクラウド アプリケーションの種類、アーキテクチャ パターン、およびベスト プラクティスを紹介します。

クラウド アプリケーションの種類とパターン

クラウド プラットフォームの選択およびクラウド サービスとアプリケーションの実装に役立つさまざまなアーキテクチャ、設計パターン、およびベスト プラクティスがあります。一般的に、これらのパターンは、コンピューティング、ストレージ、通信、および管理という 4 つのカテゴリに分類されます。

コンピューティング パターン: 使用するアプリケーションの種類が決まったら、適切なコンピューティング パターンを選択します。既に説明したように、Web ロールは対話型アプリケーション パターンの構築に使用されます。一方、Worker ロールはバックグラウンド タスクおよびスケジューラ タスクの構築に適しています。場合によっては、両方の機能が必要になります。コンピューティング タスクを計画する場合、大量のデータ移動を避けるような方法でそれらのタスクを実行することが重要になります。

ストレージ パターン: クラウド ストレージはリモート ストレージを提供し、ユーザーから見えないところでストレージ メディアを抽象化します。この設計は、多様なアプリケーション要件をサポートするのに十分な柔軟性を備えています。Azure には、テーブル ストレージとブロブ ストレージという 2 つのクラウド ストレージのパターンがあります。テーブル ストレージ パターンの場合、アプリケーションはテーブル構造に従ってキー/値ペアを格納します。一方、ブロブ ストレージ パターンを使用すると、あらゆるデータを格納できます。

通信パターン: これらのパターンでは、メッセージ交換を扱います。Azure テクノロジでは、Windows Communication Foundation (WCF) と REST API を利用して、Web サービス通信を行います。通信パターンを実装する際は、部分的に信頼されたモデルとアプリケーションのステートレスな性質を考慮する必要があります。

管理パターン: 管理パターンでは、サービス管理の中心的な側面となるサービス配置とサービス レベル管理の 2 つを区別しています。配置パターンでは、サービスの定義、構成、および監視を扱います。サービス レベル管理パターンでは、サービス レベル管理および定期的な運用保守を扱います。

次は、クラウド アプリケーションの種類について詳しく説明します。ここでは、クラウド アプリケーションの種類を、それぞれが扱うシナリオの種類に基づいて、3 つのカテゴリに分類します。最初のカテゴリは、Web アプリケーションです。これには、ホストされる従来の Web アプリケーションだけでなく、新たに登場した、2 つ以上のデータ ソースおよびサービスを利用できるように構成されたアプリケーションも含まれます。これらのアプリケーションには、自動的にスケールアウトおよびスケール ダウンできる機能が必要です。Facebook などのアプリケーションは、その良い例です。このようなシナリオに当てはまる組織には、インフラストラクチャにほとんど資本を使わずに、増大し続ける要求に対応する必要がある新興企業があります。

次は、分析アプリケーションです。これらのアプリケーションの主要な機能は、プロセッサを集中的に使用する操作とデータ マイニングを実行することです。同じデータを何度も使用することが多いため、一度に利用できるストレージおよびプロセッサの容量が非常に大きいことが要求されます。しかし、そうした膨大な処理能力に対して、毎日 24 時間分を支払い続ける必要はありません。そこにクラウド サービスの魅力があります。

最後は、並列コンピューティング アプリケーションです。これらのアプリケーションでは、大規模なプロジェクトを短時間で実行できるように、複数のタスクを並列に実行する必要があります。この場合も、クラウド コンピューティングは、大量の処理能力を使用したときにだけ支払う、コスト効率に優れたソリューションを提供します。

すべてのアプリケーションが、クラウド プラットフォームでの実行に適しているわけではありません。明らかな制限要因としては、データ セキュリティ、クラウド プロバイダによるロックインの可能性、通信用のオープン インターフェイス、信頼モデルの制限、クラウドとの間のデータ移動の効率、クラウド プラットフォームの外部にある既存のサービスとの統合、および法的な問題とプライバシーの問題があります。図 4 は、クラウド コンピューティングに適したシナリオの一部を示しています。また、図 5 は、適切なパターン、シナリオ、および機能を示しています。

Windows Azure の Web ロールは対話型 Web アプリケーションの実行に適しており、Worker ロールはバックグラウンド アプリケーションの実行に適しています。データは、Azure のブロブ ストレージ サービスとテーブル ストレージ サービスに格納されます。ロール間の通信は Queue サービスを通じて行われ、メッセージは非同期で交換されます。このプラットフォームでは、HTTP と WS* の基本バインドを使用した WCF ベースの Web サービスおよびクライアントがサポートされています。ストレージ サービスは、他のアプリケーションおよびクラウド プロバイダが利用しやすいように、REST スタイルのインターフェイスを通じて公開されます。

ご存知のように、パターンを使用することで、ソフトウェア開発時によく発生する問題に柔軟に対処できます。次は、上記のアプリケーションの種類に対応する一般的なパターンのカテゴリを紹介します。

各パターンについて詳しく説明する代わりに、広範な問題領域と関連するパターンのカテゴリに重点を置き、Azure 開発のコンテキストでこれらのパターンを実装する方法を紹介します。

実際の例

これらの概念を理解するのに役立つシナリオを紹介します。ISV である Fabrikam は、クラウドでホストされるデジタル資産管理 Web アプリケーションを開発しようと考えています。このアプリケーションを使用すると、エンド ユーザーはクラウドにデジタル画像を保存できます。送信した画像をプレビューしたり、タグを付けたり、注釈として位置情報を追加したりもできます。また、ユーザー自身のデスクトップ アプリケーションを使用して、ストレージに格納されているこれらの画像に直接アクセスすることもできます。図 6 に、Fabrikam が公開するサービスの構造的なビューの概要を示します。図に示すように、Fabrikam は、エンド ユーザーがデジタル資産を管理できるように Web アプリケーションと Web サービスを公開します。これらのサービスは、Windows Azure のブロブ サービス上に実装された資産ストアからデジタル資産の格納と取得を行います。また、タグ付け、サムネイルの生成などのタスクを実行するためにバックグラウンド プロセッサを実装します。

図 6 Windows Azure でホストされる Fabrikam のアプリケーション

それでは、こうしたアプリケーションを設計、開発し、Azure Services Platform に配置する方法について見ていきましょう。ここからは、Windows Azure の中核となる概念と利用できる機能について説明します。コードとドキュメントをダウンロードすると、シナリオ全体が Windows Azure でどのように実装およびホストされるかを確認できます。

アプリケーションの設計と開発

まず、アプリケーションのシナリオを理解し、適切なパターン、ベスト プラクティス、およびプログラミング モデルを選択します。その際に、Windows Azure を対象にしたアプリケーションとワークロードの種類を明確にします。また、アプリケーション間のメッセージングとデータ ストレージ パターンを確認します。ここでは、Fabrikam がデジタル資産からメタデータを生成するために、スケールアウト要件を備えた対話型 Web アプリケーションとバックグラウンド プロセッサを構築すると仮定します。このシナリオにはそれぞれ、Azure の Web ロールと Worker ロールが必要です。また、Fabrikam は、デジタル資産とメタデータを管理するためのブロブ ストレージ、資産を公開するためのサービス インターフェイス、および通信のためのメッセージング パターンを必要としています。

開発を容易にするために、Windows Azure SDK には、ローカル コンピュータ上で Windows Azure をシミュレートする開発環境が用意されています。この環境を使用して、オフラインでの開発およびデバッグが可能です。SDK では、Web ロールと Worker ロール、ストレージ、Visual Studio テンプレート、パッケージ化ツール、ロール インスタンスの表示と管理、および F5 機能を有効にする Visual Studio アドインがサポートされています。SDK は、MS ダウンロード センターからダウンロードできます。

まず、Windows Azure Tools for Microsoft Visual Studio を使用して、クラウド サービス プロジェクト テンプレートを使用した新しいプロジェクトを作成します。必要なユーザー インターフェイス、アプリケーション ロジック、および入力処理を Web アプリケーションに追加できます。また、既存の ASP.NET Web アプリケーションから作成することもできます。アプリケーションは部分的な信頼で実行されるため、この制限に反する API を呼び出さないようにしてください。この制限の詳細については、「Windows Azure SDK の信頼ポリシーのリファレンス」を参照してください。

次に、Microsoft.ServiceHosting.ServiceRuntime アセンブリをインポートし、以下に示すように、それぞれの API を使用して、ログの記録、ローカル環境設定の読み取り、およびサービス定義ファイルからのアプリケーション構成セクションの読み取りを有効にします。

 // Writing log information
 RoleManager.WriteLog ("Information", "message to show in the log file"); 
 // Getting service configuration information 
 RoleManager.GetConfigurationSetting("MyConfigSection"); 

// Getting local environment; code snippet below shows getting a pointer
//to a local file 
ILocalResource resource = RoleManager.GetLocalResource(    "ComputeLocalStorage")

なお、プログラミング上のベスト プラクティスは、上記のログ記録とリソース アクセスのコードを、Microsoft Enterprise Library のアプリケーション ブロックなど再利用可能なアプリケーション ブロック (Logging ブロックおよび Configuration ブロック) に置き換えることです。Windows Azure のログ記録と構成管理を行う特殊なプロバイダを実装し、それらをランタイムに接続することができます。これらのベスト プラクティスに従うと、プラットフォーム固有の API からアプリケーションが切り離され、オンプレミス環境とクラウド環境間の再利用性が向上します。

サポートされる Azure のストレージ パターンを利用するために、アプリケーションのストレージ要件を書き換える必要があります。これについては、後で説明します。

続いて、プロジェクトに Worker ロール プロジェクトを追加し、WorkRole.cs を開きます。このファイルには、RoleEntryPoint クラスから派生する WorkerRole という名前のクラスが含まれています。このクラスによって、Worker ロール サービスの初期化、開始、および停止を管理するメソッドおよびサービスの状態を監視するメソッドが提供されています。

通常、この手順では、図 7 に示すように、2 つのメソッドをオーバーライドします。

図 7 WorkerRole

public class WorkerRole : RoleEntryPoint
{
  public override void Start()
  {
      RoleManager.WriteToLog("Information", "Generating metadata from digital assets");

      while (true)
      { 
            RoleManager.WriteToLog("Information", "background task is executing thumbnail extraction");
            Thread.Sleep (1000);  
      }
  }

  public override RoleStatus GetHealthStatus()
  {
            return RoleStatus.Healthy;
  }
}

ここで、F5 キーを押して、ローカルの開発ファブリックでアプリケーションを実行します。Web ロールと Worker ロールのコンソールのインスタンスに書き込まれたログを確認します。

次に、ブロブ ストアを構成し、Web ロールからアクセスします。

まず、ブロブ ストレージのアカウント情報をセットアップする必要があります。次のパラメータを指定します。

AccountName: Windows Azure のアカウント名を指定します。

AccountSharedKey: Windows Azure のストレージに対して行われる要求の認証に使用するキーを指定します。要求を認証するには、要求を行っているアカウントのキーを使用して、要求に署名する必要があります。

BlobStorageEndpoint: ブロブ ストレージ サービスのベース URI を指定します。

ContainerName: このアプリケーションで画像を保存するために使用するブロブ コンテナの名前を指定します。

たとえば、次の構成設定を見てみましょう。

  <ConfigurationSettings>
   <Setting name="AccountName" value="fabrikamAccount" />
   <Setting name="AccountSharedKey" value="Eby111M02xNOcqFlqUwJPLlmEtlCD
   XJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBekso45Gw==" />
   <Setting name="BlobStorageEndpoint" value="http://127.0.0.1:10000"/>
   <Setting name="ContainerName" value="fabrikamImagegallery"/>
  </ConfigurationSettings>

ブロブ ストレージの REST API によって公開される 2 つのリソースは、コンテナとブロブです。コンテナはブロブのセットであり、各ブロブはコンテナに属しています。ブロブは、REST API での定義に従って、PUT 操作を使用して書き込まれます。これらの API を使用して、fabrikamImagegallery/images、fabrikamImagegallery/documents などの、資産を整理するための階層型名前空間を作成できます (fabrikamImagegallery はコンテナの名前で、images はブロブの名前を表しています)。効率的に管理するために、各ブロブを構築するブロックの最大サイズを 4 MB にする必要があることに注意してください。

REST API はかなり扱いにくいため、SDK には、REST 呼び出しを抽象化して、BlobContainer クラスおよび StorageAccountInfo クラスを通じて既知のアクセス パターンを公開できるサンプル ライブラリが付属しています。

図 8 に、ブロブ ストレージを使用する方法を示します。

図 8 ブロブ ストレージの使用

BlobStorage blobStorage = BlobStorage.Create(StorageAccountInfo.GetDefaultBlobStorageAccountFromConfiguration());

BlobContainer newContainer = blobStorage.GetBlobContainer("ContainerName");

newContainer.CreateContainer(null, ContainerAccessControl.Public);

this.container.ListBlobs(String.Empty, false);

BlobProperties properties = new 
 BlobProperties(string.Format(CultureInfo.InvariantCulture, "image_{0}", "idenitifier1"));

NameValueCollection metadata = new NameValueCollection();
metadata["Id"] = id;
metadata["Filename"] = "filename";
metadata["Tags"] = "Image";

properties.Metadata = metadata;

this.container.CreateBlob(properties, imageBlob, true);

次は、Web ロールから Worker ロールにメッセージを送信する Queue ストレージ サービスを作成します。Windows Azure Queue サービスは、サービス内およびサービス間の信頼性の高い、永続的なメッセージングを提供します。Queue サービスの REST API によって、キューとメッセージの 2 つのリソースが公開されます。一意の名前を使用して識別されるキューは、数に制限なく作成できます。ただし、メッセージの最大サイズは 8 KB に制限されています。読んだメッセージの削除は自分で行います。削除しないと、メッセージは指定された時間キューに残ったままになります。

図 9 に、Worker ロールの Queue ストレージとメッセージにアクセスする方法を示します。

図 9 Queue ストレージの操作

public class WorkerRole : RoleEntryPoint
{
        public override void Start()
        {
            Uri baseUri = new               
                 Uri(RoleManager.GetConfigurationSetting("QueueEndpoint"));
            string accountName = RoleManager.GetConfigurationSetting("AccountName");
            string accountKey =  
                RoleManager.GetConfigurationSetting("AccountSharedKey");

           StorageAccountInfo account = new StorageAccountInfo(
           baseUri,
                null,
                accountName,
                accountKey);

            QueueStorage service = QueueStorage.Create(account);
            MessageQueue queue = service.GetQueue("fabrikamimageprocessingqueue");

            while (true)
            {
                Thread.Sleep(10000);
                if (queue.DoesQueueExist())
                {
                   Message msg = queue.GetMessage();
                   if (msg != null)
                   {

                      queue.DeleteMessage(msg);
                   }
                }
            }
        }
….
}

それでは、F5 キーを押して、ローカルの開発ファブリックでこのアプリケーションを試してみましょう。Web ロールが入力を受け取り、Queue を通じて Worker ロールにメッセージが送信されることが確認できると思います。この時点で、必要なすべての開発アクティビティが完了し、アプリケーションを Azure に公開する準備が整いました。

サービスを配置する

Windows Azure へのサービスの配置は比較的簡単です。ただし、最初に、サービス定義ファイル (アプリケーションの構成情報) とサービス構成ファイル (環境要件) に含める情報、アプリケーションをパッケージ化する方法、およびパッケージをクラウドに格納した後に Azure に配置する方法を決定し、既存のツールでパッケージを作成およびアップロードできるかどうかを判断する必要があります。

ここからは、サンプル アプリケーションでこれらの要件に対処する方法について説明します。

Fabrikam ISV では、開発、配置、および運用の各担当者がクラウド アプリケーションを管理します。開発者は、アプリケーションの情報を格納するサービス定義ファイルを作成します。サービス定義ファイル (.csdef) では、サービスに対して利用可能なロールを定義し、サービス エンドポイントを指定し、サービスの構成パラメータを確立します。サービスの配置後は、サービス定義の設定を変更できません。このファイルは、パッケージ化処理時にサービス パッケージ ファイルに組み込まれます。

また、開発者は、ローカルでのデバッグや Azure ステージング配置のために、サービス構成ファイル (必要なインスタンスの数と Azure のアカウント情報を指定する) を作成します。サービス構成ファイル (.cscfg) では、実行サービスの内の 1 つまたは複数のロール インスタンスの構成を設定するための値を指定します。運用スタッフは、サービスを再配置することなく、これらのサービス構成設定を動的に変更できます。サービス構成ファイルはサービスと一緒にパッケージ化されませんが、別のファイルとして Windows Azure ファブリックにアップロードされます。

配置スタッフは、運用環境に配置する前に、Azure のアカウント固有の情報と運用要件 (実稼働に必要なインスタンスの数) に基づいて、サービス構成ファイルを更新します。

開発者または配置スタッフは、Visual Studio ツールまたは Azure SDK に付属している CSPack ツールを使用して、Azure の配置パッケージを作成します。

配置パッケージを Azure のブロブ ストレージに格納し、Azure クラウド プラットフォームに配置する際に取得することができます。

サービス パッケージ ファイル (.cspkg) は、1 つのアーティファクトにパッケージ化されたロールの定義とロールに関連するすべてのファイル (バイナリ、画像、および構成) を含む zip 形式のファイルです。Visual Studio または CSPack ツールを使用して、これらのパッケージを生成できます。Visual Studio を使用して開発ファブリック上で実行すると、作成されるパッケージの拡張子は .csx になります。ただし、"発行" 機能を使用すると、.csx ファイルを暗号化および zip 圧縮した .cspkg ファイルが作成されます。この暗号化および zip 圧縮されたファイル (拡張子は .cspkg) をクラウドにアップロードします。

次は、サービス構成ファイル (.cscfg) とパッケージ ファイル (.cspkg) を Windows Azure にアップロードします。それには、まず、Azure Services Developer Portal から Windows Azure のコンピューティング アカウントとストレージ アカウントを取得する必要があります。これらのアカウントを取得したら、Azure Services Developer Portal からクラウドにパッケージを配置できます。ファイルをアップロードすると、Windows Azure ファブリックでサービスをテストするときに使用する内部のステージング URL が提供されます。実稼動に移行するには、運用 URL を取得します。

管理

管理機能は、クラウド環境に配置されたアプリケーションの管理、ガバナンス、および運用面に対応しています。クラウド プラットフォームを利用したアプリケーションのホスティングは、サービス レベル管理、リソースの管理、サービスのプロビジョニング、セキュリティ/信頼モデル、および監視が適切に制御されている環境にサービスが配置されることを前提にしています。サービス管理に必要な、重要な機能をよく理解する必要があります。それらは、次のような機能です。

• 適切なインストルメンテーションを含めることで、運用しやすい実装のベストプラクティスを使用して、サービスを配置する。
• クラウド アプリケーションとサービスの状態と可用性を監視する。
• サービスの使用状況、パフォーマンス、および請求に関する指標とレポートを収集する。
• サービスのプロビジョニングを自動化し、サービス構成を更新する。

Windows Azure は、エージェントを使用して、各 VM のインスタンスのエラー状態を監視し、エラー、パフォーマンス測定、および使用状況に関する指標を収集します。

Azure ファブリックによって、プロビジョニングと管理面が自動化され、ユーザーによる入力は制限されます。人間とプロセスは間違いの元です。この自動化によって、人的エラーを回避できます。Windows Azure では、アプリケーションは部分的に信頼されたサンドボックスで実行され、要求は負荷分散され、エラー状態は自動的に管理されます。

開発者は、サービスの運用動作をよく理解する必要があります。これらの動作は、サービス定義とサービス構成のモデルの一部としてドキュメント化され、自動化を容易にするためにクラウド プラットフォームに伝達されます。

また、次のベスト プラクティスに従う必要があります。

コードにログ記録の情報を追加する

RoleManager.WriteLog ("Information", "message to show in the log file"); 

• GetHeatlthStatus メソッドをオーバーライドする

public override RoleStatus GetHealthStatus()
{
      // return the health status of worker role.
      return RoleStatus.Healthy;
 }

• アプリケーションの状態を分析するためにログ ファイルを取得する

Windows Azure のサービス管理

Windows Azure では、モデルを使用して開発者と配置スタッフから目的の構成情報を収集する、モデル駆動型のアプローチに従ってサービス管理が行われます。Azure ファブリックでは、これらのモデルを使用して、構成の動的な更新、自動化されたエラー処理、サービスの監視などの、サービスのライフサイクルを管理します。Windows Azure では、単一障害点 (ハードウェアまたはソフトウェア) を回避するために、複数のコンピューティング ノードまたはコンピュータ ラック間でそれぞれのロールが分離されている障害ドメインを導入しています。また、構成を通じてアップグレード ドメインを要求することで、更新中 (サービスのロール フォワードまたはロール バックワード中) にサービスが確実に実行されるようにします。

Azure ポータルで、[Configure] (構成) オプションと [Copy Log] (ログのコピー) オプションを使用して、ログ メッセージをブロブ ストレージにコピーする必要があります。

コピーが完了したら、先ほど説明したプログラミング モデルを使用して、ブロブ ストレージからログにアクセスできます。

将来的には、Windows Azure により、アクセスと制御の管理作業および運用作業に対して管理インターフェイスが公開されます。そうなると、オンプレミスのサービス管理ツールを使用して、クラウド アプリケーションを監視および管理できるようになります。

結論

クラウド コンピューティングの発展を成功に導くためには、クラウド コンピューティングのアーキテクチャ モデルを理解し、適切なパターンを見つけ、プログラミング モデルを決定し、管理を自動化することが不可欠です。Windows Azure は、開発者が Web アプリケーションと Web サービスをすばやく簡単に作成、配置、管理、および配布できるよう、開発者を念頭に置いて設計されています。

開発者は、クラウド アプリケーションを最も効果的に開発するために役立つ中心的なパターンのセットを蓄積する必要があります。また、繰り返し使用される問題解決のソリューションやその他の新しいパターンの情報を収集および共有することを心がけてください。弊社のソリューションおよび製品は、この方法により、クラウド コンピューティングの中核的なパターンを標準でサポートできるようにしています。

この記事について有益なフィードバックを寄せていただいた Steve Marx、Jason Hogg、David Hill、Fred Chong、Eugenio Pace、および Nataraja Koduru に感謝します。

Joshy Joseph は、Microsoft Services Managed Solutions グループの主席アーキテクトです。主な専門分野は、分散コンピューティング、グリッド コンピューティング、および Web サービスです。『Grid Computing』(Prentice Hall、2004 年) の著者であり、35 件を超すファイル関連の特許を取得している多産の発明家です。また、分散コンピューティングとビジネス プロセスの開発に関連する技術記事を多数執筆しています。Joshy の連絡先は jojoseph@microsoft.com です。