JP2018532172A

JP2018532172A - リソーススケジューリングのための方法およびシステム

Info

Publication number: JP2018532172A
Application number: JP2018502137A
Authority: JP
Inventors: ヤン、リン; パン、レイ; マオ、リアンリアン
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2015-08-13
Filing date: 2016-08-11
Publication date: 2018-11-01
Anticipated expiration: 2036-08-11
Also published as: EP3335120B1; US10440136B2; CN106452818A; EP3335120A4; JP7020616B2; CN106452818B; US20170048163A1; EP3335120A1

Abstract

プロキシサーバを利用するアプリケーションシステムに対するリソーススケジューリングのためのスケジューリングシステムおよび方法であって、アプリケーションシステムは、１つまたは複数のホストを含み、１つまたは複数のアプリケーションを動作させ、それぞれの１つまたは複数のアプリケーションが１つまたは複数のインスタンスを有する。方法は、１つまたは複数のアプリケーションのに対してアプリケーションシステムによって処理されるプロキシサーバでのアプリケーションリクエストのリクエストキューをモニタリングする段階と、予め決められたスケジューリングルールおよびリクエストキューのステータスに従って１つまたは複数のアプリケーションのアプリケーションに対するアプリケーションシステムのコンピューティングリソースをスケジューリングする段階とを含む。

Description

［関連出願の相互参照］
本出願は、「リソース分配のための方法およびシステム」の名称で２０１５年８月１３日に出願された中国特許出願第２０１５１０４９４８５５.９号および「リソーススケジューリングのための方法およびシステム」の名称で２０１６年８月９日に出願された米国特許出願第１５/２３１，８１２号の優先権の利点を主張するものであり、参照によりそれらの全体が本明細書に両方組み込まれる。

本開示は、サーバのようなシステム上で動作するコンピュータアプリケーションの分野に関するものであり、特にリソーススケジューリングのための方法およびシステムに関する。

アプリケーションシステムのオペレーションにおける問題は、時折多数のヒットまたはリクエストを発生することである。アプリケーションシステムが通常に動作し得ることを確実とすべく、サーバは概して最も高い需要量に応じて構築される。しかしながら、この場合、結果は通常オペレーション条件下においてアイドルリソースが大多数となることとなる。ヒットの数のピークがシステム構築期間の間で低く見積もられた場合、アプリケーションシステムが遅くなることとなり、または多数の同時リクエストが生じた場合、アプリケーションシステムがクラッシュすることとなる。従って、フレキシブルなスケジューリング機構が、上記の問題を対処するよう提案されている。すなわち、多数のヒットがある場合、コンピューティングリソースは、システムの処理能力を拡張するよう自動的に形成されることとなる。また、少数のヒットおよびシステムがアイドルである場合、コンピューティングリソースは、コストを抑えるよう自動的に低減されることとなる。

従来のフレキシブルなスケジューリング機構は、主にシステムリソースの利用に基づいてアプリケーションの負荷を決定する。それは、例えば、ＣＰＵ、メモリ、ネットワークフロー、磁気ディスクＩＯ、およびそのようなものなどのようなリソースの利用に基づいている。アプリケーションによるＣＰＵまたはメモリの利用率が高い場合、そのアプリケーションに対して必要な拡張をすることが決定される。しかしながら、ある場合において、この手法では、真の利用状態を反映することに失敗することがある。例えば、いくつかのアプリケーションによって利用されるシステムリソースは、多くはないかもしれないが、そのようなアプリケーションの処理が、極めて遅いか、一時中断されることさえある。そのようなアプリケーションには、現在のフレキシブルなスケジューリング機構の使用は、拡張のための必須要件を満たすことができない。

いくつかの実施形態によれば、本開示は、スケジューリングの実際の必要性をより正確に決定して満たすリソーススケジューリングのための方法およびシステムを提供する。

いくつかの実施形態によれば、本開示は、予め決められたスケジューリングルールおよびアプリケーションリクエストのブロッキングステータスに従って、アプリケーションに対する、サーバおよびサーバのコンピューティングリソースのスケジューリングによって処理されるアプリケーションリクエストのブロッキングステータスのモニタリングする段階を含む、リソーススケジューリングのための方法を提供する。

本開示のいくつかの実施形態によれば、サーバによって処理されるアプリケーションリクエストのブロッキングステータスをモニタリングする段階は、サーバにおけるブロックリクエストのキュー内のリクエストの数を集計する段階と、サーバによって処理されるアプリケーションリクエストを含むブロックリクエストのキューと、アプリケーションリクエストのブロッキングステータスを取得する集計されたリクエストの数に対する解析および統計解析を実行する段階とを含む。

本開示のいくつかの実施形態によれば、アプリケーションリクエストのブロッキングステータスは、特定のアプリケーションに関するリクエストのブロッキングステータスと、特定のインスタンスに関するリクエストのブロッキングステータスと、特定のホストに関するリクエストのブロッキングステータスとの少なくとも１つを含む。

本開示のいくつかの実施形態によれば、サーバ内のブロックリクエストのキューにおけるリクエストの数を集計する段階は、プロキシサーバの公開されたＡＰＩからのサーバにおけるブロックリクエストのキュー内のリクエストの数を集計する段階を含む。

本開示のいくつかの実施形態によれば、方法は、プロキシサーバにおいてイベントモニタリングおよび統計モジュールを提供する段階をさらに含み、イベントモニタリングおよび統計モジュールは、提出したリクエストの数を取得すべくサーバへリクエストを提出するプロキシサーバのイベントに対しモニタリングし、処理したリクエストの数を取得すべくサーバがリクエストの処理を完了したことを確認するプロキシサーバがイベントに対しモニタリングし、ならびに提出したリクエストの数および処理したリクエストの数に従って、サーバにおけるブロックリクエストのキューにおいてリクエストの数を決定する。

本開示のいくつかの実施形態によれば、プロキシサーバの公開されたＡＰＩからのサーバにおけるブロックリクエストのキュー内のリクエストの数を集計する段階は、ＡＰＩによって提供されたＵＲＬにアクセスする段階と、ＵＲＬに対応するページデータからサーバにおけるブロックリクエストのキュー内のリクエストの数を取得する段階とを含む。

本開示のいくつかの実施形態によれば、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに従って、アプリケーションに対するサーバのコンピューティングリソースをスケジューリングする段階は、特定のアプリケーションに関するリクエストのブロッキングステータスが第１の拡張条件を満たす場合、特定のアプリケーションに対して新たなインスタンスを生成し、配置する段階と、特定のアプリケーションに関するリクエストのブロッキングステータスが第１の縮小条件を満たす場合、特定のアプリケーションに対してインスタンスを低減させる段階と、特定のインスタンスに関するリクエストのブロッキングステータスが第２の拡張条件を満たす場合、特定のインスタンスに対してシステムリソースを増加させる段階と、または特定のインスタンスの負荷を分担すべく他のインスタンスを使用する段階と、特定のインスタンスに関するリクエストのブロッキングステータスが第２の縮小条件を満たす場合、特定のインスタンスに対してシステムリソースを低減させる段階と、特定のホストに関するリクエストのブロッキングステータスが第３の拡張条件を満たす場合、特定のホストの負荷を分担すべく他のホストを使用する段階と、特定のホストに関するリクエストのブロッキングステータスが第３の縮小条件を満たす場合、特定のホスト上のインスタンスに優先的に配置する段階と、または他のホストの負荷を分担すべく特定のホストを優先的に使用する段階とのうち少なくとも１つを含む。

本開示のいくつかの実施形態によると、方法は、特定のアプリケーションにおける、インスタンスによるリソース利用をモニタリングする段階と、特定のアプリケーションにおいて、インスタンスによる平均リソースの利用が予め決められた第１の上限値より大きいまたは等しい場合、特定のアプリケーションに対してインスタンスを増加させる段階と、特定のアプリケーションにおいて、インスタンスによる平均リソースの利用が予め決められた第１の下限値より小さいまたは等しい場合、特定のアプリケーションに対してインスタンスを低減させる段階と、特定のアプリケーションにおいて、インスタンスによってリソース利用をモニタリングする段階と、インスタンスによるリソース利用が予め決められた第２の上限値より大きいまたは等しい場合、インスタンスによって利用されるシステムリソースを増加させる段階と、インスタンスによるリソース利用が予め決められた第２の下限値より小さいまたは等しい場合、インスタンスによって利用されるシステムリソースを低減させる段階と、ホストが利用不可能として検出された場合、ホスト上のインスタンスの移動を開始する段階と、処理が利用不可能として検出された場合、処理を再開し、不成功とした場合は、処理上のインスタンスの移動を開始する段階と、アプリケーションの例外が検出された場合、アプリケーションを再開する段階と、アプリケーションに対するインスタンスの移動を開始する段階と、またはアラートを生成する段階との少なくとも１つをさらに含む。

本開示は、またリソーススケジューリングのためのシステムを提供し、サーバによって処理されるアプリケーションリクエストのブロッキングステータスをモニタリングするためのブロックモニタリングユニットと、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに従ってアプリケーションに対するサーバのコンピューティングリソースをスケジューリングするためのスケジューリングユニットとを含む。

特に、本開示のいくつかの実施形態によれば、ブロックモニタリングユニットは、アプリケーションリクエストのブロッキングステータスを取得すべくモニタリングサブユニットによって集計されたリクエストの数に対する解析および統計解析を実行するために、サーバにおけるブロックリクエストのキュー内のリクエストの数を集計するためのモニタリングサブユニットと、ブロックリクエストのキューがサーバによって処理されるアプリケーションリクエストと、コンピューティングサブユニットとを含む。

本開示の好ましい実施形態によれば、モニタリングサブユニットは、プロキシサーバの公開されたＡＰＩからのサーバにおけるブロックリクエストのキュー内のリクエストの数を集計する。

本開示のいくつかの実施形態によれば、システムは、提出したリクエストの数を取得すべくサーバへのプロキシサーバ提出リクエストのイベントに対しモニタリングプロキシサーバ内に提供されるイベントモニタリングおよび統計モジュールをさらに含み、処理したリクエストの数を取得すべくサーバがリクエストの処理を完了したことをプロキシサーバが確認するイベントに対しモニタリングし、ならびに提出したリクエストの数および処理したリクエストの数に従って、サーバにおけるブロックリクエストのキューにおいてリクエストの数を決定するよう構成される。

特に、本開示のいくつかの実施形態によれば、モニタリングサブユニットは、ＡＰＩによって提供されたＵＲＬにアクセスすることと、ＵＲＬに対応するページデータからサーバにおけるブロックリクエストのキューにおいてのリクエストの数を取得することとのためのものである。

特に、本開示のいくつかの実施形態によれば、スケジューリングユニットは、特定のアプリケーションに関するリクエストのブロッキングステータスが第１の拡張条件を満たす場合、特定のアプリケーションに対して新たなインスタンスを生成し、配置することと、特定のアプリケーションに関するリクエストのブロッキングステータスが第１の縮小条件を満たす場合、特定のアプリケーションに対してインスタンスを低減させることと、特定のインスタンスに関するリクエストのブロッキングステータスが第２の拡張条件を満たす場合、特定のインスタンスに対してシステムリソースを増加させることと、または特定のインスタンスの負荷を分担すべく他のインスタンスを使用することと、特定のインスタンスに関するリクエストのブロッキングステータスが第２の縮小条件を満たす場合、特定のインスタンスに対してシステムリソースを低減させることと、特定のホストに関するリクエストのブロッキングステータスが第３の拡張条件を満たす場合、特定のホストの負荷を分担すべく他のホストを使用することと、特定のホストに関するリクエストのブロッキングステータスが第３の縮小条件を満たす場合、特定のホスト上のインスタンスに優先的に配置されることと、または他のホストの負荷を分担すべく特定のホストを優先的に使用することとの少なくとも１つのスケジューリングを実行する。

本開示のいくつかの実施形態によれば、ブロックモニタリングユニットは、特定のアプリケーションにおいて、インスタンスによるリソース利用のモニタリングのためにさらに使用され、スケジューリングユニットは、さらに、特定のアプリケーションにおいて、インスタンスによる平均リソースの利用が予め決められた第１の上限値より大きいまたは等しい場合、特定のアプリケーションに対してインスタンスを増加させることと、特定のアプリケーションにおいて、インスタンスによる平均リソースの利用が予め決められた第１の下限値より小さいまたは等しい場合、特定のアプリケーションに対してインスタンスを低減させることと、または、インスタンスによるリソース利用が予め決められた第２の上限値より大きいまたは等しい場合、インスタンスによって利用されるシステムリソースを増加させることと、インスタンスによるリソース利用が予め決められた第２の下限値より小さいまたは等しい場合、インスタンスによって利用されるシステムリソースを低減させることとを構成する。

本開示のいくつかの実施形態によれば、システムは、ホスト、処理またはアプリケーションの動作状態を検出するためのステータス検出ユニットをさらに含み、スケジューリングユニットは、さらに使用されるために、ホストがステータス検出ユニットによって利用不可能として検出された場合、ホスト上のインスタンスの移動を開始することと、処理がステータス検出ユニットによって利用不可能として検出された場合、処理を再開することと、不成功として検出された場合、処理上のインスタンスの移動を開始することと、アプリケーションの例外がステータス検出ユニットによって検出された場合、アプリケーションを再開することと、アプリケーションに対するインスタンスの移動を開始することと、またはアラートを生成することとを含む。

本開示のいくつかの実施形態によれば、スケジューリングユニットは、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに基づいたスケジューリング命令を生成し、管理サブユニットへスケジューリング命令を送信するためのスケジューリングサブユニットと、スケジューリング命令に従って、アプリケーションに対してサーバのコンピューティングリソースのスケジューリングを実行する管理サブユニットとを含む。

本明細書の説明および描写から明らかなように、本開示は、サーバによって集計され、処理される、アプリケーションリクエストのブロッキングステータスによる手法を採用し、この手法に基づいて、アプリケーションによるシステムリソースの利用に基づく代わりに、アプリケーションに対するサーバのコンピューティングリソースがスケジューリングされる。サーバによって処理されるアプリケーションリクエストのブロッキングステータスがアプリケーションの負荷をより正確に反映し得るため、本開示によるスケジューリングの方法がスケジューリングの実際の必要性をより正確に満たし得、コンピューティングリソースのオペレーションおよびプロセッサが一部であるシステム全体を改善し得る。

本明細書に描写された添付図面は、以下の詳細な説明を併せることで本開示のさらなる理解を提供するよう意図されている。本開示の実施形態のそれらの例示的な説明は、本開示のさらなる説明および明確化のために意図され、本開示の範囲は、任意の特定の実施形態の説明または添付図面によって定義されるものではなく、特許請求の範囲によって定義されるものである。本開示は、以下の添付図面を含む。

図１は、本開示のいくつかの実施形態によるアーキテクチャの非限定的なブロック図である。

図２は、本開示のいくつかの実施形態による方法の模式フロー図である。

図３は、本開示のいくつかの実施形態による方法の模式フロー図である。

図４は、本開示のいくつかの実施形態によるリソーススケジューリングのためのシステムのブロック図である。

本開示の目的、技術的解決および利点をより明確なものとすべく、本開示は、添付図面および特定の実施形態を参照して下記に詳細に説明される。

本開示の理解を促進するよう、まずアーキテクチャに基づく本開示が説明される。図１に示されるように、アーキテクチャにおいて、サーバ１０２は、アプリケーションリクエストを詳細処理するためのネットワークデバイスである。すなわち、アプリケーションリクエストのアクセス対象は、サーバ１０２であり、アプリケーションのサービスコンテンツを認識するよう各アプリケーションリクエストを処理することを担う。さらに、アプリケーションリクエストを処理するためのサーバ１０２は、単一のサーバであり得、または複数のマシンを含むサーバのクラスタであり得る。

サーバ１０２において、少なくとも１つのホストが存在し得、それぞれのホストがその上で動作する１つまたは複数のアプリケーションインスタンスを有している。すなわち、アプリケーションは、１つよりも多くのアプリケーションインスタンスで構成され得、それぞれのアプリケーションインスタンスがホスト上に配置される。アプリケーションインスタンスは、同じホスト上に配置され得、もしくは異なるホストに配置され得、またはサーバのクラスタの異なるサーバ上にさえも配置され得る。

図１に示されるアーキテクチャにおいて、プロキシサーバ１０４は、処理のためにユーザ側のデバイスからサーバへのアプリケーションリクエストの転送およびサーバからユーザ側のデバイスへの応答の転送を担う。

スケジューリングシステム１００は、本開示のコアであり、サーバ１０２によって処理されるアプリケーションリクエストのブロッキングステータスをモニタリングすることと、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに従って、アプリケーションに対するサーバのコンピューティングリソースのスケジューリングを実行することとを担う。より詳細には、サーバ１０２によって処理されるアプリケーションリクエストのブロッキングステータスをモニタリングする場合、スケジューリングシステムは、サーバから直接的にブロッキングステータスを取得しない。しかし、代わりにサーバ１０２によって処理されるプロキシサーバ１０４からデータを集計することで、アプリケーションリクエストのブロッキングステータスを間接的に取得し、ブロッキングステータスを解析する。処理ステップおよびスケジューリングシステムのコンポーネントは、下記において詳細に説明される。

いくつかの実施形態によれば、本開示は、リソーススケジューリングのための方法を提供する。ステップ２００は、１つまたは複数のアプリケーションに対してアプリケーションシステムによって処理されるプロキシサーバでのアプリケーションリクエストのリクエストキューをモニタリングする。ステップ２０３は、予め決められたスケジューリングルールおよびリクエストキューのステータスに従って１つまたは複数のアプリケーションのアプリケーションに対するアプリケーションシステムのコンピューティングリソースをスケジューリングする。

図３は、本開示のいくつかの実施形態による方法の模式フロー図であり、例えば、当該方法は、上記において説明されたスケジューリングシステムによって実行され得る。図３に示されるように、方法は、以下のステップを含む。

ステップ２０１は、プロキシサーバの公開されたＡＰＩ（アプリケーションプログラミングインターフェース）からのサーバにおけるブロックリクエストのキュー内のリクエストの数を集計する。

サーバがアプリケーションリクエストを処理した後、プロキシサーバがアプリケーションリクエストをサーバへ転送し、サーバから戻された応答を受信することを担うため、サーバによって処理されるサーバへ送信されたリクエストの数は、プロキシサーバによってサーバへ転送されたアプリケーションリクエストの数およびプロキシサーバによってサーバから受信される応答に対応するリクエストの数によって既知とされ得る。この処理に基づいて、サーバにおけるブロックリクエストのキュー内のリクエストの数の集計は、プロキシサーバを介して取得し得る。

より詳細には、プロキシサーバが非同期イベント処理機構に従うので、処理が実行された場合、対応するイベントが存在することとなる。従って、イベントモニタリングおよび統計モジュールは、イベントモニタリングおよび統計モジュールが予めプロキシサーバ内に提供され得、プロキシサーバがリクエストのイベントおよび統計をモニタリングすることを担う。すなわち、提出されたリクエストの数を取得すべくイベントモニタリングおよび統計モジュールは、サーバへのリクエストを表しているプロキシサーバのイベントをモニタリングする。本明細書において、グローバル変数は、提出されたそれぞれのリクエストに対して、グローバル変数に１の値が加えられ（例えば、変数はｕとして識別されると仮定する）提出されたリクエストの数を表すよう使用され得る。さらに、処理したリクエストの数を取得すべく、イベントモニタリングおよび統計モジュールは、サーバがリクエストの処理を完了したことをプロキシサーバが確認するイベントに対しモニタリングする（例えば、サーバがアプリケーションリクエストを処理した後、サーバから戻された応答を受信する）。処理されたリクエストを受信したそれぞれの応答に対して上記のグローバル変数ｕから１の値を引かれることとなる。グローバル変数の最終値は、サーバにおけるブロックリクエストのキューにおいてリクエストの数、すなわち、サーバによって処理されるサーバによって送信されたリクエストの数としてみなされ得る。

いくつかの実施形態において、イベントモニタリングおよび統計モジュールは、ネットワーク接続が確立したリクエストの数を取得すべく、プロキシサーバがネットワーク接続を確立するが、いまだサーバへ転送されていないイベントもモニタリングし得る。リクエストの数は、サーバが直面することとなる処理負荷を示し、コンピューティングリソースに続くスケジューリングにおいて、基準として使用し得るスケジューリングユニットのアシストファクタとして機能し得る。

上記のように取得されたリクエストの数は、プロキシサーバの公開されたＡＰＩを通してイベントモニタリングおよび統計モジュールによって出力され得、例えば、出力のためにＨＴＴＰプロトコルが採用され得る。例えば、ＡＰＩは、特定のＵＲＬを提供し得る。さらに、スケジューリングシステムがＵＲＬをアクセスした場合、ＡＰＩは、上記に記載のリクエストの数をフォーマット化されたデータの形態で提供し得るページを返すこととなり、すなわち、スケジューリングシステムがＵＲＬに対応するページデータからサーバにおけるブロックリクエストのキュー内のリクエストの数を取得する。

ステップ２０２は、アプリケーションリクエストのブロッキングステータスを取得すべく集計したリクエストの数に対する解析および統計解析を実行する。

このステップでは、集計されたリクエストの数に対する数値解析および統計解析は、それぞれの特定のアプリケーションに対応するブロックリクエストのキューにおけるリクエストの数と、それぞれの特定のインスタンスに対応するブロックリクエストのキューにおけるリクエストの数と、特定のホストに対応するブロックリクエストのキューにおけるリクエストの数とを決定するよう実行され得る。リクエストのために、それが対応する特定のアプリケーションは、それがアクセスするドメイン名に従って決定され得、それが対応する特定のホストは、それがアクセスするＩＰアドレスに従って決定され得、また、それが対応する特定のインスタンスは、それがアクセスするポートに従って決定され得る。

対応するコンピューティングリソースの処理能力と組み合わせてブロックリクエストのキューにおけるリクエストの数は、リクエストのブロッキングステータスを反映し得、これは、本明細書における下記の説明において明らかとなることとなる。

ステップ２０３は、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに従って、アプリケーションに対するサーバのコンピューティングリソースをスケジューリングする。

特定のアプリケーションのに対して、アプリケーションに関するリクエストのブロッキングステータスが第１の拡張条件を満たす場合、例えば、ブロックリクエストのキューにおけるリクエストの数が、アプリケーションによって利用されるコンピューティングリソースの処理能力の３倍を超え（本明細書では、「３倍」とは単に例示的なものであり、実際には、経験値または過去のデータから引き出された値が使用され得、下記に提供される例においても同じことが当てはまる）、それは、アプリケーションに関するリクエストのブロックがクリティカルであることと、アプリケーションに対して新たなインスタンスが生成されることが必要であることとが示され、配置される。新たなインスタンスの配置は、比較的より低い負荷を有するホスト上に優先的に配置される新たなインスタンス（例えば、比較的より小さいブロックリクエストのキューにおけるリクエストの数を有する）と負荷分散法に基づき得る。アプリケーションに関するリクエストのブロッキングステータスが第１の縮小条件を満たす場合、例えば、ブロックリクエストのキューにおけるリクエストの数がアプリケーションによって利用されるコンピューティングリソースの処理能力の０．５倍よりも小さい場合、それは、アプリケーションに関するリクエストの数が小さいことと、それが占有するコンピューティングリソースがアイドルであることとが示される。従って、アプリケーションに割り当てられるインスタンスは、低減され得る。特に、終了するインスタンスにはリクエストが割り当てられ得ず、タスクがない場合、インスタンスは、終了し得る。

特定のインスタンスに対して、インスタンスに関するリクエストのブロッキングステータスが第２の拡張条件を満たす場合、例えば、ブロックリクエストのキューにおけるインスタンスに関するリクエストの数がインスタンスによって利用されるコンピューティングリソースの処理能力の３倍を超え、それは、インスタンスに関するリクエストのブロックがクリティカルであることが示され、インスタンスに対してシステムリソースが増加され得る。本開示に関連するシステムリソースは、限定されないが、ＣＰＵ、メモリ、ＩＯリソース、ネットワークフロー、およびそのようなものを含み得る。いくつかの実施形態において、インスタンスの負荷を分担すべくインスタンスが加えられ得る。さらに、いくつかの実施形態において、インスタンスによるシステムリソースの利用に基づいて、どのタイプのシステムリソースが加えられるべきか決定され得る。

インスタンスに関するリクエストのブロッキングステータスが第２の縮小条件を満たす場合、例えば、ブロックリクエストのキューにおけるインスタンスに関するリクエストの数がわずかな量（ｆｒａｃｔｉｏｎａｌａｍｏｕｎｔ）よりも少なく、例えば、インスタンスによって利用されるコンピューティングリソースの処理能力の０．５０より小さいまたは等しく、それは、それを占有するコンピューティングリソースがアイドルであることを示し、従って、インスタンスに対するコンピューティングリソースが低減され得る。

特定のホストに対して、特定のホストに関するリクエストのブロッキングステータスが第３の拡張条件を満たす場合、例えば、ブロックリクエストのキューにおけるホストに関するリクエストの数がホストの処理能力の３倍を超え、ホストの負荷を分担すべく追加のホストが使用され得る。特定のホストに関するリクエストのブロッキングステータスが第３の縮小条件を満たす場合、例えば、ブロックリクエストのキューにおけるホストに関するリクエストの数がホストの処理能力の０．５倍よりも小さく、新たなインスタンスは、ホスト上に優先的に配置され得、または他のホストと分担すべくホストが優先的に使用され得る。

コンピューティングリソースの上記に記載のスケジューリングは、異なる段階におけるアプリケーションに対するフレキシブルなスケジューリングのための必要性を満たすよう定期的に実行され得る。

これに基づいて、現在使用されているフレキシブルなスケジューリング機構は、また組み込まれ得、例えば、限定されないが、以下を含み得る。

いくつかの実施形態において、特定のアプリケーションにおけるインスタンスによるリソース利用がモニタリングされ、インスタンスによるリソース利用は、ＣＰＵ、メモリ、またはＩＯリソースなどのようなシステムリソースを含む。すべてのインスタンスによる平均リソースの利用が予め決められた第１の上限値より大きいまたは等しい場合、例えば、理論上の平均値の８０％より大きいまたは等しく、特定のアプリケーションに対してインスタンスが増加され得る。すべてのインスタンスによる平均リソースの利用が予め決められた第１の下限値より小さいまたは等しい場合、例えば、理論上の平均値の２０％より小さいまたは等しく、特定のアプリケーションに対してインスタンスが低減され得る。本明細書において、第１の上限値は、第１の下限値よりも大きい。

いくつかの実施形態において、インスタンスによるリソース利用が予め決められた第２の上限値より大きいまたは等しい場合、例えば、ＣＰＵの占有が３０％よりも大きく、インスタンスによって利用される、ＣＰＵ、メモリのようなシステムリソース、またはＩＯリソースが増加され得る。インスタンスによるリソース利用が予め決められた第２の下限値より小さいまたは等しい場合、例えば、ＣＰＵの占有が１０％よりも少なく、インスタンスによって利用されるシステムリソースが低減され得る。本明細書において、第２の上限値は、第２の下限値よりも大きい。

ホストが利用不可能として検出される場合、例えば、ホスト上のすべてのインスタンスの別のホストへまたは複数の他のホストへの移動が開始し得る。別のホストまたは複数の他のホストへ移動した場合、インスタンスは、負荷分散法に従って、比較的より小さい負荷を有するホストへ移動し得る。

処理が利用不可能として検出された場合、処理の再開が実行され得る。再開が不成功であった場合、処理上のインスタンスの移動が開始し得る。インスタンスは、他の処理へ移動し得、特に、同じホスト上の他の処理へ移動し得るが、ほとんどの状況下でそれらは、他のホスト上の処理へ移動し得ることとなる。

アプリケーションがアプリケーションの障害またはアプリケーションに対する攻撃によって引き起こされ得て利用不可能として検出された場合、処理上のアプリケーションに在するインスタンスが再開し得、全アプリケーションのインスタンスが移動し得、またはアラートが生成され得る。

本実施形態の上記の記載において、アプリケーションのそれぞれのインスタンスによるリソース利用は、制限され得る。非限定的な方法の例として、メモリ利用の上限値は、それぞれのインスタンスによって４ＧＢに設定され得る。それぞれのアプリケーションによるリソース利用は、また制限され得る。例えば、アプリケーションのすべてのインスタンスによる全ＣＰＵ利用の上限値は、８０％に設定され得る。これを行う目的は、あるアプリケーションコードの例外によって引き起こされるシステムリソースの無制限な使用を防ぐことである。さらに、スケジューリングシステムは、インターフェースを提供し得、これは、ユーザによって使用され得る、上記に記載のスケジューリングルールならびにリソース利用の上限値を構成および調整され得る。

図４は、本開示のいくつかの実施形態によるリソーススケジューリングのためのシステムのブロック図である。図４に示されるように、システムは、ブロックモニタリングユニット００およびスケジューリングユニット１０を含み得、さらにプロキシサーバに提供されるイベントモニタリングおよび統計モジュール２０ならびにステータス検出ユニット３０を含み得る。本明細書において、ブロックモニタリングユニット００は、モニタリングサブユニット０１および計算サブユニット０２を含み得る。スケジューリングユニット１０は、スケジューリングサブユニット１１および管理サブユニット１２を含み得る。

ブロックモニタリングユニット００は、サーバによって処理されるアプリケーションリクエストのブロッキングステータスをモニタリングすることを担う。

特に、モニタリングサブユニット０１は、サーバにおけるブロックリクエストのキュー内のリクエストの数を集計することを担い、ブロックリクエストのキューは、サーバによって処理されるアプリケーションリクエストを含んでいる。モニタリングサブユニット０１は、プロキシサーバの公開されたＡＰＩからサーバにおけるブロックリクエストのキュー内のリクエストの数を集計し得る。

プロキシサーバが非同期イベント処理機構に従うため、処理が実行された場合、対応するイベントが存在されることとなる。従って、イベントモニタリングおよび統計モジュール２０は、プロキシサーバに提供され得、提出されたリクエストの数を取得すべくサーバへのプロキシサーバ提出リクエストのイベントをモニタリングすることと、処理したリクエストの数を取得すべくサーバがリクエストの処理を完了したことをプロキシサーバが確認するイベントに対しモニタリングすることと、提出したリクエストの数および処理したリクエストの数に基づいて、サーバにおけるブロックリクエストのキュー内のリクエストの数を決定することとを担う。

本明細書において、グローバル変数は、提出されたそれぞれのリクエストに対して、グローバル変数に１を加えられた値と、処理されたリクエストを受信したそれぞれの応答に対して上記のグローバル変数から１の値を引かれることを用いて提出されたリクエストの数の統計のために、グローバル変数が使用され得る。グローバル変数の最終値は、サーバにおけるブロックリクエストのキュー内のリクエストの数、すなわち、サーバによって処理されるサーバへ送信されたリクエストの数としてみなされ得る。

さらに、ネットワーク接続が確立したリクエストの数を取得すべく、イベントモニタリングおよび統計モジュール２０は、プロキシサーバがネットワーク接続を確立するが、いまだサーバへ転送されていないイベントもモニタリングし得る。このリクエストの数は、サーバが直面することとなる処理負荷を示し、コンピューティングリソースに続くスケジューリングにおいて、参照として使用し得るスケジューリングユニットのアシストファクタとして機能し得る。

上記のように取得されるリクエストの数は、プロキシサーバの公開されたＡＰＩを通してイベントモニタリングおよび統計モジュール２０によって出力され得、例えば、ＨＴＴＰプロトコルのようなコミュニケーションプロトコルが出力のために採用され得る。例えば、ＡＰＩは、特定のＵＲＬを提供し得、スケジューリングシステムがＵＲＬにアクセスした場合、ＡＰＩは、フォーマット化されたデータの形態において上記に記載のリクエストの数を提供し得るページを返すこととなる。すなわち、モニタリングサブユニット０１は、ＵＲＬに対応するページデータから、サーバにおけるブロックリクエストのキュー内のリクエストの数を取得すべくＡＰＩによって提供されるＵＲＬにアクセスする。

コンピューティングサブユニット０２は、アプリケーションリクエストのブロッキングステータスを取得すべくモニタリングサブユニット０１によって集計されたリクエストの数に対する解析および統計解析を実行することを担う。本明細書において、アプリケーションリクエストのブロッキングステータスは、特定のアプリケーションに関するリクエストのブロッキングステータスと、特定のインスタンスに関するリクエストのブロッキングステータスと、特定のホストに関するリクエストのブロッキングステータスとの少なくとも１つを含む。リクエストのために、それが対応する特定のアプリケーションは、それがアクセスするドメイン名に従って決定され得、それが対応する特定のホストは、それがアクセスするＩＰアドレスに従って決定され得、また、それが対応する特定のインスタンスは、それがアクセスするポートに従って決定され得る。

モニタリングサブユニット０１によるリクエストの数の集計が定期的に実行されるため、モニタリングサブユニット０１は、集計されたデータをモニタリングデータベースへ送信し得、コンピューティングサブユニット０２は、上記に記載のモニタリングデータベースにおけるデータに対する解析および統計解析を実行する。

スケジューリングユニット１０は、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに従って、アプリケーションに対するサーバのコンピューティングリソースをスケジューリングすることを担う。

特に、スケジューリングユニット１０は、以下のスケジューリングの少なくとも１つを実行し得る。

特定のアプリケーションに関するリクエストのブロッキングステータスが第１の拡張条件を満たす場合、特定のアプリケーションに対する新たなインスタンスは、生成され得て、配置され得る。新たなインスタンスの配置は、比較的より低い負荷を有するホスト上に優先的に配置される新たなインスタンス（例えば、比較的より小さいブロックリクエストのキューにおけるリクエストの数を有する）と負荷分散法に基づき得る。特定のアプリケーションに関するリクエストのブロッキングステータスが第１の縮小条件を満たす場合、特定のアプリケーションに対してインスタンスが低減され得、終了するインスタンスにはリクエストが割り当てられ得ず、タスクがない場合、インスタンスは、終了し得る。

特定のインスタンスに関するリクエストのブロッキングステータスが第２の拡張条件を満たす場合、特定のインスタンスに対してシステムリソースは増加され得、または他のインスタンスは、特定のインスタンスの負荷を分担すべく使用され得る。特定のインスタンスに関するリクエストのブロッキングステータスが第２の縮小条件を満たす場合、システムリソースは、特定のインスタンスに対して低減され得る。

特定のホストに関するリクエストのブロッキングステータスが第３の拡張条件を満たす場合、他のホストは、特定のホストの負荷を分担すべく使用され得る。特定のホストに関するリクエストのブロッキングステータスが第３の縮小条件を満たす場合、インスタンスは、特定のホスト上に優先的に配置され得、または特定のホストは、他のホストの負荷を分担すべく優先的に使用され得る。

これに基づき、現在使用されるフレキシブルなスケジューリング機構もシステムに組み込まれ得る。そのような場合、ブロックモニタリングユニット００は、また特定のアプリケーションに対するインスタンスによるリソース利用のモニタリングを担う。特定のアプリケーションに対するインスタンスによる平均リソースの利用が予め決められた第１の上限値より大きいまたは等しい場合、スケジューリングユニット１０は、特定のアプリケーションに対してインスタンスを増加させ得る。特定のアプリケーションに対するインスタンスによる平均リソースの利用が予め決められた第１の下限値より小さいまたは等しい場合、スケジューリングユニット１０は、特定のアプリケーションに対してインスタンスを低減させ得る。本明細書において、第１の上限値は、第１の下限値よりも大きい。

インスタンスによるリソース利用が予め決められた第２の上限値より大きいまたは等しい場合、スケジューリングユニット１０は、ＣＰＵ、メモリ、またはＩＯリソースなどのようなインスタンスによって利用されるシステムリソースを増加させ得る。インスタンスによるリソース利用が予め決められた第２の下限値より小さいまたは等しい場合、スケジューリングユニット１０は、インスタンスによって利用されるシステムリソースを低減させ得る。本明細書において、第２の上限値は、第２の下限値よりも大きい。

ステータス検出ユニット３０は、ホストの動作状態、処理またはアプリケーションの検出を担う。ホストがステータス検出ユニット３０によって利用不可能として検出された場合、例えば、ホスト上のインスタンスの別のホストへまたは複数の他のホストへの移動がスケジューリングユニット１０によって開始され得る。いくつかの実施形態において、別のホストまたは複数の他のホストへ移動した場合、インスタンスは、負荷分散法に従って、比較的より小さい負荷を有するホストへ優先的に移動し得る。

処理がステータス検出ユニット３０によって利用不可能として検出された場合、処理の再開がスケジューリングユニット１０によって実行され得る。再開が不成功であった場合、処理上のインスタンスの移動が開始し得る。インスタンスは、他の処理へ移動し得、特に、同じホスト上の他の処理へ移動し得るが、いくつかの実施形態においてそれらは、他のホスト上の処理へ移動することが好ましい。

ステータス検出ユニット３０がアプリケーションの例外を検出した場合、スケジューリングユニット１０は、アプリケーションを再開し得、またはアプリケーションに対するインスタンスの移動を開始し得、またはアラートを生成し得る。

スケジューリングユニット１０内に含まれるスケジューリングサブユニット１１は、アプリケーションリクエストの予め決められたスケジューリングルールおよびブロッキングステータスに基づいたスケジューリング命令を生成し、管理サブユニット１２へスケジューリング命令を送信することを担う。いくつかの実施形態において、スケジューリングサブユニット１１は、ルールデータベースからスケジューリングルールを負荷し得る。データベースは、ユーザがスケジューリングルールを構成または変更し得るインターフェースを備え得る。

管理サブユニット１２は、具体的に、スケジューリングオペレーションを実行するためのユニットである。管理サブユニット１２は、通常リソースの管理を担い、本開示の実施形態において、スケジューリング命令に従ってアプリケーションに対してサーバにおいてコンピューティングリソースをスケジューリングすることを担う。さらに、スケジューリングの結果は、スケジューリングサブユニット１１に戻され得る。

本開示の目的において、モジュールおよびユニットは、本明細書で記載される処理、特徴および／または機能を（ヒューマンインタラクションまたはヒューマンオーグメンテーションの有無にかかわらず）実行または促進する、ソフトウェア、ハードウェアもしくはファームウェア（またはそれらの組み合わせ）のシステム、処理または機能性、またはそれらのコンポーネントである。モジュールは、サブモジュールを含み得、ユニットは、サブユニットを含み得る。モジュール/ユニットのソフトウェアコンポーネントは、プロセッサによって実行されるコンピュータ可読媒体に格納され得る。モジュール/ユニットは、１つもしくは複数のサーバまたはデバイスと一体型であり得、または１つまたは複数のサーバ/デバイスによって負荷および実行され得る。１つまたは複数のモジュールは、エンジンまたはアプリケーションにグループ化され得る。

本開示によって提供される実施形態における開示されたシステムおよび方法は、他の方法で実施され得ることを理解されたい。このような上記の実施形態は、単に例示的な記載に過ぎない。例えば、ユニットのパーティショニングは、単にロジカルで且つ機能的意味に過ぎなく、パーティショニングの他の方法は、実際に実施され得る。

個々のコンポーネントとして記載されるユニットは、物理的に離れ得もしくは離れ得ず、ユニットとして示されるコンポーネントは、物理的なユニットであり得もしくはあり得ず、すなわち、それらは、１つの場所に位置され得、または複数のネットワークユニットに分配され得る。実際の必要性によって、ユニットの一部またはすべてが実施形態の目的を実現するために選択され得る。

さらに、本開示のそれぞれの実施形態において、個々の機能ユニットは、１つの処理ユニットへ統合され得、または物理的に離れた方法で存在し得、または２つまたはそれより大きいまたは等しいユニットは、１つのユニットへ統合され得る。上記に記載の統合ユニットは、ハードウェアの形態で実施され得、またはソフトウェア機能ユニットと組み合わせたハードウェアの形態で実施され得る。

ソフトウェア機能ユニットの形態で実施される統合ユニットは、コンピュータ可読記憶媒体に格納され得る。ソフトウェア機能ユニットは、記憶媒体内に格納され、コンピューティングデバイス（パーソナルコンピュータ、サーバであり得、またはネットワークデバイスもしくはそのようなものであり得る）を可能にする命令の数、または本開示のそれぞれの実施形態に記載の方法のステップの一部を実行するプロセッサを含む。上記の記憶媒体は、例えば、ＵＳＢフラッシュディスク、モバイルハードディスク、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク、またはコンパクトディスク、またはピュア信号に対する有形の形態でプログラムコードに格納し得るさまざまな他の媒体などのような有形媒体を含む。

上記に記載された実施形態は、単に本開示の好ましい実施形態に過ぎなく、これを限定する意図はない。これらの実施形態へのいかなる修正、等価的置き換え、および改良は、本開示の趣旨および原理から逸脱することなく、本開示の範囲内に包含されるものとみなされる。

Claims

リソーススケジューリングのための方法であって、
プロキシサーバにて、スケジューリングシステムによって、前記プロキシサーバを利用するアプリケーションシステム上のアプリケーションリクエストのリクエストキューをモニタリングする段階であって、前記アプリケーションシステムは、１つまたは複数のホストを含み、前記アプリケーションシステムによって処理される１つまたは複数のアプリケーションを動作させ、前記１つまたは複数のアプリケーションのそれぞれは、１つまたは複数のインスタンスを有している、段階と、
スケジューリングシステムによりスケジューリングされ、予め決められたスケジューリングルールおよび前記リクエストキューのステータスに従って前記１つまたは複数のアプリケーションのアプリケーションに対する前記アプリケーションシステムのコンピューティングリソースをスケジューリングする段階と
を備える方法。
前記リクエストキューを前記モニタリングする段階が、
前記リクエストキューからアプリケーションリクエストの数を決定する段階と、
前記リクエストキューの前記ステータスを取得すべく前記アプリケーションリクエストの数に基づいて統計解析を実行する段階と
を含む、請求項１に記載の方法。
前記アプリケーションリクエストの前記数が、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホスト上で動作している前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホストのそれぞれのホストに対応する前記アプリケーションリクエストの数と
から選ばれた少なくとも１つのリクエストからなるリクエストのグループを含む、請求項２に記載の方法。
前記アプリケーションリクエストの前記数を前記決定する段階は、
前記プロキシサーバの公開されたアプリケーションプログラミングインターフェース（ＡＰＩ）を介して前記リクエストキューにおける前記アプリケーションリクエストの前記数を決定する段階を含む、請求項２または３に記載の方法。
提出したリクエストの数および処理したリクエストの数は、前記ＡＰＩを介して前記プロキシサーバから受信され、
前記リクエストキューにおける前記アプリケーションリクエストの前記数を前記決定する段階は、前記提出したリクエストの前記数および前記処理したリクエストの前記数の間の差を決定する段階である、請求項４に記載の方法。
前記アプリケーションリクエストの前記数を前記決定する段階は、
前記ＡＰＩによって提供されたユニフォームリソースロケータ（ＵＲＬ）にアクセスする段階と、
前記ＵＲＬに対応するページデータから前記リクエストキューにおける前記アプリケーションリクエストの前記数を取得する段階と
を含む、請求項４または５に記載の方法。
前記アプリケーションに対する前記アプリケーションシステムの前記コンピューティングリソースを前記スケジューリングする段階が、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューのステータスが第１の拡張条件を満たす場合、新たなインスタンスを生成し、前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューの前記ステータスが第１の縮小条件を満たす場合、インスタンスを低減させる段階と、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスに対応する前記リクエストキューのステータスが第２の拡張条件を満たす場合、前記コンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、それぞれの前記インスタンスに対応する前記リクエストキューの前記ステータスが第２の縮小条件を満たす場合、前記コンピューティングリソースを低減させる段階と、
前記１つまたは複数のホストのそれぞれのホストに対して、前記ホストに対応する前記リクエストキューのステータスが第３の拡張条件を満たす場合、前記ホストの負荷を分担すべく前記１つまたは複数のホストの他のホストを使用し、前記１つまたは複数のホストのそれぞれホストに対して、前記ホストに対応する前記リクエストキューの前記ステータスが第３の縮小条件を満たす場合、前記１つまたは複数のホストの他のホストの負荷を分担すべく前記ホストを使用する段階と
のうち少なくとも１つ含み、
拡張条件が前記アプリケーションシステムの前記コンピューティングリソースの高い利用を示している予め決められた条件であり、
縮小条件が前記アプリケーションシステムの前記コンピューティングリソースの低い利用を示している予め決められた条件である、請求項３から６のいずれか一項に記載の方法。
前記アプリケーションに対する前記アプリケーションシステムの前記コンピューティングリソースを前記スケジューリングする段階は、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションの前記１つまたは複数のインスタンスのすべてのインスタンスの平均リソース利用が予め決められた第１の上限より大きいまたは等しい場合、前記アプリケーションのインスタンスの数を増加させ、前記平均リソース利用が予め決められた第１の下限より小さいまたは等しい場合、前記アプリケーションのインスタンスの前記数を低減させる段階と、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの最大リソース利用が予め決められた第２の上限より大きいまたは等しい場合、前記インスタンスのコンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの前記最大リソース利用が予め決められた第２の下限より小さいまたは等しい場合、前記インスタンスの前記コンピューティングリソースを低減させる段階と
のうち少なくとも１つ含む、請求項２から７のいずれか一項に記載の方法。
リソーススケジューリングのためのスケジューリングシステムであって、
１つまたは複数のプロセッサと、
前記１つまたは複数のプロセッサによって実行可能な命令を格納する非一時的コンピュータ可読メモリと
を備え、前記命令が前記スケジューリングシステムに、
プロキシサーバを利用しているアプリケーションシステム上のアプリケーションリクエストのリクエストキューを前記プロキシサーバでモニタリングさせ、前記アプリケーションシステムは、１つまたは複数のホストを含み、前記アプリケーションシステムによって処理される１つまたは複数のアプリケーションを動作させ、前記１つまたは複数のアプリケーションのそれぞれが、１つまたは複数のインスタンスを有し、
前記命令が予め決められたスケジューリングルールおよび前記リクエストキューのステータスに従って前記１つまたは複数のアプリケーションのアプリケーションに対する前記アプリケーションシステムのコンピューティングリソースをスケジューリングさせる、スケジューリングシステム。
モニタリングさせる前記命令が前記スケジューリングシステムにさらに、
前記リクエストキューからアプリケーションリクエストの数を決定させ、
前記リクエストキューの前記ステータスを取得すべくアプリケーションリクエストの前記数に基づいて統計解析を実行させる、請求項９に記載のスケジューリングシステム。
前記アプリケーションリクエストの前記数が前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホスト上で動作している前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホストのそれぞれのホストに対応する前記アプリケーションリクエストの数とのうち少なくとも１つを含む、請求項１０に記載のスケジューリングシステム。
モニタリングする前記命令が前記スケジューリングシステムにさらに、前記プロキシサーバの公開されたアプリケーションプログラミングインターフェース（ＡＰＩ）を介した前記リクエストキューにおける前記アプリケーションリクエストの前記数を決定させる、
請求項１０または１１に記載のスケジューリングシステム。
提出したリクエストの数および処理したリクエストの数は、前記ＡＰＩを介して前記プロキシサーバから受信され、前記リクエストキューにおける前記アプリケーションリクエストの前記数が前記提出したリクエストの前記数および前記処理したリクエストの前記数の間の差として決定される、請求項１２に記載のスケジューリングシステム。
モニタリングする前記命令が前記スケジューリングシステムにさらに、
前記ＡＰＩによって提供されたユニフォームリソースロケータ（ＵＲＬ）にアクセスさせ、
前記ＵＲＬに対応するページデータから前記リクエストキューにおける前記アプリケーションリクエストの前記数を取得させる、請求項１２または１３に記載のスケジューリングシステム。
スケジューリング回路が、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューのステータスが第１の拡張条件を満たす場合、新たなインスタンスを生成し、前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューの前記ステータスが第１の縮小条件を満たす場合、インスタンスを低減させることと、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスに対応する前記リクエストキューのステータスが第２の拡張条件を満たす場合、前記コンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、それぞれの前記インスタンスに対応する前記リクエストキューの前記ステータスが第２の縮小条件を満たす場合、前記コンピューティングリソースを低減させることと、
前記１つまたは複数のホストのそれぞれのホストに対して、前記ホストに対応する前記リクエストキューのステータスが第３の拡張条件を満たす場合、前記ホストの負荷を分担するべく前記１つまたは複数のホストの他のホストを使用し、前記１つまたは複数のホストのそれぞれのホストに対して、前記ホストに対応する前記リクエストキューの前記ステータスが第３の縮小条件を満たす場合、前記１つまたは複数のホストの他のホストの負荷を分担するべく前記ホストを使用することとのうち少なくとも１つを実行し、
拡張条件が前記アプリケーションシステムの前記コンピューティングリソースの高い利用を示している予め決められた条件であり、
縮小条件が前記アプリケーションシステムの前記コンピューティングリソースの低い利用を示している予め決められた条件である、請求項１１から１４のいずれか一項に記載のスケジューリングシステム。
スケジューリング回路が前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションの前記１つまたは複数のインスタンスのすべてのインスタンスの平均リソース利用が予め決められた第１の上限より大きいまたは等しい場合、前記アプリケーションのインスタンスの数を増加させ、前記平均リソース利用が予め決められた第１の下限より小さいまたは等しい場合、前記アプリケーションのインスタンスの前記数を低減させることと、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの最大リソース利用が予め決められた第２の上限より大きいまたは等しい場合、前記インスタンスのコンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの前記最大リソース利用が予め決められた第２の下限より小さいまたは等しい場合、前記インスタンスの前記コンピューティングリソースを低減させることと
のうち少なくとも１つを実行する、請求項１１から１５のいずれか一項に記載のスケジューリングシステム。
プロセッサによって実行された場合、前記プロセッサにリソーススケジューリングのための手順を実行させるコンピュータプログラムであって、前記手順は、
１つまたは複数のアプリケーションに対するアプリケーションシステムによって処理されるプロキシサーバでのアプリケーションリクエストのリクエストキューからアプリケーションリクエストの数を決定する手順と、
前記リクエストキューのステータスを取得すべくアプリケーションリクエストの数に基づいて、統計解析を実行する手順と、
予め決められたスケジューリングルールおよび前記リクエストキューのステータスに従って前記１つまたは複数のアプリケーションのアプリケーションに対する前記アプリケーションシステムのコンピューティングリソースをスケジューリングする手順と
を含む、コンピュータプログラム。
前記アプリケーションリクエストの数は、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホスト上で動作している前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対応する前記アプリケーションリクエストの数と、
前記１つまたは複数のホストのそれぞれのホストに対応する前記アプリケーションリクエストの数と
のうち少なくとも１つを含む、請求項１７に記載のコンピュータプログラム。
前記アプリケーションに対する前記アプリケーションシステムの前記コンピューティングリソースを前記スケジューリングする手順は、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューのステータスが第１の拡張条件を満たす場合、新たなインスタンスを生成し、前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションに対応する前記リクエストキューの前記ステータスが第１の縮小条件を満たす場合、インスタンスを低減させる手順と、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスに対応する前記リクエストキューのステータスが第２の拡張条件を満たす場合、前記コンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、それぞれの前記インスタンスに対応する前記リクエストキューの前記ステータスが第２の縮小条件を満たす場合、前記コンピューティングリソースを低減させる手順と、
前記１つまたは複数のホストのそれぞれのホストに対して、前記ホストに対応する前記リクエストキューのステータスが第３の拡張条件を満たす場合、前記ホストの負荷を分担すべく前記１つまたは複数のホストの他のホストを使用し、前記１つまたは複数のホストのそれぞれのホストに対して、前記ホストに対応する前記リクエストキューの前記ステータスが第３の縮小条件を満たす場合、前記１つまたは複数のホストの他のホストの負荷を分担すべく前記ホストを使用する手順と
のうち少なくとも１つを含み、
拡張条件が前記アプリケーションシステムの前記コンピューティングリソースの高い利用を示している予め決められた条件であり、
縮小条件が前記アプリケーションシステムの前記コンピューティングリソースの低い利用を示している予め決められた条件である、
請求項１８に記載のコンピュータプログラム。
前記アプリケーションに対する前記アプリケーションシステムの前記コンピューティングリソースを前記スケジューリングする手順は、
前記１つまたは複数のアプリケーションのそれぞれのアプリケーションに対して、前記アプリケーションの前記１つまたは複数のインスタンスのすべてのインスタンスの平均リソース利用が予め決められた第１の上限より大きいまたは等しい場合、前記アプリケーションのインスタンスの数を増加させ、前記平均リソース利用が予め決められた第１の下限より小さいまたは等しい場合、前記アプリケーションのインスタンスの前記数を低減させる手順と、
前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの最大リソース利用が予め決められた第２の上限より大きいまたは等しい場合、前記インスタンスのコンピューティングリソースを増加させ、前記１つまたは複数のアプリケーションのそれぞれの前記１つまたは複数のインスタンスのそれぞれのインスタンスに対して、前記インスタンスの前記最大リソース利用が予め決められた第２の下限より小さいまたは等しい場合、前記インスタンスの前記コンピューティングリソースを低減させる手順と
のうち少なくとも１つを含む、請求項１８または１９に記載のコンピュータプログラム。