JP2017219972A - コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム - Google Patents
コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム Download PDFInfo
- Publication number
- JP2017219972A JP2017219972A JP2016112920A JP2016112920A JP2017219972A JP 2017219972 A JP2017219972 A JP 2017219972A JP 2016112920 A JP2016112920 A JP 2016112920A JP 2016112920 A JP2016112920 A JP 2016112920A JP 2017219972 A JP2017219972 A JP 2017219972A
- Authority
- JP
- Japan
- Prior art keywords
- service
- load
- processing
- state
- scale
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1031—Controlling of the operation of servers by a load balancer, e.g. adding or removing servers that serve requests
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Stored Programmes (AREA)
Abstract
【課題】互いに関係する複数の処理を負荷分散して実行する処理ノードを含むシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させる。【解決手段】コンピュータプログラムは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第1の処理の負荷を監視させる。そして、コンピュータプログラムは、このコンピュータシステムに、第1の処理の負荷が第1の条件を超えるときに、第1の処理に関係する第2の処理を実行する処理プログラムを第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる。【選択図】図7
Description
本発明は、コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システムに関する。
近年、マイクロサービスにコンテナ技術を適用したシステム構築が採用されている。マイクロサービスは、構築されるシステム全体よりも軽量な複数のサービスを連携させて1つのアプリケーションを作成する開発手法ということができる。マイクロサービスでは、従来1つのシステムとして構築されていたサービスが責務ごとのサービスに分離される。分離された責務ごとのサービス間をRESTful などのシンプルで疎な結合にて結びつけることで、分離された個々のサービスの組み合わせによってアプリケーションが構築される。このような責務ごとにサービスが分離されるとともに、シンプルで疎な結合にて結びつけることで、システムの可搬性・可用性を高めることができる。なお、RESTfulは、Representational State Transfer(REST)と呼ばれる、ウェブに例示されるソフトウェアのアーキテクチャである。
上述のように、マイクロサービスによるシステム構築を採用する場合に、コンテナ技術が用いられることがある。コンテナは、単一のオペレーティングシステム(OS)の環境で、複数の分離された空間を作成し、分離された空間ごとに異なるアプリケーションの環境を提供する技術ということができる。コンテナでは、単一のOSカーネルの環境で、プロセスを分離することで、異なるOS環境を提供できる、ともいうことができる。
従来、例えば、異なるOS環境を提供する技術として、仮想マシンが採用されている。仮想マシンでは、例えば、ハイパーバイザのような仮想化ソフトウェアが、仮想的なハードウェアを提供し、ゲストOSを稼働させる。仮想マシンのゲストOSは、物理マシン上のOSと同様に動作する。
一方、コンテナの環境では、単一のOSカーネルで複数のコンテナがプロセスとして稼働するため、ハードウェア資源の使用量、オーバーヘッド等が仮想マシンと比較して小さくなる。したがって、仮想マシンに比べ、より軽量なコンテナ技術を生かすことで、マイクロサービスによるシステム構築とシステム運用の効率化が期待できる。
ところで、構築されたシステムの処理能力を向上するため、スケールアウトが実施されることがある。図1に、個々にスケールアウトされる複数サービスを含む情報処理システムを例示する。図1では、情報処理システムは、ユーザインターフェース(UI)と、アカウント管理と、帳票作成と、グラフ描画と、承認処理と、データ登録と、グラフデータ作成というマイクロサービスによって構築される。なお、アカウント管理は、帳票作成、承認処理、およびデータ登録という各マイクロサービスの処理結果を利用するものとする。また、グラフ描画は、グラフデータ作成というマイクロサービスの処理結果を利用するものとする。なお、図1の各マイクロサービスは、それぞれ上記コンテナ技術を用いて実行することができる。
図2は、物理環境、仮想マシンによる仮想環境、コンテナによる仮想環境を比較する。物理環境では、情報処理システムは、例えば、ハードウェア、OS、ミドルウェア、アプリケーションを有する。また、仮想マシンによる仮想環境では、情報処理システムは、例えば、ハードウェア、ホストOS、ハイパーバイザ、1以上のゲストOS、ゲストOS上
のミドルウェア、ミドルウェア上のアプリケーションを有する。一方、コンテナによる仮想環境では、情報処理システムは、ハードウェア、OS、OS上の1以上のコンテナを有する。また、各コンテナは、ミドルウェア、ミドルウェア上のアプリケーションを有する。上述のように、コンテナは、1つのOSカーネル上の異なるプロセスとして起動される。
のミドルウェア、ミドルウェア上のアプリケーションを有する。一方、コンテナによる仮想環境では、情報処理システムは、ハードウェア、OS、OS上の1以上のコンテナを有する。また、各コンテナは、ミドルウェア、ミドルウェア上のアプリケーションを有する。上述のように、コンテナは、1つのOSカーネル上の異なるプロセスとして起動される。
仮想マシンに対して、コンテナ技術の特徴を例示すると以下の通りである。コンテナは、仮想マシンに比べて起動が高速である。コンテナの起動はOS上のプロセスの起動に相当するからである。コンテナ環境は、仮想マシンの環境に比べてメモリの使用量が少ない。コンテナ環境では、OS、あるいはOSのカーネルを共通要素として、OS上の1以上のコンテナ自体はカーネルを含まないからである。なお、コンテナ技術では、OSのうちカーネルが共通化され、コンテナごとに分離されたプロセスはカーネル以外の部分(ミドルウェアとも呼ぶ)を起動可能である。そして、コンテナ環境では、Dockerに例示されるコンテナ管理ツールを利用することにより、OSは、リポジトリに登録済みのコンテナイメージをダウンロードし、ダウンロードしたコンテナイメージを元にOSの1プロセスとしてコンテナ型の仮想環境を起動することが可能である。
したがって、例えば、図1の情報システムでは、コンテナ技術を用いることで、個々のマイクロサービスごとにスケールアウトが可能である。例えば、個々のマイクロサービスの負荷に応じて、UIに対して3つのノードを割り当て、アカウント管理に2つのノードを割り当て、データ登録に2つのノードを割り当て、グラフデータ作成に2つのノードを割り当てる、といったことが可能である。なお、スケールアウトは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムの性能向上の手法の1つである。スケールアウトは、コンピュータシステムにおいて実行される処理に割り当てられる処理ノードの追加ということができる。
上述のように、コンテナ技術とマイクロサービスによって構築された情報処理システムでは、効率的なシステム構築とシステム運用が期待される。例えば、上述のように、マイクロサービスでは、責務ごとに分離されたサービス個々にスケールアウトすることで、少ないリソースの増加でシステムを健全化することができる。一方、マイクロサービスでは、複数のサービスが連携して1つのアプリケーションを作成する。したがって、一のサービスの負荷に対応して設備の数を増加した場合に、この一のサービスと連携する他のサービスにおいても負荷に対応する設備の数が増加する場合がある。つまり、一のサービスのスケールアウトによって、連鎖的に他のサービスの負荷が増加し、他のサービスがスケールアウトすることがある。
なお、このような連鎖的な負荷の増加はコンテナ技術に限定される訳ではない。例えば、仮想マシンを用いてマイクロサービスによるシステムを構築する場合も、同様のことが生じ得る。つまり、一のサービスを実行する仮想マシンの負荷に対応して、仮想マシンの数を増加した場合に、この一のサービスと連携する他のサービスを実行する他の仮想マシンの数の増加につながる場合がある。
すなわち、コンテナ技術を一例として、コンピュータ上の処理では、一の処理が他の処理と関係することがある。例えば、1つの処理の結果が他の処理の入力となる場合があり得る。したがって、1つの処理の負荷が増加しスケールアウトした結果、スループットが向上した場合、他の処理に対する処理要求が増加し、他の処理の負荷が増加する可能性がある。また、1つの処理の負荷が増加しスケールアウトした結果、スループットが向上した場合、他の処理に対する入力が増加し、他の処理の負荷が増加する可能性がある。
このように、一の処理が他の処理と関係する複数の処理がシステムに含まれる場合、1つ1つの処理に対してスケールアウトの要否を判断したのでは、システム全体の負荷の適正化までの時間を要するおそれがある。一方、1つの処理に対するスケールアウトが実施されたときに、単純に、当該処理に対して上記関係の他の処理においてスケールアウトを実施した場合には、上記関係の他の処理において、実際にスケールアウトが実施される状況になるか否かが確定的でなく、無駄なスケールアウトを実施する可能性がある。
本発明の課題は、互いに関係する複数の処理を負荷分散して実行する処理ノードを含むシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させることにある。
開示の技術の一側面は、コンピュータプログラムによって例示される。本コンピュータプログラムは、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、第1の処理の負荷を監視させる。そして、このコンピュータシステムに、第1の処理の負荷が第1の条件を超えるときに、前記第1の処理に関係する第2の処理を実行する処理プログラムを前記第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる。
本コンピュータプログラムによれば、互いに関係する複数の処理を負荷分散して実行する処理ノードを含むコンピュータシステムにおいて、迅速に、かつ、無駄を抑制して処理を実行する処理ノードの数を増加させることができる。
以下、図面を参照して、一実施形態に係る情報処理システムについて説明する。以下の実施形態の構成は例示であり、本情報処理システムは実施形態の構成には限定されない。[比較例1]
図3から図5により、比較例1に係る情報処理システムを例示する。図3に、コンテナ技術を採用する情報システムにおけるコンテナ起動処理を例示する。図3の情報処理システムでは、コンテナが登録されたコンテナイメージリポジトリと、コンテナイメージリポジトリにネットワークを介して接続されるノードが例示される。コンテナイメージリポジトリ、および、各ノードはそれぞれ情報処理装置、サーバ、あるいはコンピュータと呼ばれる装置、設備等である。
図3の情報処理システムでは、コンテナイメージリポジトリには、コンテナイメージが登録されている。また、図3の情報処理システムでは、管理ツール(例えば、Docker)によってコンテナの実行が管理される。コンテナが一のノードに割当てられると、コンテナはコンテナイメージリポジトリから割当てられたノードにダウンロードされ、起動される。コンテナイメージは、OSのカーネル以外の部分を含むミドルウェアと、アプリケーションプログラムを含む。
ここで、コンテナイメージとは、OSカーネルへのインターフェースであるミドルウェアと、アプリケーションを含むプログラムである。OSカーネルは、コンテナイメージによってOSカーネル上の1つのプロセスとしてコンテナを起動する。それぞれのコンテナは、OSカーネル上の1つのプロセスとして、仮想環境を提供する。
図4に、比較例1の情報処理システムにおけるスケールアウトの実行例を示す。比較例1では、情報処理システムにおいて、例えば、グラフ描画、グラフデータ作成、データ収集という3つのマイクロサービスが連携して、アプリケーションを実行する場合を想定する。グラフ描画処理は、グラフデータ作成処理の結果を受け取り、グラフデータ作成処理はデータ収集処理の結果を受け取る。
今、グラフ描画処理の負荷が増大したため、グラフ描画処理を実行するサービスがスケールアウトしたと仮定する。すると、グラフ描画処理の処理能力向上に伴い、グラフ描画処理にデータを供給するグラフデータ作成処理の負荷が増加することが想定される。すると、グラフデータ作成処理を実行するサービスがスケールアウトする。すると、さらに、グラフデータ作成処理の処理能力向上に伴い、グラフデータ作成処理にデータを供給するデータ収集処理の負荷が増大することが想定される。すると、さらに、データ収集処理を実行するサービスがスケールアウトする。このように、連携するサービス間でスケールアウトの連鎖が広がっていく。図4のように、一のサービスの処理結果が次のサービスで利用される関係にある複数の連携するサービスを依存関係のあるサービスと呼ぶ。
なお、図4では、一のサービスと、当該一のサービスにデータを供給する他のサービスとの依存関係において、当該一のサービスが先にスケールアウトした場合のスケールアウトの連鎖を例示した。しかしスケールアウトの連鎖は逆方向にも生じ得る。つまり、当該一のサービスにデータを供給する他のサービスが先にスケールアウトし、その結果、データ供給を受ける当該一のサービスがスケールアウトすることで、連携するサービス間でスケールアウトの連鎖が広がっていくことも生じ得る。
図5に、依存関係のあるサービス間のスケールアウトの詳細を例示する。図4で説明したように、まず、グラフ描画処理を実行するサービスの負荷が増大したとする。負荷が所定の閾値を超えると、スケールアウトが開始される。比較例1においては、情報処理システムは、コンテナ技術を用いている。したがって、スケールアウトでは、グラフ描画処理に対応するコンテナに新たなノードが割当てられ、コンテナイメージがコンテナイメージリポジトリから割当てられたノードにダウンロードされる。そして、ダウンロード後に、ダウンロードされたコンテナイメージが起動される。新たに割当てられたノードで、グラフ描画処理に対応するコンテナが起動されることで、スケールアウトがなされ、グラフ描画処理を実行するサービスの処理能力が向上する。
そして、グラフ描画処理を実行するサービスの処理能力が向上し、処理量が増加すると、グラフ描画処理のサービスに描画データを提供するグラフデータ作成処理のサービスの負荷が増大する。グラフデータ作成処理のサービスの負荷が所定の閾値に達すると、グラフデータ作成処理のサービスに対しても、新たにノードが割当てられ、スケールアウトが実行される。すなわち、グラフデータ作成処理のサービスに新たなノードが割当てられ、コンテナイメージがダウンロードされ、起動される。さらに、同様のスケールアウトがデータ収集処理のサービスに対しても実行される。
図4、図5のように、サービス間で依存関係がある場合、一つのサービスが高負荷になり、そのサービスがスケールアウトすると、さらに関連するサービスの負荷が連鎖的に増加し、さらにスケールアウトが実行される。そして、図5の処理では、スケールアウト完了までに占めるダウンロード時間の割合が高まる。
[実施形態1]
[実施形態1]
図6から図9を参照して、実施形態1に係る情報処理システム100を例示する。実施形態1では、上記の比較例1のような連鎖的に負荷が増加する情報処理システム100におけるスケールアウトの効率向上を図る。そのため、情報処理システム100は、サービスの依存関係を解釈し、各サービスが効率的にスケールアウトを実施するための新たな状態を定義する。
実施形態1において、サービスの依存関係は、上記比較例1で説明したものと同様である。すなわち、図4のように、一のサービスと、当該一の処理にデータを供給するサービスとの関係を依存関係という。スケールアウトの連鎖は、当該一のサービスが先にスケールアウトし、次に、当該一の処理にデータを供給するサービスがスケールアウトすることによって生じ得る。この場合、先にスケールアウトするサービスを前段判定サービスということにする。
また、スケールアウトの連鎖は逆方向にも生じ得る。つまり、当該一の処理にデータを供給する他のサービスが先にスケールアウトし、その結果、データ供給を受ける当該一のサービスがスケールアウトすることで、連携するサービス間でスケールアウトの連鎖が広がっていくことも生じ得る。この場合も、先にスケールアウトするサービスを前段判定サービスということにする。
各状態は以下の通りである。
状態1:負荷が閾値以内の場合である。状態1は、stableな状態と呼ばれる。
状態2:負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間内の場合である。状態2は、preparing1の状態と呼ばれる。
状態3:負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間経過した場合である。状態3は、firedな状態と呼ばれる。
各状態は以下の通りである。
状態1:負荷が閾値以内の場合である。状態1は、stableな状態と呼ばれる。
状態2:負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間内の場合である。状態2は、preparing1の状態と呼ばれる。
状態3:負荷が閾値超え、負荷が閾値超えを継続する時間が所定時間経過した場合である。状態3は、firedな状態と呼ばれる。
状態4:前段判定サービスがfired な状態にあり、かつ、当該サービスの負荷が閾値以内の場合である。状態4は、preparing 2の状態と呼ばれる。
状態5:当該サービスがpreparing 2の状態にあり、かつ、当該サービスの負荷が閾値超
えした場合である。状態5も、firedな状態と呼ばれる。
実施形態1の情報処理システム100において、各状態に対して実行されるアクションは、以下の通りである。
状態5:当該サービスがpreparing 2の状態にあり、かつ、当該サービスの負荷が閾値超
えした場合である。状態5も、firedな状態と呼ばれる。
実施形態1の情報処理システム100において、各状態に対して実行されるアクションは、以下の通りである。
アクション1:前段判定サービスの負荷の閾値超えが所定時間継続したような高負荷状態であれば(firedな状態)、自サービスが閾値を超えた時点で(状態5)、スケールアウト
を実施する。すなわち、情報処理システム100は、サービスが状態5になるとスケールアウトを実行する。この場合には、情報処理システム100は、自サービスの負荷が所定時間継続的に閾値を超えるか否かを確認しない。
を実施する。すなわち、情報処理システム100は、サービスが状態5になるとスケールアウトを実行する。この場合には、情報処理システム100は、自サービスの負荷が所定時間継続的に閾値を超えるか否かを確認しない。
アクション2:状態2(preparing1)、状態4(preparing2)で、スケールアウトの準備を実施する。具体的には、本情報処理システム100はサービスにノードを割当て、割当てられたノードにコンテナイメージをダウンロードする。アクション2により、例えば、結果的に自サービスで負荷が上がらずスケールアウトせず、ダウンロードが無駄になる可能性もある。しかし、本情報処理システム100は、スケールアウトの見込みが高いと判断して、アクション2を実施する。アクション2による準備の実施で、ダウンロードされたコンテナイメージが実際に起動されるのは、自サービスが状態1になった場合である。
図6に、上記の比較例1と同様に、依存する3つのサービス、すなわち、グラフ描画処理のサービス、グラフデータ作成処理のサービス、およびデータ収集処理のサービスにおける状態の変化を例示する。図6では、グラフ描画処理のサービスの負荷はすでに閾値を超えた状態が所定時間継続し、状態3(firedな状態)となっている。この場合に、グラ
フ描画処理のサービス(非依存サービス)が依存するグラフデータ作成処理のサービスは状態4(preparing 2の状態)になっている。すなわち、グラフ描画処理のサービスはす
でにスケールアウトが実行され、グラフデータ作成処理のサービスは準備が実行される。
フ描画処理のサービス(非依存サービス)が依存するグラフデータ作成処理のサービスは状態4(preparing 2の状態)になっている。すなわち、グラフ描画処理のサービスはす
でにスケールアウトが実行され、グラフデータ作成処理のサービスは準備が実行される。
図7に、本情報処理システム100における、依存関係のあるサービス間のスケールアウトの詳細を例示する。本実施形態においても、情報処理システム100は、コンテナ技術を用いている。例えば、情報処理システム100は、複数のノードを有し、依存関係のある複数のサービスにはそれぞれノードが割当てられる。それぞれのサービスに割当てられたノードは、割当てられたサービスに対応するコンテナを起動する。情報処理システム100は、複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムの一例である。
まず、当初、状態1(stableな状態)であったグラフ描画処理を実行するサービスの負荷が増大したとする。負荷が所定の閾値を超えると、サービスは状態2(preparing 1の
状態)となる。グラフ描画処理のサービスは、状態2(preparing 1の状態)になると、
サービスを実行するノードを新たに割当てられる。そして、新たに割当てられたノードに、グラフ描画処理のサービスのコンテナイメージがダウンロードされる。すなわち、グラフ描画処理のサービスに対して、スケールアウトの準備が開始される。
状態)となる。グラフ描画処理のサービスは、状態2(preparing 1の状態)になると、
サービスを実行するノードを新たに割当てられる。そして、新たに割当てられたノードに、グラフ描画処理のサービスのコンテナイメージがダウンロードされる。すなわち、グラフ描画処理のサービスに対して、スケールアウトの準備が開始される。
さらに、状態2(preparing 1の状態)が所定時間継続すると、サービスは状態3(firedの状態)となり、スケールアウトが開始される。すなわち、サービスに新たに割当てられたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、グラフ描画処理のサービスの負荷が低下し、状態1(stable)になる。
さらにまた、グラフ描画処理を実行するサービスが状態3(firedの状態)になると、
グラフ描画処理のサービスが状態3(firedの状態)であることが本情報処理システム1
00の管理装置に通知される。その結果、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが状態4(preparing 2の状態)となる。情報処理システム100の管理装置としては、例えば、実施形態2のマスタサーバ2、およびコンテナイメージリポジトリサーバ1等が該当する。
グラフ描画処理のサービスが状態3(firedの状態)であることが本情報処理システム1
00の管理装置に通知される。その結果、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが状態4(preparing 2の状態)となる。情報処理システム100の管理装置としては、例えば、実施形態2のマスタサーバ2、およびコンテナイメージリポジトリサーバ1等が該当する。
そして、グラフデータ作成処理のサービスは、状態4(preparing 2の状態)になると、サービスを実行するノードを新たに割当てられる。そして、新たに割当てられたノードに、グラフデータ作成処理のサービスのコンテナイメージがダウンロードされる。
さらに、グラフデータ作成処理のサービスの負荷が所定の閾値を超えると、状態5(firedの状態)となり、スケールアウトが開始される。すなわち、サービスに新たに割当て
られたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、グラフデータ作成処理のサービスの負荷が低下し、状態1(stable)になる。
られたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、グラフデータ作成処理のサービスの負荷が低下し、状態1(stable)になる。
さらにまた、グラフデータ作成処理のサービスが状態5(firedの状態)になると、グ
ラフデータ作成処理のサービスが状態5(firedの状態)であることが本情報処理システ
ム100の管理装置に通知される。その結果、グラフデータ作成処理のサービスにデータを提供するデータ収集処理のサービスが状態4(preparing 2の状態)となる。
ラフデータ作成処理のサービスが状態5(firedの状態)であることが本情報処理システ
ム100の管理装置に通知される。その結果、グラフデータ作成処理のサービスにデータを提供するデータ収集処理のサービスが状態4(preparing 2の状態)となる。
そして、データ収集処理のサービスは、状態4(preparing 2の状態)になると、サービスを実行するノードを割当てられる。そして、割当てられたノードにデータ収集処理のサービスのコンテナイメージがダウンロードされる。
さらに、データ収集処理のサービスの負荷が所定の閾値を超えると、状態5(firedの
状態)となり、スケールアウトが開始される。すなわち、サービスに新たに割当てられたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、データ収集処理のサービスの負荷が低下し、状態1(stable)になる。
状態)となり、スケールアウトが開始される。すなわち、サービスに新たに割当てられたノードにおいて、ダウンロード済みのコンテナイメージによりコンテナが起動される。新たに割当てられたノードでのコンテナの起動によって、データ収集処理のサービスの負荷が低下し、状態1(stable)になる。
図8は、比較例1(図5)のスケールアウトの手順と、実施形態1のスケールアウトの手順を比較する図である。図8で、上側のフローは、図5に例示した比較例1の場合の処理手順である。また、図8で、下側のフローは、図7に例示した実施形態1の場合の処理手順である。図8の下側のように、本実施形態では、一のサービスがスケールアウトをすると、一のサービスに関係する他のサービスがスケールアウトの準備を開始する。すなわち、グラフデータ作成処理のサービスからデータ供給を受けるグラフ描画処理のサービスがスケールアウトを開始するとともに、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスのスケールアウトの準備が開始する。つまり、グラフデータ作成処理のコンテナイメージがサービスに割当てられたノードにダウンロードされる。したがって、グラフデータ作成処理で負荷が所定の閾値を超えた場合には、すでにコンテナがダウンロード済みとなっているため、ノードは直ちにコンテナイメージからコンテナ
を起動できる。
を起動できる。
したがって、比較例1のように、情報処理システム100が各サービスでそれぞれ個別に負荷を監視し、閾値を超えたときにスケールアウトする手順と比較して、図8の矢印で示される時間だけ、本実施形態の手順の方が、スケールアウト完了が早まる。なお、図8では、2つのサービスの間で依存関係がある場合のスケールアウトが例示されているが、依存関係のあるサービスがシーケンシャルにつながる数が多いほど、本実施形態による時間の短縮効果は大きくなる。
なお、図8で先にスケールアウトを開始するサービスを前段判定サービスといい、前段判定サービスがスケールアウト時にスケールアウトの準備を開始するサービスを当該サービスという。図8では、グラフデータ作成処理のサービスからデータの供給を受けるグラフ描画処理のサービスが前段判定サービスであり、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが当該サービスである。ただし、スケールアウトの連鎖の順序が図8と逆の場合もあり得る。すなわち、グラフ描画処理のサービスにデータを供給するグラフデータ作成処理のサービスが前段判定サービスとして、先にスケールアウトする場合もあり得る。その場合には、前段判定サービスであるグラフデータ作成処理のサービスがスケールアウトしたときに、当該サービスであるグラフ描画処理のサービスがスケールアウトの準備、すなわち、コンテナイメージのダウンロードをするようにすればよい。
図9に、本情報処理システム100において実行されるスケールアウトの処理手順を例示する。図9は、1つのサービス(以下、当該サービスと呼ぶ)に着目した観点からの処理を例示するフローチャートである。まず、実施形態1の情報処理システム100は、サービス定義から依存マップを作成する(S1)。サービス定義とは、例えば、サービスに対する入力情報、出力情報、および入力情報から出力情報を得るための処理等を定義した情報である。サービス定義は、例えば、利用者によって設定される。
本実施形態では、当該サービスに対して入力情報を取得する取得先のサービスを依存サービスと呼ぶ。また、当該サービスが出力情報を提供する提供先のサービスを被依存サービスと呼ぶ。本情報処理システム100は、入力情報の取得先および出力情報の提供先の情報を基に、サービスの依存関係を示す依存マップを作成する。
依存マップには、各サービスと、依存サービスの関係が定義される。なお、各サービスに対する依存サービスが定義できれば、依存マップを逆にたどることによって、各サービスに対する被依存サービスが把握できる。ただし、依存マップは、各サービスに対して、依存サービスおよび被依存サービスの両方を定義してもよい。依存マップを格納したテーブルは、依存テーブルと呼ばれる。依存テーブルは、例えば、実施形態2の図19で例示される。
また、本実施形態では、被依存サービス、すなわち、当該サービスの出力情報の提供先のサービスがスケールアウト要件を満たした場合に、当該サービスが状態4(preparing 2の状態)となる。そこで、本実施形態では、被依存サービスを前段判定サービスと呼ぶことにする。前段判定サービスは、第1の処理の一例である。また、前段判定サービスに対する当該サービスが第2の処理の一例である。
なお、被依存サービスを前段判定サービスとすることは、処理の一例であり、情報処理システム100は、このような処理に限定される訳ではない。例えば、依存サービス、すなわち、当該サービスの入力情報の取得先となるサービスを前段判定サービスとしてもよい。つまり、当該サービスの入力情報の取得先となるサービスがスケールアウトした場合
に、当該サービスが状態4(preparing 2の状態)となるようにしてもよい。
に、当該サービスが状態4(preparing 2の状態)となるようにしてもよい。
次に、情報処理システム100は、サービスを監視する(S2)。そして、情報処理システム100は、スケールアウト要件を満たした前段判定サービスがあるか否かを判定する(S3)。S2およびS3の処理は、第1の処理の負荷を監視することの一例である。S3で、スケールアウト要件を満たした前段判定サービスがあるとの判定(S3でYESの判定)は、第1の処理の負荷が第1の条件を超えることの一例である。
なお、スケールアウト要件は、スケールアウトするか否かを自動的に判定する要件であるので、オートスケール要件とも呼ばれる。スケールアウト要件を満たした前段判定サービスがある場合、情報処理システム100は、コンテナイメージがダウンロードされているか否かを判定する(S4)。そして、コンテナイメージがダウンロードされていない場合、情報処理システム100は、コンテナイメージをコンテナイメージリポジトリからダウンロードする(S5)。ダウンロード先は、ダウンロードされたコンテナイメージが起動されるノードである。S5の処理は、第1の処理に関係する第2の処理を実行する処理プログラムを第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することの一例である。
そして、情報処理システム100は、当該サービスの負荷が閾値を超えているか否かを判定する(S6)。S6の処理は、第1の処理に関係する第2の処理の負荷を監視することの一例である。すなわち、実施形態1の情報処理システム100は、S2、S3に例示されるように第1の処理の負荷を監視するとともに、S6に例示されるように、第1の処理に関係する第2の処理の負荷を監視する。
ここで、第1の処理に関係する第2の処理とは、第1の処理に対して第2の処理の結果のデータを入力する第2の処理をいう。第1の処理の例は、実施形態1のグラフ描画処理のサービスである。第2の処理の例は、実施形態1のグラフデータ作成処理のサービスである。かりに第1の処理の負荷に応じて、第1の処理がスケールアウトされた場合、第1の処理に対して結果のデータを入力する第2の処理も逐次的にスケールアウトする可能性がある。したがって、S2、S3で、スケールアウト要件を満たした前段判定サービスがあることを確認した上で、S6で当該サービスの負荷が閾値を超えていることを確認することで、迅速かつ無駄を少なくして当該サービスをスケールアウトできる。
また、第1の処理に関係する第2の処理とは、第1の処理の結果のデータが入力される第2の処理をいう。この場合には、第1の処理の例は、実施形態1のグラフデータ作成処理のサービスである。第2の処理の例は、実施形態1のグラフ描画処理のサービスである。第1の処理がスケールアウトし、処理能力が向上すると、逐次的に第1の処理の結果のデータが入力される第2の処理がスケールアウトする場合もあるからである。
そして、当該サービスの負荷が閾値を超えている場合、情報処理システム100は、コンテナイメージがダウンロードされたノードにおいて、コンテナイメージを起動する(S7)。S5の処理とS7の処理は、第2の処理を実行する処理ノードの数を増加することの一例である。S7の処理は、転送された処理プログラムを増加される処理ノードで起動することの一例でもある。S7の処理は、転送された処理プログラムを起動し、前記第2の処理を実行する処理ノードの数を増加することの一例でもある。
その後、情報処理システム100は、S2の処理に戻る。なお、当該サービスの負荷が閾値を超えていない場合、情報処理システム100は、コンテナイメージを起動しないで、S2の処理に戻る。S6で、当該サービスの負荷が閾値を超えているとの判定(YESの判定)は、第2の処理の負荷が第2の条件を超えることの一例である。
一方、S3の判定で、スケールアウト要件を満たした前段判定サービスがない場合、情報処理システム100は、当該サービスの負荷が閾値を超えているか否かを判定する(S8)。S3の判定で、スケールアウト要件を満たした前段判定サービスがないこと(S3でNOの判定)は、第1の処理の負荷が第1の条件を超えないことの一例である。S8の処理でYESの判定は、第2の処理の負荷が第2の条件を超えることの一例である。そして、当該サービスの負荷が閾値を超えている場合、情報処理システム100は、コンテナイメージがダウンロードされているか否かを判定する(S9)。そして、コンテナイメージがダウンロードされていない場合、情報処理システム100は、コンテナイメージをコンテナイメージリポジトリからダウンロードする(S10)。S10の処理は、第2の処理を実行する処理プログラムを増加される処理ノードにネットワークを通じて転送することの一例である。
さらに、情報処理システム100は、所定の時間継続して当該サービスの負荷が閾値を超えているか否かを判定する(S11)。S11でYESの判定は、第2の条件が超える状態が規定時間継続したことの一例である。所定の時間継続して当該サービスの負荷が閾値を超えている場合、情報処理システム100は、コンテナイメージがダウンロードされたノードにおいて、コンテナイメージを起動する(S7)。S10の処理とS7の処理は、第2の処理を実行する処理ノードの数を増加することの一例である。S7の処理は、転送された処理プログラムを増加される処理ノードで起動することの一例でもある。その後、情報処理システム100は、S2の処理に戻る。なお、当該サービスの負荷が閾値を超えた期間が所定の時間継続しなかった場合(S11の判定でNOの場合)、情報処理システム100は、コンテナイメージを起動しないで、S2の処理に戻る。
図9において、S4からS6の処理を実行中、サービスは、preparing 2の状態にある
。また、S8の処理でNOの判定がなされたとき、サービスは、stableの状態にある。また、S9からS11の処理を実行中、サービスは、preparing 1の状態にある。そして、
S7の処理を実行中、サービスは、firedの状態にある。
。また、S8の処理でNOの判定がなされたとき、サービスは、stableの状態にある。また、S9からS11の処理を実行中、サービスは、preparing 1の状態にある。そして、
S7の処理を実行中、サービスは、firedの状態にある。
以上述べたように、実施形態1の情報処理システム100は、前段判定サービス、例えば、当該サービスからの出力情報を提供する提供先となる被依存サービスがスケールアウトすると、当該サービスにおいてもスケールアウトの準備を行う。すなわち、当該サービスの処理を新たなノードで実行するため、ノードにコンテナイメージをダウンロードする。したがって、依存関係のある複数サービスにおいて、スケールアウトが連鎖的に実行される場合も、比較例1の処理よりも早期にスケールアウトを完了できる。
また、当該サービスでスケールアウトを実行するのは、当該サービスで負荷が閾値を超えた場合である。したがって、実施形態1では、単に、前段判定サービスがスケールアウトしたことから、依存関係のある当該サービスでの負荷の増加を予測するのみでなく、当該サービスで実際に負荷が閾値を超えたことを条件にコンテナイメージが起動される。このため、無駄なスケールアウトがなされにくくなる。
また、実施形態1では、前段判定サービスがスケールアウトしない場合でも、当該サービスで負荷が閾値を超えた場合に、スケールアウトの準備を行う。すなわち、情報処理システム100は、当該サービスの処理を新たなノードで実行するため、当該サービスを実行するノードを割当て、割当てたノードにコンテナイメージをロードする。そして、所定時間以上継続して負荷が閾値を超えた場合に、コンテナイメージが起動され、スケールアウトが実施される。したがって、当該サービスで負荷が閾値を超えたという第1の条件で、スケールアウトの準備をするとともに、所定時間以上継続して負荷が閾値を超えたという第2の条件で実際のスケールアウトが実行される。したがって、当該サービスにおける
判断で、スケールアウトを迅速に実行できる。さらに、このような処理によって、無駄なスケールアウトを抑止できる。
[比較例2]
判断で、スケールアウトを迅速に実行できる。さらに、このような処理によって、無駄なスケールアウトを抑止できる。
[比較例2]
図10、図11により、比較例2の処理を例示する。図10は、比較例2のスケールアウトの処理を例示する図である。図11は、処理対象の一例として、マイクロサービスの依存関係を例示する図である。
上記図9では、S1の処理のように、サービス定義から依存マップを作成し、前段判定サービスの状態と当該サービスの負荷の程度により、当該サービスの状態を判定する。すなわち、前段判定サービスがfiredの状態になると、情報処理システム100は、当該サ
ービスのコンテナイメージをダウンロードしておき、当該サービスの負荷が閾値を超えると、当該サービスを起動する。
ービスのコンテナイメージをダウンロードしておき、当該サービスの負荷が閾値を超えると、当該サービスを起動する。
図9の処理を単純化すると、図10で例示される比較例2の処理となる。比較例2では、例えば、前段判定サービス(グラフ描画処理)でスケールアウトを実施するとの判定がなされたときに、前段判定サービスだけでなく後段の当該サービス(グラフデータ作成処理)においてもスケールアウトを実施する。このような処理によっても、連鎖的なスケールアウトを比較例1の場合よりも早期に実行することは可能である。しかし、比較例2の処理は、マイクロサービスのようにより複雑な情報処理に対しては、処理効率が低下する。
図11のような依存関係を有するマイクロサービスを想定する。図11で、MS1からMS8は、依存関係のある複数のマイクロサービスを例示する。依存関係のあるマイクロサービス同士は線分で接続されている。例えば、MS1を前段サービスとして、MS2、MS4、およびMS8が連鎖的にスケールアウトする可能性のある依存サービスである。
比較例2の手順では、全てのサービスに対して、各サービスのスケールアウトの条件と後段サービスとの依存関係、およびスケールアウト条件を利用者が設定することになる。比較例1の図1に例示した3階層程度であれば、手動で定義することは現実的に可能である。しかし、マイクロサービスのように、多数段階に渡って依存関係が存在し、複雑かつ関連サービスが多い場合には、手動での依存関係の設定は困難となる。
[比較例3]
[比較例3]
図12、図13を参照して、比較例3の処理を説明する。上記実施形態1では、前段判定サービスがスケールアウトの条件を充足したときに、後段の当該サービスに対応するコンテナイメージがダウンロードされる(図9のS3からS5)。上記実施形態1の処理に代えて、例えば、予めコンテナイメージをダウンロードしておくことで、スケールアウトの時間を節約できる。しかし、クラスタ構成の情報処理システムの場合には、効率が低下する。
図12は、比較例3の処理を例示するタイムチャートである。比較例3の処理では、予めコンテナイメージがダウンロードされている。したがって、情報処理システムは、スケールアウト時に、各サービスについて、ダウンロード済みのコンテナイメージを起動すればよい。このため、比較例1の図1と比較して、スケールアウトの完了までの時間が早くなる。
図13は、クラスタ構成の情報処理システムにおいて、比較例3にしたがって、情報処理システムが予めコンテナイメージをダウンロードした場合の処理例である。クラスタ構成の情報処理システムでは、複数のサーバがネットワークで接続され、情報処理システム
としてサービスを提供する。比較例3の処理では、コンテナが起動しないサーバにもイメージがダウンロードされることになる。
としてサービスを提供する。比較例3の処理では、コンテナが起動しないサーバにもイメージがダウンロードされることになる。
すなわち、比較例3のように、予めコンテナイメージをダウンロードしておく方法でも、一台のサーバ上ですべてのコンテナを動かす情報処理システムの場合には問題は少ない。しかし、クラスタ化されたコンテナ稼働環境では、全てのノードにコンテナイメージをダウンロードしておくこととなり、リソースの無駄が大きくなる。実施形態1の場合、前段判定サービスがスケールアウトの条件を充足したときに後段の当該サービスのコンテナイメージがダウンロードされるため、投機的とはいえリスクが小さい。リスクとしては、ダウンロードによる無駄が生じるが、実際に当該サービスの負荷が閾値を超えない限り、コンテナイメージが起動されず、CPUリソースに対するリスクが小さくなる。
[比較例4]
[比較例4]
上記実施形態1では、前段判定サービスの状態と当該サービスの負荷の程度により、当該サービスのスケールアウトの要否を判定する(図9のS3、S6)。しかし、このような処理に代えて、前段判定サービスの状態から後段の当該サービスの負荷を推定して、当該サービスのスケールアウトの要否を判定することも考えられる。このような判定を連鎖的に進め全体の最適なスケール数を求め、同時に全体のスケーリングを実施することが考えられる。
しかしながら、このような方法では、スケールアウトの判定はあくまで、前段判定サービスの状態に基づく予測である。かつ、そのような予測のみに基づくスケールアウトが連鎖的に繰り返されることで、誤差が大きくなりうる。その際に、不必要なスケールアウトがされる可能性がある。すなわち、一のサービスにおいて、不必要なスケールアウトが起こると、その一のサービスに関係するサービスに不必要なスケールアウトが伝播し、リソースの無駄が発生する。一方、逆に、上記一のサービスで不必要なスケールインが実施された場合、サービスへの負荷が急速に上昇し、サービス品質の低下が生じ得る。例えば、図11において、サービスMS1の状態からサービスMS2において誤ったスケールアウトの判定がなされると、MS2の判定結果は、MS3、MS5からMS7、およびMS4に伝搬する。
一方、実施形態1の処理は、以下の点で上記比較例4の処理方法と差異がある。まず、サービスがスケールアウトする際、コンテナイメージのダウンロードと、コンテナ起動とで処理のステップが分離されている。また、前段判定サービスの状況に応じて、当該サービスの負荷が高いと予測され、コンテナイメージがダウンロードされる。そして、当該サービスの実際の負荷が閾値を超えたか否かに応じて、ダウンロードされたコンテナイメージが起動される。
このような処理方法の差異により、仮に前段判定サービスでの負荷に基づく当該サービスでの負荷の予測が外れた場合でも、不必要に消費されるのはダウンロードのためのディスクである。したがって、CPUやメモリは消費されないため、仮に前段判定サービスでの負荷に基づく当該サービスでの負荷の予測が外れた場合の影響が小さい。そして、実施形態1の手順では、予測が的中し、スケールアウトが実行される場合には、コンテナイメージがダウンロード済みため、コンテナの起動が早く、負荷の増加に対する早期の対応が可能となる。実施形態1の情報処理システム100では、相互に依存関係がある複数のサービスが高負荷の状態から健全な状態になるまでの時間を短縮する効果が得られる。
[実施形態2]
[実施形態2]
図14から図19を参照して、実施形態2に係る情報処理システム100を説明する。上記実施形態1では、依存関係のある複数のサービスについて、従来よりも迅速に、かつ
、無駄を抑制してスケールアウトを実施する情報処理システムについて説明した。本実施形態では、複数のノードサーバを含む情報処理システム100において、実施形態1と同様のスケールアウトを実施する手順を例示する。したがって、情報処理システム100の構成がさらに具体化される点を除いて、実施形態2の構成要素および作用は、実施形態1と同様である。
、無駄を抑制してスケールアウトを実施する情報処理システムについて説明した。本実施形態では、複数のノードサーバを含む情報処理システム100において、実施形態1と同様のスケールアウトを実施する手順を例示する。したがって、情報処理システム100の構成がさらに具体化される点を除いて、実施形態2の構成要素および作用は、実施形態1と同様である。
図14は、情報処理システム100の構成を例示する図である。なお、図14では、情報処理システム100にアクセスする利用者端末4も例示されている。図14のように、情報処理システム100は、コンテナイメージリポジトリサーバ1と、マスタサーバ2と、複数のノードサーバ3−1、3−2、3−3等を有している。なお、ノードサーバ3−1、3−2、3−3等を総称する場合には、単にノードサーバ3という。図14の情報処理装置10は、クラスタ構成の情報処理システムということができる。情報処理システム100は、コンピュータシステムの一例である。
コンテナイメージリポジトリサーバ1は、ネットワークインターフェース114と、コンテナイメージリポジトリ101とを有する。コンテナイメージリポジトリサーバ1は、ネットワークインターフェース114を通じてネットワークにアクセスし、マスタサーバ2、ノードサーバ3等と通信する。コンテナイメージリポジトリ101は、ある種のデータベースであり、コンテナイメージが登録される。コンテナイメージリポジトリサーバ1は、コンテナイメージリポジトリ101に格納されているコンテナイメージを管理する。
マスタサーバ2は、ネットワークインターフェース214と、Application Programming Interface(API)処理プログラム201と、コンテナクラスタ管理プログラム20
2と、を有する。マスタサーバ2は、ネットワークインターフェース214を通じてネットワークにアクセスし、コンテナイメージリポジトリサーバ1、ノードサーバ3等と通信する。
2と、を有する。マスタサーバ2は、ネットワークインターフェース214を通じてネットワークにアクセスし、コンテナイメージリポジトリサーバ1、ノードサーバ3等と通信する。
また、マスタサーバ2は、API処理プログラム201を実行することにより、利用者端末4からのリクエストを処理し、コンテナクラスタ管理プログラム202へリクエストを引き渡す。また、マスタサーバ2は、コンテナクラスタ管理プログラム202を実行することにより、各ノードサーバ3の状態を取得し、クラスタのノード、サービス、コンテナなどを管理する。例えば、マスタサーバ2は、コンテナクラスタ管理プログラム202にしたがい、マスタサーバ2に、利用者からのリクエストや、予め定められた設定に従い、タスクを登録する。
ノードサーバ3は、ネットワークインターフェース314と、コンテナ管理プログラム302と、コンテナ監視プログラム303とを有する。ノードサーバ3は、ネットワークインターフェース314を通じてネットワークにアクセスし、コンテナイメージリポジトリサーバ1、マスタサーバ2等と通信する。
また、ノードサーバ3は、コンテナ管理プログラム302を実行することにより、
コンテナクラスタ管理プログラムを実行するマスタサーバ2から情報を取得し、コンテナイメージのダウンロード、コンテナの起動、コンテナの削除を行う。また、ノードサーバ3は、コンテナ監視プログラム303を実行することにより、コンテナのリソース使用量等を監視する。
コンテナクラスタ管理プログラムを実行するマスタサーバ2から情報を取得し、コンテナイメージのダウンロード、コンテナの起動、コンテナの削除を行う。また、ノードサーバ3は、コンテナ監視プログラム303を実行することにより、コンテナのリソース使用量等を監視する。
図15に、コンテナイメージリポジトリサーバ1、マスタサーバ2、またはノードサーバ3として利用される情報処理装置10のハードウェア構成を例示する。なお、情報処理装置10は、利用者端末4としても利用可能である。
情報処理装置10は、Central Processing Unit(CPU)11、主記憶装置12、イ
ンターフェース18を通じて接続される外部機器を有し、プログラムにより情報処理を実行する。外部機器としては、外部記憶装置13およびネットワークインターフェース14を例示できる。CPU11は、主記憶装置12に実行可能に展開されたコンピュータプログラムを実行し、情報処理装置10の情報処理方法を実行する。CPU11は、プロセッサの一例である。
ンターフェース18を通じて接続される外部機器を有し、プログラムにより情報処理を実行する。外部機器としては、外部記憶装置13およびネットワークインターフェース14を例示できる。CPU11は、主記憶装置12に実行可能に展開されたコンピュータプログラムを実行し、情報処理装置10の情報処理方法を実行する。CPU11は、プロセッサの一例である。
主記憶装置12は、CPU11が実行するコンピュータプログラム、CPU11が処理するデータ等を記憶する。主記憶装置12は、Dynamic Random Access Memory(DRAM)、Static Random Access Memory(SRAM)、Read Only Memory(ROM)等である
。主記憶装置12は、メモリの一例である。
。主記憶装置12は、メモリの一例である。
さらに、外部記憶装置13は、例えば、主記憶装置12を補助する記憶領域として使用され、CPU11が実行するコンピュータプログラム、CPU11が処理するデータ等を記憶する。外部記憶装置13は、ハードディスクドライブ、Solid State Disk(SSD)等である。
また、情報処理装置10は、入力装置15、表示装置16等によるユーザインターフェースを有するようにしてもよい。入力装置15は、例えば、キーボード、ポインティングデバイス等である。また、表示装置16は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。さらに、情報処理装置10は、着脱可能記憶媒体駆動装置17を設けてもよい。着脱可能記憶媒体は、例えば、ブルーレイディスク、Digital Versatile Disk(DVD)、Compact Disc(CD)、フラッシュメモリカード等である。なお、図15の例では、単一のインターフェース18が例示されているが、インターフェース18として複数種類のものが複数設けられてもよい。
図16に、コンテナクラスタ管理プログラム202の処理を例示する。マスタサーバ2のCPU11は、主記憶装置12に実行可能に展開されたコンテナクラスタ管理プログラム202にしたがって、図16の処理を実行する。マスタサーバ2は、管理ノードの一例である。
マスタサーバ2は、コンテナ監視プログラム303を実行するノードサーバ3からコンテナのリソース状況を取得する(S21)。そして、マスタサーバ2は、取得したコンテナのリソース状況からサービスのリソース状況を計算する(S22)。次に、マスタサーバ2は、サービスのリソース状況とサービス状態テーブルから状態遷移が発生するか否かを確認する(S23)。サービス状態テーブルは、マスタサーバ2の主記憶装置12に保存されている。サービス状態テーブルは、各サービスの状態を保持する。S23の処理での確認は、例えば、stableの状態のサービスで、負荷が閾値を超えたか否かの確認である。また、S23の処理での確認は、preparing 1の状態が所定時間継続したか否かである
。また、S23での確認は、stableの状態のサービスで、前段サービスがfiredになった
か否かである。また、S23での確認は、preparing 2の状態のサービスで、負荷が閾値
を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ2は、状態遷移が発生すると判断する。
。また、S23での確認は、stableの状態のサービスで、前段サービスがfiredになった
か否かである。また、S23での確認は、preparing 2の状態のサービスで、負荷が閾値
を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ2は、状態遷移が発生すると判断する。
そして、状態遷移が発生すると判断した場合(S24でYESの場合)、マスタサーバ2は、状態テーブルを更新する(S25)。そして、マスタサーバ2は、タスクを登録する(S26)。ここで、タスクとは、コンテナイメージのダウンロード、そして、ダウンロードされたコンテナイメージの起動である。
S21からS23の処理は、第1の処理の負荷を監視することの一例である。なお、S
21からS23の処理は、第2の処理の負荷を監視することの一例である。例えば、前段サービスがfiredになったことは、第1の処理の負荷が第1の条件を超えることの一例で
ある。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第2の処理
の負荷が第2の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第1の処理の負荷が第1の条件を超えないときに、第2の処理の負荷が第2の条件を超えることの一例である。また、preparing 1の状態が所定
時間継続したことは、第2の条件を超える状態が規定時間継続したことの一例である。
21からS23の処理は、第2の処理の負荷を監視することの一例である。例えば、前段サービスがfiredになったことは、第1の処理の負荷が第1の条件を超えることの一例で
ある。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第2の処理
の負荷が第2の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第1の処理の負荷が第1の条件を超えないときに、第2の処理の負荷が第2の条件を超えることの一例である。また、preparing 1の状態が所定
時間継続したことは、第2の条件を超える状態が規定時間継続したことの一例である。
S23の処理において、状態遷移が発生する場合の一例は、例えば、状態がStableからpreparing 1に遷移する場合である。状態がpreparing 1に遷移すると、S26の処理では、コンテナイメージダウンロードのタスクが登録される。また、状態遷移が発生する場合の他の例は、状態がpreparing 1からfiredに遷移する場合である。状態がfiredに遷移す
ると、S26の処理では、コンテナ起動のタスクが登録される。S26の処理で、コンテナ起動のタスクが登録されることは、第2の処理を実行する処理ノードの数を増加することの一例である。
ると、S26の処理では、コンテナ起動のタスクが登録される。S26の処理で、コンテナ起動のタスクが登録されることは、第2の処理を実行する処理ノードの数を増加することの一例である。
図17に、コンテナ管理プログラム302の処理を例示する。ノードサーバ3のCPU11は、主記憶装置12に実行可能に展開されたコンテナ管理プログラム302にしたがって、図17の処理を実行する。ノードサーバ3は、処理ノードの一例である。
ノードサーバ3は、コンテナクラスタ管理プログラムを実行するマスタサーバ2にタスクが登録されているか否かを確認する(S31)。マスタサーバ2に登録されたタスクが存在する場合(S32でYES)、ノードサーバ3は、タスクの種類を判定する(S33)。タスクの種類がコンテナイメージダウンロードの場合、ノードサーバ3は、コンテナイメージリポジトリ101からコンテナイメージをダウンロードする(S34)。S34の処理は、第1の処理に関係する第2の処理を実行する処理プログラムを第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することの一例である。
一方、タスクの種類がコンテナ起動の場合、ノードサーバ3は、コンテナイメージがダウンロード済みか否かを判定する(S35)。コンテナイメージがダウンロード済みでない場合、ノードサーバ3は、コンテナイメージをダウンロードする(S36)。そして、ノードサーバ3は、ダウンロード済みのコンテナイメージを起動する(S37)。S37の処理は、転送された処理プログラムを前記増加される処理ノードで起動することの一例である。
図18に、サービス状態テーブルの構成を例示する。サービス状態テーブルは、現時点の各サービスの状態を保持するテーブルである。図18の例では、サービスA、B、C、D、およびEの状態(Status)として、stable、 preparing 1、 fired、 stable、およびpreparing 2がそれぞれ保持されている。状態遷移に伴い、サービス状態テーブルは、図16のS25の処理によって更新される。
図19は、サービス依存テーブルの構成を例示する。サービス依存テーブルは、サービス間の依存関係を定義する。図19の例では、サービスAは、サービスB、Cに依存し、サービスBは、サービスD、Eに依存し、サービスCは、サービスEに依存することが定義されている。サービスAがサービスBに依存する関係とは、例えば、サービスAがサービスBからデータの提供を受ける関係をいう。例えば、実施形態1のグラフ描画処理のサービスは、グラフデータ作成サービスに依存している、ということができる。ただし、逆に、サービスAがサービスBに依存する関係として、例えば、サービスAがサービスBにデータの提供をする関係としてもよい。例えば、実施形態1のグラフデータ作成サービスは、グラフ描画処理のサービスに依存している、というようにしてもよい。
図20は、1つのサービスの状態遷移を例示する。例えば、現在、ある1つのサービスがstableな状態であると仮定する。stableな状態のサービスの負荷が閾値超えになると、このサービスは、preparing 1の状態に遷移する。サービスの状態がpreparing 1になると、図16のS26の処理で説明したように、コンテナイメージダウンロードのタスクが登録され、図17のS34の処理で、コンテナイメージが、事前にダウンロードされる。そして、preparing 1の状態に遷移したサービスの負荷が所定時間継続される前に、サービ
スの負荷が閾値より下になると、このサービスは再びstableに戻る。
スの負荷が閾値より下になると、このサービスは再びstableに戻る。
一方、preparing 1の状態に遷移したサービスの負荷が所定時間継続すると、状態がfiredになる。サービスの状態がfiredになると、図16の26で説明したように、コンテナ
起動のタスクが登録され、図17のS37の処理で、コンテナイメージが、起動される。なお、1つのサービスの状態がpreparing 1の状態で前段判定サービスがfiredになった場合も、当該1つのサービスの状態はfiredになる。
起動のタスクが登録され、図17のS37の処理で、コンテナイメージが、起動される。なお、1つのサービスの状態がpreparing 1の状態で前段判定サービスがfiredになった場合も、当該1つのサービスの状態はfiredになる。
また、stableな状態のサービスに対して、前段判定サービスがfiredになると、そのstableな状態のサービスは、preparing 2の状態になる。サービスがpreparing 2の状態にな
ると、図16のS26の処理で説明したように、コンテナイメージのダウンロードのタスクが登録され、図17のS34の処理で、コンテナイメージが、事前にダウンロードされる。そして、preparing 2の状態のサービスの負荷が閾値を超えると、サービスはfiredの状態になる。サービスの状態がfiredになると、上述のpreparing 1からfiredになった場
合と同様、コンテナ起動のタスクが登録され、図17のS37の処理で、コンテナイメージが、起動される。
<実施形態の効果>
ると、図16のS26の処理で説明したように、コンテナイメージのダウンロードのタスクが登録され、図17のS34の処理で、コンテナイメージが、事前にダウンロードされる。そして、preparing 2の状態のサービスの負荷が閾値を超えると、サービスはfiredの状態になる。サービスの状態がfiredになると、上述のpreparing 1からfiredになった場
合と同様、コンテナ起動のタスクが登録され、図17のS37の処理で、コンテナイメージが、起動される。
<実施形態の効果>
以上述べたように、実施形態2の情報処理システムによれば、マスタサーバ2は、コンテナ監視プログラム303を実行するノードサーバ3からコンテナのリソース状況を取得し(図16のS21)、リソースの状況からサービスの負荷を計算する(同S22)。そして、マスタサーバ2は、サービスの負荷とサービス状態テーブルとから状態遷移が発生するか否かを判定する(同S23、S24)。例えば、stableの状態のサービスの負荷が閾値を超えると、状態がstableからpreparing 1に遷移する。また、stableの状態のサー
ビスについて、前段判定サービスがfiredになると、stableの状態のサービスがpreparing
2の状態に遷移する。そして、サービスの状態がpreparing 1あるいはpreparing 2に遷移すると、マスタサーバ2は、そのサービスを起動するためのコンテナイメージをダウンロードするように、ノードサーバ3向けのタスクを登録する(図16のS26)。ノードサーバ3は、登録されたタスクを実行し、コンテナイメージをダウンロードするタスクを実行することで、事前にスケールアウトで起動されるコンテナイメージをダウンロードしておく。
ビスについて、前段判定サービスがfiredになると、stableの状態のサービスがpreparing
2の状態に遷移する。そして、サービスの状態がpreparing 1あるいはpreparing 2に遷移すると、マスタサーバ2は、そのサービスを起動するためのコンテナイメージをダウンロードするように、ノードサーバ3向けのタスクを登録する(図16のS26)。ノードサーバ3は、登録されたタスクを実行し、コンテナイメージをダウンロードするタスクを実行することで、事前にスケールアウトで起動されるコンテナイメージをダウンロードしておく。
そして、preparing 1の状態が所定時間継続すると、サービスの状態がfiredに遷移する。また、preparing 2の状態のサービスの負荷が閾値を超えると、状態がfiredに遷移する。そして、サービスの状態がfiredに遷移すると、マスタサーバ2は、そのサービスに対
応するコンテナイメージを起動するように、ノードサーバ3向けのタスクを登録する(図16のS26)。ノードサーバ3は、登録されたタスクにしたがって、コンテナイメージを起動する(図17のS37)。
応するコンテナイメージを起動するように、ノードサーバ3向けのタスクを登録する(図16のS26)。ノードサーバ3は、登録されたタスクにしたがって、コンテナイメージを起動する(図17のS37)。
このように、実施形態2の情報処理システム100は、実施形態1の場合と同様、第1の処理に関係する第2の処理の負荷を監視する。ここで、第1の処理に関係する第2の処理とは、第1の処理に対して第2の処理の結果のデータを入力する第2の処理をいう。第1の処理の例は、実施形態1のグラフ描画処理のサービスである。第2の処理の例は、実
施形態1のグラフデータ作成処理のサービスである。また、第1の処理に関係する第2の処理とは、第1の処理の結果のデータが入力される第2の処理をいう。この場合には、第1の処理の例は、実施形態1のグラフデータ作成処理のサービスである。第2の処理の例は、実施形態1のグラフ描画処理のサービスである。
施形態1のグラフデータ作成処理のサービスである。また、第1の処理に関係する第2の処理とは、第1の処理の結果のデータが入力される第2の処理をいう。この場合には、第1の処理の例は、実施形態1のグラフデータ作成処理のサービスである。第2の処理の例は、実施形態1のグラフ描画処理のサービスである。
そして、第1の処理に相当する前段判定サービスの状態が第1の条件であるfiredを充
足するとともに、第2の処理の実行時の負荷が閾値を超えると、コンテナイメージをノードサーバ3で起動し、スケールアウトを実行する。つまり、実施形態2の情報処理システム100も、実施形態1と同様、前段判定サービスの状態からの予測と、当該サービスでの実際の負荷の状況によってスケールアウトを実行する。このような処理によって、実施形態2の情報処理システム100は、比較例1から4等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
足するとともに、第2の処理の実行時の負荷が閾値を超えると、コンテナイメージをノードサーバ3で起動し、スケールアウトを実行する。つまり、実施形態2の情報処理システム100も、実施形態1と同様、前段判定サービスの状態からの予測と、当該サービスでの実際の負荷の状況によってスケールアウトを実行する。このような処理によって、実施形態2の情報処理システム100は、比較例1から4等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
また、実施形態2の情報処理システム100は、実施形態1と同様、前段判定サービスの状態がfiredとなったことによる予測にしたがって、まず、コンテナイメージのダウン
ロードを実行する。そして、情報処理システム100は、当該サービスでの実際の負荷の状況によってダウンロード済みのコンテナイメージを起動する。したがって、コンテナイメージをノードサーバ3で実行することによるスケールアウト実行時に、コンテナのダウンロードの工程と、コンテナイメージの起動の工程とに分離して、スケールアウトが実行される。このような処理によって、実施形態2の情報処理システム100は、比較例1から4等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
ロードを実行する。そして、情報処理システム100は、当該サービスでの実際の負荷の状況によってダウンロード済みのコンテナイメージを起動する。したがって、コンテナイメージをノードサーバ3で実行することによるスケールアウト実行時に、コンテナのダウンロードの工程と、コンテナイメージの起動の工程とに分離して、スケールアウトが実行される。このような処理によって、実施形態2の情報処理システム100は、比較例1から4等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
また、実施形態2の情報処理システム100では、前段判定サービスの状態がfiredと
ならない場合でも、当該サービスの負荷が閾値を超えた場合には、状態がpreparing 1と
なる。その結果、コンテナイメージがノードサーバ3にダウンロードされる。preparing 1の状態が所定時間継続すると、コンテナイメージがノードサーバ3で起動される。した
がって、実施形態2の情報処理システム100では、前段判定サービスの状態によらず、当該サービスの監視によって、2段階でスケールアウトの実行要否を判定する。また、この場合も、コンテナイメージのダウンロードと、コンテナイメージの起動の2段階でスケールアウトが実行される。したがって、このような処理によっても、実施形態2の情報処理システムは、比較例1から4の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
ならない場合でも、当該サービスの負荷が閾値を超えた場合には、状態がpreparing 1と
なる。その結果、コンテナイメージがノードサーバ3にダウンロードされる。preparing 1の状態が所定時間継続すると、コンテナイメージがノードサーバ3で起動される。した
がって、実施形態2の情報処理システム100では、前段判定サービスの状態によらず、当該サービスの監視によって、2段階でスケールアウトの実行要否を判定する。また、この場合も、コンテナイメージのダウンロードと、コンテナイメージの起動の2段階でスケールアウトが実行される。したがって、このような処理によっても、実施形態2の情報処理システムは、比較例1から4の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
このように、前段判定サービスの状態によらず、当該サービスの監視によって、2段階でスケールアウトの実行要否を判定する場合も、コンテナのダウンロードの工程と、コンテナイメージの起動の工程とに分離して、スケールアウトが実行される。このような処理によって、実施形態2の情報処理システム100は、比較例1から4等の場合よりも、迅速かつ無駄なく、スケールアウトを実行できる。
また、従来、仮想マシンを基にスケールアウトを実行する場合、仮想マシンの起動に時間を要していた。例えば、Infrastructure as a Service(IaaS)では、スケールア
ウトに分単位の時間がかかるため、インスタンス作成および起動以外の時間を短縮したとしても相対的な影響は小さく効果が得られなかった。ここで、インスタンスとは、IaaSで提供される仮想マシンである。また、IaaSとは、情報システムの稼動に必要な機材や回線などの基盤(インフラ)を、インターネット上のサービスとして遠隔から利用できるようにしたものをいう。一方、仮想マシンを基にスケールアウトを実行する場合と比較して、コンテナを基にスケールアウトを実行する場合には、起動までの時間が仮想マシンと比較して、2桁短縮される。
ウトに分単位の時間がかかるため、インスタンス作成および起動以外の時間を短縮したとしても相対的な影響は小さく効果が得られなかった。ここで、インスタンスとは、IaaSで提供される仮想マシンである。また、IaaSとは、情報システムの稼動に必要な機材や回線などの基盤(インフラ)を、インターネット上のサービスとして遠隔から利用できるようにしたものをいう。一方、仮想マシンを基にスケールアウトを実行する場合と比較して、コンテナを基にスケールアウトを実行する場合には、起動までの時間が仮想マシンと比較して、2桁短縮される。
したがって、コンテナを基にスケールアウトを実行する場合には、起動以外のダウンロ
ードなどの時間がスケールアウトの時間に顕著に影響を与えるようになる。上記実施形態1、2の処理では、1つのサービスに対して、前段判定サービスがfiredの状態になると
、当該1つのサービスを実行するためのコンテナイメージがノードサーバ3にダウンロードされる。そして、当該1つのサービスの負荷が閾値を超えた場合に、当該サービスに対応するコンテナイメージがダウンロード先のノードサーバ3で起動される。したがって、本実施形態の処理では、起動以外のダウンロードの時間によるスケールアウトの時間への影響を低減できる。
《コンピュータが読み取り可能な記録媒体》
ードなどの時間がスケールアウトの時間に顕著に影響を与えるようになる。上記実施形態1、2の処理では、1つのサービスに対して、前段判定サービスがfiredの状態になると
、当該1つのサービスを実行するためのコンテナイメージがノードサーバ3にダウンロードされる。そして、当該1つのサービスの負荷が閾値を超えた場合に、当該サービスに対応するコンテナイメージがダウンロード先のノードサーバ3で起動される。したがって、本実施形態の処理では、起動以外のダウンロードの時間によるスケールアウトの時間への影響を低減できる。
《コンピュータが読み取り可能な記録媒体》
コンピュータその他の機械、装置(以下、コンピュータ等)に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。
ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、CD−ROM、CD−R/W、DVD、ブルーレイディスク、DAT、8mmテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ROM(リードオンリーメモリ)等がある。さらに、SSD(Solid State Drive)は、コンピュータ等から取り外し可能な記録媒体としても、コンピュータ
等に固定された記録媒体としても利用可能である。
等に固定された記録媒体としても利用可能である。
1 コンテナイメージリポジトリサーバ
2 マスタサーバ
3 ノードサーバ
10 情報処理装置
11 CPU
12 主記憶装置
14 ネットワークインターフェース
100 情報処理システム
101 コンテナイメージリポジトリ
114、214、314 ネットワークインターフェース
201 API処理プログラム
202 コンテナクラスタ管理プログラム
301 コンテナ
302 コンテナ管理プログラム
303 コンテナ監視プログラム
2 マスタサーバ
3 ノードサーバ
10 情報処理装置
11 CPU
12 主記憶装置
14 ネットワークインターフェース
100 情報処理システム
101 コンテナイメージリポジトリ
114、214、314 ネットワークインターフェース
201 API処理プログラム
202 コンテナクラスタ管理プログラム
301 コンテナ
302 コンテナ管理プログラム
303 コンテナ監視プログラム
アクション2:状態2(preparing1)、状態4(preparing2)で、スケールアウトの準備を実施する。具体的には、本情報処理システム100はサービスにノードを割当て、割当てられたノードにコンテナイメージをダウンロードする。アクション2により、例えば、結果的に自サービスで負荷が上がらずスケールアウトせず、ダウンロードが無駄になる可能性もある。しかし、本情報処理システム100は、スケールアウトの見込みが高いと判断して、アクション2を実施する。アクション2による準備の実施で、ダウンロードされたコンテナイメージが実際に起動されるのは、自サービスが状態3または状態5になった場合である。
図11のような依存関係を有するマイクロサービスを想定する。図11で、MS1からMS8は、依存関係のある複数のマイクロサービスを例示する。依存関係のあるマイクロサービス同士は線分で接続されている。例えば、MS1を前段判定サービスとして、MS2、MS4、およびMS8が連鎖的にスケールアウトする可能性のある依存サービスである。
マスタサーバ2は、コンテナ監視プログラム303を実行するノードサーバ3からコンテナのリソース状況を取得する(S21)。そして、マスタサーバ2は、取得したコンテナのリソース状況からサービスのリソース状況を計算する(S22)。次に、マスタサーバ2は、サービスのリソース状況とサービス状態テーブルから状態遷移が発生するか否か
を確認する(S23)。サービス状態テーブルは、マスタサーバ2の主記憶装置12に保存されている。サービス状態テーブルは、各サービスの状態を保持する。S23の処理での確認は、例えば、stableの状態のサービスで、負荷が閾値を超えたか否かの確認である。また、S23の処理での確認は、preparing 1の状態が所定時間継続したか否かである
。また、S23での確認は、stableの状態のサービスで、前段判定サービスがfiredにな
ったか否かである。また、S23での確認は、preparing 2の状態のサービスで、負荷が
閾値を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ2は、状態遷移が発生すると判断する。
を確認する(S23)。サービス状態テーブルは、マスタサーバ2の主記憶装置12に保存されている。サービス状態テーブルは、各サービスの状態を保持する。S23の処理での確認は、例えば、stableの状態のサービスで、負荷が閾値を超えたか否かの確認である。また、S23の処理での確認は、preparing 1の状態が所定時間継続したか否かである
。また、S23での確認は、stableの状態のサービスで、前段判定サービスがfiredにな
ったか否かである。また、S23での確認は、preparing 2の状態のサービスで、負荷が
閾値を超えたか否かである。これらの確認を肯定する判断がされると、マスタサーバ2は、状態遷移が発生すると判断する。
S21からS23の処理は、第1の処理の負荷を監視することの一例である。なお、S21からS23の処理は、第2の処理の負荷を監視することの一例である。例えば、前段判定サービスがfiredになったことは、第1の処理の負荷が第1の条件を超えることの一
例である。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第2の
処理の負荷が第2の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第1の処理の負荷が第1の条件を超えないときに、第2の処理の負荷が第2の条件を超えることの一例である。また、preparing 1の状態が所定時間継続したことは、第2の条件を超える状態が規定時間継続したことの一例である。
例である。また、preparing 2の状態のサービスで、負荷が閾値を超えたことは、第2の
処理の負荷が第2の条件を超えることの一例である。さらに、stableの状態のサービスで、負荷が閾値を超えたことの確認は、第1の処理の負荷が第1の条件を超えないときに、第2の処理の負荷が第2の条件を超えることの一例である。また、preparing 1の状態が所定時間継続したことは、第2の条件を超える状態が規定時間継続したことの一例である。
Claims (7)
- 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムに、
第1の処理の負荷を監視し、
前記第1の処理の負荷が第1の条件を超えるときに、前記第1の処理に関係する第2の処理を実行する処理プログラムを前記第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させるコンピュータプログラム。 - 前記第2の処理の負荷が第2の条件を超えるときに、前記転送された処理プログラムを起動し、前記第2の処理を実行する処理ノードの数を増加することをさらに実行させる請求項1に記載のコンピュータプログラム。
- 前記第1の処理の負荷が第1の条件を超えないときに、前記第2の処理の負荷が第2の条件を超え、かつ、前記第2の条件を超える状態が規定時間継続したときに、前記第2の処理を実行する処理ノードの数を増加することを実行させる請求項1または2に記載のコンピュータプログラム。
- 前記処理ノードの数を増加することは、
前記第2の処理の負荷が第2の条件を超えるときに、前記第2の処理を実行する処理プログラムを前記増加される処理ノードにネットワークを通じて転送することと、
前記第2の条件を超える状態が規定時間継続したときに、前記転送された処理プログラムを前記増加される処理ノードで起動することと、を含む請求項3に記載のコンピュータプログラム。 - 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムが、
第1の処理の負荷を監視し、
前記第1の処理の負荷が第1の条件を超えるときに、前記第1の処理に関係する第2の処理を実行する処理プログラムを前記第2の処理を実行するために増加される処理ノードにネットワークを通じて転送する情報処理方法。 - 複数の処理を負荷分散して実行する処理ノードの数を変更可能なコンピュータシステムを管理する管理ノードであって、
前記管理ノードは、プロセッサとメモリとを有し、前記メモリに記憶されたコンピュータプログラムが前記プロセッサに、
第1の処理の負荷を監視し、
前記第1の処理の負荷が第1の条件を超えるときに、前記第1の処理に関係する第2の処理を実行する処理プログラムを前記第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる管理ノード。 - 複数の処理を負荷分散して実行する処理ノードの数を変更可能な情報処理システムであって、
前記処理ノードと前記処理ノードを管理する管理ノードとを有し、
前記管理ノードは、プロセッサとメモリとを有し、前記メモリに記憶されたコンピュータプログラムが前記プロセッサに、
第1の処理の負荷を監視し、
前記第1の処理の負荷が第1の条件を超えるときに、前記第1の処理に関係する第2の処理を実行する処理プログラムを前記第2の処理を実行するために増加される処理ノードにネットワークを通じて転送することを実行させる情報処理システム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016112920A JP2017219972A (ja) | 2016-06-06 | 2016-06-06 | コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム |
US15/604,846 US20170353541A1 (en) | 2016-06-06 | 2017-05-25 | Non-transitory recording medium, information processing method, management node and information processing system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2016112920A JP2017219972A (ja) | 2016-06-06 | 2016-06-06 | コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2017219972A true JP2017219972A (ja) | 2017-12-14 |
Family
ID=60482391
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016112920A Pending JP2017219972A (ja) | 2016-06-06 | 2016-06-06 | コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20170353541A1 (ja) |
JP (1) | JP2017219972A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020095547A (ja) * | 2018-12-13 | 2020-06-18 | 株式会社日立製作所 | コンテナ提供支援システムおよびコンテナ提供支援方法 |
JP7079998B1 (ja) | 2021-12-16 | 2022-06-03 | 北京穿楊科技有限公司 | クラスタの容量拡張方法及び装置 |
WO2023112230A1 (ja) * | 2021-12-15 | 2023-06-22 | 富士通株式会社 | 生成方法、情報処理装置および生成プログラム |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10394541B2 (en) * | 2016-07-27 | 2019-08-27 | Optim Corporation | System, method, and program for distributing container image |
JP7011162B2 (ja) | 2018-02-05 | 2022-01-26 | 富士通株式会社 | 性能調整プログラム、および性能調整方法 |
JP7004902B2 (ja) * | 2018-02-05 | 2022-01-21 | 富士通株式会社 | 性能評価プログラム、および性能評価方法 |
US11121943B2 (en) * | 2018-12-13 | 2021-09-14 | Sap Se | Amplifying scaling elasticity of microservice meshes |
US11188437B1 (en) | 2020-07-30 | 2021-11-30 | Bank Of America Corporation | Remote deployment of monitoring agents on computing systems |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004086246A1 (ja) * | 2003-03-24 | 2004-10-07 | Fujitsu Limited | 分散処理制御装置、分散処理制御方法および分散処理制御プログラム |
US8589490B2 (en) * | 2008-01-16 | 2013-11-19 | Janos Tapolcai | System, method, and computer program for solving mixed integer programs with peer-to-peer applications |
US8819106B1 (en) * | 2008-12-12 | 2014-08-26 | Amazon Technologies, Inc. | Managing distributed execution of programs |
JP6248560B2 (ja) * | 2013-11-13 | 2017-12-20 | 富士通株式会社 | 管理プログラム、管理方法、および管理装置 |
US9992103B2 (en) * | 2014-01-24 | 2018-06-05 | Cisco Technology, Inc. | Method for providing sticky load balancing |
US9848041B2 (en) * | 2015-05-01 | 2017-12-19 | Amazon Technologies, Inc. | Automatic scaling of resource instance groups within compute clusters |
US10439870B2 (en) * | 2015-11-24 | 2019-10-08 | International Business Machines Corporation | Assessment and dynamic provisioning of computing resources for multi-tiered application |
US10574741B2 (en) * | 2016-04-18 | 2020-02-25 | Nokia Technologies Oy | Multi-level load balancing |
-
2016
- 2016-06-06 JP JP2016112920A patent/JP2017219972A/ja active Pending
-
2017
- 2017-05-25 US US15/604,846 patent/US20170353541A1/en not_active Abandoned
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2020095547A (ja) * | 2018-12-13 | 2020-06-18 | 株式会社日立製作所 | コンテナ提供支援システムおよびコンテナ提供支援方法 |
WO2023112230A1 (ja) * | 2021-12-15 | 2023-06-22 | 富士通株式会社 | 生成方法、情報処理装置および生成プログラム |
JP7079998B1 (ja) | 2021-12-16 | 2022-06-03 | 北京穿楊科技有限公司 | クラスタの容量拡張方法及び装置 |
JP2023089891A (ja) * | 2021-12-16 | 2023-06-28 | 北京穿楊科技有限公司 | クラスタの容量拡張方法及び装置 |
Also Published As
Publication number | Publication date |
---|---|
US20170353541A1 (en) | 2017-12-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2017219972A (ja) | コンピュータプログラム、情報処理方法、管理ノードおよび情報処理システム | |
US11182196B2 (en) | Unified resource management for containers and virtual machines | |
US10911367B2 (en) | Computerized methods and systems for managing cloud computer services | |
US10873623B2 (en) | Dynamically modifying a cluster of computing nodes used for distributed execution of a program | |
US10628225B2 (en) | Resource configuration system, resource configuration method and resource configuration program for selecting a computational resource and selecting a provisioning method | |
US8260840B1 (en) | Dynamic scaling of a cluster of computing nodes used for distributed execution of a program | |
JPWO2012093472A1 (ja) | サービスの予約管理方法、仮想計算機システム及び記憶媒体 | |
JP5862359B2 (ja) | シンクライアントシステム、接続管理サーバ、接続管理方法、及び接続管理プログラム | |
CN105786603B (zh) | 一种基于分布式的高并发业务处理***及方法 | |
US10785129B2 (en) | Computerized methods and systems for maintaining and modifying cloud computer services | |
TW201712527A (zh) | 用於新應用程式之記憶體管理模型與介面 | |
US10853128B2 (en) | Virtual machine management device and virtual machine management method | |
US20210326161A1 (en) | Apparatus and method for multi-cloud service platform | |
JP7159887B2 (ja) | 仮想化基盤および仮想化基盤のスケーリング管理方法 | |
US11327788B2 (en) | Methods for scheduling multiple batches of concurrent jobs | |
JP2017068480A (ja) | ジョブ管理方法、ジョブ管理装置及びプログラム | |
US8832156B2 (en) | Distributed computing management | |
JP6620609B2 (ja) | 分散処理実行管理プログラム、分散処理実行管理方法および分散処理実行管理装置 | |
JP2019008454A (ja) | 情報処理システムおよびリソース割り当て方法 | |
JP7176633B2 (ja) | 仮想化基盤制御装置、仮想化基盤制御方法および仮想化基盤制御プログラム | |
WO2013145004A1 (ja) | 情報処理装置、情報処理方法および情報処理システム | |
US11461131B2 (en) | Hosting virtual machines on a secondary storage system | |
JP2014206805A (ja) | 制御装置 | |
US10097431B1 (en) | Routing to tenant services utilizing a service directory | |
CN115576681A (zh) | 利用硬件拓扑提示在容器编排***中进行调度 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20170615 |