JP2012064070A - クラウドコンピューティングシステム、クラウドコンピューティングシステムの制御方法、および管理アプリケーション - Google Patents

Abstract

【課題】処理を実行しているＶＭを含むアプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含むＶＭを削除するクラウドコンピューティングシステムを提供する。
【解決手段】管理アプリケーション５０７が、アプリケーション管理テーブル５０８を参照して、画像形成装置４から依頼されたジョブの実行に関する優先度が最も低い追加アプリケーションが含む全てのＶＭの動作状況を取得する。管理アプリケーション５０７が、取得したＶＭの動作状況に基づいて、処理を実行していないＶＭのみを含む追加アプリケーション５０４を検出し、検出された追加アプリケーション５０４が含むＶＭを削除する。
【選択図】図５

Description

本発明は、クラウドコンピューティングシステム、クラウドコンピューティングシステムの制御方法、および管理アプリケーションに関する。

近年、インターネット上のサーバにて動作する各種アプリケーションを利用可能な、クラウドコンピューティングシステムと呼ばれる技術が提案されている。クラウドコンピューティングシステムにおいて、クラウドサービスベンダーは、インターネット上に、仮想的なコンピュータ（Virtual Machine ：ＶＭ）、ストレージを提供し、これらを用いた種々のサービスを提供することができる。アプリケーション開発者は、クラウドサービスベンダーに利用料を支払い、クラウドコンピューティングシステムが提供するサービスを使用することで、クラウドアプリケーションの開発が可能となる。

クラウドコンピューティングシステムを利用したアプリケーションでは、使用するＶＭの数を増やすことで、アプリケーションの性能の向上が可能となる。しかし、一般的に、クラウドサービスの利用料はＶＭの数によって大きく異なる。従って、アプリケーションへの負荷やトランザクションの多寡に応じて、ＶＭの数を動的に増減させ、適切な数のＶＭを用いてサービスを提供することが、パフォーマンスとコストの両面において非常に重要である。

特許文献１は、縮退可能サーバを検出するシステムを提案している。このシステムは、複数のサーバが並列的に処理を行っている状況で、各サーバの処理の負荷を計測する。システムは、計測の結果、負荷が低い場合、各サーバの処理の依存関係から、処理を停止することが可能なサーバを検出し、停止可能ならば停止する。

特開２００８−２３４３５６号公報

ここで、システム上で動作するアプリケーションが含むＶＭを削除する場合に、アプリケーションに対して、削除するＶＭの個数は指定できるが、削除対象のＶＭを個別に指定することができないクラウドコンピューティングシステムを想定する。このようなクラウドコンピューティングシステムでは、例えば処理を行っていないＶＭを削除対象として削除しようとしても、アプリケーションに対して、ＶＭの個数を指定した削除命令しか発行できないので、削除対象のＶＭ以外のＶＭが削除される可能性がある。例えば、削除されるアプリケーションに、何らかの処理を実行中のＶＭが含まれている場合には、この処理を実行中のＶＭが処理途中で削除されてしまう。このような場合には、再処理が必要となるため、システム全体のパフォーマンスが大幅に低下するといった問題がある。

本発明は、処理を実行しているＶＭを含むアプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含むＶＭを削除するクラウドコンピューティングシステムの提供を目的とする。

本発明の一実施形態のクラウドコンピューティングシステムは、情報処理装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムであって、各々が少なくとも前記バックエンド処理部を備える処理実行部を含み、該処理実行部を用いて、前記記憶手段から取得されたメッセージに基づく処理を実行するアプリケーションと、前記メッセージに基づく処理を実行している前記処理実行部を含む前記アプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含む前記処理実行部を削除する削除部とを備える。

本発明のクラウドコンピューティングシステムによれば、ＶＭのスケールイン（削除）を行う際に、処理を実行しているＶＭを含むアプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含むＶＭを削除することができる。具体的には、処理を実行していないＶＭのみを含むアプリケーションを容易に検出し、該アプリケーションが含むＶＭを削除することができる。従って、処理を実行中のＶＭが削除されないので、再処理の発生を防止できる。その結果、システム全体としてのパフォーマンスが向上する。

本実施形態のシステムの全体構成を示す図である。 アプリケーションサーバと画像形成装置のハードウェア構成例である。 本実施形態のシステムの機能ブロック図の例である。 アプリケーションサーバのプラットフォームシステムの例である。 クラウドコンピューティングシステムの構築例を示す図である。 ジョブキュー、メッセージキューに格納されるメッセージの例と、アプリケーション管理テーブルの例を示す図である。 必須アプリケーションの処理の例を説明するフローチャートである。 追加アプリケーションの処理を説明するフローチャートである。 管理アプリケーションの処理を説明するフローチャートである。

以下に、本実施形態を添付の図面に基づいて説明する。まず、本実施形態で使用される用語の一般的な定義について説明する。ポーリングとは、クライアントがホストに要求をした処理の経過や完了を確認するために、クライアントが一定間隔でホストに処理の経過状況を問い合わせる処理である。スケールインとは、クラウドコンピューティングシステム上で動作するアプリケーション（クラウドアプリケーション）に含まれるＶＭ（Virtual Machine ）を削減することを意味する。ＶＭは、仮想化技術によって物理的なサーバを論理的なコンピュータに分割し、分割された中で独立したオペレーティングシステムをもって動作する論理的なコンピュータである。この論理的なコンピュータの単位をインスタンスという。

クラウドコンピューティングシステムにおいては、ＶＭ数に応じてコストが発生するため、処理量が少ない場合には、スケールインを行うことで、コストを抑えることが重要となる。また、スケールアウトとは、クラウドアプリケーションに含まれるＶＭの数を増加させることを意味する。一般にクラウドコンピューティングシステムにおいては、ＶＭ数を増やすことで、容易にパフォーマンスの向上を図ることができる。

図１は、本実施形態のシステムの全体構成を示す図である。図１に示すシステムは、アプリケーションサーバ群１、ストレージサーバ２、ＰＣ（Personal Computer ）３、画像形成装置４を備える。アプリケーションサーバ群１乃至画像形成装置４は、互いにネットワーク５を介して接続されている。ネットワーク５の回線は、有線、無線を問わない。

ＰＣ３、画像形成装置４は、アプリケーションサーバ群１に対してジョブの実行依頼を行い、アプリケーションサーバ群１によるジョブの実行結果を受け取り、受け取ったジョブの実行結果に対して各種処理を実行する情報処理装置である。例えば、ＰＣ３は、アプリケーションサーバ群１に対して、アプリケーションサーバ群１が保持している情報の取得要求を行い、この取得要求に応答したアプリケーションサーバ群１から情報を受信し、受信した情報を画面表示する。また、例えば、画像形成装置４は、アプリケーションサーバ群１に対して印刷要求を行い、この印刷要求に応答したアプリケーションサーバ群１から印刷データを受信し、受信した印刷データを印刷処理する。ＰＣ３と画像形成装置４とは、外部からのアクセスが制限されたローカルエリアに配置されており、ネットワーク５からファイアウォールで遮断されている。

アプリケーションサーバ群１は、複数のアプリケーションサーバ１０を備える。アプリケーションサーバ群１は、ＰＣ３または画像形成装置４からジョブの処理依頼を受け取り、このジョブの処理を実行して実行結果を依頼元に返す。例えば、アプリケーションサーバ群１は、画像形成装置４から印刷要求を受け取り、所定の記憶部に保存されているコンテンツに対して印刷要求に応じた処理を実行して印刷データを生成し、生成した印刷データを画像形成装置４に送信する。

アプリケーションサーバ群１は、クラウドに設けられているクラウドコンピューティングシステムである。クラウドとは、クラウドコンピューティング環境におけるサーバ群が配置される領域のことである。クラウドコンピューティング環境においては、ユーザはコンピュータ処理をネットワーク経由でサービスとして利用する。クラウドに設けられたアプリケーションサーバ群１から発する要求によりファイアウォール内部にアクセスすることはできない。従って、アプリケーションサーバ群１は、画像形成装置４からの要求の応答を返すことによって、画像形成装置４に対して通信を行う。本実施形態のクラウドコンピューティングシステムの制御方法は、図１に示すアプリケーションサーバ群１によって実現される。また、本実施形態のコンピュータプログラムは、このクラウドコンピューティングシステムの制御方法をコンピュータに実行させる。

図２は、アプリケーションサーバと画像形成装置のハードウェア構成例である。図２（Ａ）は、図１中のアプリケーションサーバ群１に含まれる各々のアプリケーションサーバ１０のハードウェア構成例を示す。

アプリケーションサーバ１０は、ＣＰＵ１１、直接記憶部１２、間接記憶部１３、ネットワークインタフェース１４を有する。ＣＰＵ（Central Processing Unit ）１１は、所定のプログラムを実行し、アプリケーションサーバ１０の各種制御を指示する処理部である。直接記憶部１２は、ＣＰＵ１１がプログラムを実行する際に使用するワークメモリである。このプログラムは直接記憶部１２にロードされる。直接記憶部１２は、ＲＡＭ（Random Access Memory）を備える。間接記憶部１３には、アプリケーションプログラム、ＯＳ（Operating System）を含む各種プログラムが記憶されている。間接記憶部１３に記憶されている各種プログラムは、ＣＰＵ１１がプログラムを実行する際に直接記憶部１２へ移動する。間接記憶部１３は、ＲＯＭ（Read Only Memory）またはＨＤＤ（Hard Disc Drive ）を備える。なお、ＣＰＵ１１がマルチプロセッサであってもよい。ネットワークインタフェース１４は、ネットワーク５（図１）に接続されており、アプリケーションサーバ１０とネットワーク５に接続されている他の装置との通信を媒介する。なお、ストレージサーバ２、ＰＣ３のハードウェア構成は、図２（Ａ）に示すアプリケーションサーバ１０のハードウェア構成と同様である。

図２（Ｂ）は、画像形成装置４のハードウェア構成の例を示す。画像形成装置４は、画像処理ユニット４１と印刷ユニット４２とを備える。画像処理ユニット４１は、アプリケーションサーバ１０から印刷データを取得し、この印刷データに対して所定の画像処理を実行する。印刷ユニット４２は、画像処理ユニット４１によって画像処理された印刷データを印刷する。

画像処理ユニット４１は、ＣＰＵ５１、直接記憶部５２、間接記憶部５３、ユーザインタフェース５４、ネットワークインタフェース３５を備える。ＣＰＵ５１は、所定のプログラムを実行し、画像処理ユニット４１の各種制御を指示するユニットである。直接記憶部５２は、ＣＰＵ５１がプログラムを実行する際に使用するワークメモリである。このプログラムは直接記憶部５２にロードされる。直接記憶部５２は、ＲＡＭにより実現される。間接記憶部５３には、アプリケーションプログラムを含む各種プログラムが記憶されている。間接記憶部５３に記憶されている各種プログラムは、ＣＰＵ５１がプログラムを実行する際に直接記憶部５２へ移動する。間接記憶部５３は、ＳＳＤ（Solid State Drive ）またはＨＤＤにより実現される。ＣＰＵ５１がマルチプロセッサであってもよい。ユーザインタフェース５４は、ユーザからの入力を受け付ける機能を持つ。ユーザインタフェース５４は、タッチパネルや、マウス、キーボードなどの機器を介してユーザからの入力を受け付ける。ネットワークインタフェース５５は、ネットワーク５に接続されており、ネットワーク５に接続されている他の装置との通信を媒介する。

図３は、本実施形態のシステムの機能ブロック図の例である。アプリケーションサーバ群１が含むアプリケーションサーバ１０は、フロントエンド処理部１０１とバックエンド処理部１０２とを備える。フロントエンド処理部１０１は、ＰＣ３、画像形成装置４等の情報処理装置からジョブの処理依頼を受信したことに応じて、ジョブに対応するメッセージを記憶手段（キューサービス２２）に格納する要求受信部として機能する。フロントエンド処理部１０１は、要求受信プログラムを実行することにより実現される。フロントエンド処理部１０１は、一般的なＷｅｂサーバと同等の機能を持ち、同期処理を行うことが可能である。フロントエンド処理部１０１は、キューサービス２２を介して、バックエンド処理部１０２に対して処理内容すなわちジョブに対応するメッセージを伝える役割を持つ。

バックエンド処理部１０２は、キューサービス２２に対し、メッセージの取得要求を定期的に行い、キューサービス２２からメッセージを取得した場合は、該取得したメッセージに基づく処理（メッセージに記載された処理）を行う。例えば、バックエンド処理部１０２は、ネットワーク５を介して、処理の実行結果を該処理の依頼元（ＰＣ３または画像形成装置４）に返す。バックエンド処理部１０２は、バックエンド処理プログラムを実行することにより実現される。アプリケーションサーバ１０のＣＰＵ１１（図２（Ａ））が、バックエンド処理プログラムを実行する。キューサービス２２を介してフロントエンド処理部１０１からバックエンド処理部１０２に対してメッセージの受け渡しがなされることにより、フロントエンド処理部１０１とバックエンド処理部１０２とが非同期で作業を行うことができる。

ストレージサーバ２は、ブロブ２１、キューサービス２２、テーブル２３を備える。ブロブ２１は、バックエンド処理部１０２による処理の実行結果を含む各種データを保存する。ブロブ２１は、図２（Ａ）の間接記憶部１３によって実現される。キューサービス２２は、フロントエンド処理部１０１の指示に従って、ジョブに対応するメッセージを格納する。キューサービス２２は、図２（Ａ）の間接記憶部１３に保存されているキュープログラムが、直接記憶部１２にロードされて、ＣＰＵ１１により実行されることで実現される。テーブル２３は、フロントエンド処理部１０１、バックエンド処理部１０２の処理の状態を含む情報を保持するストレージを提供する。テーブル２３は、公知のデータベースサービスが持つ機能と同じ機能を持つ。

ＰＣ３は、ネットワーク通信部３１、ユーザインタフェース３２、ウェブブラウザ３３を備える。ネットワーク通信部３１は、ネットワーク５を介して外部装置と情報を送受信する。例えば、ネットワーク通信部３１は、ＰＣ３上で動作するアプリケーションの指示に従って、ジョブの処理依頼をネットワーク５を介してアプリケーションサーバ１０に対して送信する。また、例えば、ネットワーク通信部３１は、アプリケーションサーバ１０によるジョブの実行結果を、ネットワーク５を介してアプリケーションサーバ１０から受信する。ユーザインタフェース３２は、ユーザが、ＰＣ３が提供する各種アプリケーションを使用するためのインタフェースである。ＰＣ３は、ユーザインタフェース３２を介して入力されるユーザ操作に従って、各種アプリケーションを実行する。ＰＣ３上で動作するアプリケーションの１つであるウェブブラウザ３３は、ネットワーク通信部３１がネットワーク５を介して送受信する各種情報を表示する。ウェブブラウザ３３は、図２（Ａ）の間接記憶部１３に保存されているプログラムが、直接記憶部１２にロードされ、ＣＰＵ１１により実行されることで実現される。

画像形成装置４は、印刷処理部６１、印刷要求送信部６２、ユーザインタフェース６３、ウェブブラウザ６４を備える。印刷要求送信部６２は、アプリケーションサーバ１０に対して、印刷データの生成と送信に関するジョブの処理依頼を印刷要求として送信する。上記印刷要求は、ユーザインタフェース６３が設定した印刷設定に関する情報を含む。印刷要求送信部６２は、アプリケーションサーバ１０のフロントエンド処理部１０１から、フロントエンド処理部１０１が生成した印刷データを受信する。印刷処理部６１は、印刷データの印刷処理を行う。印刷データは、例えば、ＰＤＬ（Page Description Language ）、ＰＤＦ（Portable Document Format）、ラスタイメージ等である。ユーザインタフェース６３は、図２（Ｂ）中のユーザインタフェース５４に対応する。ユーザインタフェース６３は、ユーザが、画像形成装置４によって提供される各種アプリケーションを使用するためのインタフェースである。画像形成装置４は、ユーザインタフェース６３を介して入力されるユーザ操作に従って、各種アプリケーションを実行する。ウェブブラウザ６４は、ネットワーク５を介して接続されている所定のデバイス内に保存されているデータや情報を表示する機能を持つ。ウェブブラウザ６４は、図２（Ｂ）の間接記憶部５３に保存されているプログラムが、直接記憶部５２にロードされ、ＣＰＵ５１により実行されることで実現される。また、ウェブブラウザ６４は、ネットワーク上に存在する、ドキュメントや画像といった種々のコンテンツを表示することができる。ユーザは、ユーザインタフェース６３を用いて、コンテンツを選択し、印刷指示等を行うことができる。

図４は、アプリケーションサーバのプラットフォームシステムの例を示す図である。図４に示すプラットフォームシステムは、図３に示すアプリケーションサーバ１０の機能を実現する。このプラットフォームシステムの利用者は、アプリケーションサーバ１０が備える物理ハードウェア・リソースをコンピューティングリソースとして使用することができる。

図４に示すプラットフォームシステムは、ロードバランサー４０１、ＶＭ４０２、４０３、ストレージサービス４０４、ファブリックコントローラ４０５を備える。ＶＭ４０２、４０３は、所定の処理を実行する処理実行部である。ＶＭ４０２、４０３の各々は、プラットフォームシステムの内部に複数設けられている。

ＶＭ４０２は、フロントエンド処理部４０２１、エージェント４０２２を備える。フロントエンド処理部４０２１は、図３中のフロントエンド処理部１０１に対応する。フロントエンド処理部４０２１は、ロードバランサー４０１を介してユーザからの処理依頼を受信する。フロントエンド処理部４０２１は、外部ネットワークからの要求を受け付ける機能を有する。また、フロントエンド処理部４０２１は、後述するキュー４０４２を介してバックエンド処理部４０３１への処理依頼を送信する機能を有する。また、フロントエンド処理部４０２１は、エージェント４０２２を介してファブリックコントローラ５０５にアクセスする。フロントエンド処理部４０２１の高い可用性を確保するために、外部ネットワークからの要求（例えばＨＴＴＰによる通信）は、ＶＭ４０２の外部にあるロードバランサー４０１を通じて行われる。ロードバランサー４０１は、外部ネットワークからの要求を一元的に管理し、同等な要求受信機能を有する複数のＶＭに対し、選択的に要求を転送する。

エージェント４０２２は、ＶＭ４０２の使用状況、フロントエンド処理部４０２１の稼動状態、ＶＭ４０２のリソースの使用状況、およびフロントエンド処理部４０２１のエラー情報を含む各種情報を収集する。エージェント４０２２は、収集した各種情報をファブリックコントローラ４０５に定期的に送信する。

フロントエンド処理部４０２１、バックエンド処理部４０３１は、ファブリックコントローラ４０５によって管理されている。これにより、各インスタンスの拡張性と可用性が保証される。例えば、フロントエンド処理部４０２１、またはバックエンド処理部４０３１において、ある特定のインスタンスがサーバの故障によって停止した場合を想定する。この場合、ファブリックコントローラ４０５は、エージェント４０２２またはエージェント４０３２から定期通知を受け取れなくなる。定期通知を受け取らなくなったファブリックコントローラ４０５は、新しいインスタンスに処理が委譲されるようにＶＭに対して指示を出す。その結果、処理を実行しているインスタンス数が一定に保たれるため、処理の遅延を抑えることができる。

ＶＭ４０３は、バックエンド処理部４０３１、エージェント４０３２で構成される。バックエンド処理部４０３１は、図３中のバックエンド処理部１０２に対応する。バックエンド処置部４０３１は、キュー４０４２を介してフロントエンド処理部４０２１からの処理依頼を受信し、処理を行う。バックエンド処理部４０３１は、エージェント４０３２を介してファブリックコントローラ４０５にアクセスする。

フロントエンド処理部４０２１とバックエンド処理部４０３１は、スケールインまたはスケールアウトすることが可能である。フロントエンド処理部４０２１、バックエンド処理部４０３１がスケールインすると、ＶＭ４０２、４０３が減少する。すなわち、フロントエンド処理部４０２１、バックエンド処理部４０３１のインスタンスが減少する。フロントエンド処理部４０２１、バックエンド処理部４０３１がスケールアウトすると、ＶＭ４０２、４０３が増加する。すなわち、フロントエンド処理部４０２１、バックエンド処理部４０３１のインスタンスが増加する。フロントエンド処理部４０２１のスケールアウトを行うことで、ユーザ数の増加などによりトラフィックが増加した場合でも、負荷を分散させることができる。また、バックエンド処理部４０３１のスケールアウトを行うことで、バックエンド処理部１つ当たりのデータ処理量が減少する。これにより、ユーザからの処理依頼に対する結果をより早く返すことができる。

本実施形態のクラウドコンピューティングシステムは、実際にスケールイン、スケールアウトを行う場合には、システム上で動作するアプリケーションに対して、増減させるＶＭの個数を指定して、スケールアウトまたはスケールインの命令を発行する。すなわち、本実施形態のクラウドコンピューティングは、スケールインの命令を発行する際に、実際に停止させるＶＭを一意に指定することができない。従って、本実施形態のクラウドコンピューティングシステムは、スケールインの命令を発行した場合に処理を行っているＶＭが削除されないように、処理を実行していないＶＭのみを含むアプリケーションを検出し、該アプリケーションが含むＶＭを削除する。

ストレージサービス４０４は、ブロブ４０４１、複数のキュー４０４２、複数のテーブル４０４３を備える。ブロブ４０４１は、データ保存に利用されるストレージを提供する。ブロブ４０４１にはメタデータを関連付けることができる。メタデータは名前と値のペアであらわされ、メタデータはデータとは別に取得、設定することができる。キュー４０４２は、フロントエンド処理部４０２１とバックエンド処理部４０３１とが非同期でデータ通信できるようにする。フロントエンド処理部４０２１とバックエンド処理部４０３１は、キュー４０４２に対し各種指示を出すことで、非同期でデータ通信する。フロントエンド処理部４０２１がキュー４０４２に対して行う指示とは、メッセージの追加指示である。バックエンド処理部４０３１がキュー４０４２に対して行う指示とは、メッセージの取得指示、メッセージの削除指示である。

フロントエンド処理部４０２１とバックエンド処理部４０３１が非同期でデータ通信する一連の動作について説明する。フロントエンド処理部４０２１は、ユーザからの処理依頼に応じたメッセージを作成し、メッセージをキューに追加するようにキュー４０４２に追加指示を送信する。追加指示を受信したキュー４０４２は、キューにメッセージを追加する。バックエンド処理部４０３１は、メッセージを取得するために、キュー４０４２にメッセージの取得指示を出す。メッセージの取得指示を受けたキュー４０４２は、メッセージと、メッセージ毎に固有に割り振られたメッセージＩＤと、受取ＩＤとを取得指示に対するレスポンスとしてバックエンド処理部４０３１に返す。メッセージＩＤは、メッセージを一意に定めるためにメッセージごとに割り振られた固有の情報である。受取ＩＤは、処理が終了したバックエンド処理部４０３１がメッセージを削除指示する際に使用するＩＤである。メッセージと、メッセージＩＤと、受取ＩＤとは、関連付けされて保存される。

バックエンド処理部４０３１は、処理依頼を完了すると、受取ＩＤに対応するメッセージの削除指示をキュー４０４２に対して行う。削除指示を受けたキュー４０４２は、バックエンド処理部４０３１が指示した受取ＩＤに対応するメッセージをキューから削除する。これにより、削除指示を出したバックエンド処理部４０３１以外のバックエンド処理部４０３１が同じメッセージを処理するという冗長な処理を防ぐことができる。

次に、キュー５０４２に追加されているメッセージを不可視、または可視にする機能について詳細に説明する。不可視機能は、バックエンド処理部４０３１がキューからメッセージを取得した際に、他のバックエンド処理部４０３１が同一のメッセージを取得しないように、他のバックエンド処理部４０３１がメッセージを取得できない状態（不可視状態）にする機能である。ここで、再度メッセージが取得可能な状態（可視状態）になるまでの時間を不可視時間と呼ぶ。フロントエンド処理部４０２１がキューを作成する際に任意の時間を不可視時間として設定できる。不可視時間中にバックエンド処理部４０３１の処理が終了しない場合、可視状態になり、バックエンド処理部４０３１がメッセージを再取得し処理する。また、バックエンド処理部４０３１が、処理中に何らかの理由でクラッシュし、処理の継続が不可能になった場合でも、不可視時間の間は再処理を行うことができない。また、処理時間が不可視時間を超過した場合には、処理が完了していないメッセージが可視状態になり、他のバックエンド処理部４０３１により処理が開始する。

テーブル４０４３は、ストレージサービス４０４上に複数設けられる。各々のテーブル４０４３が一意の名前を持つ。本実施形態では、テーブル４０４３が、アプリケーション管理テーブル５０８（図５を参照）を備える。プラットフォーム利用者は、各々のテーブルの名前に基づいて、テーブルにアクセスすることができる。テーブル４０４３は、主にサービスの状態を保持するために用いられる。テーブル４０４３は、エンティティと呼ばれる基本的なデータ項目から構成される。エンティティは一連のプロパティで構成される。プロパティはエンティティ内の１つの値を表す。本実施形態では、テーブルを表形式で表現する。表の行をエンティティ、列をプロパティと呼ぶ。

図５は、本実施形態のクラウドコンピューティングシステムの構築例を示す図である。図５に示すクラウドコンピューティングシステムは、フロントエンドアプリケーション５０１、ジョブキュー５０２、必須アプリケーション５０３を備える。また、このクラウドコンピューティングシステムは、追加アプリケーション５０４、５０５、メッセージキュー５０６、管理アプリケーション５０７、アプリケーション管理テーブル５０８を備える。図５中の各々のアプリケーションは、図４に示すプラットフォームシステムを備え、クラウドコンピューティングシステム上で動作する。

本実施形態のクラウドコンピューティングシステムは、依頼された処理の実行に必要なＶＭを全て含んだ１つのアプリケーションがクラウド上に配置された構成を採らない。本実施形態のクラウドコンピューティングシステムは、上記アプリケーションが分割された複数のアプリケーション（必須アプリケーション５０３、追加アプリケーション５０４，５０５）を備える。

各々のアプリケーションが動作するためには、少なくとも一つの起動しているＶＭが必要である。フロントエンドアプリケーション５０１は、図４中のフロントエンド処理部４０２１を備えるＶＭを含む。フロントエンドアプリケーション５０１は、ＰＣ３または画像形成装置４からのジョブの実行依頼を受け付け、ジョブに対応するメッセージをジョブキュー５０２に格納する。このジョブキュー５０２は、図４中のキュー４０４２に対応する。

図５に示すアプリケーションのうち、必須アプリケーション５０３、追加アプリケーション５０４、５０５は、少なくともバックエンド処理部４０３１を備えるＶＭを含む。必須アプリケーション５０３、追加アプリケーション５０４、５０５は、該ＶＭを用いて、ジョブキュー５０２から取得されたメッセージに基づく処理を実行する。必須アプリケーション５０３は、常時起動させておくＶＭのみを含むアプリケーション（第１のアプリケーション）である。必須アプリケーション５０３は、スケールインの対象とならない。追加アプリケーション５０５、５０４は、スケールインの対象となり得るアプリケーション（第２のアプリケーション）である。本実施形態では、追加アプリケーションのうち、処理を行っていないＶＭのみを含む追加アプリケーションがスケールインの対象となる。このために、本実施形態のクラウドコンピューティングシステムは、処理を行っていないＶＭのみを含むアプリケーションが発生し易いようにする。これについては、後述する。

ここで、本実施形態のクラウドコンピューティングシステムが、必須アプリケーション５０３を備える一方で、スケールインの対象となり得るアプリケーションとして追加アプリケーション５０４、５０５を備える理由について説明する。依頼された処理すなわちメッセージに基づく処理を実行するために必要なアプリケーションを細かく分割し、各々のアプリケーションに含まれるＶＭを少なくしたシステムでは、細かいスケールインが可能となる。しかし、前述したように、各アプリケーションには少なくとも１つのＶＭが必要となるので、常にアプリケーション数以上のＶＭが起動しておかなければならず、無駄なコストが発生する。

例えば、稼働状況に応じて、１０個〜３０個のＶＭが必要となるアプリケーションを想定する。必須アプリケーション５０３を用意せず、例えばＶＭを１つ含んだアプリケーションを１５個配置し、適宜、各アプリケーションに対して、スケールイン／スケールアウトを行う場合を想定する。その場合、アプリケーション数以上のＶＭは常に起動しておかなければならないため、最少でも１５個のＶＭが起動していることになる。しかし、実際に依頼された処理を実行するためには１０個のＶＭだけで、十分である場合もあるので、その場合には５個ＶＭが無駄になる。一方、例えば、５個のＶＭを含んだ必須アプリケーションを１つと、２個のＶＭを含んだ追加アプリケーションを５個用意すると、起動するＶＭの最小の個数は１０個となるため、無駄なコストが省けることになる。そこで、本実施形態のクラウドコンピューティングシステムは、常に起動しておくＶＭのみを含む必須アプリケーションを用意し、必須アプリケーションとは別に、スケールインの対象となり得るアプリケーションとして、追加アプリケーションを用意する。必須アプリケーションが含むＶＭの数、および、追加アプリケーションの数は、構築するシステムの規模に応じて変化させることができる。

本実施形態において、必須アプリケーション５０３が含むＶＭの数は、追加アプリケーションが含むＶＭの数より多い。また、必須アプリケーション５０３が含むＶＭは、追加アプリケーションが含むＶＭに優先して、メッセージに基づく処理を実行する。すなわち、追加アプリケーションが含むＶＭは、必須アプリケーション５０３が含む全てのＶＭが処理を実行していない状態においては、自身の処理を実行しないように動作する。これにより、処理を行っていないＶＭのみを含む追加アプリケーションが発生し易くなる。

処理を行っていないＶＭのみを含む追加アプリケーションが発生し易くなるようにする仕組みについて、さらに説明する。後述するように、アプリケーション管理テーブル５０８は、各々のアプリケーションおよびＶＭに対応づけられる、メッセージに基づく処理の実行に関する優先度を含む。本実施形態においては、アプリケーション管理テーブル５０８において、必須アプリケーション５０３に最も高い優先度が設定される。追加アプリケーションが含むＶＭは、アプリケーション管理テーブル５０８を参照し、メッセージに基づく処理の実行に関する優先度が自身の優先度より高いアプリケーションが含む全てのＶＭが処理を行っている状態でない場合には、自身の処理を実行しない。これにより、処理を行っていないＶＭのみを含む追加アプリケーションが発生し易くなる。

管理アプリケーション５０７は、アプリケーション管理テーブル５０８において管理されている各々のアプリケーションの動作状態を監視する。管理アプリケーション５０７は、処理を行っていないＶＭのみを含む追加アプリケーションを検出し、検出した追加アプリケーションが含むＶＭを削除する削除部として機能する。すなわち、管理アプリケーション５０７は、処理を実行しているＶＭを含むアプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含むＶＭを削除する。

ジョブキュー５０２は、ＰＣ３や画像形成装置４からフロントエンドアプリケーション５０１に依頼された処理内容を、必須アプリケーション５０３、追加アプリケーション５０４、５０５に渡すために用いられるキューである。メッセージキュー５０６は、管理アプリケーション５０７と必須アプリケーション５０３との間の通信用に用いられるキューである。アプリケーション管理テーブルは、各々のアプリケーションの動作状態を管理するテーブルである。

図６は、ジョブキュー、メッセージキューに格納されるメッセージの例と、アプリケーション管理テーブルの例を示す図である。図６（Ａ）は、ジョブキュー５０２に格納されるメッセージの例を示す。このメッセージは、画像処理のジョブに対応するメッセージである。このメッセージは、処理の内容としてＯＣＲ、処理対象としてファイルへのパス、ファイルが存在する外部ストレージにアクセスするためのアカウントやパスワード、画像処理を行ったファイルの保存先の情報を含む。なお、ＯＣＲは、Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅｃｏｇｎｉｔｉｏｎの略称である。

図６（Ｂ）は、メッセージキュー５０６に格納されるメッセージの例を示す。必須アプリケーション５０３に含まれるＶＭが、ジョブキューをポーリングした際に、メッセージが格納されていない（処理がない）場合に、図６（Ｂ）に示すフォーマットのメッセージをメッセージキュー５０６に格納する。このメッセージは、ポーリングをしたＶＭのＩＤと、ポーリングをした時刻とを含む。

図６（Ｃ）は、アプリケーション管理テーブル５０８の例を示す。アプリケーション管理テーブル５０８は、必須アプリケーション、追加アプリケーションが含むＶＭの動作状況と、各々のアプリケーションおよびＶＭに対応付けられた優先度とを管理情報として管理する管理部として機能する。上記優先度は、各々のＶＭによる、メッセージに基づく処理の実行に関する優先度、すなわち、画像形成装置４等から依頼されたジョブの実行に関する優先度である。優先度が高いＶＭ、アプリケーションほど、メッセージに基づく処理を先に実行する。

具体的には、アプリケーション管理テーブル５０８は、アプリＩＤ、ＶＭＩＤ、Ｓｔａｔｕｓ、Ｐｒｉｏｒｉｔｙといったデータ項目を有する。アプリＩＤは、アプリケーションを一意に識別する識別情報である。ＶＭＩＤは、アプリケーションに含まれるＶＭを一意に識別する識別情報である。Ｓｔａｔｕｓは、ＶＭの動作状況を示す。Ｓｔａｔｕｓに設定される「Ｗｏｒｋｉｎｇ」は、ＶＭが何らかの処理を行っていることを意味する。各ＶＭは、処理を開始する前に、アプリケーション管理テーブル７０１を確認し、自身のＶＭＩＤに対応するエンティティのＳｔａｔｕｓの値を変更する。「Ｎｏｔ Ｗｏｒｋｉｎｇ」は、ＶＭが処理を行っていない状態を表す。各ＶＭは、処理を終了した後に、アプリケーション管理テーブル５０８における、自身のＶＭＩＤを持つエンティティのＳｔａｔｕｓの値を変更する。

管理アプリケーション５０７は、全てのＶＭのＳｔａｔｕｓがＮｏｔ Ｗｏｒｋｉｎｇであるアプリケーションに対して、スケールインの命令を行う。「Ｒｅｄｕｃｉｎｇ」は、スケールインの命令が発行されている状態であることを表す。一般に、クラウドコンピューティングシステムにおいては、スケールインの命令を発行された直後に、ＶＭが停止するのではなく、一定時間を経た後に、ＶＭが動作を停止する。そのため、スケールインの命令を発行された後においても、ＶＭが処理を開始する可能性がある。そこで、管理アプリケーション５０７は、スケールインの命令を発行する前に、アプリケーション管理テーブル５０８において、命令の発行先のアプリケーションに含まれる全てのＶＭに対応するＳｔａｔｕｓをＲｅｄｕｃｉｎｇに変更する。これにより、ＳｔａｔｕｓがＲｅｄｕｃｉｎｇであるＶＭが処理を開始しないように制御される。

Ｐｒｉｏｒｉｔｙは、メッセージに基づく処理の実行に関する優先度を示す。Ｐｒｉｏｒｉｔｙに格納された値が小さいほど、優先度が高い。本実施形態では、必須アプリケーション５０３が含むＶＭに対して、追加アプリケーションが含むＶＭよりも高い優先度が設定される。これにより、追加アプリケーションが含むＶＭが、必須アプリケーション５０３が含む全てのＶＭが処理を実行中の状態である場合にのみ処理を実行するので、処理を行っていないＶＭのみを含む追加アプリケーションが発生し易くなる。

図７は、必須アプリケーションの処理の例を説明するフローチャートである。図７を参照して説明する処理は、アプリケーションに含まれるＶＭの処理であり、同一アプリケーションに含まれるＶＭは、同様の処理を行う（図８に示すフローチャートの処理においても同様である）。なお、この例では、処理対象のジョブは、画像処理に対応するジョブであるものとする。

まず、必須アプリケーション５０３が含むＶＭが、起動時に、アプリケーション管理テーブル５０８に対して、自身のエンティティを追加する（ステップＳ１）。ＶＭは、アプリケーション管理テーブル５０８において、ＳｔａｔｕｓとしてＮｏｔ Ｗｏｒｋｉｎｇ 、Ｐｒｉｏｒｉｔｙとして１を設定する。

次に、ＶＭが、ジョブキュー５０２をポーリングし、ジョブキュー５０２内に画像処理に対応するジョブのメッセージがあるかを判断する（ステップＳ２）。ジョブキュー５０２内に画像処理に対応するジョブのメッセージがない場合は、ステップＳ３に進む。そして、ＶＭは、メッセージキュー５０６に、現在時刻を記載したメッセージを格納し（ステップＳ３）、ステップＳ２に戻る。

ジョブキュー５０２内に画像処理に対応するジョブのメッセージがある場合、ＶＭが、このジョブに対応するメッセージを取得する（ステップＳ４）。続いて、ＶＭが、アプリケーション管理テーブル５０８において、自身のＶＭのＶＭＩＤに対応するエンティティのＳｔａｔｕｓをＷｏｒｋｉｎｇに設定する（ステップＳ５）。

次に、ＶＭが、ジョブキュー５０２から取得したメッセージに記載されている情報に従って、画像処理の対象のデータを取得する（ステップＳ６）。続いて、ＶＭが、ジョブキュー５０２から取得したメッセージに記載されている情報に従って、上記画像処理の対象のデータに対して画像処理を実行する（ステップＳ７）。ＶＭが、ステップＳ７における画像処理の実行結果を、ブロブ４０４１等のストレージに保存する（ステップＳ８）。そして、ＶＭが、アプリケーション管理テーブル５０８において、自身のＶＭのＶＭＩＤに対応するエンティティのＳｔａｔｕｓをＮｏｔ Ｗｏｒｋｉｎｇに設定して（ステップＳ９）、ステップＳ２に戻る。

図８は、追加アプリケーションの処理を説明するフローチャートである。この例では、図５に示す追加アプリケーション５０４が含むＶＭの処理について説明する。追加アプリケーション５０４が含むＶＭが、起動時に、アプリケーション管理テーブル５０８に対して、自身のエンティティを追加する（ステップＳ１１）。ＶＭは、アプリケーション管理テーブル５０８において、ＳｔａｔｕｓとしてＮｏｔ Ｗｏｒｋｉｎｇを設定する。また、ＶＭは、自身のＰｒｉｏｒｉｔｙを設定する。ＶＭが設定するＰｒｉｏｒｉｔｙの値は、既にアプリケーション管理テーブル５０８に設定済みの他のアプリケーションのＰｒｉｏｒｉｔｙの値のうち最も大きい値よりも１だけ大きい値である。

次に、ＶＭが、アプリケーション管理テーブル５０８において、自身のＶＭのＶＭＩＤに対応するエンティティのＳｔａｔｕｓがＲｅｄｕｃｉｎｇであるかを判断する（ステップＳ１２）。ＳｔａｔｕｓがＲｅｄｕｃｉｎｇである場合は、ステップＳ１２に進む。ＳｔａｔｕｓがＲｅｄｕｃｉｎｇでない場合は、ステップＳ１３に進む。

次に、ＶＭが、アプリケーション管理テーブル５０８を参照して、自身の優先度よりも高い優先度を持つアプリケーションに含まれる全てのＶＭのＳｔａｔｕｓがＷｏｒｋｉｎｇであるかを判断する（ステップＳ１３）。自身の優先度よりも高い優先度を持つアプリケーションに含まれるＶＭのうち、ＳｔａｔｕｓがＷｏｒｋｉｎｇでないＶＭがある場合は、ステップＳ１２に戻る。自身の優先度よりも高い優先度を持つアプリケーションに含まれる全てのＶＭのＳｔａｔｕｓがＷｏｒｋｉｎｇである場合は、ステップＳ１４に進む。

次に、ＶＭが、ジョブキュー５０２をポーリングし、ジョブキュー５０２内に画像処理に対応するジョブのメッセージがあるかを判断する（ステップＳ１４）。ジョブキュー５０２内に画像処理に対応するジョブのメッセージがない場合はステップＳ１２に戻る。ジョブキュー５０２内に画像処理に対応するジョブのメッセージがある場合、ＶＭが、このジョブのメッセージを取得する（ステップＳ１５）。続いて、ＶＭが、アプリケーション管理テーブル５０８において、自身のＶＭＩＤに対応するエンティティのＳｔａｔｕｓをＷｏｒｋｉｎｇに変更する（ステップＳ１６）。

次に、ＶＭが、ジョブキュー５０２から取得したメッセージに記載されている情報に従って、画像処理の対象のデータを取得し、このデータに対して画像処理を実行する（ステップＳ１７）。ステップＳ１７において、ＶＭは、更に、画像処理の実行結果をブロブ４０４１等のストレージに格納する。そして、ＶＭが、アプリケーション管理テーブル５０８において、自身のＶＭＩＤに対応するエンティティのＳｔａｔｕｓをＮｏｔ Ｗｏｒｋｉｎｇに変更して（ステップＳ１８）、ステップＳ１２に戻る。

図８を参照して説明したように、追加アプリケーション５０４が含む各々のＶＭは、アプリケーション管理テーブル５０８が管理するＶＭの動作状況と優先度とを参照して、以下の処理を行う。ＶＭは、自身に対応する優先度より高い優先度を持つアプリケーションが含む全てのＶＭが処理を実行中であるかを判断する（ステップＳ１３を参照）。ＶＭは、自身に対応する優先度より高い優先度を持つアプリケーションが含む全てのＶＭが処理を実行中である場合にのみ、処理を実行する（ステップＳ１３でＹｅｓ，ステップＳ１４乃至Ｓ１７）。すなわち、ＶＭは、自身の優先度より高い優先度を持つアプリケーションに含まれるＶＭに、処理を行っていないＶＭがある場合は、処理を実行しない（ステップＳ１３でＮｏ）。これにより、処理を行っていないＶＭのみを含む追加アプリケーションが発生し易くなる。

図９は、管理アプリケーションの処理を説明するフローチャートである。管理アプリケーション５０７が、メッセージキュー５０６をポーリングし、メッセージキュー５０６にメッセージがあるかを判断する（ステップＳ２１）。メッセージキュー５０６にメッセージがない場合は、ステップＳ２１に戻る。メッセージキュー５０６にメッセージがある場合は、管理アプリケーション５０７が、メッセージキュー５０６からメッセージを取得して保存する（ステップＳ２２）。本実施形態では、メッセージの保存先として、管理アプリケーション５０７が含むＶＭが持つローカルな領域を想定している。管理アプリケーション５０７が、図４に示すテーブル４０４３やブロブ４０４１などにメッセージを保存してもよい。

次に、管理アプリケーション５０７が、必須アプリケーション５０３が含むＶＭがジョブキュー５０２からメッセージを取得できなかった回数が閾値以上である場合に、ＶＭのスケールインをすると判断する。具体的には、管理アプリケーション５０７は、以下の処理を行って、所定時間の間に、所定数以上の個数のメッセージがメッセージキュー５０６に格納されたかを判断する。そして、管理アプリケーション５０７は、所定時間の間に、所定数以上の個数のメッセージがメッセージキュー５０６に格納された場合に、ＶＭのスケールインを行うと判断する。

すなわち、管理アプリケーション５０７が、上記ステップＳ２２において保存したメッセージのうち、所定時間以上保存されているメッセージがあるかを判断する（ステップＳ２３）。所定時間以上保存されているメッセージがある場合、管理アプリケーション５０７は、所定時間以上保存されているメッセージを削除する（ステップＳ２４）。

所定時間以上保存されているメッセージがない場合、管理アプリケーション５０７は、保存されているメッセージの数をカウントする（ステップＳ２５）。続いて、管理アプリケーション５０７は、カウントしたメッセージの数が、予め決められた閾値以上であるかを判断する（ステップＳ２６）。カウントしたメッセージの数が閾値以上でない場合は、ステップＳ２１に戻る。カウントしたメッセージの数が閾値以上である場合は、そのメッセージに対応するＶＭの数（メッセージに記載されているＶＭＩＤの数）を算出して、ステップＳ２７に進む。

管理アプリケーション５０７が、アプリケーション管理テーブル５０８が管理する管理情報を参照して、優先度が最も低いアプリケーションが含む全てのＶＭに対応するエンティティを取得する（ステップＳ２７）。すなわち、管理アプリケーション５０７は、Ｐｒｉｏｒｉｔｙの値が最も大きい追加アプリケーションが含む全てのＶＭの動作状況を取得する。

次に、管理アプリケーション５０７が、取得した全てのエンティティのＳｔａｔｕｓがＮｏｔ Ｗｏｒｋｉｎｇであるかを判断する（ステップＳ２８）。すなわち、管理アプリケーション５０７は、上記取得した全てのＶＭの動作状況に基づいて、追加アプリケーションが処理を実行していないＶＭのみを含むかを判断する。

取得したエンティティのうち、ＳｔａｔｕｓがＮｏｔ Ｗｏｒｋｉｎｇでないエンティティがある場合は、管理アプリケーション５０７が、以下の処理を実行する。管理アプリケーション５０７は、ステップＳ２７において取得したエンティティが含む優先度より高い優先度を含むエンティティがあるかを判断する（ステップＳ２９）。ステップＳ２７において取得したエンティティが含む優先度より高い優先度を含むエンティティがない場合は、ステップＳ２１に戻る。ステップＳ２７において取得したエンティティが含む優先度より高い優先度を含むエンティティがある場合は、管理アプリケーション５０７が、そのエンティティを取得し（ステップＳ３０）、ステップＳ２８に戻る。

取得した全てのエンティティのＳｔａｔｕｓがＮｏｔ Ｗｏｒｋｉｎｇである場合、管理アプリケーション５０７は、このエンティティのＳｔａｔｕｓをＲｅｄｕｃｉｎｇに変更する（ステップＳ３１）。続いて、管理アプリケーション５０７が、ＳｔａｔｕｓをＲｅｄｕｃｉｎｇに変更したエンティティが含むアプリＩＤに対応する追加アプリケーションに対して、スケールインの命令を発行する（ステップＳ３２）。具体的には、管理アプリケーション５０７は、この追加アプリケーションに対して、上記ステップＳ２６において算出された、カウントしたメッセージに対応するＶＭの数だけ、ＶＭを削除することを指示する。スケールインの命令を受けた追加アプリケーションは、指示された個数分のＶＭを削除する。

次に、管理アプリケーション５０７は、アプリケーション管理テーブル５０８から、追加アプリケーションに対して削除を指示したＶＭの個数分だけ、該追加アプリケーションのアプリＩＤを含むエンティティを削除する（ステップＳ３４）。そして、管理アプリケーション５０７が、ステップＳ３４において削除したエンティティが含んでいたアプリＩＤと同じアプリＩＤを含むエンティティのＳｔａｔｕｓをＮｏｔ Ｗｏｒｋｉｎｇに変更し（ステップＳ３４）、ステップＳ２１に戻る。

本実施形態のクラウドコンピューティングシステムによれば、処理を実行していないＶＭのみをスケールインすることができる。従って、処理を実行中のＶＭが削除されないので、再処理の発生を防止できる。その結果、システム全体としてのパフォーマンスが向上する。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

１ アプリケーションサーバ群
２ ストレージサーバ
３ ＰＣ
４ 画像形成装置
５ ネットワーク

Claims (8)

1. 情報処理装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、
   前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムであって、
   各々が少なくとも前記バックエンド処理部を備える処理実行部を含み、該処理実行部を用いて、前記記憶手段から取得されたメッセージに基づく処理を実行するアプリケーションと、
   前記メッセージに基づく処理を実行している前記処理実行部を含む前記アプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含む前記処理実行部を削除する削除部とを備える
   ことを特徴とするクラウドコンピューティングシステム。
2. 前記削除部は、前記メッセージに基づく処理を実行していない前記処理実行部のみを含む前記アプリケーションを検出し、該アプリケーションが含む前記処理実行部を削除する
   ことを特徴とする請求項１に記載のクラウドコンピューティングシステム。
3. 前記アプリケーションが、常時起動させておく処理実行部のみを含む第１のアプリケーションと、該第１のアプリケーションとは異なる第２のアプリケーションとを含み、
   前記第１のアプリケーションが含む前記処理実行部の数は、前記第２のアプリケーションが含む前記処理実行部の数より多く、
   前記第１のアプリケーションが含む前記処理実行部は、前記第２のアプリケーションが含む前記処理実行部に優先して前記メッセージに基づく処理を実行し、
   前記削除部は、前記メッセージに基づく処理を実行していない前記処理実行部のみを含む前記第２のアプリケーションを検出し、該第２のアプリケーションが含む前記処理実行部を削除する
   ことを特徴とする請求項２に記載のクラウドコンピューティングシステム。
4. 前記第１、第２のアプリケーションが含む前記処理実行部の動作状況と、各々のアプリケーションおよび処理実行部に対応付けられ、各々の処理実行部による前記メッセージに基づく処理の実行に関する優先度とを管理情報として管理する管理部を備え、
   前記削除部は、前記管理部が管理する管理情報を参照して、前記メッセージに基づく処理を実行していない処理実行部のみを含む前記第２のアプリケーションを検出する
   ことを特徴とする請求項３に記載のクラウドコンピューティングシステム。
5. 前記削除部は、
   前記第１のアプリケーションが含む前記処理実行部が前記記憶手段から前記メッセージを取得できなかった回数が所定の閾値以上である場合に、前記管理部が管理する管理情報を参照して、対応する前記優先度が最も低い前記第２のアプリケーションが含む全ての処理実行部の動作状況を取得し、
   前記取得した前記全ての処理実行部の動作状況に基づいて、前記第２のアプリケーションが前記メッセージに基づく処理を実行していない処理実行部のみを含むかを判断し、該第２のアプリケーションが前記メッセージに基づく処理を実行していない処理実行部のみを含む場合に、該第２のアプリケーションに対して、該第２のアプリケーションが含む処理実行部の削除を指示する
   ことを特徴とする請求項４に記載のクラウドコンピューティングシステム。
6. 前記第２のアプリケーションが含む各々の処理実行部は、前記管理部が管理する前記処理実行部の動作状況と前記優先度とを参照して、自身に対応する優先度より高い優先度を持つアプリケーションが含む全ての処理実行部が前記メッセージに基づく処理を実行中であるかを判断し、自身に対応する優先度より高い優先度を持つアプリケーションが含む全ての処理実行部が前記メッセージに基づく処理を実行中である場合にのみ、前記メッセージに基づく処理を実行する
   ことを特徴とする請求項４または請求項５に記載のクラウドコンピューティングシステム。
7. 情報処理装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステムの制御方法であって、
   前記クラウドコンピューティングシステムは、各々が少なくとも前記バックエンド処理部を備える処理実行部を含み、該処理実行部を用いて、前記記憶手段から取得されたメッセージに基づく処理を実行するアプリケーションを含み、
   前記メッセージに基づく処理を実行している前記処理実行部を含む前記アプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含む前記処理実行部を削除する工程を有する
   ことを特徴とするクラウドコンピューティングシステムの制御方法。
8. 情報処理装置からジョブの処理依頼を受信したことに応じて、前記ジョブに対応するメッセージを記憶手段に格納する、要求受信プログラムを実行することにより実現される要求受信部と、前記記憶手段に対し前記メッセージの取得要求を定期的に行い、前記記憶手段から前記メッセージを取得した場合は、該取得したメッセージに基づく処理を行う、バックエンド処理プログラムを実行することにより実現されるバックエンド処理部とを有するクラウドコンピューティングシステム上で動作する管理アプリケーションであって、
   前記クラウドコンピューティングシステムは、各々が少なくとも前記バックエンド処理部を備える処理実行部を含み、該処理実行部を用いて、前記記憶手段から取得されたメッセージに基づく処理を実行するアプリケーションを含み、
   前記メッセージに基づく処理を実行している前記処理実行部を含む前記アプリケーションを削除せずに、当該アプリケーション以外のアプリケーションが含む前記処理実行部を削除する
   ことを特徴とする管理アプリケーション。

Images