GlassFish v2のインメモリセッションリプリケーションの概要
JavaOneの初日以降アップデートができなくて申し訳ありませんでした。
期間中、急遽仕事が舞い込んできたため、アップデートができませんでした。
JavaOneについての報告は、他のエンジニアの方達が既にたくさん報告してくださって
いるので、改めてという事も少ないのですが。JavaOneのセッションにおいて、
GlassFish v2についてのセッションに出てきたので技術的な概要の紹介を少しします。
GlassFish v2よりインメモリセッションリプリケーション機能が追加されました。
この機能はショッピングサイトにおけるショッピングカートの実装を
思い浮かべてもらえば分かりやすいのですが、ユーザが買い物かごに入れた
商品のデータは通常HTTPセッションのようなメモリ上に格納されます。
このため障害が発生するとメモリ上のデータであるカートの情報は失われてしまいます。
セッションリプリケーションでは、システムに障害が発生した場合に、
このカートの情報が失われないよう他のマシンにも常にセッション情報を
コピーし保持しておく仕組みです。
GlassFish v2ではセッションリプリケーションを行うため2通りの方法を提供しています。
●HADB (High Availability Database)の使用
●オンメモリセッションリプリケーションの使用（New）
1つはSun Java System Application Server Enterprise Edition 7以降で
利用されているHADBを利用する構成です。
そしてもう一つは、今回新たに導入されたインメモリセッションリプリケーションです。
GlassFish v2より新しく追加されたインメモリセッションリプリケーションの
動作を下記に説明します。
インメモリ内に保持するセッション情報は下記の通りです。
●Http session state
●Stateful (EJB technology) Session bean state
クラスタ構成された各インスタンスはそれぞれ、自動的に決定されたペアが存在し、
それぞれのインスタンスとペア間でHTTPセッション等のデータをコピーし
単一システムの障害に備えています。
例えば、Instance 1とInstance 2がペアである場合、ロードバランサ経由で
Instance 1に最初のリクエストが要求されると、Instance 1でセッションが
作成された後、セッション情報はInstance 2にコピーされます。
この状況でマシンに何らかの障害が発生し停止した際、クライアントである
Web ブラウザからの要求に対して、下記のいずれかのマシンから応答が返されます。
これはロードバランサがマシンの障害を検出すると、別の送信先を任意に決定するためです。
1.ペアになっていたインスタンス(例：Instance 2)に要求された場合
2.ペアではないインスタンス(例：Instance 3 もしくはInstance4)に要求された場合
まずロードバランサ経由で、ペアになっていたインスタンス(Instance 2)に
要求された場合、ペアであったインスタンス(Instance 2)から直接応答を返します。
次に、ペアではなかったインスタンス(例：Intance 3、Instance 4)に要求された場合、
返信用封筒付[Self-Addressed-Stamped-Envelope (SASE)]のリクエストを、クラスタ内に
所属する全インスタンスにブロードキャストし、返信に応じたインスタンス
（例：Instance 2）よりセッション情報を受け取りWebブラウザに対して応答を返します。
また、クラスタ内では障害発生システムを自動的に検知しクラスタのメンバーから
はずす処理なども行われています。
このセッション情報の共有、クラスタメンバの動的再構成にはJXTAの技術が
用いられています。
最後に、
Sun Java System Application Server 8.xまでは高可用性を実現するためには、
HADB以外に選択肢がありませんでした。しかしGlassFish v2以降では、HADBに加え
インメモリセッションリプリケーションも選択できるようになります。
インメモリセッションリプリケーションは、HADBに比べスループットが向上します。
一方、HADBは99.999%の高可用性を実現する事ができます。
今後、御客様のニーズに応じ最適な構成を選択してください。
カテゴリー: Application Server/GlassFish タグ:
この投稿へトラックバック | RSS フィード経由でコメントを購読