知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024068011
(43)【公開日】2024-05-17
(54)【発明の名称】情報処理プログラム、情報処理方法、および情報処理装置
(51)【国際特許分類】
G06F 11/07 20060101AFI20240510BHJP
【ＦＩ】
G06F11/07 160
G06F11/07 193
【審査請求】未請求
【請求項の数】8
【出願形態】ＯＬ
(21)【出願番号】P 2022178492
(22)【出願日】2022-11-07
(71)【出願人】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100104190
【弁理士】
【氏名又は名称】酒井 昭徳
(72)【発明者】
【氏名】芹川 祥太
(72)【発明者】
【氏名】下川 健一郎
(72)【発明者】
【氏名】近藤 沙綾子
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042JJ29
5B042KK17
5B042MA08
5B042MA14
5B042MC27
(57)【要約】
【課題】障害からの復旧を早期に検出すること。
【解決手段】情報処理装置１０１は、通信先１０２の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより通信先１０２の通信復旧を検出する。情報処理装置１０１は、通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、リクエストを通信先１０２に送信する。リクエストは、受信した通信先１０２への実リクエスト、または、ダミーリクエストである。情報処理装置１０１は、リクエスト成功数が閾値に達する前に、リクエストに失敗した場合、リクエスト成功数に基づいて、第２の待ち時間を決定する。情報処理装置１０１は、第２の待ち時間待機した後、期間ごとに、送信上限数を超えないように、リクエストを通信先１０２に送信する。情報処理装置１０１は、リクエスト成功数が閾値に達したことに応じて、通信先１０２の障害からの復旧を検出する。
【選択図】図１
【解決手段】情報処理装置１０１は、通信先１０２の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより通信先１０２の通信復旧を検出する。情報処理装置１０１は、通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、リクエストを通信先１０２に送信する。リクエストは、受信した通信先１０２への実リクエスト、または、ダミーリクエストである。情報処理装置１０１は、リクエスト成功数が閾値に達する前に、リクエストに失敗した場合、リクエスト成功数に基づいて、第２の待ち時間を決定する。情報処理装置１０１は、第２の待ち時間待機した後、期間ごとに、送信上限数を超えないように、リクエストを通信先１０２に送信する。情報処理装置１０１は、リクエスト成功数が閾値に達したことに応じて、通信先１０２の障害からの復旧を検出する。
【選択図】図１
【特許請求の範囲】
【請求項1】
通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
【請求項2】
前記送信上限数は、前記ダミーリクエストの送信上限数を含み、
前記期間よりも前の期間に受信した前記通信先への実リクエスト数に応じて、前記ダミーリクエストの送信上限数を決定する、処理を前記コンピュータに実行させることを特徴とする請求項１に記載の情報処理プログラム。
前記期間よりも前の期間に受信した前記通信先への実リクエスト数に応じて、前記ダミーリクエストの送信上限数を決定する、処理を前記コンピュータに実行させることを特徴とする請求項１に記載の情報処理プログラム。
【請求項3】
前記ポーリングは、ｐｉｎｇによるポーリングである、ことを特徴とする請求項１に記載の情報処理プログラム。
【請求項4】
前記通信先の通信復旧を検出する処理は、
前記通信先の障害を検出した場合、前記第１の待ち時間待機した後に、前記通信先に第１の時間間隔でｐｉｎｇを送信し、
前記ｐｉｎｇに成功した場合、前記通信先に第２の時間間隔でダミーリクエストを送信し、
前記ダミーリクエストに成功した場合、前記通信先の通信復旧を検出する、
ことを特徴とする請求項３に記載の情報処理プログラム。
前記通信先の障害を検出した場合、前記第１の待ち時間待機した後に、前記通信先に第１の時間間隔でｐｉｎｇを送信し、
前記ｐｉｎｇに成功した場合、前記通信先に第２の時間間隔でダミーリクエストを送信し、
前記ダミーリクエストに成功した場合、前記通信先の通信復旧を検出する、
ことを特徴とする請求項３に記載の情報処理プログラム。
【請求項5】
前記通信先の障害を検出した回数のうち、前記通信先の通信復旧を検出した際に、前記ｐｉｎｇおよび前記ダミーリクエストがともに１回目に成功した回数の割合に基づいて、前記第１の待ち時間を更新する、
処理を前記コンピュータに実行させることを特徴とする請求項４に記載の情報処理プログラム。
処理を前記コンピュータに実行させることを特徴とする請求項４に記載の情報処理プログラム。
【請求項6】
前記第２の待ち時間を決定する処理は、
前記リクエストの成功数が多いほど、時間長が短くなるように、前記第２の待ち時間を決定する、ことを特徴とする請求項１～５のいずれか一つに記載の情報処理プログラム。
前記リクエストの成功数が多いほど、時間長が短くなるように、前記第２の待ち時間を決定する、ことを特徴とする請求項１～５のいずれか一つに記載の情報処理プログラム。
【請求項7】
通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータが実行することを特徴とする情報処理方法。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータが実行することを特徴とする情報処理方法。
【請求項8】
通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
制御部を有することを特徴とする情報処理装置。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
制御部を有することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理プログラム、情報処理方法、および情報処理装置に関する。
【背景技術】
【0002】
近年、システムの大規模化やサービスのマイクロ化に伴い、サービスの関係性が複雑化している。このようなシステムでは、一部のサービスでトラブルが起きると、それに関係するサービスに被害が波及し、システム全体のダウンを引き起こす可能性がある。このため、あるサービスで障害が発生したときに、その障害の伝播を遮断する技術が求められる。また、システムの稼働率を高めるため、トラブル解決後は遮断した状態を直ちに元の状態に戻すことが望ましい。
【0003】
先行技術としては、外部サービスに対してリクエストを送信し、外部サービスに障害が発生しているか否かを検知し、検知された外部サービスの状態に基づきサービスが利用可能か否かを判断し、判断結果に応じて、外部サービスの状態を通知するものがある。また、リンクを維持するためのダミーデータの転送中にエラーを検出したとき、デバイスリセットを行ってエラーに対する回復処理を行うとともに、エラー監視期間を設けてエラーの発生の有無を監視する技術がある。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０２１－０５１６１２号公報
【特許文献2】特開２００７－３０４８８４号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来技術では、システム内のあるサービスで障害が発生したときに、サービスの障害からの復旧を認識するのに時間がかかり、システムを元の状態に戻すのに時間がかかる場合がある。
【0006】
一つの側面では、本発明は、障害からの復旧を早期に検出することを目的とする。
【課題を解決するための手段】
【0007】
１つの実施態様では、通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、情報処理プログラムが提供される。
【発明の効果】
【0008】
本発明の一側面によれば、障害からの復旧を早期に検出することができるという効果を奏する。
【図面の簡単な説明】
【0009】
【発明を実施するための形態】
【0010】
以下に図面を参照して、本発明にかかる情報処理プログラム、情報処理方法、および情報処理装置の実施の形態を詳細に説明する。
【0011】
（実施の形態）
図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、通信先１０２の障害からの復旧を検出するコンピュータである。通信先１０２は、例えば、サービスを提供する装置である。サービスは、コンピュータを利用して提供される情報処理であり、例えば、マイクロサービスである。マイクロサービスは、１つのサービスを分割した機能それぞれを実現するソフトウェアである。
図１は、実施の形態にかかる情報処理方法の一実施例を示す説明図である。図１において、情報処理装置１０１は、通信先１０２の障害からの復旧を検出するコンピュータである。通信先１０２は、例えば、サービスを提供する装置である。サービスは、コンピュータを利用して提供される情報処理であり、例えば、マイクロサービスである。マイクロサービスは、１つのサービスを分割した機能それぞれを実現するソフトウェアである。
【0012】
マイクロサービス化されたシステムでは、何らかのトラブルにより一部のサービスを提供できなくなると、それに関係するサービスに被害が波及し、システム全体のダウンを引き起こす可能性がある。このため、あるサービスで障害が発生したときには、その障害の伝播を遮断することが求められる。
【0013】
このようなシステムにおいて、障害の伝搬を遮断する従来技術としては、例えば、サーキットブレーカーがある。サーキットブレーカーは、サービス（例えば、通信先１０２）へのリクエストの失敗回数が一定数を超えたときに、サービスの障害を検知し、サービスへのリクエストを一時的に遮断する。サーキットブレーカーは、一時的に遮断した後は、送られてくるサービスへのリクエストの一部を試し、その成功回数によって、サービスの復旧を認識する。
【0014】
具体的には、サーキットブレーカーでは、Ｃｌｏｓｅ、ＯｐｅｎおよびＨａｌｆ－Ｏｐｅｎの３つの状態を遷移することで、サービスの復旧を認識する。Ｃｌｏｓｅは、サービスが正常な状態を示す。Ｃｌｏｓｅでは、サーキットブレーカーは、全てのリクエストを通信先（サービス）に送信する。サーキットブレーカーは、エラーレスポンスが一定数を超えた場合、Ｏｐｅｎに遷移する。
【0015】
Ｏｐｅｎでは、サーキットブレーカーは、全てのリクエストを遮断し、エラーを返す。サーキットブレーカーは、一定（タイマー）時間経過後、Ｈａｌｆ－Ｏｐｅｎに遷移する。Ｈａｌｆ－Ｏｐｅｎでは、サーキットブレーカーは、一部のリクエスト（例えば、５０％のリクエスト）について、試験的に通信先へ送信し、その他のリクエストは遮断して、エラーを返す。
【0016】
サーキットブレーカーは、試したリクエストでエラーが発生した場合、Ｏｐｅｎに遷移する。一方、サーキットブレーカーは、リクエストが連続して成功した回数が一定数を超えた場合、Ｃｌｏｓｅに遷移する。再度Ｃｌｏｓｅに遷移したことで、通信が再開されるため、サービスの復旧を検知したといえる。
【0017】
しかしながら、サーキットブレーカーでは、Ｈａｌｆ－Ｏｐｅｎにおいて、リクエストが連続して成功した回数が一定数を超えるまでは、サービスの復旧を検知することができない。このため、サーキットブレーカーでは、実際のリクエストが少ない場合、サービスが復旧済みの状態であっても、サービスの障害からの復旧を検知するのに時間がかかる。
【0018】
また、システムの稼働率を高めるためには、トラブル解決後は遮断した状態を直ちに元の状態に戻すことが求められる。しかしながら、サーキットブレーカーでは、サービスの障害からの復旧を検知するのに時間がかかって、システムの復旧時間が長期化し、トラブル解決後は直ちに元の状態に戻したいという要求を満たすことができない場合がある。
【0019】
さらに、サーキットブレーカーでは、Ｈａｌｆ－Ｏｐｅｎにおいて、試したリクエストでエラーが発生した場合、Ｏｐｅｎに遷移し、タイマー時間が経過するまで、全てのリクエストを遮断することになる。このため、障害からの復旧処理が進んでいる状態であっても、障害が発生した直後と同じタイマー時間が経過するまで、Ｈａｌｆ－Ｏｐｅｎに遷移できず、サービスの障害からの復旧を検知するのに時間がかかる。
【0020】
そこで、本実施の形態では、通信先１０２の障害からの復旧を早期に検出可能にして、システムの復旧時間の短縮化を図る情報処理方法について説明する。以下、情報処理装置１０１の処理例（下記（１）～（５）の処理に相当）について説明する。
【0021】
（１）情報処理装置１０１は、通信先１０２の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより通信先１０２の通信復旧を検出する。ポーリングは、通信先１０２の状態を監視するための処理である。ポーリングは、例えば、ｐｉｎｇによるポーリングである。
【0022】
ｐｉｎｇによるポーリングは、特定の文字列（ｐｉｎｇ）を通信先に定期的に送信することで、通信可能かどうかを監視する処理である。ｐｉｎｇによるポーリングは、例えば、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）ポーリングに比べて、通信先にかかる負荷が少ない。
【0023】
通信先１０２の障害は、例えば、通信先１０２に対するリクエストがエラーとなった回数が所定数を超えた場合に検出される。通信先１０２に対するリクエストは、例えば、情報処理装置１０１がサービスの要求元から受信する。第１の待ち時間は、任意に設定可能である。サービスの要求元は、例えば、情報処理装置１０１とは異なる他のコンピュータで動作するアプリケーションである。また、サービスの要求元は、情報処理装置１０１で動作するアプリケーションであってもよい。
【0024】
ここで、通信先１０２において障害が発生した場合、障害からの復旧のためにハードリセットが行われることがある。ハードリセット中は、通信先１０２との通信が不能となる。ハードリセットが完了してＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が起動すると、通信先１０２との通信が可能となる。
【0025】
一方、ＯＳが起動してもアプリケーションが正常に起動していなければ、リクエストがエラーとなる。アプリケーションが正常に起動して、アプリケーションとのやり取りができるようになると、リクエストが正常に処理されるようになる。このように、通信先１０２の障害は、徐々に復旧していく場合がある。
【0026】
ここでは、情報処理装置１０１は、通信先１０２に対して実際のリクエストを送信する前に、ポーリングにより通信先１０２の通信復旧を検出する。
【0027】
（２）情報処理装置１０１は、通信先１０２の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した通信先１０２への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先１０２に送信する。ここで、実リクエストは、通信先１０２への実際のリクエストである。実リクエストは、例えば、サービスの要求元から送信される。
【0028】
ダミーリクエストは、実リクエストのかわりとなるものである。ダミーリクエストは、例えば、Ｇｅｔ要求により実現される。Ｇｅｔ要求は、指定した情報を取得するためのリクエストである。所定の時間間隔は、任意に設定可能である。例えば、所定の時間間隔は、１０程度の時間間隔に設定される。ただし、各時間間隔は、等間隔でなくてもよく、多少のずれがあってもよい。
【0029】
また、送信上限数は、通信先１０２に送信する単位時間当たりのリクエストの上限値に相当する。送信上限数は、任意に設定可能であり、例えば、正常時に単位時間当たりに要求元から送られてくる実リクエスト数の平均値をもとに設定される。
【0030】
例えば、所定の時間間隔を「１０秒」とする。また、１０秒当たりの送信上限数を「５」とする。この場合、情報処理装置１０１は、例えば、通信先１０２の通信復旧を検出した場合、１０秒間隔で区切った期間ごとに、送信上限数「５」を超えないように、受信した通信先１０２への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを、通信先１０２に送信してもよい。この際、情報処理装置１０１は、各期間において、受信した通信先１０２への実リクエスト、または、ダミーリクエストのいずれかのリクエストを、２秒（＝１０秒／５）間隔で通信先１０２に送信してもよい。
【0031】
より詳細に説明すると、例えば、情報処理装置１０１は、リクエストを送信するタイミングで、受信した通信先１０２への実リクエストがあれば、受信した実リクエストを通信先１０２に送信する。一方、受信した通信先１０２への実リクエストがないときは、情報処理装置１０１は、ダミーリクエストを通信先１０２に送信する。
【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】
図４は、定数テーブル２２０の記憶内容の一例を示す説明図である。図４において、定数テーブル２２０は、各定数の値を記憶する。Ｌfailは、Ｃｌｏｓｅにおいて使用される定数である。Ｔp1，Ｔp2，Ｔp3，Ｌdummyは、Ｐｏｌｌｉｎｇにおいて使用される定数である。Ｔr，Ｌr，Ｌsucは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおいて使用される定数である。Ｒは、Ｗａｉｔｉｎｇにおいて使用される定数である。
【0058】
Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇは、処理装置Ｍｉが有する状態である。Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇについては、例えば、図９を用いて後述する。
【0059】
（処理装置Ｍｉの機能的構成例）
図５は、処理装置Ｍｉの機能的構成例を示すブロック図である。図５において、処理装置Ｍｉは、障害検出部５０１と、ポーリング部５０２と、復旧検出部５０３と、待機部５０４と、を含む。障害検出部５０１～待機部５０４は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。
図５は、処理装置Ｍｉの機能的構成例を示すブロック図である。図５において、処理装置Ｍｉは、障害検出部５０１と、ポーリング部５０２と、復旧検出部５０３と、待機部５０４と、を含む。障害検出部５０１～待機部５０４は制御部となる機能であり、具体的には、例えば、図３に示したメモリ３０２、ディスク３０４、可搬型記録媒体３０７などの記憶装置に記憶されたプログラムをＣＰＵ３０１に実行させることにより、または、通信Ｉ／Ｆ３０５により、その機能を実現する。各機能部の処理結果は、例えば、メモリ３０２、ディスク３０４などの記憶装置に記憶される。
【0060】
障害検出部５０１は、通信先の障害を検出する。ここで、通信先は、例えば、図２に示した処理装置Ｍ１～Ｍｍのうち自装置とは異なる他の処理装置Ｍｊである。障害とは、例えば、ハードウェアの故障、ソフトウェアの異常、通信の輻輳などにより、サービス（マイクロサービス）を適切に提供できない状態である。
【0061】
具体的には、例えば、障害検出部５０１は、通信先に対する実リクエストの失敗数が閾値Ｌfailに達した場合に、通信先の障害を検出する。閾値Ｌfailは、任意に設定可能であり、例えば、図４に示した定数テーブル２２０から特定される。図４の例では、閾値Ｌfailは、「Ｌfail＝１０」である。
【0062】
より詳細に説明すると、例えば、障害検出部５０１は、実リクエストを受信するたびに、受信した実リクエストを通信先に送信する。実リクエストは、通信先に対する実際のリクエストである。実リクエストは、例えば、処理装置Ｍ１～Ｍｍのうち自装置とは異なる他の処理装置Ｍｋ（ｋ≠ｉ、ｋ＝１，２，…，ｍ）や利用者端末２０１から送信される。また、実リクエストは、自装置で動作するアプリケーションから送信されてもよい。
【0063】
以下の説明では、受信した全ての実リクエストを通信先に送信する状態を「Ｃｌｏｓｅ」と表記する場合がある。
【0064】
ここで、障害検出部５０１は、送信した実リクエストに対して、エラーレスポンスを受信したり、タイムアウトしたりした場合、送信した実リクエストに失敗したと判断する。障害検出部５０１は、実リクエストに失敗した場合、実リクエストの失敗数をインクリメントする。そして、障害検出部５０１は、実リクエストの失敗数が閾値Ｌfailに達した場合に、通信先の障害を検出する。
【0065】
処理装置Ｍｉは、通信先の障害を検出した場合、ＣｌｏｓｅからＰｏｌｌｉｎｇに遷移する。
【0066】
ポーリング部５０２は、通信先の障害が検出された場合、タイマー時間Ｔp1（第１の待ち時間）待機した後、ポーリングにより通信先の通信復旧を検出する。タイマー時間Ｔp1は、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、タイマー時間Ｔp1は、「Ｔp1＝５０［秒］」である。
【0067】
ポーリングは、例えば、ｐｉｎｇによるポーリングである。具体的には、例えば、ポーリング部５０２は、通信先の障害が検出された場合、タイマー時間Ｔp1待機した後、通信先に時間間隔Ｔp2（第１の時間間隔）でｐｉｎｇを送信する。時間間隔Ｔp2は、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、時間間隔Ｔp2は、「Ｔp2＝３０［秒］」である。
【0068】
ここで、ｐｉｎｇに成功した場合、ポーリング部５０２は、通信先の通信復旧を検出してもよい。通信復旧とは、通信先が通信可能な状態に復旧したことであり、例えば、通信先のハードリセットが完了してＯＳが起動した状態をいう。例えば、ポーリング部５０２は、送信したｐｉｎｇに対する正常な応答を受信した場合に、ｐｉｎｇに成功したと判断する。一方、ポーリング部５０２は、送信したｐｉｎｇに対する正常な応答を受信できなかった場合（例えば、タイムアウト）、ｐｉｎｇに失敗したと判断する。
【0069】
これにより、ポーリング部５０２は、障害が発生した通信先が通信可能な状態まで復旧（回復）したことを認識することができる。
【0070】
また、ポーリング部５０２は、ｐｉｎｇに成功した場合、通信先に時間間隔Ｔp3（第２の時間間隔）でダミーリクエストを送信してもよい。ダミーリクエストは、例えば、Ｇｅｔ要求により実現される。そして、ポーリング部５０２は、ダミーリクエストに成功した場合に、通信先の通信復旧を検出してもよい。この通信復旧は、通信先においてアプリケーションが起動され、アプリケーションとの通信が可能となったことを示す。
【0071】
例えば、ポーリング部５０２は、送信したダミーリクエストに対する正常なレスポンスを受信した場合に、ダミーリクエストに成功したと判断する。一方、ポーリング部５０２は、送信したダミーリクエストに対して、エラーレスポンスを受信したり、タイムアウトしたりした場合、ダミーリクエストに失敗したと判断する。
【0072】
これにより、ポーリング部５０２は、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）７階層参照モデルの低層の通信から順に要求（ｐｉｎｇ、ダミーリクエスト）を送信して応答を確認することで、通信先の復旧状態を段階的に判断することができる。
【0073】
なお、ポーリング部５０２は、通信先に対するダミーリクエストの失敗数が閾値Ｌdummyに達した場合、ｐｉｎｇの送信に戻ってもよい。閾値Ｌdummyは、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、閾値Ｌdummyは、「Ｌdummy＝５」である。
【0074】
また、ポーリング部５０２は、例えば、通信先の通信復旧を検出した際に、ｐｉｎｇが１回目に成功したか否かを示す情報を記録してもよい。また、ポーリング部５０２は、通信先の通信復旧を検出した際に、ダミーリクエストが１回目に成功したか否かを示す情報を記録してもよい。
【0075】
ｐｉｎｇ、ダミーリクエストが１回目に成功したか否かを示す情報は、例えば、図６に示すような成否情報記録テーブル６００に記憶される。成否情報記録テーブル６００は、例えば、メモリ３０２、ディスク３０４などの記憶装置により実現される。
【0076】
図６は、成否情報記録テーブル６００の記憶内容の一例を示す説明図である。図６において、成否情報記録テーブル６００は、回数、ｐｉｎｇ成否およびダミーリクエスト成否のフィールドを有し、各フィールドに情報を設定することで、成否情報（例えば、成否情報６００－１，６００－２）をレコードとして記憶する。
【0077】
ここで、回数は、通信先の障害が検出された回数を示す。ｐｉｎｇ成否は、ｐｉｎｇが１回目に成功したか否かを示す。ここでは、ｐｉｎｇ成否が「１」の場合、ｐｉｎｇが１回目に成功したことを示す。ｐｉｎｇ成否が「０」の場合、ｐｉｎｇが１回目に成功しなかったことを示す。
【0078】
ダミーリクエスト成否は、ダミーリクエストが１回目に成功したか否かを示す。ここでは、ダミーリクエスト成否が「１」の場合、ダミーリクエストが１回目に成功したことを示す。ダミーリクエスト成否が「０」の場合、ダミーリクエストが１回目に成功しなかったことを示す。
【0079】
例えば、成否情報６００－１は、１回目の通信先の障害が検出されたとき、通信先の通信復旧を検出するにあたり、ｐｉｎｇは１回目に成功しなかったが、ダミーリクエストは１回目に成功したことを示す。成否情報６００－２は、２回目の通信先の障害が検出されたとき、通信先の通信復旧を検出するにあたり、ｐｉｎｇおよびダミーリクエストがともに１回目に成功したことを示す。
【0080】
また、ポーリング部５０２は、通信先の障害が検出された後、通信先の通信復旧が検出されるまでの間に、通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返す。具体的には、例えば、ポーリング部５０２は、受信した実リクエストに対して、通信先で障害が発生したためサービスを提供できない旨のエラーレスポンスを送信してもよい。
【0081】
処理装置Ｍｉは、通信先の通信復旧を検出した場合、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する。
【0082】
復旧検出部５０３は、通信先の通信復旧が検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信する。
【0083】
例えば、所定の時間間隔を「一定時間Ｔr」とする。この場合、復旧検出部５０３は、一定時間Ｔrで区切った期間ｔごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信する。
【0084】
ここで、一定時間Ｔrは、任意に設定可能である。一定時間Ｔrは、例えば、定数テーブル２２０から特定される。図４の例では、一定時間Ｔrは、「Ｔr＝１０［秒］」である。送信上限数Ｌrは、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、送信上限数Ｌrは、「Ｌr＝５」である。送信上限数Ｌrは、単位時間（一定時間Ｔr）あたりのリクエストの上限値に相当する。
【0085】
送信上限数Ｌrは、例えば、正常時に一定時間Ｔr当たりに送られてくる実リクエスト数の平均値をもとに設定される。送信上限数Ｌrは、例えば、ダミーリクエストの送信上限数Ｄ（ｔ）を含む。ダミーリクエストの送信上限数Ｄ（ｔ）は、例えば、期間ｔよりも間の期間（例えば、直前の期間（ｔ－１））に受信した通信先への実リクエスト数に応じて決定される。
【0086】
より詳細に説明すると、例えば、送信上限数Ｌrは、実リクエストの送信上限数Ｌn（ｔ）と、ダミーリクエストの送信上限数Ｄ（ｔ）とを含む。実リクエストの送信上限数Ｌn（ｔ）は、期間ｔにおける実リクエストの送信上限数である。ダミーリクエストの送信上限数Ｄ（ｔ）は、期間ｔにおけるダミーリクエストの送信上限数である。
【0087】
そして、復旧検出部５０３は、期間ｔの直前の期間（ｔ－１）に受信した通信先への実リクエスト数に応じて、期間ｔにおけるダミーリクエストの送信上限数Ｄ（ｔ）決定する。また、復旧検出部５０３は、決定したダミーリクエストの送信上限数Ｄ（ｔ）から、期間ｔにおける実リクエストの送信上限数Ｌn（ｔ）を決定する。
【0088】
なお、期間ｔにおける送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））の決定例については、図７を用いて後述する。
【0089】
また、復旧検出部５０３は、期間ｔにおいて、送信上限数Ｌrを超えないようにリクエスト（実リクエストまたはダミーリクエスト）を送信するにあたり、リクエストの送信間隔が等間隔となるように、各リクエストの送信タイミングを制御してもよい。これにより、復旧検出部５０３は、通信先の負荷の急激な上昇を抑えることができる。
【0090】
また、復旧検出部５０３は、受信した通信先への実リクエストのうち、送信上限数Ｌr（例えば、Ｌn（ｔ））を超えるために送信しない実リクエストに対してエラー応答を返す。
【0091】
また、復旧検出部５０３は、送信したリクエストの成功数が閾値Ｌsucに達したことに応じて、通信先の障害からの復旧を検出する。ここで、閾値Ｌsucは、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、閾値Ｌsucは、「Ｌsuc＝１０」である。
【0092】
閾値Ｌsucは、リクエストの成功数が閾値Ｌsucに達すると、通信先が障害から復旧したと判断できる値に設定される。リクエストの成功数は、送信したリクエストが連続して成功した回数である。以下の説明では、リクエストの成功数を「リクエスト成功数Ｃsuc」と表記する場合がある。
【0093】
また、復旧検出部５０３は、リクエスト成功数Ｃsucが閾値Ｌsucに達する前に、送信したリクエストのいずれかに失敗した場合、リクエスト成功数Ｃsucに基づいて、タイマー時間ＴW（第２の待ち時間）を決定する。
【0094】
具体的には、例えば、復旧検出部５０３は、リクエスト成功数Ｃsucが多いほど、時間長が短くなるように、タイマー時間ＴWを決定する。この際、復旧検出部５０３は、タイマー時間Ｔp1（第１の待ち時間）よりも時間長が短くなるように、タイマー時間ＴWを決定してもよい。
【0095】
より詳細に説明すると、例えば、復旧検出部５０３は、下記式（１）を用いて、閾値Ｌsucに対するリクエスト成功数Ｃsucの割合が高いほど、時間長が短くなるように、タイマー時間ＴWを決定してもよい。Ｒは、最大の待機時間である。Ｒは、任意に設定可能であり、例えば、定数テーブル２２０から特定される。図４の例では、Ｒは、「Ｒ＝６０［秒］」である。
【0096】
ＴW＝（１－Ｃsuc／Ｌsuc）×Ｒ ・・・（１）
【0097】
一例として、リクエスト成功数Ｃsucを「Ｃsuc＝４」とし、閾値Ｌsucを「Ｌsuc＝１０」とし、Ｒを「Ｒ＝６０［秒］」する。この場合、タイマー時間ＴWは、上記式（１）から、「ＴW＝３６［秒］（＝（１－４／１０）×６０」）となる。なお、上記式（１）では、例えば、Ｒをタイマー時間Ｔp1（第１の待ち時間）と同じ時間とすることで、タイマー時間Ｔp1よりも時間長が短くなるように、タイマー時間ＴWを決定することができる。
【0098】
処理装置Ｍｉは、通信先の障害からの復旧を検出した場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＣｌｏｓｅに遷移する。一方、処理装置Ｍｉは、リクエスト成功数Ｃsucが閾値Ｌsucに達する前に、送信したリクエストのいずれかに失敗した場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＷａｉｔｉｎｇに遷移する。
【0099】
ただし、処理装置Ｍｉは、通信先の通信復旧を検出した後、通信先に最初に送信したリクエストに失敗した場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＰｏｌｌｉｎｇに遷移してもよい。この場合、ポーリング部５０２は、タイマー時間Ｔp1待機した後、ポーリングにより通信先の通信復旧を検出してもよい。
【0100】
これにより、処理装置Ｍｉは、通信先が通常のリクエストを処理できる程度までは復旧していないと判断することができる。この場合、処理装置Ｍｉは、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＰｏｌｌｉｎｇに戻ることができる。
【0101】
待機部５０４は、決定されたタイマー時間ＴW（第２の待ち時間）待機する（Ｗａｉｔｉｎｇ）。待機部５０４は、タイマー時間ＴWの待機中に、通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返す。
【0102】
処理装置Ｍｉは、タイマー時間ＴW（第２の待ち時間）待機した場合、ＷａｉｔｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する。
【0103】
また、復旧検出部５０３は、タイマー時間ＴW（第２の待ち時間）待機した後、所定の時間間隔で区切った期間ごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信する。
【0104】
具体的には、例えば、復旧検出部５０３は、タイマー時間ＴW待機した後、一定時間Ｔrで区切った期間ｔごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信する。
【0105】
なお、処理装置Ｍｉは、タイマー時間ＴW（第２の待ち時間）待機した後、通信先に最初に送信したリクエストに失敗した場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＰｏｌｌｉｎｇに遷移してもよい。この場合、ポーリング部５０２は、タイマー時間Ｔp1待機した後、ポーリングにより通信先の通信復旧を検出してもよい。
【0106】
（送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））の決定例）
つぎに、図７を用いて、送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））の決定例について説明する。
つぎに、図７を用いて、送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））の決定例について説明する。
【0107】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋでは、処理装置Ｍｉは、通信先に対して、一定の頻度を上限にリクエストを送ることで、通信先にかかる負荷を抑えつつ復旧を検出する。このため、処理装置Ｍｉは、実リクエスト数が少ないと予測されるときには、ダミーリクエストで補うことで、一定のリクエスト数を確保する。
【0108】
一方で、実際に送られてくる実リクエスト数を事前に正確に予測するのは難しい。そこで、隣接した期間に送られる実リクエスト数は、ある程度相関があると仮定する。この場合、ある期間における実リクエスト数は、直前の期間の実リクエスト数から予測することができる。
【0109】
ここでは、一定時間Ｔrで区切った期間ｔを、『期間「ｔ＝０」、期間「ｔ＝１」、期間「ｔ＝２」、期間「ｔ＝３」、期間「ｔ＝４」、期間「ｔ＝５」、期間「ｔ＝６」、…』とする。そして、復旧検出部５０３は、期間ｔの直前の期間（ｔ－１）に受信した通信先への実リクエスト数に基づいて、期間ｔにおける送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））を決定する。
【0110】
具体的には、例えば、復旧検出部５０３は、下記式（２）および（３）を用いて、期間ｔのダミーリクエストの送信上限数Ｄ（ｔ）を算出する。ただし、Ｎr（ｔ－１）は、期間（ｔ－１）に受信した実リクエスト数である。例えば、Ｎr（０）は、期間「ｔ＝０」に受信した実リクエスト数に相当する。Ｌrは、単位時間（一定時間Ｔr）あたりのリクエストの上限値に相当する。
【0111】
ｔ＝０のとき、Ｄ（０）＝０ ・・・（２）
ｔ＞０のとき、Ｄ（ｔ）＝ｍａｘ（Ｌr－Ｎr（ｔ－１），０） ・・・（３）
ｔ＞０のとき、Ｄ（ｔ）＝ｍａｘ（Ｌr－Ｎr（ｔ－１），０） ・・・（３）
【0112】
つぎに、復旧検出部５０３は、下記式（４）を用いて、期間ｔの実リクエストの送信上限数Ｌn（ｔ）を算出する。
【0113】
Ｌn（ｔ）＝Ｌr－Ｄ（ｔ） ・・・（４）
【0114】
この場合、期間ｔに送信する実リクエスト数Ｎs（ｔ）は、下記式（５）のようになる。なお、Ｎr（ｔ）＞Ｎs（ｔ）となる場合、溢れた実リクエストについては、通信先に送信されず、エラー応答が返される。
【0115】
Ｎs（ｔ）＝ｍｉｎ（Ｌn（ｔ），Ｎr（ｔ）） ・・・（５）
【0116】
図７は、送信上限数の決定例を示す説明図である。図７において、表７００は、期間ｔごとのＮr（ｔ）、Ｄ（ｔ）、Ｎs（ｔ）およびエラー応答を返す実リクエスト数を示す。Ｎs（ｔ）は、上記式（５）のように、期間ｔの実リクエストの送信上限数Ｌn（ｔ）をもとに算出される。ただし、送信上限数Ｌrを「Ｌr＝５」とする。
【0117】
期間「ｔ＝０」では、最初の期間のため、Ｄ（０）が「０」となっている。また、Ｎr（０）が「２」であり、Ｌr以下である。このため、Ｎs（０）が「２」となり、エラー応答を返す実リクエスト数が「０」となっている。
【0118】
また、期間「ｔ＝１」では、Ｎr（０）が「２」のため、Ｄ（１）が「３」となっている。また、Ｎr（１）が「０」のため、Ｎs（１）が「０」となり、エラー応答を返す実リクエスト数が「０」となっている。
【0119】
また、期間「ｔ＝２」では、Ｎr（１）が「０」のため、Ｄ（２）が「５」となっている。また、Ｎr（２）が「１」となっているものの、Ｄ（２）が「５」のため、実リクエストを送信すると送信上限数Ｌrを超える。このため、実リクエストは送信されず、エラー応答を返す実リクエスト数が「１」となっている。
【0120】
また、期間「ｔ＝３」では、Ｎr（２）が「１」のため、Ｄ（３）が「４」となっている。また、Ｎr（３）が「４」となっているものの、Ｄ（３）が「４」のため、実リクエストを全て送信すると送信上限数Ｌrを超える。このため、一部の実リクエスト（３つの実リクエスト）は送信されず、エラー応答を返す実リクエスト数が「３」となっている。
【0121】
また、期間「ｔ＝４」では、Ｎr（３）が「４」のため、Ｄ（４）が「１」となっている。また、Ｎr（４）が「５」となっているものの、Ｄ（４）が「１」のため、実リクエストを全て送信すると送信上限数Ｌrを超える。このため、一部の実リクエスト（１つの実リクエスト）は送信されず、エラー応答を返す実リクエスト数が「１」となっている。
【0122】
また、期間「ｔ＝５」では、Ｎr（４）が「５」のため、Ｄ（５）が「０」となっている。また、Ｎr（５）が「７」となっているものの、実リクエストを全て送信すると送信上限数Ｌrを超える。このため、一部の実リクエスト（２つの実リクエスト）は送信されず、エラー応答を返す実リクエスト数が「２」となっている。
【0123】
各グラフ７０１～７０６は、各期間「ｔ＝０，１，２，３，４，５」における、送信するダミーリクエスト数、送信する実リクエスト数およびエラー応答を返す実リクエスト数を示す。各グラフ７０１～７０６によれば、受信する実リクエスト数が少ないときにはダミーリクエストで補い、受信する実リクエスト数が多いときにはダミーリクエストを減らすことで、通信先に対するリクエスト数を確保できていることが確認できる。
【0124】
（タイマー時間Ｔp1の更新例）
つぎに、タイマー時間Ｔp1（第１の待ち時間）の更新例について説明する。
つぎに、タイマー時間Ｔp1（第１の待ち時間）の更新例について説明する。
【0125】
ポーリング部５０２は、通信先の障害が検出され、ＣｌｏｓｅからＰｏｌｌｉｎｇの状態に遷移した際に、タイマー時間Ｔp1の待機を行う。この待機は、通信先がダウンしていることを検出した際に、通信先に負荷を与えないためである。
【0126】
一方で、通信先の復旧時間は、システム（サービス）ごとに異なることがある。このため、タイマー時間Ｔp1に共通の値を設定すると、システムによっては長すぎたり短すぎたりする可能性がある。そこで、ポーリング部５０２は、タイマー時間Ｔp1を更新することにしてもよい。
【0127】
具体的には、例えば、ポーリング部５０２は、通信先の障害を検出した回数のうち、通信先の通信復旧を検出した際に、ｐｉｎｇおよびダミーリクエストがともに１回目に成功した回数の割合に基づいて、タイマー時間Ｔp1を更新してもよい。例えば、ポーリング部５０２は、この割合が高いほど、時間長が短くなるようにタイマー時間Ｔp1を更新する。
【0128】
より詳細に説明すると、例えば、ポーリング部５０２は、図６に示した成否情報記録テーブル６００を参照して、通信先の障害を検出した直近１０回のうち、通信先の通信復旧を検出した際に、ｐｉｎｇおよびダミーリクエストがともに１回目に成功した回数Ｓを特定する。
【0129】
そして、ポーリング部５０２は、下記式（６）～（８）を用いて、特定した回数Ｓに基づいて、タイマー時間Ｔp1を更新する。ただし、Ｔp1(new)は、更新後のタイマー時間Ｔp1を示す。Ｔp1(old)は、更新前のタイマー時間Ｔp1を示す。αは、１未満の定数（例えば、０．９）である。βは、１より大きい定数（例えば、１．１）である。
【0130】
Ｔp1(new)＝Ｔp1(old)×α （Ｓ≧１０） ・・・（６）
Ｔp1(new)＝Ｔp1(old) （Ｓ＝９） ・・・（７）
Ｔp1(new)＝Ｔp1(old)×β （Ｓ≦８） ・・・（８）
Ｔp1(new)＝Ｔp1(old) （Ｓ＝９） ・・・（７）
Ｔp1(new)＝Ｔp1(old)×β （Ｓ≦８） ・・・（８）
【0131】
また、ポーリング部５０２は、下記式（９）～（１１）を用いて、特定した回数Ｓに基づいて、タイマー時間Ｔp1を更新してもよい。ただし、γ、δは、正の定数（例えば、１［秒］）である。
【0132】
Ｔp1(new)＝Ｔp1(old)－γ （Ｓ≧１０） ・・・（９）
Ｔp1(new)＝Ｔp1(old) （Ｓ＝９） ・・・（１０）
Ｔp1(new)＝Ｔp1(old)＋δ （Ｓ≦８） ・・・（１１）
Ｔp1(new)＝Ｔp1(old) （Ｓ＝９） ・・・（１０）
Ｔp1(new)＝Ｔp1(old)＋δ （Ｓ≦８） ・・・（１１）
【0133】
上記式（６）～（８）または上記式（９）～（１１）によれば、直近１０回のうち回数Ｓが１０回の場合は時間長を短くし、回数Ｓが８回以下の場合は時間長を長くすることで、回復率が９０％の待機時間に収束する。なお、上記式（６）～（８）または上記式（９）～（１１）のいずれを用いてタイマー時間Ｔp1を更新するのかは、例えば、適用するシステムに応じて決定される。
【0134】
【0135】
図８Ａは、タイマー時間Ｔp1の第１の更新例を示す説明図である。図８Ａにおいて、グラフ８１０は、復旧時間に応じた回復率を示す。回復率は、ｐｉｎｇおよびダミーリクエストがともに１回目に成功する割合を示す。図８Ａの例では、回復率が９０％となる待機時間「９０［ｓ］（図８Ａ中、符号８１２）」が、初期設定時間「６０［ｓ］（図８Ａ中、符号８１１）」よりも大きい。この場合、タイマー時間Ｔp1が延長されるように更新されていく。
【0136】
図８Ｂは、タイマー時間Ｔp1の第２の更新例を示す説明図である。８Ｂにおいて、グラフ８２０は、復旧時間に応じた回復率を示す。図８Ｂの例では、回復率が９０％となる待機時間「４０［ｓ］（図８Ｂ中、符号８２２）」が、初期設定時間「６０［ｓ］（図８Ｂ中、符号８２１）」よりも小さい。この場合、タイマー時間Ｔp1が短縮されるように更新されていく。
【0137】
（処理装置Ｍｉにおける状態遷移例）
つぎに、図９を用いて、処理装置Ｍｉにおける状態遷移例について説明する。
つぎに、図９を用いて、処理装置Ｍｉにおける状態遷移例について説明する。
【0138】
図９は、処理装置Ｍｉにおける状態遷移例を示す説明図である。図９において、状態遷移図９００は、処理装置Ｍｉにおける状態遷移を表す。処理装置Ｍｉは、Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇの４つの状態を有する。
【0139】
Ｃｌｏｓｅは、受信した全ての実リクエストを通し、結果を返す状態である。Ｃｌｏｓｅは、初期状態に相当する。Ｃｌｏｓｅからは、Ｐｏｌｌｉｎｇに遷移（矢印９０１）する場合がある。
【0140】
Ｐｏｌｌｉｎｇは、ｐｉｎｇ等により通信先の復旧状況を確認する状態である。Ｐｏｌｌｉｎｇでは、処理装置Ｍｉは、受信した実リクエストを全て遮断してエラーを返す。Ｐｏｌｌｉｎｇからは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移（矢印９０２）する場合がある。
【0141】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋは、受信した実リクエストやダミーリクエストを試して、通信先の障害からの復旧を確認する状態である。Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋでは、処理装置Ｍｉは、受信した実リクエストのうち、送信しない一部の実リクエストに対してエラーを返す。
【0142】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋからは、Ｐｏｌｌｉｎｇに遷移（矢印９０３）する場合と、Ｗａｉｔｉｎｇに遷移（矢印９０４）する場合と、Ｃｌｏｓｅに遷移（矢印９０５）する場合とがある。Ｗａｉｔｉｎｇは、Ｐｏｌｌｉｎｇよりも通信先の復旧が近い状態という位置付けである。このため、通信先の復旧が近いといえる場合は、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋから、Ｐｏｌｌｉｎｇへは遷移せず、Ｗａｉｔｉｎｇに遷移する。
【0143】
Ｗａｉｔｉｎｇは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋでのリクエストの成功数（Ｃsuc）に応じたタイマー時間ＴW待機する状態である。Ｗａｉｔｉｎｇでは、Ｗａｉｔｉｎｇからは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移（矢印９０６）する場合がある。
【0144】
（情報処理システム２００の動作例）
つぎに、図１０～図１２を用いて、情報処理システム２００の動作例について説明する。ここでは、処理装置Ｍ１を「Ｗｅｂサーバ」とし、処理装置Ｍ２を「ＡＰサーバ」とし、処理装置Ｍ３を「ＤＢサーバ」とし、ＷｅｂサーバＭ１、ＡＰサーバＭ２およびＤＢサーバＭ３が連携してサービスを提供する場合を想定する。また、ＡＰサーバＭ２の通信先であるＤＢサーバＭ３において障害が発生する場合を想定する。
つぎに、図１０～図１２を用いて、情報処理システム２００の動作例について説明する。ここでは、処理装置Ｍ１を「Ｗｅｂサーバ」とし、処理装置Ｍ２を「ＡＰサーバ」とし、処理装置Ｍ３を「ＤＢサーバ」とし、ＷｅｂサーバＭ１、ＡＰサーバＭ２およびＤＢサーバＭ３が連携してサービスを提供する場合を想定する。また、ＡＰサーバＭ２の通信先であるＤＢサーバＭ３において障害が発生する場合を想定する。
【0145】
図１０～図１２は、情報処理システム２００の動作例を示す説明図である。図１０において、ＡＰサーバＭ２は、ＷｅｂサーバＭ１からリクエストを受信する。ＡＰサーバＭ２へのリクエストは、利用者端末２０１からのリクエストに応じてＷｅｂサーバＭ１から送信される。
【0146】
なお、図１０～図１２中、リクエストは、実際のリクエストを示す。リクエスト（ｐｉｎｇ）は、ｐｉｎｇを示す。リクエスト（ダミー）は、ダミーリクエスト示す。レスポンス（成功）は、リクエストに成功した場合のレスポンスを示す。レスポンス（失敗）は、リクエストに失敗した場合のレスポンスを示す。また、Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇは、ＡＰサーバＭ２の状態を示す。
【0147】
Ｃｌｏｓｅにおいて、ＡＰサーバＭ２は、ＷｅｂサーバＭ１から受信した全てのリクエストをＤＢサーバＭ３に送信する。そして、ＡＰサーバＭ２は、送信したリクエストに対する結果（レスポンス）を、ＷｅｂサーバＭ１に送信する。
【0148】
また、ＡＰサーバＭ２は、ＤＢサーバＭ３に対するリクエストの失敗数が閾値Ｌfailに達した場合、ＤＢサーバＭ３の障害を検出する。ここでは、ＤＢサーバＭ３がダウンしたため、その後リクエストの失敗数が閾値Ｌfailに達し、ＤＢサーバＭ３の障害が検出された場合を想定する。
【0149】
この場合、ＡＰサーバＭ２は、ＣｌｏｓｅからＰｏｌｌｉｎｇに遷移して、タイマー時間Ｔp1（図１０中、符号１００１に相当）待機する。ＡＰサーバＭ２は、タイマー時間Ｔp1待機した後、ＤＢサーバＭ３に時間間隔Ｔp2でｐｉｎｇを送信する（図１０中、符号１００２に相当）。Ｐｏｌｌｉｎｇでは、ＡＰサーバＭ２は、受信した全てのリクエストに対して、エラー応答を送信する。
【0150】
図１１において、ＡＰサーバＭ２は、ｐｉｎｇに成功した場合、ＤＢサーバＭ３に時間間隔Ｔp3でダミーリクエストを送信する。ここでは、１回目のダミーリクエストに成功した場合を想定する（図１１中、符号１１０１に相当）。この場合、ＡＰサーバＭ２は、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する。
【0151】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおいて、ＡＰサーバＭ２は、一定時間Ｔrで区切った期間ごとに、送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））を超えないように、受信したリクエスト、または、ダミーリクエストのいずれかのリクエストをＤＢサーバＭ３に定期的に送信する（図１１中、符号１１０２に相当）。
【0152】
そして、ＡＰサーバＭ２は、リクエスト成功数Ｃsucが閾値Ｌsucに達したか否かを判断する。Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋでは、ＡＰサーバＭ２は、受信するＤＢサーバＭ３へのリクエスト数が少ない場合であっても、ダミーリクエストで補完することで、ＤＢサーバＭ３の障害からの復旧の検出を早めることができる。
【0153】
ここでは、閾値Ｌsucを「Ｌsuc＝２」とする。また、図１１の例では、ＤＢサーバＭ３へのリクエストが２回連続成功して、リクエスト成功数Ｃsucが閾値Ｌsucに達した場合を想定する。この場合、ＡＰサーバＭ２は、ＤＢサーバＭ３の障害からの復旧を検出して、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＣｌｏｓｅに遷移する。
【0154】
これにより、ＡＰサーバＭ２は、ＤＢサーバＭ３が障害から復旧したら、障害の伝播を遮断した状態から元の状態に直ちに戻すことができる。例えば、ＡＰサーバＭ２は、実際にＤＢサーバＭ３が復旧してから、その復旧を検出するまでのタイムラグ１１０３を小さくすることができる。
【0155】
つぎに、図１２を用いて、ＤＢサーバＭ３が復旧途中の不安定な状態のため、リクエスト成功数Ｃsucが閾値Ｌsucに達する前にリクエストに失敗した場合について説明する。
【0156】
図１２において、ＡＰサーバＭ２は、ｐｉｎｇに成功した場合、ＤＢサーバＭ３に時間間隔Ｔp3でダミーリクエストを送信する。ここでは、１回目のダミーリクエストに成功した場合を想定する（図１２中、符号１２０１に相当）。この場合、ＡＰサーバＭ２は、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する。
【0157】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおいて、ＡＰサーバＭ２は、一定時間Ｔrで区切った期間ごとに、送信上限数Ｌr（Ｌn（ｔ），Ｄ（ｔ））を超えないように、受信したリクエスト、または、ダミーリクエストのいずれかのリクエストをＤＢサーバＭ３に定期的に送信する（図１２中、符号１２０２に相当）。
【0158】
ここでは、１回目のリクエストに成功した後、２回目のリクエストに失敗した場合を想定する（図１２中、符号１２０３に相当）。ＡＰサーバＭ２は、リクエスト成功数Ｃsucが閾値Ｌsucに達する前に、リクエストに失敗した場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＷａｉｔｉｎｇに遷移する。また、ＡＰサーバＭ２は、リクエスト成功数Ｃsucに基づいて、タイマー時間ＴWを決定する。
【0159】
Ｗａｉｔｉｎｇにおいて、ＡＰサーバＭ２は、タイマー時間ＴW（図１２中、符号１２０４に相当）待機する。Ｗａｉｔｉｎｇでは、ＡＰサーバＭ２は、受信した全てのリクエストに対して、エラー応答を送信する。そして、ＡＰサーバＭ２は、タイマー時間ＴW待機した後、ＷａｉｔｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する。
【0160】
Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおいて、ＡＰサーバＭ２は、リクエスト成功数Ｃsucが閾値Ｌsucに達した場合、ＤＢサーバＭ３の障害からの復旧を検出して、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＣｌｏｓｅに遷移する。ここでは、ＤＢサーバＭ３へのリクエストが２回連続成功して、リクエスト成功数Ｃsucが閾値Ｌsucに達したため、ＡＰサーバＭ２はＣｌｏｓｅに遷移する。
【0161】
これにより、ＡＰサーバＭ２は、ＤＢサーバＭ３が障害から復旧したら、障害の伝播を遮断した状態から元の状態に直ちに戻すことができる。例えば、ＡＰサーバＭ２は、実際にＤＢサーバＭ３が復旧してから、その復旧を検出するまでのタイムラグ１２０５を小さくすることができる。
【0162】
（処理装置Ｍｉの情報処理手順）
つぎに、処理装置Ｍｉの各状態（Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇ）における情報処理手順について説明する。まず、図１３を用いて、処理装置ＭｉのＣｌｏｓｅにおける情報処理手順について説明する。
つぎに、処理装置Ｍｉの各状態（Ｃｌｏｓｅ、Ｐｏｌｌｉｎｇ、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋおよびＷａｉｔｉｎｇ）における情報処理手順について説明する。まず、図１３を用いて、処理装置ＭｉのＣｌｏｓｅにおける情報処理手順について説明する。
【0163】
図１３は、処理装置ＭｉのＣｌｏｓｅにおける情報処理手順の一例を示すフローチャートである。図１３のフローチャートにおいて、まず、処理装置Ｍｉは、エラー数Ｃfailを「Ｃfail＝０」で初期化する（ステップＳ１３０１）。エラー数Ｃfailは、通信先に対するリクエスト（実リクエスト）の失敗数を示す。
【0164】
つぎに、処理装置Ｍｉは、通信先に対するリクエストを受信したか否かを判断する（ステップＳ１３０２）。ここで、処理装置Ｍｉは、通信先に対するリクエストを受信するのを待つ（ステップＳ１３０２：Ｎｏ）。そして、処理装置Ｍｉは、通信先に対するリクエストを受信した場合（ステップＳ１３０２：Ｙｅｓ）、受信したリクエストを通信先に送信する（ステップＳ１３０３）。
【0165】
つぎに、処理装置Ｍｉは、送信したリクエストに対してエラーレスポンスを受信したか否かを判断する（ステップＳ１３０４）。ここで、エラーレスポンスを受信していない場合（ステップＳ１３０４：Ｎｏ）、処理装置Ｍｉは、ステップＳ１３０２に戻る。
【0166】
一方、エラーレスポンスを受信した場合（ステップＳ１３０４：Ｙｅｓ）、処理装置Ｍｉは、エラー数Ｃfailをインクリメントする（ステップＳ１３０５）。そして、処理装置Ｍｉは、エラー数Ｃfailが閾値Ｌfailに達したか否かを判断する（ステップＳ１３０６）。
【0167】
ここで、エラー数Ｃfailが閾値Ｌfailに達していない場合（ステップＳ１３０６：Ｎｏ）、処理装置Ｍｉは、ステップＳ１３０２に戻る。一方、エラー数Ｃfailが閾値Ｌfailに達した場合（ステップＳ１３０６：Ｙｅｓ）、処理装置Ｍｉは、Ｐｏｌｌｉｎｇに遷移して（ステップＳ１３０７）、本フローチャートによる一連の処理を終了する。
【0168】
これにより、処理装置Ｍｉは、通信先の障害を検出して、ＣｌｏｓｅからＰｏｌｌｉｎｇに状態遷移することができる。
【0169】
つぎに、図１４を用いて、処理装置ＭｉのＰｏｌｌｉｎｇにおける情報処理手順について説明する。
【0170】
図１４は、処理装置ＭｉのＰｏｌｌｉｎｇにおける情報処理手順の一例を示すフローチャートである。図１４のフローチャートにおいて、まず、処理装置Ｍｉは、タイマー時間Ｔp1待機する（ステップＳ１４０１）。つぎに、処理装置Ｍｉは、通信先にｐｉｎｇを送信する（ステップＳ１４０２）。
【0171】
そして、処理装置Ｍｉは、ｐｉｎｇが成功したか否かを判断する（ステップＳ１４０３）。ここで、ｐｉｎｇが失敗した場合（ステップＳ１４０３：Ｎｏ）、処理装置Ｍｉは、一定時間Ｔp2待機して（ステップＳ１４０４）、ステップＳ１４０２に戻る。
【0172】
一方、ｐｉｎｇが成功した場合（ステップＳ１４０３：Ｙｅｓ）、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyを「Ｃdummy＝０」で初期化する（ステップＳ１４０５）。そして、処理装置Ｍｉは、通信先にダミーリクエストを送信する（ステップＳ１４０６）。
【0173】
そして、処理装置Ｍｉは、ダミーリクエストが成功したか否かを判断する（ステップＳ１４０７）。ここで、ダミーリクエストが失敗した場合（ステップＳ１４０７：Ｎｏ）、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyをインクリメントする（ステップＳ１４０８）。
【0174】
そして、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達したか否かを判断する（ステップＳ１４０９）。ここで、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達した場合（ステップＳ１４０９：Ｙｅｓ）、処理装置Ｍｉは、ステップＳ１４０２に戻る。
【0175】
一方、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達していない場合（ステップＳ１４０９：Ｎｏ）、処理装置Ｍｉは、一定時間Ｔp3待機して（ステップＳ１４１０）、ステップＳ１４０６に戻る。
【0176】
また、ステップＳ１４０７において、ダミーリクエストが成功した場合（ステップＳ１４０７：Ｙｅｓ）、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移して（ステップＳ１４１１、本フローチャートによる一連の処理を終了する。
【0177】
これにより、処理装置Ｍｉは、ＯＳＩ７階層参照モデルの低層の通信から順に要求（ｐｉｎｇ、ダミーリクエスト）を送信して応答を確認することで、通信先の復旧状態を段階的に判断することができる。また、処理装置Ｍｉは、ダミーリクエストが処理できる程度に通信先の復旧状態が進んだ場合に、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに状態遷移することができる。
【0178】
【0179】
図１５～図１９は、処理装置ＭｉのＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおける情報処理手順の一例を示すフローチャートである。図１５のフローチャートにおいて、まず、処理装置Ｍｉは、リクエスト成功数Ｃsucを「Ｃsuc＝０」で初期化する（ステップＳ１５０１）。そして、処理装置Ｍｉは、定数テーブル２２０から、送信上限数Ｌrを取得する（ステップＳ１５０２）。
【0180】
つぎに、処理装置Ｍｉは、実リクエスト数Ｃactを「Ｃact＝０」で初期化する（ステップＳ１５０３）。そして、処理装置Ｍｉは、上記式（２）および（３）を用いて、期間ｔのダミーリクエスト数Ｄ（ｔ）を算出する（ステップＳ１５０４）。Ｄ（ｔ）は、期間ｔにおけるダミーリクエストの送信上限数に相当する。
【0181】
つぎに、処理装置Ｍｉは、上記式（４）を用いて、期間ｔの実リクエスト上限数Ｌn（ｔ）を算出する（ステップＳ１５０５）。Ｌn（ｔ）は、期間ｔにおける実リクエストの送信上限数に相当する。そして、処理装置Ｍｉは、Ｄ（ｔ）が０であるか否かを判断する（ステップＳ１５０６）。
【0182】
ここで、Ｄ（ｔ）が０ではない場合（ステップＳ１５０６：Ｎｏ）、処理装置Ｍｉは、図１６に示すステップＳ１６０１に移行する。一方、Ｄ（ｔ）が０の場合（ステップＳ１５０６：Ｙｅｓ）、処理装置Ｍｉは、一定時間Ｔr待機する（ステップＳ１５０７）。そして、処理装置Ｍｉは、待機中に通信先に対する実リクエストを受信したか否かを判断する（ステップＳ１５０８）。
【0183】
ここで、待機中に実リクエストを受信しなかった場合（ステップＳ１５０８：Ｎｏ）、処理装置Ｍｉは、ステップＳ１５０３に戻る。一方、待機中に通信先に実リクエストを受信した場合（ステップＳ１５０８：Ｙｅｓ）、処理装置Ｍｉは、図１８に示すステップＳ１８０１に移行する。なお、処理装置Ｍｉは、一定時間Ｔrの待機中に実リクエストを受信するたびに、図１８に示すステップＳ１８０１に移行する。
【0184】
図１６のフローチャートにおいて、まず、処理装置Ｍｉは、ｋを「ｋ＝０」とする（ステップＳ１６０１）。つぎに、処理装置Ｍｉは、Ｔr／Ｄ（ｔ）待機する（ステップＳ１６０２）。Ｔr／Ｄ（ｔ）は、一定時間Ｔrをダミーリクエスト数Ｄ（ｔ）で割った時間である。
【0185】
そして、処理装置Ｍｉは、待機中に通信先に対する実リクエストを受信したか否かを判断する（ステップＳ１６０３）。ここで、待機中に通信先に実リクエストを受信した場合（ステップＳ１６０３：Ｙｅｓ）、処理装置Ｍｉは、図１７に示すステップＳ１７０１に移行する。なお、処理装置Ｍｉは、Ｔr／Ｄ（ｔ）の待機中に実リクエストを受信するたびに、図１７に示すステップＳ１７０１に移行する。
【0186】
一方、待機中に通信先に実リクエストを受信しなかった場合（ステップＳ１６０３：Ｎｏ）、処理装置Ｍｉは、通信先にダミーリクエストを送信する（ステップＳ１６０４）。そして、処理装置Ｍｉは、ダミーリクエストが成功したか否かを判断する（ステップＳ１６０５）。
【0187】
ここで、ダミーリクエストが失敗した場合（ステップＳ１６０５：Ｎｏ）、処理装置Ｍｉは、図１９に示すステップＳ１９０１に移行する。一方、ダミーリクエストが成功した場合（ステップＳ１６０５：Ｙｅｓ）、処理装置Ｍｉは、リクエスト成功数Ｃsucをインクリメントする（ステップＳ１６０６）。
【0188】
そして、処理装置Ｍｉは、リクエスト成功数Ｃsucが閾値Ｌsucに達したか否かを判断する（ステップＳ１６０７）。ここで、リクエスト成功数Ｃsucが閾値Ｌsucに達していない場合（ステップＳ１６０７：Ｎｏ）、処理装置Ｍｉは、ｋをインクリメントする（ステップＳ１６０８）。
【0189】
そして、処理装置Ｍｉは、ｋがＤ（ｔ）未満であるか否かを判断する（ステップＳ１６０９）。ここで、ｋがＤ（ｔ）未満の場合（ステップＳ１６０９：Ｙｅｓ）、処理装置Ｍｉは、ステップＳ１６０２に戻る。一方、ｋがＤ（ｔ）未満ではない場合（ステップＳ１６０９：Ｎｏ）、処理装置Ｍｉは、図１５に示したステップＳ１５０３に移行する。
【0190】
また、ステップＳ１６０７において、リクエスト成功数Ｃsucが閾値Ｌsucに達した場合（ステップＳ１６０７：Ｙｅｓ）、処理装置Ｍｉは、Ｃｌｏｓｅに遷移して（ステップＳ１６１０、本フローチャートによる一連の処理を終了する。
【0191】
図１７に示すフローチャートにおいて、まず、処理装置Ｍｉは、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満であるか否かを判断する（ステップＳ１７０１）。ここで、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満の場合（ステップＳ１７０１：Ｙｅｓ）、処理装置Ｍｉは、通信先に対して実リクエストを送信する（ステップＳ１７０２）。送信する実リクエストは、図１６に示したステップＳ１６０３において待機中に受信した実リクエストに応じたリクエストである。
【0192】
つぎに、処理装置Ｍｉは、実リクエスト数Ｃactをインクリメントする（ステップＳ１７０３）。そして、処理装置Ｍｉは、送信した実リクエストが成功したか否かを判断する（ステップＳ１７０４）。ここで、実リクエストが失敗した場合（ステップＳ１７０４：Ｎｏ）、処理装置Ｍｉは、図１９に示すステップＳ１９０１に移行する。
【0193】
一方、実リクエストが成功した場合（ステップＳ１７０４：Ｙｅｓ）、処理装置Ｍｉは、リクエスト成功数Ｃsucをインクリメントする（ステップＳ１７０５）。そして、処理装置Ｍｉは、リクエスト成功数Ｃsucが閾値Ｌsucに達したか否かを判断する（ステップＳ１７０６）。
【0194】
ここで、リクエスト成功数Ｃsucが閾値Ｌsucに達していない場合（ステップＳ１７０６：Ｎｏ）、処理装置Ｍｉは、図１６に示したステップＳ１６０８に移行する。一方、リクエスト成功数Ｃsucが閾値Ｌsucに達した場合（ステップＳ１７０６：Ｙｅｓ）、処理装置Ｍｉは、Ｃｌｏｓｅに遷移して（ステップＳ１７０７）、本フローチャートによる一連の処理を終了する。
【0195】
また、ステップＳ１７０１において、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満ではない場合（ステップＳ１７０１：Ｎｏ）、処理装置Ｍｉは、受信した実リクエストに対してエラー応答を送信して（ステップＳ１７０８）、図１６に示したステップＳ１６０４に移行する。受信した実リクエストは、図１６に示したステップＳ１６０３において待機中に受信した実リクエストである。
【0196】
図１８のフローチャートにおいて、まず、処理装置Ｍｉは、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満であるか否かを判断する（ステップＳ１８０１）。ここで、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満の場合（ステップＳ１８０１：Ｙｅｓ）、処理装置Ｍｉは、通信先に対して実リクエストを送信する（ステップＳ１８０２）。送信する実リクエストは、図１５に示したステップＳ１５０８において待機中に受信した実リクエストに応じたリクエストである。
【0197】
つぎに、処理装置Ｍｉは、実リクエスト数Ｃactをインクリメントする（ステップＳ１８０３）。そして、処理装置Ｍｉは、送信した実リクエストが成功したか否かを判断する（ステップＳ１８０４）。ここで、実リクエストが失敗した場合（ステップＳ１８０４：Ｎｏ）、処理装置Ｍｉは、図１９に示すステップＳ１９０１に移行する。
【0198】
一方、実リクエストが成功した場合（ステップＳ１８０４：Ｙｅｓ）、処理装置Ｍｉは、リクエスト成功数Ｃsucをインクリメントする（ステップＳ１８０５）。そして、処理装置Ｍｉは、リクエスト成功数Ｃsucが閾値Ｌsucに達したか否かを判断する（ステップＳ１８０６）。
【0199】
ここで、リクエスト成功数Ｃsucが閾値Ｌsucに達していない場合（ステップＳ１８０６：Ｎｏ）、処理装置Ｍｉは、一定時間Ｔrの待機の完了後に、図１５に示したステップＳ１５０３に移行する。一方、リクエスト成功数Ｃsucが閾値Ｌsucに達した場合（ステップＳ１８０６：Ｙｅｓ）、処理装置Ｍｉは、Ｃｌｏｓｅに遷移して（ステップＳ１８０７）、本フローチャートによる一連の処理を終了する。
【0200】
また、ステップＳ１８０１において、実リクエスト数Ｃactが実リクエスト上限数Ｌn（ｔ）未満ではない場合（ステップＳ１８０１：Ｎｏ）、処理装置Ｍｉは、受信した実リクエストに対してエラー応答を送信して（ステップＳ１８０８）、一定時間Ｔrの待機の完了後に、図１５に示したステップＳ１５０３に移行する。受信した実リクエストは、図１５に示したステップＳ１５０８において待機中に受信した実リクエストである。
【0201】
図１９のフローチャートにおいて、まず、処理装置Ｍｉは、リクエスト成功数Ｃsucが０であるか否かを判断する（ステップＳ１９０１）。ここで、リクエスト成功数Ｃsucが０の場合（ステップＳ１９０１：Ｙｅｓ）、処理装置Ｍｉは、Ｐｏｌｌｉｎｇに遷移して（ステップＳ１９０２）、本フローチャートによる一連の処理を終了する。
【0202】
一方、リクエスト成功数Ｃsucが０ではない場合（ステップＳ１９０１：Ｎｏ）、処理装置Ｍｉは、Ｗａｉｔｉｎｇに遷移して（ステップＳ１９０３）、本フローチャートによる一連の処理を終了する。
【0203】
これにより、処理装置Ｍｉは、通信先の障害からの復旧を検出することができる。また、処理装置Ｍｉは、受信する実リクエスト数が少ない場合であっても、ダミーリクエストで補完することで、通信先の障害からの復旧の検出を早めることができる。また、処理装置Ｍｉは、リクエストの送信間隔が等間隔（Ｔr／Ｄ（ｔ））となるように、各リクエストの送信タイミングを制御することで、通信先に対するリクエスト数を確保しつつ、通信先の負荷の急激な上昇を抑えることができる。
【0204】
つぎに、図２０を用いて、処理装置ＭｉのＷａｉｔｉｎｇにおける情報処理手順について説明する。
【0205】
図２０は、処理装置ＭｉのＷａｉｔｉｎｇにおける情報処理手順の一例を示すフローチャートである。図２０のフローチャートにおいて、まず、処理装置Ｍｉは、上記式（１）を用いて、リクエスト成功数Ｃsucに基づいて、タイマー時間ＴWを決定する（ステップＳ２００１）。つぎに、処理装置Ｍｉは、決定したタイマー時間ＴW待機する（ステップＳ２００２）。
【0206】
そして、処理装置Ｍｉは、タイマー時間ＴWの待機の完了後に、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移して（ステップＳ２００３）、本フローチャートによる一連の処理を終了する。
【0207】
これにより、処理装置Ｍｉは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋにおける通信先からのレスポンス結果（リクエスト成功数Ｃsuc）に応じて変動するタイマー時間ＴW待機してから、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移することができる。
【0208】
つぎに、図２１～図２３を用いて、Ｐｏｌｌｉｎｇにおける処理装置Ｍｉの他の情報処理手順について説明する。Ｐｏｌｌｉｎｇにおける他の情報処理では、タイマー時間Ｔp1を更新（自動チューニング）する場合について説明する。
【0209】
図２１～図２３は、処理装置ＭｉのＰｏｌｌｉｎｇにおける他の情報処理手順の一例を示すフローチャートである。図２１のフローチャートにおいて、まず、処理装置Ｍｉは、ＢpingとＢdummyを「Ｂping＝Ｂdummy＝Ｔｒｕｅ」で初期化する（ステップＳ２１０１）。
【0210】
Ｂpingは、ｐｉｎｇが１回目で成功したか否かを示す。「Ｂping＝Ｔｒｕｅ」は、ｐｉｎｇが１回目で成功したことを示す。「Ｂping＝Ｆａｌｓｅ」は、ｐｉｎｇが１回目で失敗したことを示す。また、Ｂdummyは、ダミーリクエストが１回目で成功したか否かを示す。「Ｂdummy＝Ｔｒｕｅ」は、ダミーリクエストが１回目で成功したことを示す。「Ｂdummy＝Ｆａｌｓｅ」は、ダミーリクエストが１回目で失敗したことを示す。
【0211】
そして、処理装置Ｍｉは、タイマー時間Ｔp1待機する（ステップＳ２１０２）。つぎに、処理装置Ｍｉは、通信先にｐｉｎｇを送信する（ステップＳ２１０３）。そして、処理装置Ｍｉは、ｐｉｎｇが成功したか否かを判断する（ステップＳ２１０４）。
【0212】
ここで、ｐｉｎｇが失敗した場合（ステップＳ２１０４：Ｎｏ）、処理装置Ｍｉは、Ｂpingを「Ｂping＝Ｆａｌｓｅ」とする（ステップＳ２１０５）。そして、処理装置Ｍｉは、一定時間Ｔp2待機して（ステップＳ２１０６）、ステップＳ２１０３に戻る。一方、ｐｉｎｇが成功した場合（ステップＳ２１０４：Ｙｅｓ）、処理装置Ｍｉは、図２２に示すステップＳ２２０１に移行する。
【0213】
図２２のフローチャートにおいて、まず、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyを「Ｃdummy＝０」で初期化する（ステップＳ２２０１）。つぎに、処理装置Ｍｉは、通信先にダミーリクエストを送信する（ステップＳ２２０２）。
【0214】
そして、処理装置Ｍｉは、ダミーリクエストが成功したか否かを判断する（ステップＳ２２０３）。ここで、ダミーリクエストが失敗した場合（ステップＳ２２０３：Ｎｏ）、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyをインクリメントする（ステップＳ２２０４）。
【0215】
そして、処理装置Ｍｉは、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達したか否かを判断する（ステップＳ２２０５）。ここで、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達した場合（ステップＳ２２０５：Ｙｅｓ）、処理装置Ｍｉは、図２１に示したステップＳ２１０３に戻る。
【0216】
一方、ダミーリクエストの失敗数Ｃdummyが閾値Ｌdummyに達していない場合（ステップＳ２２０５：Ｎｏ）、処理装置Ｍｉは、Ｂdummyを「Ｂdummy＝Ｆａｌｓｅ」とする（ステップＳ２２０６）。そして、処理装置Ｍｉは、一定時間Ｔp3待機して（ステップＳ２２０７）、ステップＳ２２０２に戻る。
【0217】
また、ステップＳ２２０３において、ダミーリクエストが成功した場合（ステップＳ２２０３：Ｙｅｓ）、処理装置Ｍｉは、図２３に示すステップＳ２３０１に移行する。
【0218】
図２３のフローチャートにおいて、まず、処理装置Ｍｉは、Ｓtを「Ｓt＝Ｔｒｕｅ」とする（ステップＳ２３０１）。つぎに、処理装置Ｍｉは、「Ｂping＝Ｂdummy＝Ｔｒｕｅ」であるか否かを判断する（ステップＳ２３０２）。
【0219】
ここで、「Ｂping＝Ｂdummy＝Ｔｒｕｅ」ではない場合（ステップＳ２３０２：Ｎｏ）、処理装置Ｍｉは、Ｓtを「Ｓt＝Ｆａｌｓｅ」として（ステップＳ２３０３）、ステップＳ２３０４に移行する。一方、「Ｂping＝Ｂdummy＝Ｔｒｕｅ」の場合（ステップＳ２３０２：Ｙｅｓ）、処理装置Ｍｉは、Ｓlistが定義されているか否かを判断する（ステップＳ２３０４）。
【0220】
Ｓlistは、ｐｉｎｇとダミーリクエストの両方が１回目で成功したかどうかの結果が過去１０回分入力される配列である。ｐｉｎｇとダミーリクエストのうち、両方が１回目で成功した場合は「Ｔｒｕｅ」、片方でも１回目に失敗した場合は「Ｆａｌｓｅ」が入力される。Ｓlist［０］に最も古いデータが入っており、添え字が大きくなるにつれて順に新しいデータが入る。Ｓlistは、例えば、図６に示した成否情報記録テーブル６００に対応する。
【0221】
ここで、Ｓlistが定義されていない場合（ステップＳ２３０４：Ｎｏ）、処理装置Ｍｉは、Ｓlistを「Ｓlist＝［］」で初期化して（ステップＳ２３０５）、ステップＳ２３０６に移行する。一方、Ｓlistが定義されている場合（ステップＳ２３０４：Ｙｅｓ）、処理装置Ｍｉは、Ｓlistの最後にＳtを追加する（ステップＳ２３０６）。
【0222】
つぎに、処理装置Ｍｉは、Ｓlistの長さが１０未満であるか否かを判断する（ステップＳ２３０７）。ここで、Ｓlistの長さが１０未満の場合（ステップＳ２３０７：Ｙｅｓ）、処理装置Ｍｉは、ステップＳ２３１１に移行する。
【0223】
一方、Ｓlistの長さが１０未満ではない場合（ステップＳ２３０７：Ｎｏ）、処理装置Ｍｉは、ＳlistをＳlistの後ろから１０個のデータで上書きして「Ｓlist＝［－１０：－１］」とする（ステップＳ２３０８）。そして、処理装置Ｍｉは、ＳlistからＳを算出する（ステップＳ２３０９）。Ｓは、ＳlistのＴｒｕｅの数である。
【0224】
つぎに、処理装置Ｍｉは、上記式（６）～（８）を用いて、算出したＳから、タイマー時間Ｔp1を更新する（ステップＳ２３１０）。なお、処理装置Ｍｉは、上記式（９）～（１１）を用いて、算出したＳから、タイマー時間Ｔp1を更新してもよい。そして、処理装置Ｍｉは、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移して（ステップＳ２３１１）、本フローチャートによる一連の処理を終了する。
【0225】
これにより、処理装置Ｍｉは、障害が発生した通信先の復旧状態を判断した際にｐｉｎｇとダミーリクエストの両方が１回目で成功した割合に応じて、タイマー時間Ｔp1を自動チューニングすることができる。
【0226】
以上説明したように、実施の形態にかかる処理装置Ｍｉによれば、通信先の障害を検出した場合、タイマー時間Ｔp1（第１の待ち時間）待機した後、ポーリングにより通信先の通信復旧を検出することができる。ポーリングは、例えば、ｐｉｎｇによるポーリングである。
【0227】
これにより、処理装置Ｍｉは、通信先の障害発生時に、通常のリクエストに比べて負荷の少ないリクエストを試して、通信先が通信可能な状態まで復旧（回復）したことを確認することができる。この際、処理装置Ｍｉは、通信先の障害を検出した直後は、復旧処理があまり進んでいない可能性が高いため、通信先に負荷をかけないようにタイマー時間Ｔp1待機することができる。また、処理装置Ｍｉは、ｐｉｎｇによるポーリングを利用することで、ＳＮＭＰのようなポーリングに比べて、通信先により負荷をかけずに復旧状態を確認することができる。
【0228】
また、処理装置Ｍｉによれば、通信先の通信復旧を検出した場合、一定時間Ｔrで区切った期間ｔごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信することができる。ダミーリクエストは、例えば、Ｇｅｔ要求により実現される。そして、処理装置Ｍｉによれば、リクエスト成功数Ｃsucが閾値Ｌsucに達したことに応じて、通信先の障害からの復旧を検出することができる。
【0229】
これにより、処理装置Ｍｉは、通信可能な状態まで復旧した通信先に対して、受信した実際のリクエストまたはダミーリクエストを試して、障害からの復旧を確認することができる。この際、処理装置Ｍｉは、受信する実際のリクエスト数が少ない場合であっても、ダミーリクエストで補完することで、通信先の障害からの復旧の検出を早めることができる。また、処理装置Ｍｉは、ダミーリクエストをＧｅｔ要求で実現することで、通信先にかかる負荷を抑えつつ、データ矛盾の発生を防ぐことができる。
【0230】
また、処理装置Ｍｉによれば、リクエスト成功数Ｃsucが閾値Ｌsucに達する前に、リクエストのいずれかに失敗した場合、リクエスト成功数Ｃsucに基づいて、タイマー時間ＴW（第２の待ち時間）を決定することができる。また、処理装置Ｍｉによれば、決定したタイマー時間ＴW待機した後、一定時間Ｔrで区切った期間ｔごとに、送信上限数Ｌrを超えないように、受信した通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを通信先に送信することができる。そして、処理装置Ｍｉによれば、リクエスト成功数Ｃsucが閾値Ｌsucに達したことに応じて、通信先の障害からの復旧を検出することができる。
【0231】
これにより、処理装置Ｍｉは、通信先が通信は復旧しているものの一部のリクエストはエラーとなるような不安定な状態の場合には、通信先に負荷をかけないように一旦待機して、受信した実際のリクエストまたはダミーリクエストの送信を再開することができる。また、処理装置Ｍｉは、リクエスト成功数Ｃsucに応じて待機時間（タイマー時間ＴW）を変動させることで、通信先の復旧状況に応じて柔軟なタイマー監視を実施することができ、通信先の障害からの復旧を検出するタイミングの遅れを防ぐことができる。例えば、処理装置Ｍｉは、通信先の復旧が近いにもかかわらず長い待機時間を設定して、障害からの復旧検出が遅れるといった事態を回避することができる。
【0232】
また、処理装置Ｍｉによれば、リクエスト成功数Ｃsucが多いほど、時間長が短くなるように、タイマー時間ＴWを決定することができる。この際、処理装置Ｍｉは、タイマー時間Ｔp1よりも時間長が短くなるように、タイマー時間ＴWを決定してもよい。
【0233】
これにより、処理装置Ｍｉは、リクエスト成功数Ｃsucが多いほど、通信先の障害からの復旧が近いと判断して、待機時間（タイマー時間ＴW）を短くすることができる。
【0234】
また、処理装置Ｍｉによれば、期間ｔよりも前の期間（ｔ－１）に受信した通信先への実リクエスト数に応じて、ダミーリクエストの送信上限数Ｄ（ｔ）を決定することができる。具体的には、例えば、処理装置Ｍｉは、期間ｔの直前の期間（ｔ－１）に受信した通信先への実リクエスト数に応じて、ダミーリクエストの送信上限数Ｄ（ｔ）を決定する。
【0235】
これにより、処理装置Ｍｉは、通信先に対して、一定の頻度のリクエストを確保しつつ、過度な負荷をかけないような、ダミーリクエストの送信上限数Ｄ（ｔ）を決定することができる。例えば、処理装置Ｍｉは、直近の期間（ｔ－１）における実リクエスト数から、期間ｔにおいて、実リクエストをできるだけ通すような、ダミーリクエスト数（Ｄ（ｔ））を決めることができる。
【0236】
また、処理装置Ｍｉによれば、通信先の障害が検出された場合、タイマー時間Ｔp1待機した後、通信先に時間間隔Ｔp2（第１の時間間隔）でｐｉｎｇを送信し、ｐｉｎｇに成功した場合、通信先に時間間隔Ｔp3（第２の時間間隔）でダミーリクエストを送信することができる。そして、処理装置Ｍｉによれば、ダミーリクエストに成功した場合、通信先の通信復旧を検出することができる。
【0237】
これにより、処理装置Ｍｉは、通信先において障害からの復旧のためにハードリセットが行われ、ＯＳ、アプリケーションの順に起動するような場合に、通信先におけるハードウェア、ソフトウェアの復旧を段階的に確認することができる。例えば、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋへの遷移をｐｉｎｇだけで判断すると、通信先でアプリケーションが起動していない段階で、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移する可能性がある。この場合、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移後に、すぐにリクエストに対するエラーが発生してＰｏｌｌｉｎｇに戻る場合、Ｒｅｃｏｖｅｒｙ－ＣｈｅｃｋからＰｏｌｌｉｎｇへの状態遷移が頻繁に発生して復旧時間の長期化を招くおそれがある。さらに、Ｒｅｃｏｖｅｒｙ－Ｃｈｅｃｋでは、ユーザのリクエストを通信先に通すことになるため、リクエストを通した結果エラーとなる場合がある。この場合、リクエストを通さずにエラーを返す場合に比べて、トライする分、エラー応答に時間がかかり、エラーかつ応答に時間がかかるという問題が生じる。処理装置Ｍｉは、通信先におけるハードウェア、ソフトウェアの復旧を段階的に確認することで、通信先でアプリケーションが起動していない状態でのリクエストを防いで、復旧時間の長期化やエラー応答にかかる時間の長期化を防ぐことができる。
【0238】
また、処理装置Ｍｉによれば、通信先の障害を検出した回数のうち、通信先の通信復旧を検出した際に、ｐｉｎｇおよびダミーリクエストがともに１回目に成功した回数の割合に基づいて、タイマー時間Ｔp1を更新することができる。
【0239】
これにより、処理装置Ｍｉは、通信先の復旧時間がシステム（サービス）ごとに異なる場合があることを考慮して、タイマー時間Ｔp1を自動チューニングすることができる。例えば、処理装置Ｍｉは、ｐｉｎｇおよびダミーリクエストがともに１回目に成功した割合が高くなるようにタイマー時間Ｔp1を調整することで、通信先にかかる負荷を抑えつつ、通信先の通信復旧を早期に検出可能となる。
【0240】
また、処理装置Ｍｉによれば、通信先の通信復旧を検出した後、または、タイマー時間ＴW（第２の待ち時間）待機した後、通信先に最初に送信したリクエストに失敗した場合、通信先の通信復旧を検出する処理（Ｐｏｌｌｉｎｇ）に戻ることができる。例えば、処理装置Ｍｉは、ＰｏｌｌｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移した後、あるいは、ＷａｉｔｉｎｇからＲｅｃｏｖｅｒｙ－Ｃｈｅｃｋに遷移した後、通信先に最初に送信したリクエストに失敗した場合、Ｐｏｌｌｉｎｇに遷移する。
【0241】
これにより、処理装置Ｍｉは、通信先が通常のリクエストを処理できる程度まで復旧しておらず、復旧が遠い状態であるといえる場合、Ｐｏｌｌｉｎｇに戻って、通信先の通信の復旧状態を確認する処理からやり直すことができる。
【0242】
また、処理装置Ｍｉによれば、通信先の障害が検出された後、通信先の通信復旧が検出されるまでの間に、通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返すことができる。
【0243】
これにより、処理装置Ｍｉは、復旧処理中の通信先にかかる負荷を抑えることができる。また、処理装置Ｍｉは、ユーザのリクエストを通信先に通すことなくエラーを返すことで、エラー応答に時間がかかるのを防ぐことができる。
【0244】
また、処理装置Ｍｉによれば、タイマー時間ＴW（第２の待ち時間）の待機中に、通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返すことができる。
【0245】
これにより、処理装置Ｍｉは、復旧処理中の通信先にかかる負荷を抑えることができる。
【0246】
また、処理装置Ｍｉによれば、受信した通信先への実リクエストのうち、送信上限数Ｌrを超えるために送信しない実リクエストに対してエラー応答を返すことができる。
【0247】
これにより、処理装置Ｍｉは、復旧処理中の通信先にかかる負荷を抑えることができる。
【0248】
これらのことから、処理装置Ｍｉによれば、復旧中のサービスにかかる負荷を抑えつつ、サービスの復旧をいち早く検知し、要求元へのエラー応答を回避することができる。これにより、処理装置Ｍｉは、通信先を含むシステム全体の復旧時間を短縮して、トラブル解決後は直ちに元の状態に戻したいという要求を満たすことができる。
【0249】
なお、本実施の形態で説明した情報処理方法は、予め用意されたプログラムをパーソナル・コンピュータやワークステーション等のコンピュータで実行することにより実現することができる。本情報処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ－ＲＯＭ、ＤＶＤ、ＵＳＢメモリ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、本情報処理プログラムは、インターネット等のネットワークを介して配布してもよい。
【0250】
また、本実施の形態で説明した情報処理装置１０１（処理装置Ｍｉ）は、スタンダードセルやストラクチャードＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などの特定用途向けＩＣやＦＰＧＡなどのＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）によっても実現することができる。
【0251】
上述した実施の形態に関し、さらに以下の付記を開示する。
【0252】
（付記１）通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストのいずれかに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストのいずれかに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
【0253】
（付記２）前記送信上限数は、前記ダミーリクエストの送信上限数を含み、
前記期間よりも前の期間に受信した前記通信先への実リクエスト数に応じて、前記ダミーリクエストの送信上限数を決定する、ことを特徴とする付記１に記載の情報処理プログラム。
前記期間よりも前の期間に受信した前記通信先への実リクエスト数に応じて、前記ダミーリクエストの送信上限数を決定する、ことを特徴とする付記１に記載の情報処理プログラム。
【0254】
（付記３）前記ポーリングは、ｐｉｎｇによるポーリングである、ことを特徴とする付記１または２に記載の情報処理プログラム。
【0255】
（付記４）前記通信先の通信復旧を検出する処理は、
前記通信先の障害を検出した場合、前記第１の待ち時間待機した後に、前記通信先に第１の時間間隔でｐｉｎｇを送信し、
前記ｐｉｎｇに成功した場合、前記通信先に第２の時間間隔でダミーリクエストを送信し、
前記ダミーリクエストに成功した場合、前記通信先の通信復旧を検出する、
ことを特徴とする付記３に記載の情報処理プログラム。
前記通信先の障害を検出した場合、前記第１の待ち時間待機した後に、前記通信先に第１の時間間隔でｐｉｎｇを送信し、
前記ｐｉｎｇに成功した場合、前記通信先に第２の時間間隔でダミーリクエストを送信し、
前記ダミーリクエストに成功した場合、前記通信先の通信復旧を検出する、
ことを特徴とする付記３に記載の情報処理プログラム。
【0256】
（付記５）前記通信先の障害を検出した回数のうち、前記通信先の通信復旧を検出した際に、前記ｐｉｎｇおよび前記ダミーリクエストがともに１回目に成功した回数の割合に基づいて、前記第１の待ち時間を更新する、
処理を前記コンピュータに実行させることを特徴とする付記４に記載の情報処理プログラム。
処理を前記コンピュータに実行させることを特徴とする付記４に記載の情報処理プログラム。
【0257】
（付記６）前記第２の待ち時間を決定する処理は、
前記リクエストの成功数が多いほど、時間長が短くなるように、前記第２の待ち時間を決定する、ことを特徴とする付記１～５のいずれか一つに記載の情報処理プログラム。
前記リクエストの成功数が多いほど、時間長が短くなるように、前記第２の待ち時間を決定する、ことを特徴とする付記１～５のいずれか一つに記載の情報処理プログラム。
【0258】
（付記７）前記第２の待ち時間を決定する処理は、さらに、前記第１の待ち時間よりも時間長が短くなるように、前記第２の待ち時間を決定する、ことを特徴とする付記６に記載の情報処理プログラム。
【0259】
（付記８）前記通信先の通信復旧を検出した後、または、前記第２の待ち時間待機した後、前記通信先に最初に送信した前記リクエストに失敗した場合、前記通信先の通信復旧を検出する処理を前記コンピュータに再度実行させることを特徴とする付記１～７のいずれか一つに記載の情報処理プログラム。
【0260】
（付記９）前記通信先の障害が検出された後、前記通信先の通信復旧が検出されるまでの間に、前記通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返す、処理を前記コンピュータに実行させることを特徴とする付記１～８のいずれか一つに記載の情報処理プログラム。
【0261】
（付記１０）前記第２の待ち時間の待機中に、前記通信先への実リクエストを受信した場合、当該実リクエストに対してエラー応答を返す、処理を前記コンピュータに実行させることを特徴とする付記１～９のいずれか一つに記載の情報処理プログラム。
【0262】
（付記１１）受信した前記通信先への実リクエストのうち、前記送信上限数を超えるために送信しない実リクエストに対してエラー応答を返す、処理を前記コンピュータに実行させることを特徴とする付記１～１０のいずれか一つに記載の情報処理プログラム。
【0263】
（付記１２）通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータが実行することを特徴とする情報処理方法。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
処理をコンピュータが実行することを特徴とする情報処理方法。
【0264】
（付記１３）通信先の障害を検出した場合、第１の待ち時間待機した後、ポーリングにより前記通信先の通信復旧を検出し、
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
制御部を有することを特徴とする情報処理装置。
前記通信先の通信復旧を検出した場合、所定の時間間隔で区切った期間ごとに、送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が閾値に達する前に、前記リクエストに失敗した場合、前記リクエストの成功数に基づいて、第２の待ち時間を決定し、
決定した前記第２の待ち時間待機した後、前記期間ごとに、前記送信上限数を超えないように、受信した前記通信先への実リクエスト、または、ダミーリクエストの少なくともいずれかのリクエストを前記通信先に送信し、
送信した前記リクエストの成功数が前記閾値に達したことに応じて、前記通信先の前記障害からの復旧を検出する、
制御部を有することを特徴とする情報処理装置。
【符号の説明】
【0265】
１０１ 情報処理装置
１０２ 通信先
２００ 情報処理システム
２０１ 利用者端末
２０２ 管理者端末
２１０ ネットワーク
２２０ 定数テーブル
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
５０１ 障害検出部
５０２ ポーリング部
５０３ 復旧検出部
５０４ 待機部
６００ 成否情報記録テーブル
７００ 表
８１０，８２０ グラフ
９００ 状態遷移図
１０２ 通信先
２００ 情報処理システム
２０１ 利用者端末
２０２ 管理者端末
２１０ ネットワーク
２２０ 定数テーブル
３００ バス
３０１ ＣＰＵ
３０２ メモリ
３０３ ディスクドライブ
３０４ ディスク
３０５ 通信Ｉ／Ｆ
３０６ 可搬型記録媒体Ｉ／Ｆ
３０７ 可搬型記録媒体
５０１ 障害検出部
５０２ ポーリング部
５０３ 復旧検出部
５０４ 待機部
６００ 成否情報記録テーブル
７００ 表
８１０，８２０ グラフ
９００ 状態遷移図
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】