(57)【要約】【課題】クラウドコンピューティングでのデータベース更新処理失敗時における遅延処理方法を提供する。【解決手段】業務プログラムから１乃至複数のクラウドに対してデータベース更新処理要求が成された際、リアルタイム処理部はこれを更新先のパブリッククラウドに送出する。パブリッククラウドからデータベースの更新処理に失敗したことを示す処理結果が返却された場合、リアルタイム処理部は遅延処理ポリシーに従って遅延処理スクリプトを作成し、遅延処理スクリプトの「残りリトライ回数」から１を減算し、「リトライ間隔」に従って遅延処理部の起動タイマーをセットする。「リトライ間隔」に設定された時間の経過を持って遅延処理部が起動し、遅延処理部は遅延処理スクリプトに従ってデータベース更新処理の再試行を行う。【選択図】図１
2015060286.tif 000002
【特許請求の範囲】
【請求項１】
データベースを備えるクラウドと、
クラウド宛のデータベース更新要求を行う業務プログラムと、
前記クラウドと前記業務プログラムの間に介在し、両者と通信可能に接続するクラウドポータルシステムと、
からなるクラウドコンピューティングシステムであって、
前記クラウドポータルシステムは、
前記業務プログラムからのデータベース更新処理に失敗した際のデータベース更新要求の再試行回数、データベース更新要求の次回再試行までの待機時間である再試行間隔を、予め設定する遅延処理ポリシーと、
データベース更新要求を前記クラウドに送出し、前記クラウドがデータベース更新処理に失敗した場合、前記遅延処理ポリシーに従って、残り再試行回数及び再試行間隔を管理する遅延処理スクリプトを、残り再試行回数の初期値を前記遅延処理ポリシーの再試行回数、再試行間隔を遅延処理ポリシーの再試行間隔として作成するリアルタイム処理部と、
データベース更新要求の遅延処理を実行する遅延処理部と、を備え、
前記業務プログラムからデータベース更新処理要求を受けた際、前記リアルタイム処理部が起動し、データベース更新処理要求をデータ更新先の前記クラウドに対して送出し、
前記クラウドにおいてデータ更新処理が失敗し、前記業務プログラム宛に更新処理の失敗を示す処理結果が返却された場合、前記遅延処理部が起動し、前記リアルタイム処理部によって作成された前記遅延処理スクリプトの残り再試行回数から１を減算し、前記遅延処理スクリプトの再試行間隔に基づいて前記遅延処理部の起動タイマーを設定し、再試行間隔に設定された待機時間が経過した後に、作成された遅延処理スクリプトに基づいて再度遅延処理部を起動し、前記遅延処理スクリプトの再試行回数が０になるか、前記データベース更新処理要求が前記クラウドにて成功するまで再試行を繰り返すことを特徴とするクラウドコンピューティングでの遅延処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クラウドコンピューティングでの遅延処理方法に関する。
【背景技術】
【０００２】
従来、クラウドコンピューティングによるサービスであって、不特定多数のユーザによって利用されるパブリッククラウドサービスが多くの企業によって提供されている。パブリッククラウドサービスを利用するにあたり、ユーザはストレージ装置の保守作業等を意識せずとも良く、種々のデータをアップロードしておき、必要なときに必要なファイルをダウンロードして使用することができる。またこのようなデータを利用、加工するトランザクション処理等もパブリッククラウドサービスを利用して行うことで、データベース管理ソフトウェア等の保守作業等からも解放される。このようなパブリッククラウドサービスは、個人利用に留まらず、企業等が顧客データや営業データ等を管理するために利用するケースも多くなってきている。このようなパブリッククラウドサービスにおいて、その利便性の更なる向上を図る技術が種々開示されている。
【０００３】
例えば特許文献１では、上記のようなクラウドを複数に跨って一連のクラウドコンピューティングを行う際の仲介装置となるＳＤＰ（サービス  デリバリー  プラットフォーム）が開示されている。また、特許文献２では複数のクラウドの状態を判別し、異常の生じたクラウドを回避してデータの更新を行い、また異常から回復した場合、正常に更新されたクラウドの情報を復帰したクラウドへ時系列順に反映することを可能とするサービス中継装置が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１１−１８２０３１号公報
【特許文献２】特開２０１２−２０３４７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記特許文献１では、複数クラウドへのデータアクセスは可能とするものの、複数クラウドに跨るデータベース更新処理を必要とするサービスに適用しようとした際に、クラウドやネットワークに障害が発生し、正しくクラウドのデータベース更新処理ができないような場合の対処方法などは開示しておらず、また特許文献２の構成では、更新先のクラウドに障害発生時に別のクラウドへ更新処理を行い、前者のクラウドの障害が回復した際に後者のクラウドに正常に更新できたデータを、前者のクラウドへ時系列順に反映するというバックアップ的機能を有するものの、利用するクラウドが１つの場合に適用できる技術ではない。
【０００６】
そこで本発明では、クラウドコンピューティングでのデータ更新の遅延処理を可能とし、障害等発生時において、障害が回復されるまでデータ更新を所定の回数、所定の間隔にて自動的に再試行することが可能なクラウドコンピューティングでの遅延処理方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明のクラウドコンピューティングでの遅延処理方法は、データベースを備えるクラウドと、クラウド宛のデータベース更新要求を行う業務プログラムと、前記クラウドと前記業務プログラムの間に介在し、両者と通信可能に接続するクラウドポータルシステムと、からなるクラウドコンピューティングシステムであって、前記クラウドポータルシステムは、前記業務プログラムからのデータベース更新処理に失敗した際のデータベース更新要求の再試行回数、データベース更新要求の次回再試行までの待機時間である再試行間隔を、予め設定する遅延処理ポリシーと、データベース更新要求を前記クラウドに送出し、前記クラウドがデータベース更新処理に失敗した場合、前記遅延処理ポリシーに従って、残り再試行回数及び再試行間隔を管理する遅延処理スクリプトを、残り再試行回数の初期値を前記遅延処理ポリシーの再試行回数、再試行間隔を遅延処理ポリシーの再試行間隔として作成するリアルタイム処理部と、データベース更新要求の遅延処理を実行する遅延処理部と、を備え、前記業務プログラムからデータベース更新処理要求を受けた際、前記リアルタイム処理部が起動し、データベース更新処理要求をデータ更新先の前記クラウドに対して送出し、前記クラウドにおいてデータ更新処理が失敗し、前記業務プログラム宛に更新処理の失敗を示す処理結果が返却された場合、前記遅延処理部が起動し、前記リアルタイム処理部によって作成された前記遅延処理スクリプトの残り再試行回数から１を減算し、前記遅延処理スクリプトの再試行間隔に基づいて前記遅延処理部の起動タイマーを設定し、再試行間隔に設定された待機時間が経過した後に、作成された遅延処理スクリプトに基づいて再度遅延処理部を起動し、前記遅延処理スクリプトの再試行回数が０になるか、前記データベース更新処理要求が前記クラウドにて成功するまで再試行を繰り返すことを特徴とする。
【発明の効果】
【０００８】
本発明によれば、クラウドが備えるデータベースに対して更新処理が失敗した場合であっても、所定の回数、所定の時間間隔でデータベース更新処理を自動的に再試行することができる。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施例における、クラウドポータルシステムの構成を示すブロック図である。
【図２】同上、キューゲートウェイ部の構成を示すブロック図である。
【図３】同上、トランザクションゲートウェイ部の構成を示すブロック図である。
【図４】同上、セキュアゲートウェイ部の構成を示すブロック図である。
【図５】同上、データベース更新処理要求部の動作を示すフローチャートである。
【図６】同上、コミット処理部の動作を示すフローチャートである。
【図７】同上、リアルタイム処理部の動作を示すフローチャートである。
【図８】同上、遅延処理部の動作を示すフローチャートである。
【図９】同上、遅延処理部の動作を示すフローチャートである。
【図１０】同上、遅延処理部の動作を示すフローチャートである。
【図１１】同上、遅延処理部の動作を示すフローチャートである。
【図１２】同上、遅延処理ポリシーの一例を示す説明図である。
【図１３】同上、遅延処理スクリプトの一例を示す説明図である。
【図１４】同上、従来のセキュアデータセンターとセキュアゲートウェイ部を具備したセキュアデータセンターとを比較する説明図である。
【図１５】同上、処理待ちキューの構成を示す説明図である。
【図１６】同上、遅延処理スクリプト内の遅延処理対象の処理要求へのポインタに作成される処理単位リストと、処理待ちキューの関係性を示す説明図である。
【図１７】同上、業務プログラムＡの処理内容を疑似的なプログラムコードにて示す説明図である。
【発明を実施するための形態】
【００１０】
本発明を実施するための形態を以下に説明する。もちろん、本発明は、その発明の趣旨に反しない範囲で、本実施形態において説明した以外の構成のものに対しても容易に適用可能なことは説明を要するまでもない。
【００１１】
本実施例について、図１乃至６に基づいて説明する。尚、本実施例において、説明の簡略化のため、利用するパブリッククラウドサービスの数を２として説明する。
【００１２】
事業者３００は、セキュアデータセンター１００を介してパブリッククラウドサービス（以降単にパブリッククラウドと称呼する）Ｐ１、Ｐ２が備えるデータベースＰＤ１及びＰＤ２を利用する。セキュアデータセンター１００はクラウドポータルシステム２００と、事業者３００向けの業務プログラムａ１、業務プログラムａ２を備えており、事業者３００は当該業務プログラムａ１及びａ２にアクセスし、クラウドポータルシステム２００を介してパブリッククラウドＰ１、Ｐ２を利用する。
【００１３】
クラウドポータルシステム２００は、業務プログラムからのパブリッククラウド宛の処理要求の受け付け及びパブリッククラウドからの処理結果の返却を行う要求受付／結果返却部２１０、業務プログラムからパブリッククラウド宛の処理要求の待ち行列管理の機能を有するキューゲートウェイ部２２０、複数パブリッククラウドのデータベース更新を含む一連の複数の処理要求を、１つの処理要求の単位（グローバルトランザクション）として実行する機能を有するトランザクションゲートウェイ部２３０、当該暗号化された情報をパブリッククラウドから得た際にこれを復号化する機能を担うセキュアゲートウェイ部２４０、業務プログラムからパブリッククラウド宛の処理要求をパブリッククラウドに送出し、また、パブリッククラウドから処理要求の結果を受領する機能を有する要求送出／結果受領部２５０、以上大きく分類して５つの構成から成る。
【００１４】
キューゲートウェイ部２２０について詳述する。キューゲートウェイ部２２０は、業務プログラムからのパブリッククラウド宛の処理要求の待ち行列管理を担うものであり、これによってパブリッククラウドで処理要求のリアルタイムな処理が不可能な場合の遅延処理、一括バッチ処理及び後述のグローバルトランザクション処理を実現可能とするものである。図２に示すように、キューゲートウェイ部２２０は、リアルタイム処理部２２１、処理待ちキュー保持部２２２、遅延処理部２２３、遅延処理ポリシー保持部２２４から構成される。
【００１５】
リアルタイム処理部２２１は、業務プログラムからパブリッククラウド宛ての処理要求を実行するものである。この処理要求を実行する際、何らかの要因によってその処理の実行を完遂できない場合、当該要求をパブリッククラウド毎に用意された処理待ちキューに要素として編入し、後述の遅延処理ポリシーに従って遅延処理スクリプトを作成し、更にこの遅延処理スクリプトに従って後述の遅延処理部を起動させる設定を行う。
【００１６】
処理待ちキュー保持部２２２は、パブリッククラウド毎に具備する処理待ちキュー（２２２ａ、２２２ｂ、・・・）を蓄積するためのものである。処理待ちキューとは、業務プログラムから各々のパブリッククラウドに宛てた処理要求を格納する待ち行列である。
【００１７】
処理待ちキュー保持部２２２に保持される処理待ちキュー２２２ａ、２２２ｂの構造は、図１５に示すような構造からなる。各業務プログラム又はキューゲートウェイ部２２０のリアルタイム処理部２２１によって、パブリッククラウドＰ１またはＰ２宛てのデータベース更新処理要求を受け付け順に並べて管理する機能と、遅延処理ポリシー若しくは遅延処理スクリプトのリトライ間隔に応じた経過時間の到達の際にこれをパブリッククラウド宛に送出する機能と、及び遅延処理部２２３からのキュー要素の削除指示を受けて処理待ちキューから該当するキュー要素を削除する機能を有する。
個々のキュー要素には、データベース更新処理要求の具体的な内容（例えばＳＱＬ文やデータファイル等）がキュー要素として格納される。
【００１８】
遅延処理部２２３はクラウドポータルシステム２００内部からの呼び出しや、予めセットされたタイマー満了をトリガーとして起動され、前述の遅延処理スクリプトに従い、障害に起因する要求再送出等、処理待ちキューに編入された要素（即ち処理要求）に対する遅延処理や、編入された要素の処理待ちキューからの削除処理を担う。また、日次バッチ等の一括処理指定がされた要素のバッチ処理や、後述のグローバルトランザクション処理の際にも当該機能を用いる。
【００１９】
遅延処理ポリシー保持部２２４には、業務プログラム毎の遅延処理ポリシーが格納される。遅延処理ポリシーとは、業務プログラム毎に予め定義され、何らかの要因によって、処理要求の宛先であるパブリッククラウドが利用不可能な場合やデータベース更新処理が失敗した場合の対処法が記述されており、図１２に示すようなデータ構造からなる。「一括処理オプション」とは、パブリッククラウド宛の複数の要求の一括処理の是非、並びに処理に失敗した際の遅延処理又はロールバックとエラーの返却等の設定値である。「リトライ回数」とは、処理失敗の際の再試行回数の設定値である。０が指定された場合は再試行を行わずに直ちにエラーを返却する。「リトライ間隔」は再試行を行う間隔、即ち再試行するまでの待機時間の設定値であり、単位を秒とする。「要求先変更タイミング」とは、所定の回数再試行が行われても処理に失敗する場合に処理先のパブリッククラウドを変更する際の試行回数の閾値である。要求先変更タイミングに１が設定された場合、処理の失敗時に直ちに要求先を変更する。「変更後要求先」には処理の再試行回数が要求先変更タイミングに設定された閾値に到達した場合の他のパブリッククラウドを一意に特定するための識別子が設定される。
【００２０】
トランザクションゲートウェイ部２３０について詳述する。図３に示すようにトランザクションゲートウェイ部２３０は、業務プログラムからのグローバルトランザクションとしての処理要求があった場合、複数のパブリッククラウド宛のデータベース更新要求を、１つの処理単位（グローバルトランザクション）として実行するためのものであり、トランザクションゲートウェイ部２３０は、グローバルトランザクション毎に、グローバルトランザクション未成立時の扱いとしてロールバック又は遅延コミットの何れかを指定することができる。トランザクションゲートウェイ部２３０は、データベース更新要求処理部２３１とコミット処理部２３２とで構成される。
【００２１】
データベース更新要求処理部２３１は、業務プログラムからのデータベース更新要求を前述のキューゲートウェイ部２２０が具備するリアルタイム処理部２２１に伝達するものである。また、コミット処理部２３２は、データベース更新要求処理部２３１を介してパブリッククラウドに送出された処理要求の確定処理を行うためのものである。
【００２２】
セキュアゲートウェイ部２４０について詳述する。図４に示すように、セキュアゲートウェイ部２４０は、秘匿したい情報の暗号化を行う暗号化部２４１と、パブリッククラウドから送出される暗号化された情報の復号化を行う復号化部２４２、更に、予め業務プログラム毎に設定される暗号化ポリシーと、同じく予め登録される暗号化鍵及び復号化鍵が記録される暗号化／復号化情報保持部２４３ａ、２４３ｂとで構成される。尚、暗号化ポリシーとは、どの業務プログラムからの何れの情報を如何様に暗合化するか、もしくは暗号化そのものを行わないかを記述したものである。
【００２３】
続いて、キューゲートウェイ部２２０が具備するリアルタイム処理部２２１の動作について、図７に基づいて説明する。業務プログラムからのデータベース更新要求を受けてデータベース更新要求処理部２３１は当該データベース更新要求をパラメータとしてリアルタイム処理部２２１を起動する。その際、リアルタイム処理部２２１は、遅延処理ポリシーを取得する（Ｓ７０１）。この遅延処理ポリシーは、予め読み込んでおいても良いし、データベース更新要求処理部２３１がパラメータとして渡すよう構成しても良い。取得した遅延処理ポリシーに「一括処理」の指定があるかを判別する（Ｓ７０２）。一括処理指定が無い場合は直ちにデータベースの更新を要求されたものとし、要求送出／結果受領部２５０に対し、データベース更新要求の宛先となるパブリッククラウドに宛てて、データベース更新要求を送出する（Ｓ７０３）。パブリッククラウド側にて当該データベース更新要求が正しく受信され、更新処理が成功したか否かを判別し（Ｓ７０４）、更新処理が成功した場合はその結果の受領を持ってデータベース更新要求処理部２３１に処理成功を通知し、処理を終了する。更新処理に失敗した場合、当該データベース更新要求をキュー要素として更新先のパブリッククラウドに対応する処理待ちキューに編入する（Ｓ７０５）。続いて遅延処理ポリシーに従って、後述の遅延処理スクリプトを作成し（Ｓ７０６）、遅延処理スクリプトに従って遅延処理部２２３の起動タイマーをセットする（Ｓ７０７）。
【００２４】
データベース更新処理要求に一括処理指定がある場合（ステップＳ７０２  ＹＥＳ）、一括処理に対応する遅延処理スクリプトが作成済みであるか否かを検索し、作成されていない場合（Ｓ７０８  ＹＥＳ）、遅延処理ポリシーに従って一括処理用の遅延処理スクリプトを作成する（Ｓ７０９）。作成済み、もしくは作成が完了した後、当該データベース更新要求をキュー要素として更新先のパブリッククラウドに対応する処理待ちキューに編入する（Ｓ７１０）。また、処理待ちキューに編入したキュー要素を指し示すポインタを、遅延処理スクリプトの処理単位リストの末尾に追加する（Ｓ７１１）。
【００２５】
遅延処理スクリプトについて以下に詳述する。遅延処理スクリプトのデータ構造を図１３に示す。遅延処理スクリプトはリアルタイム処理部２２１によってリアルタイムに更新を行わない若しくは行えない場合の遅延処理のスケジュール管理に必要な情報を格納したスクリプトである。「残りリトライ回数」は遅延ポリシーのリトライ回数を初期値とし、再試行が行われる毎に１ずつ減算されるものである。「リトライ間隔」は遅延処理ポリシーのそれと同義であり、更新処理に失敗し次の再試行が行われるまでの待機時間が格納される。このリトライ間隔に従って遅延処理部２２３の起動タイマーが設定される。「要求先変更までの残りリトライ回数」は、初期値を遅延処理ポリシーの「要求先変更タイミング」を初期値とし、「残りリトライ回数」と同様に再試行が行われる毎に１ずつ減算される。「変更後要求先」は遅延処理ポリシーの「変更後要求先」と同値とし、識別子に応じたパブリッククラウドが割り当てられ、要求先変更タイミングが０となった場合にデータベース更新処理要求の宛先を変更先のパブリッククラウドへ変更する。「遅延処理対象の処理要求へのポインタ」にはキュー要素として格納されたデータベース更新処理要求が、処理待ちキューの何れに位置するかのポインタが格納されており、これを参照することで遅延処理スクリプトによって遅延処理を行うデータベース更新処理要求を一意に特定することを可能とする。
【００２６】
尚、「遅延処理対象の処理要求へのポインタ」には「処理単位リスト」を格納することができる。「処理単位リスト」とは複数のデータベース更新処理要求を１つのトランザクションとして扱うためのリストであり、複数のキュー要素（即ちデータベース更新処理要求）へのポインタを一覧として格納するものである。例えば、日次バッチ処理で更新を行うと指定された複数のデータベース更新処理要求がなされた場合、前述のリアルタイム処理部２２１の動作を示すフローチャートに従って、「一括処理指定」が成された複数のデータベース更新処理要求は、一括処理するための同一の遅延処理スクリプトが割り当てられ、当該遅延処理スクリプトの「遅延処理対象の処理要求へのポインタ」に格納される「処理単位リスト」には、一括処理指定がされたデータベース更新処理要求を格納するキュー要素へのポインタが順次追加されていくことになる。
【００２７】
続いて、遅延処理部２２３の動作について、図８〜図１１に基づいて説明する。遅延処理ポリシーを取得する（Ｓ８０１）。リアルタイム処理部２２１と同様、遅延処理ポリシーを記憶部等から読み出し、パラメータとして渡される等、適宜手段を用いて読み出しができればその手段は問わない。遅延処理ポリシーの「一括処理」の指定の有無を判別する（Ｓ８０２）。「一括処理」の指定が無い場合（Ｓ８０２  ＮＯ）、遅延処理スクリプトを取得する（Ｓ８０３）。遅延処理スクリプトに従い、「遅延処理対象の処理要求へのポインタ」が指し示す処理待ちキュー内のキュー要素に格納されるデータベース更新要求を、更新先のパブリッククラウド宛に送出するよう、要求送出／結果受領部２５０に指示する（Ｓ８０４）。尚、このとき「要求先変更タイミング」が０の場合は、更新先のパブリッククラウドを「変更後要求先」に格納された識別子に応じて変更する。要求送出／結果受領部２５０にて更新先のパブリッククラウドから更新の成否を受領して更新処理の成否を判別し、失敗した場合（Ｓ８０５  ＮＯ）は、遅延処理スクリプトの「リトライ回数」と「要求先変更タイミング」を減算し（Ｓ８０６）、遅延処理スクリプトの「リトライ間隔」に従って遅延処理部２２３の起動タイマーをセットして処理を終了する（Ｓ８０７）。パブリッククラウドの更新処理に成功した場合（Ｓ８０５）、「遅延処理対象の処理要求へのポインタ」に格納される処理待ちキューへのポインタを参照し、該当するキュー要素を処理待ちキューから削除し（Ｓ８０８）、当該遅延処理スクリプトを削除して処理を終了する（Ｓ８０９）。
【００２８】
ステップＳ８０２にて、遅延処理ポリシーにおいて一括処理指定がなされている場合（Ｓ８０２  ＹＥＳ）の処理を図９に基づいて説明する。遅延処理スクリプトを取得し（Ｓ９０１）、「遅延処理対象の処理要求へのポインタ」に格納される処理単位リストを読み出し、その先頭のデータを選択する（Ｓ９０２）。処理単位リストが終端か否かを判別し（Ｓ９０３）、終端でない場合は処理単位リストが処理済みでないとし、選択中のポインタが指し示す処理待ちキューのキュー要素に格納されたデータベース更新処理要求を、遅延処理スクリプトに従ってパブリッククラウド宛に送出するよう、要求送出／結果受領部２５０に指示する（Ｓ９０４）。パブリッククラウドからの更新処理成功が通知され、要求送出／結果受領部２５０がこれを受領した場合（Ｓ９０５  ＹＥＳ）、処理単位リストのポインタを次のデータへと更新し（Ｓ９０６）、以降処理単位リストが終端となるまでステップＳ９０３〜ステップＳ９０６を繰り返す。
【００２９】
続いて、処理単位リストが終端である場合（ステップＳ９０３  ＹＥＳ）の動作について、図１０に基づいて説明する。処理単位リストの先頭のデータを再度選択する（Ｓ１００１）。処理単位リストが終端か否かを判別し、終端でない場合（Ｓ１００２  ＮＯ）は処理単位リストが処理済みでないとし、選択中のポインタが指し示す処理待ちキューのキュー要素に格納されたデータベース更新処理要求に対するコミット要求を、当該データベース更新処理要求の宛先となるパブリッククラウドへ送出するよう、要求送出／結果受領部２５０に指示する（Ｓ１００３）。コミット指示を送出したデータベース更新要求を格納するキュー要素を処理待ちキューから削除する（Ｓ１００４）。これを繰り返し処理単位リストが終端となったら（Ｓ１００２  ＹＥＳ）、遅延処理スクリプトを削除して処理を終了する（Ｓ１００５）。
【００３０】
続いて、更新処理に失敗した場合（ステップＳ９０５  ＮＯ）の動作について、図１１に基づいて説明する。更新に成功した全てのデータベース更新処理要求に対してロールバック処理を行う（Ｓ１１０１）。遅延処理ポリシーの一括処理オプションが２、即ち「一括処理し、一括処理不可の場合、ポリシーに従ってリトライする」であるかを判別し、２以外の場合（ステップＳ１１０２  ＮＯ）、処理単位リストを参照し処理単位リストが指し示す全てのキュー要素を処理待ちキューから一括削除し（Ｓ１１０３）、当該遅延処理スクリプトを削除して処理を終了する（Ｓ１１０４）。遅延処理ポリシーの一括処理オプションが２である場合（ステップＳ１１０２  ＹＥＳ）は、遅延処理スクリプトの「リトライ回数」と「要求先変更タイミング」を減算し（Ｓ１１０５）、遅延処理スクリプトの「リトライ間隔」に従って遅延処理部２２３の起動タイマーをセットして処理を終了する（Ｓ１１０６）。
【００３１】
続いて業務プログラムからパブリッククラウドの更新を行う際のクラウドポータルシステムの動作について説明する。図１７は、複数の更新要求を行う業務プログラムＡの具体的な処理内容を、疑似的なプログラムコードとして表記したものを示している。業務プログラムＡは、第１に複数の更新を１つのまとまった処理とするために、当該処理をグローバルトランザクションとして宣言する。以降、パブリッククラウドＰ１のデータベースＰＤ１の更新要求及びパブリッククラウドＰ２のデータベースＰＤ２の更新要求を２回ずつ行い、これら４つの更新要求に対してコミット処理を行ってプログラムを終了する、という内容となっている。
【００３２】
まず、グローバルトランザクションの開始が宣言される。このとき、業務プログラムＡからの処理要求を要求受付／結果返却部２１０が受け付け、これに基づきトランザクションゲートウェイ部２３０のデータベース更新要求処理部２３１が当該グローバルトランザクション用の遅延処理スクリプトを生成する。
【００３３】
続いて、業務プログラムＡから各パブリッククラウドのデータベースＰＤ１、ＰＤ２の更新要求がなされる。４つのデータベース更新要求の各々はトランザクションゲートウェイ部２３０のデータベース更新要求処理部２３１を介して、キューゲートウェイ部２２０のリアルタイム処理部２２１によって、図７のフローチャートの一括処理指定有のルートに基づいて、データベース更新要求の宛先となるパブリッククラウドに対応する処理待ちキュー保持部２２２ａ又は２２２ｂにキュー要素として編入される。更にリアルタイム処理部２２１は、当該グローバルトランザクション用の遅延処理スクリプトを更新する。出来上がった遅延処理スクリプトの「遅延処理対象の処理要求へのポインタ」には図１６に概念的に示されるキュー要素へのポインタリストたる「処理単位リスト」が作成され格納される。
【００３４】
続いて、コミット処理がなされる。以降、上記４つの更新要求が全て成功しデータベースの更新を正しく終えることができたケース（ケース１）、一部更新処理が失敗し且つ業務プログラムＡの遅延ポリシーに「処理中止」が指定されているケース（ケース２）、一部更新処理に失敗し且つ業務プログラムＡの遅延ポリシーに「遅延コミット（一定時間間隔でリトライ）」が指定されているケース（ケース３）のそれぞれについて説明する。
【００３５】
最初に、上記４つの更新要求が全て成功しデータベースの更新を正しく終えることができたケース１について説明する。業務プログラムＡからのグローバルトランザクションの終了宣言を要求受付／結果返却部２１０が受け付け、トランザクションゲートウェイ部２３０のコミット処理部２３２は遅延処理部２２３を起動し、図８〜図１１に示すフローチャートに従って処理を行う。即ち、キューゲートウェイ部２２０の遅延処理部２２３に対して、当該グローバルトランザクション用の遅延処理スクリプトの「遅延処理対象の処理要求へのポインタ」に処理単位リストとして格納されるポインタが示すキュー要素たるデータベース更新処理要求の全てを、対応するパブリッククラウド宛に送出するよう指示し、要求送出／結果受領部２５０はこれを送出し、パブリッククラウドから全ての更新処理が成功した旨の通知を受領し、これを受けて遅延処理部２２３によって当該グローバルトランザクションに関連する全てのキュー要素を処理待ちキューから削除し、対応する遅延処理スクリプトを削除する。以上のような手順によって処理がなされる。
【００３６】
次に、一部更新処理が失敗し且つ業務プログラムＡの遅延処理ポリシーに「１：一括処理し、一括処理不可の場合、全ての処理をロールバックする。」が指定されているケース２について説明する。上記成功例と同様に、業務プログラムＡからのグローバルトランザクションの終了宣言を要求受付／結果返却部２１０が受け付け、キューゲートウェイ部２２０の遅延処理部２２３に対して、当該グローバルトランザクション用の遅延処理スクリプトの「遅延処理対象の処理要求へのポインタ」に格納される処理単位リストが指し示すポインタに対応するキュー要素たるデータベース更新要求を、パブリッククラウド宛に送出するよう指示し、要求送出／結果受領部２５０はこれを送出する。このとき、パブリッククラウドの更新について４つあるうちの最後の１つの更新処理が何らかの原因によって失敗した場合を想定する。このとき、続く処理は図９のフローチャートのステップＳ９０５の更新処理の成否判別のＮＯのルート、即ち図１１のフローチャートに従って行われる。まず、遅延処理部２２３に対して成功した３つの更新処理を取り消すために各パブリッククラウドのデータベースに対してロールバックを行うよう要求する。続いて遅延処理ポリシーに「１」が指定されていることから、ステップＳ１１０２の遅延コミット指定の判別はＮＯのルートとなり、当該グローバルトランザクションに関連する全てのデータベース更新処理要求を処理待ちキューから削除し、対応する遅延処理スクリプトを削除する。以上のように、グローバルトランザクション処理であって複数のパブリッククラウド宛ての更新処理において一部で成功した更新処理があったとしても、同一のグローバルトランザクション内の他の更新処理で１つでも更新に失敗した場合は、全てロールバックされる。
【００３７】
続いて、一部更新処理に失敗し且つ業務プログラムＡの遅延処理ポリシーに「２：一括処理し、一括処理不可の場合、ポリシーに従ってリトライする。」が指定されているケース３について説明する。上述の例と同様４番目の更新処理、つまりプライベートクラウドＰ２のデータベースＰＤ２への更新が失敗したものとして説明する。図８のフローチャートのステップＳ１１０２の判別まではケース２と同様に処理される。遅延処理ポリシーには「２」が指定されていることから、ステップＳ１１０２の遅延コミット指定の判別はＹＥＳのルートとなる。遅延処理スクリプトに従って、処理待ちキュー保持部２４２ａ及び２４２ｂに保持される各パブリッククラウドに対応する処理待ちキューから当該グローバルトランザクションに関連するキュー要素として格納される未実行の更新要求、この場合４番目のプライベートクラウドＰ２のデータベースＰＤ２への更新要求に対応するキュー要素のポインタを、処理単位リストとして遅延処理スクリプトの「遅延処理対象の処理要求へのポインタ」に更新し、遅延処理スクリプトの残りリトライ回数を減算し、リトライ間隔に格納された設定値に応じて遅延処理部２２３を起動するようタイマーをセットする。当然、「変更後要求先」が設定されているのであれば、「要求先変更までの残りリトライ回数」についても減算する。
【００３８】
これによって失敗した４番目の更新要求を再試行することができ、再試行の結果更新に成功した場合は、ケース１と同様に処理待ちキュー保持部２２２ａ及び２２２ｂの処理待ちキューから当該グローバルトランザクションに関連するキュー要素を全て削除し、遅延処理スクリプトを削除する。また、再試行の結果更新処理に失敗をし、その回数が遅延処理スクリプトに設定された「リトライ回数」に達した場合は、ケース２と同様に遅延処理部２２３に対して成功した３つの更新処理を取り消すために各パブリッククラウドのデータベースに対してロールバックを行うよう要求すると共に、当該グローバルトランザクションに関連する全てのキュー要素を処理待ちキューから削除し、対応する遅延処理スクリプトを削除する。
【００３９】
続いて、セキュアゲートウェイ部の動作について説明する。図１４（ａ）に示すように、パブリッククラウドサービスを活用する以前の業務プログラムは、閉鎖されたネットワーク上に設けられた処理システム及びデータベースから構成されることから、各々の処理要求は返却された結果などは平文でやり取りされている。この業務プログラムで用いるデータの管理にパブリッククラウドを用いるよう図１４（ｂ）のように構成しようとすると、業務プログラムはパブリッククラウド処理システムが予め具備する暗号化機能にそのセキュリティポリシーとセキュリティ施策を委ねることになる。往々にしてパブリッククラウドのセキュリティポリシーとセキュリティ施策は明確に可視化されることはなく、ユーザはパブリッククラウドの業務プログラムによる利用の際には、パブリッククラウド側のセキュリティポリシーに合わせて、秘匿しなくてもよい情報のみをパブリッククラウドへ、秘匿すべき情報は別途セキュアデータセンターに蓄積するといった構成する必要がある。しかしながら、それを行うには業務プログラム側でセキュリティポリシーの異なる２以上のデータベースにアクセスするよう構築し直す必要があり、更に何れのデータベースにどの情報を管理するかを分類する必要がある。大規模な業務プログラムであると、このような作業を行うには多大な工数が必要となり、パブリッククラウドを業務プログラムにて利用することの大きな障害となっている。しかしながら業務プログラムにとって、例えば障害発生時のデータ破損等データ維持に関する堅牢性や、大きなエリアで展開する端末からのアクセスの容易性等において強力なメリットを有するパブリッククラウドのメリットは計り知れないものがある。
【００４０】
そこで本実施例では図１及び図４に示すように、業務プログラムＡとパブリッククラウドＰ１及びＰ２の間に配されるセキュアデータセンター１００のクラウドポータルシステム２００に、セキュアゲートウェイ部２４０を設け、業務プログラムＡから更新要求が成される平文である値を暗号化部２４１によって暗号化し、暗号化された値によってデータベース更新要求を生成し、パブリッククラウドＰ１、Ｐ２のデータベースＰＤ１、ＰＤ２の更新を行うよう構成する。更に業務プログラムＡからの要求によってパブリッククラウドのデータベースＰＤ１またはＰＤ２から暗号化された値を取得し、復号化部２４２を介して復号化して平文の値を業務プログラムＡに返却するよう構成する。その際、業務プログラム毎に暗号化ポリシー保持部２４３ａ、２４３ｂ・・・を具備し、暗号化及び復号化のポリシー、暗号化鍵及び復号化鍵を業務プログラム毎に個別に設定登録する。
【００４１】
このように構成することで、図１４（ｃ）に示すように業務プログラムには特別な改修をせずとも、業務プログラム固有のセキュリティポリシーに従った値の暗号化を行った上でパブリッククラウドに登録することができ、暗号化された値をパブリッククラウドから取得した際も容易に復号化を行うことができる。また業務プログラム毎に暗号化／復号化のポリシー、暗号化鍵及び復号化鍵を設定することができるので、例えばセキュリティポリシーの異なる業務プログラムであっても同一のクラウドポータルシステムにて管理し、パブリッククラウドの利用を可能とする。従ってセキュアデータセンター１００内にて複数事業者の業務プログラムを稼働させたとしても、事業者ごと、業務プログラム毎に個別のセキュリティポリシーを適用することが可能となる。
【００４２】
以上のようなクラウドポータルシステムによれば、一般に公開されたパブリッククラウドサービスを利用する場合であっても、パブリッククラウドサービス側に送信するデータであって秘匿性を確保する必要があるデータに対しては暗号化を行って送信し、また当該暗号化されたデータを受信する際にはクラウドポータルシステムによって復号化して受信するので、ユーザはデータの暗号化及び復号化を意識せずに行うことができ、パブリッククラウドサービスの利便性を確保しつつ信頼性を著しく向上させることができる。
【００４３】
また、業務プログラムからの処理要求が何らかの要因で失敗した場合であっても、遅延処理部による更新要求のリトライ機能によって自動的に更新処理の再試行を行うことができ、利便性の向上を図ることができる。
【００４４】
更に、複数のパブリッククラウドサービスに対して一括処理にて更新を行うようなクラウドコンピューティングが必要なケースであっても、個別のパブリッククラウドサービスへの更新の成否を人的な運用などで判別する必要がなく、グローバルトランザクション処理を可能とし、システムの利便性及び信頼性が著しく向上する。
【００４５】
上述したクラウドポータルシステム１００に別途記憶部を設け、パブリッククラウドへの更新内容と同一の内容を当該記憶部に更新することでパブリッククラウドのミラーリングを行うことで、若しくはパブリッククラウドから定期的に全データを取得して記憶部に記憶することで、バックアップとするよう構成することで、クラウドポータルシステム１００の更なる堅牢性、信頼性の向上を図ることも可能である。
【００４６】
以上、本発明の実施例について詳述したが、本発明は前記実施例に限定されるものではなく、本発明の要旨の範囲内で種々の変形実施が可能である。例えば業務プログラムをＡの１種、パブリッククラウドサービスをＰ１及びＰ２の２種のケースとして説明したが、これに限定するものではなく、これ以上の業務プログラム及びパブリッククラウドサービスを複数組み合わせて用いたとしても何ら問題なく、業務プログラムの数もパブリッククラウドの数も任意に変更することができる。また遅延処理ポリシー及び遅延処理スクリプトは、図１２及び図１３に限定するものではなく、利便性等を勘案して適宜設定すればよい。また、遅延処理を担うキューゲートウェイ部２２０と、グローバルトランザクション機能を担うトランザクションゲートウェイ部２３０、暗号化／復号化機能を担うセキュアゲートウェイ部２４０はそれぞれ個別に利用することができ、また任意の組み合わせにて運用することもできることは言うまでもない。例えば、とあるファイルを１乃至複数暗号化してパブリッククラウドサービスに登録したい場合はセキュアゲートウェイ部２４０のみを利用すればよく、そのファイルの登録の際に失敗した場合再試行を自動化したいのであればキューゲートウェイ部２２０を用いるよう設定すればよいし、また、グローバルトランザクションを用いた複数のパブリッククラウド宛の更新においても、セキュアゲートウェイ部２４０を介した上でキューゲートウェイ部２２０やトランザクションゲートウェイ部２３０の処理を行うことで、複数のパブリッククラウドに対して自動的に暗号化したデータによって更新処理を行うことができ、また処理結果についても業務プログラムに返却する以前に復号化を終えておくことができるので、業務プログラム側が特に意識することなく、高度なセキュリティ性を実現することが可能となる。
【符号の説明】
【００４７】
１００    セキュアデータセンター
Ａ        業務プログラム
２００    クラウドポータルシステム
２１０    要求受付／結果返却部
２２０    キューゲートウェイ部
２２１    処理待ちキュー作成部
２２２ａ、ｂ  処理待ちキュー保持部
２２３    遅延処理部
２２４ａ、ｂ  遅延処理ポリシー保持部
２３０    トランザクションゲートウェイ部
２３１    データベース（ＤＢ）更新処理要求部
２３２    コミット処理部
２４０    セキュアゲートウェイ部
２４１    暗号化部
２４２    復号化部
２４３ａ、ｂ  暗号化／復号化情報保持部
２５０    要求送出／結果受領部
Ｐ１、Ｐ２  パブリッククラウドサービス
ＰＳ１、ＰＳ２  処理システム
ＰＤ１、ＰＤ２  データベース
【図１】
2015060286.tif 000003
【図２】
2015060286.tif 000004
【図３】
2015060286.tif 000005
【図４】
2015060286.tif 000006
【図５】
2015060286.tif 000007
【図６】
2015060286.tif 000008
【図７】
2015060286.tif 000009
【図８】
2015060286.tif 000010
【図９】
2015060286.tif 000011
【図１０】
2015060286.tif 000012
【図１１】
2015060286.tif 000013
【図１２】
2015060286.tif 000014
【図１３】
2015060286.tif 000015
【図１４】
2015060286.tif 000016
【図１５】
2015060286.tif 000017
【図１６】
2015060286.tif 000018
【図１７】
2015060286.tif 000019