JP7443182B2 - サーバ、サーバシステム、及びサーバ管理方法 - Google Patents

Description

本発明は、災害障害対応組織の活動に関する情報を複数の組織間で利用可能にする技術に関する。

災害障害対応活動は多岐に亘り、多数の組織が多岐に亘る活動を実施している。効率的な災害障害対応活動には、各組織の活動状況や、各組織が保有する情報を組織間で共有し、共有した情報を組み合わせて解析し、活動の全体像を把握し、全体像を踏まえたうえで、個々の活動を実施する必要がある。

多数の組織で情報を共有し、その情報を組み合わせて解析した結果を個々の活動に反映させる方法として、各組織の端末装置と、各組織の情報を組み合わせ解析する活動情報解析装置とを、複数のサーバから構成されるサーバ群を介して情報をやり取りするようにするシステムが考えられる。

例えば、情報を仲介するサーバ群を管理する技術として、非特許文献１のＡｐａｃｈｅＫａｆｋａの技術が知られている。この技術では、サーバ群に書き込まれるデータを複数に分割する。そして、分割されたデータは、端末装置が直接書き込み及び読み出しする１つのリーダレプリカと、リーダレプリカを複製し、リーダレプリカに書き込まれた最新のデータを追従する２つ以上のフォロワレプリカと、に保持される。

データを保管するサーバを選択する技術として、特許文献１には、データ格納先として安全なデータ保管するサーバを選択する際に、あらかじめ設定されたサーバ設置地域毎の危険度情報と、サーバシステムを構成する各サーバの処理状況とを考慮した危険度指標値に基づいて選択する方法が開示されている。

特開２０１４－１７４６３４号公報

Ａｐａｃｈｅ Ｋａｆｋａ、インターネット（URL:https://kafka.apache.org/）

災害障害対応組織の活動に関する情報を管理するシステムにおけるサーバ群は、災害時においても、各組織の端末装置や活動情報解析装置が必要時なときにアクセスできるように、高い可用性を持つ必要がある。

特許文献１に開示された技術よると、あらかじめ設定されたサーバ設置地域ごとの危険度情報を使って、サーバを選択することにより、可用性を持たせている。しかしながら、災害時の状況は時々刻々と変化するため、あらかじめ設定されたサーバ設置地域毎の危険度情報を使って、サーバを選択していたとしても、実際に発生した災害に対して適切なサーバであるとは限らない。

本発明は、上記事情に鑑みなされたものであり、その目的は、災害の状況に応じて、適切に情報を管理して、システムの可用性を向上することのできる技術を提供することにある。

上記目的を達成するため、一観点に係るサーバは、複数のサーバを備え、災害障害対応組織の活動に関する情報が複数に分割された各部分情報を格納し、前記部分情報のアクセスを受け付ける役割を担う記憶領域である複数の主レコードを異なるサーバに配置するとともに、前記主レコードに格納される各部分情報の複製を格納する役割を担う記憶領域である副レコードを、前記部分情報の主レコードが配置されるサーバと異なるサーバに配置するサーバシステムにおけるサーバであって、前記サーバには、前記部分情報の主レコード又は副レコードが配置されており、前記サーバは、自サーバの設置地域、又は自サーバに配置されている主レコード又は副レコードに対応する副レコード又は主レコードが配置されている他のサーバの設置地域における災害の状況に関する災害状況情報を取得し、前記災害状況情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する判定部と、配置を入れ替えると判定した場合に、他のサーバに主レコードと副レコードとの配置の入れ替えの要請を送信する入替要請部と、を備える。

本発明によれば、災害の状況に応じて、適切に情報を管理することができ、システムの可用性を向上することができる。

図１は、第１実施形態に係るサーバシステムの全体構成図である。 図２は、第１実施形態に係るサーバシステムの各構成の詳細構成図である。 図３は、第１実施形態に係るサーバシステムにおけるサーバの状態の一例を示す図である。 図４は、図３に示すサーバの状態から主副レコードの入れ替えを行った場合のサーバの状態を示す図である。 図５は、第１実施形態に係るサーバシステムにおける解析結果の取得におけるデータフローを説明する図である。 図６は、第１実施形態に係る解析処理及び解析結果の格納におけるデータフローを説明する図である。 図７は、第１実施形態に係るメタデータを説明する図である。 図８は、第１実施形態に係るシステム接続要請対応処理のフローチャートである。 図９は、第１実施形態に係るルーティン処理のフローチャートである。 図１０は、第１実施形態に係る副レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。 図１１は、第１実施形態に係る主レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。 図１２は、第１実施形態に係るレコード間の複製処理のフローチャートである。 図１３Ａは、第１実施形態に係る停電区域データを説明する図である。 図１３Ｂは、第１実施形態に係る河川氾濫区域データを説明する図である。 図１３Ｃは、第１実施形態に係る危険度計算処理のフローチャートである。 図１３Ｄは、第１実施形態に係る危険度計算結果を説明する図である。 図１４Ａは、第１実施形態に係る危険度変動を示す図である。 図１４Ｂは、第１実施形態に係る複製率変動を示す図である。 図１４Ｃは、第１実施形態に係る将来の予測も含む危険度変動を示す図である。 図１５は、第１実施形態に係るライフラインの状況を示すデータの一例を説明する図である。 図１６は、第１実施形態に係るライフライン異常指数変動を示す図である。 図１７は、第１実施形態に係る端末装置に表示される操作画面の一例を示す図である。 図１８は、第１実施形態に係るサーバにおける操作画面の一例を示す図である。 図１９Ａは、第２実施形態に係るサーバのサーバ適正度判定部の処理を説明する図である。 図１９Ｂは、第２実施形態に係る危険度変動とライフライン異常指数変動とを示す図である。 図２０Ａは、第３実施形態に係る主レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。 図２０Ｂは、第３実施形態に係る副レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、第１実施形態に係るサーバシステムの全体構成図である。

サーバシステム１は、サーバ群１００と、１以上の端末装置２００，２１０，２２０と、活動情報解析装置３００と、外部動態情報ＤＢ３１０とを備える。サーバ群１００と、１以上の端末装置２００，２１０，２２０と、活動情報解析装置３００と、外部動態情報ＤＢ３１０とは、ネットワーク５０を介して接続されている。ネットワーク５０は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などのネットワークである。

サーバ群１００は、管理するデータのやり取りを行う複数のサーバ（図１の例では、サーバ１１０，１２０，１３０）を含む。図１のサーバシステム１では、サーバ群１００は、３つのサーバから構成されているが、本発明は、これに限定されるものではなく、２つ又は４つ以上のサーバから構成されてもよい。サーバ群１００を構成する各サーバは、例えば、互いに物理的（地理的）距離の離れた異なる地域に設置されていてもよい。

端末装置２００，２１０，２２０は、それぞれ異なる災害障害対策を行う組織（災害障害対応組織）が保有し、利用する装置である。端末装置２００，２１０，２２０は、各組織の活動情報をサーバ群１００に配信し、サーバ群１００から活動情報に対する解析結果を取得する。

活動情報解析装置３０は、端末装置２００，２１０，２２０等によりサーバ群１００に配信された活動情報を取得して、解析し、解析結果をサーバ群１００に配信する。

外部動態情報ＤＢ３１０は、端末装置を保有する各組織や、サーバ群の各サーバを運用している組織の管理外からの動態情報（災害状況情報の一例）をサーバ群１００に提供する。

動態情報は、例えば、災害に関係する自然現象自体に関する情報と、自然現象に起因する所定の対象（人や建物等）の被害に関する情報とを含む。災害に関係する自然現象自体に関する情報としては、例えば、地震の震度分布、地震の状態、気象情報（例えば、大雨警報洪水警報等の気象警報、雨量、河川水位等）がある。所定の対象の被害に関する情報としては、地震による建物被害や建物の推定被害、地震での震度暴露人口、道路状況、医療機関の状態等がある。なお、動態情報に、雲の動きから予測される数時間後の気象予測や、過去の渋滞状況に基づいた渋滞予測等の未来の状況を予測する情報が含まれていてもよい。なお、図１に示すサーバシステム１においては、外部動態情報ＤＢを１つとしていたが、本発明は、これに限られず、２つ以上の外部動態情報ＤＢを備えていてもよい。また、外部動態情報ＤＢに代えて、自らデータを収集して解析することにより動態情報を作成し、サーバ群１００に提供するシステムを備えてもよい。

次に、サーバシステム１の各構成について詳細に説明する。

図２は、第１実施形態に係るサーバシステムの各構成の詳細構成図である。

サーバ１１０は、例えば、プロセッサやメモリ等を備えるコンピュータにより構成され、サーバ間連携部１１１と、サーバ適正度判定部１１２と、危険度動態ＤＢ１１３と、解析情報ＤＢ１１４と、活動情報ＤＢ１１５と、メタデータＤＢ１１６とを含む。サーバ間連携部１１１と、サーバ適正度判定部１１２とは、プロセッサがメモリに格納されたプログラムを実行することにより構成される。ここで、サーバ適正度判定部１１２は、判定部、受理決定部、入替要請部の一例であり、サーバ間連携部１１１は、アクセス管理部の一例である。

サーバ間連携部１１１は、他のサーバのサーバ間連携部との間での通信を実施する。サーバ適正度判定部１１２は、外部動態情報ＤＢ３１０やサーバ間連携部１１１から取得した他のサーバの情報から、各サーバの設置位置の危険度や、後述するレコードの複製率に基づき、各サーバの危険度等を計算して、サーバが主レコードを配置するサーバとして適正か否かを判定する。危険度動態ＤＢ１１３は、適正度判定部１１２が計算した各サーバの危険度と、外部動態情報ＤＢ３１０から取得した情報を保存する。解析結果ＤＢ１１４は、活動情報解析装置３００が解析した結果を保存する。活動情報ＤＢ１１５は、各端末装置２００，２１０，２２０等から配信される活動情報等を保存する。メタデータＤＢ１１６は、処理に必要な各種メタデータ（図７参照）を保存する。なお、他のサーバ１２０、１３０もサーバ１１０と同様な構成をしている。

端末装置２００は、例えば、プロセッサやメモリ等を備えるコンピュータにより構成され、解析結果取得部２０１と、活動情報配信部２０２と、情報形式変換部２０３と、保有活動情報ＤＢ２０４とを含む。活動情報配信部２０２と、情報形式変換部２０３と、保有活動情報ＤＢ２０４とは、プロセッサがメモリに格納されたプログラムを実行することにより構成される。

保有活動情報ＤＢ２０４は、端末装置２００により集められた各組織の活動状況等を含むデータを格納する。解析結果取得部２０１は、サーバ群１００に保存されている解析結果を取得する。活動情報配信部２０２は、保有する組織の活動情報等のデータをサーバ群１００に配信して書き込む。情報形式変換部２０３は、保有活動情報ＤＢ２０４に格納されている情報を、活動情報配信部２０２がサーバ群１００に書き込める形式に変換する。なお、他の端末装置２１０、端末装置２２０は、端末装置２００と同様な構成をしている。

端末装置２００の保有活動情報ＤＢ２０４に格納されている各組織の活動状況、管理する施設の状態等を表すデータは、情報形式変換部２０３によってサーバ群１００で管理するデータの形式に変換され、活動情報配信部２０２により、サーバ１１０（１２０，１２０）中の活動情報ＤＢ１１５（１２５，１３５）に書き込まれる。

活動情報解析装置３００は、例えば、プロセッサやメモリ等を備えるコンピュータにより構成され、解析結果配信部３０１と、情報形式変換部３０２と、インテリジェンス導出部３０３と、活動情報取得部３０４とを含む。解析結果配信部３０１と、情報形式変換部３０２と、インテリジェンス導出部３０３と、活動情報取得部３０４とは、プロセッサがメモリに格納されたプログラムを実行することにより構成される。

解析結果配信部３０１は、サーバ群１００に解析結果を書き込む。情報形式変換部３０２は、インテリジェンス導出部３０３による解析結果をサーバ群１００に書き込めるデータ形式を変換する。インテリジェンス導出部３０３は、サーバ群１００から取得した各端末装置（２００，２１０，２２０）のデータに基づいて解析処理を実行する。インテリジェンス導出部３０３は、活動情報を統合する機能や、重要支援地域を抽出する機能や、解析結果を可視化する機能を有する。活動情報取得部３０４は、サーバ群１００から各端末装置に保有されている活動情報を取得する。

活動情報解析装置３００では、活動情報取得部３０４がサーバ群１００の活動情報ＤＢ（サーバ１１０では、活動情報ＤＢ１１５）に書き込まれたデータを取得し、インテリジェンス導出部３０３に渡す。インテリジェンス導出部３０３は、活動情報取得部３０４から渡されたデータを用いて、各組織の活動の意思決定を支援するような解析結果を出力する。情報形式変換部３０２は、インテリジェンス導出部３０３により出力された解析結果をサーバ群１００で管理するデータ形式に変換し、解析結果配信部３０１は、データ形式が変換された解析結果をサーバ群１００の解析結果ＤＢ（サーバ１１０であれば、解析結果ＤＢ１１４）に書き込む。

端末装置２００は、解析結果取得部２０１によって、サーバ群１００の解析結果ＤＢから解析結果を取得し、各組織の活動の意思決定をする際の判断材料に用いる。また、サーバ群１００のサーバ、例えば、サーバ１１０では、サーバ適正度判定部１１２が外部動態情報ＤＢ３１０から、停電や河川氾濫情報等の動態情報を取得し、各サーバ１１０，１２０，１３０の主レコードと副レコードとの配置の入れ替え（主副レコード配置入替という）の判断材料として扱う。

なお、端末情報２００とサーバ１１０との間、活動情報解析装置３００とサーバ１１０との間、及び外部動態情報ＤＢ３１０とサーバ１１０との間で実施されるデータの書き込み及び読み出しは、全て非同期で実施されてもよい。

次に、本実施形態に係るサーバシステム１における各サーバの状態の一例について説明する。

図３は、第１実施形態に係るサーバシステムにおけるサーバの状態の一例を示す図である。なお、図３中において、線３２０等の実線で表されている矢印は、データを送る方向を示し、線３３０のように点線で表される矢印は、データを複製する方向を示し、線３４０のように破線で表される矢印は、サーバ間の通信を要請する方向を示している。

図３の例では、各組織の活動情報は、種類Ａと種類Ｂとの情報（部分情報）に分割されて管理されている。なお、図３の例では、活動情報は、種類Ａと種類Ｂとの２つに分割されているが、これに限定されるものではなく、活動情報は分割されていなくてもよく、３つ以上に分割されてもよい。活動情報の分割ルールは、例えば、図３の例では、端末装置２００のデータを種類Ｂとし、端末装置２１０のデータを種類Ａとするようにしているが、例えば、医療施設に関わる活動情報を種類Ａとし、物資供給に関わる情報を種類Ｂとするように活動情報の内容に応じて分割してもよく、端末装置から書き込まれた時刻が偶数分であったら種類Ａとし、奇数分であったら種類Ｂとしてもよく、これらに限定されるものではない。

一方、活動情報解析装置３００からの解析結果は、図３に示す例では、種類Ｃと、種類Ｄとの情報（部分情報）に分割されているが、活動情報と同様に、分割する種類の数や、分割ルールについては、これに限定されない。

ここで、端末装置が直接情報を読み書きするサーバ（１１０，１２０，１３０）の記憶領域を主レコードといい、主レコードに書き込まれたデータが複製される記憶領域を副レコードという。また、種類Ａ、Ｂ、Ｃ、Ｄのデータについての主レコードを、それぞれ主レコードＡ、主レコードＢ、主レコードＣ、主レコードＤという。同様に、種類Ａ、Ｂ、Ｃ、Ｄのデータについての副レコードを、それぞれ副レコードＡ、副レコードＢ、副レコードＣ、副レコードＤという。

図３の例では、端末装置２１０の活動情報、すなわち種類Ａの情報が書き込まれる主レコードＡは、主レコードＡ１２５１としてサーバ１２０に配置され、主レコードＡ１２５１のデータの複製が格納される副レコードＡは、副レコードＡ１１５１としてサーバ１１０に配置され、副レコードＡ１３５１としてサーバ１３０に配置されている。

また、端末装置２００の活動情報、すなわち種類Ｂの情報が書き込まれる主レコードＢは、主レコードＢ１１５２としてサーバ１１０に配置され、主レコードＢ１２５２のデータの複製が格納される副レコードＢは、副レコードＢ１２５２としてサーバ１２０に配置されている。

解析結果の種類Ｃの情報が書き込まれる主レコードＣは、主レコードＣ１２４１としてサーバ１２０に配置され、主レコードＣ１２４１のデータの複製が格納される副レコードＣは、副レコードＣ１１４１としてサーバ１１０に配置され、副レコードＣ１３４１としてサーバ１３０に配置されている。

また、解析結果の種類Ｄの情報が書き込まれる主レコードＤは、主レコードＤ１１４２としてサーバ１１０に配置され、主レコードＤ１１４２のデータの複製が格納される副レコードＤは、副レコードＤ１２４２としてサーバ１２０に配置されている。

図３の例では、活動情報の種類Ａの情報と、解析結果の種類Ｃの情報との、主レコードと副レコードの構成及び配置は同様であり、活動情報の種類Ｂの情報と、解析結果の種類Ｄの情報との、主レコードと副レコードの構成及び配置は同様となっているが、それぞれの種類の主レコードと副レコードの構成や配置は、同様でなくてもよい。

各サーバ１１０，１２０，１３０が保有するサーバ間連携部１１１，１２１，１３１は、自サーバが保有する副レコードに対応する主レコードを持つサーバに対して通信を要請して、主レコードのデータを取得し、副レコードに複製する。例えば、サーバ１１０のサーバ間連携部１１１は、保有する副レコードＡ１１５１，Ｃ１１４１に対応する主レコードＡ１２５１，Ｃ１２４１を保有するサーバ１２０のサーバ間連携部１２１に通信を要請して、主レコードのデータを副レコードに複製する。

同様に、サーバ１２０のサーバ間連携部１２１は、保有する副レコードＢ１２５２，副レコードＤ１２４２に対応する主レコードＢ１１５２，主レコードＤ１１４２を保有するサーバ１１０のサーバ間連携部１１１に対して通信を要請して、主レコードのデータを副レコードに複製する。

また、サーバ１３０のサーバ間連携部１３１は、保有する副レコードＡ１３５１，副レコードＣ１３４１に対応する主レコードＡ１２５１，主レコードＣ１２４１を保有するサーバ１２０のサーバ間連携部１２１に対して通信を要請して、主レコードのデータを副レコードに複製する。

なお、各レコードのデータの通信については、各サーバ間連携部は、一方的に通信を要請するが、複数のレコードがある場合には、結果として各サーバ間連携部が双方に通信を要請している状態となることもある。

次に、主レコードと、副レコードとの配置の入れ替えを行った場合のサーバの状態を説明する。

図４は、図３に示すサーバの状態から主副レコードの入れ替えを行った場合のサーバの状態を示す図である。

図４においては、図３に示すサーバ１２０の主レコードＡ１２５１と主レコードＣ１２４１と、サーバ１３０の副レコードＡ１３５１と副レコードＣ１３４１との主副レコードの配置が入れ替えられている。

これにより、サーバ１２０には、主レコードＡ１２５１に代えて、副レコードＡ１２５３が配置され、主レコードＣ１２４１に代えて、副レコードＣ１２４３が配置される。一方、サーバ１３０には、副レコードＡ１３５１に代えて、主レコードＡ１３５２が配置され、副レコードＣ１３４１に代えて、主レコードＣ１３４２が配置される。

この変更により、端末装置２１０は、活動情報の種類Ａの情報を、サーバ１３０の主レコードＡ１３５２に格納することとなる。また、副レコードＡ１１５１が配置されているサーバ１１０のサーバ間連携部１１１は、主レコードＡが配置されているサーバ１３０のサーバ間連携部１３１に主レコードＡ１３５２の情報を要求する。また、副レコードＡ１２５３が配置されているサーバ１２０のサーバ間連携部１２１は、主レコードＡが配置されているサーバ１３０のサーバ間連携部１３１に主レコード１３５２Ａの情報を要求する。

次に、サーバシステム１におけるサーバ群１００から解析結果を取得する際のデータフローについて説明する。

図５は、第１実施形態に係るサーバシステムにおける解析結果の取得におけるデータフローを説明する図である。

サーバ群１００（１１０，１２０，１３０）に格納されている解析結果を取得する場合には、端末装置２００は、取得対象の種類の解析結果を格納している主レコードから解析結果を取得する。具体的には、種類Ｃの解析結果については、端末装置２００の解析結果取得部２０１は、種類Ｃの主レコードである主レコードＣ１２４１が格納されているサーバ１２０を特定し、そのサーバ１２０の解析結果ＤＢ１２４の主レコードＣ１２４１から解析結果を取得する。一方、種類Ｄの解析結果については、端末装置２００の解析結果取得部２０１は、種類Ｄの主レコードである主レコードＤ１１４２が格納されているサーバ１１０を特定し、そのサーバ１１０の解析結果ＤＢ１１４の主レコードＤ１１４２から解析結果を取得する。

次に、サーバシステム１における活動情報解析装置３００による解析処理及び解析結果の格納におけるデータフローについて説明する。

図６は、第１実施形態に係る解析処理及び解析結果の格納におけるデータフローを説明する図である。サーバ群１００が図３に示す状態において、活動情報解析装置３００が活動情報をサーバ群１００の活動情報ＤＢから取得し、解析結果をサーバ群１００の解析結果ＤＢに格納する際のデータフローを示している。

活動情報解析装置３００の活動情報取得部３０４は、活動情報の各種類の情報を、それぞれの主レコードから取得して集約する。具体的には、活動情報取得部３０４は、種類Ａの情報については、サーバ１２０の活動情報ＤＢ１２５の主レコードＡ１２５１から取得し、種類Ｂについては、サーバ１１０の活動情報ＤＢ１１５の主レコードＢ１１５２から取得する。

インテリジェンス導出部３０３は、活動情報取得部３０４により集約された活動情報を用いて解析処理を行い、解析結果を情報形式変換部３０２に渡す。情報形式変換部３０２は、解析結果を解析結果ＤＢに格納可能なファイル形式にし、解析結果配信部３０１に渡す。解析結果配信部３０１は、解析結果の中の種類Ｃの情報については、サーバ１２０の解析結果ＤＢ１２４の主レコードＣ１２４１に格納し、種類Ｄの情報については、サーバ１１０の解析結果ＤＢ１１４の主レコードＤ１１４２に格納する。

なお、図６においては、活動情報解析装置３００及び活動情報解析装置３００の構成要素は、それぞれ１つずつとしているが、これに限定されるものではない。例えば、活動情報取得部３０４を複数用意し、活動情報の主レコードＣ１２４１の情報を読み出す活動情報取得部、活動情報の主レコードＤ１１４２の情報を読み出す活動情報取得部のように、各活動情報取得部が、異なる主レコードからデータを読み出すようにしてもよい。また、複数のインテリジェンス導出部３０３を用意し、それらによって活動情報を並列に解析して、解析結果を得てもよい。また、複数の解析結果配信部を用意し、解析結果の種類Ｃのデータを主レコードＣ１２４１に書き込む解析結果配信部、解析結果の種類Ｄのデータを主レコードＤ１１４２に書き込む解析結果配信部のように、各解析結果配信部が、異なる解析結果の主レコードにデータを書き込んでもよい。

次に、メタデータＤＢ１１６，１２６，１３６に格納されるメタデータ４００について説明する。

図７は、第１実施形態に係るメタデータを説明する図である。図７は、メタデータ４００として格納されているメタデータの種類と、図３に示す状態でのサーバ１１０におけるメタデータ４００の具体例と、メタデータの更新タイミングとを示す。

メタデータ４００としては、管理レコード４０１と、サーバ群のサーバ設定情報４０２と、関連レコードを保有するサーバの状況４０３と、関連レコードを保有するサーバの危険度指数４０４と、情報分割ルール４０５とがある。

管理レコード４０１は、サーバ群１００が管理している情報の種類及び種類ごとのレコード数のデータである。図７の例では、管理レコード４０１は、活動情報について、種類Ａ，種類Ｂのそれぞれのレコードが存在し、解析結果について、種類Ｃ、種類Ｄのそれぞれのレコードが存在することを示している。管理レコード４０１は、例えば、管理レコードを設定した場合に更新される。

サーバ群のサーバ設定情報４０２は、サーバ群１００を構成する各サーバについての設定情報である。サーバ群のサーバ設定情報４０２としては、例えば、サーバに配置されたレコードの内容と、サーバの設置位置を示す設置位置情報（例えば、その位置の緯度及び経度）等がある。図７の例では、サーバ群のサーバ設定情報４０２は、サーバ１１０は、レコードＡ、Ｂ、Ｃ、Ｄを保有し、設置位置は、緯度Ｘ、経度Ｙであり、サーバ１２０は、レコードＡ、Ｂ、Ｃ、Ｄを保有し、設置位置は、緯度Ｘ’、経度Ｙ’であり、サーバ１３０は、レコードＡ、Ｃを保有し、設置位置は、緯度Ｘ’’、経度Ｙ’’である。サーバ群のサーバ設定情報４０２は、設定情報に変更があった場合に更新される。

関連レコードを保有するサーバの状況４０３は、データデータ４００を格納しているサーバが保持するレコードと関連するレコード、すなわち、副レコードに対応する主レコード又は副レコードに対応する主レコードを、保有するサーバについての状況を示す情報である。関連レコードを保有するサーバの状況４０３は、例えば、サーバからの応答があるか否かの情報や、主レコードのデータを副レコードに複製した割合（複製率）等である。図７の例では、関連レコードを保有するサーバの状況４０３は、サーバ１２０から応答があり、サーバ１２０の副レコードの複製率が９５％であることを示している。関連レコードを保有するサーバの状況４０３は、例えば、定期的に更新される。

関連レコードを保有するサーバの危険度指数４０４は、関連するレコードを保有するサーバに関する危険度指数である。図７の例では、関連レコードを保有するサーバの危険度指数４０４は、サーバ１２０の危険度指数が０．８であることを示している。関連レコードを保有するサーバの危険度指数４０４は、例えば、定期的に更新される。

情報分割ルール４０５は、活動情報や、解析情報を分割するルールである。図７の例では、情報分割ルール４０５は、活動情報については、Ｌに関しては種類Ａとし、Ｍに関しては種類Ｂとし、解析結果については、Ｎに関しては種類Ｃとし、Ｏに関しては種類Ｄとして分割するとのルールとなっている。情報分割ルール４０５は、例えば、設定時のみ更新される。

メタデータ４００の中の各サーバで共通に管理すべきデータについては、各サーバのサーバ間連携部１１１，１２１，１３１によって、情報交換されている。

次に、サーバシステム１における処理動作について説明する。

まず、サーバ群１００のサーバに端末装置からシステムへの接続要請（システム接続要請）があった場合のシステム接続要請対応処理について説明する。

図８は、第１実施形態に係るシステム接続要請対応処理のフローチャートである。なお、以下の例では、サーバ１１０の処理として説明するが、他のサーバでも同様な処理が行われる。

サーバ１１０のサーバ間連携部１１１は、端末装置からシステム接続要請を受信すると（ステップ５０１）、メタデータ４００の情報分割ルール４０５を参照して、システム接続要請に対応する情報の種類を特定し、メタデータのサーバ群のサーバの設定情報４０２を参照して、特定した種類に関連するレコード（主レコード及び副レコード）を保有するサーバを特定し、特定したサーバの１つを対象として、主レコード又は副レコードのいずれを保有しているかを問い合わせる（ステップ５０２）。

問合せ先のサーバから応答を得た場合には、サーバ間連携部１１１は、主レコードを保有しているサーバであるか否かを確認し（ステップ５０３）、主レコードを保有していないサーバである場合（ステップ５０３：ＮＯ）には、処理をステップ５０２に進めて、他のサーバに対して問い合わせを行う。

一方、主レコードを保有しているサーバである場合（ステップ５０３：ＹＥＳ）には、サーバ間連携部１１１は、主レコードを保有するサーバのサーバＩＤを取得し（ステップ５０４）、システム接続要請の要請元の端末装置に対して、今後の接続先のサーバのサーバＩＤとして、取得したサーバＩＤを送信する（ステップ５０５）。

例えば、サーバ群１００の状態が図３に示す場合において、端末装置２００からサーバ１２０に対して端末装置２００の活動情報のデータを格納させるシステム接続要請があった場合には、端末装置２００の活動情報の種類は、種類Ｂであり、ステップ５０２では、種類Ｂのレコード（すなわち、レコードＢ）を保有するサーバ１１０，１２０が特定される。サーバ１１０に問合わせると、ステップ５０３でサーバ１１０のレコードが主レコードであるとの応答が得られるので、ステップ５０４で、サーバ間連携部１２１は、主レコードを保有するサーバ１１０のサーバＩＤを取得し、ステップ５０５で端末装置２００に今後のアクセス先が、取得したサーバＩＤのサーバ１１０であることを送信する。これにより、端末装置２００は、活動情報のデータの格納については、サーバ１１０にアクセスすることとなる。

なお、端末装置が新規に接続する場合に限らず、例えば、端末装置の活動情報を、その活動情報の種類を格納する主レコードを保持しないサーバに対して格納要請をした場合にもシステム接続要請対応処理同様な処理が行われて、主レコードを保持するサーバを端末装置に通知するようにしてもよい。

次に、サーバ群１００を構成する各サーバで実施されるルーティン処理について説明する。

図９は、第１実施形態に係るルーティン処理のフローチャートである。

ルーティン処理は、自他サーバの状態を確認する処理（ステップ５１０～５１２）と、主副レコードの配置を入れ替える処理（ステップ５１３）と、レコードの複製数の増加を検討する処理（ステップ５１４～５１８）とに大別される。

サーバのサーバ間連携部は、自サーバが保有する活動情報と解析結果とのレコードに対応するレコードを保有するサーバ（関連サーバ）に対して、稼働中であるか否かの問合せを行って応答状況を確認する（ステップ５１０）。次いで、サーバは、外部動態情報ＤＢ３１０から、自サーバ及び関連サーバの設置位置を含む範囲の動態情報を取得する（ステップ５１１）。次いで、サーバは、動態情報に基づいて、後述する方法により、各サーバの危険度を計算し、危険度を危険度動態ＤＢに格納する（ステップ５１２）。

次いで、サーバは、自サーバが保有するレコード毎に、主副レコード配置入替制御処理を実行する（ステップ５１３）。主副レコード配置入替制御処理には、副レコードを対象にする主副レコード配置制御処理(図１０参照)と、主レコードを対象にする主副レコード配置制御処理（図１１参照）とがある。

次いで、サーバは、複製数の足りないサーバがあるか否かを判定する(ステップ５１４)。この結果、複製数の足りないサーバがない場合(ステップ５１４：ＮＯ)には、サーバは、処理をステップ５１６に進める。一方、複製数の足りないサーバがある場合(ステップ５１４：ＹＥＳ)には、サーバは、サーバ群１００の各サーバに対して新規の副レコードの作成要請（新規副レコード作成要請）を行い(ステップ５１５)、処理をステップ５１６に進める。

ステップ５１６では、サーバは、他サーバから新規の副レコードの作成要請（新規副レコード作成要請）があったか否かを判定する（ステップ５１６）。ここで、ルーティン処理は、他のサーバでも、例えば、非同期で実施されているため、他のサーバで実施されたステップ５１５の新規副レコード作成要請を受ける可能性がある。そこで、ステップ５１６では、所定の期間だけ、他サーバからの新規副レコード作成要請を待つこととしている。所定の期間としては、例えば、１回のルーティン処理にかかる時間に基づいて、ある一定期間、例えば１回のルーティン処理にかかる時間の平均が１分であったら、３０秒間としてもよい。所定の期間は、上記に限られず、サーバシステム１のサーバ数や、レコード数や、サーバの性能等といったシステムの規模や性能によって任意の期間としてもよい。

次いで、他サーバから新規副レコード作成要請が無かった場合（ステップ５１６：ＮＯ）には、サーバは、処理をステップ５１０に進める一方、他サーバから新規副レコード作成要請があった場合（ステップ５１６：ＹＥＳ）には、自サーバにレコードを新規に作成する資格があるか否かを判断する（ステップ５１７）。具体的には、サーバは、危険度動態ＤＢからこれまでに計算された自サーバの危険度を取得し、この危険度から危険度指標を計算し、新規にレコードを作成する資格があるか否かを判断する。

この結果、自サーバに新規にレコードを作成する資格がないと判断した場合（ステップ５１７：ＮＯ）には、サーバは、処理をステップ５１０に進める。一方、自サーバに新規にレコードを作成する資格があると判断した場合（ステップ５１７：ＹＥＳ）には、サーバは、要請されたレコードを作成し、全サーバに対してレコードを作成したことを連絡し（ステップ５１８）、処理をステップ５１０に進める。

なお、ルーティン処理においては、便宜上ステップ５１０から開始するとして説明したが、ルーティン処理は、サーバが稼働している間に、常に実施される処理であるため、ステップ５１０から始めることに限定されず、自他サーバの状態を確認する処理（ステップ５１０～５１２）と、主副レコードの配置を入れ替える処理（ステップ５１３）と、レコードの複製数の増加を検討する処理（ステップ５１４～５１８）とのいずれかの最初のステップから処理を開始してもよい。

次に、ルーティン処理を、図３に示す状態のサーバシステム１において、サーバ１１０が実施する場合を例に具体的に説明する。

まず、サーバ１１０は、メタデータ４００を照会し、サーバ１１０が保有する活動情報のレコードＡ，Ｂと、解析結果のレコードＣ，Ｄのいずれかを保有するサーバ１２０とサーバ１３０とに対して、稼働中であるか否かの問い合わせを行う（ステップ５１０）。そして、サーバ１１０は、外部動態情報ＤＢ３１０から、自サーバ１１０の設置位置を含む範囲のデータと、関連サーバであるサーバ１２０，１３０の設置位置を含む範囲のデータを取得する（ステップ５１１）。次に、サーバ１１０は、ステップ５１１で取得したデータに基づいて、各サーバの危険度計算し、危険度動態ＤＢ１１３に計算結果を保存する（ステップ５１２）。

次に、サーバ１１０は、副レコードＡ１１５１、副レコードＣ１１４１、主レコードＢ１１５２、主レコードＤ１１４２に関して、それぞれ独立に主副レコード配置入替制御処理を実施する（ステップ５１３）。

主副レコード配置入替制御処理を実施後、サーバ１１０は、ステップ５１０で確認した、保有するレコードに関する副レコードを保有する他サーバの稼働数に基づいて、レコードの複製数の増加を検討する処理を実施する。例えば、サーバ１１０がステップ５１０で、サーバ１３０の稼働を確認できなかった場合には、活動情報のレコードＡと、解析結果のレコードＣに関するレコードの複製数（副レコードの数）が１つであると認識する。活動情報のレコードＡと、解析結果のレコードＣとのそれぞれに関するレコードの最低複製数が２であった場合には、ステップ５１４で複製数の足りないレコードが存在すると判断されるので、サーバ１１０は、サーバ群１００の全サーバに対して、活動情報のレコードＡと、解析結果のレコードＣに関する副レコードの新規作成を要請する（ステップ５１５）。

ステップ５１６では、他のサーバから副レコードの新規作成要請がなかった場合、１回分のルーティン処理を終えたことになり、処理をステップ５１０に進める。ステップ５１６で他サーバから新規副レコード作成要請があった場合、サーバ１１０は、危険度動態ＤＢ１１３のこれまでに計算されたサーバ１１０の危険度から、危険度指標を計算し、現時点でサーバ１１０が新規にレコードを増やす資格があるか否かを判断し、資格があれば、新規レコードを作成し、メタデータ４００を照会し、全サーバに、サーバ１１０が新規に副レコードを作成したことを伝え、処理をステップ５１０に進める。これにより、サーバ１１０に新たな副レコードが追加することができ、他のサーバに副レコードが追加されたことを把握させることができる。

次に、ステップ５１３における主副レコード配置制御処理の中の副レコードを対象にする主副レコード配置制御処理について説明する。

図１０は、第１実施形態に係る副レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。

サーバのサーバ適正度判定部は、危険度動態ＤＢにアクセスし、これまでに計算されたサーバの危険度から、現時点でのサーバの危険度指標を計算し、サーバが処理対象のレコード（対象レコードという）についての主レコードを保有する資格があるか否かを判断する（ステップ５２０）。この結果、主レコードを保有する資格がないと判断した場合（ステップ５２０：ＮＯ）には、サーバは処理を終了し、ルーティン処理のステップＳ５１４に処理を進める。

一方、主レコードを保有する資格があると判断した場合（ステップ５２０：ＹＥＳ）には、サーバは、危険度動態ＤＢにアクセスし、対象レコードの主レコードを保有するサーバ（保有サーバ）について、これまでに計算された保有サーバの危険度と、自サーバの危険度とを比較し、現時点において、自サーバと保有サーバとのどちらに主レコードを配置するのが相応しいかを比較し（ステップ５２１）、自サーバの副レコードと、保有サーバの主レコードとの配置を入れ替える必要があるか否かを判断する（ステップ５２２）。

この結果、自サーバの副レコードと、保有サーバの主レコードとの配置を入れ替える必要がないと判断した場合（ステップ５２２：ＮＯ）には、サーバは処理を終了する。一方、自サーバの副レコードと、保有サーバの主レコードとの配置を入れ替える必要があると判断した場合（ステップ５２２：ＹＥＳ）には、サーバは、保有サーバに、主副レコードを入れ替える要請（入替要請）を送信する（ステップ５２３）。

次いで、サーバは、所定の期間（例えば、１０秒）待って、保有サーバに入替要請が受理されたか否かを判定する（ステップ５２４）。ここで、所定の期間は、上記に限られず、サーバシステム１のサーバ数や、レコード数や、サーバの性能等といったシステムの規模や性能によって任意の期間としてもよい。この結果、入替要請が受理されていない場合（ステップ５２４：ＮＯ）には、処理を終了する。一方、入替要請が受理された場合（ステップ５２４：ＹＥＳ）には、サーバは、主副レコードの入替処理を実行し（ステップ５２５）、自サーバ及び保有サーバ以外の対象レコードを保有するサーバに対して、主副レコードの入れ替えを実施したことを通知し、処理を終了する。このように、主副レコードの配置を入れ替えた場合には、今後は、自サーバが主レコードを保有するサーバとして機能するようになる。

次に、副レコードを対象にする主副レコード配置制御処理について、図３に示す状態のサーバシステム１において、サーバ１３０が保有する活動情報の副レコードＡ１３５１を対象として実施する場合を例に具体的に説明する。

サーバ１３０は、危険度動態ＤＢ１３３にアクセスし、これまでに計算されたサーバ１３０の危険度から、現時点でのサーバ１３０の危険度指標を計算し、サーバ１３０が活動情報の種類Ａの情報についての主レコードを保有する資格があるか否かを判断する（ステップ５２０）。サーバ１３０が主レコードを保有する資格がないと判断した場合（ステップ５２０：ＮＯ）には、処理を終了し、サーバ１３０は、ルーティン処理のステップ５１４に処理を進める。一方、サーバ１３０が主レコードを保有する資格があると判断した場合（ステップ５２０：ＹＥＳ）、サーバ１３０は、危険度動態ＤＢ１３３にアクセスし、活動情報の種類Ａの情報についての主レコードを保有しているサーバ１２０について、これまでに計算されたサーバ１２０の危険度から、現時点において、サーバ１２０とサーバ１３０とのどちらが主レコードを保有するのが相応しいかを比較し（ステップ５２１）、判断する（ステップ５２２）。

ステップ５２２において、サーバ１２０の方が、サーバ１３０よりも主レコードを保有するに相応しく、主副レコードの配置の入替の必要性がない判断した場合（ステップ５２２：ＮＯ）には、処理を終了する。一方、ステップ５２２において、サーバ１２０よりもサーバ１３０の方が主レコードを保有するに相応しく、主副レコードの配置の入替の必要性があると判断した場合（ステップ５２２：ＹＥＳ）、サーバ１３０は、サーバ１２０に対して、主副レコード配置入替の要請を送信し、受理された場合（ステップ５２４：ＹＥＳ）には、主副レコードの入替を実施し（ステップ５２５）、サーバ１３０とサーバ１２０以外の活動情報の種類Ａのレコードを保有するサーバ、すなわち、サーバ１１０に対して、サーバ１３０とサーバ１２０との間で主副レコードの配置の入替を実施したことを伝える。これにより、サーバ１３０の活動情報の種類Ａの副レコードＡ１３５１は、図４に示すように、主レコードＡ１３５２として機能し、サーバ１２０の主レコードＡ１２５１は、図４に示すように副レコードＡ１２５３として機能するようになる。

次に、ステップ５１３における主副レコード配置制御処理の中の主レコードを対象にする主副レコード配置制御処理について説明する。

図１１は、第１実施形態に係る主レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。

サーバのサーバ適正度判定部は、危険度動態ＤＢにアクセスし、これまでに計算されたサーバの危険度から、現時点でのサーバの危険度指標を計算し、サーバがレコードついての主レコードを保有する資格があるか否かを判断する（ステップ５３０）。この結果、主レコードを保有する資格があると判断した場合（ステップ５３０：ＹＥＳ）には、主副レコードの配置の入替を行う必要がないので、サーバは処理を終了し、ルーティン処理のステップＳ５１４に処理を進める。

一方、主レコードを保有する資格がないと判断した場合（ステップ５３０：ＮＯ）には、所定の期間、例えば１０秒間において、処理対象の情報の副レコードを保有するサーバからの主副レコードの配置の入替の要請（主副レコード配置入替要請）を受け付ける（ステップ５３１）。ここで、所定の期間は、上記に限られず、サーバシステム１のサーバ数や、レコード数や、サーバの性能等といったシステムの規模や性能によって任意の期間としてもよい。

次いで、サーバは、主副レコード配置入替要請があったか否かを判定し（ステップ５３２）、この結果、主副レコード配置入替要請がなかった場合（ステップ５３２：ＮＯ）には、処理をステップ５３０に進める。

一方、主副レコード配置入替要請があった場合（ステップ５３２：ＹＥＳ）には、入替先を決定し、決定した入替先のサーバに対して入替要請受理を送信する（ステップ５３３）。サーバは、例えば、１つのサーバからのみ主副レコード配置入替要請を受け取った場合には、このサーバを入替先と決定する一方、複数のサーバから主福レコード入替要請を受け取った場合には、各サーバの危険度と、各サーバの副レコードの主レコードの情報についての複製率とに基づいて、入替先のサーバを決定する。

次いで、サーバは、入替先のサーバとの間で主副レコードの配置の入替処理を実施し（ステップ５３４）、処理を終了する。

次に、主レコードを対象にする主副レコード配置制御処理について、図３に示す状態のサーバシステム１において、サーバ１２０が保有する活動情報の主レコードＡ１２５１を対象として実施する場合を例に具体的に説明する。

サーバ１２０は、危険度動態ＤＢ１２３にアクセスし、これまでに計算されたサーバ１２０の危険度から、現時点においてサーバ１２０が主レコードを保有する資格があるか否かを判断する（ステップ５３０）。ステップ５３０で、主レコードを保有する資格があると判断された場合（ステップ５３０：ＹＥＳ）、サーバ１２０は、処理を終了し、ルーティン処理のステップ５１４に処理を進める。一方、ステップ５３０で、サーバ１２０が主レコードを保有する資格がないと判断された場合（ステップ５３０：ＮＯ）、所定の期間（例えば１０秒間）、活動情報の種類Ａの副レコード（副レコードＡ）を保有するサーバである、サーバ１１０とサーバ１３０とからの主副レコード配置入替要請を受け付ける（ステップ５３１）。

ステップ５３１で、サーバ１１０またはサーバ１３０の一方のみから主副レコード配置入替要請があった場合、例えばサーバ１３０のみから主副レコード配置入替要請があった場合、サーバ１３０に対して入替要請受理（ステップ５３３）を伝える。これにより、サーバ１３０では、ステップ５２４とステップ５２５の処理が実施され、サーバ１２０は、サーバ１３０との間で主副レコードの配置の入替を行う（ステップ５３４）。この結果、図３に示すシステムの状態は、図４に示す状態に遷移する。すなわち、サーバ１２０の活動情報の種類Ａの副レコードＡ１３５１は、図４に示すように、主レコード１３５２Ａとして機能し、サーバ１３０の副レコードＡ１２５１は、図４に示すように副レコードＡ１２５３として機能するようになる。

一方、サーバ１１０とサーバ１３０とからレコード入替要請があった場合、サーバ１２０は、危険度動態ＤＢ１２３にアクセスし、これまでに計算されたサーバ１１０とサーバ１３０との危険度を特定するとともに、サーバ１２０の持つメタデータから、副レコードＡ１１５１と、副レコードＡ１３５１についての主レコードＡ１２５１に対する複製率を特定し、危険度と複製率とを総合的に考慮し、いずれのサーバを入替先とするかを判断する。例えば、サーバ１１０の危険指数が０.８であり、副レコードＡ１１５１の複製率は８０％であり、サーバ１３０の危険指数が０.９であり、副レコードＡ１３５１の複製率が９９％であるとした場合に、比較するレコードの指標を、（レコード複製率）／（サーバの危険指数）とすると、サーバ１１０の副レコードＡ１１５１についての指標は、１００であり、サーバ１３０の副レコードＡ１３５１についての指標は、１１０となる。この場合には、サーバ１２０は、指標の値が大きいサーバ１３０の副レコードＡ１３５１の方が、主レコードとして適切であると判断して入替先として決定し（ステップ５３３）、サーバ１２０は、サーバ１３０に対して、主副レコード配置入替要請の受理を伝える。これにより、サーバ１３０では、ステップ５２４とステップ５２５の処理が実施され、図３に示すシステムの状態は、図４に示す状態に遷移する。

次に、主レコードに書き込まれたデータを副レコードに複製するレコード間の複製処理について説明する。

図１２は、第１実施形態に係るレコード間の複製処理のフローチャートである。

レコード間の複製処理は、副レコードを保有する各サーバが副レコード毎に実施する処理である。この処理は、例えば、副レコード毎に独立且つ並列に常時実施される。

まず、複製処理の複製先の副レコードを保有するサーバ（副レコード保有サーバ）は、副レコードに複製された最新のデータを確認し、最新のデータを、複製元の主レコードを保有するサーバ（主レコード保有サーバ）に送信する（ステップ５４０）。

主レコード保有サーバは、副レコード保有サーバから送信された副レコードでの最新のデータの内容に基づいて、主レコードに書き込まれたデータと副レコードのデータとの差分量を計算し、差分量を副レコード保有サーバに送信する（ステップ５４４）。

副レコード保有サーバは、副レコードと主レコードとの差分があるか否か、すなわち、主レコード保有サーバからの送信された差分量のデータの読み出しが完了したか否かを判定する（ステップ５４１）。この結果、差分量のデータの読み出しが完了していない場合（ステップ５４１：ＹＥＳ）には、副レコード保有サーバは、主レコード保有サーバから送られてきた差分量に基づいて、主レコードから１回のアクセスで読み出すデータ量を計算し、算出したデータ量のデータを主レコードから読み出す（ステップ５４２）。例えば、１回のアクセスで読み出すデータ量としては、システムのサーバ数やレコード数やサーバの性能等に基づいて決定してもよく、例えば、データの差分量が１０ＭＢである場合に、１回のアクセスで読み出すデータ量を１００ＫＢとしてもよい。

次いで、副レコード保有サーバは、主レコードから読み出したデータを副レコードに書き込み（ステップ５４３）、処理をステップ５４１に進める。以降は、副レコード保有サーバは、主レコード保有サーバから送られてきた差分量のデータを読み出すまでステップ５４１～５４３までの処理を繰り返し実行する。

一方、副レコードと主レコードとの差分がない場合、すなわち、副レコードと主レコードの差分がもともとなかった場合、又は差分量のデータを主レコードから読み出した場合（ステップ５４１：ＮＯ）には、副レコード保有サーバは、処理をステップ５４０に進める。

次に、レコード間の複製処理について、図３に示す状態のサーバ１１０の活動状態の種類Ａの副レコードＡ１１５１に対して、サーバ１２０の活動状態の種類Ａの主レコードＡ１２５１に書き込まれたデータを複製する場合を例に具体的に説明する。なお、このレコード間の複製処理は、サーバ１３０の活動状態の種類Ａの副レコードＡ１３５１に対して、サーバ１２０の活動状態の種類Ａの主レコードＡ１２５１に書き込まれたデータを複製する複製処理とは、独立且つ平行して実施される。

まず、サーバ１１０は、副レコードＡ１１５１に複製された最新のデータを確認し（ステップ５４０）、最新のデータをサーバ１２０に送信する（ステップ５４０）。サーバ１２０は、サーバ１１０から送られた副レコードＡ１１５１の最新のデータの内容と、主レコードＡ１２５１に書き込まれたデータの差分量を計算し、差分量をサーバ１１０に送信する（ステップ５４４）。

サーバ１１０は、サーバ１２０から送信された差分量に基づき、主レコードＡ１２５１から一度のアクセスで読み出すデータ量を計算し、これに従って、主レコードA１２５１記録されたデータを読み出し（ステップ５４２）、副レコードＡ１１５１に書き込む（ステップ５４３）。サーバ１１０は、サーバ１２から送信された差分量のデータを全て受信するまで、ステップ５４２及びステップ５４３の処理を実行する。サーバ１１０は、差分量のデータを全て受信した場合（ステップ５４１：ＮＯ）には、再びステップ５４０からの処理を実行する。

次に、ステップ５１１及び５１２で実行される外部動態情報ＤＢ３１０から取得したデータに基づいて、各サーバの設置地域におけるサーバが影響を受ける危険度を計算する方法について図１３Ａ～図１３Ｄを参照して説明する。

図１３Ａは、第１実施形態に係る停電区域データを説明する図である。図１３Ｂは、第１実施形態に係る河川氾濫区域データを説明する図である。図１３Ｃは、第１実施形態に係る危険度計算処理のフローチャートである。図１３Ｄは、第１実施形態に係る危険度計算結果を説明する図である。

まず、外部動態情報ＤＢ３１０に格納されたデータについて説明する。外部動態情報ＤＢ３１０には、図１３Ａに示す停電区域を示す停電区域データ６００が格納される。停電区域データ６００においては、停電区域を含む行政区画を示す、図中実線で示されたポリゴン６０１が含まれている、また、外部動態情報ＤＢ３１０には、図１３Ｂに示す河川氾濫区域データ６０３が格納されている。河川氾濫区域データ６０３には、河川氾濫が発生した区域を含む行政区画を示す、図中実線で示されたポリゴン６０４が含まれている。

次に、外部動態情報ＤＢ３１０に格納された停電区域データ６００及び河川氾濫区域データ６０３を利用した危険度計算処理の動作を、図１３Ｃを参照して説明する。

図１３Ｃに示す危険度計算処理は、各サーバ１１０，１２０，１３０のサーバ適正度判定部１１２，１２２，１３２のそれぞれによって独立して実行される。

サーバ適正度判定部は、メタデータを参照し、自分が属するサーバ（自サーバ）が保持するレコードに関連するレコードを保持するサーバ（関連サーバ）を特定し、関連サーバと、自サーバの設置位置周辺、すなわち設置位置を含むその周囲についての最新の停電区域データ６００と河川氾濫データ６０３とを外部動態情報ＤＢ３１０から取得する（ステップ５５０）。

次いで、サーバ適正度判定部は、外部動態情報ＤＢ３１０から取得した停電区域データ及び河川氾濫データについて、災害が発生した範囲（ここでは、停電区域及び河川氾濫区域）を示すポリゴンを囲む領域、例えば、緯度と経度とのそれぞれの軸に平行な辺で囲まれた矩形（長方形、又は正方形）を特定する（ステップ５５１）。例えば、サーバ適正度判定部は、停電区域データ６００について、図１３Ａに示す停電区域を示すポリゴン（ポリゴン６０１等）を囲む破線で表された矩形（矩形６０２等）を特定するとともに、河川氾濫データ６０３について、図１３Ｂに示す河川氾濫区域を示すポリゴン（ポリゴン６０４等）を囲む破線で表された矩形（矩形６０５等）を特定する。

次いで、サーバ適正度判定部は、停電区域データ６００と河川氾濫区域データ６０３に含まれる各ポリゴンを囲む全ての矩形について、その頂点の緯度と経度の値毎に、昇順または降順に並べた数列を作成し、緯度又は経度の数列中の各値に対して、前後の値の間隔が、必要な精度に対して狭すぎる場合には、その値と前後の値とを、前後の値の平均値に置き換える等して、数列の値の個数を減らして適切な値の数列に調整し、調整後の数列中の各値を格子の位置とするメッシュ（例えば、図１３Ｄで点線として示されるメッシュ）を作成する（ステップ５５２）。

次いで、サーバ適正度判定部は、作成したメッシュの各区画について、その区画が停電区域データ６００中のポリゴンの内側に含まれるか否か、及び、その区画が河川氾濫区域データ６０３中のポリゴンの内側に含まれるか否かに基づいて、各区画の危険度を計算する（ステップ５５３）。例えば、区画が停電区域データ６００中のポリゴンの内側に含まれる場合は、その区画の計算用危険度に０.８０を加算し、区画が河川氾濫区域データ６０３中のポリゴンの内側に含まれる場合は、その区画の計算用危険度に０.９０を加算し、各区画の計算用危険度に対して規格化処理を行う（ここでは、２つのデータを用いているため計算用危険度を２で除算する）ことにより得られた値を、その区画の危険度とする。例えば、対象となる区画が、停電区域データ６００中のポリゴンの内側に含まれるとともに、河川氾濫区域データ６０３中のポリゴンの内側に含まれる場合には、計算用危険度が０．８０＋０.９０＝１．７となり、最終的な危険度が０．８５となる。

ステップ５５３の処理により、各区画の危険度は、例えば、図１３Ｄに示すようになる。
図１３Ｄにおいては、危険度０．８５の区画を網掛け表示し、危険度がそれ以下の区画については、危険度を０とし、特に装飾表示していない。

次いで、サーバ適正度判定部は、サーバが保有するメタデータから関連サーバの位置を特定し、メッシュにおける関連サーバの設置位置が属する区画を同定し、その区画における危険度を、計算を実行した時刻におけるサーバの稼働に関する危険度として、危険度動態ＤＢに書き込む（ステップ５５４）。なお、ステップ５５０で過去の或る時点のデータを取得する場合には、その区画における危険度は、過去の或る時点におけるサーバの危険度としてもよい。

図１３Ｄにおける十字マーカ６０５，６０６，６０７は、各サーバの設置位置を示している。例えば、図１３Ｃに示す危険度計算処理が、例えば、所定の時点（例えば発災時点）から１２時間後に実施されたとし、サーバ１１０の設置位置が十字マーカ６０５で示され、サーバ１２０の設置位置が十字マーカ６０６で示され、サーバ１３０の設置位置が十字マーカ６０７で示されているとすると、発災後１２時間後においては、サーバ１１０の危険度は、０.００であり、サーバ１２０の危険度は０.８５であり、サーバ１３０の危険度は０.００として特定され、危険度動態ＤＢに書き込まれる。

次に、図１３Ｄの危険度計算処理によって計算された結果と、各レコードの複製率との利用方法の例について図１４Ａ、図１４Ｂ、及び図１４Ｃを参照して説明する。

図１４Ａは、第１実施形態に係る危険度変動を示す図である。図１４Ｂは、第１実施形態に係る複製率変動を示す図である。図１４Ｃは、第１実施形態に係る将来の予測も含む危険度変動を示す図である。

ステップ５１７（図９）、ステップ５２０（図１０）、ステップ５３０（図１１）において実施される処理は、例えば、発災から９６時間後である処理時点（現時点）までに各サーバの危険度動態ＤＢに書き込まれた図１４Ａに示す各サーバの危険度変動６１０と、図１４Ｂに示す各レコードの複製率変動６１５とに基づいて実施される。

ここでは、例えば、サーバシステム１の状態が図３に示す状態であるとする。さらに、図１０の副レコードを保持するサーバにおける主副レコード配置入替制御処理をサーバ１１０のサーバ適正度判定部１１２が実施し、図１１の主レコードを保持するサーバにおける主副レコード配置入替制御処理をサーバ１２０のサーバ適正度判定部１２２が実施するものとする。また、サーバ危険度変動６１０には、図１４Ａに示すように、サーバ１１０の危険度が、危険度変動６１１と平常危険度範囲６１４とに示す状態であり、サーバ１２０の危険度が、危険度変動６１２と平常危険度範囲６１５とに示す状態であり、サーバ１３０の危険度が、危険度変動６１３と平常危険度範囲６１６とに示す状態であることが含まれているものとする。なお、平常危険度範囲６１４、６１５、６１６は、平常であればその範囲に属すると想定される危険度の範囲である。また、レコード複製率変動６１７には、サーバ１１０の副レコードＡ１１５１の複製率が、レコード複製率変動６１８と平常複製率範囲６２０とに示す状態であり、サーバ１３０の副レコードＡ１３５１の複製率がレコード複製率変動６１９と平常複製率範囲６２１とに示す状態であることが含まれているものとする。なお、平常複製率範囲６２０、６２１とは、平常であれば、その範囲に属すると想定される複製率の範囲である。

サーバ１１０のサーバ適正度判定部１１２は、ステップ５２０において、サーバ１１０の情報である、危険度変動６１１と、平常危険度範囲６１４と、複製率変動６１９と、平常複製率範囲６２１とだけに着目してもよい。サーバ適正度判定部１１２は、発災から９６時間後の現時点における最新のサーバ１１０の危険度を、設定された閾値、例えば危険度０.７０を超えているか否かを判断し、危険度が閾値を超えていない場合は、平常危険度範囲６１４で示される発災後からのサーバ１１０の危険度の変動の不定性範囲が危険度０.２０付近であり、最新の危険度が危険度０.５０程度であることから、サーバ１１０の最新の相対的な危険度（危険度指標の一例）は０.３０程度であると計算し、例えば、設定された相対的な危険度の閾値が０.４０である場合、相対的な危険度が閾値を下回っているため、サーバ１１０は主レコードを保有する資格があると判断する。

そして、ステップ５２１では、サーバ適正度判定部１１２は、活動情報の種類Ａの主レコードＡを保有するサーバ１２０の最新の危険度（０．８０程度）と、サーバ１１０の最新の危険度（０.５０程度）との比較と、サーバ１２０の最新の相対的な危険度（０.７０程度）と、サーバ１１０の相対的な危険度（０.３０程度）との比較を行う。２つの比較の両方において、サーバ１１０よりもサーバ１２０の方が危険であると判断された場合には、ステップ５２２で、サーバ適正度判定部１１２は、入替の必要性があると判断してもよい。ステップ５２１とステップ５２２で実施される比較及び判断は、最新の危険度だけの比較や、相対的な危険度だけの比較や、両方の比較における差分を足し合わせた値の比較や、両方の比較における差分を掛け合わせた値の比較等によって判断してもよく、また、これらに制限されるものではない。

図１１の主レコードを保有するサーバにおける主副レコード配置入替制御処理におけるステップ５３０では、サーバ１２０のサーバ適正度判定部１２２は、サーバ適正度判定部１１２が実施するステップ５２０における危険度変動６１１に代えて、危険度変動６１２を用い、平常危険度範囲６１４に代えて平常危険度範囲６１５を用いて実行すればよい。この場合に、発災から９６時間後においてサーバ１２０の危険度は閾値である０.７０を上回っているため、サーバ適正度判定部１２２は、サーバ１２０は主レコードを保有する資格がないと判断して、処理をステップ５３１に進める。

ステップ５３１では、サーバ副レコードＡ１１５１を保有するサーバ１１０と、副レコードＡ１３５１を保有するサーバ１３０とから、入替要請を受信するので、ステップ５３３での入替先の決定の処理においては、サーバ適正度判定部１２２は、副レコードＡ１１５１を保有するサーバ１１０の危険度変動６１１及び平常危険度範囲６１４と、副レコードＡ１３５１を保有するサーバ１３０の危険度変動６１３及び平常危険度範囲６１６と、副レコードＡ１１５１の複製率変動６１８及び平常複製範囲６２０と、副レコードＡ１３５１の複製率変動６１９及び平常複製範囲６２１と、に基づいて判断する。

ステップ５３３における入替先の決定には、様々な評価パラメータによる比較があるが、例えば、入替要請を送信したサーバの保有するレコードの複製率を１００で規格化し、そのレコードを保有するサーバの危険度で割り、さらにそのサーバの危険度の平常危険度範囲からの相対的な危険度で割った値を、入替先決定の評価パラメータとしてもよい。

この場合、副レコードＡ１１５１の評価パラメータは、最新の複製率が９８％であり、サーバ１１０の危険度が０.５０であり、相対的な危険度が０.３０であるため、およそ６.５３となる。一方、副レコードＡ１３５１の評価パラメータは、最新の複製率が８８％であり、サーバ１３０の危険度が０.４０であり、相対的な危険度が０.０３であるため、およそ、７３．３となる。この結果、ステップ５３３では、評価パラメータの大きい、副レコードＡ１３５１を入替先として決定する。

なお、ステップ５３３における、入替先の判断は、判断時点までの情報だけではなく、例えば、図１４Ｃに示すように、危険度変動６２３を指数関数等の関数でフィッティングし、近似した危険度変数６２４を用いて、現時点から数時間後のサーバの危険度を推測し、推測した値を入替先の判断に用いてもよい。これにより、外部動態情報ＤＢ３１０から、サーバ設置位置周辺の停電の可能性や、サーバ設置位置周辺の河川氾濫の可能性が高いといった情報を受け取る前に、危険の予測に従って、主副レコード配置入替を実施することができる。

また、上記したステップ５３３では、副レコードからの入替要請を受信する時間として所定の期間を設け、その期間中に受信した全てを平等に扱い、サーバの危険度と、レコードの複製率とに基づいて入替先を決定している。しかしながら、副レコードを保有するサーバが入替要請を送信するためには、図１０に示すように、副レコードを保有するサーバの危険度が設定された危険度を下回っており（ステップ５２０）、かつ主レコードを保有するサーバよりも、主レコードを保有するサーバとして適正である（ステップ５２１）という条件を、送信の時点で既に満たしているため、入替要請を送信したどのサーバであっても主レコードを保有してもよいという考えに基づいて、主副レコード配置入替を行うサーバを決定してもよい。この場合は、ステップ５３１において、入替要請に一定期間設けず、１つの副レコードを保有するサーバから入替要請を受け取った時点で、そのサーバの副レコードを入替先として決定し、処理をステップ５３４に進めてもよい。

また、ステップ５１７における処理については、上記したステップ５２０とステップ５３０における処理と同様な処理である。例えば、サーバ１１０がステップ５１７で実施する処理は、ステップ５２０とステップ５３０との処理と同じである。

次に、活動情報解析装置３００における活動情報の解析の例について説明する。

まず、端末装置からサーバ群１００に格納される活動情報の一例について説明する。

図１５は、第１実施形態に係るライフラインの状況を示すデータの一例を説明する図である。図１５は、活動情報の一例としての病院におけるライフラインの状況の情報を示している。

病院におけるライフラインの状況の情報は、電気使用状況、水使用状況、配管損傷有無、食糧供給状況等のパラメータを含む。電気使用状況には、「停電中」、「発電機使用中」、「正常」との３段階がある。水使用状況には、「枯渇」、「貯水・給水対応」、「井戸水使用中」、「正常」の４段階がある。配管損傷有無には、「損傷有」、「正常」の２段階がある。食料供給状況には、「枯渇」、「供給の見込み無し」、「備蓄で対応」、「正常」の４段階がある。

端末装置は、管理している各病院について、電気使用状況は「停電中」、水使用状況は「枯渇」、配管損傷有無は「損傷有」、食料供給状況は「備蓄で対応」のように、４つの各パラメータとその状況を含むデータをサーバ群の主レコードに格納する。

本実施形態では、各パラメータを統一的に扱い、各病院のライフライン状況を１つの数値で表すために、活動情報解析装置３００（より詳細には、インテリジェンス導出部３０３）では、図１５に示すように、各パラメータの状況に対して、ライフラインへの対応の緊急性が高いほど数値が高くなるようなライフライン異常指数に従って数値化し、４つのパラメータのライフライン異常指数を足し合わせた数値を病院のライフライン異常指数として解析に用いている。例えば、或る病院について、電気使用状況は「停電中」、水使用状況は「枯渇」、配管損傷有無は「損傷有」、食料供給状況は「備蓄で対応」という内容のデータであれば、この病院のライフライン異常指数は１０であると数値化する。

次に、図３に示すサーバシステム１の状態において、各端末装置が、それぞれが担当する病院の電気使用状況と水使用状況と配管損傷有無と食糧供給状況とを含むライフライン状況を示すデータ（ライフライン状況データ）を、サーバ群１００に配信して格納する場合を例に、活動情報解析装置３００による解析処理について説明する。なお、端末装置２００が病院Ａ及び病院Ｂについてのライフライン状況データを配信し、端末装置２１０が病院Ｃについてライフライン状況データを配信するものとする。

端末装置２００は、病院Ａ及び病院Ｂについてのライフライン状況データを、サーバ１１０の主レコードＢ１１５２に格納し、端末装置２１０は、病院Ｃについてのライフライン状況データをサーバ１２０の主レコードＡ１２５１に格納する。

活動情報解析装置３００の活動情報取得部３０４は、病院Ａ、Ｂについてのライフライン状況データをサーバ１１０の主レコードＢ１１５２から取得できる。ライフライン状況データとしては、現時点（この例では、発災から９６時間後）の病院Ａ、Ｂのライフライン状況データだけではなく、発災から９６時間までの間における病院Ａ、Ｂのライフライン状況データを取得できる。また、活動情報取得部３０４は、病院Ｃについてのライフライン状況データをサーバ１２０の主レコードＡ１２５１から取得できる。ライフライン状況データとしては、現時点（この例では、発災から９６時間後）の病院Ｃのライフライン状況データだけではなく、発災から９６時間までの間における病院Ｃのライフライン状況データを取得できる。

インテリジェンス導出部３０３は、このように活動情報取得部３０４が取得できる病院Ａ、Ｂ、Ｃのライフライン状況データの時間変動を解析し、その結果から例えば、現時点での災害対応活動を実施するユーザが対応すべき病院を提案することができる。

次に、病院Ａ、Ｂ、Ｃについてのライフライン状況データをインテリジェンス導出部３０３が解析した解析結果である医療施設解析結果６３０に含まれるライフライン異常指数の変動について説明する。

図１６は、第１実施形態に係るライフライン異常指数変動を示す図である。図１６において、医療施設解析結果６３０における変動６３１は、病院Ａのライフライン異常指数の変動を示し、変動６３２は、病院Ｂのライフライン異常指数の変動を示し、変動６３３は、病院Ｃのライフライン異常指数の変動を示す。

インテリジェンス導出部３０３が解析した時点（現時点：発災から９６時間後）においては、ライフライン異常指数が最大となっている病院は、病院Ｃである。病院Ｃは、発災から７２時間後からライフライン異常指数が大きくなっているのに対して、病院Ａは発災直後から長期に渡ってライフライン異常指数が大きいため、現時点では、病院Ａの方が病院Ｃよりも災害対応活動を実施する組織による救援の緊急度が高いことがわかる。また、病院Ｂは、発災直後はライフライン異常指数が大きいが、発災２４時間後から発災４８時間後の間に、ライフライン異常指数が小さくなっており、現時点においては、救援の緊急度が低いことがわかる。以上のことから、インテリジェンス導出部３０３は、現時点において、病院Ａ、Ｂ、Ｃに対して、救援の優先度が高い、病院Ａ、Ｃ、Ｂの順に優先度をつけ、この優先度の結果を解析結果としてサーバ群１００の解析結果ＤＢの主レコードに書き込む。端末装置は、この解析結果をサーバ群１００の解析結果ＤＢの主レコードから取得し、今後の災害対応活動の方針を決定する材料とすることができる。

次に、端末装置に表示される操作画面について説明する。

図１７は、第１実施形態に係る端末装置に表示される操作画面の一例を示す図である。

端末装置に表示される操作画面７２０は、活動情報配信方法選択領域７２１と、解析結果取得方法選択領域７２３と、アラート表示領域７２５と、解析結果表示領域７２６とを含む。

活動情報配信方法選択領域７２１は、サーバ群１００への活動情報配信方法を選択するための領域である。活動情報配信方法選択領域７２１では、活動情報を自動で配信することを指示する自動配信と、ユーザが手動で（配信ボタン７２２を押すことにより）活動情報を配信することを指示する手動配信とを選択することができる。例えば、数秒に数十棟の医療施設のライフライン状況が集約されるように、高い頻度で情報が集約されるような災害対応活動を実施するユーザである場合、手動によって情報の配信を随時実施することは困難であるため、活動情報配信方法選択領域７２１で自動配信を選択することで、端末装置に集約された医療施設のライフライン状況を自動でサーバ群１００に配信することができる。一方、数時間に数棟の医療施設のライフライン状況が集約されるように、低い頻度で情報が集約されるような災害対応活動を実施するユーザである場合、活動情報配信方法選択領域７２１で手動配信を選択し、必要に応じて配信ボタン７２２を押すことで、ライフライン状況をサーバ群１００に配信することができる。この場合には、端末装置における無駄な処理や、端末装置とサーバ群１００との無駄な通信を減らすことができる。

解析結果取得方法選択領域７２３は、サーバ群１００からの解析結果の取得方法を選択するための領域である。解析結果取得方法選択領域７２３では、解析結果を自動で更新することを指示する自動更新と、ユーザが手動で（更新ボタン７２４を押すことにより）解析結果を更新することを指示する手動更新とを選択することができる。例えば、人命に直結する等の緊急性の高い災害対応活動を実施するユーザの場合は、最新の他ユーザの活動状況等を常に把握することの重要度が高いため、解析結果取得方法選択領域７２３で自動更新を選択することで、最新の他ユーザの活動状況等を把握することができる。一方、人員等が不足しているユーザ等の場合は、最新の状況が常に更新されても対応が間に合わないことが予想されるため、解析結果取得方法選択領域７２３で手動更新を選択し、必要に応じて更新ボタン７２３を押すことで、人員規模に適した災害対応活動を実施することができる。

このように、活動情報配信方法選択領域７２１と解析結果取得方法選択領域７２３とに対して設定等を行うことにより、各端末装置を操作するユーザは、実施する災害対応活動に適した設定を適切に選択することができる。

アラート表示領域７２５は、緊急性の高い解析結果が表示される領域である。アラート表示領域７２５は、例えば、活動情報解析装置３００が緊急性の高い解析結果、例えば、数百名の重症患者の治療している病院Ｄで停電が生じたために治療の継続が困難となるといったような結果を得た場合に、その解析結果の情報が表示される。これにより、解析結果取得方法選択領域７２３で手動更新を選択しているユーザであっても緊急度の高い情報については適切に把握することができる。

解析結果表示領域７２６は、活動情報解析装置３００による解析結果の詳細を表示する領域であり、解析結果選択領域７２７と、地図選択領域７２８と、地図表示領域７３０と、局所変動表示領域７２９とを含む。

解析結果選択領域７２７は、表示させる解析結果を選択する領域であり、例えば、解析結果の情報の種類の一覧が表示され、その中から表示が必要な情報を選択することができる。この形跡結果選択領域７２７での選択結果に応じて、地図選択領域７２８と、地図表示領域７３０と、局所変動表示領域７２９に表示される解析結果が切り替えられる。

地図選択領域７２８は、表示される地図の種別を選択する領域である。地図選択領域７２８で選択された種別の地図が地図表示領域に表示される。地図表示領域７３０は、解析結果選択領域７２７及び地図選択領域７２８での選択内容に対応する地図を表示する領域である。局所変動表示領域７２９は、地図表示領域７３０の地図上の選択された領域での所定の情報の変動を表示する。

例えば、図１７の解析結果表示領域７２６では、解析結果選択領域７２７で医療活動が選択され、表示地図選択領域７２８でライフライン異常指数分布が選択された例を示しており、地図表示部７３０には地域毎のライフライン異常指数を示す２次元ヒストグラムが表示され、局所変動表示領域７２９は、地図表示部７３０の地図中で選択された地域におけるライフライン異常指数の時間変動を示すグラフが表示される。この解析結果表示領域７２６によると、ユーザは地図表示領域７３０に表示される地図によって、広い地域のライフラインの状況を把握することができ、局所変動表示領域７２９に表示されるグラフによって、選択した地域の発災直後からのライフラインの状況の変化を把握することができる。

次に、サーバに表示される操作画面について説明する。

図１８は、第１実施形態に係るサーバにおける操作画面の一例を示す図である。

サーバ群１００を構成する各サーバに表示される操作画面７３１は、活動情報タブ７３２と、解析結果タブ７３３とを含む。活動情報タブ７３２を選択することで、活動情報のレコード設定を操作するための表示領域が表示され、解析結果タブ７３３を選択することで、解析結果のレコード設定を操作するための表示領域が表示される。

活動情報タブ７３２を選択すると、主レコード設定表示領域７３４と、副レコード設定表示領域７３８と、サーバ設置位置表示領域７４１と、レコード作成方法選択領域７４２と、新規レコード作成承認領域７４３とが表示される。

主レコード設定表示領域７３４は、レコード入替承認方法選択領域７３５と、副レコード状態表示領域７３６とを含む。レコード入替承認方法選択領域７３５は、保有する主レコードについて主副レコード配置入替要請に対する承認を自動でするのか、手動でするのかを設定する領域である。例えば、レコード入替承認方法選択領域７３５において、手動承認のチェックボックスを選択することで、図１１に示す処理における主副レコード配置入替要請に対する承認を手動で実施することができる。レコード入替承認方法選択領域７５３で手動承認を選択している場合、副レコードを持つサーバのＩＤと、複製率と、危険度と、入替要請の有無と、承認のためのチェックボックスとを含むレコード入替承認領域７３７が副レコード状態表示領域７３６に表示される。レコード入替承認領域７３７の承認のチェックボックスが選択されると、対応するサーバからの入替要請が承認される。

副レコード設定表示領域７３８は、レコード入替要請方法選択領域７３９と、主レコード状態表示領域７４０とを含む。レコード入替要請方法選択部７３９は、保有する副レコードについて主副レコード配置入替要請を自動でするのか、手動でするのかを設定する領域である。例えば、レコード入替要請方法選択領域７３９で手動承認のチェックボックスを選択することで、図１０に示す処理における主副レコード配置入替要請を手動で実施することができる。レコード入替要請方法選択領域７３９で、手動承認を選択している場合、主レコードのレコードＩＤと、主レコードを保有するサーバのＩＤと、危険度と、入替要請のチェックボックスとを含む主レコード状態表示領域７４０が表示される。例えば、レコードＣの主レコードを保有するサーバ「２」に入替要請を送信する場合は、主レコード状態表示領域７４０に表示される対応するレコードＩＤのチェックボックスを選択することで、サーバに対してレコードの入替要請を送信することができる。

サーバ設置位置表示領域７４１には、レコードを保有するサーバの設置位置を表すオブジェクト（例えば、十字のマーカ）と、例えば、図１３Ｃの危険度計算方法によって計算した危険度が閾値を超えたポリゴンの区画を表す網掛けの領域とが表示される。サーバ設置位置表示領域７４１の内容によって、サーバの管理者は、レコードを保有するサーバの状態を把握することができる。

レコード作成方法選択領域７４２は、レコードを自動で作成するのか、手動で作成するのかを設定する領域である。例えば、レコード作成方法選択領域７４２で、手動作成のチェックボックスを選択することで、サーバの管理者は、図９のステップ５１６の処理を手動で実施することができる。レコード作成方法選択領域７４２で手動作成が選択されている場合には、新規のレコード作成要請があると、新規レコード作成承認領域７４３に作成要請があったレコードの一覧が表示される。サーバの管理者は、新規レコード作成承認領域７４３において、或るレコードの新規作成要請を承認する場合、そのレコードに対応するチェックボックスを選択することでレコードの新規作成の要請を承認することができる。

次に、第２実施形態に係るサーバシステムについて説明する。なお、第２実施形態に係るサーバシステムは、第１実施形態に係るサーバシステムにおける一部の構成の機能が異なるだけであるので、便宜的に、第１実施形態に係るサーバシステムの各部の符号を用いて、異なる点について説明する。

図１９Ａは、第２実施形態に係るサーバのサーバ適正度判定部の処理を説明する図である。

サーバ適正度判定部１１２，１２２，１３２は、図１０及び図１１で示す処理におけるサーバが主レコードを保有する資格があるかを判断する処理と、図９のステップ５１７において自サーバにレコードを新規に作成する資格があるか否かを判断する処理（これら処理を、本実施形態においては、判断処理ということとする）において、図１９Ａに示すように、活動情報解析装置３００によりサーバ群１００の解析結果ＤＢに格納されている解析結果を取得し、この解析結果を加味するようにしている。

ここで、サーバ１１０のサーバ適正度判定部１１２による処理を例に説明する。なお、解析結果ＤＢ１１４の主レコードＤ１１４２及び解析結果ＤＢ１２４の主レコードＣ１２４１には、図１６に示す医療施設解析結果６３０の情報が分割されて格納されているものとする。

サーバ適正度判定部１１２は、危険度動態ＤＢ１１３から図１４Ａに示す各サーバの危険度を取得するとともに、主レコードＤ１１４２と、主レコードＣ１２４１とから医療施設解析結果６３０を取得し、各サーバの危険度と医療施設解析結果６３０とを組み合わせて判断処理を行う。これにより、確度の高い判断を下すことができる。

ここで、医療施設解析結果６３０の利用方法の一例について説明する。

図１９Ｂは、第２実施形態に係る危険度変動とライフライン異常指数変動とを示す図である。

ライフライン異常指数は、図１５及び図１６に示すように、０から１２の範囲の値である。一方、危険度指数は０から１の範囲の値であるため、ライフライン異常指数の値に、スケーリング因子１／１２をかけることにより、病院（図１９Ｂでは、病院Ｂ）の補正後ライフライン異常指数変動６３３－２を作成する。例えば、病院Ｂとサーバ１２０との距離が１ｋｍ以内にあるならば、病院Ｂ周辺とサーバ１２０の設置位置周辺との災害による被害状況は似通っていると考えられるため、サーバ１２０の危険度に対して、補正後ライフライン異常指数を乗算した値をサーバ１２０の危険度因子として、判断処理で利用する。これにより、より確度の高い判断を下すことができる。

次に、第３実施形態に係るサーバシステムについて説明する。なお、第３実施形態に係るサーバシステムは、第１実施形態に係るサーバシステムにおける一部の構成の機能が異なるだけであるので、便宜的に、第１実施形態に係るサーバシステムの各部の符号を用いて、異なる点について説明する。

第３実施形態に係るサーバシステムのサーバにおいては、自サーバが保有するレコード毎に、主副レコード配置入替制御処理を実行するステップ５１３において、主レコードを対象にする主副レコード配置制御処理として、図２０Ａに示す処理を実行し、副レコードを対象にする主副レコード配置制御処理として、図２０Ｂに示す処理を実行する。

まず、主レコードが配置されたサーバによる主副レコード配置入替制御処理について説明する。

図２０Ａは、第３実施形態に係る主レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。

サーバのサーバ適正度判定部は、ステップ５２０と同様の処理によって、主レコードを保有する資格があるか否かを判断する（ステップ５５０）。この結果、主レコードを保有する資格があると判断した場合（ステップ５５０：ＹＥＳ）には、サーバは処理を終了し、ルーティン処理のステップＳ５１４に処理を進める。

一方、主レコードを保有する資格がないと判断した場合（ステップ５５０：ＮＯ）には、サーバは、危険度動態ＤＢにアクセスし、主レコード対応する副レコードを保有する１以上のサーバ（保有サーバ）について、これまでに計算された保有サーバの危険度に基づく指標を算出して比較し（ステップ５５１）、主レコードを配置するのに適正なサーバがあるか否かを判定する（ステップ５５２）。

この結果、適正なサーバがないと判断した場合（ステップ５５２：ＮＯ）には、サーバは、処理をステップ５５０に進める。一方、適正なサーバがあると判断した場合（ステップ５５２：ＹＥＳ）には、サーバは、適正なサーバに、主副レコードを入れ替える要請（入替要請）を送信する（ステップ５５３）。なお、適正なサーバが複数ある場合には、サーバは、複数のサーバに対して入替要請を送信してもよい。

次いで、サーバは、所定の期間（例えば、１０秒）待って、保有サーバに入替要請が受理されたか否かを判定する（ステップ５５４）。ここで、所定の期間は、上記に限られず、サーバシステム１のサーバ数や、レコード数や、サーバの性能等といったシステムの規模や性能によって任意の期間としてもよい。この結果、入替要請が受理されていない場合（ステップ５５４：ＮＯ）には、処理をステップ５５１に進める。一方、入替要請が受理された場合（ステップ５５４：ＹＥＳ）には、サーバは、主副レコードの入替処理を実行し（ステップ５５５）、自サーバ及びレコード配置の入れ替えを行ったサーバ以外の対象レコードを保有するサーバに対して、主副レコードの入れ替えを実施したことを通知し、処理を終了する。なお、ステップ５５４で、複数のサーバからの要請受理を受け取った場合には、ステップ５５１で実施した指標の比較や、受理した順番等の条件から入れ替えを実施する副レコードを選択すればよい。

次に、主レコードを対象にする主副レコード配置制御処理について、図３に示す状態のサーバシステム１において、サーバ１１０が保有する活動情報の主レコードＢ１１５２を対象として実施する場合を例に具体的に説明する。

サーバ１１０のサーバ適正度判定部１１２は、自サーバが主レコードを保有する資格があるか否かを判断し（ステップ５５０）、保有する資格がないと判断した場合（ステップ５５０：ＮＯ）、ステップ５２１と同様の処理により、サーバ１２０の指標を計算する。計算した指標が主レコードを保有するのに適正である判断した場合（ステップ５５２：ＹＥＳ）、サーバ適正度判定部１１２は、サーバ１２０のサーバ間連携部１２１に対して、主副レコード配置入替要請を送る（ステップ５５３）。この結果、サーバ１２０によって、入替要請が受理された場合（ステップ５５４：ＹＥＳ）、サーバ１１０は、正副レコードの入替処理を実施する（ステップ５５５）。

次に、副レコードが配置されたサーバによる主副レコード配置入替制御処理について説明する。

図２０Ｂは、第３実施形態に係る副レコードが配置されたサーバによる主副レコード配置入替制御処理のフローチャートである。

サーバのサーバ適正度判定部は、ステップ５５０と同様の処理によって、主レコードを保有する資格があるか否かを判断する（ステップ５６０）。この結果、主レコードを保有する資格がないと判断した場合（ステップ５６０：ＮＯ）には、サーバは処理を終了し、ルーティン処理のステップＳ５１４に処理を進める。

一方、主レコードを保有する資格があると判断した場合（ステップ５６０：ＹＥＳ）には、所定の期間、例えば１０秒間において、処理対象の情報の主レコードを保有するサーバからの主副レコードの配置の入れ替えの要請（主副レコード配置入替要請）を受け付ける（ステップ５６１）。

次いで、サーバは、主副レコード配置入替要請があったか否かを判定し（ステップ５６２）、この結果、主副レコード配置入替要請がなかった場合（ステップ５６２：ＮＯ）には、処理を終了する。

一方、主副レコード配置入替要請があった場合（ステップ５６２：ＹＥＳ）には、主福レコード入替要請を行ったサーバに対して入替要請受理を送信し、主福レコードの入替処理を実行し（ステップ５６３）、処理を終了する。

なお、主レコードのサーバと、副レコードのサーバとは、ステップ５５０、５５１、５６０の処理を外部動態情報ＤＢ３１０から取得した情報に基づいて行っているため、主レコードのサーバがステップ５５１，５５２で副レコードを保有するサーバが主レコードを保有する資格があると判断した場合において、副レコードを保持するサーバにおいて、ステップ５６０で主レコードを保有する資格がないと相反する判断を行うことは、基本的には起こり得ない。しかしながら、ステップ５５１とステップ５５２での指標の閾値が、ステップ５６０での閾値と異なっている場合や、ステップ５５３とステップ５６１との実行タイミングがずれてしまっている場合や、サーバがメンテナンスをしながら稼働していて通常の状態でない場合等には、相反する判断がされてしまう虞がある。そこで、本実施形態では、ステップ５６１での一定期間にのみ入替要請を受け付けるようにすることにより、相反する判断がされることを回避することができ、サーバシステムを安定して運用することができる。

なお、本発明は、上述の実施形態に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

また、上記実施形態において、プロセッサが行っていた処理の一部又は全部を、ハードウェア回路で行うようにしてもよい。また、上記実施形態におけるプログラムは、プログラムソースからインストールされてよい。プログラムソースは、プログラム配布サーバ又は記憶メディア（例えば可搬型の記憶メディア）であってもよい。

１…サーバシステム、５０…ネットワーク、１００…サーバ群、１１０，１２０，１３０…サーバ、１１１，１２１，１３１…サーバ間連携部、１１２，１２２，１３２…サーバ適正度判定部、２００，２１０，２２０…端末装置、３００…活動情報解析装置、３１０…外部動態情報ＤＢ

Claims (11)

1. 複数のサーバを備え、災害障害対応組織の活動に関する情報が複数に分割された各部分情報を格納し、前記部分情報のアクセスを受け付ける役割を担う記憶領域である複数の主レコードを異なるサーバに配置するとともに、前記主レコードに格納される各部分情報の複製を格納する役割を担う記憶領域である副レコードを、前記部分情報の主レコードが配置されるサーバと異なるサーバに配置するサーバシステムにおけるサーバであって、
   前記サーバには、前記部分情報の主レコード又は副レコードが配置されており、
   前記サーバは、
   自サーバの設置地域、又は自サーバに配置されている主レコード又は副レコードに対応する副レコード又は主レコードが配置されている他のサーバの設置地域における災害の状況に関する災害状況情報を取得し、前記災害状況情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する判定部と、
   配置を入れ替えると判定した場合に、他のサーバに主レコードと副レコードとの配置の入れ替えの要請を送信する入替要請部と、を備える
   サーバ。
2. 前記判定部は、前記災害状況情報に基づいて前記自サーバ又は前記他のサーバが影響を受ける危険度を示す危険度情報を特定し、前記危険度情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する
   請求項１に記載のサーバ。
3. 前記判定部は、前記災害状況情報を逐次取得し、前記災害状況情報に基づいて、前記自サーバ又は前記他のサーバが将来の時点における影響を受ける危険度を示す危険度情報を特定し、将来の時点における危険度情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する
   請求項２に記載のサーバ。
4. 前記判定部は、所定の時点から判定を行う時点までの災害状況情報に基づいて、前記自サーバ又は前記他のサーバが影響を受ける危険度を示す危険度情報を特定する
   請求項２に記載のサーバ。
5. 前記サーバには、主レコードが配置されており、
   前記主レコードに対応する副レコードが配置された複数の他のサーバから入れ替えの要請を受信した場合に、複数の他のサーバの危険度情報と、前記複数の他のサーバの副レコードへの主レコードの部分情報の複製率とに基づいて、入替要請を受理する他のサーバを決定する受理決定部をさらに有する
   請求項１に記載のサーバ。
6. 前記サーバは、
   各部分情報の主レコードが配置されているサーバの情報を記憶し、
   端末装置から部分情報へのアクセスを要求するアクセス要求を受け取ると、前記部分情報の主レコードが配置されているサーバを特定し、前記サーバの情報を前記端末装置に通知するアクセス管理部をさらに有する
   請求項１に記載のサーバ。
7. 前記災害状況情報は、発生している災害の自然現象に関する情報と、前記災害により影響を受けている対象に関する情報との少なくとも一方の情報を含む
   請求項１に記載のサーバ。
8. 複数のサーバを備え、災害障害対応組織の活動に関する情報が複数に分割された各部分情報を格納し、アクセスを受け付ける役割を担う記憶領域である複数の主レコードを異なるサーバに配置するとともに、前記主レコードに格納される各部分情報の複製を格納する役割を担う記憶領域である副レコードを、前記部分情報の主レコードが配置されるサーバと異なるサーバに配置するサーバシステムであって、
   前記サーバには、前記部分情報の主レコード又は副レコードが配置されており、
   前記サーバは、
   自サーバの設置位置、又は自身に配置されている主レコード又は副レコードに対応する副レコード又は主レコードが配置されている他のサーバの設置位置における災害の状況に関する災害状況情報を取得し、前記災害状況情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する判定部と、
   配置を入れ替えると判定した場合に、他のサーバに主レコードと副レコードとの配置入れ替えの要請を送信する入替要請部とを備える、
   サーバシステム。
9. 前記サーバには、前記部分情報の副レコードが配置されており、
   前記判定部は、副レコードに対応する主レコードが配置されている前記他のサーバが影響を受ける危険度を示す危険度情報を特定し、前記危険度情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する
   請求項８に記載のサーバシステム。
10. 前記サーバには、前記部分情報の主レコードが配置されており、
    前記判定部は、前記災害状況情報に基づいて前記自サーバが影響を受ける危険度を示す危険度情報を特定し、前記危険度情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を入れ替えるか否かを判定する
    請求項８に記載のサーバシステム。
11. 複数のサーバを備え、災害障害対応組織の活動に関する情報が複数に分割された各部分情報を格納し、前記部分情報のアクセスを受け付ける役割を担う記憶領域である複数の主レコードを異なるサーバに配置するとともに、前記主レコードに格納される各部分情報の複製を格納する役割を担う記憶領域である副レコードを、前記部分情報の主レコードが配置されるサーバと異なるサーバに配置するサーバシステムにおけるサーバによるサーバ管理方法であって、
    前記サーバには、前記部分情報の主レコード又は副レコードが配置されており、
    前記サーバは、
    自サーバの設置位置、又は自サーバに配置されている主レコード又は副レコードに対応する副レコード又は主レコードが配置されている他のサーバの設置地域における災害についての危険度情報を取得し、前記危険度情報に基づいて、前記自サーバと前記他のサーバとの主レコードと副レコードとの配置を変更するか否かを判定し、
    変更すると判定した場合に、他のサーバに主レコードと副レコードとの配置変更の要求を通知する
    サーバ管理方法。