Windows Azure Cloud Service(15)複数のVM InstanceシーンでのASPの取り扱いNET Session
5408 ワード
《 Windows Azure Platformシリーズ記事ディレクトリ 》
Update 2015-04-06
筆者はAzureでSessionをどのように処理するかをまとめました.最新のドキュメントを参照してください.
Windows Azure HandBook(4)Windows Azureがセッションをどのように処理するかを分析する
Update 2015-03-10
複数のInstanceがSessionを保持する方法については、マイクロソフトの公式提案は以下の通りです.
1.Redis Cacheの使用
2.PaaSのCloud ServiceではIn-Role Cacheを使用してセッションを保持
3.セッションをSQL Server VMに保存し、Always-Onを構成して高可用性を実現します.
また、Microsoftの公式文書http://support.microsoft.com/kb/2006191によると
Aspについて.Netアプリケーションでは、MicrosoftはSQL Azureにセッションを保存することをサポートしていません.
The workarounds provided here do not work for ASP.Net SQL Session State Management features. Microsoft does not support SQL Session State Management using SQL Azure databases for ASP.net applications.
Update 2015-03-10以下は既にretired
従来のASP.NETアプリケーションはステータスなしですが、ユーザー名やパスワードの保存など、Sessionを使用してユーザーステータスを保存できます.また、一般的には、すでに導入されているアプリケーションの論理ビジネスの多くは、ローカルエリアネットワークのWebサーバに保存されているSessionステータスに基づいています.
単一コンピューティングノード(1 instance)のWindows Azureホスティングサービスを導入すると、Sessionはホスティングサーバに保存されます.しかし、これは問題に直面します.前の章で述べたように、Fabric Controlは計算ノードの実行状態を自動的に監視します.導入したシングルインスタンスのコンピューティングノードでハードウェア障害、ダウンタイムなどの問題が発生した場合、Fabric Controlは自動的に異なるサーバを検索し、コンピューティングノードを再起動します.それは私たちの管理サービスが短時間で正常に動作し、サービスを提供できず、信頼性が低下します.
Windows Azureの信頼性を向上させるために、マイクロソフトは1つの管理サービスに少なくとも2つのinstanceが必要であることを提案しています.これにより、あるコンピューティングノードが問題が発生して正常なサービスを提供できない場合、別のコンピューティングノードが継続的に動作し、サービスを提供することを保証できます.
Windows Azureのinstance countを2つのコンピューティングノード(例えばAとB)に設定したと仮定すると、Windows Azureは負荷分散(Load Balance,LB)を自動的に提供するため、我々はまた知っている.このような問題に直面する:我々はある時間内にすべての業務をコンピューティングノードAによって処理され、時間が経つとAは比較的複雑なコンピューティングサービスを処理するため、LBは我々が要求した処理を直接コンピューティングノードBに渡して処理する.しかし、A計算ノードに保存されているSession状態が失われました!計算ノードBは前のセッションを知らない.
したがって、既存のWebアプリケーションをWindows Azureプラットフォームに移行するには、Sessionの処理に非常に注意する必要があります.
一.1つのコンピューティングノード(1 instance)のWindows Azureホスティングサービスでは、既存の「Session[SESSION_NAME_KEY]」を使用してビジネスロジックを正常に処理できます.しかし、コンピューティングノードがハードウェア障害などの問題に遭遇する可能性があるため、信頼性が低下します.
二.2つ以上のコンピューティングノード(2 instance or more)のWindows Azureホスティングサービスでは、Sessionの永続化を保証するために、既存のWebアプリケーションで修正する必要があります.
(1)Azure Table Storageを使用してセッションを保存し、サンプルコードをここでダウンロードできます.
Windows Azure Platform Training kitを検索してこのプロバイダをダウンロードできます.このキットには、AspProvidersというサンプルアイテムがあります.このプロジェクトを直接ソリューションに追加したり、プログラムセットリファレンスを使用して、そのDLLをプロジェクトに追加したりすることができます.
このプログラムセットを引用したら、webを修正しなければなりません.configファイル.プロファイルを開き、要素を見つけます.既存の構成を削除し、次のコードを貼り付けます.そうするときは、本当のアプリケーション名を書いてください.
-私たちのセッションを対象としてWindows AzureのTableに保存し、必要に応じて取り出して使用するのが原理です.
メリット:
-価格はSQL Azureより安く、Windows Azure Storageは1 GBあたり毎月0.15ドルしかかかりません.
欠点:
-マイクロソフトの公式サポートは受けられません.
-性能があまり良くないかもしれません(筆者が試してみましたが、時々性能が悪い場合があります).
-以前に使用したセッションをクリーンアップする必要があります.
(2)SQL Azure Session Providerを使用してSessionを保存します.具体的にはMSDNブログを参照してください.
-私たちのセッションを対象としてSQL AzureのTableに保存し、必要に応じて取り出して使用するのが原理です.
メリット:
-Table Storageを使うより値段が安いとは言えませんが、耐えられます.
欠点:
-マイクロソフトの公式サポートは受けられません.
-以前に使用したセッションをクリーンアップする必要があります.
Sessionのたびに新しいテーブルを作成してSessionを保存します.後続のセッションリクエストに対して、このテーブルがすでに存在するかどうかをクエリーします.したがって、セッションがタイムアウトすると、タイムアウトしたセッションテーブルを削除する必要があります.期限切れのセッションを自動的に削除するには、Windows Azure Worker Roleを使用してテーブルを削除するアクションをほとんど実行します.
(3)AppFabric Caching
AppFabric Cachingは、実際にはマイクロソフトが推奨するオプションであり、マイクロソフトの公式サポートを受けています.AppFabric Caching分散メモリのキャッシュサービス.Windows Server AppFabric Cachingは自動構成に基づいています.
メリット:
-メモリにキャッシュされ、アクセス速度が非常に速い-Microsoft公式サポート
欠点:
-価格は上記の2つの方法に比べて高いです.最初の価格は128 M 45ドルで、最高4 GB 325ドルです.
参考資料:Various Options to Manage Session State in Windows Azure
Update 2015-04-06
筆者はAzureでSessionをどのように処理するかをまとめました.最新のドキュメントを参照してください.
Windows Azure HandBook(4)Windows Azureがセッションをどのように処理するかを分析する
Update 2015-03-10
複数のInstanceがSessionを保持する方法については、マイクロソフトの公式提案は以下の通りです.
1.Redis Cacheの使用
2.PaaSのCloud ServiceではIn-Role Cacheを使用してセッションを保持
3.セッションをSQL Server VMに保存し、Always-Onを構成して高可用性を実現します.
また、Microsoftの公式文書http://support.microsoft.com/kb/2006191によると
Aspについて.Netアプリケーションでは、MicrosoftはSQL Azureにセッションを保存することをサポートしていません.
The workarounds provided here do not work for ASP.Net SQL Session State Management features. Microsoft does not support SQL Session State Management using SQL Azure databases for ASP.net applications.
Update 2015-03-10以下は既にretired
従来のASP.NETアプリケーションはステータスなしですが、ユーザー名やパスワードの保存など、Sessionを使用してユーザーステータスを保存できます.また、一般的には、すでに導入されているアプリケーションの論理ビジネスの多くは、ローカルエリアネットワークのWebサーバに保存されているSessionステータスに基づいています.
単一コンピューティングノード(1 instance)のWindows Azureホスティングサービスを導入すると、Sessionはホスティングサーバに保存されます.しかし、これは問題に直面します.前の章で述べたように、Fabric Controlは計算ノードの実行状態を自動的に監視します.導入したシングルインスタンスのコンピューティングノードでハードウェア障害、ダウンタイムなどの問題が発生した場合、Fabric Controlは自動的に異なるサーバを検索し、コンピューティングノードを再起動します.それは私たちの管理サービスが短時間で正常に動作し、サービスを提供できず、信頼性が低下します.
Windows Azureの信頼性を向上させるために、マイクロソフトは1つの管理サービスに少なくとも2つのinstanceが必要であることを提案しています.これにより、あるコンピューティングノードが問題が発生して正常なサービスを提供できない場合、別のコンピューティングノードが継続的に動作し、サービスを提供することを保証できます.
Windows Azureのinstance countを2つのコンピューティングノード(例えばAとB)に設定したと仮定すると、Windows Azureは負荷分散(Load Balance,LB)を自動的に提供するため、我々はまた知っている.このような問題に直面する:我々はある時間内にすべての業務をコンピューティングノードAによって処理され、時間が経つとAは比較的複雑なコンピューティングサービスを処理するため、LBは我々が要求した処理を直接コンピューティングノードBに渡して処理する.しかし、A計算ノードに保存されているSession状態が失われました!計算ノードBは前のセッションを知らない.
したがって、既存のWebアプリケーションをWindows Azureプラットフォームに移行するには、Sessionの処理に非常に注意する必要があります.
一.1つのコンピューティングノード(1 instance)のWindows Azureホスティングサービスでは、既存の「Session[SESSION_NAME_KEY]」を使用してビジネスロジックを正常に処理できます.しかし、コンピューティングノードがハードウェア障害などの問題に遭遇する可能性があるため、信頼性が低下します.
二.2つ以上のコンピューティングノード(2 instance or more)のWindows Azureホスティングサービスでは、Sessionの永続化を保証するために、既存のWebアプリケーションで修正する必要があります.
(1)Azure Table Storageを使用してセッションを保存し、サンプルコードをここでダウンロードできます.
Windows Azure Platform Training kitを検索してこのプロバイダをダウンロードできます.このキットには、AspProvidersというサンプルアイテムがあります.このプロジェクトを直接ソリューションに追加したり、プログラムセットリファレンスを使用して、そのDLLをプロジェクトに追加したりすることができます.
このプログラムセットを引用したら、webを修正しなければなりません.configファイル.プロファイルを開き、要素を見つけます.既存の構成を削除し、次のコードを貼り付けます.そうするときは、本当のアプリケーション名を書いてください.
<!--SessionState Provider Configuration-->
<sessionState mode="Custom" customProvider="TableStorageSessionStateProvider">
<providers>
<clear/>
<add name="TableStorageSessionStateProvider"
type ="Microsoft.Samples.ServiceHosting.AspProviders.TableStorageSessionStateProvider"/>
</providers>
</sessionState>-私たちのセッションを対象としてWindows AzureのTableに保存し、必要に応じて取り出して使用するのが原理です.
メリット:
-価格はSQL Azureより安く、Windows Azure Storageは1 GBあたり毎月0.15ドルしかかかりません.
欠点:
-マイクロソフトの公式サポートは受けられません.
-性能があまり良くないかもしれません(筆者が試してみましたが、時々性能が悪い場合があります).
-以前に使用したセッションをクリーンアップする必要があります.
(2)SQL Azure Session Providerを使用してSessionを保存します.具体的にはMSDNブログを参照してください.
-私たちのセッションを対象としてSQL AzureのTableに保存し、必要に応じて取り出して使用するのが原理です.
メリット:
-Table Storageを使うより値段が安いとは言えませんが、耐えられます.
欠点:
-マイクロソフトの公式サポートは受けられません.
-以前に使用したセッションをクリーンアップする必要があります.
Sessionのたびに新しいテーブルを作成してSessionを保存します.後続のセッションリクエストに対して、このテーブルがすでに存在するかどうかをクエリーします.したがって、セッションがタイムアウトすると、タイムアウトしたセッションテーブルを削除する必要があります.期限切れのセッションを自動的に削除するには、Windows Azure Worker Roleを使用してテーブルを削除するアクションをほとんど実行します.
(3)AppFabric Caching
AppFabric Cachingは、実際にはマイクロソフトが推奨するオプションであり、マイクロソフトの公式サポートを受けています.AppFabric Caching分散メモリのキャッシュサービス.Windows Server AppFabric Cachingは自動構成に基づいています.
メリット:
-メモリにキャッシュされ、アクセス速度が非常に速い-Microsoft公式サポート
欠点:
-価格は上記の2つの方法に比べて高いです.最初の価格は128 M 45ドルで、最高4 GB 325ドルです.
参考資料:Various Options to Manage Session State in Windows Azure