Agile Cat — in the cloud

Azure Core Scenario _1

Posted in David Chappell, Microsoft by Agile Cat on May 30, 2009

コア・シナリオ_1 : スケーラブルな Web アプリケーションの作成

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 今年の 1月に、TechDays で配布されたホワイトペーパーの続編にあたるもので、Fabric の機能と、アプリケーション・シナリオについて説明されています。4 回に分けて、それらのシナリオ部分の抄訳を掲載していきます。

なお、このホワイトペーパーは、MIX 09 にタイミングを合わせて公開されています。 つまり、Relational SDS へのシフトを前提に記述されていると捉えることができます。Relational SDS はそれとして、Azure におけるスケールアウトの戦略を読み取ることができるでしょう。

David 09_03_16 

Windows Azure のコンポーネントを理解することは重要ですが、それだけでは充分ではありません。このプラットフォームを適切に理解するためのベストな方法は、それが利用される形態を知ることです。 Windows Azure を利用するための、4つのコア・シナリオがあります:

① スケーラブルな Web アプリケーションの作成
② 並列処理アプリケーションの作成
③ バック・グラウンド・プロセスを用いた Web アプリケーションの作成
④ オンプレミスあるいはホストされているアプリケーションからのクラウド・ストレージの利用

ーーーーーーーーーーーーーーーーーーーーーー

インターネット・アクセスが可能な Web アプリケーションについて、その作成を望む組織は多いはずだ。今日における一般的な選択は、組織内のデータセンターもしくはホスターに配置されたアプリケーションを動作させることである。 しかし、Windows Azure のようなクラウド・プラットフォームが、多くの場合における最適な選択枝となる。

たとえば、多数のユーザーを同時に取り扱うアプリケーションが必要とされる場合には、そのための処理を明確にサポートするように設計されたプラットフォームを基盤とすることで、本質的な解決がもたらされる。Windows Azure に備えられた、アプリケーションとデータをスケールアウトしていく機能を用いることで、これまでの多くの Web テクノロジーと比較して、さらに大きな負荷を処理できるようになる。さらに、アプリケーションにおける負荷が、連続した低負荷の状態から、不定期にピークを迎える状況についても検討すべきだ。たとえば、オンラインの発券サイトや、ホットなトピックを配信するニュース・ビデオなどが、このパターンを示すことになる。言うまでもなく、どちらのサイトも、特定の時間帯で利用されることが多い。従来からのデータセンターにおいて、この種類のアプリケーションを運用するためには、余裕を持ってピークに対応するマシンを手元に置かなければならない。しかし、そのシステムの大部分が、通常では利用されないことになってしまう。それに替えて、Windows Azure を基盤としたアプリケーション構築では、必要とされるときにだけ、使用するインスタンス数を拡張し、ピークが去った後にはインスタンス数を縮小することが可能となる。 Windows Azure における課金が、使用ベースであるため、使用されない大量のマシンを保持するよりも、費用は安くなるだろう。

Windows Azure 上でスケーラブルな Web アプリケーションを作成するには、Web ロールとテーブルを利用する。Figure 6 で、その様子をシンプルに図示する。

Azure Core Scenarios _1

Figure 6: A scalable Web application can use Web role instances and tables.

ここで示される例では、ブラウザがクライアントになる。そして、ASP.NET などの Web テクノロジーを用いて、アプリケーション・ロジックが実装されるだろう。 それにより、RESTful もしくは、WCF を使用した SOAP ベースの Web サービスを公開する、スケーラブルな Web アプリケーションの作成が可能になる。どちらの場合においても、実行されるアプリケーション・インスタンス数がデベロッパーにより明示され、また、それに対応する数の VM が、Windows Azure ファブリック・コントローラーにより作成される。 前述のとおり、ファブリック・コントローラーからのモニタリングにより、要求されたインスタンス数が常に利用可能であることが確認される。なお、このアプリケーションが使用するデータス・トレージは、膨大なデータ量の処理をスケールアウトする、Windows Azure Storage となる。

Tagged with:

Azure Core Scenario _2

Posted in David Chappell, Microsoft by Agile Cat on May 28, 2009

コア・シナリオ_2 : 並列処理アプリケーションの作成

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 そこで解説されている、2番目のアプリケーション・シナリオの抄訳です。

Windows Azure のコンポーネントを理解することは重要ですが、それだけでは充分ではありません。このプラットフォームを適切に理解するためのベストな方法は、それが利用される形態を知ることです。 Windows Azure を利用するための、4つのコア・シナリオがあります:

① スケーラブルな Web アプリケーションの作成
② 並列処理アプリケーションの作成
③ バック・グラウンド・プロセスを用いた Web アプリケーションの作成
④ オンプレミスあるいはホストされているアプリケーションからのクラウド・ストレージの利用

CREATING A PARALLEL PROCESSING APPLICATION

スケーラブルな Web アプリケーションは有用であるが、Windows Azure の持つ意味は、それだけではない。 並列処理アプリケーションによる膨大な計算能力を、時として必要とする組織について考えてみよう。 グラフィックの特殊効果や、製薬会社における新薬開発、銀行における金融モデリングなど、たくさんのケースが挙げられる。 この、稀に生じるニーズを充たすために、大規模なクラスタ・マシンを維持することも可能だが、それは高価なものになる。  Windows Azure は必要に応じて、それらのリソースを提供し、オンデマンドのスーパー・コンピュータのような利用形態を実現する。

この種類のアプリケーションを開発するためには、Worker ロールを利用することになる。 それが唯一の選択枝というわけではないが、一般的な平行処理のアプリケーションでは、大規模なバイナリ・データ・セットを用いるケースが多い。 Windows Azure では、そのことを Blob の使用と表現する。 Figure 7 が示すのは、この種類のアプリケーションが機能するための、シンプルな方式である。

Azure Core Scinarios_2
Figure 7: A parallel processing application might use a Web role instance,
many Worker role instances, queues, and blobs.

このシナリオでは、それぞれの Blob データを用いるWorker ロール・インスタンスが、同時に実行することで並列処理を達成していく。インスタンスの実行時間について、Windows Azure が関与することがないため、それぞれのインスタンスは任意の作業量を実行できる。 そして、この アプリケーションとインタラクトするユーザーは、単一の Web ロール・インスタンスに依存することになる。 そのためのインターフェイスを介して、ユーザーは実行されるインスタンス数や、それらの開始と終了などについて決定し、その結果を得ることになる。 Web ロール・インスタンスと Web ロール・インスタンスを結ぶ通信については、Windows Azure のストレージ・キューに依存することになる。

さらに、それらのキューに対して、オンプレミス・アプリケーションからダイレクトにアクセスすることも可能となる。 Windows Azure 上で実行される Web ロール・インスタンスに依存するのではなく、ユーザーはオンプレミス・アプリケーションを介して、Worker ロール・インスタンスとインタラクトする。 その様子を、Figure 8 に示す。

Azure Core Scinarios_3

Figure 8: A parallel processing application can communicate
with an on-premises application through queues.

この例においても、多数の Worker ロール・インスタンスが、キューを介して外の世界と相互作用しながら同時に実行されることで、前述のように並列処理が達成されていく。 ただし、この処理においては、オンプレミス・アプリケーションからキューに対して、リクエストがダイレクトに入力される。 このようなシナリオでは、オンプレミス・アプリケーションが、Windows Azure での並列処理に依存していることに、ユーザーは気づかないかもしれない。

Tagged with:

Azure Core Scenario _3

Posted in David Chappell, Microsoft by Agile Cat on May 25, 2009

コア・シナリオ_3 : バック・グラウンド・プロセスを用いた Web アプリケーションの作成

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 そこで解説されている、3番目のアプリケーション・シナリオの抄訳です。

Windows Azure のコンポーネントを理解することは重要ですが、それだけでは充分ではありません。 このプラットフォームを適切に理解するためのベストな方法は、それが利用される形態を知ることです。 Windows Azure を利用するための、4つのコア・シナリオがあります:

①  スケーラブルな Web アプリケーションの作成
② 並列処理アプリケーションの作成
③  バック・グラウンド・プロセスを用いた Web アプリケーションの作成
④ オンプレミスあるいはホストされているアプリケーションからのクラウド・ストレージの利用

 Creating a Scalable Web Application with Background Processing

おそらく、今日における大多数のアプリケーションが、ブラウザ・インターフェイスを提供していると思われる。 ブラウザ・リクエストを受け付けて応答する以外には、何もしないアプリケーションは有用であるが、いくつかの厄介な事柄も残される。 リクエスト/レスポンス部分から独立したバック・グラウンド処理を、Web アクセスに対応するソフトウェアから開始するケースとしては、たくさんの状況が考えられる。

例として、ビデオ共有の Web アプリケーションについて考えてみよう。 そのようなアプリケーションは、多数のユーザーによるブラウザ・リクエストを、同時に受け入れる必要がある。 いくつかのリクエストは、新しいビデオをアップロードするためのものだろう。そして、それぞれのビデオは処理され、後のアクセスのためにストアされなければならない。この処理が完了するまで、ユーザーを待たせることに意味はないだろう。 その代わりに、対象となるアプリケーションのブラウザ・リクエストを受け付けるパートは、その作業を実行するバックグラウンド・タスクの開始できるようになるべきだ。

Windows Azure の Web ロールと Worker ロールを組み合わせることで、このシナリオに取り組むことができる。Figure 9 が示すのは、この種類のアプリケーションが動作する様子である。

Azure Core Scinarios_4 Figure 9: A scalable Web application with background processing might use all of Windows Azure’s capabilities.

このアプリケーションでは、以前に説明したスケーラブルな Web アプリケーションのように、いくつかの Web ロール・インスタンスを用いて、ユーザー・リクエストを処理していく。 そして、多数のユーザーを同時にサポートするために、情報をテーブルにストアすることになる。 バックグラウンド・プロセスに関しては、キューを介して Worker ロール・インスタンスにタスクが受け渡される。 この例では、Worker インスタンスにより Blobデータに取り組んでいるが、他のアプローチを用いることも可能である。

この例で示されるのは、Windows Azure が公開している、Web ロール・インスタンスや、Worker ロール・インスタンス、ブロブ、テーブル、キューといった、すべての基本的な機能を、アプリケーションから利用する方式である。 すべてのアプリケーションが、これらすべてを必要とするわけではないが、それらを利用することで、このように複雑なシナリオを本質的にサポートできる。

Tagged with:

Azure Core Scenario _4

Posted in David Chappell, Microsoft by Agile Cat on May 23, 2009

コア・シナリオ_4 : オンプレミスあるいはホストされているアプリケーションからのクラウド・ストレージの利用

以前に紹介したように、David Chappell さんが Introducing Windows Azure というタイトルの新しいホワイトペーパーを提供しています。 そこで解説されている、最後のアプリケーション・シナリオの抄訳です。

Windows Azure のコンポーネントを理解することは重要ですが、それだけでは充分ではありません。このプラットフォームを適切に理解するためのベストな方法は、それが利用される形態を知ることです。 Windows Azure を利用するための、4つのコア・シナリオがあります:

① スケーラブルな Web アプリケーションの作成
② 並列処理アプリケーションの作成
③ バック・グラウンド・プロセスを用いた Web アプリケーションの作成
④ オンプレミスあるいはホストされているアプリケーションからのクラウド・ストレージの利用

Using Cloud Storage from an On-Premises or Hosted Application

前述における、複雑なクラウド・プラットフォームのシナリオは、有用なものになり得る。しかし、Windows Azure における1つの機能だけを、アプリケーションが必要とする場合もある。例えば、膨大な量のデータをストアするための、オンプレミスあるいはホストされたアプリケーションについて考えてみよう。コストの低減を望むエンタープライズは、メールへのアクセスを可能にしながら、古い電子メールをストレージに保存するかもしれない。同様に、ホスティングされているニュース Web サイトが、膨大なのテキストや、グラフィックス、ビデオ、ユーザー・プロファイルなどの情報をストアするために、グローバルなアクセスが可能なスケーラブルな場所を必要とするかもしれない。写真共有サイトが、信頼できるサードパーティに情報をストアするという課題に、取り組むかもしれない。

Windows Azure Storage により、これらすべての状況に取り組むことができる。 Figure 10 に、このアイデアを図示する。

Azure Core Scenarios _5

Figure 10: An on-premises or hosted application can use Windows Azure blobs and tables to store its data in the cloud.

この図が示すように、オンプレミスあるいはホストされたアプリケーションは、Windows Azure のストレージにダイレクトにアクセスできる。このアクセスでは、ローカル・ストレージと比較して時間が掛かるだろうが、さらに安価であり、スケーラブルであり、信頼性も高くなるだろう。いくつかのアプリケーションにとって、このトレードオフは明確な価値を持っている。

ーーー

これまでに説明してきた 4つのシナリオのサポートが、Windows Azure CTP における基本的なゴールとのことです。 ただし、このクラウド・プラットフォームが成長するにつれて、そこで取り扱う課題も拡大すると期待してほしい、そして、ここに記したシナリオは重要がストーリーの終わりというわけではない、とも言っています

 

Tagged with:

PHP SDK for Windows Azure

Posted in Interoperability, Microsoft by Agile Cat on May 14, 2009

CodePlex に PHP SDK for Windows Azure が登場

From <http://phpazure.codeplex.com/>

Microsoft がコミットするインターオペラビリティの一環として、PHP 開発者と Windows Azure をつなぐためのオープンソース・プロジェクトが始まるようです。その PHPAzure プロジェクトにより、Windows Azure and Windows Azure Storage – Blobs, Tables & Queues のための開発キットが提供されます。

  • Overview
    • Windows Azure で PHP を利用する開発者に提供。
    • Windows Azure Storage (Blobs, Tables & Queues) に対して、一貫性のあるプログラミング・モデルを提供。
  • Features
    • Azure の Blobs, Tables, Queues (for CRUD operations) のための PHP クラス。
    • HTTP 転送と、AuthN/AuthZ、REST、Error Management のための Helper クラス。
    • マネージャビリティと、ツール、ロギングのサポート。

Logical architecture

PHP SDK for Windows Azure プロパイダーが、Windows Azure プロバイダーの REST/XML をシンプルな PHP API の中に抽象化することで、Windows Azure におけるコンピューティング、ストレージ、マネージメントなどの各種インターフェイスへのアクセスを実現。

PHP Azure A 09_05_14 

Deployment scenarios

アプリケーションが Windows Azure および オンプレミスの Web サーバーにホストされていても、PHP SDK for Windows Azure を利用していれば、Windows Azure の機能へのアクセスが可能。

PHP Azure B 09_05_14

Roadmap

The following milestones are planned for next few months.

Milestone 1: May 15, 2009 (Alpha/Community Technology Preview)

The focus of this release is around architecture, infrastructure and shared components that all Windows Azure storage types share. We are excited to show you our initial thinking of the project and an initial API for Windows Azure blob storage. We look forward to your feedback and feature requests.

Features included in the Alpha build are:

  • Windows Azure Blob Storage
  • CRUD on storage containers
  • Setting metadata on storage containers
  • Setting ACL on storage containers
  • CRUD on blobs (in storage containers)
  • Setting metadata on blobs
  • Listing and searching blobs in containers
  • Helper Classes for HTTP transport, AuthN/AuthZ, REST & Error Management

Milestone 2: July 31, 2009 (Feature Completion)

This release will focus on Windows Azure table storage. The following features will be included:

  • SharedKey Lite authentication (for local table storage service from SDK)
  • Query Tables – Enumerates the tables in a storage account.
  • Create Table – Creates a new table within a storage account.
  • Delete Table – Deletes a table from a storage account.
  • Query Entities – Queries data in a table.
  • Insert Entity – Inserts a new entity into a table.
  • Update Entity – Updates an existing entity within a table by replacing it.
  • Merge Entity – Updates an existing entity within a table by merging new property values into the entity.
  • Delete Entity – Deletes an entity within a table

Milestone 3: August 21, 2009 (Final)

This release will focus on Windows Azure queue storage as well as final release of the full PHP SDK for Windows Azure.

The following features will be included:

  • List Queues – Lists all queues under the given account.
  • Create Queue – Creates a new queue under the given account.
  • Delete Queue – Deletes a queue.
  • Get Queue Metadata – Returns queue properties, including user-defined metadata.
  • Set Queue Metadata – Sets user-defined metadata on the queue.
  • Put Message – Adds a message to the queue.
  • Get Messages – Retrieves a message from the queue and makes it invisible to other consumers.
  • Peek Messages – Retrieves a message from the front of the queue, without changing the message visibility.
  • Delete Message – Deletes a specified message from the queue.
  • Clear Messages – Clears all messages from the queue.

From <http://phpazure.codeplex.com/>

Tagged with: , ,

オンプレミスでの Windows Azure

Posted in Private Cloud by Agile Cat on March 26, 2009

オンプレミスでの Windows Azure ホスティングには否定的?

All about Microsoft より

From <http://blogs.zdnet.com/microsoft/>

March 23rd, 2009

Posted by Mary Jo Foley @ 11:53 am

Microsoft は、Azure プラットフォームによるクラウド・コンピューティングをベースにした、オンプレミスの環境をエンタープライズにに提供するのだろうか?直近の答えは、そして、多分 最終的な答えは NO である。

去年の秋にクラウド・プラットフォームを発表してから、Azure によるプライベート/オンプレミスのための道筋を Redmond が提供するのかしないのか、その点について混乱があったように思われる。つまり、Quincy や San Antonio に構築された Microsoft のデータセンターにではなく、顧客のデータセンターに Azure のオペレーティング・システムやサービスを提供するのかという疑問である。

最近になって、Julius Sinkevicius(Director of Product Management for Windows Server)と電子メールをやり取りしてみたが、Azure ベースのプライベート・クラウドのユーザーによる作成は、意図されていないように感じる。また、最近になって Cisco が明らかにした Unified Computing System ブレード・サーバーを購入する顧客には、Windows Server と Hyper-V が提供されることもあり、Microsoft と Cisco の最近の発表についても、Sinkevicius にいくつかの説明を求めてみた。

Sinkevicius との QA を以下に示す。

MJF: Azure のライセンシングについて、Cisco から Microsoft に申し出があったのか? Azure のすべての構成要素を、他社に提供することはあり得るのか?

Sinkevicius: NO。 Microsoft はオンプレミスのディプロイメントについて、Windows Azure を提供していない。 Windows Azure は、Microsoft データセンター上だけで動作する。 エンタープライズ・カスタマーののデータセンターに、きわめてスケーラブルでフレキシブルな OS をディプロイしたいなら、Hyper-V を活用することになる。また、仮想化について無制限の権利を持つ、Windows Server Datacenter Edition ライセンスと、マネージメントのための System Center についても同様である。

MJF: Red Dog (Windows Azure) と Cisco が発表した OS 構成の違いについて、Microsoft はどのように認識しているのか?

Sinkevicius: Windows Azure は、Microsoft のデータセンターに特化された、Microsoft のランタイムである。 Windows Azure は新しいアプリケーションのためにデザインされており、ISV とエンタープライズに対して geo-cost を要求することなく、geo-scale を提供する。Cisco が発表した OS の構成は、オンプレミス・サーバーにディプロイしていく顧客のためのものであり、そこでは Windows Server Datacenter と System Center へのテコ入れが行われるだろう。

オンプレミスでの Azure ホスティングに関する混乱の元は、Azure のために開発されたすべてのアプリケーションは、Windows Server 上も実行できるという説である。しかし、現在のところ、その反対は無理とされている。つまり、既存の Windows サーバー・アプリケーションは、最終的には Azure 上で実行できるようになるだろうという状況にある。 いま現在で、いくつかの事例もあるようだが、相当な厄介さを伴うことになる。Microsoft バスケットにデータを保存することに消極的な企業にとって、Microsoft のクラウド層は「このクラウド・プラットフォームを使って、あなたのデータを、どうぞホスティングしてください」というものではない。その代わりに、「あなたのデータの一部/全部を、このデータセンターから取り出して、あなたの望みどおりの方法で、また、望むタイミングで、オンプレミス環境で利用してください。そして、同様に、それらのデータを戻してください」と言っているような感じがする。

Microsoft による、データのポータビリティに関する約束は、ナーバスなエンタープライズ・ユーザーに対して、Microsoft Azure プラットフォーム提供するのに、充分な説得力を持っているのだろうか?

Tagged with:

Windows Azure Hypervisor

Posted in Microsoft by Agile Cat on February 26, 2009

Windows Azure Hypervisor デザインの背景と原則

<Windows Azure Blog より>

29 January 2009

http://blogs.msdn.com/windowsazure/archive/2009/01/29/design-principles-behind-the-windows-azure-hypervisor.aspx

Our next few posts will be discussions on the components of the Windows Azure service.  Please add comments on anything you would like to hear more about.

この後に続くいくつかの投稿では、Windows Azureサービスにおけるコンポーネントを説明することになるだろう。これが聞きたいなど、何らかのコメントがあったら、付け加えて欲しい。

By Hoi Vo

Director

We are frequently asked about the Windows Azure Hypervisor, and whether or not the code will be made available to customers as a product they could run in their own datacenters. We built the Windows Azure Hypervisor with three principles:

Windows Azure Hypervisor のコードが、あなたのデータセンターで動く製品として提供されるのかなんて、聞かれたって困るのだが、いろいろなところで質問攻めにあってしまう。その、Windows Azure Hypervisor だが、以下の3つの原則に基づいて構築するので、まずは読んでみて欲しい。

1. Efficient: push work to hardware as much as possible. Any percentage gain once multiplied to tens of thousands of machines will be very significant for us. Consequently we can bet on new processor features to save CPU cycles for the hosted application.

1:効率: 可能な限り、ハードウェアを効率よく活用する。無数のマシンとの掛け算になる効率は、私たちにとって極めて重要な事柄だ。正直なところ、アプリケーションをホストするために必要なCPUサイクルを、新しいプロセッサが充たしてくれることに賭けている。

2. Small footprint: any features not applicable to our specific cloud scenarios are removed. This guarantees that we do not have to worry about updating or fixing unnecessary code, meaning less churning or required reboots for the host. All critical code paths are also highly optimized for our Windows Azure scenarios.

2: 無駄なし: 私たちのクラウド・シナリオに適合しない機能は、排除される。それにより、不要なコードについて考え込んだり対応したりという、効率の悪い状況には陥らない。つまり、ホストのリブートに苦情が寄せられるようなことにはならない。すべてのコードに関するクリティカルな方針が、Windows Azure のシナリオに対して、高い次元で最適化される。

3. Tight integration: The Windows Azure Hypervisor is tightly optimized with the Windows Azure kernel. This is required to achieve the level of scalability and performance we want for our stack.

3: タイトなインテグレーション:Windows Azure Hypervisor と、Windows Azure カーネルとの関係は、密接さをもたらす最適化の上に成り立つ。 それが無ければ、私たちの懸案となっている、高度なスケーラビリティとパフォーマンスに到達することは無いだろう。

Much of the development for the Windows Azure Hypervisor would only work in our environment, taking advantage of our specific homogenous data center environment. Some of the innovations would be useful to customers with a different data center design and will be incorporated in future releases of Hyper-V (e.g. Second-Level Address Translation will be available in Hyper-V v2.0).

Windows Azure Hypervisor における多くの開発は、特定のデータセンターがもたらす均一性からのアドバンテージを得るために、私たちのデータセンターだけで開発されるだろう。ただし、いくつかの進歩は、別のデータセンターでも有益なものになるはずだ。そして、将来にリリースされる Hyper-V (たとえば Second-Level Address Translation が Hyper-V v2.0 では可能) に取り込まれていくだろう。

http://blogs.msdn.com/windowsazure/archive/2009/01/29/design-principles-behind-the-windows-azure-hypervisor.aspx

ーーーーーーーーーーーーーーーーーー

Windows Azure Hypervisor と Hyper-V v2.0 って、なんか ワクワク しますね。

Tagged with:

Web Role と Worker Role

Posted in Microsoft by Agile Cat on February 11, 2009

Web Role と Worker Role という Azure 内の役割

Azure のスケーラビリティと、パフォーマンス、そしてセキュリティは、どのようなアーキテクチャを用いて実現されるのでしょうか ?

Azure 090211a3

Web Role は IIS 7 を介して、HTTP(HTTPS)入力 リクエストを受け取ります。Web Role の実装は、IIS で動作する ASP.NET や WCF といった、.NET Framework テクノロジーを用いて行われます。図が示すように、Windows Azure が提供するビルトインのロード・バランシング機能が、アプリケーションを構成する複数の Web Role Instance をまたいで、リクエストを伝えていきます。

それと組み合わされるのが、Worker Role です。 この Role は外部からのリクエストを、ダイレクトに受信することができません。つまり、ネットワーク接続を持つことも許可されず、また、その VM 上では IIS が動作していません。その代わりに、Windows Azure Queue を経由して、Web Role Instance からの入力を受け取ります。そして、処理結果を、Windows Azure Storage に書き込むことが可能であり、また、ネットワーク接続が許可されるため、外部への送信も可能にします。

つまり、スケールのための Web Role と、ストレージのための Worker Role であり、2つの Role に分離することでセキュリティに対応するということなのでしょうか。

Tagged with:
%d bloggers like this: