このシリーズでは、ウェブで注文を受け付ける WCF のサービスアプリケーションや、工場側のワークフロー (WF) と連携した WCF のサービスなど、いくつかのシナリオを作成してきました。
今回、工場側のワークフロー (WF) と連携した WCF のサービスを例に、Windows Server の負荷分散の設定がアプリケーションに対してどのように影響するかをみて、それに対処する方法について学んでいきます。

工場側のワークフロー (WF) と連携した WCF のサービスに対してユーザインタフェースを使用して処理をおこなった場合、例えば、「現在実行中のワークフローインスタンスがどの状態になっているのか ?」といったことをアプリケーションがおぼえていて、継続してステップを実行することができていました。
そのためにどのような設定をおこなったか、もし忘れてしまわれた方は、第 3 章「アプリケーションの開発」の「UI の開発」をみて再度おさらいをしておいてください。

簡単におさらいをすると、アプリケーションの中では、以下のような処理で “状態の維持” をしていました。

1. 利用者がブラウザを使ってアクセスする場合にはHTTPが使用されます。
   TCP 上に実装されている HTTP では、電話のように接続状態を保持した通信ではなく、リンクをクリックしたり、ボタンを押したりするたびに、新しい要求 (Request) をおこなって応答 (Response) を受け取るというスタイルでの通信をおこないます。
   こうした環境でも “状態の維持” を可能にするため、Internet Information Services (IIS) のようなアプリケーション サーバでは セッション (Session) と呼ばれるユーザごとに固有のオブジェクトが (一定時間の間) サーバのメモリ中に作成され、ブラウザには (クッキー (Cookie) と呼ばれる仕組みを使って) その「セッション」の識別子が返されて、次回以降、ブラウザから接続した場合に常に同じ「セッション」が利用されるよう保障しています。

2. ユーザ インタフェースを処理する Web サーバ (IIS) から、さらにその奥の WCF サービスが稼働している Web サーバ (IIS) へ処理を投げる場合でも同じことが言えます。WCF サービスが稼働している Web サーバ側でもサーバのメモリ中にワークフロー インスタンスを WCF サービスとして稼働させ、UI を処理する Web サーバ側から WCF の Web サーバ側に処理を要求 (Request) する際に、どのワークフロー インスタンスを使用するかを指定する必要があります。
   こうしたことが可能となるように、WCF の場合にはコンテキスト (Context) と呼ばれる仕組みが存在し、同じコンテキストを使って WCF サービスに要求をおこなうと常に同じ WCF サービスのインスタンス (および、その中で実行しているワークフロー インスタンス) への接続を保証してくれていました。

3. UI を処理する Web サーバ側では、この「コンテキスト」の保持をおこなっておくために、上述したメモリ中の「セッション」の中に「コンテキスト」を入れておき、毎回同じコンテキストを使って WCF サービスに接続することで、同じワークフロー (WCF/WF 統合サービス) のインスタンスに接続をおこなっていました。

さて、動きがおさらいできたところで、この UI 側の Web サーバ (IIS) や、WCF サービス側の Web サーバ (IIS) の双方に、第 5 章で述べた「負荷分散の設定」がおこなわれた場合を連想してみてください。

例えば、上記 1 の ”メモリ中のセッション” も、負荷分散によりマシンが切り替わってしまうと、メモリ中に存在していたはずのセッションにアクセスできなくなります。WCF/WF 統合サービスの稼働している Web サーバ側でも、マシンが切り替わってしまえば、存在していたはずの “メモリ中のワークフローインスタンス” にアクセスできなくなります。 つまり、このままでは負荷分散を設定しても、アプリケーションは稼働しないという事態に陥ります。

さらに、今回のようなワークフローを使用したシナリオでは他の問題も発生します。
例えば、ワークフローの処理を途中でやめて Web アプリケーション (ブラウザ) を終了した場合に、再度何日か経過して続きから実施したいケースを考えてみてください。その間にワークフローがメモリ中に存在していれば問題は発生しないかもしれませんが、サーバ マシンはメンテナンスのために毎日再起動をおこなうかもしれません。
さらに、こうした実行途中のワークフローをすべてメモリ中に長時間ロードしたままにしておくと、ユーザが少し増えただけでも大幅なメモリリソースが消費されることになるでしょう。

いくつか例を述べましたが、いずれにせよ、今の設定のままでは、いろいろと問題を発生させる要因になることは容易に想像できるでしょう。

「アプリケーション サーバ」と呼ばれるアプリケーションをホスティングする専用のサーバ環境では、こうした負荷分散などの構成に対して、みなさんが作成したアプリケーションが問題なく稼働できるように、例えば、状態情報を永続化用の専用のデータベースに保持したり、サーバをまたがってメモリからメモリに状態情報のレプリケーションをおこなったりなどの、専用の仕組みが存在しているのが一般的です。

そして、今回のように IIS と .NET Framework (ASP.NET) を使用したアプリケーションにおいても、無論、こうした点に配慮した専用の仕組みが用意されています。今回は、この用意された仕組みを使用して、アプリケーション本体のビジネス ロジックを変更することなく、負荷分散や上述したさまざまな問題に対処をおこなうための具体的方法についてご説明します。

なお、IIS / .NET Framework では、ここでご説明している方法以外にも、例えば、

• クッキー (Cookie) の有効化/無効化などのブラウザの設定に依存しない状態維持のための設定方法
• SQL Server 以外へのセッション情報の永続化など、セッション状態を管理する機能のカスタムな実装

など、さまざまな構成や拡張をおこなうための仕組みが用意されています (特にワークフロー サービスでスケーラビリティを維持するためには、シナリオに応じてカスタムの永続化サービスなどを構成する必要があります)。 ここではこれらの詳細な内容までは踏み込みませんが、基本をご理解された方は、下記の関連技術情報も是非参考にしてください。

アプリケーションの負荷分散への対応

アプリケーションの負荷分散への対応

• 【コード】変更した構成 (WCF/WF 統合サービスの場合)
• 【コード】変更した構成 (単純な WCF サービスの場合)

• ASP.NET UI 側で使用したセッション状態データベース

  system drive\Windows\Microsoft.NET\Framework\v2.0.50727\InstallSqlState.sql

  (以下は、アンインストール時 – このデータベースを使用している IIS を再起動してください)

  system drive\Windows\Microsoft.NET\Framework\v2.0.50727\UninstallSqlState.sql

• WCF / WF 連携サービスで使用した WF の永続化データベース

  system drive\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\JA\ SqlPersistenceService_Schema.sql
  system drive\Windows\Microsoft.NET\Framework\v3.0\Windows Workflow Foundation\SQL\JA\ SqlPersistenceService_Logic.sql

• 単純な WCF サービスの永続化プロバイダデータベース (Durable WCF サービス)

  system drive\Windows\Microsoft.NET\Framework\v3.5\SQL\ja\SqlPersistenceProviderSchema.sql
  system drive\Windows\Microsoft.NET\Framework\v3.5\SQL\ja\SqlPersistenceProviderLogic.sql