[アーティクル]
08/28/2015

February 2010

Volume 25 Number 02

クラウドコンピューティング - エンタープライズ向け Windows Azure プラットフォーム

Hanu Kommalapati | February 2010

クラウドコンピューティングは、名だたる企業からも新興企業からも注目に値することが既に証明されています。ほとんどの企業は、単なる好奇心以上の関心を持って、クラウドコンピューティングに注目しています。本稿執筆時点では、IT マーケットリサーチによって、ほとんどのエンタープライズ IT マネージャーには、社内の IT 機能と組み合わせてクラウドコンピューティングを導入できるだけのリソースがあることが示唆されています。

もちろん、クラウドコンピューティングに期待を裏切らないだけの能力があるかどうかを疑う人もいます。この新しいソリューションは、ARPANET (インターネットの先駆け) の構築時とほぼ同じ道を辿っています。多くの懐疑的な研究機関は、各機関が独自に保有するデータの紛失を恐れて、ARPANET への参加に消極的でした。ひとたび科学者たちがデータネットワークと、データネットワークによって実現できるコラボレーションのメリットを認めると、何物も彼らを止めることはできませんでした。その後は、ご存知のとおりです。現在の大規模企業は、ARPANET に対して懐疑的だった機関と同様に、コンピューティング機能の実現と運用形態において進行しているパラダイムシフトに適応している過程にあります。

業界のトレンドとユーザーの要望を察知し、マイクロソフトはクラウドコンピューティングに力を入れており、クラウド内に実用レベルのサービスを作成および運用するための Windows Azure プラットフォームと必要な補完サービスをリリースしています。この記事では、Windows Azure プラットフォームをアーキテクチャのレベルで紹介し、エンタープライズクラスのソリューションのニーズに絡めて説明します。

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

クラウドコンピューティングにはいくつか定義がありますが、私が最も好きな定義は「インターネット標準またはプロトコルを通じてユーティリティとして提供されるコンピューティング機能」というものです。この定義であれば、"パブリッククラウド" と "プライベートクラウド" という考え方を実現する可能性が生まれます。パブリッククラウドは、その名が示すとおり、クレジットカードを使いこなしているユーザーであればだれでも利用できます。プライベートクラウドは、その綱領によって規定されている用途で、1 企業または 1 つの共同事業体のみが使用するものです。

Windows Azure プラットフォーム、Amazon Web サービス、Google App Engine、および Force.com が数少ないパブリッククラウドの例です。大規模企業が運営するプライベートデータセンターであっても、コンピューティング、ストレージ、およびネットワークを同種のリソースプールとして扱う広範な仮想化によって実現される統合リソースモデルを利用し、システムの運営に高度に自動化されたプロセスを利用する場合は、プライベートクラウドと呼ばれることがあります。

私の記憶にある限り、ユーティリティコンピューティングは、コンピューターオートメーション分野の先見者たちの夢でした。マイクロソフトの Dynamic Systems Initiative (DSI) や他のベンダーの同様の取り組みでは、データセンター運営者によるユーティリティのような機能、つまり、高度に自動化された、自己管理型、自己最適化型で、従量制のストレージ、ネットワーク、およびコンピューティングサイクルの実現を支援するという大胆な試みを行ってきました。このビジョンは称賛に値するものでしたが、成果は成功と失敗の入り混じったものでした。仮想化の登場により、ユーティリティコンピューティングが現実のものとなりました。仮想化によって、オペレーティングシステムやアプリケーションを物理ハードウェアから分離できるようになりました。仮想化はオペレーティングシステムやアプリケーションをデータとして扱うため、オペレーティングシステムや他の依存リソースを目的のハードウェアにオンデマンドでストリーミングする自動プロセスを開発できます。

Windows Azure プラットフォームについて説明する前に、クラウドコンピューティング分野の業界用語を簡単に紹介し、Windows Azure プラットフォームとそれらの用語を対応付けて、Windows Azure プラットフォームをすばやく理解できるようにします。図 1 は、業界用語と Windows Azure プラットフォームとの対応関係を示しています。ここからは、各種クラウドサービスとそれらの相対的な違いについて詳しく説明します。

Windows Azure プラットフォームは PaaS を提供

図 1 Windows Azure プラットフォームは PaaS を提供

Software as a Service

Software as a Service (SaaS) は、ソフトウェア配布ビジネスモデルの 1 つで、プロバイダーまたはサードパーティがアプリケーションをホストし、そのアプリケーションをサブスクリプションベースでユーザーに提供するモデルです。SaaS のユーザーは、プロバイダーのインフラストラクチャ上で実行されるソフトウェアを従量制で使用します。先行投資を必要としないため、ユーザーは長期契約を維持する必要がありません。

契約条件に基づき、ユーザーはいつでもソフトウェアの使用をやめることができます。基盤となるインフラストラクチャとソフトウェア構成は、ユーザーからは認識できないため、ユーザーは既定で提供されている機能しか使用できません。SaaS はマルチテナント性の高いアーキテクチャを採用していて、実行時でも停止時でも各ユーザーのコンテキストは論理的に分離されています。

こうしたマルチテナント機能は、一部の企業にとってはそのビジネスの性質上、好ましくない場合もあります。そこで、プロバイダーは、このようなユーザーには物理的に分離されたインフラストラクチャを用意して、ソフトウェアとハードウェアのメンテナンスに関する特別料金を課すことがあります。Microsoft Business Productivity Online Suite (BPOS) および CRM Online は、SaaS の代表的な例です。マイクロソフトは、これらのサービス用の専用ホスティングも特別料金で提供しています。

多くの企業に共通する問題を解決するコラボレーションアプリケーションは、SaaS 分野において非常に成功しています。ハードウェアとソフトウェアの構成がエンドユーザーから認識できるため、IT プロフェッショナルの関与が必要になったとしても最小限で済みます。SaaS アプリケーションの中には、構成を利用してエンドユーザーがカスタマイズできるものもありますが、ほとんどはカスタマイズできません。そのため、SaaS アプリケーションの場合、必要な開発スタッフの数も最小限で済みます。

SaaS では、アプリケーションのリリースまでに必要な時間を短縮できるほか、リリースまでの過程で、よく不満の種になるビジネス部門と IT 部門間の認識の違いを解決できます。企業が SaaS を導入する初期段階で、エンタープライズアーキテクトにとって悪夢になるのは、"影の IT 部門" (たとえば、各事業部門に所属している財務諸表に詳しいプログラマから成る小規模なグループ) が全社レベルの取り組みに歩調を合わせない場合があることです。これは、SaaS では、各事業部門が IT 調達プロセスを回避できてしまうためです。エンタープライズアーキテクチャチームはこのことを認識して、各事業部門にガバナンスの重要性を啓蒙する必要があります。また、新しいガバナンスプロセスを設計するか、既存のプロセスを変更して、SaaS に対応することをお勧めします。

現在の IT 環境では、巨額の IT 投資が大きな負担となるため、中小規模の企業では各社の事業を最適に運営するために必要な機能を用意できずにいます。SaaS では、現在は大規模企業にしか手の届かない IT 機能と同様の機能をすべての企業に提供できます。SaaS には莫大な IT 投資が必要にならないため、小規模企業のハンディがなくなり、エンタープライズクラスの IT 機能を手に入れることができます。

サービスプロバイダーという観点では、どのような小規模企業でも SaaS プロバイダーとなって、大手ソフトウェア会社と張り合うことができます。今や、このような企業は、少ない資本をハードウェアやソフトウェアインフラストラクチャの取得と管理に投じるのではなく、それぞれの中核となる得意分野に注力できます。

Platform as a Service

SaaS は、1 企業のすべてのソフトウェアニーズを満たすために導入すべきものであるように思えます。しかし、レガシテクノロジや特定の事業分野のために、IT の性質は企業ごとに異なっています。すべての基幹業務ニーズに適した SaaS サービスを見つけることは多くの場合不可能です。したがって、企業はアプリケーションを作り続ける必要があります。Platform as a Service (PaaS) は、カスタムアプリケーションをサービスとして作成および運用したい企業のニーズを満たします。このような企業には、ISV、付加価値サービスプロバイダー、エンタープライズ IT ショップをはじめ、カスタムアプリケーションを必要とする企業が含まれます。PaaS では、大規模なリソースプールを利用することで、ほぼ無制限のスケーラビリティを備えるホストアプリケーションサーバーが提供されます。また、PaaS では、ストレージ、セキュリティ、統合インフラストラクチャ、開発ツールなど、プラットフォームを補完する必要なサービスも提供されます。

サービスプロバイダーによって構成済みの仮想化アプリケーションサーバー環境が提供されるため、開発スタッフはこの環境にアプリケーションを配置できます。サービスプロバイダーがハードウェア (修正プログラムの適用やアップグレードなど)、およびアプリケーションサーバーの稼動時間を管理するため、IT プロフェッショナルの関与は最小限で済みます。開発者は、アプリケーションを作成し、作成したアプリケーションにリソース記述子を注釈として設定します。配置時に、プロビジョニングエンジンによって、記述子で宣言されている必要なインフラストラクチャ機能がアプリケーションにバインドされます。この場合のリソースには、ネットワークエンドポイント、ロードバランサー、CPU コア、メモリ、ソフトウェア依存関係などが含まれます。オンデマンドのスケーラビリティと、ハードウェアおよびアプリケーションサーバーの管理が提供されるため、開発者はインフラストラクチャ関連の問題に対応する必要がなくなり、アプリケーションの作成に注力できます。PaaS は、通常、新規アプリケーションに適しています。レガシアプリケーションの場合は、サンドボックス規則に従うために、大がかりなリファクタリングが必要になることがよくあります。

Infrastructure as a Service

Infrastructure as a Service (IaaS) は、従来のホスティングと同様、企業はホスト環境を社内のデータセンターを論理的に拡張したものとして使用します。サーバー (物理サーバーと仮想サーバー) が必要に応じて貸与され、インフラストラクチャを管理する IT プロフェッショナルがソフトウェアの構成を完全に制御できます。プロバイダーによってはハードウェア構成さえもカスタマイズできる場合があり、同等の PaaS サービスと比べて IaaS は割高になります。

ソフトウェア構成には、オペレーティングシステム、アプリケーションプラットフォーム、ミドルウェア、データベースサーバー、エンタープライズサービスバス、サードパーティのコンポーネントとフレームワーク、管理と監視のソフトウェアなどが含まれます。アプリケーションサーバーを自由に選択できるため、開発ツールも柔軟に選択できます。このような柔軟性のために、ＩＴ環境の複雑さは増幅されます。ユーザー企業のＩＴプロフェッショナルは、社内のサーバーであるかのように、IaaS サーバーを管理しなければなりません。メンテナンス作業には、OS およびアプリケーションサーバーの修正プログラムの適用やアップグレード、負荷分散、データベースサーバーのフェールオーバークラスタリング、バックアップと復元、ハードウェアエラーやソフトウェアエラーの発生リスクを抑えるためのその他の作業などがあります。

開発スタッフは、サーバーのハードウェア構成とソフトウェア構成を完全に把握した状態で、アプリケーションを作成、テスト、および配置します。通常、障害復旧と事業継続性にはユーザーが対応します。IaaS の重要なメリットの 1 つは、レガシアプリケーションをクラウドに移行できることです。IaaS は柔軟なためにどのような構成でも構築できるため、クラウドプロバイダー間でのアプリケーションの移植は困難です。クラウド内で企業のインフラストラクチャを模倣できるため、レガシアプリケーションを移行できることは、IaaS の最も魅力的なポイントです。IaaS はその柔軟によって、ソフトウェア構成の管理が大変な新規アプリケーションも作成できます。たとえば、アプリケーションの中にはサードパーティのバイナリやサービスのインストールを必要とするものもありますが、IaaS では、そのようなインストールにまったく制約がありません。

Windows Azure プラットフォームは、PaaS のメリットをすべて備えているだけでなく、IaaS と同様の柔軟性も期待できます (図 1 参照)。Windows Azure プラットフォームは、コンピューティング (コモディティサーバー) 、ネットワーク、ストレージといった大規模なリソースプールを組み合わせて、1 つのユーティリティコンピューティング環境を構築しています。この環境からユーザーはオンデマンドでリソースを利用し、使用した分だけ料金を支払います。クラウド環境では一般的なことですが、Windows Azure プラットフォームを利用する場合、ユーザーは先行投資を回避しやすく、必要に応じて IT 機能を拡張できます。

Windows Azure プラットフォーム

Windows Azure プラットフォームでは、Windows アプリケーションを作成および運用するための、ホストアプリケーションサーバーおよび必要なストレージ、ネットワーク、統合インフラストラクチャを提供しています。Windows Azure プラットフォームは、コモディティハードウェアの大規模プールを利用して、ユーティリティコンピューティング環境を構築しています。図 2 は、仮想化されたストレージ、ネットワーク、およびコンピューティングリソースが、配置時に設定されるプロビジョニングポリシーに従って、オンデマンドで配置される Windows Azure プラットフォームのリソースモデルを表しています。ファブリックコントローラーは、環境全体の頭脳にあたり、アプリケーションリソースプールに含まれない専用リソースのセットを備えています。ファブリックコントローラーは決して停止できないため、非常に冗長なハードウェアとソフトウェア環境を用意します。

コンピューティングインフラストラクチャの概念図 (Windows Azure の設定は異なる場合があります)

図 2 コンピューティングインフラストラクチャの概念図 (Windows Azure の設定は異なる場合があります)

コンピューティングリソースプールは、ファブリックコントローラーによってフォールトトレラントになっているコモディティリソースで構成されます。ファブリックコントローラーは、アプリケーションエラーを早期検出できるように設計されているほか、契約上のサービスレベルアグリーメントを満たす追加のインスタンスを作成します。Windows Azure 環境は、アプリケーションホストに必要なものを完備したプラットフォームなので、事実上無制限のリソースをオンデマンドのプロビジョニングにより提供することで、アプリケーションのシステム品質が維持されるようにします。使用されていないリソースは、プールに返されるため、使用効率が向上します。リソースには、コンピューティングサイクル、永続性のための仮想化ストレージ、プライベートおよびパブリックネットワークルーターの動的な再構成のための仮想化ネットワークリソースが含まれます。これらのリソースの物理構成は、仕様により、アプリケーションアーキテクトおよび開発者からは認識できません。

では、アプリケーションの所有者は、これらのリソースをどのようにプロビジョニングするのでしょうか。Windows Azure プラットフォームのデータセンターは、オートメーションをかなり活用している少数の担当者によって管理されているため、従来の社内環境のように、IT プロフェッショナルに電話をかけることなどできません。データセンターの日々の運用には、通常、人間の介入はまったく必要ありません。Windows Azure プラットフォームの場合、アプリケーション所有者は、リソース記述子で構成される、コンピューターが読み取ることができるモデルを利用して、必要なリソースをプロビジョニングできます。Windows Azure プラットフォームでは、これらのリソース記述子をサービスモデルと呼びます。これらのサービスモデルでは、完全な実行時インフラストラクチャを人手の介入なくプロビジョニングするために必要なアプリケーションリソースとその依存関係を指定します。このオートメーションのために、アプリケーションインフラストラクチャのプロビジョニングには、通常 5 分もかかりません。一般的な社内環境で行われている調達してプロビジョニングする方法と比べれば、クラウドコンピューティングの威力がわかります。

コンピューティング

Windows Azure プラットフォームのコンピューティングリソースは、アプリケーションを実行するための CPU サイクルを提供します。アプリケーションは、基盤となるオペレーティングシステムとハードウェアに物理的に依存しないように、仮想化環境内でホストされます。アプリケーションの疎結合は、ローカルファイル、永続ストレージ (構造化および非構造化)、診断およびインストルメンテーションリソースから成る仮想化リソースによって実現されます。ホスティング環境は仮想マシンとして実装されるため、アプリケーションエラーが発生しても、同じ物理ハードウェア上で実行されている他のアプリケーションに影響はありません。

アプリケーションは、ロールおよび関連付けられている実行可能コードとリソースのパッケージとして、Windows Azure プラットフォームに配置されます。Azure のロールは、ホスティング環境の特性を宣言によって記述します。配置されたアプリケーションがアクティブにされると、Azure のプロビジョニング環境がサービスモデルを解析し、ロールの種類を基に構成済みの仮想マシン (VM) イメージを選択して、アプリケーションビットを VM にコピーし、仮想マシンを起動して、必要なアプリケーションサービスを起動します。図 3 のサービス定義は、買い物リストアプリケーションを表しています。このアプリケーションは、この記事全体で参考例として使用します。

図 3 Web およびワーカーロールのサービスモデル

ShoppingListService の定義

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="ShoppingList">
<WebRole name="ShoppingList_WebRole">
<LocalResources>
<LocalStorage name="ShoppoingList_ImageCache" sizeInMB="100" 
cleanOnRoleRecycle="false"/>
</LocalResources>
<InputEndpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="HttpsIn" protocol="https" port="443" />
</InputEndpoints>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistOut"/>
</ConfigurationSettings>
</ WebRole>
< WorkerRole name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
<Setting name="DataConnectionString" />
<Setting name="ShoppinglistIn"/>
</ConfigurationSettings>
< WorkerRole />
</ServiceDefinition>

ShoppingListService の構成

<?xml version="1.0"?>
<ServiceConfiguration serviceName="ShoppingList">
</Role>
<Role name="ShoppingList_WebRole">
<Instances count="3" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the following two lines for application 
storage needs on  local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistOut" value="shoppinglistq"/>
</ConfigurationSettings>
</Role>
<Role name="ShoppingList_WorkerRole">
<Instances count="2" />
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" value=
              "UseDevelopmentStorage=true" />
<!-- flip the commenting of the followign two lines for local dev fabric -->
<!--<Setting name="DataConnectionString" value=
                  "UseDevelopmentStorage=true" />-->
<Setting name="DataConnectionString" 
value="DefaultEndpointsProtocol=http;
AccountName=<<account name>>;AccountKey=<<account key>>" />
<Setting name="ShoppinglistIn" value="shoppinglistq"/>
</ConfigurationSettings>
</Role></ServiceConfiguration>

図 3 の買い物リストアプリケーションは、Web ロールのインスタンスを 3 つ、ワーカーロールのインスタンスを 2 つ要求します。Web ロールの複数のインスタンスへの Web トラフィックは自動的に負荷分散され、3 つのインスタンス全部が、サービスモデルの記述に従って、SSL と HTTP エンドポイントを使用してプロビジョニングされます。アプリケーションが完全に停止することがないように、ファブリックコントローラーは多数の障害ドメイン間で割り当てを分散します。障害ドメインの構成は、図 2 の簡略図に比べればはるかに複雑です。簡単に説明すると、関連付けられているネットワークスイッチと電源を備えた個々のサーバーラックを、障害ドメインと考えることができます。

図 2 では、ファブリックコントローラーは、最初、1 つの Web ロールを各障害ドメイン (ラック #1、#3、および #n) から割り当てています。ここでは、2、3 の架空のイベントを基に、Windows Azure コンピューティングレイヤー全体の信頼性について説明します。イベント #1 の発生中に、ラックの電源障害のために、Web ロール #1 とワーカーロール #1 が応答を停止しました。ファブリックコントローラーは、Web ロール #1 とワーカーロール #1 のプロビジョニングプロセスを、利用可能なラック (ラック #2 およびラック #3) で開始します。しばらくしてから、イベント #2 が発生し、このときに、アプリケーションエラーのために、割り当て直された Web ロール #1 が正常性チェックに不合格になりました。そこで、ファブリックコントローラーは、Web ロール #1 の利用可能なラックの 1 つへの割り当てを開始します。

これらのイベントの発生中も、アプリケーションの可用性には影響がありません。Web ページ要求は、少なくとも 2 つの Web ロールによって引き続き処理されます。また、少なくとも 1 つのワーカーロールが、引き続きキューからトランザクション項目を取得して、Windows Azure ストレージに書き込みます。ファブリックコントローラーは、正常な 3 つの Web ロールインスタンスと 2 つのワーカーロールインスタンスが稼動している場合と同等の処理能力を実現するように努めます。実際には、ラックには冗長な電源およびネットワークスイッチが用意されていることが考えらるため、ロールのリサイクルと再割り当てが起きるのは、通常、アプリケーションに問題があるか、スケーラビリティの目標を達成するためにスケールアップする場合です。

買い物リストサービスモデルは、単一障害点が生まれないように、2 つのワーカーロールを要求します。Web 層とバッチ層は、Windows Azure キューによって分離されていますが、短時間で処理しなければならないミッションクリティカルなバッチサービスをホストする場合は、やはり、少なくとも 2 つのワーカーロールを要求することをお勧めします。ホストされるサービスが短時間処理を必要としない場合は、1 つのワーカーロールでも対応できる可能性があります。

図 1 は、Windows Azure プラットフォームが PaaS のメリットの提供を図りながらも、同時に、IaaS の柔軟性を実現できることを示しています。これは、Web ロール、ワーカーロール、CGI ロール、および今後提供されるその他の多数のロールによって宣言されているポリシーベースの配置モデルによって実現されます。サポートされるロールは、ユーザーの多様なアプリケーションニーズおよび配置ニーズに応えられるように、引き続き拡充される予定です。

コストを意識したクラウドアーキテクチャ

どのようなアーキテクチャにするかによって、小規模企業および大規模企業の運用コストに大きく影響する可能性があります。クラウドコンピューティングの主眼は IT のアジリティですが、ソリューションのアーキテクチャを決める際は、企業の運用コストに関する検討事項も考慮する必要があります。クラウドアプリケーションのアーキテクチャは、機能とシステム品質 (スケーラビリティ、可用性、信頼性、およびパフォーマンス) を実現するだけでなく、同時に、運用コストも最適化できる必要があります。社内環境の場合は、アプリケーションアーキテクトがストレージコスト、ネットワーク帯域幅、またはコンピューティングサイクスのコストを気にかけることはめったにありません。これらは組織レベルで発生する資本支出のためです。

たとえば、ストレージの維持コストは運用経費に含まれないため、アプリケーションストレージの最適化は、アーキテクトの仕事の最優先事項ではありません。社内システムの最優先事項は、重要なシステム品質を、割り当てられた予算内で実現することです。しかし、クラウドコンピューティングにおいては、最適な運用コストになるようにシステムのアーキテクチャを設計することが、ソフトウェア開発プロセスの重要な要素の 1 つになっています。

ここでは、図 4 で示した買い物リストを基に、Windows Azure プラットフォームのコストモデルについて説明します。この図は、買い物リストの論理アーキテクチャを示しています。図中の矢印は、データの動きを示しています。点線の矢印はデータセンター内の帯域幅使用を表し、実線はクラウドデータセンターと他のシステム間でやり取りされるデータの動きを表しています。

Windows Azure プラットフォームアプリケーションの課金モデル

図 4 Windows Azure プラットフォームアプリケーションの課金モデル

Windows Azure プラットフォームでは、データセンター外部とやり取りされるデータ転送のみが課金対象となり、データセンター内ローカルのデータ転送は無視されます。Windows Azure キューに書き込まれるデータについては、キューによるストレージ使用は非常に短時間であるため、帯域幅またはストレージの使用料は発生しません。ただし、キューを使用する場合、トランザクション単位で料金が発生します。キューアイテムの参照、読み取り、または書き込みは、1 トランザクションと見なされます。

Windows Azure プラットフォームサーバーの利用料は、ロールの数とアプリケーションが配置されている時間を基に計算されます。つまり、アプリケーションにエンドユーザーからの要求がなかったとしても、Windows Azure プラットフォームの課金システムでは、ロールの状態が "中断" および "開始" であれば、インスタンス数と配置時間に応じた料金が発生します。現時点では、これは手動プロセスですが、診断データおよびサービス管理 API を利用して、アプリケーションのスケーラビリティパターンを基に、アプリケーションのスケールを自動調整できる可能性があります。Windows Azure のテーブル、キュー、およびブロブを使用する場合は、ストレージ維持コストが発生します。これは、1 GB のレコードデータごとに課金されます。本稿執筆時点で発表されていた Windows Azure の料金表 (図 5) を参照してください。

図 5 Windows Azure の料金表

Windows Azure の機能	料金	備考
サーバー使用	小: 0.12 ドル/サービス時間中: 0.24 ドル/サービス時間大: 0.48 ドル/サービス時間特大: 0.96 ドル/サービス時間	アクティブなアプリケーションがあるロールによって、料金が決まります。小: (1.6 Ghz)、メモリ 1.75 GB (中程度の IO 性能) 中: (1.6 Ghz)、メモリ 3.5 GB 大: (1.6 Ghz)、メモリ 7.0 GB 特大: (1.6 Ghz)、メモリ 14.0 GB
Windows Azure ブロブおよびテーブル	0.15 ドル/GB	各課金サイクル中に、1  日の平均使用量が計測されます。さらに詳しい説明が必要なので、料金の計算方法についての詳細を確認してください。
トランザクション	0.01 ドル/1 万トランザクション	Windows Azure キュー、ブロブ、およびテーブルの作成、読み取り、更新、および削除は、1 トランザクションと見なされます。
SQL Azure: Web Edition	9.99 ドル/月 (1 GB の RDBMS)	大規模アプリケーションのメタデータまたは販売する商品数が数百点である小規模電子商取引 Web サイトの商品カタログ。
SQL Azure: Business Edition	99.99 ドル/月 (10 GB の RDBMS)	中規模ビジネス向け。または、データ共有により、大規模データストレージを必要とするアプリケーションを作成することも可能。
AppFabric	0.15 ドル/10 万メッセージ操作	メッセージ操作は、サービスバスメッセージ、アクセス制御トークン要求、またはサービス管理 API 呼び出し。
受信 GB	0.10 ドル/GB (アジアでは 0.30 ドル)	課金対象は、データセンターとそれ以外のシステム間でやり取りされるデータのみ。
送信 GB	0.15 ドル/GB (アジアでは 0.45 ドル)	課金対象は、データセンターとそれ以外のシステム間でやり取りされるデータのみ。

Windows Azure プラットフォームの料金体系は、ブロブとテーブルによって使用されるストレージを除いては、単純です。アカウントの Windows Azure ストレージの使用量は、課金サイクル中に 1 日単位で計測され、一日の平均使用量が計算されます。料金は、この一日あたりの平均使用量に 0.15 ドル/GB をかけて、算出されます。たとえば、1 日目に 20 GB を保存、2 日目に 10 GB を追加、3 日目に 5 GB を追加、4 日目に 5 GB を削除し、この課金サイクルの残りの日ではなにも操作が行われなかった場合、料金は以下のように計算されます。

((20 +10 + 5 – 5)/30) * 0.15 = $0.15

この例では、1 課金サイクルを 30 日間としています。課金サイクルの最後にしか計測しないシステムとは異なり、ストレージの使用量を 1 日単位で計測することで、アプリケーションが非常に短い時間しかデータ保存を必要としない場合でも、確実にストレージを使用した分が課金されます。

前述のとおり、アーキテクチャは、アプリケーションの毎月の運用コストを左右する重要な要素です。たとえば、アプリケーションが大量のデータを生成するとしても、アプリケーションの機能に必要なのは最新 (たとえば過去 2 週間) のデータだけであれば、不要なデータを削除するか、定期的に社内システムに転送するようアーキテクチャを調整できます。1 回の帯域幅使用料を支払う方が、永続的にストレージコストが発生するよりも、有利な場合があります。アクティブなデータセットから外れた参照データについても、同じことが言えます。この方法は、既にデータのアーカイブリソースに投資している企業では、有効な可能性があります。

アプリケーションのシナリオ

実用レベルの電子商取引シナリオである買い物リストアプリケーションを基に、Windows Azure プラットフォームのさまざまな要素を説明します。ここでは、主に買い物リストを作成して、後で店頭で買い物をするときに使用できるように保存します。Web UI が買い物リストを作成し、Web サービスを使用してリストを Windows Azure ストレージに保存します。スケーラビリティのため、Web 層は買い物リストを Windows Azure キューに書き込みます。定期的に、バッチプロセスがキューからリストを取得して、Windows Azure テーブルに保存します。また、実際のソリューションの要素を具体的に説明できるように、Windows Azure ベースの認証とロールベースのセキュリティを使用します。

Windows Azure プラットフォーム上の買い物リストアプリケーション

図 6 Windows Azure プラットフォーム上の買い物リストアプリケーション

前述のコストを意識したアーキテクチャの観点では、さまざまな決定が毎月の運用コストに影響します。アーキテクチャの設計を始める前に、検討が必要なシステムの要素をいくつか以下に示します。

参照データの増加率
トランザクションデータの増加率
動作のプロファイリングデータのキャプチャ率
ビジネスイベントデータの増加率
システムイベントデータのキャプチャ率
商品関連のメディアコンテンツ
キューを使用するか、永続ストレージを直接操作するか

この買い物リストシナリオに含まれているメディアコンテンツは多くなかったので、コスト計算上の大きな要素にはなりませんでしたが、ビデオ、画像、およびオーディオストリームを提供するコンテンツサイトにとっては、非常に重要な検討事項になる場合があります。図 7 は、Windows Azure プラットフォームでの一般的なアプリケーションの毎月の運用コストを示しています。このスプレッドシートには、開発、運用サポート、およびエンドユーザーサポートにかかる人件費は含まれていません。

ある電子商取引アプリケーションの Windows Azure の運用経費の内訳

図 7 ある電子商取引アプリケーションの Windows Azure の運用経費の内訳

クラウドコンピューティング環境を使用すると、運用サポートスタッフの数が減少するため、社内とクラウド間で ROI を比較する場合には、これを考慮する必要があります。また、ROI の計算には、アプリケーションごとの電力費や減価償却費を含めることも重要です。アプリケーション単位での消費電力を求めることは難しいため、多くの場合、現在の社内アプリケーションのコストモデルにはこうした経費が含まれていません。冷却および設置スペースにかかる費用にも、同じことが言えます。ROI の計算ツールでは、目的の費用項目の額がわからない場合に、知識に基づいた推測を使用できます。

図 7 の単純なコスト計算ツールにより、Windows Azure プラットフォームでホストされているアプリケーションの運用経費が見積もられています。この Microsoft Excel ベースのツールでは、一般的な電子商取引アプリケーションのさまざまな入力パラメーターを指定でき、図 5 の Windows Azure プラットフォームの料金表を使用して、毎月の運用コストが計算されます。このツールで使用されている既定のパラメーターは架空のものであることに注意してください。ツールの出力を基に判断する前に、実際のシステムを考慮してください。このコスト計算ツールでは、1 か月あたりのビジター数を基本とし、ページビューとトランザクションデータ作成およびイベントデータ作成の数値を仮定しています。Windows Azure プラットフォームチームは、アプリケーションの毎月のコストを計算するだけでなく、社内アプリケーションの TCO と Windows Azure の TCO を比較する、より包括的なツールを作成しています。この Windows Azure TCO ツールは、microsoft.com/windowsazure/tco (英語) からアクセスできます。

図 7 からわかるように、この架空のアプリケーションは、ある月に 9,000 GB のデータを生成しています。この場合、このデータを Windows Azure テーブル内に保存する場合は、毎月 1,350 ドルの費用が発生します。図 7 は、ある時点のストレージ状態を示しているに過ぎず、イベントデータに伴う料金は、アプリケーションの運用を続けるに従い、累積される可能性があることに注意してください。このようなコストは、アプリケーションの運用成熟度に合わせて、キャプチャするイベントデータの量を調整することで、最適化できます。このコスト計算ツールは、1 か月あたりのビジター数を基本とし、Web ロール数を 10、ワーカーロール数を 3 としています。この月の料金総額は、3,571 ドルです。

または、既に償却済みの社内ストレージシステムが存在する場合は、1 回の帯域幅使用料 (送信の場合 0.10 ドル/GB) を払って、イベントデータを転送するようにアプリケーションのアーキテクチャを設計できます。トランザクションデータや動作のプロファイリングデータも同様に扱い、ストレージ料の累積を避けることができます。

コンピューティング料金は累積される性質のものではないため、アプリケーション全体の運用費へは比較的影響しません。ただし、アプリケーションのスケーラビリティについて観測された統計データを基に、アクティブな Web ロールインスタンスとバッチロールインスタンスの数を調整して、わずかながら運用経費の軽減を図ることができます。コンピューティング料金とストレージ料金の違いは、コンピューティングは使用量をいつでも管理できますが、ストレージコストは、アプリケーションが一度作成されたら、簡単には修正できないアーキテクチャによって決まるコストです。したがって、永続アーキテクチャを最初に正しく設計することをお勧めします。

アプリケーションのコストモデルのほかに、大規模企業では、アプリケーションのセキュリティについても細心の注意が必要です。次は、これについて説明します。

コンピューティングセキュリティ

企業は、クラウドにおけるアプリケーションとデータのセキュリティを非常に気にします。データセンター、インフラストラクチャ、およびオペレーティングシステムのセキュリティはマイクロソフトによって対応されますが、アプリケーションのセキュリティは、アプリケーション所有者が対応する必要があります。ここでは、買い物リスト Web アプリケーションを基に、アプリケーションのセキュリティについて説明します。Windows Azure プラットフォームアプリケーションのセキュリティ保護は、社内アプリケーションのセキュリティ保護と同様です。Windows Azure プラットフォームは、アプリケーションへのセキュリティの組み込みを支援するさまざまなシステムコンポーネントを提供しています。これらのシステムコンポーネントを使用すると、大規模企業に適したフェデレーションシナリオでの基本となる自己完結型の認証と承認を利用できます。

基本 ID

基本 ID モデルは、名前が示すとおり、1 つのアプリケーション、または同じユーザーセットを共有し、実装レベルで同じ ID システムに密結合されている共存グループのニーズを満たす自己完結型の ID アーキテクチャを実装します。Windows Azure プラットフォームのサンプルには、基本 ID ソリューションの実装に使用できる ASP.NET プロバイダーのセット (メンバーシップ、ロール、プロファイル、およびセッション) が含まれています。Windows Azure ASP.NET は、Windows Azure テーブルおよびブロブを含む、Windows Azure ストレージ上に実装されます。これらのプロバイダーは、ASP.NET プロバイダーコントラクトを実装し、Windows Azure プラットフォーム SDK に含まれる StorageClient API を利用します。これらのプロバイダーの概略図を図 8 に示します。

Windows Azure ASP.NET プロバイダー

図 8 Windows Azure ASP.NET プロバイダー

アプリケーションが Windows Azure ASP.NET プロバイダーを使用できるようにするには、Web.config ファイルを変更して、既定のプロバイダーを削除し、新しいプロバイダーを指定します。図 9 の構成の変更は、社内環境におけるカスタム ASP.NET プロバイダー向けに行う必要がある変更と同様です。

図 9 Windows Azure ASP.NET プロバイダーのための Web.config の変更

<system.web>
  ... ... ... ...
<authentication mode="Forms" />
<!-- Membership Provider Configuration -->
<membership defaultProvider="TableStorageMembershipProvider"
userIsOnlineTimeWindow="20">
<providers>
<clear/>
<add name="TableStorageMembershipProvider"
type="Microsoft...AspProviders.TableStorageMembershipProvider"
description="Membership provider using Azure storage"
applicationName="ShoppingList"
... ... ... ... ...
minRequiredNonalphanumericCharacters="0"
requiresUniqueEmail="true"
passwordFormat="Hashed"/>
</providers>
</membership>
<sessionState mode="Custom"
customProvider="TableStorageSessionStateProvider">
<providers>
<clear />
<add name="TableStorageSessionStateProvider"
type="Microsoft...AspProviders.TableStorageSessionStateProvider"
applicationName="ShoppingList"/>
</providers>
</sessionState>
<roleManager enabled="true"
defaultProvider="TableStorageRoleProvider"
cacheRolesInCookie="true"
cookieName=".ASPXROLES"
cookieTimeout="30"
... ... ... ... ...
cookieProtection="All">
<providers>
<clear/>
<add name="TableStorageRoleProvider"
type="Microsoft....AspProviders.TableStorageRoleProvider"
description="Role provider using table storage"
applicationName="ShoppingList" />
</providers>
</roleManager>
... ... ... ...
</system.web>

ASP.NET プロバイダーが構成されると、従来の ASP.NET アプリケーションと同様の方法で、認証、承認、およびユーザープロファイルを実装できます。図 9 の構成には、Windows Azure ストレージベースのセッションプロバイダーが含まれていて、このプロバイダーでは、耐久性のあるメディアにセッション状態を保存できます。Windows Azure のロードバランサーは固定セッションをサポートしないため、Windows Azure ストレージにセッションデータを保存することで、セッションベースでパーソナル化してユーザーエクスペリエンスを強化できます。基本 ID モデルは、同じアプリケーション内で開始し終了されるユーザー ID ライフサイクル (ユーザーアカウントの作成、使用、および終了) があるアプリケーションに適しています。基本 ID 実装が選ばれる理由としては、次のようなさまざまな理由があります。

ユーザー ID レコードの完全な所有権をアプリケーションで保持したい
フェデレーション ID ストアを実装し、サービスをサポートできるインフラストラクチャがない
ユーザー登録が必要なアプリケーションの有効期間が短い (マーケティングコンテンツやキャンペーンなど)

Windows Azure ASP.NET プロバイダーは、AJAX および Silverlight アプリケーションのユーザーを認証する目的でも使用できます。AJAX から呼び出し可能な AuthenticationService クラス、ProfileService クラス、および RoleService クラスは、System.Web.Extensions.dll に保持されていて、Windows Azure Web ロールを利用して .svc エンドポイントとして公開できます。HTTP コンテキスト固有のデータにアクセスするには、これらのサービスが ASP.NET 互換である必要があることに注意してください。「Silverlight を使用して基幹業務エンタープライズアプリケーションを構築する (第 2 部)」(msdn.microsoft.com/magazine/dd434653) という記事では、Silverlight または AJAX から呼び出される上記のサービスのセットアップについて詳しく説明されています。

フェデレーション ID モデル

サプライチェーン、バリューチェーン、コラボレーション、ソーシャルネットワーキングなどのアプリケーションのほか、インターネット上でよく利用される ID ストアと統合するアプリケーションには、フェデレーション ID が必要です。Windows Azure ASP.NET スタックは、Windows Identity Foundation (WIF) と組み合わせて、1 つ以上のセキュリティトークンサービスプロバイダーと統合できます。WIF は、WS-Trust および WS-Federation によって既に確立されている信頼関係と連携して機能します。図 10 は、社内のトークンプロバイダーとフルフィルメントパートナーのトークンプロバイダーの 2 つと連携する買い物リストアプリケーションの概念図です。

Windows Azure アプリケーションには複数のトークンサービスを登録可能

図 10 Windows Azure アプリケーションには複数のトークンサービスを登録可能

信頼関係によって、セキュリティトークンサービス (STS) エンドポイントと、トークンの要求と応答の署名に必要な X509 証明書が指定されています。図 11 は、信頼の概略図です。これは、配置時に買い物リストアプリケーションに組み込まれる XML 表現です。ユーザーは各自のシステムで認証され、その結果生成された Security Assertion Markup Language (SAML) トークンが要求元のアプリケーションに転送されます。

フェデレーションの信頼関係の記述子

図 11 フェデレーションの信頼関係の記述子

図 10 からわかるように、ユーザーが、Windows Azure プラットフォームでホストされている買い物リストアプリケーションのセキュリティ保護された Web コンテンツにアクセスする場合、WIF は要求を信頼構成で指定されている買い物リストの STS URL に転送します。買い物リスト STS は資格情報を収集し、Active Directory を基にユーザーを認証し、Active Directory Federation Services (ADFS、旧称 "Geneva Server") と連携して SAML トークンを作成し、これを Web ブラウザーを介して買い物リストアプリケーションに転送します。Windows Azure 上の買い物リストサイト内で実行されている WIF が、SAML クレームを抽出して、承認チェックを実行します。

複数の STS が関係する場合、Web サイトは、各種トークンを標準形式に変換できるように、トークン変換ロジックを実装する必要があります。新しい STS をシステムに導入する際の影響を最小限に抑えるためには、トークン変換ロジックは外部化するか、ロジックを利用するアプリケーションに影響を与えることなく変更できるコンポーネントにカプセル化できます。図 12 は、WIF と連携するトークン変換の概略図です。

複数のトークンプロバイダーを使用するフェデレーション ID システム

図 12 複数のトークンプロバイダーを使用するフェデレーション ID システム

フェデレーション ID モデルでは、次のようなシナリオを実現できます。

法令遵守のために社内での ID レコードの保存
既存の社内のアプリケーションセキュリティインフラストラクチャの活用
バリューチェーンやサプライチェーンにおけるパートナーとの統合
社内および Windows Azure プラットフォームアプリケーション間のシングルサインオン

多くの場合、大規模企業には、既にアプリケーションのセキュリティ保護に利用する必要がある認証サービスとディレクトリサーバーが実装されています。Windows Azure プラットフォームでは、クラウドを利用してアプリケーションを迅速に配置できるようにするだけでなく、同時に、既存のインフラストラクチャを利用してセキュリティを確保できます。また、Windows Azure プラットフォームでは、仕様で、ビジネスパートナー間やバリューチェーン内でさまざまな統合シナリオを可能にするフェデレーション ID の使用が許可されています。

Windows Azure ストレージ

Windows Azure プラットフォームに配置されるアプリケーションやサービスは、非構造化および半構造化コンテンツを永続的に保持するために Windows Azure ストレージを使用できます。Windows Azure ストレージは、実用レベルのアプリケーションおよびサービスの作成に必要な、テーブル、ブロブ、およびキューという 3 つの基本機能を備えています。Windows Azure ストレージは、REST などの業界標準 Web サービスインターフェイスを介して、社内でホストされているアプリケーションにもアクセスできる、非常にスケーラブルかつ信頼性の高い永続化メカニズムです。通信中のプライバシー保護のため、Windows Azure ストレージでは、標準の HTTP プロトコルに加えて、SSL (HTTPS) ベースのアクセスもサポートしています。スケーラビリティなどのシステム品質は、コモディティサーバーハードウェアとディスクアレイから成る大規模なストレージファームによって実現されます。このファームは、Windows Azure ストレージソフトウェアによって管理されます。スケーラビリティと可用性のために、ストレージアクセスは、ノードセット内で自動的に負荷分散されます。各ノードは、物理ストレージの容量制限内での処理を行います。ノードのスコープ外のストレージへのアクセスは、ピアツーピアインターフェイスによって実現されます。信頼性は、エンティティ (ShoppingList など) を複数のノード上に保存して冗長性を持たせることで実現されます。ストレージソフトウェアは、書き込みが発生すると、データの複数のレプリカ (本稿執筆時点では 3 つ) を自動的に作成します。ストレージは、アトミックなトランザクション書き込みをサポートしており、トランザクションは、すべてのレプリカがドライブに書き込まれなければ完了しません。図 13 は、Windows Azure ストレージサービスを構成するコモディティストレージノードのコレクションを示しています。

ストレージサービス

図 13 ストレージサービス

使用中に、どこかのストレージドライブで障害が発生する可能性があります。ノード番号 4 および 11 の赤の "X" は、この可能性を示しています。ストレージサービスは、障害が発生したドライブを特定すると、稼動しているドライブから新しいノードにデータをレプリケートします。ストレージサービスは、どの時点でも必ずレプリカポリシーに従います。前述のとおり、アプリケーションからの要求トラフィックは、複数のノード間で負荷分散されます。

このようなアーキテクチャは、Windows Azure プラットフォームなどのパブリッククラウド PaaS サービスで必要とされる大規模なスケールでの運用に役立ちます。図 13 に示されているように、ノード 4、11、および 14 に、データの最初の 3 つのレプリカがあるとします。ノード 4 と 11 で障害が発生した場合、ノード 14 は要求の直接の処理を続行しながら、すぐに少なくとも 2 つの追加のノード (ノード 2 と 8) にデータを再度レプリケートして、データのレプリカが必要数維持されるようにします。

ストレージのセキュリティ

Windows Azure ストレージは、ハッシュベースのメッセージ認証コード (HMAC) を利用して、REST Web 要求を認証します。Windows Azure ストレージプロジェクトに関連付けられている共有の秘密キーは、Web 要求に "認証" ヘッダーとして埋め込まれる 256 バイトのハッシュ計算時に HTTP 要求と組み合わされます。同じプロセスが、サーバー側でも繰り返され、要求の信頼性が検証されます。ストレージの種類ごとにペイロードとターゲット URL は異なりますが、Windows Azure テーブル、キュー、およびブロブのいずれでも同じ認証プロセスが実行されます。以下は、"hkshoppinglist" というプロジェクトの下で、上記の 3 つのストレージ機能にアクセスするための URL です。

http(s)://hkshoppinglist.blob.core.windows.net/
http(s)://hkshoppinglist.queue.core.windows.net/
http(s)://hkshoppinglist.table.core.windows.net/

図 14 のコードサンプルは、アプリケーションを配置するためにストレージを準備する一環として、複数の Windows Azure テーブルを作成する処理を表しています。

図 14 Windows Azure テーブルおよびデータの認証済み作成を表す疑似コード

[DataServiceKey("TableName")]
Public class StorageTable
{
  Private string _tableName;
  Public string TableName
{
  get { return this._tableName; }
  set { this._tableName = value; }
}
}

Public class Customer: TableServiceEntity
{
  Public string Name { get; set; }
  Public string CustomerID { get; set; }
  public Customer()
{
  PartitionKey = "enterprise";
  RowKey = string.Format("{0:10}_{1}", DateTime.MaxValue.Ticks –
  DateTime.Now.Ticks, Guid.NewGuid());
}
}
CloudStorageAccount _storageAccount = CloudStorageAccount.FromConfigurationSetting("DataConnectionString");

Public void CreateMultipleCustomers(List<Customer> customers)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials);
  foreach (Customer cust in customers)
{
  tsc.AddObject("customers", cust);
}
try
{
  DataServiceResponse resp =  tsc.SaveChanges(SaveChangesOptions.Batch);
  foreach (ChangeOperationResponse cor in resp)
{
  if (cor.Error != null)
{
//cor.Headers["Location"] can be parsed to find out the failed 
//requests which can be retried after correcting the error condition
}
}
}
catch (Exception ex){ //do something with the exception }
}

protectedvoid linkCreateTables_Click(object sender, EventArgs e)
{
  labelStatus.Text = string.Empty;
try
{
  CreateTable("customers");
  CreateTable("products");
}
catch (DataServiceRequestException ex)
{
  labelStatus.ForeColor = System.Drawing.Color.Red;
  labelStatus.Text = "Error: Table creation error : " + ex.Message;
}
}
//Use ADO.NET services directly to create an Windows Azure Table
Public void CreateTableUsingContext(AzureStorageTable storageTable)
{
  TableServiceContext tsc = new
  TableServiceContext(_storageAccount.TableEndpoint.AbsoluteUri, 
  _storageAccount.Credentials); tsc.AddObject("Tables", storageTable);
try
{
  DataServiceResponse resp = tsc.SaveChanges(SaveChangesOptions.None);
//handle errors
}
catch (Exception ex){//do something here}
}
//much simpler way of creating an Windows Azure Table
  publicvoid CreateTable(string tableName)
{
CloudTableClient ctc = _storageAccount.CreateCloudTableClient();
try
{
  ctc.CreateTable(tableName);
}
catch(Exception e) { //handle exception }
}

Windows Azure テーブルを例にして、トランザクションによるデータ設定ができるように Windows Azure ストレージを準備する簡単な方法を紹介します。このコードサンプルでは、REST ベースの通信の相互作用の柔軟性を示すため、TableServiceContext と CloudTableClient を使用した "customers" テーブルと "products" テーブルを作成しています。実は、新しいペイロードを作成して、HMAC を Web 要求に添付し、テーブルの URL に対して HTTP POST を実行することもできますが、これにはコードが大量に必要になるため、学習目的で演習として使用する以外はこの方法はお勧めしません。推奨方法は、Windows Azure SDK に含まれる StorageClient を使用することです。

CreateTableUsingContext 関数は、AzureStorageTable クラスを使用して、ADO.NET データサービスと連携してテーブル作成ペイロードを生成します。TableServiceContext は自動的に HMAC を生成し、CloudStorageAccount.Credentials プロパティに保持されているキーを使用して要求に添付します。

Windows Azure テーブルストレージでは、バッチトランザクションも実行できます (図 14 の CreateMultipleCustomers 関数を参照)。バッチは特定の変更セット内で100 操作を超えないようにします。また、1 バッチは 4 MB 以下にします。詳細については、Windows Azure ストレージのドキュメントを参照してください。バッチトランザクションは、同じパーティションに属しているエンティティにしか実行できません。

HMAC の生成に必要な資格情報は、対応する Windows Azure ロールのサービス構成において指定されます。ローカルストレージ用とクラウド用の接続文字列の形式を以下に示します。

ローカルストレージ:

<Setting name="DataConnectionString"
value="UseDevelopmentStorage=true"/>

クラウドストレージ:

<Setting name="DataConnectionString"
value="DefaultEndpointsProtocol=
http;AccountName=
<your account>;AccountKey=<your account key"/>

Windows Azure ストレージにはロールベースのセキュリティの概念はありません。したがって、認証済み要求は、ストレージプロジェクトのコンテキストのストレージに完全にアクセスできます。この例外はブロブコンテナーです。これは、パブリック (匿名) にもプライベートにもなります。承認は、ストレージサービスを利用するアプリケーションによって処理される必要があります。

まとめ

この記事では、Windows Azure プラットフォームのごくさわりの部分を説明しました。将来は、Microsoft SQL Azure、AppFabric、さまざまなサーバーロール、およびここで紹介できなかったその他のセキュリティシナリオに関する情報が豊富に提供されているものと思います。Windows Azure プラットフォームは、アプリケーションやサービスを開発およびホストするための、オンデマンドのユーティリティコンピューティングを実現するように設計されているコンピューティングプラットフォームです。

コモディティハードウェアの大規模プールは、オートメーションを多用することで、ソフトウェアによって高い信頼性が得られています。大規模なスケールによる経済的なメリットは、サブスクリプション料金を低く設定することで利用者に還元されています。利用者は、毎月の課金サイクルでの、帯域幅、ストレージ、およびコンピューティングサイクルの使用量を基に課金されます。Windows Azure プラットフォームでは、先行投資や長期契約を必要とせずに、エンタープライズクラスのアプリケーションとサービスの作成に必要なプラットフォームコンポーネントが提供されます。

Hanu Kommalapati は Microsoft のプラットフォーム戦略アドバイザーであり、現在は企業顧客に対して Silverlight および Windows Azure プラットフォーム上でスケーラブルな基幹業務アプリケーションを構築できるように助言を行っています。

この記事のレビューに協力してくれた技術スタッフの Vittorio Bertocci、Brad Calder、Ryan Dunn、および Tim O'Brien に心より感謝いたします。

次の方法で共有

クラウドコンピューティング - エンタープライズ向け Windows Azure プラットフォーム

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

Software as a Service

Platform as a Service

Infrastructure as a Service

Windows Azure プラットフォーム

コンピューティング

コストを意識したクラウドアーキテクチャ

アプリケーションのシナリオ

フェデレーション ID モデル

Windows Azure ストレージ

ストレージのセキュリティ

まとめ

その他のリソース

次の方法で共有

クラウド コンピューティング - エンタープライズ向け Windows Azure プラットフォーム

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

Software as a Service

Platform as a Service

Infrastructure as a Service

Windows Azure プラットフォーム

コンピューティング

コストを意識したクラウド アーキテクチャ

アプリケーションのシナリオ

フェデレーション ID モデル

Windows Azure ストレージ

ストレージのセキュリティ

まとめ

その他のリソース

クラウドコンピューティング - エンタープライズ向け Windows Azure プラットフォーム

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

コストを意識したクラウドアーキテクチャ