(57)【要約】【課題】  分散処理システムにおいてアプリケーションを移行する際には多くの無駄な処理時間が発生しており、システムの縮退時間が長くなってしまっている。【解決手段】  上記課題を解決するために、旧アプリケーションを稼働中のアプリケーションサーバに関する、性能情報と、アプリケーションの処理毎の統計情報と、アプリケーションの処理毎の未完了処理数と、に基づいて移行評価を行い、最短で移行完了するように移行対象サーバグループを決定して新アプリケーションへ段階的に移行する分散処理システムを提供する。【選択図】  図３
2015219732.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリケーションサーバと管理装置とを含む分散処理システムであって、
前記アプリケーションサーバは、アプリケーション部と分散実行基盤部とを備え、
前記アプリケーション部は、
クライアント端末からアプリケーションの実行要求を受け付け、前記分散実行基盤部に前記アプリケーションの処理要求のメッセージを通知するアダプタ部と、
前記分散実行基盤からの依頼により前記アプリケーションの処理を実行するプロセッサ部と、を備え、
前記分散実行基盤部は、
前記アダプタ部から通知されたメッセージを保持し、前記メッセージで要求されている前記アプリケーションの処理を実行させるアプリケーションサーバをルーティングストラテジに従って選択するディスパッチャ部と、
前記アプリケーションサーバによるアプリケーションの処理毎の統計情報を保持する統計情報格納部と、を備え、
前記管理装置は、
複数の前記アプリケーションサーバ毎にアプリケーションの移行状態を管理する移行管理部と、
前記移行状態が旧アプリケーション稼働中であるアプリケーションサーバに関する、前記アプリケーションサーバの性能情報と、前記アプリケーションの処理毎の統計情報と、前記ディスパッチャ部が保持する前記メッセージ数から算出した前記処理毎の未完了処理数と、に基づいて、移行対象サーバグループを決定する移行評価部を備えることを特徴とする分散処理システム。
【請求項２】
請求項１に記載の分散処理システムであって、
前記プロセッサ部は、前記アプリケーションの処理を実行した後、当該処理に後続する処理がある場合は当該後続する処理の実行要求を前記アダプタ部へ通知し、
前記アダプタ部は、前記後続する処理の実行要求を通知されると、前記分散実行基盤部に前記後続する処理の処理要求のメッセージを通知し、
前記管理装置は、
前記クライアント端末からアプリケーションの実行要求を受け付けた際の処理および後続する処理の実行順序を管理する定義格納部を備え、
前記移行評価部は、前記ディスパッチャ部が保持する前記メッセージ数に前記メッセージで要求されている処理に後続する処理の数を加算して前記未完了処理数を算出することを特徴とする分散処理システム。
【請求項３】
請求項２に記載の分散処理システムであって、
前記移行評価部は、前記性能情報と前記統計情報と前記未完了処理数に基づいて、前記未完了処理数分のアプリケーションの処理を実行するのに必要な最小のサーバ数となるアプリケーションサーバの組合せパターンを作成し、前記組合せパターンに含まれないアプリケーションサーバが有する処理の完了想定時間が最小となる組合せパターンに含まれるアプリケーションサーバを前記移行対象サーバグループとして決定することを特徴とする分散処理システム。
【請求項４】
請求項３に記載の分散処理システムであって、
前記アダプタ部は、前記クライアント端末からアプリケーションの実行要求を受け付ける第１アダプタと、前記プロセッサ部から処理の実行要求を通知される第２アダプタとを有し、
前記管理装置は、
前記移行評価部が決定した移行対象サーバグループに含まれるアプリケーションサーバに対して予閉塞指示をする指示部を有し、
前記予閉塞指示を受けたアプリケーションサーバのディスパッチャ部は、前記処理を実行するアプリケーションサーバの候補が複数ある場合に自アプリケーションサーバ以外を選択するように前記ルーティングストラテジを変更し、
前記予閉塞指示を受けたアプリケーションサーバのアダプタ部は、前記第１アダプタを停止させることを特徴とする分散処理システム。
【請求項５】
請求項４に記載の分散処理システムであって、
複数の前記アプリケーションサーバの状態を管理し、アプリケーションの処理を実行可能なアプリケーションサーバを前記アプリケーションサーバに通知するサーバ共有装置を備え、
前記予閉塞指示を受けたアプリケーションサーバのディスパッチャ部は、前記サーバ共有装置に対して、自アプリケーションサーバはアプリケーションの処理を実行不可であることを通知し、
前記サーバ共有装置は、アプリケーションサーバの状態を更新し、更新した実行可能アプリケーションサーバリストを他のアプリケーションサーバに送信し、
他のアプリケーションサーバのディスパッチャ部は、受信した実行可能アプリケーションサーバリストの中から前記ルーティングストラテジに従って処理を実行するアプリケーションサーバを選択することを特徴とする分散処理システム。
【請求項６】
請求項５に記載の分散処理システムであって、
前記管理装置は、
前記指示部から予閉塞指示をされたアプリケーションサーバのディスパッチャ部が保持するメッセージ数を監視する監視部と、
前記監視部が監視するメッセージ数が０となったアプリケーションサーバに対してアプリケーションの移行を指示する移行部と、を備え、
前記移行管理部は、前記移行部からアプリケーションの移行を指示されたアプリケーションサーバを新アプリケーション稼働中に更新することを特徴とする分散処理システム。
【請求項７】
請求項６に記載の分散処理システムであって、
前記指示部が予閉塞指示を行った全てのアプリケーションサーバに対して、前記移行部がアプリケーションの移行を指示した後、
前記移行評価部は、前記移行状態が旧アプリケーション稼働中であるアプリケーションサーバに関する、前記アプリケーションサーバの性能情報と、前記アプリケーションの処理毎の統計情報と、前記ディスパッチャ部が保持する前記メッセージ数から算出した前記処理毎の未完了処理数と、再度取得して、新たな移行対象サーバグループを決定することを特徴とする分散処理システム。
【請求項８】
請求項６または請求項７に記載の分散処理システムであって、
前記移行部は、前記監視部が監視するメッセージ数が所定回数連続して０となったアプリケーションサーバに対してアプリケーションの移行を指示することを特徴とする分散処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散実行基盤を用いた分散処理システムのアプリケーション移行の効率化に関する。
【背景技術】
【０００２】
Hadoop（米国その他の国における登録商標）などのデータ処理で適用されてきた分散実行技術を応用し、基幹系システムのアプリケーションサーバへ適用し、高スケーラビリティを実現する基盤（以下「分散実行基盤」という）が存在する。
【０００３】
分散処理システムついて、例えば特許文献１には、複数のクライアントサーバと、複数のＷＥＢサーバと、複数のデータベースサーバと、複数のアプリケーションサーバとで構成され、サーバの負荷分散のパターンが書き込まれたテーブルを有し、前記テーブルに従って負荷が分散される技術が開示されている。また、ＷＥＢサーバの障害を監視する手段を有し、障害が発生したときどのサーバが代替サーバになるかが書き込まれたテーブルを有することが記載されている。これにより、サーバの負荷を容易に分散させ、サーバに障害が発生しても動作が可能な信頼性の高いシステムが記載されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2008-225793号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
分散処理システムではアプリケーションを移行する際に、移行対象である複数のアプリケーションサーバの中から一部のアプリケーションサーバを選んで新たな処理要求を受けない状態（以降、「予閉塞」という）にし、そのアプリケーションサーバ内の処理が全て完了した場合にアプリケーションを入れ替え、また新たに一部のアプリケーションサーバを選んで予閉塞してからアプリケーションを入れ替えるという手順を繰り返すことで旧アプリケーションから新アプリケーションへの移行を行っている。そのため、縮退状態ではあるが分散処理システムの稼働を維持しながらアプリケーションの移行を行える。しかし、アプリケーションの移行には多くの無駄な時間があり、縮退時間が長くなっている。
【０００６】
その一つ目の要因として、移行対象の一部アプリケーションサーバを選ぶときにアプリケーションサーバ毎のＣＰＵ使用率等の負荷状況から早く移行できそうなサーバを選ぶことはできるが、サーバの負荷状況からでは必ずしも移行時間の短いサーバを選ぶことはできず、結果的に縮退時間を延ばしてしまうこともあった。
【０００７】
二つ目の要因として、移行対象のアプリケーションサーバの予閉塞後の全処理の完了確認はアプリケーションが処理サーバ名と処理状況をＤＢなどに管理していない限りは困難であった。そのため、ＣＰＵやメモリの使用率の推移から移行のタイミングを決めるなどしているため、無駄な時間を費やして、縮退時間を延ばしていた。
【０００８】
三つ目の要因として、従来の分散処理システムはクライアント端末からのリクエストを振分けることで負荷分散を行い、１リクエストの処理は１つのアプリケーションサーバで全て行うため、予閉塞する前までに受けたリクエストに対する処理全ての完了を待つ必要があった。
【０００９】
そこで、本発明では、前述の三つの課題の少なくともいずれかを解決し短時間でアプリケーションの移行を実現とすることを目的とする。
【課題を解決するための手段】
【００１０】
上記課題の少なくともいずれかを解決するために、
複数のアプリケーションサーバと管理装置とを含む分散処理システムであって、
アプリケーションサーバは、アプリケーション部と分散実行基盤部とを備え、
アプリケーション部は、
クライアント端末からアプリケーションの実行要求を受け付け、分散実行基盤部にアプリケーションの処理要求のメッセージを通知するアダプタ部と、
分散実行基盤からの依頼によりアプリケーションの処理を実行するプロセッサ部と、を備え、
分散実行基盤部は、
アダプタ部から通知されたメッセージを保持し、メッセージで要求されているアプリケーションの処理を実行させるアプリケーションサーバをルーティングストラテジに従って選択するディスパッチャ部と、
アプリケーションサーバによるアプリケーションの処理毎の統計情報を保持する統計情報格納部と、を備え、
管理装置は、
複数のアプリケーションサーバ毎にアプリケーションの移行状態を管理する移行管理部と、
移行状態が旧アプリケーション稼働中であるアプリケーションサーバに関する、アプリケーションサーバの性能情報と、アプリケーションの処理毎の統計情報と、ディスパッチャ部が保持するメッセージ数から算出した処理毎の未完了処理数と、に基づいて、移行対象サーバグループを決定する移行評価部を備えること分散処理システムを提供する。
【発明の効果】
【００１１】
本発明によれば、アプリケーションの移行の際にシステムの縮退時間を短縮することが可能となる。
【図面の簡単な説明】
【００１２】
【図１】分散処理システムの構成例を示す図である。
【図２】分散実行基盤上で開発するアプリケーションの処理フロー例を示す図である。
【図３】分散実行基盤を用いた分散処理システムの機能ブロック図の例である。
【図４】アプリケーションサーバ移行制御部の処理シーケンス例を示す図である。
【図５】アプリケーション移行時のグループ遷移の例を示す図である。
【図６】アプリケーションサーバ移行制御部が実行する処理例を示すフローチャートである。
【図７】サーバ情報に含まれる統計情報と未完了処理数の例を示す図である。
【図８】サーバ情報に含まれるサーバ性能情報の例を示す図である。
【図９】移行評価部が実行する移行評価の処理フローチャート例を示す図である。
【図１０】移行状態管理テーブルの例を示す図である。
【図１１】移行状態管理テーブルの状態遷移の例を示す図である。
【図１２】アプリケーションサーバの予閉塞動作の例を示すフローチャートである。
【図１３】他サーバ優先ルーティングストラテジの処理例を示すフローチャートである。
【図１４】アプリケーションサーバ管理端末の物理構成例を示す図である。
【図１５】アプリフローファイルの例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施形態について、図面を用いて説明する。
図１は、分散処理システムの構成例を示す図である。アプリケーションサーバ管理端末101とアプリケーションサーバ102、103、104、105とアプリケーションサーバ共有端末106とクライアント端末108及び109がそれぞれネットワーク107に接続され、各々の端末間の通信はネットワーク107を経由して行われる。アプリケーションサーバ102〜105に実装された分散実行基盤上で各種アプリケーションが動作するようになっており、クライアント端末108、109からの要求を受けてアプリケーションを動作させる。アプリケーションサーバ管理端末101は、アプリケーションサーバ102〜105で動作するアプリケーションの新しいアプリケーションへの移行を制御する端末である。アプリケーションサーバ共有端末106は、アプリケーションサーバ102〜105の状態を管理する端末である。なお、アプリケーションサーバ102〜105は4台に限定されるものではなく、所望の台数を配置すればよい。
【００１４】
図２は、分散実行基盤上で事前に開発するアプリケーションの処理フロー例を示す図である。例えば、携帯電話等の新規契約申込み要求をクライアント端末から受けた場合に動作するアプリケーションであり、その新規契約申込み要求に対する受付処理を処理Aとし、新規契約申込み要求に対する業務手続に関する処理を処理Bとし、新規契約申込み要求に対する完了処理を処理Cとする。
【００１５】
また、アプリケーションの各々の処理について、処理要求の受付を行うアダプタと、分散実行基盤のディスパッチャ部205に処理の実行を通知するためのメッセージと、アプリケーションの実処理を行い、さらに後続処理がある場合はその後続処理の実行要求をアダプタに通知するメッセージプロセッサと、で構成され、これらを組み合わせることでアプリケーションのフローの処理を順次実行するように開発する。
【００１６】
以下、アプリケーションフローの動作について説明する。
まず、処理Aアダプタ210は外部からの要求を受信するためのチャネルを開いた状態で待機しており、ネットワーク107を経由してクライアント端末108及び109から要求を受信した場合、その要求に対し処理Aメッセージ211を作成して分散実行基盤のディスパッチャ部205に通知する。
【００１７】
次に、ディスパッチャ部205は処理Aメッセージ211の場合はそれに対応した処理Aメッセージプロセッサ212に処理を依頼する。処理Aメッセージプロセッサ212では、処理Aの実処理を行い、実処理を完了した場合に後続処理である処理Bの実行要求を処理Bアダプタ213に通知する。
【００１８】
次に、処理Bアダプタ213は新たに処理Bメッセージ214を作成して分散実行基盤のディスパッチャ部205に通知する。ディスパッチャ部205は処理Bメッセージ214の場合はそれに対応した処理Bメッセージプロセッサ215に処理を依頼する。処理Bメッセージプロセッサ215では、処理Bの実処理を行い、実処理を完了した場合に後続処理である処理Cの実行要求を処理Cアダプタ216に通知する。
【００１９】
次に、処理Cアダプタ216は新たに処理Cメッセージ217を作成して分散実行基盤のディスパッチャ部205に通知する。ディスパッチャ部205は処理Cメッセージ217の場合はそれに対応した処理Cメッセージプロセッサ218に処理を依頼する。処理Cメッセージプロセッサ218では、処理Cの実処理を行い、後続の処理がないため終了する。
【００２０】
なお、詳細は後述するが、処理Aアダプタ210、処理Bアダプタ213、処理Cアダプタ216、処理Aメッセージプロセッサ212、処理Bメッセージプロセッサ215、処理Cメッセージプロセッサ218は、それぞれ異なるアプリケーションサーバ102〜105上にて動作可能である。このように、クライアント端末からの要求（例：携帯電話等の新規契約申込み要求）を受けた際、従来の分散処理システムであれば当該要求に対する一連の処理を全て所定の一台のアプリケーションサーバで実行するが、本実施形態によれば、クライアント端末からの要求を処理A（例：受付処理）、処理B（例：業務手続処理）、処理C（例：完了処理）に分割することにより、それぞれの処理を別々のアプリケーションサーバに実行させることが可能となっている。
【００２１】
図３は、分散実行基盤を用いた分散処理システムの機能ブロック図の例である。アプリケーションサーバ102〜105は、アプリケーション２００、分散実行基盤300、サーバ情報作成部311を備える。アプリケーション200はアダプタ部203とメッセージプロセッサ部200を備えており、アダプタ部203は例えば図２で説明した処理Aアダプタ210や処理Bアダプタ213や処理Cアダプタ216等の複数のアダプタを有している。また、メッセージプロセッサ部200も例えば図２で説明した処理Aメッセージプロセッサ212や処理Bメッセージプロセッサ215や処理Cメッセージプロセッサ218等の複数のメッセージプロセッサを有している。
【００２２】
分散実行基盤300は、管理コンソール部302、受付可能サーバ管理部304、統計情報作成部306、統計情報格納部307、他アプリケーションサーバ処理依頼管理部308、ディスパッチャ部205を備えている。ディスパッチャ部205は、図２で説明したディスパッチャ部205に対応する機能部であり、未完了メッセージ格納部303とルーティングストラテジ部305を有する。
【００２３】
アプリケーションサーバ管理端末101は、アプリケーションサーバ移行制御部301、アプリフロー定義部325、移行管理部326を備え、アプリケーションサーバ移行制御部301はさらに移行評価部321、予閉塞指示部322、処理状況監視部323、移行指示部324を備えている。また、クライアント端末108、109は、アプリケーション実行要求部310を備え、アプリケーションサーバ共有端末106は、サーバ状態管理部309を備えている。なお、サーバ状態管理部309は、全アプリケーションサーバ102〜105の状態を管理しており、各アプリケーションサーバがビジー状態であったり、予閉塞によって処理要求の受付不可状態である等の各種状態を保持している。
【００２４】
ここで、本実施形態における分散処理方式を用いたアプリケーション実行について説明する。
【００２５】
まず、クライアント端末108のアプリケーション実行要求部310からアプリケーションサーバ102にアプリケーション実行要求を送信すると、アプリケーション実行要求を受けたアダプタ部203（図2では処理Aアダプタ210）はアプリケーションの処理要求メッセージを作成して分散実行基盤300のディスパッチャ部205に通知する。
【００２６】
通知を受けたディスパッチャ部205は、まず、そのメッセージを未完了メッセージ格納部303に格納する。次にディスパッチャ部205は受付可能サーバ管理部304にアプリケーションの処理要求を受付可能なアプリケーションサーバを問い合わせる。受付可能サーバ管理部304は定期的にアプリケーションサーバ共有端末106のサーバ状態管理部309と通信することにより、他のアプリケーションサーバの状態を把握しているため、例えばビジー状態のアプリケーションサーバがあった場合は、そのサーバは除外して受付可能なアプリケーションサーバをディスパッチャ部205に回答する。なお、受付可能なサーバには必ず自アプリケーションサーバを含む。
【００２７】
次に受付可能なサーバを受け取ったディスパッチャ部205は、ルーティングストラテジ部305へ受付可能なサーバを通知し、ルーティングストラテジを実行して受付可能な複数のサーバから処理を実行するサーバ（以降、実行サーバ）を１つ選択させる。実行サーバが自サーバだった場合、ディスパッチャ部205は、メッセージプロセッサ部204（図2では処理Aメッセージプロセッサ212）に処理の依頼を行い、メッセージプロセッサ部204から処理の完了通知を受信すると、未完了メッセージ格納部303に格納していた処理要求メッセージを削除する。また、ディスパッチャ部205は、その処理に対しての処理時間などを統計情報作成部306に通知し、統計情報格納部307に格納させる。なお、ルーティングストラテジとしては、自サーバを含む複数の受付可能なサーバの中からラウンドロビン方式で１台の実行サーバを選択したり、アプリケーションの処理要求メッセージに含まれる所定の情報のハッシュ値に基づいて実行サーバを選択する方式など、任意のアルゴリズムを採用可能である。
【００２８】
一方、ルーティングストラテジ部305が選択した実行サーバが自サーバでなかった場合、ディスパッチャ部205は、自アプリケーションサーバのメッセージプロセッサ部204に処理の依頼は行わず、他のアプリケーションサーバとの処理依頼の送受信を行う他アプリケーションサーバ処理依頼管理部308へ通知し、未完了メッセージ格納部303に格納していた処理要求メッセージを削除する。
【００２９】
他アプリケーションサーバ処理依頼管理部308は実行サーバへ処理を依頼し、実行サーバの他アプリケーションサーバ処理依頼管理部308がディスパッチャ部205に通知し、未完了メッセージ格納部303に処理要求メッセージを格納する。実行サーバのディスパッチャ部205は、自アプリケーションサーバのメッセージプロセッサ部204に処理の依頼を行い、メッセージプロセッサ部204から処理の完了通知を受信すると、未完了メッセージ格納部303に格納していた処理要求メッセージを削除する。また、実行サーバのディスパッチャ部205は、その処理に対しての処理時間などを統計情報作成部306に通知し、統計情報格納部307に格納させる。
【００３０】
メッセージプロセッサ部204はアプリケーションの処理要求に対する実処理を実行した後、当該処理に後続する処理がある場合は当該後続する処理の実行要求をアダプタ部203（図2では処理Bアダプタ213）へ通知し、アプリケーションの後続処理の依頼をする。以上の手順をアプリケーションの後続処理が無くなるまで行う。
【００３１】
次に、アプリケーションサーバ102〜105で動作する旧アプリケーションを新アプリケーションへ移行する際のアプリケーションサーバ管理端末101の動作を中心に説明する。アプリケーションサーバ管理端末101のアプリケーションサーバ移行制御部301は、全てのアプリケーションサーバ102〜105のサーバ情報作成部311および管理コンソール部302と接続されている。
【００３２】
また、アプリフロー定義格納部325には、クライアント端末108及び109から要求を受信するアダプタ部203（図2では処理Aアダプタ210）を特定できる情報とアプリケーションの処理の実行順序についての情報が定義されたファイル（以降、アプリフローファイル）が格納され、移行評価部321と予閉塞指示部322で使用される。
【００３３】
図１５は、アプリフローファイルの例を示す図である。クライアント端末からの要求を処理Aアダプタで受信し、処理A、処理Bアダプタ、処理B、処理Cアダプタ、処理Cの順番で実行されることが示されている。
【００３４】
また、移行管理部326は、各アプリケーションサーバ102〜105における旧アプリケーションから新アプリケーションへの移行状態を管理しており、後述する移行状態管理テーブルを保持している。
【００３５】
移行評価部321は、旧アプリケーションを稼働中のアプリケーションサーバから移行評価に必要な各種情報を取得する。具体的には、アプリケーションサーバのサーバ情報作成部311からサーバの性能情報を取得し、管理コンソール302を経由して統計情報作成部306から旧アプリケーションの処理毎の統計情報を取得し、未完了メッセージ格納部303から完了していない処理の数（以降、未完了処理数）を取得する。なお、未完了処理数は、未完了メッセージ格納部303が保持しているアプリケーションの処理要求メッセージの数である。また、アプリフロー定義格納部325に格納されるファイルから旧アプリケーションの処理の実行順序を取得し、これら取得した各種情報に基づいて移行評価を行う。詳細は後述するが、移行評価では、旧アプリケーションを稼働中のアプリケーションサーバのうち、どのアプリケーションサーバを新アプリケーションに移行させるかを決定する。
【００３６】
予閉塞指示部322は、旧アプリケーションのアプリフローファイルからクライアント端末108及び109から要求を受信するアダプタ（以降、外部要求受信アダプタ）を特定し、移行評価で決定された移行を行うアプリケーションサーバの管理コンソール部302を経由して、アダプタ部203に、外部要求受信アダプタの停止指示を行い、クライアント端末108及び109から旧アプリケーションの処理要求を受信しないようにする。なお、図１５の例でいえば、外部要求受信アダプタは処理Aアダプタである。
【００３７】
次に、予閉塞指示部322は、受付可能サーバ管理部304に対してノード閉塞指示を行い、これにより受付可能サーバ管理部304は、アプリケーションサーバ共有端末106のサーバ状態管理部309に対して移行対象のアプリケーションサーバを「受付不可状態」とするよう指示を行う。次に、予閉塞指示部322は、ルーティングストラテジ部305に対してルーティングストラテジの変更指示を行い、複数サーバから処理を実行する１サーバを選定するロジックを変更させる。具体的には、処理を受付可能な複数のアプリケーションサーバがあった場合に、自サーバ以外のサーバを選択するようにルーティングストラテジを変更する。
【００３８】
処理状況監視部323は、予閉塞指示部322が予閉塞指示を行ったアプリケーションサーバの管理コンソール部302を経由し、未完了メッセージ格納部303から未完了処理数を取得し、アプリケーションサーバ内の処理がなくなることを監視する。
【００３９】
移行指示部324は、処理状況監視部323でアプリケーションサーバ内の処理がなくなった場合に、管理コンソール部302を経由し、旧アプリケーションのアンデプロイと新アプリケーションのデプロイを指示してアプリケーションを移行させる。
【００４０】
図４は、アプリケーションサーバ管理端末101のアプリケーションサーバ移行制御部301の処理シーケンス例を示す図である。図４では、旧アプリケーションを稼働中のアプリケーションサーバ102〜105を段階的に新アプリケーションに移行するための処理シーケンスを説明する。
【００４１】
まず、ステップ401において、新アプリケーションへ移行するアプリケーションサーバを決定するための情報（以降、移行評価情報）を作成するために、アプリケーションサーバ102〜105に対して、未完了処理数と統計情報とサーバ性能情報を纏めた情報（以降、サーバ情報）の送信を要求する。アプリケーションサーバ102〜105は、それぞれステップ420、430、440、450でサーバ情報をアプリケーション管理端末101へ送信する。アプリケーションサーバ移行制御部301は、受信したサーバ情報を纏めて移行評価情報を作成する。
【００４２】
次に、ステップ402において、アプリケーションサーバ管理端末101は作成した移行評価情報を評価し、移行対象のサーバをアプリケーションサーバ102及び103に決定する。
【００４３】
次に、ステップ403において、移行対象としたアプリケーションサーバ102及び103に対して予閉塞指示をする。予閉塞指示を受けたアプリケーションサーバ102及び103はそれぞれステップ421、431で、予閉塞を実行する。
【００４４】
次に、ステップ404において、予閉塞指示を行ったアプリケーションサーバ102及び103に対してそれぞれステップ422、423とステップ432、433で未完了処理数を送信させ、アプリケーションサーバそれぞれの未完了処理を監視し、アプリケーションサーバ102については未完了処理がなくなったと判断された。
【００４５】
次に、ステップ405において、未完了処理がなくなったアプリケーションサーバ102に移行指示を行い、アプリケーションサーバ102はステップ424において旧アプリケーションから新アプリケーションへの移行を行う。
【００４６】
次に、ステップ406において、予閉塞を指示済みで、且つ、未だ新アプリケーションに移行していないアプリケーションサーバ103に対して、ステップ434において未完了処理数を送信させ、未完了処理の監視を再開し、アプリケーションサーバ103について未完了処理がなくなったと判断された。
【００４７】
次に、ステップ407において、未完了処理がなくなったアプリケーションサーバ103に移行指示を行い、アプリケーションサーバ103はステップ435において旧アプリケーションから新アプリケーションへの移行を行う。
【００４８】
次に、予閉塞を指示したアプリケーションサーバは全て移行されたため、ステップ408において未だ移行されていないアプリケーションサーバ104及び105に対してサーバ情報の送信を要求する。アプリケーションサーバ104及び105は、それぞれステップ441、451でサーバ情報をアプリケーションサーバ管理端末101へ送信する。アプリケーションサーバ移行制御部301は、受信したサーバ情報を纏めて移行評価情報を作成する。
【００４９】
次に、ステップ409において、アプリケーションサーバ管理端末101は、作成した移行評価情報を評価し、移行対象のサーバをアプリケーションサーバ104に決定する。
【００５０】
次に、ステップ410において、移行対象としたアプリケーションサーバ104に対して予閉塞指示をする。予閉塞指示を受けたアプリケーションサーバ104はステップ442で、予閉塞を実行する。
【００５１】
次に、ステップ411において、予閉塞を指示したアプリケーションサーバ104に対してステップ443で未完了処理数を送信させ、未完了処理の監視を行い、アプリケーションサーバ104については未完了処理がなくなったと判断された。
【００５２】
次に、ステップ412において、未完了処理がなくなったアプリケーションサーバ104に移行指示を行い、アプリケーションサーバ104ではステップ444で新アプリケーションへの移行を行う。
【００５３】
次に、予閉塞指示を行ったアプリケーションサーバは全て移行されたため、ステップ413において未だ移行されていないアプリケーションサーバ105に対してサーバ情報の送信を要求する。アプリケーションサーバ105は、ステップ452でサーバ情報をアプリケーションサーバ管理端末101へ送信する。アプリケーションサーバ移行制御部301は、受信したサーバ情報を纏めて移行評価情報を作成する。
【００５４】
次に、ステップ414において、アプリケーションサーバ管理端末101は、作成した移行評価情報を評価し、移行対象のサーバをアプリケーションサーバ105に決定する。
【００５５】
次に、ステップ415において、移行対象としたアプリケーションサーバ105に対して予閉塞指示をする。予閉塞指示を受けたアプリケーションサーバ105はステップ453で、予閉塞を実行する。
【００５６】
次に、ステップ416において、予閉塞指示を行ったアプリケーションサーバ105に対して、ステップ454、455、456で未完了処理数を送信させ、未完了処理の監視をし、アプリケーションサーバ105については未完了処理がなくなったと判断された。
【００５７】
次に、ステップ417において、未完了処理がなくなったアプリケーションサーバ105に移行指示を行い、アプリケーションサーバ105はステップ457で新アプリケーションへの移行を行う。
【００５８】
以上の手順により、旧アプリケーションから新アプリケーションへの移行を実現する。
【００５９】
図５は、アプリケーションサーバ102〜105が図４のシーケンスにより旧アプリケーションから新アプリケーションに移行するにあたってのグループ遷移の例を示す図である。
【００６０】
まず、ステップ501は、初期状態であり、全てのアプリケーションサーバ102〜105は旧アプリケーションのグループに属しており、ステップ402の移行評価によりステップ502の状態に遷移する。
【００６１】
ステップ502では、旧アプリケーションのグループを移行対象グループと移行対象外グループのサブグループに分割し、移行対象グループのアプリケーションサーバ102、103に対してステップ421、431で予閉塞を実行する。予閉塞を実行したアプリケーションサーバはクライアント端末108、109からの処理要求と他のアプリケーションサーバからの処理要求を受けなくなり、さらに、自アプリケーションサーバで実行している処理については、後続の処理を移行対象外グループのアプリケーションサーバへ依頼し、後続の処理は自アプリケーションサーバでは行わない。このようにすることで、予閉塞を行ったアプリケーションサーバ内の全ての処理の完了までの時間を短縮する。予閉塞を実行したアプリケーションサーバ102、103内の全ての処理が完了した場合、それぞれステップ424、435で移行を行い、ステップ503に遷移する。
【００６２】
ステップ503では、移行したアプリケーションサーバ102、103は新アプリケーションのグループとなる。分散実行基盤300では、動作するアプリケーションの資材名とそのハッシュ値を元に旧アプリケーションと同一のアプリケーションが稼働していないことを検知するため、別の領域で管理されることになる。このため、新アプリケーショングループのアプリケーションサーバへ旧アプリケーションの処理要求が行われることはない。旧アプリケーションのグループのアプリケーションサーバ104、105に対して、ステップ409で移行評価を行い、ステップ504へ遷移する。
【００６３】
ステップ504では、旧アプリケーションのグループを移行対象グループと移行対象外グループのサブグループに分割し、移行対象グループのアプリケーションサーバ104に対してステップ442で予閉塞を実行する。予閉塞を実行したアプリケーションサーバ104はクライアント端末108、109からの処理要求とアプリケーションサーバ105からの処理要求を受けなくなり、さらに、自アプリケーションサーバで実行している処理については、後続の処理を移行対象外グループのアプリケーションサーバ105へ依頼し、後続の処理は自アプリケーションサーバでは行わない。予閉塞を実行したアプリケーションサーバ104内の全ての処理が完了した場合、ステップ444で移行を行い、ステップ505に遷移する。
【００６４】
ステップ505では、移行したアプリケーションサーバ104は新アプリケーションのグループに追加され、旧アプリケーションのグループはアプリケーションサーバ105のみになり、アプリケーションサーバ105に対して、ステップ414で移行評価を行い、ステップ506へ遷移する。
【００６５】
ステップ506では、旧アプリケーションのグループはアプリケーションサーバ105を移行対象グループとし、ステップ453で予閉塞を実行する。予閉塞を実行したアプリケーションサーバ105はクライアント端末108、109からの処理要求を受けなくなる。旧アプリケーションのグループには予閉塞を行ったアプリケーションサーバ105以外にないため、自アプリケーションサーバで実行している処理については、後続の処理を含めて全て実行する。予閉塞を実行したアプリケーションサーバ105内の全ての処理が完了した場合、ステップ457で移行を行い、ステップ507に遷移し、全てのアプリケーションサーバは新アプリケーションのグループになる。
【００６６】
図６は、アプリケーションサーバ移行制御部301が実行する処理例を示すフローチャート図である。図６では、アプリケーションの移行を行う際の処理内容を示している。
【００６７】
まず、ステップ601において、移行評価部321は、移行管理部326が保持する移行状態管理テーブル（図１０で後述）を参照し、旧アプリケーションが稼働中のアプリケーションサーバの台数が１以上かを判定する。１以上の場合はステップ602に遷移し、１以上でない場合（0の場合）は処理を終了する。
【００６８】
ステップ602において、移行評価部321は、旧アプリケーションが稼働中の全てのアプリケーションサーバからサーバ情報（未完了処理数と統計情報とサーバ性能情報）を取得し、これらの情報を纏めて移行評価情報を作成し、ステップ603へ遷移する。
【００６９】
ステップ603では、移行評価部321は、アプリフロー定義格納部325に格納されている旧アプリケーションのアプリフローファイルから処理の実行順序を取得し、ステップ602で作成した移行評価情報も参照して移行評価を行う（移行評価の詳細については図９を用いて後述する）。移行評価の結果、アプリケーションの移行を行うアプリケーションサーバを0以上選定し、移行対象グループを決定する。
【００７０】
次に、ステップ604において、ステップ604で決定した移行対象グループのサーバ数を判定し、1以上である場合はステップ605へ遷移する。一方、1以上でない場合（0の場合）はステップ613へ遷移し、一定時間待機した後にステップ601へ遷移する。
【００７１】
ステップ605では、予閉塞指示部322は、アプリフロー定義格納部325に格納されている旧アプリケーションのアプリフローファイルから外部要求受信アダプタ（図１５の例における処理アダプタA）を取得し、移行対象グループの全てのサーバに対して予閉塞指示を行い、ステップ606へ遷移する。
【００７２】
なお、予閉塞指示部322は、予閉塞指示として、以下（１）〜（３）の処理を行う。
（１）外部要求受信アダプタの停止指示を行い、クライアント端末108及び109から旧アプリケーションの処理要求を受信しないようにする。
（２）受付可能サーバ管理部304に対してノード閉塞指示を行う。ノード閉塞指示を受けた受付可能サーバ管理部304は、アプリケーションサーバ共有端末106のサーバ状態管理部309に対して移行対象のアプリケーションサーバを「受付不可状態」とするよう指示を行う。これにより、ディスパッチャ部205からアプリケーションの処理要求を受付可能なアプリケーションサーバの問合せを受けた受付可能サーバ管理部304は、受付不可状態となったアプリケーションサーバを受付可能なアプリケーションサーバとして回答しなくなる。
（３）ルーティングストラテジ部305に対してルーティングストラテジの変更指示を行い、複数サーバから処理を実行する１サーバを選定するロジックを変更させる。具体的には、処理を受付可能な複数のアプリケーションサーバがあった場合に、自サーバ以外のサーバを選択するようにルーティングストラテジを変更する。
【００７３】
次に、ステップ606から移行対象グループのサーバ数分の繰り返しを開始し、ステップ607へ遷移する。
【００７４】
ステップ607において、処理状況監視部323は、移行対象グループのアプリケーションサーバの未完了メッセージ格納部303から未完了処理数を取得し、ステップ608へ遷移する。
【００７５】
ステップ608では、処理状況監視部323は、ステップ607で取得した未完了処理数が「0」の場合、未完了処理数「0」が所定回数以上連続したかを判定し、所定回数以上連続している場合、ステップ609へ遷移する。この所定回数は、アプリケーションサーバ内にアプリケーションの処理がなくなっていることを確実に確認するための回数であり、任意の回数を設定可能である。
【００７６】
ステップ609では、移行指示部324は、未処理回数「0」が所定回数以上連続したアプリケーションサーバに対して移行指示を行い、移行対象グループから当該アプリケーションサーバを削除する。
【００７７】
ステップ608において、所定回数以上「0」が連続していない場合、ステップ610へ遷移する。
【００７８】
ステップ610では、移行対象グループのサーバ数分の繰り返しを終えた場合、ステップ611に遷移する。
【００７９】
ステップ611では、移行対象グループのサーバ数がまだ１以上残っている場合（すなわちステップ605で予閉塞指示をしたサーバの中でまだ移行指示を行っていないサーバがある場合）は、ステップ612で一定時間待機を行い、再度ステップ606へ遷移する。ステップ611で移行対象グループのサーバ数が１以上でない場合（すなわちステップ605で予閉塞指示をしたサーバが全てに対して移行指示を行った場合）は、再度、移行対象グループを決定するため、ステップ613で一定時間待機した後に、ステップ601へ遷移する。
【００８０】
図７は、サーバ情報に含まれる統計情報と未完了処理数の例を示す図である。統計情報は統計情報作成部306で、未完了処理数は未完了メッセージ格納部303でそれぞれ作成され、図４のステップ420、430、440、450等においてアプリケーションサーバ102〜105からアプリケーションサーバ管理端末101へサーバ情報として送信される。サーバ情報は複数のアプリケーションサーバ毎に作成されるが、図７の例では、所定の一台のアプリケーションサーバで作成されたサーバ情報の例を示している。統計情報としては、処理毎の平均処理時間、平均CPU時間、平均メモリ使用時間が含まれている。これらの情報は移行評価の際に利用される。
【００８１】
項番１は処理Aについての未完了処理数と統計情報であり、１実行あたりの平均の処理時間は121ミリ秒でCPUを使用する時間は15ミリ秒でメモリ使用量は1MBで、現在の未完了処理数は15であることを示す。
項番２は処理Bについての未完了処理数と統計情報であり、１実行あたりの平均の処理時間は568ミリ秒でCPUを使用する時間は65ミリ秒でメモリ使用量は3MBで、現在の未完了処理数は126であることを示す。
項番３は処理Cについての未完了処理数と統計情報であり、１実行あたりの平均の処理時間は158ミリ秒でCPUを使用する時間は6ミリ秒でメモリ使用量は2MBで、現在の未完了処理数は48であることを示す。
【００８２】
図８は、サーバ情報に含まれるサーバ性能情報の例を示す図である。サーバ性能情報はサーバ情報作成部311で作成され、ステップ420、430、440、450等においてアプリケーションサーバ102〜105からアプリケーションサーバ管理端末101へサーバ情報として送信される。サーバ性能情報は複数のアプリケーションサーバ毎に作成されるが、図８の例では、所定の一台のアプリケーションサーバに関するサーバ性能情報の例を示している。
【００８３】
並列実行最大数は、処理を最大で32個並列実行できることを示しており、移行評価の際に、予閉塞後の全処理完了の想定時間を算出するために使用される。CPUコア数は、4つであることを示しており、移行評価の際に、レイテンシーを守れるCPUコア数が確保されるか判断するために使用される。メモリ量は、8000MBであることを示しており、移行評価の際に、システムとして必要なメモリ量を確保されるか判断するために使用される。
【００８４】
図９は、移行評価部321が実行する移行評価の処理フローチャート例を示す図である。この移行評価は、図４のステップ402や図６のステップ603で行われる処理である。
【００８５】
まず、ステップ901では、図７の平均CPU時間と平均メモリ使用量と未完了処理数を元にし、アプリフロー定義格納部325に格納された旧アプリケーションのアプリフローファイルから処理の実行順序を取得した上で、全ての未完了の処理を実行する際の総CPU時間からレイテンシーを守れる必要CPUコア数と必要メモリ量を計算する。
【００８６】
必要CPUコア数について、例えば図７と同じサーバ情報を４台のアプリケーションサーバ102〜105が返却し、レイテンシーが3,000ミリ秒で余力10％を加味する場合を例に説明する。
【００８７】
未完了の処理Aを実行するのに必要なCPU時間については、「平均CPU時間(15ミリ秒)×未完了処理数(15個)×サーバ台数(4台)＝900ミリ秒」となる。
未完了の処理Bを実行するのに必要なCPU時間については、「平均CPU時間(65ミリ)×未完了処理数(126個+15個（処理Aの未完了分実行後に処理Bを実行することになるため加算する）)×サーバ台数(4台)＝36,660ミリ秒」となる。なお、以下同じであるが、例えば処理Aの後に処理Bを実行することは、アプリフローファイルから各処理の実行順序を参照することで把握することができる。
未完了の処理Cを実行するのに必要なCPU時間については、「平均CPU時間(6ミリ)×未完了処理数(48個+126個+15個（処理Aと処理Bの未完了分実行後に処理Cを実行することになるため加算する）)×サーバ台数(4台)＝4,536ミリ秒」となる。
【００８８】
以上の処理A〜処理Cを実行するのに必要なCPU時間を加算すると「42,096ミリ秒」であり、余力10％を加味すると、総CPU時間は「46,305.6ミリ秒」となる。レイテンシー3,000ミリ秒に収めるため、「総CPU時間46,305.6ミリ秒/レイテンシー3000ミリ秒＝15.4352」から、小数点以下切り上げを行い必要CPUコア数は16コアと計算できる。
【００８９】
次に、必要メモリ量について、同様に図７と同じサーバ情報を４台のアプリケーションサーバ102〜105が返却し、余力10％を加味する場合を例に説明する。
【００９０】
未完了の処理Aを実行するのに必要なメモリ量については、「平均メモリ使用量(1MB)×未完了処理数(15個)×サーバ台数(4台)＝60MB」となる。
未完了の処理Bを実行するのに必要なメモリ量については、「平均メモリ使用量(3MB)×未完了処理数(126個+15個（処理Aの未完了分実行後に処理Bを実行することになるため加算する）)×サーバ台数(4台)＝1,692MB」となる。
未完了の処理Cを実行するのに必要なメモリ量については、「平均メモリ使用量(2MB)×未完了処理数(48個+126個+15個（処理Aと処理Bの未完了分実行後に処理Cを実行することになるため加算する）)×サーバ台数(4台)＝1,512MB」となる。
【００９１】
以上の処理A〜処理Cを実行するのに必要なメモリ量を加算すると「3264MB」であり、余力10％を加味すると、必要メモリ量は「3,590.4MB」となる。
【００９２】
次にステップ902では、図７の平均処理時間と未完了処理数と図８の並列実行最大数から、サーバごとに処理完了想定時間を計算する。また、全ての処理の未完了処理数の合計値が並列実行最大数以下になる場合は、平均処理時間の中で最大の時間を採用する。
【００９３】
例えば、図７と図８の場合は、全ての処理の未完了処理数の合計値が並列実行最大数より大きいため、以降の計算を実施する。
処理Aについての処理時間は、「平均処理時間(121ミリ秒)×未完了数(15個)＝1815ミリ秒」となる。
処理Bについての処理時間は、「平均処理時間(568ミリ秒)×未完了数(126個)＝71568ミリ秒」となる。
処理Cについての処理時間は、「平均処理時間(158ミリ秒)×未完了数(48個)＝7584ミリ秒」となる。
以上の処理A〜処理Cの処理時間を全て加算すると「80967ミリ秒」となる。80967ミリ秒を並列実行最大数の多重で実行するとし、「80967ミリ秒/並列実行最大数(32)」を計算することで、本アプリケーションサーバにおける処理完了想定時間は「2,530.218ミリ秒」と算出できる。このように全てのアプリケーションサーバ102〜105それぞれについて、処理完了想定時間を算出する。
【００９４】
次にステップ903では、図８の各アプリケーションサーバの性能情報と、ステップ901で算出した必要CPUコア数および必要メモリ量とを比較し、必要CPUコア数および必要メモリ量を満たし且つ最小のサーバ数となるアプリケーションサーバの組み合わせパターン（以下、サーバ組み合わせパターン）を作成し、ステップ904に遷移する。
【００９５】
次にステップ904では、ステップ903で作成したサーバ組み合わせパターンごとに、その組み合わせに入らないサーバ（移行対象グループの候補となるサーバ）についてステップ902で算出した処理完了想定時間を平均した値（以下、処理完了平均想定時間）を計算し、ステップ905へ遷移する。
【００９６】
次にステップ905では、ステップ904で計算した処理完了平均想定時間が最小となるサーバ組み合わせパターンを選択し、選択されたサーバ組み合わせパターンに含まれるアプリケーションサーバを移行対象外グループとし、サーバ組み合わせパターンに含まれないアプリケーションサーバを移行対象グループと決定する。
【００９７】
このような移行評価によって、旧アプリケーションが稼働中のアプリケーションサーバの中から移行対象グループのアプリケーションサーバを決定することができる。図６のフローで説明したように、移行対象グループのアプリケーションサーバが決定されると、これらのサーバに対して予閉塞指示を行い（ステップ605）、その後の移行処理が進められる。
【００９８】
図１０は、移行状態管理テーブルの例を示す図である。移行管理部326が保持しており、アプリケーションサーバの旧アプリケーションから新アプリケーションへの移行状況を管理している。
項番１では、アプリケーションサーバ102が新アプリケーションを稼働中であり、移行が完了している状態であることを示している。
項番２では、アプリケーションサーバ103が新アプリケーションを稼働中であり、移行が完了している状態であることを示している。
項番３では、アプリケーションサーバ104に対して予閉塞指示が行われており、サーバ内の全ての処理の完了を監視している状態であることを示している。
項番４では、アプリケーションサーバ105が旧アプリケーションを稼働中であり、未だ移行対象グループに選ばれていないことを示している。
【００９９】
図１１は、移行状態管理テーブルの状態遷移の例を示す図である。
ステップ1101は、アプリケーションサーバが初期状態で旧アプリケーションを稼働しており、アプリケーション移行を行っていない状態であることを示している。図６のステップ603で行われる移行評価により移行対象グループに選出されると、移行状態管理テーブルが更新され、ステップ1102の予閉塞待ちの状態に遷移する。図６のステップ605で予閉塞指示が行われると、移行状態管理テーブルが更新され、ステップ1103の全処理完了待ちの状態に遷移する。アプリケーションサーバで実行されている全ての処理が完了し、図６のステップ608で未完了処理数「0」が所定回数以上連続すると、移行状態管理テーブルが更新され、ステップ1104の移行待ちの状態に遷移する。そして、図６のステップ609で移行指示が行われると、移行状態管理テーブルが更新され、ステップ1105の新アプリケーション稼働中の状態に遷移する。
【０１００】
図１２は、図４のステップ421、431等で行われるアプリケーションサーバの予閉塞動作の例を示すフローチャートである。アプリケーションサーバの予閉塞動作は、移行指示部324からの予閉塞指示により行われるものであり、図１２の動作フローは、図６のステップ605で説明した予閉塞指示に伴う処理（１）〜（３）に対応するものである。
【０１０１】
まず、ステップ1201では、予閉塞指示を受けたアダプタ部203が、外部要求受信アダプタ（図２によれば、処理Aアダプタ）を停止し、チャネルを閉じることで外部（クライアント端末108、109等）からのアプリケーションの実行要求を受けないようにし、ステップ1202へ遷移する。
【０１０２】
次に、ステップ1202では、予閉塞指示を受けた受付可能サーバ管理部304が、アプリケーションサーバ共有端末106のサーバ状態管理部309へ自アプリケーションサーバが予閉塞状態になったことを通知する。これにより、他のアプリケーションサーバの受付可能サーバ管理部304がディスパッチャ部205へ回答する受付可能なサーバから自アプリケーションサーバを除外する。そのため、他のアプリケーションサーバは、予閉塞状態になったアプリケーションサーバに対して処理の依頼ができないようになる。
【０１０３】
次に、ステップ1203では、予閉塞指示を受けたルーティングストラテジ部305が、ルーティングストラテジを他サーバ優先ルーティングストラテジに変更する。このことにより、例えば処理Aを実行していた場合、後続の処理Bアダプタが処理Bメッセージを作成しディスパッチャ部205に通知した時、後続処理である処理Bの処理要求は他のアプリケーションサーバへ優先して依頼され、自サーバでは後続処理は行わない。そのため、より早く自サーバの処理を完了させることが可能となる。
【０１０４】
図１３は、他サーバ優先ルーティングストラテジの処理例を示すフローチャートである。
まず、ステップ1301では、ルーティングストラテジ部305は、受付可能サーバ管理部304が回答した受付可能なサーバの中に自サーバ以外が存在するか判定し、自サーバ以外が存在すればステップ1302で自サーバ以外のアプリケーションサーバの中からランダムに１つのサーバを選択する。自サーバのみしか無い場合は、ステップ1303で自サーバを返却する。
【０１０５】
図１４は、アプリケーションサーバ管理端末101の物理構成例を示す図である。CPU1401とメモリ1402とストレージ1406とネットワークインターフェース1411がデータバス1410により接続されており、各々がデータバス1410を経由して通信する。ネットワークインターフェース1411はネットワーク107と接続される。
【０１０６】
図３に示すアプリケーションサーバ移行制御部301は、通常時には、ストレージ1406にアプリケーションサーバ移行制御プログラムファイルとして格納される。実際にアプリケーションサーバ移行が実行される際には、CPU1401の命令によって、ストレージ1406のアプリケーションサーバ移行制御プログラムファイル1408からデータバス1410を経由してメモリ1402に展開され、CPU1401の命令によって実行される。アプリケーションサーバ移行制御プログラムファイル1408は、アプリケーションサーバ移行制御プログラム1404としてメモリ1402に展開される。一時データ1405は、一時的な記憶データであり、動作する際に必要なデータが格納され必要に応じて参照及び更新され、アプリケーションサーバ移行制御部301の終了後に消去される。また、アプリフロー定義格納部325や移行管理部326もアプリケーションサーバ移行制御部301と同様にプログラムファイルとしてストレージ1406に格納されており、CPU1401の命令によって、メモリ1402に展開され、実行される。ネットワークインターフェース1411は、ネットワーク107を経由し、図１に示すアプリケーションサーバそれぞれの端末との通信を接続する。
【０１０７】
なお、アプリケーションサーバ102〜105、アプリケーションサーバ共有端末106、クライアント端末108,109も同様にCPU、メモリ、ストレージ、ネットワークIF等の物理構成を有しており、ストレージに格納されたプログラムファイルをCPUがメモリに展開して実行することにより、各機能部を実現している。
【０１０８】
以上説明したように、本実施形態によれば、移行するアプリケーションサーバ毎の性能や処理毎の統計情報・現在の未完了の処理数などから最短で移行できるサーバを予閉塞し、全処理の完了確認を確実に行う。また、アプリケーションの処理を実行中であったとしても、予閉塞された場合には、移行対象でない他のサーバに後続の処理を依頼し、システムの縮退時間を短縮することが可能となる。
【符号の説明】
【０１０９】
101：アプリケーション管理端末、102〜105：アプリケーションサーバ、106：アプリケーションサーバ共有端末、107：ネットワーク、108，109：クライアント端末、200：アプリケーション、203：アダプタ部、204：メッセージプロセッサ部、205：ディスパッチャ部、210：処理Aアダプタ、211：処理Aメッセージ、212：処理Aメッセージプロセッサ、213：処理Bアダプタ、214：処理Bメッセージ、215：処理Bメッセージプロセッサ、216：処理Cアダプタ、217：処理Cメッセージ、218：処理Cメッセージプロセッサ、301：アプリケーションサーバ移行制御部、302：管理コンソール部、303：未完了メッセージ格納部、304：受付可能サーバ管理部、305：ルーティングストラテジ部、306：統計情報作成部、307：統計情報格納部、308：他アプリケーションサーバ処理依頼管理部、309：サーバ状態管理部、310：アプリケーション実行要求部、311：サーバ情報作成部、321：移行評価部、322：予閉塞指示部、323：処理状況監視部、324：移行指示部、325：アプリフロー定義部、326：移行管理部
【図１】
2015219732.tif 000003
【図２】
2015219732.tif 000004
【図３】
2015219732.tif 000005
【図４】
2015219732.tif 000006
【図５】
2015219732.tif 000007
【図６】
2015219732.tif 000008
【図７】
2015219732.tif 000009
【図８】
2015219732.tif 000010
【図９】
2015219732.tif 000011
【図１０】
2015219732.tif 000012
【図１１】
2015219732.tif 000013
【図１２】
2015219732.tif 000014
【図１３】
2015219732.tif 000015
【図１４】
2015219732.tif 000016
【図１５】
2015219732.tif 000017