APサーバとしてTomcatの複数台でのクラスタリング構成をする場合、
セッションの扱いってどうすんだろう。。ということでざっくり調べてみた。
つかTomcatに限った話じゃねえな。糞無知すぎる。
同一のセッションアクセスを同一のノードに振り分ける、という方法。
Tomcat側は特に何もしなくても、LB側が対応できればよい。
なので例えばApacheがLBとして機能しているならmod_jkとかのsticky sessionモードにする。
技術的雑談-複数のTomcatを立ち上げてmod_jk経由でロードバランスさせる - Tsubasa's HomePage
LBがやればよいので、別にこれWebサーバである必要もなくて、
BIG IPとかLVSみたいなL4レベルで対応することもできる。
BIG IP 機能紹介 | 兼松エレクトロニクス KEL
lvsでsession persistence(セッションパーシステンス) - うまい棒blog
何をみて判断しているかはいろいろ方法があって、IPとかCookieとかが多いと思うがSSLのセッションIDとかURLとかっていうのもあるらしい。
まあでもCookieがポピュラーなのかな。
この方法のデメリットは、アクセスノードがユーザにとってはシングルポイントになるのでそのノードが落ちたらセッション情報が消失すること。再起動にもモロ影響を受ける。
あとLBにアクセスの判定っていう余計な？処理が増えるためそこでもパフォーマンスが低下するってところか。
ならセッション情報をレプリしちゃおうぜ！っていう方法。
これはTomcatのマニュアルに詳しい解説がある。
The Apache Tomcat 5.5 Servlet/JSP Container - Clustering/Session Replication HOW-TO
5.5ですまん。
方式はいくつかあるが要はセッション情報をコピーしてクラスタリングしている全てのノードで同じセッション情報をもつやり方。(all-to-all)
これならどのサーバに振られても同じセッション情報を参照できるので
今までアクセスしてたノードが落ちようが再起動かかろうが問題ない。
ただこの方法にも問題がある。
一つはセッション情報をいちいち全台にレプリするためトラフィックがはんぱないことになる。
さらには全台のユーザのセッション情報を全て持つので、メモリに抱える量も当然多くなる。
じゃあ全台にレプリしなきゃいいんでしょ。って方法もある。
クラスタリングしてるノードをグループに分けて、そのグループ内だけでセッションレプリケーションを行う方法。
[ThinkIT] 第2回：Tomcatのクラスタ設定 (1/4)
たしかにこの方法なら冗長性も確保できる。
けど結局LBで処理しなきゃいけないし、グループの規模とかそういうチューニングを一歩間違えると前述の二つの方法のデメリットを両方引く可能性もある。
なにより複雑っす。。グループとかのルールが必要だし。ルール設定して振り分けみたいなのは事故る。
ああもう身も蓋もねえ。。
セッションに詰めとくような情報をmemcachedに持たせておけば、どこのノードに振られても大丈夫だし、レプリケーションによるトラフィックとかメモリのコストを気にしなくても良い。
まあこの方法の場合はmemcachedが落ちたら意味ないのだがかといってmemcachedの分散とかやりだすとキリがない。冗長性を確保したい場合はセッションDBとかでバックアップ、とかが現実的な落とし所か。
他にもあったら教えてほしいっす。革命的な何か。
セッションの扱いってどうすんだろう。。ということでざっくり調べてみた。
つかTomcatに限った話じゃねえな。糞無知すぎる。
Session Persistence(Sticky Session)
同一のセッションアクセスを同一のノードに振り分ける、という方法。
Tomcat側は特に何もしなくても、LB側が対応できればよい。
なので例えばApacheがLBとして機能しているならmod_jkとかのsticky sessionモードにする。
技術的雑談-複数のTomcatを立ち上げてmod_jk経由でロードバランスさせる - Tsubasa's HomePage
LBがやればよいので、別にこれWebサーバである必要もなくて、
BIG IPとかLVSみたいなL4レベルで対応することもできる。
BIG IP 機能紹介 | 兼松エレクトロニクス KEL
lvsでsession persistence(セッションパーシステンス) - うまい棒blog
何をみて判断しているかはいろいろ方法があって、IPとかCookieとかが多いと思うがSSLのセッションIDとかURLとかっていうのもあるらしい。
まあでもCookieがポピュラーなのかな。
この方法のデメリットは、アクセスノードがユーザにとってはシングルポイントになるのでそのノードが落ちたらセッション情報が消失すること。再起動にもモロ影響を受ける。
あとLBにアクセスの判定っていう余計な？処理が増えるためそこでもパフォーマンスが低下するってところか。
セッションレプリケーション
ならセッション情報をレプリしちゃおうぜ！っていう方法。
これはTomcatのマニュアルに詳しい解説がある。
The Apache Tomcat 5.5 Servlet/JSP Container - Clustering/Session Replication HOW-TO
5.5ですまん。
方式はいくつかあるが要はセッション情報をコピーしてクラスタリングしている全てのノードで同じセッション情報をもつやり方。(all-to-all)
これならどのサーバに振られても同じセッション情報を参照できるので
今までアクセスしてたノードが落ちようが再起動かかろうが問題ない。
ただこの方法にも問題がある。
一つはセッション情報をいちいち全台にレプリするためトラフィックがはんぱないことになる。
さらには全台のユーザのセッション情報を全て持つので、メモリに抱える量も当然多くなる。
ドメインクラスタリング
じゃあ全台にレプリしなきゃいいんでしょ。って方法もある。
クラスタリングしてるノードをグループに分けて、そのグループ内だけでセッションレプリケーションを行う方法。
[ThinkIT] 第2回：Tomcatのクラスタ設定 (1/4)
たしかにこの方法なら冗長性も確保できる。
けど結局LBで処理しなきゃいけないし、グループの規模とかそういうチューニングを一歩間違えると前述の二つの方法のデメリットを両方引く可能性もある。
なにより複雑っす。。グループとかのルールが必要だし。ルール設定して振り分けみたいなのは事故る。
Tomcatじゃなくてmemcachedとかに持たせる
ああもう身も蓋もねえ。。
セッションに詰めとくような情報をmemcachedに持たせておけば、どこのノードに振られても大丈夫だし、レプリケーションによるトラフィックとかメモリのコストを気にしなくても良い。
まあこの方法の場合はmemcachedが落ちたら意味ないのだがかといってmemcachedの分散とかやりだすとキリがない。冗長性を確保したい場合はセッションDBとかでバックアップ、とかが現実的な落とし所か。
他にもあったら教えてほしいっす。革命的な何か。