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

Abstract

【課題】サービスの実行主体を固定する場合に比べて、サービスを実行する仮想マシンを少なくすること。【解決手段】リソース使用率算出部４０３は、各インスタンス５０のリソース使用率を算出する。サービス移転判断部４０４は、取得したリソース使用率に基づいて、複数のインスタンス５０から、１以上のサービスを実行可能な空きリソースを有するインスタンス５０を、移転先候補として検出する。移転対象選択部４０５は、検出されたインスタンス５０（移転先候補）のリソース使用率が、複数のインスタンス５０のうちその移転先候補の空きリソースで実行可能なサービス６０（移転対象候補）を実行中のインスタンス５０（移転元候補）のリソース使用率から定まる閾値以上である場合、その移転先候補をその移転対象候補の移転先として決定する。【選択図】図５

Description

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

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

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

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

本発明の請求項１に係るプログラムは、コンピュータを、各々が自身に割り当てられた第１リソースを用いて複数のサービスを実行する複数の仮想マシンから、１以上のサービスを実行可能な空きリソースを有する第１仮想マシンを検出する検出部と、検出された前記第１仮想マシンのリソース使用率が、前記複数の仮想マシンのうち前記空きリソースで実行可能なサービスを実行中の第２仮想マシンのリソース使用率から定まる閾値以上である場合、前記第１仮想マシンを当該サービスの移転先として決定する決定部として機能させることを特徴とする。

本発明の請求項２に係るプログラムは、請求項１に記載の構成において、前記決定部は、サービスの移転元の候補となる前記第２仮想マシンが複数ある場合、当該サービスの移転後に前記リソース使用率が他の前記移転元の候補よりも小さくなる前記第２仮想マシンを移転元とするサービスの移転先を決定することを特徴とする。

本発明の請求項３に係るプログラムは、請求項１又は２に記載の構成において、前記決定部は、移転可能なサービスが複数ある場合、実行中の処理が他のサービスに比べて早く終わるサービスの移転先を決定することを特徴とする。

本発明の請求項４に係るプログラムは、請求項１から３のいずれか１項に記載の構成において、前記決定部は、前記空きリソースで実行可能なサービスが前記第２仮想マシンとは別の仮想マシンを用いて冗長化されている場合、当該サービスについては前記移転先を決定しないことを特徴とする。

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

本発明の請求項６に係るプログラムは、請求項５に記載の構成において、前記決定部は、サービスの移転元の候補となる前記第２仮想マシンが複数ある場合、当該サービスの移転後に前記第２割合が他の前記移転元の候補よりも小さくなる前記第２仮想マシンで実行されているサービスの前記移転先を決定することを特徴とする。

本発明の請求項７に係るプログラムは、請求項５又は６に記載の構成において、前記決定部は、移転先の候補の前記第１仮想マシンが複数ある場合、前記空きリソースにサービスが移転した後の前記第２割合が他の前記移転先の候補よりも大きい前記第１仮想マシンを前記移転先として決定することを特徴とする。

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

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

本発明の請求項１０に係るプログラムは、請求項８に記載の構成において、前記決定部は、記憶された前記第１仮想マシンの移転履歴が示す最新の移転時期が古いほど前記閾値を小さくすることを特徴とする。

本発明の請求項１１に係るプログラムは、請求項１から１０のいずれか１項に記載の構成において、前記決定部は、複数の方法のいずれかを用いて前記移転先を決定し、前記複数の方法のうち、決定した前記移転先にサービスを移転させたことで前記第２仮想マシンが実行するサービスの数が０となった頻度又は回数が多い方法ほど優先して用いることを特徴とする。

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

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

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

本発明の請求項１５に係る情報処理装置は、各々が自身に割り当てられた第１リソースを用いて複数のサービスを実行する複数の仮想マシンから、１以上のサービスを実行可能な空きリソースを有する第１仮想マシンを検出する検出部と、検出された前記第１仮想マシンのリソース使用率が、前記複数の仮想マシンのうち前記空きリソースで実行可能なサービスを実行中の第２仮想マシンのリソース使用率から定まる閾値以上である場合、前記第１仮想マシンを当該サービスの移転先として決定する決定部とを備えることを特徴とする。

請求項１、５、１５に係る発明によれば、サービスの実行主体を固定する場合に比べて、サービスを実行する仮想マシンを少なくすることができる。
請求項２、６に係る発明によれば、他の仮想マシンを移転元にする場合に比べて、リソースの空きを特定の仮想マシンに偏らせることができる。
請求項３に係る発明によれば、処理の終了時期に関係なくサービスを移転させる場合に比べて、サービスの移転時期を早めることができる。
請求項４に係る発明によれば、冗長化されたサービスの移転先を決定する場合に比べて、そのサービスの復旧ミスを減らすことができる。
請求項７に係る発明によれば、他の仮想マシンを移転先にする場合に比べて、特定の仮想マシンにサービスを偏らせることができる。
請求項８に係る発明によれば、閾値が固定である場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項９に係る発明によれば、移転の頻度又は回数が多い仮想マシンを移転先にする場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項１０に係る発明によれば、最新の移転時期が新しい仮想マシンを移転先にする場合に比べて移転したサービスが移転先に定着しやすいようにすることができる。
請求項１１に係る発明によれば、移転先の決定方法を固定する場合に比べて、サービスを実行する仮想マシンを少なくすることができる。
請求項１２に係る発明によれば、移転先を見直さない場合に比べて、移転先として適当でなくなったインスタンスへのサービスの移転を抑制することができる。
請求項１３に係る発明によれば、各仮想マシンにおける過去の移転の経緯を把握することができる。
請求項１４に係る発明によれば、サービスの実行状態から移転状況を把握することができる。

実施例に係るリソース提供システムの全体構成を表す図 サーバ装置のハードウェア構成を表す図 リソース管理装置のハードウェア構成を表す図 リソース提供システムが実現する機能構成を表す図 リソース提供システムが実現する機能構成を表す図 移転先の決定例を表す図 移転先の決定例を表す図 複数の移転元候補の例を表す図 複数の移転先候補の例を表す図 移転処理における各装置の動作手順の一例を表す図 閾値テーブルの一例を表す図 移転先の決定結果の例を表す図 閾値テーブルの別の一例を表す図 閾値テーブルの別の一例を表す図 変形例の移転処理における各装置の動作手順の一例を表す図 移転対象サービスの決定例を表す図

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

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

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

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

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

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

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

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

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

図５に表すように、移転制御部４０は、サービス状態管理部４０１と、サービス状態記憶部４０２と、リソース使用率算出部４０３と、サービス移転判断部４０４と、移転対象選択部４０５と、サービス停止判断部４０６と、サービス移転情報記憶部４０７とを備える。リソース管理装置２０は、サービス管理情報表示部２０１を備える。インスタンス群３１は、インスタンス５０−１、インスタンス５０−２及びインスタンス５０−３等の複数のインスタンスを備える。以下それらを区別しない場合は「インスタンス５０」という。

インスタンス５０−１は、コンテナ制御要求受付部５１−１と、コンテナ実行部５２−１と、コンテナ制御部５３−１とを備える。インスタンス５０−２は、コンテナ制御要求受付部５１−２と、コンテナ実行部５２−２と、コンテナ制御部５３−２とを備える。なお、インスタンス５０−３以降の各インスタンスもいずれもインスタンス５０−１及びインスタンス５０−２と共通の機能を備える。各インスタンス５０の機能を区別しない場合、以下ではそれぞれ「コンテナ制御要求受付部５１」、「コンテナ実行部５２」、「コンテナ制御部５３」という。

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

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

コンテナ制御要求受付部５１は、自インスタンスの外部からのコンテナに対する制御要求を受け付けて、コンテナ制御部５３に要求内容を伝達する。コンテナ実行部５２は、自インスタンスに割り当てられたリソースを用いて上述したＯＣＲサービス等の複数のサービスを実行する。インスタンスにリソースを割り当てるとは、そのインスタンスのためにリソースを確保することである。インスタンス内では、各サービスに対しても同様にリソースが割り当てられる（確保される）。

コンテナ実行部５２−１は、図５の例では、サービス６１−１、サービス６１−２及びサービス６１−３という３つのサービスを実行しており、インスタンス５０−２のコンテナ実行部５２−２は、サービス６２−１、サービス６２−２及びサービス６２−３という３つのサービスを実行している。以下では各サービスを区別しない場合は「サービス６０」という。

リソース提供システム１では、各インスタンス５０及び各サービス６０が各々の識別情報（インスタンスＩＤ（Identification）、サービスＩＤ）によって識別されるようになっている。以下では、各インスタンス５０及び各サービス６０に関する情報には常にそれらの識別情報が付与されており、どのインスタンス５０及びサービス６０の情報であるかが分かるようになっているものとする。

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

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

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

移転制御部４０は、サービス６０の移転に関する動作を制御する機能であり、各インスタンス５０とは独立して動作する。インスタンス群３１においては、インスタンス間でサービス６０が移転される。サービス６０の移転とは、本実施例では、移転元のインスタンスで実行されているサービス６０を移転先のインスタンスで実行させ、移転元のインスタンスで実行されていたサービス６０を停止させることをいう。

移転制御部４０のサービス状態管理部４０１は、各インスタンス５０のコンテナ実行部５２におけるサービス６０の状態を取得して管理する。サービス６０の状態には、作成中、実行中、移転準備中の３つの状態が含まれる。「作成中」は、コンテナ実行部５２がサービス６０の実行環境を作成している途中であることを意味し、作成中のサービス６０は処理を実行することができない状態である。

「実行中」は、サービス６０の実行環境の作成が完了しており、コンテナ実行部５２が処理を実行することができる状態である。リクエストがなくて処理を実行していなくても、実行環境の作成が完了していれば実行中の状態となる。移転先のサービス６０の状態が作成中から実行中になると、後述するように移転制御部４０が移転元のサービス６０を停止させる。こうして移転元のサービス６０を停止したときに移転が完了する。

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

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

コンテナ実行部５２は、サービス６０の状態が変更された場合、サービス６０が停止された場合、「実行中」の状態のサービス６０が処理を開始した場合、又は、その処理が終了した場合に、その旨をコンテナ制御部５３及びコンテナ制御要求受付部５１を介してサービス状態管理部４０１に通知する。サービス状態管理部４０１は、この通知を受け取ると、サービス６０の状態をサービス状態記憶部４０２に記憶させ、既にそのサービス６０の状態が記憶されている場合は状態を更新する。こうしてサービス状態記憶部４０２は、各インスタンス５０のサービス６０の状態を記憶する。

リソース使用率算出部４０３は、各インスタンス５０のリソース使用率を算出する。インスタンス５０のリソース使用率とは、そのインスタンス５０に割り当てられているリソースのうち、そのインスタンス５０で実行されているサービス６０に割り当てられているリソースの割合をいう。リソース使用率算出部４０３は、現時点での使用率と、移転後の使用率とをリソース使用率として算出する。

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

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

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

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

リソース使用率算出部４０３は、サービス移転判断部４０４からリソース使用率の算出を指示されたときに、サービス状態記憶部４０２から各インスタンス５０のサービスの状態を読み出してリソース使用率を算出する。リソース使用率算出部４０３は、算出したインスタンス５０のリソース使用率をサービス移転判断部４０４に供給する。

サービス移転判断部４０４は、サービス６０の移転に関する判断を行う。サービス移転判断部４０４は、本実施例では、決められた時間間隔でこの判断を行う。サービス移転判断部４０４は、この時間間隔が経過すると、前述したようにリソース使用率算出部４０３にリソース使用率の算出を指示して各インスタンス５０のリソース使用率（現時点での使用率及び移転後の使用率）を取得する。

サービス移転判断部４０４は、取得したリソース使用率に基づいて、まず、複数のインスタンス５０（各々が自身に割り当てられたリソースを用いて複数のサービスを実行する複数の仮想マシン）から、１以上のサービスを実行可能な空きリソースを有するインスタンス５０を、移転先候補として検出する。サービス移転判断部４０４は本発明の「検出部」の一例である。

以下では、説明を分かり易くするため、各インスタンス５０に割り当てられているリソースが等しく、各サービス６０に割り当てられているリソースも等しく全て第１リソースの３分の１であるという前提を置くこととする。つまり、どのインスタンス５０でも最大で３つのサービス６０が実行されるようになっている。なお、これらの前提はあくまで説明の便宜上のものであり、本発明はこれに限定されない。

サービス移転判断部４０４は、例えば、取得した現時点での使用率が２つ以下のサービス６０を実行するときの使用率（つまり６６．６・・％以下）である場合、少なくとも１つのサービス６０を実行するだけの空きリソースがあるから、そのインスタンス５０を移転先候補として検出する。

また、サービス移転判断部４０４は、サービス状態記憶部４０２から各インスタンス５０のサービス６０の状態を取得して、取得した状態に基づいて移転対象候補となるサービス６０（実際に移転させる対象となるサービス６０の候補）を検出する。サービス移転判断部４０４は、本実施例では、「実行中」の状態になっているサービス６０のうち、処理を実行していないサービス６０（つまり処理を終了した状態になっているサービス６０）を移転対象候補として検出する。

また、サービス移転判断部４０４は、検出した移転対象候補のサービス６０を実行しているインスタンス５０を移転元候補として検出する。サービス移転判断部４０４は、こうして検出した移転対象候補、移転元候補及び移転先候補を示す識別情報を、取得したリソース使用率（現時点での使用率及び移転後の使用率）を移転対象選択部４０５に供給する。移転対象選択部４０５は、供給された識別情報が示す移転対象候補、移転元候補及び移転先候補から、実際に移転させる対象となるものを選択する。

移転対象選択部４０５は、検出されたインスタンス５０（移転先候補）のリソース使用率が、複数のインスタンス５０のうちその移転先候補の空きリソースで実行可能なサービス６０（移転対象候補）を実行中のインスタンス５０（移転元候補）のリソース使用率から定まる閾値以上である場合、その移転先候補をその移転対象候補の移転先として決定する。移転対象選択部４０５は本発明の「決定部」の一例である。

本実施例では、サービス移転判断部４０４は、比較するリソース使用率として移転後の使用率を用い、閾値として移転元候補の移転後の使用率を用いる。つまり、サービス移転判断部４０４は、移転元候補の移転後の使用率（本実施例における閾値）以上の移転後の使用率が算出された移転先候補を移転先として決定する。移転先の決定方法について図６Ａ、図６Ｂを参照して説明する。

図６Ａ、図６Ｂは移転先の決定例を表す。図６の例では、説明を簡単にするため、インスタンス５０−１及びインスタンス５０−２だけが実現されているものとして説明する。図６Ａ（ａ）では、インスタンス５０−１においてサービス６１−１、６１−２が実行中の状態で且つ処理を実行している状態（処理中）であり、サービス６１−３が実行中の状態だが処理が終了している状態（処理終了）である。また、インスタンス５０−２ではサービス６２−１、６２−２、６２−３が実行中且つ処理中の状態である。

サービス移転判断部４０４は、この例では、処理終了の状態のサービス６１−３を移転対象候補として検出し、サービス６１−３を実行するインスタンス５０−１を移転元候補として検出するが、インスタンス５０−２にはサービス６１−３を実行可能な空きリソースがないので、インスタンス５０−２を移転先候補として検出しない。従って、サービス６１−３がインスタンス５０−２に移転されることはない。

図６Ａ（ｂ）では、図６Ａ（ａ）の状態からサービス６１−１及びサービス６２−１が停止して空きリソースが生じている。この場合、サービス移転判断部４０４は、インスタンス５０−２にサービス６１−３を実行可能な空きリソースがあるので移転先候補として検出する。移転対象選択部４０５は、移転先候補（インスタンス５０−２）の移転後の使用率（６６．６・・％）が移転元候補（インスタンス５０−１）の移転後の使用率（６６．６・・％）以上であるため、インスタンス５０−２を移転先として決定する。

このように、本実施例では、移転後の使用率が同じインスタンス同士でもどちらかにサービスが寄せられることになる。こうしてサービスの実行主体を特定のインスタンス５０に偏らせることで、反対にサービスの実行主体にならないインスタンス５０、すなわち停止させてもよいインスタンス５０が増え、それらのインスタンス５０を停止させることで利用中のインスタンスの数に応じた課金が減少する。

図６Ａ（ｃ）では、図６Ａ（ｂ）の状態からサービス６２−２が移転準備中に変化している。この場合、サービス移転判断部４０４は、インスタンス５０−２の現時点での使用率がサービス６１−３を実行させるための空きを示しているため、インスタンス５０−２を移転先候補として検出する。しかし、移転先候補（インスタンス５０−２）の移転後の使用率（３３．３・・％）が移転元候補（インスタンス５０−１）の移転後の使用率（６６．６・・％）未満であるため、移転対象選択部４０５はインスタンス５０−２を移転先として決定しない。

図６Ａ（ｄ）では、図６Ａ（ｃ）の状態からサービス６１−１及び６１−２が移転準備中に変化している。この場合、移転先候補の現時点の使用率（６６．６・・％）は移転元候補の現時点の使用率（１００％）未満だが、移転先候補の移転後の使用率（３３．３・・％）は移転元候補の移転後の使用率（３３．３・・％）以上であるため、移転対象選択部４０５は、移転先候補であるインスタンス５０−２を移転先として決定する。

図６Ｂ（ｅ）では、図６Ａ（ｃ）の状態からサービス６１−２及び６２−３が移転準備中に変化している。この場合、移転先候補の現時点の使用率（６６．６・・％）は移転元候補の現時点の使用率（６６．６・・％）以上だが、移転先候補の移転後の使用率（０％）は移転元候補の移転後の使用率（３３．３・・％）未満であるため、移転対象選択部４０５は、移転先候補であるインスタンス５０−２を移転先として決定しない。

図６Ｂ（ｆ）では、図６Ａ（ｃ）の状態からサービス６１−２及び６２−１が移転準備中に変化している。この場合、移転先候補の移転後の使用率（３３．３・・％）が移転元候補の移転後の使用率（３３．３・・％）以上になるが、現時点ではインスタンス５０−２に空きリソースがないので、サービス移転判断部４０４は、インスタンス５０−２を移転先候補として検出しない。

なお、図６Ｂ（ｆ）の場合にも移転が行われるように、サービス移転判断部４０４は、移転後の使用率が示す空きリソースで移転対象候補のサービス６０を実行可能なインスタンス５０−２を移転先候補として検出するようにしてもよい。そうすれば、図６Ｂ（ｆ）の場合でも、サービス移転判断部４０４がインスタンス５０−２を移転先候補として検出し、移転対象選択部４０５がインスタンス５０−２を移転先として決定することになる。

移転元候補及び移転先候補はそれぞれ複数検出される場合がある。それらの場合の移転先の決定方法について説明する。まず、移転対象選択部４０５は、移転元候補となるインスタンス５０が複数ある場合、移転対象のサービス６０が移転した後のリソース使用率が他の移転元候補よりも小さくなる（つまりそのリソース使用率が最小の）インスタンス５０を移転元として決定し、そのインスタンス５０を移転元とする移転対象のサービス６０の移転先を決定する。

図７は複数の移転元候補の例を表す。図７（ａ）では、インスタンス５０−１においてサービス６１−２が実行中且つ処理中の状態であり、サービス６１−３が実行中且つ処理終了の状態である。また、インスタンス５０−２ではサービス６２−１、６２−２が実行中且つ処理中の状態であり、サービス６２−３が実行中且つ処理終了の状態である。この場合、インスタンス５０−１及び５０−２のどちらも移転元対象として検出される。

移転対象選択部４０５は、リソース使用率算出部４０３により算出された移転後の使用率から、移転対象のサービス６０によるリソース使用率を減じた値を、移転対象のサービス６０が移転した後のリソース使用率として用いる。図７（ａ）の例では、インスタンス５０−１のリソース使用率は３３．３・・％で、インスタンス５０−２のリソース使用率は６６．６・・％となるので、移転対象選択部４０５は、リソース使用率がより小さい方のインスタンス５０−１を移転元として決定する。

図７（ｂ）では、図７（ａ）からサービス６２−１、６２−２の状態が実行中から移転準備中に変化している。この場合は、インスタンス５０−１のリソース使用率は３３．３・・％のままだが、インスタンス５０−２のリソース使用率は０％となるので、移転対象選択部４０５は、リソース使用率がより小さい方のインスタンス５０−２を移転元として決定する。このように移転元を決定することで、他のインスタンス５０を移転元として決定する場合に比べて、リソースの空きが特定のインスタンス５０に偏ることになる。その結果、実行するサービスが０になるインスタンス５０が生じやすくなり、インスタンス５０を停止させやすくなる。

移転対象選択部４０５は、空きリソースを有して移転先候補となっているインスタンス５０が複数ある場合、その空きリソースに移転対象のサービス６０が移転した後のリソース使用率が他の移転先候補よりも大きい（つまりそのリソース使用率が最大の）インスタンス５０を移転先として決定する。
図８は複数の移転先候補の例を表す。図８（ａ）では、インスタンス５０−１においてサービス６１−３が実行中の状態であり、インスタンス５０−２ではサービス６２−２、６２−３が実行中の状態である。この場合、インスタンス５０−１及び５０−２のどちらも移転先対象として検出される。

移転対象選択部４０５は、リソース使用率算出部４０３により算出された移転後の使用率に、移転対象のサービス６０によるリソース使用率を加えた値を、移転対象のサービス６０が移転した後のリソース使用率として用いる。図８（ａ）の例では、インスタンス５０−１のリソース使用率は、３３．３・・％（移転後の使用率）＋３３．３・・％（サービス６０によるリソース使用率）＝６６．６・・％となり、インスタンス５０−２のリソース使用率は、６６．６・・％（移転後の使用率）＋３３．３・・％（サービス６０によるリソース使用率）＝１００％となるので、移転対象選択部４０５は、リソース使用率がより大きい方のインスタンス５０−２を移転先として決定する。

図８（ｂ）では、図８（ａ）からサービス６２−２、６２−３の状態が実行中から移転準備中に変化している。この場合は、インスタンス５０−１のリソース使用率は図８（ａ）の例と同じで６６．６・・％となるが、インスタンス５０−２のリソース使用率は、０％（移転後の使用率）＋３３．３・・％（サービス６０によるリソース使用率）＝３３．３・・％となるので、移転対象選択部４０５は、リソース使用率がより大きい方のインスタンス５０−１を移転先として決定する。

このように移転先を決定することで、他のインスタンス５０を移転先として決定する場合に比べて、移転後に移転先のインスタンス５０に集まるサービス６０が多くなり、特定のインスタンス５０にサービス６０が集中することになる。すると、それ以外のインスタンス５０にはサービス６０が集まらなくなり、そうしてサービス６０が少なくなったインスタンス５０からはサービス６０が移転で出て行きやすくなるので、その結果、インスタンス５０を停止させやすくなる。

移転対象選択部４０５は、サービス６０の移転先を決定した場合、移転先のインスタンスのコンテナ制御要求受付部５１に移転するサービス６０の配置を要求する。この要求により上記のとおり移転先のインスタンス５０に移転対象のサービス６０と同じサービス６０の実行環境が作成される（例えば移転対象がＯＣＲサービスなら移転先でもＯＣＲサービスの実行環境が作成される）。また、移転対象選択部４０５は、決定した移転先のインスタンス５０、移転元のインスタンス５０及び移転対象のサービス６０の識別情報をサービス停止判断部４０６に供給する。

サービス停止判断部４０６は、受け取った識別情報が示す移転先のインスタンス５０のコンテナ制御要求受付部５１に移転対象のサービス６０の状態を問い合わせる。サービス停止判断部４０６は、移転対象のサービス６０の状態が作成中から実行中になった場合、受け取った識別情報が示す移転元のインスタンス５０のコンテナ制御要求受付部５１にその移転対象のサービス６０の停止を依頼する。移転元のコンテナ制御部５３がこの依頼に基づきサービス６０を停止すると、移転が完了する。

サービス停止判断部４０６は、移転が完了すると、サービス６０の移転に関する情報（サービス移転情報）として、例えば供給された移転先のインスタンス５０、移転元のインスタンス５０及び移転対象のサービス６０の識別情報と、移転が完了した時刻を示す時刻情報とをサービス移転情報記憶部４０７に供給する。サービス移転情報記憶部４０７は、サービス停止判断部４０６から供給されたサービス移転情報を記憶する。サービス移転情報記憶部４０７は、記憶したサービス移転情報をサービス管理情報記憶部３６に供給する。

サービス管理情報記憶部３６は、供給されたサービス移転情報を蓄積して、複数のインスタンス５０におけるサービス６０の移転履歴として記憶する。また、サービス管理情報記憶部３６は、サービス状態記憶部４０２から、複数のインスタンス５０におけるサービス６０の実行状態（作成中、実行中、移転準備中）を示す実行状態情報を取得して記憶する。

また、サービス管理情報記憶部３６は、リソース使用率算出部４０３から、複数のインスタンス５０におけるリソース使用率（現時点での使用率及び移転後の使用率）を示す使用率情報を取得して記憶する。サービス管理情報記憶部３６は本発明の「記憶部」の一例である。なお、サービス管理情報記憶部３６への移転履歴、実行状態情報及び使用率情報の供給は、サービス管理情報記憶部３６から要求するプル型で行われてもよいし、供給元が能動的に供給してくるプッシュ型で行われてもよい。

リソース管理装置２０のサービス管理情報表示部２０１は、サービス管理情報記憶部３６に記憶されたサービス管理情報を表示する。例えば、リソース提供システム１の管理者がサービス６０の移転履歴を表示させる操作を行うと、サービス管理情報表示部２０１は、サービス管理情報記憶部３６からサービス６０の移転履歴を取得して表示する。この場合のサービス管理情報記憶部３６は、記憶している複数のインスタンス５０におけるサービス６０の移転履歴を表示手段であるサービス管理情報表示部２０１に出力する機能であり、本発明の「履歴出力部」の一例である。このように複数のインスタンスにおけるサービスの移転履歴が出力されることで、各インスタンスにおける過去の移転の経緯が把握される。

また、管理者が全て又は一部のインスタンス５０における実行状態情報（サービス６０の実行状態を示す情報）を表示させる操作を行うと、サービス管理情報表示部２０１は、サービス管理情報記憶部３６から指定されたインスタンス５０の実行状態情報を取得して表示する。この場合のサービス管理情報記憶部３６は、記憶している複数のインスタンス５０における実行状態情報を表示手段であるサービス管理情報表示部２０１に出力する機能であり、本発明の「状態出力部」の一例である。

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

また、管理者が全て又は一部のインスタンス５０におけるリソース使用率（現時点での使用率及び移転後の使用率）を表示させる操作を行うと、サービス管理情報表示部２０１は、サービス管理情報記憶部３６から指定されたインスタンス５０の使用率情報を取得して、その使用率情報が示すリソース使用率を表示する。これにより、リソース使用率から移転状況が把握されることになる。例えばリソース使用率が高い数値で維持されているインスタンスは移転で出入りするサービスが少なく、リソース使用率が低い数値で変化しているインスタンスは移転で出入りするサービスが多いことが把握される。

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

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

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

リソース提供システム１が備える各装置は、上記の構成に基づいて、インスタンス間でサービスを移転させる移転処理を行う。
図９は移転処理における各装置の動作手順の一例を表す。図９では、インスタンス５０−１及び５０−２だけを表しているが、他にもインスタンス５０が存在するものとする。まず、インスタンス５０が、サービス状態の変更又はサービスの停止を行うと（ステップＳ１１、Ｓ１２）、その旨を移転制御部４０に通知し（ステップＳ１３、Ｓ１４）、第１オートスケール制御部３２にも通知する（ステップＳ１５、Ｓ１６）。

移転制御部４０（リソース使用率算出部４０３）は、通知されてきた情報に基づいて各インスタンス５０のリソース使用率（現時点での使用率及び移転後の使用率）を算出する（ステップＳ２１）。次に、移転制御部４０（サービス移転判断部４０４）は、算出されたリソース使用率に基づいて移転先候補のインスタンス５０を検出する（ステップＳ２２）。続いて、移転制御部４０（サービス移転判断部４０４）は、算出されたリソース使用率に基づいて移転対象候補のサービス６０とそのサービス６０を実行する移転元候補のインスタンス５０を検出する（ステップＳ２３）。

そして、移転制御部４０（移転対象選択部４０５）は、検出された移転先候補、移転対象及び移転元候補から、実際に移転させる移転対象のサービス６０と、移転元のインスタンス５０と、移転先のインスタンス５０とを決定する（ステップＳ２４）。図９の例ではインスタンス５０−１が移転先として、インスタンス５０−２が移転元として決定されたものとする。移転制御部４０（移転対象選択部４０５）は、移転元として決定されたインスタンス５０−１に、移転するサービス６０の配置を要求する（ステップＳ３１）。

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

移転制御部４０（サービス停止判断部４０６）は、ステップＳ３５で実行環境が完成した（ＹＥＳ）と判断した場合は、移転対象のサービス６０を停止するよう、移転元のインスタンス５０−２に対して依頼する（ステップＳ３６）。インスタンス５０−２は、依頼されたサービスを停止して（ステップＳ３７）、その旨をステップＳ１６と同様に第１オートスケール制御部３２に通知する（ステップＳ４１）。

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

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

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

［２−１］リソース使用率の閾値
移転対象選択部４０５は、移転元候補のインスタンス５０のリソース使用率から定まる閾値として実施例とは異なる値を用いてもよい。移転対象選択部４０５は、例えば、サービス移転情報記憶部４０７に記憶されている複数のインスタンスにおけるサービスの移転履歴に基づいて閾値を変化させる。この場合のサービス移転情報記憶部４０７は本発明の「記憶部」の一例である。

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

図１０は閾値テーブルの一例を表す。図１０の例では、「Ｆ１未満」、「Ｆ１以上Ｆ２未満」及び「Ｆ２以上」という移転の頻度の範囲に、「Ｒ１×０．５」、「Ｒ１×１．０」及び「Ｒ１×２．０」という閾値が対応付けられている。Ｒ１は、移転先候補のインスタンスのリソース使用率を表している。この閾値テーブルを用いた場合の移転先の決定結果について図１１を参照して説明する。

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

この場合に、移転対象選択部４０５は、インスタンス５０−２の移転の頻度がＦ１未満の場合、１００％（Ｒ１）×０．５＝５０％＜６６．６・・％（Ｒ２）なのでインスタンス５０−２を移転先として決定する。また、移転対象選択部４０５は、インスタンス５０−２の移転の頻度がＦ１以上Ｆ２未満の場合は１００％（Ｒ１）×１．０＝１００％＞６６．６・・％（Ｒ２）となり、インスタンス５０−２の移転の頻度がＦ２以上の場合は１００％（Ｒ１）×２．０＝２００％＞６６．６・・％（Ｒ２）となるので、どちらの場合もインスタンス５０−２を移転先として決定しない。

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

図１１（ｃ）では、図１１（ｂ）の状態からインスタンス５０−１のサービス６１−２が停止して空きになり、インスタンス５０−１の移転後の使用率Ｒ１が３３．３・・％に変わっている。この場合に、移転対象選択部４０５は、インスタンス５０−２の移転の頻度がＦ１未満の場合は３３．３・・％（Ｒ１）×０．５＝１６．６・・％＜６６．６・・％（Ｒ２）となり、インスタンス５０−２の移転の頻度がＦ１以上Ｆ２未満の場合は３３．３・・％（Ｒ１）×１．０＝３３．３・・％＜６６．６・・％（Ｒ２）となり、インスタンス５０−２の移転の頻度がＦ２以上の場合は３３．３・・％（Ｒ１）×２．０＝６６．６・・％＝６６．６・・％（Ｒ２）となるので、いずれの場合もインスタンス５０−２を移転先として決定する。

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

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

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

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

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

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

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

以上のとおり、本変形例では、サービスの移転履歴に基づいて閾値を変化させることで、閾値が固定である場合に比べて、移転したサービスがそのインスタンスに定着しやすくなる。その結果、上述したサービスの実行主体の偏りが維持されやすくなり、反対にサービスの実行主体にならないインスタンスが増えやすくなって、それらのインスタンスがスケールインにより停止させられることで利用中のインスタンスの数に応じた課金が減少する。

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

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

図１４は本変形例の移転処理における各装置の動作手順の一例を表す。この動作手順では、図９に表すステップＳ１１（サービス状態の変更・サービスの停止）からステップＳ３５（実行環境の完成の判断）までが行われる。次に、移転制御部４０（移転対象選択部４０５）が、移転先のインスタンス（この例ではインスタンス５０−１）に対してサービス状態を問い合わせる（ステップＳ５１）。

インスタンス５０−１は、この問い合わせを受け取ると自インスタンスのサービスの状況を移転制御部４０に通知する（ステップＳ５２）。移転制御部４０（リソース使用率算出部４０３）は、通知されたサービスの状態を反映してリソース使用率を算出する（ステップＳ５３）。次に、移転制御部４０（移転対象選択部４０５）は、インスタンス５０−１、すなわち移転先のリソース使用率が閾値未満か否かを判断する（ステップＳ５４）。

移転制御部４０（サービス停止判断部４０６）は、ステップＳ５４で移転先のリソース使用率が閾値未満ではない（ＮＯ）と判断された場合は、ステップＳ３６（サービス停止の依頼）の動作を行う。図１４では図７のステップＳ４１以降の動作を省略している。ステップＳ５４で移転先のリソース使用率が閾値未満である（ＹＥＳ）と判断された場合、移転制御部４０（リソース使用率算出部４０３）は、ステップＳ２１（リソース使用率の算出）に戻って動作を行う。ステップＳ２１からの動作が再び行われることで、移転先の見直しが行われる。

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

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

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

そこで、本変形例では、移転制御部４０の移転対象選択部４０５が、複数の移転元候補のインスタンスからのサービスを移転先候補のインスタンスに移転させた場合に、移転先候補のリソース使用率がより大きくなるサービスを移転対象として決定する。
図１５は移転対象サービスの決定例を表す。図１５（ａ）では、空きが５０％のインスタンス５０−１が移転先候補として検出され、４０％のリソースを使用するサービスＡと、３０％のリソースを使用するサービスＢとが移転対象候補のサービスとして検出されている。

この場合、移転対象選択部４０５は、移転先候補（インスタンス５０−１）の移転後のリソース使用率が８０％になるサービスＢよりも、そのリソース使用率が９０％になるサービスＡを移転対象サービスとして決定する。図１５（ｂ）では、空きが５０％のインスタンス５０−１が移転先候補として検出され、サービスＡ、Ｂの他に、２０％のリソースを使用するサービスＣが移転対象候補のサービスとして検出されている。

この場合、移転対象選択部４０５は、移転先候補の移転後のリソース使用率が１００％になるサービスＢ、Ｃを移転対象サービスとして決定する。このように移転要求を受け付けることで、移転先候補の移転後のリソース使用率に関係なく移転対象サービスを決定する場合に比べて、移転先候補のリソース使用率が高まることになる。

なお、移転対象選択部４０５は、他の方法で移転対象サービスを決定してもよい。移転対象選択部４０５は、移転可能なサービス（移転対象候補のサービス）が複数ある場合、実行中の処理が他のサービスに比べて早く終わるサービスの移転先を決定する、すなわちそのサービスを移転対象サービスとして決定する。この場合、インスタンス５０のコンテナ実行部５２が、サービス６０の状態として、そのサービス６０が実行している処理の終了見込み時刻をサービス状態管理部４０１に通知することで、サービス状態記憶部４０２がその終了見込み時刻を記憶する。

移転対象選択部４０５は、複数の移転対象候補のサービスの各終了見込み時刻を読み出し、その時刻が最も早いサービスを移転対象サービスとして決定する。これにより、処理の終了時期に関係なくサービスを移転させる場合に比べて、サービスの移転時期が早まるので、サービスの実行主体の特定のインスタンス５０への偏りもより早く進み、停止させてもよいインスタンスもより早く生じることになる。

［２−５］サービスの冗長化
移転対象候補のサービスの中には、他のインスタンスを用いて冗長化（ホットスタンバイ型の冗長化、コールドスタンバイ型の冗長化又はレプリケーションによる冗長化等）がなされている場合がある。その場合に、移転対象選択部４０５は、そのように冗長化されたサービスについては移転先を決定しなくてもよい。本変形例では、インスタンス５０のコンテナ実行部５２が、サービス６０の状態として、そのサービス６０の冗長化の有無をサービス状態管理部４０１に通知することで、サービス状態記憶部４０２がその冗長化の有無を記憶する。

移転対象選択部４０５は、複数の移転対象候補のサービスの冗長化の有無を読み出し、冗長化がなされているサービスについては、移転対象候補から外して移転先を決定せず、冗長化がなされていないサービスについて移転先を決定する。これにより、冗長化されたサービスであっても移転先を決定して移転させる場合に比べて、その冗長化されたサービスの復旧ミスが減ることになる。

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

［２−７］有効な決定方法の選択
移転対象選択部４０５は、複数の移転先候補から実際に移転を行う移転先を決定する方法として、実施例及び変形例で述べた複数の決定方法のいずれかを用いてもよい。複数の決定方法とは、例えば、図７で述べた移転対象のサービスが移転した後のリソース使用率が他の移転元候補よりも小さくなるインスタンスを移転元として決定する第１の方法、そのリソース使用率を求めるのに移転後の使用率を用いる代わりに現時点での使用率を用いる第２の方法、第１の方法で移転先を決定した後に図１４で述べた移転先の見直しを行う第３の方法、又は、第１の方法で移転先を決定した後に移転先を見直す第４の方法である。

その場合に、移転対象選択部４０５は、それらの複数の決定方法のうち、決定した移転先にサービスを移転させたことで移転元のインスタンスが実行するサービスの数が０となった頻度又は回数が多い方法ほど優先して用いてもよい。本変形例では、インスタンス５０のコンテナ実行部５２が、自インスタンスのサービスの状態として、移転対象のサービスを停止させたときに実行しているサービスの数をサービス状態管理部４０１に通知することで、サービス状態記憶部４０２がそのサービス移転時の残りのサービスの数を記憶する。

移転対象選択部４０５は、例えば、一定期間は上記の複数の決定方法を均等に用いて移転先を決定し、その際に用いた決定方法をサービス状態管理部４０１に通知することで、サービス状態記憶部４０２が通知された決定方法を前述した残りのサービスの数に対応付けて記憶する。移転対象選択部４０５は、その期間が過ぎると、移転先を決定する際にサービス状態記憶部４０２を参照し、残りのサービスの数が０になった頻度を決定方法毎に算出する。

移転対象選択部４０５は、算出した頻度が多い決定方法ほど優先して用いて、移転先を決定する。具体的には、例えば第１、第２、第３、第４の方法における上記頻度の比率が３：１：４：２であれば、１０分の３の確率で第１の方法を用いるという具合である。頻度ではなく回数を用いる場合も同様に行えばよい。これにより、移転先の決定方法を固定する場合に比べて、より移転元のインスタンスに残るサービスが０になりやすくなるので、サービスを実行する仮想マシンが少なくなりやすくなる。

なお、複数の決定方法として、移転対象のサービスを決定する複数の決定方法が用いられてもよい。その場合に、移転対象選択部４０５は、それらの複数の決定方法のうち、決定した移転対象のサービスを移転させたことで移転元のインスタンスが実行するサービスの数が０となった頻度又は回数が多い方法ほど優先して用いてもよい。また、複数の決定方法として、移転元のインスタンスを決定する複数の決定方法が用いられてもよい。その場合に、移転対象選択部４０５は、それらの複数の決定方法のうち、決定した移転元のインスタンスのサービスを移転させたことでその移転元のインスタンスが実行するサービスの数が０となった頻度又は回転が多い方法ほど優先して用いてもよい。

移転対象選択部４０５は、それらの複数の決定方法のうち、決定した移転元のインスタンスのサービスを移転させたことで移転元のインスタンスが実行するサービスの数が０となった頻度又は回数が多い方法ほど優先して用いてもよい。いずれの場合も、移転先の決定方法を固定する場合に比べて、より移転元のインスタンスに残るサービスが０になりやすくなるので、サービスを実行する仮想マシンが少なくなりやすくなる。

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

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

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

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

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

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

Claims (15)

1. コンピュータを、
   各々が自身に割り当てられた第１リソースを用いて複数のサービスを実行する複数の仮想マシンから、１以上のサービスを実行可能な空きリソースを有する第１仮想マシンを検出する検出部と、
   検出された前記第１仮想マシンのリソース使用率が、前記複数の仮想マシンのうち前記空きリソースで実行可能なサービスを実行中の第２仮想マシンのリソース使用率から定まる閾値以上である場合、前記第１仮想マシンを当該サービスの移転先として決定する決定部
   として機能させるためのプログラム。
2. 前記決定部は、サービスの移転元の候補となる前記第２仮想マシンが複数ある場合、当該サービスの移転後に前記リソース使用率が他の前記移転元の候補よりも小さくなる前記第２仮想マシンを移転元とするサービスの移転先を決定する
   請求項１に記載のプログラム。
3. 前記決定部は、移転可能なサービスが複数ある場合、実行中の処理が他のサービスに比べて早く終わるサービスの移転先を決定する
   請求項１又は２に記載のプログラム。
4. 前記決定部は、前記空きリソースで実行可能なサービスが前記第２仮想マシンとは別の仮想マシンを用いて冗長化されている場合、当該サービスについては前記移転先を決定しない
   請求項１から３のいずれか１項に記載のプログラム。
5. 前記コンピュータを、
   実行中の１以上のサービスに割り当てられた第２リソースの前記第１リソースに対する第１割合を前記リソース使用率として前記複数の仮想マシンのそれぞれについて算出する第１算出部と、
   他の仮想マシンに移転予定のサービスを除いた前記実行中のサービスに割り当てられた第３リソースの前記第１リソースに対する第２割合を前記リソース使用率として前記複数の仮想マシンのそれぞれについて算出する第２算出部として機能させ、
   前記決定部は、前記第２仮想マシンの前記第２割合から定まる閾値以上の前記第２割合が算出された前記第１仮想マシンを前記空きリソースで実行可能なサービスの移転先として決定する
   請求項１から４のいずれか１項に記載のプログラム。
6. 前記決定部は、サービスの移転元の候補となる前記第２仮想マシンが複数ある場合、当該サービスの移転後に前記第２割合が他の前記移転元の候補よりも小さくなる前記第２仮想マシンで実行されているサービスの前記移転先を決定する
   請求項５に記載のプログラム。
7. 前記決定部は、移転先の候補の前記第１仮想マシンが複数ある場合、前記空きリソースにサービスが移転した後の前記第２割合が他の前記移転先の候補よりも大きい前記第１仮想マシンを前記移転先として決定する
   請求項５又は６に記載のプログラム。
8. 前記コンピュータを、
   前記複数の仮想マシンにおけるサービスの移転履歴を記憶する記憶部として機能させ、
   前記決定部は、記憶された前記移転履歴に基づいて前記閾値を変化させる
   請求項１から７のいずれか１項に記載のプログラム。
9. 前記決定部は、記憶された前記第１仮想マシンの移転履歴が示す移転の頻度又は移転の回数が少ないほど前記閾値を小さくする
   請求項８に記載のプログラム。
10. 前記決定部は、記憶された前記第１仮想マシンの移転履歴が示す最新の移転時期が古いほど前記閾値を小さくする
    請求項８に記載のプログラム。
11. 前記決定部は、複数の方法のいずれかを用いて前記移転先を決定し、前記複数の方法のうち、決定した前記移転先にサービスを移転させたことで前記第２仮想マシンが実行するサービスの数が０となった頻度又は回数が多い方法ほど優先して用いる
    請求項１から１０のいずれか１項に記載のプログラム。
12. 前記決定部は、前記空きリソースで実行可能なサービスが実行していた処理が終了したときに前記第１仮想マシンの前記リソース使用率が前記閾値未満になっていた場合、他の仮想マシンを当該サービスの移転先として決定する
    請求項１から１１のいずれか１項に記載のプログラム。
13. 前記コンピュータを、
    前記複数の仮想マシンにおけるサービスの移転履歴を記憶する記憶部と、
    記憶された前記移転履歴を出力する履歴出力部として機能させる
    請求項１から１２のいずれか１項に記載のプログラム。
14. 前記コンピュータを、
    前記複数の仮想マシンにおけるサービスの実行状態を示す情報を出力する状態出力部として機能させる
    請求項１から１３のいずれか１項に記載のプログラム。
15. 各々が自身に割り当てられた第１リソースを用いて複数のサービスを実行する複数の仮想マシンから、１以上のサービスを実行可能な空きリソースを有する第１仮想マシンを検出する検出部と、
    検出された前記第１仮想マシンのリソース使用率が、前記複数の仮想マシンのうち前記空きリソースで実行可能なサービスを実行中の第２仮想マシンのリソース使用率から定まる閾値以上である場合、前記第１仮想マシンを当該サービスの移転先として決定する決定部と
    を備える情報処理装置。

Images