特許 7552280 情報処理装置、配置方法、および、プログラム

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

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

(11)【特許番号】

(24)【登録日】2024-09-09

(45)【発行日】2024-09-18

(54)【発明の名称】情報処理装置、配置方法、および、プログラム

(51)【国際特許分類】

   G06F 11/07 20060101AFI20240910BHJP

【ＦＩ】

G06F11/07 193

【請求項の数】 8

(21)【出願番号】P 2020191784

(22)【出願日】2020-11-18

(65)【公開番号】P2022080615

(43)【公開日】2022-05-30

【審査請求日】2023-10-13

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100149618

【弁理士】

【氏名又は名称】北嶋 啓至

(72)【発明者】

【氏名】渡邊 岳大

【審査官】松平 英

(56)【参考文献】

【文献】特開２０１８－１９０３３３（ＪＰ，Ａ）

【文献】ＪＰ１ Ｖｅｒｓｉｏｎ１２ インフラストラクチャ管理 基本ガイド ３０２１－３－Ｄ６０－１０，日本，株式会社日立製作所，2020年01月，pp. 47-50

【文献】青山 真也，Ｋｕｂｅｒｎｅｔｅｓ完全ガイド 第２版，初版，日本，株式会社インプレス，2020年08月11日，pp.369-372,562-563，ISBN:978-4-295-00979-5

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

Ｇ０６Ｆ ８／００－８／３８

８／６０－８／７７

９／４４－９／４４５

９／４５１

９／４５５－９／５４

１１／０７

１１／２８－１１／３６

Ｇ０６Ｑ１０／００－１０／１０

３０／００－３０／０８

５０／００－５０／２０

５０／２６－９９／００

Ｇ１６Ｚ９９／００

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

【請求項1】

ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もる期間見積手段と、
前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する決定手段と、
を備える情報処理装置。

【請求項2】

前記期間見積手段を含み、
前記ノイジーネイバー問題に対処する前記再配置の方針ごとに、前記改修期間による前記Ｐｏｄの再配置のコストを計算するコスト計算手段を備える、
請求項１に記載の情報処理装置。

【請求項3】

前記決定手段は、計算された前記コストに基づき、前記Ｐｏｄの再配置の方針を決定する、
請求項２に記載の情報処理装置。

【請求項4】

前記開発情報は、前記マイクロサービスに関する開発チームの生産性、開発難易度、技術的負債、サービス更新頻度の少なくとも１つを含む、
請求項１から３のいずれか１つに記載の情報処理装置。

【請求項5】

前記コンテナクラスタの性能情報を収集し、前記ノイジーネイバー問題の有無を判定する性能情報収集手段と、
前記性能情報に基づき、前記ノイジーネイバー問題の原因が前記マイクロサービスにあるかを推定する原因推定手段と、を更に備える、
請求項１から４のいずれか１つに記載の情報処理装置。

【請求項6】

前記原因推定手段は、前記Ｐｏｄで動作している前記マイクロサービスへのリクエスト数が増加することなく前記Ｐｏｄの性能が劣化している場合、前記ノイジーネイバー問題の原因が前記マイクロサービスにあると推定する、
請求項５に記載の情報処理装置。

【請求項7】

コンピュータが、
ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もり、
前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する、
配置方法。

【請求項8】

コンピュータを、
ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もる期間見積手段と、
前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する決定手段と、
として機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、情報処理装置等に関する。

【背景技術】

【0002】

近年、システムを一枚岩の構成で構築するモノリシックなシステムに対する考え方として、複数のサービスからなるマイクロサービスアーキテクチャが注目されている。また、一般的にマイクロサービスアーキテクチャを構成する各マイクロサービスには、（１）各マイクロサービスが別々のチームによって開発される、（２）各チームで使っている技術・言語・開発体制などが異なる、（３）アジャイル開発により開発サイクルが短いという特徴がある。

【0003】

また、可用性の高いサービスを実現する方法の一つとして、コンテナ型仮想化が挙げられる。コンテナオーケストレーションツールによるコンテナ基盤上でマイクロサービスが動作している環境において、あるＰｏｄのリソース消費によって他のＰｏｄの動作に影響が出る問題(ノイジーネイバー問題)が存在する。ノイジーネイバー問題が発生すると、ＰｏｄのＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）使用率、メモリ使用量のような性能情報に基づいてＰｏｄの再配置が実施される。ノートを追加してＰｏｄを再配置することが考えられるが、ノードを追加すると時間的・金銭的コストが発生する。

【先行技術文献】

【特許文献】

【0004】

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

【文献】国際公開第２０１９／１８１８６０号

【文献】特開２０２０－１４４６６９号公報

【発明の概要】

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

【0005】

ノイジーネイバー問題には様々な原因があるが、バグ、あるいは、使用するリソースの設定が不適切など、マイクロサービスによる原因も存在する。ノイジーネイバー問題の原因がマイクロサービスの不具合である場合、マイクロサービスの改修にかかる期間を見積もることができれば、コストを考慮したＰｏｄの再配置が可能となる。しかし、特許文献１～３に開示された技術では、マイクロサービスの改修期間を見積もりを実現することができない。

【0006】

本開示の目的の１つは、ノイジーネイバー問題の原因となるマイクロサービスの改修期間を見積もることができる情報処理装置を提供することにある。

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

【0007】

本開示の情報処理装置の一態様は、ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もる期間見積手段と、前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する決定手段を備える。

【0008】

本開示の配置方法の一態様は、コンピュータが、ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もり、前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する。

【0009】

本開示のプログラムは、コンピュータを、ノイジーネイバー問題の原因となるマイクロサービスの開発情報に基づき、前記マイクロサービスの改修期間を見積もる期間見積手段と、前記改修期間を用いて、コンテナクラスタにおける前記マイクロサービスを動作させるＰｏｄの再配置の方針を決定する決定手段、として機能させる。

【発明の効果】

【0010】

本開示の情報処理装置等によれば、ノイジーネイバー問題の原因となるマイクロサービスの改修期間を見積もることができる。

【図面の簡単な説明】

【0011】

【図1】第１の実施形態に係るコンテナ型仮想化システムの概要を示す図である。

【図2】Ｐｏｄの再配置の例を示す説明図である。

【図3】アプリケーション開発環境における各マイクロサービスの開発情報の例を示す図である。

【図4】第１の実施形態に係る開発装置１００の動作を示すフローチャートである。

【図5】第１の実施形態に係る実行装置２００の動作を示すフローチャートである。

【図6】コスト計算部の動作を示すフローチャートである。

【図7】開発情報ごとのコスト計算の例を示すデータシートである。

【図8】ノイジーネイバー問題の方針ごとのコストの例を示すデータシートである。

【図9】第２の実施形態に係る実行装置２００の構成を示すブロック図である。

【図10】第２の実施形態に実行装置の動作を示すフローチャートである。

【図11】コンピュータのハードウェア構成の例を示すブロック図である。

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

【0012】

（第１の実施形態）
第１の実施形態におけるコンテナ型仮想化システムについて図面を用いて説明する。図１は、第１の実施形態に係るコンテナ仮想化システムの概要を示す図である。コンテナ仮想化システムは、アプリケーション開発環境１０、アプリケーション実行環境２０を含む。

【0013】

アプリケーション開発環境１０は、アプリケーション実行環境上で動作するアプリケーションを開発する環境である。アプリケーション実行環境２０は、アプリケーションを実行することでユーザにサービスを提供する基盤となる環境である。アプリケーション開発環境１０、アプリケーション実行環境２０は、ネットワーク３０を介して接続される。アプリケーション開発環境１０、アプリケーション実行環境２０は、それぞれ物理マシン又は仮想マシン上で構築されてもよい。

【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】

１００ 開発装置
１０１ ソースリポジトリ
１０２ 開発情報保持部
１０３ 開発情報計算部
２００ 実行装置
２０１ 収集部
２０２ 原因推定部
２０３ コスト計算部
２０４ 決定部
２０５ コンテナクラスタ
２０６ クラスタ管理部
２０７ Ｐｏｄ
３００ 実行装置
３０１ 期間見積部
３０２ 決定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】