特開 2022-173862 コンテナ管理システム、及びコンテナ管理方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022173862

(43)【公開日】2022-11-22

(54)【発明の名称】コンテナ管理システム、及びコンテナ管理方法

(51)【国際特許分類】

   G06F 9/455 20060101AFI20221115BHJP

【ＦＩ】

G06F9/455 150

【審査請求】未請求

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2021079843

(22)【出願日】2021-05-10

(71)【出願人】

【識別番号】000005108

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

(74)【代理人】

【識別番号】110000176

【氏名又は名称】一色国際特許業務法人

(72)【発明者】

【氏名】柿田 将幸

(72)【発明者】

【氏名】相樂 恭宏

(72)【発明者】

【氏名】肥村 洋輔

(72)【発明者】

【氏名】橋本 恭佑

(57)【要約】      （修正有）

【課題】複数のオペレータによるコンテナの構成情報の変更を安定的にコントロールするコンテナ管理システム及びコンテナ管理方法を提供する。
【解決手段】コンテナ管理システム１００は、プロセッサ及びメモリを有し、第１のオペレータ（アプリＡオペレータコンテナ１０４）によるコンテナの構成情報の変更の実行を検知した場合に、所定時間、第２のオペレータ（アプリＢオペレータコンテナ１０５）によるコンテナの構成情報の変更の実行を禁止させる構成変更管理部を構成する構成変更監視コンポーネント１０２及び監視データストア１０３を備える。
【選択図】図１

【特許請求の範囲】

【請求項1】

プロセッサ及びメモリを有し、
第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、所定時間、第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる構成変更管理部を備える、コンテナ管理システム。

【請求項2】

前記第２のオペレータは、所定の条件が満たされたと判定した場合に前記コンテナの構成情報の変更を実行するものであり、
前記構成変更管理部は、前記第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、前記第２のオペレータに、前記所定時間、前記所定の条件が満たされないことを示す情報を送信する、
請求項１に記載のコンテナ管理システム。

【請求項3】

前記構成変更管理部は、
前記第１のオペレータによる第１のタイミングでのコンテナの構成情報の変更の実行を検知した場合に、前記第２のオペレータによるコンテナの構成情報の変更の要求を受信し、受信したタイミングが、前記第１のタイミングから前記所定時間経過しているか否かを判定し、前記受信したタイミングが前記第１のタイミングから前記所定時間経過していると判定した場合にのみ、前記第２のオペレータによるコンテナの構成情報の変更を実行する、
請求項１に記載のコンテナ管理システム。

【請求項4】

各前記オペレータによる前記コンテナの構成情報の変更の実行の履歴を記憶する構成情報履歴管理部を備え、
前記構成変更管理部は、前記履歴に基づき、前記第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる、
請求項１に記載のコンテナ管理システム。

【請求項5】

前記構成情報の変更要求の発行元と、前記構成情報の変更要求に係るオペレータとの対応関係の履歴を記憶する対応表管理部を備え、
前記構成変更管理部は、前記コンテナの構成情報の変更要求を取得した場合に、前記対応関係の履歴に基づき、前記変更要求に含まれるオペレータ及び発行元の情報がそれぞれ前記第１のオペレータ及び前記第１のオペレータの発行元に対応するか否かを判定し、前記変更要求に含まれるオペレータ及び発行元の情報がそれぞれ前記第１のオペレータ及び前記第１のオペレータの発行元に対応すると判定した場合には、前記第１のオペレータによるコンテナの構成情報の変更の実行があったと検知する、
請求項１に記載のコンテナ管理システム。

【請求項6】

情報処理装置が、
第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、所定時間、第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる構成変更管理処理を実行する、コンテナ管理方法。

【請求項7】

前記第２のオペレータは、所定の条件が満たされたと判定した場合に前記コンテナの構成情報の変更を実行するものであり、
前記構成変更管理処理は、前記第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、前記第２のオペレータに、前記所定時間、前記所定の条件が満たされないことを示す情報を送信する処理である、
請求項６に記載のコンテナ管理方法。

【請求項8】

前記構成変更管理処理は、
前記第１のオペレータによる第１のタイミングでのコンテナの構成情報の変更の実行を検知した場合に、前記第２のオペレータによるコンテナの構成情報の変更の要求を受信し、受信したタイミングが、前記第１のタイミングから前記所定時間経過しているか否かを判定し、前記受信したタイミングが前記第１のタイミングから前記所定時間経過していると判定した場合にのみ、前記第２のオペレータによるコンテナの構成情報の変更を実行する処理である、
請求項６に記載のコンテナ管理方法。

【請求項9】

前記情報処理装置が、
各前記オペレータによる前記コンテナの構成情報の変更の実行の履歴を記憶する構成情報履歴管理処理を実行し、
前記構成変更管理処理は、前記履歴に基づき、前記第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる処理である、
請求項６に記載のコンテナ管理方法。

【請求項10】

前記情報処理装置が、
前記構成情報の変更要求の発行元と、前記構成情報の変更要求に係るオペレータとの対応関係の履歴を記憶する対応表管理処理を実行し、
前記構成変更管理処理は、前記コンテナの構成情報の変更要求を取得した場合に、前記対応関係の履歴に基づき、前記変更要求に含まれるオペレータ及び発行元の情報がそれぞれ前記第１のオペレータ及び前記第１のオペレータの発行元に対応するか否かを判定し、前記変更要求に含まれるオペレータ及び発行元の情報がそれぞれ前記第１のオペレータ及び前記第１のオペレータの発行元に対応すると判定した場合には、前記第１のオペレータによるコンテナの構成情報の変更の実行があったと検知する処理である、
請求項６に記載のコンテナ管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、コンテナ管理システム、及びコンテナ管理方法に関する。

【背景技術】

【0002】

アプリケーション（アプリ）の運用において、アプリとその実行環境の監視データを利用して、従来は人間が手作業で行っていた処理をプログラムに実行させる自動化の運用が広がっている。中でも、データストアのようなステートフルアプリを運用するために、「どのようにデプロイするのか」「何らかの問題が起きた場合にどのように対処するのか」といった、従来は開発者がスクリプトや操作手順書に記載していたようなドメイン知識を自動運用プログラムに組み込んだものを特にオペレータ（Operator）と呼ぶ。

【0003】

例えば、受け付けたリクエストに対して処理を施して返送するようなステートレスアプリの場合、オペレータは、アプリに対する負荷が高まったときに、アプリを実行している仮想マシン（Virtual Machine: VM）やコンテナのインスタンスを増やしてリクエストを
分散処理させるだけでアプリの処理能力を向上させることができる（スケールアウト）。一方で、複数のインスタンスからなるクラスタを構成しデータを分散管理するデータストアのような、ステートフルアプリを運用する場合は、負荷が高まったときにアプリを実行しているインスタンスを増やすだけでは不十分であり、オペレータはインスタンスからクラスタ内のリーダの選出やデータの再配置などアプリ固有の処理を正しい手順で実行することで、クラスタ全体の処理能力が向上し負荷を分散できる状態にできる。オペレータは、このようなアプリ固有の運用操作を実施するプログラムである。

【0004】

このようなオペレータに関して、アプリ及びその設定情報を含むコンテナの実行基盤であるKubernetes（登録商標）上でステートフルアプリのコンテナを運用する場合のオペレータプログラムの開発が活発に進められている。オープンソースソフトウェア（Open Source Software: OSS）アプリに関しては、各アプリにおいて共通性の高い運用操作を自動
化するオペレータが各OSSコミュニティによって開発され、例えばOperator Hub (https://operatorhub.io/)などを通じてインターネット上で公開されている。

【0005】

このようなオペレータ（自動運用プログラム）の運用上の問題として、独立した自動運用プログラム同士の干渉がある。例えば、オペレータの普及により互いの運用ルールを考慮していない複数のアプリとそのオペレータが共通の基盤上で動作するような状況を考える。各アプリとオペレータは独立して動作しているため、あるアプリのオペレータがコンテナの運用操作、具体的には構成情報の変更を実行したことで一時的にシステムに対する負荷が上昇し、別のアプリの性能に影響を及ぼすことがある。その場合、影響を受けたアプリのオペレータによるアプリの構成変更を伴う運用操作が誘発され、最悪の場合は個々のオペレータの運用が干渉し合って無限ループに陥る可能性がある。

【0006】

このような自動運用プログラムによる不要な運用操作を排除するための仕組みとして、例えば、特許文献１には、閾値を用いたルールベースのオートスケールにおいて、不適切な閾値設定によりスケールアウトとスケールインを繰り返してしまうフラッピング現象を防ぐために、スケールアウトを実施した後に、スケールインを実施するとき、スケールイン後の負荷状況をシミュレーションして再スケールアウトが起きそうな場合はスケールイン処理をスキップすることが開示されている。

【0007】

また、特許文献２には、メトリクスの種類と過去にメトリクス異常値が継続した時間を使って、メトリクスの異常値が検出されたときに運用操作の要否をスコアリングすること
が開示されている。

【先行技術文献】

【特許文献】

【0008】

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

【特許文献2】国際公開第２０１３／０２７５６２号

【発明の概要】

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

【0009】

しかしながら、特許文献１の技術では同一のアプリケーションの運用操作の無限ループを防ぐことができるが複数のアプリケーションにまたがって起きる運用操作の不具合に対する対策を取ることはできない。また、シミュレーションを実施するために運用操作に使うメトリクス情報を明示的に宣言させる必要がある。

【0010】

特許文献２では、メトリクスの種類と異常継続時間による重み付けだけでは、メトリクス変動の傾向が変わってしまった場合などの状況の変化に追従して正しい判定を下すことができない。

【0011】

本発明はこのような事情に鑑みてなされたもので、その目的は、複数のオペレータによるコンテナの構成情報の変更を安定的にコントロールすることが可能なコンテナ管理システム、及びコンテナ管理方法を提供することにある。

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

【0012】

上記課題を解決するための本発明の一つは、プロセッサ及びメモリを有し、第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、所定時間、第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる構成変更管理部を備える、コンテナ管理システム、とする。

【0013】

また、上記課題を解決するための本発明の一つは、情報処理装置が、第１のオペレータによるコンテナの構成情報の変更の実行を検知した場合に、所定時間、第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる構成変更管理処理を実行する、コンテナ管理方法、とする。

【発明の効果】

【0014】

本発明によれば、複数のオペレータによるコンテナの構成情報の変更を安定的にコントロールすることができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

【図面の簡単な説明】

【0015】

【図1】第１実施形態に係るコンテナ管理システムの構成の一例を示すブロック図である。

【図2】構成変更監視コンポーネントが有する機能の一例を説明するブロック図である。

【図3】ＯＰ－ＳＡ対応表の一例を示す図である。

【図4】監視データストアが有する機能の一例を示すブロック図である。

【図5】メトリクスデータ表の一例を示す図である。

【図6】構成変更操作履歴表の一例である。

【図7】コンテナオーケストレータ、構成変更監視コンポーネント、監視データストア、及びコンテナが備えるハードウェアの一例を説明する図である。

【図8】ＯＰ－ＳＡ対応表更新処理の一例を説明するシーケンス図である。

【図9】新規リソース作成通知におけるリソース操作情報表の一例である。

【図10】ＯＰ－ＳＡ対応表更新実行処理の一例を説明するフローチャートである。

【図11】構成情報変更管理処理の一例を説明するシーケンス図である。

【図12】構成変更要求通知におけるリソース操作情報表の一例である。

【図13】構成変更監視処理の一例を説明するフローチャートである。

【図14】構成変更履歴更新処理の一例を説明するフローチャートである。

【図15】メトリクスデータ送信処理の一例を説明するフローチャートである。

【図16】構成変更抑制処理の詳細を説明するフローチャートである。

【図17】第２実施形態に係る構成変更監視コンポーネントが有する機能の一例を示すブロック図である。

【図18】第２実施形態に係る監視データストアが有する機能の一例を示すブロック図である。

【図19】第２実施形態に係る構成情報管理処理を示すシーケンス図である。

【図20】第２実施形態に係る構成変更監視処理の詳細を示すフローチャートである。

【図21】第２実施形態に係るメトリクスデータ送信処理の一例を説明するフローチャートである。

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

【0016】

－第１実施形態－
＜システム構成＞
図１は、第１実施形態に係るコンテナ管理システム１００の構成の一例を示すブロック図である。コンテナ管理システム１００は、コンテナオーケストレータ１０１、構成変更監視コンポーネント１０２、監視データストア１０３、及びコンテナ１３０（複数のオペレータコンテナ１１０及び複数のアプリコンテナ１２０）を含んで構成され、これらの装置の間は、ネットワーク１０８により通信可能に接続される。ネットワーク１０８は、例えば、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット
、又は専用線等の有線若しくは無線の通信ネットワークである。

【0017】

本実施形態では、オペレータコンテナ１１０は、アプリＡオペレータコンテナ１０４、及びアプリＢオペレータコンテナ１０５を含む。また、本実施形態では、アプリコンテナ１２０は、アプリＡコンテナ１０６及びアプリＢコンテナ１０７を含む。なお、アプリＡコンテナ１０６及びアプリＢコンテナ１０７は複数のコンテナを含んでいでもよい。また、これらの各コンテナ１３０は、対応する１つの情報処理装置として構成されていてもよいし、情報処理装置の一部を構成するコンポーネント（データ）であってもよいし、複数の情報処理装置によって構成されるコンポーネント（データ）であってもよい。本実施形態では、各コンテナは、対応する１つの情報処理装置として構成されているものとする。

【0018】

各コンテナ１３０は、アプリケーション、そのアプリケーションの設定情報、及びその他の設定情報であるコンテナを記憶している。このうち、アプリコンテナ１２０は、アプリケーションのコンテナを記憶している。オペレータコンテナ１１０は、アプリコンテナ１２０におけるコンテナの構成情報を管理するプログラムであるオペレータのコンテナを記憶している。

【0019】

コンテナオーケストレータ１０１は、各コンテナ１３０が保持するコンテナの構成情報を管理しており、各コンテナ１３０が所定の構成で動作するように、各コンテナ１３０の起動及び停止を制御する。具体的には、コンテナオーケストレータ１０１は、各コンテナ１３０に対して、構成情報の変更を命令する制御命令を送信する。

【0020】

構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１から送信され
た制御命令をフックし、構成情報の変更の履歴として取得して記憶する。構成変更監視コンポーネント１０２の詳細は後述する。

【0021】

監視データストア１０３は、各アプリコンテナ１２０の性能を評価するためのパラメータであるメトリクスデータを監視データとして取得し蓄積する。メトリクスデータは、構成情報の変更を行うための条件が満たされているか否かを判定するために、各オペレータコンテナ１１０によって用いられる情報である。

【0022】

オペレータコンテナ１１０は、監視データストア１０３に蓄積された監視データを参照する。オペレータコンテナ１１０は、監視データに含まれるメトリクスデータの異常値を検出すると、コンテナオーケストレータ１０１に対して、アプリコンテナ１２０の構成情報の変更を要求する。

【0023】

このように、本実施形態では、構成変更監視コンポーネント１０２及び監視データストア１０３が、構成情報の変更を統括的に管理する構成変更管理部を構成している。

【0024】

（構成変更監視コンポーネント）
次に、図２は、構成変更監視コンポーネント１０２が有する機能の一例を説明するブロック図である。構構成変更監視コンポーネント１０２は、対応表更新処理部２０２、及び構成変更監視処理部２０３を備える。また、構成変更監視コンポーネント１０２は、ＯＰ－ＳＡ対応表２０１を記憶している。

【0025】

ＯＰ－ＳＡ対応表２０１（オペレータ－サービスアカウント対応表）は、コンテナオーケストレータ１０１に対する構成情報の変更要求の発行元である各サービスアカウントと、各オペレータとの対応を記憶したデータである。

【0026】

（ＯＰ－ＳＡ対応表）
図３は、ＯＰ－ＳＡ対応表２０１の一例を示す図である。ＯＰ－ＳＡ対応表２０１は、オペレータの識別子が設定されるオペレータ識別子２０１０１、及び、オペレータに紐付けられるサービスアカウントの識別子が設定されるサービスアカウント識別子２０１０２の各データ項目を有する。

【0027】

次に、図２に示すように、ＯＰ－ＳＡ対応表更新処理部２０２は、コンテナオーケストレータ１０１から送信された、新たなオペレータコンテナ１１０を生成するための構成情報の生成の要求を含む制御命令をフックし、そのオペレータと制御命令に含まれるサービスアカウントの識別子とを対応づけてＯＰ－ＳＡ対応表２０１に記憶する。

【0028】

構成変更監視処理部２０３は、コンテナオーケストレータ１０１から送信された、構成情報の変更要求を含む制御命令をフックして、その制御命令を取得する。さらに、構成変更監視処理部２０３は、取得した制御命令からアプリケーションの構成情報の変更内容に関する情報を抽出して、監視データストア１０３に、その構成情報の変更を通知する通知情報を送信する。

【0029】

（監視データストア）
次に、図４は、監視データストア１０３が有する機能の一例を示すブロック図である。監視データストア１０３は、メトリクスデータ送信処理部８０３、構成変更抑止判定処理部８０４、及び構成変更履歴更新処理部８０５の各機能部を有する。また、監視データストア１０３は、メトリクスデータ表８０１を記憶する。

【0030】

メトリクスデータ表８０１は、各コンテナ１３０のメトリクスデータを記憶している。
構成変更操作履歴表８０２は、構成変更監視コンポーネント１０２から送信された通知情報を記憶したデータである。
ここで、メトリクスデータ表８０１及び構成変更操作履歴表８０２について説明する。

【0031】

（メトリクスデータ表）
図５は、メトリクスデータ表８０１の一例を示す図である。メトリクスデータ表８０１は、メトリクスデータが取得された時刻が設定される時刻８０１０１、取得されたメトリクスの識別子が設定されるメトリック識別子８０１０２、及び、取得されたメトリクスデータの値が設定される値８０１０３の各データ項目を含む。

【0032】

（構成変更操作履歴表）
図６は、構成変更操作履歴表８０２の一例である。構成変更操作履歴表８０２は、構成変更監視コンポーネント１０２から送信されてきた通知情報を記憶している。

【0033】

すなわち、構成変更操作履歴表８０２は、通知情報の識別子が設定される通知情報識別子、通知情報が示す構成情報の変更の要求元（例えば、オペレータ、その他のユーザ端末等）の識別子が設定されるオペレータ識別子、通知情報の送信元の識別子（サービスアカウント等）が設定される要求元識別子、通知情報により特定される変更後の構成情報が設定される更新後情報、構成情報の変更の要求のタイミング（例えば、通知情報の受信時刻若しくは送信時刻、又はアプリ構成情報変更要求の送信時刻若しくは受信時刻等でもよい。以下、発生日時という。）が設定される発生日時８０２０３、及び、上記要求元がオペレータの場合にそのオペレータ以外のオペレータによる構成情報の変更を禁止する時期の期限（構成情報の変更を遅延させる時間を示す情報）が設定される変更抑制判定失効日時の各データ項目から構成される。なお、この期限は、すべてのオペレータに対して同じとしてもよいし、各オペレータの処理ごとに異ならせてもよい。

【0034】

次に、図４に示すメトリクスデータ送信処理部８０３は、各オペレータコンテナ１１０に対してメトリクスデータを送信する。

【0035】

構成変更抑止判定処理部８０４は、メトリクスデータ送信処理部８０３がメトリクスデータを送信する際に、構成変更操作履歴表８０２を参照することで、一定時間前の時刻から現在時刻までの間に、オペレータが構成情報の変更を実行していたか否かを判定し、実行されていたときは構成変更を抑止する（遅延させる）メトリクスデータを送信するか否かを判定する。

【0036】

構成変更履歴更新処理部８０５は、構成変更監視コンポーネント１０２から受信した通知情報が示す、コンテナの構成情報の変更の履歴を構成変更操作履歴表８０２に記憶する。

【0037】

ここで、図７は、コンテナオーケストレータ１０１、構成変更監視コンポーネント１０２、監視データストア１０３、及びコンテナ１３０が備えるハードウェアの一例を説明する図である。これらのコンポーネントは、ＣＰＵ（Central Processing Unit）、ＭＰＵ
（Micro Processing Unit）、又はＧＰＵ（Graphics Processing Unit）等のプロセッサ
１と、ＲＯＭ（Read Only Memory）、又はＲＡＭ（Random Access Memory）等の主記憶装置２と、ハードディスクドライブ（Hard Disk Drive）、フラッシュメモリ（Flash Memory）、又はＳＳＤ（Solid State Drive）等の補助記憶装置３と、キーボード、マウス、カードリーダ、又はタッチパネル等の入力装置４と、液晶ディスプレイ（Liquid Crystal Display: LCD）、音声出力装置（スピーカ）、又は印字装置等の出力装置５と、ネットワ
ークインタフェースカード（Network Interface Card: NIC）、無線通信モジュール、Ｕ
ＳＢ（Universal Serial Interface）モジュール、又はシリアル通信モジュール等の通信
装置６とを備える。

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

＜メトリクスデータ送信処理＞
図１５は、メトリクスデータ送信処理ｓ１の一例を説明するフローチャートである。メトリクスデータ送信処理は、各オペレータコンテナ１１０に対して現在のメトリクスデータを送信し、または、抑制判定失効日時に基づき過去のメトリクスデータを送信する処理である。

【0082】

なお、トリクスデータ送信処理ｓ１の開始は、例えば、メトリクスデータ表８０１が更新されたことを契機に開始される。この場合、監視データストア１０３が更新データを送信するプッシュ型のイベントが契機であってもよいし、オペレータコンテナ１１０が、監視データストア１０３に更新データを要求するプル型のイベントが契機であってもよい。ここでは、時刻「２０２１－０３－０２Ｔ０９：３２：００Ｚ」に、アプリＢオペレータコンテナ１０５によってメトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」である最新のメトリクスデータの送信が要求された場合を説明する。

【0083】

監視データストア１０３は、アプリＢオペレータコンテナ１０５から、メトリクスデータを送信するための所定リクエストを受信する（Ｓ１２０１）。例えば、このリクエストには、アプリＢオペレータコンテナ１０５が要求するメトリックデータのメトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」が含まれる。

【0084】

監視データストア１０３は、リクエストを受信すると、このリクエストに対応する最新のメトリクスデータをメトリクスデータ表８０１から取得する（Ｓ１２０２）。図５の例では、メトリクスデータ表８０１における、メトリック識別子が「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」である行のうち時刻が最新の行Ｒ８０１０１を取得する。

【0085】

監視データストア１０３は、Ｓ１２０２で取得したメトリクスデータ（送信対象メトリクスデータ）を必要に応じて（抑制判定失効日時に応じて）変更する構成変更抑制処理Ｓ１２０３を実行する。具体的には、監視データストア１０３は、メトリクスデータの送信先（例えば、アプリＢオペレータコンテナ１０５）のオペレータ識別子（例えば、「ａｐｐＢ－ｏｐｒ」）、及びメトリック識別子（例えば、「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」）を引数として構成変更抑制処理Ｓ１２０３を呼び出す。構成変更抑制処理Ｓ１２０３の詳細は後述する。

【0086】

監視データストア１０３は、Ｓ１２０３で変更した（又は変更しなかった）メトリクスデータを、オペレータコンテナ１１０に送信する。例えば、監視データストア１０３は、変更したメトリクスデータをアプリＢオペレータコンテナ１０５に送信する。以上でメトリクスデータ送信処理ｓ１は終了する。
ここで構成変更抑制処理Ｓ１２０３の詳細を説明する。

【0087】

＜構成変更抑制処理＞
図１６は、構成変更抑制処理Ｓ１２０３の詳細を説明するフローチャートである。

【0088】

監視データストア１０３は、構成変更操作履歴表８０２から、送信対象メトリクスデータの送信先のオペレータと異なる他のオペレータであって、その変更抑制判定失効日時がまだ到来していないオペレータを検索する（なお、変更抑制判定失効日時がまだ到来していない全てのオペレータを対象としてもよい）。

【0089】

具体的には、監視データストア１０３は、構成変更操作履歴表８０２を参照して、引数として渡されたオペレータ識別子とは異なるオペレータ識別子が設定され、変更抑制判定失効日時８０２０２が現在時刻よりも未来である行を検索する。

【0090】

変更抑制判定失効日時がまだ到来していない他のオペレータを検索できた場合は（Ｓ１３０１：ＹＥＳ）、監視データストア１０３はＳ１０３２の処理を実行し、変更抑制判定失効日時がまだ到来していない他のオペレータを検索できなかった場合は（Ｓ１３０１：ＮＯ）、構成変更抑制処理Ｓ１２０３は終了する（送信対象メトリクスデータの更新は行わない）。

【0091】

Ｓ１３０２において監視データストア１０３は、送信対象メトリクスデータを、Ｓ１３０１で特定した構成情報の変更が実施される前のメトリクスデータに変更し、構成変更抑制処理Ｓ１２０３は終了する。

【0092】

例えば、監視データストア１０３は、時刻「２０２１－０３－０２Ｔ０９：３２：００Ｚ」において構成変更操作履歴表８０２を参照し、図６に示す構成変更操作履歴表８０２に、他のオペレータＡ「ａｐｐＡ－ｏｐｒ」が時刻「２０２１－０３－０２Ｔ０９：３０：００Ｚ」で行った構成情報の変更（行Ｒ８０２０１）が有効な状態で存在した（行Ｒ８０２０１の変更抑制判定失効日時８０２０２が未到来）と判定する。この場合、監視データストア１０３はメトリクスデータ表８０１を参照して時刻「２０２１－０３－０２Ｔ０９：３０：００Ｚ」以前の最新の時刻に係る行Ｒ８０１０２を取得し、取得した行Ｒ８０１０２のデータで送信対象メトリクスデータを書き換える。

【0093】

このように、構成変更抑制処理Ｓ１２０３は、あるオペレータがあるアプリの構成情報の変更を行おうとする際、過去の所定時間以内に他のオペレータによる当該アプリの構成情報の変更履歴が存在した場合は、その構成情報の変更を抑制する。

【0094】

以上のように、本実施形態のコンテナ管理システム１００は、第１のオペレータ（例えば、アプリＡオペレータコンテナ１０４）によるコンテナの構成情報の変更の実行を検知した場合に、所定時間（例えば、構成情報の変更の発生日時から変更抑制判定失効日時まで）、第２のオペレータ（例えば、アプリＢオペレータコンテナ１０５）によるコンテナの構成情報の変更の実行を禁止させる。

【0095】

特に、第１実施形態のコンテナ管理システム１００では、アプリＢオペレータコンテナ１０５（アプリＡオペレータコンテナ１０４も同様）は、メトリクスデータに基づき応答性能が低下したと判定した場合にコンテナの構成情報の変更を実行するものであり、構成変更監視コンポーネント１０２及び監視データストア１０３は、第１のオペレータ（例えば、アプリＡオペレータコンテナ１０４）によるコンテナの構成情報の変更の実行を検知した場合に、第２のオペレータに（例えば、アプリＢオペレータコンテナ１０５）、所定時間、応答性能が低下していないことを示すメトリクスデータを送信する。

【0096】

これにより、第２のオペレータは所定時間、構成情報の変更を要求することがなく、第１のオペレータによる構成情報の変更に起因する、第２のオペレータによる構成情報の変更が抑制される。

【0097】

すなわち、例えば、オペレータＡによる運用操作に起因する一時的なメトリクス変動によって、別のオペレータＢの運用操作が誘発されることを阻止し、運用操作の無限ループやリソースの過剰利用を抑制することができる。また、抑制期間を有限にしていることにより、メトリクス変動が一時的なものではなかった場合に、オペレータＢの運用操作が実施されないことを防ぐことができる。

【0098】

このように、本実施形態のコンテナ管理システム１００によれば、複数のオペレータによるコンテナの構成情報の変更を安定的にコントロールすることができる。

【0099】

また、本実施形態のコンテナ管理システム１００は、各オペレータによるコンテナの構成情報の変更の実行の履歴を記憶する構成変更操作履歴表８０２を備えており、この構成変更操作履歴表８０２に基づき、第２のオペレータによるコンテナの構成情報の変更の実行を禁止させる。このように、各オペレータによる構成情報の変更履歴を管理することで、多数のオペレータが存在するコンテナ管理システム１００であっても、コンテナの構成情報の変更を安定的にコントロールすることができる。

【0100】

また、本実施形態のコンテナ管理システム１００は、構成情報の変更要求の発行元と、構成情報の変更要求に係るオペレータとの対応関係の履歴を記憶したＯＰ－ＳＡ対応表２０１を記憶しており、コンテナの構成情報の変更要求を取得した場合に、ＯＰ－ＳＡ対応表２０１に基づき、第１のオペレータによるコンテナの構成情報の変更の実行があったと検知する。すなわち、オペレータ以外の発行元（ユーザアカウント等）に基づく構成情報の変更をコントロール外とすることで、柔軟なシステム運用が可能となる。

【0101】

－第２実施形態－
次に、本発明の第２実施形態について説明する。第２実施形態に係るコンテナ管理システム１００は、構成変更操作履歴表８０２を有するコンポーネントが、第１実施形態のように監視データストア１０３ではなく、構成変更監視コンポーネント１０２である。これにより、例えば、コンテナ管理システム１００における実行基盤の監視のために外部システム（例えば、ＳａａＳ（Software as a Service））を利用している等により、監視デ
ータストア１０３の機能を拡張できない場合においても、第１実施形態と同様に、構成情報の変更の抑制を行うことができる。

【0102】

本実施形態では、構成変更監視コンポーネント１０２のみが、構成情報の変更をコントロールする構成変更管理部を構成する。

【0103】

まず、第２実施形態に係るコンテナ管理システム１００の構成は第１実施形態と同一である。

【0104】

＜構成変更監視コンポーネント＞
図１７は、第２実施形態に係る構成変更監視コンポーネント１０２が有する機能の一例を示すブロック図である。

【0105】

同図に示すＯＰ－ＳＡ対応表２０１、及びＯＰ－ＳＡ対応表更新処理部２０２は第１実施形態と同様である。構成変更操作履歴表８０２は、第１実施形態に係る監視データストア１０３が記憶している構成変更操作履歴表８０２と同様である。

【0106】

構成変更監視処理部１５０１は、第１実施形態に係る監視データストア１０３の構成変更履歴更新処理部８０５と同様である。この構成変更監視処理部１５０１は、コンテナオーケストレータ１０１から送信されたコンテナの制御命令をフックして、そのコンテナの構成情報の変更内容を参照することができる。また、この構成変更監視処理部１５０１は、参照した変更内容に応じて構成情報の変更の実行の可否を判定し、その判定結果をコンテナオーケストレータ１０１に返送する。

【0107】

図１８は、第２実施形態に係る監視データストア１０３が有する機能の一例を示すブロック図である。

【0108】

メトリクスデータ表３０１は、第１実施形態に係るメトリクスデータ表８０１と同様である。

【0109】

メトリクスデータ送信処理部１８０１は、第１実施形態に係るメトリクスデータ送信処理部８０３と類似し、各オペレータコンテナ１１０（アプリＡオペレータコンテナ１０４、アプリＢオペレータコンテナ１０５）に対してメトリクスデータを送信する。

【0110】

図１９は、第２実施形態に係る構成情報管理処理を示すシーケンス図である。まず、同図に示すメトリクスデータ送信処理ｓ１、アプリＡオペレータコンテナ１０４によるアプリＡの応答性能が低下していることの検知（ｓ２）、アプリＡオペレータコンテナ１０４によるアプリ構成情報変更要求の送信（ｓ３）、及び、コンテナオーケストレータ１０１による構成変更要求通知の送信（ｓ４）は第１実施形態と同様である。

【0111】

一方、構成変更監視コンポーネント１０２は、構成変更監視処理ｓ５１を実行している。

【0112】

すなわち、構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１からの構成変更要求通知の受信を監視している。構成変更監視コンポーネント１０２は、構成変更要求通知を受信すると、構成情報の変更の要求元がオペレータであることを確認し、要求元がオペレータである場合は、構成変更操作履歴表８０２を参照し、過去所定時間以内にオペレータによる構成情報の変更があったか否かを確認する。この際、構成変更監視コンポーネント１０２は、第１実施形態と同様に、処理続行許可通知を、コンテナオーケストレータ１０１に送信する（ｓ７）。以上の構成変更監視処理ｓ５１の詳細は後述する。

【0113】

構成変更監視コンポーネント１０２から処理続行許可通知を受信したコンテナオーケストレータ１０１は、第１実施形態と同様に、アプリＡコンテナ１０６におけるアプリＡのコンテナの構成情報を変更する（例えば、コンテナ数を増加する）ための指示である構成変更要求を送信する構成変更処理を実行する（ｓ８）。

【0114】

アプリＡコンテナ１０６は、第１実施形態と同様に、構成変更要求を受信すると、アプリＡのコンテナ数を増加させる（ｓ９）。

【0115】

以下では、構成変更監視コンポーネント１０２は、構成変更監視処理ｓ５１において、構成変更操作履歴表８０２に、過去所定時間以内にオペレータによる構成情報の変更が存在せず、図６に示す構成変更操作履歴表８０２の行Ｒ８０２０１に、ｓ４で受信した構成変更要求通知に係る構成情報の変更の情報を追加したものとする。

【0116】

監視データストア１０３は、アプリＢオペレータコンテナ１０５を含む各オペレータ１１０に対してメトリクスデータを定期的に送信するメトリクスデータ送信処理ｓ１を実行
している。具体的には、監視データストア１０３は、メトリクスデータを送信する際は、構成変更操作履歴表８０２を参照し、これまで受信したメトリクスデータ（ここでは、メトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」のメトリクスデータ）のうち、直近のメトリクスデータを送信する。

【0117】

アプリＢオペレータコンテナ１０５は、監視データストア１０３から受信したメトリクスデータによりアプリＢの応答性能が低下していることを検知する（ｓ１４）。ここでは、時刻ｔ４（２０２１－０３－０２Ｔ０９：３６：００Ｚ）において、メトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」のメトリクスデータに関して、アプリＡオペレータコンテナ１０４によるアプリＡコンテナ１０６の構成情報の変更の影響により、アプリＢコンテナ１０７の応答性能が低下したものとする。

【0118】

すると、アプリＢオペレータコンテナ１０５は、アプリＢコンテナ１０７の処理能力を増強して性能低下を解消するため、コンテナオーケストレータ１０１に対してアプリＢコンテナ１０７の構成情報を変更（例えば、コンテナ数の増加）させるためのアプリ構成情報変更要求を送信する（ｓ１５）。

【0119】

コンテナオーケストレータ１０１は、アプリ構成情報変更要求を受信すると、ｓ３と同様に、自身が記憶している構成情報の変更を試行する。そして、コンテナオーケストレータ１０１は、構成情報の変更の情報であるリソース操作情報表５０１を生成し、生成したリソース操作情報表５０１を含む構成変更要求通知を構成変更監視コンポーネント１０２に送信する（ｓ１７）。

【0120】

一方、構成変更監視コンポーネント１０２は、構成変更監視処理ｓ５１を実行中である。

【0121】

すなわち、まず、構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１から、アプリＢコンテナ１０７に係る構成変更要求通知を受信すると、過去所定時間以内の、各オペレータコンテナ１１０による構成情報の変更の履歴の有無を確認することで、各オペレータコンテナ１１０による変更抑制判定失効日時が過去であるか否かを確認する。

【0122】

例えば、構成変更監視コンポーネント１０２は、構成変更操作履歴表８０２から、メトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」のメトリクスデータに係る行Ｒ８０２０１の変更抑制判定失効日時８０２０２が過去の時刻であるか否かを確認する。

【0123】

変更抑制判定失効日時が過去でない場合は、構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１に、構成情報の変更を行わない旨の却下通知を送信する。却下通知を受信したコンテナオーケストレータ１０１は、アプリＢコンテナ１０７の構成情報の変更（コンテナ数の増加）を行わない。

【0124】

一方、変更抑制判定失効日時が過去である場合は、構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１に、構成情報の変更を実行する許可通知を送信する。許可通知を受信したコンテナオーケストレータ１０１は、アプリＢコンテナ１０７の構成情報の変更（コンテナ数の増加）を実行する。

【0125】

なお、構成変更監視コンポーネント１０２は、変更抑制判定失効日時以降に、コンテナオーケストレータ１０１からアプリＢコンテナ１０７に係る構成変更要求通知を受信した場合には、構成情報の変更を実行する。すなわち、アプリＢコンテナ１０７の構成情報の
変更が行われない状態が継続し続けることはなく、不都合は生じない。

【0126】

以上のように、アプリＡオペレータコンテナ１０４によるアプリＡコンテナ１０６の構成情報の変更の後は、一定時間、アプリＢオペレータコンテナ１０５による構成情報の変更が抑止、すなわち変更が遅延されている。
以下、構成変更監視処理ｓ５１の詳細を説明する。

【0127】

＜構成変更監視処理＞
図２０は、第２実施形態に係る構成変更監視処理ｓ５１の詳細を示すフローチャートである。

【0128】

構成変更監視コンポーネント１０２は、リソース操作情報表５０１を含む構成変更要求通知を受信する（Ｓ１７０１）。

【0129】

構成変更監視コンポーネント１０２は、ｓ１７０１で受信した構成変更要求通知に基づき、構成変更要求通知の送信元がオペレータであるか否かを判定する（ｓ１７０２）。具体的には、構成変更監視コンポーネント１０２は、構成変更要求通知に含まれているリソース操作情報表５０１の要求元識別子５０１０１を抽出し、抽出した内容が、ＯＰ－ＳＡ対応表２０１の各行のサービスアカウント識別子２０１０２のいずれかと一致するか否かを判定する。

【0130】

構成変更要求通知の送信元がオペレータである場合は（ｓ１７０３：ＹＥＳ）、構成変更監視コンポーネント１０２はｓ１７０４の処理を実行し、構成変更要求通知の送信元がオペレータでない場合は（ｓ１７０３：ＮＯ）、構成変更監視コンポーネント１０２は構成変更監視処理ｓ５１を終了する。

【0131】

Ｓ１７０３において構成変更監視コンポーネント１０２は、構成変更操作履歴表８０２を参照することで、構成変更要求通知の要求元のオペレータと異なる、過去所定時間以内に構成情報の変更を行ったオペレータが存在するか否かを確認する（なお、過去所定時間以内に構成情報の変更を行った全てのオペレータとしてもよい）。例えば、構成変更監視コンポーネント１０２は、構成変更操作履歴表８０２のオペレータ識別子を参照して、構成変更要求通知の要求元のオペレータと異なるオペレータのレコードを抽出し、抽出したレコードの変更抑制判定失効日時８０２０２が示す日時が現在未だ到来していないレコードがあるか否かを検索する。

【0132】

過去所定時間以内に構成情報の変更を行った他オペレータが存在する場合は（Ｓ１７０３：ＹＥＳ）、構成変更監視コンポーネント１０２はＳ１７０４の処理を実行し、過去所定時間以内に構成情報の変更を行った他オペレータが存在しない場合は（Ｓ１７０３：ＮＯ）、構成変更監視コンポーネント１０２はＳ１７０５の処理を実行する。

【0133】

Ｓ１７０５において構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１に対して、構成情報の変更を却下する通知を返信する。その後、構成変更監視処理ｓ５１は終了する。

【0134】

Ｓ１７０４において構成変更監視コンポーネント１０２は、構成変更要求通知が示す構成情報の変更を、構成変更操作履歴表８０２に追加する。

【0135】

具体的には、構成変更監視コンポーネント１０２は、構成変更操作履歴表８０２の通知情報識別子、オペレータ識別子、要求元識別子、更新後情報、及び発生日時８０２０３には、Ｓ１７０１にて受信したリソース操作情報表５０１から抽出した値を設定する。変更
抑制判定失効日時８０２０２には、オペレータごとに決定された所定の時間を発生日時から経過させた時刻が設定される。

【0136】

そして、構成変更監視コンポーネント１０２は、コンテナオーケストレータ１０１に構成情報の変更の許可の通知を返信する（Ｓ１７０６）。その後、構成変更監視処理ｓ５１は終了する。

【0137】

例えば、アプリＡオペレータコンテナ１０４による構成情報の変更（コンテナ数の変更）が、時刻「２０２１－０３－０２Ｔ０９：３０：００Ｚ」に実施されるとする（発生日時）。すると、Ｓ１７０１においては、図１２に示すリソース操作情報表５０１を含む構成変更要求通知に含まれるデータが、コンテナオーケストレータ１０１から構成変更監視コンポーネント１０２に送信される。その後、Ｓ１７０５においては、図６に示す構成変更操作履歴表８０２の行Ｒ８０２０１にデータが追加される。ここで、図６に示す変更抑制判定失効日時８０２０２がアプリＡオペレータコンテナ１０４に係る構成情報の変更から所定時間後（５分後）の時刻「２０２１－０３－０２Ｔ０９：３５：００Ｚ」に設定されている。なお、この所定時間は、すべてのオペレータのすべての処理に対して同じとしてもよいし、各オペレータの処理ごとに異ならせてもよい。

【0138】

このように、構成変更監視処理ｓ５１は、オペレータによる構成情報の変更イベントを検出し、過去所定時間以内に他のオペレータによる構成情報の変更履歴が存在した場合はコンテナオーケストレータ１０１における構成情報の変更を中止させ、構成情報の変更履歴が存在しない場合はコンテナオーケストレータ１０１における構成情報の変更処理を続行させる。
＜メトリクスデータ送信処理＞
図２０は、第２実施形態に係るメトリクスデータ送信処理ｓ１の一例を説明するフローチャートである。なお、メトリクスデータ送信処理ｓ１１の開始のタイミングは、第１実施形態と同様である。ここでは、時刻「２０２１－０３－０２Ｔ０９：３２：００Ｚ」に、アプリＢオペレータコンテナ１０５によってメトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」である最新のメトリクスデータの送信が要求された場合を説明する。

【0139】

監視データストア１０３は、第１実施形態と同様に、アプリＢオペレータコンテナ１０５から、メトリクスデータを送信するためのリクエストを受信する（Ｓ１９０１）。例えば、このリクエストには、アプリＢオペレータコンテナ１０５が要求するメトリックのメトリック識別子「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」が含まれる。

【0140】

監視データストア１０３は、第１実施形態と同様に、リクエストを受信すると、このリクエストに対応する最新のメトリクスデータをメトリクスデータ表８０１から取得する（Ｓ１９０２）。図２０の例では、メトリクスデータ表８０１における、メトリック識別子が「ｃｏｎｔａｉｎｅｒ－ｘｂｋｖｆ８ｆｅ－ｒｅｓｐｏｎｓｅｔｉｍｅ」である行のうち時刻が最新の行Ｒ８０１０１を取得する。

【0141】

監視データストア１０３は、Ｓ１９０２で取得したメトリクスデータを、オペレータコンテナ１１０に送信する。例えば、監視データストア１０３は、メトリクスデータをアプリＢオペレータコンテナ１０５に送信する。以上でメトリクスデータ送信処理ｓ１は終了する。

【0142】

以上のように、第２実施形態に係るコンテナ管理システム１００は、第１のオペレータ（例えば、アプリＡオペレータ１０４）によるその発生日時でのコンテナの構成情報の変
更の実行を検知した場合に、第２のオペレータ（例えば、アプリＢオペレータ１０５）によるコンテナの構成情報の変更の要求を受信し、受信したタイミングが、変更抑制判定失効日時を経過している場合にのみ、第２のオペレータによるコンテナの構成情報の変更を実行する。

【0143】

これにより、変更抑制判定失効日時以前に第２のオペレータから要求された構成情報の要求は却下され、複数のオペレータによるコンテナの構成情報の変更が安定的にコントロールされることとなる。

【0144】

本発明は以上に説明した実施形態に限定されるものではなく、様々な変形例が含まれる。上記した実施形態は本発明のより良い理解のために詳細に説明したものであり、必ずしも説明の全ての構成を備えるものに限定されるものではない。

【0145】

例えば、各実施例の各装置が備える各機能の一部は他の装置に設けてもよいし、別装置が備える機能を同一の装置に設けてもよい。

【0146】

また、本実施形態の構成情報はコンテナにおける構成情報を想定したが、それ以外のリソースに関する構成情報であっても、本発明のコンテナ管理システムは適用可能である。例えば、仮想マシン（Virtual Machine）の構成情報であっても適用可能である。

【符号の説明】

【0147】

１００ コンテナ管理システム、１０１ コンテナオーケストレータ、１０２ 構成変更監視コンポーネント、１０３ 監視データストア、１３０ コンテナ、１１０ オペレータコンテナ、１２０ アプリコンテナ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【手続補正書】

【提出日】2021-06-17

【手続補正1】

【補正対象書類名】明細書

【補正対象項目名】００４５

【補正方法】変更

【補正の内容】

【0045】

コンテナオーケストレータ１０１は、処理続行許可を受信すると、コンテナの作成処理を実施する（ｓ１０４）。この処理によって、アプリＡオペレータコンテナ１０４のインスタンス（コンテナの実体）が作成される（ｓ１０５）。
ここで、ＯＰ－ＳＡ対応表更新実行処理ｓ１０２の詳細を説明する。

【手続補正2】

【補正対象書類名】図面

【補正対象項目名】図８

【補正方法】変更

【補正の内容】

【図8】