JP6562744B2 - システム、及び制御方法 - Google Patents

Description

本発明は、スケジューラなどのモジュールが複数存在する場合のタスクの実行制御のための技術に関する。

従来から、コンピュータ上でデータ処理をする際に、スケジューラなどのモジュールがキューを用いて各データ処理に対応する複数のタスクを管理して、処理順などを制御するといった技術が存在する（例えば、特許文献１）。ここで、タスクとは、キューなどで管理される処理の単位で、ジョブとも呼ばれる場合がある。複数のスケジューラなどのタスク実行制御モジュールがタスクを共通のキューに登録し、タスクを順番に処理するといったシステムも存在する。

また、近年、インターネットなどのネットワーク上に、クラウドコンピューティングといわれる仮想化技術を応用した技術を用いてアプリケーションやサービスを提供するシステムが構築される場合がある。このようなシステムにおいて、アプリケーションやサービスを停止することなくバージョンアップなどを行う手法として、ブルー・グリーン・デプロイメントという技術が存在する。

ブルー・グリーン・デプロイメントでは、ブルー環境とグリーン環境と呼ばれる２つの実行環境を用意して、それぞれでアプリケーションやサービスを稼働させてシステムを構築する。ここで、バージョンアップのためにこの技術を用いる場合には、グリーン環境上でバージョンアップ後のアプリケーションやサービスを稼働させる。

ブルー環境に構築されたシステムは、現在、インターネット上で公開されており、システム外部からのリクエストは、ルータ或はＤＮＳなどを介して、ブルー環境に構築されたシステムに転送され、処理される。ブルー・グリーン・デプロイメントでは、ルータなどの設定を変更し、システム外部からのリクエストをグリーン環境上に構築されたシステムに転送させ、リクエストの処理／実行環境を切り替えることで、システムのバージョンアップを実現する。なお、バージョンアップ後であってもそれまで蓄積された処理結果やデータなどを利用できるように、それぞれの環境上のシステムは、データベースなどを共有するように構成される。

特開２００９−１７６１４６号公報

ここで、ブルー環境とグリーン環境のそれぞれに構築されたシステム内で前述のスケジューラが動作し、それら環境で共有するデータベース内を用いて、複数のタスクに係るデータ処理を実現している場合がある。ここで管理されるタスクとしては、システム外部からのリクエストに対応する処理を定義したタスクや、定期実行する必要がある処理を定義したタスクなどがある。

ここで、例えば、ブルー環境上のシステムで動作するスケジューラは、処理環境の切り替えを考慮せずに、グリーン環境と共通して利用するデータベースを用いてタスクを管理したとする。このような場合、前述したグリーン環境上のシステムで動作するスケジューラが、本来はブルー環境上のシステムで動作するスケジューラが扱うべきタスクをデータベースから取り出して、グリーン環境上のシステムで実行させてしまうといった課題が発生し得る。

そこで、複数環境上のそれぞれで動作する複数の実行制御モジュールが共有するデータベースで管理されるタスクの実行制御を行う場合に、各タスクを実行するモジュールが保証される手法を提供することを目的とする。

上述した課題を解決するために、データベースで管理されたタスク情報に対応するタスクが実行される複数の実行環境を構築できるシステムであって、稼働中の複数の実行環境のそれぞれで動作する手段であって、前記データベースで管理された該手段の識別情報に紐付くタスク情報の中から、所定の条件に合致するタスク情報に対応するタスクの実行を制御する実行制御手段を、有し、前記複数の実行環境のそれぞれで動作する複数の前記実行制御手段において、いずれか１つの実行制御手段には動作モードとして第１のモードが設定され、他の実行制御手段には動作モードとして前記第１のモードとは異なる第２のモードが設定され、前記第２のモードが設定された実行制御手段は、当該手段の識別情報に紐付いていないタスク情報に対応するタスクについては実行制御せず、前記第１のモードが設定された実行制御手段は、稼働中の前記複数の実行環境のそれぞれで動作する複数の実行制御手段の識別情報のいずれにも紐付かないタスク情報も前記データベースから取得して、当該取得されたタスク情報に対応するタスクの実行を制御することを特徴とする。

本発明に依れば、複数環境上のそれぞれで動作する複数の実行制御モジュールが共有するデータベースで管理されるタスクの実行制御を行う場合に、各タスクを実行するモジュールが保証されるようになる。

本発明に係るシステム全体の構成例を示す図。 情報処理装置のハードウェアの構成例を示すブロック図。 各環境１０３及び１０７の内部構成の例をより詳細に説明するための図。 仮想マシンの構成例を示す図。 タスク情報の内容の例を示す図。 スケジューラによるタスクの実行制御に係る処理を説明するためのフローチャート。 タスクの実行処理を説明するためのフローチャート。 切替制御部による環境の切替え処理を説明するためのフローチャート。 スケジューラの動作モードが決定される処理を説明するためのフローチャート。 スケジューラによるタスク情報の登録処理を説明するためのフローチャート。

以下、本発明を実施するための形態について図面を用いて説明する。
図１は、本発明に係るシステム全体の構成例を示す図である。

クライアント１０１は、システムの本番環境（ブルー環境１０３）により提供されるサービスを利用するユーザが利用する端末である。クライアント１０１は、ウェブブラウザなどを用いて、システム１００にアクセスし、リクエストを送信する。システム１００の外部には、該システムの提供するサービスを利用するクライアントが、クライアント１０１以外にも複数存在してもよい。そのような場合には、複数のクライアントは、それぞれ、システム１００に対してリクエストを送信する。

ルータ１０２は、クライアント１０１からのシステム１００に対するリクエストを受け付けて、該リクエストを適当な実行環境に転送する。現在、システム内では２つの実行環境が稼働中であり、ブルー環境１０３が本番環境として公開されているので、ルータ１０２は、クライアント１０１からのリクエストをブルー環境１０３に転送する。ここでは、ブルー環境１０３のようなシステム外部のクライアントにサービスを公開中の実行環境を本番環境と呼んでいる。一方で、システム外部のクライアント１０１などにサービスを公開していないグリーン環境１０７のことをテスト環境や予備環境などと呼ぶ場合がある。グリーン環境１０７は、システム外部のクライアント１０１などにサービスを公開していないが、内部の構成は通常動作しており、システム管理者などからはアクセスしてシステムを利用することも可能である。また、グリーン環境１０７は、複数用意しても良い。また、ブルー環境１０３、グリーン環境１０７などの各環境は、ユニークな環境識別子を属性情報として有している。この環境識別子は、各環境内に含まれるスケジューラなどの構成から参照可能である。

ブルー環境１０３は、ＷＥＢサーバ１０４、アプリケーションサーバ１０５、スケジューラ１０６により構成されている。ＷＥＢサーバ１０４、アプリケーションサーバ１０５はそれぞれ複数構築されてもよく、またそれらサーバは１以上のサーバコンピュータ上の仮想マシンで実現されるものとする。

ＷＥＢサーバ１０４は、クライアント１０１からのリクエストを受信し、必要に応じてアプリケーションサーバ１０５を呼び出し、クライアント１０１に該リクエストの処理結果を返信する。アプリケーションサーバ１０５は、ＷＥＢサーバ１０４やスケジューラからのリクエストを受信し、該リクエストに従う処理を実行し、呼び出し元に処理結果を返す。また、アプリケーションサーバ１０５は、リクエストの前後などに必要に応じてデータベース１１１内のデータを操作する。

スケジューラ１０６は、ＷＥＢサーバ１０４やアプリケーションサーバ１０５などからの所定のＷＥＢ ＡＰＩを介したリクエストとして、タスク情報を受信し、これをデータベース１１１に格納する。データベース１１１ではタスク情報テーブルによりタスク情報が管理される。スケジューラ１０６は、タスク情報テーブルを定期的に参照し、管理されたタスク情報のスケジュール情報に従って、タスク情報に対応するタスクを実行する。スケジューラ１０６は、例えば、アプリケーションサーバ１０５の機能を呼び出すことにより、タスクの実行を行う。

データベース１１１は、ブルー環境１０３とグリーン環境１０７の両方のシステム内のアプリケーションやサービス、スケジューラからアクセス可能となっている。

グリーン環境１０７の構成は基本的にはブルー環境１０３と同様の構成となる。差異としては、環境内で動作するアプリケーションやサービスなど（例えば、ＷＥＢサーバ１０８やアプリケーションサーバ１０９で動作するプログラム）のバージョンが異なる点などである。グリーン環境１０７においても、スケジューラ１０６と同様の機能をもつ、スケジューラ１１０が動作している。

切替制御部１１２は、クライアント１０１からのリクエストの処理環境を、ブルー環境１０３からグリーン環境１０７へと切り変える等の、環境を切り替える処理を実行する。この切り替えの実行タイミングは、システム１００の管理者による指示入力に従い実行されたり、事前に設定されたスケジュールに従い自動で実行されたりする。なお、グリーン環境１０７内の各構成は、運用テストなどを目的に、一定期間、ブルー環境１０３と並存して、動作する。このテストの期間は、スケジューラ１１０による内部的なタスクの実行制御が動作したり、管理者による手動でのリクエストがＷＥＢサーバ１０８やアプリケーションサーバ１０９で実行されたりすることになる。十分なテストが完了した場合に、上述のタイミングにより、切替制御部１１２による環境を切り替える処理が実行される。

図２は、仮想マシンが動作するサーバコンピュータなどを含む情報処理装置のハードウェア構成を示すブロック図である。同図において、情報処理装置は、ＣＰＵ５０１、ＲＡＭ５０２、ＲＯＭ５０３、外部記憶装置５０７を備える。ＣＰＵ５０１は、ＲＯＭ５０２や外部記憶装置５０７に記憶された、或いはネットワークよりダウンロードしたソフトウェアを実行し、システムバス５０９に接続された各デバイスを総括的に制御する。ＲＡＭ５０２は、ＣＰＵ５０１の主メモリあるいはワークエリアなどとして機能する。外部記憶装置５０７はハードディスク（ＨＤ）やソリッドステートドライブ（ＳＳＤ）等からなる。外部記憶装置５０７は、ブートプログラム、オペレーティングシステム、認証サーバ、認証クライアント等を含む各種のアプリケーション、データベースデータ、ユーザファイル等を記憶する。さらに情報処理装置において、５０４はキーボードコントローラ（ＫＢＤＣ）であり、キーボードやポインティングデバイスからの入力情報をＣＰＵ５０１に送る。５０５はビデオコントローラ（ＶＣ）であり、ＬＤＣ等からなる表示装置の表示を制御する。５０６はディスクコントローラ（ＤＣ）であり、外部記憶装置５０７とのアクセスを制御する。４０８はネットワークインターフェースコントローラ（ＮＩＣ：Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃｏｎｔｒｏｌｌｅｒ）であり、これを介してネットワークに接続される。図４で後述するような仮想マシン（ＶＭ）は、ハイパーバイザと呼ばれる仮想化ソフトウェアがエミュレートしている。

図３は、図１で前述した各環境１０３及び１０７の内部構成の例をより詳細に説明するための図である。図３では、３０１、３０２、３０３はＷＥＢサーバであり、同じウェブアプリケーションが動作している。３０４及び３０５はアプリケーションサーバであり、同じアプリケーションが動作している。

ロードバランサ（ＬＢ）３０６は、クライアント１０１からのリクエストをＷＥＢサーバ３０１〜３０３に振り分けることで負荷分散を行う構成である。また、ロードバランサ（ＬＢ）３０７は、ＷＥＢサーバ３０１〜３０３やスケジューラ１０６からのリクエストをアプリケーションサーバ３０４及び３０５の何れかに振り分けることで負荷分散を行う。ＷＥＢサーバやアプリサーバ、スケジューラは、仮想マシン（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）で実現される。

なお、本図におけるスケジューラは、スケジューラ１０６、スケジューラ１１０の何れかである。また、図１におけるＷＥＢサーバ１０４はＬＢ３０６とＷＥＢサーバ３０１、３０２、３０３に対応し、アプリケーションサーバ１０５はＬＢ３０７とアプリサーバ３０４、３０５に対応するものである。

図４は、仮想マシンを供給するサーバとコントローラの構成を示す図である。同図に於いて、４０１〜４０５は仮想サーバ、４０６は仮想サーバ全体を制御するコントローラである。これらのサーバ及びコントローラは、ネットワークを介して相互に接続されている。図では、仮想サーバの内部構造を４０１内部に示している。同構造は、４０１から４０５全ての仮想サーバに共通である。

仮想サーバ内には、複数の仮想マシン４０８、４０９、４１０が動作する。仮想マシンは、ホストコンピュータをエミュレートし、その中で、オペレーティングシステム４１２や、オペレーティングシステム上で動作するアプリケーション４１１が動作する。４１３は通信コントローラをエミュレートする仮想ＮＩＣであり、仮想スイッチ４０７及びＮＩＣ４０８を介して、ネットワーク４０７や仮想スイッチ４０７に接続された他の仮想ＮＩＣとデータの送受信を行う。仮想スイッチ４０７は、スイッチング・ハブをエミュレートするソフトウェアであり、仮想マシン内の仮想ＮＩＣや仮想サーバ４０１内のＮＩＣ４０８との通信を制御する。仮想サーバ上で仮想マシンを実現するソフトウェアをハイパーバイザと呼ぶ。コントローラ４０６は、仮想サーバ内の仮想マシンや仮想スイッチの設定を管理する。例えば、コントローラ４０６は、負荷に応じてＷＥＢサーバやアプリケーションサーバの数を増減する。また、コントローラ４０６は仮想マシン４０８内で動作するアプリケーション４１２を監視し、アプリケーション４１２の故障を検知すると、仮想マシン４０８の停止し起動する。

［本発明におけるタスク情報の説明］
スケジューラ１０６は、タスク情報をデータベース１１１内に格納し、タスク情報に従うタスクの実行を制御する。ＷＥＢサーバ１０４やアプリケーションサーバ１０５は、ＷＥＢ ＡＰＩを介して、スケジューラ１０６に対してタスクの登録や変更を指示できる。

ここで、表１は、データベース１１１に格納され、管理されるタスク情報の内容（フォーマット）を示している。

「スケジューラＩＤ」は、スケジューラの起動時にＵＵＩＤ等からそれぞれが生成したスケジューラのそれぞれのインスタンスを一意に識別する識別情報（文字列）を示す。異なるスケジューラのインスタンスは、異なるスケジューラＩＤを持つ。例えば、スケジューラ１０６は、タスク情報の追加時及びタスク情報の変更時に、自身のスケジューラＩＤをここに設定する。

「タスク名」は、データベース１１１に格納されたタスク情報を一意に識別するための文字列であり、タスク情報の登録元から指定される。

「実行予定日時」は、本タスク情報に従うタスクを実行すべきスケジュール情報を示す。年月日時などを用いて指定される。ここで、タスク情報が繰り返しタスクを示す場合には、「実行予定日時」はタスクの登録時及び実行時に後述の繰り返し設定から計算される。繰り返しタスクでない場合には、タスク情報の登録元から指定される。

「繰り返し設定」は、タスクを繰り返し実行する場合の繰り返し設定を、ＪＳＯＮ形式で表現したものであり、タスク情報の登録元から指定される。この項目には、繰り返す期間の終端を示す終了日時も併せて指定されている場合がある。なお、「繰り返し設定」が空の場合は、「実行予定日時」に指定されたスケジュールで、１回位だけ実行されるタスクである。

図５（ａ）は、表１の「繰り返し設定」の一例を示す。これは、東京時間の２０１５年２月４日から２０２０年２月３日まで、毎年、東京時間で３月と６月と９月と１２月の月曜日から金曜日の０時１５分、０時４５分、１２時１５分、１２時４５分にタスクを実行することを意味する。

図５（ｂ）は、表１の「繰り返し設定」の別の例を示す。これは、東京時間の２０１５年２月４日８時１２分から、３分毎にタスクを呼び出すことを意味する。スケジューラ１０６は、タスク情報にこのような繰り返し設定の指定がある場合、後述の図１０などでタスク情報をデータベースに登録する際などに、現在時刻以降で最も近い実行予定日時を計算し、タスクの「実行予定日時」に設定する。

「タスクの種別」は、タスクの実行方式である。例えば、スケジューラは、以下の２種類のタスクの実行方法を提供する。
１．“メッセージキュー（ＭＱ）”：メッセージキューにタスクに対応するメッセージを送信することにより、メッセージキューからメッセージを受信するアプリケーションサーバ１０５、１０９にタスクの実行を指示する。
２．“ＷＥＢ ＡＰＩ呼び出し（ＨＴＴＰ）”：アプリケーションサーバ１０５、１０９が提供するＷＥＢ ＡＰＩの呼び出しにより、アプリケーションサーバ１０５、１０９にタスクの実行を指示する。

「詳細」は、スケジューラがアプリケーションサーバにタスクの実行を指示する際の詳細設定をＪＳＯＮ形式で表現したものである。スケジューラは、「タスクの種別」と「詳細」を利用して、アプリケーションサーバに対してタスクの実行を指示する。

図５（ｃ）は、タスク種別がメッセージキューの場合の、表１の「詳細」の一例を示す。

「ａｇｇｒｅｇａｔｅ」というメッセージキューに「１５９ｄ２７７８−６ａｄｃ−４２ａｆ−ｂ４９３−６７５ｂ２８２ａ７ｅ９５」というメッセージを送信することを意味する。例えば、アプリサーバ１０３は、メッセージキュー「ａｇｇｒｅｇａｔｅ」からメッセージを定期的に取り出し、メッセージに記載されたＩＤ、即ち「１５９ｄ２７７８−６ａｄｃ−４２ａｆ−ｂ４９３−６７５ｂ２８２ａ７ｅ９５」を持つユーザに関する集計を実施し、その集計結果をデータベースに格納する、といった処理を行う。

図５（ｄ）は、タスク種別がＷＥＢ ＡＰＩ呼び出しの場合の「詳細」の一例を示す。

“ｔａｒｇｅｔ”は、ＷＥＢ ＡＰＩの呼び出し先のアドレス（スキーマ、ホスト、ポート）を各環境（１０３、１０７）から取得する際に用いる名前である。アプリケーションサーバのアドレスは各環境で異なるため、スケジューラはアプリサーバのアドレスを各環境から取得する。

“ｐａｔｈ”は、ＷＥＢ ＡＰＩ呼び出しのＵＲＬのパスである。例えば、“ｔａｒｇｅｔ”を指定して各環境から得られるアドレスが「ｈｔｔｐ：／／１９２．１６８．１１．３０：８０８０」の場合、上記ＷＥＢ ＡＰＩを呼び出すためのＵＲＬは、「ｈｔｔｐ：／／１９２．１６８．１１．３０：８０８０／ｓｅｎｄ」となる。この例は、このＵＲＬに対し、「ｊｐ」というデータを平文でＰＯＳＴすることを意味している。例えば、上記リクエストを受信したアプリサーバ１０３は、地域が「ｊｐ」である顧客に対して、送信待ちになっているメール送信を行う、といった処理を行う。

図６を用いて、スケジューラ１０６または１１０によるタスクの実行制御のための処理を説明する。

図６（ａ）は、スケジューラ１０６または１１０によるタスク起動処理の呼び出し処理を説明するためのフローチャートである。本処理により、タスク起動処理は周期的に呼び出され、実行されることになる。また、本処理では、スケジューラ１０６または１１０は複数の条件のそれぞれに合致するタスク情報をデータベース１１１から取得して実行制御することになる。

Ｓ６０１で、スケジューラ１０６または１１０は、所定期間（例えば、１分）が経過したかを判定する。経過した場合にはＳ６０２に進み、タスク起動処理を呼び出す。

図６（ｂ）は、スケジューラ１０６または１１０によるタスク起動処理を説明するためのフローチャートである。本処理は、前述した通り、Ｓ６０２で呼び出される。

まず、Ｓ６０３にて、スケジューラ１０６または１１０は、データベース１１１のタスク情報テーブルから、自身のスケジューラＩＤが設定されているタスク情報を参照する。そして、そのタスク情報の中から、１つ目の条件として、現在日時より以前のスケジュール情報（年月日時）が項目「実行予定日時」に指定されたタスク情報を特定して、データベース１１１から取得する。複数のタスク情報がタスク情報テーブルから取得される場合がある。

Ｓ６０４にて、スケジューラ１０６または１１０により、Ｓ６０３で取得されたタスク情報に対応するタスクの実行処理が行われる。タスク情報が複数取得されていた場合には、複数のタスクのそれぞれについて実行処理が行われることになる。タスク実行処理の詳細は、図７で後述する。

Ｓ６０５にて、スケジューラ１０６または１１０は、現在の自身のモードを確認する。スケジューラの動作モードは、“主”モードあるいは“副”モードのいずれかを示す値を取る。本番環境におけるスケジューラの動作モードは“主”モードを示す。テスト環境または予備環境におけるスケジューラの動作モードは“副”モードを示す。Ｓ６０５において現在の動作モードが“主”モードを示さない場合には本処理が終了し、現在の動作モードが“主”モードを示す場合にはＳ６０６に進む。

Ｓ６０６にて、スケジューラ１０６または１１０は、２つ目の条件として、現在日時より所定時間（例えば、３分）前の日時以前のスケジュール情報が項目「実行予定日時」に指定されたタスク情報を特定して、データベース１１１から取得する。Ｓ６０７にて、スケジューラ１０６または１１０により、Ｓ６０６で取得されたタスク情報に対応するタスクの実行処理が行われる。その後、本処理を終了する。

尚、上述のＳ６０１の所定期間をＸ分、Ｓ６０６の所定時間をＹ分とすると、以下のような関係が成り立つように、任意にＸとＹの値を指定することが可能である。ここで、図６（ａ）の呼び出し処理を実行してタスク起動処理（図６（ｂ））が開始されるまでに必要となると予想される最大時間をαとする。
（関係式）：Ｙ＞（２×Ｘ）＋α
例えば、ブルー環境１０３が本番環境であった場合には、スケジューラ１０６がＳ６０６の処理を実行することになる。この際に、現在日時から所定時間Ｙ分前の日時の間には、上述の関係式により“副”モードで動作しているスケジューラ１１０がＳ６０３〜Ｓ６０４を実行していることが保証される。

従って、Ｓ６０６で取得されるタスク情報は、スケジューラ１０６、１１０のいずれのスケジューラＩＤとも異なる識別情報が「スケジューラＩＤ」に設定されたタスク情報となる。また、ケジューラ１０６はスケジューラ１１０が処理すべきタスク情報を間違って取得することもない。

このようなタスク情報が取得されるケースは、図１で示したブルー環境１０３、グリーン環境１０７とは異なる過去に利用されていた環境（不図示）がデータベース１１１に登録したタスク情報を示す。本発明が利用するブルー・グリーン・デプロイメントといった技術により、環境の切り替えを繰り返した場合には、過去に利用されていた環境の動作が停止してしまったスケジューラにより登録されたタスク情報が、データベース１１１に処理されずに残ってしまう場合がある。このようなタスク情報に関しても、システム１００内で実行すべきであるので、停止してしまったスケジューラに代わり、本実施例では現在本番環境のスケジューラ１０６が、それに対応するタスクの実行制御を行うものとしている。

図７は、図６のＳ６０４およびＳ６０７での、スケジューラ１０６または１１０によるタスクの実行処理の詳細を説明するためのフローチャートである。

Ｓ７０２にて、スケジューラ１０６または１１０は、タスク情報のタスク種別を判別する。タスク種別がメッセージキュー（ＭＱ）を示す場合、Ｓ７０３にて、スケジューラ１０６または１１０は、タスク情報の項目「詳細」などで指定内容に従い、メッセージキューにメッセージを登録する。一方で、タスク種別がＷＥＢ ＡＰＩ呼び出し（ＨＴＴＰ）を示す場合、Ｓ７０４にて、スケジューラ１０６または１１０は、タスク情報の項目「詳細」などで指定内容に従い、指定されたメソッド、及び本文を含むパケットを作成し、指定ＵＲＬに対して送信する。Ｓ７０３及びＳ７０４の処理によって、アプリケーションサーバなどでで、タスクが実行されることになる。

Ｓ７０５にて、スケジューラ１０６または１１０は、タスク情報の項目「繰り返し設定」に指定があるか否かを判断する。「繰り返し設定」に指定がない場合にはＳ７０６に進み、「繰り返し設定」に指定がある場合にはＳ７０７に進む。

Ｓ７０６にて、スケジューラ１０６または１１０は、データベース１１１内の処理対象であるタスク情報を無効にして、本処理を終了する。ここで、タスク情報を無効にするとは、例えば、データベース１１１から該タスク情報を削除する、或は、タスク情報の項目「実行予定日時」に対して“９９９９年”などといった実行されないと想定されるようなスケジュール情報を設定する。これにより、無効になったタスク情報は、前述したＳ６０３及びＳ６０６などでは取得されなくなる。

Ｓ７０７にて、スケジューラ１０６または１１０は、タスク情報の項目「繰り返し設定」の指定内容から、次回の実行タイミング（年月日時）を計算する。次に、Ｓ７０８にて、スケジューラ１０６または１１０は、タスク情報の項目「繰り返し設定」で終了日時が指定されている場合に、Ｓ７０７で計算された次回の実行タイミングと、該終了日時とを比較する。Ｓ７０８での比較の結果、次回の実行タイミングが終了日時以後となっている場合にはＳ７０６に進み、そうでない場合にはＳ７０９に進む。なお、終了日時が設定されていない場合には、本ステップを省略して、Ｓ７０９に進む。

Ｓ７０９にて、スケジューラ１０６または１１０は、自身のスケジューラＩＤとＳ７０７で計算された次回の実行タイミングとを用いて、データベース１１１に格納されている処理対象のタスク情報の「スケジューラＩＤ」及び「実行予定日時」で指定される情報を更新する。

表２は、データベース１１１に格納され、管理されているタスク情報テーブルの具体例である。なお、タスク情報テーブルで管理される内容は、この例に含まれる内容以外の情報が含まれてもよい。

上述のタスク情報テーブルには、少なくとも、３つの異なるスケジューラのインスタンス（「スケジューラＩＤ」が、“５５０ｅ８４００”、“８７６１ｄ９１ａ”、“６１９ｃ８２ｂ９”）に紐付けられたタスク情報が登録されている。また、「タスク名」“ｃｈｅｃｋ”のタスク情報は、「繰り返し設定」が指定されていない。

例えば、ブルー環境１０３のスケジューラ１０６が毎分００秒に図６（ｂ）に示すタスク起動処理を呼び出し、グリーン環境１０７のスケジューラ１１０が毎分３０秒に図６（ｂ）で示すタスク起動処理を呼び出すとする。また、スケジューラ１０６とスケジューラ１１０の「スケジューラＩＤ」はそれぞれ、“５５０ｅ８４００”と、“６１９ｃ８２ｂ９”であるとする。一方、「スケジューラＩＤ」が“８７６１ｄ９１ａ”は、ブルー環境１０３、グリーン環境１０７のいずれでもない旧環境のスケジューラの識別情報を示すものである。該スケジューラは現在動作していないものとする。

ここで、上述のタスク情報テーブルに含まれるタスク情報に従い行われるタスクの実行制御について、具体的に説明する。

現在時刻が２０１５年５月１２日１２時２３分３０秒になると、スケジューラ１１０は、図６（ｂ）のＳ６０３にて、「タスク名」が“ｃｈｅｃｋ”のタスク情報を取得することになり、Ｓ６０４でこのタスク情報に対応するタスクを実行する。スケジューラ１１０は、動作モードが“副”モードを示すため、図６（ｂ）で示す処理をこれで終了する。「タスク名」が“ｃｈｅｃｋ”のタスク情報は、図７のＳ７０６で無効になる。

次に、現在時刻が１２時２４分００秒になると、スケジューラ１０６は、図６（ｂ）のＳ６０３にて、「タスク名」が“ｓｅｎｄｍａｉｌ”のタスク情報を取得することになり、Ｓ６０４でこのタスク情報に対応するタスクを実行する。スケジューラ１０６が、「タスク名」が“ｓｅｎｄｍａｉｌ”のタスク情報に対応するタスクを実行した際には、上述のタスク情報テーブルの対象となるタスク情報について、図７のＳ７０９で「実行予定日時」のみが更新されることになる。

スケジューラ１０６は、動作モードが“主”モードを示すため、次にＳ６０６で更なるタスク情報の取得処理を行う。ここでは、「実行予定日時」が２０１５年５月１２日１２時２１分００秒（現在時刻より３分前）より以前に設定されている「タスク名」が“ａｇｇｒｅｇａｔｅ”であるタスク情報を取得する。スケジューラ１０６は、Ｓ６０７で、ここで取得された「スケジューラＩＤ」が“８７６１ｄ９１ａ”に紐づけられた「タスク名」が“ａｇｇｒｅｇａｔｅ”であるタスク情報に対応するタスクを実行する。スケジューラ１０６が、「タスク名」が“ａｇｇｒｅｇａｔｅ”であるタスク情報に対応するタスクを実行した際には、上述のタスク情報テーブルの対象となるタスク情報について、図７のＳ７０９で「実行予定日時」と「スケジューラＩＤ」とが更新される。とくに、「スケジューラＩＤ」については、スケジューラ１０６を示す識別情報“５５０ｅ８４００”に更新される。

この「スケジューラＩＤ」で示す情報の更新により、スケジューラ１０６は、「タスク名」が“ａｇｇｒｅｇａｔｅ”であるタスク情報に対応するタスクを、次回からはＳ６０４のタイミングで実行できるようになる。

図８は、切替制御部１１２による環境の切替え処理を説明するためのフローチャートである。本処理では、ブルー環境１０３からグリーン環境１０７へと本番環境を切り替える処理について詳しく説明する。なお、本処理はシステム１００の管理者による指示入力や、事前に設定されたスケジュールに従い開始されるものである。

Ｓ８０１にて、切替制御部１１２は、本番環境としてサービスをシステム外部のクライアント１０１に公開しているブルー環境１０３内のスケジューラ１０６を停止する。具体的には、各環境のスケジューラは、処理停止のためのＷＥＢ ＡＰＩを提供しており、切替制御部１１２はスケジューラ１０６のこのＡＰＩを呼び出す。スケジューラ停止処理後は、図６で示した周期的に実行される処理などが全て停止する。

Ｓ８０２にて、切替制御部１１２は、本番環境をグリーン環境１０７に切り替えるため、ルータ１０２の設定を変更する。Ｓ８０３にて、切替制御部１１２は、グリーン環境１０７内のスケジューラ１１０の動作モードを“主”に変更する。具体的には、各環境のスケジューラは、動作モードを変更するためのＷＥＢ ＡＰＩを提供しており、切替制御部１１２はスケジューラ１１０のこのＡＰＩを呼び出し、動作モードを変更する。

図９を用いて、スケジューラの動作モードが決定される処理を説明する。

図９（ａ）は、スケジューラの動作モードの設定処理を説明するためのフローチャートである。本処理は、図８のＳ８０３にて呼び出され、実行される。なお、ブルー環境１０３やグリーン環境１０７等の環境は、それぞれの環境を一意に識別する環境識別子を持ち、環境内で動作するプログラムは前記環境識別子を取得することが可能である。

Ｓ９０１にて、スケジューラ１０６または１１０は、自身の動作モードを指定されたモードに変更する。次に、Ｓ９０２にて、スケジューラ１０６または１１０は、変更後の動作モードが“主”モードであるか否かを判定する。ここで、“主”モードだった場合にはＳ９０３に進み、“主”モードでない場合には本処理を終了する。

Ｓ９０３にて、スケジューラ１０６または１１０は、自身が動作している環境を示す環境識別子を取得して、データベース１１１に書き込んだ後に、本処理を終了する。Ｓ９０３の処理により、現在の本番環境の環境識別子が、データベース１１１で管理されることになる。

図９（ｂ）は、スケジューラの動作モードの設定処理を説明するためのフローチャートである。この処理は、スケジューラの起動時に実行される。

Ｓ９０５にて、スケジューラ１０６または１１０は、データベース１１１から、環境識別子を取得する。これは、前述のＳ９０３で、動作モードが“主”モードであるスケジューラにより、データベース１１１に対して書き込まれた値である。

Ｓ９０６で、スケジューラ１０６または１１０は、自身が動作している環境の環境識別子と、Ｓ９０５で取得した環境識別子とを比較する。比較の結果、両者が一致する場合にはＳ９０７に進み、一致しない場合にはＳ９０８に進む。

Ｓ９０７で、スケジューラ１０６または１１０は、自身の動作モードを“主”に設定する。また、Ｓ９０８で、スケジューラ１０６または１１０は、自身の動作モードを“副”に設定する。

本処理に依れば、例えば、動作モードが“主”モードで稼働していたスケジューラ１０６が、何らかの理由で停止した後に再起動した場合には、再起動後のスケジューラ１０６の動作モードは“主”モードに設定される。なお、本発明が想定しているシステム１００など仮想環境を利用したＷＥＢアプリケーションやサービスの提供では、各仮想マシン内のアプリケーションの稼働状況を監視している。アプリケーションの動作に問題が見つかった場合、監視処理は、アプリケーションが動作する仮想マシンを破棄し、アプリケーションを含む仮想マシンを新規に作成することによりアプリケーションを再配置する。この際、スケジューラ１０６を識別するスケジューラＩＤは再起動前のものと異なる。

図１０は、スケジューラ１０６または１１０が、データベース１１１にタスクを登録する処理の流れを示すフローチャートである。

Ｓ１００１にて、スケジューラ１０６または１１０は、タスク情報の登録のためのリクエストを受付けて、当該リクエストの中から登録対象となるタスク情報を取り出す。リクエストはＷＥＢ ＡＰＩなどを経由して受け付ける。取り出されるタスク情報の内容は、タスクを一意に識別するためのタスク名、実行予定日時、繰り返し設定、タスク種別、詳細といった各項目に対する情報が含まれる。ここで、タスクが繰り返しタスクでない場合には項目「繰り返し設定」に対する情報は空である。また、タスクが繰り返しタスクの場合には項目「実行予定日時」に対する情報は空である。

Ｓ１００２にて、スケジューラ１０６または１１０は、Ｓ１００１で取り出されたタスク情報の項目「タスク名」で指定される情報を持つタスク情報が、データベース１１１に既に存在する（登録済み）か、を検査する。検査の結果、データベース１１１に未登録の場合にはＳ１００３に進み、データベース１１１に登録済み場合にはタスク情報を登録せずに本処理を終了する。

Ｓ１００３にて、スケジューラ１０６または１１０は、Ｓ１００１で取り出されたタスク情報の項目「繰り返し設定」で繰り返し設定が指定されているか否かを判定する。繰り返し設定のある繰り返しタスクであった場合にはＳ１００４に進み、繰り返し設定のないタスクであった場合にはＳ１００５に進む。

Ｓ１００４にて、スケジューラ１０６または１１０は、Ｓ１００１で取り出されたタスク情報の項目「繰り返し設定」の指定内容から、次回の実行タイミング（年月日時）を計算する。その後、該タスク情報の項目「実行予定日時」に、計算結果である次回の実行タイミングを示すスケジュール情報を設定する。

Ｓ１００５にて、スケジューラ１０６または１１０は、自身を識別するための識別情報を「スケジューラＩＤ」として設定したうえで、タスク情報をデータベース１１１に格納して、本処理を終了する。データベース１１１に格納されたタスク情報は、前述したタスク情報テーブルで管理されることになる。

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

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

１００ システム
１０３ ブルー環境
１０６、１１０ スケジューラ
１０７ グリーン環境
１１１ データベース
１１２ 切替制御部

Claims (10)

1. データベースで管理されたタスク情報に対応するタスクが実行される複数の実行環境を構築できるシステムであって、
   稼働中の複数の実行環境のそれぞれで動作する手段であって、前記データベースで管理された該手段の識別情報に紐付くタスク情報の中から、所定の条件に合致するタスク情報に対応するタスクの実行を制御する実行制御手段を、有し、
   前記複数の実行環境のそれぞれで動作する複数の前記実行制御手段において、いずれか１つの実行制御手段には動作モードとして第１のモードが設定され、他の実行制御手段には動作モードとして前記第１のモードとは異なる第２のモードが設定され、
   前記第２のモードが設定された実行制御手段は、当該手段の識別情報に紐付いていないタスク情報に対応するタスクについては実行制御せず、
   前記第１のモードが設定された実行制御手段は、稼働中の前記複数の実行環境のそれぞれで動作する複数の実行制御手段の識別情報のいずれにも紐付かないタスク情報も前記データベースから取得して、当該取得されたタスク情報に対応するタスクの実行を制御することを特徴とするシステム。
2. 前記第１のモードが設定された実行制御手段は、該手段が動作する実行環境を示す環境識別子を前記データベースに格納することを特徴とする請求項１に記載のシステム。
3. 前記データベースに格納された環境識別子で示される実行環境で実行制御手段が起動された場合に、当該起動された実行制御手段に動作モードとして前記第１のモードが設定され、
   前記データベースに格納された環境識別子で示される実行環境とは異なる実行環境で実行制御手段が起動された場合に、当該起動された実行制御手段に動作モードとして前記第２のモードが設定されることを特徴とする請求項２に記載のシステム。
4. 前記複数の実行環境のそれぞれで動作する前記実行制御手段は、タスク情報の登録ためのリクエストがあった場合には、該手段の識別情報を前記リクエストに含まれるタスク情報に紐付けて前記データベースに登録することを特徴とする請求項１乃至３のいずれか１項に記載のシステム。
5. 前記複数の実行環境のそれぞれで動作する前記実行制御手段は、前記リクエストに含まれるタスク情報に繰り返し設定があった場合には、該タスク情報に対応するタスクの次回の実行タイミングを設定した上で、該タスク情報を前記データベースに登録することを特徴とする請求項４に記載のシステム。
6. 前記第２のモードが設定された実行制御手段の動作モードが前記第１のモードに変更される実行環境の切替え処理が行われた場合に、切替え前に前記第１のモードが設定されていた実行制御手段によるタスクの実行の制御が停止されることを特徴とする請求項１乃至５のいずれか１項に記載のシステム。
7. 前記第１のモードが設定された実行制御手段は、稼働中の前記複数の実行環境のそれぞれで動作する複数の実行制御手段の識別情報のいずれにも紐付かないタスク情報を前記データベースから取得して、当該取得されたタスク情報に対応するタスクの実行を制御した際には、該タスク情報に自身の識別情報を紐付けて、前記データベースに登録することを特徴とする請求項１乃至６のいずれか１項に記載のシステム。
8. 前記タスク情報には、タスク種別を示す情報が含まれ、
   該情報に従う実行方式によって前記タスク情報に対応するタスクが実行されることを特徴とする請求項１乃至７のいずれか１項に記載のシステム。
9. 前記第１のモードが設定された実行制御手段が動作する実行環境は、前記システムの外部のクライアントに対してサービスを公開していることを特徴とする請求項１乃至８の何れか１項に記載のシステム。
10. データベースで管理されたタスク情報に対応するタスクが実行される複数の実行環境を構築できるシステムにおける制御方法であって、
    稼働中の複数の実行環境のそれぞれで動作する実行制御手段が、前記データベースで管理された該手段の識別情報に紐付くタスク情報の中から、所定の条件に合致するタスク情報に対応するタスクの実行を制御する制御工程を、有し、
    前記複数の実行環境のそれぞれで動作する複数の前記実行制御手段において、いずれか１つの実行制御手段には動作モードとして第１のモードが設定され、他の実行制御手段には動作モードとして前記第１のモードとは異なる第２のモードが設定され、
    前記第２のモードが設定された実行制御手段は、当該手段の識別情報に紐付いていないタスク情報に対応するタスクについては実行制御せず、
    前記第１のモードが設定された実行制御手段により、稼働中の前記複数の実行環境のそれぞれで動作する複数の実行制御手段の識別情報のいずれにも紐付かないタスク情報も前記データベースから取得され、当該取得されたタスク情報に対応するタスクの実行が制御されることを特徴とする制御方法。

Images