JP2023527170A - ルール・エンジンのインスタンスを横断したルール分散 - Google Patents

Abstract

ルール・エンジンのインスタンスを横断してルールを分散する方法が提供される。方法は、複数のルール・セットの各ルール・セットごとにルール負荷を決定するステップを含む。各ルール・セットは、マルチテナント・システム上でホストされる複数のテナントのうちのテナントに関連付けられる。方法は、各ルール・セットごとのルール負荷を全体ルール負荷に統合するステップを含む。方法は、さらに、全体ルール負荷の略同一割合がルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、ルール・エンジン・インスタンスのセットを横断して、複数のルール・セットを分散するステップを含む。

Description

本開示は、概して、ルール・サービスの分野に関し、より詳細には、ルール・エンジンの複数の独立したインスタンスを横断してルールの実行を分散することに関する。

現代のルール・エンジンは、ルール・セットのインメモリ・モデルを保持し、ルールの高速な評価を容易にする。現代のマイクロサービス環境において、ルール・サービスは、典型的には、ルール・エンジンの複数のインスタンスを同時にデプロイして、ルールの高速な評価をさらに容易にする。

本開示は、ルール・エンジンの独立したインスタンスを横断してルールを分散するための方法、コンピュータ・プログラム製品およびシステムを含む。方法は、複数のルール・セットの各ルール・セットごとにルール負荷を決定するステップを含む。各ルール・セットは、マルチテナント・システム上でホストされる複数のテナントのうちのテナントに関連付けられる。方法は、さらに、ルール負荷を全体ルール負荷に統合するステップを含む。方法は、さらに、全体ルール負荷の略同一割合がルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、ルール・エンジン・インスタンスのセットを横断して複数のルール・セットを分散するステップを含む。

上述した発明の概要は、本開示の説明される各実施形態またはすべての実装を説明することを意図するものではない。

本開示に含まれる図面は、明細書に組み込まれるか、その一部を構成する。これらは、本開示の実施形態を説明し、記載に沿って、開示の原理を説明するはたらきをする。図面は、典型的な実施形態を説明するのみであり、開示を限定するものではない。

図１は、本開示の実施形態による例示のルール実行システムのブロック図を示す。 図２は、本開示の実施形態による、ルール・エンジン・インスタンスにルールを割り当てるための例示の方法のフローチャートを示す。 図３は、本開示の実施形態による、ルール・リクエストを実行するための例示の方法のフローチャートを示す。 図４は、本開示の実施形態による、ルール分散最適化およびスケーリングのための例示のシステムのブロック図を示す。 図５は、本開示の実施形態によるルールモデルの分散を最適化するための例示の方法のフローチャートを示す。 図６は、本開示の実施形態に従う、本明細書で説明される方法、ツールおよびモジュールおよび任意の関連する機能の１または複数を実装するために用いることができる、例示のコンピュータ・システムのハイレベル・ブロック図を示す。 図７は、本開示の実施形態による、クラウド・コンピューティング環境を示す。 図８は、本開示の実施形態による抽象化モデル・レイヤを示す。

本明細書において説明される実施形態は、種々の変更および代替的な形態を受け入れる余地があるが、これらの詳細は、例として図面に示され、詳細に説明される。しかしながら、説明される特定の実施形態は、限定する意味で取り扱われるべきではない点を理解されたい。むしろ、その意図は、本発明の精神および範囲内に入る全ての変更、等価物および代替物を対象とするものである。

本開示の側面は、概して、ルール・サービスの分野に関し、より具体的には、ルール・エンジンの独立したインスタンスを横断したルールの実行を分散することに関する。本開示は、必ずしもそのような用途に限定されるものではないが、本開示の種々の側面は、この文脈を用いた種々の例の議論を通して認識され得る。

ルール・エンジンは、数多くの種類のリクエストを処理し、適切な応答を返すために使用され得る。ルール・エンジンは、それぞれが条件および関連付けられるアクションを有するルール・セットを利用して、データを処理し、結果を生成（またはフィルタ）する（例えば、処理済みのデータに基づいてアクションを選択する）ことができる。例えば、ルール・エンジンは、検索エンジンの一部として使用されてもよい。検索エンジンは、系統的なやり方で、要求される特定の情報の検索を実行する。検索の結果は、次いで、要求元に返される。どのように、どのような順序で検索の結果が提示されるかは、例えば、ルール・エンジンによって管理される。より具体的には、ルール・エンジンは、ルール・セットまたは複数のルール・セットを結果に適用して、結果が要求者に提示されるやり方を決定する。ルール・セットまたは複数のルール・セットは、ルールを生成するエンティティの目的に依存して異なる。

例えば、オンライン小売業者の場合、いくつかの理由のうちの１つのために特定の品物を奨励することが小売業者に有利である可能性がある。例えば、品物は、限られた保管期限を有している可能性があり、小売業者は、それが満了する前に、その品物をより多く販売する必要がある可能性がある。加えて、または代替的に、小売業者は、特定の供給者から品物を販売することについての特定の利益を受け取る可能性があり、よって、その供給元からより多くの品物を販売することに対して動機付けされる可能性がある。追加的に、または代替的に、小売業者は、新しい品物または異なる品物のための余地を生み出すため、より多くの特定の品物を販売することを望む可能性がある。これらの例示の状況のそれぞれにおいて、多くの他の場合において、小売業者にとって、どのように検索結果のリストが消費者に提示されるかをいくらか制御することができることが有利である。例えば、小売業者は、特定の品物が強調される、最初に示される、またはそうでなければ消費者の注意により容易にもたらされるような修正された検索結果を有し得る。小売業者は、このような制御を、消費者の検索の結果にルール・エンジンが適用するルール・セットまたは複数のルール・セットを介して発揮してもよい。

マイクロサービス環境では、本明細書においてマイクロサービスと参照される、種々のサービスが、マイクロサービス・プロバイダによってテナントに提供される。テナントは、例えば、オンライン小売業者であってよい。テナントに提供されるマイクロサービスは、例えば、検索結果の取得およびルール・セットの適用などであってもよい。マイクロサービス・プロバイダにとって、単一のマイクロサービス・プロバイダが複数のテナントにマイクロサービスを提供するマルチテナント・システムを動作させることが一般的である。このようなマイクロサービス・プロバイダは、例えば、共有クラウドシステムを介して、テナントにそのようなサービスを提供してもよい。

本開示において、マイクロサービス・プロバイダは、ルール・セットを検索結果に対し適用するサービスを提供する。したがって、マイクロサービス・プロバイダは、リクエストに応じてテナントについてのルールを実行するルール実行マイクロサービスを維持する。マルチテナント・システム内の各テナントは、自身のルールまたはルール・セットを有してもよく、これは、マイクロサービス・プロバイダに、要求されたマイクロサービスのマイクロサービス・プロバイダの実行中に適用されるように提供される。各ルール・セットは、マイクロサービス・プロバイダが、リクエストに応じてテナントについてのルール・セットを迅速に呼び出し、適用することができるように、マイクロサービス・プロバイダのメモリに格納される。典型的には、マルチテナント・システムにおいて、異なるテナントについて異なるセットのルールを呼び出して適用するプロセスを高速化するために、マイクロサービス・プロバイダは、並行して、ルール・エンジンの複数のインスタンスを同時に実行する。現在、ルール・エンジンの各インスタンスは、テナントすべてについてのすべてのルールを含む。このように、テナントからの複数のリクエストが同時にまたはその周辺に来た場合、異なるリクエストは、ルール・エンジンの異なるインスタンスに送信されて、リクエスト負荷を分散し、テナントに対し可能な限り迅速にレスポンスを返すようすることができる。

この現在のシステムの１つの欠点は、しかしながら、複数の場所に格納されるべき同一のルールの複製の大きな数である。より具体的には、マルチテナント・マイクロサービス・プロバイダが５，０００テナントを有し、各テナントが、適用されるべき平均１００のルールを有する場合、５，０００テナントのための１００ルールが、マイクロサービス・プロバイダのルール・エンジンのすべてのインスタンスにロードされる必要がある。言い換えると、５００，０００ルールが、ルール・エンジンのすべてのインスタンスにロードされる必要がある。いくつかの点において、ルールの数は、それほど多くのルールをロードするシステムが被るコスト、例えばメモリ消費が、ルール・エンジンの各インスタンス上に各テナントに対する各ルールの複製をロードすることによって提供される利益を上回るほどに十分に高くなる。

多数のルールを管理する１つの方法は、インスタンス間でテナントを均等に分割し、それぞれのインスタンスに割り当てられたテナントについてのルールのみを、それぞれのインスタンス上にロードすることである。例えば、テナント１～１００は、ルール・エンジンのインスタンスＡに割り当てられてもよいだろうし、テナント１０１～２００は、ルール・エンジンのインスタンスＢに割り当てられてもよいだろうし、テナント２０１～３００は、ルール・エンジンのインスタンスＣに割り当てられてもよいであろう。次いで、インスタンスＡは、テナント１～１００に関連付けられたルールのみを格納し、適用し、インスタンスＢは、テナント１０１～２００に関連付けられたルールのみを格納し、適用し、インスタンスＣは、テナント２０１～３００に関連付けられたルールのみを格納し、適用する。したがって、ルール分散マイクロサービスは、テナント１～１００のいずれかからの任意の入来リクエストがインスタンスＡにルーティングされるように、テナント１０１～２００のいずれかからの任意の入来リクエストがインスタンスＢにルーティングされるように、テナント２０１～３００のいずれかからの任意の入来リクエストがインスタンスＣにルーティングされるように、マイクロサービス・プロバイダからの要求を分散する。

しかしながら、すべてのルールの実行が、同量のリソースを必要としない。例えば、いくつかのテナントについてのルール・セットを実行することが、他のテナントについてのルール・セットを実行することよりも大きな実際の実行時間または負荷コストを被る可能性がある。したがって、ルール・エンジンのインスタンスを横断して多数のテナントを均等に分散しても、全てのテナントの集合的な負担または負荷をルール・エンジンのインスタンスを横断して均等に分散するとは限らない。よって、インスタンス間で均等にテナントを分割することは、マイクロサービス・プロバイダの機能性およびリソースを最適化するための最も効率的または効果的な方法ではない可能性がある。

本開示の実施形態は、各テナントによって生成される負荷に基づいて、ルール・エンジンの独立したインスタンスを横断してルールの実行を分散することによって、上記の問題および他の問題を克服し得る。したがって、マイクロサービス・プロバイダは、また、本明細書でさらに詳細に説明されるように、ルールを分散するルール分散マイクロサービスを維持する。関連付けられるテナントによって生成される負荷は、本明細書においては、その特定のテナントによって生成される「ルール負荷」と参照される。ルール負荷は、アルゴリズムによってテナント毎に決定され、このアルゴリズムは、これらに限定されるものではないが、所定の時間期間内のテナントによるルール評価リクエストの数、この所与の時間期間内のリクエスト当たりのルール・エンジンによって実行されるルール条件チェックの平均数、この所与の時間期間内のリクエスト当たりのルール・エンジンによりトリガされるアクションの平均数、この所与の時間期間内のリクエスト当たりの平均ルール評価コンテキスト・サイズ、テナント当たりの定義される条件事実の数、および、複雑性の構成値を含む要因を考慮する。

各テナントのルール負荷が既知となると、テナントすべてのルール負荷が全体ルール負荷に統合されてもよい。テナントは、次いで、各インスタンスが全体ルール負荷の略同一割合を処理するように、ルール・エンジンのインスタンス上で分散される。言い換えると、テナントは、すべてのテナントの累積ルール負荷を可能な限り均等に分散するようなやり方で、インスタンス上で分散される。このようにして、マイクロサービス・プロバイダの機能性およびリソースは、より効率的かつ効果的に最適化される。

上記利点は、例示の利点であり、限定として解釈されるべきではないことを理解されたい。本開示の実施形態は、本開示の精神および範囲内に留まりながら、上記利点のすべてを含んでもよいし、一部を含んでもよいし、またはいずれも含まない可能性もある。さらに、本開示は、検索エンジンの文脈において種々の実施形態の詳細な応用を開示しているが、実施形態は、ルール・エンジンの他の応用を対象としてもよく、本明細書に開示される例示の実施形態は、限定として解釈されるべきではないことを理解されたい。

ここで、図面を参照すると、図１は、本開示の実施形態による例示のルール実行システム１００のブロック図を示す。例示のルール実行システム１００は、マイクロサービス・プロバイダ１０２、ルール分散マイクロサービス１０４、複数のルール・エンジン・インスタンス１０６Ａ，１０６Ｂ，１０６Ｃ，１０６Ｄ（集合的にルール・エンジン・インスタンス１０６と参照される）、ルール監視コンポーネント１０８および複数のテナントＴ（ｎ）（集合的にテナント１１０と参照される）を含む。本開示の少なくとも１つの実施形態においては、マイクロサービス・プロバイダ１０２は、ルール分散マイクロサービス１０４を含む。しかしながら、本開示の他の実施形態においては、マイクロサービス・プロバイダ１０２およびルール分散マイクロサービス１０４は、分離しかつ区別されるシステム１００のコンポーネントである。

図１は、例示のルール実行システム１００の代表的な主要コンポーネントを示すことを意図することに留意されたい。いくつかの実施形態においては、しかしながら、個々のコンポーネントは、図１に表されたものより多くのまたはより少ない複雑性を有していてもよく、図１に示されるこれらのもの以外のコンポーネントまたはそれに追加のコンポーネントが存在してもよく、そのようなコンポーネントの数、種類および構成は、変化する可能性がある。例えば、図１は、４つのルール・エンジン・インスタンス１０６を有するルール実行システム１００を示すが、本開示の実施形態を実施するための好適なコンピューティング環境は、任意の数のルール・エンジン・インスタンスを含んでもよい。加えて、図１に示される種々のモデル、モジュール、システムおよびコンポーネントは、存在するとしても、複数のホストデバイスおよびリモート・デバイスを横断して存在し得る。

いくつかの実施形態においては、ルール実行システム１００は、クラウド・コンピューティング環境内で、または１または複数のクラウド・コンピューティング・サービスを用いて、実装されてもよい。種々の実施形態と一貫して、クラウド・コンピューティング環境は、１または複数のクラウド・コンピューティング・サービスを提供する、ネットワーク・ベースの分散データ処理システムを含んでもよい。さらに、クラウド・コンピューティング環境は、１または複数のデータセンタに配置され、ネットワークを介してリソースを共有するよう構成された多数のコンピュータ（例えば、数百または数千のコンピュータまたはそれ以上）を含んでもよい。

本開示の実施形態によれば、マイクロサービス・プロバイダ１０２は、複数のテナントにマイクロサービスを提供する。説明のために、図１に示される例示の実施形態においては、マイクロサービス・プロバイダ１０２は、４，０００テナント（テナントＴ１，テナントＴ２，…，テナントＴ４０００のように図１に示される）にマイクロサービスを提供し、これらのテナントは、テナント１１０と集合的に参照される。代替的な実施形態においては、マイクロサービス・プロバイダ１０２は、４，０００テナントより多くのまたはより少ないマイクロサービスを提供してもよい。本明細書で議論されるルール実行システム１００においては、マイクロサービス・プロバイダ１０２は、少なくとも部分的に、ルール・エンジンとして動作し、各テナント１１０にルール実行サービスを提供する。したがって、マイクロサービス・プロバイダ１０２は、テナント１１０の各々からのテナント固有ルール・セットを備える。各テナント固有ルール・セットは、異なる数のルールを有する可能性があり、もしくは、これらのルールの実行のための異なる量のリソースを必要とする可能性があり、またはその両方の可能性がある。

テナント１１０から受信されるルール実行リクエストに応答する効率を改善するために、マイクロサービス・プロバイダ１０２に提供されるルールは、ルール・エンジン・インスタンス１０６を横断して分散される。ルール・エンジン・インスタンス１０６の各々は、テナントからルール実行リクエストを受信すると、ルールを格納し、ロードし、実行することが可能であるルール・エンジンの少なくとも一部のコピーである。ルールの分散は、ルール分散マイクロサービス１０４によって管理される。特に、特定のテナント１１０に関連付けられるテナント固有ルール・セットのうちのすべてのルールが単一のルール・エンジン・インスタンス１０６に割り当てられるようなやり方で、ルールが分散される。各ルール・エンジン・インスタンス１０６は、割り当てられたルールを格納し、ロードし、実行する責任を負う。

本開示の実施形態によれば、各ルール・エンジン・インスタンス１０６にルールのすべてが割り当てられるのではなく、各ルール・エンジン・インスタンス１０６には、ルール・セットのサブセットが割り当てられる。特に、テナント１１０すべてについてのルール・セットが各ルール・エンジン・インスタンス１０６に割り当てられるのではなく、各ルール・エンジン・インスタンス１０６には、テナント１１０のサブセットが関係するルール・セットが割り当てられる。

より具体的には、図２を参照すると、どのようにルール・セットがルール・エンジン・インスタンス１０６に割り当てられるかは、方法２００によって管理される。第１に、動作２０４で、インメモリのルール評価モデルが各テナント１１０に対して生成される。インメモリのルール評価モデルは、本明細書において、ルール評価モデル、インメモリ・モデルまたはルールモデルと参照される可能性がある。本開示の少なくとも１つの実施形態においては、ルールモデルは、ルール分散マイクロサービス１０４により生成される。本開示の少なくとも一部の実施形態においては、各ルールモデルは、ルール・セットが提供されるデータのセットにどのように適用されるかを指定する。

動作２０８では、ワークロードが各ルールモデルに対して計算される。ルールモデルが各テナント１１０について生成されるので、ルールモデルに対して計算されるワークロードも、関連付けられるテナントのワークロードである。ワークロードは、ルールモデルを実行することが、マイクロサービス・エンジンに与える影響または負担を表す。この場合、マイクロサービス・エンジンは、ルール・エンジンである。各ルールモデル対するワークロードは、ルールモデルにおけるルールの数、各ルールに関連付けられる条件の数および複雑度、ルール評価リクエストの期待平均数、ルール評価コンテキストの複雑度など、ルールモデルの多くの側面に基づいて計算される。

本開示の少なくとも１つの実施形態によれば、ルールモデルのワークロードを計算するための特定のアルゴリズムは、以下の通りである：
（数１）
Ｗ（Ｔ）＝ｒ（ｔ）＊ｃ（ｔ）＊ａ（ｔ）＊（ｘ＋ｓ（ｔ）／ｆ）

アルゴリズムにおいて、変数Ｗ（Ｔ）は、テナントのワークロードを表す。変数ｒ（ｔ）は、所定の時間期間（ｔ）内で、ルール・エンジンによりテナントから受信されたルール評価リクエストの数を表す。本開示の少なくとも１つの実施形態によれば、所与の時間期間（ｔ）は、例えば、２分間であってもよい。変数ｃ（ｔ）は、ルール・エンジンが、それらのリクエストに答えるために考慮すべきルール条件の平均数を表す。変数ａ（ｔ）は、所与の時間期間（ｔ）内で、これらのリクエストに答えるためにルール・エンジンによりトリガされるアクションの平均数を表す。変数ｓ（ｔ）は、所与の期間内のそれらのリクエストの平均ルール評価コンテキスト・サイズを表す。本開示の少なくとも１つの実施形態によれば、評価コンテキストは、例えば、事実値（fact value）であってよい。したがって、リクエスト当たりの平均ルール評価コンテキスト・サイズは、例えば、所与の時間期間（ｔ）内にルール評価リクエストに渡された事実値の数であってもよい。変数ｆは、テナントが定義した条件事実（condition fact）の数を表す。本開示の少なくとも１つの実施形態によれば、条件事実は、限定なく、例えば、ユーザ・セグメント、地理的位置、リファラ、クライアント・デバイスの種類、性別、または年齢を含んでもよい。変数ｘは、複雑度の構成値を表し、これは、ワークロードを調整するために使用され得る。本開示の少なくとも１つの実施形態によれば、変数ｘのデフォルト値は１である。

本開示の少なくとも１つの実施形態によれば、ルール監視コンポーネント１０８は、ルール・エンジン上で特定のテナントによって生成されるルール負荷を測定するトラッキング・コンポーネントである。したがって、マイクロサービス・システム１００が運用される場合、ルール監視コンポーネント１０８は、下記に関するデータを受信する：所定の時間期間内のテナント当たりのルール評価リクエストの数、所与の時間期間内のリクエスト当たりの実行されるルール条件チェックの平均数、所与の時間期間内のリクエスト当たりのトリガされるアクションの平均数、所与の期間内のリクエスト当たりの平均ルール評価コンテキスト・サイズもしくはテナント当たりの定義される条件事実の数、またはその組み合わせ。

各ルールモデルのワークロードが決定されると、方法２００は、動作２１２に進み、ここで、これらのワークロードは、マイクロサービス・プロバイダの機能性およびリソースを最適化するために、組み上げられた（orchestrated）マイクロサービス・エンジン（例えば、ルール・エンジン・インスタンス１０６など）のセットの間でルールモデルを分散するために使用される。より具体的には、テナント１１０すべてについて計算されたワークロードは、インメモリのルール・エンジン分散モデルを生成するために考慮される。インメモリのルール・エンジン分散モデルに基づいて、ルール・セットは、テナント１１０のすべてのワークロードがルール・エンジン・インスタンス１０６を横断して可能な限り均等に分散されるように、ルール・エンジン・インスタンス１０６を横断して分散される。言い換えると、各ルール・エンジン・インスタンス１０６に割り当てられるテナント１１０の数または関連付けられるルール・セットは、変化する可能性があるが、各ルール・エンジン・インスタンス１０６に割り当てられるワークロードは、可能な限り等しい。したがって、各ルール・エンジン・インスタンス１０６は、全体のワークロードの略同一割合を処理している。よって、利用可能なシステムリソースは、ルール・エンジン・インスタンス１０６を横断して可能な限り均一に展開されることによって最適化される。

例えば、方法２００の実行は、テナントＴ１～Ｔ３０およびテナントＴ７００～Ｔ２０００についてのルールのルール・エンジン・インスタンスＡ１０６Ａへの割り当て、テナントＴ３１～Ｔ６９９およびテナントＴ２００１～Ｔ２５００についてのルールのルール・エンジン・インスタンスＢ１０６Ｂへの割り当て、テナントＴ２５０１～Ｔ３２２５およびテナントＴ３９００～Ｔ４０００についてのルールのルール・エンジン・インスタンスＣ１０６Ｃへの割り当て、テナントＴ３２２６～Ｔ３８９９のルールのルール・エンジン・インスタンスＤ１０６Ｄへの割り当てを結果としてもたらすかもしれない。

なお、上記は、例示の分散である。別の要因（ユーザ設定、種々のエンジンをホストするノードの相対的な処理パワーなど）に基づく別の分散も可能である。例えば、本開示の少なくともいくつかの実施形態においては、ルールモデルの分散は、個々のルール・エンジン・インスタンスに利用可能なリソースもしくはその能力、またはその両方に基づいて決定されてもよい。例えば、特定のルール・エンジン・インスタンスは、より大きなメモリを有するサーバ上にある可能性がある。したがって、この特定のルール・エンジン・インスタンスは、他のルール・エンジン・インスタンスよりも大きなメモリ・リソースへのアクセスを有する可能性がある。このようにして、ルールモデルをすべてのルール・エンジン・インスタンスを横断して略均等に分散するのではなく、より大きな割合が特定のルール・エンジン・インスタンスによって処理されるようにルールモデルを分散することが有利である可能性がある。

本開示の少なくとも１つの実施形態においては、インメモリのルール・エンジン分散モデルに基づくルール・エンジン・インスタンス１０６上のテナント１１０の分散または再分散は、対応するソースのルール・エンジン・インスタンス１０６から対応するターゲットのルール・エンジン・インスタンス１０６へのテナントの割り当てを変更することによって達成されてもよい。例えば、ルール・エンジン・インスタンスＡ１０６Ａからルール・エンジン・インスタンスＢ１０６ＢへのテナントＴ３１の割り当てを変更することは、ターゲットのインスタンス、この場合ではルール・エンジン・インスタンスＢ１０６Ｂ上で、テナントＴ３１のためのルールモデルをブートストラプすることと、次いで、マッピングテーブル内の対応するエントリを修正することとを含む。テナントＴ３１のためのルールモデルは、次いで、ソースのインスタンス、この場合ではルール・エンジン・インスタンスＡ１０６Ａから除去され、マッピングテーブル内の対応するエントリが、それに応じて修正される。

本開示のいくつかの実施形態によれば、上記の方法２００などによって、ワークロードがルール・エンジン・インスタンス１０６を横断して分散されると、図３に示される方法３００に従ってルール・リクエストが実行されてもよい。方法３００は、動作３０４から開始し、ここでは、テナント１１０からの入来ルール実行リクエストを受信する。本開示の少なくとも１つの実施形態においては、入来ルール実行リクエストは、マイクロサービス・プロバイダ１０２によって受信され、ルール分散マイクロサービス１０４は、次いで、マイクロサービス・プロバイダ１０２から入来ルール実行リクエストを受信する。

説明のために、一例では、消費者は、製品ウェブサイトでウィジェットを検索する可能性がある。テナントＴ５は、製品ウェブサイトに関連付けられ、検索サービス・プロバイダから検索結果を受信する。テナントＴ５は、次いで、これらの検索結果をルール実行リクエストとともにマイクロサービス・プロバイダ１０２に送信する。この例では、動作３０４において、入来ルール実行リクエストは、テナントＴ５に固有のルールを検索結果に適用して消費者に提示するための好ましい検索結果表現を返すためのマイクロサービス・プロバイダ１０２に対する要求である。

動作３０８では、受信されたリクエストに対するレスポンスを提供するために最も適したルール・エンジン・インスタンス１０６が、上述したインメモリのルール・エンジン分散モデルに基づいて、選択される。本開示の少なくとも１つの実施形態においては、最も適したルール・エンジン・インスタンス１０６は、ルール分散マイクロサービス１０４によって選択される。本開示の少なくとも１つの実施形態においては、ルール分散マイクロサービス１０４は、入来リクエストを分析し、ルール・エンジン・インスタンス１０６の間でルール・セットの分散を決定するために使用された基準を適用し、リクエストが送信されるべき適切なルール・エンジン・インスタンス１０６を選択する。

本開示の少なくとも１つの代替実施形態においては、最も適したルール・エンジン・インスタンス１０６は、上記マッピングテーブルを使用して特定されてもよい。例えば、最も適したルール・エンジン・インスタンス１０６は、いずれのテナントがリクエストに関連付けられているかを判定し、マッピングテーブルを参照して、いずれのルール・エンジン・インスタンス１０６が、そのテナントに関連付けられるかを特定し、次いで特定されたルール・エンジン・インスタンス１０６にリクエストを送信することによって特定されてもよい。

説明の例を続けると、ルール分散マイクロサービス１０４は、テナントＴ５のテナント固有ルールの複製を有するルール・エンジン・インスタンス１０６を選択する。この例では、ルール・エンジン・インスタンスＡ１０６Ａは、テナントＴ５のテナント固有ルールの複製を有する。したがって、動作３０８では、ルール分散マイクロサービス１０４は、ルール・エンジン・インスタンスＡ１０６Ａを選択する。

動作３１２では、ルール実行リクエストは、選択されたルール・エンジン・インスタンス１０６にルーティングされる。本開示の少なくとも１つの実施形態においては、ルール実行リクエストは、ルール分散マイクロサービス１０４によってルーティングされる。説明の例では、テナントＴ５からのルール実行リクエストは、選択されたルール・エンジン・インスタンス１０６Ａにルーティングされる。本開示の少なくとも１つの実施形態においては、検索結果は、ルール実行リクエストとともに、選択されたルール・エンジンに送信される。

動作３１６では、ルール実行リクエストが実行される。本開示の少なくとも１つの実施形態においては、ルール実行リクエストは、指定されたルール・エンジン・インスタンス１０６によって実行される。説明の例では、ルール・エンジン・インスタンス１０６Ａは、テナントＴ５についてのテナント固有ルールを、提供された検索結果に適用することによって、要求されたルール実行リクエストを実行する。テナントＴ５についてのテナント固有ルールは、例えば、特定の価格範囲内の検索結果内の任意の結果が、検索結果の提示において特定の順序でランク付けされるというルールを含んでもよい。テナントＴ５についてのテナント固有ルールは、さらに、特定の場所の特定の地理的距離内で利用可能な特定の価格範囲内の任意の結果が、検索結果の提示において特定の順序でランク付けされるというルールを含んでもよい。

動作３２０では、実行されたルール実行リクエストの結果は、マイクロサービス・プロバイダ１０２に返される。本開示の少なくとも１つの実施形態においては、実行されたルール実行リクエストの結果は、ルール実行リクエストを実行したルール・エンジン・インスタンス１０６によってマイクロサービス・プロバイダ１０２に返される。説明の例では、ルール・エンジン・インスタンス１０６Ａによって実行されたルール実行リクエストの結果は、マイクロサービス・プロバイダ１０２に返される。これらの結果は、上記で議論した２つのルールによる検索結果の優先順位付けを含む。マイクロサービス・プロバイダ１０２は、次いで、これらの優先順位付けされた結果をテナントＴ５に提供することができ、テナントＴ５は、優先順位付けされた結果を消費者に提示することができる。

動作３２４において、非同期メッセージがルール監視コンポーネント１０８に送信される。本開示の少なくとも１つの実施形態においては、非同期メッセージは、ルール実行リクエストを実行したルール・エンジン・インスタンス１０６によって送信される。本開示の少なくとも１つの実施形態においては、非同期メッセージは、ルール・メトリックス、または、ルール・メトリックスを決定するために使用される情報を含む。説明の例では、非同期メッセージは、ルール・エンジン・インスタンス１０６Ａによってルール監視コンポーネント１０８に送信され、これに限定されるものではないが、ルール実行中に適用されたルールの数、および、これらのルールを実行するためにチェックされるべき条件または事実の数を含む。

動作３２８では、実行されたルール実行リクエストに関するルール・メトリックスが集約される。本開示の少なくとも１つの実施形態においては、ルール・メトリックスは、ルール監視コンポーネント１０８によって集約される。説明する例においては、ルールの実行中に適用されたルールの数およびそれらのルールを実行するためにチェックされるべき条件または事実の数を含むデータは、マイクロサービス・プロバイダ１０２によって受信された他のルール実行リクエストと類似のデータとともに集約される。

これらの集約されたルール・メトリックスは、次いで、各ルールモデルまたはテナント１１０についてワークロードを再計算または更新するために使用されてもよい。例えば、集約されたルール・メトリックス内のデータは、方法２００の動作２０８で提供されるアルゴリズムに戻って入力されてもよい。システム１００の動作中に収集されるデータに基づいてワークロードを更新し、更新されたワークロードをインメモリのルール・エンジン分散モデルに戻して供給することによって、ルール・エンジン・インスタンス間のルールモデルの分散は、さらに、かつ、繰り返して、最適化されてもよい。例えば、本開示の少なくとも１つの実施形態においては、一定の間隔で集約されたルール・メトリックスからのデータに基づいてワークロードが更新されてもよい。

上記で説明した方法２００によるなど、最初、ワークロードがルール・エンジン・インスタンス１０６を横断して分散されると、本開示のいくつかの実施形態によれば、時間にわたって動的に分散がさらに最適化されてもよい。このような更なるルール最適化およびスケーリングは、図４に示されるようなシステム４００によって実行されてもよい。

より具体的には、システム４００は、図１を参照して上述したルール分散マイクロサービス１０４と実質的に類似するルール分散マイクロサービス４０４と、図１を参照して上述したルール・エンジン・インスタンス１０６と実質的に類似する複数のルール・エンジン・インスタンス４０６と、図１を参照して上述したルール監視コンポーネント１０８と実質的に類似するルール監視コンポーネント４０８とを含む。システム４００は、さらに、ルール分散最適化およびスケーリング・コンポーネント４１２およびルールストア４１６を含む。

本開示の少なくとも１つの実施形態によれば、ルール分散最適化およびスケーリング・コンポーネント４１２は、ルール監視コンポーネント４０８から、集約されたルール・メトリックスを要求するように構成される。リクエストは、例えば、一定の時間間隔で送信されてもよい。さらに、ルール監視コンポーネント４０８は、集約されたルール・メトリックスを、ルール分散最適化およびスケーリング・コンポーネント４１２に返すように構成される。要求されたルール・メトリックスは、いずれのテナントによっていずれのルールが実行されるか、各ルールのメモリ消費および平均ルール実行のＣＰＵ消費に関するデータを含んでもよい。加えて、ルール分散最適化およびスケーリング・コンポーネント４１２は、ルール分散マイクロサービス４０４と通信可能に結合し、ルール分散マイクロサービス４０４が、ルール分散最適化およびスケーリング・コンポーネント４１２から、更新されたルール・エンジン分散モデルを受信することができるようにする。そのような更新されたルール・エンジン分散モデルは、その後、方法２００などによるルール・セットの割り当て、もしくは、方法３００などによるルール・リクエストの後続の実行、またはその両方において使用されてもよい。

本開示の少なくとも１つの実施形態によれば、ルールストア４１６は、ルールモデルのすべてのルールのすべてを格納するように構成される。言い換えると、ルールストア４１６は、マイクロサービス・プロバイダ（図１に示すマイクロサービス・プロバイダ１０２など）に提供され、ルール・エンジン・インスタンス４０６の間で分散されるルールのためのレポジトリとして動作するよう構成される。

組み上げられたマイクロサービス・エンジンのセット間でルールモデルの分散の更なる最適化の例示の方法５００が図５に示される。本開示の少なくともいくつかの実施形態においては、方法５００は、システム４００を使用して実現される。方法５００は、上記方法２００によるなど、ルール・エンジン・インスタンス１０６を横断して分散されたワークロードから開始される。

動作５０４において、ルール監視コンポーネント４０８から、集約されたルール・メトリックスが要求される。本開示の少なくとも１つの実施形態においては、ルール分散最適化およびスケーリング・コンポーネント４１２は、ルール監視コンポーネント４０８から、集約されたルール・メトリックを要求する。本開示の少なくとも１つの実施形態においては、ルール分散最適化およびスケーリング・コンポーネント４１２は、規則的な間隔で、集約されたルール・メトリックを要求する。特に、要求される集約されたルール・メトリックは、限定なく、いずれのルールがいずれのテナントによって実行されるか、各ルールのメモリ消費および平均ルール実行のＣＰＵ消費を含んでもよい。

動作５０８では、ルールモデルとルール・エンジン・インスタンス４０６との間の割り当てが再計算される。本開示の少なくとも１つの実施形態においては、ルールモデルは、ルールストア４１６からロードされる。本開示の少なくとも１つの実施形態においては、ルール分散最適化およびスケーリング・コンポーネント４１２は、（ルールストアからロードされた）ルールモデルとルール・エンジン・インスタンス４０６との間の割り当てを再計算して、ルール・エンジン・インスタンス４０６を横断した均衡された中央処理ユニットおよびメモリ消費を達成する。本開示の少なくとも１つの実施形態においては、期待メモリおよびＣＰＵの消費が上方の事前定義された値を上回る場合、ルール分散最適化およびスケーリング・コンポーネント４１２は、追加のルール・エンジン・インスタンス４０６をインスタンス化する。しかしながら、メモリおよびＣＰＵ消費が下方の事前定義された値を下回る場合、ルール分散最適化およびスケーリング・コンポーネント４１２は、ルール・エンジン・インスタンス４０６をシャットダウンし、システムリソースを開放する。

動作５１２においては、更新されたルール・エンジン分散モデルがルール分散マイクロサービス４０４に送信される。本開示の少なくとも１つの実施形態においては、ルール分散最適化およびスケーリング・コンポーネント４１２は、更新されたルール・エンジン分散モデルを、ルール分散マイクロサービス４０４に送信する。

動作５１６では、リクエストは、各ルール・エンジン・インスタンス４０６がメモリ内にロードするもしくは利用可能にする、もしくはその両方にする必要がある対応するルールの識別情報とともに、各ルール・エンジン・インスタンス４０６に送信される。本開示の少なくとも１つの実施形態においては、ルール分散最適化およびスケーリング・コンポーネント４１２は、各ルール・エンジン・インスタンス４０６がメモリ内にロードするもしくは利用可能にする必要のあるルールの識別とともに、各ルール・エンジン・インスタンス４０６にリクエストを送信する。

本開示の少なくとも１つの実施形態においては、機械学習を使用して、テナント当たりの期待されるルール負荷を予測することができる。例えば、時刻または別の定量的な変数に基づいて、テナントのルール負荷は、変動する可能性がある。これらの変動は、時計または定量的な変数を検出するように構成されるセンサによって検出されてもよい。このような予測により、システムは、特定のルール・エンジン・インスタンスに高負荷がかかることを防止するやり方でルールモデルを先制的に分散または再分散することが可能になる。

本開示の少なくとも１つの実施形態においては、ルールの実行は、一緒に共通して実行されるそれらを識別するために分析されてもよい。この要因は、ルール・エンジン・インスタンスを横断したルールの分散の管理に使用することができる。

ここで、図６を参照すると、本開示の実施形態に従う、（例えば、１または複数のプロセッサ回路またはコンピュータのコンピュータ・プロセッサを用いて）本明細書で説明される方法、ツールおよびモジュールおよび任意の関連する機能の１または複数を実装する際に利用され得る、例示のコンピュータ・システム６０１の上位レベルのブロック図が示される。いくつかの実施形態においては、コンピュータ・システム６０１の主要なコンポーネントは、１以上のＣＰＵ６０２、メモリ・サブシステム６０４、ターミナル・インタフェース６１２、ストレージ・インタフェース６１４、Ｉ／Ｏ（入力／出力）デバイス・インタフェース６１６およびネットワーク・インタフェース６１８を含んでもよく、これらのすべては、メモリバス６０３、Ｉ／Ｏバス６０８およびＩ／Ｏバスインタフェース・ユニット６１０を介したコンポーネント間通信のために、直接的にまたは間接的に、通信可能に結合されている。

コンピュータ・システム６０１は、１以上の汎用プログラマブルな中央処理ユニット（ＣＰＵ）６０２Ａ、６０２Ｂ、６０２Ｃおよび６０２Ｄを包含し、本明細書において、総称的にＣＰＵ６０２と参照する。いくつかの実施形態においては、コンピュータ・システム６０１は、比較的大規模なシステムに典型的なマルチ・プロセッサを包含し得るが、しかしながら、他の実施形態においては、コンピュータ・システム６０１は、あるいはシングルＣＰＵシステムであってもよい。各ＣＰＵ６０２は、メモリ・サブシステム６０４に格納された命令を実行し、１以上のレベルのオンボード・キャッシュを含んでもよい。

システムメモリ６０４は、ランダム・アクセス・メモリ（ＲＡＭ）６２２またはキャッシュ・メモリ６２４など、揮発性メモリの形態でコンピュータ・システム可読な媒体を含んでもよい。コンピュータ・システム６０１は、さらに、他のリムーバブル／非リムーバブルの揮発性／不揮発性コンピュータ・システム・ストレージ媒体を含んでもよい。一例として、ストレージ・システム６２６は、”ハード・ドライブ”などの非ポータブルの不揮発性磁気媒体から読み出すおよび磁気媒体へ書き込むために提供される。図示しないが、リムーバブルの不揮発性磁気ディスク（例えば、「フロッピーディスク」（登録商標））から読み出し、または、磁気ディスクへ書き込むための磁気ディスク・ドライブ、または、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭまたは他の光学メディアなどのリムーバブルの不揮発性光学ディスクから読み出しおよび光学ディスクへ書き込むための光学ディスク・ドライブが提供されてもよい。加えて、メモリ６０４は、例えば、フラッシュメモリ・スティック・ドライブまたはフラッシュドライブなどのフラッシュメモリを含んでもよい。メモリ装置は、１以上のデータ・メディア・インタフェースによってメモリバス６０３に接続されてもよい。メモリ６０４は、種々の実施形態の機能を実現するよう構成されたプログラム・モジュールのセット（少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでいてもよい。

１または複数のプログラム／ユーティリティ６２８は、それぞれ、プログラム・モジュール１０３０の少なくとも１つのセットを有しており、メモリ６０４に格納されてもよい。プログラム／ユーティリティ６２８は、ハイパーバイザ（また仮想マシンモニタとも参照される）、１以上のオペレーティング・システム、１以上のアプリケーション・プログラム、他のプログラム・モジュールおよびプログラム・データを含んでもよい。オペレーティング・システム、１以上のアプリケーション・プログラム、他のプログラム・モジュールおよびプログラム・データの各々またはこれらのいくつかの組み合わせは、ネットワーキング環境の実装を含んでもよい。プログラム・モジュール１０３０は、概して、種々の実施形態の機能または方法論を実行する。

メモリバス６０３が、ＣＰＵ６０２間の直接通信経路を提供する単一のバス構造として図６に示されているが、メモリ・サブシステム６０４、Ｉ／Ｏバスインタフェース６１０およびメモリバス６０３は、いくつかの実施形態においては、複数の異なるバスまたは通信経路を含んでもよく、これらは、階層、スターまたはウェブ構成におけるポイント・ツー・ポイント・リンク、マルチ階層バス、パラレルおよび二重化経路、または任意の他の適切なタイプの構成などの任意の種々の形態に配置されてもよい。さらに、Ｉ／Ｏバスインタフェース６１０およびＩ／Ｏバス６０８が、単一のそれぞれのユニットとして示されているが、コンピュータ・システム６０１は、いくつかの意実施形態においては、複数のＩ／Ｏバス・インタフェース・ユニット６１０、複数のＩ／Ｏバス６０８、またはこれらの両方を含んでもよい。さらに、Ｉ／Ｏバス６０８を、種々のＩ／Ｏデバイスに達する種々の通信経路から分離する複数のＩ／Ｏインタフェース・ユニットが示されるが、他の実施形態においては、Ｉ／Ｏデバイスのいくつかまたは全部が、直接、１以上のシステムＩ／Ｏバスに接続されてもよい。

いくつかの実施形態においては、コンピュータ・システム６０１は、マルチ・ユーザ・メインフレーム・コンピュータ・システム、単一ユーザ・システム、または、サーバ・コンピュータ、またはごく少数のユーザインタフェースを有するか全く有さない類似のデバイスであってもよいが、他のコンピュータ・システム（クライアント）からの要求を受信する。さらに、いくつかの実施形態においては、コンピュータ・システム６０１は、デスクトップ・コンピュータ、ポータブル・コンピュータ、ラップトップまたはノートブック・コンピュータ、タブレット・コンピュータ、ポケット・コンピュータ、電話、スマートフォン、ネットワーク・スイッチまたはルータ、または任意の他の適切なタイプの電子機器として実装されてもよい。

図６は、例示的なコンピュータ・システム６０１の代表的な主要なコンポーネントを描くことを意図している点に留意されたい。いくつかの実施形態においては、しかしながら、個々のコンポーネントは、図６に表されるよりも多くのまたはより少ない複雑性を有していてもよく、図６に示されたもの以外のまたはこれらに加えて別のコンポーネントがあってもよく、このようなコンポーネントの数、タイプおよび構成は異なる場合がある。

この開示は、クラウド・コンピューティングについての詳細な説明を含むが、本明細書で詳述される教示の実装は、クラウド・コンピューティング環境に限定されないことに前もって理解されたい。むしろ、本発明の実施形態は、現時点で知られた、またはこれから開発される他の任意のタイプのコンピューティング環境と併せて実装可能性である。

クラウド・コンピューティングは、最小の管理労力またはサービス・プロバイダとの対話で迅速にプロビジョニングおよびリリースされ得る、構成可能なコンピューティング・リソース（例えば、ネットワーク、ネットワーク帯域、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシンおよびサービス）の共有プールへの便利なオンデマンドのネットワーク・アクセスを可能とする、サービス配布のモデルである。このクラウド・モデルは、少なくとも５つの特性、少なくとも３つのサービス・モデルおよび少なくとも４つのデプロイメント・モデルを含む可能性がある。

特性は、以下の通りである。

オンデマンド・セルフ・サービス：クラウド・コンシューマは、サービス・プロバイダとの人的な対話を必要とせずに自動的に必要なだけ、サーバ時間およびネットワーク・ストレージなどのコンピュータ能力を一方的にプロビジョニングすることができる。

広帯域ネットワーク・アクセス：能力は、ネットワーク越しに利用可能であり、異種シン・クライアントまたはシック・クライアント・プラットフォーム（例えば、モバイルフォン、ラップトップ、ＰＤＡ）による使用を促進する標準的なメカニズムを介して、アクセスされる。

リソース・プーリング：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを用いて複数のコンシューマに提供するためにプールされ、種々の物理的および仮想的リソースが需要に従って動的に割り当てられ、また、再割り当てられる。コンシューマは、一般的に、提供されるリソースの正確な場所を管理したり、知識を有したりせず、しかし、より高度な抽象レベル（例えば国、州、またはデータセンタ）にて場所を指定することが可能であるという意味で、場所の独立感がある。

迅速な弾力性：能力は、迅速かつ柔軟に、いくつかの場合では自動的に、プロビジョニングされて素早くスケール・アウトすることができ、また、迅速にリリースされて素早くスケール・インすることができる。コンシューマにとって、プロビジョニング利用可能な能力は、しばしば外面的には無制限のように見え、任意の時間に任意の量を購入することができる。

測量されたサービス：クラウドシステムは、サービスのタイプにとって適切なある抽象レベル（例えば、ストレージ、処理、帯域幅、アクティブ・ユーザ数）での計量能力を利用することによって、自動的にリソース使用を制御し、また最適化する。リソース使用量は、監視され、制御されおよび報告されて、利用サービスのプロバイダおよびコンシューマの双方に対する透明性を提供する。

サービス・モデルは、以下の通りである。

ソフトウェア・アズ・ア・サービス（ＳａａＳ）：コンシューマに提供される能力は、クラウド・インフラストラクチャ上で稼働するプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザ（例えばウェブベースの電子メール）などのシン・クライアント・インタフェースを介して種々のクライアント・デバイスからアクセス可能である。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、ストレージ、または、限定されたユーザ固有のアプリケーション構成設定の潜在的な例外を除いて個々のアプリケーション能力すらも含む下層のインフラストラクチャを管理または制御しない。

プラットフォーム・アズ・ア・サービス（ＰａａＳ）：コンシューマに提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを用いて作成された、コンシューマ作成または獲得のアプリケーションをクラウド・インフラストラクチャ上にデプロイすることである。コンシューマは、ネットワーク、サーバ、オペレーティング・システムまたはストレージを含む下層のクラウド・インフラストラクチャを管理または制御しないが、デプロイされたアプリケーションおよび場合によってはアプリケーション・ホスティング環境の構成への制御を有する。

インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）：コンシューマに提供される能力は、処理、ストレージ、ネットワーク、および、コンシューマが、オペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアをデプロイし、稼働させることができる他の基本的なコンピューティング・リソースを提供することである。コンシューマは、下層のクラウド・インフラストラクチャを管理または制御しないが、オペレーティング・システム、ストレージ、デプロイされたアプリケーションに対する制御、および、場合によっては、選択したネットワーキング・コンポーネント（例えば、ホストファイアウォール）の限定された制御を有する。

デプロイメント・モデルは、以下の通りである。

プライベート・クラウド：クラウド・インフラストラクチャは、１つの組織のためだけに使用される。これは、組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスが存在し得る。

コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織により共有され、共通の懸念（例えば、ミッション、セキュリティ要件、ポリシーおよびコンプライアンスに関する考慮事項）を有する特定のコミュニティをサポートする。これは、組織または第三者によって管理されてもよく、オンプレミスまたはオフプレミスが存在し得る。

パブリック・クラウド：クラウド・インフラストラクチャは、一般公衆、または、大きな業界団体が利用可能であり、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：クラウド・インフラストラクチャは、２以上のクラウド（プライベート、コミュニティまたはパブリック）の混成であり、これらのクラウドは、固有のエンティティのままであるが、しかし、データおよびアプリケーションのポータビリティを可能とする標準化されたまたは独自の技術（例えばクラウド間の負荷分散のためのクラウド・バースティング）によって結合される。

クラウド・コンピューティング環境は、ステートレス性、低結合、モジュール性および意味論的な相互運用性に重点を置いたサービス指向である。クラウド・コンピューティングの核心は、相互接続された複数のノードのネットワークを含むインフラストラクチャである。

ここで、図７を参照すると、例示的なクラウド・コンピューティング環境５０が示されている。図示するように、クラウド・コンピューティング環境５０は、１以上のクラウド・コンピューティング・ノード１０を含み、これと、例えば、ＰＤＡまたは携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃもしくは自動車コンピュータ・システム５４Ｎまたはこれらの組み合わせなどの、クラウド・コンシューマによって使用されるローカル・コンピューティング・デバイスが通信してもよい。ノード１０は、互いに通信してもよい。これらは、プライベート、コミュニティ、パブリックもしくはハイブリッド・クラウドなど上述したような、またはこれらの組み合わせなどの１以上のネットワークにおいて、物理的にまたは仮想的にグループ化（図示しない）されてもよい。これは、クラウド・コンピューティング環境５０が、インフラストラクチャ、プラットフォームもしくはソフトウェアまたはこれらの組み合わせをサービスとして提供することを可能とし、これらについては、クラウド・コンシューマは、リソースをローカル・コンピューティング・デバイス上で維持する必要がない。図７に示されるコンピューティング・デバイス５４Ａ～５４Ｎのタイプは、説明する目的のみであり、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０が、任意のタイプのネットワーク、ネットワークアドレス可能な接続（例えば、ウェブ・ブラウザを使用して）またはこれらの両方を介して、任意のタイプのコンピュータ化されたデバイスと通信することができることが理解される。

ここで、図８を参照すると、クラウド・コンピューティング環境５０（図７）によって提供される機能抽象レイヤのセットが示される。図８に示すコンポーネント、レイヤおよび機能が、説明する目的のみであり、本発明の実施形態は、これらに限定されないことを事前に理解されるである。示すように、以下のレイヤおよび対応する機能が提供される。

ハードウェアおよびソフトウェア・レイヤ６０は、ハードウェアおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例には、メインフレーム６１、ＲＩＳＣ（縮約命令セットコンピュータ）アーキテクチャに基づくサーバ６２、サーバ６３，ブレードサーバ６４、ストレージ・デバイス６５およびネットワークおよびネットワーキング・コンポーネント６６を含む。いくつかの実施形態においては、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化レイヤ７０は、抽象化レイヤを提供し、そこから仮想化サーバ７１、仮想化ストレージ７２、バーチャル・プライベート・ネットワークを含む仮想化ネットワーク７３、仮想化アプリケーションおよびオペレーティング・システム７４、および仮想クライアント７５などの仮想化エンティティの例が提供される。

一例においては、管理レイヤ８０は、以下に説明する機能を提供してもよい。リソース・プロビショニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソースおよび他のリソースの動的な調達を提供する。メータリングおよびプライシング８２は、リソースがクラウド・コンピューティング環境内で利用されるコストの追跡およびこれらのソースの消費に対する請求またはインボイスの送付を提供する。一例においては、これらのリソースは、アプリケーション・ソフトウェアのライセンスを含んでもよい。セキュリティは、クラウド・コンシューマおよびタスクについての本人確認、並びに、データおよび他のリソースに対する保護を提供する。ユーザポータル８３は、コンシューマおよびシステム管理者に対しクラウド・コンピューティング環境へのアクセスを提供する。サービス・レベル・マネジメント８４は、要求されるサービス・レベルを満たすようにクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス・レベル合意（ＳＬＡ）の計画と履行８５は、ＳＬＡに従って、将来の要求が予期されるクラウド・コンピューティグ・リソースの事前配置および調達を提供する。

ワークロード・レイヤ９０は、クラウド・コンピューティング環境が利用される機能性の例を提供する。ワークロードおよびこのレイヤから提供される機能の例には、マッピングおよびナビゲ―ション９１、ソフトウェア開発およびライフサイクル管理９２、仮想クラスルーム教育分散９３、データ・アナリティクス処理９４、トランザクション処理９５、モバイル・デスクトップ９６が含まれる。

上記実施形態に加えて、より少ない動作ステップ、より多くの動作ステップまたは異なる動作ステップを有する他の実施形態が企図される。また、いくつかの実施形態は、上記動作ステップの一部または全部を異なる順序で実行してもよい。さらに、複数の動作が同時に生じてもよく、または、より大きな処理の内側部分として生じてもよい。例示的に実施形態に従ってモジュールが列挙され、また、説明されるが、特定のモジュールの必要性を示すことを意味するものではなく、または他の潜在的なモジュール（または特定のモジュールに適用される機能／目的）の排除を示すことを意味するものではない。

上記においては、種々の実施形態が参照された。しかしながら、本開示は、具体的に説明されるものに限定されるものではないことを理解されたい。代わりに、説明された特徴および要素の任意の組み合わせは、異なる実施形態に関連するかどうかにかかわらず、本開示を実装および実施することが企図される。記載される実施形態の範囲および精神から逸脱することなく、当業者には多くの修正および変形が明らかである可能性がある。さらに、本開示の実施形態は、他の潜在的な解決策を越えたまたは先行技術を越えた利点を達成し得るが、所与の実施形態によって特定の利点が達成されるかどうかは、本開示を限定するものではない。したがって、説明された側面、特徴、実施形態および利点は、単なる例示であり、特許請求の範囲に明示的に記載された場合を除き、添付の特許請求の範囲の要素または限定であると見なされない。

本開示は、システム、方法もしくはコンピュータ・プログラム製品またはこれらの組み合わせであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の側面を実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読ストレージ媒体を含んでもよい。

コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持し格納する有形のデバイスであってよい。コンピュータ可読ストレージ媒体は、例えば、これに限定されるものではないが、電子的ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイスまたは上記の任意の適切な組み合わせであってよい。コンピュータ可読ストレージ媒体のより具体的な例示の例示列挙としては、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリー・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリー・メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、ポータブル・コンパクト・ディスク・リード・オンリー・メモリ（ＣＤ－ＲＯＭ）、デジタル・バーサタイル・ディスク（ＤＶＤ）、メモリースティック、フロッピーディスク（登録商標）、パンチカードまたは記録された命令を有する溝内の隆起構造のような機械的エンコードされたデバイス、および上記の任意の適切な組み合わせが含まれる。コンピュータ可読ストレージ媒体は、本明細書で使用されるように、電波、自由伝搬する電磁波、導波路または他の伝送媒体を伝搬する電磁波（たとえば、ファイバ光ケーブルを通過する光パルス）または、ワイヤを通して伝送される電気信号のような、それ自体が一時的な信号として解釈されるものではない。

本明細書で説明されるコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からそれぞれのコンピュータ／処理デバイスに、または、例えばインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワークもしくは無線ネットワークまたはこれらの組み合わせといったネットワークを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータもしくはエッジサーバまたはこれらの組み合わせを含んでもよい。各コンピュータ／処理デバイスにおけるネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、機械語命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、１以上のプログラミング言語の任意の組み合わせで書かれたソース・コードあるいはオブジェクト・コードであってよく、１以上のプログラミング言語は、Ｓｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋またはこれらに類するもなどのオブジェクト指向言語、Ｃプログラミング言語または類似のプログラミング言語などの従来型の手続型言語を含む。コンピュータ可読プログラム命令は、スタンド・アローンのソフトウェア・パッケージとして、全体としてユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上かつ部分的に遠隔のコンピュータ上で、または、完全に遠隔のコンピュータまたはサーバ上で実行されてもよい。後者のシナリオでは、遠隔のコンピュータは、ユーザのコンピュータに、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通じて接続されてもよく、あるいは接続は、（例えば、インターネット・サービス・プロバイダを用いてインターネットを通じて）外部コンピュータになされてもよい。いくつかの実施形態においては、電気的回路は、本発明の側面を実行するために、コンピュータ可読プログラム命令の状態情報を利用して、電気的回路を個別化することによって、コンピュータ可読プログラム命令を実行してもよく、この電気的回路は、例えば、プログラマブル・ロジック回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ）を含む。

本発明の側面は、本明細書において、本発明の実施形態に従った方法、装置（システム）およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照しながら、説明される。フローチャート図もしくはブロック図またはその両方の各ブロック、および、フローチャート図もしくはブロック図またはその両方における複数のブロックの組み合わせは、コンピュータ可読プログラム命令によって実装されてもよいことが理解されよう。

これらのコンピュータ可読プログラム命令は、汎用コンピュータおよび特定用途コンピュータのプロセッサまたは他のプログラマブル・データ処理装置に提供され、コンピュータのプロセッサまたは他のプログラマブル・データ処理装置を介して実行される命令が、フローチャート図もしくはブロックまたはその両方のブロックまたは複数のブロックにおいて特定される機能／作用を実装するための手段を作成するように、マシンを生成する。これらのコンピュータ可読プログラム命令は、また、コンピュータ、プログラマブル・データ処理装置もしくは他のデバイスまたはこれらの組み合わせに特定のやり方で機能するよう指示できるコンピュータ可読ストレージ媒体に格納され、それに格納された命令を有するコンピュータ可読ストレージ媒体に、フローチャートもしくはブロックまたはその両方のブロックまたは複数のブロックで特定される機能／作用の側面を実装する命令を含む製品が含まれるようにする。

コンピュータ可読プログラム命令は、また、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスにロードされ、コンピュータ、他のプログラマブル・データ処理装置または他のデバイス上で一連の動作ステップを実行させて、コンピュータ、他のプログラマブル・データ処理装置または他のデバイス上で実行される命令が、フローチャートもしくはブロックまたはその両方のブロックまたは複数のブロックで特定される機能／作用の側面を実装するように、コンピュータ実装処理を生成することもできる。

図面におけるフローチャートおよびブロック図は、本発明の種々の実施形態に従ったシステム、方法およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能性および動作を示す。この点に関して、フローチャートまたはブロック図の各ブロックは、特定の論理機能を実装するための１以上の実行可能な命令を含む、モジュール、セグメントまたは命令の部分を表す可能性がある。いくつかの代替の実装では、ブロックにおいて言及された機能は、図面に示された順序から外れて生じる可能性がある。例えば、連続して示される２つのブロックは、実際には、１つのステップとして実現されてもよく、同時に、実質的に同時に、一部または全部が時間的に重なり合う態様で、実行されてもよく、あるいは、複数のブロックは、関与する機能性に応じて逆の順序で実行されてもよい。ブロック図もしくはフローチャート図またはその両方の各ブロックおよびブロック図もしくはフローチャート図またはその両方の複数のブロックの組み合わせが、特定の機能または作用を実行し、または、特別な目的のハードウェアおよびコンピュータ命令の組み合わせを実施する、特定目的ハードウェアベースのシステムによって実装されてもよいことに留意されたい。

本明細書で使用される用語は、特定の実施形態を説明することのみを目的とし、種々の実施形態を限定することを意図するものではない。本明細書で使用されるように、単数形「ａ」、「ａｎ」および「ｔｈｅ」は、文脈が明確に示さない限り、複数形も含むことを意図している。さらに、用語「含む（ｉｎｃｌｕｄｅ）」もしくは「含んでいる（ｉｎｃｌｕｄｉｎｇ）」またはこれらの両方は、この明細書で使用される場合、記載された特徴、整数、ステップ、動作、要素もしくはコンポーネントまたはこれらの組み合わせの存在を指定し、１以上の他の特徴、整数、ステップ、動作、要素、コンポーネントもしくはこれらのグループまたはこれらの組み合わせの存在または追加を除外するものではないことを理解されたい。前述した種々の実施形態の例示の実施形態の説明において、添付の図面（ここで、同様の数字は同様の要素を表す）に参照が行われており、これは、本明細書の一部を形成し、それは、種々の実施形態を実施することができる、特定の例示の実施形態を説明するために示される。これらの実施形態は、当業者が実施形態を実施することができるように充分に詳細に説明されたが、他の実施形態が使用されてもよく、論理的、機械的、電気的および他の変更が、種々の実施形態の範囲を逸脱することなく行える。前述の説明においては、種々の実施形態を完全に理解するべく多くの具体的な詳細が述べられた。しかしながら、種々の実施形態は、これらの特定の詳細なしに実施することができる。いくつかの他の例では、実施形態をあいまいにしないために、周知の回路、構造および技術については、詳細に説明されていない。

本明細書で使用される場合、項目を参照して使用される場合の「複数の（ａ ｎｕｍｂｅｒ ｏｆ）」は、１または複数の項目を意味する。例えば、「複数の異なる種類のネットワーク（ａ ｎｕｍｂｅｒ ｏｆ ｄｉｆｆｅｒｅｎｔ ｎｅｔｗｏｒｋｓ）」は、複数の異なる種類のネットワークである。

異なる参照番号が、共通の番号および後続する異なる文字を含む（例えば、１００ａ，１００ｂ，１００ｃ）または句読点および後続する異なる番号を含む（例えば、１００‐１、１００‐２または１００．１、１００．２）場合、文字または後続する番号を除く参照文字のみの使用（例えば、１００など）は、全体としての要素のグループ、グループの任意のサブセットまたはグループの例示的な標本を参照する可能性がある。

さらに、項目のリストと共にフレーズ「の少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ）」が使用される場合、リストされた項目のうちの１または複数の異なる組み合わせが使用されることを意味し、リスト内の各項目のうちの１つのみが必要とされ得る。言い換えると、フレーズ「の少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ）は、任意の項目の組み合わせおよび項目の数が、リストから使用され得るが、しかしながら、リスト内のすべての項目が必要なわけではない。項目は、特定のオブジェクト、物またはカテゴリであってよい。

例えば、限定なく、「項目Ａ、項目Ｂまたは項目Ｃの少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ ｉｔｅｍ Ａ，ｉｔｅｍ Ｂ ｏｒ ｉｔｅｍ Ｃ）」は、項目Ａ、項目Ａおよび項目Ｂ、または項目Ｂを含む可能性がある。この例は、また、項目Ａ、項目Ｂおよび項目Ｃ、または項目Ｂおよび項目Ｃを含んでもよい。もちろん、これらの項目の任意の組み合わせが存在し得る。いくつかの説明する例では、「の少なくとも１つ（ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ）」は、例えば、限定なく、項目Ａの２つ；項目Ｂの１つ、項目Ｃの１０つ、項目Ｂの４つおよび項目Ｃの７つ、または他の適切な組み合わせであってもよい。

この明細書で使用されるような、単語「実施形態（ｅｍｂｏｄｉｍｅｎｔ）」の異なる実例は、同一の実施形態を参照するとは限らないが、しかしながら、そうであってもよい。明細書において図示または説明された任意のデータおよびデータ構造は、単なる例であり、他の実施形態においては、異なる量のデータ、データのタイプ、フィールド、フィールドの数およびタイプ、フィールド名、行の数およびタイプ、レコード、エントリまたはデータの編成を使用してもよい。加えて、任意のデータをロジックと組み合わせて、個別のデータ構造を必要としないようにしてもよい。前述の詳細な説明は、したがって、限定的な意味で解釈されるべきではない。

本開示の種々の実施形態の説明が、説明のために提示されたが、しかしながら、網羅的であること、または、開示される実施形態に限定されることを意図するものではない。説明される実施形態の範囲および精神を逸脱することなく、多くの変更および変形が当業者にとって明らかであろう。本明細書で使用される用語は、実施形態の原理、実際の応用または市場で発見される技術に対する技術的改善を最もよく説明するために、あるいは、他の当業者が、本明細書で開示される実施形態を理解できるように選ばれたものである。

本発明が特定の実施形態に関連して説明されたが、その変更および修正は、当業者にとって明らかになるものと予期される。したがって、以下の特許請求の範囲は、本発明の真の精神および範囲内にあるようなすべての変更および修正に及ぶものとして解釈されることが意図される。

Claims (20)

1. 方法であって、
   複数のルール・セットの各ルール・セットごとにルール負荷を決定するステップであって、各ルール・セットは、マルチテナント・システム上でホストされる複数のテナントのうちのテナントに関連付けられる、決定するステップと、
   前記ルール負荷を全体ルール負荷に統合するステップと、
   前記全体ルール負荷の略同一割合がルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを分散するステップと
   を含む、方法。
2. 前記複数のルール・セットは、マイクロサービス・プロバイダによって維持される、請求項１に記載の方法
3. 前記ルール・エンジン・インスタンスのセットは、前記マイクロサービス・プロバイダによってデプロイされる、請求項２に記載の方法。
4. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
   それぞれのテナントによりなされるリクエストの数を決定するステップと、
   リクエスト当たりトリガされるアクションの平均数を決定するステップと
   を含む、請求項１～３のいずれか１項に記載の方法。
5. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
   それぞれのテナントによりなされるリクエストの数を決定するステップと、
   各リクエストに応答するために考慮される条件の数を決定するステプと
   を含む、請求項１～４のいずれか１項に記載の方法。
6. それぞれのテナントによりなされたリクエストの数と各リクエストに応答するために考慮される条件の数とは、ルール監視コンポーネントに送信され、
   前記ルール監視コンポーネントは、前記ルール・セットごとにこれらの数を集約することを特徴とする、請求項５に記載の方法。
7. 前記方法は、さらに、
   前記ルール監視コンポーネントから前記集約された数を取得するステップと、
   前記集約された数に基づいて、前記全体ルール負荷の略同一割合が前記ルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを再分散するステップと
   を含む、請求項６に記載の方法。
8. そこにプログラム命令が具現化されたコンピュータ可読ストレージ媒体を含むコンピュータ・プログラム製品であって、前記プログラム命令は、プロセッサに、プロセッサによって実行可能であり、前記プロセッサに方法を実行させ、前記方法は、
   複数のルール・セットの各ルール・セットごとにルール負荷を決定するステップであって、各ルール・セットは、マルチテナント・システム上でホストされる複数のテナントのうちのテナントに関連付けられる、決定するステップと、
   前記ルール負荷を全体ルール負荷に統合するステップと、
   前記全体ルール負荷の略同一割合がルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを分散するステップと
   を含む、コンピュータ・プログラム製品。
9. 前記複数のルール・セットは、マイクロサービス・プロバイダによって維持される、請求項８に記載のコンピュータ・プログラム製品。
10. 前記ルール・エンジン・インスタンスのセットは、前記マイクロサービス・プロバイダによってデプロイされる、請求項９に記載のコンピュータ・プログラム製品。
11. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
    それぞれのテナントによりなされるリクエストの数を決定するステップと、
    リクエスト当たりトリガされるアクションの平均数を決定するステップと
    を含む、請求項８～１０のいずれか１項に記載のコンピュータ・プログラム製品。
12. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
    それぞれのテナントによりなされるリクエストの数を決定するステップと、
    各リクエストに応答するために考慮される条件の数を決定するステプと
    を含む、請求項８～１１のいずれか１項に記載のコンピュータ・プログラム製品。
13. それぞれのテナントによりなされたリクエストの数と各リクエストに応答するために考慮される条件の数とがルール監視コンポーネントに送信され、
    前記ルール監視コンポーネントは、前記ルール・セットごとにこれらの数を集約することを特徴とする、請求項１２に記載のコンピュータ・プログラム製品。
14. 前記方法は、さらに、
    前記ルール監視コンポーネントから前記集約された数を取得するステップと、
    前記集約された数に基づいて、前記全体ルール負荷の略同一割合が前記ルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを再分散するステップと
    を含む、請求項１３に記載のコンピュータ・プログラム製品。
15. ルール分散システムであって、
    メモリと、
    前記メモリに通信可能に結合されたプロセッサと
    を含み、前記プロセッサは、方法を実行するように構成されており、前記方法は、
    複数のルール・セットの各ルール・セットごとにルール負荷を決定するステップであって、各ルール・セットは、マルチテナント・システム上でホストされる複数のテナントのうちのテナントに関連付けられる、決定するステップと、
    前記ルール負荷を全体ルール負荷に統合するステップと、
    前記全体ルール負荷の略同一割合がルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを分散するステップと
    を含む、ルール分散システム。
16. 前記複数のルール・セットは、マイクロサービス・プロバイダによって維持される、請求項１５に記載のルール分散システム。
17. 前記ルール・エンジン・インスタンスのセットは、前記マイクロサービス・プロバイダによってデプロイされる、請求項１６に記載のルール分散システム。
18. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
    それぞれのテナントによりなされるリクエストの数を決定するステップと、
    リクエスト当たりトリガされるアクションの平均数を決定するステップと
    を含む、請求項１５～１７のいずれか１項に記載のルール分散システム。
19. 前記ルール・セットごとに前記ルール負荷を決定するステップは、
    それぞれのテナントによりなされるリクエストの数を決定するステップと、
    各リクエストに応答するために考慮される条件の数を決定するステプと
    を含む、請求項１５～１８のいずれか１項に記載のルール分散システム。
20. 前記方法は、さらに、
    それぞれのテナントによりなされるリクエストの数および各リクエストに応答するために考慮される条件の数を集約するステップと、
    前記集約された数に基づいて、前記全体ルール負荷の略同一割合が前記ルール・エンジン・インスタンスのセットの各ルール・エンジン・インスタンスに割り当てられるように、前記ルール・エンジン・インスタンスのセットを横断して、前記複数のルール・セットを再分散するステップと
    を含む、請求項１９に記載のルール分散システム。

Images