JP2017219972A - コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム - Google Patents

Abstract

【課題】互いに関係する複数の処理を負荷分散して実行する処理ノードを含むシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させる。【解決手段】コンピュータプログラムは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第１の処理の負荷を監視させる。そして、コンピュータプログラムは、このコンピュータシステムに、第１の処理の負荷が第１の条件を超えるときに、第１の処理に関係する第２の処理を実行する処理プログラムを第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる。【選択図】図７

Description

本発明は、コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システムに関する。

近年、マイクロサービスにコンテナ技術を適用したシステム構築が採用されている。マイクロサービスは、構築されるシステム全体よりも軽量な複数のサービスを連携させて１つのアプリケーションを作成する開発手法ということができる。マイクロサービスでは、従来１つのシステムとして構築されていたサービスが責務ごとのサービスに分離される。分離された責務ごとのサービス間をＲＥＳＴｆｕｌ などのシンプルで疎な結合にて結びつけることで、分離された個々のサービスの組み合わせによってアプリケーションが構築される。このような責務ごとにサービスが分離されるとともに、シンプルで疎な結合にて結びつけることで、システムの可搬性・可用性を高めることができる。なお、ＲＥＳＴｆｕｌは、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）と呼ばれる、ウェブに例示されるソフトウェアのアーキテクチャである。

上述のように、マイクロサービスによるシステム構築を採用する場合に、コンテナ技術が用いられることがある。コンテナは、単一のオペレーティングシステム（ＯＳ）の環境で、複数の分離された空間を作成し、分離された空間ごとに異なるアプリケーションの環境を提供する技術ということができる。コンテナでは、単一のＯＳカーネルの環境で、プロセスを分離することで、異なるＯＳ環境を提供できる、ともいうことができる。

従来、例えば、異なるＯＳ環境を提供する技術として、仮想マシンが採用されている。仮想マシンでは、例えば、ハイパーバイザのような仮想化ソフトウェアが、仮想的なハードウェアを提供し、ゲストＯＳを稼働させる。仮想マシンのゲストＯＳは、物理マシン上のＯＳと同様に動作する。

一方、コンテナの環境では、単一のＯＳカーネルで複数のコンテナがプロセスとして稼働するため、ハードウェア資源の使用量、オーバーヘッド等が仮想マシンと比較して小さくなる。したがって、仮想マシンに比べ、より軽量なコンテナ技術を生かすことで、マイクロサービスによるシステム構築とシステム運用の効率化が期待できる。

ところで、構築されたシステムの処理能力を向上するため、スケールアウトが実施されることがある。図１に、個々にスケールアウトされる複数サービスを含む情報処理システムを例示する。図１では、情報処理システムは、ユーザインターフェース（ＵＩ）と、アカウント管理と、帳票作成と、グラフ描画と、承認処理と、データ登録と、グラフデータ作成というマイクロサービスによって構築される。なお、アカウント管理は、帳票作成、承認処理、およびデータ登録という各マイクロサービスの処理結果を利用するものとする。また、グラフ描画は、グラフデータ作成というマイクロサービスの処理結果を利用するものとする。なお、図１の各マイクロサービスは、それぞれ上記コンテナ技術を用いて実行することができる。

図２は、物理環境、仮想マシンによる仮想環境、コンテナによる仮想環境を比較する。物理環境では、情報処理システムは、例えば、ハードウェア、ＯＳ、ミドルウェア、アプリケーションを有する。また、仮想マシンによる仮想環境では、情報処理システムは、例えば、ハードウェア、ホストＯＳ、ハイパーバイザ、１以上のゲストＯＳ、ゲストＯＳ上
のミドルウェア、ミドルウェア上のアプリケーションを有する。一方、コンテナによる仮想環境では、情報処理システムは、ハードウェア、ＯＳ、ＯＳ上の１以上のコンテナを有する。また、各コンテナは、ミドルウェア、ミドルウェア上のアプリケーションを有する。上述のように、コンテナは、１つのＯＳカーネル上の異なるプロセスとして起動される。

仮想マシンに対して、コンテナ技術の特徴を例示すると以下の通りである。コンテナは、仮想マシンに比べて起動が高速である。コンテナの起動はＯＳ上のプロセスの起動に相当するからである。コンテナ環境は、仮想マシンの環境に比べてメモリの使用量が少ない。コンテナ環境では、ＯＳ、あるいはＯＳのカーネルを共通要素として、ＯＳ上の１以上のコンテナ自体はカーネルを含まないからである。なお、コンテナ技術では、ＯＳのうちカーネルが共通化され、コンテナごとに分離されたプロセスはカーネル以外の部分（ミドルウェアとも呼ぶ）を起動可能である。そして、コンテナ環境では、Ｄｏｃｋｅｒに例示されるコンテナ管理ツールを利用することにより、ＯＳは、リポジトリに登録済みのコンテナイメージをダウンロードし、ダウンロードしたコンテナイメージを元にＯＳの１プロセスとしてコンテナ型の仮想環境を起動することが可能である。

したがって、例えば、図１の情報システムでは、コンテナ技術を用いることで、個々のマイクロサービスごとにスケールアウトが可能である。例えば、個々のマイクロサービスの負荷に応じて、ＵＩに対して３つのノードを割り当て、アカウント管理に２つのノードを割り当て、データ登録に２つのノードを割り当て、グラフデータ作成に２つのノードを割り当てる、といったことが可能である。なお、スケールアウトは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムの性能向上の手法の１つである。スケールアウトは、コンピュータシステムにおいて実行される処理に割り当てられる処理ノードの追加ということができる。

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

上述のように、コンテナ技術とマイクロサービスによって構築された情報処理システムでは、効率的なシステム構築とシステム運用が期待される。例えば、上述のように、マイクロサービスでは、責務ごとに分離されたサービス個々にスケールアウトすることで、少ないリソースの増加でシステムを健全化することができる。一方、マイクロサービスでは、複数のサービスが連携して１つのアプリケーションを作成する。したがって、一のサービスの負荷に対応して設備の数を増加した場合に、この一のサービスと連携する他のサービスにおいても負荷に対応する設備の数が増加する場合がある。つまり、一のサービスのスケールアウトによって、連鎖的に他のサービスの負荷が増加し、他のサービスがスケールアウトすることがある。

なお、このような連鎖的な負荷の増加はコンテナ技術に限定される訳ではない。例えば、仮想マシンを用いてマイクロサービスによるシステムを構築する場合も、同様のことが生じ得る。つまり、一のサービスを実行する仮想マシンの負荷に対応して、仮想マシンの数を増加した場合に、この一のサービスと連携する他のサービスを実行する他の仮想マシンの数の増加につながる場合がある。

すなわち、コンテナ技術を一例として、コンピュータ上の処理では、一の処理が他の処理と関係することがある。例えば、１つの処理の結果が他の処理の入力となる場合があり得る。したがって、１つの処理の負荷が増加しスケールアウトした結果、スループットが向上した場合、他の処理に対する処理要求が増加し、他の処理の負荷が増加する可能性がある。また、１つの処理の負荷が増加しスケールアウトした結果、スループットが向上した場合、他の処理に対する入力が増加し、他の処理の負荷が増加する可能性がある。

このように、一の処理が他の処理と関係する複数の処理がシステムに含まれる場合、１つ１つの処理に対してスケールアウトの要否を判断したのでは、システム全体の負荷の適正化までの時間を要するおそれがある。一方、１つの処理に対するスケールアウトが実施されたときに、単純に、当該処理に対して上記関係の他の処理においてスケールアウトを実施した場合には、上記関係の他の処理において、実際にスケールアウトが実施される状況になるか否かが確定的でなく、無駄なスケールアウトを実施する可能性がある。

本発明の課題は、互いに関係する複数の処理を負荷分散して実行する処理ノードを含むシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させることにある。

開示の技術の一側面は、コンピュータプログラムによって例示される。本コンピュータプログラムは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第１の処理の負荷を監視させる。そして、このコンピュータシステムに、第１の処理の負荷が第１の条件を超えるときに、前記第１の処理に関係する第２の処理を実行する処理プログラムを前記第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる。

本コンピュータプログラムによれば、互いに関係する複数の処理を負荷分散して実行する処理ノードを含むコンピュータシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させることができる。

個々にスケールアウトされる複数サービスを含む情報処理システムを例示する図である。 物理環境、仮想マシンによる仮想環境、コンテナによる仮想環境を比較する図である。 コンテナ技術を採用する情報システムにおけるコンテナ起動処理を例示する図である。 比較例１の情報処理システムにおけるスケールアウトの実行例を示す図である。 依存関係のあるサービス間のスケールアウトの詳細を例示する図である。 サービスの状態の変化を例示する図である。 実施形態１の情報処理システムにおける、依存関係のあるサービス間のスケールアウトの詳細を例示する図である。 比較例１のスケールアウトの手順と、実施形態１のスケールアウトの手順を比較する図である。 実施形態１の情報処理システムにおいて実行されるスケールアウトの処理手順を例示する図である。 比較例２のスケールアウトの処理を例示する図である。 マイクロサービスの依存関係を例示する図である。 比較例３の処理を例示するタイムチャートである。 比較例３にしたがって、情報処理システムが予めコンテナイメージをダウンロードした場合の処理例である。 情報処理システムの構成を例示する図である。 情報処理装置のハードウェア構成を例示する図である。 コンテナクラスタ管理プログラムの処理を例示する図である。 コンテナ管理プログラムの処理を例示する図である。 サービス状態テーブルの構成を例示する図である。 サービス依存テーブルの構成を例示する図である。 サービスの状態遷移を例示する図である。

以下、図面を参照して、一実施形態に係る情報処理システムについて説明する。以下の実施形態の構成は例示であり、本情報処理システムは実施形態の構成には限定されない。［比較例１］

図３から図５により、比較例１に係る情報処理システムを例示する。図３に、コンテナ技術を採用する情報システムにおけるコンテナ起動処理を例示する。図３の情報処理システムでは、コンテナが登録されたコンテナイメージリポジトリと、コンテナイメージリポジトリにネットワークを介して接続されるノードが例示される。コンテナイメージリポジトリ、および、各ノードはそれぞれ情報処理装置、サーバ、あるいはコンピュータと呼ばれる装置、設備等である。

図３の情報処理システムでは、コンテナイメージリポジトリには、コンテナイメージが登録されている。また、図３の情報処理システムでは、管理ツール（例えば、Ｄｏｃｋｅｒ）によってコンテナの実行が管理される。コンテナが一のノードに割当てられると、コンテナはコンテナイメージリポジトリから割当てられたノードにダウンロードされ、起動される。コンテナイメージは、ＯＳのカーネル以外の部分を含むミドルウェアと、アプリケーションプログラムを含む。

ここで、コンテナイメージとは、ＯＳカーネルへのインターフェースであるミドルウェアと、アプリケーションを含むプログラムである。ＯＳカーネルは、コンテナイメージによってＯＳカーネル上の１つのプロセスとしてコンテナを起動する。それぞれのコンテナは、ＯＳカーネル上の１つのプロセスとして、仮想環境を提供する。

図４に、比較例１の情報処理システムにおけるスケールアウトの実行例を示す。比較例１では、情報処理システムにおいて、例えば、グラフ描画、グラフデータ作成、データ収集という３つのマイクロサービスが連携して、アプリケーションを実行する場合を想定する。グラフ描画処理は、グラフデータ作成処理の結果を受け取り、グラフデータ作成処理はデータ収集処理の結果を受け取る。

今、グラフ描画処理の負荷が増大したため、グラフ描画処理を実行するサービスがスケールアウトしたと仮定する。すると、グラフ描画処理の処理能力向上に伴い、グラフ描画処理にデータを供給するグラフデータ作成処理の負荷が増加することが想定される。すると、グラフデータ作成処理を実行するサービスがスケールアウトする。すると、さらに、グラフデータ作成処理の処理能力向上に伴い、グラフデータ作成処理にデータを供給するデータ収集処理の負荷が増大することが想定される。すると、さらに、データ収集処理を実行するサービスがスケールアウトする。このように、連携するサービス間でスケールアウトの連鎖が広がっていく。図４のように、一のサービスの処理結果が次のサービスで利用される関係にある複数の連携するサービスを依存関係のあるサービスと呼ぶ。

なお、図４では、一のサービスと、当該一のサービスにデータを供給する他のサービスとの依存関係において、当該一のサービスが先にスケールアウトした場合のスケールアウトの連鎖を例示した。しかしスケールアウトの連鎖は逆方向にも生じ得る。つまり、当該一のサービスにデータを供給する他のサービスが先にスケールアウトし、その結果、データ供給を受ける当該一のサービスがスケールアウトすることで、連携するサービス間でスケールアウトの連鎖が広がっていくことも生じ得る。

図５に、依存関係のあるサービス間のスケールアウトの詳細を例示する。図４で説明したように、まず、グラフ描画処理を実行するサービスの負荷が増大したとする。負荷が所定の閾値を超えると、スケールアウトが開始される。比較例１においては、情報処理システムは、コンテナ技術を用いている。したがって、スケールアウトでは、グラフ描画処理に対応するコンテナに新たなノードが割当てられ、コンテナイメージがコンテナイメージリポジトリから割当てられたノードにダウンロードされる。そして、ダウンロード後に、ダウンロードされたコンテナイメージが起動される。新たに割当てられたノードで、グラフ描画処理に対応するコンテナが起動されることで、スケールアウトがなされ、グラフ描画処理を実行するサービスの処理能力が向上する。

そして、グラフ描画処理を実行するサービスの処理能力が向上し、処理量が増加すると、グラフ描画処理のサービスに描画データを提供するグラフデータ作成処理のサービスの負荷が増大する。グラフデータ作成処理のサービスの負荷が所定の閾値に達すると、グラフデータ作成処理のサービスに対しても、新たにノードが割当てられ、スケールアウトが実行される。すなわち、グラフデータ作成処理のサービスに新たなノードが割当てられ、コンテナイメージがダウンロードされ、起動される。さらに、同様のスケールアウトがデータ収集処理のサービスに対しても実行される。

図４、図５のように、サービス間で依存関係がある場合、一つのサービスが高負荷になり、そのサービスがスケールアウトすると、さらに関連するサービスの負荷が連鎖的に増加し、さらにスケールアウトが実行される。そして、図５の処理では、スケールアウト完了までに占めるダウンロード時間の割合が高まる。
［実施形態１］

図６から図９を参照して、実施形態１に係る情報処理システム１００を例示する。実施形態１では、上記の比較例１のような連鎖的に負荷が増加する情報処理システム１００におけるスケールアウトの効率向上を図る。そのため、情報処理システム１００は、サービスの依存関係を解釈し、各サービスが効率的にスケールアウトを実施するための新たな状態を定義する。

実施形態１において、サービスの依存関係は、上記比較例１で説明したものと同様である。すなわち、図４のように、一のサービスと、当該一の処理にデータを供給するサービスとの関係を依存関係という。スケールアウトの連鎖は、当該一のサービスが先にスケールアウトし、次に、当該一の処理にデータを供給するサービスがスケールアウトすることによって生じ得る。この場合、先にスケールアウトするサービスを前段判定サービスということにする。

また、スケールアウトの連鎖は逆方向にも生じ得る。つまり、当該一の処理にデータを供給する他のサービスが先にスケールアウトし、その結果、データ供給を受ける当該一のサービスがスケールアウトすることで、連携するサービス間でスケールアウトの連鎖が広がっていくことも生じ得る。この場合も、先にスケールアウトするサービスを前段判定サービスということにする。
各状態は以下の通りである。
状態１：負荷が閾値以内の場合である。状態１は、stableな状態と呼ばれる。
状態２：負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間内の場合である。状態２は、preparing1の状態と呼ばれる。
状態３：負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間経過した場合である。状態３は、firedな状態と呼ばれる。

状態４：前段判定サービスがfired な状態にあり、かつ、当該サービスの負荷が閾値以内の場合である。状態４は、preparing 2の状態と呼ばれる。
状態５：当該サービスがpreparing 2の状態にあり、かつ、当該サービスの負荷が閾値超
えした場合である。状態５も、firedな状態と呼ばれる。
実施形態１の情報処理システム１００において、各状態に対して実行されるアクションは、以下の通りである。

アクション１：前段判定サービスの負荷の閾値超えが所定時間継続したような高負荷状態であれば（firedな状態）、自サービスが閾値を超えた時点で(状態５)、スケールアウト
を実施する。すなわち、情報処理システム１００は、サービスが状態５になるとスケールアウトを実行する。この場合には、情報処理システム１００は、自サービスの負荷が所定時間継続的に閾値を超えるか否かを確認しない。

アクション２：状態２（preparing1）、状態４（preparing2）で、スケールアウトの準備を実施する。具体的には、本情報処理システム１００はサービスにノードを割当て、割当てられたノードにコンテナイメージをダウンロードする。アクション２により、例えば、結果的に自サービスで負荷が上がらずスケールアウトせず、ダウンロードが無駄になる可能性もある。しかし、本情報処理システム１００は、スケールアウトの見込みが高いと判断して、アクション２を実施する。アクション２による準備の実施で、ダウンロードされたコンテナイメージが実際に起動されるのは、自サービスが状態１になった場合である。

図６に、上記の比較例１と同様に、依存する３つのサービス、すなわち、グラフ描画処理のサービス、グラフデータ作成処理のサービス、およびデータ収集処理のサービスにおける状態の変化を例示する。図６では、グラフ描画処理のサービスの負荷はすでに閾値を超えた状態が所定時間継続し、状態３（firedな状態）となっている。この場合に、グラ
フ描画処理のサービス（非依存サービス）が依存するグラフデータ作成処理のサービスは状態４（preparing 2の状態）になっている。すなわち、グラフ描画処理のサービスはす
でにスケールアウトが実行され、グラフデータ作成処理のサービスは準備が実行される。

図７に、本情報処理システム１００における、依存関係のあるサービス間のスケールアウトの詳細を例示する。本実施形態においても、情報処理システム１００は、コンテナ技術を用いている。例えば、情報処理システム１００は、複数のノードを有し、依存関係のある複数のサービスにはそれぞれノードが割当てられる。それぞれのサービスに割当てられたノードは、割当てられたサービスに対応するコンテナを起動する。情報処理システム１００は、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムの一例である。

まず、当初、状態１（stableな状態）であったグラフ描画処理を実行するサービスの負荷が増大したとする。負荷が所定の閾値を超えると、サービスは状態２（preparing 1の
状態）となる。グラフ描画処理のサービスは、状態２（preparing 1の状態）になると、
サービスを実行するノードを新たに割当てられる。そして、新たに割当てられたノードに、グラフ描画処理のサービスのコンテナイメージがダウンロードされる。すなわち、グラフ描画処理のサービスに対して、スケールアウトの準備が開始される。

さらに、状態２（preparing 1の状態）が所定時間継続すると、サービスは状態３（firedの状態）となり、スケールアウトが開始される。すなわち、サービスに新たに割当てられたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、グラフ描画処理のサービスの負荷が低下し、状態１（stable）になる。

さらにまた、グラフ描画処理を実行するサービスが状態３（firedの状態）になると、
グラフ描画処理のサービスが状態３（firedの状態）であることが本情報処理システム１
００の管理装置に通知される。その結果、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが状態４（preparing ２の状態）となる。情報処理システム１００の管理装置としては、例えば、実施形態２のマスタサーバ２、およびコンテナイメージリポジトリサーバ１等が該当する。

そして、グラフデータ作成処理のサービスは、状態４（preparing ２の状態）になると、サービスを実行するノードを新たに割当てられる。そして、新たに割当てられたノードに、グラフデータ作成処理のサービスのコンテナイメージがダウンロードされる。

さらに、グラフデータ作成処理のサービスの負荷が所定の閾値を超えると、状態５（firedの状態）となり、スケールアウトが開始される。すなわち、サービスに新たに割当て
られたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、グラフデータ作成処理のサービスの負荷が低下し、状態１（stable）になる。

さらにまた、グラフデータ作成処理のサービスが状態５（firedの状態）になると、グ
ラフデータ作成処理のサービスが状態５（firedの状態）であることが本情報処理システ
ム１００の管理装置に通知される。その結果、グラフデータ作成処理のサービスにデータを提供するデータ収集処理のサービスが状態４（preparing ２の状態）となる。

そして、データ収集処理のサービスは、状態４（preparing ２の状態）になると、サービスを実行するノードを割当てられる。そして、割当てられたノードにデータ収集処理のサービスのコンテナイメージがダウンロードされる。

さらに、データ収集処理のサービスの負荷が所定の閾値を超えると、状態５（firedの
状態）となり、スケールアウトが開始される。すなわち、サービスに新たに割当てられたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、データ収集処理のサービスの負荷が低下し、状態１（stable）になる。

図８は、比較例１（図５）のスケールアウトの手順と、実施形態１のスケールアウトの手順を比較する図である。図８で、上側のフローは、図５に例示した比較例１の場合の処理手順である。また、図８で、下側のフローは、図７に例示した実施形態１の場合の処理手順である。図８の下側のように、本実施形態では、一のサービスがスケールアウトをすると、一のサービスに関係する他のサービスがスケールアウトの準備を開始する。すなわち、グラフデータ作成処理のサービスからデータ供給を受けるグラフ描画処理のサービスがスケールアウトを開始するとともに、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスのスケールアウトの準備が開始する。つまり、グラフデータ作成処理のコンテナイメージがサービスに割当てられたノードにダウンロードされる。したがって、グラフデータ作成処理で負荷が所定の閾値を超えた場合には、すでにコンテナがダウンロード済みとなっているため、ノードは直ちにコンテナイメージからコンテナ
を起動できる。

したがって、比較例１のように、情報処理システム１００が各サービスでそれぞれ個別に負荷を監視し、閾値を超えたときにスケールアウトする手順と比較して、図８の矢印で示される時間だけ、本実施形態の手順の方が、スケールアウト完了が早まる。なお、図８では、２つのサービスの間で依存関係がある場合のスケールアウトが例示されているが、依存関係のあるサービスがシーケンシャルにつながる数が多いほど、本実施形態による時間の短縮効果は大きくなる。

なお、図８で先にスケールアウトを開始するサービスを前段判定サービスといい、前段判定サービスがスケールアウト時にスケールアウトの準備を開始するサービスを当該サービスという。図８では、グラフデータ作成処理のサービスからデータの供給を受けるグラフ描画処理のサービスが前段判定サービスであり、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが当該サービスである。ただし、スケールアウトの連鎖の順序が図８と逆の場合もあり得る。すなわち、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが前段判定サービスとして、先にスケールアウトする場合もあり得る。その場合には、前段判定サービスであるグラフデータ作成処理のサービスがスケールアウトしたときに、当該サービスであるグラフ描画処理のサービスがスケールアウトの準備、すなわち、コンテナイメージのダウンロードをするようにすればよい。

図９に、本情報処理システム１００において実行されるスケールアウトの処理手順を例示する。図９は、１つのサービス（以下、当該サービスと呼ぶ）に着目した観点からの処理を例示するフローチャートである。まず、実施形態１の情報処理システム１００は、サービス定義から依存マップを作成する（Ｓ１）。サービス定義とは、例えば、サービスに対する入力情報、出力情報、および入力情報から出力情報を得るための処理等を定義した情報である。サービス定義は、例えば、利用者によって設定される。

本実施形態では、当該サービスに対して入力情報を取得する取得先のサービスを依存サービスと呼ぶ。また、当該サービスが出力情報を提供する提供先のサービスを被依存サービスと呼ぶ。本情報処理システム１００は、入力情報の取得先および出力情報の提供先の情報を基に、サービスの依存関係を示す依存マップを作成する。

依存マップには、各サービスと、依存サービスの関係が定義される。なお、各サービスに対する依存サービスが定義できれば、依存マップを逆にたどることによって、各サービスに対する被依存サービスが把握できる。ただし、依存マップは、各サービスに対して、依存サービスおよび被依存サービスの両方を定義してもよい。依存マップを格納したテーブルは、依存テーブルと呼ばれる。依存テーブルは、例えば、実施形態２の図１９で例示される。

また、本実施形態では、被依存サービス、すなわち、当該サービスの出力情報の提供先のサービスがスケールアウト要件を満たした場合に、当該サービスが状態４（preparing ２の状態）となる。そこで、本実施形態では、被依存サービスを前段判定サービスと呼ぶことにする。前段判定サービスは、第１の処理の一例である。また、前段判定サービスに対する当該サービスが第２の処理の一例である。

なお、被依存サービスを前段判定サービスとすることは、処理の一例であり、情報処理システム１００は、このような処理に限定される訳ではない。例えば、依存サービス、すなわち、当該サービスの入力情報の取得先となるサービスを前段判定サービスとしてもよい。つまり、当該サービスの入力情報の取得先となるサービスがスケールアウトした場合
に、当該サービスが状態４（preparing ２の状態）となるようにしてもよい。

次に、情報処理システム１００は、サービスを監視する（Ｓ２）。そして、情報処理システム１００は、スケールアウト要件を満たした前段判定サービスがあるか否かを判定する（Ｓ３）。Ｓ２およびＳ３の処理は、第１の処理の負荷を監視することの一例である。Ｓ３で、スケールアウト要件を満たした前段判定サービスがあるとの判定（Ｓ３でＹＥＳの判定）は、第１の処理の負荷が第１の条件を超えることの一例である。

なお、スケールアウト要件は、スケールアウトするか否かを自動的に判定する要件であるので、オートスケール要件とも呼ばれる。スケールアウト要件を満たした前段判定サービスがある場合、情報処理システム１００は、コンテナイメージがダウンロードされているか否かを判定する（Ｓ４）。そして、コンテナイメージがダウンロードされていない場合、情報処理システム１００は、コンテナイメージをコンテナイメージリポジトリからダウンロードする（Ｓ５）。ダウンロード先は、ダウンロードされたコンテナイメージが起動されるノードである。Ｓ５の処理は、第１の処理に関係する第２の処理を実行する処理プログラムを第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することの一例である。

そして、情報処理システム１００は、当該サービスの負荷が閾値を超えているか否かを判定する（Ｓ６）。Ｓ６の処理は、第１の処理に関係する第２の処理の負荷を監視することの一例である。すなわち、実施形態１の情報処理システム１００は、Ｓ２、Ｓ３に例示されるように第１の処理の負荷を監視するとともに、Ｓ６に例示されるように、第１の処理に関係する第２の処理の負荷を監視する。

ここで、第１の処理に関係する第２の処理とは、第１の処理に対して第２の処理の結果のデータを入力する第２の処理をいう。第１の処理の例は、実施形態１のグラフ描画処理のサービスである。第２の処理の例は、実施形態１のグラフデータ作成処理のサービスである。かりに第１の処理の負荷に応じて、第１の処理がスケールアウトされた場合、第１の処理に対して結果のデータを入力する第２の処理も逐次的にスケールアウトする可能性がある。したがって、Ｓ２、Ｓ３で、スケールアウト要件を満たした前段判定サービスがあることを確認した上で、Ｓ６で当該サービスの負荷が閾値を超えていることを確認することで、迅速かつ無駄を少なくして当該サービスをスケールアウトできる。

また、第１の処理に関係する第２の処理とは、第１の処理の結果のデータが入力される第２の処理をいう。この場合には、第１の処理の例は、実施形態１のグラフデータ作成処理のサービスである。第２の処理の例は、実施形態１のグラフ描画処理のサービスである。第１の処理がスケールアウトし、処理能力が向上すると、逐次的に第１の処理の結果のデータが入力される第２の処理がスケールアウトする場合もあるからである。

そして、当該サービスの負荷が閾値を超えている場合、情報処理システム１００は、コンテナイメージがダウンロードされたノードにおいて、コンテナイメージを起動する（Ｓ７）。Ｓ５の処理とＳ７の処理は、第２の処理を実行する処理ノードの数を増加することの一例である。Ｓ７の処理は、転送された処理プログラムを増加される処理ノードで起動することの一例でもある。Ｓ７の処理は、転送された処理プログラムを起動し、前記第２の処理を実行する処理ノードの数を増加することの一例でもある。

その後、情報処理システム１００は、Ｓ２の処理に戻る。なお、当該サービスの負荷が閾値を超えていない場合、情報処理システム１００は、コンテナイメージを起動しないで、Ｓ２の処理に戻る。Ｓ６で、当該サービスの負荷が閾値を超えているとの判定（ＹＥＳの判定）は、第２の処理の負荷が第２の条件を超えることの一例である。

一方、Ｓ３の判定で、スケールアウト要件を満たした前段判定サービスがない場合、情報処理システム１００は、当該サービスの負荷が閾値を超えているか否かを判定する（Ｓ８）。Ｓ３の判定で、スケールアウト要件を満たした前段判定サービスがないこと（Ｓ３でＮＯの判定）は、第１の処理の負荷が第１の条件を超えないことの一例である。Ｓ８の処理でＹＥＳの判定は、第２の処理の負荷が第２の条件を超えることの一例である。そして、当該サービスの負荷が閾値を超えている場合、情報処理システム１００は、コンテナイメージがダウンロードされているか否かを判定する（Ｓ９）。そして、コンテナイメージがダウンロードされていない場合、情報処理システム１００は、コンテナイメージをコンテナイメージリポジトリからダウンロードする（Ｓ１０）。Ｓ１０の処理は、第２の処理を実行する処理プログラムを増加される処理ノードにネットワークを通じて転送することの一例である。

さらに、情報処理システム１００は、所定の時間継続して当該サービスの負荷が閾値を超えているか否かを判定する（Ｓ１１）。Ｓ１１でＹＥＳの判定は、第２の条件が超える状態が規定時間継続したことの一例である。所定の時間継続して当該サービスの負荷が閾値を超えている場合、情報処理システム１００は、コンテナイメージがダウンロードされたノードにおいて、コンテナイメージを起動する（Ｓ７）。Ｓ１０の処理とＳ７の処理は、第２の処理を実行する処理ノードの数を増加することの一例である。Ｓ７の処理は、転送された処理プログラムを増加される処理ノードで起動することの一例でもある。その後、情報処理システム１００は、Ｓ２の処理に戻る。なお、当該サービスの負荷が閾値を超えた期間が所定の時間継続しなかった場合（Ｓ１１の判定でＮＯの場合）、情報処理システム１００は、コンテナイメージを起動しないで、Ｓ２の処理に戻る。

図９において、Ｓ４からＳ６の処理を実行中、サービスは、preparing 2の状態にある
。また、Ｓ８の処理でＮＯの判定がなされたとき、サービスは、stableの状態にある。また、Ｓ９からＳ１１の処理を実行中、サービスは、preparing 1の状態にある。そして、
Ｓ７の処理を実行中、サービスは、firedの状態にある。

以上述べたように、実施形態１の情報処理システム１００は、前段判定サービス、例えば、当該サービスからの出力情報を提供する提供先となる被依存サービスがスケールアウトすると、当該サービスにおいてもスケールアウトの準備を行う。すなわち、当該サービスの処理を新たなノードで実行するため、ノードにコンテナイメージをダウンロードする。したがって、依存関係のある複数サービスにおいて、スケールアウトが連鎖的に実行される場合も、比較例１の処理よりも早期にスケールアウトを完了できる。

また、当該サービスでスケールアウトを実行するのは、当該サービスで負荷が閾値を超えた場合である。したがって、実施形態１では、単に、前段判定サービスがスケールアウトしたことから、依存関係のある当該サービスでの負荷の増加を予測するのみでなく、当該サービスで実際に負荷が閾値を超えたことを条件にコンテナイメージが起動される。このため、無駄なスケールアウトがなされにくくなる。

また、実施形態１では、前段判定サービスがスケールアウトしない場合でも、当該サービスで負荷が閾値を超えた場合に、スケールアウトの準備を行う。すなわち、情報処理システム１００は、当該サービスの処理を新たなノードで実行するため、当該サービスを実行するノードを割当て、割当てたノードにコンテナイメージをロードする。そして、所定時間以上継続して負荷が閾値を超えた場合に、コンテナイメージが起動され、スケールアウトが実施される。したがって、当該サービスで負荷が閾値を超えたという第１の条件で、スケールアウトの準備をするとともに、所定時間以上継続して負荷が閾値を超えたという第２の条件で実際のスケールアウトが実行される。したがって、当該サービスにおける
判断で、スケールアウトを迅速に実行できる。さらに、このような処理によって、無駄なスケールアウトを抑止できる。
［比較例２］

図１０、図１１により、比較例２の処理を例示する。図１０は、比較例２のスケールアウトの処理を例示する図である。図１１は、処理対象の一例として、マイクロサービスの依存関係を例示する図である。

上記図９では、Ｓ１の処理のように、サービス定義から依存マップを作成し、前段判定サービスの状態と当該サービスの負荷の程度により、当該サービスの状態を判定する。すなわち、前段判定サービスがfiredの状態になると、情報処理システム１００は、当該サ
ービスのコンテナイメージをダウンロードしておき、当該サービスの負荷が閾値を超えると、当該サービスを起動する。

図９の処理を単純化すると、図１０で例示される比較例２の処理となる。比較例２では、例えば、前段判定サービス（グラフ描画処理）でスケールアウトを実施するとの判定がなされたときに、前段判定サービスだけでなく後段の当該サービス（グラフデータ作成処理）においてもスケールアウトを実施する。このような処理によっても、連鎖的なスケールアウトを比較例１の場合よりも早期に実行することは可能である。しかし、比較例２の処理は、マイクロサービスのようにより複雑な情報処理に対しては、処理効率が低下する。

図１１のような依存関係を有するマイクロサービスを想定する。図１１で、ＭＳ１からＭＳ８は、依存関係のある複数のマイクロサービスを例示する。依存関係のあるマイクロサービス同士は線分で接続されている。例えば、ＭＳ１を前段サービスとして、ＭＳ２、ＭＳ４、およびＭＳ８が連鎖的にスケールアウトする可能性のある依存サービスである。

比較例２の手順では、全てのサービスに対して、各サービスのスケールアウトの条件と後段サービスとの依存関係、およびスケールアウト条件を利用者が設定することになる。比較例１の図１に例示した３階層程度であれば、手動で定義することは現実的に可能である。しかし、マイクロサービスのように、多数段階に渡って依存関係が存在し、複雑かつ関連サービスが多い場合には、手動での依存関係の設定は困難となる。
［比較例３］

図１２、図１３を参照して、比較例３の処理を説明する。上記実施形態１では、前段判定サービスがスケールアウトの条件を充足したときに、後段の当該サービスに対応するコンテナイメージがダウンロードされる（図９のＳ３からＳ５）。上記実施形態１の処理に代えて、例えば、予めコンテナイメージをダウンロードしておくことで、スケールアウトの時間を節約できる。しかし、クラスタ構成の情報処理システムの場合には、効率が低下する。

図１２は、比較例３の処理を例示するタイムチャートである。比較例３の処理では、予めコンテナイメージがダウンロードされている。したがって、情報処理システムは、スケールアウト時に、各サービスについて、ダウンロード済みのコンテナイメージを起動すればよい。このため、比較例１の図１と比較して、スケールアウトの完了までの時間が早くなる。

図１３は、クラスタ構成の情報処理システムにおいて、比較例３にしたがって、情報処理システムが予めコンテナイメージをダウンロードした場合の処理例である。クラスタ構成の情報処理システムでは、複数のサーバがネットワークで接続され、情報処理システム
としてサービスを提供する。比較例３の処理では、コンテナが起動しないサーバにもイメージがダウンロードされることになる。

すなわち、比較例３のように、予めコンテナイメージをダウンロードしておく方法でも、一台のサーバ上ですべてのコンテナを動かす情報処理システムの場合には問題は少ない。しかし、クラスタ化されたコンテナ稼働環境では、全てのノードにコンテナイメージをダウンロードしておくこととなり、リソースの無駄が大きくなる。実施形態１の場合、前段判定サービスがスケールアウトの条件を充足したときに後段の当該サービスのコンテナイメージがダウンロードされるため、投機的とはいえリスクが小さい。リスクとしては、ダウンロードによる無駄が生じるが、実際に当該サービスの負荷が閾値を超えない限り、コンテナイメージが起動されず、ＣＰＵリソースに対するリスクが小さくなる。
［比較例４］

上記実施形態１では、前段判定サービスの状態と当該サービスの負荷の程度により、当該サービスのスケールアウトの要否を判定する（図９のＳ３、Ｓ６）。しかし、このような処理に代えて、前段判定サービスの状態から後段の当該サービスの負荷を推定して、当該サービスのスケールアウトの要否を判定することも考えられる。このような判定を連鎖的に進め全体の最適なスケール数を求め、同時に全体のスケーリングを実施することが考えられる。

しかしながら、このような方法では、スケールアウトの判定はあくまで、前段判定サービスの状態に基づく予測である。かつ、そのような予測のみに基づくスケールアウトが連鎖的に繰り返されることで、誤差が大きくなりうる。その際に、不必要なスケールアウトがされる可能性がある。すなわち、一のサービスにおいて、不必要なスケールアウトが起こると、その一のサービスに関係するサービスに不必要なスケールアウトが伝播し、リソースの無駄が発生する。一方、逆に、上記一のサービスで不必要なスケールインが実施された場合、サービスへの負荷が急速に上昇し、サービス品質の低下が生じ得る。例えば、図１１において、サービスＭＳ１の状態からサービスＭＳ２において誤ったスケールアウトの判定がなされると、ＭＳ２の判定結果は、ＭＳ３、ＭＳ５からＭＳ７、およびＭＳ４に伝搬する。

一方、実施形態１の処理は、以下の点で上記比較例４の処理方法と差異がある。まず、サービスがスケールアウトする際、コンテナイメージのダウンロードと、コンテナ起動とで処理のステップが分離されている。また、前段判定サービスの状況に応じて、当該サービスの負荷が高いと予測され、コンテナイメージがダウンロードされる。そして、当該サービスの実際の負荷が閾値を超えたか否かに応じて、ダウンロードされたコンテナイメージが起動される。

このような処理方法の差異により、仮に前段判定サービスでの負荷に基づく当該サービスでの負荷の予測が外れた場合でも、不必要に消費されるのはダウンロードのためのディスクである。したがって、ＣＰＵやメモリは消費されないため、仮に前段判定サービスでの負荷に基づく当該サービスでの負荷の予測が外れた場合の影響が小さい。そして、実施形態１の手順では、予測が的中し、スケールアウトが実行される場合には、コンテナイメージがダウンロード済みため、コンテナの起動が早く、負荷の増加に対する早期の対応が可能となる。実施形態１の情報処理システム１００では、相互に依存関係がある複数のサービスが高負荷の状態から健全な状態になるまでの時間を短縮する効果が得られる。
［実施形態２］

図１４から図１９を参照して、実施形態２に係る情報処理システム１００を説明する。上記実施形態１では、依存関係のある複数のサービスについて、従来よりも迅速に、かつ
、無駄を抑制してスケールアウトを実施する情報処理システムについて説明した。本実施形態では、複数のノードサーバを含む情報処理システム１００において、実施形態１と同様のスケールアウトを実施する手順を例示する。したがって、情報処理システム１００の構成がさらに具体化される点を除いて、実施形態２の構成要素および作用は、実施形態１と同様である。

図１４は、情報処理システム１００の構成を例示する図である。なお、図１４では、情報処理システム１００にアクセスする利用者端末４も例示されている。図１４のように、情報処理システム１００は、コンテナイメージリポジトリサーバ１と、マスタサーバ２と、複数のノードサーバ３−１、３−２、３−３等を有している。なお、ノードサーバ３−１、３−２、３−３等を総称する場合には、単にノードサーバ３という。図１４の情報処理装置１０は、クラスタ構成の情報処理システムということができる。情報処理システム１００は、コンピュータシステムの一例である。

コンテナイメージリポジトリサーバ１は、ネットワークインターフェース１１４と、コンテナイメージリポジトリ１０１とを有する。コンテナイメージリポジトリサーバ１は、ネットワークインターフェース１１４を通じてネットワークにアクセスし、マスタサーバ２、ノードサーバ３等と通信する。コンテナイメージリポジトリ１０１は、ある種のデータベースであり、コンテナイメージが登録される。コンテナイメージリポジトリサーバ１は、コンテナイメージリポジトリ１０１に格納されているコンテナイメージを管理する。

マスタサーバ２は、ネットワークインターフェース２１４と、Application Programming Interface（ＡＰＩ）処理プログラム２０１と、コンテナクラスタ管理プログラム２０
２と、を有する。マスタサーバ２は、ネットワークインターフェース２１４を通じてネットワークにアクセスし、コンテナイメージリポジトリサーバ１、ノードサーバ３等と通信する。

また、マスタサーバ２は、ＡＰＩ処理プログラム２０１を実行することにより、利用者端末４からのリクエストを処理し、コンテナクラスタ管理プログラム２０２へリクエストを引き渡す。また、マスタサーバ２は、コンテナクラスタ管理プログラム２０２を実行することにより、各ノードサーバ３の状態を取得し、クラスタのノード、サービス、コンテナなどを管理する。例えば、マスタサーバ２は、コンテナクラスタ管理プログラム２０２にしたがい、マスタサーバ２に、利用者からのリクエストや、予め定められた設定に従い、タスクを登録する。

ノードサーバ３は、ネットワークインターフェース３１４と、コンテナ管理プログラム３０２と、コンテナ監視プログラム３０３とを有する。ノードサーバ３は、ネットワークインターフェース３１４を通じてネットワークにアクセスし、コンテナイメージリポジトリサーバ１、マスタサーバ２等と通信する。

また、ノードサーバ３は、コンテナ管理プログラム３０２を実行することにより、
コンテナクラスタ管理プログラムを実行するマスタサーバ２から情報を取得し、コンテナイメージのダウンロード、コンテナの起動、コンテナの削除を行う。また、ノードサーバ３は、コンテナ監視プログラム３０３を実行することにより、コンテナのリソース使用量等を監視する。

図１５に、コンテナイメージリポジトリサーバ１、マスタサーバ２、またはノードサーバ３として利用される情報処理装置１０のハードウェア構成を例示する。なお、情報処理装置１０は、利用者端末４としても利用可能である。

情報処理装置１０は、Central Processing Unit（ＣＰＵ）１１、主記憶装置１２、イ
ンターフェース１８を通じて接続される外部機器を有し、プログラムにより情報処理を実行する。外部機器としては、外部記憶装置１３およびネットワークインターフェース１４を例示できる。ＣＰＵ１１は、主記憶装置１２に実行可能に展開されたコンピュータプログラムを実行し、情報処理装置１０の情報処理方法を実行する。ＣＰＵ１１は、プロセッサの一例である。

主記憶装置１２は、ＣＰＵ１１が実行するコンピュータプログラム、ＣＰＵ１１が処理するデータ等を記憶する。主記憶装置１２は、Dynamic Random Access Memory（ＤＲＡＭ）、Static Random Access Memory（ＳＲＡＭ）、Read Only Memory（ＲＯＭ）等である
。主記憶装置１２は、メモリの一例である。

さらに、外部記憶装置１３は、例えば、主記憶装置１２を補助する記憶領域として使用され、ＣＰＵ１１が実行するコンピュータプログラム、ＣＰＵ１１が処理するデータ等を記憶する。外部記憶装置１３は、ハードディスクドライブ、Solid State Disk（ＳＳＤ）等である。

また、情報処理装置１０は、入力装置１５、表示装置１６等によるユーザインターフェースを有するようにしてもよい。入力装置１５は、例えば、キーボード、ポインティングデバイス等である。また、表示装置１６は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。さらに、情報処理装置１０は、着脱可能記憶媒体駆動装置１７を設けてもよい。着脱可能記憶媒体は、例えば、ブルーレイディスク、Digital Versatile Disk（ＤＶＤ）、Compact Disc（ＣＤ）、フラッシュメモリカード等である。なお、図１５の例では、単一のインターフェース１８が例示されているが、インターフェース１８として複数種類のものが複数設けられてもよい。

図１６に、コンテナクラスタ管理プログラム２０２の処理を例示する。マスタサーバ２のＣＰＵ１１は、主記憶装置１２に実行可能に展開されたコンテナクラスタ管理プログラム２０２にしたがって、図１６の処理を実行する。マスタサーバ２は、管理ノードの一例である。

マスタサーバ２は、コンテナ監視プログラム３０３を実行するノードサーバ３からコンテナのリソース状況を取得する（Ｓ２１）。そして、マスタサーバ２は、取得したコンテナのリソース状況からサービスのリソース状況を計算する（Ｓ２２）。次に、マスタサーバ２は、サービスのリソース状況とサービス状態テーブルから状態遷移が発生するか否かを確認する（Ｓ２３）。サービス状態テーブルは、マスタサーバ２の主記憶装置１２に保存されている。サービス状態テーブルは、各サービスの状態を保持する。Ｓ２３の処理での確認は、例えば、stableの状態のサービスで、負荷が閾値を超えたか否かの確認である。また、Ｓ２３の処理での確認は、preparing 1の状態が所定時間継続したか否かである
。また、Ｓ２３での確認は、stableの状態のサービスで、前段サービスがfiredになった
か否かである。また、Ｓ２３での確認は、preparing 2の状態のサービスで、負荷が閾値
を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ２は、状態遷移が発生すると判断する。

そして、状態遷移が発生すると判断した場合（Ｓ２４でＹＥＳの場合）、マスタサーバ２は、状態テーブルを更新する（Ｓ２５）。そして、マスタサーバ２は、タスクを登録する（Ｓ２６）。ここで、タスクとは、コンテナイメージのダウンロード、そして、ダウンロードされたコンテナイメージの起動である。

Ｓ２１からＳ２３の処理は、第１の処理の負荷を監視することの一例である。なお、Ｓ
２１からＳ２３の処理は、第２の処理の負荷を監視することの一例である。例えば、前段サービスがfiredになったことは、第１の処理の負荷が第１の条件を超えることの一例で
ある。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第２の処理
の負荷が第２の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第１の処理の負荷が第１の条件を超えないときに、第２の処理の負荷が第２の条件を超えることの一例である。また、preparing 1の状態が所定
時間継続したことは、第２の条件を超える状態が規定時間継続したことの一例である。

Ｓ２３の処理において、状態遷移が発生する場合の一例は、例えば、状態がStableからpreparing 1に遷移する場合である。状態がpreparing 1に遷移すると、Ｓ２６の処理では、コンテナイメージダウンロードのタスクが登録される。また、状態遷移が発生する場合の他の例は、状態がpreparing 1からfiredに遷移する場合である。状態がfiredに遷移す
ると、Ｓ２６の処理では、コンテナ起動のタスクが登録される。Ｓ２６の処理で、コンテナ起動のタスクが登録されることは、第２の処理を実行する処理ノードの数を増加することの一例である。

図１７に、コンテナ管理プログラム３０２の処理を例示する。ノードサーバ３のＣＰＵ１１は、主記憶装置１２に実行可能に展開されたコンテナ管理プログラム３０２にしたがって、図１７の処理を実行する。ノードサーバ３は、処理ノードの一例である。

ノードサーバ３は、コンテナクラスタ管理プログラムを実行するマスタサーバ２にタスクが登録されているか否かを確認する（Ｓ３１）。マスタサーバ２に登録されたタスクが存在する場合（Ｓ３２でＹＥＳ）、ノードサーバ３は、タスクの種類を判定する（Ｓ３３）。タスクの種類がコンテナイメージダウンロードの場合、ノードサーバ３は、コンテナイメージリポジトリ１０１からコンテナイメージをダウンロードする（Ｓ３４）。Ｓ３４の処理は、第１の処理に関係する第２の処理を実行する処理プログラムを第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することの一例である。

一方、タスクの種類がコンテナ起動の場合、ノードサーバ３は、コンテナイメージがダウンロード済みか否かを判定する（Ｓ３５）。コンテナイメージがダウンロード済みでない場合、ノードサーバ３は、コンテナイメージをダウンロードする（Ｓ３６）。そして、ノードサーバ３は、ダウンロード済みのコンテナイメージを起動する（Ｓ３７）。Ｓ３７の処理は、転送された処理プログラムを前記増加される処理ノードで起動することの一例である。

図１８に、サービス状態テーブルの構成を例示する。サービス状態テーブルは、現時点の各サービスの状態を保持するテーブルである。図１８の例では、サービスＡ、Ｂ、Ｃ、Ｄ、およびＥの状態(Status)として、stable、 preparing 1、 fired、 stable、およびpreparing 2がそれぞれ保持されている。状態遷移に伴い、サービス状態テーブルは、図１６のＳ２５の処理によって更新される。

図１９は、サービス依存テーブルの構成を例示する。サービス依存テーブルは、サービス間の依存関係を定義する。図１９の例では、サービスＡは、サービスＢ、Ｃに依存し、サービスＢは、サービスＤ、Ｅに依存し、サービスＣは、サービスＥに依存することが定義されている。サービスＡがサービスＢに依存する関係とは、例えば、サービスＡがサービスＢからデータの提供を受ける関係をいう。例えば、実施形態１のグラフ描画処理のサービスは、グラフデータ作成サービスに依存している、ということができる。ただし、逆に、サービスＡがサービスＢに依存する関係として、例えば、サービスＡがサービスＢにデータの提供をする関係としてもよい。例えば、実施形態１のグラフデータ作成サービスは、グラフ描画処理のサービスに依存している、というようにしてもよい。

図２０は、１つのサービスの状態遷移を例示する。例えば、現在、ある１つのサービスがstableな状態であると仮定する。stableな状態のサービスの負荷が閾値超えになると、このサービスは、preparing 1の状態に遷移する。サービスの状態がpreparing 1になると、図１６のＳ２６の処理で説明したように、コンテナイメージダウンロードのタスクが登録され、図１７のＳ３４の処理で、コンテナイメージが、事前にダウンロードされる。そして、preparing 1の状態に遷移したサービスの負荷が所定時間継続される前に、サービ
スの負荷が閾値より下になると、このサービスは再びstableに戻る。

一方、preparing 1の状態に遷移したサービスの負荷が所定時間継続すると、状態がfiredになる。サービスの状態がfiredになると、図１６の２６で説明したように、コンテナ
起動のタスクが登録され、図１７のＳ３７の処理で、コンテナイメージが、起動される。なお、１つのサービスの状態がpreparing 1の状態で前段判定サービスがfiredになった場合も、当該１つのサービスの状態はfiredになる。

また、stableな状態のサービスに対して、前段判定サービスがfiredになると、そのstableな状態のサービスは、preparing 2の状態になる。サービスがpreparing 2の状態にな
ると、図１６のＳ２６の処理で説明したように、コンテナイメージのダウンロードのタスクが登録され、図１７のＳ３４の処理で、コンテナイメージが、事前にダウンロードされる。そして、preparing 2の状態のサービスの負荷が閾値を超えると、サービスはfiredの状態になる。サービスの状態がfiredになると、上述のpreparing 1からfiredになった場
合と同様、コンテナ起動のタスクが登録され、図１７のＳ３７の処理で、コンテナイメージが、起動される。
＜実施形態の効果＞

以上述べたように、実施形態２の情報処理システムによれば、マスタサーバ２は、コンテナ監視プログラム３０３を実行するノードサーバ３からコンテナのリソース状況を取得し（図１６のＳ２１）、リソースの状況からサービスの負荷を計算する（同Ｓ２２）。そして、マスタサーバ２は、サービスの負荷とサービス状態テーブルとから状態遷移が発生するか否かを判定する（同Ｓ２３、Ｓ２４）。例えば、stableの状態のサービスの負荷が閾値を超えると、状態がstableからpreparing 1に遷移する。また、stableの状態のサー
ビスについて、前段判定サービスがfiredになると、stableの状態のサービスがpreparing
2の状態に遷移する。そして、サービスの状態がpreparing 1あるいはpreparing 2に遷移すると、マスタサーバ２は、そのサービスを起動するためのコンテナイメージをダウンロードするように、ノードサーバ３向けのタスクを登録する（図１６のＳ２６）。ノードサーバ３は、登録されたタスクを実行し、コンテナイメージをダウンロードするタスクを実行することで、事前にスケールアウトで起動されるコンテナイメージをダウンロードしておく。

そして、preparing 1の状態が所定時間継続すると、サービスの状態がfiredに遷移する。また、preparing 2の状態のサービスの負荷が閾値を超えると、状態がfiredに遷移する。そして、サービスの状態がfiredに遷移すると、マスタサーバ２は、そのサービスに対
応するコンテナイメージを起動するように、ノードサーバ３向けのタスクを登録する（図１６のＳ２６）。ノードサーバ３は、登録されたタスクにしたがって、コンテナイメージを起動する（図１７のＳ３７）。

このように、実施形態２の情報処理システム１００は、実施形態１の場合と同様、第１の処理に関係する第２の処理の負荷を監視する。ここで、第１の処理に関係する第２の処理とは、第１の処理に対して第２の処理の結果のデータを入力する第２の処理をいう。第１の処理の例は、実施形態１のグラフ描画処理のサービスである。第２の処理の例は、実
施形態１のグラフデータ作成処理のサービスである。また、第１の処理に関係する第２の処理とは、第１の処理の結果のデータが入力される第２の処理をいう。この場合には、第１の処理の例は、実施形態１のグラフデータ作成処理のサービスである。第２の処理の例は、実施形態１のグラフ描画処理のサービスである。

そして、第１の処理に相当する前段判定サービスの状態が第１の条件であるfiredを充
足するとともに、第２の処理の実行時の負荷が閾値を超えると、コンテナイメージをノードサーバ３で起動し、スケールアウトを実行する。つまり、実施形態２の情報処理システム１００も、実施形態１と同様、前段判定サービスの状態からの予測と、当該サービスでの実際の負荷の状況によってスケールアウトを実行する。このような処理によって、実施形態２の情報処理システム１００は、比較例１から４等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。

また、実施形態２の情報処理システム１００は、実施形態１と同様、前段判定サービスの状態がfiredとなったことによる予測にしたがって、まず、コンテナイメージのダウン
ロードを実行する。そして、情報処理システム１００は、当該サービスでの実際の負荷の状況によってダウンロード済みのコンテナイメージを起動する。したがって、コンテナイメージをノードサーバ３で実行することによるスケールアウト実行時に、コンテナのダウンロードの工程と、コンテナイメージの起動の工程とに分離して、スケールアウトが実行される。このような処理によって、実施形態２の情報処理システム１００は、比較例１から４等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。

また、実施形態２の情報処理システム１００では、前段判定サービスの状態がfiredと
ならない場合でも、当該サービスの負荷が閾値を超えた場合には、状態がpreparing 1と
なる。その結果、コンテナイメージがノードサーバ３にダウンロードされる。preparing 1の状態が所定時間継続すると、コンテナイメージがノードサーバ３で起動される。した
がって、実施形態２の情報処理システム１００では、前段判定サービスの状態によらず、当該サービスの監視によって、２段階でスケールアウトの実行要否を判定する。また、この場合も、コンテナイメージのダウンロードと、コンテナイメージの起動の２段階でスケールアウトが実行される。したがって、このような処理によっても、実施形態２の情報処理システムは、比較例１から４の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。

このように、前段判定サービスの状態によらず、当該サービスの監視によって、２段階でスケールアウトの実行要否を判定する場合も、コンテナのダウンロードの工程と、コンテナイメージの起動の工程とに分離して、スケールアウトが実行される。このような処理によって、実施形態２の情報処理システム１００は、比較例１から４等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。

また、従来、仮想マシンを基にスケールアウトを実行する場合、仮想マシンの起動に時間を要していた。例えば、Infrastructure as a Service（ＩａａＳ）では、スケールア
ウトに分単位の時間がかかるため、インスタンス作成および起動以外の時間を短縮したとしても相対的な影響は小さく効果が得られなかった。ここで、インスタンスとは、ＩａａＳで提供される仮想マシンである。また、ＩａａＳとは、情報システムの稼動に必要な機材や回線などの基盤（インフラ）を、インターネット上のサービスとして遠隔から利用できるようにしたものをいう。一方、仮想マシンを基にスケールアウトを実行する場合と比較して、コンテナを基にスケールアウトを実行する場合には、起動までの時間が仮想マシンと比較して、２桁短縮される。

したがって、コンテナを基にスケールアウトを実行する場合には、起動以外のダウンロ
ードなどの時間がスケールアウトの時間に顕著に影響を与えるようになる。上記実施形態１、２の処理では、１つのサービスに対して、前段判定サービスがfiredの状態になると
、当該１つのサービスを実行するためのコンテナイメージがノードサーバ３にダウンロードされる。そして、当該１つのサービスの負荷が閾値を超えた場合に、当該サービスに対応するコンテナイメージがダウンロード先のノードサーバ３で起動される。したがって、本実施形態の処理では、起動以外のダウンロードの時間によるスケールアウトの時間への影響を低減できる。
《コンピュータが読み取り可能な記録媒体》

コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ＲＯＭ（リードオンリーメモリ）等がある。さらに、ＳＳＤ（Solid State Drive）は、コンピュータ等から取り外し可能な記録媒体としても、コンピュータ
等に固定された記録媒体としても利用可能である。

１ コンテナイメージリポジトリサーバ
２ マスタサーバ
３ ノードサーバ
１０ 情報処理装置
１１ ＣＰＵ
１２ 主記憶装置
１４ ネットワークインターフェース
１００ 情報処理システム
１０１ コンテナイメージリポジトリ
１１４、２１４、３１４ ネットワークインターフェース
２０１ ＡＰＩ処理プログラム
２０２ コンテナクラスタ管理プログラム
３０１ コンテナ
３０２ コンテナ管理プログラム
３０３ コンテナ監視プログラム

アクション２：状態２（preparing1）、状態４（preparing2）で、スケールアウトの準備を実施する。具体的には、本情報処理システム１００はサービスにノードを割当て、割当てられたノードにコンテナイメージをダウンロードする。アクション２により、例えば、結果的に自サービスで負荷が上がらずスケールアウトせず、ダウンロードが無駄になる可能性もある。しかし、本情報処理システム１００は、スケールアウトの見込みが高いと判断して、アクション２を実施する。アクション２による準備の実施で、ダウンロードされたコンテナイメージが実際に起動されるのは、自サービスが状態３または状態５になった場合である。

図１１のような依存関係を有するマイクロサービスを想定する。図１１で、ＭＳ１からＭＳ８は、依存関係のある複数のマイクロサービスを例示する。依存関係のあるマイクロサービス同士は線分で接続されている。例えば、ＭＳ１を前段判定サービスとして、ＭＳ２、ＭＳ４、およびＭＳ８が連鎖的にスケールアウトする可能性のある依存サービスである。

マスタサーバ２は、コンテナ監視プログラム３０３を実行するノードサーバ３からコンテナのリソース状況を取得する（Ｓ２１）。そして、マスタサーバ２は、取得したコンテナのリソース状況からサービスのリソース状況を計算する（Ｓ２２）。次に、マスタサーバ２は、サービスのリソース状況とサービス状態テーブルから状態遷移が発生するか否か
を確認する（Ｓ２３）。サービス状態テーブルは、マスタサーバ２の主記憶装置１２に保存されている。サービス状態テーブルは、各サービスの状態を保持する。Ｓ２３の処理での確認は、例えば、stableの状態のサービスで、負荷が閾値を超えたか否かの確認である。また、Ｓ２３の処理での確認は、preparing 1の状態が所定時間継続したか否かである
。また、Ｓ２３での確認は、stableの状態のサービスで、前段判定サービスがfiredにな
ったか否かである。また、Ｓ２３での確認は、preparing 2の状態のサービスで、負荷が
閾値を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ２は、状態遷移が発生すると判断する。

Ｓ２１からＳ２３の処理は、第１の処理の負荷を監視することの一例である。なお、Ｓ２１からＳ２３の処理は、第２の処理の負荷を監視することの一例である。例えば、前段判定サービスがfiredになったことは、第１の処理の負荷が第１の条件を超えることの一
例である。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第２の
処理の負荷が第２の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第１の処理の負荷が第１の条件を超えないときに、第２の処理の負荷が第２の条件を超えることの一例である。また、preparing 1の状態が所定時間継続したことは、第２の条件を超える状態が規定時間継続したことの一例である。

Claims (7)

1. 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、
   第１の処理の負荷を監視し、
   前記第１の処理の負荷が第１の条件を超えるときに、前記第１の処理に関係する第２の処理を実行する処理プログラムを前記第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させるコンピュータプログラム。
2. 前記第２の処理の負荷が第２の条件を超えるときに、前記転送された処理プログラムを起動し、前記第２の処理を実行する処理ノードの数を増加することをさらに実行させる請求項１に記載のコンピュータプログラム。
3. 前記第１の処理の負荷が第１の条件を超えないときに、前記第２の処理の負荷が第２の条件を超え、かつ、前記第２の条件を超える状態が規定時間継続したときに、前記第２の処理を実行する処理ノードの数を増加することを実行させる請求項１または２に記載のコンピュータプログラム。
4. 前記処理ノードの数を増加することは、
   前記第２の処理の負荷が第２の条件を超えるときに、前記第２の処理を実行する処理プログラムを前記増加される処理ノードにネットワークを通じて転送することと、
   前記第２の条件を超える状態が規定時間継続したときに、前記転送された処理プログラムを前記増加される処理ノードで起動することと、を含む請求項３に記載のコンピュータプログラム。
5. 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムが、
   第１の処理の負荷を監視し、
   前記第１の処理の負荷が第１の条件を超えるときに、前記第１の処理に関係する第２の処理を実行する処理プログラムを前記第２の処理を実行するために増加される処理ノードにネットワークを通じて転送する情報処理方法。
6. 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムを管理する管理ノードであって、
   前記管理ノードは、プロセッサとメモリとを有し、前記メモリに記憶されたコンピュータプログラムが前記プロセッサに、
   第１の処理の負荷を監視し、
   前記第１の処理の負荷が第１の条件を超えるときに、前記第１の処理に関係する第２の処理を実行する処理プログラムを前記第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる管理ノード。
7. 複数の処理を負荷分散して実行する処理ノードの数を変更可能な情報処理システムであって、
   前記処理ノードと前記処理ノードを管理する管理ノードとを有し、
   前記管理ノードは、プロセッサとメモリとを有し、前記メモリに記憶されたコンピュータプログラムが前記プロセッサに、
   第１の処理の負荷を監視し、
   前記第１の処理の負荷が第１の条件を超えるときに、前記第１の処理に関係する第２の処理を実行する処理プログラムを前記第２の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる情報処理システム。

Images