JP2021033892A - 管理装置、サーバシステム、および、管理方法 - Google Patents

Abstract

【課題】クラウドシステムにおけるソフトウェアに関わる変更が原因となって不具合が生じた場合でも、当該不具合がサービスに及ぼす悪影響を抑制することができる技術を提供する。【解決手段】管理装置は、複数のローカルサーバとネットワークを介して接続されるセンタ装置が有する複数の情報処理装置を管理する。管理装置は、前記複数の情報処理装置のソフトウェアに関わる変更が必要である場合に、前記複数のローカルサーバを所定の条件に従って複数のグループにグループ分けするグループ分け部と、前記複数のグループのうちの一部のグループを前記変更が行われる前記情報処理装置に割り当て、残りのグループを前記変更が行われない前記情報処理装置に割り当てる割当部と、を備える。【選択図】図１

Description

本発明は、管理装置、サーバシステム、および、管理方法に関する。

従来、ネットワークを介してサーバ、ストレージ、アプリケーション等の計算機資源を利用するクラウドコンピューティングが知られる。クラウドコンピューティングのサービスを提供するクラウドサービス提供者は、ユーザにクラウドシステムの可用性（availability）の目標値とその価格を示し、それに従いサービスを提供することがある。

クラウドサービス提供者は、可用性の目標値を達成できない場合に、例えばペナルティの支払いを行う等の不利益を被る可能性がある。このために、従来、可用性の目標値の未達の可能性を抑制することができる技術が知られている（例えば特許文献１参照）。特許文献１の構成では、サービスレベルに応じたサービスの停止可能時間と、記憶手段に記憶された稼働実績が示すサービス停止時間との差分が算出される。複数のソフトウェアが更新対象として存在する場合に、ソフトウェアの更新の失敗の際のサービス停止による前記差分への影響度に応じて、複数の更新対象ソフトウェアの更新順序を算出し、更新順序に従って複数の更新対象ソフトウェアの更新を行う。

特開２０１２−１６８７３３号公報

ところで、アプリケーションソフトウェア（以下、単にアプリケーションと記載する）の更新、又は、アプリケーションの追加は、複数ではなく、単独で行われることがある。例えば、クラウドシステムの想定外の使われ方や、想定外の環境変化等によって、単独或いは複数のアプリケーションの追加によってクラウドシステムに障害が発生する可能性はゼロとは言えないのが現状である。

本発明は、上記の課題に鑑み、クラウドシステムにおけるソフトウェアに関わる変更が原因となって不具合が生じた場合でも、当該不具合がサービスに及ぼす悪影響を抑制することができる技術を提供することを目的とする。

上記目的を達成するために本発明の管理装置は、複数のローカルサーバとネットワークを介して接続されるセンタ装置が有する複数の情報処理装置を管理する管理装置であって、前記複数の情報処理装置のソフトウェアに関わる変更が必要である場合に、前記複数のローカルサーバを所定の条件に従って複数のグループにグループ分けするグループ分け部と、前記複数のグループのうちの一部のグループを前記変更が行われる前記情報処理装置に割り当て、残りのグループを前記変更が行われない前記情報処理装置に割り当てる割当部と、を備える構成（第１の構成）になっている。

また、上記第１の構成の管理装置において、前記割当部は、前記複数のグループのうちの１つのグループを前記変更が行われる前記情報処理装置に割り当てる構成（第２の構成）であることが好ましい。

また、上記第２の構成の管理装置は、前記複数のグループのうち、前記変更が行われる前記情報処理装置に割り当てられる前記グループは、当該グループに含まれる前記ローカルサーバの数が最小である構成（第３の構成）であることが好ましい。

また、上記第１から第３のいずれかの構成の管理装置は、前記変更が行われた後に、所定のタイミングで前記グループ分けを見直す見直し部を更に備える構成（第４の構成）であることが好ましい。

また、上記第４の構成の管理装置は、前記情報処理装置の動作の異常の有無を監視する監視部を更に備え、前記所定のタイミングは、前記変更が行われた前記情報処理装置について前記異常が認められることなく所定期間が経過したタイミングである構成（第５の構成）であることが好ましい。

また、上記第４又は第５の構成の管理装置において、前記見直し部は、前記変更が前記複数の情報処理装置の全てに対して行われた後に、定期的に前記グループ分けを見直す構成（第６の構成）であってよい。

また、上記第６の構成の管理装置において、前記見直し部は、前記ローカルサーバ毎の、稼働率の目標値と実績値との差分に基づき定期的に前記グループ分けの見直しを行う構成（第７の構成）であってよい。

また、上記目的を達成するための本発明のサーバシステムは、前記複数の情報処理装置と、上記第１から第７のいずれかの構成の管理装置と、を備える構成（第８の構成）になっている

また、上記目的を達成するために本発明の管理方法は、複数のローカルサーバとネットワークを介して接続されるセンタ装置が有する複数の情報処理装置を管理する管理方法であって、前記複数の情報処理装置のソフトウェアに関わる変更が必要である場合に、前記複数のローカルサーバを所定の条件に従って複数のグループにグループ分けするグループ分け工程と、前記複数のグループのうちの一部のグループを前記変更が行われる前記情報処理装置に割り当て、残りのグループを前記変更が行われない前記情報処理装置に割り当てる割当工程と、を備える構成（第９の構成）になっている。

本発明によれば、クラウドシステムにおけるソフトウェアに関わる変更が原因となって不具合が生じた場合でも、当該不具合がサービスに及ぼす悪影響を抑制することができる。

本発明の実施形態に係る配車システムの構成を示す図 タクシー会社装置の構成を示す図 情報処理装置の構成を示す図 管理装置の構成を示す図 アプリケーションに関わる変更が行われる場合の管理装置の動作例を示すフローチャート アプリケーションに関わる変更を行う前の配車システムの状態を示す図 アプリケーションに関わる変更を行うためのグループ分けおよび情報処理装置の割当てが行われた後の配車システムの状態を示す図 グループ分けの第１回目の見直しが行われた後の配車システムの状態を示す図 グループ分けの第２回目の見直しが行われた後の配車システムの状態を示す図 全ての情報処理装置に対してアプリケーションに関わる変更が行われた後に実行される定期的なグループ分けの見直し動作の動作例を示すフローチャート 図６Ｄの状態で配車システムの運用が開始されてから所定時間が経過するまでの、稼働率の目標値と実績値との差分値を示す図 図８Ａに示す実績値と目標値との差分に基づいてグループ分けの見直しを行った結果を示す図 本発明の実施形態に係る配車システムの変形例の構成を示す図

以下、本発明の例示的な実施形態について、図面を参照しながら詳細に説明する。なお、以下では、本発明が配車システムに適用される場合を例に挙げて説明する。ただし、本発明が適用されるシステムは、配車システムに限られない。本発明は、複数のローカルサーバと、複数のローカルサーバとネットワークを介して接続されるセンタ装置とを備えるシステムに広く適用可能である。

＜１．配車システム＞
図１は、本発明の実施形態に係る配車システム１００の構成を示す図である。配車システム１００は、クラウドコンピューティングを利用するクラウドシステムである。配車システム１００は、複数のタクシー会社装置１と、センタ装置２とを備える。配車システム１００は、タクシーの配車を行う配車システムである。ただし、配車システム１００は、例えば運送用のトラック等、タクシー以外の車両の配車を行う配車システムであってよい。

各タクシー会社装置１は、ネットワーク３を介してセンタ装置２と接続される。すなわち、各タクシー会社装置１は、ネットワーク３を介してセンタ装置２と通信可能である。なお、ネットワーク３は、公衆網でもよいが専用網であることが好ましい。本実施形態では、ネットワーク３は、ＶＰＮ（Virtual Private Network）である。ＶＰＮは、インターネットＶＰＮでもＩＰ−ＶＰＮでもよい。

図２は、タクシー会社装置１の構成を示す図である。図２に示すように、各タクシー会社装置１は、パーソナルコンピュータ（以下、「ＰＣ」と略す）１１と、ローカルサーバ１２とを備える。

ＰＣ１１は、情報を入力する入力端末である。各タクシー会社装置１が備えるＰＣ１１の数は１つでもよいが、通常は複数である。各タクシー会社装置１が備えるＰＣ１１の数は、全て同じに統一されてもよいが、通常は、タクシー会社毎に決められ、その数はまちまちである。

ローカルサーバ１２は、ＰＣ１１に接続される。タクシー会社装置１が複数のＰＣ１１を備える場合には、ローカルサーバ１２は、複数のＰＣ１１に接続される。ローカルサーバ１２は、ＰＣ１１からの命令に応じて、配車指示を不図示のルータおよびネットワーク３を介してセンタ装置２に送信する。なお、各タクシー会社装置１には、ローカルサーバ１２が備えられる。したがって、センタ装置２は、複数のローカルサーバ１２とネットワーク３を介して接続される。

センタ装置２は、不図示のルータを含んで構成され、複数のタクシー会社装置１および不図示の車載端末と通信を行う。車載端末は、タクシーに定常的又は一時的に搭載される端末である。センタ装置２は、例えば不図示の公衆網を介して車載端末と通信を行う。

図１に示すように、センタ装置２は、複数の情報処理装置２０を有する。本実施形態では、情報処理装置２０の数は３つであるが、この数は適宜変更されてよい。図１に示す例では、複数のタクシー会社装置１が３つのグループＧ１〜Ｇ３に分けられている。各グループＧ１〜Ｇ３において、グループに属するタクシー会社装置１の数は単数でも複数でもよい。各グループＧ１〜Ｇ３間で、グループに属するタクシー会社装置１の数は同じとしてもよいが、異なってもよい。情報処理装置２０は、グループＧ１〜Ｇ３毎に１つずつ設けられる。

第１情報処理装置２１は、第１グループＧ１に属するタクシー会社装置１からの配車指示に対応して処理を実行する。第２情報処理装置２２は、第２グループＧ２に属するタクシー会社装置１からの配車指示に対応して処理を実行する。第３情報処理装置２３は、第３グループＧ３に属するタクシー会社装置１からの配車指示に対応して処理を実行する。本実施形態のように、複数のタクシー会社装置１をグループ分けし、グループ毎に別々の情報処理装置２０で対応する構成とすると、情報処理装置２０に加わる負荷を分散させることできる。また、グループＧ１〜Ｇ３毎に別々の情報処理装置２０が対応する構成とすることにより、何らかの不具合が生じた時に全てのタクシー会社装置１の配車処理が止まる可能性を低減することができる。

図３は、情報処理装置２０の構成を示す図である。本実施形態では、情報処理装置２０は、仮想サーバ群を備える仮想サーバ装置である。ただし、各情報処理装置２０は、仮想サーバ群を備える物理サーバ装置であってもよい。情報処理装置２０は、仮想サーバとして、ＦＷ／ＬＢサーバ２０１と、ＡＤサーバ２０２と、ＷＥＢ／ＡＰサーバ２０３と、ＤＢサーバ２０４とを備える。

ＦＷ／ＬＢサーバ２０１は、ファイヤーウォールおよびロードバランサ（負荷分散装置）として機能する。ロードバランサとして機能により、情報処理装置２０を構成する仮想サーバに対する処理負荷が分散される。ＡＤサーバ２０２は、認証サーバとして機能する。ＷＥＢ／ＡＰサーバ２０３は、ＷＥＢサーバとＡＰサーバとの機能を併せ持つ。ＷＥＢ／ＡＰサーバ２０３は、各タクシー会社装置１からの要求を受け取り、要求に対してアプリケーションを実行する。ＤＢサーバ２０４は、ＷＥＢ／ＡＰサーバ２０３のアプリケーションで利用するデータを格納し操作する。ＤＢサーバ２０４は、センタ装置２が受信するデータ等に基づいてデータベースを更新する。センタ装置２が受信するデータには、データベースに格納されている各車載端末の位置情報が含まれる。

なお、ＦＷ／ＬＢサーバ２０１と、ＡＤサーバ２０２と、ＷＥＢ／ＡＰサーバ２０３と、ＤＢサーバ２０４とのうちの少なくとも１つは、冗長構成とされることが好ましい。本実施形態では、これらの仮想サーバ２０１〜２０４の全てが冗長構成とされている。

或るタクシー会社装置１が配車指示を出すと、対応する情報処理装置２０の仮想サーバ群が機能する。これにより、配車指示に含まれるタクシー会社および配車先に関する情報に基づいて、配車先の周辺に位置する該当タクシー会社のタクシーが搭載する車載端末に配車指示が送信される。なお、配車先の周辺に該当タクシー会社のタクシーが複数存在する場合、複数のタクシーの車載端末に配車指示が送信される。情報処理装置２０は、配車指示を受信した車載端末から最も早く返ってきた配車指示応答を、配車指示を行ったタクシー会社装置１に送信する。これにより、１つの配車が完了する。

＜２．管理装置＞
図１に示すように、センタ装置２は、管理装置２４を更に備える。管理装置２４は、複数の情報処理装置２０を管理する。管理装置２４は、例えば、情報処理装置２０のアプリケーションの更新や追加を管理する。管理装置２４は、仮想サーバ又は物理サーバである。センタ装置２は、サーバシステムＳＹＳを備える。サーバシステムＳＹＳは、複数の情報処理装置２０と、管理装置２４とを備える。管理装置２４を含むサーバシステムＳＹＳが構成されることにより、情報処理装置２０におけるアプリケーションの更新や追加が原因となって不具合が生じた場合でも、当該不具合が配車システム１００におけるサービスに及ぼす悪影響を抑制することが可能になっている。アプリケーションは、本発明のソフトウェアの実施形態である。

図４は、管理装置２４の構成を示す図である。図４に示すように、管理装置２４は、例えばＣＰＵで構成される演算部２４０を備える。図４に示すグループ分け部２４１、割当部２４２、見直し部２４３、および、監視部２４４は、不図示の記憶部に記憶されるコンピュータプログラムの実行により実現される演算部２４０の機能である。換言すると、管理装置２４は、グループ分け部２４１と、割当部２４２とを備える。管理装置２４は、見直し部２４３を更に備える。管理装置２４は、監視部２４４を更に備える。

なお、演算部２４０が備える各機能部２４１〜２４４の少なくともいずれか１つは、管理装置２４が物理サーバ装置である場合、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成されてもよい。また、演算部２４０が備える各機能部２４１〜２４４は、概念的な構成要素である。１つの構成要素が実行する機能を複数の構成要素に分散させたり、複数の構成要素が有する機能を１つの構成要素に統合させたりしてよい。

グループ分け部２４１は、複数の情報処理装置２０のアプリケーション（ソフトウェア）に関わる変更が必要である場合に、複数のローカルサーバ１２を所定の条件に従って複数のグループにグループ分けする。アプリケーションに関わる変更には、例えば、アプリケーションの一部または全部を変更するアプリケーションの更新が含まれる。また、アプリケーションに関わる変更には、例えば、新しいアプリケーションの追加が含まれる。ここでの複数のローカルサーバ１２は、センタ装置２とネットワーク３を介して接続される全てのローカルサーバ１２を指す。

所定の条件は、タクシー会社毎に設定される条件である。所定の条件は、例えば、タクシー会社毎に設定される目標稼働率である。本実施形態において、稼働率は、情報処理装置２０が動作すべき時間から、当該動作すべき時間に情報処理装置２０が停止した時間を差し引いた値（時間）を、情報処理装置２０が動作すべき時間で除して得られる値に１００を掛けたものである。稼働率の計算に際して、メンテナンス時間は、動作すべき時間から除外されてもよいし、動作すべき時間中に発生した停止時間に組み込まれてもよい。

グループ分け部２４１によって形成されるグループの数は、グループ分けを行う前のグループ数と同じであってもよいし、グループ分けを行う前のグループ数とは異なってもよい。例えば、グループ分け部２４１によって形成されたグループ数は、グループ分け前のグループ数よりも増えてよい。この場合には、センタ装置２が有する情報処理装置２０の数を増やす必要がある。

割当部２４２は、グループ分け部２４１によって分けられた複数のグループのうち、一部のグループをアプリケーションに関わる変更が行われる情報処理装置２０（複数の情報処理装置２０から選択される）に割り当て、残りのグループをアプリケーションに関わる変更が行われない情報処理装置２０（複数の情報処理装置２０のうち、アプリケーションに関わる変更が行われる情報処理装置２０に選択されなかった残りの情報処理装置２０）に割り当てる。アプリケーションに関わる変更が行われないとは、例えば、アプリケーションの更新が必要であるにもかかわらず、とりあえず、現在のアプリケーションの使用が維持されることが該当する。また、アプリケーションに関わる変更が行われないとは、例えば、アプリケーションの追加が必要であるにもかかわらず、とりあえず、アプリケーションの追加が行われないことが該当する。より詳細には、本実施形態では、センタ装置２が有する複数の情報処理装置２０に対しアプリケーションに関わる変更を行う場合、まず１の情報処理装置２０（例えば情報処理装置２１）に対して変更が行われる。割当部２４２は、変更が行われた１の情報処理装置２０に一部のグループを割り当てる。なお、割当部２４２の動作は、グループ分け部２４１の動作と並行して行われてよい。すなわち、グループ分け部２４１によるグループ分けが行われながら、対応する情報処理装置２０の割当てが行われてよい。

本実施形態の構成によれば、複数の情報処理装置２０のうち、一部の情報処理装置２０のみがアプリケーションに関わる変更が行われるために、アプリケーションに関わる変更によって不具合が生じた場合においても、当該不具合の影響が全てのローカルサーバ１２（すなわち、全てのタクシー会社）に及ぶことを抑制することができる。すなわち、アプリケーションに関わる変更が原因となって不具合が生じた場合でも、当該不具合がサービスに及ぼす悪影響を抑制することが可能になる。そして、変更を行った１の情報処理装置２０で所定期間異常がなければ残りの報処理装置２０に対して同様にアプリケーションに関わる変更が行われる。

なお、グループ分け部２４１が、グループ分け前よりもグループ数を増やしてグループ分けを行った場合には、割当部２４２は、仮想サーバ装置である情報処理装置２０の数を増やして、各グループに対する情報処理装置２０の割り当てを行えばよい。情報処理装置２０の数を増やすことにより、各情報処理装置２０に加わる負荷を分散させ易くすることができる。

割当部２４２は、グループ分け部２４１のグループ分けにより得られた複数のグループのうちの１つのグループをアプリケーションに関わる変更が行われる情報処理装置２０に割り当てることが好ましい。この場合、グループ分け部２４１によって形成された複数のグループのうち、１つを除く残りのグループは、アプリケーションに関わる変更が行われない情報処理装置２０に割り当てられる。これによれば、アプリケーションに関わる変更によって不具合が生じた場合においても、当該不具合の影響が及ぶ可能性があるローカルサーバ１２（タクシー会社）の数を更に減らすことができる。

また、複数のグループのうち、アプリケーションに関わる変更が行われる情報処理装置２０に割り当てられるグループは、当該グループに含まれるローカルサーバ１２の数が最小であることが好ましい。当該グループに含まれるローカルサーバ１２の数は、１つであることが好ましい。これによれば、アプリケーションに関わる変更によって不具合が生じた場合においても、当該不具合の影響が及ぶ可能性があるローカルサーバ１２（タクシー会社）の数を更に減らすことができる。

見直し部２４３は、アプリケーションに関わる変更が行われた後に、所定のタイミングでグループ分けを見直す。詳細には、見直し部２４３は、一部の情報処理装置２０においてアプリケーションに関わる変更が行われた後に、所定のタイミングでグループ分けを見直す。例えば、見直し部２４３は、割当部２４２によるグループの割当てが行われ、アプリケーションに関わる変更の対象となった情報処理装置２０にてアプリケーションに関わる変更が行われた後に、所定のタイミングでグループ分けを見直す。

所定のタイミングは、例えば、アプリケーションに関わる変更が行われた情報処理装置２０が予め決められた時間、正常に動作した時点等である。見直し部２４３による見直しには、各ローカルサーバ１２が割り当てられる情報処理装置２０の変更も含まれる。見直し部２４３は、グループ分けの見直しにあたって、例えば、アプリケーションに関わる変更が行われた情報処理装置２０に割り当てたグループを構成するローカルサーバ１２の数を増やす。

なお、見直し部２４３は、グループ分けの見直しに応じて、適宜、アプリケーションに関わる変更が行われる情報処理装置２０の数を増やしてよい。具体的には、アプリケーションに関わる変更が行われていない残りの情報処理装置２０対してアプリケーションに関わる変更が行われる。また、見直し部２４３は、グループ分けの見直しを行うことなく、所定のタイミングでアプリケーションに関わる変更が行われる情報処理装置２０の数を増やすといった見直しを行ってもよい。

見直し部２４３が設けられることにより、アプリケーションに関わる変更が原因となって生じる不具合が多くのローカルサーバ１２に及ぶことを抑制しつつ、アプリケーションに関わる変更が行われた情報処理装置２０によって処理が行われるローカルサーバ１２の数を徐々に増やしていくことができる。

なお、見直し部２４３は、グループ分けの見直しに際して、グループ分けの見直しの前後で、グループ数を同じとしてもよいし、グループ数を変更してもよい。例えば、見直し部２４３は、グループ分けの見直しによって、見直し前に比べてグループ数を減らしてもよい。グループ数を減らすことにより、情報処理装置２０の数を減らすことができ、センタ装置２における管理コスト等を抑制することができる。

また、見直し部２４３は、センタ装置２が有する複数の情報処理装置２０の全てに対してアプリケーションに関わる変更が行われるまでに、１回又は複数回のグループ分けの見直しを行ってよい。言い換えると、見直し部２４３は、センタ装置２とネットワーク３を介して接続される複数のローカルサーバ１２の全てが、アプリケーションに関わる変更が行われた情報処理装置２０で処理が行われる状態になるまでに、１回又は複数回のグループ分けの見直しを行ってよい。

また、見直し部２４３は、センタ装置２が有する複数の情報処理装置２０の全てに対してアプリケーションに関わる変更が行われた後に、定期的にグループ分けを見直してもよい。言い換えると、見直し部２４３は、センタ装置２とネットワーク３を介して接続される複数のローカルサーバ１２の全てが、アプリケーションに関わる変更が行われた情報処理装置２０で処理が行われた状態になった後に、定期的にグループ分けを見直してもよい。このような構成とすることで、各タクシー会社が要求する稼働率に、稼働率の実績値を近づけることが可能になる。この点の詳細については後述する。

監視部２４４は、情報処理装置２０の動作の異常の有無を監視する。詳細には、監視部２４４は、センタ装置２が有する複数の情報処理装置２０の全ての動作の異常の有無を監視する。例えば、見直し部２４３は、アプリケーションに関わる変更が行われた情報処理装置２０について、監視部２４４にて異常が認められることなく所定期間が経過したタイミングで、グループ分けの見直しを行う。このような構成では、アプリケーションに関わる変更が原因となって生じる不具合（異常）を的確なタイミングで検出することができ、多くのローカルサーバ１２に不具合の影響が出ることを抑制することができる。

監視部２４４は、例えば、各情報処理装置２０の動作が正常であるか否かを確認する信号を所定周期（例えば数十秒周期等）で送信する。監視部２４４は、例えば、各情報処理装置２０に、当該情報処理装置２０が対応するタクシー会社のデータを要求する。そして、監視部２４４は、当該要求に対して所定時間（例えば数秒等）内に情報処理装置２０から返答がない場合、当該情報処理装置２０の動作が異常であると判断する。

＜３．管理装置の動作例＞
次に、以上のように構成される管理装置２４の動作例について説明する。

（３−１．アプリケーションに関わる変更が行われる場合の動作）
まず、センタ装置２が有する各情報処理装置２０に対してアプリケーションに関わる変更を行う場合の管理装置２４の動作例について説明する。図５は、アプリケーションに関わる変更が行われる場合の管理装置２４の動作例を示すフローチャートである。

なお、図５に示すフローチャートの理解を容易とするために、図６Ａ〜図６Ｄを適宜参照して説明する。図６Ａ〜図６Ｄは、あくまでも動作の一例を示すものにすぎない。図６Ａは、アプリケーションに関わる変更を行う前の配車システム１００の状態を示す図である。図６Ｂは、アプリケーションに関わる変更を行うためのグループ分け及び情報処理装置２０の割当てが行われた後の配車システム１００の状態を示す図である。図６Ｃは、グループ分けの第１回目の見直しが行われた後の配車システム１００の状態を示す図である。図６Ｄは、グループ分けの第２回目の見直しが行われた後の配車システム１００の状態を示す図である。

図６Ａ〜図６Ｄにおいて、ＰＣ数は、各タクシー会社のタクシー会社装置１が有するＰＣ１１の数である。目標稼働率は、各タクシー会社が配車システム１００を構成するセンタ装置２の管理者に要求する稼働率である。適用装置は、各タクシー会社のタクシー会社装置１に適用される情報処理装置２０を指し、丸で囲んだ数字の「１」は第１情報処理装置２１を、丸で囲んだ数字の「２」は第２情報処理装置２２を、丸で囲んだ数字の「３」は第３情報処理装置２３を指す。適用装置毎のＰＣ数は、各情報処理装置２１〜２３が対応するＰＣ１１の総数を示す。各情報処理装置２１〜２３が対応できるＰＣ１１の総数には上限がある。この上限数のことを、以下、ＰＣ上限数と呼び、図６Ａ〜図６Ｄに示す例（以下、単に図６に示す例という）ではＰＣ上限数は５０台である。ＰＣ上限数は、例えば実験等により求められる。

ステップＳ１では、演算部２４０は、グループ分け部２４１の機能により、センタ装置２にネットワーク３を介して接続される全てのタクシー会社装置１のローカルサーバ１２を、複数のグループにグループ分けする。演算部２４０は、目標稼働率に従ってグループ分けを行う。演算部２４０は、グループ分けを完了すると、次のステップＳ２に処理を進める。

図６に示す例では、図６Ｂに示すように、演算部２４０は、目標稼働率が低い順にローカルサーバ１２を並べ、目標稼働率が最も低いタクシー会社Ｔ１のローカルサーバ１２を第１グループＧ１とする。なお、この例では、第１グループＧ１を構成するタクシー会社のローカルサーバ１２の数は１つであるが、目標稼働率が最も低いタクシー会社が複数ある場合には、第１グループＧ１を構成するローカルサーバ１２の数は複数となってよい。ただし、目標稼働率が最も低いタクシー会社が複数ある場合でも、第１グループＧ１を構成するローカルサーバ１２の数は単数としてよい。

また、演算部２４０は、第１グループＧ１を決めると、残りのローカルサーバ１２につき、目標稼働率が低いタクシー会社のローカルサーバ１２から順に、ＰＣ上限数を超えない範囲でＰＣ上限数の近くとなるまで同じグループに入れていき、第２グループＧ２とする。図６Ｂに示すように、第２グループＧ２には、タクシー会社Ｔ２〜Ｔ７、Ｔ１０の７つのローカルサーバ１２が属する。演算部２４０は、残りのタクシー会社Ｔ８、Ｔ９の２つのローカルサーバ１２を第３グループＧ３とする。第３グループＧ３は、第２グループＧ２に比べて、平均的にみて、目標稼働率が高いタクシー会社のローカルサーバ１２が属する。

なお、本例では、第２グループＧ２のローカルサーバ１２の数の方が、第３グループＧ３のローカルサーバ１２より多くしているが、これは例示にすぎない。第２グループＧ２と第３グループＧ３とで、所属するローカルサーバ１２の数を同じとしてもよい。ただし、平均的にみて目標稼働率が高いタクシー会社のローカルサーバ１２が属するグループ方が、所属するローカルサーバ１２の数を少なくすることが好ましい。また、グループの数は、図６Ａのグループ数（３つ）より増やしてもよい。グループ数を増やすことにより、情報処理装置２０を増やすことになり、情報処理装置２０毎の負荷を分散させることができる。また、ステップＳ１の段階では、第１グループＧ１に属するローカルサーバ１２のみを決め、残りのローカルサーバ１２については、第２グループＧ２と第３グループＧ３のいずれに入るかまでは決めなくてもよい。すなわち、ステップＳ１では、グループ分けにより２つのグループのみを形成する構成としてもよい。

ステップＳ２では、演算部２４０は、割当部２４２の機能により、グループ分けにより得られた各グループに情報処理装置２０を割り当てる。詳細には、演算部２４０は、目標稼働率が最も低いタクシー会社のローカルサーバ１２が属するグループに、アプリケーションに関わる変更が行われる情報処理装置２０を割り当てる。演算部２４０は、残りのグループにアプリケーションに関わる変更が行われない情報処理装置２０を割り当てる。すなわち、全ての情報処理装置２０について同時にアプリケーションに関わる変更が行われるのではなく、１つの情報処理装置２０に対してのみ先行してアプリケーションに関わる変更が行われる。アプリケーションに関わる変更が先行して行われる１つの情報処理装置２０には、最も目標稼働率が低いタクシー会社で構成されるグループ（本例では第１グループＧ１）が割当てられる。当該情報処理装置２０において、アプリケーションに関わる変更によって異常が生じないか否かの様子を見、異常が生じない場合には、アプリケーションに関わる変更が行われる情報処理装置２０が増やされる。なお、演算部２４０は、グループ分けを行いながら情報処理装置２０の割当てを行ってよい。演算部２４０は、情報処理装置２０の割当てを完了すると、次のステップＳ３に処理を進める。

図６に示す例では、図６Ｂに示すように、演算部２４０は、目標稼働率が最も低いタクシー会社Ｔ１のローカルサーバ１２が属する第１グループＧ１に第１情報処理装置２１を割り当てる。第１情報処理装置２１は、この段階でアプリケーションに関わる変更が行われることが決定している唯一の情報処理装置である。演算部２４０は、第２グループＧ２に第２情報処理装置２２を割り当て、第３グループＧ３に第３情報処理装置２３を割り当てる。

なお、各グループＧ１〜Ｇ３に情報処理装置２１〜２３が割り当てられると、管理装置２４又は管理装置２４と連携する他の装置によって、第１情報処理装置２１におけるアプリケーションに関わる変更が実行される。本例では、アプリケーションに関わる変更で不具合が生じても、当該不具合の影響を受けるローカルサーバ１２を１つにできる。そして、不具合の影響を受けるローカルサーバ１２を有するタクシー会社の目標稼働率が低いために、目標稼働率に未達となる可能性を低く抑えることができる。

ステップＳ３では、演算部２４０は、監視部２４４の機能により、アプリケーションに関わる変更が行われた後、当該変更が行われた情報処理装置２０について所定期間の間、異常が無いか否かを監視する。すなわち、アプリケーションに関わる変更が先行して行われる１つの情報処理装置２０において、異常が生じないか否かの様子を見る。異常があった場合には（ステップＳ３でＮｏ）、アプリケーションに関わる変更処理に問題があると判断され、一旦、処理が終了され、問題の生じた情報処理装置２０に対するメンテナンス等が行われる。異常がない場合には（ステップＳ３でＹｅｓ）、ステップＳ４に処理が進められる。なお、図６に示す例では、演算部２４０は、アプリケーションに関わる変更が行われた第１情報処理装置２１について所定期間の間、異常が無いか否かを監視する。

ステップＳ４では、演算部２４０は、見直し部２４３の機能により、ステップＳ１で行ったグループ分けの見直しを行う。演算部２４０は、目標稼働率とＰＣ上限数とに基づいてグループ分けの見直しを行う。演算部２４０は、当該見直しにより、アプリケーションに関わる変更が行われた情報処理装置２０によって処理が行われるローカルサーバ１２の数を増やす。この段階では、まだ、アプリケーションに関わる変更を行う情報処理装置２０の数は増やされていない。まずは、アプリケーションに関わる変更が先行して行われる１つの情報処理装置２０において、対応するローカルサーバ１２の数が増えても異常が生じないか否かを確認する趣旨である。演算部２４０は、グループ分けの見直しを完了すると、次のステップＳ５に処理を進める。

図６に示す例では、図６Ｃに示すように、演算部２４０は、第２グループＧ２に所属する目標稼働率が低いタクシー会社のローカルサーバ１２から順に、ＰＣ上限数の半分（本例では２５台）程度となるまで、ローカルサーバ１２を第１グループＧ１の所属に変更する。これにより、グループ分けの見直し前に第２グループＧ２に所属していたタクシー会社Ｔ３、Ｔ５、Ｔ６のローカルサーバ１２が第１グループＧ１の所属となる。すなわち、グループ分けの見直しにより、タクシー会社Ｔ１のローカルサーバ１２だけでなく、タクシー会社Ｔ３、Ｔ５、Ｔ６のローカルサーバ１２もアプリケーションに関わる変更が行われた第１情報処理装置２１で処理が行われるようになる。これによれば、アプリケーションに関わる変更が行われた情報処理装置２０で処理されるローカルサーバ１２の数が徐々に増やされるために、不具合が一度に多くのローカルサーバ１２に及ぶことを抑制できる。

第２グループＧ２には、タクシー会社Ｔ７、Ｔ４、Ｔ２、Ｔ１０のローカルサーバ１２が所属し、これらのローカルサーバ１２は、アプリケーションに関わる変更が行われていない第２情報処理装置２２を用いて処理が実行される。第３グループＧ３には、見直し前と同じタクシー会社Ｔ８、Ｔ９のローカルサーバ１２が所属し、これらのローカルサーバ１２は、アプリケーションに関わる変更が行われていない第３情報処理装置２３を用いて処理が実行される。

なお、本例では、第１グループＧ１と第２グループＧ２とのローカルサーバ１２の所属が見直される構成であるが、これらに加えて第３グループＧ３の見直しも行われてよい。また、本例では、ＰＣ上限数の半分程度となるまで第２グループＧ２から第１グループＧ１へとローカルサーバ１２の所属を移動する構成としたが、これも例示である。例えば、ＰＣ上限数となるまで第２グループＧ２から第１グループＧ１へとローカルサーバ１２の所属を変更する構成としてもよい。

ステップＳ５では、演算部２４０は、監視部２４４の機能により、グループ分けの見直し後、情報処理装置２０について所定期間の間、異常が無いか否かを監視する。異常があった場合には（ステップＳ５でＮｏ）、一旦、処理が終了され、異常を解消するための処置が行われる。異常がない場合には（ステップＳ５でＹｅｓ）、ステップＳ６に処理が進められる。なお、図６に示す例では、演算部２４０は、グループ分けの見直し後、第１情報処理装置２１について所定期間の間、異常が無いか否かを監視する。

ステップＳ６では、演算部２４０は、見直し部２４３の機能により、ステップＳ４で見直したグループ分けを再度見直す。演算部２４０は、目標稼働率とＰＣ上限数とに基づいてグループ分けの再見直しを行う。演算部２４０は、当該再見直しにより、アプリケーションに関わる変更が行われた情報処理装置２０によって処理が行われるローカルサーバ１２の数を増やす。すなわち、アプリケーションに関わる変更が先行して行われた１つの情報処理装置２０において、異常が生じないと判断されたために、残りの情報処理装置２０の少なくとも１つに対してアプリケーションに関わる変更が実行され、アプリケーションに関わる変更が行われる情報処理装置２０の数が増やされる。

なお、図５に示すフローチャートでは、ステップＳ６の再見直しによって、全てのローカルサーバ１２が、アプリケーションに関わる変更が行われた情報処理装置２０によって処理が行われるようになる。すなわち、アプリケーションに関わる変更が先行して行われた１つの情報処理装置２０において、異常が生じないと判断されたために、残りの情報処理装置２０の全てに対してアプリケーションに関わる変更が行われる。このために、ステップＳ６の完了により、アプリケーションに関わる変更が行われる場合に実行される一連の処理は終了する。

ただし、この段階では、全てのローカルサーバ１２の処理が、アプリケーションに関わる変更が行われた情報処理装置２０によって行われるようにしなくてもよい。ステップＳ６の後に、更なる見直しが少なくとも１回行われたのちに、全てのローカルサーバ１２の処理が、アプリケーションに関わる変更が行われた情報処理装置２０によって行われるようにしてもよい。更なる見直しは、グループ分けの再設定を行うことなく、単に、アプリケーションに関わる変更が行われる情報処理装置２０の数を増やす構成であってもよい。

図６に示す例では、図６Ｄに示すように、演算部２４０は、第２グループＧ２に所属する目標稼働率が低いタクシー会社のローカルサーバ１２から順に、ＰＣ上限数を超えない範囲でＰＣ上限数の近くとなるまで、ローカルサーバ１２を第１グループＧ１の所属に変更する。これにより、グループ分けの見直し前に第２グループＧ２に所属していたタクシー会社Ｔ７、Ｔ４、Ｔ２のローカルサーバ１２が第１グループＧ１の所属となる。

また、演算部２４０は、第３グループＧ３に所属していたタクシー会社Ｔ８のローカルサーバ１２を第２グループＧ２に移動させる。これにより、第２グループＧ２と第３グループＧ３とに属するＰＣ１１の数を互いに同程度にでき、目標稼働率が高いタクシー会社のローカルサーバ１２に対応する情報処理装置２０の負荷を分散することができる。ただし、第３グループＧ３に所属するローカルサーバ１２は変更しなくてもよい。目標稼働率が高いタクシー会社のローカルサーバ１２が所属するグループにおいては、ＰＣ上限数の半分（本例では２５台）以下となるようにグループ分けが行われることが好ましい。また、第３グループＧ３に所属するローカルサーバ１２を全て第２グループＧ２に移動させてもよい。このようにすることで、センタ装置２が有する情報処理装置２０の数を減らすことができ、低コスト化を図ることができる。

本例では、再見直しに伴い、第２グループＧ２に対応する第２情報処理装置２２、および、第３グループＧ３に対応する第３情報処理装置２３を、アプリケーションに関わる変更を行う対象とする。ただし、これは例示であり、今回の見直しでは、第２グループＧ２に対応する第２情報処理装置２２をアプリケーションに関わる変更を行う対象とし、次回の見直しで、第３グループＧ３に対応する第３情報処理装置２３をアプリケーションに関わる変更を行う対象としてもよい。

（３−２．アプリケーションに関わる変更後の定期的な見直し）
次に、センタ装置２が有する全ての情報処理装置２０に対してアプリケーションに関わる変更が行われた後に実行される定期的なグループ分けの見直し動作の動作例について説明する。図７は、全ての情報処理装置２０に対してアプリケーションに関わる変更が行われた後に実行される定期的なグループ分けの見直し動作の動作例を示すフローチャートである。図７に示す処理は、演算部２４０が見直し部２４３としての機能を発揮することにより実行される。

ステップＳ１１では、演算部２４０は、全ての情報処理装置２０に対してアプリケーションに関わる変更が行われてからの配車システム１００の稼働時間が所定時間を経過したか否かを確認する。当該確認は、所定時間を経過するまで行われる。所定時間は、実験等によって適宜決められ、例えば数時間等であってよい。なお、ステップＳ１５の後にステップＳ１１に戻ってきた場合には、ステップＳ１４のグループ分けの見直しが行われてから所定時間が経過したか否かが確認される。演算部２４０は、所定時間を経過したことを確認すると（ステップＳ１１でＹｅｓ）、ステップＳ１２に処理を進める。

ステップＳ１２では、演算部２４０は、各情報処理装置２０の稼働率の実績値を取得する。稼働率の実績値は、例えば、監視部２４４の監視結果から得られる。各情報処理装置２０に対して、監視部２４４によって異常が認められた場合、その情報処理装置２０は停止していたと判断される。一方、監視部２４４によって異常が認められない場合、その情報処理装置２０は稼働していたと判断される。このために、監視部２４４の監視結果から各情報処理装置２０の停止時間が得られ、これと各情報処理装置２０が動作すべき時間とから、各情報処理装置２０に対して稼働率の実績値を求めることができる。演算部２４０は、稼働率の実績値を求めると次のステップＳ１３に処理を進める。

ステップＳ１３では、演算部２４０は、ローカルサーバ１２毎（タクシー会社毎）の、稼働率の目標値と実績値との差分を算出する。差分は、実績値から目標値を差し引いて得られる構成でも、目標値から実績値を差し引いて得られる構成であってもよい。演算部２４０は、差分を求めるとステップＳ１４に処理を進める。

ここで、図８Ａに、稼働率の目標値と実績値との差分を例示する。図８Ａは、図６Ｄの状態となって配車システム１００が稼働を開始してから所定時間が経過するまでの、稼働率の目標値と実績値との差分を示した図である。なお、図８Ａは、図６Ｄの図に、稼働率の実績値と、実績値から目標値を差し引いた差分とを追加した図である。

図８Ａに示すように、差分はプラスの値と、マイナスの値とを取り得る。図８Ａに示す例では、差分がプラス又はゼロである場合には、実績値が目標値以上であり、各タクシー会社は、自社の要求が満たされ、満足が行く状態である。センタ装置２を基準とすると、プラスの値の絶対値が大きいほど、要求に対する余裕度が大きい。一方、差分がマイナスである場合には、実績値が目標値を下回っており、各タクシー会社は、自社の要求が満たされず、不満な状態となる。センタ装置２を基準とすると、マイナスの値の絶対値が大きいほど、タクシー会社の要求を満たすように設定変更の緊急度が高い。なお、以下、差分の大小について、差分がプラスである場合には、差分の絶対値が大きいものほど差分が大きいと表現し、差分がマイナスである場合、差分の絶対値が大きいものほど差分は小さいと表現する。

ステップＳ１４では、演算部２４０は、算出した差分に基づいてグループ分けの見直しを行う。演算部２４０は、例えば実績値から目標値を差し引いて得られた差分に基づいて、複数のローカルサーバ１２のグループ分けの見直しを行う。演算部２４０は、グループ分けの見直しを行うとステップＳ１５に処理を進める。

ここで、図８Ａおよび図８Ｂを参照して、グループ分けの見直し処理の一例を説明する。なお、図８Ｂは、図８Ａに示す実績値と目標値との差分に基づいてグループ分けの見直しを行った結果を示す図である。演算部２４０は、図８Ｂに示すように、図８Ａの差分算出結果に基づいて、各ローカルサーバ１２（タクシー会社）を差分が大きいものから小さいものとなるように順に並べる。演算部２４０は、各ローカルサーバ１２（タクシー会社）について、差分が大きいものから順に、ＰＣ上限数を超えない範囲でＰＣ上限数の近くとなるまで同じグループに入れていき、第１グループＧ１とする。図８Ｂに示す例では、タクシー会社Ｔ２、Ｔ１０、Ｔ９のローカルサーバ１２が第１グループＧ１に属し、これらは、第１情報処理装置２１によって処理が行われる。

演算部２４０は、第１グループＧ１に入らなかった残りのローカルサーバ１２について、第２情報処理装置２２が対応するＰＣ１１の数と第３情報処理装置２３が対応するＰＣ１１の数とが予め決められた配分に近くなり、且つ、差分が大きなものが第２グループＧ２に入り、差分の小さなものが第３グループＧ３に入るように割り振る。差分が小さいものが入るグループの方が、グループに属するＰＣ１１の数が少なくなるように、前述の配分は決められる。図８Ｂに示す例では、第２情報処理装置２２が対応するＰＣ１１の数と、第２情報処理装置２２が対応するＰＣ１１の数との比か３：２に近くなるように配分されている。

図８Ｂに示す例では、タクシー会社Ｔ８、Ｔ１、Ｔ３、Ｔ５のローカルサーバ１２は第２グループＧ２に属し、これらは、第２情報処理装置２２によって処理が行われる。タクシー会社Ｔ６、Ｔ７、Ｔ４のローカルサーバ１２は第３グループＧ３に属し、これらは、第３情報処理装置２３によって処理が行われる。これによれば、タクシー会社が不満を抱くことが予想される場合に、当該タクシー会社のローカルサーバ１２を負荷が少ない情報処理装置２０で処理を行うようにすることができる。定期的にグループ分けが見直されるために、稼働率の実績値を目標値に近づけていくことができる。

ステップＳ１５では、演算部２４０は終了イベントが発生しているか否かを確認する。終了イベントは、例えば、予定された或いは緊急のメンテナンスが行われる場合等、定期的な見直しを中断せざるを得ない事態が生じた場合等である。演算部２４０は、終了イベントが発生している場合には（ステップＳ１５でＹｅｓ）、図７に示すフローチャートを終了する。演算部２４０は、終了イベントが発生していない場合には（ステップＳ１５でＮｏ）、ステップＳ１１に戻って処理を続ける。

以上のように、本実施形態では、見直し部２４３は、ローカルサーバ１２毎の、稼働率の目標値と実績値との差に基づいて定期的にグループ分けを見直す。このために、本実施形態によれば、稼働率の目標値に実績値が未達となるローカルサーバ１２（タクシー会社
の発生を抑制することができる。また、目標値と実績値との差を管理することができるために、情報処理装置２０の能力の適否に関する検討を行うことも可能になる。例えば、情報処理装置２０の能力が低いと判断される場合に、情報処理装置２０のＣＰＵを能力の高いものに変更するといった対処を行うことができる。

＜３．留意事項＞
本明細書中に開示されている種々の技術的特徴は、上記実施形態のほか、その技術的創作の主旨を逸脱しない範囲で種々の変更を加えることが可能である。すなわち、上記実施形態は、全ての点で例示であって、制限的なものではないと考えられるべきであり、本発明の技術的範囲は、上記実施形態の説明ではなく、特許請求の範囲によって示されるものであり、特許請求の範囲と均等の意味及び範囲内に属する全ての変更が含まれると理解されるべきである。また、本明細書中に示される複数の実施形態及び変形例は可能な範囲で適宜組み合わせて実施されてよい。

例えば、配車システム１００は、図９の構成であってもよい。図９においては、管理装置２４は、ネットワーク３に繋がっている。このために、管理装置２４は、例えば、情報処理装置２０の動作の異常の有無を監視するに際して、ネットワーク３を介して情報処理装置２０にデータを要求することができる。この場合、ネットワーク３に不具合が発生している場合にも不具合を検出することができる。このために、システムのサービスレベルを顧客（例えばタクシー会社）が要求するレベルにより近づけることができる。

また、図９の構成とする場合には、管理装置２４がネットワーク３を介して各ローカルサーバ１２に対して指示を行う構成とすることができる。このために、図９の構成とすることにより、管理装置２４がローカルサーバ１２毎の稼働率を把握することも可能になる。この結果、配車システム１００のサービスレベルを顧客（例えばタクシー会社）が要求するレベルに更に近づけ易くすることができる。

２・・・センタ装置
３・・・ネットワーク
１２・・・ローカルサーバ
２０・・・情報処理装置
２１・・・第１情報処理装置
２２・・・第２情報処理装置
２３・・・第３情報処理装置
２４・・・管理装置
２４１・・・グループ分け部
２４２・・・割当部
２４３・・・見直し部
２４４・・・監視部
ＳＹＳ・・・サーバシステム

Claims (9)

1. 複数のローカルサーバとネットワークを介して接続されるセンタ装置が有する複数の情報処理装置を管理する管理装置であって、
   前記複数の情報処理装置のソフトウェアに関わる変更が必要である場合に、前記複数のローカルサーバを所定の条件に従って複数のグループにグループ分けするグループ分け部と、
   前記複数のグループのうちの一部のグループを前記変更が行われる前記情報処理装置に割り当て、残りのグループを前記変更が行われない前記情報処理装置に割り当てる割当部と、
   を備える、管理装置。
2. 前記割当部は、前記複数のグループのうちの１つのグループを前記変更が行われる前記情報処理装置に割り当てる、請求項１に記載の管理装置。
3. 前記複数のグループのうち、前記変更が行われる前記情報処理装置に割り当てられる前記グループは、当該グループに含まれる前記ローカルサーバの数が最小である、請求項２に記載の管理装置。
4. 前記変更が行われた後に、所定のタイミングで前記グループ分けを見直す見直し部を更に備える、請求項１から３のいずれか１項に記載の管理装置。
5. 前記情報処理装置の動作の異常の有無を監視する監視部を更に備え、
   前記所定のタイミングは、前記変更が行われた前記情報処理装置について前記異常が認められることなく所定期間が経過したタイミングである、請求項４に記載の管理装置。
6. 前記見直し部は、前記変更が前記複数の情報処理装置の全てに対して行われた後に、定期的に前記グループ分けを見直す、請求項４又は５に記載の管理装置。
7. 前記見直し部は、前記ローカルサーバ毎の、稼働率の目標値と実績値との差分に基づき定期的に前記グループ分けの見直しを行う、請求項６に記載の管理装置。
8. 前記複数の情報処理装置と、
   請求項１から７のいずれか１項に記載の管理装置と、
   を備える、サーバシステム。
9. 複数のローカルサーバとネットワークを介して接続されるセンタ装置が有する複数の情報処理装置を管理する管理方法であって、
   前記複数の情報処理装置のソフトウェアに関わる変更が必要である場合に、前記複数のローカルサーバを所定の条件に従って複数のグループにグループ分けするグループ分け工程と、
   前記複数のグループのうちの一部のグループを前記変更が行われる前記情報処理装置に割り当て、残りのグループを前記変更が行われない前記情報処理装置に割り当てる割当工程と、
   を備える、管理方法。

Images