JP2018142165A

JP2018142165A - プログラム、システム、及び方法

Info

Publication number: JP2018142165A
Application number: JP2017035933A
Authority: JP
Inventors: 雄馬池内; Yuma Ikeuchi
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2017-02-28
Filing date: 2017-02-28
Publication date: 2018-09-13

Abstract

【課題】受信するデータに対応するバージョンのプログラムを起動するための仕組みを提供する。
【解決手段】システムを構成するコンピューターによって、前記システムに含まれるストレージシステムの所定領域へのデータ登録に応じて発生するシステムイベントに従い実行されるプログラムであって、前記システムイベントでの登録対象のデータが第１の条件および第２の条件のいずれを満たすかを判定する判定手段と、前記第１の条件を満たすと前記判定手段が判定した場合に、第１の処理システムに対応する第１のプログラムの起動を行い、前記第２の条件を満たすと前記判定手段が判定した場合に、第２の処理システムに対応する第２のプログラムの起動を行う起動手段として前記コンピューターを機能させる。
【選択図】図１

Description

本発明は、クラウドコンピューティングサービスにおけるイベント駆動型コンピューティングサービスを実現するプログラム、システム、及び方法に関する。

近年、各種のクラウドコンピューティングサービスが存在する。たとえば、ＡｍａｚｏｎＷｅｂＳｅｒｖｉｃｅ（以下「ＡＷＳ」と略す）や、ＧｏｏｇｌｅＣｌｏｕｄＰｌａｔｆｏｒｍ、ＭｉｃｒｏｓｏｆｔＡｚｕｒｅなどである。これらは、仮想サーバーやストレージなどのコンピューティングリソースを、性能や容量に応じて時間単位で課金する形態でサービス提供することで普及してきている。利用者は、これらのサービスを利用することで、自ら物理的な設備を持たなくても、Ｗｅｂシステムなどの情報処理システムを低コストで柔軟に構築することができる。

クラウドコンピューティングサービスの利用例として、ネットワークに接続された各種デバイスやモバイル端末、コンピューター端末から、デバイスやアプリケーションのログ情報や稼働情報を収集してストレージに保存して管理するものがある。ここでは、情報（ファイル等）がストレージにアップロードされるごとにレコードが作成され、ファイル名や置き場所等がデータベースで管理される。

特許文献１には、クラウドコンピューティングサービスを利用したシステムではないが、複数のアプリケーションサーバーのそれぞれに搭載されるアプリケーション間でのデータ連携を実現するアプリケーション連携システムについて記載されている。このアプリケーション連携システムでは、特定パラメータのデータ更新があった際に、このデータ更新をトリガにして、予め登録されているデータドリブン型のスクリプトが起動され、データ更新やアプリケーション間のデータ連携が行われる。

クラウドコンピューティングサービスでも、「ファイルのアップロード」などのイベントの発生に応じて、軽量な処理ができるサービス（以後「イベント駆動型コンピューティングサービス」と呼ぶ）が提供されている。そのサービスで代表的なものが、ＡｍａｚｏｎＬａｍｂｄａ、ＧｏｏｇｌｅＣｌｏｕｄＦｕｎｃｔｉｏｎｓ、ＡｚｕｒｅＦｕｎｃｔｉｏｎｓなどである。これらは、クラウドコンピューティングサービスに対して所望の処理を実現するためのプログラムコードを登録しておくことで、イベント発生時に、該処理を実行させることができるサービスである。ここで言うイベントとは、例えば、ファイルの着信、ＤＢテーブルの更新、アプリケーションやデバイスにより生成されたカスタムイベントなどである。

さらに、ＡｍａｚｏｎＬａｍｂｄａでは、イベント駆動型の非同期処理コードであるプログラム（Ｌａｍｂｄａ関数と呼ばれる）のバージョンを管理することが可能である。イベントが発生した際には、予め指定したバージョンのＬａｍｂｄａ関数を呼び出すことのできる仕組みがある。この仕組みにより、開発ワークフローに合わせて、異なるバリエーションのＬａｍｂｄａ関数の管理が容易となる。

また、近年、上述したクラウドコンピューティングサービスを用いて構築されるシステムをバージョンアップする際などに、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントと呼ばれる技術が利用されることがある。まず、クラウドコンピューティングサービス上では、顧客であるクライアントに対してサービスの提供を行っている現行バージョンの処理システムが本番環境として動作している。ここで、次バージョンの処理システムをクラウドコンピューティングサービス上に更に構築し、動作確認のためのテストを完了した後に、本番環境となる処理システムが切り替えられて、システムのバージョンアップが実現される。具体的に、処理システムのテストでは、動作検証のためのテストリクエストを、決められたスケジュールに従って送信し、それらのリクエストに対し正常な動作を確認することとなる。ここで、現行のバージョンのアプリケーションが動作する、切り替え元の処理システムは、Ｂｌｕｅ環境と呼ばれ、次バージョンのアプリケーションが動作する、切り替え先の処理システムは、Ｇｒｅｅｎ環境と呼ばれる。

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

上述したイベント駆動型コンピューティングサービスでは、２つの処理システムそれぞれに対応する異なるバージョンの２つのプログラム（非同期処理コード）を用意することは可能である。しかしながら、前述のクラウドコンピューティングサービスでは、データを保存するストレージは、両処理システムで共通のものが利用される。ここで、ストレージの特定の領域へデータをアップロードするというイベントの発生に応じて起動できるプログラムは１つしか指定することができない。したがって、上述したシステムのバージョンアップ前のような２つの処理システムが共存する期間において、発生するイベントが２つの処理システムのいずれかのデータ処理に関係するものだとしても、現状、同じバージョンのプログラムが起動されてしまう。

本発明は、上記課題に鑑みてなされたものであり、対象のデータが満たす条件に応じたプログラムを起動させるための仕組みを提供することを目的とする。

上記課題を解決するために、本発明は、システムを構成するコンピューターによって、前記システムに含まれるストレージシステムの所定領域へのデータ登録に応じて発生するシステムイベントに従い実行されるプログラムであって、前記システムイベントでの登録対象のデータが第１の条件および第２の条件のいずれを満たすかを判定する判定手段と、前記第１の条件を満たすと前記判定手段が判定した場合に、第１の処理システムに対応する第１のプログラムの起動を行い、前記第２の条件を満たすと前記判定手段が判定した場合に、第２の処理システムに対応する第２のプログラムの起動を行う起動手段として前記コンピューターを機能させる。

本発明によれば、対象のデータが満たす条件に応じたプログラムを起動させることができる。

本実施形態に係るシステムの全体構成の一例を示す図である。クライアント装置１０１、検証用クライアント装置１０２のハードウェアの構成例を示す図である。ファイルサーバー１０３、ファイル情報管理システム１０４、イベント情報管理サーバー１０５のハードウェアの構成例を示す図である。クライアント装置１０１、検証用クライアント装置１０２のソフトウェアの構成例を示す図である。ファイルサーバー１０３のソフトウェアの構成例を示す図である。ファイル情報管理システム１０４の構成例を示す図である。実施例１におけるアプリケーション７００のソフトウェアの構成例を示す図である。実施例１におけるイベント情報管理サーバー１０５のソフトウェアの構成例を示す図である。非同期処理コードの登録処理の流れを示すシーケンス図である。実施例１におけるＢｌｕｅ環境のファイル情報登録処理の流れを示すシーケンス図である。実施例１におけるディスパッチコード８１１の内容を示す図である。実施例１におけるＧｒｅｅｎ環境の動作検証処理の流れを示すシーケンス図である。実施例２、３におけるアプリケーション１３００のソフトウェアの構成を示す図である。実施例２におけるイベント情報管理サーバー１０５のソフトウェアの構成例を示す図である。実施例２におけるＧｒｅｅｎ環境の動作検証処理の流れを示すシーケンス図である。実施例２におけるディスパッチコード１４１１の内容を示す図である。実施例３におけるイベント情報管理サーバー１０５のソフトウェアの構成例を示す図である。実施例３におけるディスパッチコード１５１０の内容を示す図である。

以下、発明を実施するための形態について、図面を用いて説明する。

（実施例１）
図１は、本実施形態に係るシステムの全体構成の一例を示す図である。システムには、クライアント装置１０１、検証用クライアント装置１０２、ファイルサーバー１０３、ファイル情報管理システム１０４、イベント情報管理サーバー１０５が含まれる。特に、ファイルサーバー１０３、ファイル情報管理システム１０４、及びイベント情報管理サーバー１０５は、クラウドコンピューティングサービスによって提供されるプラットフォームやリソースを利用して構築されるシステムに含まれる。なお、以降、このシステムをクラウドシステムと呼ぶ場合もある。ＩａａｓやＰａａｓなどのクラウドコンピューティングサービスは、リソースとして、例えばインターネット上のデータセンターに存在するサーバーコンピューター上で動作する複数の仮想マシンやストレージなどを提供する。仮想マシンとは、仮想化技術によって、サーバーコンピューターを物理的な構成にとらわれずに論理的な単位で分割し、それぞれが独立したオペレーティングシステムをもって動作する論理的なコンピューターである。

ネットワーク１００は、システムの全体構成に含まれる各要素間で通信を行うための基盤である。本実施例においては、クライアント装置１０１、検証用クライアント装置１０２とそれら以外の構成要素との間はインターネットによって接続されるものとして説明する。それら以外の構成要素間においては、イントラネット、インターネットまたはその他のネットワークシステムを介して接続されている。

クライアント装置１０１、検証用クライアント装置１０２は、図１に示す図の各構成要素のうち、ネットワーク１００を介してファイルサーバー１０３、ファイル情報管理システム１０４と相互に接続する。本実施例においては、クライアント装置１０１、検証用クライアント装置１０２はＰＣ（パーソナルコンピューター）を前提に説明を進めるが、ネットワーク１００を介した通信機能を有する端末であれば種別は問わない。なお、本実施例においては、クライアント装置１０１は、ファイル情報管理システム１０４のＢｌｕｅ環境と通信を行う。つまり、クライアント装置１０１は、クラウドシステムにより提供されるサービスの利用者が操作するＰＣである。検証用クライアント装置１０２は、ファイル情報管理システム１０４のＧｒｅｅｎ環境に対し、動作検証のためのテストリクエストを、決められたスケジュールに従って送信する。

ファイルサーバー１０３は、クライアント装置１０１、検証用クライアント装置１０２から送信されるファイルの実体を受信し、保存するストレージシステムとして機能する。ファイルサーバー１０３は、クライアント装置１０１、検証用クライアント装置１０２から送信される様々なフォーマットのファイルを保存する機能を有する。

ファイル情報管理システム１０４は、ファイル情報管理アプリケーションが稼働する仮想マシン群によって構成される。ファイル情報管理システム１０４は、クライアント装置１０１、検証用クライアント装置１０２から送信されるファイルの属性情報とファイルサーバー１０３上の保存場所情報（ＵＲＬ）を関連付けて保存する。

イベント情報管理サーバー１０５は、イベント駆動型コンピューティングサービスにおけるプログラムコードの管理及び実行を行う。

ここで、イベント駆動型コンピューティングサービスが利用され始める前について説明する。従来、クラウドコンピューティングサービスの利用者により、イベントを検知するためのポーリングや所望の処理を実行するためのアプリケーションと該アプリケーションが稼働するためのインフラの構築や管理が必要だった。しかしながら、イベント駆動型コンピューティングサービスでは、クラウドコンピューティングサービス側で、所望の処理を実現するプログラムコードを実行するためのインフラが用意されて、かつ、イベントを検知するためのポーリング処理が実行される。そのため、クラウドコンピューティングサービスの利用者は、イベント処理の実現が従来に比べて随分と容易になった。

イベント駆動型コンピューティングサービスの利用者は事前にイベント情報管理サーバー１０５にプログラムとそれを実行するためのファイルサーバー１０３で発生するイベントとを関連付けて登録する。ここでのイベントとは、具体的には「ファイルサーバー１０３の所定領域にファイルがアップロードされたこと」や「ファイルサーバー１０３の所定のパスに保存されるファイルが更新されたこと」などである。すなわち、イベントは、ファイルサーバー１０３で保存されるファイルに対してクライアント装置１０１などが行う操作のことを指す。また、イベント情報管理サーバー１０５には、プログラムを実行する仮想マシンの環境情報などコンピューティングリソースの情報も、イベントと関連付けて登録される。環境情報として、具体的には、仮想マシンで稼働するＣＰＵやＲＡＭの性能が、イベント登録時に指定される。これにより、イベント情報管理サーバー１０５は、ファイルサーバー１０３でイベントが検出されたタイミングで、ファイルサーバー１０３で実行される処理とは非同期で所定のプログラムを実行できる。以降、イベント情報管理サーバー１０５が、ファイルサーバー１０３で検出されるイベントに応答して実行されるプログラムを非同期処理コードと呼ぶ。また、ファイルサーバー１０３で検出されるイベントを、システムイベントとも呼ぶ。

図２は、クライアント装置１０１、検証用クライアント装置１０２のハードウェア構成の一例を示す図である。

システムバス２００はクライアント装置１０１、検証用クライアント装置１０２を構成する各ハードウェアを相互に接続するバスである。本実施例においては特に言及しない限り、システムバス２００はＣＰＵ２０１からの制御命令をシステムバス２００に接続された各ハードウェアに伝播させるものとする。

ＣＰＵ２０１は、ＲＡＭ２０２及び記憶装置２０３から読み込んだプログラムを実行し、本実施例を実現するためにシステムバス２００で接続されたクライアント装置の各ハードウェアを直接的あるいは間接的に制御する。ＲＡＭ２０２は、ＣＰＵ２０１が動作するためのワーク領域として利用される一時メモリ領域である。記憶装置２０３は、基本ソフトウェアであるＯＳやその他ソフトウェアモジュールが記憶されているＨＤＤに代表されるような外部記憶装置である。

ネットワーク装置２０４は、ネットワーク１００に接続して他の装置と通信を行うハードウェアである。入出力インターフェース２０５は、入出力装置２０６と接続するためのインターフェースである。入出力インターフェース２０５は例えばＰＳ２やＵｎｉｖｅｒｓａｌＳｅｒｉａｌＢｕｓ（ＵＳＢ）、アナログやデジタルのディスプレイインターフェースを備える。入出力装置２０６は、入出力インターフェース２０５を介して、情報のインプットおよびアウトプットを行う装置である。入出力装置２０６は例えばディスプレイ、キーボード、マウスなどがある。

図３は、クラウドシステムが構築されるデータセンター上に存在するサーバーコンピューターのハードウェア構成の一例を示す図である。

システムバス３００は、サーバーコンピューターを構成する各ハードウェアを相互に接続するバスである。本実施例においては特に言及しない限り、システムバス３００はＣＰＵ３０１からの制御命令を、システムバスに接続された各ハードウェアに伝播させるものとする。

ＣＰＵ３０１は、ＲＡＭ３０２および記憶装置３０３から読み込んだプログラムを実行し、本実施例を実現するためにシステムバス３００で接続されたクライアント装置の各ハードウェアを直接的あるいは間接的に制御する。ＲＡＭ３０２は、ＣＰＵ３０１が動作するためのワーク領域として利用される一時メモリ領域である。記憶装置３０３は、基本ソフトウェアであるＯＳやその他ソフトウェアモジュールが記憶されているＨＤＤに代表されるような外部記憶装置である。ネットワーク装置３０４は、ネットワーク１００に接続して他の装置と通信を行うハードウェアである。

なお、ファイルサーバー１０３、ファイル情報管理システム１０４、イベント情報管理サーバー１０５の機能構成も、図３に示すハードウェア構成と同じ構成である。つまり、それらは、仮想マシンソフトウェアによって、アプリケーションソフトウェアが実現され、物理ハードウェア要素と同様の挙動をとるものとする。

図４は、クライアント装置１０１、検証用クライアント装置１０２のソフトウェア構成の一例を示す図である。

アプリケーション４００は、クライアント装置１０１の記憶装置２０３に格納されてＣＰＵ２０１によって実行される、クライアント装置の情報を送信するアプリケーションである。アプリケーション４００は、通信部４０１、情報収集部４０２から構成される。

通信部４０１は、ネットワーク装置２０４を介してファイルサーバー１０３、ファイル情報管理システム１０４と通信を行う。情報収集部４０２は、クライアント装置１０１が生成するクライアント装置情報を収集して、ファイルとして記憶装置２０３に保存する。具体的には、情報収集部４０２は、クライアント装置１０１が出力するハードウェアのログ情報などを逐次ファイルとして記憶装置２０３に保存する。

アプリケーション４１０は、検証用クライアント装置１０２の記憶装置２０３に格納されてＣＰＵ２０１によって実行される、ファイル情報管理システム１０４を検証するためのアプリケーションである。アプリケーション４１０は、通信部４１１、検証情報管理部４１２から構成される。

通信部４１１は、検証情報管理部４１２から、ファイル情報管理システム１０４が正常に稼働しているかどうかを確認するための検証用ファイル情報を、検証情報管理部４１２から取得する。その上で、通信部４１１は、ネットワーク装置２０４を介してファイルサーバー１０３、ファイル情報管理システム１０４と通信を行い、ファイル情報管理システム１０４の検証を行う。

検証情報管理部４１２は、通信部４１１がファイル情報管理システム１０４に対して送信する検証用ファイル情報を記憶装置２０３に保存する。具体的には、検証情報管理部４１２は、ファイル情報管理システムに対する正常系のリクエストや異常系のリクエストおよび関連するファイルを、プロジェクトファイル形式で保存する。

図５は、ファイルサーバー１０３で稼働するアプリケーション５００のソフトウェア構成の一例を示す図である。

アプリケーション５００は、ファイルサーバー１０３の記憶装置３０３に格納されＣＰＵ３０１によって実行される、ファイル管理のためのアプリケーションである。アプリケーション５００は、通信部５０１、ファイル管理部５０２、ファイル保存部５０３から構成される。

通信部５０１は、ネットワーク装置３０４を介してクライアント装置１０１、検証用クライアント装置１０２、ファイルサーバー１０３、ファイル情報管理システム１０４、イベント情報管理サーバー１０５と通信を行う。

ファイル管理部５０２は、通信部５０１を介してクライアント装置１０１、検証用クライアント装置１０２、ファイル情報管理システム１０４、イベント情報管理サーバー１０５からのリクエストを受信する。また、ファイル管理部５０２は、通信部５０１を介してイベント情報管理サーバー１０５へイベントを送信する。

ファイル保存部５０３は、ファイル管理部５０２からの指示に従って、クライアント装置１０１、検証用クライアント装置１０２から受信したファイルの実体を保存する。またファイル保存部５０３は、ファイル管理部５０２からの指示にしたがって図１に示す本実施例の各構成要素からリクエストに応じたファイルの実体を送信する。ファイル保存部５０３がファイルの実体を管理するデータの一例を、以下のファイル管理テーブルに示す。

ＩＤカラムには、ファイルサーバー１０３に保存されるファイルをアプリケーション５００が一意に識別するための値が格納される。保存パスカラムには、ファイルサーバー１０３におけるファイルの保存先フォルダのパス情報が格納される。ファイル名カラムには、ファイルサーバー１０３に保存されるファイルの名称の値が格納される。ファイルデータカラムには、ファイルサーバー１０３に保存されるファイルの実体となるバイナリデータが保存される。属性カラムには、ファイルサーバー１０３に保存されるファイルの属性情報が格納される。本実施例においては、属性カラムには、該ファイルのイベントを実行する非同期処理コード名が、属性情報として格納されている。例えば、本テーブルのＩＤカラムが「１」のデータは、「ＧｒｅｅｎＰｒｏｃ」の非同期処理コードが実行されることを意味している。

図６は、ファイル情報管理システム１０４の構成例を示す図である。図６（Ａ）は、Ｇｒｅｅｎ環境６１０が生成される前のファイル情報管理システム１０４を示す図である。図６（Ａ）において、ファイル情報管理システム１０４は、Ｂｌｕｅ環境６００で構成され、ＣＰＵ３０１によって実行される。なお、のように、ロードバランサーと仮想マシンとを含むＢｌｕｅ環境６００などを、処理システムとも呼ぶ。

図６（Ｂ）は、Ｇｒｅｅｎ環境６１０が生成された後のファイル情報管理システム１０４を示す図である。図６（Ｂ）において、ファイル情報管理システム１０４は、図６（Ａ）のファイル情報管理システム１０４の構成にＧｒｅｅｎ環境６１０が追加されて、処理システムを複数含むこととなる。Ｇｒｅｅｎ環境６１０は、検証用クライアント装置１０２による動作検証が完了した後に、Ｂｌｕｅ環境６００と代わって本番環境となる。

ここで、システムバージョンアップの方法であるＢｌｕｅ−Ｇｒｅｅｎデプロイメントについて説明する。ここで、システムのバージョンアップとは、例えば、システム内の仮想マシンで実行されるアプリケーションのバージョンアップが含まれる。バージョンアップ後のシステムは、提供できる機能が追加されたり、管理するデータの種類や形式が変更されたりする。まず、クラウドコンピューティングサービス上では、外部ネットワークからのリクエストを受け付けて処理を行っている本番環境としての処理システムが動作している。処理システムは、少なくとも、リクエストを処理する１以上の仮想マシンと、それらにリクエストを分散させる負荷分散装置として機能するロードバランサーとで構成される。そして、該処理システムをバージョンアップさせたい場合には、現行のバージョンの該処理システムとは異なるバージョンの処理システムをクラウドコンピューティングサービス上に更に構築する。そのあと、バージョンアップさせたいタイミングになったら、クラウドコンピューティングサービス上で外部ネットワークからのリクエストの送信対象を示す接続先の設定の変更などを行い、本番環境となる処理システムを切り替える。ここでは、本番環境がバージョンアップ後の処理システムに切り替えられる。この切り替えによって、システムのバージョンアップが実現される。

図６においてＢｌｕｅ環境６００は、現行のバージョンのアプリケーションが動作する処理システムであり、ロードバランサー６０１、仮想マシン６０２から構成される。Ｇｒｅｅｎ環境６１０は、次バージョンのアプリケーションが動作する処理システムであり、ロードバランサー６１１、仮想マシン６１２から構成される。なお、ロードバランサー６０１、６１１、仮想マシン６０２、６１２は、それぞれの環境において、複数存在しても良い。

ロードバランサー６０１は、負荷分散装置であり、クライアント装置１０１から受け付けたリクエストを仮想マシン６０２に転送する。仮想マシン６０２は、ロードバランサー６０１から転送されたリクエストを受け付けて処理するＷｅｂサーバーである。

ロードバランサー６１１は、負荷分散装置であり、検証用クライアント装置１０２から受け付けた動作検証リクエストを仮想マシン６１２に分散させる。仮想マシン６１２は、ロードバランサー６１１から転送された、リクエストを受け付けて処理するＷｅｂサーバーである。

図７は、仮想マシン６０２、６１２で稼働するアプリケーション７００のソフトウェア構成の一例を示す図である。

アプリケーション７００は、仮想マシン６０２、６１２上に配置されてＣＰＵ３０１によって実行される、ファイル情報を管理するためのアプリケーションである。アプリケーション７００は、通信部７０１、ファイル情報管理部７０２、ファイル情報保存部７０３から構成される。

通信部７０１は、ネットワーク装置３０４を介して、ファイルサーバー１０３と通信を行う。さらに、通信部７０１は、Ｂｌｕｅ環境であればロードバランサー６０１と通信を行い、Ｇｒｅｅｎ環境であればロードバランサー６１１と通信を行う。

ファイル情報管理部７０２は、通信部７０１を介してロードバランサー６０１、６１１、ファイルサーバー１０３からのリクエストを受信する。ファイル情報管理部７０２は、取得したリクエスト情報をもとにファイル情報保存部７０３にファイル情報の保存を要求する。

ファイル情報保存部７０３は、ファイル情報管理部７０２からの指示に従って、ファイルサーバー１０３から受信したファイルの実体から抽出した各属性情報を保存する。イベント情報管理サーバー１０５が実行する非同期処理コードの実行結果として、各属性情報がファイル情報保存部７０３に保存される。

ファイル情報保存部７０３がファイルの属性情報を管理するデータの一例を、以下のファイル情報管理テーブルに示す。

ＩＤカラムには、ファイル情報管理システム１０４において保存するファイルの属性情報をアプリケーション７００が一意に識別するための値が格納される。アップロードファイルパスカラムには、ファイルサーバー１０３に保存されるファイル実体のパスが格納される。属性カラムには、ファイルの実体から抽出した属性情報がそれぞれ格納される。属性カラムに格納される値としては、アプリケーションの用途に関する情報などがある。例えば、ファイルサイズやファイルから抽出した全文検索用のインデックステキストデータ等が挙げられる。なお、本実施例においては、抽出する属性情報の値については特に限定するものではない。

図８は、イベント情報管理サーバー１０５で稼働する各アプリケーションのソフトウェア構成の一例を示す図である。

イベント情報管理サーバー１０５は、アプリケーション８００、アプリケーション８２０、実行環境８３０から構成される。アプリケーション８００、アプリケーション８２０、実行環境８３０は、イベント情報管理サーバー１０５の記憶装置３０３に格納され、ＣＰＵ３０１によって実行される。アプリケーション８００は、イベント情報管理サーバー１０５で実行する非同期処理コードの保存や、非同期処理コードの実行設定の管理を行う。アプリケーション８００は、通信部８０１、非同期処理コード管理部８０２、非同期処理コード保存部８０３、非同期処理コード設定保存部８０４、非同期処理コード８１０から構成される。

通信部８０１は、ネットワーク装置３０４を介してクライアント装置１０１、ファイルサーバー１０３、ファイル情報管理システム１０４、アプリケーション８２０と通信を行う。非同期処理コード管理部８０２（以降、管理部８０２と記載）は、通信部８０１を介してクライアント装置１０１からの非同期処理コード登録リクエストを受信する。また、アプリケーション８２０からの非同期処理コード要求リクエストを受信する。

非同期処理コード保存部８０３（以降、保存部８０３と記載）は、管理部８０２からの指示に従って、クライアント装置１０１から受信した非同期処理コードを保存する。また、保存部８０３は、管理部８０２からの指示に従って、アプリケーション８２０に非同期処理コードを送信する。保存部８０３が非同期処理コードを管理するデータの一例を、以下の非同期処理コード管理テーブルに示す。

ＩＤカラムには、アプリケーション８００において、保存される非同期処理コードを一意に識別するための値が格納される。コード名カラムには、アプリケーション８００において、保存される非同期処理コードのコード名称の値が格納される。ファイルデータカラムは、アプリケーション８００において、保存される非同期処理コードのバイナリデータが保存される。次に、非同期処理コード設定保存部８０４（以降、設定保存部８０４と記載）は、管理部８０２からの指示に従って、クライアント装置１０１から受信した非同期処理コードの実行設定を非同期処理コードの実体と関連付けて保存する。また、保存部８０３は、管理部８０２からの指示に従って、アプリケーション８２０に非同期処理コードの実行設定を非同期処理コードと合わせて送信する。

設定保存部８０４が非同期処理コードの実行設定を管理するデータの一例を、以下の実行環境設定テーブル、イベント設定テーブルに示す。

ＩＤカラムには、アプリケーション８００において、非同期処理コードを実行する仮想マシン環境の設定を一意に識別するための値が格納される。実行環境タイプカラムには、非同期処理コードを実行する仮想マシン環境の特徴を示す名称が格納される。ＣＰＵカラムには、非同期処理コードを実行する仮想マシン環境のＣＰＵ値が格納される。ＲＡＭカラムには、非同期処理コードを実行する仮想マシン環境のＲＡＭ値が格納される。ＨＤＤカラムには、非同期処理コードを実行する仮想マシン環境のＨＤＤのサイズが格納される。

ＩＤカラムには、アプリケーション８００において、非同期処理コードの実行対象となるイベントを一意に識別するための値が格納される。対象ファイルパスカラムには、非同期処理コードを実行する対象のファイルパスが格納される。対象イベントカラムには、非同期処理コードを実行する条件となる対象ファイルパスカラムに格納されたファイルパスに該当するファイルに対して実行された操作の内容が格納される。非同期処理コードＩＤカラムには、実行される非同期処理コードに該当する非同期処理コード管理テーブルのＩＤカラムの値が格納される。実行環境ＩＤカラムには、非同期処理コードを実行する環境に該当する実行環境設定テーブルのＩＤカラムの値が格納される。

ここで、イベント設定テーブルのＩＤカラムの値が「１」のレコードを例にとって説明する。これは、「ｌｏｇｄａｔａ」以下のフォルダにファイルが「追加」された場合に「Ｄｉｓｐａｔｃｈ」の非同期処理コードをＣＰＵ２ＧＨｚ、ＲＡＭ４ＧＢ、ＨＤＤ１ＧＢの仮想マシン環境で実行することを意味している。

次に、非同期処理コード８１０は、設定保存部８０４によって保存された非同期処理コードのバイナリデータであり、イベント情報管理サーバー１０５の記憶装置３０３に格納され、ＣＰＵ３０１によって実行される。本実施例においては、ディスパッチコード８１１、Ｂｌｕｅ環境コード８１２、Ｇｒｅｅｎ環境コード８１３が格納されるものとする。

ディスパッチコード８１１は、「ｌｏｇｄａｔａ」以下のフォルダにファイルが「追加」された場合に実行される非同期処理コード「Ｄｉｓｐａｔｃｈ」のバイナリデータである。Ｂｌｕｅ環境コード８１２は、現行のバージョンの非同期処理コード「ＢｌｕｅＰｒｏｃ」のバイナリデータである。Ｂｌｕｅ環境コード８１２のバージョンは、Ｇｒｅｅｎ環境コード８１３のバージョンと比較して古い。Ｇｒｅｅｎ環境コード８１３は、次バージョンの非同期処理コード「ＧｒｅｅｎＰｒｏｃ」のバイナリデータである。Ｇｒｅｅｎ環境コード８１３のバージョンは、Ｂｌｕｅ環境コード８１２のバージョンと比較して新しい。

アプリケーション８２０は、ファイルサーバー１０３から受信するイベントに応じた非同期処理コードとその実行設定をアプリケーション８００から取得する。さらに、アプリケーション８２０は、取得した非同期処理コードを実行する実行環境８３０を作成するものである。

アプリケーション８２０は、通信部８２１、非同期処理コード実行管理部８２２、非同期処理コード実行部８２３、非同期処理コード実行環境管理部８２４から構成される。通信部８２１は、ネットワーク装置３０４を介しファイルサーバー１０３、ファイル情報管理システム１０４、アプリケーション８００、実行環境８３０と通信を行う。非同期処理コード実行管理部８２２（以降、管理部８２２と記載）は、通信部８２１を介してファイルサーバー１０３からイベント、アプリケーション８００から非同期処理コードおよび実行設定を受信する。

非同期処理コード実行部８２３（以降、実行部８２３と記載）は、管理部８２２からの指示に従って、ファイルサーバー１０３から受信したイベントに対応する非同期処理コードおよび実行設定を受信する。また、実行部８２３は、ファイルサーバー１０３から受信した実行設定に基づき、実行環境８３０を生成し、イベントに対応する非同期処理コードの実行を指示する。

非同期処理コード実行環境管理部８２４（以降、管理部８２４と記載）は、実行環境８３０で実行する非同期処理コードの実行状況を管理する。管理部８２４が管理する実行環境８３０の稼働条件の一例を、以下の実行環境監視項目テーブルに示す。

ＩＤカラムには、アプリケーション８２０において、実行環境８３０の稼働状況を管理する項目を一意に識別するための値が格納される。監視項目カラムには、実行環境８３０で実行中の非同期処理コードの実行状況を監視するための項目が格納される。監視項目値カラムには、監視項目カラムに格納された項目に対する閾値が格納される。例えば、実行環境監視項目テーブルのＩＤカラムの値が「１」のレコードの場合、実行環境８３０で実行される非同期処理コードのリトライを５回まで許容することを意味する。５回実行しても非同期処理コードがイベントの処理を完了できなかった場合は、エラーとなりアプリケーション８２０は非同期処理コードの実行を中断する。

また、実行環境監視項目テーブルのＩＤカラムの値が「２」のレコードの場合、実行環境８３０で実行される非同期処理コードがイベントの処理に要する時間を３００秒までと制限することを意味する。３００秒を越えても非同期処理コードがアプリケーション８２０に対して処理完了の通知を送信しない場合は、処理を中断させる。

次に、実行環境８３０は、ファイルサーバー１０３がアプリケーション８２０に送信したイベントを対応する非同期処理コードを実行して処理するための仮想マシン環境である。実行環境８３０は、通信部８３１、実行部８３２から構成される。通信部８３１は、ネットワーク装置３０４を介しファイルサーバー１０３、ファイル情報管理システム１０４、アプリケーション８００、実行環境８３０と通信を行う。実行部８３２は、通信部８３１を介してアプリケーション８２０から受信したファイルサーバー１０３で発生したイベントを、アプリケーション８００から受信した非同期処理コードを実行して処理する。また、実行部８３２は、管理部８２４から逐次実行監視リクエストを受信し、実行中の非同期処理コードに対する監視リクエストをアプリケーション８２０から受信して、非同期処理コードの実行を制御する。

図９に、図８で説明したイベント情報管理サーバー１０５上での非同期処理コードの登録処理の一連の流れをシーケンス図で示す。図９は、本実施例においてクライアント装置１０１がアプリケーション８００に非同期処理コードを登録する一連の処理を示したシーケンス図である。なお、クライアント装置１０１ではなく、不図示のシステム管理者ＰＣが非同期処理コードを登録しても良い。

Ｓ９０１において、クライアント装置１０１は、通信部４０１を介してアプリケーション８００に非同期処理コード登録リクエストを送信する。非同期処理コード登録リクエストとしてアプリケーション８００に送信されるレコードの一例を、非同期処理コード登録リクエストレコードとして以下に示す。

非同期処理コードカラムには、非同期処理コードの実体がバイナリデータで格納される。非同期処理コード名カラムには、非同期処理コードのコード名が格納される。実行対象ファイルパスカラムには、非同期処理コードを実行する対象となるファイルサーバー１０３上のファイルパスが格納される。アプリケーション８２０は、ファイルサーバー１０３から受信するイベントに含まれるファイルパスを参照して、このカラムに格納されたパスと一致した場合に非同期処理コードを実行すべきイベントであると判別することになる。実行対象イベントカラムには、ファイルサーバー１０３上の実行対象ファイルパスに格納されたファイルに対して、非同期処理コードを実行する対象とする操作が格納される。実行環境ＩＤカラムには、非同期処理コードを実行する実行環境に該当する実行環境設定テーブルのＩＤカラムの値が格納される。

例えば、表７に示す非同期処理コード登録リクエストレコードの１行目は、ファイルサーバー１０３の「ｌｏｇｄａｔａ」フォルダ以下にファイルが追加された場合に実行される非同期処理コード「Ｄｉｓｐａｔｃｈ」の登録要求である。なお、２行目の「ＢｌｕｅＰｒｏｃ」および３行目の「ＧｒｅｅｎＰｒｏｃ」はファイルパス、イベントの値ともに空であるが、これはコードのみを登録し、特にイベントとの紐づけは行わないことを意味する。なお、本実施例においては、「Ｄｉｓｐａｔｃｈ」がディスパッチコード８１１、「ＢｌｕｅＰｒｏｃ」がＢｌｕｅ環境コード８１２、「ＧｒｅｅｎＰｒｏｃ」がＧｒｅｅｎ環境コード８１３に対応するものとする。

次に、Ｓ９０２において、アプリケーション８００は、通信部７０１が受信した非同期処理コード登録リクエストレコードから非同期処理コード管理レコードを生成する。さらに、それを保存部８０３の非同期処理コード管理テーブルに格納する。非同期処理コード管理レコードのコード名カラムには非同期処理コード登録リクエストレコードの非同期処理コード名カラムの値が格納される。非同期処理コード管理レコードのファイルデータカラムには非同期処理コード登録リクエストレコードの非同期処理コードカラムのバイナリデータが格納される。

Ｓ９０３において、アプリケーション８００は、イベント設定レコードを生成して、設定保存部８０４のイベント設定テーブルに格納する。イベント設定レコードの対象ファイルパスカラムには、非同期処理コード登録リクエストレコードの実行対象ファイルパスカラムの値が格納される。イベント設定レコードの対象イベントカラムには、非同期処理コード登録リクエストレコードの実行対象イベントカラムの値が格納される。イベント設定レコードの非同期処理コードＩＤカラムには、Ｓ９０２で保存部８０３の非同期処理コード管理テーブルに格納された非同期処理コード管理レコードのＩＤカラムの値が格納される。イベント設定レコードの実行環境ＩＤカラムには、非同期処理コード登録リクエストレコードの実行環境ＩＤカラムの値が格納される。

以上の図９で示すシーケンスの処理によって、アプリケーション８００に非同期処理コードが登録されることになる。

図１０に、Ｂｌｕｅ環境における一連の処理の流れをシーケンス図で示す。図１０は、クライアント装置１０１がファイル情報管理システムのＢｌｕｅ環境６００に対してファイル情報を登録して、ファイル情報管理システム１０４のＢｌｕｅ環境コード８１２が実行されるまでの一連の処理を示したシーケンス図である。

Ｓ１００１において、クライアント装置１０１は、通信部４０１を介してデータ登録のためのリクエストをファイル情報管理システム１０４のＢｌｕｅ環境６００に送信する。なお、不図示のＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバーで、クライアント装置１０１からのリクエストの送信先がＢｌｕｅ環境６００のロードバランサー６０１に設定されているものとする。具体的には、ＤＮＳサーバーで保持されるレコードが、クライアント装置１０１からのリクエストの送信先として、Ｂｌｕｅ環境６００のロードバランサー６０１を示している。つまり、ＤＮＳサーバーのレコードが書きかえられることで、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントが実行される。ここでの登録対象となるデータは、情報収集部４０２がファイルとして出力したログ情報などである。ファイル情報登録リクエストとしてファイル情報管理システム１０４のＢｌｕｅ環境６００に送信されるレコードの一例を、ファイル情報登録リクエストレコードとして以下に示す。

ファイル名カラムには、登録されるファイルの名称が格納される。アップロード先フォルダカラムには、ファイルのアップロード先となるファイルサーバー１０３のフォルダパスが格納される。次に、Ｓ１００２において、ファイル情報管理システム１０４のＢｌｕｅ環境６００のロードバランサー６０１は、ファイル情報登録リクエストを受信し、仮想マシン６０２にリクエストに送信する。仮想マシン６０２で稼働するアプリケーション７００の通信部７０１は、ロードバランサー６０１からファイル情報登録リクエスト（表８）を受信する。ファイル情報管理部７０２は、通信部７０１が受信したファイル情報登録リクエスト（表８）をもとに、登録対象のデータに関する情報であるファイル情報をファイル情報保存部７０３に登録する。ファイル情報管理部７０２は、ファイル情報の登録が成功すると、通信部７０１を介して、クライアント装置１０１にファイル情報登録成功を示すレスポンスを送信する。

Ｓ１００３において、クライアント装置１０１は、通信部４０１を介して情報収集部４０２がファイルとして出力したログファイルを登録するファイルアップロードリクエストをファイルサーバー１０３に送信する。ファイルアップロードリクエストとしてファイルサーバー１０３に送信されるレコードの一例をファイルアップロードリクエストレコードに示す。

ファイルデータカラムには、送信対象のファイルのバイナリデータが格納される。アップロードパスカラムには、ファイルのアップロード先となるファイルサーバー１０３に存在するファイルパスが格納される。関連非同期処理コード名カラムには、ファイルのアップロードに関連して実行を行う非同期処理コード８１０のコード名が格納される。なお、図１０のシーケンスにおいては、Ｂｌｕｅ環境の非同期処理コードであるＢｌｕｅ環境コード８１２を実行することを想定する。クライアント装置１０１は、表９で示すように、関連非同期処理コード名カラムに値を入れずに、ファイルアップロードリクエストを送信する。一方、表１３を用いて後述する検証用クライアント装置からのファイルアップロードリクエストには、関連非同期処理コード名カラムに値が入る。これにより、クライアント装置からのリクエストのカラムをクライアント装置で動作するアプリケーションの更新の手間が不要となり、また、クライアント装置１０１からのリクエストのデータサイズを増やさずに済む。

したがって、関連非同期処理コード名カラムが「空」であることから、検証用クライアント装置１０２ではなくクライアント装置１０１からのリクエストであることが判別可能となる。つまり、関連非同期処理コード名カラムが「空」であることに基づき、本リクエストでの登録対象のデータが第１の条件を満たすと判定され、Ｂｌｕｅ環境コード８１２が起動される。

次に、Ｓ１００４において、ファイルサーバー１０３は、通信部５０１が受信したファイルアップロードリクエストに含まれる各データをファイル保存部５０３のファイル管理テーブルに追加する。ファイルサーバー１０３は、ファイル保存部５０３への各データの追加が完了すると、通信部５０１を介してクライアント装置１０１にファイルアップロードが完了したことを通知するレスポンスを送信する。

Ｓ１００５において、ファイルサーバー１０３は、ファイルのアップロードが完了したことを示すイベントを生成して、通信部５０１を介してアプリケーション８２０に通知する。ファイルアップロード完了イベントとして、アプリケーション８２０に送信されるレコードの一例を、以下のファイルアップロード完了イベントに示す。

ファイルパスカラムには、イベントを生成するきっかけとなったファイルのファイルサーバー１０３でのファイルパスが格納される。イベント種別カラムには、ファイルパスカラムに格納されたファイルパスに保存されているファイルサーバー１０３のファイルに対して行われた操作内容が格納される。ファイルサーバー１０３は、Ｓ１００３でクライアント装置１０１からファイルを新規にアップロードされたため、上述の例においては「追加」の値が入る。

次に、Ｓ１００６において、アプリケーション８２０は、通信部８２１を介して受信したファイルアップロード完了イベントの内容を管理部８２２で確認する。まず、管理部８２２は、ファイルアップロード完了イベントのファイルパスカラムの値からファイル名を除いたフォルダパスと、イベント種別カラムの値を取得する。次に、管理部８２２は、通信部８２１を介して、アプリケーション８００の設定保存部８０４のイベント設定テーブル（表５）を参照する。そして、対象ファイルパスカラムの値と対象イベントカラムの値の組み合わせと一致する、フォルダパスとイベント種別カラムの値の組み合わせのレコードを検索し、取得する。

Ｓ１００７において、管理部８２２は、Ｓ１００６で受信したイベントに対応する非同期処理コードをアプリケーション８００から取得する。管理部８２２は、イベント設定レコードの非同期処理コードＩＤカラムの値が一致するレコードを保存部８０３の非同期処理コード管理テーブル（表３）から検索する。そして、管理部８２２は、ファイルデータカラムに格納された非同期処理コードのバイナリデータを取得する。なお、本実施例においては、ここでディスパッチコード８１１のバイナリデータが取得されるものとする。

Ｓ１００８において、管理部８２２は、Ｓ１００７で取得した非同期処理コード（ディスパッチコード８１１）を実行するための設定をアプリケーション８００から取得する。管理部８２２は、イベント設定レコードの実行環境ＩＤカラムの値が一致するレコードを、保存部８０３の実行環境設定テーブル（表４）から検索し、取得する。

Ｓ１００９において、管理部８２２は、Ｓ１００８で取得した実行環境設定レコードに基づく性能の実行環境８３０の仮想マシンを作成し、起動する。

Ｓ１０１０において、管理部８２２は、通信部８２１を介して実行環境８３０の記憶装置３０３にＳ１００７で取得した非同期処理コード（ディスパッチコード８１１）を配備する。

Ｓ１０１１において、実行部８２３は、通信部８２１を介して実行環境８３０の実行部８３２に非同期処理コード実行リクエストを送信する。非同期処理コード実行リクエストとして、実行部８３２に送信されるレコードの一例を、以下の非同期処理コード実行リクエストレコードに示す。

ファイルパスカラムには、非同期処理コードの処理対象であるファイルのファイルサーバー１０３上でのパスが格納される。格納されるパスは、具体的には、Ｓ１００５で受信したファイルアップロード完了イベントレコードのファイルパスカラムの値である。イベント設定ＩＤカラムには、アプリケーション８２０がＳ１００６で取得したイベント設定レコードのＩＤカラムの値が格納される。

Ｓ１０１２において、実行部８３２は非同期処理コード実行リクエストを受信するとＳ１０１０で受信したディスパッチコード８１１をＲＡＭ３０２に読み込み、非同期処理コードの実行を開始する。

ここで、図１１に、Ｓ１０１３からＳ１０１５で行われるディスパッチコード８１１の処理の実コードの一例を示す。図１１は、ディスパッチコード８１１を示す図であり、本コードは実行環境８３０の実行部８３２で実行される。

１行目は、ディスパッチを行う関数の開始を示す。２行目から１２行目では、本コードにおけるローカル変数定義を行う。また、９行目で、イベントの発生契機となったファイルサーバー１０３のファイルパスを変数に代入している。なお、本実施例においては、ファイルパスは、「ｌｏｇｄａｔａ／ｃｌｉｅｎｔ００２／２０１６０５．ｌｏｇ」となる。

１３行目では、９行目で定義したファイルパスに対応するファイルサーバー１０３のファイル情報の取得を行う。１４行目では、ディスパッチ先の非同期処理コード名を定義し、初期化する。

１５行目では、１３行目のファイルサーバー１０３からのファイル情報の取得に失敗したかどうかを判定する。１６行目は、１５行目の判定処理において、ファイルサーバー１０３からのファイル情報の取得に失敗したと判定された場合に行われる処理であり、エラーが発生した旨をコンソール表示する。

１７行目以降は、１５行目の判定処理において、ファイルサーバー１０３からのファイル情報の取得に成功したと判定された場合に行われる処理である。なお、本実施例においては、１５行目の判定処理において、ファイルサーバー１０３からのファイル情報の取得に成功したと判定されたものとする。よって、１７行目以降の処理が実行される。

１８行目では、１７行目で取得したファイル情報から、属性情報である関連非同期処理コード名を抽出する。なお、図１０のシーケンスにおいては、表９のデータが取得されるものとする。よって、関連非同期処理コード名は、「空」の値が取得される。１９行目では、１８行目で取得した関連非同期処理コード名が「空」であるかどうかを判定する。

２０行目は、１９行目の判定処理において、関連非同期処理コード名が「空」であると判定された場合に行われる処理である。ここでは、１４行目で定義したディスパッチ先の非同期処理コード名に、Ｂｌｕｅ環境コード８１２の非同期処理コード名である「ＢｌｕｅＰｒｏｃ」を代入する。なお、図１０のシーケンスにおいては、１９行目の判定処理において、関連非同期処理コード名が「空」である、つまり第１の条件を満たすと判定されたものとする。そのため、２０行目の処理が実行される。

２１行目から２３行目は、１９行目の判定処理において、関連非同期処理コード名が「空」でないと判定された場合に行われる処理であり、１４行目で定義したディスパッチ先の非同期処理コード名に、１８行目で取得した関連非同期処理コード名を代入する。なお、図１０のシーケンスにおいては、１９行目の判定処理において、関連非同期処理コード名が「空」であると判定されているため、２１行目から２３行目の処理は実行されない。

２４行目から２７行目は、ディスパッチ先の関連非同期処理コードを呼び出すための変数定義を行う。２８行目は、ディスパッチ先の関連非同期処理コードを呼び出す処理を行う。この際、呼び出す関連非同期処理コード名は、１４行目で定義した非同期処理コード名となる。図１０のシーケンスにおいては、２０行目で代入された、第１の処理システムに対応する第１のプログラムとして、Ｂｌｕｅ環境コード８１２の非同期処理コード名である「ＢｌｕｅＰｒｏｃ」が呼び出される。

２９行目は、２８行目のディスパッチ先の関連非同期処理コードの呼び出しに成功したかどうかを判定する。３０行目は、２９行目の判定処理において、ディスパッチ先の関連非同期処理コードの呼び出しに失敗したと判定された場合に行われる処理であり、エラーが発生した旨をコンソール表示する。

３１行目から３３行目は、９行目の判定処理において、ディスパッチ先の関連非同期処理コードの呼び出しに成功したと判定された場合に行われる処理であり、ディスパッチコード８１１の正常終了処理を行う。なお、本実施例においては、２９行目の判定処理において、ディスパッチ先の関連非同期処理コードの呼び出しに成功したと判定されたものとする。よって、３１行目から３３行目の処理が実行される。

３４行目は、２８行目の処理の終了記号を意味する。３５行目は、１３行目の処理の終了記号を意味する。３６行目は、１行目の処理の終了記号を意味する。

以上、図１１で示した処理コードによって、図１０のＳ１０１３からＳ１０１５の処理が完了し、ディスパッチコード８１１によるＢｌｕｅ環境コード８１２の適切なディスパッチが行われる。

ここで、図１０の説明に戻る。Ｓ１０１６において、管理部８２２は、Ｓ１０１５で取得したＢｌｕｅ環境コード８１２の呼び出しを受けて、Ｂｌｕｅ環境コード８１２をアプリケーション８００から取得する。Ｓ１０１７において、管理部８２２は、通信部８２１を介して実行環境８３０の記憶装置３０３にＳ１０１６で取得した非同期処理コード（Ｂｌｕｅ環境コード８１２）を配備する。

Ｓ１０１８において、実行部８２３は、通信部８２１を介して実行環境８３０の実行部８３２に、Ｂｌｕｅ環境コード８１２の実行リクエストを送信する。Ｓ１０１９において、実行部８３２はＢｌｕｅ環境コード８１２の実行リクエストを受信するとＳ１０１６で取得したＢｌｕｅ環境コード８１２をＲＡＭ３０２に読み込み、Ｂｌｕｅ環境コード８１２の実行を開始する。

以上、図１０のシーケンスによって、Ｂｌｕｅ環境における一連の処理が完了し、本番環境であるクライアント装置１０１からのリクエストを関連させて、Ｂｌｕｅ環境コード８１２を実行させることができる。

なお、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによる本番環境の切り替え後に、Ｓ１００７で管理部８２２がアプリケーション８００から、表３における「ＧｒｅｅｎＰｒｏｃ」を取得するように、管理部８０２は設定変更を行う。これにより、本番環境の切り替え後には、クライアント装置１０１からのデータ受信の際に、表３における「ＧｒｅｅｎＰｒｏｃ」が呼び出されることとなる。

また、本番環境に対応するＬａｍｂｄａ関数にエイリアスを設定しておき、他のアプリケーションは常にこのエイリアスを参照するようにしておいてもよい。ここで、エイリアスとは、イベントが発生した際に、予め指定したＬａｍｂｄａ関数のバージョンを呼び出すことのできるプログラムであり、現状のＡｍａｚｏｎＬａｍｂｄａで提供される機能の一つである。つまり、２０行目で示す関連非同期処理コード名が「空」であると判定された場合に行われる処理において、１４行目で定義したディスパッチ先の非同期処理コード名として、エイリアスを指定しておいても良い。すると、Ｂｌｕｅ−Ｇｒｅｅｎデプロイメントによる本番環境の切り替え後には、クライアント装置１０１からのデータ受信の際に、表３における「ＧｒｅｅｎＰｒｏｃ」が呼び出されることとなる。

図１２に、Ｇｒｅｅｎ環境における動作検証の処理の流れをシーケンス図で示す。図１２は、検証用クライアント装置１０２がファイル情報管理システムのＧｒｅｅｎ環境６１０に対して検証用ファイル情報を登録して、Ｇｒｅｅｎ環境コード８１３が実行されるまでの一連の処理を示したシーケンス図である。なお、図１２はあくまで動作検証のパターンの１つであり、当該シーケンスは動作検証が十分に行われたと判断される基準を満たすまで、繰り返し実行されてもよいものとする。

Ｓ１２０１において、検証用クライアント装置１０２は、通信部４１１を介してデータ登録のためのリクエストをファイル情報管理システム１０４のＧｒｅｅｎ環境６１０に送信する。なお、検証用クライアント装置１０２は、Ｇｒｅｅｎ環境６１０のロードバランサー６１１を示す宛先情報を保持しているために、ロードバランサー６１１にリクエストを送ることができる。ここでの登録対象となるデータは、検証情報管理部４１２がファイルとして出力した検証用ファイル情報などである。検証用ファイル情報登録リクエストとして、ファイル情報管理システム１０４のＧｒｅｅｎ環境６１０に送信されるレコードの一例を検証用ファイル情報登録リクエストレコードに示す。

なお、ファイル名カラム、アップロード先フォルダカラムは、表８と同様のため、説明は省略する。

次に、Ｓ１２０２において、ファイル情報管理システム１０４のＧｒｅｅｎ環境６１０のロードバランサー６１１は、検証用ファイル情報登録リクエストを受信し、仮想マシン６１２にリクエストに送信する。仮想マシン６１２で稼働するアプリケーション７００の通信部７０１は、ロードバランサー６１１からファイル情報登録リクエストを受信する。ファイル情報管理部７０２は、通信部７０１が受信したファイル情報登録リクエストをもとにファイル情報保存部７０３にファイル情報を登録する。ファイル情報管理部７０２は、ファイル情報の登録が成功すると、通信部７０１を介して、クライアント装置１０１に検証用ファイル情報登録成功を示すレスポンスを送信する。

Ｓ１２０３において、検証用クライアント装置１０２は、通信部４１１を介して検証情報管理部４１２がファイルとして出力した検証用ファイルを登録するファイルアップロードリクエストをファイルサーバー１０３に送信する。ファイルアップロードリクエストとしてファイルサーバー１０３に送信されるレコードの一例を、以下のファイルアップロードリクエストレコードに示す。

なお、ファイルデータカラム、アップロードパスカラム、関連非同期処理コード名カラムは、表９と同様のため、説明は省略する。なお、図１２のシーケンスでは、Ｇｒｅｅｎ環境の非同期処理コードであるＧｒｅｅｎ環境コード８１３を実行することを想定する。そのため、表１２の関連非同期処理コード名は、Ｇｒｅｅｎ環境コード８１３の非同期処理コード名である「ＧｒｅｅｎＰｒｏｃ」を指定している。

したがって、関連非同期処理コード名カラムに入っている「ＧｒｅｅｎＰｒｏｃ」の値、つまりＧｒｅｅｎ環境コード８１３を特定するための情報から、検証用クライアント装置１０２からのリクエストであることが判別可能となる。つまり、このリクエストに含まれる「ＧｒｅｅｎＰｒｏｃ」の値に基づき、本リクエストでの登録対象のデータが第２の条件を満たすと判定される。Ｓ１２０４からＳ１２１２は、図１０のＳ１００４からＳ１０１２と同様のため、説明は省略する。

Ｓ１２１３において、図１１の１３行目以降の処理である、ファイルサーバー１０３のファイル情報の取得が行われる。なお、図１１の１８行目の処理において抽出される関連非同期処理コード名は、表９で指定した「ＧｒｅｅｎＰｒｏｃ」の値となる。

Ｓ１２１４において、図１１の１９行目以降の処理である、ディスパッチコード８１１が呼び出す非同期処理コードの判定が行われる。なお、図１２のシーケンスにおいては、関連非同期処理コード名は「ＧｒｅｅｎＰｒｏｃ」のため、図１１の１９行目の処理において、関連非同期処理コード名は「空」でない、つまり第２の条件を満たすと判定される。そのため、図１１の２１行目から２３行目の処理が実行され、１４行目で定義したディスパッチ先の非同期処理コード名に、「ＧｒｅｅｎＰｒｏｃ」が代入される。

Ｓ１２１５において、図１１の２８行目以降の処理である、関連非同期処理コードの呼び出しが行われる。なお、図１２のシーケンスにおいては、第２の処理システムに対応する第２のプログラムとして、Ｇｒｅｅｎ環境コード８１３の非同期処理コード名である「ＧｒｅｅｎＰｒｏｃ」が呼び出される。Ｓ１２１６において、管理部８２２は、Ｓ１２１５で受信したＧｒｅｅｎ環境コード８１３の呼び出しを受けて、Ｇｒｅｅｎ環境コード８１３をアプリケーション８００から取得する。Ｓ１２１７において、管理部８２２は、通信部８２１を介して実行環境８３０の記憶装置３０３にＳ１２１６で取得した非同期処理コード（Ｇｒｅｅｎ環境コード８１３）を配備する。Ｓ１２１８において、実行部８２３は、通信部８２１を介して実行環境８３０の実行部８３２に、Ｇｒｅｅｎ環境コード８１３の実行リクエストを送信する。Ｓ１２１９において、実行部８３２はＧｒｅｅｎ環境コード８１３の実行リクエストを受信するとＳ１２１６で受信したＧｒｅｅｎ環境コード８１３をＲＡＭ３０２に読み込み、Ｇｒｅｅｎ環境コード８１３の実行を開始する。

以上、図１２のシーケンスによって、Ｇｒｅｅｎ環境における検証処理の１パターンが完了し、検証用クライアント装置１０２からのリクエストと関連させて、Ｇｒｅｅｎ環境コード８１３を実行させることができる。

図１０と図１２のシーケンスによって、本番環境であるＢｌｕｅ環境コード８１２を稼働させつつ、次バージョンであるＧｒｅｅｎ環境コード８１３を動作検証することができる。その後、Ｇｒｅｅｎ環境コード８１３の動作検証が完了した上で、Ｂｌｕｅ環境コード８１２をＧｒｅｅｎ環境コード８１３に置き換える。本実施例により、イベント駆動型コンピューティングサービスにおいて、Ｇｒｅｅｎ環境の十分な動作検証を行った上でＢｌｕｅ−Ｇｒｅｅｎ切り替えを実現することができる。

また、本実施例は、上述したように２つの処理システムのそれぞれに対応する２つのプログラムを呼び分ける場合だけでなく、１つの処理システムに対応する２つのプログラムを呼び分ける場合にも適用可能である。

（実施例２）
実施例１では、非同期処理コードのＢｌｕｅ−Ｇｒｅｅｎの呼び分けを実現するための方法として、検証用クライアント装置１０２が実行する非同期処理コード名をファイルサーバー１０３に送信する形態を説明した。そのため、実施例１においては、検証用クライアント装置１０２が、実行される非同期処理コード名を把握する必要がある。それに対して、本実施例では、クライアント側ではなくファイル情報管理システム１０４側で、実行する非同期処理コード名を管理する形態を説明する。

図１３は、本実施例における仮想マシン６０２、６１２で稼働するアプリケーション１３００のソフトウェア構成の一例を示す図である。

アプリケーション１３００は、仮想マシン６０２、６１２上に配置され、ＣＰＵ３０１によって実行される。アプリケーション１３００は、通信部７０１、ファイル情報管理部１３０１、バージョン情報管理部１３０２、ファイル情報保存部１３０３から構成される。

通信部７０１は、図７と同様のため、説明は省略する。ファイル情報管理部１３０１は、通信部７０１を介して、ロードバランサー６０１、６１１、ファイルサーバー１０３からのリクエストを受信し、さらにバージョン情報管理部１３０２からバージョン情報を取得する。ファイル情報管理部１３０１は、これらの情報をもとにファイル情報保存部１３０３にファイル情報の保存を要求する。

バージョン情報管理部１３０２は、アプリケーション１３００のバージョン情報を管理する。なお、本実施例においては、Ｂｌｕｅ環境６００の仮想マシン６０２に配置されたアプリケーション１３００のバージョンを「Ｖｅｒｓｉｏｎ．１」とする。そして、Ｇｒｅｅｎ環境６１０の仮想マシン６１２に配置されたアプリケーション１３００のバージョンを「Ｖｅｒｓｉｏｎ．２」とする。

ファイル情報保存部１３０３は、図７のファイル情報保存部７０３の処理に加えて、バージョン情報に紐づく非同期処理コード名を属性情報として保存する。ファイル情報保存部１３０３がファイルの属性情報を管理するデータの一例を、以下のファイル情報管理テーブルに示す。

ＩＤカラム、アップロードファイルパスカラム、ファイルサイズカラムに関しては、表２と同様のため、説明は省略する。関連非同期処理コード名カラムは、属性カラムであり、実行する非同期処理コード名が格納される。なお、本実施例においては、バージョン情報管理部１３０２が保存しているアプリケーション１３００のバージョンと対応した値を関連非同期処理コード名としているが、この値に関しては特に限定するものではない。

図１４は、本実施例におけるイベント情報管理サーバー１０５で稼働する各アプリケーションのソフトウェア構成の一例を示す図である。

アプリケーション１４００は、図８の非同期処理コード８１０と同様に、イベント情報管理サーバー１０５の記憶装置３０３に格納され、ＣＰＵ３０１によって実行される。本実施例においては、ディスパッチコード１４１１、Ｖｅｒｓｉｏｎ．１コード１４１２、Ｖｅｒｓｉｏｎ．２コード１４１３が格納されるものとする。

ディスパッチコード１４１１は、「ｌｏｇｄａｔａ」以下のフォルダにファイルが「追加」された場合に実行される非同期処理コード「Ｄｉｓｐａｔｃｈ」のバイナリデータである。

Ｖｅｒｓｉｏｎ．１コード１４１２は、Ｂｌｕｅ環境６００のアプリケーション１３００のバージョンである「Ｖｅｒｓｉｏｎ．１」に対応する非同期処理コードのバイナリデータである。Ｖｅｒｓｉｏｎ．２コード１４１３は、Ｇｒｅｅｎ環境６１０のアプリケーション１３００のバージョンである「Ｖｅｒｓｉｏｎ．２」に対応する非同期処理コードのバイナリデータである。その他の要素は、図８と同様のため、説明は省略する。

図１５は、検証用クライアント装置１０２がファイル情報管理システムのＧｒｅｅｎ環境６１０に対して、ファイル情報を登録してファイル情報管理システム１０４のＧｒｅｅｎ環境コード８１３が実行されるまでの処理を示したシーケンス図である。

Ｓ１５０１において、検証用クライアント装置１０２は、Ｓ１００１と同様の手順で、ファイル情報管理システム１０４のＧｒｅｅｎ環境６１０にファイル情報登録リクエストを送信する。なお、ここでのファイル情報登録リクエストは、表８と同様であるものとする。

Ｓ１５０２において、ファイル情報管理システム１０４のＧｒｅｅｎ環境６１０のロードバランサー６１１は、ファイル情報登録リクエストを受信し、仮想マシン６１２にリクエストに送信する。仮想マシン６１２で稼働するアプリケーション１３００の通信部７０１は、ロードバランサー６１１からファイル情報登録リクエストを受信する。ファイル情報管理部１３０１は、通信部７０１が受信したファイル情報登録リクエストと、バージョン情報管理部１３０２から取得した現在のバージョン情報と対応付けたファイル情報として、ファイル情報保存部１３０３で登録する。なお、図１５のシーケンスにおいて、登録されるファイル情報は、表１４の通りとする。Ｓ１５０３からＳ１５０９は、Ｓ１００３からＳ１００９と同様のため、説明は省略する。

Ｓ１５１０において、Ｓ１０１０と同様の手順で、非同期処理コードが実行環境８３０に配備される。なお、本実施例においては、ディスパッチコード１４１１が配備される。Ｓ１５１１において、Ｓ１０１１と同様の手順で、ディスパッチコード１４１１の実行リクエストが、実行環境８３０に送信される。Ｓ１５１２において、Ｓ１０１２と同様の手順で、ディスパッチコード１４１１の実行が開始される。

図１６に、Ｓ１５１３からＳ１５１５で行われるディスパッチコード１４１１の処理の実コードの一例を示す。図１６は、ディスパッチコード１４１１を示す図であり、本コードは実行環境８３０の実行部８３２で実行される。

１行目から６行目は、図１１の１行目から６行目と同様のため、説明は省略する。７行目は、図１１の１４行目と同様に、ディスパッチ先の非同期処理コード名を定義し、初期化する。

８行目から１１行目は、図１１の９行目から１２行目と同様のため、説明は省略する。１２行目は、ファイル情報管理システム１０４のＧｒｅｅｎ環境６１０から、ファイルサーバー１０３のアップロードファイルパスに対応するファイル情報を取得し、ファイル情報に含まれる関連非同期処理コード名を取得する。本実施例においては、「ｌｏｇｄａｔａ／ｃｌｉｅｎｔ／２０１６０５．ｌｏｇ」に対応する関連非同期処理コード名「Ｖｅｒｓｉｏｎ．２」が取得される。

１３行目は、１２行目で取得した関連非同期処理コード名が「空」であるかを判定する。１４行目は、１３行目の判定処理において、関連非同期処理コード名が「空」であると判定された場合に行われる処理であり、エラーが発生した旨をコンソール表示する。１５行目以降は、１３行目の判定処理において、関連非同期処理コード名が「空」でないと判定された場合に行われる処理である。なお、本実施例においては、関連非同期処理コード名は「Ｖｅｒｓｉｏｎ．２」のため、１３行目の判定処理において「空」でないと判定されたものとする。そのため、１５行目以降の処理が実行される。

１６行目は、７行目で定義したディスパッチ先の非同期処理コード名に、Ｖｅｒｓｉｏｎ．２コード１４１３の非同期処理コード名である「Ｖｅｒｓｉｏｎ．２」を代入する。

１７行目から２０行目は、２４行目から２７行目と同様のため、説明は省略する。２１行目は、図１１の２８行目と同様に、ディスパッチ先の関連非同期処理コードを呼び出す処理を行う。なお、図１５のシーケンスにおいては、Ｖｅｒｓｉｏｎ．２コード１４１３の非同期処理コード名である「Ｖｅｒｓｉｏｎ．２」が呼び出される。２２行目から２６行目は、図１１の２９目から３３行目と同様のため、説明は省略する。２７行目は、１３行目の処理の終了記号を意味する。２８行目は、１行目の処理の終了記号を意味する。

以上、図１６の処理によって、図１５のＳ１５１３からＳ１５１５の処理が完了し、ディスパッチコード１４１１によるＶｅｒｓｉｏｎ．２コード１４１３の適切なディスパッチが行われる。

ここで、図１５の説明に戻る。Ｓ１５１６において、管理部８２２は、Ｓ１５１５で取得したＶｅｒｓｉｏｎ．２コード１４１３の呼び出しを受けて、Ｖｅｒｓｉｏｎ．２コード１４１３をアプリケーション８００から取得する。

Ｓ１５１７において、管理部８２２は、通信部８２１を介して実行環境８３０の記憶装置３０３にＳ１０１６で取得した非同期処理コード（Ｖｅｒｓｉｏｎ．２コード１４１３）を配備する。Ｓ１５１８において、実行部８２３は、通信部８２１を介して実行環境８３０の実行部８３２に、Ｖｅｒｓｉｏｎ．２コード１４１３の実行リクエストを送信する。Ｓ１５１９において、実行部８３２はＶｅｒｓｉｏｎ．２コード１４１３の実行リクエストを受信するとＳ１５１６で取得しＶｅｒｓｉｏｎ．２コード１４１３をＲＡＭ３０２に読み込み、Ｖｅｒｓｉｏｎ．２コード１４１３の実行を開始する。

以上、図１０のシーケンスによって、Ｇｒｅｅｎ環境における一連の処理が完了し、検証用クライアント装置１０２による検証リクエストと関連させて、Ｖｅｒｓｉｏｎ．２コード１４１３を実行させることができる。本実施例により、検証用のクライアント装置でＧｒｅｅｎ環境コードを把握できない場合でも、次バージョンの非同期処理コードを動作検証することが可能となる。

（実施例３）
実施例１では、検証用クライアント装置１０２が、実施例２では、ファイル情報管理システム１０４が、それぞれ実行する非同期処理コード名を制御する形態を説明した。本実施例では、クライアント側による制御、サーバー側による制御のいずれのパターンでも動作検証を行えるような柔軟性を実現する形態を説明する。

図１７は、本実施例におけるイベント情報管理サーバー１０５で稼働する各アプリケーションのソフトウェア構成の一例を示す図である。

アプリケーション１５００は、図８の非同期処理コード８１０と同様に、イベント情報管理サーバー１０５の記憶装置３０３に格納され、ＣＰＵ３０１によって実行される。本実施例においては、ディスパッチコード１７１１、Ｂｌｕｅ環境コード８１２、Ｇｒｅｅｎ環境コード８１３、Ｖｅｒｓｉｏｎ．１コード１４１２、Ｖｅｒｓｉｏｎ．２コード１４１３が格納されるものとする。ディスパッチコード１７１１は、「ｌｏｇｄａｔａ」以下のフォルダにファイルが「追加」された場合に実行される非同期処理コード「Ｄｉｓｐａｔｃｈ」のバイナリデータである。その他の要素は、図８、図１４と同様のため、説明は省略する。

図１８は、本実施例におけるディスパッチコード１７１１を示す図であり、本コードは実行環境８３０の実行部８３２で実行される。

１行目から１８行目は、図１１の１行目から１８行目と同様のため、説明は省略する。１９行目は、図１１の１９行目と同様に、１８行目で取得したファイルサーバー１０３のファイル情報に含まれる関連非同期処理コード名が「空」であるかを判定する。この際、「空」であると判定された場合は、検証用クライアント装置１０２による非同期処理コードの制御が行われなかったケースであり、２０行目から２５行目の処理が実行される。一方、「空」でないと判定された場合は、検証用クライアント装置１０２による非同期処理コードの制御が行われたケースであり、２６行目から２８行目の処理が実行される。

２０行目は、図１６の１２行目と同様のため、説明は省略する。２１行目は、図１６の１３行目と同様に、２０行目で取得したファイル情報管理システム１０４のファイル情報に含まれる関連非同期処理コード名が「空」であるかを判定する。

２２行目は、２１行目の判定処理において、ファイル情報管理システム１０４のファイル情報に含まれる関連非同期処理コード名が「空」であると判定された場合に行われる処理である。この判定結果によって、検証用クライアント装置１０２、ファイル情報管理システム１０４のどちらの非同期処理コードの制御も行われていないと判定されたことになるため、本番環境の処理とみなされる。そのため、２２行目は、図１１の２０行目と同様に、関連非同期処理コードはＢｌｕｅ環境コード８１２の非同期処理コード名を指定する。

２３行目から２５行目は、２１行目の判定処理において、ファイル情報管理システム１０４のファイル情報に含まれる関連非同期処理コード名が「空」でないと判定された場合に行われる処理である。この判定結果によって、ファイル情報管理システム１０４が明示的に関連非同期処理コードを指定したとみなされる。そのため、２３行目から２５行目は、関連非同期処理コード名に、２０行目で取得した、ファイル情報管理システム１０４のファイル情報に含まれる非同期処理コード名を指定する。

２６行目から２８行目は、１９行目の判定処理において、ファイルサーバー１０３のファイル情報に含まれる関連非同期処理コード名が「空」でないと判定された場合に行われる処理である。この判定結果によって、検証用クライアント装置１０２が明示的に関連非同期処理コードを指定したとみなされる。そのため、２６行目から２８行目は、関連非同期処理コード名に、１８行目で取得した、ファイルサーバー１０３のファイル情報に含まれる非同期処理コード名を指定する。２９行目から、４１行目は、図１１の２４行目から３６行目と同様のため、説明は省略する。

以上、図１８のディスパッチコード１７１１の処理によって、検証用クライアント装置１０２、ファイル情報管理システム１０４それぞれが指定した非同期処理コード名を呼び出すことができる。本実施例により、それぞれが実行する非同期処理コード名を制御したとしても、適切に動作検証を行うことができる。

（他の実施例）
本発明は、上述した実施例を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施例の機能を実現する１つ以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施例を実現するための方法も本発明の１つである。また、そのプログラムは、ネットワークまたは各種記憶媒体を介してシステムあるいは装置に供給され、そのシステムあるいは装置の１つ以上のコンピューター（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の１つとして、さらにそのプログラム自体、あるいは当該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施例の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１０３ファイルサーバー
１０４ファイル情報管理システム
１０５イベント情報管理サーバー
８００、８２０アプリケーション
８３０実行環境

Claims

システムを構成するコンピューターによって、前記システムに含まれるストレージシステムの所定領域へのデータ登録に応じて発生するシステムイベントに従い実行されるプログラムであって、
前記システムイベントでの登録対象のデータが第１の条件および第２の条件のいずれを満たすかを判定する判定手段と、
前記第１の条件を満たすと前記判定手段が判定した場合に、第１の処理システムに対応する第１のプログラムの起動を行い、前記第２の条件を満たすと前記判定手段が判定した場合に、第２の処理システムに対応する第２のプログラムの起動を行う起動手段として前記コンピューターを機能させるためのプログラム。
前記判定手段は、前記システムイベントでの登録対象のデータの属性に基づき、該データが、前記第１の条件および前記第２の条件のいずれを満たすかを判定することを特徴とする請求項１に記載のプログラム。
前記システムに含まれる複数の処理システムのそれぞれは、
前記システムの外部にあるクライアント装置から、データ登録のためのリクエストを受信する受信手段と、
前記受信したリクエストでの登録対象のデータに関する情報と、当該処理システムの情報とを対応付けて保持する保持手段と、を有し、
前記判定手段は、前記受信手段がリクエストを受信した後、前記システムイベントが発生した際に、前記リクエストでの登録対象のデータに対応付けられて前記第１の処理システムの情報が前記保持手段で保持されている場合には、前記第１の条件を満たすと判定し、前記リクエストでの登録対象のデータに対応付けられて前記第２の処理システムの情報が前記保持手段で保持されている場合には、前記第２の条件を満たすと判定することを特徴とする請求項１に記載のプログラム。
前記第１のプログラムのバージョンは、前記第２のプログラムのバージョンと比較して古いことを特徴とする請求項１乃至３のいずれか１項に記載のプログラム。
前記起動手段は、前記登録対象のデータが前記第１の条件を満たすと前記判定手段が判定した場合、前記第１のプログラムとは異なる、前記システムに含まれるＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバーで保持されるレコードが示す処理システムに対応するプログラムを起動させるためのプログラムの起動を行うことを特徴とする請求項１乃至４のいずれか１項に記載のプログラム。
コンピューティングリソースを指定して予め登録されたプログラムをシステムイベントに応答して実行するサービスを提供するシステムであって、
システム内にあるストレージシステムの所定領域へのデータ登録に応じて発生するシステムイベントを検出する検出手段と、
前記システムに予め登録されたプログラムを実行する実行手段と、を有し、
前記実行手段は、前記検出手段が検出したシステムイベントに応じて、該システムイベントでの登録対象のデータが第１の条件および第２の条件のいずれを満たすかを判定する第３のプログラムを実行し、
前記実行手段は、前記第３のプログラムの実行により前記システムイベントでの登録対象のデータが前記第１の条件を満たすと判定された場合に、第１の処理システムに対応する第１のプログラムを更に実行し、前記第３のプログラムの実行により前記システムイベントでの登録対象のデータが前記第２の条件を満たすと判定された場合に、第２の処理システムに対応する第２のプログラムを更に実行することを特徴とするシステム。
前記第３のプログラムの実行により、前記システムイベントでの登録対象のデータの属性に基づき、該データが、前記第１の条件および前記第２の条件のいずれを満たすかが判定されることを特徴とする請求項６に記載のシステム。
前記システムに含まれる複数の処理システムのそれぞれは、
前記システムの外部にあるクライアント装置から、データ登録のためのリクエストを受信する受信手段と、
前記受信したリクエストでの登録対象となるデータに関する情報と、当該処理システムの情報とを対応付けて保持する保持手段と、を有し、
前記第３のプログラムの実行により、前記受信したリクエストでの登録対象のデータに対応付けられて前記第１の処理システムの情報が前記保持手段で保持されている場合には、前記第１の条件を満たすと判定され、前記受信したリクエストでの登録対象のデータに対応付けられて前記第２の処理システムの情報が前記保持手段で保持されている場合には、前記第２の条件を満たすと判定されることを特徴とする請求項６に記載のシステム。
前記第１のプログラムのバージョンは、前記第２のプログラムのバージョンと比較して古いことを特徴とする請求項６乃至８のいずれか１項に記載のシステム。
前記実行手段は、前記第３のプログラムの実行により前記登録対象のデータが前記第１の条件を満たすと判定された場合も、前記第１のプログラムとは異なる、前記システムに含まれるＤＮＳ（ＤｏｍａｉｎＮａｍｅＳｙｓｔｅｍ）サーバーで保持されるレコードが示す処理システムに対応するプログラムを実行するためのプログラムを更に実行することを特徴とする請求項６乃至９のいずれか１項に記載のシステム。
コンピューティングリソースを指定して予め登録されたプログラムをシステムイベントに応答して実行するサービスを提供するシステムの方法であって、
システム内にあるストレージシステムの所定領域へのデータ登録に応じて発生するシステムイベントを検出する検出工程と、
前記システムに予め登録されたプログラムを実行する実行工程と、を有し、
前記実行工程では、前記検出工程で検出されたシステムイベントに応じて、該システムイベントでの登録対象のデータが第１の条件および第２の条件のいずれを満たすかを判定する第３のプログラムが実行され、
前記実行工程では、前記第３のプログラムの実行により前記システムイベントでの登録対象のデータが前記第１の条件を満たすと判定された場合に、第１の処理システムに対応する第１のプログラムが更に実行され、前記第３のプログラムの実行により前記システムイベントでの登録対象のデータが前記第２の条件を満たすと判定された場合に、第２の処理システムに対応する第２のプログラムが更に実行されることを特徴とする方法。