JP4532946B2

JP4532946B2 - アプリケーション入れ替え方法およびそのプログラム

Info

Publication number: JP4532946B2
Application number: JP2004079582A
Authority: JP
Inventors: 尚紀井川; 裕二溝手; 英男高橋
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-03-19
Filing date: 2004-03-19
Publication date: 2010-08-25
Anticipated expiration: 2024-03-19
Also published as: JP2005267312A

Description

本発明は、アプリケーション入れ替え技術に係わり、旧アプリケーションから新アプリケーションへ入れ替える方法に関するものである。

Ｗｅｂで買い物ができるオンラインショッピングサイトのような商用のＷｅｂサイトでは、利用者に常にサービスを提供できるように２４時間３６５日運転を可能とする高可用性が求められている。このようなサービスは、Ｗｅｂシステム上のアプリケーションによって実現され、一般にアプリケーションを構成する一連のページを、リンクをたどって順次呼び出すことにより実現される。そしてそれぞれのページではユーザにデータを段階的に入力させ、アプリケーションの処理が完了した時点でそれまでに入力されたデータを一括してデータベースに登録する構成を採ることが多い。例えばショッピングサイトでは、アプリケーションを構成する個々のページで、購入商品を選択させ、住所やクレジットカードの番号などのデータを入力させ、最後に決済を行った時点で一括してそれらデータをデータベースに格納する。

このときデータベースに登録するまでに段階的に入力された中間的なデータをクライアントに対応付けて保持している必要がある。市販のアプリケーションサーバでは、メモリ上でそれらのデータをクライアントに対応付けて保持する機能をもっている。そのためアプリケーションサーバに障害が起きると、このメモリ上のデータが失われてしまい、ユーザがそれまで入力した購入商品や住所などのデータが消えてしまう。

このメモリ上の中間データをセッション情報と呼ぶ。アプリケーションサーバは、クライアントとセッション情報とを対応付けるために、クライアントに対してセッションＩＤと呼ぶ識別子を発行し、それに対応付けてセッション情報を管理している。

Ｗｅｂシステムを無休で運用している環境において、アプリケーションに不都合が見つかったとき、またはバージョンアップを行う等の理由でアプリケーションを入れ替える必要性が生じることがある。このようなときにシステム上で稼動しているアプリケーションが単一であるとアプリケーションの入れ替え中はサービスが停止してしまうため、ユーザからのリクエストを処理することはできない。従って同一のアプリケーションを同じサーバまたは異なるサーバ内に複数稼動させておき、入れ替え中は負荷分散機等のリクエスト転送プログラムを用いて入れ替えを行っていない他のアプリケーションへリクエストを転送する必要がある。

従来におけるアプリケーションの入れ替え方法は、非特許文献１に開示されるように以下のように行われている。（１）ユーザから送信されるアプリケーション開始要求を意味する新規リクエストを入れ替え対象のアプリケーションへ転送しないように、システム管理者がリクエスト転送プログラムの設定を行う。（２）システム管理者が入れ替え対象のアプリケーションが使用しているセッション情報を監視するために、入れ替え対象のアプリケーションの実行ログを一定時間ごとに監視する。（３）入れ替え対象のアプリケーションが使用しているセッション情報を全て使い終わると、入れ替え対象のアプリケーションをアンインストール（以後アンデプロイと表記）した後、新アプリケーションをインストール（以後デプロイと表記）する。以上の作業を起動しているアプリケーションについて数回行いアプリケーションの入れ替えを行っている。

この入れ替え作業は、システム管理者にとって非常に手間がかかると同時に間違えやすい作業となっている。システムを構成するアプリケーションサーバの数が多くなるとこの傾向は顕著に現れる。システム管理者が手順を間違えると、セッション情報が失われてしまう。システム管理者の手間を軽減し、間違いを生じないようにするためにはアプリケーション入れ替え作業の一連の手順を自動化することが課題となる。

特開２００２−２５９１４２号公報（特許文献１）は、システムを停止せずにアプリケーションの入れ替え作業の自動化を実現している。しかしこの方法ではユーザからの単一のリクエストの処理が終了するタイミングでアプリケーションの入れ替えを行ってはいるが、複数のリクエストに跨って行われる一連のサービスの終了を待ってアプリケーションの入れ替えを行うことはできない。従ってサービスの利用中にアプリケーションの入れ替えが生じると、それまでに記録したセッション情報が失われてしまう。

セッション情報を失わず、サービスを停止せずにアプリケーション入れ替えの自動化を実現する方法としてフェイルオーバーを利用する非特許文献２に開示されるような入れ替え方法がある。フェイルオーバーとは、Ｗｅｂシステムを少なくとも一組の正常系アプリケーションサーバと待機系アプリケーションサーバを運用する冗長構成とし、正常系アプリケーションサーバでのリクエスト処理ごとにリクエスト処理で使用したメモリ上のセッション情報を待機系アプリケーションサーバのメモリ上に二重化しておき、正常系アプリケーションサーバの障害時に待機系アプリケーションサーバが処理を引き継ぐ処理方式である。この方式を利用すれば次の（１）〜（６）の手順を自動化することによってセッション情報を失わずにアプリケーション入れ替えの自動化を実現できる。すなわち（１）正常系アプリケーションサーバの停止、（２）正常系アプリケーションサーバ上のアプリケーションの入れ替え、（３）正常系アプリケーションサーバの起動、（４）待機系アプリケーションサーバの停止、（５）待機系アプリケーションサーバ上のアプリケーションの入れ替え、（６）待機系アプリケーションサーバの起動の手順である。

上記のフェイルオーバーの方法では、（１）の正常系アプリケーションサーバの停止後、セッション情報は待機系アプリケーションサーバのメモリに二重化されているのでセッション情報を失わずに待機系アプリケーションサーバで処理を引き継ぐことができる。しかし（３）後、正常系アプリケーションサーバにコピーされるセッション情報は、待機系アプリケーションサーバ上の更新前アプリケーションが使用していたものであるため、正常系アプリケーションサーバ上の更新後アプリケーションは、更新前アプリケーション用のセッション情報を使用することになる。この場合、更新後アプリケーションと更新前アプリケーションが使用するセッション情報の構造が変われば（４）後にセッション情報を引き継ぐことはできない。

特開２００２−２５９１４２号公報

John Wiley & Sons 著、"Load Balancing Servers, Firewalls, and Caches"、Wiley Computer 出版、2002、p.17 Gregory Pfister 著、"In SEARCHI OF CLUSTERS"、Prentice Hall PTR 出版、1998、p.394−400

上記の従来技術を用いて２４時間３６５日止まることなくサービスを提供する商用の大規模Ｗｅｂサイトにおいて、非特許文献１の技術を用いた手作業によるアプリケーションの入れ替え作業を行った場合、従来はシステム管理者が手動で入れ替え作業を行っているため、システム管理者に大きな負担がかかる。また入れ替え手順を間違えるとユーザとのセッション情報が失われる時があり、この場合ユーザは再入力をしなければならない。

特許文献１の技術を用いた入れ替え方法は、一連の入れ替え作業の自動化を実現している。しかしこの方法は複数のリクエストに跨って行われる一連のサービスの終了を待ってアプリケーションの入れ替え作業を行うことができないため、入れ替えのタイミングでセッション情報をデータベースへ格納する前にメモリから消去されてしまう。

フェイルオーバーを用いた非特許文献２の入れ替え方法では、更新前と更新後のアプリケーションが使用するセッション情報の構造が変化すると、正常系アプリケーションサーバと待機系アプリケーションサーバ間でセッション情報を引き継ぐことはできないため、セッション情報が失われてしまう。

本発明の目的は、アプリケーションが提供するサービスを停止することなく、またセッション情報を失うことなく、アプリケーション入れ替えの自動化を実現することにある。

本発明は、システム管理者からの入れ替え指示に応答して新アプリケーションをデプロイし、アプリケーションに対する新規リクエストについては新アプリケーションを実行し、旧アプリケーションが参照するメモリ上のセッション情報の数を監視し、セッション情報の数が0になったとき旧アプリケーションをアンデプロイするアプリケーション入れ替え技術を特徴とする。

本発明によれば、アプリケーションが提供するサービスを停止することなく、またセッション情報を失うことなく、旧アプリケーションを新アプリケーションに入れ替えることができる。

以下、本発明の一実施例について図面を用いて詳細に説明する。

図1は、本実施例の計算機システムの構成図である。本実施例のシステムでは、Ｗｅｂシステム15と端末装置12がインターネット14を介して接続されている。ここでＷｅｂシステム15は、パーソナルコンピュータ（以下、パソコンと呼ぶ）などの汎用の計算機によって構成される。この計算機上では、ＨＴＴＰ(Hyper Text Transfer Protocol)サーバプログラム（以後、Ｗｅｂサーバプログラムと記述する）およびアプリケーションサーバプログラム（以後、ＡＰサーバプログラムと記述する）が実行される。これによってＷｅｂシステム15は、３６５日２４時間無休で運用される。

システム管理者は、端末装置10上で運用管理プログラム11を操作することによってＷｅｂシステム15上のＡＰサーバプログラムと通信を行い、アプリケーション入れ替えの指示を発行する。

運用管理プログラム11は、ＡＰサーバプログラムと通信を行うためのプログラムであり、アプリケーション入れ替え指示のほかに、ＡＰサーバの起動／停止要求、アプリケーションのデプロイ／アンデプロイ要求等の様々な要求をＡＰサーバプログラムに対して指示することができる。運用管理プログラム11は、汎用のＡＰサーバとともに提供されるプログラムなので、ここでは詳細に説明しない。本実施例では汎用の運用管理プログラムに新たにアプリケーション入れ替え指示を発行する機能を追加した。運用管理プログラムからアプリケーション入れ替え指示命令をＡＰサーバプログラムに送信すると、ＡＰサーバプログラムは、自動的にアプリケーションの入れ替え処理を行う。なおこの際に適用される通信のプロトコルについてはここでは言及しない。

ユーザは、端末装置12上でＷｅｂブラウザ13を実行し、インターネット14経由で、Ｗｅｂシステム15上のＷｅｂサーバやＡＰサーバと通信を行い、サービスを利用する。

図２は、Ｗｅｂシステム15の構成を示す図である。本実施例のＷｅｂシステム15は、ＣＰＵ、メモリおよびディスクなどの記憶装置を有する少なくとも１台のＷｅｂ計算機である。このＷｅｂ計算機のメモリには、Ｗｅｂサーバプログラム20およびアプリケーションサーバプログラム30がロードされ、ＣＰＵによって実行される。

Ｗｅｂサーバプログラム20にはポータルページ等のページが置かれており、ＡＰサーバプログラム30が提供するアプリケーションを利用するユーザは、初めにこのページにアクセスする。ユーザは、Ｗｅｂブラウザ13から利用するアプリケーションの宛先ＵＲＬを指定することによって、ＡＰサーバプログラム30が提供するアプリケーションの利用を開始することができる。以降では、ユーザがアプリケーションの利用を開始する際に送信するＨＴＴＰリクエストを新規リクエストと記述する。新規リクエストにはアプリケーションのリンク先である宛先ＵＲＬが含まれている。

アプリケーションの利用を開始後、ユーザはＡＰサーバプログラム30へＨＴＴＰリクエスト21を送信することによりアプリケーションが提供するサービスを利用することができる。この時送信されたＨＴＴＰリクエスト21は、Ｗｅｂサーバプログラム20を通じてＡＰサーバプログラム30に送信される。つまりＷｅｂサーバプログラム20は、ユーザからのリクエストをＡＰサーバプログラム30へ転送する働きをもつ。以降では、アプリケーション開始後、継続的にアプリケーションを使用している段階において、ＡＰサーバプログラム30へ送信するＨＴＴＰリクエストを継続リクエストと記述する。継続リクエストにはアプリケーションの宛先ＵＲＬやアプリケーションで使用するセッションＩＤ、アプリケーションのバージョン番号等が含まれている。

ＡＰサーバプログラム30は、運用管理エージェント40、アプリケーション実行プログラム50およびセッション情報管理プログラム60から構成される。またＡＰサーバプログラム30の内部には、運用管理エージェント40によってデプロイされて実行可能状態にあるアプリケーションが１個以上存在する。

次にＡＰサーバプログラム30の構成要素であるアプリケーション実行プログラム50、セッション情報管理プログラム60および運用管理エージェント40について詳細に説明する。

まずアプリケーション実行プログラム50について説明する。アプリケーション実行プログラム50は、アプリケーション実行アドレステーブル51を持ち、リクエスト解析処理52と、アプリケーション実行処理53と、テーブル更新処理54を行う。ここで処理を行う処理モジュールのことを単に「処理」と略称する。この３つの処理についてそれぞれ説明する。

最初にリクエスト解析処理52について詳細に説明する。リクエスト解析処理52は、ユーザから送信されるＨＴＴＰリクエスト21を解析して、リクエストに含まれる宛先ＵＲＬ、バージョン番号から、アプリケーション実行アドレステーブル51を用いて、実行するアプリケーションを決定する処理である。

図３は、アプリケーション実行アドレステーブル51の構造を表した図である。アプリケーション実行アドレステーブル51は、Ｗｅｂ計算機のメモリ上に保持される。アプリケーション実行アドレステーブル51の各エントリは、宛先ＵＲＬ511、バージョン番号512およびアドレス513の各項目を有する。

アプリケーション実行アドレステーブル51を用いて実行するアプリケーションを決定する流れを図５のＰＡＤ図を用いて説明する。アプリケーション実行プログラム50のリクエスト解析処理52は、ユーザからＨＴＴＰリクエスト21を受信すると、リクエストに含まれる宛先ＵＲＬとバージョン番号を抽出する（ステップ120）。リクエストにバージョン番号が含まれている場合、つまり、受信したリクエストが継続リクエストの場合、アプリケーション実行アドレステーブル51からリクエストに含まれるアプリケーションの宛先ＵＲＬ、バージョン番号に適合するエントリを検索して、エントリのアドレス513の値を実行対象のアプリケーションのアドレスとして求める。（ステップ121）。アドレス513は、アプリケーションが格納されているディスク上の位置であり、アプリケーション実行プログラム50は、このアドレスを指定することによってアプリケーションの実行を行う。

リクエストにバージョン番号が含まれていない場合、つまり、受信したリクエストが新規リクエストの場合、アプリケーション実行アドレステーブル51からリクエストに含まれる宛先ＵＲＬに一致するエントリを検索して、適合したエントリのアドレス513に存在するアプリケーションを実行対象のアプリケーションとして選択する（ステップ122）。エントリが２個存在する場合、つまり新旧両方のアプリケーションがデプロイされている場合、バージョン番号512の値が大きいエントリ、すなわち新アプリケーションに関するエントリを選択する（ステップ123）。選択したエントリのアドレス513の値を実行対象のアプリケーションのアドレスとして求め、ユーザに対して使用するアプリケーションのバージョン番号を割り当てる（ステップ124）。バージョン番号が発行されると、端末装置12側でバージョン番号を保持し、以降送信するリクエストにバージョン番号を含める。バージョン番号を保持する仕組みは、クッキーやＵＲＬに直接埋め込むなどの方法があるが、ここではいずれの方法でも実現可能である。実行対象のアプリケーションのアドレスを決定した後、アプリケーション実行処理53を呼び出し、実行させるアプリケーションのアドレスを渡し、リクエストに対する処理をアプリケーションに実行させる（ステップ125）。以上が、リクエスト解析処理52が行う処理である。

次にアプリケーション実行処理53について説明する。アプリケーション実行処理53は、リクエスト解析処理52から渡されたアドレスに基づいて、指定されたアドレスに存在するアプリケーションの実行を行う処理である。アプリケーションの実行処理は、汎用のＡＰサーバに備わっている機能なので、実行処理についての説明は省略する。ここでは、アプリケーションの実行中に発生、更新、又は消滅するセッション情報を扱う処理について説明する。

アプリケーションの実行中にセッション情報が発生すると、アプリケーション実行プログラム50は、そのセッション情報とそのセッション情報を使うユーザに対してセッションＩＤを発行する。セッションＩＤも、バージョン番号と同様の方法によって端末装置12側に保持される。以降、このユーザが送信する継続リクエストには、割り当てられたセッションＩＤが含まれる。セッションＩＤは、異なるユーザに同じＩＤが重複することのないように発行される必要がある。なおセッションＩＤ発行のアルゴリズムについてはここでは説明しない。セッションＩＤの発行後、アプリケーション実行プログラム50は、セッション情報をセッション情報管理テーブルに格納する。セッション情報管理テーブルは、アプリケーションごとに存在し、アプリケーション実行中に発生したセッション情報は、そのアプリケーション用のセッション情報管理テーブルに格納され、ユーザからの継続リクエストに対する処理を行う際の中間データとして利用される。図２に示すように、ＡＰサーバプログラム30は、新アプリケーション用セッション情報管理テーブル70と旧アプリケーション用セッション情報管理テーブル71の２種のセッション情報管理テーブルを保持する。

図４は、セッション情報管理テーブル70、71の構造を表した図である。セッション情報管理テーブル70/71は、Ｗｅｂ計算機のメモリ上に保持される。セッション情報管理テーブル70/71の各エントリは、リクエストごとに設けられ、セッションＩＤ721、セッション情報オブジェクト722および最終アクセス時刻723を保持する。セッションＩＤ721はセッション情報のセッションＩＤの値、最終アクセス時刻723はセッション情報を生成又は参照、更新した時刻を格納し、セッション情報オブジェクト722はセッション情報を構造体変数として格納する。

アプリケーションの実行中にセッション情報を使用する場合、アプリケーション実行プログラム50は、ユーザから送信された継続リクエストに含まれるセッションＩＤを取り出し、セッション情報管理テーブル70/71のセッションＩＤ721に適合するエントリを検索し、セッション情報オブジェクト722からセッション情報を取り出し、最終アクセス時刻723を現在の時刻に更新してアプリケーションへ渡す。アプリケーションの実行中にセッション情報が更新されると、アプリケーション実行プログラム50は更新が発生したセッションＩＤに対応するセッション情報オブジェクト722へ更新したセッション情報の構造体を上書きする。セッション情報を使い終わると、セッション情報管理テーブルを検索し、そのセッションＩＤに対応するエントリを消去する。以上がアプリケーション実行処理におけるセッション情報を扱う処理である。

次にテーブル更新処理54について説明する。テーブル更新処理54は、運用管理エージェント40から受信したデプロイ通知80に応答して、デプロイしたアプリケーションのＵＲＬ、バージョン番号、アドレスをアプリケーション実行アドレステーブル51へ書き込む処理と、運用管理エージェント40から受信したアンデプロイ通知81に応答して、アンデプロイするアプリケーションのＵＲＬ、バージョン番号、アドレスをアプリケーション実行アドレステーブル51から消去する処理を行う。

テーブル更新処理54において、新アプリケーションのデプロイ通知80を受信した時の処理の流れを図６のＰＡＤ図を用いて説明する。運用管理エージェント40からデプロイ通知80を受信すると、デプロイ通知80に含まれるアプリケーションの宛先ＵＲＬ、アプリケーションのバージョン番号、アプリケーションのアドレスを取り出し、取り出したアプリケーションの宛先ＵＲＬがアプリケーション実行アドレステーブル51の宛先ＵＲＬ511に存在するかチェックする（ステップ130）。ここで新アプリケーションと旧アプリケーションのアプリケーション名および宛先ＵＲＬが同一であり、新アプリケーションのバージョン番号が旧アプリケーションのバージョン番号より大きいものとする。渡された宛先ＵＲＬがテーブルに存在する場合、そのエントリのバージョン番号512の値が、渡されたバージョン番号よりも大きい値である時、運用管理エージェント40へエラー応答を送信し、処理を終了する（ステップ131）。渡された宛先ＵＲＬがテーブルに存在しない場合、またはテーブルに存在し、かつそのエントリのバージョン番号512が渡されたバージョン番号よりも小さい値ならば、テーブル更新処理54は、リクエスト実行アドレステーブル51へ渡された宛先ＵＲＬを宛先ＵＲＬ511に、新アプリケーションのバージョン番号をバージョン番号512に、新アプリケーションのアドレスをアドレス513に新規に書き込む（ステップ132）。テーブルに書き込み後、運用管理エージェント40へテーブル更新応答82を返す（ステップ133）。

次にテーブル更新処理54において、旧アプリケーションのアンデプロイ通知81を受信した時の処理の流れを図７のＰＡＤ図を用いて説明する。運用管理エージェント40からアンデプロイ通知81を受け取ると、アンデプロイ通知81に含まれるアプリケーションの宛先ＵＲＬを取り出し、アプリケーション実行アドレステーブル51の宛先ＵＲＬ511に存在するかチェックする（ステップ140）。渡された宛先ＵＲＬがテーブルに存在しない場合、運用管理エージェント40へエラーを送信する（ステップ141）。存在する場合、そのエントリをアプリケーション実行アドレステーブル51から消去する（ステップ143）。複数存在する場合はバージョン番号512の小さいエントリを選択し（ステップ142）、そのエントリをアプリケーション実行アドレステーブル51から消去する（ステップ143）。テーブルから消去後、運用管理エージェント40へテーブル更新応答82を返す（ステップ144）。以上がテーブル更新処理54の流れである。

以上、アプリケーション実行プログラム50が行う処理であるリクエスト解析処理52、アプリケーション実行処理53およびテーブル更新処理54について説明した。次にセッション情報管理プログラム60について説明する。

セッション情報管理プログラム60は、アプリケーションが使用しているセッション情報の管理と監視を行うプログラムであり、セッション情報管理処理61とセッション情報監視処理62の処理モジュールを有する。この２つの処理モジュールの処理について説明する。

セッション情報管理処理61は、長時間アクセスされていないセッション情報をセッション情報管理テーブル70/71から消去する処理を行う。各セッション情報管理テーブル70/71に存在する全てのセッションオブジェクトに対して最終アクセス時刻723の値と現在時刻を比較し、その差が予めＡＰサーバプログラム30に設定している時間よりも大きくなれば、そのエントリをセッション情報管理テーブルから消去する。

従って、消去されたセッション情報を使用していたユーザが継続リクエストを送信するとエラーになる。これにより、長時間アクセスしていないユーザに対してはアプリケーションの使用を終了させている。セッション情報管理処理61は、ＡＰサーバプログラム30が起動されてから終了するまで繰り返し行われる。なおセッション情報管理処理61は、汎用のＡＰサーバに備わっている機能なので、処理の詳細な説明を省略する。

セッション情報監視処理62は、運用管理エージェント40から指定されたアプリケーション用セッション管理テーブルを一定時間ごとに繰り返し監視する。セッション監視処理62の流れを図８のＰＡＤ図を用いて説明する。セッション情報管理プログラム60は、一定時間ごとにセッション情報管理テーブルのエントリの数を数える（ステップ151）。エントリの数が0になると、運用管理エージェント40へセッション情報終了通知83を送信する（ステップ152）。上記２つの処理がセッション管理プログラム60において行われる処理であり、この２つの処理は独立に実行される。

次に運用管理エージェント40について説明する。運用管理エージェント40は、運用管理プログラム11から送信される入れ替え指示43を受信すると、アプリケーション入れ替え処理41を実行し、旧アプリケーションから新アプリケーションへの入れ替える処理を行い、本発明におけるアプリケーション入れ替え処理の自動化を実現する処理である。アプリケーション入れ替え処理41の流れを図９のＰＡＤ図を用いて説明する。

運用管理エージェント40は、運用管理プログラム11から送信される入れ替え指示10を受信すると、アプリケーション入れ替え処理41は、入れ替え指示43に含まれる新アプリケーション、新アプリケーションのバージョン番号、アプリケーションの宛先ＵＲＬを取り出し、新アプリケーションのデプロイを行う（ステップ160）。ここでデプロイは、新アプリケーションが外部のディスクファイルからＡＰサーバプログラム30の管理するファイルにインストールされる。デプロイ後、アプリケーション実行プログラム50へデプロイ通知80を送信し、新アプリケーションのバージョン番号とアドレス、宛先ＵＲＬを渡す（ステップ161）。デプロイ通知を受け取ったアプリケーション実行プログラム50は、テーブル更新処理54を実行するため、これ以降にＡＰサーバプログラム30に送信される新規リクエストは新アプリケーションによって実行されることになる。運用管理エージェント40は、アプリケーション実行プログラム50からテーブル更新応答82を受信する（ステップ162）。ここで新旧両方のアプリケーションが利用可能となる。受信した応答がエラー応答であれば、新アプリケーションをアンデプロイし、運用管理プログラム11へ終了通知44を送信して処理を終了する（ステップ163）。

受信した応答がエラー応答でなければ、アプリケーション入れ替え処理41は、セッション管理プログラム60へ旧アプリケーション用セッション情報管理テーブル71へのセッション情報監視指示84を送信する（ステップ164）。セッション情報監視指示84を受け取ったセッション情報管理プログラム60は、セッション情報監視処理62を実行する。これにより、現在、旧アプリケーションが使用しているセッション情報が監視される。セッション情報が全て使い終わると、セッション情報管理プログラム60は、運用管理エージェント40へセッション情報終了通知83を送信する。運用管理エージェント40がセッション情報終了通知83を受信すると（ステップ165）、アプリケーション実行プログラム50へアンデプロイ通知81を送信し、入れ替え指示時に運用管理プログラム11から渡されたアプリケーションのＵＲＬを渡す（ステップ166）。アンデプロイ通知81を受信したアプリケーション実行プログラム50は、テーブル更新処理54を実行しアプリケーション実行アドレステーブル51から旧アプリケーションのエントリを削除し、運用管理エージェント40へ応答を返す。運用管理エージェント40は、アプリケーション実行プログラム50から応答を受信すると（ステップ167）、旧アプリケーションをアンデプロイする（ステップ168）。旧アプリケーションがアンデプロイされることによって、旧アプリケーション90がＡＰサーバプログラム30の管理する領域から消去される。アンデプロイ後、運用管理プログラム11へ入れ替え終了通知44を送信する（ステップ169）。

以上が運用管理エージェント40が行うアプリケーション入れ替え処理41の流れである。このように運用管理エージェント40は、新アプリケーションをデプロイ後、旧アプリケーションが使用しているセッション情報が全て使い終わるのを待ってから旧アプリケーションをアンデプロイすることによって、セッション情報を失わずにアプリケーションの入れ替え処理を実現する。

次に運用管理プログラム11の処理手順について説明する。システム管理者は、運用管理プログラム11へ新アプリケーション、新アプリケーションのバージョン番号、入れ替え対象のアプリケーションのＵＲＬを渡し、入れ替え指示を出す。運用管理プログラム11は、入れ替え指示を受けてＡＰサーバプログラム30上の運用管理エージェント40へ新アプリケーション、新アプリケーションのバージョン番号、入れ替え対象のアプリケーションのＵＲＬを渡し、入れ替え指示43を送信する。入れ替え指示43を受信した運用管理エージェント40は、アプリケーション入れ替え処理41を実行して、旧アプリケーションが使用しているセッション情報を失わずにアプリケーションを旧バージョンから新バージョンへ入れ替え処理を行う。アプリケーション入れ替え処理41が終了すると、運用管理プログラム11へ終了通知44を送信し、運用管理プログラム11は、ユーザに入れ替え処理終了を通知する。

以上説明した本実施例によれば、Ｗｅｂシステムが提供するサービスを停止することなく、アプリケーション入れ替えを自動化する方法を、セッション情報を失うことなしに実現できる。

最後に、従来技術ではセッションオブジェクトの構造が変わるとフェイルオーバー機能では入れ替え不可能であるのに対し、本発明は、セッションオブジェクトの構造が変化しても入れ替え可能である点を示す。

図１０は、セッションオブジェクトの構造例を表したものである。一般にセッションオブジェクトは、変数名と値が対になって格納されており、アプリケーションごとに構造が異なる。フェイルオーバーを用いた入れ替え方法では正常系アプリケーションサーバに新アプリケーションをデプロイ後、待機系アプリケーションサーバが使用していた旧アプリケーション用のセッションオブジェクト170を、新アプリケーションが使用するセッションオブジェクトとして引き継ぎを行う。しかし本来新アプリケーションが使用するセッションオブジェクト180の構造と引継ぎ予定の旧アプリケーション用セッションオブジェクト170の構造が異なっているため、引継ぎ時にエラーが生じる。

これに対して本発明では、新旧間でセッションオブジェクトの構造が変化した場合でも、旧セッションオブジェクト170は旧アプリケーションが使い続け、新アプリケーションに引き継がれることは無いためフェイルオーバーで発生する問題が解消されている。

実施例の計算機システムの構成図である。実施例のＷｅｂシステムの構成を示す図である。実施例のアプリケーション実行アドレステーブルの構成図である。実施例のセッション情報管理テーブルの構成図である。実施例のリクエスト解析処理のＰＡＤ図である。実施例のデプロイ通知を受信した場合のテーブル更新処理のＰＡＤ図である。実施例のアンデプロイ通知を受信した場合のテーブル更新処理のＰＡＤ図である。実施例のセッション監視処理のＰＡＤ図である。実施例のアプリケーション入れ替え処理のＰＡＤ図である。セッションオブジェクトの構成例を示す図である。

符号の説明

１１：運用管理プログラム、１５：Ｗｅｂシステム、２０：Ｗｅｂサーバプログラム、３０：ＡＰサーバプログラム、４０：運用管理エージェント、４１：アプリケーション入れ替え処理、５０：アプリケーション実行プログラム、５１：アプリケーション実行アドレステーブル、６０：セッション情報管理プログラム、７０：新アプリケーション用セッション情報管理テーブル、７１：旧アプリケーション用セッション情報管理テーブル、９０：旧アプリケーション、９１：新アプリケーション

Claims

アプリケーションを実行するＡＰサーバを含むＷｅｂシステムと、前記ＡＰサーバに対して前記アプリケーションから新アプリケーションへの入れ替え指示を行う端末装置と、前記アプリケーションに対して実行のためのリクエストを送る複数のユーザ端末とからなるシステムにおけるアプリケーション入れ替え方法であって、前記ＡＰサーバは、
システム管理者からの前記端末装置を介した入れ替え指示に応答して前記入れ替え指示に含まれる前記新アプリケーションをデプロイし、前記ユーザ端末を介したユーザからの前記アプリケーションに対する前記リクエストが前記アプリケーションのバージョン番号を含まない新規リクエストの場合はデプロイした前記新アプリケーションを実行し、前記アプリケーションに対する前記リクエストが、前記アプリケーションの宛先ＵＲＬ、前記アプリケーションを使用する前記ユーザに割り当てられたセッションＩＤ、および、前記アプリケーションのバージョン番号を含む継続リクエストの場合は、前記宛先ＵＲＬと前記バージョン番号を参照して前記アプリケーションを実行し、（１）前記入れ替え指示に入れ替え対象として指定された前記アプリケーションが実行中に使用し、更新される中間データであり、（２）前記アプリケーションを使用するユーザ毎に対応付けられた前記セッションＩＤと対応してメモリ上に保持され、かつ（３）前記アプリケーションによる前記ユーザに対応する使用が終わるとそのエントリが消去される、前記アプリケーションに対応するセッション情報の前記エントリの数を監視し、前記エントリの数が0になったとき前記アプリケーションをアンデプロイすることを特徴とするアプリケーション入れ替え方法。
前記入れ替え指示に含まれ、前記新アプリケーションと前記アプリケーションとの区別のための、前記新アプリケーションのバージョン番号は、前記アプリケーションのバージョン番号より大きいことを特徴とする請求項１記載のアプリケーション入れ替え方法。
前記新規リクエストについては、前記ユーザからの以後の継続リクエストに前記新アプリケーションのバージョン番号を含ませるために、前記ユーザが使用する前記ユーザ端末に前記新アプリケーションのバージョン番号を返すことを特徴とする請求項２記載のアプリケーション入れ替え方法。
アプリケーションを実行するＡＰサーバを含むＷｅｂシステムと、前記ＡＰサーバに対して前記アプリケーションから新アプリケーションへの入れ替え指示を行う端末装置と、前記アプリケーションに対して実行のためのリクエストを送る複数のユーザ端末とからなるシステムにおいて前記APサーバに、稼動中の前記アプリケーションから前記新アプリケーションに入れ替えるアプリケーション入れ替えを実現させるためのプログラムであって、前記APサーバに、システム管理者からの前記端末装置を介した入れ替え指示に応答して前記入れ替え指示に含まれる前記新アプリケーションをデプロイする機能、前記ユーザ端末を介したユーザからの前記アプリケーションに対する前記リクエストが新規リクエストの場合はデプロイした前記新アプリケーションを実行する機能、前記アプリケーションに対する前記リクエストが、前記アプリケーションの宛先ＵＲＬ、前記アプリケーションを使用する前記ユーザに割り当てられたセッションＩＤ、および、前記アプリケーションのバージョン番号を含む継続リクエストの場合は、前記宛先ＵＲＬと前記バージョン番号を参照して前記アプリケーションを実行する機能、（１）前記入れ替え指示に入れ替え対象として指定された前記アプリケーションが実行中に使用し、更新される中間データであり、（２）前記アプリケーションを使用するユーザ毎に対応付けられた前記セッションＩＤと対応してメモリ上に保持され、かつ（３）前記アプリケーションによる前記ユーザに対応する使用が終わるとそのエントリが消去される、前記アプリケーションに対応するセッション情報の前記エントリの数を監視する機能、および前記エントリの数が0になったとき前記アプリケーションをアンデプロイする機能を実現させるためのプログラム。
前記入れ替え指示に含まれ、前記新アプリケーションと前記アプリケーションとの区別のための、前記新アプリケーションのバージョン番号は、前記アプリケーションのバージョン番号より大きいことを特徴とする請求項４記載のプログラム。