Tomcatでフェイルオーバー（比較）

　（細かい設定はさておき）Tomcatでサポートされている３種類のセッション情報の共有化に関して試してみたわけですが・・・その比較を。Tomcat easy clustering configurationに詳細にまとめられていますが、個人的な意見も交えつつ。なお、フェイルオーバーに関連した細かい設定等に関しては、気が向けば改めてまとめるかもしれません。

【PersistenceManagerを利用】
　PersistenceManager+FileStoreおよびPersistenceManager+JDBCStoreの組み合わせを用いた場合、セッション情報の保管が行われるまで若干のタイムラグが発生してしまいます。他にも、いくつかの不利な点があります。

設定でセッション保管の間隔を短縮することは可能だが、最低でも１秒以上の間隔は必要。当然ながら、間隔を短くしすぎるとリソースの消費は激しくなるので現実的には１秒といった設定は無理だと思いますが。

セッションデータのFile/DBへの保管が完了する前に別のTomcatにリクエストが行ってしまうと、古いセッション情報をロードしてしまう危険性がある。

セッション情報の変更の有無にかかわらず保管処理が行われる（従って、セッション数が多くなるとセッション情報の保管処理そのものにリソース（CPUおよびFile/DBへのIO、ネットワークの帯域等）が消費されてしまうことに）。

１つ前のと関連しますが、セッション内のデータ全てをまとめて保管するため、セッションにいろいろな情報を格納すればするほどセッション情報保管時の負荷が増大することになる。

　また、不利な点というわけではありませんが、注意すべき点として以下のようなことがあります。

saveOnRestart属性の値を"true"にしておかなければ、Tomcatダウン時にセッション情報がクリアされてしまう（＝フェイルオーバーできなくなる）。もっとも、PersistenceManagerはセッション情報の共有だけのために作られたものではないので、そういうものなのでしょうけど。

まずメモリ上にあるセッション情報を優先的にロード（メモリ上に見つからない場合にFile/DBからセッション情報を取得する）するため、StickySessionなしだと古いセッション情報を元に処理を行う場合がある。

【SimpleTcpCluster】
　PersistenceManagerを利用したときと比較し、以下のようなメリットがあります。

DeltaManagerを使用することにより、最低限のデータのみを複製することが可能。

useDirtyFlag="true"にすることで、setAttribute(key,value)やremoveAttribute(key)を行った場合のみセッション情報の複製が行われるため、複製処理の頻度を最小限に抑えることが可能。

Sender要素のreplicationMode属性の設定にもよりますが、１つのリクエスト終了時に複製処理を行うことが可能であるため、タイムラグを可能な限り短縮することが可能（リクエスト中にTomcatが落ちた場合は無理ですが、それ以外の場合だと基本的にセッション情報は即時に引き継ぎ可能）。

　逆に、デメリットとしては、

他のマシンのセッション情報もメモリ上に保持（複製）するため、メモリの消費量が増大する。従って、セッションにいろいろな情報を格納すればするほどマシンのリソースを消費することに。

　ってなところでしょうかね。ネットワークのトラフィックがPersistenceManagerを用いたときと比べて増えるかどうかはリクエストの頻度次第、でしょうか。１秒間あたりのリクエスト数が多く、かつセッション情報の更新も多い場合はSimpleTcpClusterを用いたレプリケーションの方がネットワークのトラフィックが増大するかと思いますが、数秒に１リクエストでセッション情報の更新も少ない（ログイン時にセッション情報を保存する程度）だとしたら、ネットワークのトラフィックは減少するのではないかと思います（もちろん、生存確認用のトラフィックが発生するので、０にはなりませんが）。

　実際にどの方法を使用するか（もっとも、FileStoreを使用することはほとんどないような気もしますが）は、アプリケーションの用件次第？

　SimpeTcpClusterと同様に、リクエスト終了時にセッション情報をDBに保管するような仕組みがあれば一番使いやすい＆高可用性を実現できるのかもしれません（Tomcat5.0の頃のDocumentにあったJDBCManagerってのがそれを目的としていたものなのかもしれませんが）。