JP2012221273A - 動的にリソースを割り当てる方法、システム及びプログラム - Google Patents

Abstract

【課題】クラウド・コンピューティングにおいて、クライアントに、動的スケーラビリティの品質要求を可能にする。
【解決手段】動的スケーラビリティの品質要求指標を可変にし、与えられた指標を満たすように、事前準備を組み合わせたプラットフォーム・サービスを提供することによって達成される。プラットフォームの許容量拡大の上限と拡大スピードへの要求をもって、一定の確実性を担保された動的スケーラビリティの品質要求の指標とする。この要求を満たすように、クラウド・サーバは、ホット・スタンバイ、スワップ・アウト状態、コールド・スタンバイなどの様々な事前準備状況のプラットフォームを組み合わせて提供する。クラウド・サーバは、例えば、記憶系リソースを異なる予約間で共用する一方で、複数の実リソースに多重化して割り当てる。そして、すべての利用者のスケールアップの状況を常にモニタし、共用と多重化を調整する。
【選択図】図６

Description

この発明は、クラウド・コンピューティング・システムなどのサーバ環境における制御に関し、クライアントからのサービス要求の変化に対応して、サーバ環境がクライアントに提供するリソースを動的に変化させる技法に関する。

近年、通信インフラの改善により、コンピュータの間の通信速度が高まるにつれて、ホスト・コンピュータを自社内ではなく、海外など、遠隔の地に配置することが可能となってきた。このため、多数のサーバを配置して、所定のアプリケーション、計算リソース、あるいは、ストレージなどの使用をユーザにレンタルするベンダがあらわれてきた。このような形態のコンピュータ・リソースの使い方は、クラウド・コンピューティングと呼ばれる。

クラウド・コンピューティングは下記のような種類に類別される。
・ＳａａＳ(Software as a service)：これは、ソフトウェアをサービスとして提供するものである。例えば、給与計算プログラムの使用を、クライアントに提供する。
・ＰａａＳ(Platform as a service)：これは、プラットフォームをサービスとして提供するものである。一般的に、スケーリングを考慮せずアプリケーションを動かせるという特徴がある。すなわち、クラウド・コンピューティングのベンダは、クライアントからのサービス要求が増大するにつれて、自動的にリソースを追加するので、性能低下をクライアントに体感させない。プラットフォームには、データベース、アプリケーション実行環境、管理ツールなどのミドルウェアが含まれる。
・ＩａａＳ(Infrastructure as a service)：これは、仮想マシンやストレージなどのインフラストラクチャを提供するものである。そのインフラストラクチャ上で、所望のオペレーティング・システムやミドルウェアを導入できる。この場合、クライアントがスケーリングを考慮する必要がある。

クラウド・コンピューティング、特にＰａａＳの最大の魅力の１つとして、サービス要求の量の変化に応じて柔軟に、サーバの規模を変化させられるということがある。

このような要求をみたす１つの仕組みとして、ロード・バランサがある。例えば、WebSphere(商標) Virtual Enterpriseなどでは、予め用意しておいた複数のサーバの許容量までの要求の増加に対応できる。ただ、ロード・バランサの仕組みを実現するには、複数のサーバを予め用意して走らせておかなくてはならない。すると、活きているサーバ・インスタンスで課金されると、チャージが高価になる。

別の仕組みとして、クラウドＡＰＩがある。例えば、Amazon(商標) Web Serviceなどでは、クラウドにおけるサーバ・インスタンスの作成・起動などを制御することが可能である。しかし、サーバ・インスタンスの作成や起動に時間がかかりすぎるという問題がある。

この技術分野で、下記のような特許文献がある。
まず、特開平１１−２８２６９５号公報は、多重システム・クラスタ内のサーバの数を制御する方法及び装置に関し、入来作業要求がサービス・クラスに編成され、それらの各々がクラスタに渡って、サーバによりサービスされるキューを有するようになされる。各サービス・クラスは予め、所定の性能指標を割当てられる。各システムはサービス・クラスがそれらの目標にどれ程良く合致するかにもとづき、あるサービス・クラスを、システム資源を提供するドナー・クラスとして選択し、別のサービス・クラスを、システム資源を受け取るレシーバ・クラスとして選択する。各システムは次に、レシーバ・クラスがその目標を逸する原因となる資源ボトルネックがサーバの数の場合、各システムは、サーバの追加がレシーバ・クラスの性能指標に及ぼすプラスの効果が、ドナー・クラスの性能指標に及ぼすマイナスの効果を上回るか否かにもとづき、幾つのサーバがレシーバ・クラスに追加されるべきかを決定する。

特開２００２−１６３２４１号公報は、需要変動に応じて、サービス提供側の資源を動的に再構成することに関し、開示されているシステムによれば、各クライアント１からのアクセス要求（サービス要求）は、負荷分散装置により、サーバクラスタで稼働中のいずれかのサーバに振り分けられる。そして、アクセスが増大又は減少すると、管理モジュールは、サーバクラスタの構成変更を指示し、サーバクラスタへのサーバ６の追加又はサーバクラスタからのサーバの削除等を行わせる。サーバクラスタの構成変更は、管理モジュールにより負荷分散装置のアクセス振り分け先リストに反映される。

特開２００３−１６２５１６号公報は、複数の利用者から発行される大容量データのデータ処理要求に対応するために、ネットワーク、プロセッサ、データストレージなどの資源の動的静的構成と、データ処理業務の動的静的割当てが可能な高速大容量データ処理システムを実現することに関し、複数台の高速データ処理装置と複数台のデータ蓄積装置を超高速ネットワークで接続したネットワーク後置サーバーと、複数の端末装置から発行されるデータ処理要求に対応してデータストレージのネットワーク上の位置とネットワークの負荷、データ処理の負荷を動的静的に勘案して、ネットワークトポロジ、プロセッサトポロジの動的静的構成と複数の高速データ処理装置へのデータ処理業務の動的静的分配を行い、ネットワークの負荷とデータ処理の負荷を動的静的に配分する機能を備えることによって高速大容量データ処理が可能なマルチプロセッサシステムおよびデータ蓄積システムを開示する。

特開２００５−１４１６０５号公報は、複数のサービス間で余剰のリソースを融通でき、余剰リソースの維持コストが低減できるリソース配分方法に関し、待機系計算機リソースが、少なくともアプリケーションがインストールされていないデッドスタンバイ状態を持ち、このデッドスタンバイ状態の計算機リソースを複数サービスや複数ユーザで共有することで、遊休計算機リソースの使用率の向上やサーバ統合を実現し、計算機リソース維持に必要なコストを削減し、また、個々のサービスに関し過去の稼動履歴を用いて負荷予測を行い、余剰のでるサービスから確保して維持している遊休計算機リソースを予測結果に応じて投入することを開示する。

特開２００９−３７３６９号公報は、データ量の増加や複数バッチ処理の同時実行によりバッチ処理が予め設定した要求時間内に終了しないという課題を解決するために、バッチ処理実行中にて既に実行済みＳＱＬの処理時間及びリソース使用量をもとに未実行バッチ処理手順の処理時間及びリソース使用量を算出した後、バッファヒット率等のデータベースサーバの状態を示す情報、I/O回数やCPU負荷などのOSの情報を用いて処理手順及びリソース使用量を再計算し、必要に応じてリソースの割当てを行うことを開示する。

また、この技術分野で、下記のような非特許文献がある。

Donald Kossmann, Tim Kraska, Simon Loesing: An evaluation of alternative architectures for transaction processing in the cloud, SIGMOD 2010, pp.579-590は、クラウド・コンピューティングにおけるトランザクション処理について記述する。

Tim Kraska, Martin Hentschel, Gustavo Alonso, Donald Kossmann: Consistency Rationing in the Cloud: Pay only when it matters. VLDB 2009, pp.253-264は、設計者にデータ上での一貫性保証を定義することを可能ならしめるだけでなく、ランタイムで一貫性保証を切り替えることをも可能にするトランザクション・パラダイムを記述する。

Carsten Binnig, Donald Kossmann, Tim Kraska, Simon Loesing: How is the weather tomorrow?: towards a benchmark for the cloud. DBTest 2009は、クラウド・コンピューティングのシステムのスケーラビリティ、フォールト・トレランスなどのベンチマーキングについて記述する。

これらの従来技術によれば、クラウド・コンピューティング・システムにおいて、サービス要求に対して、必要なだけリソースを割り当る技術は教示される。

一方、特にＰａａＳにおいて、動的に変化していくサービスの要求の負荷に、求められるスピードや確実性を満たしながら、効率よくリソースを割り当る技術の対する要望があらわれてきている。しかし、上記従来技術では、このような要望に十分応えることはできない。

特開平１１−２８２６９５号公報 特開２００２−１６３２４１号公報 特開２００３−１６２５１６号公報 特開２００５−１４１６０５号公報 特開２００９−３７３６９号公報

Donald Kossmann, Tim Kraska, Simon Loesing: An evaluation of alternative architectures for transaction processing in the cloud, SIGMOD 2010, pp.579-590 Tim Kraska, Martin Hentschel, Gustavo Alonso, Donald Kossmann: Consistency Rationing in the Cloud: Pay only when it matters. VLDB 2009, pp.253-264 Carsten Binnig, Donald Kossmann, Tim Kraska, Simon Loesing: How is the weather tomorrow?: towards a benchmark for the cloud. DBTest 2009

従って、この発明の目的は、クラウド・コンピューティングなどのサービスにおいて、クライアントに、所定の確実度の範囲で動的スケーラビリティの品質要求を可能ならしめることにある。

上記目的は、本発明に従い、動的スケーラビリティの品質要求指標を可変にし、与えられた指標を満たすように、様々な手段からなる事前準備を組み合わせたプラットフォーム・サービスを提供することによって達成される。

すなわち、プラットフォームの許容量拡大の上限と拡大スピードへの要求をもって、一定の確実性を担保された動的スケーラビリティの品質要求の指標とする。この要求を満たすように、本発明に従うクラウド・サーバは、ホット・スタンバイ、スワップ・アウト状態、コールド・スタンバイなどの様々な事前準備状況のプラットフォームを組み合わせて提供する。

本発明に従うクラウド・サーバは、例えば、記憶系リソースを異なる予約間で共用する一方で、複数の実リソースに多重化して割り当てる。そして、すべての利用者のスケールアップの状況を常にモニタし、与えられた確実性を満たすように、共用と多重化を調整する。

動作において、クラウド・コンピューティングなどのサービスのユーザは、予め所定の動的スケーラビリティのサービス品質保証契約(service level agreement = SLA)を、クラウド・コンピューティングのプロバイダと結んでおく。これには限定されないが、ここでは、主としてＰａａＳを想定する。そして、ユーザは、必要に応じて、クラウド・サーバに対してリクエストを送る。クラウド・サーバは、受け取ったリクエストを一旦キューに入れて、順次処理していく。

リクエストには、ユーザからの仮想マシン（ＶＭ）追加要求であるＵｐイベント処理と、ユーザからの仮想マシン（ＶＭ）削除要求であるＤｏｗｎイベント処理が含まれる。

クラウド・サーバは、リクエストがＵｐイベント処理である場合、リソースの予約テーブルを更新して、該当ＶＭインスタンスを追加し、利用するＣＰＵを、ＣＰＵのプール集合から削除し、リソース割当調整処理を行う。

一方、クラウド・サーバは、リクエストがＤｏｗｎイベント処理である場合、該当ＶＭインスタンスを削除し、それによって利用可能になったＣＰＵを、 ＣＰＵのプール集合に戻し、確実性が満たされるかどうか判断する。ここで確実性が満たされるとは、予約の現在の確実性が、サービス品質保証契約で要求されている確実性より大きいということである。もしそうでないなら、クラウド・サーバは、ＣＰＵのプール集合をみて、ＣＰＵが割当可能か判断し、もし割当可能なら、ハードウェア・リソースを追加する。

確実性は、例えば、ポアッソン分布などに従い、確率的に計算することができる。

この発明によれば、クラウド・サービスなどのサーバ提供サービスにおいて、動的スケーラビリティを妥当な価格でユーザに提供することが可能になる。例えば、「１００インスタンスを、３０分で、８０％の確実性で」増強できるように、というリクエストを受けることができ、またそのような条件に適切に価格設定可能である。これにより、従来考えられなかった新しいＳＬＡが提示可能となる。

本発明を実施するための全体構成の概要を示す図である。 クライアント・コンピュータの一例の構成のブロック図である。 サーバ・コンピュータの一例の構成のブロック図である。 仮想化のための構成を示すブロック図である。 仮想化のための管理アプリケーションの構成を示すブロック図である。 キュー処理のフローチャートを示す図である。 Ｕｐイベント処理のフローチャートを示す図である。 Ｄｏｗｎイベント処理のフローチャートを示す図である。 リソース割当調整処理のフローチャートを示す図である。 テーブル更新処理のフローチャートを示す図である。 テーブル更新処理のフローチャートを示す図である。 予約テーブルのエントリの例を示す図である。 予約テーブルのエントリの例を示す図である。 リソースの準備状態とコストの対応を示す図である。 ＶＭインスタンスを立ち上げを示す図である。 本発明の仕組みと、従来技術の仕組みとの、性能及びコストの相違点を図式的に説明する図である。

以下、図面を参照して、本発明の実施例を説明する。特に断わらない限り、同一の参照番号は、図面を通して、同一の対象を指すものとする。また、以下で説明するのは、本発明の一実施形態であり、この発明を、この実施例で説明する内容に限定する意図はないことに留意されたい。

図１は、本発明を実施するためのシステム全体の概要を示す図である。クラウド・サーバのユーザが使うクライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚは、詳細には図示しないが、適当なプロキシ・サーバなどを介して、インターネット１０４に接続されている。

クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚはさらに、インターネット１０４を介して、クラウド・サービス、特にＰａａＳサービスのプロバイダのシステム１１０に接続される。

システム１１０は、スケジューラ１１２と、好適にはハードディスクに保存された、スケジューラ１１２の予約スケジュールのデータ１１４と、クライアント・コンピュータからのリクエストを入れるためのキュー１１６と、リソース・アロケータ１１８と、好適にはハードディスクに保存され、リソース・アロケータ１１８が参照し更新する予約テーブルのデータ１２０と、キュー１１６のデータに基づきユーザの状況を監視するユーザ・モニタ１２２と、計算資源としての複数のコンピュータ（計算ノード）１３２、・・・１５２と、記憶資源としてのストレージ・エリア・ネットワーク（ＳＡＮ）、ネットワーク接続ストレージ（ＮＡＳ）、あるいは遠隔ディスク装置であるディスク・ストレージ装置１５４、１５６、１５８・・からなるハードウェア・リソース・プール１３０を有する。

スケジューラ１１２は、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚからのリクエストを受付け、一旦予約スケジュール１１４に格納する。そして、リクエストによって指定された日時になると、そのリクエストをキュー１１６に入れ、リソース・アロケータ１１８の処理に委ねる。

この実施例では、クラウド・コンピューティングなどのサービスのユーザは、予め所定の動的スケーラビリティのサービス品質保証契約(service level agreement = SLA)を、クラウド・コンピューティングのプロバイダと結んでおく。このような契約の内容は、予めプロバイダの所定のシステムに格納され、必要に応じて参照される。このような契約の内容は、例えば、予約スケジュール１１４に含めてもよい。

リクエストには、動的スケーラビリティのサービス品質保証契約の内容、ユーザからの仮想マシン（ＶＭ）追加要求であるＵｐイベント処理と、ユーザからの仮想マシン（ＶＭ）削除要求であるＤｏｗｎイベント処理などが含まれえる。

リソース・アロケータ１１８は、リクエストがＵｐイベント処理である場合、予約テーブル１２０を更新して、ＶＭインスタンスを追加し、利用するハードウェア資源（特にＣＰＵ）を、ハードウェア・リソース・プール１３０から、リソース割当調整する。なおここでＣＰＵとは具体的に、ハードウェア・リソース・プール１３０におけるコンピュータ（計算ノード）１３２、１３４などのことである。

一方、リソース・アロケータ１１８は、リクエストがＤｏｗｎイベント処理である場合、該当ＶＭインスタンスを削除し、それによって利用可能になったＣＰＵを、ＣＰＵのリソース・プールに戻し、確実性が満たされるかどうか判断する。ここで確実性が満たされるとは、サービス品質保証契約に従う予約の要求されている確実性が、予約の現在の確実性より大きいということである。もしそうなら、リソース・アロケータ１１８は、予約テーブル１２０をみて、ＣＰＵが割当可能か判断し、もしそうなら、ＣＰＵを追加する。

リソース・アロケータ１１８は、クライアントからのリクエストに応じて、ハードウェア・リソース・プール１３０のリソースを割当あるいは開放するだけではなく、動作状況を監視する役割も果たす。

なお、スケジューラ１１２、リソース・アロケータ１１８、及びユーザ・モニタ１２２の機能は、コンピュータ・ハードウェアのハードディスクに導入されたソフトウェアとして実現することができ、当該コンピュータに導入されたオペレーティング・システムの働きで、当該コンピュータの主記憶にロードされて実行される。

スケジューラ１１２、リソース・アロケータ１１８、及びユーザ・モニタ１２２は、好適には同一のコンピュータ・ハードウェア上で実行され、予約スケジュール１１４と、予約テーブル１２０は、当該のコンピュータのハードディスクに保存されてもよく、あるいは、そのうちの一部が、ネットワーク接続された別のコンピュータ・ハードウェア上にあってもよい。

次に、図２を参照して、クライアント・コンピュータ１０２ａ、１０２ｂ・・・１０２ｚの例示的な構成を説明する。

次に、図２を参照して、図１で参照番号１０６ａ、１０６ｂ・・・１０６ｚのように示されているクライアント・コンピュータのハードウェア・ブロック図について、説明する。図２において、クライアント・コンピュータは、主記憶２０６、ＣＰＵ２０４、ＩＤＥコントローラ２０８をもち、これらは、バス２０２に接続されている。バス２０２には更に、ディスプレイ・コントローラ２１４と、通信インターフェース２１８と、ＵＳＢインターフェース２２０と、オーディオ・インターフェース２２２と、キーボード・マウス・コントローラ２２８が接続されている。ＩＤＥコントローラ２０８には、ハードディスク・ドライブ（ＨＤＤ）２１０と、ＤＶＤドライブ２１２が接続されている。ＤＶＤドライブ２１２は、必要に応じて、ＣＤ−ＲＯＭやＤＶＤから、プログラムを導入するために使用する。ディスプレイ・コントローラ２１４には、好適には、ＬＣＤ画面をもつディスプレイ装置２１６が接続されている。ディスプレイ装置２１６には、Ｗｅｂブラウザを通じて、アプリケーションの画面が表示される。

ＵＳＢインターフェース２２０には、必要に応じて、拡張ハードディスクなどのデバイスを接続をすることができる。

キーボード・マウス・コントローラ２２８には、キーボード２３０と、マウス２３２が接続されている。キーボード２３０とマウス２３２は、テキスト・エディタなどの所定のプログラムを使って、プロバイダによって定義されたＡＰＩを使用したプログラムを作成したり、使用される。

ＣＰＵ２０４は、例えば、３２ビット・アーキテクチャまたは６４ビット・アーキテクチャに基づく任意のものでよく、インテル社のPentium（インテル・コーポレーションの商標）4、Core(商標)2 Duo、AMD社のAthlon（商標）などを使用することができる。

ハードディスク・ドライブ２１０には、少なくとも、オペレーティング・システムと、オペレーティング・システム上で動作するＷｅｂブラウザ（図示しない）が格納されており、システムの起動時に、オペレーティング・システムは、メインメモリ２０６にロードされる。さらに、好適には、ＡＰＩを呼び出すためのプログラムを作成するためのテキスト・エディタ、またはEclipse(Eclipse Foundationの商標）などの開発環境、オペレーティング・システムは、Windows XP（マイクロソフト・コーポレーションの商標）、Windows Vista（マイクロソフト・コーポレーションの商標）、Windows（マイクロソフト・コーポレーションの商標） ７、Linux（Linus Torvaldsの商標）などを使用することができる。また、Ｗｅｂブラウザは、マイクロソフト・コーポレーションのInternet Explorer、Mozilla FoundationのMizilla FireFoxなど、任意のものを使用することができる。

通信インターフェース２１８は、オペレーティング・システムが提供するＴＣＰ／ＩＰ通信機能を利用して、イーサネット（商標）・プロトコルなどにより、インターネット１０４と通信する。

ＡＰＩを使用したプログラムを作成する１つの方法は、これには限定されないが、開発環境のツールを用いて、例えば、作成するＷｅｂページに、JavaScript(R)のタグをつけ、その中で、プロバイダが提供した所定のＵＲＬをsrc=" "で指定し、ＡＰＩで定義された関数を所定の引数とともに呼び出すような書き方をすることである。

図３は、ハードウェア・リソース・プール１３０における個々のコンピュータ（計算ノード）１３２、１３４、・・・、１５２のハードウェア構成の概要ブロック図である。これらは各々、通信インターフェース３０２をもつ。通信インターフェース３０２はさらに、バス３０４に接続され、バス３０４には、ＣＰＵ３０６、主記憶（ＲＡＭ）３０８、及びハードディスク・ドライブ（ＨＤＤ）３１０が接続されている。コンピュータ（計算ノード）１３２、１３４、・・・、１５２は、好適には同じサイトに配置され、光ファイバなどの構内高速ネットワーク接続網により互いに接続されるが、あるいは、インターネット回線を介して接続され、遠隔地に配置されていてもよい。コンピュータ１３２、１３４、・・・、１５２としては、IBM(R) System X、IBM(R) Power System(R)などの、目的に応じた任意のコンピュータ・ハードウェア・システムを使用することができる。

スケジューラ１１２、予約スケジュール１１４、キュー１１６、リソース・アロケータ１１８、予約テーブル１２０及びユーザ・モニタ１２２を走らせるコンピュータ・システムは、コンピュータ１３２、１３４、・・・、１５２などと同一タイプのものでよい。

図１のハードウェア・リソース・プール１３０は、ディスク装置１５４、１５６、１５８などを統合するために、IBM(R) System Storage SANボリューム・コントローラのような、SAN管理ハードウェアを備えていてもよい。

図４は、システム１１０に導入されているハードウェア仮想化環境を示す図である。リソース・アロケータ１１８が導入されているコンピュータ・システムには、ハイパーバイザ４０２が導入され、セットアップされている。ここで使用可能なハイパーバイザ４０２は、これらには限定されないが、Xen、Microsoft社のHyper-V、VMware社のVMware(R)などが使用可能である。この実施例では、Xenを想定する。

ハイパーバイザ４０２は、ハードウェア・リソース・プール１３０にあるコンピュータ１３２、１３４・・・１５２及びディスク装置１５４、１５６等を仮想化する。

ハイパーバイザ４０２としてのXenの下では、ドメイン0とも呼ばれる特権的仮想マシン（ＶＭ）４０４が生成される。特権的仮想マシン４０４は、仮想マシン（ＶＭ）の作成、削除、ハードウェア・リソース・プール１３０へのアクセス、その他の機能を有する管理アプリケーション・プログラム（ＡＰＰ）４０４ａを含む。図１に示すスケジューラ１１２、リソース・アロケータ１１８、及びユーザ・モニタ１２２も、管理アプリケーション・プログラム４０４ａに含まれる。

管理アプリケーション・プログラム４０４ａは、クライアントからのリクエストに応じて適宜、ドメインUと呼ばれる仮想マシン（ＶＭ）４０６、４０８、・・・４１０を生成し、あるいは削除する。

図５は、管理アプリケーション・プログラム４０４ａにおける、本発明に関連する処理モジュールを示す図である。図示されているように、管理アプリケーション・プログラム４０４ａは、キュー処理モジュール５０２、Ｕｐイベント処理モジュール５０４、Ｄｏｗｎイベント処理モジュール５０６、リソース割当調整モジュール５０８、及びテーブル更新(UpdateTable)モジュール５１０を含む。

次に、図６のフローチャートを参照して、キュー処理モジュール５０２の処理について説明する。キュー処理モジュール５０２の基本的な動作は、システム停止まで、ステップ６０２からステップ６２６までのループを回り、キュー１１６内にあるリクエストを順次処理することである。

キュー処理モジュール５０２は、ステップ６０４で、キュー１１６が空かどうか判断し、空でないなら、ステップ６０６で、キューの先頭がＵｐ要求かどうか判断する。もしそうなら、キュー処理モジュール５０２は、ステップ６０８で、Ｕｐイベント処理モジュール５０４を呼び出す。Ｕｐイベント処理モジュール５０４の処理の詳細は、図７のフローチャートを参照して、後で説明する。

キューの先頭がＵｐ要求でないなら、キュー処理モジュール５０２は、ステップ６１０で、キューの先頭がＤｏｗｎ要求かどうか判断する。もしそうなら、キュー処理モジュール５０２は、ステップ６１２で、Ｄｏｗｎイベント処理モジュール５０６を呼び出す。Ｄｏｗｎイベント処理モジュール５０６の処理の詳細は、図８のフローチャートを参照して、後で説明する。

キューの先頭がＤｏｗｎ要求でないなら、キュー処理モジュール５０２は、ステップ６１４で、キューの先頭が、予約追加・削除かどうか判断する。もしそうなら、キュー処理モジュール５０２は、ステップ６１６で予約の追加・削除処理をする。予約には、要求する動的スケジューリング条件が含まれる。ここでの予約の追加・削除処理は、予約スケジュール１１４に反映される。

ステップ６１６の次に、キュー処理モジュール５０２は、ステップ６１８でリソース割当調整モジュール５０８を呼び出す。リソース割当調整モジュール５０８については、図９のフローチャートを参照して、後で説明する。

ステップ６１４で、キュー１１６の先頭が、予約追加・削除でないなら、ステップ６２０でその他の制御処理を行う。

ステップ６０８、６１２、６１８あるいは６２０の後、キュー処理モジュール５０２は、ステップ６２２でキューの先頭から要求を１つ取り除いて、ステップ６２６のループに戻る。

ステップ６０４に戻って、キュー処理モジュール５０２が、キュー１１６が空であると判断すると、ステップ６２４で一定時間待機して、ステップ６２６のループに戻る。

次に、図７のフローチャートを参照して、Ｕｐイベント処理モジュール５０４について説明する。ステップ７０２で、Ｕｐイベント処理モジュール５０４は、新規ＶＭ追加可能かどうか判断する。それを式で表すと、|{c∈CPUs|Reservation(c,r_k)=1}| > 0かどうかの判断となる。ここで、CPUsは、ハードウェア・リソース・プール１３０におけるＣＰＵのＩＤの集合であり、r_kは予約ＩＤであり、Reservation(c,r_k)=1は、予約ＩＤにCPUsの要素cが予約されていることを意味する。すなわち、ステップ７０２は、当該予約ＩＤに予約されたCPUsの要素が１つ以上あるかどうかの判断である。

そうでないなら、Ｕｐイベント処理モジュール５０４は、直ちに処理を終わる。一方、ステップ７０２で、当該予約ＩＤに予約されたCPUsの要素が１つ以上あると判断されると、Ｕｐイベント処理モジュール５０４は、ステップ７０４で、UpdateTable(テーブル更新）モジュール５１０を呼び出して予約テーブル１２０を更新する。テーブル更新モジュール５１０の処理は、図１０及び図１１のフローチャートを参照して後で説明する。

Ｕｐイベント処理モジュール５０４は、ステップ７０６で、該当ＶＭインスタンスを追加し、ステップ７０８で、利用するＣＰＵのＩＤを、ＣＰＵのＩＤの集合であるCPUsから削除する。

次に、Ｕｐイベント処理モジュール５０４は、ステップ７１０で、リソース割当調整モジュール５０８を呼び出す。リソース割当調整モジュール５０８については、図９のフローチャートを参照して、後で説明する。

次に、図８のフローチャートを参照して、Ｄｏｗｎイベント処理モジュール５０６について説明する。

Ｄｏｗｎイベント処理モジュール５０６は、ステップ８０２で、該当ＶＭインスタンスを削除し、ステップ８０４で、利用可能になったＣＰＵのＩＤを、ＣＰＵのＩＤの集合であるCPUsへ追加する。

次に、Ｄｏｗｎイベント処理モジュール５０６は、ステップ８０６で、リソース割当調整モジュール５０８を呼び出す。リソース割当調整モジュール５０８については、図９のフローチャートを参照して、後で説明する。

次に、図９を参照して、リソース割当調整モジュール５０８の処理について説明する。リソース割当調整モジュール５０８は、ステップ９０２で、変数kに1を格納する。次のステップ９０４で、リソース割当調整モジュール５０８は、k < Nかどうか判断する。ここでNは、クライアントによってなされた全体の予約の数である。そこでk < Nでない、すなわち、kがNに達したなら、リソース割当調整モジュール５０８は、処理を終了する。

一方、k < Nなら、リソース割当調整モジュール５０８は、下記の式で、確実性が満たされるかどうか判断する。
P_certainty(r_k) < P_requirement(r_k)

ここで、P_requirement(r_k)は、予約r_kの要求されている確実性であり、クラウドユーザが定義したものである。

一般的に、予約ridがn個のインスタンスを作れる確実性は、次の式で与えられる。

ここで、P_certainty(cid,rid)は下記の式で与えられる。

ここで、Reservationsは、予約の集合であり、P_scaleup(cid,rid)は、ＣＰＵのcidで、予約ridのインスタンスが１個作られる確率は、下記の式で与えられる：

但し、Reservation(cid,rid) ∈ {0,1}はＣＰＵのcidの予約をあわらし、

は、多重化数をあわらしている。また、P_scaleup(rid)は、予約ridのＵｐイベントの平均発生数であり、好適には、過去のＵｐイベントの履歴データがポアソン分布に従うと想定して、計算される。

以上のような計算の結果、P_certainty(r_k) < P_requirement(r_k)でないと判断されると、処理はステップ９１４に進み、kを1つインクリメントしてステップ９０４に戻る。

一方、P_certainty(r_k) < P_requirement(r_k)であると判断されると、ステップ９０８に進み、リソース割当調整モジュール５０８は、下記の式により、割当可能かどうか判断する。
|{c∈CPUs|Reservation(c,r_k)=1}| > 0
この式の意味は、ステップ７０２で説明したとおりである。

そして、リソース割当調整モジュール５０８は、もし割当可能であると判断すると、ステップ９１０で、CPUs ← CPUs ∪ {c}により、CPUsにハードウェア・リソースを追加する。

ステップ９１０の後、あるいはステップ９０８の判断が否定的である場合、リソース割当調整モジュール５０８は、ステップ９１２で、Reservation(c,r_k) ← 1により、r_kに新規割当の追加を行い、処理はステップ９１４に進み、kを1つインクリメントしてステップ９０４に戻る。

次に、図１０と図１１のフローチャートを参照して、テーブル更新(UpdateTable)モジュール５１０の処理を説明する。テーブル更新モジュール５１０が扱うのは、図１２に示すようなフォーマットをもつ予約テーブル１２０である。予約テーブル１２０において、RIDは拡張予約IDであり、拡張予約の１契約毎のIDである。STEPは、準備予約された仮想的なノードID（例えば30分で10台のうち5台目)で小さい方から段階的に準備完了していく段階である。GRADEは、準備状況の状態で、0が準備完了(running)状態、1がスワップアウト状態、2が要起動(need-to-launch)状態、3が要ブート(need-to-boot)状態、4が要導入／構成状態、5が要購入（ソフトウェア）状態、6が要購入（ハードウェア）状態である。CPUIDは、実際に割当てられた計算ノードのIDである。

図１０に示すように、テーブル更新モジュール５１０であるUpdateTableは、拡張予約IDである引数ridをとる。ステップ１００２で、テーブル更新モジュール５１０は、Promote(rid,1,1)を呼び出す。Promote関数の詳細は、図１１のフローチャートを参照して後で説明する。

ステップ１００４では、テーブル更新モジュール５１０は、ridをもつ、準備完了状態に昇格可能な予約テーブル１２０のレコードを１つ選択する。

ステップ１００６では、テーブル更新モジュール５１０は、当該レコードを準備完了状態にして戻る。

次に、図１１のフローチャートを参照して、UpdateTableで呼ばれるPromote関数の処理を説明する。Promote関数は、Promote(rid,step,grade)という引数で呼ばれる。

ステップ１１０２で、Promote関数は、step > MaxStep(rid) - count(select * where RID = rid and GRADE = 0)であるかどうか判断する。ここでMaxStep(rid)は、予約テーブル１２０において、予約ridが準備予約した総数を返す。また、count(select * where RID = rid and GRADE = 0)は、ridをもち現在準備完了であるレコードの数である。

もしstep > MaxStep(rid) - count(select * where RID = rid and GRADE = 0)であるなら、Promote関数は、何もしないで戻る。

step > MaxStep(rid) - count(select * where RID = rid and GRADE = 0)でないなら、Promote関数は、ステップ１１０４で、RID = rid、STEP = step、GRADE = gradeであるレコードがあるかどうか判断し、もしあれば、ステップ１１０６で、その見つかったレコードを１つ選択する。

Promote関数は、ステップ１１０８からステップ１１２０までのループで、ステップ１１０６でみつかったレコードの同じＣＰＵを共有している、予約テーブル１２０のレコードを順次検索する。

そこで、ステップ１１０４で見つかった目下のレコードを(rid',step',grade',cupid')とする。

ステップ１１１０で、Promote関数は、目下のレコードが、見つかったレコードそのものか判断し、もしそうなら、ステップ１１１２で、そのレコードのstepとgradeを１つずつデクリメントし、ステップ１１１４で、Promote(rid,step,grade)を再帰的に呼び出す。これは、STEP=stepのレコードが１個減った分のリソースを確保するために行う。

ステップ１１１０で、目下のレコードが、見つかったレコードそのものでないなら、Promote関数は、ステップ１１１６で、目下のレコードを削除し、ステップ１１１８で、Promote(rid',step',grade')により、削除したレコード分のリソースの確保を行う。

このような処理を予約テーブル１２０のすべてに亘って行うと、Promote関数は、ステップ１１２０を抜けて、戻る。

ステップ１１０４に戻って、RID = rid、STEP = step、GRADE = gradeであるレコードがないなら、Promote関数は、ステップ１１２２で、利用可能なcpuidを選択し、(rid,step,grade,cupid)のエントリをもつ新しいレコードを挿入して、戻る。

図１３は、図１０及び図１１のフローチャートの処理に従い、図１２の予約テーブル１２０を更新した結果を示す図である。

次に動的スケジューリングの品質QoDS(t_overall,λ_overall)について説明する。ここで、t_overallは、全体の準備完了までの時間、λ_overallは、全体のＶＭインスタンス数である。

すなわち、QoDS(t_overall,λ_overall)と、準備完了までの時間{t₁,t₂,...,t_n}のリスト（ここでt₁はほぼ0で、任意のiについてt_i < t_i+1)を与えたとき、最適なスタンバイ状態として、i番目のスタンバイ状態のＶＭインスタンス数λ_iは、次の式で得られる。ここで、N⁰は、0以上の整数の集合である。

すなわち、図１のシステムは、クライアントに対して、このようにして決定された(t_i,λ_i) i = 1,2,...,nでＶＭインスタンスを立ち上げる。

ここで、各t_iの値の標準偏差は、過去のデータに基づき予め推定される。特に、各t_iが正規分布に従うと仮定し、その標準偏差をσとすると、下記が成立する。

ここで、Pr()は、括弧の中の条件が成立する確率である。

下記に示すように、t_i = t_average + 3σのように、時間的に相対的に高い確実性(99.87%)を実現しようとすると、時間はかかるが、リソース割当は、相対的に楽観的(80.10%)でよい。なおここで、Pr(QoDS)は、動的スケーリング条件QoDSを満たす確率である。

一方、下記に示すように、t_i = t_average + 1σのように、時間的に相対的に低い確実性(84.14%)を実現しようとすると、時間は迅速になるが、リソース割当は、相対的に悲観的(95.08%)にする必要がある。

図１４は、準備状態、準備時間、確実性、上限、各リソース、及びコスト（値付け）の例を示す図である。示されているように、準備状態は、例として、準備完了、スワップアウト、要起動、要ブート、要導入／構成、要購入（ソフトウェア）、及び要購入（ハートウェア）を含む。

図１５は、このようにして用意された、異なる準備状態を組み合わせて、ＱｏＤＳに対応するＶＭインスタンスの立ち上げ時間を達成する状態を示す図である。異なる準備状態毎のインスタンス数は、数５のアルゴリズムに従い、管理ＡＰＰ４０４ａが決定する。ＶＭインスタンスの立ち上げは、例えば、管理ＡＰＰ４０４ａが、リソース割当調整処理を完了した直後、開始する。

図１６は、本発明の処理の効果を模式的に示す図である。すなわち、あるクライアントが、処理実行のために１００クライアントを要するとすると、コールドスタンバイ１６０２の場合は、起動時に、全く準備できておらずそこから立ち上げるので、コストは安いが、立ち上げ時間がかかる。

一方、ホットスタンバイ１６０４の場合は、最初からすべてのインスタンスが準備完了なので、立ち上げは迅速だが、コストは高い。

本発明の場合は、事前に一部のインスタンスがある程度まで準備状態が進んでいるので、それらの異なる準備状態にあるインスタンスを組みあわせて順次起動することによって、コストを妥当な範囲に抑えつつ、要求を満たす立ち上げ時間が達成される。

すなわち、従来技術では、１００インスタンスをある時間でユーザに提供するなら、１００インスタンスを常時走らせておかなくてはならず、それはクラウド・サーバ側でリソースが消耗されており、一方で、ユーザに対して相対的に高い課金となる。

それでは、従来技術で、１００インスタンスを非稼動状態にしておくと、ユーザに対して相対的に低い課金で済むが、ユーザの要求する立ち上げ時間を達成できない。

そこで、本発明によれば、実行中を１インスタンス、スワップアウトを２インスタンス、要起動を１２インスタンス、要ブートを２５インスタンス、要導入／構成を６０インスタンスというように用意しておくことで、活動リソースを最小限にしつつ、ユーザが要求する時間内にリソースを用意することが可能になる。このことにより、ユーザの課金と、サーバ側の可用リソースの両面で最適化が図られることになる。

以上、本発明の実施例を、特定のコンピュータ・プラットフォームに従い説明してきたが、このような特定のコンピュータ・プラットフォームに限定されず、複数の計算ノードと、それらの計算ノードを仮想化して複数の仮想マシンを生成できるサーバ環境であるなら、任意のサーバ環境で実施可能であることを、この分野の当業者であるなら理解するであろう。

１０２ａ、・・・、１０２ｚ クライアント・コンピュータ
１０４ インターネット
１１０ システム
１１２ スケジューラ
１１４ 予約スケジュール
１１６ キュー
１１８ リソース・アロケータ
１２０ 予約テーブル
１２２ ユーザ・モニタ
１３０ ハードウェア・リソース・プール
１３２、・・・１５２ コンピュータ（計算ノード）
１５４、１５６、１５８ ディスク装置
２０２ バス
２０４ ＣＰＵ
２０６ メインメモリ
２０６ 主記憶
２０８ コントローラ
２１０ ハードディスク・ドライブ
２１２ ドライブ
２１４ ディスプレイ・コントローラ
２１６ ディスプレイ装置
２１８ 通信インターフェース
２２２ オーディオ・インターフェース
２３０ キーボード
２３２ マウス
３０２ 通信インターフェース
３０４ バス
３０６ ＣＰＵ
４０２ ハイパーバイザ
４０４ 特権的仮想マシン
５０２ キュー処理モジュール
５０４ Ｕｐイベント処理モジュール
５０６ Ｄｏｗｎイベント処理モジュール
５０８ リソース割当調整モジュール
５１０ テーブル更新モジュール

Claims (18)

1. 複数の計算ノードを含むリソースを有するサーバ・システムにおいて、該サーバ・システムの処理により、クライアント・コンピュータからのリクエストに応じて、動的にリソースを割り当てる方法であって、
   異なる準備状態にある複数のインスタンスを用意するステップと、
   クライアント・コンピュータから、動的スケーリング条件のリクエストを受け取るステップと、
   前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動するステップを有する、
   動的にリソースを割り当てる方法。
2. 前記リクエストのＩＤと、前記計算ノードのＣＰＵのＩＤと、準備状態の段階のフィールドを含む予約テーブルを維持するステップと、
   前記クライアント・コンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てるステップをさらに有する、
   請求項１に記載の動的にリソースを割り当てる方法。
3. 前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てるステップが、前記確実度が満たされるかどうかを判断するステップを有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項２に記載の動的にリソースを割り当てる方法。
4. 前記確実度が満たされるかどうかを判断するステップが、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づき実行される、請求項３に記載の動的にリソースを割り当てる方法。
5. 前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項１に記載の動的にリソースを割り当てる方法。
6. 前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にするステップをさらに有する、請求項５に記載の動的にリソースを割り当てる方法。
7. 複数の計算ノードを含むリソースを有するサーバ・システムにおいて、該サーバ・システムの処理により、クライアント・コンピュータからのリクエストに応じて、動的にリソースを割り当てるプログラムであって、
   前記サーバ・システムに、
   異なる準備状態にある複数のインスタンスを用意するステップと、
   クライアント・コンピュータから、動的スケーリング条件のリクエストを受け取るステップと、
   前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動するステップを実行させる、
   動的にリソースを割り当てるプログラム。
8. 前記リクエストのＩＤと、前記計算ノードのＣＰＵのＩＤと、準備状態の段階のフィールドを含む予約テーブルを維持するステップと、
   前記クライアント・コンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てるステップをさらに有する、
   請求項７に記載の動的にリソースを割り当てるプログラム。
9. 前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てるステップが、前記確実度が満たされるかどうかを判断するステップを有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項８に記載の動的にリソースを割り当てるプログラム。
10. 前記確実度が満たされるかどうかを判断するステップが、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づき実行される、請求項９に記載の動的にリソースを割り当てるプログラム。
11. 前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項７に記載の動的にリソースを割り当てるプログラム。
12. 前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にするステップをさらに有する、請求項１１に記載の動的にリソースを割り当てるプログラム。
13. 複数の計算ノードを含むリソースを有するサーバ・システムにおいて、該サーバ・システムの処理により、クライアント・コンピュータからのリクエストに応じて、動的にリソースを割り当てるシステムであって、
    異なる準備状態にある複数のインスタンスを用意する手段と、
    クライアント・コンピュータから、動的スケーリング条件のリクエストを受け取る手段と、
    前記動的スケーリング条件を満たすように前記異なる準備状態にある複数のインスタンスを組み合わせて起動する手段を有する、
    動的にリソースを割り当てるシステム。
14. 前記サーバ・システムの記憶手段に記憶された、前記リクエストのＩＤと、前記計算ノードのＣＰＵのＩＤと、準備状態の段階のフィールドを含む予約テーブルと、
    前記クライアント・コンピュータからの、計算ノードの使用を要求するリクエストを受領することに応答して、前記予約テーブルに基づき、計算ノードを割当可能かどうか判断し、もしそうなら、その割当を反映するように前記予約テーブルを更新して、該計算ノードを前記リクエストに割当てる手段をさらに有する、
    請求項１３に記載の動的にリソースを割り当てるシステム。
15. 前記動的スケーリング条件のリクエストが、前記動的スケーリング条件が満たされるかどうかの確実度を含み、前記計算ノードを前記リクエストに割当てる手段が、前記確実度が満たされるかどうかを判断する手段を有し、前記確実度が満たされる場合にのみ前記計算ノードを前記リクエストに割当てる、請求項１４に記載の動的にリソースを割り当てるシステム。
16. 前記確実度が満たされるかどうかを判断する手段が、計算ノードの使用を要求するリクエストを受け取る頻度の統計値に基づく、請求項１５に記載の動的にリソースを割り当てるシステム。
17. 前記準備状態が、準備完了状態、スワップアウト状態、要起動状態、要ブート状態、及び要導入状態を含む、請求項１３に記載の動的にリソースを割り当てるシステム。
18. 前記計算ノードを前記リクエストに割当てることに応答して、前記予約テーブルの該当する準備状態の段階のフィールドを、準備完了状態にする、請求項１７に記載の動的にリソースを割り当てるシステム。

Images