サービス中にアプリケーションを入れ替える―クラスタ機能を活用しよう―：事例に学ぶWebシステム開発のワンポイント（5）

本連載では、現場でのエンジニアの経験から得られた、アプリケーション・サーバをベースとしたWebシステム開発における注意点やヒントについて解説する。巷のドキュメントではなかなか得られない貴重なノウハウが散りばめられている。読者の問題解決や今後システムを開発する際の参考として大いに活用していただきたい。（編集局）

[池田寛治，（株）NTTデータ] PC用表示関連情報

LINE

Hatena

今回のワンポイント

一般にクラスタは、可用性向上のために使われるが、サービスを中断しないでアプリケーションを入れ替える手段としても活用できる。WebLogicクラスタを用いて、アプリケーション入れ替えを行う場合の注意点を解説する。

クラスタ機能を活用する

　Webシステムでは24時間サービスは当たり前で、なかなか停止することが許されない。そのため、サービスを停止することなくアプリケーションの入れ替えを行いたいといった要求がしばしば出てくる。そんなときに役に立つのがクラスタである。一般にクラスタは、負荷分散と可用性向上を目的として導入されることが多いが、サービスを停止することなくアプリケーションの入れ替えを行うといった場合にも有効である。

　しかし、サービス中にアプリケーションを入れ替えて大丈夫なのだろうか、セッション情報は正しく引き継がれるのだろうか、といった不安が出てくるかもしれない。今回は、WebLogicクラスタ*1を利用してアプリケーションの入れ替えを行う手順について解説したい。

*1：ここではWebLogic Server 5.1を対象としている。

WebLogicクラスタの仕組み

　WebLogicクラスタは、セッション情報をサーバ間でコピーしあう「イン・メモリ・レプリケーション」という特徴的な機能を持っている。ただし、レプリケーションされるのは、クラスタを構成しているサーバ中の2台のサーバ（プライマリとセカンダリと呼ばれる）のみである。また、どのサーバがプライマリ／セカンダリであるかという情報は、セッションIDの中に埋め込まれてクライアント（Webブラウザ）に渡される。

　このため、WebLogicクラスタでは、クライアントから送付されたセッションIDの内容を見て、まずはプライマリに、そしてプライマリに接続できなかった場合はセカンダリに、リクエストを振り分けるといった動作を行っている。この処理を行うのがWebLogicプラグインモジュールであり、Webサーバ上で動作する。これがWebLogicクラスタの仕組みである*2。

*2：正確には、WebLogicクラスタの機能は、Servlet／JSPのクラスタとEJBクラスタの大きく2つの機能があるが、ここではServlet／JSPのクラスタのみを取り上げる。

　すなわち、次の図のように、Webブラウザがサーバに初めてアクセスするとき（リクエスト中にセッションIDが含まれない場合）は、プライマリ／セカンダリが動的に決定され、その情報がセッションIDに含められてWebブラウザに返されることになる。

初めてアクセスした場合は、プライマリ／セカンダリの情報をペアとしたセッションＩＤが作成され、ブラウザに返される

　一方、Webブラウザが2回目以降アクセスした場合は、リクエスト中にセッションIDが存在し、WebLogicプラグインがセッションIDの内容を識別して、プライマリにリクエストを振り分ける。

2回目以降は、WebLogicプラグインリクエスト中のセッションＩＤの内容を見て、振分けを行う

　もし、プライマリがダウンしている場合は、WebLogicプラグインはリクエストをセカンダリに振り分けるとともに、ほかにもクラスタを構成しているサーバがある場合は、新たにプライマリ／セカンダリのペアを決定し直す。

サーバがダウンした場合は、新たにプライマリ／セカンダリのペアを決定し直す

アプリケーションの入れ替え手順

　このように、WebLogicクラスタはセッション情報をコピーしあうため、プライマリとセカンダリのうち、どちらか1台がダウンしてもサービスを継続することが可能である。この仕組みを用いて、サービスを停止することなく、1台ずつサーバを停止してアプリケーションの入れ替えを行うことが可能になる*3。

*3：動的デプロイを行えばサーバを再起動する必要はないが、運用環境では安定性を重視して動的デプロイ機能を用いないことが多い。このため、ほとんどのケースで、アプリケーション入れ替え時に再起動を行っている。

　2台のWebLogic Server（サーバA、サーバB）を用いたアプリケーションの入れ替え手順は、次のようになる。

クラスタを利用してアプリケーションを入れ替える手順は、簡単だが、安定運用を考えると極めて有効な手段だ

（1）killコマンドで停止すべき

　このとき、注意する必要があるのはサーバの停止方法である。通常、WebLogicを停止させるには、シャットダウンコマンドや管理コンソールを利用するが、停止に至るまでしばらく時間がかかってしまう。この停止処理中の間にリクエストが来たとき、正しくセッション情報が引き継がれない事象が確認されている。このため、WebLogicを停止させるにはシャットダウンコマンドではなく、killコマンドを用いた方がトラブルの可能性が少ない。

（2）セッションに格納したクラスを変更した場合は、サービス中の入れ替えはできない

　また、いうまでもないことであるが、セッションに格納されたクラスを変更した場合（例えば、インスタンス変数を追加するなどした場合）、今回の方法では正常にアプリケーションの入れ替えができない。セッション情報をコピーする際は、Javaのシリアライズ／デシリアライズが行われるため、片方のサーバだけクラス構成が変更されると、エラー（InvalidClassException）が発生してしまうのである。セッションに格納したクラスを変更せざるを得ない場合は、残念ながら、一度全サーバを停止して、アプリケーションの入れ替えを行う必要がある。

　以上、運用環境の安全を考慮した、アプリケーション入れ替えのテクニックについて解説した。

著者プロフィール

池田寛治（いけだ　かんじ）

現在、株式会社NTTデータ　COEシステム本部に所属。技術支援グループとして、J2EEをベースにしたWebシステム開発プロジェクトを対象に、技術サポートを行っている。特に、性能・信頼性といった方式技術を中心に活動中。

「次回」へ

「事例に学ぶWebシステム開発のワンポイント」バックナンバー