特許 7332249 移行先決定プログラム、装置、及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-08-15

(45)【発行日】2023-08-23

(54)【発明の名称】移行先決定プログラム、装置、及び方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20230816BHJP

   G06F 11/20 20060101ALI20230816BHJP

【ＦＩ】

G06F9/50 150Z

G06F11/20 620

【請求項の数】 5

(21)【出願番号】P 2021200878

(22)【出願日】2021-12-10

(65)【公開番号】P2023086394

(43)【公開日】2023-06-22

【審査請求日】2021-12-13

【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２９年度、防衛装備庁、請負契約、産業技術力強化法第１７条の適用を受ける特許出願

(73)【特許権者】

【識別番号】390014306

【氏名又は名称】防衛装備庁長官

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110001519

【氏名又は名称】弁理士法人太陽国際特許事務所

(72)【発明者】

【氏名】石丸 光宏

(72)【発明者】

【氏名】奥本 有樹

(72)【発明者】

【氏名】実井 恒二

(72)【発明者】

【氏名】島本 鋭志郎

【審査官】坂東 博司

(56)【参考文献】

【文献】特開２０１２－１１８８４１（ＪＰ，Ａ）

【文献】特開２０１１－１８６６３７（ＪＰ，Ａ）

【文献】中国特許出願公開第１１２７４０２９０（ＣＮ，Ａ）

【文献】再公表特許第２０１２／１３２８０８（ＪＰ，Ａ１）

【文献】特開２０１２－２５２６０２（ＪＰ，Ａ）

【文献】特開２０１８－０５５５１８（ＪＰ，Ａ）

【文献】特開２０１６－１２６４５４（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５０

Ｇ０６Ｆ １１／２０

(57)【特許請求の範囲】

【請求項1】

複数の拠点の各々で稼働する１又は複数のシステムの各々であって、アクティブ系のシステムとスタンバイ系のシステムとの対で構成され、対となる前記アクティブ系のシステムと前記スタンバイ系のシステムとは異なる拠点に配置されている前記１又は複数のシステムの各々を監視し、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントの発生により他の拠点へ移行する必要がある移行元システムを移行するためのリソースを確保可能な空きリソース量を有する拠点、又は、前記リソースを確保可能な拠点が存在しない場合には、前記アクティブ系のシステムか若しくは前記スタンバイ系のシステムかに基づいて、又は、システムの重要性を示す優先度に基づいて削除対象若しくは縮退対象と判定したシステムを削除若しくは縮退することで前記リソースを確保可能な拠点を移行先候補として選定し、
前記移行先候補のうち、前記移行先候補と、前記インシデントが発生したシステムの拠点又は前記移行元システムの拠点との距離が、移行の目的又はインシデントの原因に応じた条件を満たす前記移行先候補から、移行先の拠点を決定する
ことを含む処理をコンピュータに実行させるための移行先決定プログラム。

【請求項2】

優先度が予め定めた優先度より低く、かつスタンバイ系のシステムを削除対象のシステムと判定し、優先度が予め定めた優先度より高く、かつアクティブ系のシステムを縮退対象のシステムと判定する請求項１に記載の移行先決定プログラム。

【請求項3】

システムの優先度が低い順、かつスタンバイ系、アクティブ系の順に各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出し、前記拠点毎に導出したリソース量の合計が、前記インシデントに関するシステムを移行するために必要なリソース量に到達した拠点から順に移行先候補として選定し、
選定された前記移行先候補が前記条件を満たす場合、前記移行先候補の選定を終了し、前記条件を満たす前記移行先候補を移行先の拠点として決定する
請求項１又は請求項２に記載の移行先決定プログラム。

【請求項4】

複数の拠点の各々で稼働する１又は複数のシステムの各々であって、アクティブ系のシステムとスタンバイ系のシステムとの対で構成され、対となる前記アクティブ系のシステムと前記スタンバイ系のシステムとは異なる拠点に配置されている前記１又は複数のシステムの各々を監視する監視部と、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントの発生により他の拠点へ移行する必要がある移行元システムを移行するためのリソースを確保可能な空きリソース量を有する拠点、又は、前記リソースを確保可能な拠点が存在しない場合には、前記アクティブ系のシステムか若しくは前記スタンバイ系のシステムかに基づいて、又は、システムの重要性を示す優先度に基づいて削除対象若しくは縮退対象と判定したシステムを削除若しくは縮退することで前記リソースを確保可能な拠点を移行先候補として選定する選定部と、
前記移行先候補のうち、前記移行先候補と、前記インシデントが発生したシステムの拠点又は前記移行元システムの拠点との距離が、移行の目的又はインシデントの原因に応じた条件を満たす前記移行先候補から、移行先の拠点を決定する決定部と、
を含む移行先決定装置。

【請求項5】

複数の拠点の各々で稼働する１又は複数のシステムの各々であって、アクティブ系のシステムとスタンバイ系のシステムとの対で構成され、対となる前記アクティブ系のシステムと前記スタンバイ系のシステムとは異なる拠点に配置されている前記１又は複数のシステムの各々を監視し、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントの発生により他の拠点へ移行する必要がある移行元システムを移行するためのリソースを確保可能な空きリソース量を有する拠点、又は、前記リソースを確保可能な拠点が存在しない場合には、前記アクティブ系のシステムか若しくは前記スタンバイ系のシステムかに基づいて、又は、システムの重要性を示す優先度に基づいて削除対象若しくは縮退対象と判定したシステムを削除若しくは縮退することで前記リソースを確保可能な拠点を移行先候補として選定し、
前記移行先候補のうち、前記移行先候補と、前記インシデントが発生したシステムの拠点又は前記移行元システムの拠点との距離が、移行の目的又はインシデントの原因に応じた条件を満たす前記移行先候補から、移行先の拠点を決定する
ことを含む処理をコンピュータが実行する移行先決定方法。

【発明の詳細な説明】

【技術分野】

【0001】

開示の技術は、移行先決定プログラム、移行先決定装置、及び移行先決定方法に関する。

【背景技術】

【0002】

従来、管理対象のシステムに対するサイバー攻撃や物理的破壊に対する監視を行い、インシデント発生時には、インシデントが発生したシステムを移行させることが行われている。

【0003】

例えば、現在のリソース割り当てに対して性能劣化や性能の余剰が生じた際に、適切な構成変更により、処理能力及びリソース利用効率の両方を最適化する管理方法が提案されている。この方法では、性能劣化又は余剰が生じている当該サーバと、他のサーバの性能について、相互に影響しあっているか否かを特定し、同一装置におけるリソース量の変更が適切か、あるいは別の装置への移行が適切かを判断する。移行方策については、実現可能性を確認した上で、改善される項目と、移行にかかる所要時間やコストなどと合わせて提示し、当該構成変更作業の長所及び短所を定量的に示す。

【0004】

また、十分な空き容量を有するリソースプールが無い場合でも新たな仮想マシンを稼働させることができるシステム制御装置が提案されている。この装置は、第１物理リソースプールが有する物理リソースの余剰リソース量が、対象仮想マシンの稼働に要する物理リソース量以上であるか否かを判定する。また、この装置は、第１物理リソースプールの余剰リソース量が必要リソース量未満である場合に、第１物理リソースプールの余剰リソース量を必要リソース量以上の量に増加させる。そして、この装置は、第１物理リソースプールの余剰リソース量が必要リソース量以上である場合に、第１物理リソースプールに含まれる物理リソースを用いて対象仮想マシンを稼働させる。

【先行技術文献】

【特許文献】

【0005】

【文献】特表２０１５－５２４５８１号公報

【文献】特開２０１５－１４１４５９号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

複数の拠点の各々に配置されたシステムの各々を連携し、インシデント発生時などには、システムの移行等を各拠点間で行うなどの対処を行う場合がある。この場合、システムの継続性を担保するために、移行先として、より適切な拠点を決定することが望ましい。

【0007】

一つの側面として、開示の技術は、複数の拠点間におけるシステムの適切な移行先を決定することを目的とする。

【課題を解決するための手段】

【0008】

一つの態様として、開示の技術は、複数の拠点の各々で稼働する１又は複数のシステムの各々を監視する。また、開示の技術は、前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点の中から、移行先候補を選定する。移行先候補は、前記インシデントに関連するシステムが稼働する拠点以外の拠点で、前記インシデントに関連するシステムを移行するためのリソースを確保可能な拠点である。そして、開示の技術は、前記移行先候補のうち、前記移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす前記移行先候補から、移行先の拠点を決定する。

【発明の効果】

【0009】

一つの側面として、複数の拠点間におけるシステムの適切な移行先を決定することができる、という効果を有する。

【図面の簡単な説明】

【0010】

【図1】システム及び移行先決定装置の構成を示す概略図である。

【図2】本実施形態に係る移行先決定装置の機能ブロック図である。

【図3】システムＤＢの一例を示す図である。

【図4】拠点ＤＢの一例を示す図である。

【図5】本実施形態に係る移行先決定装置として機能するコンピュータの概略構成を示すブロック図である。

【図6】各拠点で稼働するシステムを優先度別に表した図である。

【図7】本実施形態における移行先決定処理の一例を示すフローチャートである。

【図8】選定処理の一例を示すフローチャートである。

【図9】削除又は縮退の対象とするシステムの順番の一例を示す図である。

【図10】拠点毎に確保可能なリソース量を積み上げる様子を概略的に示す図である。

【発明を実施するための形態】

【0011】

以下、図面を参照して、開示の技術に係る実施形態の一例を説明する。

【0012】

図１に示すように、本実施形態に係る移行先決定装置１０は、複数のシステム３０Ａ、３０Ｂ、３０Ｃ、３０Ｄ、３０Ｅ、・・・の各々とネットワークを介して接続されている。以下では、システム３０Ａ、３０Ｂ、３０Ｃ、３０Ｄ、３０Ｅ、・・・を区別なく説明する場合には、単に「システム３０」と表記する。

【0013】

各システム３０は、データセンタ等の複数の拠点の各々に配置された物理的リソースである１以上のサーバ装置上に構築された仮想サーバ上で稼働する。各システム３０は、稼働中のシステムの状態を示すログ情報を随時出力し、移行先決定装置１０へ送信する。ログ情報には、インシデントの発生有無を識別可能な情報も含まれる。

【0014】

また、各システム３０は、アクティブ系とスタンバイ系との対で構成されており、アクティブ系のシステム３０と、スタンバイ系のシステム３０とは、それぞれ異なる拠点に配置されている。

【0015】

移行先決定装置１０は、図２に示すように、機能的には、監視部１２と、選定部１４と、決定部１６とを含む。また、移行先決定装置１０の所定の記憶領域には、システムＤＢ（Database）２２と、拠点ＤＢ２４とが記憶される。

【0016】

監視部１２は、複数の拠点の各々で稼働する１又は複数のシステムの各々を監視する。具体的には、監視部１２は、各システム３０から送信されるログ情報を取得し、ログ情報にインシデントの発生を示す情報が含まれている場合に、そのログ情報を送信したシステム３０におけるインシデントの発生を検知する。

【0017】

監視部１２は、インシデントの発生を検知した場合、アクティブ系とスタンバイ系との切り替えや移行を制御する移行制御部（図示省略）へ、インシデントが発生したアクティブ系のシステム３０とスタンバイ系のシステム３０との切り替えを指示する。これにより、移行制御部が、スタンバイ系のシステム３０をアクティブ系のシステム３０として稼働を開始させる。

【0018】

また、監視部１２は、インシデントの発生を検知した場合、インシデントに関連するシステム３０の識別情報（以下、「システムＩＤ」という）を選定部１４に通知する。なお、インシデントに関連するシステム３０とは、他の拠点への移行が必要となるシステムである。インシデントがアクティブ系のシステム３０で発生した場合、そのシステム３０と対になるスタンバイ系のシステム３０であり、インシデントがスタンバイ系のシステム３０で発生した場合、そのシステム３０自体である。

【0019】

選定部１４は、複数のシステム３０のいずれかのシステム３０において、インシデントの発生が検知された場合、インシデントに関連するシステム３０の移行先の候補となる拠点（以下、「移行先候補」という）を選定する。選定部１４は、複数の拠点のうち、インシデントに関連するシステム３０が稼働する移行元の拠点以外の拠点で、インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補を選定する。

【0020】

具体的には、選定部１４は、拠点ＤＢ２４に記憶された「空きリソース量」（詳細は後述）を参照し、各拠点の空リソース量を取得し、システム３０の移行に必要なリソースが確保可能か否かを判定する。リソースを確保可能な拠点が存在する場合、選定部１４は、その拠点を移行先候補として選定する。リソースを確保可能な拠点が存在しない場合、選定部１４は、システムＤＢ２２を参照して、各拠点で稼働するシステム３０を削除又は縮退した場合に確保可能なリソース量を導出する。

【0021】

ここで、システムＤＢ２２には、図３に示すように、「システムＩＤ」、「ＡＣＴ／ＳＢＹ」、「優先度」、「拠点」、「リソース」等の情報が記憶される。「ＡＣＴ／ＳＢＹ」は、該当のシステム３０がアクティブ系（ＡＣＴ）かスタンバイ系（ＳＢＹ）かを示す情報である。「優先度」は、該当のシステム３０の重要性に基づく稼働の優先度である。本実施形態では、優先度を「高」、「中」、及び「低」の３段階とする場合について説明する。「拠点」は、該当のシステム３０が配置されている拠点の識別情報（以下、「拠点ＩＤ」という）である。「リソース」は、該当のシステム３０を構築するために必要なリソース量である。本実施形態では、各拠点で動作する仮想サーバの各々が利用するリソース量が全て同じであるものとし、図３の例では、各システム３０が稼働する仮想サーバを「リソース」として特定することで、必要なリソース量を表している。

【0022】

より具体的には、選定部１４は、各拠点で稼働するシステム３０がアクティブ系かスタンバイ系かに基づいて、そのシステム３０が削除対象か縮退対象かを判断する。また、選定部１４は、各拠点で稼働するシステム３０の優先度に基づいて、システム３０が削除対象か縮退対象かを判断する。例えば、選定部１４は、優先度が予め定めた優先度より低く、かつスタンバイ系のシステムを削除対象のシステムと判定し、優先度が予め定めた優先度より高く、かつアクティブ系のシステムを縮退対象のシステムと判定することができる。

【0023】

また、選定部１４は、優先度が低い順、かつスタンバイ系、アクティブ系の順に各拠点で稼働するシステム３０を削除又は縮退した場合に確保可能なリソース量を導出する。そして、選定部１４は、拠点毎に導出したリソース量の合計が、インシデントに関連するシステム３０を移行するために必要なリソース量に到達した拠点から順に移行先候補として選定する。選定部１４は、選定した移行先候補である拠点の拠点ＩＤを決定部１６に通知する。

【0024】

決定部１６は、選定部１４で選定された移行先候補から、所定の条件を満たす移行先候補を移行先の拠点として決定する。所定の条件とは、移行先候補とインシデントが発生した拠点又は移行するシステム３０が稼働していた拠点（以下、「移行元に関する拠点」という）との距離に基づく条件である。なお、ここでの「距離」は、具体的な数値で表される距離に限定されず、相対的に遠い又は近い等を表すものであってもよい。

【0025】

決定部１６は、図４に示すような拠点ＤＢ２４を参照して、移行先候補の各々と移行元に関する拠点との距離を特定する。図４の例では、拠点ＤＢ２４には、「拠点ＩＤ」、「地方」、「空リソース量」等の情報が記憶されている。「地方」は、拠点が存在する地方であり、移行先候補の各々と移行元に関する拠点との距離を特定するための情報である。「空リソース量」は、必要なリソース量を確保可能か否かを判断する際に使用される情報である。

【0026】

距離に基づく条件としては、例えば、地震等の大規模災害に対してもシステム３０の継続性を担保することを目的として、インシデントが発生した拠点との距離が最大の移行先候補を選択するような条件を定めておくことができる。また、例えば、迅速なシステム３０の移行を目的として、移行するシステム３０が稼働していた拠点との距離が最小の移行先候補を選択するような条件を定めておくことができる。さらに、発生したインシデントの原因に応じて、上述のような条件を切り替えて適用するようにしてもよい。

【0027】

決定部１６は、決定した移行先の拠点の拠点ＩＤ、削除又は縮退するシステム３０の情報、移行するシステム３０の情報等を含む移行情報を、移行制御部へ出力する。

【0028】

移行先決定装置１０は、例えば図５に示すコンピュータ４０で実現することができる。コンピュータ４０は、ＣＰＵ（Central Processing Unit）４１と、一時記憶領域としてのメモリ４２と、不揮発性の記憶部４３とを備える。また、コンピュータ４０は、入力部、表示部等の入出力装置４４と、記憶媒体４９に対するデータの読み込み及び書き込みを制御するＲ／Ｗ（Read/Write）部４５とを備える。また、コンピュータ４０は、インターネット等のネットワークに接続される通信Ｉ／Ｆ（Interface）４６を備える。ＣＰＵ４１、メモリ４２、記憶部４３、入出力装置４４、Ｒ／Ｗ部４５、及び通信Ｉ／Ｆ４６は、バス４７を介して互いに接続される。

【0029】

記憶部４３は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、フラッシュメモリ等によって実現できる。記憶媒体としての記憶部４３には、コンピュータ４０を、移行先決定装置１０として機能させるための移行先決定プログラム５０が記憶される。移行先決定プログラム５０は、監視プロセス５２と、選定プロセス５４と、決定プロセス５６とを有する。また、記憶部４３は、システムＤＢ２２及び拠点ＤＢ２４の各々を構成する情報が記憶される情報記憶領域６０を有する。

【0030】

ＣＰＵ４１は、移行先決定プログラム５０を記憶部４３から読み出してメモリ４２に展開し、移行先決定プログラム５０が有するプロセスを順次実行する。ＣＰＵ４１は、監視プロセス５２を実行することで、図２に示す監視部１２として動作する。また、ＣＰＵ４１は、選定プロセス５４を実行することで、図２に示す選定部１４として動作する。また、ＣＰＵ４１は、決定プロセス５６を実行することで、図２に示す決定部１６として動作する。また、ＣＰＵ４１は、情報記憶領域６０から情報を読み出して、システムＤＢ２２及び拠点ＤＢ２４の各々をメモリ４２に展開する。これにより、移行先決定プログラム５０を実行したコンピュータ４０が、移行先決定装置１０として機能することになる。なお、プログラムを実行するＣＰＵ４１はハードウェアである。

【0031】

なお、移行先決定プログラム５０により実現される機能は、例えば半導体集積回路、より詳しくはＡＳＩＣ（Application Specific Integrated Circuit）等で実現することも可能である。

【0032】

次に、本実施形態に係る移行先決定装置１０の作用について説明する。ここでは、図３に示すように、各システム３０の情報がシステムＤＢ２２に記憶されているものとする。この各システム３０の情報を、優先度別、拠点別に表すと共に、アクティブ系とスタインバイ系とで対になるシステム３０間を一点鎖線で接続した図を、図６に示す。

【0033】

複数のシステム３０の各々が、稼働中のシステムの状態を示すログ情報を随時出力し、移行先決定装置１０へ送信する。そして、移行先決定装置１０において、図７に示す移行先決定処理が実行される。なお、移行先決定処理は、開示の技術の移行先決定方法の一例である。

【0034】

ステップＳ１０で、監視部１２が、各システム３０から送信されたログ情報を取得し、ログ情報にインシデントの発生を示す情報が含まれているか否かに基づいて、いずれかのシステム３０でインシデントが発生したか否かを判定する。インシデントが発生した場合には、ステップＳ２０へ移行し、インシデントが発生していない場合には、本ステップの判定を繰り返す。

【0035】

ここでは、図６に示すように、拠点１で稼働するシステムＢにインシデントが発生したとする。この場合、拠点４で稼働するスタンバイ系のシステムＢがアクティブ系に切り替えられる。これに伴い、スタンバイ系のシステムＢを新たに他の拠点に移行する必要がある。

【0036】

ステップＳ２０では、監視部１２が、インシデントが発生したアクティブ系のシステム３０とスタンバイ系のシステム３０との切り替えを移行制御部に指示する。また、監視部１２が、インシデントに関連するシステム３０、すなわち移行するシステム３０のシステムＩＤ（ここでは、「システムＢ（ＳＢＹ）」）を選定部１４に通知する。

【0037】

次に、ステップＳ３０で、選定部１４が選定処理を実行する。ここで、図８を参照して、選定処理について詳述する。

【0038】

ステップＳ３１で、選定部１４が、システムＤＢ２２を参照して、監視部１２から通知されたシステムＩＤが示すシステム３０を構築するために必要なリソース量を特定する。そして、選定部１４が、拠点ＤＢ２４の「空きリソース量」を参照して、移行元に関する拠点以外の拠点で必要なリソース量を確保可能な拠点が存在するか否かを判定する。リソースを確保可能な拠点が存在する場合には、処理はステップＳ３６へ移行する。リソースを確保可能な拠点が存在しない場合には、処理はステップＳ３２へ移行する。

【0039】

ステップＳ３２で、選定部１４が、他のシステム３０を削除又は縮退して必要なリソース量を確保可能な移行先候補を選定するため、削除又は縮退の対象となるシステム３０を特定するための変数ｉを１に設定する。ここでは、図９に示すように、削除又は縮退の対象となるシステム３０の条件を、システム３０の優先度、及びアクティブ系かスタンバイ系かに基づいて順番に判断するように予め定めておく。図９の例では、ｉ＝１、２、・・・、７の順で、システムの優先度が低い順、かつスタンバイ系、アクティブ系の順となっている。

【0040】

次に、ステップＳ３３で、選定部１４が、ｉ巡目の条件が、移行するシステム３０の優先度、及びアクティブ系かスタンバイ系かと同程度に達したか否かを判定する。これは、移行するシステム３０と優先度等が同程度以上のシステム３０を削除又は縮退することを回避するため、１つ手前の条件で処理を終了するための判定である。ｉ巡目の条件が、移行するシステム３０と同程度に達した場合には、処理はステップＳ３９へ移行し、同程度に達していない場合には、処理はステップＳ３４へ移行する。

【0041】

ステップＳ３４では、選定部１４が、移行元の拠点以外の拠点毎に、ｉ巡目の条件に該当するシステム３０の削除又は縮退により確保できるリソース量を導出する。

【0042】

ここでは、移行元の拠点である拠点４以外の拠点１、拠点２、及び拠点３の各々の空リソース量が同量であり、他のシステム３０の削除又は縮退により確保する必要があるリソース量も同量であるとする。この場合、図９の条件に従うと、１巡目の条件は、「優先度が低、かつＳＢＹのシステムを削除」であるため、拠点１のシステムＧ（ＳＢＹ）及び拠点２のシステムＦ（ＳＢＹ）が該当する。

【0043】

選定部１４は、システムＤＢ２２を参照して、該当のシステム３０が使用しているリソース量を特定し、図１０に示すように、拠点毎に、確保可能なリソース量として積み上げる。

【0044】

次に、ステップＳ３５で、選定部１４が、ｉ巡目までの条件に該当するシステム３０の削除又は縮退により、確保が必要なリソース量に到達する拠点が存在するか否かを判定する。確保が必要なリソース量に到達する拠点が存在する場合には、処理はステップＳ３６へ移行し、存在しない場合には、処理はステップＳ３７へ移行する。ここでは、確保が必要なリソース量に到達する拠点が存在しないため、ステップＳ３７へ移行する。

【0045】

ステップＳ３７では、ｉが、最後の条件の順番を表すＮ（図９の例では「７」）より大きいか否かを判定する。ｉ＞Ｎの場合には、処理はステップＳ３９へ移行する。ｉ≦Ｎの場合には、処理はステップＳ３８へ移行し、選定部１４が、ｉを１インクリメントして、処理はステップＳ３３に戻る。ここでは、ｉ＝１であるので、ステップＳ３８でｉ＝２となって、処理はステップＳ３３に戻る。

【0046】

２巡目の条件は、「優先度が低、かつＡＣＴのシステムを削除」であるため、拠点３のシステムＧ（ＡＣＴ）及びシステムＦ（ＡＣＴ）が該当する。選定部１４は、図１０に示すように、拠点毎に、該当のシステム３０が使用しているリソース量を、確保可能なリソース量として、１巡目の結果に積み上げる。

【0047】

２巡目の条件でも確保が必要なリソース量に到達する拠点が存在しないため、３巡目が実行される。３巡目の条件は、「優先度が中、かつＳＢＹのシステムを削除」であるため、拠点１のシステムＥ（ＳＢＹ）及び拠点２のシステムＣ（ＳＢＹ）が該当する。選定部１４は、図１０に示すように、拠点毎に、該当のシステム３０が使用しているリソース量を、確保可能なリソース量として、２巡目までの結果に積み上げる。

【0048】

３巡目の条件でも確保が必要なリソース量に到達する拠点が存在しないため、４巡目が実行される。４巡目の条件は、「優先度が中、かつＡＣＴのシステムを縮退」であるため、拠点２のシステムＤ（ＡＣＴ）及び拠点３のシステムＥ（ＡＣＴ）が該当する。選定部１４は、図１０に示すように、拠点毎に、該当のシステム３０が使用しているリソース量のうち、縮退により削減可能なリソース量を、確保可能なリソース量として、３巡目までの結果に積み上げる。なお、縮退により削減可能なリソース量は、システム３０毎に、どの程度のサイズまで縮退可能かを予め定めておけばよい。

【0049】

４巡目の終了後に、拠点２及び拠点３が、確保が必要なリソース量に到達するため、ステップＳ３５で肯定判定されてステップＳ３６へ移行する。

【0050】

ステップＳ３６では、選定部１４が、必要なリソース量を確保可能な拠点を移行先候補として選定する。必要なリソース量を確保可能な拠点が複数存在する場合、その複数の拠点を全て移行先候補として選定する。ここでは、拠点２及び拠点３が移行先候補として選定される。そして、選定部１４は、移行先候補として選定した拠点の拠点ＩＤを決定部１６に通知し、処理は移行先決定処理（図７）に戻る。

【0051】

ステップＳ３９では、選定部１４が、移行先候補がない旨を選定結果として決定部１６に通知し、処理は移行先決定処理（図７）に戻る。

【0052】

次に、図７のステップＳ４０で、決定部１６が、選定部１４により選定された移行先候補が複数存在するか否かを判定する。複数存在する場合には、処理はステップＳ５０へ移行し、１つの場合には、処理はステップＳ６０へ移行する。なお、選定部１４から移行先候補がない旨を通知されている場合には、決定部１６はその旨をユーザに通知する等の処理を行う。

【0053】

ステップＳ５０では、決定部１６が、複数の移行先候補から、移行先候補と移行元に関する拠点との距離に基づく所定の条件を満たす移行先候補を移行先の拠点として決定する。ここでは、拠点２及び拠点３が移行先候補として選定されている。また、インシデントが発生したのは拠点１、移行するシステムの移行元は拠点４である。距離に基づく条件が、移行先候補とインシデントが発生した拠点との距離が最大となる移行先候補を選択するように定められているとする。この場合、図４に示す拠点ＤＢ２４を参照すると、拠点１（北海道）からの距離がより遠い拠点３（近畿）が移行先として決定される。また、距離に基づく条件が、移行先候補と移行元の拠点との距離が最小となる移行先候補を選択するように定められているとする。この場合も、拠点４（九州）からの距離がより近い拠点３（近畿）が移行先として決定される。

【0054】

一方、ステップＳ６０では、決定部１６が、１つの移行先候補をそのまま移行先として決定する。

【0055】

次に、ステップＳ７０で、決定部１６が、決定した移行先の拠点の拠点ＩＤ、削除又は縮退するシステム３０の情報、移行するシステム３０の情報等を含む移行情報を、移行制御部へ出力し、移行先決定処理は終了する。

【0056】

以上説明したように、本実施形態に係る移行先決定装置によれば、複数の拠点の各々で稼働する１又は複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、移行先候補を選定する。移行先候補は、複数の拠点のうち、インシデントに関連するシステムが稼働する移行元の拠点以外の拠点で、インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補である。そして、移行先候補のうち、移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす移行先候補から、移行先の拠点を決定する。これにより、複数の拠点間におけるシステムの適切な移行先を決定することができる。

【0057】

なお、上記実施形態では、必要なリソース量を確保可能な移行先候補が見つかり次第、距離の条件に基づいて移行先を決定する場合について説明したが、これに限定されない。例えば、優先度、及びアクティブ系かスタンバイ系かに基づく複数の条件（例えば、図９に示すｉ＝１～４の条件）のいずれかを満たす拠点を全て抽出しておいて、その中で距離の条件に基づいて移行先を決定してもよい。また、例えば、インシデントが発生した拠点から所定距離以上離れている等の距離の条件に基づいて拠点の絞り込みを行ってから、優先度、及びアクティブ系かスタンバイ系かに基づく所定の条件で移行先候補を選定してもよい。

【0058】

また、上記実施形態では、移行先候補が１つしかない場合には、その移行先候補を移行先として決定する場合について説明したが、これに限定されない。距離に基づく条件が、所定の数値で定められている場合（例えば、インシデントが発生した拠点から所定距離以上離れている等）、移行先候補が１つの場合でも、距離の条件を満たす場合に、移行先として決定するようにしてもよい。

【0059】

この場合、移行先候補が移行先に決定されなかった場合には、まだ移行先候補として選定されていない拠点について、図８に示すステップＳ３８に戻って、移行先候補を選定する処理を継続してもよい。

【0060】

また、距離に基づく条件が、所定の数値で定められている場合、上記移行先決定処理（図７）のステップＳ５０で該当の移行先が存在しない場合も生じ得る。この場合も上記と同様に、図８に示すステップＳ３８に戻って、移行先候補を選定する処理を継続してもよい。

【0061】

また、上記実施形態における優先度、及びアクティブ系かスタンバイ系かに基づく所定の条件は、図９の例に限定されない。スタンバイ系のシステムを優先度が低い順に削除又は縮退の対象とした後に、アクティブ系のシステムを優先度が低い順に削除又は縮退の対象としてもよい。また、優先度が低のシステム、及び優先度が中かつスタンバイ系のシステムについても、まず縮退の対象としてから削除の対象としてもよい。

【0062】

また、移行先候補から移行先を決定する際、距離の条件に加え、他の条件も決定の指標として用いてもよい。例えば、各拠点で稼働するシステムの優先度の平均値がより低い拠点を選択する等の条件を加えてもよい。

【0063】

また、上記実施形態では、移行するシステムが稼働していた移行元の拠点を、移行先候補から除外する場合について説明したが、その他にも、隔離された拠点、インシデントが発生した拠点等を除外してもよい。

【0064】

また、上記実施形態では、移行先決定プログラムが記憶部に予め記憶（インストール）されている態様を説明したが、これに限定されない。開示の技術に係るプログラムは、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、ＵＳＢメモリ等の記憶媒体に記憶された形態で提供することも可能である。

【0065】

以上の実施形態に関し、さらに以下の付記を開示する。

【0066】

（付記１）
複数の拠点の各々で稼働する１又は複数のシステムの各々を監視し、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補を選定し、
前記移行先候補のうち、前記移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす前記移行先候補から、移行先の拠点を決定する
ことを含む処理をコンピュータに実行させるための移行先決定プログラム。

【0067】

（付記２）
前記インシデントの原因に応じて前記条件が予め定められた付記１に記載の移行先決定プログラム。

【0068】

（付記３）
前記リソースを確保可能か否かの判定において、各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出する付記１又は付記２に記載の移行先決定プログラム。

【0069】

（付記４）
前記各拠点で稼働するシステムがアクティブ系かスタンバイ系かに基づいて、前記システムが削除対象か縮退対象かを判断する付記３に記載の移行先決定プログラム。

【0070】

（付記５）
前記各拠点で稼働するシステムの優先度に基づいて、前記システムが削除対象か縮退対象かを判断する付記４に記載の移行先決定プログラム。

【0071】

（付記６）
優先度が予め定めた優先度より低く、かつスタンバイ系のシステムを削除対象のシステムと判定し、優先度が予め定めた優先度より高く、かつアクティブ系のシステムを縮退対象のシステムと判定する付記５に記載の移行先決定プログラム。

【0072】

（付記７）
システムの優先度が低い順、かつスタンバイ系、アクティブ系の順に前記各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出し、前記拠点毎に導出したリソース量の合計が、前記インシデントに関するシステムを移行するために必要なリソース量に到達した拠点から順に移行先候補として選定し、
選定された前記移行先候補が前記条件を満たす場合、前記移行先候補の選定を終了し、前記条件を満たす前記移行先候補を移行先の拠点として決定する
付記５又は付記６に記載の移行先決定プログラム。

【0073】

（付記８）
複数の拠点の各々で稼働する１又は複数のシステムの各々を監視する監視部と、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補を選定する選定部と、
前記移行先候補のうち、前記移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす前記移行先候補から、移行先の拠点を決定する決定部と、
を含む移行先決定装置。

【0074】

（付記９）
前記インシデントの原因に応じて前記条件が予め定められた付記８に記載の移行先決定装置。

【0075】

（付記１０）
前記選定部は、前記リソースを確保可能か否かの判定において、各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出する付記８又は付記９に記載の移行先決定装置。

【0076】

（付記１１）
前記選定部は、前記各拠点で稼働するシステムがアクティブ系かスタンバイ系かに基づいて、前記システムが削除対象か縮退対象かを判断する付記１０に記載の移行先決定装置。

【0077】

（付記１２）
前記選定部は、前記各拠点で稼働するシステムの優先度に基づいて、前記システムが削除対象か縮退対象かを判断する付記１１に記載の移行先決定装置。

【0078】

（付記１３）
前記選定部は、優先度が予め定めた優先度より低く、かつスタンバイ系のシステムを削除対象のシステムと判定し、優先度が予め定めた優先度より高く、かつアクティブ系のシステムを縮退対象のシステムと判定する付記１２に記載の移行先決定装置。

【0079】

（付記１４）
前記選定部は、システムの優先度が低い順、かつスタンバイ系、アクティブ系の順に前記各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出し、前記拠点毎に導出したリソース量の合計が、前記インシデントに関するシステムを移行するために必要なリソース量に到達した拠点から順に移行先候補として選定し、
前記決定部は、選定された前記移行先候補が前記条件を満たす場合、前記移行先候補の選定を終了し、前記条件を満たす前記移行先候補を移行先の拠点として決定する
付記１２又は付記１３に記載の移行先決定装置。

【0080】

（付記１５）
複数の拠点の各々で稼働する１又は複数のシステムの各々を監視し、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点の中から、前記インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補を選定し、
前記移行先候補のうち、前記移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす前記移行先候補から、移行先の拠点を決定する
ことを含む処理をコンピュータが実行する移行先決定方法。

【0081】

（付記１６）
前記インシデントの原因に応じて前記条件が予め定められた付記１５に記載の移行先決定方法。

【0082】

（付記１７）
前記リソースを確保可能か否かの判定において、各拠点で稼働するシステムを削除又は縮退した場合に確保可能なリソース量を導出する付記１５又は付記１６に記載の移行先決定方法。

【0083】

（付記１８）
前記各拠点で稼働するシステムがアクティブ系かスタンバイ系かに基づいて、前記システムが削除対象か縮退対象かを判断する付記１７に記載の移行先決定方法。

【0084】

（付記１９）
前記各拠点で稼働するシステムの優先度に基づいて、前記システムが削除対象か縮退対象かを判断する付記１８に記載の移行先決定方法。

【0085】

（付記２０）
複数の拠点の各々で稼働する１又は複数のシステムの各々を監視し、
前記複数のシステムのいずれかのシステムにおいて、インシデントの発生を検知した場合に、前記複数の拠点のうち、前記インシデントに関連するシステムが稼働する拠点以外の拠点で、前記インシデントに関連するシステムを移行するためのリソースを確保可能な移行先候補を選定し、
前記移行先候補のうち、前記移行先候補と移行元に関する拠点との距離が予め定めた条件を満たす前記移行先候補から、移行先の拠点を決定する
ことを含む処理をコンピュータに実行させるための移行先決定プログラムを記憶した記憶媒体。

【符号の説明】

【0086】

１０ 移行先決定装置
１２ 監視部
１４ 選定部
１６ 決定部
２２ システムＤＢ
２４ 拠点ＤＢ
３０ システム
４０ コンピュータ
４１ ＣＰＵ
４２ メモリ
４３ 記憶部
４９ 記憶媒体
５０ 移行先決定プログラム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】