特許 7571083 負荷分散装置、負荷分散システム、および、負荷分散方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-10-11

(45)【発行日】2024-10-22

(54)【発明の名称】負荷分散装置、負荷分散システム、および、負荷分散方法

(51)【国際特許分類】

   G06F 9/50 20060101AFI20241015BHJP

【ＦＩ】

G06F9/50 150D

【請求項の数】 15

(21)【出願番号】P 2022099262

(22)【出願日】2022-06-20

(65)【公開番号】P2024000460

(43)【公開日】2024-01-05

【審査請求日】2023-01-06

(73)【特許権者】

【識別番号】000005108

【氏名又は名称】株式会社日立製作所

(74)【代理人】

【識別番号】110001689

【氏名又は名称】青稜弁理士法人

(72)【発明者】

【氏名】宮崎 星冬

【審査官】三坂 敏夫

(56)【参考文献】

【文献】特表２０１７－５３４１０７（ＪＰ，Ａ）

【文献】国際公開第２０２２／１０３６８９（ＷＯ，Ａ１）

【文献】特表２０１８－５１２０８７（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／４５５－９／５４

(57)【特許請求の範囲】

【請求項1】

コンテナ基盤のノードにコンテナをデプロイするスケジュール機構と、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得するスケール機構と、
を備え、
前記スケール機構は、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、
前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
前記スケジュール機構は、
コンテナのデプロイ要求に基づいて、前記コンテナ基盤に前記コンテナをデプロイ可能であるかどうかについて判定し、
前記コンテナをデプロイ可能であると判定した場合、前記コンテナを前記コンテナ基盤にデプロイし、
前記コンテナをデプロイ可能でないと判定した場合、コンテナの外部リソースへのデプロイの可否を判定し、前記コンテナを前記外部リソースにデプロイ可能であると判定した場合、前記コンテナを前記外部リソースにデプロイする、
ことを特徴とする負荷分散装置。

【請求項2】

請求項１に記載の負荷分散装置であって、
前記スケール機構は、
開発環境においてＣＩ／ＣＤパイプラインからデプロイ予定のコンテナに関する情報を取得する、
ことを特徴とする負荷分散装置。

【請求項3】

請求項２に記載の負荷分散装置であって、
前記情報は、コンテナの識別情報、コンテナの用途、処理の優先度、および、アフィニティルールをさらに含む、
ことを特徴とする負荷分散装置。

【請求項4】

請求項１に記載の負荷分散装置であって、
前記スケール機構は、
本番環境におけるリソースの需給予測、および、前記コンテナ基盤のＣＰＵとメモリのリソースの情報に基づいて、前記コンテナ基盤のスケール判断を行い、前記需給予測に応じたリソースを準備する、
ことを特徴とする負荷分散装置。

【請求項5】

コンテナを格納するノードを複数有するコンテナ基盤と、
前記コンテナ基盤に接続され、前記コンテナ基盤のノードにコンテナをデプロイする負荷分散装置と、
を備え、
前記負荷分散装置は、
プロセッサと、記憶部と、を備え、
前記プロセッサは、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得し、取得した前記のリソースの情報を前記記憶部に格納し、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、取得した前記情報を前記記憶部に格納し、
前記記憶部に格納された前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
コンテナのデプロイ要求に基づいて、前記コンテナ基盤に前記コンテナをデプロイ可能であるかどうかについて判定し、
前記コンテナをデプロイ可能であると判定した場合、前記コンテナを前記コンテナ基盤にデプロイし、
前記コンテナをデプロイ可能でないと判定した場合、コンテナの外部リソースへのデプロイの可否を判定し、前記コンテナを前記外部リソースにデプロイ可能であると判定した場合、前記コンテナを前記外部リソースにデプロイする、
ことを特徴とする負荷分散システム。

【請求項6】

プロセッサと、記憶部と、を備え、コンテナ基盤のノードにデータをデプロイする負荷分散装置を用いて行う負荷分散方法であって、
前記プロセッサは、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得し、取得した前記のリソースの情報を前記記憶部に格納し、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、取得した前記情報を前記記憶部に格納し、
前記記憶部に格納された前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
コンテナのデプロイ要求に基づいて、前記コンテナ基盤に前記コンテナをデプロイ可能であるかどうかについて判定し、
前記コンテナをデプロイ可能であると判定した場合、前記コンテナを前記コンテナ基盤にデプロイし、
前記コンテナをデプロイ可能でないと判定した場合、コンテナの外部リソースへのデプロイの可否を判定し、前記コンテナを前記外部リソースにデプロイ可能であると判定した場合、前記コンテナを前記外部リソースにデプロイする、
ことを特徴とする負荷分散方法。

【請求項7】

請求項６に記載の負荷分散方法をプロセッサに実行させるプログラム。

【請求項8】

コンテナ基盤のノードにコンテナをデプロイするスケジュール機構と、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得するスケール機構と、
を備え、
前記スケール機構は、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、
前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて、前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
前記コンテナ基盤のリソースの判定では、
ＣＰＵについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｃ）と、
前記値（Ａｃ）の今回値から前回値を引くことにより計算した値（ΔＡｃ）と、
デプロイするコンテナの要求値（Ｂｃ）と、
残す空きリソースの閾値（Ｈｃ）と、
許容する空きリソースの閾値（Ｐｃ）と、
メモリについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｍ）と、
前記値（Ａｍ）の今回値から前回値を引くことにより計算した値（ΔＡｍ）と、
デプロイするコンテナの要求値（Ｂｍ）と、
残す空きリソースの閾値（Ｈｍ）と、
許容する空きリソースの閾値（Ｐｍ）と、
を用いた判定を行い、
（Ａｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｍ）－（Ｂｍ）＜（Ｈｍ）、又は、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＜（Ｈｍ）の場合に、前記コンテナ基盤のリソースが不足していることを判定し、
（Ａｃ）－（Ｂｃ）＞（Ｐｃ）、且つ、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＞（Ｐｃ）、又は、（Ａｍ）－（Ｂｍ）＞（Ｐｍ）、且つ、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＞（Ｐｍ）の場合に、前記コンテナ基盤のリソースが過剰であることを判定する、
ことを特徴とする負荷分散装置。

【請求項9】

請求項８に記載の負荷分散装置であって、
前記スケール機構は、
開発環境においてＣＩ／ＣＤパイプラインからデプロイ予定のコンテナに関する情報を取得する、
ことを特徴とする負荷分散装置。

【請求項10】

請求項９に記載の負荷分散装置であって、
前記情報は、コンテナの識別情報、コンテナの用途、処理の優先度、および、アフィニティルールをさらに含む、
ことを特徴とする負荷分散装置。

【請求項11】

請求項８に記載の負荷分散装置であって、
前記スケール機構は、
本番環境におけるリソースの需給予測、および、前記コンテナ基盤のＣＰＵとメモリのリソースの情報に基づいて、前記コンテナ基盤のスケール判断を行い、前記需給予測に応じたリソースを準備する、
ことを特徴とする負荷分散装置。

【請求項12】

請求項８に記載の負荷分散装置であって、
前記スケジュール機構は、
コンテナのデプロイ要求に基づいて、前記コンテナ基盤に前記コンテナをデプロイ可能であるかどうかについて判定し、
前記コンテナをデプロイ可能であると判定した場合、前記コンテナを前記コンテナ基盤にデプロイし、
前記コンテナをデプロイ可能でないと判定した場合、コンテナの外部リソースへのデプロイの可否を判定し、前記コンテナを前記外部リソースにデプロイ可能であると判定した場合、前記コンテナを前記外部リソースにデプロイする、
ことを特徴とする負荷分散装置。

【請求項13】

コンテナを格納するノードを複数有するコンテナ基盤と、
前記コンテナ基盤に接続され、前記コンテナ基盤のノードにコンテナをデプロイする負荷分散装置と、
を備え、
前記負荷分散装置は、
プロセッサと、記憶部と、を備え、
前記プロセッサは、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得し、取得した前記のリソースの情報を前記記憶部に格納し、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、取得した前記情報を前記記憶部に格納し、
前記記憶部に格納された前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
前記コンテナ基盤のリソースの判定では、
ＣＰＵについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｃ）と、
前記値（Ａｃ）の今回値から前回値を引くことにより計算した値（ΔＡｃ）と、
デプロイするコンテナの要求値（Ｂｃ）と、
残す空きリソースの閾値（Ｈｃ）と、
許容する空きリソースの閾値（Ｐｃ）と、
メモリについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｍ）と、
前記値（Ａｍ）の今回値から前回値を引くことにより計算した値（ΔＡｍ）と、
デプロイするコンテナの要求値（Ｂｍ）と、
残す空きリソースの閾値（Ｈｍ）と、
許容する空きリソースの閾値（Ｐｍ）と、
を用いた判定を行い、
（Ａｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｍ）－（Ｂｍ）＜（Ｈｍ）、又は、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＜（Ｈｍ）の場合に、前記コンテナ基盤のリソースが不足していることを判定し、
（Ａｃ）－（Ｂｃ）＞（Ｐｃ）、且つ、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＞（Ｐｃ）、又は、（Ａｍ）－（Ｂｍ）＞（Ｐｍ）、且つ、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＞（Ｐｍ）の場合に、前記コンテナ基盤のリソースが過剰であることを判定する、
ことを特徴とする負荷分散システム。

【請求項14】

プロセッサと、記憶部と、を備え、コンテナ基盤のノードにデータをデプロイする負荷分散装置を用いて行う負荷分散方法であって、
前記プロセッサは、
前記コンテナ基盤からＣＰＵとメモリのリソースの情報を取得し、取得した前記のリソースの情報を前記記憶部に格納し、
前記コンテナ基盤にデプロイするコンテナに関するＣＰＵ要求値とメモリ要求値を含む情報を取得し、取得した前記情報を前記記憶部に格納し、
前記記憶部に格納された前記のＣＰＵとメモリのリソースの情報と、取得したＣＰＵ要求値およびメモリ要求値と、に基づいて前記コンテナ基盤のリソースを判定し、前記リソースが過剰であると判定した場合に前記コンテナ基盤のノードを削除し、前記リソースが不足していると判定した場合に前記コンテナ基盤のノードを追加し、
前記コンテナ基盤のリソースの判定では、
ＣＰＵについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｃ）と、
前記値（Ａｃ）の今回値から前回値を引くことにより計算した値（ΔＡｃ）と、
デプロイするコンテナの要求値（Ｂｃ）と、
残す空きリソースの閾値（Ｈｃ）と、
許容する空きリソースの閾値（Ｐｃ）と、
メモリについて、
ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、さらに、グループ内の各ノードについての該差の合計を計算した値（Ａｍ）と、
前記値（Ａｍ）の今回値から前回値を引くことにより計算した値（ΔＡｍ）と、
デプロイするコンテナの要求値（Ｂｍ）と、
残す空きリソースの閾値（Ｈｍ）と、
許容する空きリソースの閾値（Ｐｍ）と、
を用いた判定を行い、
（Ａｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＜（Ｈｃ）、（Ａｍ）－（Ｂｍ）＜（Ｈｍ）、又は、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＜（Ｈｍ）の場合に、前記コンテナ基盤のリソースが不足していることを判定し、
（Ａｃ）－（Ｂｃ）＞（Ｐｃ）、且つ、（Ａｃ）＋（ΔＡｃ）－（Ｂｃ）＞（Ｐｃ）、又は、（Ａｍ）－（Ｂｍ）＞（Ｐｍ）、且つ、（Ａｍ）＋（ΔＡｍ）－（Ｂｍ）＞（Ｐｍ）の場合に、前記コンテナ基盤のリソースが過剰であることを判定する、
ことを特徴とする負荷分散方法。

【請求項15】

請求項１４に記載の負荷分散方法をプロセッサに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、負荷分散装置、負荷分散システム、および、負荷分散方法に関する。

【背景技術】

【0002】

複数のコンテナがデプロイされ、限られたハードウェアリソースを共有する環境がある。そして、当該環境では、ハードウェアリソースを効率良く利用することで、コストの抑制とサービスの負荷に合わせた対応とを両立したいというニーズが存在する。

【0003】

ここで、特許文献１は、クラスターリソースを効率的に割り当てる技術を開示する。すなわち、特許文献１は、クラスターリソース割り当て要請が入力されれば、クラウドプラットフォームシステムがサービスグループ情報を生成する段階と、前記サービスグループの使用者を追加／削除する段階と、前記サービスグループの使用者に割り当てるクラスターが選択されて割り当て情報が入力される段階と、クラスター資源可用量を問い合わせする段階と、前記資源可用量問い合わせ結果資源が使用可能ならば、前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、前記資源可用量問い合わせ結果資源が不足ならば、クラスター資源が加えられるかを確認する段階と、前記クラスター資源が追加できれば、前記クラスター資源を追加登録する段階と、前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、及び前記クラスター資源が追加できなければ、可用クラスターを再選択する段階と、を含むクラウドプラットフォームでのクラスターリソース割り当て及び管理方法を開示する。

【0004】

また、特許文献２は、監視状況が異なるリソースの監視情報からＩＴサービスに必要なリソースキャパシティを精度よく予測する技術を開示する。すなわち、特許文献２は、ログ信頼度算出手段と、リソース使用率推移推定手段と、を備えるリソースキャパシティ予測装置を開示する。ログ信頼度算出手段は、コンピュータから、リソースの監視状況に関する第一のログを取得し、第一のログに含まれるコンピュータの複数の時刻における監視状況の情報に基づいて、複数の時刻におけるログの信頼度を算出する。リソース使用率推移推定手段は、コンピュータから、リソースの使用に関する第二のログおよびコンピュータのサービスレベル項目の測定に関する第三のログを取得し、第二のログに含まれるコンピュータの複数の時刻におけるリソースの使用率の情報と、第三のログに含まれるコンピュータの複数の時刻におけるサービスレベル項目の測定値の情報と、複数の時刻におけるログの信頼度とに基づいて、コンピュータのリソースの使用率を推定する。

【先行技術文献】

【特許文献】

【0005】

【文献】特表２０２１－５３０８０１号公報

【文献】特開２０１３－１７５０８５号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

特許文献１および２の技術を用いることで、コンテナをデプロイするコンテナ基盤のリソースを管理することができることが考えられる。

【0007】

しかしながら、コンテナのスケールは迅速に可能であるが、コンテナ基盤においてそのリソース基盤となるノードの処理に時間がかかることで、例えば、コンテナ基盤の稼働率が高い状態でノードを追加する場合に、コンテナをデプロイする処理に遅延が発生することや、利用者へのサービス提供に悪影響が発生する可能性がある。その一方で、こうした事情を踏まえてリソースに余裕を持たせる場合、稼働していないリソース対してコストの無駄が発生する。

【0008】

そこで、本発明は、デプロイの処理遅延の発生やサービス提供の悪影響を抑制しつつ、未利用リソースに伴うコスト削減を行うことで、利用者の利便性の確保を図りつつ、経済的な観点で貢献することができる負荷分散装置、負荷分散システム、負荷分散方法を提供することを目的とする。

【課題を解決するための手段】

【0009】

本発明の第１の態様によれば、下記の負荷分散装置が提供される。この負荷分散装置は、スケジュール機構と、スケール機構と、を備える。スケジュール機構は、コンテナ基盤のノードにコンテナをデプロイする。スケール機構は、コンテナ基盤からリソースの情報を取得する。また、スケール機構は、コンテナ基盤にデプロイするコンテナに関する外部情報を取得する。スケール機構は、前記のリソースの情報と前記外部情報に基づいてコンテナ基盤のリソースを判定し、リソースが過剰であると判定した場合にコンテナ基盤のノードを削除し、リソースが不足していると判定した場合にコンテナ基盤のノードを追加する。

【0010】

本発明の第２の態様によれば、下記の負荷分散システムが提供される。この負荷分散システムは、コンテナを格納するノードを複数有するコンテナ基盤と、コンテナ基盤に接続され、コンテナ基盤のノードにコンテナをデプロイする負荷分散装置と、を備える。この負荷分散装置は、プロセッサと、記憶部と、を備える。プロセッサは、コンテナ基盤からリソースの情報を取得し、取得した前記のリソースの情報を記憶部に格納し、コンテナ基盤にデプロイするコンテナに関する外部情報を取得し、取得した前記外部情報を記憶部に格納する。プロセッサは、記憶部に格納されたリソースの情報と外部情報に基づいてコンテナ基盤のリソースを判定し、リソースが過剰であると判定した場合にコンテナ基盤のノードを削除し、リソースが不足していると判定した場合にコンテナ基盤のノードを追加する。

【0011】

本発明の第３の態様によれば、下記の負荷分散方法が提供される。この負荷分散方法は、プロセッサと、記憶部と、を備え、コンテナ基盤のノードにデータをデプロイする負荷分散装置を用いて行う方法である。プロセッサは、コンテナ基盤からリソースの情報を取得し、取得した前記のリソースの情報を記憶部に格納し、コンテナ基盤にデプロイするコンテナに関する外部情報を取得し、取得した前記外部情報を記憶部に格納し、記憶部に格納された前記のリソースの情報と前記外部情報に基づいてコンテナ基盤のリソースを判定し、リソースが過剰であると判定した場合にコンテナ基盤のノードを削除し、リソースが不足していると判定した場合にコンテナ基盤のノードを追加する。

【発明の効果】

【0012】

本発明によれば、デプロイの処理遅延の発生やサービス提供の悪影響を抑制しつつ、未利用リソースに伴うコスト削減を行うことで、利用者の利便性の確保を図りつつ、経済的な観点で貢献することができる負荷分散装置、負荷分散システム、負荷分散方法が提供される。なお、上記した以外の課題、構成および効果は、以下の発明を実施するための形態の説明により明らかにされる。

【図面の簡単な説明】

【0013】

【図1】負荷分散装置の処理の一例の概要を示す図である。

【図2】負荷分散装置を開発環境のＣＩ／ＣＤパイプラインと組み合わせて適用する例の概要を示す図である。

【図3】負荷分散装置を開発環境のＣＩ／ＣＤパイプラインと組み合わせて適用する例の概要を示す図である。

【図4】負荷分散装置の構成の一例を示す図である。

【図5】スケジュール機構の処理の一例を示すフローチャートである。

【図6】スケール機構の処理の一例を示すフローチャートである。

【図7】ＣＩ／ＣＤパイプラインから取得する情報の一例を示す図である。

【図8A】スケール判定の一例を示すフローチャートである。

【図8B】図８Ａの続きであり、スケール判定の一例を示すフローチャートである。

【図9】ノードグループに関して取得する情報の一例を示す図である。

【図10】ノードグループに関して取得する情報であって、前回値と今回値の一例を示す図である。

【図11】ノードの追加時における処理の一例を示すフローチャートである。

【図12】ノードの削除時における処理の一例を示すフローチャートである。

【図13】（Ａ）と（ΔＡ）の計算結果の一例を示す図である。

【図14】スケール判定結果の一例を示す図である。

【図15】余剰リソースコストの計算結果の一例を示す図である。

【図16】システム全体のハードウェア構成例を示す図である。

【発明を実施するための形態】

【0014】

以下、図面を参照して本発明の実施形態を説明する。実施形態は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施することが可能である。
各種情報の例として、「テーブル」、「リスト」、「キュー」等の表現にて説明することがあるが、各種情報はこれら以外のデータ構造で表現されてもよい。例えば、「ＸＸテーブル」、「ＸＸリスト」、「ＸＸキュー」等の各種情報は、「ＸＸ情報」としてもよい。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。

【0015】

まず、図１－図３を参照しながら、本実施形態の負荷分散装置の処理例の概要について説明する。負荷分散装置１１は、コンテナ基盤２１のリソースを管理することができる。すなわち、図１に示すように、例えば、コンテナ基盤２１のリソースが不足しており、コンテナ基盤２１にコンテナをデプロイできない場合、負荷分散装置１１はコンテナ基盤２１のノードを追加する制御を行う。ここで、負荷分散装置１１は、コンテナ基盤２１からの情報に加えて外部情報を取得し、その情報に基づいて、ノードを追加する制御を行う。なお、外部情報は、コンテナ基盤２１にデプロイするコンテナに関する情報であり、環境の用途に応じた情報（例えば、開発環境であればＣＩジョブの状況に関する情報）である。そして、コンテナ基盤２１にノードが新たに追加された場合、負荷分散装置１１は、コンテナ基盤２１（この例では、追加されたノード）にコンテナをデプロイする。なお、状況に応じて外部リソース３１を利用する場合がある。また、図１等では、「高」、「中」、「小」により、処理の優先度を表現している。

【0016】

次に、図２－図３を参照しながら、負荷分散装置１１を開発環境のＣＩ／ＣＤパイプラインと組み合わせて適用する例について説明する。図２に示すように、開発者がコードをプッシュし、ＣＩ／ＣＤパイプラインがスタートした場合、コンテナイメージがＣＩ／ＣＤパイプラインにて生成（ビルド）される。ここで、負荷分散装置１１は、パイプラインの開始を検知し、コンテナに関する外部情報を取得する。そして、デプロイするコンテナの生成時に（すなわち、ビルドステージにおけるビルドの継続中に）、負荷分散装置１１は、コンテナ基盤２１からの情報と外部情報に応じて、コンテナ基盤２１におけるノードを追加する制御を行う。その後、負荷分散装置１１は、ビルドされたコンテナイメージをコンテナ基盤２１にデプロイし、コードを検証するテスト（テストステージ）が開始される。

【0017】

次に、図４を参照しながら、負荷分散装置の構成例について説明する。図４は、負荷分散装置の構成の一例を示す図である。図４に示すように、負荷分散装置１１は、スケール機構１７と、スケジュール機構１８と、をプログラムモジュールとして備え、負荷分散装置１１では、スケール機構１７とスケジュール機構１８が連携して処理を行う。スケール機構１７は、コンテナ基盤２１のリソース使用状況と外部情報に基づいて、スケールを行う。すなわち、スケール機構１７は、コンテナ基盤２１のリソースに応じたスケールアウト／イン判断を行う。スケジュール機構１８は、デプロイ指示があった各コンテナについて、記載された要求を基にして、コンテナ基盤２１もしくは外部リソース３１へのデプロイ判断を行う。

【0018】

次に、図５を参照しながら、スケジュール機構の処理の一例について説明する。図５は、スケジュール機構の処理の一例を示すフローチャートである。なお、図５の例において、外部との情報の入出力が破線で示されている。この例では、開発環境における一連の処理の流れで説明する。すなわち、上記したように、開発者がコードをプッシュし、ＣＩ／ＣＤパイプラインがスタートし、コンテナイメージのビルドが開始する。そして、ビルドが完了した後に、負荷分散装置に、デプロイ要求（デプロイ指示）が入力される。そして、デプロイ完了後にテストが実行され、ＣＩ／ＣＤパイプラインが終了する。

【0019】

スケジュール機構１８は、コンテナデプロイの要求を受け付ける（Ｓ５０１）。また、スケジュール機構１８は、未スケジュールのコンテナがあるか（すなわち、まだ処理していないコンテナがあるか）を判定する（Ｓ５０２）。ここで、未スケジュールのコンテナがある場合、スケジュール機構１８は、デプロイするコンテナのリソースがコンテナ基盤２１にあり、このコンテナをデプロイ可能であるかについて判定する（Ｓ５０３）。そして、デプロイ可能である場合、スケジュール機構は、このコンテナをデプロイする（Ｓ５０４）。

【0020】

その一方で、デプロイ可能でないと判定した場合、スケジュール機構１８は、スケール機構１７にその旨を通知し（Ｓ５０５）、コンテナ基盤２１において退避可能なコンテナがあるかどうかについて判定する（Ｓ５０６）。退避可能なコンテナがあると判定した場合、スケジュール機構１８は、このコンテナを退避させ（Ｓ５０７）、未スケジュールのコンテナをデプロイする（Ｓ５０４）。退避可能なコンテナがないと判定した場合、スケジュール機構１８は、未スケジュールのコンテナの情報に基づいて、外部リソース３１が利用可能であるかどうかを判定する（Ｓ５０８）。スケジュール機構１８は、外部リソース３１が利用可能であると判定した場合に未スケジュールのコンテナを外部リソース３１にデプロイする（Ｓ５０９）。その一方で、外部リソースが利用可能でないと判定した場合に、スケジュール機構１８は未スケジュールのコンテナをキューに戻す（Ｓ５１０）。

【0021】

なお、デプロイ要求には、コンテナが必要とするリソース（ＣＰＵ，メモリ，永続ストレージ）等の記載がある。この要求によっては、特定のノードにしかデプロイできないコンテナも発生しうる（例えば、永続ストレージとして作成済みのＡＷＳ ＥＢＳを利用している場合、ＥＢＳが所在するＡＺ以外にデプロイできない）が、スケジュール機構１８は、このような情報も踏まえて判断を行う。

【0022】

また、スケジュール機構１８は、外部リソース３１が利用可能であるかについて適宜に判断する。例えば、デプロイ予定のコンテナ（すなわち、未スケジュールのコンテナ）が他のコンテナと通信しない場合（例えば、単体テストの場合）、必ずしもクラスターにデプロイされる必要はないため、スケジュール機構１８は、外部リソース３１を利用可能と判断する。その一方で、デプロイ予定のコンテナが他のコンテナと依存関係を持つ場合、異なる場所にデプロイすると動作しないため、スケジュール機構１８は、外部リソース３１を利用不可と判断する。

【0023】

次に、図６を参照しながら、スケール機構の処理の一例について説明する。図６は、スケール機構の処理の一例を示すフローチャートである。なお、図６の例において、外部との情報の入出力が破線で示されている。この例でもスケジュール機構の場合と同様に、開発環境における一連の処理の流れで説明する。

【0024】

スケール機構１７は、コンテナ基盤２１の状態を監視する（Ｓ６０１）。また、スケール機構１７は、ＣＩ／ＣＤパイプラインの情報を取得する（Ｓ６０２）。そして、スケール機構１７は、コンテナ基盤２１のリソースが必要十分であるかどうかについて判定する（Ｓ６０３）。ここで、コンテナ基盤２１のリソースが過剰であると判定した場合、スケール機構１７は、コンテナ基盤２１におけるノードの削除を指示する（Ｓ６０４）。その一方で、コンテナ基盤２１のリソースが不足であると判定した場合、スケール機構１７は、コンテナ基盤２１におけるノードの追加を指示する（Ｓ６０５）。スケール機構１７は、コンテナ基盤２１のリソースが必要十分であると判定した場合、スケール（すなわち、ノードの追加あるいは削除）を行わない。そして、スケール機構１７は、一定時間待機し（Ｓ６０６）、処理を繰り返す。

【0025】

スケール機構１７は、スケジュール機構１８からのコンテナデプロイ不可の通知やＣＩ／ＣＤパイプラインの開始の通知に基づいて、上記のスケール判定を行う。なお、スケール判定の詳細については後述する。

【0026】

次に、図７を参照しながら、スケール機構１７が外部情報として取得するＣＩ／ＣＤパイプラインの情報の一例について説明する。図７は、ＣＩ／ＣＤパイプラインから取得する情報の一例を示す図である。ＣＩ／ＣＤパイプラインからは、デプロイ予定のコンテナの要求リソース、種類、用途（バッチ処理ｏｒサーバー）、優先度、および依存関係を取得する。なお、これらの情報は、デプロイ要求に記載されていることがほとんどであり、アプリケーションのソースコードと同様にレポジトリで管理されていることを想定している。

【0027】

図７に示すように、ＣＩ／ＣＤパイプラインの情報は、一例として、コンテナ名（コンテナの識別情報）と、用途（コンテナの用途）と、レプリカ数と、ＣＰＵリクエスト値（コンテナの要求リソース）と、メモリリクエスト値（コンテナの要求リソース）と、優先度（処理の優先度）と、アフィニティルールと、を含む。そして、この例では、この情報は、コンテナごとにまとめられている。レプリカ数は、クラスターに保管したいデータのコピーの数を示す。ＣＰＵリクエスト値は、ＣＰＵ（この例では、ＣＰＵのコア）のリクエスト値であり、メモリリクエスト値は、メモリのリクエスト値である。優先度は、コンテナを処理する優先度を示す。この例では、負荷分散装置１１は、優先度がプラスに大きいコンテナを優先的に処理する。従って、負荷分散装置１１は、コンテナＣを優先的に処理し、次いでコンテナＡを処理し、その次にコンテナＢの処理を行う。アフィニティルールは、制約条件を示す。この例では、ＡＺ（可用性ゾーン）に関する記載があり、コンテナＣの「ＡＺ－１に限る」により、コンテナＣはＡＺ－１のノードにデプロイされる条件を定めている。このように、アフィニティルールを設定することで、依存関係の条件を有するコンテナの処理が可能となる。

【0028】

次に、図８Ａと図８Ｂを参照しながら、スケール判定の一例について説明する。図８Ａと図８Ｂは、スケール判定の一例を示すフローチャートである。なお、ここでは、図７で示すデータが取得された場合のスケール判定について説明する。従って、優先度が高いコンテナＣに基づくスケール判定の一例を説明する。

【0029】

先ず、スケール機構１７は、事前設定した閾値を取得する（Ｓ８０１）。すなわち、スケール機構１７は、閾値Ｈおよび閾値Ｐを取得する。ここで、閾値Ｈは、最低限残す空きリソースを定める。閾値Ｐは、許容する空きリソースを定め、１以上のノード分のリソースが存在するように設定される。なお、本明細書において、閾値Ｈを（Ｈ）、閾値Ｐを（Ｐ）で示すことがある。

【0030】

次に、スケール機構１７は、コンテナ基盤２１からノードグループの一覧を取得し、デプロイ要求を満たせないノードグループを除外する（Ｓ８０２）。スケール機構１７は、例えば、アフィニティルールに基づいて、デプロイ要求を満たせないノードグループを除外する。コンテナＣに基づくスケール判定では、「ＡＺ－１に限る」という条件が存在するので、スケール機構１７は、ＡＺ－１と異なるノードグループを除外する。

【0031】

ここで、図９を参照しながら、コンテナ基盤から取得する情報の一例について説明する。図９は、ノードグループに関して取得する情報の一例である。

【0032】

図９の例では、それぞれのノードグループ別（♯１～６）に情報が格納される。この情報には、ノードグループの可用性ゾーンと、ノードグループにおける１ノードのＣＰＵ量と、ノードグループにおける１ノードのメモリ量と、現在のノード数と、最小ノード数と、最大ノード数と、ノードコストと、が含まれる。

【0033】

従って、スケール機構１７が図９で示す情報を用いてコンテナＣに基づくスケール判定を行う場合では、スケール機構１７は、アフィニティルールにより「ＡＺ－２」と「ＡＺ－３」に関するノードグループ（♯２、３、５、６）を除外し、処理を進める。

【0034】

次に、スケール機構１７は、１ノードのＣＰＵ量、１ノードのメモリ量、現在のノード数、上限（最大ノード数）、下限（最小ノード数）を取得する（Ｓ８０３）。なお、この例では、スケール機構は、コンテナＣに基づくスケール判定において、ノードグループ（♯１、４）のデータを取得する。

【0035】

本明細書の説明において、各ノードグループをＧ１，Ｇ２・・・で示すことがある。また、ノードグループごとの１ノード当たりのＣＰＵ量をＣ１，Ｃ２・・・で示し、ノードグループごとの１ノード当たりのメモリ量をＭ１，Ｍ２・・・で示し、ノードグループごとの現在のノード数をＤ１，Ｄ２・・・で示し、ノードグループごとの最大ノード数をＵ１，Ｕ２・・・で示し、ノードグループごとの最小ノード数をＬ１，Ｌ２・・・で示し、ノードグループごとの１ノード当たりのノードコストをＹ１，Ｙ２・・・で示すことがある。

【0036】

次に、スケール機構１７は、コンテナ基盤２１の空きリソース（Ａ）を計算する（Ｓ８０４）。ここで、スケール機構１７は、ＣＰＵおよびメモリについて、ノードのリソースと、コンテナの要求値の合計または直近における実使用量の平均のうちで大きい方の値との差を計算し、各ノードについての該差の合計を（Ａ）として計算する。すなわち、スケール機構１７は、各ノードのＣＰＵ/メモリについて、ノードのリソース－ＭＡＸ（コンテナの要求値の合計，直近における実使用量の平均）を計算し、その合計を（Ａ）として計算する。なお、この例では、スケール機構１７は、ノードグループ♯１とノードグループ♯４に関する計算を行う。

【0037】

図１０を参照しながら、（Ａ）の計算の一例について説明する。図１０は、ノードに関して取得する情報であって、前回値と今回値の一例を示す図である。図１０の例では、ノードグループごとに、１ノードのＣＰＵおよびメモリのリソースに対する、リクエスト合計（すなわち、コンテナの要求値の合計）と、使用量（実使用量の平均）が格納されている。

【0038】

ノードグループ♯１の場合、前回値と今回値のＣＰＵのリクエスト合計が３．９０であり、前回値のＣＰＵの使用量が２．０５であり、今回値のＣＰＵの使用量が１．０５である。また、前回値と今回値のメモリのリクエスト合計が７．５であり、前回値のメモリの使用量が７．６であり、今回値のメモリの使用量が７．０である。

【0039】

従って、スケール機構１７は、前回のノードグループ♯１におけるノードのＣＰＵおよびメモリの空きリソースの計算において、ＣＰＵ量を３．９０とし、メモリ量を７．６として計算する。また、スケール機構１７は、今回のノードグループ♯１におけるノードのＣＰＵおよびメモリの空きリソースの計算において、ＣＰＵ量を３．９０とし、メモリ量を７．５として計算する。

【0040】

また、ノードグループ♯４の場合、前回値と今回値のＣＰＵのリクエスト合計が３．９０であり、前回値と今回値のＣＰＵの使用量が３．２５である。また、前回値と今回値のメモリのリクエスト合計が１５．５であり、前回値のメモリの使用量が１５．４であり、今回値のメモリの使用量が１５．０である。

【0041】

従って、スケール機構１７は、前回のノードグループ♯４におけるノードのＣＰＵおよびメモリの空きリソースの計算において、ＣＰＵ量を３．９０とし、メモリ量を１５．５として計算する。また、スケール機構１７は、今回のノードグループ♯４におけるノードのＣＰＵおよびメモリの空きリソースの計算において、ＣＰＵ量を３．９０とし、メモリ量を１５．５として計算する。

【0042】

次に、スケール機構１７は、（Ａ）の傾向である（ΔＡ）を計算する（Ｓ８０５）。スケール機構１７は、（ΔＡ）を（Ａ）の今回値から（Ａ）の前回値を引くことにより計算する。

【0043】

次に、スケール機構１７は、デプロイ予定のコンテナのリソース要求値を算出する（Ｓ８０６）。なお、本明細書において、このリソース要求値を（Ｂ）で示すことがある。スケール機構１７は、デプロイ予定のコンテナに関する外部情報において、デプロイ要求にリソース要求値が指定されているかどうかについて確認する。そして、スケール機構１７は、デプロイ要求にリソース要求値が指定されている場合、このリソース要求値を抽出し、デプロイ要求にリソース要求値が指定されていない場合、名前空間のデフォルト値を取得する。

【0044】

そして、スケール機構１７は、ＣＰＵおよびメモリについて、（Ａ）、（ΔＡ）、（Ｂ）、（Ｈ）、（Ｐ）をもとに、スケール判定を行う（Ｓ８０７）。スケール機構１７は、（Ａ）－（Ｂ）＜（Ｈ）、又は、（Ａ）＋（ΔＡ）－（Ｂ）＜（Ｈ）の関係があることを判定した場合、ノード数を増やすノードグループを選択し（Ｓ８０８）、ノード追加指示を行う（Ｓ８０９）。なお、Ｓ８０８～Ｓ８０９の詳細は後述する。スケール機構１７は、（Ａ）－（Ｂ）＞（Ｐ）、且つ、（Ａ）＋（ΔＡ）－（Ｂ）＞（Ｐ）の関係があることを判定した場合、ノードの数を減らすノードグループを選択し（Ｓ８１０）、ノードの削除指示を行う（Ｓ８１１）。なお、Ｓ８１０～Ｓ８１１の詳細は後述する。これら以外の場合、スケール機構１７は、スケール（ノードの追加あるいは削除）を実施しない。

【0045】

図１１を参照しながら、Ｓ８０８～Ｓ８０９の処理の詳細について説明する。図１１は、ノードの追加時における処理の一例を示すフローチャートである。

【0046】

スケール機構１７は、ノードグループの１つを選択し（Ｓ１１０１）、このノードグループについて最大ノード数に達しているかどうかについて判定する（Ｓ１１０２）。なお、図１１において、Ｄｎはあるノードグループの現在のノード数を示し、Ｕｎは該ノードグループにおける最大ノード数を示している。そして、スケール機構１７は、最大ノード数に達していないことを判定した場合、１ノード追加時の余剰リソースを計算する（Ｓ１１０３）。スケール機構１７は、こうした処理を全ノードグループについて実行する。

【0047】

Ｓ１１０３における１ノード追加時の余剰リソースの計算について説明する。スケール機構１７は、ＣＰＵおよびメモリそれぞれについて計算する。

【0048】

スケール機構１７は、Ｘｃｎ＝Ａｃ＋ＭＩＮ（ΔＡｃ，０）＋Ｃｎ－Ｂｃの式に基づいて、ＣＰＵの余剰リソースを計算する。ここで、該式において、Ｘｃｎは、対象となるノードグループにおいて１ノード追加時のＣＰＵの余剰リソースを示す。Ａｃは、ＣＰＵに関する空きリソースを示す。ＭＩＮ（ΔＡｃ，０）は、ΔＡｃもしくは０のうちで小さい値を用いることを示し、ΔＡｃは、Ａｃの傾向を示す。ΔＡｃは、Ａｃの今回値からＡｃの前回値を引くことにより計算される。Ｃｎは、対象となるノードグループにおける１ノードのＣＰＵ量を示す。Ｂｃは、デプロイ予定のコンテナに関する外部情報に基づいたＣＰＵリクエスト値を示す。

【0049】

スケール機構１７は、Ｘｍｎ＝Ａｍ＋ＭＩＮ（ΔＡｍ，０）＋Ｍｎ－Ｂｍの式に基づいて、メモリの余剰リソースを計算する。ここで、該式において、Ｘｍｎは、対象となるノードグループにおいて１ノード追加時のメモリの余剰リソースを示す。Ａｍは、メモリに関する空きリソースを示す。ＭＩＮ（ΔＡｍ，０）は、ΔＡｍもしくは０のうちで小さい値を用いることを示し、ΔＡｍは、Ａｍの傾向を示す。ΔＡｍは、Ａｍの今回値からＡｍの前回値を引くことにより計算される。Ｍｎは、対象となるノードグループにおける１ノードのメモリ量を示す。Ｂｍは、デプロイ予定のコンテナに関する外部情報に基づいたメモリリクエスト値を示す。

【0050】

スケール機構１７は、全ノードグループを選択した後に、Ｘｃｎ＞Ｈｃ、且つ、Ｘｍｎ＞Ｈｍを満たすノードグループ（Ｇｎ）が存在するかどうかについて判定する（Ｓ１１０４）。ここで、Ｈｃは、（Ｈ）のＣＰＵに関する値を示し、Ｈｍは、（Ｈ）のメモリに関する値を示す。スケール機構１７は、上記の条件を満たすノードグループが存在することを判定した場合、余剰リソースコストが最小となるノードグループを選択する（Ｓ１１０５）。スケール機構１７は、上記の条件を満たすノードグループが存在しないことを判定した場合、不足リソースが最大となるノードグループを選択する（Ｓ１１０７）。

【0051】

Ｓ１１０５について詳しく説明する。スケール機構１７は、（（Ｘｃｎ－Ｈｃ）／Ｃｎ＋（Ｘｍｎ－Ｈｍ）／Ｍｎ）×Ｙｎが最小となるノードグループ（Ｇｘ）を選択する。ここで、Ｙｎは、あるノードグループのノードコストを示す。そして、スケール機構１７は、選択されたノードグループ（Ｇｘ）のノード数を１増加させる（Ｓ１１０６）。Ｓ１１０５では、ノード追加後の余剰リソースが追加するノードの何台分になるかをＣＰＵ、メモリそれぞれで計算し、その和にノードコストを掛けたものを計算値としている。この値が少ないほど、追加するノードが不足分にフィットしており、より余剰コストを削減できるということになる（例えば、ＣＰＵ不足ならＣＰＵが多いノードを、メモリ不足ならメモリが多いノードを入れるということになる）。

【0052】

Ｓ１１０７について詳しく説明する。スケール機構１７は、ＭＩＮ（（Ｘｃｎ－Ｈｃ）／Ｃｎ，（Ｘｍｎ－Ｈｍ）／Ｍｎ）が最大となるノードグループ（Ｇｘ）を選択する。そして、スケール機構１７は、選択されたノードグループ（Ｇｘ）のノード数を１増加させる（Ｓ１１０８）。Ｓ１１０７は、どのノードを１台追加してもリソース不足を解消できない場合に発生する。従って、ＭＩＮ関数の両引数は必ず負（すなわち、リソース不足）になる。ここで、リソース不足を解消できるノードを追加する際に、この負の値が０に近くなるほどリソース不足が解消されることになる。そこで、ＭＩＮ関数を通すことでＣＰＵ、メモリのうちより不足している方の値を採用し、その値を０に近づけるノードを追加する。

【0053】

Ｓ１１０８においてノードが追加された後にＳ１１０１に戻り、スケール機構１７は、別のノードをさらに追加する処理に移行する。なお、全ノードグループが最大ノード数に達している場合、スケール機構１７は、Ｓ１１０４において処理の終了を判定する。

【0054】

図１２を参照しながら、Ｓ８１０～Ｓ８１１の処理の詳細について説明する。図１２は、ノードの削除時における処理の一例を示すフローチャートである。

【0055】

スケール機構１７は、ノードグループの１つを選択し（Ｓ１２０１）、このノードグループについて最小ノード数に達しているかどうかについて判定する（Ｓ１２０２）。なお、図１２において、Ｄｎはあるノードグループの現在のノード数を示し、Ｌｎは該ノードグループにおける最小ノード数を示している。そして、スケール機構１７は、選択したノードグループにおいて最小ノード数以上のノードの存在を判定した場合、削除可能なノードが存在するかについて判定する（Ｓ１２０３）。

【0056】

Ｓ１２０３について詳しく説明する。ノード削除時には該当ノード上で動くコンテナの退避が発生する。基本的には、各コンテナはいつでも退避可能であるのが理想であるが、バッチ処理のコンテナ等、処理の中断が大きな影響をもたらすコンテナも存在する。こういったコンテナが動作していない＝削除可能と判定する。なお、退避不可のコンテナの指定方法については、自動で決定される方法（例えば、コンテナがシステム管理用コンテナとされること）と手動で決定される方法（例えば、ラベルの付与）が存在する。

【0057】

そして、スケール機構１７は、削除可能なノードの存在を判定した場合、１ノード削除時の余剰リソースを計算する（Ｓ１２０４）。スケール機構１７は、こうした処理を全ノードグループについて実行する。

【0058】

Ｓ１２０４における１ノード削除時の余剰リソースの計算について説明する。スケール機構１７は、ＣＰＵおよびメモリそれぞれについて計算する。

【0059】

スケール機構１７は、Ｘｃｎ＝Ａｃ＋ＭＩＮ（ΔＡｃ，０）－Ｃｎ－Ｂｃの式に基づいて、ＣＰＵの余剰リソースを計算する。ここで、該式において、Ｘｃｎは、対象となるノードグループにおいて１ノード削除時のＣＰＵの余剰リソースを示す。Ａｃは、ＣＰＵに関する空きリソースを示す。ＭＩＮ（ΔＡｃ，０）は、ΔＡｃもしくは０のうちで小さい値を用いることを示し、ΔＡｃは、Ａｃの傾向を示す。ΔＡｃは、Ａｃの今回値からＡｃの前回値を引くことにより計算される。Ｃｎは、対象となるノードグループにおける１ノードのＣＰＵ量を示す。Ｂｃは、デプロイ予定のコンテナに関する外部情報に基づいたＣＰＵリクエスト値を示す。

【0060】

スケール機構１７は、Ｘｍｎ＝Ａｍ＋ＭＩＮ（ΔＡｍ，０）－Ｍｎ－Ｂｍの式に基づいて、メモリの余剰リソースを計算する。ここで、該式において、Ｘｍｎは、対象となるノードグループにおいて１ノード削除時のメモリの余剰リソースを示す。Ａｍは、メモリに関する空きリソースを示す。ＭＩＮ（ΔＡｍ，０）は、ΔＡｍもしくは０のうちで小さい値を用いることを示し、ΔＡｍは、Ａｍの傾向を示す。ΔＡｍは、Ａｍの今回値からＡｍの前回値を引くことにより計算される。Ｍｎは、対象となるノードグループにおける１ノードのメモリ量を示す。Ｂｍは、デプロイ予定のコンテナに関する外部情報に基づいたメモリリクエスト値を示す。

【0061】

スケール機構１７は、全ノードグループを選択した後に、Ｘｃｎ＞Ｈｃ、且つ、Ｘｍｎ＞Ｈｍを満たすノードグループ（Ｇｎ）が存在するかどうかについて判定する（Ｓ１２０５）。ここで、Ｈｃは、（Ｈ）のＣＰＵに関する値を示し、Ｈｍは、（Ｈ）のメモリに関する値を示す。スケール機構１７は、上記の条件を満たすノードグループが存在することを判定した場合、余剰リソースコストが最小となるノードグループを選択する（Ｓ１２０６）。

【0062】

Ｓ１２０６について詳しく説明する。スケール機構１７は、（（Ｘｃｎ－Ｈｃ）／Ｃｎ＋（Ｘｍｎ－Ｈｍ）／Ｍｎ）×Ｙｎが最小となるノードグループ（Ｇｘ）を選択する。ここで、Ｙｎは、あるノードグループのノードコストを示す。そして、スケール機構１７は、選択されたノードグループ（Ｇｘ）のノード数を１減少させる（Ｓ１２０７）。Ｓ１２０６では、ノード削除後の余剰リソースが削除するノードの何台分になるかをＣＰＵ、メモリそれぞれで計算し、その和にノードコストを掛けたものを計算値としている。この値が少ないほど、削除するノードが余剰分にフィットしており、より余剰コストを削減できるということになる（例えば、ＣＰＵ過剰ならＣＰＵが多いノードを、メモリ過剰ならメモリが多いノードを外すということになる）。

【0063】

Ｓ１２０７においてノードを減少させた後に、スケール機構１７は、未だリソースが余剰であるかについて判定する（Ｓ１２０８）。リソースが余剰であると判定した場合にＳ１２０１に戻り、スケール機構１７は、別のノードをさらに減少させる処理に移行する。なお、Ｓ１２０８では、Ｘｃｘ＞Ｐｃ、且つ、Ｘｍｘ＞Ｐｍを満たすかどうかの判定を行う。ここで、Ｘｃｘは、Ｓ１２０７で処理したノードグループについて、１ノード削除時のＣＰＵの余剰リソースを示す。Ｘｍｘは、Ｓ１２０７で処理したノードグループについて、１ノード削除時のメモリの余剰リソースを示す。ＰｃはＣＰＵに関する（Ｐ）を示し、Ｐｍはメモリに関する（Ｐ）を示す。

【0064】

次に、図１３－図１５を参照しながら、スケール機構の動作例について説明する。この例では、外部情報として図７に示す情報を取得し、コンテナ基盤の情報に関して図９および図１０に示す情報を取得した場合について説明する。

【0065】

先ず、スケール機構１７は、一番優先度が高いコンテナＣの処理を実行する。ここで、コンテナＣに関するアフィニティルールが参照され、アフィニティルールを満たす処理が行われる。

【0066】

スケール機構１７は閾値を取得する。ここでは、Ｈｃ＝０、Ｈｍ＝０、Ｐｃ＝４、Ｐｍ＝８（ＧＢ）とする。

【0067】

スケール機構１７は、ノードグループの一覧に関する情報（ここでは、図９および図１０に示す情報）をコンテナ基盤２１から取得する。スケール機構１７は、アフィニティルールに従ってノードグループ♯１、および、ノードグループ♯４のみを残し、処理を続行する。

【0068】

スケール機構１７は、（Ａ）と（ΔＡ）を計算する。すなわち、ＣＰＵおよびメモリそれぞれの値を計算する。図１３にその計算結果を示す。

【0069】

スケール機構１７は、外部情報に基づいて（Ｂ）を算出する。ここでは、Ｂｃ＝０．５、Ｂｍ＝０．１が算出される。

【0070】

スケール機構１７は、スケール判定を行う。図１４にその判定結果を示す。

【0071】

スケール機構１７は、スケールするノードグループを選択し、スケールを行う。図１５に余剰リソースコストの計算結果を示す。この例では、余剰コストリソースの値について、ノードグループ♯１の方が低いので、ノードグループ♯１のノード数を１追加する（１⇒２）。

【0072】

スケール機構１７は、残りのコンテナＡ、コンテナＢについて、同様の手順でスケール判断を行う。

【0073】

次に、図１６を参照しながら、ハードウェア構成の一例について説明する。図１６は、システム全体のハードウェア構成例を示す図である。

【0074】

図１６に示すように、システム（負荷分散システム４１）は、負荷分散装置１１と、コンテナ基盤２１（クラスター）と、外部リソース３１と、を備える。利用者（例えば、開発者）は、コンピュータ（クライアント）を負荷分散装置１１に接続し、負荷分散装置１１を利用することができる。利用者は、例えば、インターネット、専用線や仮想プライベートネットワーク（ＶＰＮ）などの接続を行うことができる。クラウドプロバイダ（若しくは作業者）は、負荷分散装置１１の設定作業、および、コンテナ基盤２１の準備作業（プロビジョニング）を行う。

【0075】

負荷分散装置１１は、ＣＰＵ１２（プロセッサ）と、メモリ１３（この例では、ＲＡＭ）と、補助記憶装置１４（記憶部を構成し、この例では、ＳＳＤ）と、ネットワークインターフェース１５と、を備えるコンピュータとして構成され、データの負荷分散を行い、ノードにデータを振り分ける装置である。負荷分散装置１１は、上記で説明した処理を実行する。ここで、補助記憶装置１４は、取得されたリソースの情報や外部情報などのデータを格納する。また、補助記憶装置１４は、スケール機構１７とスケジュール機構１８を格納する。そして、ＣＰＵ１２は、メモリ１３にデータを読み出して所定の処理を実行する。

【0076】

コンテナ基盤２１は、複数の可用性ゾーン（もしくはデータセンター）を有しており、それぞれ可用性ゾーンには、コンテナをデプロイするノードが適宜に配置される。この例では、ノードは、ＣＰＵと、メモリ（この例では、ＲＡＭ）と、補助記憶装置（この例では、ＳＳＤ）と、ネットワークインターフェースと、を備えるコンピュータとして構成されている。

【0077】

また、このシステムは、外部リソース３１を備え、外部リソース３１は、ＣＰＵと、メモリ（この例では、ＲＡＭ）と、補助記憶装置（この例では、ＳＳＤ）と、ネットワークインターフェースと、を備えるコンピュータ（マシン）を含んで構成される。外部リソース３１は、例えば、コンテナをデプロイする際に、必要に応じてコンテナを退避することに活用される。

【0078】

以上、本発明の実施形態について詳述したが、本発明は、前記の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の精神を逸脱しない範囲で、種々の設計変更を行うことができるものである。例えば、前記した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

【0079】

所定の処理が実行されればよく、適宜に変更されてもよい。例えば、ＣＰＵ１２がプロセッサである例について説明されたが、他の種類の半導体デバイスが用いられ、同様のデータ処理が行われてもよい。補助記憶装置１４としてＳＳＤが説明されたが、他の種類の装置（例えば、ＨＤＤ）が用いられてもよい。その他のハードウェア構成についても、所定の処理を実行することができれば適宜に変更されてもよい。

【0080】

上記の開発環境の場合とは別に、負荷分散装置１１は、本番環境におけるリソースの需給予測を基に必要となるコンテナ数を決定し、コンテナ基盤２１のリソースを踏まえて基盤のスケール判断を行ってもよい。例えば、月末や繁忙期などでは需要が増加することが予測される。ここで、負荷分散装置１１は、例えば、リソースの変化を自動的に記録したデータに基づいて、需給予測を取得（計算）してもよい。また、需給予測は、例えば、外部から取得され、負荷分散装置１１に事前登録されてもよい。負荷分散装置１１は、必要となるタイミングでスケール判断を行い、本番環境での需給予測に応じたリソースを準備する。

【符号の説明】

【0081】

１１ 負荷分散装置
１２ ＣＰＵ（プロセッサ）
１３ メモリ
１４ 補助記憶装置（記憶部）
１５ ネットワークインターフェース
１７ スケール機構
１８ スケジュール機構
２１ コンテナ基盤
３１ 外部リソース
４１ 負荷分散システム

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】