(57)【要約】【課題】  通信障害等でも最低限の機能を維持可能な情報処理システムを提供する。【解決手段】  複数の情報処理装置と、前記複数の情報処理装置を互いに通信可能に接続する通信ネットワークとを有する情報処理システムである。複数の情報処理装置で動作している複数のアプリケーションソフトウェアの種別を示す第１の識別情報と、前記アプリケーションソフトウェアが使用するデータの種別を示す第２の識別情報と、複数の情報処理装置間でデータ送受信が実行されようとする際に、当該データ送受信に関連するアプリケーションソフトウェアに割り当てられている第１の識別情報と、データ送受信の対象となるデータに割り当てられている第２の識別情報との組合せに基づいて、データ送受信を実行するか判定する。【選択図】図１
2014191589.tif 000002
【特許請求の範囲】
【請求項１】
複数の情報処理装置と、前記複数の情報処理装置を互いに通信可能に接続する通信ネットワークとを有する情報処理システムであって、
前記情報処理システムは、前記複数の情報処理装置で動作している複数のアプリケーションソフトウェアの種別を示す第１の識別情報と、前記アプリケーションソフトウェアが使用するデータの種別を示す第２の識別情報と、
前記複数の情報処理装置間でデータ送受信が実行されようとする際に、当該データ送受信に関連する前記アプリケーションソフトウェアに割り当てられている前記第１の識別情報と、前記データ送受信の対象となるデータに割り当てられている前記第２の識別情報との組合せに基づいて、前記データ送受信を実行するか判定するデータ送受信可否判定処理部を備えている、
情報処理システム。
【請求項２】
前記第１の識別情報は、前記アプリケーションソフトウェアの種別ごとに固有の第１の数値データを含み、前記第２の識別情報は、前記データの種別ごとに固有の第２の数値データを含み、前記データ送受信可否判定処理部は、前記第１の数値データと前記第２の数値データを用いて所定の演算を実行し、当該演算の実行結果に応じて前記データの送受信可否を決定する、
請求項１に記載の情報処理システム。
【請求項３】
前記データ送受信可否判定処理部が前記データ送受信におけるデータ送信要求側の情報処理装置に設けられ、
前記データ送受信可否判定処理部が、前記データ送信要求を行った前記アプリケーションソフトウェアに関する前記第１の数値データと、前記データ送信要求の対象であるデータの前記第２の数値データとを用いて実行した前記演算の実行結果が所定の結果となったと判定した場合に、前記データ送信要求の送信を抑止する、
請求項２に記載の情報処理システム。
【請求項４】
前記データ送受信可否判定処理部が前記データ送受信におけるデータ送信側の情報処理装置に設けられ、
前記データ送受信可否判定処理部が、前記データ送信要求を行った前記アプリケーションソフトウェアに関する前記第１の数値データと、前記データ送信要求の対象であるデータの前記第２の数値データとを用いて実行した前記演算の実行結果が所定の結果となったと判定した場合に、前記データ送信要求に応じたデータ送信を抑止する、
請求項２に記載の情報処理システム。
【請求項５】
前記情報処理システムは、前記データ送受信可否判定処理部によるデータ送受信可否判定の判定基準となる少なくとも一の判定基準値を備え、
前記データ送受信可否判定処理部は、前記第１の数値データと前記第２の数値データとを用いた前記演算の実行結果と前記判定基準値との比較結果に応じてデータ送受信の可否を決定する、
請求項２に記載の情報処理システム。
【請求項６】
前記情報処理システムは前記通信ネットワークの状態を取得するネットワーク状態取得部を有し、
前記少なくとも一の判定基準値は前記通信ネットワークの状態を示すネットワーク状態情報として、前記ネットワーク状態取得部が取得した前記通信ネットワークの状態に応じて設定され、
前記データ送受信可否判定処理部は、前記第１の数値データと前記第２の数値データとを用いた前記演算の実行結果と前記判定基準値との比較結果に応じてデータ送受信の可否を決定する、
請求項５に記載の情報処理システム。
【請求項７】
前記判定基準値は前記ネットワーク状態取得部によって定期的に取得される前記通信ネットワークの状態情報に応じて更新され、
前記データ送受信可否判定処理部が、前記データ送受信の実行を不可と判定した場合、前記データ送受信の実行を所定の時間抑止し、当該所定時間経過後に、再度前記データ送受信可否判定を実行する、
請求項６に記載の情報処理システム。
【請求項８】
前記通信ネットワークは、少なくとも２つの異なる通信ネットワークセグメントと、前記通信ネットワークセグメント間でのデータ送受信を中継する中継装置とを備え、
前記データ送受信可否判定処理部は前記中継装置に設けられており、前記通信ネットワークセグメント間でデータ転送を実行しようとする際に、当該データ転送に関連する前記アプリケーションソフトウェアに割り当てられている前記第１の識別情報と、前記データ転送の対象となるデータに割り当てられている前記第２の識別情報との組合せに基づいて、前記データ転送を実行するか判定する、
請求項１に記載の情報処理システム。
【請求項９】
前記データ送受信可否判定処理部は、前記データ転送を実行しないと判定した場合、当該データ転送に係るデータの要求元であるアプリケーションソフトウェアに、当該データ要求に対する応答を模擬した情報を送信する、
請求項９に記載の情報処理システム。
【請求項１０】
前記情報処理システムは、前記第１の識別情報と前記第２の識別情報との組合せごとに、当該第１の識別情報が特定するアプリケーションソフトウェアによる前記第２の識別情報が特定するデータのデータ送受信量を経時的に記録しており、
前記データ送受信可否判定処理部は、前記データ送受信量の経時的記録に所定の変化が生じたと判定した場合、当該データ送受信を不可と判定する、
請求項１に記載の情報処理システム。
【請求項１１】
前記情報処理システムは、経時的に記録された、前記第１の識別情報と前記第２の識別情報との組合せごとに、当該第１の識別情報が特定するアプリケーションソフトウェアによる前記第２の識別情報が特定するデータのデータ送受信量に基づいて、単位時間あたりのデータ送受信量としてのデータ送受信速度を算定することができるように構成され、前記データ送受信速度に基づいて、当該第１の識別情報が特定するアプリケーションソフトウェアと前記第２の識別情報が特定するデータとの組合せごとに、当該組合せでのデータ送受信を抑止した場合に得られる前記通信ネットワークの通信データ削減量を算出する、
請求項８に記載の情報処理システム。
【請求項１２】
複数の情報処理装置と、前記複数の情報処理装置を互いに通信可能に接続する通信ネットワークとを有する情報処理システムの制御方法であって、
前記情報処理システムは、前記複数の情報処理装置で動作している複数のアプリケーションソフトウェアの種別を示す第１の識別情報と、前記アプリケーションソフトウェアが使用するデータの種別を示す第２の識別情報とを備え、
前記複数の情報処理装置間でデータ送受信が実行されようとする際に、当該データ送受信に関連する前記アプリケーションソフトウェアに割り当てられている前記第１の識別情報と、前記データ送受信の対象となるデータに割り当てられている前記第２の識別情報との組合せに基づいて、前記データ送受信を実行するか判定する、
情報処理システムの制御方法。
【請求項１３】
前記第１の識別情報は、前記アプリケーションソフトウェアの種別ごとに固有の第１の数値データを含み、前記第２の識別情報は、前記データの種別ごとに固有の第２の数値データを含み、前記情報処理システムは、前記第１の数値データと前記第２の数値データを用いて所定の演算を実行し、当該演算の実行結果に応じて前記データの送受信可否を決定する、
請求項１２に記載の情報処理システムの制御方法。
【請求項１４】
前記データ送受信におけるデータ送信要求側の情報処理装置が、前記データ送信要求を行った前記アプリケーションソフトウェアに関する前記第１の数値データと、前記データ送信要求の対象であるデータの前記第２の数値データとを用いて実行した前記演算の実行結果が所定の結果となったと判定した場合に、前記データ送信要求の送信を抑止する、
請求項１３に記載の情報処理システムの制御方法。
【請求項１５】
前記データ送受信におけるデータ送信側の情報処理装置が、前記データ送信要求を行った前記アプリケーションソフトウェアに関する前記第１の数値データと、前記データ送信要求の対象であるデータの前記第２の数値データとを用いて実行した前記演算の実行結果が所定の結果となったと判定した場合に、前記データ送信要求に応じたデータ送信を抑止する、
請求項１３に記載の情報処理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム及び情報処理システムの制御方法に関する。
【技術背景】
【０００２】
電力分野の設備監視制御システム、鉄道分野の運行管理システム等に代表される情報処理システムは、社会インフラとして重要な役割を担っているために、事故やシステム障害等が発生した場合でも、システムとして完全に停止してしまうことは防止する必要がある。そのため、システムに生じた障害の状況などに応じて、システム全体としての機能を制限しつつも、システムが提供する機能のうち、最低限必須となる機能だけは維持することが求められる。このような障害の例として、システムを構成する個々の機能を担うサーバの間でのデータ送受信処理量、システム外部とのデータ送受信処理量が異常に増大することによるネットワーク負荷の増大、あるいはシステムを構成している通信ネットワーク自体の障害により送受信可能なデータの量が制限されてしまう通信障害などがある。このような障害が発生した場合、そのまま通常の運転を継続すると、システムのすべての機能に関してデータ送受信機能が大幅に低下し、結果としてシステムのすべての機能が正常に動作しなくなる事態につながるおそれがある。このようなシステムダウンの事態を予防すべく、前記したように、対象システムの必要最小限の機能についてのデータ送受信処理を優先的に実行し、その他のデータの送受信処理を抑止するモードでのシステム運転が行われる。このような運転モードを、「縮退運転」と称する。
【０００３】
ネットワーク負荷の増大時、通信障害発生時等に実施すべき縮退運転は、システム内で実行されるデータの送受信を間引くことにより実現することができる。その際には、システムとして必須となる機能に関するデータの送受信処理は継続して実行し、それ以外の、例えば不急のデータ送受信処理は抑止するという、データ送受信処理の判別が必要となる。システム内及びシステムと外部とのデータ通信量を削減するという目的を考えると、このデータ送受信処理の判別は、データを送信するサーバ、あるいはデータを要求するサーバ上で行う必要がある。
【０００４】
データ送受信処理の判別を行うための方法として、データの送信相手が有するＩＰアドレス、ポート番号などの物理情報と、送信しようとするデータの種別とを、それらの組合せをあらかじめ格納した対応表などの形式で管理しておいて、縮退運転時には、データ送信側サーバにてこの対応表を参照して逐一データ送信を実行するか否かを判定する方法がある。しかしこの方法では、一つのサーバに複数の機能が配置されている場合、データ送受信処理の実行継続可否判定の切り分けが難しいという問題がある。また、サーバの物理構成が変更された場合、送受信処理するデータ種別が追加された場合などに、対応表の変更、変更後対応表の各サーバへの配布などを含む対応表の更新管理を別途行う必要が生じるという問題もある。システムの規模によって対応表自体のサイズが大きくなった場合には、各サーバがデータ送受信の際に対応表を参照して実行する判別処理そのものがシステムにとって高負荷になることがあり得る。
【０００５】
上記した問題点に関する技術として、例えば特許文献１に開示されている技術がある。特許文献１には、適用システムの性質上システムダウンが許されない通信ネットワークについて、異なるタイプの送受信データに異なる優先順位を割り当て、解析したネットワークの状態に基づいて、送受信するデータを判別して選択的に通信する方法が提案されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１２−７５１７２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、特許文献１の方法では、通信ネットワークで送受信されるデータ種別のみで送受信可否判定を実施するため、判定処理自体は低負荷であると考えられるものの、送受信処理を実行するサーバが備えている機能は考慮されておらず、システムの状態に応じた縮退運転の最適化を達成することはできない。
【０００８】
本発明は、上記の及び他の課題を解決するためになされたもので、情報処理システムを構成する通信ネットワークでのデータ送受信による負荷がなんらかの原因によって過大となった場合でも、情報処理システムとしての機能を最低限維持することができる、情報処理システム及びその制御方法を提供することを一つの目的としている。
【課題を解決するための手段】
【０００９】
上記の及び他の目的を達成するために、本発明の一態様は、複数の情報処理装置と、前記複数の情報処理装置を互いに通信可能に接続する通信ネットワークとを有する情報処理システムであって、前記情報処理システムは、前記複数の情報処理装置で動作している複数のアプリケーションソフトウェアの種別を示す第１の識別情報と、前記アプリケーションソフトウェアが使用するデータの種別を示す第２の識別情報と、前記複数の情報処理装置間でデータ送受信が実行されようとする際に、当該データ送受信に関連する前記アプリケーションソフトウェアに割り当てられている前記第１の識別情報と、前記データ送受信の対象となるデータに割り当てられている前記第２の識別情報との組合せに基づいて、前記データ送受信を実行するか判定するデータ送受信可否判定処理部を備えている。また、本発明の他の態様は、上記情報処理システムの制御方法である。
【発明の効果】
【００１０】
本発明によれば、様々な情報処理システムを構成している通信ネットワークにおいて、なんらかの障害等によりネットワークの通信状態が低下した場合でも、通信ネットワークにおいてデータ送受信処理を実行するサーバの機能と、処理対象となるデータの種別とに応じて、情報処理システムの必要最小限の機能を維持するのに必要なデータ送受信処理が継続され、情報処理システムの機能を維持することができる。
【図面の簡単な説明】
【００１１】
【図１】本発明の一実施形態に係る情報処理システム１の構成例を示す図である。
【図２】情報処理システム１に含まれるサーバ１００、２００のハードウェア構成例を示す図である。
【図３】サーバ１００におけるデータ送信要求処理の概略フロー例を示す図である。
【図４】サーバ１００のデータ送信要求可否判定処理部１６０の処理フロー例を示す図である。
【図５】サーバ２００におけるデータ送信処理の概略フロー例を示す図である。
【図６】サーバ２００のデータ送信可否判定処理部２６０の処理フロー例を示す図である。
【図７】本発明の一実施形態で、アプリケーション又はそのデータ処理部に付与される識別情報に含まれるバイナリ型フィルタコードの構成例を示す図である。
【図８】本発明の一実施形態で、データ種別の識別情報に含まれるバイナリ型フィルタコードの構成例を示す図である。
【図９】本発明の一実施形態で、アプリケーション又はそのデータ処理部に付与される識別情報に含まれる整数型フィルタコードの構成例を示す図である。
【図１０】本発明の一実施形態で、データ種別の識別情報に含まれる整数型フィルタコードの構成例を示す図である。
【図１１】通信ネットワークの状態を考慮したデータ送信要求可否処理のフロー例を示す図である。
【図１２】通信ネットワークの状態を考慮したデータ送信要求可否処理のフロー例を示す図である。
【図１３】ゲートウェイサーバ３００を有する情報処理システム１の構成例を示す図である。
【図１４】ゲートウェイサーバ３００のデータ転送可否判定処理部３１２の処理フロー例を示す図である。
【図１５】アプリケーションと送信データとの組合せごとのデータ送信記録を格納する時系列情報の例である。
【図１６】アプリケーションと送信データとの組合せごとのデータ送信記録を格納する時系列情報の例である。
【発明を実施するための形態】
【００１２】
以下、本発明について、その実施形態により添付図面を参照しつつ説明する。まず、本発明の一実施形態に係る情報処理システムについて説明する。図１は、本発明の一実施形態による情報処理システム１の構成図、図２は、情報処理システム１に設けられている情報処理装置としてのサーバ１００のハードウェア構成を例示する図である。
【００１３】
情報処理システム１における必要最低限の機能を維持するために縮退運転を行う場合、縮退運転時の送受信データの判別は、そのデータを利用する情報処理システム１の機能が縮退運転時も必須のものであるか否かに応じて行う必要がある。このことから、データの送受信の判定は、データの種別と、システムの機能単位であるアプリケーションの種別の組合せに対して行う。
【００１４】
また、このとき、データの種別とアプリケーションの種別の組合せの対応表を作成・管理し、各サーバに配布してデータ送信処理時に参照するのではなく、データの識別情報とアプリケーションの識別情報の中に、データ送受信を判定するための情報を含めておき、データの識別情報とアプリケーションの識別情報を組合せて簡易的な演算を行うことによってデータの送信処理の判定を行う。
【００１５】
情報処理システム（以下「システム」）１は、２台のサーバコンピュータ（以下「サーバ」）１００、２００と、これらを互いに通信可能に接続する通信ネットワークＮとを備えている。図１において、通信ネットワークＮにはさらに１以上のサーバを接続してもよい。通信ネットワークＮとしては、無線通信または有線通信で通信可能な種々の形態（ＬＡＮ、ＰＬＣ、インターネット、専用線等）を採用することができる。サーバ１００、２００は、後述するように、種々のアプリケーションソフトウェアを備えて情報処理システム１に必要な機能を提供している。
【００１６】
ここで、図２を参照してサーバ１００、２００のハードウェア構成について説明する。サーバ１００、２００は、例えば、ＣＰＵ（Central Processing Unit）１１と、主記憶装置１２と、補助記憶装置１３と、通信インタフェース１４と、入出力装置１５とを備える。ＣＰＵ１１、主記憶装置１２、補助記憶装置１３、通信インタフェース１４、及び入出力装置１５は、内部バス１６等を介して相互に通信可能に接続される。
【００１７】
ＣＰＵ１１は、補助記憶装置１３に記憶されているコンピュータプログラム（以下「プログラム」）を読み出して実行することで、サーバ１００、２００としての様々な機能を実現する。
【００１８】
主記憶装置１２は、ＣＰＵ１１がプログラムを実行するにあたり必要なデータを、一時的に記憶する。主記憶装置１２は、例えば、ＤＲＡＭ（Dynamic Random Access Memory）等で構成される。
【００１９】
補助記憶装置１３は、ＣＰＵ１１にて実行されるプログラム及び各種データ等を記憶する。補助記憶装置１３は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等の不揮発性メモリ等で構成される。
【００２０】
通信インタフェース１４は、情報処理システム１に接続されている他のサーバ等と無線、又は有線で通信するためのインタフェースである。通信インタフェース１４は、接続される通信ネットワークＮの種別に応じてＮＩＣ（Network Interface Card）等の形態を取り、他のサーバとデータを送受信する。
【００２１】
入出力装置１５は、サーバ１００、２００で処理されたデータを種々の形態で出力する出力装置と、サーバ１００、２００に指示入力、データ入力を行うための入力装置とを含む。出力装置としては、例えば、種々の形式のディスプレイ装置、プリンタ等の出力デバイスが、入力装置としては、キーボード、マウス等の入力デバイスが含まれる。
【００２２】
なお、各サーバ１００、２００は、一つのコンピュータから構成してもよいし、または、複数のコンピュータから構成してもよい。
【００２３】
図１を参照すると、システム１を構成する各サーバ１００、２００上には、システム１が実現すべき様々な機能を担うアプリケーションソフトウェア（以下「アプリケーション」）１１０、２１０が各々インストールされており、各アプリケーション１１０、２１０はそれぞれの機能を実現するための情報処理の必要に応じて、他のアプリケーションとデータ４００の送受信を行う。アプリケーション１１０、２１０の機能は、補助記憶装置１３に格納されている対応プログラムをＣＰＵ１１が主記憶装置１２上に読み出して実行することによって実現される。各アプリケーション１１０、２１０は、さらに別個の機能を有するプログラムモジュールであるデータ処理部１２０、２２０を複数備えることができる。
【００２４】
アプリケーション１１０、２１０によって送受信されるデータ４００は、どこでどのように生成されたか、あるいはどのような用途・目的で使用されるものか等の属性、あるいはどのような機能・役割のアプリケーションによって利用されるかなどといった属性によって区分される。
【００２５】
また、これらのデータ４００を利用するアプリケーション１１０、２１０も、それぞれどのような機能・役割を持つのか、あるいはどこでどのように動作しているかなどといった属性によって区分される。
【００２６】
なお、サーバ１００には、ネットワーク状態取得部１７０を設けることができる。ネットワーク状態取得部１７０は、サーバ１００と通信ネットワークＮとの通信状態を、通信インタフェース１４を介してモニタし、その通信状態を数値化してデータ送信要求可否判定処理部１６０等に引き渡す機能を有するプログラムである。ネットワーク状態取得部１７０は、パケットモニタリング等の技術を利用して、ネットワークのトラフィック状態、実効通信速度などをモニタする。
【００２７】
図１の例では、サーバ１００がサーバ２００に対して通信ネットワークＮを介してデータ送信を要求する構成となっているが、データ送信要求側とデータ送信側とはアプリケーション１１０、２１０の動作を通じて入れ替わることがある。ここで、データ送信要求側のサーバ１００には、アプリケーション１１０の各データ処理部１２０にデータ送信要求処理部１３０が設けられている。データ送信要求処理部１３０はアプリケーション１１０の一部であるデータ処理部１２０に含まれるプログラムであって、アプリケーション１１０からの要求により、後述するデータ送信要求可否判定処理部１６０に対してデータ送信要求を送信する。
【００２８】
データ送信要求可否判定処理部１６０は、データ送信要求処理部１３０から受信した他のサーバ等へのデータ送信要求を送信して良いか判定し、その結果に応じて送信許可又は送信抑止の処理を実行する機能を有するプログラムである。
【００２９】
データ送信要求を受けるデータ送信側のサーバであるサーバ２００には、受信したデータ送信要求の処理を行う機能を有するプログラムであるデータ送信要求処理部２３０、データ送信要求処理部２３０の処理結果を受けて送信対象データ４００を補助記憶装置１３から読み出してその送信処理を実行する機能を有するプログラムであるデータ送信部２４０、及びデータ送信可否判定処理部２６０が設けられている。データ送信可否判定処理部２６０は、後述する処理に従って、データ送信要求を受けたデータを実際に要求元（図１ではサーバ１００）に対して送信するか否かを判定し、データ送信又は送信抑止の処理を実行する機能を有するプログラムである。
【００３０】
以上の構成を有するシステム１において、システム１が全体として平常状態で動作しているときには、全てのアプリケーション１１０、２１０が、必要な処理を全て実行するために、必要なデータ４００の送受信を全て実行している。一方、サーバ１００、２００間を接続する通信ネットワークＮになんらかの障害が発生した場合、あるいはアプリケーション１１０、２１０間のデータ４００の送受信量が多くなりすぎてネットワークトラフィックが逼迫した場合など、平常状態と同様のパフォーマンスで通信ネットワークＮが使用できなくなった場合には、アプリケーション１１０、２１０間でのデータ送受信処理を間引くなどして削減し、システム１として必要な最低限度の機能を維持するためのデータ４００の送受信処理のみを残す形で、アプリケーション１１０、２１０間でのデータ４００の送受信処理が実行される。
【００３１】
［実施例１］
本実施形態の実施例１に係るシステム１では、上記のアプリケーション間におけるデータ送受信量を抑制するための構成として、具体的には、図１に例示するように、データ４００の送信を要求する（データ４００を利用する）側のアプリケーション１１０、あるいはアプリケーション１１０を構成する個々のデータ処理部１２０に対して識別情報１４０または１５０を付与しておく。また、アプリケーション間で送受信されるデータ４００には、データの種別に応じた識別情報４１０を付与する。
【００３２】
上記のアプリケーション１１０、あるいはアプリケーション１１０を構成する個々のデータ処理部１２０に対する識別情報１４０、１５０と、アプリケーション間で送受信されるデータ４００の種別に応じた識別情報４１０には、データ４００の送信時に、送信するか否かを判定する際に利用するためのフィルタコードを各々含める。識別情報１４０、１５０、４１０の具体的構成例については後述する。
【００３３】
サーバ１００、２００間を接続する通信ネットワークＮに障害が発生したり、あるいは通信ネットワークＮを介して送受信される情報が増えすぎてネットワークトラフィックが逼迫したりした場合など、サーバ１００、２００間でのデータ４００の送受信を間引きして実行することが望ましい状況が発生した場合、システム１においてこの縮退運転を実行する。
【００３４】
次に、図３を参照して、本実施形態によるサーバ１００が、データ送信要求処理を実行する際のデータ処理を説明する。図３は、サーバ１００におけるデータ送信要求処理フロー例を示している。
【００３５】
サーバ１００において、アプリケーション１１０がそのデータ処理の過程で生成した他のサーバ等へのデータ送信要求が送信されると（Ｓ１０１）、データ送信要求処理部１３０がそのデータ送信要求を受信し、データ送信要求可否判定処理部１６０へ送信する（Ｓ１０２）。データ送信要求可否判定処理部１６０は、受信したデータ送信要求に基づいてその送信可否判定処理を実行する（Ｓ１０３）。データ送信要求可否判定処理部１６０がデータ送信要求送信不可と判定した場合、アプリケーション１１０にデータ送信要求抑止情報が送信され（Ｓ１０５）、アプリケーション１１０ではその抑止情報に基づくデータ処理及び必要な外部への情報送信等が実行される（Ｓ１０６）。一方、データ送信要求可否判定処理部１６０がデータ送信要求送信許可と判定した場合、データ送信要求を通信ネットワークＮへ送信する（Ｓ１０４）。なお、データ送信要求可否判定処理部１６０は、システム１が縮退運転を実行する場合に動作すれば良いので、例えば縮退運転実行時にサーバ１００の入出力装置１５を通じてデータ送信要求可否判定処理部１６０に縮退運転実行を通知しておく。
【００３６】
次に、データ送信要求可否判定処理部１６０におけるデータ処理について説明する。図４に、データ送信要求可否判定処理部１６０において実行されるデータ処理フロー例を示している。
【００３７】
前記のように、アプリケーション１１０、あるいはアプリケーション１１０を構成する個々のデータ処理部１２０が、データ送信要求処理部１３０、２３０によってデータ４００に対するデータ送信要求処理を行う際には、アプリケーション１１０が配置されているサーバ１００上に同じく配置されているデータ送信要求可否判定処理部１６０において、データ送信要求可否判定処理が実行される。
【００３８】
まず、Ｓ２０１で処理が開始されると、データ送信要求可否判定処理部１６０は、アプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０に対して付与されている識別情報１４０又は１５０を参照し、それに含まれるフィルタコードを取得する（Ｓ２０２）。次いで、データ送信要求可否判定処理部１６０は、データ送信要求の対象であるデータ４００を参照して、データ４００の種別に応じて付与されている識別情報４１０を取得する（Ｓ２０３）。データ送信要求可否判定処理部１６０は、取得した識別情報１４０又は１５０のフィルタコードと、識別情報４１０のフィルタコードとを用いて所定の演算（図４の実施形態では積演算）を行う（Ｓ２０４）。演算結果がデータ送信抑止を示すものであった場合（Ｓ２０５、Ｙｅｓ）、データ送信要求可否判定処理部１６０は、データ送信要求元に対してデータ送信抑止情報を送信して処理を終了する（Ｓ２０６、Ｓ２０８）。演算結果がデータ送信抑止を示すものでなかった場合（Ｓ２０５、Ｎｏ）、データ送信要求可否判定処理部１６０は、データ送信要求の対象であるデータ４００を要求通りに送信して処理を終了する（Ｓ２０７、Ｓ２０８）。
【００３９】
以上のデータ送信要求可否判定処理により、システム１が縮退運転を実行する場合、データ送信要求側であるサーバ１００からのデータ送信要求について、あらかじめ設定したアプリケーション１００又はデータ処理部１２０とデータ４００との組合せについてはデータ送信要求の送信が抑止され、通信ネットワークＮのトラフィックが低減される。
【００４０】
このデータ送信要求可否判定処理において、データ４００の要求元となるアプリケーション１１０と要求するデータ４００の組合せに対して上記の判定を行うのではなく、要求先となるアプリケーション２１０と要求するデータ４００の組合せに対して、上記同様に識別情報１４０又は１５０、及び４１０に含まれるフィルタコードの演算によって上記の判定を実施しても良い。あるいは、データ４００の要求先となるアプリケーション２１０と、要求元となるアプリケーション１１０と、要求するデータ４００の三者の組合せに対して、上記と同様に、識別情報１４０又は１５０、及び４１０に含まれるフィルタコードの演算によって上記判定を行っても良い。
【００４１】
［実施例２］
次に、実施例２として、図５を参照して、本実施形態によるサーバ２００が、データ送信要求に対するデータ送受信を実行する際のデータ処理を説明する。図５は、サーバ２００におけるデータ送信処理フロー例を示している。
【００４２】
サーバ２００において、アプリケーション２００のデータ送信要求処理部２３０が他のサーバ等からのデータ送信要求を処理した結果をデータ送信可否判定処理部２６０が受信すると（Ｓ３０１）、データ送信可否判定処理部２６０は、受信したデータ送信要求に基づいてその送信可否判定処理を実行する（Ｓ３０２）。データ送信可否判定処理部２６０がデータ送信不可と判定した場合、データ送信要求元に対してデータ送信要求抑止情報が送信される（Ｓ３０４）。一方、データ送信可否判定処理部２６０がデータ送信許可と判定した場合、データを通信ネットワークＮへ送信する（Ｓ３０３）。なお、サーバ１００の場合と同様に、データ送信可否判定処理部２６０は、システム１が縮退運転を実行する場合に動作すれば良いので、例えば縮退運転実行時にサーバ２００の入出力装置１５を通じてデータ送信可否判定処理部２６０に縮退運転実行を通知しておく。なお、データ送信可否判定処理部２６０がデータ送信不可と判定した場合、そのままデータ送信を抑止して特に他の付随した処理を実行しないように構成してもよい。
【００４３】
次に、データ送信可否判定処理部２６０におけるデータ処理について説明する。図６に、データ送信可否判定処理部２６０において実行されるデータ処理フロー例を示している。
【００４４】
前記のように、アプリケーション１１０、あるいはアプリケーション１１０を構成する個々のデータ処理部１２０が、データ送信要求処理部１３０によってサーバ２００にデータ送信要求を行った際には、サーバ２００に配置されているデータ送信可否判定処理部２６０において、受信したデータ送信要求に対するデータ送信可否判定処理が実行される。
【００４５】
まず、Ｓ４０１で処理が開始されると、データ送信可否判定処理部２６０は、他のサーバ等からのデータ送信要求を受信する（Ｓ４０２）。データ送信可否判定処理部２６０は、データ送信要求元であるサーバ１００のアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０に対して付与されている識別情報１４０又は１５０を参照し、それに含まれるフィルタコードを取得する（Ｓ４０３）。次いで、データ送信可否判定処理部２６０は、データ送信要求の対象であるデータ４００を参照して、データ４００の種別に応じて付与されている識別情報４１０を取得する（Ｓ４０４）。データ送信可否判定処理部２６０は、取得した識別情報１４０又は１５０のフィルタコードと、識別情報４１０のフィルタコードとを用いて所定の演算（図６の実施形態では積演算）を行う（Ｓ４０５）。演算結果がデータ送信抑止を示すものであった場合（Ｓ４０６、Ｙｅｓ）、データ送信可否判定処理部２６０は、データ送信を抑止して処理を終了する（Ｓ４０７、Ｓ４０９）。演算結果がデータ送信抑止を示すものでなかった場合（Ｓ４０６、Ｎｏ）、データ送信可否判定処理部２６０は、データ送信要求の対象であるデータ４００を要求通りに送信して処理を終了する（Ｓ４０８、Ｓ４０９）。
【００４６】
以上のデータ送信可否判定処理により、システム１が縮退運転を実行する場合、データ送信要求側であるサーバ１００からのデータ送信要求について、あらかじめ設定したアプリケーション１１０又はデータ処理部１２０とデータ４００との組合せについてはデータ送信要求に対するデータ送信が抑止され、通信ネットワークＮのトラフィックが低減される。
【００４７】
なお、サーバ１００のデータ送信要求可否判定処理と同様に、データ４００の要求元となるアプリケーション１１０と要求するデータ４００の組合せに対して上記の判定を行うのではなく、要求先となるアプリケーション２１０と要求するデータ４００の組合せに対して、上記同様に識別情報１４０又は１５０、及び４１０に含まれるフィルタコードの演算によって上記の判定を実施しても良い。あるいは、データ４００の要求先となるアプリケーション２１０と、要求元となるアプリケーション１１０と、要求するデータ４００の三者の組合せに対して、上記と同様に、識別情報１４０又は１５０、及び４１０に含まれるフィルタコードの演算によって上記判定を行っても良い。
【００４８】
次に、本実施形態におけるアプリケーション１１０、２１０、又はデータ処理部１２０、２２０の識別情報１４０、１５０、及びデータ４００の識別情報４１０に設定するフィルタコードの具体的な例について述べる。図７に、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に付与する識別情報１４０又は１５０と、それに含まれるフィルタコードを、バイナリ型として表現した場合の例を示す。また、図８に、アプリケーション１１０、２１０間で送受信されるデータ４００の種別に応じた識別情報４１０と、それに含まれるフィルタコードを、バイナリ型として表現した場合の例を示す。なお、通信ネットワークで送受信されるデータのＩＤコードについては、例えば、ＩＥＣ規格６１９０７「通信ネットワークの信頼性工学（Communication Network Dependability Engineering）」を参照されたい。
【００４９】
アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に付与する識別情報１４０又は１５０に、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種別の数と同数の桁数を持つバイナリコード５０１を含めておく。このバイナリコードの各桁に各々対応するアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種別をあらかじめ定義しておき、各アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０では、各々持っている識別情報１４０又は１５０に含まれるバイナリコード５０１において、自身に対応するバイナリの桁の部分に「１」を立てておき、それ以外の桁は「０」としておく。複数の機能を持つアプリケーション１１０あるいはデータ処理部１２０の場合は、各々対応する複数の桁に「１」を立てることができる。
【００５０】
また、アプリケーション１１０、２１０間で送受信されるデータ４００の種別に応じた識別情報４１０に、上記と同様に、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種類の数と同数の桁数を持つバイナリコード６０１を含めておく。また、同様に、そのバイナリコードの各桁に各々対応するアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種類がどれなのかをあらかじめ定義しておく。各々のデータ４００の種別に応じた識別情報４１０に含まれるバイナリ型フィルタコード６０１において、縮退運転時でもデータの送信を実行する相手アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に対応する桁には「１」を、縮退運転時にはデータ送信を抑止する相手アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に対応する桁には「０」を格納しておく。
【００５１】
アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０が、他のサーバ２００等に格納されているデータ４００に対するデータ送信要求を送信する際には、送信処理を実行する前に、要求元となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０に含まれるバイナリコード５０２と、要求するデータ４００の種別に応じた識別情報４１０に含まれるバイナリコード６０２を積演算する。演算の結果について、要求元となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に対応する桁が「１」になった場合には、データ送信要求可否判定処理部１６０はデータ４００に対する送信要求の送信を実行し、「０」になった場合にはデータ４００に対する要求の送信を抑止する。
【００５２】
一方、図５、図６について説明したように、サーバ２００で、データ４００の送信要求を受けた後に、データ４００の送信を実行するか否かを判定する場合については以下のようになる。アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０からの要求を受けたアプリケーション２１０がデータ４００を送信する際に、その送信実行前に、データ送信可否判定処理部２６０は、送信相手となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０に含まれるバイナリコード５０１と、送信するデータ４００の種別に応じた識別情報４１０に含まれるバイナリコード６０１とを積演算する。データ送信可否判定処理部２６０は、演算の結果について、送信相手となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に対応する桁が「１」になった場合にはデータ４００の送信を実行し、「０」になった場合にはデータ４００の送信を抑止する。
【００５３】
以上により、本実施形態のシステム１では、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信するデータ４００の種別に応じた識別情報４１０による簡易な演算（ここではバイナリデータの積演算）のみによって、システム１の縮退運転実行時に、データ４００を通信ネットワークＮに送信するか抑止するかの判定を行うことができる。
【００５４】
これにより、ネットワーク負荷増大時や通信障害時などでの縮退運転における、送受信データの間引きによる通信量軽減を、必要とするシステム１の機能をきめ細かく選択した上で、各サーバ１００、２００上での演算のみによって軽負荷で実行することが可能となる。
【００５５】
また、システム１内で利用するデータ４００を新規に追加した場合であっても、追加したデータ４００の識別情報４１０中に所定のルールに従ったフィルタコードを埋め込んでおくだけで縮退運転に対応可能となるため、データ追加が容易となる。
【００５６】
［実施例３］
次に、本実施形態のシステム１について、通信ネットワークＮのネットワーク障害の程度、ネットワークトラフィックの逼迫の程度等に応じて、複数の段階での縮退運転を実施可能とする構成例（実施例２）について説明する。この構成例における、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に付与する識別情報１４０又は１５０と、それに含まれるフィルタコードの例を図９に示す。また、アプリケーション１１０、２１０間で送受信されるデータ４００の種別に応じて設定される識別情報４１０と、それに含まれるフィルタコードの例を図１０に示す。
【００５７】
アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に付与する識別情報１４０又は１５０に、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種別の数と同数の桁数を持つ整数型のコード５０２を含めておく。また、その整数型コードの各桁に各々対応するアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種類がどれなのかをあらかじめ定義しておき、各アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０では、各々持つ識別情報１４０又は１５０に含まれる整数型コード５０２において、自身に対応するコードの桁の部分に、自身の重要度に応じた整数値（例えば、重要度が低い順に０〜９のいずれか）を格納しておく。複数の機能を持つアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の場合は、各々対応する複数の桁に、各々の機能の重要度に応じた整数値を記載しても良い。
【００５８】
一方、アプリケーション１１０、２１０間で送受信されるデータ４００の種別に応じた識別情報４１０に、上記と同様に、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種類の数と同数の桁数を持つ整数型コード８０２を含めておく。また、同様に、その整数型コード８０２の各桁に各々対応するアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の種類がどれなのかをあらかじめ定義しておく。各々のデータ４００の種別に応じた識別情報４１０に含まれる整数型コード６０２の各桁において、各桁に対応するアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０にとっての当該データ４００の重要度に応じた整数値（例えば、重要度が低い順に０〜９のいずれか）を格納しておく。
【００５９】
図１１に、上記構成例を有するシステム１のデータ送信要求可否判定処理部１６０におけるデータ処理フロー例を示している。図１１の処理フロー例では、システム１の縮退運転を、通信ネットワークＮの状態に基づいて管理するようにしている。
【００６０】
まず、Ｓ８０１で処理が開始されると、個々のアプリケーション１１０、あるいはそれらが配置されているサーバ１００では、ネットワーク状態取得部１７０によって現在の通信ネットワークＮの状態をモニタし、通信ネットワークＮの状態が、所定の状態、例えば一定以上のネットワークトラフィック逼迫発生、実効通信速度の低下などが発生したと判定した場合に、縮退運転を開始する（Ｓ８０２）。ここで、ネットワーク状態取得部１７０には、システム１の縮退運転に関して、発生した状況、例えばネットワークトラフィック逼迫の度合い、実効速度低下の度合い等に対してあらかじめ通信ネットワークＮの状態レベルを定義しておき、併せて各状態レベルに対応する閾値を定義しておく。
【００６１】
アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０がデータ４００に対する要求を送信する際には、その送信の前に、要求元となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０を参照してこれに含まれる整数値コード７０２を取得する（Ｓ８０３）。また、データ送信要求可否判定処理部１６０は、要求するデータ４００の種別に応じた識別情報４１０を参照して、これに含まれる整数値コード８０２を取得する（Ｓ８０４）。データ送信要求可否判定処理部１６０は、整数値コード７０２、８０２の各々の桁ごとに所定の演算、例えば積演算又は和演算を行う（Ｓ８０５）。次いで、データ送信要求可否判定処理部１６０は、その演算の結果について、送信相手となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に対応する桁の演算結果の値と、ネットワーク状態取得部１７０から取得した、実際に発生している状況に対応する前記状態レベルに対して定義した閾値とを比較する（Ｓ８０６）。演算結果の値の方が大きいと判定した場合（Ｓ８０７、Ｙｅｓ）、データ送信要求可否判定処理部１６０はデータ４００に対する要求の送信を実行して処理を終了する（Ｓ８０８、Ｓ８１０）。演算結果の値が閾値以下であると判定した場合（Ｓ８０７、Ｎｏ）、データ送信要求可否判定処理部１６０は、データ４００に対する要求の送信を抑止して処理を終了する（Ｓ８０９、Ｓ８１０）。
【００６２】
なお、図１１に例示しているデータ送信要求可否判定処理を、実施例１の場合と同様に、データ送信要求先におけるデータ送信可否判定処理部２６０の処理に置き換えることも可能である。この場合、図１１における各ステップの処理主体は、データ送信可否判定処理部２６０となる。その処理内容は明らかであるので、ここでは詳細な説明を省略する。
【００６３】
以上により、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信するデータ４００の種別に応じた識別情報４１０とによる簡易な演算のみによって、データ４００を送信するか抑止するかの判定を、通信ネットワークＮに発生している状況に応じて適切に実行することができる。
【００６４】
［実施例４］
次に、本実施形態のシステム１について、使用する通信ネットワークＮにおける最低通信速度を担保するために適用可能な構成例について説明する。この構成例における、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０に付与する識別情報１４０又は１５０と、それに含まれるフィルタコードの構成は、図９に示す例と同様である。また、アプリケーション１１０、２１０間で送受信されるデータ４００の種別に応じて設定される識別情報４１０と、それに含まれるフィルタコードの構成は、図１０に示す例と同様である。
【００６５】
図１２に、上記構成例を有するシステム１におけるデータ送信要求可否判定処理部１６０におけるデータ処理フロー例を示している。図１２の処理フロー例では、図１１の処理フロー例と同様に、システム１の縮退運転を、通信ネットワークＮの状態に基づいて管理するようにしている。
【００６６】
まず、Ｓ９０１で処理が開始されると、個々のアプリケーション１１０、あるいはそれらが配置されているサーバ１００では、ネットワーク状態取得部１７０によって現在の通信ネットワークＮの状態をモニタし、通信ネットワークＮの状態が、所定の状態、例えば一定以上のネットワークトラフィック逼迫発生、実効通信速度の低下などが発生したと判定した場合に、縮退運転を開始する（Ｓ９０２）。ここで、ネットワーク状態取得部１７０には、システム１の縮退運転に関して、発生した状況、例えばネットワークトラフィック逼迫の度合い、実効速度低下の度合い等に対してあらかじめ通信ネットワークＮの状態レベルを定義しておき、併せて各状態レベルに対応する閾値を定義しておく。
【００６７】
アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０がデータ４００に対する要求を送信する際には、その送信の前に、要求元となるアプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０を参照してこれに含まれる整数値コード５０２を取得する（Ｓ９０３）。また、データ送信要求可否判定処理部１６０は、要求するデータ４００の種別に応じた識別情報４１０を参照して、これに含まれる整数値コード６０２を取得する（Ｓ９０４）。
【００６８】
データ送信要求可否判定処理部１６０は、整数値コード７０２、８０２の各々の桁ごとに所定の演算、例えば積演算又は和演算を行う（Ｓ９０５）。次いで、データ送信要求可否判定処理部１６０は、その演算の結果について、送信相手となるアプリケーション２１０又はアプリケーション２１０を構成する個々のデータ処理部２２０に対応する桁の演算結果の値と、ネットワーク状態取得部１７０から取得した、実際に発生している状況に対応する前記状態レベルに対して定義した閾値とを比較する（Ｓ９０６）。状態レベルに対して定義した閾値より演算結果の値の方が大きいと判定した場合（Ｓ９０７、Ｙｅｓ）、データ送信要求可否判定処理部１６０はデータ４００に対する要求の送信を実行して処理を終了する（Ｓ９０８、Ｓ９１０）。演算結果の値が閾値以下であると判定した場合（Ｓ９０７、Ｎｏ）、データ送信要求可否判定処理部１６０は、データ４００に対する要求の送信を、あらかじめ設定された一定時間抑止してから（Ｓ９０９）、処理をＳ９０２に戻す。以後、Ｓ９０２以降の処理を再度実行し、通信ネットワークＮの状態と、送信対象であるデータ４００の種別及び送信要求するアプリケーション１００の種別の組合せとの関係に基づいて、データ送信要求が許容されるものについては迅速にデータ送信要求がなされることとなる。
【００６９】
なお、図１１に例示しているデータ送信要求可否判定処理を、実施例１の場合と同様に、データ送信要求先におけるデータ送信可否判定処理部２６０の処理に置き換えることも可能である。この場合、図１１における各ステップの処理主体は、データ送信可否判定処理部２６０となる。その処理内容は明らかであるので、ここでは詳細な説明を省略する。
【００７０】
以上により、アプリケーション１１０又はアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信するデータ４００の種別に応じた識別情報４１０とによる簡易な演算のみによって、データ４００を送信するか、あるいは一定時間送信を待つかの判定を、通信ネットワークＮに発生している状況に応じて適切に実行することができる。これによって通信ネットワークＮの負荷、あるいはトラフィックが一定の限度を超えないようにして、システム１の最低限度のネットワーク性能を保証することが可能となる。
【００７１】
以上説明したシステム１の縮退運転において、データ送信の抑止をデータ送信の要求を受けた側で行う場合、データ送信の要求を受けた際に、その要求に対する応答としてのデータ送信を行う前に、要求する側となっているアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０と、送信を要求されているデータ４００の種別について、本発明の方式によるデータ送信あるいは抑止の判定を行い、判定結果に基づいて送信または抑止を行う。これにより、データ送信要求に対する応答のデータ送信について、ネットワーク負荷を軽減することが可能となる。しかし、データ送信を要求する側のアプリケーション１１０上でデータ送信を要求している処理が、同期型、すなわちデータ送信要求処理を実行した後、それに対する応答が返ってくるまでそれ以降の処理を停止して待機する形の処理であった場合には、応答となるデータ送信が抑止されると、応答を待機する状態が継続することになり、データ送信要求側でのデータ処理が中断することになる。
【００７２】
そこで、データ送信の実行又は抑止の判定を行い、判定結果に基づいて、データ送信の要求を出すか抑止するかを判定し、これを実行するとき、データ送信の要求を抑止した場合、要求する側のアプリケーション１１０内あるいはサーバ１００内において、データ送信の要求に対する応答としてのデータ送信を模擬する応答を、要求元となっているアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ7処理部１２０に対して行う。この模擬された応答は、例えば、エラーや例外通知などでも良い。これにより、データ送信を要求する側のアプリケーション１１０上でデータ送信を要求している処理が、同期型であった場合でも、処理が停止し待ち受けている状態をいつまでも継続することなく、以降の処理が実行される。また、データ送信の要求およびそれに対する応答の双方の通信を抑止可能となるため、より大きなネットワーク負荷軽減が可能となる。
【００７３】
一方、以上説明したシステム１の縮退運転において、通常、あらかじめデータ送信を要求する側が、求めるデータ送信についてデータ送信を要求する相手に対して、対象となるデータや送信を行うタイミング等の設定を登録しておき、その設定に基づいて、要求を受けた側ではデータ送信を行う構成をとる場合について説明する。
【００７４】
このような構成では、設定されたタイミングでのデータ送信を行う際に、パケットモニタリング等の技術を利用して通信ネットワークのトラフィック状態、実効通信速度などをモニタリングしておき、所定の状況、例えば一定以上のネットワークトラフィック逼迫、実効通信速度の低下などの事態が発生したと判定した場合、要求する側となっているアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０と、送信を要求されているデータ４００の種別について、前記実施例によるデータ送信あるいは抑止の判定を行い、その判定結果に基づいてデータ送信または抑止を行う。すなわち、あらかじめ設定されたデータ送信タイミングにおいて、通信ネットワークＮの状況に応じて、サーバ２００のデータ送信可否判定処理部２６０における判定処理が実行される構成である。
【００７５】
なお、この判定は、データ送信が発生する際ではなく、あらかじめデータ送信を要求する側が登録している、求めるデータ送信についてデータ送信を要求する相手に対しての、対象となるデータ、送信を行うタイミング等の設定の登録情報に対して、通信ネットワークＮのトラフィック状態、実効通信速度などのモニタリングの結果として、所定の状況、例えば一定以上のネットワークトラフィック逼迫、実効通信速度の低下などが発生した場合に、個別に判定しておき、その通信ネットワークＮの状態の判定結果だけを保持しておいて、データ送信を行う際にその結果を参照しても良い。
【００７６】
［実施例５］
次に、本発明の実施形態に係るシステム１におけるデータ送信処理の抑止判定を、データ送信の要求元あるいは要求先ではなく、データ送信要求元が属する通信ネットワークと、データ送信要求先が属する通信ネットワークとの間に設けた中継サーバ、ゲートウェイサーバ等の装置で行う場合の構成例について述べる。図１３に、本実施例によるシステム１の構成例を示す。
【００７７】
図１３のシステム１において、サーバ１００は通信ネットワークＮ１に接続されており、サーバ２００は通信ネットワークＮ２に接続されている。通信ネットワークＮ１、Ｎ２は別個のネットワークセグメントであって、ゲートウェイサーバ３００によって相互に通信可能に接続されている。サーバ１００とサーバ２００との間でのデータ送受信処理は、ゲートウェイサーバ３００におけるデータ転送処理を介して行われる。
【００７８】
サーバ１００は、データ送信要求可否判定処理部１６０が設けられていない点を除き、図１、図２に示したサーバ１００と同一の構成を有する。サーバ２００は、データ送信可否判定処理部２６０が設けられていない点を除き、図１、図２に示したサーバ２００と同一の構成を有する。
【００７９】
ゲートウェイサーバ３００は、ハードウェアとしては図２に示したサーバ１００、２００と同等の構成を備えており、通信ネットワークＮ１、Ｎ２間でのデータ転送機能を果たすデータ転送部３１１、転送対象となるデータの転送可否を判定するデータ転送可否判定処理部３１２、及び後述する本実施例の機能の一部を担当する模擬応答生成・送信処理部１３３が設けられている。
【００８０】
サーバ１００とサーバ２００との間で送受信されるデータ４００を含むパケット内の所定のロケーションには、データ送信を要求する側となっているアプリケーション１００あるいはアプリケーション１００を構成する個々のデータ処理部１２０の識別情報１４０、１５０と、データ送信を要求されているデータ４００の種別についての識別情報４１０が記録される。これにより、ゲートウェイサーバ３００においてデータ転送（中継）を行うか、データ転送を抑止するかの判定を行うことを可能としている。ゲートウェイサーバ３００では、中継先となる通信ネットワーク（例えばサーバ１００からサーバ２００へデータ送信を要求する場合には通信ネットワークＮ２）の状態をモニタリングしておき、所定の状況、例えば一定以上のネットワークトラフィック逼迫発生、実効通信速度の低下などの事象が発生した場合に、データ送信要求側となっているアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信を要求されているデータ４００の種別についての識別情報４１０を処理対象のパケットにおいて参照して、例えば図４に例示したデータ送信要求可否判定処理の例と同様にしてデータを送信するか抑止するかの判定を行い、判定結果に基づいてデータの中継あるいは抑止を行うことができる。
【００８１】
図１４に、図１３のゲートウェイサーバ３００により実行されるデータ転送可否判定処理のフロー例を示している。まず、Ｓ１００１で処理が開始され、データ転送要求をデータ転送部３１１から受信すると（Ｓ１００２）、データ転送可否判定処理部３１２は、転送対象のデータを構成するパケットについて、アプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０に対して付与されている識別情報１４０又は１５０を参照し、それに含まれるフィルタコードを取得する（Ｓ１００３）。次いで、データ転送可否判定処理部３１２は、転送要求の対象であるデータ４００を参照して、データ４００の種別に応じて付与されている識別情報４１０を取得する（Ｓ１００４）。データ転送可否判定処理部３１２は、取得した識別情報１４０又は１５０のフィルタコードと、識別情報４１０のフィルタコードとを用いて所定の演算（図１４の実施例では積演算）を行う（Ｓ１００５）。
【００８２】
演算結果がデータ転送抑止を示すものであった場合（Ｓ１００６、Ｙｅｓ）、データ転送可否判定処理部３１２は、データ転送を抑止して処理を終了する（Ｓ１００８、Ｓ１００９）。演算結果がデータ送信抑止を示すものでなかった場合（Ｓ１００６、Ｎｏ）、データ転送可否判定処理部３１２は、データ転送要求の対象であるデータ４００を要求通りに転送するようにデータ転送部３１１に通知して処理を終了する（Ｓ１００７、Ｓ１００９）。
【００８３】
なお、要求元から受信するデータ送信要求が同期型、すなわち要求先にて要求処理を実行した後、それに対する応答を受領するまで要求元でのそれ以降の処理が停止し待機するような形の処理であった場合には、ゲートウェイサーバ３００で応答となるデータ転送が抑止されると、要求元では処理が停止し待ち受けている状態をいつまでも継続することになり、データ送信要求元で以降の処理が実行されないことになる。このような事象を防止するため、データ送信の要求またはその応答となるデータの中継を抑止した場合には、ゲートウェイサーバ３００から、データ送信の要求に対する応答としてのデータ送信を模擬する応答を、模擬応答生成・送信処理部３１３によって生成し、要求元となるアプリケーション１００あるいはアプリケーション１００を構成する個々のデータ処理部１２０に対して行うように構成することができる。図１４の例では、Ｓ１００８においてデータ転送を抑止するとともに、送信要求元に対して模擬応答データを返すようにデータ転送部３１１に通知することになる。この模擬された応答は、例えば、エラーや例外通知などでも良い。これにより、要求する側のアプリケーション１００上でデータ送信を要求している処理が、同期型であった場合でも、処理が停止し待ち受けている状態をいつまでも継続することなく、以降の処理が実行されるようになる。
【００８４】
以上の構成により、通信ネットワークの状態に基づくデータ送信の実行または抑止の判定について、複数のネットワークセグメントをまたがってこれを行う場合に、経路上のすべての通信ネットワークについての状態のモニタリングおよびこれに基づく判定を行う必要が無くなり、個々のネットワークのゲートウェイサーバ３００において個別に当該ゲートウェイサーバ３００のデータ転送に関係するネットワーク状態のモニタリングおよびこれに基づく判定を実行することが可能となる。
【００８５】
［実施例６］
次に、本実施形態の実施例７によるシステム１について説明する。実施例７の構成では、本実施形態の識別情報を通信ネットワークに関するセキュリティ対策に利用する。
【００８６】
本実施例では、アプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０からのデータ送信要求、およびその応答としてのデータ要求について、実際に発生したデータ送信要求およびそれに対するデータ送信を、アプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信要求の対象であるデータ４００の種別についての識別情報４１０の組合せ毎に、時系列情報として、データ送信要求の発生時刻の情報を加えて、例えばサーバ１００あるいは２００の主記憶装置１２に蓄積しておく。図１５に時系列情報の蓄積テーブル例を示している。図１５の例では、アプリケーション１１０又はデータ処理部１２０の種別と送信対象データ４００の種別との組合せごとに、直近の一定期間における送信イベント発生時刻を時系列に記録している。この送信時系列情報は、例えばサーバ１００の主記憶装置１２に格納しておくことができる。
【００８７】
例えば、データ送信要求可否判定処理部１６０あるいはデータ送信可否判定処理部２６０は、前記蓄積された時系列情報を参照して、データ送信の要求およびデータ送信の単位時間あたりの発生頻度を、アプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信を要求されているデータ４００の種別についての識別情報４１０の組合せ毎に集計して取得しておき、単位時間あたりのデータ送信の要求あるいはデータ送信の発生頻度が一定の閾値に達した場合、あるいは前記発生頻度の増加率が一定の上限値を超えた場合に、該当するアプリケーション１１０あるいはアプリケーション１１０を構成する個々のデータ処理部１２０の識別情報１４０又は１５０と、送信を要求されているデータ４００の種別についての識別情報４１０の組合せについてのデータ送信要求およびデータ送信を抑止することができる。
【００８８】
以上により、アプリケーション１１０、２１０のハッキング等による乗っ取り、エラー等によるデータ送受信処理量の増大を抑止し、通信ネットワークにおけるトラフィックの異常増加を防ぐことができる。
【００８９】
［実施例７］
次に、本実施形態の実施例８によるシステム１について説明する。本実施例では、これまでに説明した縮退運転対応の構成を持つシステム１（以下、これを「内部システム」と呼称する）が、縮退運転対応の構成を持たない別のシステム（以下、これを「外部システム」と呼称する）と連携する場合の構成例について述べる。
【００９０】
外部システム上のアプリケーションあるいはデータと、内部システム上のアプリケーションあるいはデータとの間で送受信を行う場合、外部システム上のアプリケーションおよびデータには、実施例１等で述べたようなフィルタコードを含む識別情報が設けられていない。そこで、内部システム上のアプリケーションあるいはデータの識別情報のみを利用して縮退運転時の判定を行う。
【００９１】
具体的には、例えば、外部システム上のアプリケーションから内部システム上のアプリケーションおよびデータに対してデータ送信要求を行う場合は、この要求を受けた内部システム上のアプリケーションにおいて、要求先である自分自身の識別情報に含まれるフィルタコードと、要求されているデータの識別情報に含まれるフィルタコードを用いて、縮退運転時に、要求に対してデータを返すか否かの判定を行う。内部システム上のアプリケーションから、外部システム上のアプリケーションおよびデータに対して要求を行う場合は、要求元となるアプリケーションにおいて、自分自身の識別情報に含まれるフィルタコードを用いて、縮退運転時に、要求を送るか否かの判定を行う。
【００９２】
以上の構成によれば、外部システムと内部システムとの間でデータ送受信を実行する場合でも、本実施形態のシステム１における縮退運転を適用することができる。
【００９３】
［実施例８］
次に、本実施形態の実施例９によるシステム１について説明する。本実施例では、実際にアクセスが発生したアプリケーションの識別情報とデータの識別情報との組合せを、例えばサーバ１００の主記憶装置１２に蓄積しておき、特定のアプリケーションとデータとの組合せでのデータ送受信をフィルタした場合に、通信ネットワークにおける通信量の削減量を定量的に予測するのに利用する。
【００９４】
具体的には、上記蓄積された、実際にアクセスが発生したアプリケーションの識別情報とデータの識別情報との組合せにおいて、個々のアプリケーションとデータとの組合せ毎の通信量を、各データの容量を踏まえて集積して算出することで、予測する。図１６に、送信時系列情報の蓄積例を示している。例えば、アプリケーションＸとデータＡＹとの組合せについて、直近の時間Ｔの間に容量ＤのデータＹが送信されたことが記録されていると仮定すると、アプリケーションＸとデータＹとの組合せをフィルタしたとすれば、次の時間Ｔ’において（Ｄ×Ｔ’／Ｔ）の通信量（図１６の例では０．７ＭＢ／ｓ）が削減されると予測することができる。
【００９５】
上記の通信量削減予測方式を利用して、システム１において、ネットワーク状態取得部１７０が通信ネットワークＮにおける実際の通信状態をモニタリングした上で、削減したい通信量を算出し、それに合致するだけのフィルタリングを実施するために、フィルタするアプリケーションとデータとの組合せを決定することができる。
【００９６】
また、システム１として必要最低限度の機能を維持するために、あるいは特定のレベルの縮退運転を行うために、必要となる帯域を、事前に予測することも可能である。この場合、上記蓄積された、実際にアクセスが発生したアプリケーションの識別情報とデータの識別情報との組合せにおいて、個々のアプリケーションとデータとの組合せ毎の通信量を、各データの容量を踏まえて集積して算出した上で、個々のアプリケーションの識別情報に含まれるフィルタコードと、個々のデータの識別情報に含まれるフィルタコードとによる演算の結果として得られる、実施例２で述べたような縮退レベル毎の送信可否判定結果に基づき、各縮退レベルにおける通信量を予測する。例えば、実施例２の構成において、あらかじめ設定された縮退運転レベルを示す閾値に対して、アプリケーション１１０とデータ４００の種別との組合せによるフィルタコードを用いてデータ送信要求可否判定処理部１６０により演算値を算出する。その演算値と前記縮退運転レベルの閾値とを比較することにより、送信要求が抑止されることとなるアプリケーション１１０とデータ４００の種別との組合せが得られるので、その各組合せの通信量記録に基づいて、前記のように通信量削減を予測することができる。このような構成によれば、システム１の機能を所定レベルで維持するのに必要なアプリケーション１１０とデータ４００の種別との組合せを特定しその通信量削減効果を予測することができる。
【００９７】
以上説明したように、本実施形態の情報処理システム１によれば、情報処理システム１を構成している通信ネットワークＮにおいて、なんらかの障害等によりネットワークの通信状態が低下した場合でも、通信ネットワークＮにおいてデータ送受信処理を実行するサーバ１００、２００の機能と、処理対象となるデータ４００の種別とに応じて、情報処理システム１の必要最小限の機能を維持するのに必要なデータ送受信処理が継続され、情報処理システム１の機能を維持することができる。
【符号の説明】
【００９８】
１  情報処理システム  １１  ＣＰＵ    １２  主記憶装置
１３  補助記憶装置    １４  通信インタフェース
１５  入出力装置    １６  内部バス
１００、２００  サーバ（情報処理装置）
１１０、２１０  アプリケーションソフトウェア
１２０、２２０  データ処理部
１３０  データ送信要求処理部
１４０  識別情報（アプリケーションソフトウェア１１０、２１０の）
１５０  識別情報（データ処理部１２０、２２０の）
１６０  データ送信要求可否判定処理部（データ送受信可否判定処理部）
１７０  ネットワーク情報取得部
２３０  データ送信要求処理部
２４０  データ送信部
２６０  データ送信可否判定処理部（データ送受信可否判定処理部）
３００  ゲートウェイサーバ（中継装置）
３１１  データ転送部
３１２  データ転送可否判定処理部（データ送受信可否判定処理部）
３１３  模擬応答生成・送信処理部
４００  データ（送信対象としての）
４１０  識別情報（データ４００の）
５０１、５０２  フィルタコード（識別情報１４０、１５０の）
６０１、６０２  フィルタコード（識別情報４１０の）
Ｎ、Ｎ１、Ｎ２  通信ネットワーク
【図１】
2014191589.tif 000003
【図２】
2014191589.tif 000004
【図３】
2014191589.tif 000005
【図４】
2014191589.tif 000006
【図５】
2014191589.tif 000007
【図６】
2014191589.tif 000008
【図７】
2014191589.tif 000009
【図８】
2014191589.tif 000010
【図９】
2014191589.tif 000011
【図１０】
2014191589.tif 000012
【図１１】
2014191589.tif 000013
【図１２】
2014191589.tif 000014
【図１３】
2014191589.tif 000015
【図１４】
2014191589.tif 000016
【図１５】
2014191589.tif 000017
【図１６】
2014191589.tif 000018