負荷分散セットアップで Redis キャッシュを使用した Azure App Service での効率的なセッション管理

従来のロード バランシング環境でのセッション

一般に、すべての Web アプリケーションではインメモリ セッション (RAM に保存されたデータ) を使用します。これは、専用 VM または共有ホスティング プランでアプリケーションをホストする従来のホスティング環境のほとんどでうまく機能します。

ただし、トラフィックが増加した場合は、複数の Web サーバーを作成し、ロード バランサーを使用してトラフィックを制御することで負荷分散を計画します。これらのシナリオでは、リクエスト (単一セッションに関連する) が複数のサーバーによって処理されるため、セッションは機能しません (同じサーバーで単一セッションのリクエストを処理することも可能ですが、推奨されていません)。解決策は、ロード バランシング環境のすべての Web サーバーからアクセスできる SQL サーバーにセッションを保存することです。

Azure 自動スケール環境でのセッション

これについての理論的な議論の代わりに、セッションを使用する小さなプログラムを開発して、Azure でセッションがどのように機能するかを見て、実際的な議論に直接移りましょう。

次の Web ページを含む Web サイトを作成し (MVC アプリケーションも作成できます)、以前の記事で示したようにアプリケーションをデプロイしてみましょう。

• Azure App Service - Visual Studio から既存のアプリケーションを構成する

ログイン.aspx

このページではユーザー名とパスワードのみを受け入れます。 「ログイン」ボタンをクリックすると、セッションを作成し、ログインしているユーザー名の値をセッションに保存し、ユーザーを「Default.aspx」にリダイレクトします。

このページには、Web サイトがホストされている仮想マシンの IP アドレス「10.202.116.91」も表示されることに注意してください。

デフォルト.aspx

このページには、セッション内の値に基づいて次のメッセージが表示されます。

Session に何らかの値がある場合、以下のスクリーン キャプチャに示すように、「管理者としてログインしているユーザー。10.202.116.91 にいます」と表示されます。

セッションに値がない場合は、以下のスクリーン キャプチャに示すように、「セッションは NULL です。10.202.116.91 にいます」と表示されます。

Login.aspx と Default.aspx の両方のサーバーの IPAddress が同じであることに注意してください。すべてのリクエストは同じサーバーにリダイレクトされます。

また、以下のスクリーン キャプチャのように、セッションは「ASP.NET_SessionID」という名前の Cookie を使用して維持されます。これは私たちのほとんどにとって馴染みのあるものです。

Web サイトへのトラフィックが増加し、それを 2 つのインスタンスに拡張したいとします。では、インスタンス数を 2 に増やしてみましょう。

注: 無料および共有レベルではインスタンス数を増やすことはできないことに注意してください。 App Service は「Basic」、「Standard」、または「Premium」レベルにある必要があります。

もう一度ログイン ページにアクセスし、ページを更新して複数回アクセスしてみましょう。ページを何度更新しても IP アドレスは変更されません。

同じ Web サーバーがページを提供していることがわかります。 2 つのインスタンスへのスケーリングを有効にしましたが、App Service は引き続き 1 つのサーバーからのリクエストを処理します。

負荷分散が有効になっており、他のサーバーが適切に利用されていないにもかかわらず、同じサーバーがリクエストを処理しているため、これは実際のシナリオでは問題になる可能性があります。

すべてのリクエストが処理される理由は、以下に示す ARR Cookie によるものです。詳細については、ここをご覧ください。

簡単に言うと、この Cookie には最初のリクエストが処理されたサーバー情報が含まれているため、同じセッションからの後続のリクエストはすべて同じ VM によって処理されます。

以下に示すように、App Service のアプリケーション設定に移動して、ARR Cookie 機能を無効にしましょう。

上のスクリーン キャプチャに示すように、「ARR アフィニティ」をオフにし、「保存」ボタンをクリックして変更を保存します。すべてのセッションをクリアするために、App Service を再起動してください。

これからは少し気をつけてください。次のいくつかの段落は少しわかりにくいです。

重要

ARR アフィニティをオフにすると、ARRAffinity Cookie の作成プロセスが無効になります。したがって、Cookie が無効になっている場合、リクエストは利用可能なサーバーのいずれかに送信される可能性があります。したがって、セッションが適切に維持されるという保証はありません。セッションは、リクエストが同じサーバーから提供されている場合にのみ機能します。いずれかのリクエストが（セッションが保存されているサーバーではなく）別のサーバーによって処理される場合、セッションは NULL になります。

次に、Web アプリに戻り、ログイン ページに移動して、新しい IP アドレス「10.202.174.84」に注目してください。 (あなたの場合、最初は以前と同じ IP アドレスが表示される可能性があります。ページを更新すると IP アドレスが変更されます。私の場合は、以下に示すように新しい IP アドレスを取得するためにページを 2 回更新しました。)

「ログイン」ボタンをクリックしても、フォームが 10.202.174.84 に投稿されることは保証されません。データを他のサーバーに投稿する可能性があります。私の場合は「10.202.116.91」です。

私の場合、上記のスクリーン キャプチャの「ログイン」ボタンをクリックすると、次の値を含むデフォルト ページが表示されました。

• IP アドレスは 10.202.174.84 です (これはログイン ページでも同じです)。
• セッションが NULL です。その理由は、ログインをクリックすると、セッションが保存されている他のインスタンス (「10.202.116.91」) にリクエストが送信された可能性があるためです。
• ページを数回更新します。
  

以下の点をお守りください。

• セッションには「admin」という値が含まれています。
• IP アドレスは 10.202.116.91 です。

したがって、ここでの結論は、自動スケーリング機能を使用してロード バランサーを構成すると、Azure App Service で「セッション」が期待どおりに機能しないということです。

ここに救世主がやって来ます。 Redis キャッシュプロバイダー。以下は、Azure 公式 Web サイトからの定義です。

Azure Redis Cache は、人気のあるオープンソースの Redis キャッシュに基づいています。これにより、Microsoft によって管理され、Azure 内の任意のアプリケーションからアクセスできる安全な専用 Redis キャッシュにアクセスできるようになります。

以下は、セッションが期待どおりに機能するために必要な手順です。

• Azure 管理ポータルから Redis キャッシュを作成します。
• Azure Redis Cache を使用するようにアプリケーションを構成します。
• セッションを使用します。

Azure 管理ポータルから Redis キャッシュを作成します。

以下に示すように、Azure 管理ポータルを使用して Redis キャッシュの作成を開始しましょう。

以下に示すように、Redis キャッシュの詳細を入力します。

上の画面キャプチャの「作成」ボタンをクリックします。 Redis キャッシュの作成には数分かかります。

Azure Redis Cache を使用するようにアプリケーションを構成する

作成したばかりの Redis キャッシュを使用するようにアプリケーションを構成しましょう。

上のスクリーン キャプチャに示すように、パッケージ マネージャー コンソールに移動し、「Install-Package StackExchange.Redis」コマンドを入力して、「Enter」をクリックします。

これで、必要なパッケージが正常にインストールされました。 (.NET Framework は 4 以降である必要があることに注意してください。)

アセンブリを使用するには、まず次の名前空間を Login.aspx ページと Default.aspx ページの両方に追加する必要があります。

StackExchange.Redis の使用;

「RedisConnection」という名前の新しいクラスをプロジェクトに追加しましょう。添付のプロジェクトを参照してください。

Redis Cache に接続するには、次の情報を ConnectionMultiplexer.Connect 関数に渡す必要があります。ポータルから取得しましょう。

• Redis キャッシュ URL。
• キー。

キーをコードに保存しないでください。話を簡単にするために、キーをソース コードに保存します。認証情報を保存する方法については、このページを参照してください。

これで、Redis キャッシュへの接続に使用できるクラスの準備が整いました。このクラスを使用して、Redis キャッシュにセッションを作成しましょう。

Login.aspx.cs ファイルを開き、次のコード行を置き換えます。

Session["login"] = this.txtUsername.Text.Trim();

IDatabase cache = RedisConnection.Connection.GetDatabase();
cache.StringSet("login", this.txtUsername.Text.Trim());

Default.aspx.cs を開いて、次のコード行を置き換えます。

protected void Page_Load(object sender, EventArgs e)
{
 if (Session["login"] == null)
 {
 Response.Write("Session is NULL. You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
 else
 {
 Response.Write("Logged in user is " + Session["login"] + ". You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
}

protected void Page_Load(object sender, EventArgs e)
{
 IDatabase cache = RedisConnection.Connection.GetDatabase();
 string strLoginValue = cache.StringGet("login");
 if (strLoginValue == null)
 {
 Response.Write("Session is NULL. You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
 else
 {
 Response.Write("Logged in user is " + strLoginValue + ". You are in " + Request.ServerVariables["LOCAL_ADDR"]);
 }
}

コードを Azure App Service にデプロイして変更を確認し、以下に示すようにログイン ページに移動しましょう。

IPアドレスに注目してください。 10.202.174.84です。 「ログイン」ボタンをクリックしてください。以下に示すように、Default.aspx ページが表示されます。

上記のスクリーン キャプチャでは、IP アドレスは異なりますが、ユーザー名「admin」が表示されていることに注目してください。これは、セッションが両方のインスタンスからアクセス可能な分散場所「Redis キャッシュ」に保存されているためです。

ここで、ページを複数回更新し続けます。 IP アドレスは変更されていますが、ユーザー名の値は変更されていないことがわかります。

それだけです。負荷分散環境にセッションを保存する方法を学習しました。 Redis Cache にはあらゆる種類のデータを保存できます。

記事を楽しんで読んでいただければ幸いです。フィードバックをお待ちしております。