Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
JP7513866B2 - 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム - Google Patents
[go: Go Back, main page]

JP7513866B2 - 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム - Google Patents

移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム Download PDF

Info

Publication number
JP7513866B2
JP7513866B2 JP2020036593A JP2020036593A JP7513866B2 JP 7513866 B2 JP7513866 B2 JP 7513866B2 JP 2020036593 A JP2020036593 A JP 2020036593A JP 2020036593 A JP2020036593 A JP 2020036593A JP 7513866 B2 JP7513866 B2 JP 7513866B2
Authority
JP
Japan
Prior art keywords
container
node
containers
interference
moved
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.)
Active
Application number
JP2020036593A
Other languages
English (en)
Other versions
JP2021140385A (ja
Inventor
敦史 北田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2020036593A priority Critical patent/JP7513866B2/ja
Priority to EP20215464.7A priority patent/EP3876097B1/en
Priority to US17/129,406 priority patent/US12032982B2/en
Publication of JP2021140385A publication Critical patent/JP2021140385A/ja
Application granted granted Critical
Publication of JP7513866B2 publication Critical patent/JP7513866B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • G06F9/5088—Techniques for rebalancing the load in a distributed system involving task migration
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラムに関する。
コンピュータを仮想化する技術としてVM(Virtual Machine)仮想化技術とコンテナ仮想化技術が知られている。このうち、VM仮想化技術は、ホストOS(Operating System)の上でゲストOSを実行することにより仮想化を行う技術であり、ゲストOSを実行するためのオーバヘッドが大きい。
一方、コンテナ仮想化技術は、ゲストOSのカーネルの一部のみを利用して仮想化を行う技術である。このように一部のカーネルのみを利用するため、コンテナ仮想化技術は、VM仮想化技術と比較して仮想化のオーバヘッドが小さく軽量であるという利点がある。そのコンテナ仮想化技術においては、互いに独立した複数のユーザ空間が生成される。これらのユーザ空間はコンテナと呼ばれ、そのコンテナの各々においてアプリケーションプログラムが実行される。また、コンテナを生成するプログラムであるコンテナエンジンとしては例えばDOCKER（登録商標）がある。
コンテナは、前述のように仮想化のためのオーバヘッドが小さいため、ノード間での移動を容易に行うことができる。そのため、複数のノードの各々にコンテナを生成することにより、スケーラビリティに優れたシステムを容易に構築することが可能となる。
しかし、このようにコンテナを利用したシステムにおいては、コンテナの性能が低下するのを抑制するという点で改善の余地がある。
特開２０１７－９１００１号公報 特開２０１５－１５２９８４号公報 特開２０１７－７３０４５号公報
一側面によれば、コンテナの性能が低下するのを抑制することを目的とする。
一側面によれば、複数のコンテナを実行する第１のノードが、前記第１のノードが使用しているリソースの使用率が増加した時間帯でレスポンスタイムが増加する２以上のコンテナは、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超えない第１コンテナと、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超える第２コンテナとを含み、前記第１コンテナを、他のノードに移動するコンテナとして決定する処理を実行する移動対象コンテナ決定方法が提供される。
一側面によれば、コンテナの性能が低下するのを抑制することができる。
図１は、検討に使用したシステムの構成図である。 図２は、問題について説明するためのノードの模式図である。 図３は、コンテナ同士の干渉を解消する方法について模式的に示す図である。 図４は、第１実施形態に係るシステムのシステム構成図である。 図５は、第１実施形態に係るノードのハードウェア構成図である。 図６は、第１実施形態に係る一つのノードの模式図である。 図７は、第１実施形態において干渉に弱いコンテナを決定する方法について示す模式図である。 図８は、第１実施形態における干渉指数の定義について示す模式図である。 図９は、第１実施形態におけるノード同士の干渉指数の授受を模式的に示す図である。 図１０は、第１実施形態に係るノードの機能構成図である。 図１１は、第１実施形態に係る性能低下判定部の処理について示す模式図である。 図１２は、第１実施形態係る移動対象コンテナ決定方法のフローチャートである。 図１３は、第１実施形態において複数のノード間で干渉指数情報を共有する方法のフローチャートである。 図１４は、第１実施形態においてコンテナの移動先のノードを決定する方法のフローチャートである。 図１５は、第１実施形態におけるコンテナの移動方法のフローチャートである。 図１６は、第２実施形態に係るシステムのシステム構成図である。 図１７は、第２実施形態における代表のノードの動作を示すフローチャートである。 図１８は、第３実施形態に係るノードの機能構成図である。 図１９は、第３実施形態に係るコンテナの移動方法のフローチャートである。
本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。
図１は、検討に使用したシステムの構成図である。
このシステム１は、PC(Personal Computer)等の利用者端末２に対してWebサービスを提供するためのシステムであって、複数のノード３を有する。各々のノード３は例えば物理サーバである。以下では、ノード３の各々を一意に識別する文字列「node #1」、「node #2」、及び「node #3」で各ノード３を識別する。
また、各ノード３は、ホストOSを実行するための物理的なリソースを有する。そのようなリソースとしては、例えばCPU(Central Processing Unit)、メモリ、ストレージ、及びNIC(Network Interface Card)がある。そして、ホストOSの上でDOCKER（登録商標）等のコンテナエンジンが実行される。
コンテナエンジンは、その上で複数のコンテナ４を起動するためのプログラムである。そして、そのコンテナ４の内部において、種々の処理を行うためのアプリケーションプログラムであるアプリ５が実行される。
また、各ノード３は、NICを介してネットワーク７に接続されており、これにより各ノード３が相互にアクセス可能となる。なお、ネットワーク７は、例えばインターネットである。
この例では、ノード３の各々が協働して３層アーキテクチャを構築する場合を想定している。この場合、「node #1」のノード３においては、Webサーバを実現するためのアプリ５が実行される。また、「node #2」のノード３においては、アプリサーバを実現するためのアプリ５が実行される。そして、「node #3」のノード３においては、DB(Database)サーバを実現するためのアプリ５が実行される。
このようなアーキテクチャの場合は、「node #1」のWebサーバが、利用者端末２からサービスの要求を受け付ける。そして、「node #2」のアプリサーバが、サービスの提供に必要なデータを「node #3」のDBサーバから取得する。更に、そのアプリサーバがデータに対して所定の処理を行い、処理の結果を「node #1」のWebサーバを介して利用者端末２に返す。
このように機能が異なる複数のアプリ５を組み合わせて一つの処理を行うアーキテクチャはマイクロサービスと呼ばれる。特に、ゲストOSが不要なコンテナ４は軽量であるため、ノード３の間でのマイグレーションを短時間で容易に実行することができ、スケーラビリティに優れたマイクロサービス用のシステムを構築することができる。但し、このシステム１には次のような問題がある。
図２は、その問題について説明するためのノード３の模式図である。
VM仮想化技術では、仮想化ソフトが複数のVMの各々に対してリソースを占有的に割り当てる。例えば、一番目のVMに対してCPUの一番目のコアが割り当てられた場合には、二番目のVMに対してはCPUの二番目のコアが割り当てられる。これにより、各々のVMは、自身に割り当てられたリソースを独占的に使用することができる。
一方、コンテナ仮想化技術においては、コンテナ４にリソースを割り当てる権限はホストOSが有しており、コンテナエンジンにその権限はない。そのため、図２に示すようにCPU等の一つのリソースが複数のコンテナ４に対して割り当てられてしまい、複数のコンテナ４が一つのリソースを共有する場合が生じる。この場合、複数のコンテナ４が一つのリソースを奪い合うことになるため、リソースを介してコンテナ４同士が相互に干渉し合い、各コンテナ４のレスポンスタイム等の性能が低下してしまう。
リソースにはCPUやメモリ等があるが、このうちのどのリソースがコンテナ４同士の干渉を仲介するかは、各コンテナ４で実行するアプリ５の特性に依存する。
例えば、DBサーバ用のアプリ５を実行するコンテナ４は、DBが格納されたストレージに頻繁にアクセスする傾向がある。よって、そのコンテナ４は、ストレージを介して他のコンテナ４に干渉する可能性が高い。
一方、アプリサーバ用のアプリ５を実行するコンテナ４は、ストレージにアクセスする頻度が少ないため、ストレージを介して他のコンテナ４に干渉する可能性は低い。
図３は、コンテナ４同士の干渉を解消する方法について模式的に示す図である。
あるリソースを介して相互に干渉し合う複数のコンテナ４が一つのノード３に集中した場合には、そのコンテナ４を別のノード３に移動すればよい。
図３の例では、「node #1」のノード３において、Webサーバ用のアプリ５を実行するコンテナ４と、他アプリ５を実行するコンテナ４とがメモリを介して干渉している場合を想定している。この場合は、webサーバ用のアプリ５を実行するコンテナ４を「node #1」から「node #2」に移動することにより、「node #1」におけるコンテナ４同士の干渉を解消できる。
しかし、この例では、移動先の「node #2」において、Webサーバ用のアプリ５を実行するコンテナ４が、他アプリ５を実行するコンテナ４とメモリを介して再び干渉してしまっている。よって、Webサーバ用のアプリ５を実行するコンテナ４を、更に「node #2」から「node #3」に移動しなければならない。
このように、コンテナ４の移動先のノード３を適当に選択したのでは、移動先のノード３においてもコンテナ４同士が干渉してしまう。
特に、マイクロサービスにおいては、あるコンテナ４の処理の結果を他のコンテナ４が使用することによりサービスを実現する。よって、上記のように一つのコンテナ４の性能が低下すると、サービス自体のレスポンスタイム等の性能も低下してしまう。
なお、コンテナ４同士の干渉を避ける方法として、干渉の原因となるコンテナ４を特定し、それを他のノード３に移動することも考えられる。
例えば、図３の例では、「node #1」における他アプリ５がメモリに頻繁にアクセスしており、これが原因でメモリを介してコンテナ４同士が干渉している。この場合には、「node #1」の他アプリ５を実行するコンテナ４を「node #2」のノード３に移動させれば「node #1」における干渉が解消される。しかし、このように干渉の原因となっているコンテナ４を「node #2」に移動させると、「node #2」においても当該コンテナ４が原因で干渉が発生する可能性がある。これを避けるには、干渉の原因となっているコンテナ４を専用のノード３で実行すればよいが、これではシステムのコストが増加してしまう。
以下に、コンテナの性能低下を抑制し得る各実施形態について説明する。
（第１実施形態）
図４は、本実施形態に係るシステムのシステム構成図である。
このシステム２１は、PC等の利用者端末２２に対してサービスを提供するためのシステムであって、複数のノード２３を有する。各々のノード２３は例えば物理サーバであり、インターネット等のネットワーク２４を介して相互に接続される。ここでは、ノード２３の各々を一意に識別する文字列「node #1」、「node #2」、…「node #n」で各ノード２３を識別する。
なお、クラウド事業者が提供するクラウドサービスを利用してこのシステム２１を構築してもよい。この場合は、クラウド事業者のデータセンタにある物理サーバがノード２３となる。
図５は、ノード２３のハードウェア構成図である。
図５に示すように、ノード２３は、ストレージ２３ａ、メモリ２３ｂ、CPU２３ｃ、NIC２３ｄ、表示装置２３ｅ、入力装置２３ｆ、及び記録媒体２３ｈを有する。これらの各部は、バス２３ｇにより相互に接続される。
このうち、ストレージ２３ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性の記憶装置である。この例では、ストレージ２３ａは、ホストOS２６、コンテナエンジン２７、及び移動対象コンテナ決定プログラム２８を記憶する。このうち、ホストOSとしては、例えばLinux（登録商標）の各ディストリビューションのOSを採用し得る。また、コンテナエンジン２７は例えばDOCKER（登録商標）である。そして、移動対象コンテナ決定プログラム２８は、後述のようにコンテナを別のノードに移動するプログラムである。
なお、移動対象コンテナ決定プログラム２８をコンピュータが読み取り可能な記録媒体２３ｈに記録させておき、CPU２３ｃに記録媒体２３ｈの移動対象コンテナ決定プログラム２８を読み取らせるようにしてもよい。
そのような記録媒体２３ｈとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体２３ｈとして使用してもよい。これらの記録媒体２３ｈは、物理的な形態を持たない搬送波のような一時的な媒体ではない。
更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置に移動対象コンテナ決定プログラム２８を記憶させてもよい。その場合は、CPU２３ｃがその移動対象コンテナ決定プログラム２８を読み出して実行すればよい。
一方、メモリ２３ｂは、DRAM等のようにデータを一時的に記憶するハードウェアであって、その上にホストOS２６、コンテナエンジン２７、及び移動対象コンテナ決定プログラム２８が展開される。
CPU２３ｃは、ノード２３の各部を制御するプロセッサである。また、CPU２３ｃは、メモリ２３ｂと協働してホストOS、コンテナエンジン２７、及び移動対象コンテナ決定プログラム２８を実行する。
更に、NIC３０ｄは、ノード２３をネットワーク２４に接続するための通信インターフェースである。
そして、表示装置２３ｅは、液晶表示装置等のハードウェアであって、システム２１の管理者に種々の情報を表示する。また、入力装置２３ｆは、キーボードやマウス等のハードウェアである。例えば、管理者は、入力装置２３ｆを操作することにより、ノード２３に対して種々の指示を出すことになる。
図６は、本実施形態に係る一つのノード２３の模式図である。
図６に示すように、ノード２３においては、物理的なリソースの上でホストOSが実行される。そのリソースとしては、図５のストレージ２３ａ、メモリ２３ｂ、CPU２３ｃ、及びNIC２３ｄがある。
そして、ノード２３がホストOS２６の上でコンテナエンジン２７を実行することにより複数のコンテナ３１が起動する。以下では、各コンテナ３１を「#1」、「#2」、…「#m」の文字列で識別する。また、各々のコンテナ３１の内部では一つのアプリ３２が実行される。アプリ３２は、システム２１が提供するサービスに必要な処理を実行するためのアプリケーションプログラムである。
図２の例と同様に、このノード２３においてもリソースを介して各コンテナ３１同士が干渉することがある。干渉を受けたコンテナ３１は、他のコンテナ３１がリソースを占有している等の理由により、レスポンスタイム等の性能が低下してしまう。
以下では、リソースを介して互いに干渉し合っている複数のコンテナ３１のうちで性能低下が最も著しいコンテナ３１を、そのリソースを介した干渉に弱いコンテナと呼ぶ。本実施形態では、各ノード２３が干渉に弱いコンテナ３１を以下のように決定し、そのコンテナ３１を他のノード２３に移動する。
図７は、本実施形態において干渉に弱いコンテナ３１を決定する方法について示す模式図である。
この例では、コンテナ３１同士の干渉を仲介するリソースがCPU２３ｃであるときに、「#1」、「#2」、「#3」のコンテナ３１のうちで干渉に弱いコンテナを特定する場合を想定している。
この場合は、P1に示すように、「#1」、「#2」、「#3」の各コンテナ３１を実行している一つのノード２３の全体でのCPU２３ｃの使用率に着目する。ノード２３の全体でのCPU２３ｃの使用率は、各コンテナ３１の稼働状態等に応じて時間と共に変化する。この例では、時刻t1から時刻t2までの時間帯T1と、時刻t3から時刻t4までの時間帯T2において、CPU２３ｃの使用率が急激に増加している。このような場合、時間帯T1と時間帯T2の各々において、「#1」、「#2」、「#3」のコンテナ３１のいずれかがCPU２３ｃで重い処理を実行しており、そのコンテナ３１が原因でCPU２３ｃの使用率が増加していると考えられる。
この場合に干渉に弱いコンテナ３１を決定するために、本実施形態では各コンテナ３１のデータ処理量、CPU２３ｃの使用率、及びレスポンスタイムを使用する。このうち、レスポンスタイムは、コンテナ３１の外部のプロセスが、当該コンテナ３１で実行中のアプリ３２に処理を依頼してからその処理の結果を受け取るまでの時間である。コンテナ３１が干渉を受けていると、そのコンテナ３１の性能が低下してレスポンスタイムが増大する。よって、レスポンスタイムは、コンテナ３１の性能が低下したかどうかを判断する指標となる。
また、あるコンテナ３１におけるデータ処理量は、例えば単位時間にそのコンテナ３１が処理したデータのビット数として定義される。そして、あるコンテナ３１のCPU２３ｃの使用率は、当該コンテナ３１の実行時間が、ノード２３の全体のCPU２３ｃの処理時間を占有している割合として定義される。
P2に示すように#1のコンテナ３１に着目すると、時間帯T1と時間帯T2において、「#1」のコンテナ３１のデータ処理量とCPU２３ｃの使用率は変化していない。
仮に「#1」のコンテナ３１が原因でP1のようにCPU２３ｃの使用率が増加したのであれば、「#1」のコンテナ３１のデータ処理量とCPU２３ｃの使用率の少なくとも一方が時間帯T1や時間帯T2において増加するはずである。しかし、このような増加がみられないということは、「#1」のコンテナ３１とは別のコンテナ３１が原因でCPU２３ｃの使用率が増加したものと推定できる。
また、「#1」のコンテナ３１のレスポンスタイムに着目すると、時間帯T1と時間帯T2においてレスポンスタイムが増加している。ここでは、ある時間帯におけるレスポンスタイムの増加量ΔRを、その時間帯におけるレスポンスタイムの最大値と最小値との差として定義する。
「#1」のコンテナ３１自身は各時間帯T1、T2で重い処理をしていないにも関わらず、この例では各時間帯T1、T2における増加量ΔRが顕著となっており、「#1」のコンテナ３１の性能が低下している。よって、#1のコンテナ３１は、CPU２３ｃを介して他のコンテナ３１から干渉を受け易いコンテナであると判断できる。
次に、P3に示すように「#2」のコンテナ３１に着目する。「#1」のコンテナ３１と同様に、「#2」のコンテナ３１のデータ処理量とCPU２３ｃの使用率は大きく変化していない。よって、P1のように各時間帯T1、T2においてCPU２３ｃの使用率が増加した原因は「#2」のコンテナ３１ではないことが分かる。
更に、「#2」のコンテナ３１においては、各時間帯T1、T2においてレスポンスタイムも変化していない。したがって、「#2」のコンテナ３１は、ノード全体でのCPU２３ｃの使用率が増加してもレスポンスタイム等の性能が低下し難く、CPU２３ｃを介して他のコンテナ３１から干渉を受け難いコンテナであると判断できる。
次に、P4に示すように「#3」のコンテナ３１に着目する。「#3」のコンテナ３１は、各時間帯T1、T2においてデータ処理量とCPU２３ｃの使用率が増加している。
ここでは、ある時間帯におけるコンテナ３１のデータ処理量の増加量ΔDを、その時間帯におけるデータ処理量の最大値と最小値との差として定義する。同様に、ある時間帯におけるコンテナ３１のCPU２３ｃの使用率の増加量ΔBcを、その時間帯における当該コンテナ３１のCPU２３ｃの使用率の最大値と最小値との差として定義する。
「#3」のコンテナ３１においては、各時間帯T1、T2において増加量ΔD、ΔBcが顕著となっている。よって、P1のように各時間帯T1、T2においてノード２３の全体のCPU２３ｃの使用率が増加した原因が「#3」のコンテナ３１にあると判断できる。
更に、「#3」のコンテナ３１のレスポンスタイムは各時間帯T1、T2において増加している。これは、「#3」のコンテナ３１自身がCPU２３ｃで重い処理を実行したことが原因で自身の性能が低下したためと判断できる。
以上の結果から、「#1」のコンテナ３１が、CPU２３ｃを介した干渉に弱いコンテナであると決定できる。更に、「#2」のコンテナ３１がCPU２３ｃを介した干渉に強いコンテナであり、「#3」のコンテナ３１が干渉の原因のコンテナであると決定できる。
このように干渉に弱いコンテナ３１をノード２３が決定するために、本実施形態では、時間帯T1においてコンテナ３１のレスポンスタイムの増加量ΔRが所定値R0を超えたかをノード２３が判断する。所定値R0は、当該コンテナ３１が干渉を受けているかどうかの目安となる値であって、予め試験等において定めておく。
また、増加量ΔRが所定値R0を超えた場合には、ノード２３は、そのコンテナ３１におけるCPU２３ｃの使用率の増加量ΔBcが時間帯T1において所定値BC0を超えたかを判断する。更に、ノード２３は、そのコンテナ３１におけるデータ処理量の増加量ΔDが時間帯T1において所定値D0を超えたかを判断する。各増加量ΔBc、ΔDは、コンテナ３１のレスポンスタイムの増加に影響を与えるパラメータの一例である。そして、所定値BC0、D0は、これらのパラメータが原因でレスポンスタイムが増加したかを判断する目安となる値であって、試験等において予め定めておく。
ここで、そのコンテナ３１のデータ処理量の増加量ΔDが所定値D0を超えておらず、かつCPU２３ｃの使用率の増加量ΔBcも所定値BC0を超えていない場合を考える。この場合は、ノード２３は、当該コンテナ３１のレスポンスタイムの増加量ΔRが所定値R0を超えた原因がそのコンテナ３１自身にはなく、当該コンテナ３１が他のコンテナ３１から干渉を受けていると判断する。
更に、ノード２３は、コンテナ３１の干渉を仲介しているリソースがCPU２３ｃであるかを判断するために、時間帯T1における自ノードの全体のCPU２３ｃの使用率の増加量ΔUcが所定値Uc0を超えたかを判断する。なお、使用率の増加量ΔUcは、時間帯T1におけるCPU２３ｃの使用率の最大値と最小値との差として定義される。また、所定値Uc0は、コンテナ３１同士の干渉を仲介するリソースがCPU２３ｃであることを特定するための値である。そして、ノード２３は、増加量ΔUcが所定値Uc0を超えている場合に、そのコンテナ３１が、CPU２３ｃを介した干渉に弱いコンテナであると決定する。
なお、この例では干渉を仲介するリソースがCPU２３ｃである場合について説明したが、CPU２３ｃ以外のリソースを介した干渉に弱いコンテナ３１も同様に決定できる。この場合は、コンテナ３１が使用するメモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々の使用率の増加量ΔBm、ΔBs、ΔBnの各々に対する所定値Bm0、Bs0、Bn0をノード２３が使用すればよい。なお、NIC２３ｄの各々の使用率は、NIC２３ｄに接続されたネットワークの帯域幅の使用率として定義される。そして、ノード２３の全体におけるメモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々の使用率の増加量ΔUm、ΔUs、ΔUnに対する所定値Um0、Us0、Un0をノード２３が使用すればよい。
ところで、図７におけるコンテナ３１同士の干渉を解消するには、干渉の原因となっている「#3」のコンテナ３１を他のノード２３に移動すればよいとも考えられる。しかし、これでは移動先のノード２３で再び「#3」のコンテナ３１が他のコンテナ３１に対して干渉する可能性がある。
そこで、本実施形態では、相互に干渉しているコンテナ３１のうちで、干渉に弱い「#1」のコンテナ３１を他のノード２３に移動する。「#1」のコンテナ３１は、干渉を発生させる原因のコンテナではなく、干渉を受けやすいコンテナである。よって、移動先のノード２３において「#1」のコンテナ３１が原因でコンテナ３１同士が干渉するのを抑制でき、移動先のノード２３の各コンテナ３１の性能が低下するのを抑えることができる。
また、複数のノード２３のなかには、コンテナ３１同士が干渉し易いノードと、コンテナ３１同士が干渉し難いノードがあると考えられる。
そこで、本実施形態では、以下のようにコンテナ３１が干渉を受けやすいかどうかを示す干渉指数をノード２３ごとに定義する。
図８は、本実施形態における干渉指数の定義について示す模式図である。
図８に示すように、あるノード２３の全体のCPU２３ｃの使用率の増加量が時間帯T1においてΔUcであるとする。また、そのノード２３の「#1」、「#2」、…「#m」の各コンテナ３１のレスポンスタイムの増加量が同じ時間帯T1においてそれぞれΔR1、ΔR2、…ΔRmであるとする。
この場合、CPU２３ｃについてのノード２３の干渉指数Xcは次の式（１）で定義される。
Figure 0007513866000001
式（１）に示すように、干渉指数Xcは、レスポンスタイムの増加量ΔR1、ΔR2、…ΔRmと使用率の増加量ΔUcとの比を全てのコンテナ３１について加算した値として定義される。この定義によれば、干渉指数Xcは、ノード２３の全体でのCPU２３ｃの使用率が増加したときに各コンテナ３１のレスポンスタイムが増加する程度を表すことになる。
なお、干渉指数Xcの関数形は式（１）に限定されない。各増加量ΔR1、ΔR2、…ΔRm、ΔUcの関数であって、ノード２３の全体のCPU２３ｃの使用率が増加したときに各コンテナ３１のレスポンスタイムが増加する程度を表す任意の関数を干渉指数Xcとして採用し得る。
その干渉指数Xcが小さい場合には、CPU２３ｃの使用率が増加しても各コンテナ３１のレスポンスタイムが大きくならない。よって、この場合には、そのノード２３は、各コンテナ３１がCPU２３ｃを介して相互に干渉し難いノードであると判断できる。
これと同様に、メモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々についての干渉指数Xm、Xs、Xnを以下のように定義する。
Figure 0007513866000002
Figure 0007513866000003
Figure 0007513866000004
以下では、各干渉指数の組(Xc, Xm, Xs, Xn)を干渉指数情報Gと呼ぶ。干渉指数情報Gは、ノード２３ごとに定義される情報であって、これを基にしてコンテナ３１の移動先のノード２３が決定される。
また、本実施形態では、各ノード２３が干渉指数情報Gを他の全てのノード２３に通知することにより、各ノード２３が全ノードの干渉指数情報Gを共有する。
図９は、本実施形態におけるノード２３同士の干渉指数情報Gの授受を模式的に示す図である。
図９においては、「node #1」、「node #2」、「node #3」、「node #4」の各ノード２３が相互に干渉指数情報Gを通知している場合を例示している。
これにより、各々のノード２３が、全ノードの干渉指数情報Gをメモリやストレージ等の記憶部に格納でき、これらの干渉指数情報Gに基づいてコンテナ３１の移動先のノード２３を決定できる。
例えば、「node #1」のノード２３の#1のコンテナ３１がCPU２３ａを介した干渉に弱く、当該コンテナ３１の移動先のノード２３をどこにするのかについて考える。
図９に示されるように、全てのノード２３のうちでCPU２３ａについての干渉指数Xcが最も小さく、CPU２３ａを介した干渉によってコンテナ３１の性能が低下し難いノードは「node #2」のノード２３である。よって、「node #2」に「node #1」の「#1」のコンテナ３１を移動させても、そのコンテナ３１が「node #2」で再び干渉を受けてその性能が低下するのを抑制できる。したがって、この場合は、「node #1」のノード２３は、自ノードで起動している「#1」のコンテナ３１の移動先を「node #2」に決定する。
次に、本実施形態に係るノード２３の機能構成について説明する。
図１０は、本実施形態に係るノード２３の機能構成図である。
図１０に示すように、ノード２３は、通信部４１、記憶部４２、コンテナ実行部４３、及び制御部４４を有する。
このうち、通信部４１は、NIC２３ｄ（図５参照）によって実現される処理部である。ここでは、通信部４１は、ネットワーク２４を介して自ノードを他のノード２３や利用者端末２２に接続するインターフェースとして機能する。
記憶部４２は、ストレージ２３ａ（図５参照）とメモリ２３ｂとによって実現され、ネットワーク２４に接続されている「node #1」～「node #n」の全てのノード２３の干渉指数情報Gを記憶する。
また、コンテナ実行部４３は、CPU２３ｃとメモリ２３ｂとが協働してコンテナエンジン２７を実行することにより実現される処理部である。そのコンテナ実行部４３により、一つのノード２３内に複数のコンテナ３１が起動することになる。
一方、制御部４４は、CPU２３ｃとメモリ２３ｂとが協働して移動対象コンテナ決定プログラム２８を実行することにより実現される処理部である。その制御部４４は、コンテナ監視部５１、使用率監視部５２、干渉指数算出部５３、コンテナ決定部５４、性能低下判定部５５、移動先決定部５６、及び移動実行部５７を有する。
このうち、コンテナ監視部５１は、複数のコンテナ３１の各々のレスポンスタイム、データ処理量、及びリソースの使用率を監視する処理部である。そのリソースの使用率としては、ストレージ２３ａ、メモリ２３ｂ、CPU２３ｃ、及びNIC２３ｄの各々の使用率がある。
一方、使用率監視部５２は、ノード２３の全体でのリソースの使用率を監視する処理部である。その使用率監視部５２が監視するリソースとしては、CPU２３ｃ、メモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄがある。ここでは、使用率監視部５２は、CPU監視部５２ｃ、メモリ監視部５２ｍ、ストレージ監視部５２ｓ、及びネットワーク監視部５２ｎを有する。
このうち、CPU監視部５２ｃはCPU２３ｃの使用率を監視し、メモリ監視部５２ｍはメモリ２３ｂの使用率を監視する。また、ストレージ監視部５２ｓはストレージ２３ａの使用率を監視する。そして、ネットワーク監視部５２ｎは、NIC２３ｄに接続されたネットワークの帯域幅の使用率を監視する。
干渉指数算出部５３は、図８に示した方法に従って自ノード２３の干渉指数情報Gを算出し、それを記憶部４２に格納する処理部である。前述のように、その干渉指数情報Gには、リソースごとの干渉指数Xc、Xm、Xs,、Xnが含まれる。また、干渉指数算出部５３は、自ノード２３の干渉指数情報Gを、通信部４１を介して他のノード２３に通知する。
通信部４１は、他のノード２３の干渉指数情報Gを受信し、それを記憶部４２に格納する。
コンテナ決定部５４は、他のノード２３に移動するコンテナ３１を決定する処理部である。例えば、コンテナ決定部５４は、図７に示した方法に従ってあるリソースを介した干渉に弱いコンテナ３１を特定し、そのコンテナ３１を他のノード２３に移動するコンテナであると決定する。
性能低下判定部５５は、コンテナ決定部５４が決定したコンテナ３１の性能が、実際に他のノード２３に移動しなければならない程度に低下したかどうかを判定する処理部である。
図１１は、第１実施形態に係る性能低下判定部５５の処理について示す模式図である。
性能低下判定部５５は、コンテナ監視部５１が監視したコンテナ３１のレスポンスタイムRが閾値Rthを超えたかを判断する。閾値Rthは、コンテナ３１を別のノード２３に移動しなければならない程度にコンテナ３１の性能が低下したかを判断する目安となる値である。
そして、性能低下判定部５５は、レスポンスタイムRが閾値Rthを超えた時刻txにコンテナ３１の性能が低下したと判定する。
再び図１０を参照する。
移動先決定部５６は、記憶部４２が記憶する全ノード２３の干渉指数情報Gを参照して、コンテナ３１の移動先のノード２３を決定する処理部である。例えば、CPU２３ｃを介した干渉に弱いコンテナ３１がコンテナ決定部５４により決定されたとする。この場合、移動先決定部５６は、複数のノード２３のうちで、CPU２３ｃについての干渉指数Xcが最も小さいノード２３をコンテナ３１の移動先として決定する。
移動実行部５７は、実際にコンテナ３１を他のノード２３に移動する処理部である。移動対象のコンテナ３１は、コンテナ決定部５４によって干渉に弱いと判断されたコンテナ３１である。また、移動をするタイミングは、性能低下判定部５５によって性能が低下したと判定されたタイミングである。そして、移動先のノード２３は、移動先決定部５６によって決定されたノード２３である。
次に、本実施形態に係る移動対象コンテナ決定方法について説明する。
図１２は、本実施形態に係る移動対象コンテナ決定方法のフローチャートである。以下では、前述の図７を適宜参照しながら説明を行う。
このフローチャートは、実際にシステム２１で利用者端末２２に対してサービスを提供しながら、一つのノード２３における複数のコンテナ３１ごとに実行される。そこで、最初に図７の「#1」のコンテナ３１に対してこのフローチャートを実行する場合について説明する。
まず、使用率監視部５２が、自ノード２３の全体でのリソースの使用率Uの増加量ΔUを監視する（ステップＳ１０）。その増加量ΔUとしては、CPU２３ｃ、メモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々の使用率の増加量ΔUc、ΔUm、ΔUs、ΔUnがある。
次に、コンテナ監視部５１が、「#1」のコンテナ３１のレスポンスタイム、当該コンテナ３１が使用するリソースの使用率、及び当該コンテナ３１のデータ処理量の各々を監視する（ステップＳ１１）。このとき、コンテナ監視部５１は、コンテナ３１のレスポンスタイムの増加量ΔR、リソースの使用量の増加量ΔQ、及びデータ処理量の増加量ΔDも監視する。
次に、コンテナ決定部５４が、時間帯T1（図７参照）におけるレスポンスタイムが増加したかを判断する（ステップＳ１２）。なお、時間帯T1の開始時間やその長さは特に限定されず、任意に設定し得る。
また、レスポンスタイムが増加したかの判断基準として、ここでは前述の所定値R0を採用する。この場合、コンテナ決定部５４は、時間帯T1におけるレスポンスタイムの増加量ΔRが所定値R0を超えた場合にレスポンスタイムが増加したと判断し、そうでない場合にレスポンスタイムは増加していないと判断する。
ここで、増加量ΔRが所定値R0を超えていない場合（ステップＳ１２：否定）にはステップＳ１０に戻る。
一方、増加量ΔRが所定値R0を超えた場合（ステップＳ１２：肯定）にはステップＳ１３に移る。図７の#1のコンテナ３１においては、増加量ΔRが所定値R0を超えたと判断されるため、ステップＳ１３に移ることになる。
ステップＳ１３では、コンテナ決定部５４が、時間帯T1において#1のコンテナ３１が使用する複数のリソースのうちのいずれかの使用率Qの増加量ΔQが所定値Q0を超えたかを判断する。その増加量ΔQとしては、CPU２３ｃ、メモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々の使用率の増加量ΔBc、ΔBm、ΔBs、ΔBnがある。また、これらの使用率に対する所定値としては、前述のBc0、Bm0、Bs0、Bn0がある。
ここで、複数のリソースのうちのいずれかの使用率が所定値を超えた場合（ステップＳ１３：肯定）にはステップＳ１０に戻る。
一方、複数のリソースのうちのいずれの使用率も所定値を超えていない場合（ステップＳ１３：否定）にはステップＳ１４に移る。図７の#1のコンテナ３１においては、増加量ΔBc、ΔBm、ΔBs、ΔBnの各々が所定値Bc0、Bm0、Bs0、Bn0を超えていないため、ステップＳ１４に移ることになる。
ステップＳ１４においては、コンテナ決定部５４が、時間帯T1におけるコンテナ３１のデータ処理量の増加量ΔDが所定値D0を超えたかを判断する。
ここで、増加量ΔDが所定値D0を超えた場合（ステップＳ１４：肯定）にはステップＳ１０に戻る。
一方、増加量ΔDが所定値D0を超えていない場合（ステップＳ１４：否定）にはステップＳ１５に移る。図７の#1のコンテナ３１においては、増加量ΔDが所定値D0を超えていないため、ステップＳ１５に移ることになる。
ステップＳ１５においては、コンテナ決定部５４が、ノード２３の複数のリソースのうちのいずれかの使用率の増加量ΔUが所定値U0を超えたかを判断する。その増加量ΔUとしては、前述のようにCPU２３ｃ、メモリ２３ｂ、ストレージ２３ａ、及びNIC２３ｄの各々の使用率の増加量ΔUc、ΔUm、ΔUs、ΔUnがある。また、所定値U0としてはUc0、Um0、Us0、Un0がある。
ここで、複数のリソースのうちのいずれの使用率の増加量ΔUも所定値U0を超えていない場合（ステップＳ１５：否定）にはステップＳ１０に戻る。
一方、複数のリソースのうちのいずれかの使用率の増加量ΔUが所定値U0を超えた場合（ステップＳ１５：肯定）にはステップＳ１６に移る。図７の例では、ノード２３の全体のCPU２３ｃの使用率の増加量ΔUcが時間帯T1において所定値Uc0を超えているためステップＳ１６に移ることになる。
ステップＳ１６においては、ステップＳ１２においてR0<ΔRと判断され、かつステップＳ１５においてU0<ΔUと判断される事象が複数の時間帯に発生したかをコンテナ決定部５４が判断する。
ここで、そのような事象が発生していない場合（ステップＳ１６：否定）にはステップＳ１０に戻る。
一方、当該事象が発生した場合（ステップＳ１６：肯定）にはステップＳ１７に移る。図７の例では、時間帯T1と時間帯T2においてこのような事象が発生しているためステップＳ１７に移ることになる。
ステップＳ１７においては、コンテナ決定部５４が、このコンテナ３１が干渉に弱いコンテナであり、他ノード２３に移動する対象となるコンテナであると決定する。また、コンテナ決定部５４は、そのコンテナ３１の干渉を仲介するリソースが、ステップＳ１５で使用率の増加量ΔUが所定値U0を超えたと判断されたリソースであると決定する。
以上により、本実施形態に係る移動対象コンテナ決定方法の基本ステップを終了する。
この後は、一つのノード２３に起動している残りのコンテナ３１の各々に上記の各処理を行うことにより、当該ノード２３における全てのコンテナ３１に対して干渉に弱いかどうかの決定を行う。
この方法によれば、時間帯T1においてノード２３の全体のリソースの使用率Uが増加した場合（ステップＳ１５：肯定）に、当該ノード２３で実行しているコンテナ３１を干渉に弱いかどうかの判断対象とする。更に、そのコンテナ３１のレスポンスタイムが時間帯T1で増加し（ステップＳ１２：肯定）、かつパラメータΔQ、ΔDが所定値を超えないときに（ステップＳ１３、Ｓ１４：否定）、コンテナ３１は干渉に弱いと判断する。これによれば、ノード２３全体のリソースの使用率Uや、コンテナ３１のレスポンスタイムと各パラメータΔQ、ΔDを監視することにより、当該コンテナ３１が干渉に弱いかどうかを簡単に決定できる。
なお、ここではステップＳ１３とステップＳ１４とを直列的に行うことで、二つのパラメータΔQ、ΔDの両方が所定値を越えない場合にコンテナ３１が干渉に弱いかどうかを判断したが、本実施形態はこれに限定されない。例えば、二つのパラメータΔQ、ΔDのいずれか一方のみが所定値を超えた場合にコンテナ３１が干渉に弱いかどうかの判断を行ってもよい。
しかも、ステップＳ１６では、コンテナ３１のレスポンスタイムが増加した時間帯が複数存在し、かつ各時間帯で使用率Uが増加したかの判断を行う。これにより、コンテナ３１が干渉に強いにも関わらず、一つの時間帯で偶然に使用率Uと当該コンテナ３１のレスポンスタイムとが同時に増加した場合を排除でき、コンテナ３１が干渉に弱いかの判断が正確となる。なお、判断の正確性が問題にならない場合にはステップＳ１６を省いてもよい。
更に、ΔR、ΔQ、ΔD、及びΔUの各値をリアルタイムに監視した結果をステップＳ１２～Ｓ１５で使用するため、これらの監視結果に基づいてコンテナ３１が干渉に弱いかをコンテナ決定部５４がリアルタイムに判断できる。
次に、複数のノード２３間で干渉指数情報Gを共有する方法について説明する。
図１３は、第１実施形態において複数のノード２３間で干渉指数情報Gを共有する方法のフローチャートである。
まず、各ノード２３の使用率監視部５２が、ある時間帯T1における自ノードの複数のリソースの各々の使用率の増加量ΔUを監視する（ステップＳ２１）。
例えば、使用率監視部５２のCPU監視部５２ｃがCPU２３ｃの使用率の増加量ΔUcを監視し、メモリ監視部５２ｍがメモリ２３ｂの使用率の増加量ΔUmを監視する。そして、ストレージ監視部５２ｓがストレージ２３ａの使用率の増加量ΔUsを監視し、ネットワーク監視部５２ｎがNIC２３ｄの使用率の増加量ΔUnを監視する。
次に、コンテナ監視部５１が、「#1」、「#2」、…「#m」の各コンテナ３１の時間帯T1におけるレスポンスタイムの増加量ΔR1、ΔR2、…ΔRmを監視する（ステップＳ２２）。
次いで、干渉指数算出部５３が、前述の使用率の増加量ΔUc、ΔUm、ΔUs、ΔUnとレスポンスタイムの増加量ΔR1、ΔR2、…ΔRmとを用いて干渉指数Xc、Xm、Xs、Xnを算出する（ステップＳ２３）。これらの干渉指数Xc、Xm、Xs、Xnは、前述の式（１）～（４）に従って干渉指数算出部５３によって算出される。また、干渉指数算出部５３は、干渉指数Xc、Xm、Xs、Xnを干渉指数情報Gとして記憶部４２に格納する。
次いで、通信部４１が、自ノードの干渉指数情報Gを他のノード２３の全てに通知する（ステップＳ２４）。この後は、再びステップＳ２１に戻り、ステップＳ２１～Ｓ２４を定期的に繰り返す。なお、繰り返す度に干渉指数算出部５３が全ノードの干渉指数情報Gの移動平均を計算し、それを新たな干渉指数情報Gとして記憶部４２に格納してもよい。
以上により、全てのノード２３において干渉指数情報Gを共有することができる。
次に、コンテナ３１の移動先のノード２３を決定する方法について説明する。
図１４は、第１実施形態においてコンテナ３１の移動先のノード２３を決定する方法のフローチャートである。
まず、図１２のフローチャートを実行することにより、コンテナ決定部５４が、自ノードに起動している複数のコンテナ３１のうち、あるリソースを介した干渉に弱いコンテナを決定する（ステップＳ３１）。以下では、CPU２３ｃを介した干渉に弱いコンテナ３１をコンテナ決定部５４が決定した場合を例にして説明する。
次に、移動先決定部５６が、記憶部４２に格納されている全てのノード２３の干渉指数情報Gを参照することにより、干渉指数が最も小さいノード２３を抽出する（ステップＳ３２）。
例えば、上記のようにCPU２３ｃを介した干渉に着目している場合は、移動先決定部５６は、全てのノード２３のうちでCPU２３ｃについての干渉指数Xcが最も小さいノード２３を抽出する。
そして、移動先決定部５６が、抽出したノード２３を移動先のノードとして決定する（ステップＳ３３）。
以上により、リソースを介した干渉に弱いコンテナ３１の移動先のノード２３を決定することができる。
このような移動先のノード２３の決定方法によれば、ステップＳ３２、Ｓ３３において、移動先決定部５６が、干渉指数が最も小さいノード２３を移動先として決定する。
干渉指数は、式（１）～（４）を参照して説明したように、その値が小さいほどコンテナ３１同士が干渉しに難くなる指数である。よって、このように干渉指数が最も小さいノード２３を移動先とすることにより、移動先に移動したコンテナ３１が干渉を受ける可能性を少なくでき、そのコンテナ３１のレスポンスタイム等の性能を維持することができる。
次に、コンテナ３１の移動方法について説明する。
図１５は、第１実施形態におけるコンテナ３１の移動方法のフローチャートである。
まず、各ノード２３のコンテナ監視部５１が、所定の時間間隔でコンテナ３１のレスポンスタイムRを監視し、その監視結果を性能低下判定部５５に通知する（ステップＳ４１）。なお、監視対象のコンテナ３１は、ステップＳ１７（図１２参照）でコンテナ決定部５４が干渉に弱いと決定したコンテナ３１である。
次に、性能低下判定部５５が、レスポンスタイムRが閾値Rthを超えたかを判断する（ステップＳ４２）。ここで、レスポンスタイムRが閾値Rthを超えていない場合（ステップＳ４２：否定）にはステップＳ４１に戻り、コンテナ監視部５１がレスポンスタイムRの監視を続ける。
一方、レスポンスタイムRが閾値Rthを超えた場合（ステップＳ４２：肯定）にはステップＳ４３に移る。
ステップＳ４３においては、移動実行部５７が、移動先決定部５６によって決定されたノード２３にコンテナ３１を移動する。
以上により、コンテナ３１の移動方法を終える。
この移動方法によれば、ステップＳ４２において、性能低下判定部５５によって実際に性能が低下したと判定されたコンテナ３１を他のノード２３に移動する。これにより、当該コンテナ３１の性能を移動先で回復させることができるため、移動前と比較してシステム２１全体のレスポンスタイム等の技術的な性能を改善することができる。
しかも、移動対象のコンテナ３１は、干渉の発生源となっているコンテナ３１ではなく、コンテナ決定部５４が干渉に弱いと決定したコンテナ３１である。干渉に弱いコンテナ３１は、移動先で干渉源となって他のコンテナ３１の性能を低下させる可能性が少ない。そのため、本実施形態では、コンテナ３１の移動に伴ってシステム２１の全体のレスポンスタイム等の性能が低下するのを抑制でき、ひいてはシステム２１の全体の性能改善を図ることが可能となる。
（第２実施形態）
第１実施形態では全てのノード２３が干渉指数情報Gを共有したが、本実施形態では複数のノード２３のうちの一つを代表ノードと定めておき、その代表ノードが干渉指数情報Gを管理する。
図１６は、本実施形態に係るシステム２１のシステム構成図である。なお、図１６において、第１実施形態で説明したのと同じ要素には第１実施形態で説明したのと同じ符号を付し、以下ではその説明を省略する。
ここでは、「node #k」のノード２３が代表ノードである場合を例にして説明する。この場合、本実施形態では、複数のノード２３の各々の通信部４１（図１０参照）が、自ノードの干渉指数情報Gを代表のノード２３に送信する。そして、代表のノード２３は、自ノードの通信部４１を介してその干渉指数情報Gを取得し、それを自ノードの記憶部４２（図１０参照）に格納する。
この場合、代表ノード以外のノード２３の移動先決定部５６は、代表ノードに移動先のノード２３を以下のように問合わせる。
図１７は、本実施形態における代表のノード２３の動作を示すフローチャートである。
まず、代表のノード２３の通信部４１が、他の全てのノード２３から干渉指数情報Gの通知を受け付け、その干渉指数情報Gを自ノードの記憶部４２に格納する。（ステップＳ５１）
次に、代表ノード２３の移動先決定部５６が、あるリソースについての干渉指数が最も小さいノード２３がどこかについての問合わせを他のノード２３から受けたかどうかを判断する（ステップＳ５２）。
ここで、問合せを受けていない場合（ステップＳ５２：否定）にはステップＳ５１に戻る。
一方、問合せを受けた場合（ステップＳ５２：肯定）にはステップＳ５３に移る。
ステップＳ５３においては、代表のノード２３の移動先決定部５６が、干渉指数が最も小さいノード２３を、通信部４１を介して問合せ元の他のノード２３に通知する。例えば、CPU２３ｃについての干渉指数Xcの問合せの場合には、移動先決定部５６は、当該干渉指数Xcが最も小さいノード２３を問合せ元の他のノード２３に通知する。
以上により、代表のノード２３の動作の基本ステップを終了する。
上記した本実施形態によれば、代表ノードが全てのノード２３の全ての干渉指数情報Gを格納するため、これらの干渉指数情報Gを代表ノードが一元的に管理できる。しかも、代表ノード以外の他のノード２３は、自ノード以外の干渉指数情報Gを記憶部４２に格納する必要がないため、記憶部４２の容量を節約することもできる。
（第３実施形態）
第１実施形態では、例えば図７に示したように、実際にシステム２１で利用者端末２２に対してサービスを提供している場面において、コンテナ３１におけるデータ処理量等をノード２３がリアルタイムに監視した。そして、その監視結果に基づいて、ノード２３が干渉に弱いコンテナ３１を決定した。
これに対し、本実施形態では、システム２１でサービスを提供する前の試験環境において、予め干渉に弱いコンテナ３１を決定しておく。
図１８は、本実施形態に係るノード２３の機能構成図である。
なお、図１８において、第１実施形態で説明したのと同じ要素には同じ符号を付し、以下ではその説明を省略する。
図１８に示すように、本実施形態においては、ノード２３を利用してサービスを実際に提供する前に、記憶部４２にコンテナ情報Cを予め記憶させる。
コンテナ情報Cは、他のノード２３に移動するコンテナ３１を特定する情報である。ここでは、システム２１の管理者が、あるリソースを介した干渉に弱いコンテナ３１とそのリソースとを対応付けてコンテナ情報Cに格納する。例えば、「#1」のコンテナ３１がCPU２３ａを介した干渉に弱い場合には、管理者は、そのコンテナ３１を識別する文字列「#1」とリソース名「CPU」とを対応付けてコンテナ情報Cに格納する。
このように干渉に弱いコンテナ３１は、例えばシステム２１と同一の試験環境において第１実施形態に従って予め決定しておき、管理者がコンテナ情報Cに格納すればよい。そして、記憶部４２がコンテナ情報Cを記憶した後に、試験環境から本番のシステム２１に切り替えればよい。このように試験環境から本番の環境に切り替える方法はブルーグリーンデプロイメントとも呼ばれる。
また、コンテナ監視部５１は、自ノードで起動している複数のコンテナ３１のうち、コンテナ情報Cに含まれるコンテナ３１のレスポンスタイムRを監視する。そして、性能低下判定部５５は、そのレスポンスタイムRが閾値Rthを超えたかを判定する。更に、移動実行部５７は、レスポンスタイムRが閾値Rthを超えたと判定された場合に、当該コンテナ３１を他のノード２３に移動する。
コンテナ３１の移動先のノード２３は移動先決定部５６により決定される。例えば、コンテナ情報Cにおいてコンテナ３１がCPUと対応付けられている場合には、移動先決定部５６は、CPUについての干渉指数Xcが最も小さいノード２３を移動先のノードとして決定する。
図１９は、本実施形態に係るコンテナの移動方法のフローチャートである。
まず、コンテナ監視部５１が、コンテナ情報Cに含まれる各々のコンテナ３１のレスポンスタイムRを監視する（ステップＳ６１）。
次に、性能低下判定部５５が、各コンテナ３１のレスポンスタイムRが閾値Rthを超えたかを判定する（ステップＳ６２）。
ここで、レスポンスタイムRが閾値Rthを超えていない場合（ステップＳ６２：否定）にはステップＳ６１に戻る。
一方、レスポンスタイムRが閾値Rthを超えた場合（ステップＳ６２：肯定）にはステップＳ６３に移る。
ステップＳ６３においては、レスポンスタイムRが閾値Rthを超えたコンテナ３１を、移動実行部５７が他のノード２３に移動する。移動先のノード２３は、前述のように移動先決定部５６が決定したノードである。
以上により、本実施形態に係るコンテナの移動方法を終了する。
上記した本実施形態によれば、試験環境において干渉に弱いことが決定されたコンテナ３１をコンテナ情報Cに予め格納しておく。そのため、本番の環境において実際にサービスを提供しながらノード２３が干渉に弱いコンテナ３１を決定する必要がなく、その決定に要するノード２３のリソースを節約することができる。
以上説明した各実施形態に関し、更に以下の付記を開示する。
（付記１） 複数のコンテナを実行する第１のノードが、
前記第１のノードが使用しているリソースの使用率が増加した時間帯でレスポンスタイムが増加するコンテナであって、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超えないコンテナを、他のノードに移動するコンテナとして決定する、
処理を実行することを特徴とする移動対象コンテナ決定方法。
（付記２） 前記パラメータは、前記コンテナが使用している前記リソースの使用率の増加量、又は前記コンテナにおけるデータ処理量の増加量であることを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記３） 前記第１のノードが、
前記コンテナの前記レスポンスタイムが増加した前記時間帯が複数存在し、複数の前記時間帯の各々において前記使用率が増加した場合に、前記パラメータが前記所定値を超えないコンテナを前記他のノードに移動するコンテナとして決定することを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記４） 前記第１のノードが、
複数の他のノードのうちで、前記使用率が増加したときに複数の前記コンテナの各々の前記レスポンスタイムが増加する程度を表す指数が最も小さいノードを移動先ノードとして決定する処理を更に実行することを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記５） 前記第１のノードと複数の他のノードの各々が、自身のノードについての前記指数を、自身以外のノードの全てに通知することを特徴とする付記４に記載の移動対象コンテナ決定方法。
（付記６） 前記第１のノードと複数の他のノードのうちの一つのノードが、
全てのノードから前記指数の通知を受け付け、
自身以外のノードから前記指数が最も小さいノードについての問合わせがあったときに、前記問合わせに対する回答を、問合せ元の前記ノードに通知することを特徴とする付記４に記載の移動対象コンテナ決定方法。
（付記７） 前記指数は、前記レスポンスタイムの増加量と前記使用率の増加量との比を複数の前記コンテナについて加算した値であることを特徴とする付記４に記載の移動対象コンテナ決定方法。
（付記８） 前記第１のノードが、
前記コンテナの前記レスポンスタイムが閾値を超えたときに、前記コンテナを前記他のノードに移動することを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記９） 前記第１のノードが、
前記使用率を監視し、
複数の前記コンテナの各々の前記レスポンスタイムと前記パラメータとを監視し、
前記使用率、前記レスポンスタイム、及び前記パラメータの各々の監視結果に基づいて、前記他のノードに移動する前記コンテナを決定することを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記１０） 前記第１のノードが、
前記他のノードに移動する前記コンテナを特定する情報を記憶した記憶部を参照し、
前記情報における前記コンテナの前記レスポンスタイムが閾値を超えたときに、前記コンテナを前記他のノードに移動することを特徴とする付記１に記載の移動対象コンテナ決定方法。
（付記１１） 複数のコンテナを実行する第１のノードに、
前記第１のノードが使用しているリソースの使用率が増加した時間帯でレスポンスタイムが増加するコンテナであって、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超えないコンテナを、他のノードに移動するコンテナとして決定する、
処理を実行させるための移動対象コンテナ決定プログラム。
１…システム、２…利用者端末、３…ノード、４…コンテナ、５…アプリ、７…ネットワーク、２１…システム、２２…利用者端末、２３…ノード、２３ａ…ストレージ、２３ｂ…メモリ、２３ｅ…表示装置、２３ｆ…入力装置、２３ｇ…バス、２３ｈ…記録媒体、２４…ネットワーク、２７…コンテナエンジン、３１…コンテナ、３２…アプリ、４１…通信部、４２…記憶部、４３…コンテナ実行部、４４…制御部、５１…コンテナ監視部、５２…使用率監視部、５２ｃ…ＣＰＵ監視部、５２ｍ…メモリ監視部、５２ｎ…ネットワーク監視部、５２ｓ…ストレージ監視部、５３…干渉指数算出部、５４…コンテナ決定部、５５…性能低下判定部、５６…移動先決定部、５７…移動実行部。

Claims (5)

  1. 複数のコンテナを実行する第１のノードが、
    前記第１のノードが使用しているリソースの使用率が増加した時間帯でレスポンスタイムが増加する２以上のコンテナは、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超えない第１コンテナと、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超える第２コンテナとを含み、前記第１コンテナを、他のノードに移動するコンテナとして決定する、
    処理を実行することを特徴とする移動対象コンテナ決定方法。
  2. 前記第１のノードが、
    前記２以上のコンテナの前記レスポンスタイムが増加した前記時間帯が複数存在し、複数の前記時間帯の各々において前記使用率が増加した場合に、前記パラメータが前記所定値を超えない前記第１コンテナを前記他のノードに移動するコンテナとして決定することを特徴とする請求項１に記載の移動対象コンテナ決定方法。
  3. 前記第１のノードが、
    複数の他のノードのうちで、前記使用率が増加したときに前記２以上のコンテナの各々の前記レスポンスタイムが増加する程度を表す指数が最も小さいノードを移動先ノードとして決定する処理を更に実行することを特徴とする請求項１に記載の移動対象コンテナ決定方法。
  4. 前記第１のノードが、
    前記２以上のコンテナの前記レスポンスタイムが閾値を超えたときに、前記第１コンテナを前記他のノードに移動することを特徴とする請求項１に記載の移動対象コンテナ決定方法。
  5. 複数のコンテナを実行する第１のノードに、
    前記第１のノードが使用しているリソースの使用率が増加した時間帯でレスポンスタイムが増加する２以上のコンテナは、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超えない第１コンテナと、当該レスポンスタイムの増加に影響を与えるパラメータが所定値を超える第２コンテナとを含み、前記第１コンテナを、他のノードに移動するコンテナとして決定する、
    処理を実行させるための移動対象コンテナ決定プログラム。
JP2020036593A 2020-03-04 2020-03-04 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム Active JP7513866B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2020036593A JP7513866B2 (ja) 2020-03-04 2020-03-04 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム
EP20215464.7A EP3876097B1 (en) 2020-03-04 2020-12-18 Method for determining container to be migrated and program for determining container to be migrated
US17/129,406 US12032982B2 (en) 2020-03-04 2020-12-21 Method for determining container to be migrated and non-transitory computer-readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020036593A JP7513866B2 (ja) 2020-03-04 2020-03-04 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム

Publications (2)

Publication Number Publication Date
JP2021140385A JP2021140385A (ja) 2021-09-16
JP7513866B2 true JP7513866B2 (ja) 2024-07-10

Family

ID=73855787

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020036593A Active JP7513866B2 (ja) 2020-03-04 2020-03-04 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム

Country Status (3)

Country Link
US (1) US12032982B2 (ja)
EP (1) EP3876097B1 (ja)
JP (1) JP7513866B2 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017033117A (ja) 2015-07-30 2017-02-09 日本電信電話株式会社 クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム
JP2017146791A (ja) 2016-02-17 2017-08-24 日本電信電話株式会社 クラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラム
JP2019061359A (ja) 2017-09-25 2019-04-18 富士ゼロックス株式会社 プログラム及び情報処理装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008062864A1 (fr) 2006-11-24 2008-05-29 Nec Corporation Système de localisation de machine virtuelle, procédé de localisation de machine virtuelle, programme, dispositif de gestion de machine virtuelle et serveur
JP2012208541A (ja) 2011-03-29 2012-10-25 Mitsubishi Electric Corp 仮想マシン管理装置、仮想マシン管理方法及び仮想マシン管理プログラム
EP2948841A4 (en) * 2013-01-23 2016-09-07 Hewlett Packard Entpr Dev Lp COMPETITION BETWEEN COMMONLY USED RESOURCES
JP6075226B2 (ja) 2013-06-26 2017-02-08 富士通株式会社 プログラム、仮想マシン管理方法および情報処理装置
JP6031462B2 (ja) 2014-02-12 2016-11-24 日本電信電話株式会社 仮想マシン配置装置及び方法及びプログラム
US10007584B2 (en) * 2015-01-28 2018-06-26 Red Hat, Inc. Automated container migration in a platform-as-a-service system
JP6383340B2 (ja) 2015-10-09 2018-08-29 日本電信電話株式会社 キャッシュ競合管理システム、リソース割当サーバおよびリソース割当方法
JP2017091001A (ja) 2015-11-04 2017-05-25 日本電信電話株式会社 仮想インスタンス配置位置決定装置、仮想インスタンス配置位置決定方法および仮想インスタンス配置位置決定プログラム
US10719354B2 (en) * 2017-06-20 2020-07-21 Samsung Electronics Co., Ltd. Container workload scheduler and methods of scheduling container workloads
US10884779B2 (en) * 2018-12-07 2021-01-05 Nutanix, Inc. Systems and methods for selecting virtual machines to be migrated

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017033117A (ja) 2015-07-30 2017-02-09 日本電信電話株式会社 クラスタ内リソース管理システム、クラスタ内リソース管理方法、管理サーバ及びプログラム
JP2017146791A (ja) 2016-02-17 2017-08-24 日本電信電話株式会社 クラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラム
JP2019061359A (ja) 2017-09-25 2019-04-18 富士ゼロックス株式会社 プログラム及び情報処理装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MUKHERJEE JOYDEEP ET AL，Subscriber-Driven Interference Detection for Cloud-Based Web Services，IEEE TRANSACTIONS ON NETWORK AND SERVICE MANAGEMENT，米国，IEEE，2017年03月01日，vol.14, no.l ，48-62，ISSN: 1932-4537, DOI: 10.1 109/TNSM.2016.2642838

Also Published As

Publication number Publication date
EP3876097A1 (en) 2021-09-08
US20210279089A1 (en) 2021-09-09
US12032982B2 (en) 2024-07-09
EP3876097B1 (en) 2025-09-10
JP2021140385A (ja) 2021-09-16

Similar Documents

Publication Publication Date Title
US11237871B1 (en) Methods, systems, and devices for adaptive data resource assignment and placement in distributed data storage systems
US10733029B2 (en) Movement of services across clusters
KR102031471B1 (ko) 자원 배치 최적화를 위한 기회적 자원 이주
US10356150B1 (en) Automated repartitioning of streaming data
US8260925B2 (en) Finding workable virtual I/O mappings for HMC mobile partitions
JP4686606B2 (ja) 複数のホスト・バス・アダプタを介して取り付けられた取り外し可能メディア・デバイス間での入力／出力作業負荷の動的分散のための方法、コンピュータ・プログラム、およびシステム
US20150052528A1 (en) Management of prioritizing virtual machines in an operating environment
US20100229175A1 (en) Moving Resources In a Computing Environment Having Multiple Logically-Partitioned Computer Systems
US11556391B2 (en) CPU utilization for service level I/O scheduling
US20200183703A1 (en) Systems and methods for selecting a target host for migration of a virtual machine
US12112047B2 (en) Method, device and computer program product for locking a storage area in a storage system
CN114442910A (zh) 管理存储系统的方法、电子设备和计算机程序产品
US11012316B2 (en) Methods and apparatus to generate and manage workload domains in virtual server racks
US10761726B2 (en) Resource fairness control in distributed storage systems using congestion data
US10594620B1 (en) Bit vector analysis for resource placement in a distributed system
US10782922B2 (en) Storage device volume selection for improved space allocation
JP7513866B2 (ja) 移動対象コンテナ決定方法、及び移動対象コンテナ決定プログラム
US11334390B2 (en) Hyper-converged infrastructure (HCI) resource reservation system
US10884861B2 (en) Write-balanced parity assignment within a cluster
US12379962B2 (en) Storage array resource allocation based on feature sensitivities
US11360798B2 (en) System and method for internal scalable load service in distributed object storage system
US10721181B1 (en) Network locality-based throttling for automated resource migration
JP6374059B2 (ja) コンピュータ資源配分決定方法、コンピュータ資源配分決定方法プログラムおよび制御用コンピュータ
CN117806571B (zh) 一种云主机的i/o参数值确定方法、计算机设备及其云平台
US20250231815A1 (en) Workload resource contention reduction system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221117

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231212

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240213

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240528

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240610

R150 Certificate of patent or registration of utility model

Ref document number: 7513866

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150