JP5084827B2 - 永続性を管理する方法、装置、及びコンピュータ・プログラム - Google Patents

Description

本発明は、メッセージング・システム、ファイル・システム、データベースのようなデータ処理システムの永続性管理に関するものである。

既知のいくつかのメッセージング・システムは、メッセージ状態情報及びメッセージが永続ストレージ（即ち、ディスク・ストレージのような不揮発性ストレージ）内のログ及びメッセージ・キュー・データ・ファイルに保存される「永続（ｐｅｒｓｉｓｔｅｎｔ）」メッセージングを提供する。永続的に記憶されたメッセージは、メッセージング・システムの大部分の障害から再始動に至る過程を乗り切ることができる。ディスク障害以外の障害が発生した場合にも、ログ・データ及び永続的に記憶されたキューからメッセージ状態情報とメッセージとを復元することができる。永続メッセージ及び状態情報の復元可能性は、保証された１回限りのメッセージ配信（ｏｎｃｅ−ｏｎｌｙ ｍｅｓｓａｇｅ ｄｅｌｉｖｅｒｙ）を実現する上で重要な要因となる。

例えば、メッセージング・マネージャは、メッセージに関する動作が無事実行されたことをアプリケーション・プログラムに確認する前に永続メッセージをディスク・ストレージに保存することができる。典型的なメッセージング・ネットワークでは、メッセージ送信側のアプリケーション・プログラムがＡＰＩコールを介し「put_message」命令を発行して出力メッセージをキューに入れる。ローカル・メッセージング・マネージャ・プログラムがこのキューの管理を行い、分散メッセージング・ネットワーク内の他のローカル・アプリケーション・プログラム又は他のメッセージング・マネージャと通信して当該メッセージをターゲット受信者に転送する。永続メッセージング・システムにおいて、ローカル・メッセージング・マネージャは、「put_message」動作が無事完了したことを送信側アプリケーションに確認する前にメッセージを永続ストレージに保存する。（同期点マネージャによって現在制御されている「作業単位（ｕｎｉｔ ｏｆ ｗｏｒｋ）」からメッセージが除外されるいくつかの実施形態では）永続メッセージ又はメッセージに関するデータは、メッセージを宛先に転送するために「put_message」及び「get_message」が実行される度にディスクに書き込むことも、現在の作業単位がコミットされたときにだけメッセージをログに記録することもできる。分散作業単位を用いると、メッセージ転送中にいくつかの中間ポイントへのログの書き込みを回避することが可能となるが、「永続」メッセージとして識別されたメッセージは、事前定義されたポイントの永続ストレージに書き込まれることになる。

これとは対照的に、「非永続」メッセージはディスクに保存されないため、メッセージング・マネージャに障害が発生し再始動の必要が生じたとき、ならびにメッセージング・マネージャがオペレータ・コマンドによって停止されたときは廃棄されることになる。永続メッセージングは復元可能性及び保証されたメッセージ配信の観点では多くの利点をもたらすが、性能コストも伴う。「put_message」及び「get_message」処理が行われる度にディスク書き込みを行えば、メッセージのスループットが低下しアプリケーションの応答回数が増加するため、一部のメッセージを非永続的に処理することには事業上の正当な理由が存在しなければならない。

保証されたメッセージ配信と性能との間にはトレードオフの関係が存在するため、ＩＢＭコーポレーションのＷｅｂＳｐｈｅｒｅ ＭＱファミリー製品にはメッセージのオプション属性として永続設定又は非永続設定のサポートが含まれており、永続メッセージングの性能の改善に向けた様々な取り組みがなされている（「ＷｅｂＳｐｈｅｒｅ」及び「ＩＢＭ」はインターナショナル・ビジネス・マシーンズ・コーポレーションの商標である）。性能は、高性能ディスク・ストレージの使用、障害不存在下の性能を最適化するコミット処理技法の使用、ならびに障害に対処する効率的な復元技法の使用によって改善されている。例えば、１９９４年３月２３日に出願されＩＢＭコーポレーションに譲渡された米国特許第５，４５２，４３０号には、永続データ及び非永続データを単一のメッセージ・キュー内の別個のページ・セットに格納することにより、システム障害からの復旧中に生じる遅延を低減することを目的とする永続メッセージ及び非永続メッセージ処理の解決策が記載されている。Ｃ． Ｍｏｈａｎ及びＤ． Ｄｉｅｖｅｎｄｏｒｆｆの「Ｒｅｃｅｎｔ Ｗｏｒｋ ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｍｉｔ Ｐｒｏｔｏｃｏｌｓ， ａｎｄ Ｒｅｃｏｖｅｒａｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ」、ＩＥＥＥ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ Ｂｕｌｌｅｔｉｎ、１７（１）、２２〜２８ページ（１９９４年）には、分散コミット・プロトコルならびに復元可能メッセージング／キューイングに関する分野の開発技術が記載されている。
Ｃ． Ｍｏｈａｎ及びＤ． Ｄｉｅｖｅｎｄｏｒｆｆの「Ｒｅｃｅｎｔ Ｗｏｒｋ ｏｎ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｍｍｉｔ Ｐｒｏｔｏｃｏｌｓ， ａｎｄ Ｒｅｃｏｖｅｒａｂｌｅ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ」、ＩＥＥＥ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ Ｂｕｌｌｅｔｉｎ、１７（１）、２２〜２８ページ（１９９４年） 米国特許第５，４５２，４３０号

しかしながら、典型的なメッセージング・システムでは依然として永続性指定の柔軟さがあまり改善されていない。１つの提案としては、定義された異なるシステム状態に応じて異なる永続性を指定する機会をメッセージング・システムのユーザに与えるものがある。そのようなメッセージング・システムでは永続性の制御の粒度が高まることからユーザに利点がもたらされるが、永続性ポリシーが指定されたときに永続性の挙動は固定化される。

メッセージの永続性が所望の特性として指定された場合にも、典型的なメッセージング・システムではメッセージの保全性の確保にシステムの過剰なリソースがつぎ込まれてしまう。多くの応用分野において、個々のメッセージの大半は事業価値が低くそのような投資を正当化するに足る理由が見出せないが、典型的な従来技術の解決策では、価値が異なるメッセージ同士を区別することができず、メッセージの永続化コスト又はメッセージの非永続化リスクを考慮に入れることができない。

性能と永続性とのトレードオフの関係は、メッセージング・システムだけでなくデータベース、ファイル・システム、及び他の永続システムにも当てはまる。データベース・システムでは、データは典型的には永続的に保存されるが、低オーバーヘッドのストレージ・ソリューションでもクエリ／構造化機能の利益を享受することができるように、永続ストレージへの書き込みが強制されないいくつかのテーブルが記憶されることも知られている。このような「軽量な」データベース・ソリューションへの動きが進むにつれ、柔軟な永続性管理手法の必要性も益々高まっている。例えばアプリケーション・サーバ用の構成データをファイル・システム内でＸＭＬファイルの形で保持する等、データの信頼性を高めるために、ファイル・システムの利用頻度は益々高まっている。近年、トランザクション・ファイル・システムの需要が益々高まっているが、現行の解決策では柔軟な永続性制御が実現されていない。

本発明の第１の態様は、永続ストレージに保存するコスト、又は永続ストレージに保存しないことに関連するリスクに関する少なくとも１つの基準の評価に従って、データ処理システム内のデータの永続性を管理する方法を提供する。この評価は、ディスク書き込みが行われる時点で実行することもできるが、データ更新処理中の様々な時点でデータ処理ネットワーク内の様々なポイントで実行することもできる。

本発明は、データを永続ストレージに保存するメッセージング・システム、データベース・システム、ファイル・システム、及び他のデータ処理システム内で実施することができる。本発明の第１の実施形態は、メッセージング・システム内の少なくとも１つの基準の動的評価に従ってメッセージの永続性を管理する方法を提供する。前記評価は、前記メッセージが発信元エンティティによって作成され送信された後に実行される点で動的に実行される。前記方法は、永続ストレージへの保存に関するリソース・コストもしくは性能コスト、又は利益、あるいはその両方に従って、前記メッセージに関するメッセージ・データ又はログ・レコードあるいはその両方を永続ストレージに保存する必要があるかどうかを判定するステップを含む。

この文脈では、特定のメッセージの永続性判定を行うときに検討される永続ストレージへの保存（「永続化」）の利益に関しては、当該特定のメッセージの価値及びメッセージに関するデータの損失リスク及び二重化リスクが考慮に入れられることが好ましい。永続化の利益に関しては、メッセージの損失又はメッセージ配信の二重化あるいはその両方に関する潜在的なコスト、あるいは別の処理操作の二重化に関する潜在的なコストが考慮に入れられることが好ましい。例えば、メッセージの損失「コスト」は、個々のメッセージの重要度に基づくものであっても、定義されたサービス品質要件を満足させるメッセージング・システムの能力に基づくものであってもよい。永続化の「コスト」に関しては、好ましくは現時点の使用可能リソースと、内部永続キューの競合のようなリソース制約とに従って、永続ストレージへの書き込みを実行した場合の影響が考慮に入れられることが好ましい。

永続ストレージに保存すべきかどうかの判定は、メッセージがネットワーク内のローカル・メッセージング・マネージャを介して又はメッセージング・システムのネットワークを介して送信側アプリケーションから受信側のターゲット・アプリケーションに転送されるときに、様々なポイントで実行することができる。例えば、周知のとおり、送信側アプリケーションは「put_message」コマンドを発行して、ローカル・メッセージング・マネージャによって管理されるキュー上にメッセージを配置することができ、ローカル・メッセージング・マネージャ（又は「キュー・マネージャ」）は、当該メッセージをネットワーク内の次のメッセージング・マネージャに転送することができ、当該メッセージがターゲット・アプリケーションのローカル・メッセージング・マネージャに到達するまで、以下同様にメッセージの転送を行うことができる。その後、ターゲット・アプリケーションは、ローカル・メッセージング・マネージャによって保持されるメッセージ・キューからメッセージを取得する。本発明によれば、永続性判定は、該当する通信経路内の各メッセージング・マネージャにおいて実行することができるが、メッセージは、各メッセージング・マネージャに影響を及ぼす動的特性に応じて１つのメッセージング・マネージャにおいて永続化されると、それ以外のメッセージング・マネージャにおいて永続化されることはない。

このように永続ストレージへの書き込みを行うべきかどうかの判定が繰り延べられ、状況に応じてその判定が繰り返されることは、メッセージが作成される時点又はメッセージが最初に送信される時点で永続性の挙動が定義される典型的なメッセージング・システムとは大きく異なる点である。

例えば、メッセージが第１のキュー・マネージャＱＭ１から第２のキュー・マネージャに迅速に移動される場合は、当該メッセージは必ずしもＱＭ１において永続的に保存する必要はない可能性がある。その後、最終使用側アプリケーションが低速又は非アクティブである故にメッセージがある期間にわたってＱＭ２で待機することになる場合は、当該メッセージをＱＭ２において永続化することができる。「ムーバ」（メッセージ・チャネル・エージェントとしても知られる）は、ＱＭ１上の伝送キューからＱＭ２上のキューへのメッセージの移動を担当するメッセージ・キュー・マネージャ・コンポーネントである。ＱＭ１によって管理されるキューにメッセージが入れられるときにムーバが低速な場合又は非アクティブ状態にある場合は、当該メッセージをＱＭ１において永続化することができる。ムーバがメッセージを最終的に移動する時点で使用側アプリケーションがアクティブ状態となった場合は、当該メッセージをＱＭ２において永続化する必要がなくなる可能性がある。上記の例は、メッセージを永続的に記憶すること又はメッセージに対して実行された操作をログに永続的に記録することが望ましいかどうか、及びそのような処理をいつ行うのが望ましいのかを柔軟且つ動的に判定することから得られ得る効果の単なる例示にすぎない。追加的な例については以下の「発明を実施するための最良の形態」のセクションで説明する。

本発明の一実施形態は、メッセージング・システムを介してメッセージが処理されている間に前記メッセージの永続性を管理する方法であって、データを永続ストレージに保存するコストと、データを永続ストレージに保存しないことに関連するリスクとを表す１組の基準のうちの少なくとも１つの基準を評価して、前記メッセージに関するデータを永続ストレージに保存する必要があるかどうかを判定するステップと、前記評価するステップにおいて永続ストレージへの保存が必要であると判定されたことに応答して、前記メッセージに関するデータを永続ストレージに保存するステップと、を含む方法を提供する。

第２の実施形態は、データベース内のデータの永続性を管理する方法であって、データを永続ストレージに保存するコスト又は利益を表す少なくとも１つの基準を評価して、前記データを永続ストレージに保存する必要があるかどうかを判定するステップと、前記評価するステップにおいて永続ストレージへの保存が必要であると判定されたことに応答して、前記データを永続ストレージに保存するステップと、を含む方法を提供する。前記評価は、特定のデータの挿入、削除、又は更新を対象に実行することができ、あるいは前記データベースに影響を及ぼす１組の操作を対象に実行することができる。

本発明のもう一つの態様は、上述の方法を実施する永続性マネージャを含むデータ処理システム、例えばデータベース・システム又はメッセージング・システムを提供する。本発明の一実施形態に係るデータ処理システムは、揮発性データ・ストアと、不揮発性データ・ストアと、前記揮発性データ・ストア内に保持されているデータベース・テーブルに対してデータ更新を適用するデータベース・マネージャと、データ更新を前記不揮発性データ・ストアに保存する必要があるかどうかを判定する永続性マネージャと、を備える。前記永続性マネージャは、前記不揮発性データ・ストアへの保存のコスト又は利益を表す少なくとも１つの基準を評価して、前記データ更新を前記不揮発性データ・ストアに保存する必要があるかどうかを判定し、その後前記データ更新の前記不揮発性データ・ストアへの保存を開始することによって正判定に応答する。

一実施形態に係るメッセージング・システムは、ランダム・アクセス・メモリのような揮発性データ・ストアと、ディスク・ストレージのような不揮発性データ・ストアと、メッセージ配信を処理するメッセージング・マネージャと、メッセージに関するデータを前記不揮発性データ・ストアに保存する必要があるかどうかを判定する永続性マネージャと、を備える。前記永続性マネージャは、前記不揮発性データ・ストアへの保存のコスト又は利益を表す少なくとも１つの基準を評価して、メッセージに関するデータを前記不揮発性データ・ストアに保存する必要があるかどうかを判定する。前記永続性マネージャは、永続ストレージへの保存に関する現在のリソース・コスト又は利益あるいはその両方に従って、前記メッセージに対する操作が実行された時点又はその後のある時点で上記の判定を動的に実行することができる。前記永続性マネージャは、前記評価するステップにおいて永続ストレージへの保存が必要であると判定されたことに応答して、メッセージに関するデータの前記不揮発性データ・ストアへの保存を開始する。

本発明の一実施形態では、永続ストレージへの保存を行うべきかどうかの前記判定は、ログ書き込みが行われる直前に実行され、その結果、どの操作をログ書き込みに含めるべきかがチェックされる。別の実施形態では、前記判定は非同期警告によってトリガされ、例えば該当するキューを処理している前記アプリケーション・プログラム又はメッセージ・チャネル・エージェントがシャット・ダウンされたことに応答して、又は前記キュー深度がメッセージの閾値数を超えたことに応答して、又はメッセージがキューに入っている時間が閾値のミリ秒数を超過したことに応答してトリガされる。

本発明の第３の態様は、データ処理システム内の操作の実行を制御する１組の命令を備え、上述の方法を実施するコンピュータ・プログラムを提供する。前記コンピュータ・プログラムは、前記１組の命令が記録媒体又はデータ転送媒体上に記録されたコンピュータ・プログラム・コードによって実行されるコンピュータ・プログラム製品として提供されることが好ましい。そのようなコンピュータ・プログラム・コードは、データ通信媒体を介して転送することが可能な形で提供され得る。

以下では例示として、添付図面を参照しながら本発明の諸実施形態についてより詳細に説明する。

本発明は、単一のデータ処理システム内、又は分散データ処理ネットワーク内で実施することができ、新規性ある永続性管理手法を実施することにより、いくつかの既存のデータ処理システムよりも高い柔軟性を提供することができる。以下では、メッセージング・ネットワーク内で使用される本発明の第１の実施形態について説明する。

典型的な分散メッセージング・ネットワークは、通信リンク２０を介して接続される複数のデータ処理システム１０、１５を備える。図１には２つのデータ処理システムが相互接続された単純なネットワークが例示されているが、メッセージング・ネットワークは例えば数百の別個のデータ処理システムを含むことができる。メッセージング・ネットワーク内の各データ処理システム１０、１５は、コンピュータ・プログラム・コードの形であるいは電子回路を使用したハードウェアの形で実装され得るメッセージング・マネージャ３０、３５を含む。特定のデータ処理システム１０上のメッセージング機能は、業務処理を実行するアプリケーション・プログラム４０及び４１と統合することもできるが、本実施形態では、アプリケーション・プログラム４０、４１、４５と、メッセージング・マネージャ３０、３５とは、相互動作する別個のコンピュータ・プログラムである。アプリケーション・プログラム４０、４１、４５は、メッセージング・ネットワークを介して互いに通信することができ、それぞれメッセージング・インターフェース（ＡＰＩ）５０、５５を介してローカル・メッセージング・マネージャ３０、３５と通信することができる。各メッセージング・マネージャ３０、３５は、ハードウェア・プロセッサ（図示せず）の処理機能に依存し、それらが実行されるデータ処理システム上のオペレーティング・システム（図示せず）から提供されるサービスに依存する。各メッセージング・マネージャ３０、３５は、ネットワーク内のシステム間におけるオペレーティング・システムの差異に対応するためにデータ変換を行う必要があれば、そのようなデータ変換を実行する。当業界で周知のとおり、上述したデータ処理システム内の各コンポーネント、ランダム・アクセス・メモリ７０、７５、ならびに不揮発性ディスク・ストレージ９０、９５は通信バスを介して接続される。

本発明はいくつかの従来型データ処理システムのハードウェア及びオペレーティング・システム・アーキテクチャに適用可能であるので、本明細書では既知のデータ処理システムの標準的な特徴については詳述しない。

図１のメッセージング・システム・アーキテクチャは、比較的単純なアプリケーション・プログラム開発を容易にし、典型的な異種分散データ処理環境内の多種多様なコンポーネント間の統合及び相互動作に関連する問題の多くを解決する。一般的なメッセージング機能はメッセージング・マネージャ３０、３５内で実行することができ、アプリケーション・プログラム４０、４１、４５を書くことにより、それぞれメッセージングＡＰＩ ５０、５５を介して各ローカル・メッセージング・マネージャの機能をコールすることができる。ＩＢＭコーポレーションのＷｅｂＳｐｈｅｒｅ ＭＱメッセージング・マネージャのようなメッセージング・マネージャ３０、３５は、各メッセージング・マネージャによって管理されるメッセージ・キューを利用した非同期メッセージ通信を実現する。

例えば、第１のデータ処理システム１０上で実行される第１のアプリケーション・プログラム４０は、ローカル・メッセージング・マネージャ３０によって管理される伝送キュー１００上にメッセージを配置することによってリモート・アプリケーション・プログラム４５と通信することができる。ローカル・アプリケーション・プログラム４５の伝送キュー１００や入力キュー１１０のようなメッセージ・キューは単純に、対応するメッセージング・マネージャが１つのプログラムから別のプログラムに移行する間にメッセージを保持するために予約するストレージ領域である。図１ではメッセージング・マネージャの要素として概略的に示されているが、メッセージ・キュー１００、１０５、１１０は、後述するように揮発性ランダム・アクセス・メモリ７０、７５に保持され、永続性マネージャ８０、８５の制御下でディスク・ストレージ９０、９５に固定（ｈａｒｄｅｎ）される。

通信チャネル２５は、第１のシステム１０とリモート・システム１５との間の通信リンク２０を介して１対のメッセージ・チャネル・エージェント（又は「ムーバ（ｍｏｖｅｒ）」）６０、６５間で確立される。ローカル・メッセージング・マネージャは、伝送キュー１００内に配置されたメッセージのヘッダーを検査してメッセージを経路指定すべきネットワーク内の次のメッセージング・マネージャを判定し、その後ムーバ６０、６５は、伝送キュー１００から第２のメッセージング・マネージャ３５によって管理されるキューへの関連メッセージの転送を担当する。第２のメッセージング・マネージャが宛先メッセージング・マネージャまでの経路上の単なる中間ノードにすぎない場合には、メッセージを次のネットワーク・ノードに転送することができるようになるまで、新しいキューはやはりメッセージの一時レポジトリとして働く伝送キュー１００となるが、第２のメッセージング・マネージャが宛先アプリケーション・プログラム４５のローカル・メッセージング・マネージャである場合には、そのメッセージを処理するアプリケーション・プログラム４５の準備が整ったときに、アプリケーション・プログラム４５からサービスされるアプリケーション入力キュー１１０内に配置される。

メッセージを第１の伝送キュー１００上に配置するステップと、当該メッセージをアプリケーション入力キュー１１０に移動するステップと、アプリケーション・プログラム４５が当該メッセージを入力キュー１１０から取得するステップとは、アプリケーション・プログラム４０とアプリケーション・プログラム４５との間の永続的な専用接続が必要とならないように非同期的に実行される。図１には示されていないが、第１の送信側システム１０からリモートの宛先システム１５までのネットワーク内に複数の非同期ホップが存在する可能性もある。

いくつかの既知のメッセージング・システムでは、システム管理者又は送信側アプリケーションの指定に従ってメッセージを永続的に送信することも非永続的に送信することもできる。永続性マネージャ８０、８５は、通信中のアプリケーション・プログラム又はメッセージング・マネージャから必要とされる（それらのアプリケーション又はメッセージング・マネージャ間で送信されるすべてのメッセージについて必要とされ、又は特定のメッセージについてのみ必要とされる）指定の永続性に従って、メッセージを永続ストア９０、９５（例えば不揮発性ディスク・ストレージ）に書き込む。永続メッセージは、それ自体が送信側アプリケーションのローカル・メッセージング・マネージャ３０によって第１の伝送キュー１００上に配置されている場合にはローカル永続ストア９０に保存することができ（即ち、第１の伝送キュー１００のコピーをディスク・ストレージに保存することができ）、それ自体が伝送キュー１００に入れられた場合、ならびにそれ自体が伝送キュー１００からアプリケーション入力キュー１１０に無事移動された場合には、ローカル・ログ・レコードをローカル永続ストア９０に書き込むことができる。メッセージがアプリケーション入力キュー１１０内に配置されている場合には、当該メッセージ及び関連するログ・レコードを第２のシステム１５上の第２の永続ストア９５に書き込むことができ、当該メッセージがターゲット・アプリケーション・プログラム４５によってアプリケーション入力キュー１１０から取得されたときは、やはりログ・レコードの書き込みを行うことができる。

いくつかのメッセージング・システムでは、システム障害後の復旧を可能にする上でログ・レコードが必要とされるため、ログ・レコードは、メッセージをキューに入れる操作又はメッセージをキューから取得する操作が完了と定義される前に書き込まなければならない。しかしながら、（通常のシステム・シャットダウン時の強制的な遅延書き込みを除いたバックグラウンド・タスクとして）キューの永続コピーの更新を書き込む際に「遅延が生じる（ｌａｚｉｌｙ）」こともある。

ログ・レコードが永続的に書き込まれる場合に実現され得るメッセージ配信の復元可能性と、その結果得られる保証されたメッセージ配信の利点があるにも関わらず、そのようなディスク書き込みは性能の大きなボトルネックとなっている。いくつかの既知のシステムは、ログ・レコードがディスクに固定される回数（即ち、ｐｕｔ操作、ｇｅｔ操作、又は他の更新操作が行われる時点ではなく、分散作業単位がコミットされた時点の永続ストレージに対する書き込み回数）を少なくする分散トランザクションをサポートしている。多数の操作が並列実行されるいくつかの既知のシステムは、複数の操作に関するログ・レコードを単一のバッファ内で組み合わせ、それらのログ・レコードを同時にディスクに強制移動（ｆｏｒｃｅ）する。これらの特徴は性能の改善に寄与するが、永続性及びログ処理は依然として性能のボトルネックとなる。

提案されている１つのシステムでは、ユーザは所望の永続性ポリシーを指定して、異なるシステム状態に応じて異なる永続性の挙動を設定することができる。しかしながら、永続性の挙動はやはり永続性要件が指定されるときに事前定義されるため、現状への動的な対応ならびに永続ストレージへの保存のコスト及び利益の点で考えると、真の意味での柔軟性は実現されていない。

本発明は、必要とされる永続性を事前定義によって指定する柔軟性の低い操作の制約を回避することにより、柔軟性を大幅に高めることができる。メッセージ価値（ｍｅｓｓａｇｅ ｖａｌｕｅ）ならびに永続ストレージへの保存のコスト及び利益を含めた１組の基準に基づいて行われる、永続ストレージへの保存を行うべきかどうかの繰り延べ判定（ｄｅｆｅｒｒｅｄ ｄｅｔｅｒｍｉｎａｔｉｏｎ）を行うことにより、いくつかの永続保存操作を全体的に回避することができる。このようなコスト及び利益の基準は、メッセージが送信側から宛先に運ばれるときに、メッセージング・ネットワーク内の様々なポイントで評価することができる。

以下では図２を参照して、本発明の第１の実施形態に係るメッセージング・システム１０について説明する。アプリケーション・プログラム４０、４１は互いに対話することができ、（メッセージング・マネージャ３０を介してネットワーク内の他の場所に配置され得る）他のアプリケーション・プログラムとも対話することができる。メッセージング・マネージャ３０は、アプリケーション・プログラムからのＡＰＩコールに応答してネットワーク全体のメッセージ転送を処理し、ローカル・データ処理システム１０内の使用可能なネットワーク通信機能及びオペレーティング・システム機能を利用する。図２にはメッセージング・ローカル・アプリケーション・プログラムであるＡＰＩ ５０及びメッセージング・マネージャ３０が概略的に示されている。図２には揮発性ランダム・アクセス・メモリ７０及び不揮発性ディスク・ストレージ９０も概略的に示されている。

アプリケーション・プログラムがメッセージを作成するときに、当該メッセージと永続性属性との関連付けが行われる。当業界で知られるように、永続性属性としては「永続」又は「非永続」を指定することができ、メッセージが配置されるキューのキュー定義に基づいて永続性を選択することが指定される第３のオプションを指定することもできる。永続性属性は（アプリケーション又はメッセージが配置されるキューに関するデフォルトのメッセージ記述子設定を使用して）各メッセージ毎に矛盾なく自動的に設定することができ、また、アプリケーション・プログラムは任意選択でメッセージ記述子内の永続性フィールドを使用して個々のメッセージを「永続」又は「非永続」として指定することもできる。典型的なメッセージング・システムでは、「永続」メッセージについては永続ストレージに保存する必要があるが、「非永続」メッセージについてはそれ自体の損失（即ち、偶発的なメッセージ損失）がアプリケーションによって許容され得るので、永続ストレージに保存する必要はない。それ故、アプリケーションによって指定される永続性属性が典型的なメッセージング・システムのその後の挙動を決定する。メッセージの取得及び読み出しを行うプログラムは、永続性属性にアクセスすることができ、それ自体が応答すべきメッセージと同一の永続性を有する応答メッセージが送信されることを保証することができる。

いくつかの既知のメッセージング・システムにおいて、メッセージは２つの異なる部分、即ち、メッセージ・コンテンツ又はメッセージ・ペイロードと呼ばれることが多いアプリケーション固有データと、メッセージ記述子（ｍｅｓｓａｇｅ ｄｅｓｃｒｉｐｔｏｒ：ＭＱＭＤ）及び他の構造化フィールドを含むメッセージ・ヘッダーと、から成る。アプリケーション固有データは何らかの特定のデータ・タイプに限定されるわけではなく、例えば文字列、バイト列、２進整数、浮動小数点数等を含むことができる。構造化フィールドは、メッセージを作成したメッセージング・マネージャ３０のバージョン番号、メッセージを時系列順に処理するクロック値、データ長、場合によっては有効期限間隔等の情報も含むメッセージの記述を保持する。メッセージ記述子は、送信側アプリケーション・プログラム４０からメッセージング・マネージャ３０に受け渡され、その後メッセージング・マネージャ３０から受信側アプリケーション・プログラム４５に受け渡される。メッセージ記述子は、送信側アプリケーション・プログラムの要求に応じて永続性属性（「MQMD.persistence」）及び優先度属性（「MQMD.priority」）を含むことができる。優先度属性は、送信側アプリケーションがメッセージの緊急度を示すことを可能にするために提供され、優先度値は、メッセージング・マネージャがメッセージ・キュー内のメッセージの順序を決定する際に考慮に入れることができる。ただし、宛先キューは先入れ先出し（ＦＩＦＯ）キューとして定義することもでき、その場合には優先度属性が無視されることもある。

上述のように、本発明はより制約の少ない永続性管理手法を実施するものであるが、本発明の実施形態の中には上述の優先度属性を利用するものもある。第１の実施形態において、優先度属性は、（上述の非永続メッセージに関する従来の処理のように）メッセージを常に非永続的に処理すべきかどうかを示し、また、永続ストレージへの保存の利益によってコストが正当化される場合はメッセージを永続的に処理すべきかどうかを示す。送信側アプリケーションによって「永続」のラベルが付されたメッセージについては、メッセージの発信元から当該メッセージが送信された後に永続性の判定が行われる。このような「公称永続（ｎｏｍｉｎａｌｌｙ−ｐｅｒｓｉｓｔｅｎｔ）」メッセージに関するコスト／利益の繰り延べ比較（ｄｅｆｅｒｒｅｄ ｃｏｓｔ／ｂｅｎｅｆｉｔ ｃｏｍｐａｒｉｓｏｎ）は、メッセージが送信された後にメッセージング・システム内の動的基準の評価に基づいて永続性の判定が行われない従来の解決策とは異なるものである。本発明の本実施形態において、「公称永続」メッセージは、常に永続的に保存されるのではなく、メッセージの処理中にメッセージング・システムによって評価される１組の基準（即ち少なくとも１つの基準）によってそのことが正当化されたときにだけ永続ストレージに保存される。

送信側アプリケーション・プログラム４０は、アプリケーション固有のメッセージ・データ及びメッセージ記述子を指定することによって新しいメッセージをキューに入れる。メッセージ記述子は、ターゲット・メッセージ・キュー及びターゲット・メッセージング・マネージャ３５を識別し、メッセージを追加すべき第１のメッセージ・キューを識別するのに使用される記述子である。当該第１のメッセージ・キューからターゲット・アプリケーション・プログラムへのメッセージ転送は、複数のメッセージング・マネージャから成るネットワークによって処理される（同一のデータ処理装置上で２つのアプリケーションが実行される限定的なシナリオでは、単一のメッセージング・マネージャがアプリケーション間の通信をサポートすることができるが、多くのシナリオでは、複数のメッセージング・マネージャから成る分散ネットワークによって分散物理ネットワーク全体の非同期メッセージ転送がサポートされる）。

メッセージング・マネージャ又は受信側アプリケーション・プログラムがそれぞれ伝送キュー又はアプリケーション入力キューからメッセージを取得するときに、メッセージング・マネージャ又は受信側アプリケーション・プログラムは、取得すべきメッセージに関するいくつかの情報を指定し、当該メッセージを配置すべきバッファ・ストレージの空き領域（及び当該バッファ・ストレージの空き領域の長さ）を指定する。メッセージを取得するメッセージング・マネージャは、指定された優先度属性に従って当該メッセージを処理する。

本発明の第１の例示的な実施形態では、メッセージの順序付けを簡略化し、故障イベント時の効率的な復旧処理を可能にするために、非永続メッセージ及び「公称永続」メッセージは単一のメッセージ・キュー内の別個のページ・セット１２０、１３０内に配置される。このような解決策は、永続ストレージへの保存のコスト又は利益あるいはその両方と無関係に後の永続性の挙動が優先度属性によって決定される点を除いて、米国特許第５，４５２，４３０号に記載されるとおりである。本実施形態では、非永続メッセージに割り振られたページ・セットに保持されるメッセージについては永続的な保存が企図されていないが、公称永続メッセージに割り当てられたページ・セットに保持されるメッセージについては不揮発性ディスク・ストレージへの書き込みがスケジューリングされる。データを実際にディスク・ストレージに書き込む前に、永続性のコスト要因及び利益要因の評価が行われる。

永続性のコスト及び利益の評価は様々なタイミングで行うことができ、いくつかの要因を考慮に入れることができる。まず、この評価は、メッセージがメッセージング・ネットワーク内を移動している間にメッセージング・マネージャによって最初にキューに書き込まれるときに、メッセージング・マネージャによって実行され得る。これにより、重要なメッセージを直ちに永続ストレージに保存することが可能となる。この評価の性能のプロンプトが出される他の「トリガ・イベント」は、所与のキューが閾値サイズに達した時点や、個々のメッセージが閾値期間キューに入れられた時点等、メッセージング・システム内の各イベントに基づいて発生させることができる。この評価はログの操作によってトリガすることもでき、例えばミリ秒単位でログ・バッファへの強制移動を行うというシステム認識を利用して、追加的な操作を非常に低いオーバーヘッドで同時にログに記録し得ることを判定することができる。この場合では、特定のログ・レコードの永続化に関連するリソース・コストが低いことが識別されると、ログ・レコードは通常より早い段階でディスクに書き込むことが可能となる。他の「トリガ・イベント」としては、例えば直後のシステム・シャットダウン又は潜在的なシステム障害の警告がメッセージング・マネージャに出されるシステム・イベントを挙げることができる。後者の例は、ディスク・ストレージ・サブシステムによって不良セクタの書き込みパターンが検出された場合に検出することができる。

このような「トリガ・イベント」と、永続ストレージへの保存のコスト及び利益の評価に関する閾値とは、各メッセージに応じて動的に定めることができる。例えば、メッセージが最初にキューに入れられるときにメッセージング・マネージャによって行われる評価では、メッセージが非常に重要なものであるが直ちに書き込むほど重要なメッセージではないことが判定されることもある。その後、このような初期評価では当該特定のメッセージに関するトリガ・イベントとして短い期間が設定されることになる。この期間が満了（即ち「トリガ・イベント」が発生）したときは、それ以上評価を行うことなくメッセージをディスクに強制移動することができ、あるいは第２の評価を行うことができる。

初期評価においては「メッセージ価値」（後述）又は他のデータの判定といった重要な処理が行われる可能性があるので、本発明の第１の実施形態では、最初の評価で収集されたデータがネットワークを介して送られ、同一のメッセージに関して行われる後続の評価で再利用される。一実施形態において、メッセージング・マネージャ間でメッセージを受け渡すのに使用される通信プロトコルは、相互接続されたメッセージング・マネージャ間で計算されたメッセージ価値をメッセージと共に受け渡し、永続性を効率的に評価することができるように機能拡張される。他の実施形態において、メッセージングＡＰＩは、例えば（以下で詳述する）メッセージ・ヘッダーの追加フィールド内でメッセージ価値を指定することができるように機能拡張される。

各メッセージング・マネージャ３０において、データ・コレクタ・コンポーネント１４０は、ローカル・システム上で保持されるメッセージに関するコスト及び利益の評価で使用されるメッセージ価値と、より一般的なメッセージ処理統計情報とを含む一連のメッセージ固有データを維持する。１組のルールがルール・レポジトリ１５０内で保持され、永続性マネージャ８０の評価コンポーネント１６０によって収集データに適用される。コレクタ・コンポーネント１４０は、メッセージング・マネージャ３０内の処理性能及びデータ構造の分析から様々な情報を得た後、それらの情報を用いて１組のデータベース・テーブルを更新する。

メッセージ価値は、いくつかの手法のうちの１つを利用してメッセージング・マネージャによって判定され得る。例えば、メッセージ価値は、メッセージ・タイプに基づいて、メッセージが配置されるキューに関連するルールに従って計算することができる。別法として、（例えば、通信中のアプリケーション・プログラムが資金移動処理を行っている場合）メッセージ価値は受信側メッセージング・マネージャがメッセージ・コンテンツを分析することによって、あるいはメッセージ・ヘッダー内のメッセージ価値フィールドを参照することによって判定することができる。後者の例の解決策は、メッセージ価値が送信側アプリケーションによってメッセージングＡＰＩ（後述）を介して指定される本発明の実施形態、及びメッセージ価値が送信側アプリケーションのローカル・メッセージング・マネージャによって一度だけ計算される本発明の実施形態に適用することができる。

サービス指向アーキテクチャ（ＳＯＡ）等より高次のアーキテクチャでは一般に、キューと、当該キュー上に配置されるメッセージとして許可されるメッセージ・タイプと、それらのタイプのメッセージのフォーマットと、メッセージ及びそれらの処理に関する他の意味情報（ｓｅｍａｎｔｉｃ ｉｎｆｏｒｍａｔｉｏｎ）との間の関連付けを保持するアーキテクチャがシステムに実装される。本発明のＳＯＡ実装では、意味情報はメッセージ価値（又はそのような価値を計算するＳＯＡ実装ルール内のコンポーネント）を含む。この情報は、メッセージングＡＰＩの明示的なプログラミングを必要としないより高次の意味コンポーネントによってメッセージング・マネージャに通信される。メッセージング・マネージャは、そのようなメッセージ価値がメッセージングＡＰＩを介して直接提供されたかどうか、あるいはそのようなメッセージ価値がより高次のＳＯＡシステムを介して決定されたかどうかを必ずしも認識している必要はない。

より原始的なシステムでは、メッセージの意味を理解しメッセージ価値を抽出あるいは導出することが可能なＡＰＩ交差出口（ＡＰＩ ｃｒｏｓｓｉｎｇ ｅｘｉｔ）を利用することによって同様の効果を達成することができる。この場合も、アプリケーションのプログラマが明示的なＡＰＩコードを書き込む必要なしに「messageValue」がメッセージング・システムに送信される。また、メッセージング・システムがメッセージ価値の情報源を認識していなくてもよい。

（いくつかの既知のメッセージング・システムの場合と同様に）キュー深度も監視され、当該データがデータ・コレクタ・コンポーネント１４０に提供される。また、メッセージがキュー内に残っている時間と、キュー内に保持されているアイテムの合計データ・サイズとが監視される（また、既知のメッセージング・システムでは明示的な監視を行われなくてもそうした情報が既に利用可能であるため、そのような監視に伴うオーバーヘッドはほとんど存在しない）。更に、キューからのメッセージの読み出しレート、及びメッセージがキュー内に残る典型的な時間と共に、キューの先頭に達する予想時間等より高度な統計ベースの推定値を監視することができる。既知のシステムでしばしば監視される別のシステム特性としてはＣＰＵのオーバーヘッドが挙げられるが、非常に高いＣＰＵ負荷がシステム障害と相関を有することが多いことから、そのようなデータは永続性評価にとって重要である可能性がある。また、いくつかのプログラムは他のプログラムに悪影響を及ぼすことが知られており、この事実を永続保存操作を実行すべきか否かを判定する際に考慮することができる。

第１の例示的な実施形態では、メッセージング・マネージャ３０はそれ自体の内部メッセージ処理レートを監視し、１秒間にキューから読み出されるメッセージ数を表す値をコレクタ・コンポーネント１４０に提供する。コレクタ・コンポーネント１４０は、指数平滑化アルゴリズムをメッセージの読み出しレートに適用してデータベースに保存される値（「messageProcessingRate」）を生成する。コレクタ・コンポーネント１４０は、各メッセージのメッセージ・キュー内の位置（positionInQueue）も監視する。この「positionInQueue」の値は、メッセージがキューに追加されるときに判定され、後で更新することができる。

メッセージング・マネージャのコレクタ・コンポーネント１４０は、メッセージング・マネージャ、オペレーティング・システム、又はデータ処理システムのハードウェアに関するすべての障害を含む障害間隔時間に関する統計平均（「meanTimeToFailure」）も生成する。他の統計値（ディスク書き込みエラー等、既存のシステム管理製品によって既に監視がなされているものもある）、ならびに発生し得るシステム障害と関連性を有する雷雨、電力供給の信頼性、地震リスク等の外部要因も、同様に使用することができる。

コレクタ・コンポーネント１４０は、メッセージング・システムの現在の負荷を表す値（「load」）と、メッセージング・システムの平均負荷を表す統計値（「avgLoad」）と、１秒間に永続メッセージがディスクに書き込まれる平均回数「persistPerSec」）とを（メッセージング・マネージャ３０又はオペレーティング・システムから）取得する。

あるメッセージをキューの先頭から取得した後、当該メッセージの処理に費やした時間を表す１つ又は複数の「timeInProcess」値を維持することができる。例えば、現在のメッセージング・マネージャ３０がターゲット・アプリケーション・プログラムの入力キューを管理するターゲット・メッセージング・マネージャである場合には、「timeInProcess」は、ローカル・アプリケーションが「get_message」コールを発行することによって上記メッセージを取得した時点からメッセージ取得操作がコミットされるまでの時間となる。メッセージング・マネージャが送信側アプリケーションのメッセージング・マネージャとターゲット宛先アプリケーションのメッセージング・マネージャとの間の中間処理ノードである場合には、「timeInProcess」は、メッセージが（当初の配置場所である）ローカル伝送キューの先頭から取得された時点から当該メッセージを別のノードに転送するメッセージ転送操作がコミットされるまでの時間となる。

データベースを上述のデータで更新した後、それらのデータは、永続性マネージャ８０の評価コンポーネント１６０がルール・レポジトリ１５０内に保持されている１組のルールを適用することによって処理することができる。評価コンポーネントは、「positionInQueue」及び「messageProcessingRate」の値を処理してメッセージがメッセージ・キューの先頭に達する推定時間（「timeToHeadOfQueue」）を計算する。
timeToHeadOfQueue =positionInQueue / messageProcessingRate

評価コンポーネントは、メッセージがメッセージング・マネージャによって保持される時間の推定値（「timeHeld」）も計算する。
timeHeld = timeToHeadOfQueue +timeInProcess

特定のメッセージの推定損失リスクは、メッセージの保持時間と平均障害間隔時間とに従って計算される。
riskOfLoss = min(1, timeHeld /meanTimeToFailure)

メッセージの損失リスクに関するこのような推定値の評価は、後に永続ストレージへの保存を行うべきか否かを判定する際に使用することができる。永続性マネージャ８０の評価コンポーネント１６０による上記の予備評価ステップの時点ではまだメッセージ価値の検討は行われず、特定のメッセージの損失リスクが考慮に入れられる。本発明のいくつかの実施形態ではメッセージ価値を検討せずにメッセージの損失リスクが評価され、必要とされる永続性が判定されるが、好ましい解決策では、個々のメッセージ価値に基づいてメッセージの損失コストが単なる検討要素として、あるいはメッセージ性能の統計値又はリソース・コストの検討事項と組み合わせて評価される。このように、メッセージの損失コストを表す値は、メッセージの損失リスクを表す値及びシステム・リソースの需要に関する追加的な基準と組み合わせることができ、その一例を以下に示す。
riskCost = messageValue *riskOfLoss

「persistenceCost」値は、「riskCost」が「persistenceCost」を上回ったときにデータを永続ストレージに保存すべきと判断された場合に、「load」値及び「avgLoad」値ならびに「persistPerSec」値に従って計算することができる。この「persistenceCost」は、データを永続ストレージに保存するのに必要とされるリソースに基づく値とすることができ、また、システム性能の永続化効果の推定値を計算し、この推定値を使用して永続性判定に影響を与えることができる。
if (riskCost >persistenceCost) then persistence=true
if (riskCost <persistenceCost) then persistence=false

この永続性判定は、メッセージング・システムが特定の顧客のメッセージング・アプリケーションで規定されるサービス品質要件に従って、性能と、保証された１回限りのメッセージ配信のどちらを優先する必要があるのかに基づいて行うことができる。

上述したような単純なルールであっても、これを実装することでメッセージ処理システムの費用対効果を改善することが可能である。上記のルールは動作性を実証し、本発明の動的な諸原理がどのように具現化され得るかを実証するものであるが、他の多くの代替ルールを使用して永続性を決定することができることも理解していただきたい。そのようなルールは、永続性マネージャが使用可能な情報に応じて上記の例よりも複雑なものとなる可能性がある。

図３は、本発明の一実施形態に係る永続性マネージャ８０のコレクタ・コンポーネント１４０及び評価コンポーネント１６０に関する更なる詳細の一部を示している。コンポーネント１４１は、キュー深度及び各メッセージのキュー内の位置ならびに個々のメッセージング・マネージャの内部メッセージ処理レートを含めたメッセージング・マネージャ自体から提供される情報のコレクタである。コレクタ・コンポーネント１４０は、例えばシステム負荷に関するデータ、障害までの推定平均時間、検出されたディスク書き込みエラーに関する情報等を提供する別個の外部コレクタ・コンポーネント１４２も含む。コンポーネント１４１及び１４２はいずれも、それぞれのデータを評価コンポーネント１６０の評価処理コンポーネント１６２によって使用される監視データのソースとなるコレクタ・データベース１４３に提供する。評価コンポーネント１６０は、内部コレクタ・コンポーネント１４１及び外部コレクタ・コンポーネント１４２によって生成される各イベントに応答し、永続書き込みに関連する設定期間の満了に応答するトリガ・コンポーネント１６１も含む。ルール・レポジトリ１５０は、（ｉ）メッセージング・マネージャの動作に特有の条件に関するルール、及び（ｉｉ）メッセージング・マネージャの内部動作と独立したデータ処理システム内部の条件に関するルールのうちの一方又は両方を含むことができる。図２及び図３ではメッセージング・マネージャ３０の内部コンポーネントとして示されているが、永続性マネージャ８０のコンポーネントの一部又は全部は、メッセージング・マネージャ３０と別個のコンポーネントであるがメッセージング・マネージャ３０と協働するデータ処理システム１０内の１つ又は複数のコンポーネントとして実装することもできる。

ここで、電話交換器が顧客の請求書として送るべき通話記録を発行する電話使用料金計算の応用例について検討する。通話記録の多くは数セントにすぎず、現実的な価値のない通話記録もある一方、相当額（例えば５０セント又は１ドル）に達する通話記録もあり、通話記録の何割かは数ドル程度掛かっているものもある。請求書の応用例では高価値の通話記録を見過ごすべきでなく、それらは常に永続的に処理されることになるが、閾値（例えば１セント又は１０セント）未満の記録については、それらを永続的に取り扱うコストを正当化するほどの価値が見出せないこともある。信頼性の高いデータ処理システムではエラー及び障害が発生する頻度は相対的に低くなり、いくつかの低価値の通話記録の損失は処理性能の向上のために許容され得る。中価値の通話記録は公称永続として取り扱うことができるが、性能コストがメッセージ損失の推定リスクによって正当化される場合にのみ永続ストレージに保存される。

他の応用例では、永続化のコスト及び利益に関連する基準の評価に基づいてデータを永続的に保存すべきかどうかを判定する処理は、すべてのデータ項目に適用することも、高価値の項目にだけ適用することも（他の項目は非永続として取り扱われる）、低価値の項目にだけ適用することもできる（他の項目は永続的に取り扱われる）。

例えば１セントの通話の場合を考えると、第１の「messageValue」は「１．０」となる。ここで、メッセージ処理レートを１０００メッセージ／秒、平均「timeInProcess」を０．２秒、平均障害レートを１０日に１回と仮定する。次式のとおり、メッセージはキュー上の４０番目のメッセージとして追加されるものと仮定する。

上式で、persistenceCost = 3.17e-7 （riskCost < persistenceCost）であれば、メッセージは永続的に保存されない。

一方、１０セントの通話であれば以下のようになるため、永続的に記録される。
riskCost = 10 * 2.78e-7 =0.00000278 > 3.17e-7
riskCost > persistenceCost

典型的なシステムでは、「persistenceCost」は一定の値をとらないことに留意していただきたい。例えば、バッファ内に保持されているすべてのログ・レコードを対象とするディスク書き込みが行われる時点で、新しいメッセーメッセージの単一のログ・レコードに関連する「persistenceCost」は、同時に書き込むべきデータが他に存在しないときに実行されたディスク書き込みの直後に得られる「persistenceCost」と比較して、非常に低い値をとることになる。

電話料金の例では、メッセージ配信の障害の事業コストは通話コストと非常に近くなる可能性がある（各自の通話の正確な記録を求める顧客もいるため、場合によってはそれより高くなることもある）。二重配信の事業コストの方が定量化は容易であるが、メッセージング・システム外部のシステム機能を使用して二重化が検出される可能性があり、その場合には、二重化の解消が事業コストではなく処理コストと見なされる可能性がある（多くの場合、顧客は値下げよりも二重課金の方に強い抵抗を示すはずである）。また、メッセージングの既知の解決策では、メッセージの読み出し／削除に関する記録が慎重に処理され、返却される受信確認も慎重に処理される。したがって、本明細書では主に二重化ではなくメッセージ配信の障害のリスク及び関連するコストに焦点が当てられているが、本発明は二重配信のコストの評価にも適用可能である。

上述したように、メッセージは、「riskCost」の計算に基づいて「永続キュー（ｐｅｒｓｉｓｔｅｎｃｅ ｑｕｅｕｅ）」（永続ストレージへの保存が企図される項目から成るキュー）上に配置することができる。一実施形態では、この「riskCost」と各メッセージのキュー内の位置とを周期的に再計算することも、顧客アプリケーションの開始や停止等のイベントに応答して再計算することもできる。高価値のメッセージはキューの先頭に移動して迅速に永続化することができる一方、低価値のメッセージの永続化は、最も価値の低いメッセージが永続化前に処理されるように、高価値のメッセージの永続化よりも遅延させることができる。

上記の例示的なルール及び通話料金に関する具体例は、データを永続的に保存すべきか否かの判定に適用され得る検討事項の単なる例にすぎない。障害予測の知識、及びキュー深度やＣＰＵ負荷のような統計値の知識、あるいはメッセージ・サイズのようなパラメータの知識を考慮に入れることが、特定のシステムの永続性のボトルネックによって正当化されるかどうかに従って、様々なレベルの複雑さを伴う様々な代替ルールを適用することができる。

当業者ならこのようなルールの様々な変形形態に想到するはずであるが、永続ストレージへの保存のコスト及び利益に関する動的な基準の評価に基づいてデータを永続ストレージに保存すべきかどうかを判定することは、永続性の挙動が事前定義される従来の解決策から脱却するものである。上述の諸実施形態によれば、いくつかの永続保存操作を省略することが可能となり、その結果、永続ストレージへの保存が必要ないことが判定された場合にログ及びメッセージ・キューがディスク・ストレージに書き込まれることに関連する性能のボトルネックを低減することが可能となる。

ここで、メッセージング・システムにおける本発明の適用可能性及び潜在的な利益を更に提示するために、いくつかの例示的なシナリオについて説明する。例えば、あるメッセージ・キューの処理がアクティブ状態の顧客（又は上述のムーバ）によって迅速に行われる場合、上述の永続性判定では、当該キューに追加されるメッセージを永続的に保存する必要はないことが判定される可能性がある。一方、例えばその顧客が使用している別のリソースの障害が原因でシャット・ダウンが行われる場合には、別の永続性判定が行われることによって異なる結果が得られる可能性もある。上記の例示的な公式を使用すると、メッセージがキュー上に残り得る時間が長くなり、その結果riskOfLossが増加するため、riskCostが高くなり、キュー上のメッセージが永続的に保存される傾向も高くなる。このような永続化の判断は新しく到着したメッセージだけを対象に適用することも、すべての待機メッセージを対象に遡及的に適用することもできる。

本例を説明するために、初期プロデューサが第１のメッセージング・マネージャＱＭ１を介してメッセージを送信し、その後第１のメッセージング・マネージャＱＭ１がムーバを使用してメッセージを第２のメッセージング・マネージャＱＭ２に転送し、第２のメッセージング・マネージャＱＭ２がメッセージをエンキューし、最終顧客がそこからメッセージを取得する、メッセージング・ネットワークについて検討する。典型的なメッセージを初期プロデューサからＱＭ１に、その後ＱＭ１からＱＭ２へと迅速に移動することができても、最終顧客が低速な場合又は非アクティブ状態にある場合は、メッセージがＱＭ１で永続化されない可能性があるが、ＱＭ２で永続化される可能性がある。また、メッセージがプットされる時点でムーバが低速な場合又は非アクティブ状態にある場合は、メッセージがＱＭ１で永続化される可能性がある。ムーバが最終的にメッセージを移動する時点で顧客が既にアクティブ状態にある場合は、メッセージはＱＭ２で永続化されない可能性がある。

メッセージ価値が非常に低い場合にはどちらのメッセージング・マネージャでも永続化を行う必要はないが、メッセージ価値が非常に高い場合には両方のメッセージング・マネージャで永続化が行われることになる。高価値のメッセージは永続キューの先頭に移動され、永続化前に処理される傾向がある低価値のメッセージと比較すると、非常に迅速に永続化され得る。

上述のように、本発明のいくつかの実施形態を用いると、メッセージングＡＰＩを介してメッセージ価値を指定することが可能となる。上記の説明では、（例えば新しいメッセージ・ヘッダー・フィールド「MQMD.messageValue」で指定された）メッセージ価値が、「PERSISTENT」、「NON_PERSISTENT」、及び「PERSISTENCE_AS_Q_DEF」の３つのオプションのうちの１つを指定した永続性属性（「MQMD.persistence」）と組み合わせて使用される、第１の実施形態が示されている。上記の説明では、「NON_PERSISTENT」メッセージが従来どおり処理されるように説明されており、他のメッセージを評価してそれぞれの「公称永続」状態を無視することが状況に応じて正当化されるかどうかが判定されている。別の実施形態では、メッセージング・システムは、メッセージ価値を得るために永続性属性（「MQMD.persistence」）に関連するメッセージの固定メッセージ・ヘッダー（ＭＱＭＤ）内の追加フィールドを提供する一方、新しい永続性属性オプション「PERSISTENCE_BY_VALUE」も可能にする。ここで、メッセージ送信側のアプリケーション・プログラムは、次のメッセージ価値のうちの１つを指定することができる。
「PERSISTENT」
「NON_PERSISTENT」
「PERSISTENCE_AS_Q_DEF」
「PERSISTENCE_BY_VALUE」

メッセージ価値フィールドは、セントを単位とする３２ビットの整数又は３２ビットの浮動小数点数とすることができ、また、フィールドが設定されていないことを示す「１」等のデフォルト値を有することができる。

別の実施形態では、既知の「PERSISTENCE_AS_Q_DEF」属性値は、最終顧客アプリケーションの入力キューにある限りメッセージング・ネットワークを介して受け渡すことができる。この属性値には、発信元のメッセージング・マネージャ及び他のメッセージング・マネージャが本発明に係る永続性評価及び永続性判定を実行することによって応答することができる。

他の実施形態では、メッセージ価値を既存の永続性属性に追加する代わりに、ＡＰＩを介して指定されたメッセージ価値に基づいて、すべてのメッセージの永続性判定を行うことができる。

上記では、永続ストレージへの一部の書き込みを回避することによってメッセージの永続化又は他のデータ更新のオーバーヘッドを低減することが望ましい応用例及びシステムの文脈で本発明が説明されてきたことに留意していただきたい。代替的な解決策では、メッセージ送信者の「永続性」指定が絶対要件として取り扱われるが、評価された基準によってそうすることが妥当であると判定された場合には、「非永続」として指定された重要なメッセージであっても、永続メッセージ処理の利益を享受することが可能となる。例えば、実際のシステム障害が検出された後、又はいくつかの条件によってシステム障害のリスクが示された後は、非常に高い価値を有するメッセージあるいはすべてのメッセージをある期間にわたって永続的に処理することができる。

図４乃至図６は、本発明の一実施形態に係る方法の各ステップを簡略的に示している。図４に示されるように、この方法は、第１のアプリケーション・プログラム４０がメッセージ・ペイロードと、送信者、ターゲット・メッセージング・マネージャ及びメッセージ・キューのＩＤ、ならびに１組の属性に関する情報を含むメッセージ・ヘッダーとを用いてメッセージを作成するステップ２００から開始する。この第１の実施形態では、送信側アプリケーションが以下の永続性属性、即ち「PERSISTENT」、「NON_PERSISTENT」、又は「PERSISTENCE_AS_Q_DEF」のうちの１つを指定する。送信側アプリケーションは「put_message」コマンドを発行して、ローカル・メッセージング・マネージャ３０によって管理されるメッセージ・キューにメッセージを配置する。ローカル・メッセージング・マネージャ３０は、ターゲット・メッセージング・マネージャのＩＤに基づいて（永続メッセージ及び非永続メッセージが１つのキュー又は別個のキュー内の別個のページ・セットにエンキューされる一実施形態では永続性属性に基づいて）メッセージを配置するのに適したローカル・キューを識別する。ローカル・キューがリモート・ターゲット・キューまでの経路上の中間伝送キューに該当する場合には、その後、ローカル・メッセージング・マネージャのムーバ・コンポーネントは、場合によっては複数の中間メッセージング・マネージャを介して、リモート・メッセージング・マネージャに転送するメッセージを（非同期的に）取得する（２２０）。一方、メッセージはローカル・キュー・マネージャ３０が管理するキュー上に保持されるので、ローカルの永続性マネージャ８０は、メッセージ及び当該メッセージに関するログ・データを永続ストレージに保存すべきかどうかを判定する必要がある（２３０）。この判定は周期的に又はトリガ条件に応答して実行される。先述のように、例示的なトリガ条件としては、メッセージがキュー上に配置されることやシステム問題の検出等のイベント、あるいはキュー深度がメッセージの閾値数に達すること等の条件が挙げられる。永続ストレージへの保存が必要であることが永続性マネージャによって判定された場合には、保存操作が直ちに実行される（２４０）（他の実施形態では、ディスク書き込み命令自体が優先度順にエンキューされる）。永続ストレージへの保存が現時点で必要ないことが永続性マネージャによって判定された場合には、永続性マネージャは、キュー上に残されたすべてのメッセージを対象とする次回の評価及び永続性判定のためのタイマを設定することができる（２５０）。図４に示される各方法ステップの更なる詳細は先に説明したとおりである。

図５は、メッセージの発信元のシステム以外のデータ処理システムにおいて、メッセージング・マネージャ及び永続性マネージャによって実行されるステップを示している。メッセージング・マネージャは、別のメッセージング・マネージャからメッセージを受信し（３００）、当該メッセージのメッセージ・ヘッダー及び他のデータ・フィールドを読み出してターゲット・メッセージング・マネージャ及びターゲット・キューを識別し、優先度や指定された永続性等のメッセージ属性を識別する（３１０）。その後、メッセージに対して図４と同様の処理が実行され、ムーバ又はローカル・アプリケーション・プログラムによってメッセージが取得され（３２０）、永続性マネージャによってメッセージの永続化のコスト及び利益が評価され（３３０）、その後ディスク書き込みが開始され（３４０）、又はタイマが経過するまで永続化が繰り延べられる（ｄｅｆｅｒｒａｌ）（３５０）。

図６は、発信元のメッセージング・システムによって実行される本発明の別の実施形態に係る方法の各ステップを示している。図６においても、送信側アプリケーション・プログラムがメッセージを作成し、ターゲット・メッセージング・マネージャ及びキューを識別する「put_message」コマンドを発行する（４００）。ただし、送信側アプリケーションは永続性属性を明示的に指定する代わりに、メッセージ・ヘッダー内でメッセージ価値を指定する（４００）。ローカル・メッセージング・マネージャ３０は、メッセージ・ヘッダーを読み出してどのローカル・キュー上にメッセージを配置すべきかを判定し、その判定に従ってメッセージをエンキューする（４１０）。本実施形態では、価値の異なるメッセージが同一のキューに保存される。ターゲット・キューがローカル・キュー・マネージャによって管理されないものと仮定すると、その後、ローカル・メッセージング・マネージャ内のムーバがメッセージを取得し（４２０）、当該メッセージをターゲット・メッセージング・マネージャまでの経路上に所在する次のメッセージング・マネージャに送信する。メッセージが到着する任意のメッセージング・システムで永続性判定を実行することができるようにメッセージと共にメッセージ価値も転送される。メッセージがローカルで保持されている間、ローカルの永続性マネージャ８０は当該メッセージをローカルの永続ストレージ９０に保存すべきかどうかを判定する必要がある。永続性マネージャは、それ自体のキュー上のメッセージに関するヘッダー情報を読み出し、永続ストレージへの保存のコスト及び利益の評価を実行する（４３０）。上述のように、この評価では永続的に保存する利益を評価する際に、所与のメッセージ価値に関するメッセージの損失又は二重化の事業コストやメッセージ損失のリスク等のメッセージ価値が考慮に入れられる。その後、上述のように、永続性マネージャはディスク書き込みを開始することができ、あるいは次回の評価のためのタイマを設定することができる。

図７は、データベース更新の永続記憶を管理する本発明の別の実施形態に係るコンポーネントを示すデータベース・システムの図である。図７では、プロセッサ５００、入出力コンポーネント５１０、揮発性ランダム・アクセス・メモリ（ＲＡＭ）５２０、不揮発性ディスク・ストレージ・システム５３０、データベース・マネージャ５４０、及び永続性マネージャ５５０を含めた本システムの様々なコンポーネントがシステム・バス５６０を介して接続されている。永続性マネージャ５５０は、データ・コレクタ・コンポーネント５５１、トリガ・コンポーネント５５２、ルール・レポジトリ５５３、及び評価コンポーネント５５４を備える。データベース・マネージャ５４０は、ＲＡＭ ５２０内に保持される１組のデータベース・テーブル５７０を管理し、データベース５７０との間のデータ更新（追加、削除、及び更新）の読み出し及び書き込みを実行する。データ・コレクタ・コンポーネント５５１は、データ更新を検出し、当該データ更新に関する情報及びデータベース・システム内の状態に関する他の情報をＲＡＭ ５２０内の第２のデータベース５８０に保存する。トリガ・コンポーネント５５２によって識別されたトリガ条件に応答して、評価コンポーネント５５４は、ルール・レポジトリ５５３から取得されるルールを第２のデータベース５８０内に保持されているデータに適用して、永続ストレージへの保存のコスト及び利益を評価する。この評価は、データ更新を不揮発性データ・ストア５３０内のデータベース５７０の永続レプリカ５９０に保存すべきかどうかを判定する際に使用される。ディスク・ストレージのような不揮発性ストレージへのデータ書き込みは、評価の結果永続保存が必要であるという正判定が得られた場合にだけ実行されるので、上記の実施形態は、低価値のデータ項目に関する低オーバーヘッドの（高性能が実現され得る）記憶に適したデータベース・システムを提供する。

当業界で知られる単純な分散メッセージング・システムの概略図である。 本発明を実施することが可能なメッセージング・システムと、互いに協働して本発明の一実施形態に係る永続性管理を実現するシステム・コンポーネントとを概略的に示す図である。 図２の実施形態に係るメッセージング・システム内のいくつかのコンポーネントを詳細に示す図である。 本発明の一実施形態に係る永続性を管理する方法の各ステップを簡略化して示すフロー図である。 本発明の一実施形態に係る永続性を管理する方法の各ステップを簡略化して示すフロー図である。 本発明の別の実施形態に係る方法の各ステップを簡略化して示すフロー図である。 本発明の別の実施形態に係るデータベース管理システムの概略図である。

Claims (20)

1. データ処理装置であって、
   プロセッサと、
   揮発性データ・ストアと、
   不揮発性データ・ストアと
   を備えており、
   前記プロセッサに、前記不揮発性データ・ストアへのデータの保存を管理する方法の各ステップを実行させる永続性マネージャを前記揮発性データ・ストア上に備えており、
   前記方法は、
   データを前記不揮発性データ・ストアに保存するリソース又は性能コスト（以下、「保存コスト」ともいう）と、データを前記不揮発性データ・ストアに保存しないことに関連付けられたリスク（以下、「リスク・コスト」ともいう）とを評価するステップと、
   前記揮発性データ・ストア内に保持されているデータ更新を前記不揮発性データ・ストアに保存する必要があるかどうかを前記保存コストと前記リスク・コストとを比較することによって判定するステップであって、前記保存コストが前記リスク・コストよりも低いことに応じて前記データ更新を前記不揮発性データ・ストアに保存し、一方、前記保存コストが前記リスク・コストよりも高いことに応じて前記データ更新を前記不揮発性データ・ストアに保存しない、前記判定するステップと
   を含み、
   データを前記不揮発性データ・ストアに保存しないことに関連付けられた前記リスクが前記データを前記不揮発性データ・ストアに保存されなかった場合の当該メッセージに関するデータの損失リスクである、
   前記データ処理装置。
2. 前記評価するステップが、前記メッセージの価値に基づいて前記損失の潜在的なコストを評価するステップを含む、請求項１に記載のデータ処理装置。
3. 前記メッセージの前記価値が、
   前記メッセージのコンテンツに含まれる金銭価値に基づいて判定され、
   前記メッセージの送信先となるメッセージ・キューの属性から推論され、又は、
   前記メッセージの属性値から判定される、
   請求項２に記載のデータ処理装置。
4. 前記評価するステップは、前記データ更新の価値と前記データ損失リスクとに基づいて潜在的なデータ損失コストを計算するステップを含む、請求項１〜３のいずれか一項に記載のデータ処理装置。
5. 前記評価するステップは、前記データ更新が前記不揮発性データ・ストアに保存されなかった場合のデータ更新の二重化リスクを評価するステップを含む、請求項１〜４のいずれか一項に記載のデータ処理装置。
6. 前記評価するステップは、前記データ処理装置の性能特性を評価するステップを含む、請求項１〜５のいずれか一項に記載のデータ処理装置。
7. 前記評価するステップは、ログ・レコードが前記不揮発性データ・ストアに書き込まれるまでの残り時間を評価するステップを含む、請求項１〜６のいずれか一項に記載のデータ処理装置。
8. 前記揮発性データ・ストア上にメッセージング・マネージャが更に備えており、
   前記評価するステップは、メッセージが前記メッセージング・マネージャによって処理されている間に、前記メッセージに関するデータを前記不揮発性データ・ストアに保存するコストと、前記メッセージに関するデータを前記不揮発性データ・ストアに保存しないことに関連付けられたリスクとを表す複数の１組の基準のうちの少なくとも１つの基準を評価するステップを含み、
   前記判定するステップは、前記評価に基づいて、前記メッセージに関する前記データを前記不揮発性データ・ストアに保存すべきかどうかを判定するステップを含み、
   前記方法は、
   正の判定に応答して、前記メッセージに関する前記データの前記不揮発性データ・ストアへの保存を開始するステップ
   をさらに含む、請求項１〜７のいずれか一項に記載のデータ処理装置。
9. 前記評価するステップは、前記メッセージが前記不揮発性データ・ストアへの保存候補であることを示すメッセージ属性に応答して実行される、請求項８に記載のデータ処理装置。
10. 前記メッセージが、
    「永続」、
    「非永続」、
    「メッセージ・キューの定義に従って決定される永続性」、及び
    「メッセージ価値に従って決定される永続性」
    から成る群から選択される少なくとも１つのメッセージ属性値を含むメッセージ永続性オプションが提供されている、請求項９に記載のデータ処理装置。
11. 前記データ処理装置が、前記メッセージ価値を指定する手段を備えており、
    前記メッセージが、少なくとも前記メッセージ永続性オプションの「メッセージ・キューの定義に従って決定される永続性」が提供される、
    請求項１０に記載のデータ処理装置。
12. 前記評価するステップは、
    前記損失に関連付けられたコストを前記メッセージの前記価値に基づいて評価するステップ
    を含む、請求項１〜１１のいずれか一項に記載のデータ処理装置。
13. ネットワーク通信用に互いに接続された複数のデータ処理システムを備えており、
    前記複数のデータ処理システムはそれぞれ、
    プロセッサと、
    揮発性データ・ストアと、
    不揮発性データ・ストアと
    を備えており、
    前記プロセッサに、メッセージに関するデータをそれぞれの前記不揮発性データ・ストアに保存すべきかどうかを判定する方法の各ステップを実行させる関連する永続性マネージャ並びに、メッセージング・マネージャを前記揮発性データ・ストア上に備えており、
    第１のデータ処理システムは、
    第１のメッセージング・マネージャを使用して、前記第１のデータ処理システム側の前記第１の永続性マネージャによって使用されるメッセージ価値を判定するステップと、
    前記判定されたメッセージ価値を第２のメッセージング・マネージャを備えた第２のデータ処理システム側に送信するステップと
    を実行し、
    前記第２のデータ処理システムは、
    前記第２のメッセージング・マネージャを使用して、前記メッセージ価値を識別するステップと、
    前記識別されたメッセージ価値を前記第２のデータ処理システムに提供することにより、前記第２の永続性マネージャがメッセージに関するデータを前記第２のデータ処理システム側の不揮発性データ・ストアに保存すべきかどうかを判定するステップと
    を実行する、
    請求項１２に記載のデータ処理装置。
14. 前記評価するステップは、前記メッセージに関する前記データについて計算される損失リスクに基づいて、前記メッセージに関するデータを前記不揮発性データ・ストアに保存する前記利益を評価するステップを含む、請求項８〜１３のいずれか一項に記載のデータ処理装置。
15. メッセージ・キューが閾値キュー深度に達したことに応答して、前記評価するステップと、前記判定するステップと、前記不揮発性データ・ストアへの保存を開始するするステップとが開始される、請求項８〜１４のいずれか一項に記載のデータ処理装置。
16. 前記メッセージに関する操作が実行されたことに応答して、前記評価するステップと、前記判定するステップと、前記不揮発性データ・ストアへの保存を開始するするステップとが開始される、請求項８〜１４のいずれか一項に記載のデータ処理装置。
17. 前記メッセージに関する操作は、前記メッセージを前記メッセージング・マネージャによって管理されるキュー上に配置することを含む、請求項１６に記載のデータ処理装置。
18. 前記プロセッサに、前記揮発性データ・ストア内に保持されているデータベース・テーブルに対してデータ更新を適用するデータベース・マネージャを前記揮発性データ・ストア上に更に備えており、
    前記判定するステップは、少なくとも１つの基準の前記評価に基づいて、データの更新、追加、及び削除が前記不揮発性データ・ストアへの保存を必要とするものかどうかを判定するステップを実行する、
    請求項１〜４のいずれか一項に記載のデータ処理装置。
19. データ処理装置内のデータの永続性を管理する方法であって、前記データ処理装置が、
    データを永続ストレージに保存するリソース又は性能コスト（以下、「保存コスト」ともいう）と、データを前記永続ストレージに保存しないことに関連付けられたリスクとを評価して、揮発性データ・ストア内に保持されているデータ更新を前記永続ストレージに保存する必要があるかどうかを前記保存コストと前記リスク・コストとを比較することによって判定するステップであって、前記保存コストが前記リスク・コストよりも低いことに応じて前記データ更新が前記不揮発性データ・ストアに保存され、一方、前記保存コストが前記リスク・コストよりも高いことに応じて前記データ更新が前記不揮発性データ・ストアに保存されない、前記判定するステップと、
    前記保存コストが前記リスク・コストよりも低いことに応じて、前記データ更新の永続ストレージへの保存を開始するステップと
    を実行することを含み、
    データを前記不揮発性データ・ストアに保存しないことに関連付けられた前記リスクが前記データを前記不揮発性データ・ストアに保存されなかった場合の当該メッセージに関するデータの損失リスクである、
    前記方法。
20. コンピュータに、請求項１９に記載の方法の各ステップを実行させるコンピュータ・プログラム。

Images