Windows Azure Platformのコンピューティングサービスを利用してWebアプリケーションを運用するには、Webロールと呼ばれる環境を使うのが一般的です。WebロールにはあらかじめInternet Information Services(IIS)やファイアウォール設定などが組み込まれており、IISの機能を使用してHTMLファイルやASP.NETアプリケーションなどを配信できます。

 複数のWebロールインスタンス(Webサーバーに相当)を設けて、クライアントからのリクエストをそれらWebロールインスタンスに割り振ることができます。それにより、Webサイトの拡張性や可用性を高められます。Windows Azure Platformには、ラウンドロビン方式によってリクエストを振り分けるロードバランサーが用意されています。

 ただし、そのロードバランサーでは、同一ユーザーのリクエストを同じインスタンスに割り振ることが保障されていません。このため、セッション情報を持たないインスタンスに処理が割り振られるといった問題が生じます。

 第3回では、この問題を回避するためのセッション状態プロバイダーという仕組みを用いて、セッションを維持する設計を取り上げます。

意図したコンテンツを配信できない

 本題に入る前に、Windows Azure Platformのロードバランサーによって、各インスタンスにリクエストが分散される際に起こる問題を整理しておきます(図1)。

図1●ロードバランサーによるリクエストの分散で起こる問題
図1●ロードバランサーによるリクエストの分散で起こる問題

 前述のように、同じユーザーのリクエストであっても、前回とは異なるインスタンスに処理が割り振られることがあります。セッション情報を一切持たない、完全にステートレスな通信であればそれでも構いませんが、セッション情報を持って、利用者ごとにコンテンツの中身を変更したり、ページ遷移を変えたりしたい場合には困ったことになります。初期状態では各インスタンスのローカル領域にセッション情報が保持されるので、セッション情報を持たないインスタンスに処理が割り振られてしまうと、意図した通りにコンテンツを配信したり、ページ遷移を制御したりできなくなるからです。

 クラウドコンピューティングのメリットの一つに、負荷の状況によって動的にインスタンス数を増減させる運用、つまりオートスケーリングを比較的簡単に実現できることがあります。しかし、各インスタンスがローカル領域にセッション情報を保持していると、インスタンスを減らす際に、削減対象のインスタンスが持つセッション情報を他のインスタンスに移す必要が生じます。これも問題になります。

共有エリアにセッション情報を置く

 セッション状態プロバイダー(以下、プロバイダー)を使うと、どのインスタンスからでも参照可能な領域、具体的にはストレージサービスやSQL Azureなどにセッションデータが保存されます。それによって、リクエストの割り振り先となるインスタンスが変更されても対処できたり、インスタンス数が減少する場合でもセッション情報を引き継げたりするのです。

 代表的なプロバイダーには、Training KitやIISに付属するもの、Windows Azure AppFabric Caching Serviceに用意されたものがあります(図2)。また、MSDNに掲載されたサンプルを基に自作しているケースも多いようです。

図2●Windows Azure Platformで使われる代表的なセッション状態プロバイダー
図2●Windows Azure Platformで使われる代表的なセッション状態プロバイダー
[画像のクリックで拡大表示]

SQL Azureを使うプロバイダーが人気

 現在よく使われているのは、性能とコストのバランスが良好な、IISに付属するASP.NET標準のプロバイダーです。ただし、SQL Server用のプロバイダーなので、SQL Azureの環境で用いるとASP.NETスクリプトの実行エラーが生じます。米Microsoftのサポートサイトに、このエラーの回避方法が示されています。

 MSDNにサンプルとして掲載されている、オンプレミスのIIS用プロバイダーを基に、自作するケースもよく見かけます。このサンプルは、AccessデータベースにODBC経由で接続するものなので、SQL Azureで使えるように修正する必要があります。動作を自由にカスタマイズできる点がメリットです。

 なお、どちらのプロバイダーを使う場合でも、セッションがタイムアウトした際に、何らかの方法で対象セッションの情報をSQL Azureから削除する必要があります。現状のSQL Azureには、そうした作業を自動実行するためのエージェント機能が搭載されていないからです。

ストレージやメモリーを利用するものもある

 ストレージサービスを用いるプロバイダーは安価に運用可能です。ただし、動作が遅いので大規模なシステムには向きません。小規模プロジェクトや開発段階でのデバッグ用など、手軽にセッションを維持したい用途に適しています。テーブルストレージを用いるプロバイダーのソースコードが、Windows Azure Platform Training Kit(米Microsoftのサイトから無償でダウンロード可能)の中に含まれています。プロバイダーのファイル名は「TableStorageSessionStateProvider.cs」です。
 2011年4月に、インメモリー型キャッシュサービスの「Windows Azure AppFabric Caching Service」がリリースされました。SQL Azureへのアクセス集中によってアプリケーションのレスポンスが低下しないよう、問い合わせ結果をキャッシュしておく用途などに使うものです。このキャッシュサービスには、専用のプロバイダーが提供されています。メリットは、メモリーを使うのでセッション情報を高速に取得できることです。半面、利用コストはSQL Azureやストレージサービスを用いるプロバイダーよりも高くなります。

冨田 順(@harutama)
富士通システムソリューションズ
Windows Azureを中心に、各種クラウドプラットフォーム上にシステムを構築するための研究研究開発を行っている。Microsoft MVP for Windows Azure。