[Seasar-user:21711] Re: Tomcatでのセッションレプリケーション実装方法について

[Hiroyuki Ohnaka]

大中です。

> もともとは、「負荷分散」を目的として、
> 振り分け先APサーバを固定化させなくても良いようにActive-Active方式で
> セッションレプリケーションを検討していましたが、
> tomcatとteedaを使用したセッションレプリケーションでは、
> 上記の理由で不整合が起こる可能性があるという認識でよろしいでしょうか。

そうですね、自分の経験した例だとログイン画面からログイン処理後、
リダイレクトした後次画面遷移するはずが何回に一回かログイン画面に戻る、
という事象で、スティッキーセッションを入れると現象が起きなくなったので、
そう判断しました。Teedaの場合どうかは、検証してほしいんですが...

> > Tomcatのセッションレプリケーションはデフォルトがリクエストに対して非同期のため、
> ・・・・とありますが、リクエストに対して同期をかけるように設定可能か、ご存知でしょうか。

http://tomcat.apache.org/tomcat-6.0-doc/config/cluster.html の

channelSendOptions になります。

デフォルトはSEND_OPTIONS_ASYNCHRONOUS です。

このあたりも参照ください。
http://kks2107.blog120.fc2.com/blog-category-7.html

> 負荷分散するために、上記以外にも何か良い方法はありますでしょうか。

セッションアプリケーションを同期モードにすればいいんですが、これが
応答時間にどれくらい影響するか次第ですね。

通常のWebアプリケーションだと、セッションアプリケーションを同期モードに
した上で、セッション属性に変更があった場合だけsetAttribute してやればいいんですが、

Teeda(というかJSF)は画面の状態の保持にセッションを多用するので、これが
難しいんですよね。
(つまり、リクエストの度にセッション属性に操作が走る)

JSFには javax.faces.STATE_SAVING_METHOD というオプションがあって、
このオプションで client を指定すると、画面の状態をセッションでなく、
画面(ブラウザ)側でBASE64エンコードして保持するので、これを使えば
いいのかもしれませんが、自分はこのオプションを使ったことがないので、
このオプションを使ったときにアプリケーションがどのような挙動になるか
という点について、知識を持っていません。

> > これを避ける確実な方法は、スティッキーセッションを併用して、セッションレプリケーションは
> > サーバーに障害が起きた場合の保険および、デプロイ時のセッション継続の手段として
> > 使う、ということになります。
>
> 上記の「スティッキーセッション」とは、APサーバの上のLBで設定して、
> 同一セッションの間は、同じAPサーバに振り分けるという認識でよいでしょうか。

はい、セッションID(もしくはurlリライト)で振り分けるパターンです。


> お世話になっております。
> 西村です。
>
> 大中さん、ありがとうございます。
>
> > Tomcatのセッションレプリケーションはデフォルトがリクエストに対して非同期のため、
> > TeedaのようなPageの処理の後リダイレクトするのが原則なフレームワークの場合、
> > リダイレクトした後にリクエスト先のtomcatに(レプリケーションがまだ終わっていないため)
> > セッション情報がとどかず、セッションの状態に不整合が起きる可能性があります。
> > (自分が経験したのはTeedaでないフレームワークのため、あくまで可能性ですが...)
>
> もともとは、「負荷分散」を目的として、
> 振り分け先APサーバを固定化させなくても良いようにActive-Active方式で
> セッションレプリケーションを検討していましたが、
> tomcatとteedaを使用したセッションレプリケーションでは、
> 上記の理由で不整合が起こる可能性があるという認識でよろしいでしょうか。
>
>
> > Tomcatのセッションレプリケーションはデフォルトがリクエストに対して非同期のため、
> ・・・・とありますが、リクエストに対して同期をかけるように設定可能か、ご存知でしょうか。
>
>
> > これを避ける確実な方法は、スティッキーセッションを併用して、セッションレプリケーションは
> > サーバーに障害が起きた場合の保険および、デプロイ時のセッション継続の手段として
> > 使う、ということになります。
>
> 上記の「スティッキーセッション」とは、APサーバの上のLBで設定して、
> 同一セッションの間は、同じAPサーバに振り分けるという認識でよいでしょうか。
>
> 負荷分散を目的としてActive-Active方式の構成とする場合、
> 「スティッキーセッション」を利用して振り分けされるAPサーバを固定化させる必要があり、
> tomcatでのセッションレプリケーションは、あくまでも片方のサーバがダウンしたときのための
> 保険的な役割（※）として使用する方が良いということですよね。
>
> ※サーバがダウンした場合にセッションレプリケーションが行われても、
> 　tomcatとteedaの仕様上不整合が起きる可能性がある為。
>
> 負荷分散するために、上記以外にも何か良い方法はありますでしょうか。
>
>
>
> > 大中です。
> >
> > Tomcatのセッションレプリケーションはデフォルトがリクエストに対して非同期のため、
> > TeedaのようなPageの処理の後リダイレクトするのが原則なフレームワークの場合、
> > リダイレクトした後にリクエスト先のtomcatに(レプリケーションがまだ終わっていないため)
> > セッション情報がとどかず、セッションの状態に不整合が起きる可能性があります。
> > (自分が経験したのはTeedaでないフレームワークのため、あくまで可能性ですが...)
> >
> > これを避ける確実な方法は、スティッキーセッションを併用して、セッションレプリケーションは
> > サーバーに障害が起きた場合の保険および、デプロイ時のセッション継続の手段として
> > 使う、ということになります。
> >
>
> _______________________________________________
> Seasar-user mailing list
> Seasar-user ＠ ml.seasar.org
> https://ml.seasar.org/mailman/listinfo/seasar-user