JP7059859B2 - 制御方法、制御装置および制御プログラム - Google Patents

Description

本発明は、制御方法、制御装置および制御プログラムに関する。

従来、アプリケーションサーバと連携しているデータベース等が生存状態、すなわち正常に動作している状態にあるかを監視するための技術が知られている。また、生存状態の監視においては、アプリケーションサーバとデータベースとの間の通信路の一部が故障している場合、データベースが生存状態にあったとしても、正確な生存状態の判断が困難な場合がある。

従来の生存状態の監視技術として、データベースへの接続検証が知られている。データベースへの接続検証とは、アプリケーションサーバが、データベースへの接続要求を受けた際に、接続プールに保持されている接続の利用可否を確認した上で、接続要求に対し接続を返す手法である。なお、接続プールとは、アプリケーションサーバが、接続要求があるたびに接続を作成せずに済むように、作成した接続を保持して再利用する機能である。

また、アプリケーションが連携機能に接続できない等の連携機能に関する異常を検出した場合に、アプリケーション側で連携機能への接続を一定時間遮断する手法（サーキットブレーカー）が知られている。

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

しかしながら、従来の手法では、アプリケーションサーバから連携先への接続要求の処理を効率化することが困難な場合がある。

例えば、データベースへの接続検証では、利用可能であることが確認された接続がアプリケーションサーバに返されたとしても、その後、アプリケーションサーバからの接続が成功しないことがあり得る。これは、接続可否の確認を行った際の通信路と、その後アプリケーションからの接続が試みられた通信路とが異なる場合があるためである。

例えば、アプリケーションサーバとデータベースとの間の通信路の振り分けがＤＮＳ（Domain Name System）サーバによって行われている場合、アプリケーションサーバは、通信先としてデータベースのＦＱＤＮ（Fully Qualified Domain Name）を指定する。このとき、ＤＮＳサーバによって、ＦＱＤＮに対する通信は複数の接続先に振り分けられる。この場合、アプリケーションサーバは、ＤＮＳにより振り分けられる接続先の識別および制御ができない。

そのため、データベースへの接続検証においてＦＱＤＮが利用可能であることが確認されたとしても、ＤＮＳサーバによる振り分けによっては、実際の接続時には検証時と異なる通信路が選択される場合がある。このため、データベースへの接続検証により利用可能であることが確認された接続であっても、アプリケーションからデータベースへの接続に失敗する場合がある。

なお、サーキットブレーカーについては、アプリケーションに機能を追加する必要があり、アプリケーション開発者への負担の増加等により、容易に実現することが困難な場合がある。

一つの側面では、アプリケーションサーバから連携先への接続要求の処理を効率化することができる制御方法、制御装置および制御プログラムを提供することにある。

一つの態様では、制御方法は、複数の通信路のうち、アクセスに応じて所定のアルゴリズムで順次切り替え選択された通信路を介して他の装置にアクセスする装置が実行する。装置は、他の装置へのアクセスの成否の履歴に基づいて、他の装置へのアクセスの失敗を検出した際のリトライ回数を制御する処理を実行する。

アプリケーションサーバから連携先への接続要求の処理を効率化することができる。

図１は、実施例の制御装置の構成の一例を示すブロック図である。 図２は、設定テーブルの一例を示す図である。 図３は、履歴テーブルの一例を示す図である。 図４は、応答状況テーブルの一例を示す図である。 図５は、生存状態テーブルの一例を示す図である。 図６は、接続不可の場合の処理を説明するための図である。 図７は、一部接続不可の場合の処理を説明するための図である。 図８は、高負荷の場合の処理を説明するための図である。 図９は、実施例の制御装置の処理の一例を示すフローチャートである。 図１０は、実施例の制御装置の生存状態設定処理の一例を示すフローチャートである。 図１１は、実施例の通信制御処理の一例を示すフローチャートである。 図１２は、実施例の制御装置の通信前処理の一例を示すフローチャートである。 図１３は、実施例の制御装置の通信後処理の一例を示すフローチャートである。 図１４は、制御プログラムを実行するコンピュータの一例を示す図である。

以下、図面に基づいて、本願の開示する制御方法、制御装置および制御プログラムの実施例を詳細に説明する。なお、本実施例により、開示技術が限定されるものではない。また、以下の実施例は、矛盾しない範囲で適宜組みあわせてもよい。

図１を用いて、制御装置１０の構成について説明する。図１は、実施例の制御装置の構成の一例を示すブロック図である。制御システム１は、制御装置１０、連携機能２１、連携機能２２および連携機能２３を有する。なお、以降の説明では、連携機能２１、連携機能２２および連携機能２３を区別せずに連携機能２０と称する場合がある。また、連携機能２０の数は図示のものに限定されず、任意の数であってよい。

例えば、制御装置１０は、アプリケーションサーバである。制御装置１０は、内部または外部のアプリケーションからの要求に応じて、通信路３０を介して連携機能２０と連携し、所定の情報を当該アプリケーションに提供する。

また、例えば、連携機能２０は、データベースサーバである。連携機能２０は、制御装置１０に情報を提供する。また、例えば、通信路３０は、インターネットを介した通信経路である。また、制御装置１０と連携機能２０のそれぞれとの間には、複数の通信路３０が存在する。なお、連携機能２０は、他の装置の一例である。

ここで、アプリケーションは、当該アプリケーションの機能を発揮するため、制御装置１０に対し連携機能２０へのアクセスを要求することがある。また、制御装置１０は、アプリケーションからの要求にかかわらず、連携機能２０の生存状態の確認のため、連携機能２０にアクセス要求を行う場合がある。このとき、制御装置１０からのアクセスに利用される通信路３０は、所定のアルゴリズムで順次切り替わる。つまり、制御装置１０は、複数の通信路３０のうち、アクセスに応じて所定のアルゴリズムで順次切り替え選択された通信路３０を介して連携機能２０にアクセスする。

ここで、制御装置１０から連携機能２０へのアクセスは、通信路３０の故障等により失敗する場合がある。その場合、制御装置１０は、アクセスのリトライを試みる。このとき、リトライにおけるアクセスは、さらに失敗する場合がある。本実施例の制御装置１０は、アクセスの成否の履歴に基づいてリトライの回数を制御する。

図１に示すように、制御装置１０は、通信部１１と、記憶部１２と、制御部１３とを有する。なお、制御装置１０は、図１に示す機能部以外にも既知のコンピュータが有する各種の機能部、例えば各種の入力デバイスや音声出力デバイス等の機能部を有することとしてもかまわない。

通信部１１は、例えば、ＮＩＣ（Network Interface Card）等によって実現される。通信部１１は、ネットワークを介して有線または無線で接続された連携機能２０との間で情報の通信を司る通信インタフェースである。例えば、通信部１１は、通信路３０を介して連携機能２０との間でデータの送受信を行う。また、通信部１１は、複数の通信路３０のうち、アクセスに応じて、ラウンドロビンで順次切り替え選択された通信路３０を介して連携機能２０にアクセスすることができる。

記憶部１２は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）等の半導体メモリ素子、ハードディスクや光ディスク等の記憶装置によって実現される。記憶部１２は、設定テーブル１２１、履歴テーブル１２２、応答状況テーブル１２３および生存状態テーブル１２４を有する。また、記憶部１２は、制御部１３での処理に用いる情報を記憶する。

設定テーブル１２１は、制御装置１０による制御に用いられる既定の設定値を記憶する。図２は、設定テーブルの一例を示す図である。例えば、図２に示すように、設定テーブル１２１は、設定項目として、生存状態測定サイクル、高負荷状態閾値、遮断解除時間、負荷状況測定サイクル、および通信失敗時リトライ回数を記憶する。

また、設定テーブル１２１は、生存状態測定サイクルとして、例えば「３００ｓ」を記憶する。また、設定テーブル１２１は、高負荷状態閾値として、例えば「１ｓ」を記憶する。また、設定テーブル１２１は、遮断解除時間として、例えば「６０ｓ」を記憶する。また、設定テーブル１２１は、負荷状況測定サイクルとして、例えば「６０ｓ」を記憶する。また、設定テーブル１２１は、通信失敗時リトライ回数として、例えば「１０回」を記憶する。

履歴テーブル１２２は、制御装置１０による連携機能２０へのアクセスの成否の履歴を記憶する。また、履歴テーブル１２２は、アクセスの成否の履歴を、連携機能２０のそれぞれに対応付けて記憶する。図３は、履歴テーブルの一例を示す図である。例えば、図３に示すように、履歴テーブル１２２は、連携機能、接続成否、応答時間および接続日時を記憶する。

履歴テーブル１２２の連携機能は、連携機能２０を識別するための情報である。また、接続成否は、アクセスが成功したか失敗したかを示す情報である。また、応答時間は、アクセスの要求後、応答が返ってくるまでに要した時間である。また、接続日時は、アクセス要求があった日時である。例えば、履歴テーブル１２２の１行目は、「17/12/20 13:44:05.238」に行われた連携機能２１へのアクセスが成功し、応答時間が「０．５ｓ」であったことを示している。

応答状況テーブル１２３は、連携機能２０のそれぞれに対応するアクセスの成否の履歴に基づいて生成される、制御装置１０からのアクセス要求に対する応答状況を記憶する。図４は、応答状況テーブルの一例を示す図である。例えば、図４に示すように、応答状況テーブル１２３は、連携機能、接続成功率および平均応答時間を記憶する。

応答状況テーブル１２３の連携機能は、連携機能２０を識別するための情報である。また、接続成功率は、アクセスの総数に対する成功したアクセスの数の割合である。また、平均応答時間は、応答時間の平均である。例えば、応答状況テーブル１２３の１行目は、連携機能２１へのアクセスの接続成功率が「５０％」であり、平均応答時間が「０．３ｓ」であることを示している。

生存状態テーブル１２４は、連携機能２０のそれぞれに対応する応答状況に基づいて生成される情報であって、制御装置１０による制御に用いられる情報を記憶する。図５は、生存状態テーブルの一例を示す図である。例えば、図５に示すように、生存状態テーブル１２４は、連携機能および生存状態を記憶する。

生存状態テーブル１２４の連携機能は、連携機能２０を識別するための情報である。また、生存状態は、制御装置１０による制御方法を区別するための情報である。なお、生存状態には、「一部接続不可」、「正常」、「接続不可」、「高負荷」がある。例えば、生存状態テーブル１２４の１行目は、連携機能２１の生存状態が「一部接続不可」であることを示している。

図１の説明に戻って、制御部１３は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）等によって、内部の記憶装置に記憶されているプログラムがＲＡＭを作業領域として実行されることにより実現される。また、制御部１３は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されるようにしてもよい。制御部１３は、アプリケーション１３１、リトライ制御部１３２および特定部１３３を有し、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部１３の内部構成は、図１に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。

アプリケーション１３１は、連携機能２０と連携して動作する所定のプログラムである。例えば、アプリケーション１３１は、データベースサーバから取得した情報を基に生成したＷｅｂサイトをユーザに提供するＷｅｂアプリケーションである。

ここで、アプリケーション１３１は、連携機能２０へのアクセスにおいて例外が発生した場合、当該例外に関する情報を受け取り、受け取った情報をユーザに通知する機能を有する。ここで、例外とは、連携機能２０へのアクセス時に発生するタイムアウト等のエラーである。また、アプリケーション１３１は、処理の実行中に連携機能２０へのアクセスが失敗した場合、無応答状態に陥ることもあり得る。

アプリケーション１３１でエラーが発生すること、および、アプリケーション１３１が無応答状態に陥ることは、ユーザにとっては好ましくないことである。このため、本実施例は、アプリケーション１３１と連携機能２０との連携時に、アクセスの失敗等の好ましくない状態をなるべく発生させないようにすることを一つの目的としている。

リトライ制御部１３２は、連携機能２０へのアクセスの成否の履歴に基づいて、連携機能２０へのアクセスの失敗を検出した際のリトライ回数を制御する処理を実行する。また、リトライ制御部１３２は、特定部１３３によって特定された応答状況に基づき、連携機能２０へのアクセス要求の送信を制御する。

特定部１３３は、連携機能２０へのアクセス要求を受け付けると、記憶部１２の履歴テーブル１２２を参照して、連携機能２０のそれぞれについて、アクセス要求に対する応答状況を特定する。ここで、記憶部１２の履歴テーブル１２２は、過去の特定期間に連携機能２０に送信されたアクセス要求に対するアクセスの成否の履歴を連携機能２０に対応付けて記憶する。

また、特定部１３３は、連携機能２０に送信されたアクセス要求に対するアクセスの成功率、および連携機能２０に送信されたアクセス要求に対する応答時間の少なくともいずれかに基づいて応答状況を特定する。

特定部１３３は、連携機能２０のそれぞれについて応答状況を特定し、特定した応答状況に基づいて、生存状態を「一部接続不可」、「正常」、「接続不可」、「高負荷」のいずれかに分類する。また、特定部１３３は、分類した生存状態を生存状態テーブル１２４に格納する。

次に、リトライ制御部１３２が、アクセス先の連携機能２０の生存状態に応じて通信部１１を制御する処理について説明する。図６、図７および図８を用いて、生存状態が「接続不可」、「一部接続不可」または「高負荷」である場合のリトライ制御部１３２による処理について説明する。また、ここでは、一例として、制御装置１０が連携機能２１にアクセスを試みる場合について説明する。

図６は、接続不可の場合の処理を説明するための図である。図６に示すように、連携機能２１の生存状態が「接続不可」であることは、制御装置１０が、いずれの通信路を使っても連携機能２１にアクセスできないと推定されたことを意味している。この場合、リトライ制御部１３２は、連携機能２１へのアクセスが失敗した場合、リトライを行わないように通信部１１を制御する。つまり、リトライ制御部１３２は、特定部１３３によって成功率が０％であることが特定された場合、リトライ回数を０回に制御する。

図７は、一部接続不可の場合の処理を説明するための図である。図７に示すように、連携機能２１の生存状態が「一部接続不可」であることは、制御装置１０が、一部の通信路を使う場合に、連携機能２１にアクセスできないと推定されたことを意味している。この場合、リトライ制御部１３２は、連携機能２１へのアクセスが失敗した場合、最大Ｎ回のリトライを行うように通信部１１を制御する。

ここで、リトライ制御部１３２は、応答状況テーブル１２３の接続成功率、平均応答時間、および履歴テーブル１２２における成功回数と失敗回数の偏りを基にＮを計算する。また、Ｎは、設定テーブル１２１の通信失敗時リトライ回数の設定値以下の値である。つまり、リトライ制御部１３２は、特定部１３３によって成功率が０％より大きく、かつ１００％未満であることが特定された場合、成功率、アクセスの成否の履歴における成功回数と失敗回数の偏り、および応答時間に基づいてリトライ回数を制御する。

例えば、リトライ制御部１３２は、接続成功率が大きいほど、また、平均応答時間が短いほどＮが大きくなるように計算を行う。また、例えば、リトライ制御部１３２は、成否の履歴において、成功または失敗が連続している箇所が多いほど偏りが大きいとみなし、Ｎが小さくなるように計算を行う。

図８は、高負荷の場合の処理を説明するための図である。図８に示すように、連携機能２１の生存状態が「高負荷」であることは、制御装置１０が、少なくとも一部の通信路を使えば連携機能２１にアクセスできるが、応答時間が長くなると推定されたことを意味している。この場合、リトライ制御部１３２は、連携機能２１への接続要求を遮断し、一定時間待機する。つまり、リトライ制御部１３２は、特定部１３３によって応答時間が閾値以上であることが特定された場合、所定の時間の間、連携機能２１へのアクセスを遮断する。

さらに、リトライ制御部１３２は、連携機能２１への接続要求を遮断し、一定時間が経過した後、連携機能２１の単位時間当たりの平均応答時間を負荷状況として測定する。ここで、リトライ制御部１３２は、測定した平均応答時間が閾値未満であれば、連携機能２１の生存状態を「正常」に変更する。一方、リトライ制御部１３２は、測定した平均応答時間が閾値以上である場合、連携機能２１の生存状態を「高負荷」のままとし、さらに一定時間が経過するまで待機する。なお、ここでの一定時間、単位時間、および閾値は、それぞれ設定テーブル１２１の遮断解除時間、負荷状況測定サイクルおよび高負荷状態閾値の設定値であってよい。

なお、生存状態が「正常」である場合、リトライ制御部１３２は、設定テーブル１２１の通信失敗時リトライ回数の設定値だけアクセスのリトライを行うように通信部１１を制御する。つまり、リトライ制御部１３２は、特定部１３３によって成功率が１００％であることが特定された場合、リトライ回数を、あらかじめ設定された既定の回数にする。

次に、実施例の制御装置１０の処理について説明する。図９は、実施例の制御装置の処理の一例を示すフローチャートである。図９に示すように、まず、制御装置１０は、管理者の操作等に応じてシステムを起動する（ステップＳ１）。このとき、設定テーブル１２１の各設定項目の設定値は、管理者等により設定済みであるものとする。

制御装置１０は、システムが起動した後、生存状態設定処理および通信制御処理を非同期で実行する（ステップＳ２）。その後、制御装置１０は、生存状態設定処理および通信制御処理を、システムが終了するまで実行する（ステップＳ３）。

図１０を用いて、実施例の生存状態設定処理について説明する。図１０は、実施例の制御装置の生存状態設定処理の一例を示すフローチャートである。図１０に示すように、まず、制御装置１０は、待機しつつ、生存状態測定サイクルが経過したか否かを判定する（ステップＳ１１）。なお、制御装置１０は、生存状態測定サイクルを設定テーブル１２１から取得することができる。

ここで、制御装置１０は、生存状態設定サイクルが経過していない場合（ステップＳ１１：否定）、さらに待機する。一方、制御装置１０は、生存状態設定サイクルが経過した場合（ステップＳ１１：肯定）、履歴テーブル１２２を参照し、平均応答時間および接続成功率を算出する（ステップＳ１２）。また、制御装置１０は、算出した平均応答時間および接続成功率を応答状況テーブル１２３に格納する。なお、生存状態設定処理の実行中であっても、通信制御処理の実行に伴い履歴テーブル１２２は随時更新される。

次に、制御装置１０は、平均応答時間が高負荷状態閾値未満であるか否かを判定する（ステップＳ１３）。なお、制御装置１０は、高負荷状態閾値を設定テーブル１２１から取得することができる。

制御装置１０は、平均応答時間が閾値未満である場合（ステップＳ１３：肯定）、生存状態テーブル１２４の生存状態を「高負荷」に設定する（ステップＳ１４）。また、制御装置１０は、遮断時間の計測を開始する（ステップＳ１５）。なお、制御装置１０は、後述する通信制御処理において実際にアクセスを遮断する。

一方、制御装置１０は、平均応答時間が閾値未満でない場合（ステップＳ１３：否定）、接続成功率が１００％、０％、および、０％より大きい、かつ１００％未満のいずれであるかを判定する（ステップＳ１６）。

ここで、制御装置１０は、接続成功率が１００％である場合、生存状態テーブル１２４の生存状態を「正常」に設定する（ステップＳ１７）。また、制御装置１０は、接続成功率が０％である場合、生存状態テーブル１２４の生存状態を「接続不可」に設定する（ステップＳ１８）。また、制御装置１０は、接続成功率が０％より大きい、かつ１００％未満である場合、生存状態テーブル１２４の生存状態を「一部接続不可」に設定する（ステップＳ１９）。

このように、制御装置１０は、生存状態設定処理において、生存状態測定サイクルが経過するごとに生存状態テーブル１２４を更新する。このため、制御装置１０は、通信制御処理において、生存状態テーブル１２４を参照し、生存状態に関する最新の情報を取得することができる。

図１１を用いて、実施例の通信制御処理について説明する。図１１は、実施例の通信制御処理の一例を示すフローチャートである。図１１に示すように、まず、制御装置１０は、待機しつつ、連携機能２０との通信が発生したか否かを判定する（ステップＳ２１）。

ここで、制御装置１０は、連携機能２０との通信が発生していない場合（ステップＳ２１：否定）、さらに待機する。一方、制御装置１０は、連携機能２０との通信が発生した場合（ステップＳ２１：肯定）、通信前処理を実行する（ステップＳ２２）。制御装置１０は、通信前処理において、生存状況テーブル１２４等の情報を基に、必要に応じて連携機能２０への通信の遮断を行う。なお、通信制御処理の実行中であっても、生存状態設定処理の実行に伴い生存状態テーブル１２４は随時更新される。

制御装置１０は、連携機能２０への通信が遮断されているか否かを判定する（ステップＳ２３）。制御装置１０は、連携機能２０への通信が遮断されている場合（ステップＳ２３：肯定）、ステップＳ２１へ戻り、連携機能２０との間で次の通信が発生するまで待機する。

一方、制御装置１０は、連携機能２０への通信が遮断されていない場合（ステップＳ２３：否定）、連携機能２０との通信処理を実行する（ステップＳ２４）。ここで、制御装置１０は、通信処理の完了後、通信後処理を実行する（ステップＳ２５）。制御装置１０は、通信後処理において、生存状況テーブル１２４等の情報を基に、通信処理のリトライ回数を決定する。

制御装置１０は、リトライ回数が０より大きいか否かを判定する（ステップＳ２６）。制御装置１０は、リトライ回数が０より大きい場合（ステップＳ２６：肯定）、ステップＳ２４へ戻り、通信処理をさらに実行する。このように、制御装置１０は、通信の遮断およびリトライ回数の制御により、無駄なアクセスの発生を抑制している。

以降、通信制御処理の各処理について説明する。まず、図１２を用いて、通信前処理について説明する。図１２は、実施例の制御装置の通信前処理の一例を示すフローチャートである。図１２に示すように、制御装置１０は、生存状態テーブル１２４を参照し、生存状態が「高負荷」、「負荷状況測定中」、もしくは「高負荷」および「負荷状況測定中」のいずれでもないかを判定する（ステップＳ１０１）。

ここで、制御装置１０は、生存状態が「高負荷」および「負荷状況測定中」のいずれでもない場合（ステップＳ１０１：高負荷および負荷状況測定中のいずれでもない）、通信前処理を終了する。

制御装置１０は、生存状態が「高負荷」である場合（ステップＳ１０１：高負荷）、遮断時間が遮断時間解除時間以上であるか否かを判定する（ステップＳ１０２）。なお、制御装置１０は、遮断時間解除時間を設定テーブル１２１から取得することができる。

ここで、制御装置１０は、遮断時間が遮断時間解除時間以上でない場合（ステップＳ１０２：否定）、連携機能２０との通信を遮断し（ステップＳ１１３）、通信前処理を終了する。なお、制御装置１０は、ステップＳ１１３において既に通信が遮断されている場合、引き続き通信を遮断する。

一方、制御装置１０は、遮断時間が遮断時間解除時間以上である場合（ステップＳ１０２：肯定）、生存状態テーブル１２４の生存状態を「負荷状況測定中」に設定する（ステップＳ１０３）。このとき、制御装置１０は、負荷状況測定時間の計測を開始する（ステップＳ１０４）。

ここで、制御装置１０は、通信が遮断されているか否かを判定する（ステップＳ１０５）。制御装置１０は、通信が遮断されている場合（ステップＳ１０５：肯定）、通信の遮断を解除することで通信を再開し（ステップＳ１０６）、ステップＳ１０７に進む。また、制御装置１０は、通信が遮断されていない場合（ステップＳ１０５：否定）、そのままステップＳ１０７に進む。

制御装置１０は、生存状態が「負荷状況測定中」である場合（ステップＳ１０１：負荷状況測定中）、負荷状況測定時間の計測が開始されてから、負荷状況測定サイクルが経過したか否かを判定する（ステップＳ１０７）。なお、制御装置１０は、負荷状況測定サイクルを設定テーブル１２１から取得することができる。

制御装置１０は、負荷状況測定サイクルが経過していない場合（ステップＳ１０７：否定）、通信前処理を終了する。一方、制御装置１０は、負荷状況測定サイクルが経過している場合（ステップＳ１０７：肯定）、平均応答時間を算出する（ステップＳ１０８）。

ここで、制御装置１０は、算出した平均応答時間が高負荷状態閾値未満であるか否かを判定する（ステップＳ１０９）。制御装置１０は、平均応答時間が高負荷状態閾値未満である場合（ステップＳ１０９：肯定）、生存状態テーブル１２４の生存状態を「正常」に設定し（ステップＳ１１０）、通信前処理を終了する。

一方、制御装置１０は、平均応答時間が高負荷状態閾値未満でない場合（ステップＳ１０９：否定）、生存状態テーブル１２４の生存状態を「高負荷」に設定する（ステップＳ１１１）。このとき、制御装置１０は、遮断時間の計測を開始する（ステップＳ１１２）。さらに、制御装置１０は、連携機能２０との通信を遮断し（ステップＳ１１３）、通信前処理を終了する。このように、制御装置１０は、通信処理の前に負荷状況への対処を行うことができる。

次に、図１３を用いて、通信後処理について説明する。図１３は、実施例の制御装置の通信後処理の一例を示すフローチャートである。図１３に示すように、まず、制御装置１０は、通信処理の履歴を履歴テーブル１２２に記録する（ステップＳ２０１）。

ここで、制御装置１０は、生存状態テーブル１２４を参照し、生存状態が「負荷状況測定中」であるか否かを判定する（ステップＳ２０２）。制御装置１０は、生存状態が「負荷状況測定中」である場合（ステップＳ２０２：肯定）、リトライ回数を０に設定し（ステップＳ２０６）、通信後処理を終了する。

一方、制御装置１０は、生存状態が「負荷状況測定中」でない場合（ステップＳ２０２：否定）、通信処理において接続が成功したか否かを判定する（ステップＳ２０３）。制御装置１０は、接続が成功している場合（ステップＳ２０３：肯定）、生存状態テーブル１２４の生存状態が「接続不可」であるか否かを判定する（ステップＳ２０４）。

制御装置１０は、生存状態が「接続不可」である場合（ステップＳ２０４：肯定）、生存状態テーブル１２４の生存状態を「正常」に設定し（ステップＳ２０５）、ステップＳ２０６に進む。また、制御装置１０は、生存状態が「接続不可」でない場合（ステップＳ２０４：否定）、そのままステップＳ２０６に進む。つまり、制御装置１０は、リトライ回数を０に設定し（ステップＳ２０６）、通信後処理を終了する。

制御装置１０は、ステップＳ２０３において、接続が成功していない場合（ステップＳ２０３：否定）、リトライ回数が設定済みであるか否かを判定する（ステップＳ２０７）。制御装置１０は、リトライ回数が設定済みである場合（ステップＳ２０７：肯定）、リトライ回数を減算し（ステップＳ２１１）、通信後処理を終了する。ここでは、制御装置１０は、リトライ回数を、例えば「１」だけ減算する。一方、制御装置１０は、リトライ回数が設定済みでない場合（ステップＳ２０７：否定）、生存状態が「一部接続不可」、「正常」および「接続不可」のいずれであるかを判定する（ステップＳ２０８）。

制御装置１０は、生存状態が「一部接続不可」である場合（ステップＳ２０８：一部接続不可）、算出値に基づいてリトライ回数を設定し（ステップＳ２０９）、通信後処理を終了する。このとき、制御装置１０は、成功率、アクセスの成否の履歴における成功回数と失敗回数の偏り、および応答時間に基づく算出値をリトライ回数として算出する。

制御装置１０は、生存状態が「正常」である場合（ステップＳ２０８：正常）、リトライ回数を既定値に設定し（ステップＳ２１０）、通信後処理を終了する。このとき、制御装置１０は、設定テーブル１２１の通信失敗時リトライ回数を、リトライ回数の既定値として取得することができる。

制御装置１０は、生存状態が「接続不可」である場合（ステップＳ２０８：接続不可）、リトライ回数を０に設定し（ステップＳ２０６）、通信後処理を終了する。このとき、制御装置１０は、接続に失敗したことを例外に関する情報としてアプリケーション１３１に返すようにしてもよい。このように、制御装置１０は、通信処理の結果に応じたリトライ回数の決定を行うことができる。

このように、制御装置１０は、連携機能２０へのアクセスの成否の履歴に基づいて、連携機能２０へのアクセスの失敗を検出した際のリトライ回数を制御する処理を実行する。このため、制御装置１０によって行われるリトライの回数は一定ではなく、アクセス成否の履歴に基づいて決定される。その結果、制御装置１０は、無駄なリトライを抑制し、アプリケーションサーバから連携先への接続要求の処理を効率化することができる。

また、制御装置１０は、連携機能２０へのアクセス要求を受け付けると、過去の特定期間に連携機能２０に送信されたアクセス要求に対するアクセスの成否の履歴を参照し、連携機能２０のそれぞれについて、アクセス要求に対する応答状況を特定する。また、制御装置１０は、特定した応答状況に基づき、連携機能２０へのアクセス要求の送信を制御する。このように、制御装置１０は、連携機能２０の応答状況を基にして、リトライ回数を容易に決定することができる。

また、制御装置１０は、連携機能２０に送信されたアクセス要求に対するアクセスの成功率、および連携機能２０に送信されたアクセス要求に対する応答時間の少なくともいずれかに基づいて応答状況を特定する。その結果、制御装置１０は、接続の可否だけでなく、応答にかかる時間を考慮した制御を行うことができる。

また、制御装置１０は、成功率が０％であることが特定された場合、リトライ回数を０回に制御する。このように、制御装置１０は、アクセスの成功率が非常に低いと考えられる場合、リトライを行わない。その結果、制御装置１０は、無駄なリトライを抑制することができる。

また、制御装置１０は、成功率が０％より大きく、かつ１００％未満であることが特定された場合、成功率、アクセスの成否の履歴における成功回数と失敗回数の偏り、および応答時間に基づいてリトライ回数を制御する。このように、制御装置１０は、アクセスの状況に合わせてリトライの回数を増減させることができる。その結果、制御装置１０は、無駄なリトライを抑制することができる。

また、制御装置１０は、成功率が１００％であることが特定された場合、リトライ回数を、あらかじめ設定された既定の回数にする。このように、制御装置１０は、アクセスの成功率が非常に高いと考えられる場合、リトライの回数の算出等の制御に関する処理を行わないため、計算量が削減される。

また、制御装置１０は、応答時間が閾値以上であることが特定された場合、所定の時間の間、連携機能２０へのアクセスを遮断する。その結果、制御装置１０は、アクセスの成功率だけでなく、連携機能２０の負荷状況を考慮した制御を行うことができる。

また、制御装置１０の通信部１１は、複数の通信路３０のうち、アクセスに応じて、ラウンドロビンで順次切り替え選択された通信路３０を介して連携機能２０にアクセスする。制御装置１０がリトライ回数の制御を行っている結果、ラウンドロビンのような単純な経路の選択手法を採用しても、効率的な通信制御が可能になる。

なお、上記の実施例では、アプリケーション１３１が制御装置１０に含まれている構成について説明したが、アプリケーション１３１は制御装置１０と異なる装置で実行されるものであってもよい。その場合、制御装置１０は、アプリケーション１３１が実行される装置と連携機能２０との間に備えられる負荷分散装置であってもよい。

また、上記の本実施例では、制御装置１０は、生存状態が「負荷状況測定」の場合に、リトライ回数を０に設定するものとした。一方で、負荷状況を測定する機会を増やすために、制御装置１０は、生存状態が「負荷状況測定」の場合に、リトライ回数を既定値等に設定するようにしてもよい。

図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、制御装置１０のリトライ制御部１３２と特定部１３３とを統合してもよい。また、図示した各処理は、上記の順番に限定されるものでなく、処理内容を矛盾させない範囲において、同時に実施してもよく、順序を入れ替えて実施してもよい。

さらに、各装置で行われる各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部または任意の一部を実行するようにしてもよい。また、各種処理機能は、ＣＰＵ（またはＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行されるプログラム上、またはワイヤードロジックによるハードウェア上で、その全部または任意の一部を実行するようにしてもよいことは言うまでもない。

ところで、上記の各実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータで実行することで実現できる。そこで、以下では、上記の各実施例と同様の機能を有するプログラムを実行するコンピュータの一例を説明する。図１４は、制御プログラムを実行するコンピュータの一例を示す図である。

図１４に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０１と、データ入力を受け付ける入力装置２０２と、モニタ２０３とを有する。また、コンピュータ２００は、記憶媒体からプログラム等を読み取る媒体読取装置２０４と、各種装置と接続するためのインタフェース装置２０５と、他の情報処理装置等と有線または無線により接続するための通信装置２０６とを有する。また、コンピュータ２００は、各種情報を一時記憶するＲＡＭ２０７と、ハードディスク装置２０８とを有する。また、各装置２０１～２０８は、バス２０９に接続される。

ハードディスク装置２０８には、図１に示したアプリケーション１３１、リトライ制御部１３２および特定部１３３の各処理部と同様の機能を有する制御プログラムが記憶される。また、ハードディスク装置２０８には、設定テーブル１２１、履歴テーブル１２２、応答状況テーブル１２３、生存状態テーブル１２４および記憶部１２を実現するための各種データが記憶される。

入力装置２０２は、例えば、コンピュータ２００の管理者から操作情報等の各種情報の入力を受け付ける。モニタ２０３は、例えば、コンピュータ２００の管理者に対して出力画面等の各種画面を表示する。インタフェース装置２０５は、例えば印刷装置等が接続される。通信装置２０６は、例えば図１１に示す通信路３０を介して連携機能２０と接続され、各種情報をやりとりする。

ＣＰＵ２０１は、ハードディスク装置２０８に記憶された各プログラムを読み出して、ＲＡＭ２０７に展開して実行することで、各種の処理を行う。また、これらのプログラムは、コンピュータ２００を図１に示したアプリケーション１３１、リトライ制御部１３２および特定部１３３として機能させることができる。

なお、上記の制御プログラムは、必ずしもハードディスク装置２０８に記憶されている必要はない。例えば、コンピュータ２００が読み取り可能な記憶媒体に記憶されたプログラムを、コンピュータ２００が読み出して実行するようにしてもよい。コンピュータ２００が読み取り可能な記憶媒体は、例えば、ＣＤ－ＲＯＭやＤＶＤ（Digital Versatile Disc）、ＵＳＢ（Universal Serial Bus）メモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ、ハードディスクドライブ等が対応する。また、公衆回線、インターネット、ＬＡＮ等に接続された装置にこの制御プログラムを記憶させておき、コンピュータ２００がこれらから制御プログラムを読み出して実行するようにしてもよい。

１ 制御システム
１０ 制御装置
１１ 通信部
１２ 記憶部
１３ 制御部
２０、２１、２２、２３ 連携機能
３０ 通信路
１２１ 設定テーブル
１２２ 履歴テーブル
１２３ 応答状況テーブル
１２４ 生存状態テーブル
１３１ アプリケーション
１３２ リトライ制御部
１３３ 特定部

Claims (10)

1. 複数の通信路のうち、アクセスに応じて所定のアルゴリズムで順次切り替え選択された通信路を介して他の装置にアクセスする装置が、
   前記他の装置へのアクセスの成否の履歴に基づいて、前記他の装置へのアクセスの失敗を検出した際のリトライ回数を制御する処理を実行することを特徴とする制御方法。
2. 前記他の装置へのアクセス要求を受け付けると、過去の特定期間に前記他の装置に送信されたアクセス要求に対するアクセスの成否の履歴を前記他の装置に対応付けて記憶する記憶部を参照して、前記他の装置のそれぞれについて、アクセス要求に対する応答状況を特定する処理をさらに実行し、
   前記制御する処理は、特定した前記応答状況に基づき、前記他の装置へのアクセス要求の送信を制御する、
   ことを特徴とする請求項１に記載の制御方法。
3. 前記特定する処理は、前記他の装置に送信されたアクセス要求に対するアクセスの成功率、および前記他の装置に送信されたアクセス要求に対する応答時間の少なくともいずれかに基づいて前記応答状況を特定することを特徴とする請求項２に記載の制御方法。
4. 前記制御する処理は、前記特定する処理によって前記成功率が０％であることが特定された場合、前記リトライ回数を０回に制御することを特徴とする請求項３に記載の制御方法。
5. 前記制御する処理は、前記特定する処理によって前記成功率が０％より大きく、かつ１００％未満であることが特定された場合、前記成功率、前記アクセスの成否の履歴における成功回数と失敗回数の偏り、および前記応答時間に基づいて前記リトライ回数を制御することを特徴とする請求項３に記載の制御方法。
6. 前記制御する処理は、前記特定する処理によって前記成功率が１００％であることが特定された場合、前記リトライ回数を、あらかじめ設定された既定の回数にすることを特徴とする請求項３に記載の制御方法。
7. 前記制御する処理は、前記特定する処理によって前記応答時間が閾値以上であることが特定された場合、所定の時間の間、前記他の装置へのアクセスを遮断することを特徴とする請求項３に記載の制御方法。
8. 複数の通信路のうち、アクセスに応じて、ラウンドロビンで順次切り替え選択された通信路を介して他の装置にアクセスする装置が実行することを特徴とする請求項１に記載の制御方法。
9. 複数の通信路のうち、アクセスに応じて所定のアルゴリズムで順次切り替え選択された通信路を介して他の装置にアクセスする制御装置において、
   前記他の装置へのアクセスの成否の履歴に基づいて、前記他の装置へのアクセスの失敗を検出した際のリトライ回数を制御する制御部、
   を備えたことを特徴とする制御装置。
10. 複数の通信路のうち、アクセスに応じて所定のアルゴリズムで順次切り替え選択された通信路を介して他の装置にアクセスする装置に、
    前記他の装置へのアクセスの成否の履歴に基づいて、前記他の装置へのアクセスの失敗を検出した際のリトライ回数を制御する処理を実行させることを特徴とする制御プログラム。

Images