- - PR -
ASP.NET でのセッション管理について
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-09-15 23:29
いつもお世話になっております。
今回ご意見いただきたいと思いますのが、ASP.NET のセッション管理についてです。 ログインによってコンテンツを閲覧できるサイトがあると、 一度ログインをするとセッションが有効な間は、ログイン操作をせずに コンテンツを閲覧することができます。 サーバ１台であれば、ログインしたかしないかをセッションＩＤで識別できると 思うのですが、規模の大きなシステムでロードバランサを使って複数のサーバに 分散したときは、リクエストがつど、違うサーバに行く可能性があり、 セッションＩＤが毎回異なり、毎回ログイン操作をしないといけない状態になります。 さて、ここからが本題ですが、こうしたクラスタ構成のサーバで、 ASP.NET のシステムを動かす場合、どういったセッション管理をするのが ベストなのでしょうか？ 最悪は、セッション管理を自前で実装しようと考えておりますが、 ASP.NET の技術だけで実現できるなら、そちらを使いたい次第です。 すみませんが、ご意見お願いします。 | ||||||||
|
投稿日時: 2007-09-16 00:15
ASP.NET のセッション情報は、DB に持たせることも可能です。 へプルに解説があるので、読んでみてください。 | ||||||||
|
投稿日時: 2007-09-16 00:55
ロードバランサに依るでしょう。 毎回違うサーバーに接続するのもありますし、 一定期間同じのに接続するようになってるのもありますし。
これだけの質問内容だと ベストの定義も検証方法もわかりません。 「時と場合による」「case by case」という情報量ほぼ0の回答になってしまいます。 もともとステートレスなHTTPにASP.Netが無理にステートを付与してるわけですから、 無理があるのは当然で、 どのレベルで対応すべきか、どう対応するのかは当然、対象のシステムに依ります。 SQLサーバーとかにセッションもたせてもいいですし、 そもそもセッションが必要ないシステムを作ってもいいですし、 他にもいろいろな手があります。 私なら、（ASP.Netの技術ではないですが、）バランサを変えます。 毎回違うサーバーに接続させるようなバランサでは、 ステートを付与したい時に必ず問題になります。 そんなバランサの下ではServletやASP.NetなどのWebアプリを使う気になれません。 DBにセッションを保存して共有するのは場合によってはよい解決策だと思いますが、 場合によっては望ましくありません。 せっかくバランサで分けたリクエストをまた集約するんですから、 ダメな場合もあるのは当然ですよね。 本当は、 どのくらいリクエストがあるのか、 どのくらいの帯域があるのか、 どのくらいのレスポンス速度が必要なのか、 どのくらいの処理時間がかかるのか、 少なくともオーダー程度は見積もって決定すべきです。 | ||||||||
|
投稿日時: 2007-09-16 01:03
別のマシンにセッション管理をさせる方法としては、SQL Serverに保存させる方法と、もう一つステートサーバを使う方法があります。
詳しくはヘルプなどのドキュメント参照になりますが、以下にも軽く説明があります。 http://www.atmarkit.co.jp/fdotnet/aspnet/aspnet15/aspnet15_02.html どちらの方法にせよ、ロードバランサの裏で負荷分散されたWebサーバの後ろで使うならそこがボトルネックになる可能性はあります。 ますは、SQL Serverとステートサーバ、それぞれについて調べてみてはいかがでしょうか。 | ||||||||
|
投稿日時: 2007-09-16 10:06
こんにちは。
ご意見、ありがとうございます。 ＞ 渋木宏明 様 確か、SQLサーバでセッション情報を管理する機能ですよね？ でもそれには SQLサーバ 専用のサーバを１台構えなければならないですよね。 ＞ れい 様 専門的なご意見、どうもありがとうございます。 アプリケーションサーバ１台の構成で運用していたシステムがありますが、 アクセスが集中すると、ＣＰＵが常に１００％の状態となってしまい、 不安定な状況に陥ってしまいます。 そこで、ロードバランサを導入してサーバ自体を分散することを考えています。 サーバ自体は今後、状況次第で増加することが予想されますが、 なにぶん、インターネット接続を考えているだけに、接続数は未知数です。 アクセス数が増えたりした場合は、サーバを増設することを検討しておりますが、 増設した場合でもセッション情報を維持するように、と技術を調査していたところでした。 ＞ kiyokura 様 SQLサーバを使った方法は予算的にも、ちょっぴり難しい状況ですが、 ステートサーバは使えそうな気がしますね。 ただ、Ｎ台のサーバのバックグラウンドで働いている１台のセッション管理用の サーバへの負荷は大きそうですね。 ありがとうございました。 | ||||||||
|
投稿日時: 2007-09-16 12:05
標準のステートサーバは同一マシン内の IIS としか連携できなかったと思うんですけど？ 複数 Web サーバ間でセッションを共有するための手段として、標準で用意されているのは SQL Server を使用する方法だけだったような気がするんですが、違ったかな？ まぁ、ステート管理のプロバイダを自作する、とかなら話はまったく別ですが。 どっちにしろ、他マシンと共有する情報を Web サーバとして使用しているマシンのどれかに同居させるような運用はあんまり感心しない（特に負荷がどうこういう話であるなら、Web サーバが稼動しているマシンの余計な負担は減らすべき）ので、結局は別に１っちょマシンを確保しないと駄目なんじゃないかと。
複数の Web サーバが、バアックヤードのたった１台の DB にアクセスするなんてのはよくあるパターンです。 それで持たないようなら DB をクラスタ化するなどの対応もありますが、Web サーバからみた見かけ上の DB インスタンスは１個に見せるのがよくあるパターンでしょう。 で、ビジネスロジックの処理が伴わない、ごく単純なセッション管理だけの負荷なら大したことはありません。 逆に言えば、それくらいの負荷が問題になるようなら、負荷の見積もりが甘過ぎで、システム設計からやりなおすべきなんじゃないかと。 ロードバランサーも結構いいお値段するはずなので、ひょっとしたら Web サーバをアップグレードするだけの方が当座の出費は安く上がる場合もあるかもしれません。 [ メッセージ編集済み 編集者: 渋木宏明(ひどり) 編集日時 2007-09-16 15:17 ] | ||||||||
|
投稿日時: 2007-09-16 20:51
私もれいさんと同じ考えですね。
確かにSQLサーバやステートサーバを使った方法がありますが、 参照ファイル（一時ファイル）を必要とする処理が発生した場合、対処が難しくなります。 まずは、ロードバランサーの機能(設定)を確認された方がよいのではないでしょうか？ 細かな機能については詳しく知りませんが、クライアントのIPを保持して同じサーバに振り分けたり、クッキーを投げつけて１度通ったクライアントを別サーバに振り分けさせないセッション管理にやさしいロードバランサーの設定があるものもあります。 | ||||||||
|
投稿日時: 2007-09-17 21:05
最近あった、ASP と ASP.NET でセッション情報を共有したい、ってやつでできそうですね。 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。