(57)【要約】【課題】ストリームイベントをトリガーとするイベント駆動型コンピューティングサービスにおいて、イベントの処理で例外またはタイムアウトが繰り返し発生すると、ストリームからイベントが削除される時間までリトライし続け、その間処理が詰まってしまう。【解決手段】ストリームイベントの発生に応じて行われるプログラムコードの実行が例外あるいはタイムアウトが発生したことにより正常に終了しなかった場合であっても、第１のイベントの発生から一定時間は第１のイベントの処理を実行する。  そして、一定時間が経過した後、エラー通知を行うとともに、その間に発生した第２のイベントの処理を一度のみ実行する。【選択図】図５
2020046899.tif 000002
【特許請求の範囲】
【請求項１】
データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを発生順に処理できるシステムであって、
現在時刻と処理対象のイベントの発生時刻との差が前記第１の時間よりも短い第２の時間以内であった際に開始された処理対象のイベントの第１イベント処理が正常に終了しなかった場合に、当該イベントに対するイベント処理をリトライするための制御を行う第１の処理手段と、
現在時刻と処理対象のイベントの発生時刻との差が前記第２の時間以内でなかった際に開始された処理対象のイベントの第２イベント処理が正常に終了しなかった場合に、当該イベントに対する処理の失敗を通知するための処理を実行する第２の処理手段と、
を有することを特徴とするシステム。
【請求項２】
現在時刻と処理対象のイベントの発生時刻との差が前記第２の時間以内でなかった場合に、新たにスレッドを作成する作成手段と、
前記作成された新たなスレッドで、第３の時間だけ経過したことを判定した場合に、前記第２イベント処理を中止させる中止手段と、
前記第２イベント処理が中止された場合に、失敗を通知するための処理を実行する第２の処理手段と、前記第２イベント処理の対象のイベントに対する処理の失敗を通知するための処理を実行する第３の処理手段と、
をさらに有することを特徴とする請求項１に記載のシステム。
【請求項３】
前記第３の時間は、前記第２の時間よりも短い時間であることを特徴とする請求項２に記載のシステム。
【請求項４】
データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを処理できるシステムであって、
前記発行されたイベントに応答して、第１メッセージングサービスに、当該イベントを通知する第１の処理手段と、
前記第１メッセージングサービスからのイベントの通知に応答して、当該イベントに対するイベント処理の制御を行う第２の処理手段と、を有し、
前記第２の処理手段による前記イベント処理が例外終了、または、タイムアウトした場合には、当該イベント処理のリトライが実行され、
前記第２の処理手段は、前記イベント処理が例外終了、または、タイムアウトし、さらに、リトライの回数が一定回数を超えていた場合には、当該イベントに対するイベント処理の失敗を通知するための処理を実行することを特徴とするシステム。
【請求項５】
前記イベント処理の失敗を通知するための処理では、キューを介して、第２メッセージングサービスに対して、処理に失敗したイベントが通知されることを特徴とする請求項４に記載のシステム。
【請求項６】
データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを処理できるシステムであって、
現在時刻と処理対象のイベントの発生時刻との差が前記第１の時間よりも短い第２の時間以内であった際に開始された処理対象の前記発行されたイベントに対する第１イベント処理が正常に終了しなかった場合に、当該イベントに対するイベント処理をリトライするための制御を行い、現在時刻と処理対象のイベントの発生時刻との差が前記第２の時間以内でなかった際に開始された処理対象のイベントの第２イベント処理が正常に終了しなかった場合に、当該イベントに対する処理の失敗を通知するための処理を実行する第１のシステムと、
前記発行されたイベントに関する第１メッセージングサービスを介した通知に応答して、当該イベントに対する第３イベント処理の制御を行う第２のシステムと、を有し、
前記第２のシステムでは、前記第３イベント処理が例外終了、または、タイムアウトした場合には、当該イベント処理のリトライが実行され、
前記第２のシステムでは、前記第３イベント処理が例外終了、または、タイムアウトし、さらに、リトライの回数が一定回数を超えていた場合には、当該イベントに対するイベント処理の失敗を通知するための処理が実行されることを特徴とするシステム。
【請求項７】
データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを発生順に処理できるシステムにおける方法であって、
現在時刻と処理対象のイベントの発生時刻との差が前記第１の時間よりも短い第２の時間以内であった際に開始された処理対象のイベントの第１イベント処理が正常に終了しなかった場合に、当該イベントに対するイベント処理をリトライするための制御を行う第１の処理工程と、
現在時刻と処理対象のイベントの発生時刻との差が前記第２の時間以内でなかった際に開始された処理対象のイベントの第２イベント処理が正常に終了しなかった場合に、当該イベントに対する処理の失敗を通知するための処理を実行する第２の処理工程と、
を有することを特徴とする方法。
【請求項８】
データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを処理できるシステムにおける方法であって、
前記発行されたイベントに応答して、第１メッセージングサービスに、当該イベントを通知する第１の処理工程と、
前記第１メッセージングサービスからのイベントの通知に応答して、当該イベントに対するイベント処理の制御を行う第２の処理工程と、を有し、
前記第２の処理工程で前記イベント処理が例外終了、または、タイムアウトした場合には、当該イベント処理のリトライが実行され、
前記第２の処理工程では、前記イベント処理が例外終了、または、タイムアウトし、さらに、リトライの回数が一定回数を超えていた場合には、当該イベントに対するイベント処理の失敗を通知するための処理が実行されることを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システム及び方法に関するものであり、特に、クラウドサービスを利用したイベント駆動型サービスにおいてイベント処理を行うための情報処理システム及び方法に関するものである。
【背景技術】
【０００２】
近年、各種のクラウドコンピューティングサービスが存在している。例えば、Ａｍａｚｏｎ Ｗｅｂ Ｓｅｒｖｉｃｅ（以下、「ＡＷＳ」という）や、Ｇｏｏｇｌｅ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ等である。これらのサービスは、仮想マシンやストレージ等のコンピューティングリソースを、使用した性能や容量に応じて時間単位で課金する形態でサービス提供することで普及してきている。サービスの利用者は、これらのサービスを利用することで、自ら物理的な設備を用意しなくても、Ｗｅｂシステム等の情報処理システムを低コストで柔軟に構築することが可能となる。
【０００３】
クラウドコンピューティングサービスの利用例としては、ネットワークに接続された各種デバイスやコンピュータ端末、モバイル端末から、デバイスやアプリケーションの設定値を収集してストレージに保存し、データベースで管理するものがある。そのようなサービスにおいては、ファイル等の収集した情報がアップロードされるたびにレコードが作成され、ファイル名やストレージ上の保存場所等が管理される。
【０００４】
例えば、特許文献１には、イベントドリブン型スクリプトという技術が開示されている。この技術によれば、特定の情報に対する更新が行われた場合、その更新イベントにしたがい、予め登録されているスクリプトが起動される。
クラウドコンピューティングサービスにおいても、特定のコンピューティングリソースに対して発生したイベントに応じて、軽量な処理を実行するサービス（以下、「イベント駆動型コンピューティングサービス」という）が提供されている。例えば、ＡＷＳ Ｌａｍｂｄａ、Ｇｏｏｇｌｅ Ｃｌｏｕｄ Ｆｕｎｃｔｉｏｎｓ、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅ Ｆｕｎｃｔｉｏｎｓ等がある。
【０００５】
これらのサービスでは、クラウドコンピューティングサービスに対して所望の処理を実現するためのプログラムコードを、そのプログラムコードを実行する仮想マシンのＣＰＵやメモリ等のスペックを指定して事前に登録する。そして、登録したプログラムコードをコンピューティングリソースとそのコンピューティングリソースに対して発生する特定のイベントと関連付ける。
【０００６】
従来、イベント駆動型コンピューティングサービスが実現する処理と同様のことを実現するためには、クラウドコンピューティングサービスの利用者はそのための開発や管理が必要であった。例えば、コンピューティングリソースに対して発生するイベントの検知や、所望の処理の実行のためのアプリケーションの開発と、当該アプリケーションが稼働するインフラの構築や管理などである。
しかし、前述のイベント駆動型コンピューティングサービスにより、クラウドコンピューティングサービスの利用者は所望の処理の開発にだけ集中することが可能となった。また、イベント駆動型コンピューティングサービスにおいては、登録したプログラムコードが実行された時間単位で課金する形態でサービスが提供されているため、インフラの費用面でも容易にアプリケーションの開発が容易になった。
【０００７】
一方、現状のＡＷＳ Ｌａｍｂｄａに代表されるイベント駆動型コンピューティングサービスでは、イベントの発生に応じて実行されるプログラムコードの実行に際して制限事項が存在する。具体的には、プログラムコードはイベント駆動型コンピューティングサービスが定める時間内に処理が完了しないとタイムアウトが発生し、エラー終了する。特許文献２では、こうしたタイムアウトを抑制するための技術が提案されている。
【０００８】
そのため、開発者は、プログラムコードやイベントの不具合で例外が発生した場合の他に、こうした制限事項に抵触した場合のエラーに関しても、発生検知や通知を受け取るなどして、速やかな復旧を行えるよう備える必要がある。
【０００９】
前述したイベント駆動型コンピューティングサービスのトリガーとなる更新イベントには、発生後にストリームとして保持されるもの（以下、「ストリームイベント」という）がある。ストリームイベントの例としては、データベーステーブルに係る更新イベントがある。
こうしたストリームベースのイベントの場合、イベント駆動型コンピューティングサービスが定期的にストリームをポーリングし、更新されたレコードがあれば、レコードに対応付けて登録されているプログラムコードを実行する。例えば、データベーステーブルの変更が短期間に連続して発生した場合には、複数のストリームイベントが発生する。イベント駆動型コンピューティングサービスは、プログラムコードを実行し、発生順に、ストリームイベントを処理することができる。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００４−３８７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ストリームイベントをトリガーにした際の前述のプログラムコードによる処理の失敗が続いた場合、イベント駆動型コンピューティングサービスでは、ストリーム上から失敗したイベントが削除されるまで、対象イベントに対する処理のリトライが続けられる。前述のデータベーステーブルの更新に応じたストリームイベントについては、例えば、２４時間でストリーム上から削除される。そのため、ストリームイベントに対して特殊な処理を発生順に実行する場合などに、一つのイベント処理で不具合が発生した場合には、ストリーム上から対象イベントが削除されるまでの長期間、次のストリームイベントが処理されないことになる。そのようなケースでは、イベント駆動型コンピューティングサービスでの全体の処理に詰まりが生じるといった課題がある。
また、ストリーム上からイベントが削除されるのに伴い、イベント駆動型コンピューティングサービスで対象イベントに対する処理は実行されなくなる。しかし、この場合には、プログラムコードによる処理に失敗したわけではないため、その対象イベントに関するエラーの通知等はなされない。
【００１２】
前述した、ストリームイベントをトリガーした際のイベント駆動型コンピューティングサービスでの処理の停滞を抑制するための１つの方法として、所定の時間（例えば、１０分）だけリトライするという仕組みが考えられる。具体的には、イベント駆動型コンピューティングサービスでの処理開始時に、現在時刻とデータベーステーブルで管理されるイベント発生時刻を比較する。この差が所定時間を超えていなければ通常に処理し、前述した所定時間を超えていればエラーを通知し処理せずに終了する、といった制御を行うものである。これにより、イベント駆動型コンピューティングサービスで、対象イベントがストリーム上から削除されるまでリトライを続けることを回避できる。
【００１３】
しかし、この仕組みでは、ストリーム上で複数イベントがほぼ同時に連続して発生し、さらに、先に発生したイベントがリトライを繰り返して所定時間を超えてしまった場合に問題が生じる。具体的には、イベント駆動型コンピューティングサービスで、後発イベントを取得した場合に、現在時刻とデータベーステーブルで管理されるイベント発生時刻を比較すると、その差が既に所定時間を超えていると判定されてしまう場合がある。つまり、後発イベントが、イベント駆動型コンピューティングサービスでプログラムコードによる処理が一度も試行されないままエラーとして処理される可能性がある。
【００１４】
本発明は、このような課題を解決するため、イベント駆動型コンピューティングサービスを利用するシステムにおいて、長時間にわたる処理の詰まりの解消しつつ、正常にイベント処理が完了できなかった際に通知が行われるための仕組みを提供するものである。
【課題を解決するための手段】
【００１５】
本発明は、データベースに対して行われた複数の変更に応答して発行された各イベントが第１の時間だけ管理され、各イベントに応答して、該変更に対応するコードを実行することで、該複数のイベントを発生順に処理できるシステムであって、現在時刻と処理対象のイベントの発生時刻との差が前記第１の時間よりも短い第２の時間以内であった際に開始された処理対象のイベントの第１イベント処理が正常に終了しなかった場合に、当該イベントに対するイベント処理をリトライするための制御を行う第１の処理手段と、現在時刻と処理対象のイベントの発生時刻との差が前記第２の時間以内でなかった際に開始された処理対象のイベントの第２イベント処理が正常に終了しなかった場合に、当該イベントに対する処理の失敗を通知するための処理を実行する第２の処理手段と、を有することを特徴とする。
【発明の効果】
【００１６】
本発明によれば、イベント駆動型コンピューティングサービスを利用するシステムにおいて、長時間にわたる処理の詰まりの解消しつつ、正常にイベント処理が完了できなかった際に通知が行える。
【図面の簡単な説明】
【００１７】
【図１】イベント駆動型コンピューティングサービスのシステム構成である。
【図２】クライアント装置及びイベント駆動処理システムのハードウェア構成である。
【図３】実施例１のイベント駆動処理システムのソフトウェア構成である。
【図４】更新イベント発行のシーケンスである。
【図５】実施例１におけるイベント駆動処理システムが行うイベント処理の一例を示すシーケンスである。
【図６Ａ】実施例１における処理の流れを示すフローチャート（その１）である。
【図６Ｂ】実施例１における処理の流れを示すフローチャート（その２）である。
【図７】実施例２のイベント駆動処理システムのソフトウェア構成である。
【図８】実施例２におけるイベント駆動処理システムが行うイベント処理の一例を示すシーケンスである。
【図９】実施例２における処理の流れを示すフローチャートである。
【図１０】実施例３のイベント駆動処理システムのソフトウェア構成である。
【図１１】実施例３のイベント駆動処理システムが行うイベント処理の一例を示すシーケンスである。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための形態である各実施例について、図面を用いて説明する。
【実施例１】
【００１９】
図１は、各実施例における、イベント駆動型コンピューティングサービスのシステム構成（ネットワーク構成）を示している。
クライアント装置１００は、ネットワーク１０１を介してイベント駆動処理システム１０２と通信を行う。クライアント装置１００は、一例として、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、スマートフォンなどのコンピュータからなる。また、他の例としては、オフィス複合機、プリンターなどの画像処理装置からなる。
【００２０】
ネットワーク１０１は、インターネットなどのネットワーク網である。
イベント駆動処理システム１０２は、サーバなどの情報処理装置からなる情報処理システムであり、イベント駆動型コンピューティングサービスを提供する。なお、イベント駆動処理システム１０２の詳細については、後で説明する。
【００２１】
図２（Ａ）は、クライアント装置１００のハードウェア構成を示している。
ＣＰＵ２００は、ＲＡＭ２０１、ＲＯＭ２０２、二次記憶装置２０６などから読み込んだプログラムを実行する。
ＲＡＭ２０１は一時メモリ領域である。ＲＯＭ２０２は組込済みプログラムおよびデータを記録している。
【００２２】
ネットワークＩ／Ｆ２０３は、ネットワークインターフェースであり、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行う。通信の方式としては、有線・無線のいずれでもよい。
入出力Ｉ／Ｆ２０５は、入出力インタフェースであり、ディスプレイ、キーボード、マウス、タッチパネル、ボタンなどによる、情報や信号の入出力を行う。これらのハードウェアを備えないコンピュータにおいては、リモートデスクトップやリモートシェルなどにより、他のコンピュータから接続・操作することも可能である。
【００２３】
二次記憶装置２０６は、ＨＤＤやフラッシュメモリに代表されるような記憶装置である。
上記の各ハードウェアは、システムバス２０４を介して接続されている。本実施例においては、特に言及しない限り、システムバス２０４は、ＣＰＵ２００からの制御命令をシステムバス２０４に接続された各ハードウェアに伝播させるものとする。
【００２４】
図２（Ｂ）は、イベント駆動処理システム１０２を構成するサーバのハードウェア構成を示している。
ＣＰＵ２０７は、ＲＡＭ２０８、ＲＯＭ２０９、二次記憶装置２１２などから読み込んだプログラムを実行する。
ＲＡＭ２０８は一時メモリ領域である。ＲＯＭ２０９は組込済みプログラムおよびデータを記録している。
【００２５】
ネットワークＩ／Ｆ２１０は、ネットワークインターフェースであり、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行う。通信の方式としては、有線・無線のいずれでもよい。
二次記憶装置２１２は、ＨＤＤやフラッシュメモリに代表されるような記憶装置である。
【００２６】
上記の各ハードウェアは、システムバス２１１を介して接続されている。本実施例においては、特に言及しない限り、システムバス２１１はＣＰＵ２０７からの制御命令をシステムバス２１１に接続された各ハードウェアに伝播させるものとする。
なお、イベント駆動処理システム１０２を構成するサーバは、クラウドコンピューティングサービスとして提供されるものである。そして、図２（Ｂ）に示した各ハードウェアの機能は、それぞれ、仮想マシンソフトウェアによってアプリケーションソフトウェアとして実現され、物理ハードウェア要素と同様の挙動をとるものとする。
【００２７】
図３は、実施例１における、イベント駆動処理システム１０２のソフトウェア構成（機能構成）を示すブロック図である。
イベント駆動処理システム１０２において、データベーステーブル３００は、クライアント装置１００からのリクエストなどに基づき、データベーステーブル３００で管理される項目に対する変更（作成、更新、削除等）に応答してストリームイベント発行をする。
更新イベント格納部３０１は、データベーステーブル３００で発行されたストリームイベントを格納する。なお、実施例１においては、ストリームイベントは、データベーステーブルの更新を示すイベントであるとする。
【００２８】
エラーメッセージングサービス３０２は、後述するように、例外やタイムアウトなどの異常によりプログラムコードを実行する処理が異常終了した場合、イベント処理サービス３０３のイベント送信部３０７からストリームイベントを受信する。そして、あらかじめ登録しておいた宛先にエラーメッセージを送信する。
【００２９】
イベント処理サービス３０３は、更新イベント格納部３０１に対してポーリングを行い、未処理のストリームイベントがあれば、これを処理する。
なお、イベント処理サービス３０３は、サーバのプロビジョニングや管理を必要とせず、所定のイベントなどに応じてシステム側で割り当てられたリソースによりプログラムコードを実行する仕組みによって実現される。
【００３０】
イベント処理の開始にあたり、イベント処理サービス３０３は、まず、経過時間判断部３０４において実行状態を決定する。ここで、実行状態は、通常実行状態と終了準備実行状態との２種類が存在する。
【００３１】
通常実行状態では、イベント処理サービス３０３は、処理実行部３０５において、ストリームイベントの発生に応じて、登録されたプログラムコードを実行する。プログラムコードを実行する際に、例外が発生した場合、あるいは、経過時間が許容範囲（所定時間）を超えた（タイムアウトが発生した）場合、プログラムコードが実行中ならば、イベント処理サービス３０３はプログラムコードを実行する処理を中止する。そして、再度、経過時間判断部３０４が所定時間の経過を判断した後、あらかじめ定義された一定時間が経過するまで、プログラムコードの実行をリトライする。
【００３２】
終了準備実行状態では、イベント処理サービス３０３は、処理実行部３０５においてプログラムコードを実行するとともに、時間管理部３０６において経過時間をカウントする。プログラムコードを実行する際に、例外が発生した場合、あるいは、タイムアウトが発生した場合、プログラムコードが実行中ならば、イベント処理サービス３０３は、プログラムコードを実行する処理を終了する。その上で、イベント処理サービス３０３は、イベント送信部３０７からエラーメッセージングサービス３０２にストリームイベントを送付する。
【００３３】
図４は、データベーステーブルにおける更新イベントを発行する処理を示すシーケンスである。
まず、Ｓ４００において、クライアント装置１００からイベント駆動処理システム１０２のデータベーステーブル３００に対して、テーブルの更新を指令する。ここで、データベーステーブル３００としては、例えば、クライアント装置１００としてのコンピュータのステータスに関する情報や、画像処理装置の消耗品に関する情報を保持するデータベースなどがある。また、テーブルの更新としては、新規レコードの登録、あるいは既存レコードの更新、削除などがある。
【００３４】
そして、Ｓ４０１において、データベーステーブル３００は、テーブルの更新の内容を、ストリームイベントとして、更新イベント格納部３０１上に発行する。ここで、テーブルの更新イベントは、ＪＳＯＮなどのデータ記述言語で表される。
【００３５】
なお、本シーケンスにおいてクライアント装置１００が実行するプログラムは、ＲＡＭ２０１、ＲＯＭ２０２、二次記憶装置２０６などから読み込まれ、ＣＰＵ２００により実行される。また、データベーステーブル３００に係るプログラムは、ＲＡＭ２０８、ＲＯＭ２０９、二次記憶装置２１２などから読み込まれ、ＣＰＵ２０７により実行される。
【００３６】
ここで、データベーステーブルの更新イベントの例をＪＳＯＮ形式で以下に示す。なお、以下の例は、主キーが「１０１」であるレコードの「ｓｔａｔｕｓ」値が、「ＳＴＡＲＴＥＤ」から「ＳＵＣＣＥＥＤＥＤ」に更新されるイベントである。
【００３７】
{
"Records": [
{
"event-id": "1",
"event-version": "1.0",
"database": {
"Keys": {
"Id": "{
"Number": "101"
}
},
"OldImage": {
"Id": {
"Number": "101"
},
"status": {
"String": "STARTED"
}
},
"NewImage": {
"Id": {
"Number": "101"
},
"status": {
"String": "SUCCEEDED"
}
}
},
"event-name": "MODIFY",
"event-source": "database"
}
]
}
【００３８】
図５は、イベント駆動処理システム１０２で行われるイベント処理を含む全体処理の一例を示すシーケンスである。
まず、Ｓ５００において、イベント処理サービス３０３が、更新イベント格納部３０１に対してポーリングを行い、ストリームイベントを取得する。ここで、ストリームイベントは、データベーステーブルを更新するイベントであるとする。また、更新イベント格納部３０１では複数のストリームイベントを管理することが可能で、この例ではイベントの発生順にイベント処理サービス３０３に渡されるものとする。更新イベント格納部３０１では、各ストリームイベントを一定期間だけ管理する。この期間が経過してしまったストリームイベントは、更新イベント格納部３０１で削除する。削除された場合には、当該イベントはイベント処理サービス３０３には渡されなくなる。
一方で、イベント処理サービス３０３は、経過時間判断部３０４においてストリームイベント発生後の経過時間を、現在時刻を用いて算出し、経過時間があらかじめ定義された所定時間よりも短いか否かで実行状態を決定する。
【００３９】
ここで、上述のとおり、実行状態には２種類のものが存在し、第１の実行状態が、通常実行状態である。
通常実行状態の場合、イベント処理サービス３０３は、まず、処理実行部３０５において、取得したストリームイベントに対応付けてあらかじめ登録しておいたプログラムコードを実行する（Ｓ５０１）。これによって、イベント処理を実行する。
【００４０】
プログラムコードの実行が正常に終了した場合、そのままイベント処理サービス３０３による処理は終了する。一方、プログラムコードの実行が、例外あるいはタイムアウトにより終了した場合、あらかじめ定義された一定時間が経過するまで、同じストリームイベントに対して、プログラムコードを再度実行する（Ｓ５０２）。
【００４１】
プログラムコードが再実行された場合にストリームイベント発生後の経過時間が所定時間を過ぎていた場合には、イベント処理サービス３０３では、第２の実行状態である、終了準備実行状態で処理が行われる。
終了準備実行状態の場合、Ｓ５０３で、イベント処理サービス３０３は２つ目のスレッドを立てる（マルチスレッド処理）。第１のスレッドでは、処理実行部３０５が、Ｓ５００で取得したストリームイベントに対応付けてあらかじめ登録されている前述のプログラムコードを実行する。２つ目のスレッド（第２のスレッド）では、時間管理部３０６が、第１のスレッドで実行されているプログラムコードの実行開始後の経過時間をカウントする。
この際、プログラムコードの実行でタイムアウトが発生するまでの時間と、エラーを出力するのに十分な時間の差の時間（以下、「タイムアウト推定時間」という）を、あらかじめ定義しておく。例えば、タイムアウトが発生するまでの時間が５分であり、エラーを出力するのに１分あれば十分である場合、タイムアウト推定時間は４分となる。
【００４２】
第１のスレッドにおいて対象のストリームイベントに対するイベント処理が正常に終了した場合、そのままイベント処理サービス３０３における処理は終了する。
一方、第１のスレッドにおけるイベント処理で正常に終了せずに例外が発生して終了した場合、イベント送信部３０７が、エラーメッセージングサービス３０２にストリームイベントを送信する（Ｓ５０４）。そして、イベント処理サービス３０３の処理を終了する。
【００４３】
また、第１のスレッドにおけるプログラムコードの実行が正常または例外で終了する前に、第２のスレッドにおいてタイムアウト推定時間が経過した場合、イベント処理サービス３０３はその時点で第１のスレッドにおけるプログラムコードの実行を中止する。その上で、イベント送信部３０７がエラーメッセージングサービス３０２にストリームイベントを送信する（Ｓ５０４）。そして、イベント処理サービス３０３における処理は終了する。
【００４４】
ここで、エラーメッセージングサービス３０２には、あらかじめ宛先としてエラー通知先を登録しておく。エラー通知先は、例えば、開発メンバー用のメールアドレス、チャットサービス、プロジェクト管理ツールなどである。
【００４５】
なお、連続してストリームイベントが発生していた場合、通常実行状態であれば、Ｓ５０１において先行するストリームイベントが処理され、正常に終了した後、再度、Ｓ５００の処理が実行されて、後続するストリームイベントが処理される。
また、Ｓ５０４に応じて先行するストリームイベントの処理が終了し、その後のＳ５００の処理で後続のストリームイベントが取得された際に、既に該イベント発生後の経過時間が前述した所定時間を過ぎているケースもある。その場合には、Ｓ５０１〜Ｓ５０２の通常処理がスキップされ、最初から終了準備実行状態で後続のストリームイベントが処理されることになる。
【００４６】
なお、本シーケンスに係るイベント処理サービス３０３の処理実行部３０５は、サーバのプロビジョニングや管理を必要とせず、所定のイベント等に応じてシステム側で割り当てられたリソースによりプログラムコードを実行する仕組みによって実現される。
【００４７】
図６は、図５に示したシーケンスにおいてイベント処理サービス３０３が行う処理の詳細を示すフローチャートである。本フローチャートによる処理は、ストリームイベントの発生をトリガーとして開始する。
イベント処理サービス３０３では、プログラムコードを実行する際に、まず、経過時間判断部３０４が、現在時刻とイベント発生時刻の差を確認する（図６ＡのフローチャートにおけるＳ６００）。
【００４８】
現在時刻と処理対象のイベント発生時刻の差があらかじめ定義された所定時間以内であれば（Ｓ６００：Ｎ）、処理実行部３０５が、対象イベントを処理するために、対象イベントに対応するプログラムコードを実行する（Ｓ６０１）。なお、この判定で用いる“所定時間”は、更新イベント格納部３０１が各ストリームイベントを削除するまで管理する一定の期間よりも短い時間である。
そして、処理実行部３０５は、処理が完了したかを確認する（Ｓ６０２）。
【００４９】
処理が完了していない場合（Ｓ６０２：Ｎ）、経過時間判断部３０４が、処理が完了する前にタイムアウト（例えば、５分）が発生したかを判断する（Ｓ６０３）。
そして、タイムアウトが発生していれば（Ｓ６０３：Ｙ）、経過時間判断部３０４は、条件判断部Ｓ６００からリトライする。
【００５０】
タイムアウト発生前に処理が終了した場合（Ｓ６０２：Ｙ）、処理実行部３０５が、処理が成功したかを判断する（Ｓ６０４）。
処理が成功していた場合（Ｓ６０４：Ｙ）、そのままイベント処理サービス３０３における処理は終了する。一方、処理が失敗（例外終了など）していた場合は（Ｓ６０４：Ｎ）、経過時間判断部３０４が、条件判断部Ｓ６００からリトライする。
【００５１】
経過時間判断部３０４で確認した現在時刻とイベント発生時刻の差があらかじめ定義された所定時間以上（例えば、１時間以上）であれば（Ｓ６００：Ｙ）、処理実行部３０５は新たにスレッド（前述した第２のスレッド）を作成する（Ｓ６０５）。Ｓ６００でＹＥＳと判定されるケースの１つは、１つのストリームイベントに対してＳ６０３及びＳ６０４の判定結果に従い何度かリトライしたケースである。また、Ｓ６００でＹＥＳと判定される他のケースは、ほぼ同時に連続して発生したストリームイベントの中の後発イベントが取得された際に先発イベントが何度かリトライして処理されていたケースである。後者のケースは、Ｓ６０１の処理を実行することなく、Ｓ６０５に進むことがある。そして、図６Ｂに示されるマルチスレッド処理に入る（Ｓ６１２）。
【００５２】
図６Ｂ（１）は、第１のスレッドでの処理を説明するためのフローチャートである。Ｓ６０６では、処理実行部３０５が、Ｓ６０１と同様に、ストリームイベントに応じたプログラムコードを実行し、イベント処理を実行する。
図６Ｂ（２）は、第１のスレッドでの処理と並行に実行される、Ｓ６０５で作成された第２のスレッドでの処理を説明するためのフローチャートである。Ｓ６１０では、時間管理部３０６が、スレッド作成後の経過時間をカウントする。
【００５３】
図６Ｂ（２）で示す第２のスレッドの処理について、まず説明を行う。
Ｓ６１０でカウントを開始したスレッド作成後の経過時間が、タイムアウト推定時間（例えば、４分）に達した場合、その時点で、Ｓ６０６で開始されたプログラムコードの実行を処理実行部３０５に中止させる（Ｓ６１１）。タイムアウト推定時間は１回分のイベント処理に相当する時間であるため、通常は、Ｓ６００で前述した所定時間よりも短い時間が定義されることになる。
そして、イベント送信部３０７がエラーメッセージングサービス３０２にストリームイベントを送信する（Ｓ６１２）。
これで、イベント処理サービス３０３における処理は終了する。
【００５４】
一方、図６Ｂ（１）で示す第１のスレッドの処理についても説明を行う。
図６Ｂ（２）でのスレッド作成後の経過時間がタイムアウト推定時間に達する前に、Ｓ６０６で開始されたプログラムコードを実行することによるイベント処理が完了した場合、前記経過時間のカウント処理を時間管理部３０６に中止させる（Ｓ６０７）。
【００５５】
そして、処理実行部３０５が、プログラムコードの実行によるイベント処理が成功したか否かを判断する（Ｓ６０８）。処理が成功していた場合、イベント処理サービス３０３における処理は終了する。
【００５６】
一方、イベント処理が失敗した場合、イベント送信部３０７はその時点でエラーメッセージングサービス３０２にストリームイベントを送信する（Ｓ６０９）。この場合には、図６Ａで説明した処理とは異なり、イベント処理のリトライが行われない。その後、イベント処理サービス３０３における処理は終了する。
【００５７】
上記のとおり、実施例１によれば、ストリームイベントが発生してからあらかじめ定義された所定時間が経過した場合は、実行状態を終了準備実行状態に切り替えて、イベント処理のリトライを制限する。これにより、更新イベント格納部３０１でストリームイベントが自動削除されるまでリトライを繰り返すことによる、長時間の処理の詰まりを防ぐことができる。
また、実施例１によれば、連続してストリームイベントが発生し、先行するストリームイベントで何度かリトライされた場合であっても、後続のストリームイベントに対する処理の実行が一度は保証される。
【００５８】
また、実施例１によれば、更新イベント格納部３０１でストリームイベントが自動削除されることによりストリームイベントのリトライが中止されることが無いため、イベントの処理の失敗をエラーメッセージングサービス３０２経由で確実に通知できる。
【実施例２】
【００５９】
次に、実施例２について、実施例１と異なる部分について主に説明する。
図７は、実施例２における、イベント駆動処理システム１０２のソフトウェア構成（機能構成）を示すブロック図である。
【００６０】
実施例１では、イベント駆動処理システム１０２内において、イベント処理サービス３０３が処理を実行した。それに対し、実施例２では、イベント変換部７０１を備えるイベント転送サービス７００と、処理実行部７０６を備えるイベント処理サービス７０５と、イベントメッセージングサービス７０３と、エラー通知用のキュー７０４と、が処理を実行する。
なお、イベント転送サービス７００やイベント処理サービス７０５は、サーバのプロビジョニングや管理を必要とせず、所定のイベント等に応じてシステム側で割り当てられたリソースによりプログラムコードを実行する仕組みによって実現される。
【００６１】
図８は、実施例２における、イベント駆動処理システム１０２が行うイベント処理の一例を示すシーケンスである。
【００６２】
実施例２では、イベント転送サービス７００が、ストリームイベントを取得する（Ｓ８００）。ここで、ストリームイベントは、実施例１と同様に、データベーステーブルを更新するイベントであるとする。
そして、イベント転送サービス７００は、ストリームイベントがバッチ処理されたイベントであった場合には、個別のイベントに分割する。この際、後の処理のため、イベント変換部７０１において、イベントのフォーマットなどを変換する（Ｓ８０１）。イベント変換処理は省略されても良い。
【００６３】
そして、イベント転送サービス７００は、処理されたイベントをイベント送信部７０２によりイベントメッセージングサービス７０３に転送する（Ｓ８０２）。
イベントメッセージングサービス７０３は、イベント通知を行うため、イベント転送サービス７００から転送されたイベントを、イベント処理サービス７０５に通知する（Ｓ８０３）。ここで、イベントメッセージングサービス７０３には、あらかじめ宛先としてイベント処理サービス７０５を登録しておく。また、イベントメッセージングサービス７０３は、複数のイベントがイベント転送サービス７００から転送されてきた場合は、転送されてきた順番で、イベント処理サービス７０５に対して通知する。
【００６４】
イベント処理サービス７０５は、イベントメッセージングサービス７０３からの通知に応答して、ストリームイベントに対応付けて予め登録されていたプログラムコードを実行する（Ｓ８０４）。
ここで、タイムアウトが発生する前に処理が正常に終了した場合、そのままイベント処理サービス７０５における処理は終了する。
なお、イベントメッセージングサービス７０３からイベント処理サービス７０５に対しての通知はイベントの転送順に行われる。しかしながら、Ｓ８０４における処理では連続で通知されてきた各イベントを前述のプログラムコードを順次実行し、並行してイベント処理する際に、それらのイベント処理の完了タイミングが、逆転する場合がある。
【００６５】
一方、プログラムコードの実行に基づくイベント処理の際に例外が発生して終了した場合、あるいは、タイムアウトを起こした場合、あらかじめ定義された一定回数に到達するまで、イベント処理サービス７０５は、イベント処理のリトライを行う（Ｓ８０５）。
既にあらかじめ定義された一定回数を超えて、リトライに失敗した場合、イベント処理サービス７０５はその時点でエラー通知用のキュー７０４にストリームイベントを送信する（Ｓ８０６）。そして、イベント処理サービス７０５における処理は終了する。
【００６６】
そして、キュー７０４は、宛先として登録されているエラーメッセージングサービス３０２へストリームイベントを送信する（Ｓ８０７）。
【００６７】
図９は、図８に示したシーケンスにおいて、イベント処理サービス７０５が行う処理の詳細を示すフローチャートである。
まず、イベント処理サービス７０５内の処理実行部７０６が、イベントメッセージングサービス７０３からストリームイベントの通知を受信する（Ｓ９００）。
すると、処理実行部７０６は、イベントメッセージングサービス７０３からの通知に応答して、ストリームイベントに対応付けて予め登録されていたプログラムコードを実行することで、イベント処理の実行を制御する（Ｓ９０１）。
【００６８】
そして、処理実行部７０６は、イベント処理が完了したかを確認する（Ｓ９０２）。
イベント処理が完了した場合（Ｓ９０２：Ｙ）、処理実行部７０６は、処理が成功したかを確認する（Ｓ９０４）。処理が成功していれば（Ｓ９０４：Ｙ）、イベント処理サービス７０５における処理は終了する。
イベント処理が完了していない場合（Ｓ９０２：N）、処理実行部７０６は、タイムアウトが発生したか否かを確認する（Ｓ９０３）。タイムアウトが発生していない場合（Ｓ９０３：N）には処理がＳ９０２に戻る。
【００６９】
イベント処理が例外終了した場合（Ｓ９０４：Ｎ）、あるいは、タイムアウトが発生した場合（Ｓ９０３：Ｙ）、処理実行部７０６は、例外終了やタイムアウトによるリトライの発生回数があらかじめ定義された一定回数を超えるか否かを判断する（Ｓ９０５）。
【００７０】
一定回数以下である場合（Ｓ９０５：Ｎ）、処理実行部７０６は、プログラムコードを再実行することで、イベント処理をリトライする（Ｓ９０１）。
一定回数以上である場合（Ｓ９０５：Ｙ）、イベント送信部７０７が、エラー通知用のキュー７０４にストリームイベントを通知する（Ｓ９０６）。
そして、イベント処理サービス７０５における処理は終了する。
【００７１】
上記のとおり、実施例２によれば、イベントメッセージングサービス７０３を経由することで、メッセージベースでイベント駆動型コンピューティングサービスを起動する。そして、イベント処理の失敗によるリトライ回数があらかじめ定義された一定回数を超えた場合、エラーメッセージとして、ストリームイベントをキュー７０４に送信する。
これにより、開発側で試行回数を管理することなく、データベースからのストリームイベントをイベント駆動型コンピューティングサービスで処理する際に、処理の詰まりを抑制しつつ、一定回数の失敗でエラーを通知することができる。
【実施例３】
【００７２】
次に、実施例３について、実施例１や実施例２と異なる部分について主に説明する。
図１０は、実施例３における、イベント駆動処理システム１０２のソフトウェア構成（機能構成）を示すブロック図である。
実施例３の処理システムは、図３に示した実施例１の処理システム（「第１システム」）の機能構成１００４と、図７に示した実施例２の処理システム（「第２システム」）の機能構成１００５とを、併せ持つ。
【００７３】
ただし、実施例１におけるイベント処理サービス３０３にあたるイベント処理サービス１０００は、ポーリングしたストリームイベントを実行するかを判断する処理実行判断部１００１をさらに備える。また、実施例２におけるイベント転送サービス７００にあたるイベント転送サービス１００２も、処理実行判断部１００３をさらに備える。
なお、イベント処理サービス１０００やイベント転送サービス１００２は、サーバのプロビジョニングや管理を必要とせず、所定のイベント等に応じてシステム側で割り当てられたリソースによりプログラムコードを実行する仕組みによって実現される。
【００７４】
ここで実施例３の処理システムは、実施例１の第１システムと、実施例２の第２システムを組み合わせたものであるため、「ハイブリッド処理システム」とも称することとする。
実施例３によれば、実施例１と実施例２のシステムを併用し、それぞれの利点を享受することができる。
【００７５】
実施例３においては、ストリームイベント種別ごとに、第１システムと第２システムのいずれかの処理システムに紐づけ、イベント識別マップに登録しておく。そして、ストリームイベントの種別に応じて、第１システムと第２システムとを切り替える。
具体的には、ある程度リアルタイムにイベントを管理する際に、とくにイベントの登録順に応じた厳密な順序保証が必要なストリームイベントのタイプの場合には第１システムが選択できる。第２システムもある程度、処理順が保たれる上に、多くのイベントが頻発するケースにおいては、第１システムよりも相対的にそれら全てのイベント処理の時間が短くて済む。イベントタイプに応じた処理システムの選択は、管理者が任意に選択することが可能である。
【００７６】
図１１は、実施例３における、イベント駆動処理システム１０２が行うイベント処理の一例を示すシーケンスである。
【００７７】
まず、第１システム１００４のイベント処理サービス１０００が、更新イベント格納部３０１に対してポーリングを行い、ストリームイベントを取得する（Ｓ１１００）。また、第２システム１００５のイベント転送サービス１００２も、更新イベント格納部３０１に対してポーリングを行い、ストリームイベントを取得する（Ｓ１１０１）。ここで、ストリームイベントは、実施例１や２と同様に、データベーステーブルを更新するイベントであるとする。
【００７８】
次に、イベント処理サービス１０００は、イベント識別マップを参照し、プログラムコードを実行するか否かを判断する（Ｓ１１０２）。また、イベント転送サービス１００２も、イベント識別マップを参照し、プログラムコードを実行するか否かを判断する（Ｓ１１０３）。
ここで、イベント識別マップとは、ストリームイベントの種別ごとに、第１システムと第２システムのどちらを実行するかについて、あらかじめ紐づけた上で記録したものである。なお、イベント識別マップは、ＪＳＯＮ等の形式のファイルとして、外部に保持してもよく、また、プログラムに直接書いてもよい。
【００７９】
受信したストリームイベントの種別が第１システムに紐づけられていた場合、第１システム１００４のイベント処理サービス１０００が、図５のシーケンスで示したＳ５０１以降の処理を行う。なお、第２システム１００５のイベント転送サービス１００２は、処理を行わずに終了する。
【００８０】
受信したストリームイベントの種別が第２システムと紐づけられていた場合、第１システム１００４のイベント処理サービス１０００は、処理を行わず終了する。そして、第２システム１００５のイベント転送サービス１００２が、図８のシーケンスで示したＳ８０１以降の処理を行う。
【００８１】
なお、本シーケンスに係るイベント処理サービス１０００やイベント転送サービス１００２は、サーバのプロビジョニングや管理を必要しない。イベント処理サービス１０００やイベント転送サービス１００２は、所定のイベントなどに応じてシステム側で割り当てられたリソースによりプログラムコードを実行する仕組みによって実現される。
【００８２】
なお、ストリームイベントに対応したプログラムコードの実行に冪等性が保たれておらず、第１システムに紐づけられる処置の例としては、画像形成装置における用紙のカウンタ値加算イベントがある。この場合、複数回の実行が起きてしまうと、加算されるカウント値に誤りが生じてしまう。
【００８３】
以下に、カウンタ値加算イベントの例をＪＳＯＮ形式で示す。なお、これは、テナントＩＤ「１０００ＢＡ」、デバイスＩＤ「２００−ａａａ」のデバイスで、白黒、再生紙で印刷した際のカウンタ値加算イベントの例である。
【００８４】
{
"Records": [
{
"event-id": "1",
"event-version": "1.0",
"database": {
"Keys": {
"HashKey": "{
"String": "device|1000BA|200-aaa"
}
},
"OldImage": {
"HashKey": "{
"String": "device|1000BA|200-aaa"
},
"Counter": {
"String": "140"
},
"Black_and_White": {
"String": "110"
},
"Recycles_Paper": {
"String": "25"
}
},
"NewImage": {
"HashKey": "{
"String": "device|1000BA|200-aaa"
}},
"Counter": {
"String": "141"
},
"Black_and_White": {
"String": "111"
},
"Recycles_Paper": {
"String": "26"
}
}
},
"event-name": "MODIFY",
"event-source": "database"
}
]
}
【００８５】
一方、順序保証が不要かつ冪等性が保たれているプログラムコードの実行例としては、デバイスのバックアップ成功イベントに伴い、データベーステーブルに登録されたバックアップレコードを、最新の指定件数を残して削除する処理がある。この場合、順序が入れ替わりや複数回の実行が起きたとしても、最終的に残る件数は同じであるため、不具合は起こらない。
【００８６】
以下に、バックアップ成功イベントの例をＪＳＯＮ形式で示す。なお、これは、テナントＩＤ「１０００ＢＡ」に紐づいた、バックアップＩＤ「１１１１−２３４５」のバックアップが、ステータス「開始」から「成功」へ更新されたイベントの例である。
【００８７】
{
"Records": [
{
"event-id": "1",
"event-version": "1.0",
"database": {
"Keys": {
"HashKey": "{
"String": "backup|1000BA"
}
},
"OldImage": {
"HashKey": "{
"String": "backup|1000BA"
},
"backup_id": {
"String": "1111-2345"
},
"status": {
"String": "STARTED"
}
},
"NewImage": {
"HashKey": "{
"String": "backup|1000BA"
},
"backup_id": {
"String": "1111-2345"
},
"status": {
"String": "SUCCEEDED"
},
"received_at": {
"String": "2018-01-01T07:00:00.000Z"
},
"file_id": {
"String": "20180101-070000.zip"
}
}
},
"event-name": "MODIFY",
"event-source": "database"
}
]
}
【００８８】
（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上述の実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形が可能であり、それらを本発明の範囲から除外するものではない。すなわち、上述の各実施例及びその変形例を組み合わせた構成もすべて本発明に含まれるものである。
【符号の説明】
【００８９】
１００      クライアント装置
１０２      イベント駆動処理システム
３００      データベーステーブル
３０１      更新イベント格納部
３０２      エラーメッセージングサービス
３０３      イベント処理サービス
１００４    第１システム
１００５    第２システム
【図１】
2020046899.tif 000003
【図２】
2020046899.tif 000004
【図３】
2020046899.tif 000005
【図４】
2020046899.tif 000006
【図５】
2020046899.tif 000007
【図６Ａ】
2020046899.tif 000008
【図６Ｂ】
2020046899.tif 000009
【図７】
2020046899.tif 000010
【図８】
2020046899.tif 000011
【図９】
2020046899.tif 000012
【図１０】
2020046899.tif 000013
【図１１】
2020046899.tif 000014