JP2020177489A - 制御方法、制御プログラム、および情報処理装置 - Google Patents

Abstract

【課題】仮想環境で動作するプロセスの不要な再起動を抑止する。【解決手段】情報処理装置１０は、ソフトウェア実行環境において動作する第１プロセス２ａ，２ｂの動作状態を示す第１監視情報と、第１プロセス２ａ，２ｂを監視する第２プロセス２ｃの動作状態を示す第２監視情報とを取得する。次に情報処理装置１０は、第１監視情報および第２監視情報に基づき、第１プロセス２ａ，２ｂおよび第２プロセス２ｃそれぞれが異常であるか否かを判定する。そして情報処理装置１０は、第１プロセス２ａ，２ｂが異常である場合、第２プロセス２ｃが異常であるか否かにより、ソフトウェア実行環境の再起動を生じさせる情報を出力する。また情報処理装置１０は、第１プロセス２ａ，２ｂが異常でない場合、第２プロセス２ｃが異常であるか否かによらず、情報の出力を抑制する。【選択図】図１

Description

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

コンピュータにおける仮想化技術の１つにコンテナ型仮想化と呼ばれる技術がある。コンテナ型仮想化では、アプリケーションの起動に用いるライブラリなどの資源を纏めたコンテナが、ソフトウェアの実行環境として定義される。コンピュータは、ＯＳ（Operating System）のカーネル上でコンテナを起動し、コンテナを用いてソフトウェアを実行する。コンテナ型仮想化では、仮想マシンを用いた仮想化に用いられるゲストＯＳが不要であり、仮想マシンを用いた仮想化に比べコンピュータの処理負荷が少なくてすむ。

コンテナは、コンテナ基盤によって管理される。コンテナ基盤は、例えばコンテナの起動、および停止を行うことができる。コンテナ基盤は、コンテナの動作状況を監視して、異常があるコンテナを再起動させることもできる。例えばコンテナ基盤は、異常な状態のコンテナを検出するために、コンテナで実行されるプロセスとの定期的なＨＴＴＰ（HyperText Transfer Protocol）通信による異常な応答の有無の監視を行う。コンテナ基盤は、コンテナの異常を検出すると、そのコンテナを再起動する。これにより、コンテナの異常な状態が解消し、コンテナを用いて実行されているプロセスの正常動作が復旧する。例えばコンテナ内に複数のプロセスが存在する場合、コンテナ基盤は、コンテナ内のｉｎｉｔプロセスと呼ばれるプロセスＩＤ（ｐｉｄ）＝１のデーモンプロセスの動作を監視し、そのプロセスに異常があれば、コンテナを再起動する。

プロセスの再起動に関する技術としては、例えばシステム内で稼動するプロセスの優先度を判断し、プロセス障害復旧の１手段であるプロセスの再起動、プロセスが稼動しているＯＳの再起動を自動的に行うプロセス障害判定復旧装置が開示されている。仮想化に関する技術としては、例えば高可用性仮想機械環境において稼働するアプリケーションの高可用性を提供するための様々なシステムが提案されている。また複数の仮想サーバの適切な識別及びＩＤ情報管理などにより、複数の仮想サーバに関する詳細な監視などを実現することができる技術も提案されている。

特開２０１２−２５６２２７号公報 特表２０１３−５３５７４５号公報 特開２０１２−２０８６０５号公報

コンテナ内に複数のプロセスが存在する場合、監視対象のプロセスに異常が発生しても、他のプロセスが正常に動作していれば、コンテナで実行するソフトウェアとしては正常に動作している場合がある。例えばコンテナ基盤が監視対象とするｐｉｄ＝１のデーモンプロセスは、ユーザが使用するソフトウェアに関連する実質的な処理を行っていない。そのため監視対象のプロセスに異常があっても、他のプロセスが正常に動作している限り、コンテナを用いて実行されているソフトウェアの機能は正しく動作する。それにもかかわらず、従来は、監視対象のプロセスに異常があれば、コンテナの再起動によりコンテナ内の全プロセスの再起動が行われ、正常に動作していたソフトウェアの処理が中断されてしまう。その結果、仮想環境で動作するプロセスによる処理の可用性（処理を継続して実行できる能力）が低下してしまう。

１つの側面では、本件は、仮想環境で動作するプロセスの不要な再起動を抑止することを目的とする。

１つの案では、コンピュータが以下の処理を実行する制御方法が提供される。
当該制御方法では、コンピュータは、ソフトウェア実行環境において動作する第１プロセスの動作状態を示す第１監視情報と、ソフトウェア実行環境において第１プロセスを監視する第２プロセスの動作状態を示す第２監視情報とを取得する。次にコンピュータは、第１監視情報および第２監視情報に基づき、第１プロセスおよび第２プロセスそれぞれが異常であるか否かを判定する。そしてコンピュータは、判定の結果、第１プロセスが異常である場合、第２プロセスが異常であるか否かにより、ソフトウェア実行環境の再起動を生じさせる情報を出力するか否かを判定し、第１プロセスが異常でない場合、第２のプロセスが異常であるか否かによらず、情報の出力を抑制する。

１態様によれば、仮想環境で動作するプロセスの不要な再起動を抑止することができる。

第１の実施の形態に係る制御方法の一例を示す図である。 第２の実施の形態のシステム構成例を示す図である。 サーバのハードウェアの一構成例を示す図である。 サーバの機能を示すブロック図である。 コンテナの監視状況の一例を示す図である。 初期化処理の一例を示す図である。 被監視プロセスレジストリの一例を示す図である。 代表プロセス正常動作中の監視処理の一例を示す図である。 代表プロセスの状態が異常となった場合の監視処理の一例を示す図である。 復旧処理を実施すると判断する場合の一例を示す図である。 代表プロセスの処理手順の一例を示すフローチャートである。 被監視プロセスの処理手順の一例を示すフローチャートである。 代理監視プロセスの正常通知受信処理の手順の一例を示すフローチャートである。 代理監視プロセスの復旧判断処理の手順の一例を示すフローチャートである。 第３の実施の形態における被監視プロセスの処理手順の一例を示すフローチャートである。 第３の実施の形態における代理監視プロセスの復旧判断処理の手順の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る制御方法の一例を示す図である。図１には、制御方法を情報処理装置１０により実施した場合の例を示している。情報処理装置１０は、制御方法の処理手順が記述された制御プログラムを実行することにより、制御方法を実施することができる。

情報処理装置１０は、制御方法を実現するために、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリ、またはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサ、または演算回路である。

記憶部１１は、処理部１２によるソフトウェアの実行環境の管理に用いる情報を記憶する。
処理部１２は、ＯＳのカーネル上で仮想化技術によって隔離されたソフトウェア実行環境を構築するソフトウェア実行環境構築部１を有する。構築されるソフトウェア実行環境には、仮想マシンにおけるゲストＯＳのような、基礎となるカーネル以外のＯＳは含まれない。ソフトウェア実行環境は、例えばコンテナ型仮想化技術によって生成されるコンテナである。ソフトウェア実行環境構築部１は、例えば第１ソフトウェア実行環境２と第２ソフトウェア実行環境３とを構築する。

第１ソフトウェア実行環境２は、１または複数の第１プロセス２ａ，２ｂと第２プロセス２ｃとを動作させるためのソフトウェア実行環境である。第１プロセス２ａ，２ｂは、例えばアプリケーションソフトウェアなどのソフトウェアを実行するプロセスである。第２プロセス２ｃは、第１プロセス２ａ，２ｂの動作状態を監視するプロセスである。

第２ソフトウェア実行環境３は、第１ソフトウェア実行環境２で動作している第１プロセス２ａ，２ｂおよび第２プロセス２ｃの動作状態を監視する第３プロセス３ａを動作させるための実行環境である。例えば記憶部１１に、第３プロセス３ａで監視する第１プロセスの識別子を格納しておき、第３プロセス３ａは、記憶部１１を参照して、監視する第１プロセス２ａ，２ｂを認識する。

処理部１２は、第３プロセス３ａを用いて以下の処理を実行する。
処理部１２は、まず、第１プロセス２ａ，２ｂの動作状態を示す第１監視情報と、第２プロセス２ｃの動作状態を示す第２監視情報とを、第１プロセス２ａ，２ｂおよび第２プロセス２ｃから取得する（ステップＳ１）。次に処理部１２は、第１監視情報および第２監視情報に基づき、第１プロセス２ａ，２ｂおよび第２プロセス２ｃそれぞれが異常であるか否かを判定する（ステップＳ２）。そして処理部１２は、判定の結果に基づいて、第１プロセス２ａ，２ｂおよび第２プロセス２ｃの再起動を生じさせる情報（再起動情報）を出力、またはその情報の出力の抑制を行う（ステップＳ３）。例えば処理部１２は、第１プロセス２ａ，２ｂが異常である場合、第２プロセス２ｃが異常であるか否かにより、再起動情報を出力するか否かを判定する。また処理部１２は、第１プロセス２ａ，２ｂが異常でない場合、第２のプロセスが異常であるか否かによらず、再起動情報の出力を抑制する。

なお複数の第１プロセス２ａ，２ｂがある場合、処理部１２は、第１プロセス２ａ，２ｂのうちの少なくとも１つが異常であり、かつ第２プロセス２ｃが異常である場合、再起動情報を出力する。また処理部１２は、複数の第１プロセス２ａ，２ｂのいずれもが異常でない場合または第２プロセス２ｃが異常でない場合、再起動情報の出力を抑制する。

再起動情報は、例えば第１ソフトウェア実行環境２の異常を示す情報である。例えば再起動情報が出力されると、ソフトウェア実行環境構築部１が、第１ソフトウェア実行環境２を再起動する（ステップＳ４）。第１ソフトウェア実行環境２を再起動する場合、ソフトウェア実行環境構築部１は、第１ソフトウェア実行環境２で動作している第１プロセス２ａ，２ｂおよび第２プロセス２ｃを一旦終了させる。そしてソフトウェア実行環境構築部１は、第１ソフトウェア実行環境２の再起動が完了後、第１プロセス２ａ，２ｂおよび第２プロセス２ｃの実行を再開させる。すなわちソフトウェア実行環境構築部１により、第１プロセス２ａ，２ｂおよび第２プロセス２ｃの再起動が行われる。

このような情報処理装置１０によれば、第１プロセス２ａ，２ｂを監視している第２プロセス２ｃに異常が発生しても、第１プロセス２ａ，２ｂが正常に動作している限り、第１プロセス２ａ，２ｂおよび第２プロセス２ｃの再起動は行われない。その結果、第１プロセス２ａ，２ｂの不要な再起動が行われず、第１プロセス２ａ，２ｂによって実行されている処理の可用性が向上する。すなわち何らかの異常が発生したときに、第１ソフトウェア実行環境２の再起動によって第１プロセス２ａ，２ｂが実行している処理が停止する可能性が低減される。

例えばユーザへのサービス提供のためのソフトウェアは第１プロセス２ａ，２ｂによって実行される。第１プロセス２ａ，２ｂが正常に実行されていれば、第２プロセス２ｃに異常が発生しても、ユーザへのサービス提供は正常に行われる。そのため第２プロセス２ｃに異常が発生しても、第１プロセス２ａ，２ｂを停止してまで、第１ソフトウェア実行環境２を再起動しなくてもよい場合が多い。例えば第１ソフトウェア実行環境２を定期的に再起動するようにスケジュールが組まれている場合がある。このような場合、第２プロセス２ｃに異常が発生しても、第１ソフトウェア実行環境２の次の再起動時期まで第１プロセス２ａ，２ｂが正常に動作し続ければ、第１プロセス２ａ，２ｂで実行するソフトウェアによるサービス提供への影響はない。したがって、すべての第１プロセス２ａ，２ｂが正常に動作している間は再起動情報の出力を抑止することで、第１プロセス２ａ，２ｂによって実行されている処理の可用性が向上する。

また第２プロセス２ｃが正常に動作しており、第１プロセス２ａ，２ｂのうちの少なくとも１つに異常が発生した場合、第１ソフトウェア実行環境２内で異常に対する対処が可能である。例えば第２プロセス２ｃは、第１プロセス２ａ，２ｂの監視により第１プロセス２ａ，２ｂが異常であると判断した場合、第１プロセス２ａ，２ｂを再起動させることができる。このように第２プロセス２ｃが正常に動作していれば、第１プロセス２ａ，２ｂの異常が発生しても、異常状態が自動で解消する可能性があり、第１ソフトウェア実行環境２の再起動までせずにすむ場合が多い。したがって、第２プロセス２ｃが正常に動作している間は再起動情報の出力を抑止することで、第１プロセス２ａ，２ｂによって実行されている処理の可用性が向上する。

なお、処理部１２は、異常が未検出の間は、第１監視情報と第２監視情報との一方のみを取得し、異常検出後に他方（未取得の監視情報）を取得してもよい。例えば処理部１２は、異常検出前は、第１プロセス２ａ，２ｂそれぞれから第１監視情報を取得する。処理部１２は、第１プロセス２ａ，２ｂのいずれかの異常を検出すると、第２プロセス２ｃから第２監視情報を取得する。また処理部１２は、異常検出前は、第２プロセス２ｃから第２監視情報を取得する。そして処理部１２は、第２プロセス２ｃの異常を検出すると、第１プロセス２ａ，２ｂから第１監視情報を取得する。これにより、第３プロセス３ａが第１監視情報または第２監視情報を取得するための通信量を削減することができる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、オンプレミス（企業などの使用者が有する設備による情報システムの運用形態）で動作していたソフトウェアを、クライアントコンピューティング上のコンテナに移行した場合における、システムの可用性を向上させるものである。

コンテナ型仮想化では、１つのコンテナでは１つのプロセスを実行することが推奨されているものの、１つのコンテナで複数のプロセスを実行することも可能である。
ここで、１つのコンテナに１つのプロセスのみが実行されているのであれば、コンテナ基盤によるコンテナの監視に問題は生じない。すなわち、コンテナで実行されるプロセスが１つの場合、コンテナで実行されているプロセスが異常終了するとコンテナも異常終了する。またコンテナで実行されているプロセスにスローダウンなどの異常な状態が発生すると、コンテナ基盤によるコンテナ内のプロセスのヘルスチェックに異常な応答が返される。コンテナ基盤は、ヘルスチェックで異常を検出するとコンテナを再起動する。

コンテナの再起動は、コンテナで実行中のプロセスをすべて終了させ、改めてプロセスの生成、および生成したプロセスによるソフトウェアの実行を開始させる処理である。コンテナ基盤がコンテナを再起動することで、プロセスの異常な状態が解消される。

それに対して、１つのコンテナにおいて、複数のプロセスが実行される場合、コンテナ基盤は、ｐｉｄ＝１のプロセスのみを監視する。そのプロセスの状態が正常なとき、コンテナ基盤は、それ以外のプロセスが異常終了しても、コンテナの再起動を行わない。ここで、コンテナ内にｐｉｄのプロセス以外の代表プロセスを設け、コンテナ基盤が代表プロセスを監視することが考えられる。

代表プロセスを用いる場合、代表プロセスが、コンテナで実行されているプロセスのいずれかに異常を検出したときに、コンテナ基盤からのヘルスチェックに対して異常を通知するようにすると、不要なコンテナの再起動が発生する。このようなコンテナの再起動は、システムの可用性を低下させる。

すなわち、コンテナ内でユーザへのサービスを提供するソフトウェアを実行するのは、代表プロセス以外のプロセスである。代表プロセス以外のプロセスが正常に動作していれば、コンテナ内のプロセスによるユーザへのサービス提供処理は正常に実行可能である。このような場合にまでコンテナを再起動すると、コンテナを用いたサービスの稼働率が低下する。すなわち、該当サービスの可用性が低下する。

このように、コンテナ内で複数のプロセスが実行されている場合、コンテナ基盤からのヘルスチェックのみでは、コンテナ内の異常に対して適切に対応することができない。しかも、オンプレミスで実行している既存のソフトウェアをコンテナ基盤に移行する場合、元のソフトウェアを修正せずにコンテナで動作させることが望まれる。そのため既存のソフトウェアのコンテナ基盤への移行では、１つのコンテナで複数のプロセスを起動する構成のソフトウェアとなる場合が多い。したがって、オンプレミスで実行していたソフトウェアのコンテナ基盤への移行後のシステムの可用性低下を抑止するためにも、１つのコンテナで複数のプロセスが実行される場合における無駄なコンテナの再起動を抑止することが重要となる。

図２は、第２の実施の形態のシステム構成例を示す図である。ネットワーク２０には、サーバ１００と端末装置３１とが接続されている。サーバ１００は、コンテナ型仮想化技術によって複数のコンテナを構築し、コンテナを用いてソフトウェアを実行することにより、端末装置３１に対するサービスを提供する。

図３は、サーバのハードウェアの一構成例を示す図である。サーバは、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳのプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

サーバ１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１０も、図３に示したサーバ１００と同様のハードウェアにより実現することができる。

サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

図４は、サーバの機能を示すブロック図である。サーバ１００のハードウェア１１０上で、コンテナを実行するためのＯＳ１２０が実装されている。コンテナ型仮想化におけるＯＳ１２０は、システムのカーネルのみを有する。ＯＳ１２０上で、コンテナ基盤１３０、代理監視コンテナ１４０、および監視対象となるコンテナ１５０が実行されている。

コンテナ基盤１３０は、コンテナの起動や停止を制御する。またコンテナ基盤１３０は、代理監視コンテナ１４０と監視対象となるコンテナ１５０とを監視し、異常を検出したときに、代理監視コンテナ１４０と監視対象となるコンテナ１５０とを再起動する。例えばコンテナ基盤１３０は、代理監視コンテナ１４０とコンテナ１５０を１つのグループとして管理する。そしてコンテナ基盤１３０は、代理監視コンテナ１４０から異常発生の通知を受け取ると、同じグループとなっている代理監視コンテナ１４０とコンテナ１５０との再起動を行う。なおコンテナ基盤１３０は、図１に示した第１の実施の形態のソフトウェア実行環境構築部１の一例である。

代理監視コンテナ１４０は、コンテナ１５０内のプロセスを監視する。代理監視コンテナ１４０は、コンテナ１５０内のプロセスの異常を検知したとき、その異常の内容に応じてコンテナ１５０を再起動させるか否かを判断する。代理監視コンテナ１４０は、コンテナ１５０を再起動させると判断した場合、コンテナ１５０を再起動させるための処理を行う。例えば代理監視コンテナ１４０は、コンテナ基盤１３０に異常の発生を通知することで、コンテナ基盤１３０にコンテナ１５０を再起動させることができる。なお代理監視コンテナ１４０は、図１に示した第１の実施の形態の第２ソフトウェア実行環境３の一例である。

コンテナ１５０は、ユーザが利用するアプリケーションソフトウェアなどのソフトウェアを実行するための環境である。コンテナ１５０には、ＯＳにおけるカーネル以外の機能が含まれる。例えばファイルシステム、コマンドや関数の実行機能がコンテナ１５０に含まれる。コンテナ１５０は、例えばオンプレミスで実行されていたソフトウェアを変更せずに、そのまま実行することができる。コンテナ１５０で実行するソフトウェアが、オンプレミス上で複数のプロセスで処理を実行するソフトウェアであった場合、コンテナ１５０は、複数のプロセスを生成してそのソフトウェアを実行する。なおコンテナ１５０は、図１に示した第１の実施の形態の第１ソフトウェア実行環境２の一例である。

図４に示したＯＳ１２０、コンテナ基盤１３０、代理監視コンテナ１４０、およびコンテナ１５０は、例えば該当要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。

上記のように、コンテナ基盤１３０が代理監視コンテナ１４０とコンテナ１５０を監視し、代理監視コンテナ１４０内のプロセスがコンテナ１５０内のプロセスを監視する。
図５は、コンテナの監視状況の一例を示す図である。コンテナ基盤１３０は、代理監視コンテナ１４０と監視対象のコンテナ１５０とを１つのグループ４０として管理している。コンテナ基盤１３０は、代理監視コンテナ１４０で実行されている代理監視プロセス１４１の動作状況を監視することで、代理監視コンテナ１４０の異常の有無を監視する。

例えばコンテナ基盤１３０は、代理監視プロセス１４１のヘルスチェック（Ｈｅａｌｔｈｃｈｅｃｋ）を行い、代理監視プロセス１４１の異常の有無を確認する。ヘルスチェックにおいて、コンテナ基盤１３０は、代理監視コンテナ１４０に対してＨＴＴＰステータスコードの問い合わせを行い、問い合わせに対する応答を取得する。コンテナ基盤１３０は、応答が受信できない場合や、異常を示す値が応答された場合に、代理監視コンテナ１４０が異常であると判断する。

コンテナ基盤１３０は、代理監視コンテナ１４０またはコンテナ１５０で異常を検知した場合、代理監視コンテナ１４０とコンテナ１５０との両方を再起動する。
代理監視コンテナ１４０内の代理監視プロセス１４１はコンテナ１５０内のプロセスを監視する。例えばコンテナ１５０では、ｐｉｄ＝１のプロセス１５１以外に、代表プロセス１５２と被監視プロセス１５３，１５４とが実行されている。代理監視コンテナ１４０は、代表プロセス１５２のヘルスチェックを行うことで、代表プロセス１５２の異常の有無を監視する。

代理監視プロセス１４１は、ヘルスチェックによる代表プロセス１５２の監視の結果と、被監視プロセス１５３，１５４からの通知の有無の監視（通知監視）の結果とに基づいて、コンテナ１５０の復旧処理の実施の有無を判断する。ヘルスチェックの結果と通知監視の結果との組合せは、図５に示すように４つのパターンが考えられる。１つ目は、ヘルスチェックと通知監視とがいずれも正常となるパターン（パターンＡ）である。この場合、代理監視プロセス１４１は、復旧処理を実施しないと判断する。２つ目は、ヘルスチェックは正常であるが、通知監視で異常が検知されるパターン（パターンＢ）である。この場合、代理監視プロセス１４１は、復旧処理を実施しないと判断する。３つ目は、ヘルスチェックで異常が検知されるが、通知監視は正常であるパターン（パターンＣ）である。この場合、代理監視プロセス１４１は、復旧処理を実施しないと判断する。４つ目は、ヘルスチェックと通常監視との情報で異常が検知されるパターン（パターンＤ）である。この場合、代理監視プロセス１４１は、復旧処理を実施すると判断する。

なお代理監視プロセス１４１は、代表プロセス１５２のヘルスチェックと被監視プロセス１５３，１５４からの通知監視との情報を常時行っていてもよいが、一方で異常を検出した場合に、他方の監視を開始してもよい。例えば代理監視プロセス１４１は、代表プロセス１５２のヘルスチェックで異常を検知した場合、被監視プロセス１５３，１５４からの通知監視を開始する。代理監視プロセス１４１は、被監視プロセス１５３，１５４の通知監視において正常通知が定期的に受信できていることを監視する。代理監視プロセス１４１は、代表プロセス１５２に異常があり、かつ被監視プロセス１５３，１５４のいずれか１つについて異常を検知した場合、復旧処理を実施すると判断し、コンテナ基盤１３０に対して異常を通知する。

以下、図６〜図１０を参照し、代理監視コンテナ１４０およびコンテナ１５０での監視機能の起動から復旧処理実施までの処理について具体的に説明する。
図６は、初期化処理の一例を示す図である。代理監視コンテナ１４０は、まず代理監視プロセス１４１を起動する（ステップＳ１１）。またコンテナ１５０は、ｐｉｄ＝１のプロセス１５１を起動する（ステップＳ１２）。次にコンテナ１５０は、代表プロセス１５２を起動する（ステップＳ１３）。起動された代表プロセス１５２は、被監視プロセス１５３，１５４を起動する（ステップＳ１４，ステップＳ１５）。

さらに代表プロセス１５２は、起動完了通知を代理監視プロセス１４１に送信する（ステップＳ１６）。起動完了通知を受信した代理監視プロセス１４１は、代表プロセス１５２のヘルスチェックを開始する（ステップＳ１７）。

起動された被監視プロセス１５３，１５４は、起動完了通知を代理監視プロセス１４１に送信する（ステップＳ１８、ステップＳ１９）。代理監視プロセス１４１は、起動完了通知に基づいて被監視プロセス１５３，１５４の存在を認識し、被監視プロセスレジストリ１４２に被監視プロセス１５３，１５４の情報を格納する。

図７は、被監視プロセスレジストリの一例を示す図である。被監視プロセスレジストリ１４２には、被監視プロセスの識別子（被監視プロセスＩＤ）に対応付けて、該当被監視プロセスから正常通知を受信した最新の時刻（最新正常通知時刻）が設定されている。代理監視プロセス１４１は、被監視プロセスレジストリ１４２を参照することで、正常通知が途絶えた被監視プロセスの有無を判断することができる。

初期化が完了すると、代理監視プロセス１４１は、代表プロセス１５２が正常に動作している限り、代表プロセス１５２のみを監視する。
図８は、代表プロセス正常動作中の監視処理の一例を示す図である。代理監視プロセス１４１は、代表プロセス１５２にＨＴＴＰステータスコードの問い合わせを、定期的に送信する（ステップＳ２１）。代表プロセス１５２は、自身が正常に動作していれば、正常を示すステータスコード（例えば「２００」）を、代理監視プロセス１４１に応答する（ステップＳ２２）。また代表プロセス１５２は、被監視プロセス１５３，１５４それぞれを定期的に監視する（ステップＳ２３、ステップＳ２４）。例えば代表プロセス１５２は、被監視プロセス１５３，１５４それぞれに対して正常確認要求を送信し、正常の応答を受信できれば被監視プロセス１５３，１５４が正常であると判断する。

被監視プロセス１５３，１５４は、代表プロセス１５２からの正常確認が定期的に実施されているか否かにより、代表プロセス１５２が正常に動作しているか否かを確認している。そのため、代表プロセス１５２に異常が発生すると、代理監視プロセス１４１と被監視プロセス１５３，１５４とが、それぞれ個別に異常を検知する。

図９は、代表プロセスの状態が異常となった場合の監視処理の一例を示す図である。代表プロセス１５２に異常が発生した場合、例えば代理監視プロセス１４１が代表プロセス１５２にＨＴＴＰステータスコードの問い合わせを行っても、応答が返されない（ステップＳ３１）。代理監視プロセス１４１は、応答を受信できないことにより、代表プロセス１５２の異常を検知する（ステップＳ３２）。なお、代表プロセス１５２が、正常のステータスコード「２００」以外のステータスコードを応答する場合もある。この場合、代理監視プロセス１４１は、ステータスコードが正常以外であることにより、代表プロセス１５２の異常を検知する。

また、被監視プロセス１５３，１５４は、代表プロセス１５２からの定期的な監視のアクセスが途絶えたことにより、代表プロセス１５２の異常を検知する。例えば被監視プロセス１５３，１５４は、代表プロセス１５２からの正常確認要求を所定時間以上受信していない場合に、代表プロセス１５２に異常が発生したと判断する。被監視プロセス１５３，１５４は、代表プロセス１５２の異常を検知すると、その後、代理監視プロセス１４１に対して正常通知を定期的に送信する（ステップＳ３３、ステップＳ３４）。

代理監視プロセス１４１は、代表プロセス１５２の異常を検知すると、被監視プロセス１５３，１５４からの正常通知の監視を開始する（ステップＳ３５）。例えば代理監視プロセス１４１は、被監視プロセス１５３から正常通知を受信すると、受信時刻と、被監視プロセス１５３の識別子に対応付けて被監視プロセスレジストリ１４２に設定されている最新正常通知時刻とを比較する。代理監視プロセス１４１は、正常通知の受信時刻と最新正常通知時刻との差が、所定値以下であれば、被監視プロセス１５３が正常であると判断し、被監視プロセスレジストリ１４２内の最新正常通知時刻を更新する。

代理監視プロセス１４１は、代表プロセス１５２の異常を検知しても、起動されている被監視プロセス１５３，１５４それぞれからの定期的な正常通知の受信が確認できている間は、復旧処理の実施は不要と判断する。他方、代理監視プロセス１４１は、起動されている被監視プロセス１５３，１５４のうちの少なくとも１つについて、正常通知が受信できなくなった場合、復旧処理を実施すると判断する。

図１０は、復旧処理を実施すると判断する場合の一例を示す図である。図１０の例では、被監視プロセス１５３は正常に動作しており、定期的な正常通知を行っている（ステップＳ４１）。他方、被監視プロセス１５４に異常が発生し、被監視プロセス１５４は正常通知を行うことができない。代理監視プロセス１４１は、被監視プロセスレジストリ１４２を参照し、被監視プロセス１５４の最新正常通知時刻から所定時間以上、被監視プロセス１５４から正常通知を受信できない場合、被監視プロセス１５４に異常が発生したと判断する（ステップＳ４２）。

代理監視プロセス１４１は、被監視プロセス１５４の異常を検知すると、コンテナ基盤１３０への異常通知を行う（ステップＳ４３）。例えばコンテナ基盤１３０は、代理監視プロセス１４１に対して、ＨＴＴＰステータスコードの問い合わせを行う（ステップＳ４４）。代理監視プロセス１４１は、問い合わせに対して、異常を表すステータスコード（例えば「５００」）を応答する（ステップＳ４５）。なお代理監視プロセス１４１は、ＨＴＴＰステータスコードの問い合わせに対して何も応答しないことで、コンテナ基盤１３０に異常を通知することもできる。

コンテナ基盤１３０は、代理監視プロセス１４１からの異常通知を受けて、例えば代理監視コンテナ１４０、および代理監視コンテナ１４０と同じグループに属しているコンテナ１５０の再起動処理を行う（ステップＳ４６、ステップＳ４７）。

このようにして代表プロセス１５２と少なくとも一部の被監視プロセス１５４とに異常が発生した場合に、コンテナ１５０が再起動される。換言すると、代表プロセス１５２に異常が発生しても、被監視プロセス１５３，１５４が正常に動作している間は、コンテナ１５０の再起動は行われない。これにより、被監視プロセス１５３，１５４による処理が無駄に停止してしまうことを抑止できる。

以下、代表プロセス１５２、被監視プロセス１５３，１５４、および代理監視プロセス１４１それぞれの処理について、フローチャートを参照して詳細に説明する。
図１１は、代表プロセスの処理手順の一例を示すフローチャートである。以下、図１１に示す処理をステップ番号に沿って説明する。

［ステップＳ１０１］代表プロセス１５２は、起動されると、コンテナ１５０で実行するソフトウェアに定義済みの被監視プロセス１５３，１５４ごとにステップＳ１０２の処理を実行する。

［ステップＳ１０２］代表プロセス１５２は、被監視プロセス１５３，１５４を起動する。
［ステップＳ１０３］代表プロセス１５２は、定義済みの被監視プロセス１５３，１５４の起動が完了すると、処理をステップＳ１０４に進める。

［ステップＳ１０４］代表プロセス１５２は、代理監視プロセス１４１へ代表プロセス１５２の起動完了を通知する。
［ステップＳ１０５］代表プロセス１５２は、コンテナ１５０が停止するまで、ステップＳ１０６〜Ｓ１０９の処理を無限にループする。

［ステップＳ１０６］代表プロセス１５２は、定義済みの被監視プロセス１５３，１５４ごとにステップＳ１０７〜Ｓ１０８の処理を実行する。
［ステップＳ１０７］代表プロセス１５２は、被監視プロセス１５３，１５４の状態が正常か異常かを判断する。例えば代表プロセス１５２は、被監視プロセス１５３，１５４に対して正常確認要求を送信し、正常の応答があった場合、正常であると判断する。また代表プロセス１５２は、正常確認要求に応答がない場合、異常であると判断する。代表プロセス１５２は、被監視プロセスの状態が正常であれば、処理をステップＳ１０９に進める。また代表プロセス１５２は、被監視プロセスの状態が異常であれば、処理をステップＳ１０８に進める。

［ステップＳ１０８］代表プロセス１５２は、異常が発生した被監視プロセスを再起動する。
［ステップＳ１０９］代表プロセス１５２は、定義済みのすべての被監視プロセスについてステップＳ１０７〜Ｓ１０８の処理が終了したら、処理をステップＳ１１０に進める。

［ステップＳ１１０］代表プロセス１５２は、コンテナが停止する場合、処理を終了する。
このようにして、代表プロセス１５２は、被監視プロセス１５３，１５４の状態を監視し、異常を検知した場合には、異常となった被監視プロセスを再起動することができる。これにより、代表プロセス１５２が正常に動作している間は、被監視プロセス１５３，１５４のいずれかに異常が発生しても、コンテナ１５０内の処理で正常な状態に復旧させることができる。

次に被監視プロセス１５３，１５４が実行する処理について説明する。
図１２は、被監視プロセスの処理手順の一例を示すフローチャートである。以下、被監視プロセス１５３が実行する場合を想定し、図１２に示す処理をステップ番号に沿って説明する。

［ステップＳ１２１］被監視プロセス１５３は、代理監視プロセスへ起動完了通知を送信する。起動完了通知には、被監視プロセス１５３の識別子（被監視プロセスＩＤ）が含まれる。

［ステップＳ１２２］被監視プロセス１５３は、被監視プロセスが停止するまで、ステップＳ１２３〜Ｓ１２４の処理を無限ループする。
［ステップＳ１２３］被監視プロセス１５３は、代表プロセスによる最後の正常確認時刻からの経過時間が「Ｘ秒」（Ｘは０より大きい実数）以上か否かを判断する。被監視プロセス１５３は、正常確認時刻からの経過時間が「Ｘ秒」以上であれば処理をステップＳ１２４に進める。また被監視プロセス１５３は、正常確認時刻からの経過時間が「Ｘ秒」未満であれば処理をステップＳ１２５に進める。

［ステップＳ１２４］被監視プロセス１５３は、代理監視プロセス１４１に正常通知を送信する。正常通知には、被監視プロセス１５３の識別子（被監視プロセスＩＤ）が含まれる。

［ステップＳ１２５］被監視プロセス１５３は、代表プロセス１５２からの再起動またはコンテナ１５０の再起動などにより被監視プロセス１５３が停止する場合、処理を終了する。

このように被監視プロセス１５３は、代表プロセス１５２からの正常確認がＸ秒以上途絶えた場合、代表プロセス１５２に異常が発生したものと判断し、代理監視プロセス１４１への正常通知の送信を開始する。

なお図１２の処理を被監視プロセス１５３が実行するものとして説明したが、他の被監視プロセス１５４も被監視プロセス１５３と同様の処理を実行する。また被監視プロセス１５３，１５４は、図１２に示した処理以外に、例えば端末装置３１からの要求に応じたサービス提供処理も実行する。

次に代理監視プロセス１４１が実行する処理について説明する。代理監視プロセス１４１が実行する処理には、正常通知受信処理と復旧判断処理とがある。
図１３は、代理監視プロセスの正常通知受信処理の手順の一例を示すフローチャートである。以下、図１３に示す処理をステップ番号に沿って説明する。

［ステップＳ１３１］代理監視プロセス１４１は、代理監視プロセス１４１が停止するまで、ステップＳ１３２〜Ｓ１３６の処理を無限ループする。
［ステップＳ１３２］代理監視プロセス１４１は、被監視プロセス１５３，１５４の起動完了通知を受信したか否かを判断する。代理監視プロセス１４１は、起動完了通知を受信した場合、処理をステップＳ１３３に進める。また代理監視プロセス１４１は、起動完了通知を受信していなければ、処理をステップＳ１３５に進める。

［ステップＳ１３３］代理監視プロセス１４１は、起動完了通知の送信元の被監視プロセスの被監視プロセスＩＤが、被監視プロセスレジストリ１４２に登録済みか否かを判断する。代理監視プロセス１４１は、被監視プロセスＩＤが登録済みであれば、処理をステップＳ１３５に進める。また代理監視プロセス１４１は、被監視プロセスＩＤが未登録であれば、処理をステップＳ１３４に進める。

［ステップＳ１３４］代理監視プロセス１４１は、被監視プロセスレジストリ１４２に、起動完了通知の送信元の被監視プロセスの被監視プロセスＩＤを、被監視プロセスレジストリ１４２に追加する。

［ステップＳ１３５］代理監視プロセス１４１は、いずれかの被監視プロセスの正常通知を受信したか否かを判断する。代理監視プロセス１４１は、正常通知を受信した場合、処理をステップＳ１３６に進める。また代理監視プロセス１４１は、正常通知を受信していなければ、処理をステップＳ１３７に進める。

［ステップＳ１３６］代理監視プロセス１４１は、被監視プロセスレジストリ１４２における、正常通知の送信元の被監視プロセスの被監視プロセスＩＤに対応する最新正常通知時刻に、現在の時刻を設定する。

［ステップＳ１３７］代理監視プロセス１４１は、コンテナ基盤１３０による代理監視コンテナ１４０の再起動処理などにより代理監視プロセス１４１が停止する場合、正常通知受信処理を終了する。

このようにして、代理監視プロセス１４１は、被監視プロセスレジストリ１４２に設定されている、被監視プロセス１５３，１５４それぞれの最新正常通知時刻を更新することができる。そして代理監視プロセス１４１は、被監視プロセスレジストリ１４２を参照して、コンテナ１５０の復旧処理を行うか否かを判断する。

図１４は、代理監視プロセスの復旧判断処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。
［ステップＳ１４１］代理監視プロセス１４１は、代表プロセス１５２のヘルスチェックを行い、代表プロセス１５２が正常か否かを判断する。代理監視プロセス１４１は、代表プロセスが正常であれば、ステップＳ１４１の処理を繰り返す。また代理監視プロセス１４１は、代表プロセス１５２の異常を検出した場合、処理をステップＳ１４２に進める。

［ステップＳ１４２］代理監視プロセス１４１は、コンテナ１５０で実行するソフトウェアに定義済みの被監視プロセス１５３，１５４ごとにステップＳ１４３の処理を実行する。

［ステップＳ１４３］代理監視プロセス１４１は、処理対象の被監視プロセスの最新正常通知時刻からの経過時間を算出する。例えば代理監視プロセス１４１は、被監視プロセスレジストリ１４２を参照し、処理対象の被監視プロセスの被監視プロセスＩＤに対応付けて登録された最新正常通知時刻と現在時刻との差を計算し、経過時間とする。

［ステップＳ１４４］代理監視プロセス１４１は、定義済みのすべての被監視プロセス１５３，１５４について経過時間の算出が終了したら、処理をステップＳ１４５に進める。

［ステップＳ１４５］代理監視プロセス１４１は、経過時間が「Ｙ秒」（Ｙは０より大きな実数）以上となった被監視プロセスが少なくとも１つあるか否かを判断する。代理監視プロセス１４１は、該当する被監視プロセスがある場合、その被監視プロセスに異常が発生したと判断し、処理をステップＳ１４６に進める。また代理監視プロセス１４１は、該当する被監視プロセスがなければ、すべての被監視プロセス１５３，１５４が正常であると判断し、処理をステップＳ１４１に進める。

［ステップＳ１４６］代理監視プロセス１４１は、コンテナ１５０の復旧処理を行う。例えば代理監視プロセス１４１は、コンテナ基盤１３０に対して異常の発生を通知する。するとコンテナ基盤１３０が、代理監視コンテナ１４０とコンテナ１５０とを再起動する。これにより、代理監視コンテナ１４０とコンテナ１５０とが初期化され、正常な状態から処理が開始される。

なお図１４に示す処理のうち、ステップＳ１４２〜Ｓ１４５の処理が、被監視プロセス１５３，１５４からの正常通知を監視する通知監視処理である。
このように代理監視プロセス１４１は、ヘルスチェックが正常であれば、異常な被監視プロセスは代表プロセス１５２によって復旧されるため、コンテナ基盤１３０によるコンテナ１５０の再起動は不要と判断する（図５に示す「パターンＡ」と「パターンＢ」）。図１４の例では、被監視プロセス１５３，１５４からの通知監視の前にヘルスチェックを行っているため、代理監視プロセス１４１は、図５に示す「パターンＡ」と「パターンＢ」とを区別していない。

また代理監視プロセス１４１は、ヘルスチェックが異常であっても、被監視プロセス１５３，１５４からの正常通知の定期受信に異常がなければ、すべての被監視プロセス１５３，１５４は正常であるため、コンテナ１５０の再起動は不要と判断する（図５に示す「パターンＣ」）。これにより、コンテナ１５０を用いたサービスなどの実質的な処理が正常に動作しているにもかかわらず、コンテナ１５０が再起動されることが抑止される。その結果、システムの安定性が向上する。

さらにヘルスチェックと、被監視プロセス１５３，１５４の少なくとも一方からの正常通知とに異常であれば、代表プロセス１５２による異常な被監視プロセスの復旧は期待できない。この場合、代理監視プロセス１４１は、復旧処理（コンテナ基盤１３０によるコンテナ１５０の再起動）を行うと判断する（図５に示す「パターンＤ」）。これにより、被監視プロセスによるサービスの提供に異常が発生すると、自動でコンテナ１５０の再起動が行われ、正常状態に復旧される。これにより、サービスの異常状態の長期化が抑止され、運用効率が向上する。

なおサーバ１００では、被監視プロセス１５３，１５４の動作の監視機能を、代表プロセス１５２と代理監視プロセス１４１との両方が有している。このように代表プロセス１５２と代理監視プロセス１４１とのそれぞれが被監視プロセス１５３，１５４を監視できるようにしたのは、代表プロセス１５２と代理監視プロセス１４１とで実施できる復旧処理が異なるためである。

すなわち代表プロセス１５２は、被監視プロセス１５３，１５４と同じコンテナ１５０内に存在するため、被監視プロセス１５３，１５４のいずれかに異常が発生すれば、異常な被監視プロセスのみを再起動させることができる。それに対して、代理監視プロセス１４１は、被監視プロセス１５３，１５４とは別の代理監視コンテナ１４０内に存在する。代理監視コンテナ１４０とコンテナ１５０とは、ＨＴＴＰなどによりプロセス間の通信は可能であるものの、それぞれは隔離された環境である。そのため代理監視プロセス１４１は、被監視プロセス１５３，１５４のいずれかに異常が発生しても、異常な被監視プロセスのみを再起動させることはできない。

また代理監視プロセス１４１は、コンテナ１５０内の代表プロセス１５２および被監視プロセス１５３，１５４の動作を外部から監視することができ、コンテナ１５０内の異常状態を正確に把握することができる。これにより代理監視プロセス１４１は、コンテナ１５０内で復旧可能な異常またはサービスの実行に影響のない異常を検出しても、コンテナ基盤１３０に異常通知を行わないことで、コンテナ１５０の不要な再起動を抑止できる。

このように、代理監視プロセス１４１と代表プロセス１５２との両方が存在することにより、コンテナ１５０内での異常の復旧の可能性を高めることができると共に、コンテナ１５０内の状況を正確に把握した、コンテナ１５０の再起動の適切な判断とが両立できる。その結果、コンテナ１５０の再起動が最小限に抑えられ、被監視プロセス１５３，１５４が実行する処理の可用性が向上する。

〔第３の実施の形態〕
次に第３の実施の形態について説明する。第３の実施の形態は、被監視プロセス１５３，１５４からの正常通知の監視を、代表プロセス１５２のヘルスチェックより優先して実行するものである。この場合、被監視プロセス１５３，１５４は、代表プロセス１５２の異常の有無に関係無く、正常通知の定期送信を行う。

図１５は、第３の実施の形態における被監視プロセスの処理手順の一例を示すフローチャートである。以下、被監視プロセス１５３が実行する場合を想定し、図１５に示す処理をステップ番号に沿って説明する。

［ステップＳ２０１］被監視プロセス１５３は、代理監視プロセス１４１へ起動完了通知を送信する。起動完了通知には、被監視プロセス１５３の識別子（被監視プロセスＩＤ）が含まれる。

［ステップＳ２０２］被監視プロセス１５３は、被監視プロセス１５３が停止するまで、ステップＳ２０３〜Ｓ２０４の処理を無限ループする。
［ステップＳ２０３］被監視プロセス１５３は、代理監視プロセス１４１に正常通知を送信する。正常通知には、被監視プロセス１５３の識別子（被監視プロセスＩＤ）が含まれる。

［ステップＳ２０４］被監視プロセス１５３は、代表プロセス１５２からの再起動またはコンテナ１５０の再起動などにより被監視プロセス１５３が停止する場合、処理を終了する。

このように被監視プロセス１５３は、代表プロセス１５２からの正常確認が途絶えているか否かを判断せずに、代理監視プロセス１４１への正常通知の定期送信を行う。なお図１５の処理を被監視プロセス１５３が実行するものとして説明したが、他の被監視プロセス１５４も被監視プロセス１５３と同様の処理を実行する。

図１６は、第３の実施の形態における代理監視プロセスの復旧判断処理の手順の一例を示すフローチャートである。以下、図１６に示す処理をステップ番号に沿って説明する。
［ステップＳ２１１］代理監視プロセス１４１は、コンテナ１５０で実行するソフトウェアに定義済みの被監視プロセス１５３，１５４ごとにステップＳ２１２の処理を実行する。

［ステップＳ２１２］代理監視プロセス１４１は、処理対象の被監視プロセスの最新正常通知時刻からの経過時間を算出する。
［ステップＳ２１３］代理監視プロセス１４１は、定義済みのすべての被監視プロセス１５３，１５４について経過時間の算出が終了したら、処理をステップＳ２１４に進める。

［ステップＳ２１４］代理監視プロセス１４１は、経過時間が「Ｙ秒」（Ｙは０より大きな実数）以上となった被監視プロセスが少なくとも１つあるか否かを判断する。代理監視プロセス１４１は、該当する被監視プロセスがある場合、その被監視プロセスに異常が発生したと判断し、処理をステップＳ２１５に進める。また代理監視プロセス１４１は、該当する被監視プロセスがなければ、すべての被監視プロセス１５３，１５４が正常であると判断し、処理をステップＳ２１１に進める。

［ステップＳ２１５］代理監視プロセス１４１は、代表プロセス１５２のヘルスチェックを行い、代表プロセス１５２が正常か否かを判断する。代理監視プロセス１４１は、代表プロセスが正常であれば、処理をステップＳ２１１に進める。また代理監視プロセス１４１は、代表プロセス１５２の異常を検出した場合、処理をステップＳ２１６に進める。

［ステップＳ２１６］代理監視プロセス１４１は、コンテナ１５０の復旧処理を行う。例えば代理監視プロセス１４１は、コンテナ基盤１３０に対して異常の発生を通知する。するとコンテナ基盤１３０が、代理監視コンテナ１４０とコンテナ１５０とを再起動する。これにより、代理監視コンテナ１４０とコンテナ１５０とが初期化され、正常な状態から処理が開始される。

なお図１６に示す処理のうち、ステップＳ２１１〜Ｓ２１４の処理が、被監視プロセス１５３，１５４からの正常通知を監視する通知監視処理である。図１４に示した第２の実施の形態における復旧判断処理と比較すれば分かるように、第３の実施の形態では、代理監視プロセス１４１は、ヘルスチェック処理の前に通知監視処理を行っている。

このように代理監視プロセス１４１は、通知監視が正常であれば、すべて被監視プロセス１５３，１５４は正常であるため、コンテナ基盤１３０によるコンテナの再起動は不要と判断する（図５に示す「パターンＡ」と「パターンＣ」）。図１６の例では、ヘルスチェックの前に被監視プロセス１５３，１５４からの通知監視を行っているため、代理監視プロセス１４１は、図５に示す「パターンＡ」と「パターンＣ」とを区別していない。

また被監視プロセス１５３，１５４のいずれかに異常があっても、ヘルスチェックに異常がなければ、異常な被監視プロセスは代表プロセス１５２によって復旧される。この場合、代理監視プロセス１４１は、コンテナ１５０の再起動は不要と判断する（図５に示す「パターンＢ」）。

さらに代理監視プロセス１４１は、ヘルスチェックも通知監視も異常であれば、異常な被監視プロセスが代表プロセス１５２によって復旧されないため、コンテナ基盤１３０によるコンテナ１５０の再起動を実行すると判断する（図５に示す「パターンＤ」）。

〔その他の実施の形態〕
代理監視プロセス１４１は、被監視プロセスレジストリ１４２に記録した各被監視プロセス１５３，１５４の最新正常通知時刻に基づいて、被監視プロセス１５３，１５４から正常通知の途絶を監視しているが、他の手段で正常通知の途絶を監視することもできる。例えば代理監視プロセス１４１は、被監視プロセス１５３，１５４ごとのタイマを用いて、正常通知の途絶を監視することが可能である。その場合、代理監視プロセス１４１は、被監視プロセス１５３，１５４のいずれかから正常通知を受信すると、その被監視プロセスのタイマによる時間計測を開始する。そして代理監視プロセス１４１は、タイマの計測時間が所定値（例えば「Ｙ秒」）以上となった被監視プロセスがある場合、通知監視における被監視プロセスの異常が発生したと判断する。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ ソフトウェア実行環境構築部
２ 第１ソフトウェア実行環境
２ａ，２ｂ 第１プロセス
２ｃ 第２プロセス
３ 第２ソフトウェア実行環境
３ａ 第３プロセス
１０ 情報処理装置
１１ 記憶部
１２ 処理部

Claims (7)

1. コンピュータが、
   ソフトウェア実行環境において動作する第１プロセスの動作状態を示す第１監視情報と、前記ソフトウェア実行環境において前記第１プロセスを監視する第２プロセスの動作状態を示す第２監視情報とを取得し、
   前記第１監視情報および前記第２監視情報に基づき、前記第１プロセスおよび前記第２プロセスそれぞれが異常であるか否かを判定し、
   前記判定の結果、前記第１プロセスが異常である場合、前記第２プロセスが異常であるか否かにより、前記ソフトウェア実行環境の再起動を生じさせる情報を出力するか否かを判定し、前記第１プロセスが異常でない場合、前記第２のプロセスが異常であるか否かによらず、前記情報の出力を抑制する、
   制御方法。
2. 前記情報の出力では、複数の前記第１プロセスのうちの少なくとも１つが異常であり、かつ前記第２プロセスが異常である場合、前記情報を出力し、複数の前記第１プロセスのいずれもが異常でない場合または前記第２プロセスが異常でない場合、前記情報の出力を抑制する、
   請求項１記載の制御方法。
3. 前記コンピュータには、前記第１プロセスおよび前記第２プロセスが動作する第１ソフトウェア実行環境と、前記第１ソフトウェア実行環境とは別の第２ソフトウェア実行環境とが構築されており、前記第２ソフトウェア実行環境で動作する第３プロセスが、前記第１監視情報と前記第２監視情報との取得、前記第１プロセスおよび前記第２プロセスそれぞれが異常であるか否かの判定、および前記情報の出力または抑制を行う、
   請求項１または２記載の制御方法。
4. 前記第２プロセスは、前記第１プロセスの監視により前記第１プロセスが異常であると判断した場合、前記第１プロセスを再起動させる、
   請求項１ないし３のいずれかに記載の制御方法。
5. 前記第１監視情報および前記第２監視情報の取得では、前記第１監視情報と前記第２監視情報との一方を取得し、前記第１プロセスまたは前記第２プロセスに異常が検出された後に、未取得の前記第１監視情報または前記第２監視情報を取得する、
   請求項１ないし４のいずれかに記載の制御方法。
6. コンピュータに、
   ソフトウェア実行環境において動作する第１プロセスの動作状態を示す第１監視情報と、前記ソフトウェア実行環境において前記第１プロセスを監視する第２プロセスの動作状態を示す第２監視情報とを取得し、
   前記第１監視情報および前記第２監視情報に基づき、前記第１プロセスおよび前記第２プロセスそれぞれが異常であるか否かを判定し、
   前記判定の結果、前記第１プロセスが異常である場合、前記第２プロセスが異常であるか否かにより、前記ソフトウェア実行環境の再起動を生じさせる情報を出力するか否かを判定し、前記第１プロセスが異常でない場合、前記第２のプロセスが異常であるか否かによらず、前記情報の出力を抑制する、
   処理を実行させる制御プログラム。
7. ソフトウェア実行環境において動作する第１プロセスの動作状態を示す第１監視情報と、前記ソフトウェア実行環境において前記第１プロセスを監視する第２プロセスの動作状態を示す第２監視情報とを取得し、前記第１監視情報および前記第２監視情報に基づき、前記第１プロセスおよび前記第２プロセスそれぞれが異常であるか否かを判定し、前記判定の結果、前記第１プロセスが異常である場合、前記第２プロセスが異常であるか否かにより、前記ソフトウェア実行環境の再起動を生じさせる情報を出力するか否かを判定し、前記第１プロセスが異常でない場合、前記第２のプロセスが異常であるか否かによらず、前記情報の出力を抑制する処理部、
   を有する情報処理装置。

Images