―BEA WebLogic Server編―
| WebLogic Serverのセッション管理（応用編） |
 |
2. クラスタリングの実現（session replication） |
WebLogic Serverでは、セッションを外部の媒体へ永続化し複数のサーバでこれを共有することで高可用性（High Availability）を実現する仕組みを提供しています。セッションの永続化（session persistence）にはRDBかファイルのいずれかを使用することができます。この RDB やファイルを複数サーバで共有することで、セッションのフェイル・オーバーを行うことができます(http://www.beasys.co.jp/weblogic/docs/admindocs/http.html#persistence)。
ここまではどのアプリケーション・サーバでも提供している機能ですが、WebLogic Serverではさらにセッションのin-memory replicationを提供しています。in-memory replicationとはほかのサーバのメモリ内にセッションのレプリカを作成してセッションのフェイル・オーバーを実現する機能です。
in-memory replicationを使用するには下記の構成をとる必要があります。
|
複数(2〜3が一般的)のインスタンスを立ち上げ、クラスタを構成します。クラスタ・メンバーのweblogic.propertiesに下記の設定を追加することでクラスタを構成することができます（起動スクリプトでjavaコマンドに-Dweblogic.cluster.enable=true ... として与えた方が何かと便利です）。なお、クラスタ・メンバーはすべて同じポート番号 (weblogic.system.listenPort および SSLListenPort）を使用しなければなりません(*2)。
各クラスタ・メンバーのweblogic.propertiesに以下の設定を追加します(*3)。
クラスタの前にプロキシを立て、WebLogic plug-in を適用します。プロキシとしては下記のWebサーバを使用することができます(*4)。
上記のいずれのplug-inや組み込みServletを使用しても等価な機能を利用できますが、サーバがライセンス・フリーでマルチ・プラットフォーム対応であるApacheを使用することをお勧めしています。 |
in-memory replication では、おおよそ次のような仕組みで高可用性を実現しています。
| (1) セッションを開始したクラスタ・メンバー（以下サーバ）のメモリ内にセッション・オブジェクトが生成されます。このサーバを“プライマリ”と呼びます。 (2) ほかのいずれか1台のサーバのメモリ上に (1) のセッション・オブジェクトのレプリカが作成・維持されます。このサーバを“バックアップ”と呼びます。 (3) (1)のセッションに関するリクエストは、“プライマリ”がUPしている間はproxyのplug-inによって常に"プライマリ"に転送されます。 (4) 万一“プライマリ”がダウンした場合、リクエストはplug-in によって自動的に“バックアップ”に転送されます。“バックアップ”では、セッション・オブジェクトのレプリカを使用して処理を継続することができます。 (5) この時点で、"バックアップ"がそのセッションの新たな“プライマリ”になり、生き残っているサーバがあればほかのいずれか1台が新たな“バックアップ”になります。 |
上記の“プライマリ”や“バックアップ”はセッションごとに異なるサーバに割り当てられるという点に注意してください。あるセッションの“プライマリ”になっているサーバが別のセッションの“バックアップ”になっている可能性もあるということです。
さて、セッションのin-memory replicationを使用すると、次のようにsession idの後ろにクラスタリングのための情報が付加されます。
|
OmaIxZ228eN3gmewQSFaRUhnmQQRfmq27fWi6Q8qhdyI1hyDgU5G| |
この場合 session id は次のような構成になっています。
session-id|プライマリ・サーバ情報|バックアップ・サーバ情報|セッション・オブジェクトのOID
|
in-memory replication では、plug-inがsession idの後ろのプライマリ／バックアップ情報を参照してリクエストの転送を行う仕組みになっています。
また、URL rewriting ではこのようにプライマリ／バックアップ情報が付加された session id をエンコードしなくてはなりません。したがって、in-memory replicationを使用するとencodeURL ()の結果が極端に長くなります。クラスタ情報だけで約140bytes(*5)、session id自身が最短で10bytes、元のURLとsession id 名まで含めると180bytesくらいになります。これにリクエスト・パラメータを加えると携帯コンテンツでのin-memory replicationの適用に不安を感じられることでしょう。以下、i-mode、EZweb、J-Sky向けのコンテンツにin-memory replication を適用した際の経験をお伝えしておきます。
●i-mode
公式にはURL長200bytesまでとなっていますので、URL自身をコンパクトにするよう心がければ問題ありません。formでは method="post"が使えます。
●EZweb
EZweb(HDML)にはpostの概念がありません。しかし、実システムでは、元のURLとリクエスト・パラメータを含めて最長で300bytesくらいになりましたが、リクエスト情報が欠落するといった問題は発生しませんでした。ただし、ページサイズの制限が厳しいEZwebでは、エンコードされたURLの大きさがページ・デザインに与える影響は決して少なくありません。
●J-Sky
J-Sky(MML、CHTML)もpost が使えません。リクエストのURL長に関しては、EZweb と同じく300bytesくらいになりましたが問題はありませんでした。ただし、formで使用するhidden
fieldの有効長が 数十bytesと極端に短い機種が存在します (詳細は J-Sky のサポートにお問い合わせください）。これらの機種についてはサポートをあきらめるか、脚注(*1)に記したようにWebLogic
Server 6.0で対応していただくしかありません。
携帯向けコンテンツ全般に言えることですが、端末機種によって思わぬところで機能自体やサそのポートの範囲に差があるのは頭の痛いところです。テスト段階で全機種試すことは不可能ですから、機種限定の障害は運用開始後に明らかになります。各キャリアには、機種別の制限事項について情報の公開を望みたいところです。
 |
セッションのタイムアウト |
本稿に関するご質問やご意見は下記のメールアドレスまでお願いします。
|
|||||||||||||||||||||||||||||||||||||||||
脚注：WebLogic Server 6.0での変更点
(*1) 前回、Cookieの場合session id名が “JSESSIONID” になったと説明しましたが、URL rewriting の場合 session id はリクエスト・パラメータとしてではなく、servlet 2.2 仕様に準拠した、';'をセパレータに“jsessionid”という名前でエンコードされるようになりました。
|
/order/Submit.jsp;jsessionid=OqXn3Ab9!-3044480099678014536!-926997315!7001!7002!-2679308213499512072!-926997316!7001!7002 |
このため、formでmethod="get"を使用する場合もsession idをhidden fieldで渡す必要がなくなりました。つまり、以下のように素直に encodeURL()を使用すればよいわけです。
|
<form action="<%= response.encodeURL
(request.getContextPath () + "/order/Submit.jsp") %>"
method="get"> |
(*2) クラスタの設定は、管理サーバ(Administration Server)上で一括して管理されるようになりました。
(*3) このようなセッション関係の設定はすべてweblogic.xml(WebLogic Server固有のWeb
Applicationデプロイメント・ディスクリプタ)で行うよう変更されています（http://www.beasys.co.jp/e-docs/wls60e/programming/weblogic_xml.html）。
(*4) Webサーバの代わりに、スティッキング機能を備えたスイッチやロード・バランサーなどのハードウェアを前に立ててクラスタリングさせることもできるようになりました
(in-cluster routing)。
(*5) (*1)のエンコードされたURLの例はクラスタリングした場合のものですが、5.1に比べコンパクト(クラスタ情報だけで約85bytes)になったのがお分かりいただけると思います。
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
