JP2019159977A - 制御プログラム、制御装置及び制御方法 - Google Patents

Abstract

【課題】コンテナ上のプロセスとして動作するＴａｓｋＴｒａｃｋｅｒの再起動を効率的に行うことによって再起動に要する時間の短縮を可能とする制御プログラム、制御装置及び制御方法を提供する。【解決手段】複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された特定のコンテナが動作する特定のホストマシンを示す情報に基づき、特定のホストマシンの動作状況を推定し、推定の結果に応じて、分散処理が行われるデータのデータ量に基づいて算出された、特定のコンテナを特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する。【選択図】図８

Description

本発明は、分散並列環境におけるコンテナの制御プログラム、制御装置及び制御方法に関する。

例えば、利用者にサービスを提供する事業者（以下、単に事業者とも呼ぶ）は、サービスの提供を行うための業務システム（以下、情報処理システムとも呼ぶ）を構築して稼働させる。具体的に、事業者は、業務システムの構築を行う際に、例えば、サービスの提供を効率的に行うためのコンテナ型仮想化技術（例えば、Ｄｏｃｋｅｒ）を利用する。このコンテナ型仮想化技術は、物理マシン（以下、ホストマシンとも呼ぶ）から隔離された環境であるコンテナをホストマシン上において生成する技術である。

このようなコンテナ型仮想化技術では、ハイパーバイザ型仮想化技術のようにゲストＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）の生成を行うことなくコンテナの生成を行う。そのため、コンテナ型仮想化技術は、ハイパーバイザ型仮想化技術と比較して、コンテナの生成に要するオーバヘッドが小さいという利点がある（例えば、特許文献１乃至３参照）。

特開２００６−０３１０９６号公報 特開平６−０１２２９４号公報 特開平１１−３２８１３０号公報

上記のようなコンテナ上のプロセスとしてＨａｄｏｏｐを動作させる場合、マスターノードに含まれる機能であるＪｏｂＴｒａｃｋｅｒ及びＮａｍｅＮｏｄｅと、スレーブノードに含まれる機能であるＴａｓｋＴｒａｃｋｅｒ及びＤａｔａＮｏｄｅとを、それぞれコンテナ上のプロセスとして動作させる。そして、例えば、コンテナ上のプロセスとして動作するＪｏｂＴｒａｃｋｅｒは、複数の他のコンテナ上のプロセスとして動作するＴａｓｋＴｒａｃｋｅｒと連携し、処理対象となるデータ（以下、タスクデータとも呼ぶ）の分散処理を行う。

ここで、タスクデータの分散処理の実行中において、上記のようなコンテナ上のＴａｓｋＴｒａｃｋｅｒの再起動が行われる場合、コンテナ上のＪｏｂＴｒａｃｋｅｒは、各ＴａｓｋＴｒａｃｋｅｒが存在するスレーブノードに対して処理対象となるタスクデータの再配置を行い、ジョブの実行を初めからやり直す。

また、ＪｏｂＴｒａｃｋｅｒは、例えば、あるスレーブノードからの応答を待ち続けたことによってタイムアウトが発生した場合、そのスレーブノードに含まれるＴａｓｋＴｒａｃｋｅｒ上においてタスクデータの分散処理を行わない。すなわち、この場合、ＪｏｂＴｒａｃｋｅｒは、そのＴａｓｋＴｒａｃｋｅｒを利用することができない状態になったと判断する（以下、この状態になることをブラックリスト入りとも呼ぶ）。そのため、ＪｏｂＴｒａｃｋｅｒは、この場合、発生したタイムアウトに対応するＴａｓｋＴｒａｃｋｅｒ以外の各ＴａｓｋＴｒａｃｋｅｒに対して処理対象となるタスクデータの再配置を行い、ジョブの実行を初めからやり直す。

しかしながら、上記のようなＪｏｂＴｒａｃｋｅｒを含むマスターノードは、例えば、他の機能と連携することにより、スレーブノードのコンテナ上において動作するＴａｓｋＴｒａｃｋｅｒやＤａｔａＮｏｄｅ（以下、ＴａｓｋＴｒａｃｋｅｒ等とも呼ぶ）からの通知の応答があるか否かの判定を行うことが可能である一方、そのＴａｓｋＴｒａｃｋｅｒ等が動作するホストマシンの動作状況については監視することができない。すなわち、マスターノードは、例えば、スレーブノードのコンテナ上において動作するＴａｓｋＴｒａｃｋｅｒ等からの応答がなくなった場合、ＴａｓｋＴｒａｃｋｅｒ等及びホストマシンの両方において異常が発生しているのか、ＴａｓｋＴｒａｃｋｅｒ等においてのみ異常が発生しているのかを判定することができない。

そのため、ＪｏｂＴｒａｃｋｅｒは、例えば、ＴａｓｋＴｒａｃｋｅｒの再起動に応じて行われているタスクデータの再配置が長引いたことに起因してタイムアウトが発生した場合（ホストマシンにおいて異常が発生していない場合）であっても、実行中のタスクデータの再配置を中止し、タイムアウトの発生に応じて行われるタスクデータの再配置を最初から開始する場合がある。したがって、ホストマシンにおいて異常が発生していない場合であっても、ＴａｓｋＴｒａｃｋｅｒの再起動に必要以上の時間を要する場合がある。

そこで、一つの側面によれば、本発明は、コンテナ上のプロセスとして動作するＴａｓｋＴｒａｃｋｅｒの再起動を効率的に行うことによって再起動に要する時間の短縮を可能とする制御プログラム、制御装置及び制御方法を提供することを目的とする。

実施の形態の一態様では、マスターノードを構成するコンテナ（例えば、１以上のコンテナからなるコンテナ群）と複数のスレーブノードを構成するコンテナ（例えば、１以上のコンテナからなるコンテナ群）とが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御処理をコンピュータに実行させる制御プログラムにおいて、前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定し、前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する、処理を前記コンピュータに実行させる。

一つの側面によれば、コンテナ上のプロセスとして動作するＴａｓｋＴｒａｃｋｅｒの再起動を効率的に行うことによって再起動に要する時間の短縮を可能とする。

図１は、情報処理システム１０の全体構成を示す図である。 図２は、ホストマシン１で動作する各コンテナ３の機能を説明する図である。 図３は、ホストマシン１で動作する各コンテナ３の機能を説明する図である。 図４は、ホストマシン１で動作する各コンテナ３の機能を説明する図である。 図５は、ホストマシン１で動作する各コンテナ３の機能を説明する図である。 図６は、ホストマシン１のハードウエア構成を示す図である。 図７は、マスターノード２１の機能のブロック図である。 図８は、第１の実施の形態における制御処理の概略を説明するフローチャート図である。 図９は、第１の実施の形態における制御処理の概略を説明する図である。 図１０は、第１の実施の形態における制御処理の概略を説明する図である。 図１１は、第１の実施の形態における制御処理の概略を説明する図である。 図１２は、第１の実施の形態における制御処理の概略を説明する図である。 図１３は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。 図１４は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。 図１５は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。 図１６は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。 図１７は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。 図１８は、対応情報１３１の具体例を説明する図である。

［情報処理システムの構成］
図１は、情報処理システム１０の全体構成を示す図である。図１に示す情報処理システム１０は、例えば、利用者にサービスを提供するための業務システムである。図１に示す情報処理システム１０において、ホストマシン１がデータセンター（図示しない）内に設けられている。そして、クライアント端末５は、インターネットやイントラネット等のネットワークを介して、データセンターとアクセス可能になっている。

ホストマシン１は、例えば、複数の物理マシンから構成される。各物理マシンは、ＣＰＵ（Ｃｅｎｔｒａｌ Ｃｏｍｐｕｔｉｎｇ Ｕｎｉｔ）と、メモリ（ＤＲＡＭ：Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）と、ハードディスク（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の大容量メモリとを有する。そして、ホストマシン１の物理リソースは、利用者に対してサービスを提供するための各処理を実行される複数のコンテナ３に割当てられる。

コンテナ型仮想化ソフトウエア４は、ホストマシン１のＣＰＵ、メモリ、ハードディスク及びネットワークを割当てることにより、コンテナ３を生成する基盤ソフトウエアである。コンテナ型仮想化ソフトウエア４は、例えば、ホストマシン１において動作する。

［ホストマシンで動作する各仮想マシンの機能］
次に、ホストマシン１で動作する各コンテナ３の機能を説明する。図２から図４は、ホストマシン１で動作する各コンテナ３の機能を説明する図である。なお、以下、図１で説明したホストマシン１には、ホストＯＳ１１ａ、１２ａ及び１３ａがそれぞれ動作するホストマシン１１、１２及び１３が含まれるものとして説明を行う。また、以下、各ホストマシン１では、１つのマスターノードまたは１つのスレーブノードのみが動作するものとして説明を行う。

図２に示すホストマシン１１上では、プロセスとしてＪｏｂＴｒａｃｋｅｒが動作するコンテナであるＪｏｂＴｒａｃｋｅｒコンテナ３１ａ（以下、ＪＴ３１ａとも呼ぶ）と、プロセスとしてＮａｍｅＮｏｄｅが動作するコンテナ３であるＮａｍｅＮｏｄｅコンテナ３１ｂ（以下、ＮＮ３１ｂとも呼ぶ）とを含むマスターノード２１が動作する。

そして、図２に示すホストマシン１２上では、プロセスとしてＴａｓｋＴｒａｃｋｅｒが動作するコンテナ３であるＴａｓｋＴｒａｃｋｅｒコンテナ３２ａ（以下、ＴＴ３２ａとも呼ぶ）と、プロセスとしてＤａｔａＮｏｄｅが動作するコンテナであるＤａｔａＮｏｄｅコンテナ３２ｂ（以下、ＤＮ３２ｂとも呼ぶ）とを含むスレーブノード２２が動作する。

さらに、図３に示すホストマシン１３上では、ＴａｓｋＴｒａｃｋｅｒコンテナ３３ａ（以下、ＴＴ３３ａとも呼ぶ）と、ＤａｔａＮｏｄｅコンテナ３３ｂ（以下、ＤＮ３３ｂとも呼ぶ）とを含むスレーブノード２３が動作する。

そして、マスターノード２１（マスターノード２１に含まれる通信機能）は、図２に示すように、例えば、ＴＴ３２ａ及びＴＴ３３ａから通信の応答が定期的にあるか否かの判定を行う。その結果、例えば、図３に示すように、ＴＴ３３ａから通信の応答が途絶えたことを検知した場合、マスターノード２１は、ＴＴ３３ａにおいて異常が発生した可能性があると判定する。

ここで、マスターノード２１は、他のコンテナ３（ＴＴ３２ａ、ＤＮ３２ｂ、ＴＴ３３ａ及びＤＮ３３ｂ）からの通知の応答があるか否かの判定を行うことが可能である一方、他のコンテナ３が動作するホストマシン１２及び１３の動作状況については監視することができない。すなわち、マスターノード２１は、例えば、他のコンテナ３からの応答がなくなった場合、コンテナ３及びホストマシン１の両方において異常が発生しているのか、コンテナ３のみにおいて異常が発生しているのかを判定することができない。

そのため、ＪＴ３１ａは、例えば、ＴＴ３３ａの再起動に応じて行われたタスクデータの再配置が長引いたことに起因してタイムアウトが発生した場合（ホストマシン１３において異常が発生していない場合）であっても、図４に示すように、実行中のタスクデータの再配置を中止し、タイムアウトの発生に応じて行われるタスクデータの再配置を最初から開始する場合がある。したがって、ＪＴ３１ａでは、例えば、ホストマシン１３において異常が発生していない場合であっても、ＴＴ３３ａの再起動に必要以上の時間を要する場合がある。

そこで、本実施の形態におけるマスターノード２１は、例えば、複数のスレーブノード２２及び２３を構成するコンテナ３２ａ及び３３ａからの通信の応答状況を監視する。そして、マスターノード２１は、例えば、複数のスレーブノード２２及び２３に含まれるコンテナ３のいずれか（以下、特定のコンテナとも呼ぶ）からの通信の応答状況に異常を検出した場合、あらかじめ蓄積された特定のコンテナが動作するホストマシン１（以下、特定のホストマシンとも呼ぶ）を示す情報（以下、対応情報とも呼ぶ）に基づき、特定のホストマシンの動作状況を推定する。

その後、マスターノード２１は、推定の結果に応じて、分散処理が行われるデータのデータ量に基づいて算出された、特定のコンテナを特定のホストマシンと異なるホストマシン１において動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する。

すなわち、マスターノード２１は、例えば、ＴＴ３３ａからの通信の応答が途絶えていることを検知した場合、対応情報を参照することにより、ＴＴ３３ａが動作するホストマシン１３が停止しているか否かを判定する。具体的に、マスターノード２１は、ホストマシン１３上で動作するコンテナ３（ＴＴ３３ａ及びＤＮ３３ｂ）とホストマシン１３との両方において異常が発生しているのか、ホストマシン１３上で動作するコンテナ３のみにおいて異常が発生しているのかを判定する。

そして、マスターノード２１は、例えば、ホストマシン１３上で動作するコンテナ３のみにおいて異常が発生していると判定した場合（ホストマシン１３で異常が発生していないと判定した場合）、タイムアウトが発生したか否かを判定する際に参照されるタイムアウト時間として、処理対象となるタスクデータのデータ量から予め算出した時間を用いる。

これにより、マスターノード２１は、ホストマシン１３において異常が発生していないと判定した場合、ＴＴ３３ａの再起動をタイムアウト時間が経過する前に完了させることが可能になる。そのため、マスターノード２１は、ホストマシン１３において異常が発生していないにもかかわらず、ＴＴ３３ａの再起動に応じて行われたタスクデータの再配置が中止されることを防止することが可能になる。したがって、マスターノード２１は、図５に示すように、図４で説明した場合と比較して、ＴＴ３３ａの再起動に要する時間を短縮させることが可能になる。

［情報処理システムのハードウエア構成］
次に、情報処理システム１０のハードウエア構成について説明する。図６は、ホストマシン１のハードウエア構成を示す図である。

ホストマシン１は、プロセッサであるＣＰＵ１０１と、メモリ１０２と、外部インターフェース（以下、Ｉ／Ｏユニットとも呼ぶ）１０３と、記憶媒体１０４とを有する。各部は、バス１０５を介して互いに接続される。

記憶媒体１０４は、例えば、記憶媒体１０４内のプログラム格納領域（図示しない）に、ＪｏｂＴｒａｃｋｅｒコンテナがＴａｓｋＴｒａｃｋｅｒコンテナの管理を行う処理（以下、制御処理とも呼ぶ）を行うためのプログラム１１０を記憶する。また、記憶媒体１０４は、例えば、制御処理を行う際に用いられる情報を記憶する情報格納領域１３０（以下、記憶部１３０とも呼ぶ）を有する。

ＣＰＵ１０１は、プログラム１１０の実行時に、プログラム１１０を記憶媒体１０４からメモリ１０２にロードし、プログラム１１０と協働して制御処理を行う。また、外部インターフェース１０３は、例えば、クライアント端末５と通信を行う。

［マスターノードの機能及びマスターノードが参照する情報］
次に、マスターノード２１の機能について説明する。図７は、マスターノード２１の機能のブロック図である。

ホストマシン１のＣＰＵ１０１は、プログラム１１０と協働することにより、図７に示すように、マスターノード２１の機能として、時間算出部１１１と、スレーブ監視部１１２と、ホストマシン監視部１１３と、時間設定部１１４と、データ配置部１１５として動作する。また、マスターノード２１は、情報格納領域１３０に記憶された対応情報１３１とタイムアウト時間１３２とを参照する。

時間算出部１１１は、分散処理の対象となるタスクデータのデータ量に基づき、ＴＴ３２ａまたはＴＴ３３ａをブラックリスト入りさせるか否かを判定する際に参照されるタイムアウト時間１３２を算出する。具体的に、時間算出部１１１は、例えば、分散処理の対象となる新たなタスクデータのデータ量が取得される毎に、分散処理の対象となる新たなタスクデータのデータ量に基づいてタイムアウト時間１３２の算出を行う。

スレーブ監視部１１２は、複数のスレーブノード２２及び２３を構成するコンテナ３２ａ、３２ｂ、３３ａ及び３３ｂからの通信の応答状況を監視する。具体的に、スレーブ監視部１１２は、例えば、ＴＴ３２ａ、３２ｂ、３３ａ及び３３ｂのそれぞれからの通信の応答が定期的にあるか否かの判定を行う。

ホストマシン監視部１１３は、スレーブ監視部１１２が特定のコンテナ（例えば、コンテナ３２ａ及び３３ａのうちのいずれか）からの通信の応答状況について異常を検出した場合、情報格納領域１３０に記憶された対応情報１３１を参照し、特定のコンテナが動作する特定のホストマシンの動作状況を推定する。対応情報１３１は、各スレーブノードを構成するホストマシンとコンテナ群（ＴａｓｋＴｒａｃｋｅｒコンテナ及びＤａｔａＮｏｄｅコンテナ）とを対応付けた情報である。対応情報１３１の具体例については後述する。

時間設定部１１４は、ホストマシン監視部１１３が特定のホストマシンにおいて異常が発生していると判定した場合、時間算出部１１１が算出したタイムアウト時間１３２をマスターノード２１に参照させる。具体的に、時間設定部１１４は、時間算出部１１１が算出したタイムアウト時間１３２を、マスターノード２１がタイムアウトの発生有無を判定する際に参照する領域（例えば、メモリ１０２内の所定の領域）に設定する。

データ配置部１１５は、ＪＴ３１ａの機能であり、ＴＴ３２ａ及びＴＴ３３ａに対して処理対象となるタスクデータの配置を行う。

［第１の実施の形態の概略］
次に、第１の実施の形態の概略について説明を行う。図８は、第１の実施の形態における制御処理の概略を説明するフローチャート図である。図９から図１２は、第１の実施の形態における制御処理の概略を説明する図である。図９から図１２を参照しながら、図８に示す第１の実施の形態における制御処理の概略について説明を行う。

マスターノード２１は、複数のスレーブノード２２及び２３を構成するコンテナ３２ａ及び３３ａからの通信の応答状況を監視（モニタ）する（Ｓ１）。具体的に、マスターノード２１は、例えば、図９に示すように、ＴＴ３２ａ及びＴＴ３３ａからの通信の応答が定期的にあるか否かの判定を行う。

そして、マスターノード２１は、図１０に示すように、複数のスレーブノード２２及び２３を構成するコンテナ３２ａ及び３３ａのうちのいずれかのコンテナ（特定のコンテナ）からの通信の応答状況が異常であるか否かを判定する（Ｓ２）。

その結果、特定のコンテナからの通信の応答状況に異常を検出した場合（Ｓ２のＹＥＳ）、マスターノード２１は、図１１に示すように、Ｓ２の処理で検出した特定のコンテナが動作する特定のホストマシンを示す情報に基づき、特定のホストマシンにおける動作状況を推定する（Ｓ３）。

具体的に、例えば、ＴＴ３３ａからの通信の応答が途絶えていることを検出した場合、マスターノード２１は、対応情報１３１を参照し、ＴＴ３３ａが動作するホストマシン１としてホストマシン１３を特定する。そして、マスターノード２１は、対応情報１３１をさらに参照し、特定したホストマシン１３上で動作するＤＮ３３ｂ（ホストマシン１３上で動作するコンテナ３のうちのＴＴ３３ａ以外のコンテナ３）を特定する。その後、マスターノード２１は、ＤＮ３３ｂからの通信の応答が定期的にあるか否かの判定を行う。その結果、ＤＮ３３ｂからの通信の応答が定期的にあると判定した場合、マスターノード２１は、ホストマシン１３においては異常が発生していないと判定する。一方、ＤＮ３３ｂからの通信の応答が途絶えていると判定した場合、マスターノード２１は、ホストマシン１３においても異常が発生していると判定する。

その後、マスターノード２１は、図１２に示すように、Ｓ３の処理の推定の結果に応じて、分散処理が行われるデータのデータ量に基づいて算出された、特定のコンテナを特定のホストマシンと異なるホストマシン１において動作させるか否かの判定を行う際に参照されるタイムアウト時間１３２を設定する（Ｓ４）。なお、Ｓ２の処理において、特定のコンテナからの通信の応答状況に異常を検出しなかった場合（Ｓ２のＮＯ）、マスターノード２１は、Ｓ３及びＳ４の処理を行わない。

これにより、マスターノード２１は、ホストマシン１３において異常が発生していないと判定した場合、新たなタイムアウト時間１３２を設定することで、ＴＴ３３ａの再起動をタイムアウト時間が経過する前に完了させることが可能になる。

［第１の実施の形態の詳細］
次に、第１の実施の形態の詳細について説明する。図１３から図１７は、第１の実施の形態における制御処理の詳細を説明するフローチャート図である。また、図１８は、第１の実施の形態における制御処理の詳細を説明する図である。図１８を参照しながら、図１３から図１７に示す制御処理の詳細を説明する。

［時間算出処理］
初めに、制御処理の事前処理である時間算出処理について説明を行う。時間算出処理は、処理対象となるタスクデータのデータ量からタイムアウト時間１３２を算出する処理である。図１３は、時間算出処理を説明するフローチャート図である。

マスターノード２１の時間算出部１１１は、図１３に示すように、処理対象となるタスクデータのデータ量を取得する（Ｓ１１）。そして、時間算出部１１１は、Ｓ１１の処理で取得したデータ量から、タイムアウト時間１３２を算出する（Ｓ１２）。以下、Ｓ１２の処理の詳細について説明を行う。

［Ｓ１２の処理の詳細］
図１４は、Ｓ１２の処理の詳細を説明するフローチャート図である。

時間算出部１１１は、例えば、分散処理の対象となるタスクデータのデータ量Ｍ（ＧＢ）と、分割データのデータ量Ｄ（ＭＢ）と、タスクデータの複製数Ｒ（個）と、各分割データの割り当て時間Ｗ（ｓｅｃ）とを取得する（Ｓ２１）。分割データのデータ量Ｄは、各ＴａｓｋＴｒａｃｋｅｒコンテナが処理を行う単位のデータ量である。なお、タスクデータのデータ量Ｍ、分割データのデータ量Ｄ、タスクデータの複製数Ｒ及び各分割データの割り当て時間Ｗは、例えば、事業者によってあらかじめ情報格納領域１３０に記憶されるものであってもよい。そして、時間算出部１１１は、例えば、情報格納領域１３０を参照することによって、各情報を取得するものであってもよい。

続いて、時間算出部１１１は、例えば、Ｓ２１の処理で取得したタスクデータのデータ量Ｍを、Ｓ２１の処理で取得した分割データのデータ量Ｄで除算することにより、分割データ数を算出する（Ｓ２２）。そして、時間算出部１１１は、例えば、Ｓ２２で算出した分割データ数と、Ｓ２１で取得したタスクデータの複製数Ｒと、Ｓ２１の処理で取得した各分割データの割り当て時間Ｗとを乗算することにより、タイムアウト時間１３２として算出する（Ｓ２３）。

すなわち、時間算出部１１１は、Ｓ２２及びＳ２３の処理において、例えば、以下の式（１）用いることにより、タイムアウト時間１３２を算出する。
タイムアウト時間１３２＝（Ｍ／Ｄ）×Ｒ×Ｗ ・・・ （１）

これにより、時間算出部１１１は、例えば、全て分割データを１つのＴａｓｋＴｒａｃｋｅｒコンテナが処理を行う場合における処理時間の概算を、新たなタイムアウト時間１３２として算出することが可能になる。

なお、時間算出部１１１は、例えば、上記の式（１）において算出された値に所定の係数（例えば、１．１）を乗算した値を、新たなタイムアウト時間１３２とするものであってもよい。

［制御処理の詳細］
次に、制御処理の詳細について説明を行う。図１５から図１７は、制御処理の詳細を説明するフローチャート図である。

マスターノード２１のスレーブ監視部１１２は、図１５に示すように、ＴＴ３２ａ及び３３３３ａからの通信の応答状況を監視する（Ｓ３１）。そして、スレーブ監視部１１２は、ＴＴ３２ａ及び３３ａのうち、通信の応答を確認することができないＴａｓｋＴｒａｃｋｅｒコンテナが存在するか否かを判定する（Ｓ３２）。

その結果、マスターノード２１のホストマシン監視部１１３は、情報格納領域１３０に記憶された対応情報１３１に基づき、Ｓ３２の処理で存在したＴａｓｋＴｒａｃｋｅｒコンテナが動作するホストマシン１で動作するＤａｔａＮｏｄｅコンテナを特定する（Ｓ３３）。以下、対応情報１３１の具体例について説明を行う。

［対応情報の具体例］
図１８は、対応情報１３１の具体例を説明する図である。

図１８に示す対応情報１３１は、対応情報１３１に含まれる各情報を識別する「項番」と、ホストマシン名が設定される「ホストマシン」と、コンテナ名が設定される「コンテナ名（１）」及び「コンテナ名（２）」とを項目として有する。

具体的に、図１８に示す対応情報１３１において、「項番」が「１」である情報には、「ホストマシン名」として「ホストマシン１１」が設定され、「コンテナ名（１）」として「ＪＴ３１ａ」が設定され、「コンテナ名（２）」として「ＮＮ３１ｂ」が設定されている。

また、図１８に示す対応情報１３１において、「項番」が「２」である情報には、「ホストマシン名」として「ホストマシン１２」が設定され、「コンテナ名（１）」として「ＴＴ３２ａ」が設定され、「コンテナ名（２）」として「ＤＮ３２ｂ」が設定されている。

さらに、図１８に示す対応情報１３１において、「項番」が「３」である情報には、「ホストマシン名」として「ホストマシン１３」が設定され、「コンテナ名（１）」として「ＴＴ３３ａ」が設定され、「コンテナ名（２）」として「ＤＮ３３ｂ」が設定されている。

具体的に、Ｓ３３の処理において、例えば、通信の応答を確認することができないＴａｓｋＴｒａｃｋｅｒコンテナがＴＴ３３ａである場合、ホストマシン監視部１１３は、図１８で説明した対応情報１３１を参照し、「コンテナ（１）」及び「コンテナ（２）」のいずれかに「ＴＴ３３ａ」が設定された情報の「ホストマシン名」に設定された情報である「ホストマシン１３」を特定する。そして、ホストマシン監視部１１３は、図１８で説明した対応情報１３１をさらに参照し、「ホストマシン名」に「ホストマシン１３」が設定された情報の「コンテナ（１）」及び「コンテナ（２）」に設定された情報のうち、「ＴＴ３３ａ」以外の情報である「ＤＮ３３ｂ」を特定する。

図１５に戻り、ホストマシン監視部１１３は、Ｓ３３の処理で特定したＤａｔａＮｏｄｅコンテナからの通信の応答状況を判定する（Ｓ３４）。

その結果、図１６に示すように、ＤａｔａＮｏｄｅコンテナからの応答が確認できた場合（Ｓ４１のＹＥＳ）、マスターノード２１の時間設定部１１４は、Ｓ１２の処理で算出したタイムアウト時間１３２を設定する（Ｓ４２）。具体的に、時間設定部１１４は、例えば、マスターノード２１がＴＴ３２ａまたはＴＴ３３ａをブラックリスト入りさせるか否かを判定する際に参照する領域（例えば、メモリ１０２内の所定の領域）に、Ｓ１２の処理で算出したタイムアウト時間１３２を設定する。

そして、Ｓ２２の処理で存在したＴａｓｋＴｒａｃｋｅｒコンテナにおいてタイムアウトが発生しなかった場合（Ｓ４３のＮＯ）、マスターノード２１は、制御処理を終了する。

一方、Ｓ４１の処理において、ＤａｔａＮｏｄｅコンテナからの応答が確認できなかった場合（Ｓ４１のＮＯ）、ホストマシン監視部１１３は、図１７に示すように、Ｓ３２の処理で存在したＴａｓｋＴｒａｃｋｅｒコンテナが動作するホストマシン１が停止していると判定する（Ｓ５１）。そして、ホスト監視部１１３は、Ｓ３２の処理で存在したＴａｓｋＴｒａｃｋｅｒコンテナからの通信の応答が再開されない旨の情報をクライアント端末５に送信する（Ｓ５２）。

すなわち、例えば、Ｓ４１の処理においてＤＮ３３ｂからの応答が確認できなかった場合、マスターノード２１は、ホストマシン１３において異常が発生していると判定し、Ｓ３２の処理で応答を確認できなかったＴＴ３３ａをブラックリスト入りさせる。そして、マスターノード２１は、この場合、例えば、ＴＴ３３ａがブラックリスト入りした旨の情報をクライアント端末５に送信する。その後、例えば、クライアント端末５に送信された情報を閲覧した事業者は、ブラックリスト入りしたＴＴ３３ａに代わるＴａｓｋＴｒａｃｋｅｒコンテナを他のホストマシン１に起動させる。

これにより、マスターノード２１は、新たなＴａｓｋＴｒａｃｋｅｒコンテナを含めた複数のＴａｓｋＴｒａｃｋｅｒコンテナに対して、処理対象となるタスクデータの再配置を行うことが可能になる。

図１７に戻り、他のホストマシン１において新たなＴａｓｋＴｒａｃｋｅｒコンテナの起動が完了した場合（Ｓ５３のＹＥＳ）、データ配置部１１５は、新たなＴａｓｋＴｒａｃｋｅｒコンテナを含む複数のＴａｓｋＴｒａｃｋｅｒコンテナに対し、処理対象となるタスクデータの再配置を行う（Ｓ５４）。

また、マスターノード２１は、Ｓ２２の処理で存在したＴａｓｋＴｒａｃｋｅｒコンテナにおいてタイムアウトが発生した場合も同様に（Ｓ４３のＹＥＳ）、Ｓ５２からＳ５４の処理を行う。

このように、本実施の形態におけるマスターノード２１は、例えば、複数のスレーブノード２２及び２３を構成するコンテナ３２ａ及び３３ａからの通信の応答状況を監視する。そして、マスターノード２１は、例えば、複数のスレーブノード２２及び２３に含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された特定のコンテナが動作する特定のホストマシンを示す対応情報に基づき、特定のホストマシンの動作状況を推定する。

その後、マスターノード２１は、推定の結果に応じて、分散処理が行われるデータのデータ量に基づいて算出された、特定のコンテナを特定のホストマシンと異なるホストマシン１において動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する。

すなわち、マスターノード２１は、例えば、ＴＴ３３ａからの通信の応答が途絶えていることを検知した場合、対応情報を参照することにより、ＴＴ３３ａが動作するホストマシン１３が停止しているか否かを判定する。具体的に、マスターノード２１は、ホストマシン１３上で動作するコンテナ３（ＴＴ３３ａ及びＤＮ３３ｂ）と、ホストマシン１３との両方において異常が発生しているのか、ホストマシン１３上で動作するコンテナ３のみにおいて異常が発生しているのかを判定する。

そして、マスターノード２１は、例えば、ホストマシン１３上で動作するコンテナ３のみにおいて異常が発生していると判定した場合、タイムアウトが発生したか否かを判定する際に参照されるタイムアウト時間として、処理対象となるタスクデータのデータ量から予め算出した時間を用いる。

これにより、マスターノード２１は、ホストマシン１３において異常が発生していないと判定した場合、ＴＴ３３ａの再起動をタイムアウト時間が経過する前に完了させることが可能になる。そのため、マスターノード２１は、予め設定された短いタイムアウト時間によってＴＴ３３ａの再起動が行われ、実行中のタスクデータの再配置が強制的に中断される事態の発生を防止することが可能になる。したがって、マスターノード２１は、ＴＴ３３ａの再起動を効率的に行うことが可能になり、再起動に要する時間の短縮が可能になる。

以上の実施の形態をまとめると、以下の付記のとおりである。

（付記１）
マスターノードを構成するコンテナと複数のスレーブノードを構成するコンテナとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御処理をコンピュータに実行させる制御プログラムにおいて、
前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、
前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定し、
前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する、
処理を前記コンピュータに実行させる制御プログラム。

（付記２）
付記１に記載の制御プログラムにおいて、
前記推定する処理では、前記特定のホストマシンにおいて動作するスレーブノードを構成するすべてのコンテナからの応答がない場合、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定する、
制御プログラム。

（付記３）
付記２に記載の制御プログラムにおいて、
前記設定する処理では、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定した場合に、前記タイムアウト時間の設定を行う、
制御プログラム。

（付記４）
付記１に記載の制御プログラムにおいて、
前記タイムアウト時間は、前記分散処理が行われるデータのデータ量を、前記スレーブノードが処理を行う単位である単位データのデータ量によって除算した値と、前記単位データの複製数と、前記単位データを前記スレーブノードに配置する際に要する時間とを乗算することによって算出された時間である、
制御プログラム。

（付記５）
付記１に記載の制御プログラムにおいて、
前記複数のスレーブノードのそれぞれに対する前記データの再配置は、前記特定のコンテナの再起動が行われたタイミングである第１タイミングと、前記特定のコンテナからの通信の応答がなくなってから前記タイムアウト時間が経過したタイミングである第２タイミングとにおいてそれぞれ行われ、
前記第１タイミングにおける前記データの再配置の実行中に、前記第２タイミングが発生した場合、前記第１タイミングにおける前記データの再配置が中止され、前記第２タイミングにおける前記データの再配置が行われる、
制御プログラム。

（付記６）
マスターノードを構成するコンテナと複数のスレーブノードを構成するコンテナとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御装置において、
前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視するスレーブ監視部と、
前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定するホストマシン監視部と、
前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する時間設定部と、を有する、
制御装置。

（付記７）
付記６に記載の制御装置において、
前記ホストマシン監視部は、前記特定のホストマシンにおいて動作するスレーブノードを構成するすべてのコンテナからの応答がない場合、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定する、
制御装置。

（付記８）
付記７に記載の制御装置において、
前記時間設定部は、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定した場合に、前記タイムアウト時間の設定を行う、
制御装置。

（付記９）
コンテナ上においてそれぞれ動作するマスターノードと複数のスレーブノードとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御方法において、
前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、
前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定し、
前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する、
制御方法。

（付記１０）
付記９に記載の制御方法において、
前記推定する工程では、前記特定のホストマシンにおいて動作するスレーブノードを構成するすべてのコンテナからの応答がない場合、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定する、
制御方法。

（付記１１）
付記１０に記載の制御方法において、
前記設定する工程では、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定した場合に、前記タイムアウト時間の設定を行う、
制御方法。

１：ホストマシン ３：コンテナ
４：コンテナ仮想化ソフトウエア ５：クライアント端末

Claims (7)

1. マスターノードを構成するコンテナと複数のスレーブノードを構成するコンテナとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御処理をコンピュータに実行させる制御プログラムにおいて、
   前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、
   前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定し、
   前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する、
   処理を前記コンピュータに実行させる制御プログラム。
2. 請求項１に記載の制御プログラムにおいて、
   前記推定する処理では、前記特定のホストマシンにおいて動作するスレーブノードを構成するすべてのコンテナからの応答がない場合、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定する、
   制御プログラム。
3. 請求項２に記載の制御プログラムにおいて、
   前記設定する処理では、前記特定のホストマシンが前記特定のコンテナを動作させることができない状態にあると判定した場合に、前記タイムアウト時間の設定を行う、
   制御プログラム。
4. 請求項１に記載の制御プログラムにおいて、
   前記タイムアウト時間は、前記分散処理が行われるデータのデータ量を、前記スレーブノードが処理を行う単位である単位データのデータ量によって除算した値と、前記単位データの複製数と、前記単位データを前記スレーブノードに配置する際に要する時間とを乗算することによって算出された時間である、
   制御プログラム。
5. 請求項１に記載の制御プログラムにおいて、
   前記複数のスレーブノードのそれぞれに対する前記データの再配置は、前記特定のコンテナの再起動が行われたタイミングである第１タイミングと、前記特定のコンテナからの通信の応答がなくなってから前記タイムアウト時間が経過したタイミングである第２タイミングとにおいてそれぞれ行われ、
   前記第１タイミングにおける前記データの再配置の実行中に、前記第２タイミングが発生した場合、前記第１タイミングにおける前記データの再配置が中止され、前記第２タイミングにおける前記データの再配置が行われる、
   制御プログラム。
6. マスターノードを構成するコンテナと複数のスレーブノードを構成するコンテナとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御装置において、
   前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視するスレーブ監視部と、
   前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定するホストマシン監視部と、
   前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する時間設定部と、を有する、
   制御装置。
7. コンテナ上においてそれぞれ動作するマスターノードと複数のスレーブノードとが連携して分散処理を行う情報処理システムに含まれる前記複数のスレーブノードの制御方法において、
   前記複数のスレーブノードを構成するコンテナからの通信の応答状況を監視し、
   前記複数のスレーブノードに含まれる特定のコンテナからの通信の応答状況に異常を検出した場合、あらかじめ蓄積された前記特定のコンテナが動作する特定のホストマシンを示す情報に基づき、前記特定のホストマシンの動作状況を推定し、
   前記推定の結果に応じて、前記分散処理が行われるデータのデータ量に基づいて算出された、前記特定のコンテナを前記特定のホストマシンと異なるホストマシンにおいて動作させるか否かの判定を行う際に参照されるタイムアウト時間を設定する、
   制御方法。

Images