AWS上でASP.NETのセッション管理（Amazon RDS for SQL Server 編）

○はじめに

ASP.NETアプリケーションを稼働させる上で、セッション管理はつきもの。弊社でもASP.NETのセッション管理が必要なアプリケーションが存在します。また、AWSで構成を組む上での単一障害点は避けるべきであるため、冗長化は必須です。
これをふまえ、今回は冗長化を見据えたAWS上でのセッション管理について説明していきます。

○IISにおけるセッション管理の種類と選定

セッション管理には主に4種類の方法があります。

1. InProc

インプロセスモードとして、アプリケーションを動かしているIISプロセス上でセッション管理。
IISの再起動やプログラム更新などで、プロセスが再起動するとセッション情報は消失してしまう。

2. StateServer

「ASP.NET状態サービス」というWindowsサービスを利用して管理。
インプロセスモードと異なり、サービスが独立しているのでアプリケーションとセッションでサーバーを分けることが可能。
複数のアプリケーションサーバーから一つの「ASP.NET状態サービス」を共通で利用することで、アプリケーション側の冗長化が実現できる。
ただ、セッション側である「ASP.NET状態サービス」そのものは冗長構成にはできず、再起動を行えばセッション情報は消失してしまう。

3. SQLServer

SQL Serverを使いセッション管理を行う。
データベースへの保存によりセッション情報の永続性を確保。
RDSであればマルチAZを採用することで冗長化も実現可能。

4. Custom

上記以外で独自に定義した方法でセッション管理を行う。
RedisやDynamoDBなどのNoSQLデータベースを利用したい場合などに選択する。

というわけで、冗長化を見据えるなら 3. SQLServerか4. Customの2択になりますが、ASP.NET側でデフォルトで提供され、かつ同じMicrosoft社製品であることから、信頼性も高いことを見こし、まずは3. SQLServerモードで進めていきます。また、AWS上での構築のため、データベースはAmazon RDS for SQL Serverを利用します。

○検証

まず予め、RDSインスタンスを用意します。今回用意するのは SQL Server 2017 Web Edition です。セッションDBの構築は .NET Framework に内包されている aspnet_regsql.exe から行います。
実行ファイルのあるディレクトリに移動し、コマンドを実行してみましょう。

cd C:\Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -sstype p -S [DBエンドポイント] -U [ユーザー名] -P [パスワード]

結果はエラーになってしまいました。どうやらRDS環境ではジョブ関連のスクリプト処理が拒否されるようです。この実行ファイルは、内部的には同ディレクトリにある InstallSqlState.sql を実行しており、中身を確認すると該当のジョブ作成スクリプトがありました。ジョブの内容としては、定期的にゴミデータ（期限切れセッション情報）を削除するプロシージャを呼び出すのみとなっており、無くても稼働自体には支障がなさそうです。
ひとまずジョブ部分をコメントアウトして再度試してみましょう。

コメントアウトしたら再度コマンドを実行してみます。

今度は正常に完了しました。
RDSサーバーを確認すると「ASPState」データベースが作成されています。

早速セッションDBを使ってみましょう。
IISでセッションの設定を行います。

アプリケーションにアクセスして早速セッションを発行してみます。

データベースにセッションが登録されていることが確認できました。
アクセスを繰り返すことでExpiresが更新されていたので問題なく機能しているとみていいでしょう。
今回省いたジョブにあった「定期的なプロシージャ実行」についても何かしら代替手段はありそうですね。

補足：

冗長化のためにAmazon RDS for SQL ServerをMulti-Az対応するためには、Standard以上が必要です。
Multi-Az対応のStandardはインスタンスの最小クラス帯であるdb.m5.largeでも月額約$1,550～が必要となります。（2019年12月時点調べ）

○まとめ

Amazon RDS for SQL Serverでは一部制限がある影響で、導入時に少し手を加える必要がある。
セッション管理をするためだけにSQLServer（Standard以上のMulth-AZ）を構築するのはランニングコスト的に割高なため、既に稼働しているSQLServerが存在し、そこに同居させる形であれば追加コストは抑えられる。
次回のブログでは、4. Customを使ってDynamoDBでのセッション管理を試してみたいと思います。

LINKcom ブログ