JP7040113B2 - プログラム及び情報処理装置 - Google Patents

Description

本発明は、プログラム及び情報処理装置に関する。

特許文献１には、複数のサーバ間における仮想マシンの負荷情報に基づいて移行元サーバと移行対象仮想マシン、移行先サーバを決定し、動的移行の準備が完了した後の移行元サーバ及び移行先サーバの負荷情報に基づいて動的移行の実行の可否を決定する技術が開示されている。

特許第５５４９１８９号公報

クラウドサービスでは、ユーザが利用する各種サービス（画像処理サービス等）を複数個同時に実行可能なインスタンスと呼ばれる仮想マシンが提供され、利用中のインスタンスの数に応じて課金されることがある。例えばサービスの実行主体であるインスタンスを固定している場合、実行中のサービスが１つでも残っているとそのサービスを終了させない限りインスタンスの利用も終了することができないから、インスタンスの数を減らすことができない。
そこで、本発明は、サービスの実行主体を固定する場合に比べて、サービスを実行する仮想マシンを少なくすることを目的とする。

本発明の請求項１に係るプログラムは、複数の仮想マシンを実現する実現部を備えるコンピュータを、第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部として機能させることを特徴とする。

本発明の請求項２に係るプログラムは、請求項１に記載の構成において、前記コンピュータを、仮想マシンで実行中のサービスに割り当てられている第２リソースの前記第１リソースに対する第１割合を前記リソース使用率として算出する第１算出部と、他の仮想マシンに移転予定のサービスを除いた前記実行中のサービスに割り当てられている第３リソースの前記第１リソースに対する第２割合を前記リソース使用率として算出する第２算出部と、複数の仮想マシンにおける前記第１割合及び前記第２割合を取得する取得部として機能させ、前記決定部は、前記第２仮想マシンについての前記第１割合又は前記第２割合が示す空きリソースで実行可能なサービスが前記実行部により実行中である場合、前記第１仮想マシンの前記第２割合から定まる閾値以上の前記第２割合が前記第２仮想マシンについて取得されたときに当該第２仮想マシンを当該サービスの移転先として決定することを特徴とする。

本発明の請求項３に係るプログラムは、請求項２に記載の構成において、前記決定部は、取得された前記第１仮想マシンの前記第２割合を前記閾値とすることを特徴とする。

本発明の請求項４に係るプログラムは、請求項１から３のいずれか１項に記載の構成において、前記コンピュータを、前記第１仮想マシン及び前記第２仮想マシンにおけるサービスの移転履歴を記憶する記憶部として機能させ、前記決定部は、記憶された前記移転履歴に基づいて前記閾値を変化させることを特徴とする。

本発明の請求項５に係るプログラムは、請求項４に記載の構成において、前記決定部は、記憶された前記移転履歴が示す移転の頻度又は移転の回数が少ないほど前記閾値を小さくすることを特徴とする。

本発明の請求項６に係るプログラムは、請求項４に記載の構成において、前記決定部は、取得された前記移転履歴が示す最新の移転時期が古いほど前記閾値を小さくすることを特徴とする。

本発明の請求項７に係るプログラムは、請求項１から６のいずれか１項に記載の構成において、前記実行部は、前記第２仮想マシンへの移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成するまでは当該サービスに新たな処理を実行させることを特徴とする。

本発明の請求項８に係るプログラムは、請求項１から６のいずれか１項に記載の構成において、前記実現部は、前記第２仮想マシンに移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成していなくても当該サービスに新たな処理を実行させないことを特徴とする。

本発明の請求項９に係るプログラムは、請求項１から８のいずれか１項に記載の構成において、前記決定部は、移転対象のサービスが実行していた処理が終了したときに移転先の前記第２仮想マシンの前記リソース使用率が前記閾値未満になっていた場合、他の仮想マシンを当該サービスの移転先として決定することを特徴とする。

本発明の請求項１０に係るプログラムは、請求項１から９のいずれか１項に記載の構成において、前記コンピュータを、他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部として機能させ、前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、前記受付部は、複数の他の仮想マシンから移転するサービスの受け入れを要求された場合、移転後の前記リソース使用率がより大きくなる要求を受け付けることを特徴とする。

本発明の請求項１１に係るプログラムは、請求項１から１０のいずれか１項に記載の構成において、前記コンピュータを、他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部として機能させ、前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、前記受付部は、他の仮想マシンからのサービスの受け入れの要求を受け付けた後に前記第１仮想マシンで実行中のサービスが全て移転予定になった場合、当該要求の受け付けを撤回することを特徴とする。

本発明の請求項１２に係るプログラムは、請求項１１に記載の構成において、前記決定部は、前記受付部が前記要求の受け付けを撤回した場合に、当該要求が行われたサービスの移転先を当該要求の時点での前記第１仮想マシンのリソース使用率に基づいて決定し、前記コンピュータを、決定された前記移転先を前記要求の送り元の仮想マシンに通知する通知部として機能させることを特徴とする。

本発明の請求項１３に係るプログラムは、請求項１から１２のいずれか１項に記載の構成において、前記コンピュータを、複数の仮想マシンにおけるサービスの移転履歴を記憶する記憶部と、記憶された前記移転履歴を出力する履歴出力部として機能させることを特徴とする。

本発明の請求項１４に係るプログラムは、請求項１から１３のいずれか１項に記載の構成において、前記コンピュータを、前記実行部によるサービスの実行状態を示す情報を出力する実行状態出力部として機能させることを特徴とする。

本発明の請求項１５に係るプログラムは、請求項１から１４のいずれか１項に記載の構成において、前記コンピュータを、前記リソース使用率を示す情報を出力する使用率出力部として機能させることを特徴とする。

本発明の請求項１６に係る情報処理装置は、複数の仮想マシンを実現する実現部と、第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部とを備えることを特徴とする。

請求項１、２、１６に係る発明によれば、サービスの実行主体を固定する場合に比べて、サービスを実行する仮想マシンを少なくすることができる。
請求項３に係る発明によれば、第２割合が同じ仮想マシン同士でもどちらかにサービスを寄せることができる。
請求項４に係る発明によれば、閾値が固定である場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項５に係る発明によれば、移転の頻度又は回数が多い仮想マシンを移転先にする場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項６に係る発明によれば、最新の移転時期が新しい仮想マシンを移転先にする場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項７に係る発明によれば、新たな処理を実行させない場合に比べて処理の進捗を早めることができる。
請求項８に係る発明によれば、新たな処理を実行させる場合に比べてサービスの移転を早めることができる。
請求項９に係る発明によれば、移転先を見直さない場合に比べて、移転先として適当でなくなったインスタンスへのサービスの移転を抑制することができる。
請求項１０に係る発明によれば、自仮想マシンの移転後のリソース使用率に関係なく要求を受け付ける場合に比べて、自仮想マシンのリソース使用率を高めることができる。
請求項１１に係る発明によれば、移転したサービスだけが移転先の仮想マシンで実行される事態を防ぐことができる。
請求項１２に係る発明によれば、受け付けが撤回された移転要求の送り元のインスタンスが移転先を決定し直す場合に比べて、決定された移転先への移転要求が受け付けられやすいようにすることができる。
請求項１３に係る発明によれば、各仮想マシンにおける過去の移転の経緯を把握することができる。
請求項１４に係る発明によれば、サービスの実行状態から移転状況を把握することができる。
請求項１５に係る発明によれば、リソース使用率から移転状況を把握することができる。

実施例に係るリソース提供システムの全体構成を表す図 サーバ装置のハードウェア構成を表す図 リソース管理装置のハードウェア構成を表す図 リソース提供システムが実現する機能構成を表す図 リソース提供システムが実現する機能構成を表す図 移転先の決定例を表す図 移転先の決定例を表す図 移転処理における各装置の動作手順の一例を表す図 閾値テーブルの一例を表す図 移転の有無の判断結果の例を表す図 閾値テーブルの別の一例を表す図 閾値テーブルの別の一例を表す図 変形例の移転処理における各装置の動作手順の一例を表す図 移転要求の受け付けの例を表す図 変形例の移転処理における各装置の動作手順の一例を表す図

［１］実施例
図１は実施例に係るリソース提供システム１の全体構成を表す。リソース提供システム１は、処理（情報処理）の実行に用いられるリソースをユーザに使用させるリソース提供サービスを実施するためのシステムである。ここでいうリソースには、ＣＰＵ（Central Processing Unit）、メモリ、ストレージ、それらを備える物理的な装置及びそれらによって実現される仮想的な装置（いわゆる仮想マシン）等がある。

また、リソース提供システム１においては、ユーザが利用する各種サービス（ＯＣＲ（Optical Character Recognition）サービス及び文章を翻訳する翻訳サービス等）を複数個同時に実行可能なインスタンスと呼ばれる仮想マシンがリソースとして提供される。本実施例では、ユーザに対しては、利用中のインスタンスの数に応じた課金が行われるものとする。

リソース提供システム１は、通信回線２と、ユーザ端末３と、クラウドシステム４と、リソース管理装置２０とを備える。通信回線２は、例えばインターネット、移動体通信網及び電話回線等を含み、自回線に接続されている装置同士の通信を仲介する。通信回線２には、ユーザ端末３及びクラウドシステム４が接続されている。

ユーザ端末３は、前述したリソース提供サービスを利用するユーザが使用する端末である。ユーザには、例えば、企業の業務としてリソース提供サービスを利用する者と、個人的な活動（例えばオンラインゲームのプレイ等）でリソース提供サービスを利用する者とが含まれる。なお、図１ではユーザ端末３が１台しか表されていないが、通常は複数のユーザ端末３が使用されているものとする。

ユーザ端末３は、ユーザの操作により前述したサービスの実行をクラウドシステム４に対して要求し、要求したサービスの実行結果を受け取って例えばその実行結果に応じた画面を表示する。クラウドシステム４によるサービスの実行とは、各サービスに対応した１以上の処理（ＯＣＲサービスなら文字領域抽出処理、文字の切り出し処理及び文字の認識処理等）を実行することを意味する。

クラウドシステム４は、処理を実行するリソースである複数のサーバ装置１０を備え、それらのリソースを用いてユーザ端末３から要求されたサービスを実行する。各サーバ装置１０は、前述したインスタンスを実現する。リソース管理装置２０は、リソース提供システム１の管理者がリソースの稼働状況を管理するための装置であり、本実施例では、各インスタンスでのサービスの実行状況及びその履歴等を表示する。

図２はサーバ装置１０のハードウェア構成を表す。サーバ装置１０は、ＣＰＵ１１と、ＲＡＭ（Random Access Memory）１２と、ＲＯＭ（Read Only Memory）１３と、通信部１４と、ストレージ１５とを備えるコンピュータである。ＣＰＵ１１は、メモリであるＲＡＭ１２をワークエリアとして用いてＲＯＭ１３やストレージ１５に記憶されているプログラムを実行することで各部の動作を制御する。通信部１４は、通信回路等を有し、通信回線２を介して外部装置と通信を行う。ストレージ１５は、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリなどの記憶手段であり、ＣＰＵ１１が制御に用いるデータやプログラムを記憶している。

図３はリソース管理装置２０のハードウェア構成を表す。リソース管理装置２０は、ＣＰＵ２１と、ＲＡＭ２２と、ＲＯＭ２３と、通信部２４と、ストレージ２５と、ＵＩ部２６（User Interface）とを備えるコンピュータである。ＣＰＵ２１からストレージ２５までは、図２に表す同名のハードウェアと共通するハードウェアである。ＵＩ部２６は、液晶ディスプレイ等の表示手段を備え、自装置を操作するためのメニュー画面等を表示する。また、ＵＩ部２６は、キーボード及びマウス等の入力手段を備えている。

リソース提供システム１が備える各装置のＣＰＵがプログラムを実行して各部を制御することで、以下に述べる機能が実現される。
図４及び図５はリソース提供システム１が実現する機能構成を表す。図４ではサーバ装置１０を１台だけ表しているが、各サーバ装置１０は、いずれも、仮想マシン実現部３０と、インスタンス群３１と、第１オートスケール制御部３２と、第２オートスケール制御部３３と、リクエスト・レスポンスキュー３４と、サービス定義記憶部３５と、サービス移転情報永続記憶部３６とを備える。リソース管理装置２０は、現状情報表示部４１と、履歴情報表示部４２とを備える。

インスタンス群３１は、インスタンス１００、インスタンス２００及びインスタンス３００等の複数のインスタンスを備える。図５に表すように、インスタンス１００は、リソース使用率算出部１０１と、サービス移転受付部１０２と、サービス移転状態応答部１０３と、コンテナ制御部１０４と、コンテナ実行部１０５と、サービス状態管理部１０６と、サービス状態記憶部１０７と、サービス移転判断部１０８と、サービス停止判断部１０９と、サービス移転先記憶部１１０とを備える。

インスタンス２００及びインスタンス３００等の各インスタンスは、いずれもインスタンス１００と共通の機能を備えるので、以下ではインスタンス１００の機能を主に説明する。なお、図５では、インスタンス２００についても説明に登場するリソース使用率算出部２０１、サービス移転受付部２０２、サービス移転状態応答部２０３、サービス移転判断部２０８及びサービス停止判断部２０９を図示している。

本実施例では、インスタンス１００で実行されているサービスの移転先がインスタンス２００となる場合について主に説明する（ただし移転先にならない場合も説明する）。インスタンス２００が移転先となる場合は、インスタンス１００は本発明の「第１仮想マシン」の一例となり、インスタンス２００は本発明の「第２仮想マシン」の一例となる。

仮想マシン実現部３０は、仮想マシンを実現する機能であり、本実施例では、コンテナ型の仮想化技術を用いた仮想マシンを実現する。仮想マシン実現部３０は、例えばＤｏｃｋｅｒ（登録商標）によって実現されるが、これに限らず、その他のコンテナ型の仮想化プログラムによって実現されてもよい。仮想マシン実現部３０は、図４の例では、インスタンス１００等の各インスタンスの他、インスタンス以外の機能である第１オートスケール制御部３２等も実現する。仮想マシン実現部３０は本発明の「実現部」の一例である。

コンテナ実行部１０５は、自インスタンス（インスタンス１００）に割り当てられたリソースを用いて上述したＯＣＲサービス等の複数のサービスを実行する。コンテナ実行部１０５は本発明の「実行部」の一例である。インスタンスにリソースを割り当てるとは、そのインスタンスのためにリソースを確保することである。インスタンス内では、各サービスに対しても同様にリソースが割り当てられる（確保される）。コンテナ実行部１０５は、図５では、サービス１５１、サービス１５２及びサービス１５３という３つのサービス（それぞれ区別しない場合は「サービス１５０」という）を実行している。

リクエスト・レスポンスキュー３４は、図１に表すユーザ端末３からのサービス１５０へのリクエスト及びそのリクエストに対するサービス１５０からのレスポンスをキュー（先入れ先出しのデータ）として取り扱う。サービス１５０は、リクエスト・レスポンスキュー３４からリクエストを示すメッセージを受け取り、そのメッセージで指定された処理を実行し、処理結果を示すメッセージをレスポンスとしてリクエスト・レスポンスキュー３４に格納する。

コンテナ制御部１０４は、コンテナ実行部１０５によるサービスの実行を制御する。コンテナ制御部１０４は、コンテナ実行部１０５へのサービスの配置、コンテナ実行部１０５が実行しているサービスの停止、サービスの実行に必要なリソースの割り当て、割り当てられたリソース以上のリソースをサービスが利用することの制限及びサービスの実行状態の管理等を行う。

サービスの配置とは、コンテナ実行部１０５のリソースを確保してそのサービスの実行環境を作成することをいう。サービスの配置は、サービス定義記憶部３５が記憶するサービスの定義情報に基づいて行われる。サービスの定義情報とは、そのサービスで用いられるプログラム、データ、パラメータ及び使用するリソース等を示す情報である。

サービス状態管理部１０６は、コンテナ実行部１０５におけるサービスの状態を管理する。サービスの状態には、作成中、実行中、移転準備中の３つの状態が含まれる。「作成中」は、コンテナ実行部１０５がサービスの実行環境を作成している途中であることを意味し、作成中のサービスは処理を実行することができない状態である。「実行中」は、サービスの実行環境の作成が完了しており、コンテナ実行部１０５が処理を実行することができる状態である。リクエストがなくて処理を実行していなくても、実行環境の作成が完了していれば実行中の状態となる。

インスタンス群３１においては、インスタンス間でサービスが移転される。サービスの移転とは、本実施例では、移転元のインスタンスで実行されているサービスを移転先のインスタンスで実行させ、移転元のインスタンスで実行されていたサービスを停止させることをいう。詳細には、移転先のサービスが作成中から実行中になると、移転元のサービスが停止されて移転が完了する。

「移転準備中」は、他のインスタンスに移転予定であり、その移転先のインスタンスで同一のサービスが作成中となっている状態である。本実施例では、コンテナ実行部１０５は、移転準備中のサービス、すなわち他のインスタンスへの移転が決定されたサービスがある場合、移転先のインスタンスでそのサービスの実行環境が完成するまで（つまりサービスの状態が「実行中」になるまで）は、そのサービスに新たな処理を実行させる。

なお、コンテナ実行部１０５は、前述の場合に、移転先のインスタンスでそのサービスの実行環境が完成していなくてもそのサービスに新たな処理を実行させないようにしてもよい。新たな処理を実行させる場合は、新たな処理を実行させない場合に比べて処理の進捗が早まることになり、新たな処理を実行させない場合は、新たな処理を実行させる場合に比べてサービスの移転が早まることになる。

コンテナ実行部１０５は、サービスの状態が変更又はサービスが停止された場合、その旨をサービス状態管理部１０６に通知する。サービス状態管理部１０６は、この通知を受け取ると、サービスの状態をサービス状態記憶部１０７に記憶させ、既にそのサービスの状態が記憶されている場合は状態を更新する。こうしてサービス状態記憶部１０７は、自インスタンスのサービスの状態を記憶する。

リソース使用率算出部１０１は、自インスタンス（インスタンス１００）のリソース使用率を算出する。リソース使用率とは、自インスタンスに割り当てられているリソースのうち、サービスに割り当てられているリソースの割合をいう。リソース使用率算出部１０１は、現時点での使用率と、移転後の使用率とをリソース使用率として算出する。

現時点での使用率は、自インスタンスで現在実行されているサービスに割り当てられているリソースについてのリソース使用率である。現在実行されているサービスとは、前述した３つの状態（作成中、実行中、移転準備中）のサービスのことである。作成中のサービスも、既に実行の過程にあるものとして含めている。リソース使用率算出部１０１は、自インスタンスにおけるサービスの状態を示す情報をサービス状態管理部１０６から取得する。

リソース使用率算出部１０１は、これら３つの状態のサービスに割り当てられているリソース（以下「第２リソース」という）の、インスタンスに割り当てられているリソース（以下「第１リソース」という）に対する割合（以下「第１割合」という）を現時点での使用率として算出する。この第１割合を算出するリソース使用率算出部１０１は本発明の「第１算出部」の一例である。

移転後の使用率は、自インスタンスで実行されているサービスから他のインスタンスに移転予定のサービスを除いたもの、すなわち移転予定のサービスが移転した後に実行されている見込みのサービスについてのリソース使用率である。移転後に実行されている見込みのサービスとは、３つの状態のうち移転準備中のサービスを除いた作成中及び実行中のサービスのことである。

リソース使用率算出部１０１は、この移転後に実行されている見込みのサービスに割り当てられているリソース（以下「第３リソース」という）の第１リソース（インスタンスに割り当てられているリソース）に対する割合（以下「第２割合」という）を移転後の使用率として算出する。この第２割合を算出するリソース使用率算出部１０１は本発明の「第２算出部」の一例である。

サービス移転受付部１０２は、他のインスタンスのサービス移転判断部（例えばインスタンス２００のサービス移転判断部２０８）から移転するサービスの受け入れ（配置）を要求されると、自インスタンスにおいてそのサービスの受け入れ（配置）が可能であればその移転要求を受け付け、コンテナ制御部１０４にそのサービスの配置を依頼する。サービス移転受付部１０２は本発明の「受付部」の一例である。

コンテナ制御部１０４が依頼されたサービスをコンテナ実行部１０５に配置させる制御を行い、コンテナ実行部１０５がこの制御を受けてサービスを作成する。このように、コンテナ実行部１０５は、サービス移転受付部１０２により移転要求が受け付けられたサービスを実行する。

サービス移転状態応答部１０３は、他のインスタンスのサービス停止判断部（例えばインスタンス２００のサービス停止判断部２０９）からのサービスの状態の問い合わせを受け取ると、サービス状態管理部１０６から自インスタンスのサービスの状態を取得し、取得したサービスの状態を問い合わせへの応答として問合せ元のサービス停止判断部に通知する。

サービス移転判断部１０８は、自インスタンスのコンテナ実行部１０５により実行されているサービスを他のインスタンスに移転するか否かを判断し、移転すると判断した場合、移転先のインスタンスを決定する。サービス移転判断部１０８は本発明の「決定部」の一例である。本実施例では、サービス１５０が処理の実行を終了するとその旨をサービス移転判断部１０８に通知し、サービス移転判断部１０８は、この通知を受け取ったときに通知元のサービスについて移転の有無を判断する。

サービス移転判断部１０８は、前述の通知を受け取ると、複数のインスタンス（自インスタンスを含む）のリソース使用率算出部に対してリソース使用率の算出を要求し、その応答で送られてくる各インスタンスにおけるリソース使用率（現時点での使用率及び移転後の使用率の両方）を取得する。この場合のサービス移転判断部１０８は本発明の「取得部」の一例である。

サービス移転判断部１０８は、詳細には、自インスタンス（インスタンス１００）のリソース使用率から定まる閾値以上のリソース使用率の別のインスタンスが存在する場合に、自インスタンスのコンテナ実行部１０５が実行するサービスを移転すると判断し、そのリソース使用率が閾値以上のインスタンスを移転先として決定する。本実施例では、サービス移転判断部１０８は、比較するリソース使用率として移転後の使用率を用い、閾値として自インスタンスの移転後の使用率を用いる。

より詳細には、サービス移転判断部１０８は、別のインスタンスについての現時点での使用率が示す空きリソースで実行可能なサービスが自インスタンスのコンテナ実行部１０５により実行中であり、且つ、自インスタンスの移転後の使用率から定まる閾値（前述した自インスタンスの移転後の使用率そのもの）以上の移転後の使用率が別のインスタンスについて取得された場合に、そのサービスを移転すると判断し、その移転後の使用率が閾値以上のインスタンスを移転先として決定する。

移転有無の判断と移転先の決定について図６Ａ、図６Ｂを参照して説明する。
図６Ａ、図６Ｂは移転先の決定例を表す。この例では、説明を分かり易くするため、インスタンス１００及びインスタンス２００だけが実現されており、両インスタンスに割り当てられているリソース（上述した第１リソース）が等しく、各サービスに割り当てられているリソースも全て第１リソースの３分の１であるものとする。つまり、両インスタンスとも最大で３つのサービスが実行されるようになっている。なお、これらの前提はあくまで説明の便宜上のものであり、本発明はこれに限定されない。

図６Ａ（ａ）では、インスタンス１００においてサービス１５１、１５２が作成中又は実行中であり、サービス１５３が実行中である。また、インスタンス２００においてサービス２５１、２５２、２５３が作成中又は実行中である。サービス移転判断部１０８は、サービス１５３が処理の実行を終了したときに、両インスタンスの現時点での使用率及び移転後の使用率を取得する。

サービス移転判断部１０８は、この例では、取得したインスタンス２００の現時点での使用率が１００％であり、サービス１５３を実行させるための空きがないため、移転を行わないと判断する。図６Ａ（ｂ）では、インスタンス１００においてサービス１５２が作成中又は実行中であり、サービス１５３が実行中である。また、インスタンス２００においてサービス２５２、２５３が作成中又は実行中である。

この場合、サービス移転判断部１０８は、取得したインスタンス２００の現時点での使用率が６６．６・・％であるからサービス１５３を実行させるための空きがあり、且つ、自インスタンスの移転後の使用率（６６．６・・％）以上の移転後の使用率（６６．６・・％）がインスタンス２００について取得されているため、移転を行うと判断し、インスタンス２００を移転先として決定する。このように、本実施例では、自インスタンスと移転先のインスタンスの移転後の使用率が同じであればサービス移転判断部１０８は移転すると判断するので、移転後の使用率が同じインスタンス同士でもどちらかにサービスが寄せられることになる。

図６Ａ（ｃ）では、図６Ａ（ｂ）の状態からサービス２５２が移転準備中に変化している。この場合、サービス移転判断部１０８は、取得したインスタンス２００の現時点での使用率はサービス１５３を実行させるための空きを示しているが、自インスタンスの移転後の使用率（６６．６・・％）以上の移転後の使用率（３３．３・・％）がインスタンス２００について取得されていないため、移転を行わないと判断する。

図６Ａ（ｄ）では、図６Ａ（ｃ）の状態からサービス１５２が移転準備中に変化している。この場合、サービス移転判断部１０８は、取得したインスタンス２００の現時点での使用率がサービス１５３を実行させるための空きを示しており、且つ、自インスタンスの移転後の使用率（３３．３・・％）以上の移転後の使用率（３３．３・・％）がインスタンス２００について取得されているため、移転を行うと判断し、インスタンス２００を移転先として決定する。

図６Ｂ（ｅ）では、図６Ａ（ｄ）の状態からサービス２５３が移転準備中に変化している。この場合、サービス移転判断部１０８は、取得したインスタンス２００の現時点での使用率はサービス１５３を実行させるための空きを示しているが、自インスタンスの移転後の使用率（３３．３・・％）以上の移転後の使用率（０％）がインスタンス２００について取得されているため、移転を行わないと判断する。

図６Ｂ（ｆ）では、図６Ａ（ｄ）の状態からサービス２５１が移転準備中に変化している。この場合、インスタンス２００の移転後の使用率（３３．３・・％）がインスタンス１００の移転後の使用率（３３．３・・％）以上になるが、現時点ではインスタンス２００に空きリソースがないので、サービス移転判断部１０８は、移転を行わないと判断する。なお、図６Ｂ（ｆ）の場合にも移転が行われるように、サービス移転判断部１０８は、移転後の使用率が示す空きリソースで実行可能なサービスが自インスタンスのコンテナ実行部１０５により実行中である場合に移転することを判断してもよい。

その場合、図６Ｂ（ｆ）の例であれば、サービス移転判断部１０８は、取得したインスタンス２００の移転後の使用率がサービス１５３を実行させるための空きを示しており（移転準備中のサービスに割り当てられている６６．６・・％が空きリソースとなる）、且つ、自インスタンスの移転後の使用率（３３．３・・％）以上の移転後の使用率（３３．３・・％）がインスタンス２００について取得されているため、移転を行うと判断し、インスタンス２００を移転先として決定する。

サービス移転判断部１０８は、サービスを移転すると判断した場合、移転先のインスタンスのサービス移転受付部（インスタンス２００であればサービス移転受付部２０２）に移転するサービスの配置を要求する。この要求により上記のとおり移転先のインスタンスに移転対象のサービスと同じサービスの実行環境が作成される（例えば移転対象がＯＣＲサービスなら移転先でもＯＣＲサービスの実行環境が作成される）。また、サービス移転判断部１０８は、移転対象のサービスの識別情報（サービスＩＤ（Identification））と移転先のインスタンスの識別情報（インスタンスＩＤ）とをサービス停止判断部１０９に供給する。

サービス停止判断部１０９は、これらの識別情報を受け取ると、インスタンスＩＤが示す移転先のインスタンスのサービス移転状態応答部（インスタンス２００であればサービス移転状態応答部２０３）にサービスＩＤが示す移転対象のサービスの状態を問い合わせる。サービス停止判断部１０９は、移転対象のサービスの状態が作成中から実行中になった場合、コンテナ制御部１０４にその移転対象のサービスの停止を依頼する。コンテナ制御部１０４がこの依頼に基づきサービスを停止すると、移転が完了する。

サービス停止判断部１０９は、移転先のインスタンスに関する移転先情報として、例えば供給されたインスタンスＩＤ及びサービスＩＤを含む情報をサービス移転先記憶部１１０に供給する。サービス移転先記憶部１１０は、サービス停止判断部１０９から供給された移転先情報を記憶する。サービス移転先記憶部１１０は、記憶した移転先情報をサービス移転情報永続記憶部３６に供給する。

サービス移転情報永続記憶部３６には、インスタンス１００のサービス移転先記憶部１１０だけでなく、他のインスタンスのサービス移転先記憶部からも移転先情報を供給される。サービス移転情報永続記憶部３６は、こうして供給される複数のインスタンス（望ましくは全てのインスタンス）におけるサービスの移転履歴を記憶する。サービス移転情報永続記憶部３６は本発明の「記憶部」の一例である。

リソース管理装置２０の現状情報表示部４１は、各インスタンスの現在の状況を示す現状情報を表示する。現状情報表示部４１は、例えば、サービス状態記憶部１０７から、コンテナ実行部１０５によるサービスの実行状態（作成中、実行中、移転準備中）を示す実行状態情報を現状情報として取得して表示する。サービス状態記憶部１０７は、この実行状態情報を出力する機能であり、本発明の「実行状態出力部」の一例である。

状態情報が出力されることで、サービスの実行状態から移転状況が把握されることになる。例えばサービスの状態が実行中から変化しないインスタンスは移転で出入りするサービスが少なく、移転準備中の状態が多いインスタンスは移転で出入りするサービスが多いことが把握される。

また、現状情報表示部４１は、リソース使用率算出部１０１からリソース使用率を示す使用率情報を現状情報として取得して表示する。リソース使用率算出部１０１は、この使用率情報を出力する機能であり、本発明の「使用率出力部」の一例である。使用率情報が出力されることで、リソース使用率から移転状況が把握されることになる。例えばリソース使用率が高い数値で維持されているインスタンスは移転で出入りするサービスが少なく、リソース使用率が低い数値で変化しているインスタンスは移転で出入りするサービスが多いことが把握される。

また、現状情報表示部４１は、サービス移転先記憶部１１０から移転先情報を現状情報として取得して表示する。移転先情報が表示されることで、移転先情報が表示されない場合に比べて、上記の移転状況の把握がより正確に行われる。一方、リソース管理装置２０の履歴情報表示部４２は、各インスタンスの現在の状況の履歴を示す履歴情報を表示する。履歴情報表示部４２は、例えばサービス移転情報永続記憶部３６から複数のインスタンスにおけるサービスの移転履歴を履歴情報として取得して表示する。

サービス移転情報永続記憶部３６は、この移転履歴を出力する機能であり、本発明の「履歴出力部」の一例である。複数のインスタンスにおけるサービスの移転履歴が出力されることで、各インスタンスにおける過去の移転の経緯が把握される。

第１オートスケール制御部３２は、定められたルールに則り、インスタンスのスケールイン及びスケールアウトを制御する。スケールインとは仮想マシンの台数を減らすことをいい、スケールアウトとは仮想マシンの台数を増やすことをいう。本実施例では、例えばインスタンス１００のサービス停止判断部１０９が、コンテナ実行部１０５が実行していたサービスを全て停止すると、その旨を第１オートスケール制御部３２に通知する。

第１オートスケール制御部３２は、コンテナ実行部１０５により実行されるサービスの数が０になった（実行していたサービスが全て停止された）インスタンスをスケールインの対象と判定して停止させる制御を行う。こうしてインスタンスが停止すると、本実施例における課金（利用中のインスタンスの数に応じた課金）の対象ではなくなる。

なお、第１オートスケール制御部３２は、これ以外にも、例えばリクエスト・レスポンスキュー３４に格納されたキューの状況に基づいてスケールイン及びスケールアウトの判定を行ってもよい。第２オートスケール制御部３３は、定められたルールに則り、サービスのスケールイン及びスケールアウトを制御する。第２オートスケール制御部３３は、コンテナ制御部１０４に対して、スケールインを行う際はサービスの停止を依頼し、スケールアウトを行う際はサービスの配置を依頼する。

リソース提供システム１が備える各装置は、上記の構成に基づいて、インスタンス間でサービスを移転させる移転処理を行う。
図７は移転処理における各装置の動作手順の一例を表す。図７では、インスタンス１００、２００、３００という第１から第３までの３つのインスタンスを表しているが、他にもインスタンスが存在するものとする。この例では、インスタンス１００でサービス１５０により実行されていた処理が終了すること（ステップＳ１０）を契機に動作手順が開始される。

まず、インスタンス１００（サービス移転判断部１０８）が、各インスタンスのリソース使用率算出部に対してリソース使用率の算出を指示する（ステップＳ１１、Ｓ１２、Ｓ１３）。インスタンス１００（リソース使用率算出部１０１）は、この指示を受け取ると自インスタンスのリソース使用率を算出する（ステップＳ１４）。インスタンス２００（リソース使用率算出部２０１）及びインスタンス３００（リソース使用率算出部３０１）も、この指示を受け取ると自インスタンスのリソース使用率を算出する（ステップＳ１５、Ｓ１６）。

インスタンス２００（リソース使用率算出部２０１）及びインスタンス３００（リソース使用率算出部３０１）は、算出したリソース使用率をインスタンス１００に送信する（ステップＳ１７、Ｓ１８）。インスタンス１００（サービス移転判断部１０８）は、こうして各インスタンスのリソース使用率を取得する（ステップＳ１９）。次に、インスタンス１００（サービス移転判断部１０８）は、取得したリソース使用率に基づいて、上述したように処理が終了したサービスの移転の有無を判断し（ステップＳ２１）、移転すると判断した場合はその移転先のインスタンスを決定する（ステップＳ２２）。

図７の例ではインスタンス２００が移転先として決定されたものとする。インスタンス１００（サービス移転判断部１０８）は、インスタンス２００に対してサービスの移転要求を行う（ステップＳ３１）。インスタンス２００（サービス移転受付部２０２、コンテナ制御部２０４）は、移転要求が行われたサービスの実行環境を作成する（ステップＳ３２）。

インスタンス１００（サービス停止判断部１０９）は、インスタンス２００に対して移転対象のサービスの状態を問い合わせる（ステップＳ３３）。インスタンス２００（サービス移転状態応答部２０３）は、問い合わせされたサービスの状態をインスタンス１００に通知する（ステップＳ３４）。インスタンス１００（サービス停止判断部１０９）は、実行環境が完成したか否かを判断し（ステップＳ３５）、完成していない（ＮＯ）と判断した場合はステップＳ３３（問い合わせ）に戻って動作を行う。

インスタンス１００（サービス停止判断部１０９）は、実行環境が完成した（ＹＥＳ）と判断した場合は、移転対象のサービスを停止する（ステップＳ３６）。インスタンス１００（サービス停止判断部１０９）は、サービスを停止した結果、自インスタンスで実行されているサービスが０になったか否かを判断し（ステップＳ４１）、０になっていない（ＮＯ）と判断した場合はこの動作手順を終了する。

インスタンス１００（サービス停止判断部１０９）は、自インスタンスで実行されているサービスが０になった（ＹＥＳ）と判断した場合、その旨を第１オートスケール制御部３２に通知する（ステップＳ４２）。第１オートスケール制御部３２は、実行されるサービスが０になったのでスケールインの条件が満たされたと判定し（ステップＳ４３）、インスタンス１００に対してスケールイン、すなわち停止を指示する（ステップＳ４４）。インスタンス１００がこの指示を受け取って自インスタンスを停止した場合も（ステップＳ４５）、この動作手順が終了する。

本実施例では、上記のとおりサービスの実行主体であるインスタンスがリソース使用率の状況によって変化する。これにより、例えばサービスが１つだけになったインスタンスがそのサービスを実行し続けるとインスタンスの数が減らないが、そのサービスを別のインスタンスに移転させることで、サービスの実行主体（インスタンス）を固定する場合に比べて、サービスを実行するインスタンスが少なくなり、上述したインスタンス数単位での課金が少なくなる。

［２］変形例
上述した実施例は本発明の実施の一例に過ぎず、以下のように変形させてもよい。また、実施例及び各変形例は、必要に応じて組み合わせて実施してもよい。

［２－１］リソース使用率の閾値
サービス移転判断部は、自インスタンスのリソース使用率から定まる閾値として実施例とは異なる値を用いてもよい。本変形例では、例えばインスタンス１００のサービス移転判断部１０８が、サービス移転情報永続記憶部３６に記憶されている複数のインスタンスにおけるサービスの移転履歴に基づいて閾値を変化させる。

サービス移転判断部１０８は、例えば、記憶された他のインスタンス（例えばインスタンス２００）の移転履歴が示す移転の頻度が少ないほど、そのインスタンスの移転の有無を判断する際に用いる閾値を小さくする。この閾値を小さくするということは、他のインスタンスのリソース使用率が閾値以上である場合にそのインスタンスが移転先として決定されるのだから、サービスが移転されやすくなることを意味する。サービス移転判断部１０８は、例えば、移転の頻度と閾値とを対応付けた閾値テーブルを用いて閾値を決定する。

図８は閾値テーブルの一例を表す。図８の例では、「Ｆ１未満」、「Ｆ１以上Ｆ２未満」及び「Ｆ２以上」という移転の頻度の範囲に、「Ｒ１×０．５」、「Ｒ１×１．０」及び「Ｒ１×２．０」という閾値が対応付けられている。Ｒ１は、自インスタンス（サービス移転判断部１０８の場合はインスタンス１００）のリソース使用率を表している。この閾値テーブルを用いた場合の移転の有無について図９を参照して説明する。

図９は移転の有無の判断結果の例を表す。図９では、移転すると判断した場合を「○」、移転しないと判断した場合を「×」で示している。図９（ａ）では、インスタンス１００においてサービス１５１、１５２、１５３が実行中であり、インスタンス２００においてサービス２５２、２５３が実行中であり、このうちのサービス１５３が移転対象である。つまり、インスタンス１００の移転後の使用率Ｒ１が１００％でインスタンス２００の移転後の使用率Ｒ２が６６．６・・％である。

この場合に、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ１未満の場合、１００％（Ｒ１）×０．５＝５０％＜６６．６・・％（Ｒ２）なので移転すると判断する。また、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ１以上Ｆ２未満の場合、１００％（Ｒ１）×１．０＝１００％＞６６．６・・％（Ｒ２）なので移転しないと判断し、インスタンス２００の移転の頻度がＦ２以上の場合、１００％（Ｒ１）×２．０＝２００％＞６６．６・・％（Ｒ２）なので移転しないと判断する。

図９（ｂ）では、図９（ａ）の状態からインスタンス１００のサービス１５１が停止して空きになり、インスタンス１００の移転後の使用率Ｒ１が６６．６・・％に変わっている。この場合に、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ１未満の場合、６６．６・・％（Ｒ１）×０．５＝３３．３・・％＜６６．６・・％（Ｒ２）なので移転すると判断し、インスタンス２００の移転の頻度がＦ１以上Ｆ２未満の場合、６６．６・・％（Ｒ１）×１．０＝６６．６・・％＝６６．６・・％（Ｒ２）なので移転すると判断する。また、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ２以上の場合、６６．６・・％（Ｒ１）×２．０＝１３３．３・・％＞６６．６・・％（Ｒ２）なので移転しないと判断する。

図９（ｃ）では、図９（ｂ）の状態からインスタンス１００のサービス１５２が停止して空きになり、インスタンス１００の移転後の使用率Ｒ１が３３．３・・％に変わっている。この場合に、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ１未満の場合、３３．３・・％（Ｒ１）×０．５＝１６．６・・％＜６６．６・・％（Ｒ２）なので移転すると判断し、インスタンス２００の移転の頻度がＦ１以上Ｆ２未満の場合、３３．３・・％（Ｒ１）×１．０＝３３．３・・％＜６６．６・・％（Ｒ２）なので移転すると判断する。また、サービス移転判断部１０８は、インスタンス２００の移転の頻度がＦ２以上の場合も、３３．３・・％（Ｒ１）×２．０＝６６．６・・％＝６６．６・・％（Ｒ２）なので移転すると判断する。

図９の例に表すように、本変形例では、インスタンス２００（他のインスタンスでもよい）の移転履歴が示す移転の頻度が少ないほど、インスタンス２００が移転先として決定されやすくなっている。なお、図９（ｃ）の例のようにＲ２がＲ１よりも十分に大きいと移転の頻度に関わらず常に移転先として決定される場合があるし、反対にＲ２がＲ１に比べて小さすぎると、移転の頻度がいくら小さくても移転先として決定されない場合もある。

また、サービス移転判断部１０８は、他のサービスの移転履歴を用いてもよい。例えば、サービス移転判断部１０８は、記憶された他のインスタンスの移転履歴が示す移転の回数が少ないほど、そのインスタンスの移転の有無を判断する際に用いる閾値を小さくしてもよい。この場合、サービス移転判断部１０８は、移転の回数と閾値とを対応付けた閾値テーブルを用いて閾値を決定する。

図１０は閾値テーブルの別の一例を表す。図１０の例では、「Ｃ１未満」、「Ｃ１以上Ｃ２未満」及び「Ｃ２以上」という移転の回数の範囲に、「Ｒ１×０．５」、「Ｒ１×１．０」及び「Ｒ１×２．０」という閾値が対応付けられている。この閾値テーブルを用いることで、図８に表した移転の頻度の例と同様に、移転の回数が少ないほど小さな閾値が用いられるようになる。

サービスの中には、第２オートスケール制御部３３によるスケールアウト及びスケールインが頻繁に行われるサービス（一時的に利用が集中するサービス）と、それがあまり行われないサービス（利用数の変動が少ないサービス）とがある。前者のサービスを実行しているインスタンスは、後者のサービスを実行しているインスタンスよりも移転後の使用率が小さくなって移転が生じやすく、移転の頻度及び回数が多くなりやすい。そのため、移転の頻度及び回数が少ないインスタンスにサービスを移転すると、移転の頻度及び回数が多いインスタンスを移転先にする場合に比べて移転したサービスがそのインスタンスに定着しやすくなる。

他にも、サービス移転判断部１０８は、記憶された他のインスタンスの移転履歴が示す最新の移転時期が古いほど、そのインスタンスの移転の有無を判断する際に用いる閾値を小さくしてもよい。ここでいう最新の移転時期とは、そのインスタンスにおいて現時点から遡って最後にサービスが移転した時期のことを意味する。この場合、サービス移転判断部１０８は、最新の移転時期と閾値とを対応付けた閾値テーブルを用いて閾値を決定する。

図１１は閾値テーブルの別の一例を表す。図１１の例では、「Ｔ１より前」、「Ｔ１以降Ｔ２より前」及び「Ｔ２以降」という最新の移転時期の範囲に、「Ｒ１×０．５」、「Ｒ１×１．０」及び「Ｒ１×２．０」という閾値が対応付けられている。この閾値テーブルを用いることで、図８に表した移転の頻度の例と同様に、最新の移転時期が古いほど小さな閾値が用いられるようになる。

スケールアウト及びスケールインが頻繁に行われるサービスを実行しているインスタンスは、それがあまり行われないサービスを実行しているインスタンスよりも移転後の使用率が小さくなって移転が生じやすく、最新の移転時期が新しくなりやすい。そのため、最新の移転時期が古いインスタンスにサービスを移転すると、最新の移転時期が新しいインスタンスを移転先にする場合に比べて移転したサービスがそのインスタンスに定着しやすくなる。

以上のとおり、本変形例では、サービスの移転履歴に基づいて閾値を変化させることで、閾値が固定である場合に比べて、移転したサービスがそのインスタンスに定着しやすくなる。

［２－２］移転先の見直し
移転先が決定して移転準備中の状態なったサービスであっても、移転先のインスタンスで実行環境が完成するまでは停止しないので、それまでの間に移転先のインスタンスのリソース使用率が変化する場合がある。その場合に、サービス移転判断部が一度決定した移転先を見直してもよい。

本変形例では、例えばインスタンス１００のサービス移転判断部１０８が、移転対象のサービスが実行していた処理が終了したときに移転先のインスタンスのリソース使用率が閾値未満になっていた場合、他のインスタンスをそのサービスの移転先として決定する。この場合のインスタンス１００の動作手順について図１２を参照して説明する。

図１２は本変形例の移転処理における各装置の動作手順の一例を表す。この動作手順では、図７に表すステップＳ１０（処理の終了）からステップＳ３５（実行環境の完成の判断）までが行われる。次に、インスタンス１００（サービス移転判断部１０８）が、移転先のインスタンス（この例ではインスタンス２００）のリソース使用率算出部に対してリソース使用率の算出を指示する（ステップＳ５１）。

インスタンス２００（リソース使用率算出部２０１）は、この指示を受け取ると自インスタンスのリソース使用率を算出し（ステップＳ５２）、算出したリソース使用率をインスタンス１００に送信する（ステップＳ５３）。インスタンス１００（サービス移転判断部１０８）は、送信されてきたリソース使用率、すなわち移転先のリソース使用率が閾値未満か否かを判断する（ステップＳ５４）。インスタンス１００（サービス停止判断部１０９）は、ステップＳ５４で移転先のリソース使用率が閾値未満ではない（ＮＯ）と判断された場合に、移転対象のサービスを停止する（ステップＳ３６）。図１２では図７のステップＳ４１以降の動作を省略している。

インスタンス１００（サービス移転判断部１０８）は、ステップＳ５４で移転先のリソース使用率が閾値未満である（ＹＥＳ）と判断した場合、ステップＳ１１（算出指示）に戻って動作を行う。ステップＳ１１からの動作が再び行われることで、移転先の見直しが行われる。２回目のステップＳ１１においては、移転が見送られたインスタンス（図１２の例ではインスタンス２００）への算出指示が行われてもよいし、行われなくてもよい。

移転先が決定されてから実際に移転が完了するまではタイムラグがあるので、例えば移転が完了する前にサービスのスケールインが行われて実行されるサービスが少なくなり、移転先として適当でなくなることがある。本変形例では、上記のとおり移転先を見直すことで、移転先を見直さない場合に比べて、そのように移転先として適当でなくなったインスタンスへのサービスの移転が抑制される。

［２－３］割り当てられるリソース
実施例では、説明を分かり易くするため、各インスタンスに割り当てられているリソース（第１リソース）が等しく、各サービスに割り当てられているリソースも全て第１リソースの３分の１であるものとしたが、これに限らない。例えばインスタンス毎に第１リソースが異なっていてもよいし、サービス毎にも割り当てられるリソースが異なっていてもよい。また、各インスタンスで実行されるサービスの数も異なっていてもよい。

［２－４］複数の移転要求
リソースに空きのあるインスタンスには、複数のインスタンスから移転要求が送られてくることがある。実施例のように各サービスのリソースが等しければどちらの移転要求を受け付けても自インスタンスのリソース使用率が変わらないが、上記変形例のように各サービスのリソースが異なっていると、どの移転要求を受け付けるかによって、自インスタンスのリソース使用率が変化する。

そこで、本変形例では、例えばインスタンス１００のサービス移転受付部１０２が、複数の他のインスタンスから移転するサービスの受け入れを要求された場合、自インスタンスの移転後のリソース使用率がより大きくなる移転要求を受け付ける。
図１３は移転要求の受け付けの例を表す。図１３（ａ）では、空きが５０％のインスタンス１００に、４０％のリソースを使用するサービスＡと、３０％のリソースを使用するサービスＢとの移転要求がされている。

この場合、サービス移転受付部１０２は、自インスタンスの移転後のリソース使用率が８０％になるサービスＢよりも、そのリソース使用率が９０％になるサービスＡの移転要求を受け付ける。図１３（ｂ）では、空きが５０％のインスタンス１００に、サービスＡ、Ｂの他に、２０％のリソースを使用するサービスＣの移転要求がされている。この場合、サービス移転受付部１０２は、自インスタンスの移転後のリソース使用率が１００％になるサービスＢ、Ｃの移転要求を受け付ける。

このように移転要求を受け付けることで、自インスタンスの移転後のリソース使用率に関係なく要求を受け付ける場合に比べて、自インスタンスのリソース使用率が高まることになる。なお、サービス移転受付部１０２は、基本的には移転要求のタイミングが早いものから順番に受け付けるが、複数の移転要求が例えば数秒程度の決められた期間内に行われた場合に、上記のとおり受け付ける移転要求を選択する。

［２－５］移転先による移転の見直し
移転要求を受け付けた移転先のインスタンスの方から、その移転を見直してもよい。例えばインスタンス１００のサービス移転受付部１０２は、他のインスタンスからの移転要求を受け付けた後に自インスタンスで実行中のサービスが全て移転予定になった場合、その移転要求の受け付けを撤回してもよい。この場合のインスタンス１００の動作手順について図１４を参照して説明する。

図１４は本変形例の移転処理における各装置の動作手順の一例を表す。この動作手順では、図７に表すステップＳ１０（処理の終了）からステップＳ３１（移転要求）までが行われる。次に、この例における移転先であるインスタンス２００（サービス移転受付部２０２）が、インスタンス１００からの移転要求を受け付けて（ステップＳ６１）、移転要求を受け付けた旨をインスタンス１００に通知する（ステップＳ６２）。

インスタンス２００（コンテナ制御部２０４）は、この通知を行ってから移転要求が行われたサービスの実行環境を作成する（ステップＳ３２）。インスタンス１００（サービス停止判断部１０９）は、インスタンス２００に対して移転対象のサービスの状態を問い合わせる（ステップＳ３３）。インスタンス２００（サービス移転受付部２０２）は、この問い合わせを受け取ると、自インスタンスにおいて、移転要求を受け付けたサービスを除いた全てのサービスが移転準備中になっているか否かを判断する（ステップＳ６３）。

インスタンス２００（サービス移転状態応答部２０３）は、ステップＳ６３で全てのサービスが移転準備中になっているわけではない（ＮＯ）、つまり移転要求を受け付けたサービスを除いて１つでも実行中又は作成中のサービスがあると判断された場合に、問い合わせされたサービスの状態をインスタンス１００に通知する（ステップＳ３４）。インスタンス２００（サービス移転受付部２０２）は、ステップＳ６３で全てのサービスが移転準備中になっている（ＹＥＳ）と判断した場合は、移転要求の受け付けを撤回すると判断し（ステップＳ６４）、その旨をインスタンス１００に通知する（ステップＳ６５）。

インスタンス１００は、この通知を受け取ると、ステップＳ１１（算出指示）に戻って動作を行う。ステップＳ１１からの動作が再び行われることで、移転先の見直しが行われる。２回目のステップＳ１１においては、移転要求の受け付けが撤回されたインスタンス（図１４の例ではインスタンス２００）への算出指示が行われてもよいし、行われなくてもよい。本変形例では、上記のとおり移転要求の受け付けを撤回することで、移転したサービスだけが移転先のインスタンスで実行される事態が防がれるようになっている。

［２－６］受け付け撤回後の移転先の決定
上記変形例で移転要求の受け付けが撤回された場合、再度移転先を決定しなければならないが、この決定を、移転要求の受け付けを撤回したインスタンスの方で行ってもよい。例えば図１４の例の場合、インスタンス２００のサービス移転判断部２０８が、サービス移転受付部２０２が移転要求の受け付けを撤回した場合に、その移転要求が行われたサービスの移転先をその移転要求の時点での要求元のインスタンス（この例ではインスタンス１００）のリソース使用率に基づいて決定する。

本変形例では、例えば図１４のステップＳ３１又はＳ３３でインスタンス１００から自身スタンスのリソース使用率がインスタンス２００に通知される。サービス移転判断部２０８は、ステップＳ６４で受け付けの撤回が判断されると、通知されたリソース使用率から定まる閾値以上のリソース使用率の別のインスタンス（インスタンス１００及び２００以外のインスタンス）の有無を判断する。

別のインスタンスのリソース使用率については、例えば、インスタンス１００がステップＳ１９で取得したものをインスタンス１００のリソース使用率と共に取得してもよいし、インスタンス２００自身が改めて各インスタンスから取得してもよい。また、インスタンス２００が自身のサービスの移転の有無の判断のために各インスタンスのリソース使用率を取得していれば、それを用いてもよい。

サービス移転判断部２０８は、こうして決定した移転先を移転要求の送り元のインスタンス（この例ではインスタンス１００）に通知する。サービス移転判断部２０８は本発明の「通知部」の一例である。移転要求は基本的に早いものから順番に受け付けられるから、移転先の決定が早いほど移転要求も受け付けられやすい。本変形例では、移転要求の受け付けを撤回したインスタンス（上記例ではインスタンス２００）が移転先を決定することで、受け付けが撤回された移転要求の送り元のインスタンス（上記例ではインスタンス１００）が移転先を決定し直す場合に比べて、移転先の決定時期が早くなり、その結果、決定された移転先への移転要求が受け付けられやすくなる。

［２－７］移転判断のタイミング
サービス移転判断部１０８は、実施例では、サービス１５０が処理の実行を終了したときにそのサービス１５０の移転の有無を判断したが、これに限らず、例えば、決められた時間間隔で移転の有無を判断してもよいし、自インスタンスのＣＰＵ使用率又はメモリ使用率が閾値を下回ったときに移転の有無を判断してもよい。

［２－８］比較するリソース使用率
サービス移転判断部１０８は、実施例では、比較するリソース使用率として移転後の使用率を用いたが、現時点での使用率を用いてもよい。例えば図６Ａ（ｃ）の例は、移転後の使用率だとインスタンス１００よりもインスタンス２００の方が小さいので移転が行われなかったが、現時点での使用率であれば両インスタンスとも同じ値になるので、移転が行われる。この場合でも、サービスの実行主体（インスタンス）を固定する場合に比べれば、サービスを実行するインスタンスが少なくなり、インスタンス数単位での課金が少なくなる。

［２－９］仮想化の方式
実施例では、コンテナ型の仮想化技術により仮想マシンが実現されたが、これに限らず、例えばＶＭＷａｒｅ（登録商標）等のハイパーバイザー型の仮想化技術により仮想マシンが実現されてもよい。要するに、物理的に区分された装置（物理マシン）ではなく、論理的に区分されて１台の装置のように振る舞う仮想マシンが実現されるのであれば、どのような技術が用いられてもよい。

［２－１０］各機能の実現方法
図４、図５に表す各機能は、２以上の機能が統合されてもよいし、１つの機能が２以上の機能に分割されてもよい。例えば、リソース使用率算出部１０１が、現時点での使用率を算出する算出部と、移転後の使用率を算出する算出部とに分割されてもよい。また、サービス移転判断部１０８及びサービス停止判断部１０９が統合されてサービスに関する判断をまとめて行う判断部としてもよい。

また、実施例では、インスタンス以外の機能である第１オートスケール制御部３２等も仮想マシンで実現されていたが、これらについては物理マシンで実現されてもよい。また、実施例では、各サーバ装置１０がインスタンス以外の機能をそれぞれ備えていたが、それらの機能が複数のサーバ装置１０で共有されていてもよい。要するに、リソース提供システム１の全体で図４、図５に表す各機能と同等の機能が実現されていれば、機能のまとめ方はどのようになっていてもよい。

［２－１１］発明のカテゴリ
本発明は、サーバ装置１０及びリソース管理装置２０という各情報処理装置の他、それらの情報処理装置を備えるリソース提供システムという情報処理システムとしても捉えられる。また、本発明は、各装置が実施する処理を実現するための情報処理方法としても捉えられるし、各装置を制御するコンピュータを機能させるためのプログラムとしても捉えられる。このプログラムは、それを記憶させた光ディスク等の記録媒体の形態で提供されてもよいし、インターネット等の通信回線を介してコンピュータにダウンロードさせ、それをインストールして利用可能にするなどの形態で提供されてもよい。

１…リソース提供システム、１０…サーバ装置、２０…リソース管理装置、３０…仮想マシン実現部、３１…インスタンス群、３２…第１オートスケール制御部、３３…第２オートスケール制御部、３４…リクエスト・レスポンスキュー、３５…サービス定義記憶部、３６…サービス移転情報永続記憶部、４１…現状情報表示部、４２…履歴情報表示部、１００、２００、３００…インスタンス、１０１…リソース使用率算出部、１０２…サービス移転受付部、１０３…サービス移転状態応答部、１０４…コンテナ制御部、１０５…コンテナ実行部、１０６…サービス状態管理部、１０７…サービス状態記憶部、１０８…サービス移転判断部、１０９…サービス停止判断部、１１０…サービス移転先記憶部、１５０…サービス。

Claims (19)

1. 複数の仮想マシンを実現する実現部を備えるコンピュータを、
   第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
   前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部
   として機能させるためのプログラムであって、
   前記実行部は、前記第２仮想マシンへの移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成するまでは当該サービスに新たな処理を実行させる
   プログラム。
2. 複数の仮想マシンを実現する実現部を備えるコンピュータを、
   第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
   前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部
   として機能させるためのプログラムであって、
   前記実現部は、前記第２仮想マシンに移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成していなくても当該サービスに新たな処理を実行させない
   プログラム。
3. 複数の仮想マシンを実現する実現部を備えるコンピュータを、
   第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
   前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
   他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部
   として機能させるためのプログラムであって、
   前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、
   前記受付部は、複数の他の仮想マシンから移転するサービスの受け入れを要求された場合、移転後の前記リソース使用率がより大きくなる要求を受け付ける
   プログラム。
4. 複数の仮想マシンを実現する実現部を備えるコンピュータを、
   第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
   前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
   他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部
   として機能させるためのプログラムであって、
   前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、
   前記受付部は、他の仮想マシンからのサービスの受け入れの要求を受け付けた後に前記第２仮想マシンで実行中のサービスが全て移転予定になった場合、当該要求の受け付けを撤回する
   プログラム。
5. 前記決定部は、前記受付部が前記要求の受け付けを撤回した場合に、当該要求が行われたサービスの移転先を当該要求の時点での前記第１仮想マシンのリソース使用率に基づいて決定し、
   前記コンピュータを、
   決定された前記移転先を前記要求の送り元の仮想マシンに通知する通知部として機能させる
   請求項４に記載のプログラム。
6. 複数の仮想マシンを実現する実現部を備えるコンピュータを、
   第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
   前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
   前記リソース使用率を示す情報を出力する使用率出力部
   として機能させるためのプログラム。
7. 前記コンピュータを、
   仮想マシンで実行中のサービスに割り当てられている第２リソースの前記第１リソースに対する第１割合を前記リソース使用率として算出する第１算出部と、
   他の仮想マシンに移転予定のサービスを除いた前記実行中のサービスに割り当てられている第３リソースの前記第１リソースに対する第２割合を前記リソース使用率として算出する第２算出部と、
   複数の仮想マシンにおける前記第１割合及び前記第２割合を取得する取得部として機能させ、
   前記決定部は、前記第２仮想マシンについての前記第１割合又は前記第２割合が示す空きリソースで実行可能なサービスが前記実行部により実行中である場合、前記第１仮想マシンの前記第２割合から定まる閾値以上の前記第２割合が前記第２仮想マシンについて取得されたときに当該第２仮想マシンを当該サービスの移転先として決定する
   請求項１から６のいずれか一項に記載のプログラム。
8. 前記決定部は、取得された前記第１仮想マシンの前記第２割合を前記閾値とする
   請求項７に記載のプログラム。
9. 前記コンピュータを、
   前記第２仮想マシンにおけるサービスの移転履歴を記憶する記憶部として機能させ、
   前記決定部は、記憶された前記第２仮想マシンの前記移転履歴に基づいて前記閾値を変化させる
   請求項１から８のいずれか１項に記載のプログラム。
10. 前記決定部は、記憶された前記第２仮想マシンの前記移転履歴が示す移転の頻度又は移転の回数が少ないほど前記閾値を小さくする
    請求項９に記載のプログラム。
11. 前記決定部は、記憶された前記第２仮想マシンの前記移転履歴が示す最新の移転時期が古いほど前記閾値を小さくする
    請求項９に記載のプログラム。
12. 前記決定部は、移転対象のサービスが実行していた処理が終了したときに移転先の前記第２仮想マシンの前記リソース使用率が前記閾値未満になっていた場合、他の仮想マシンを当該サービスの移転先として決定する
    請求項１から１１のいずれか１項に記載のプログラム。
13. 前記コンピュータを、
    複数の仮想マシンにおけるサービスの移転履歴を記憶する記憶部と、
    記憶された前記移転履歴を出力する履歴出力部として機能させる
    請求項１から１２のいずれか１項に記載のプログラム。
14. 前記コンピュータを、
    前記実行部によるサービスの実行状態を示す情報を出力する実行状態出力部として機能させる
    請求項１から１３のいずれか１項に記載のプログラム。
15. 複数の仮想マシンを実現する実現部と、
    第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
    前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と
    を備え、
    前記実行部は、前記第２仮想マシンへの移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成するまでは当該サービスに新たな処理を実行させる
    情報処理装置。
16. 複数の仮想マシンを実現する実現部と、
    第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
    前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と
    を備え、
    前記実現部は、前記第２仮想マシンに移転が決定されたサービスがある場合、当該第２仮想マシンで当該サービスの実行環境が完成していなくても当該サービスに新たな処理を実行させない
    情報処理装置。
17. 複数の仮想マシンを実現する実現部と、
    第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
    前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
    他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部と
    を備え、
    前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、
    前記受付部は、複数の他の仮想マシンから移転するサービスの受け入れを要求された場合、移転後の前記リソース使用率がより大きくなる要求を受け付ける
    情報処理装置。
18. 複数の仮想マシンを実現する実現部と、
    第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
    前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
    他の仮想マシンから移転するサービスの受け入れを要求された場合に当該要求を受け付ける受付部と
    を備え、
    前記実行部は、前記受付部により要求が受け付けられたサービスを実行し、
    前記受付部は、他の仮想マシンからのサービスの受け入れの要求を受け付けた後に前記第２仮想マシンで実行中のサービスが全て移転予定になった場合、当該要求の受け付けを撤回する
    情報処理装置。
19. 複数の仮想マシンを実現する実現部と、
    第１仮想マシンに割り当てられた第１リソースを用いて複数のサービスを実行する実行部と、
    前記第１仮想マシンのリソース使用率から定まる閾値以上のリソース使用率の第２仮想マシンを前記実行部が実行するサービスの移転先として決定する決定部と、
    前記リソース使用率を示す情報を出力する使用率出力部と
    を備える情報処理装置。

Images