これから Windows Azure を始める 開発者の皆様に知っていただきたい 8 つの真実 【Reloaded】～ みっつめ
さて、みっつめにご理解いただきたい真実は、Windows Azure が “スケーラブル” なクラウド プラットフォームである、ということです。
漠然と、「クラウド＝スケーラブル」という印象は持たれているかと思いますが、Windows Azure では、そもそもの Windows Azure の設計思想の根本からして、”スケーラビリティ” を追求した作りになっています。
具体的にどういうことなのか？
Windows Azure では、Windows Azure 上で稼動させるアプリケーションに対して、ある種の制約としての設計パターンを課しています。
【制約１】 アプリケーションは Stateless な設計とする（アプリケーション側で “状態” 管理を行わない）。
【制約２】 ユーザーからのリクエストを直接受け付けるフロント担当の “Web Role” とユーザーへの直接的なサービスは提供せず、間接的にバックエンドで処理を担当する “Worker Role” に分けてアプリケーションを構築する。
また実際の構築においては、Web Role と Worker Role は直接接続するのではなく（密結合とするのではなく）、メッセージングテクノロジー（たとえば、Windows Azure Storage Queue や、Windows Azure Service Bus の Queue や Topic など）や、ストレージサービス(Windows Azure Storage や SQL Azure）などを使って間接接続とします。
これにより、Web Role と Worker Role を疎結合にすることができます。
Windows Azure をご利用いただく場合には、この設計パターンを守ってアプリケーション構築を行っていただくと、ユーザーの負荷に応じて、Windows Azure の利用量を柔軟に設定することが可能になります（「これから Windows Azure を始める 開発者の皆様に知っていただきたい 8 つの真実 【Reloaded】～ ひとつめ」で紹介した、コンピューティング インスタンスの数やサイズの調整によって行います）。
例えば、Web Role と Woker Role を２インスタンスづつ使っていたサービスで、
Web Role を６インスタンス、Worker Role を４インスタンスの運用にしたり、
さらに、Web Role を９インスタンス、Worker Role を６インスタンスに変更する、といったことが自由にできるようになります。これは Windows Azure をご利用いただく場合に、最初から組み込まれた機能として利用いただける特長（機能）になります（そして、Web Role と Worker Role のインスタンス数をばらばらに自由に設定するために、「疎結合」にしておくことも重要になります）。
もちろん、ユーザーアクセスのピークが去った場合など、使用インスタンスの数を減らすことも柔軟に行うことが可能です。
Windows Azure は、クラウド プラットフォームとして、使用量に応じた課金となっているため、この特長をうまく利用していただければ、運用コストの最適化を進めることが可能かと思います。
なお、Windows Azure のコンピューティング サービスの利用料は、一時間単位での課金となっています。その他のサービス項目含め、Windows Azure の課金最適化に関しては「Windows Azure 用アプリケーション開発 Step-by-Step チュートリアル ガイド 第 4 章 Windows Azure 運用環境における課金」が読みやすい文章となっているかと思いますので、一読をお勧めいたします（※ Windows Azure のサービス利用料は適宜改定を行っております（データセンターの効率化により基本的に値段は徐々に下がってきています）。最新の価格情報に関しては、Windows Azure の Web サイトにおける価格情報を参照してください）。
さらにもう一つ。
アプリケーション開発者が、クラウドサービスを展開するにあたって、そのサービス(Web アプリケーション）を Stateless に設計しておくのは Windows Azure に限らず一つの定石だと思います。
ただそのようは場合であっても、実際のサービス運営にあたって問題になるのが、サービスへのロードバランシングの設定と、ストレージ部分を如何にスケールさせるか、の２点ではないでしょうか？
Windows Azure に関しては、前者の「ロードバランス」に関しては、コンピューティング サービスの基本的な機能として提供しており、Windows Azure を使っていただく限り、特に問題になることはないかと思います（より高度な要求として、ユーザーとデータセンターの物理的距離に対応するためにユーザーリクエストの振り分け等を行う必要がありますが、これは別の機能(Traffic Manager や CDN と呼ばれる仕組み）で解決策を提供しています）。
では、後者のストレージのスケール、に関してはどうでしょう。
まず Windows Azure では２つのストレージサービスを提供しています。具体的にはリレーショナルなデータベースサービスを提供する “SQL Azure” と、Key-Value 型のデータベースサービスを提供する “Windows Azure Storage” です。
SQL Azure に関しては、単純に SQL Server が Windows Azure のコンピューティングサービス上で動いている、わけではなく、クラウドサービスとして、３つのデータベースインスタンスを用いた冗長構成となっており、ロードバランシング等の機能もあらかじめ備えているようなサービスとなっています。
また、非常に大量のトラフィックを裁く必要がある場合は、SQL Azure の新機能である Fedaration の機能を使って複数のデータベースを論理的に統合して使用することが可能です（いわゆる “シャーディング。”George Huey による SQL Azure Federation 概要 ～ クラウドカバー Episode 69” あたりも参照ください）。
他方の Windows Azure Storage に関しては、KVS の特長を活かして開発者側で自由度の高いデータベース設計を行っていただくことが可能です（テーブル等の設計により目的のパフォーマンス ゴールに近づける設計を行っていただくことが可能です）。
このように、Windows Azure においては、アプリケーションがスケールすることを前提に Windows Azure 自体のサービス設計を行っており、開発者の皆様がアプリケーションを構築する際にそのメリットを活かした、柔軟なサービス利用を行っていただくことが可能になっています。
ということでみっつめにお伝えしたかった真実は、Windows Azure が “スケーラブル” なクラウドプラットフォームである、という事でした。
それでは、Enjoy Azure!