アプリケーションの一部は「ルール エンジン」として機能します。ルールは、プロセスの状態と時間の 2 つの要素で構成できます。ルールは単純にも複雑にもできます。すべてのルールにはステータスがあります - True または False
典型的なルールは次のようになります。
いつ - 9:00 から 11:00 までの時間で、プロセス 1 のステータスはオープンです。
And
時刻は 4:00 から 6:00 の間であり、プロセス 2 のステータスは閉じています。
したがって、このルールは、プロセス 1 の状態が変更されたとき、またはプロセス 2 の状態が変更されたときに、9:00、11:00、4:00、および 6:00 にチェックして評価する必要があります。評価後、ルールのステータスが (以前のものから) 変更された場合、イベントを発生させます。新しい結果が保存されるため、次にこのルールが評価されるときにその結果を比較できます。新しい結果が前の結果と同じ場合、何も起こりません。
これと同じことを実現するために、アプリケーションで 3 つの異なるコンポーネントを使用しました。
1) Web UI - ルールの作成、プロセス状態の変更など。プロセス状態またはルール構成が変更されるたびにイベントを発生させます。
2) スケジューラ - これは 1 分ごとにジョブを実行するワーカー ロール (ウィンドウ サービス) です. 開始時刻または終了時刻が現在時刻であるルールがあるかどうかをチェックします. 見つかった場合, イベントをキューに上げます.
3) ルール エンジン - このエンジンは、ルールの定義変更イベント、プロセス状態変更イベント、時間イベントの 3 種類のイベントをリッスンするワーカー ロール (ウィンドウ サービス) です。プロセスの状態変化や時間ルールイベントが発生した場合、これを条件とするルールを全て見つけ出し、それらのルールを発火させ、さらに「ルール状態変化」としてイベントを発生させます。
このソリューションは、Windows Azure クラウド プラットフォーム上に構築されています。設計上の決定事項をいくつか次に示します。
1) ルールの定義は SQL サーバーに保存されます。前述のように、ルールは本質的に階層的 (複雑) で、複数の条件で構成されている場合があります。
2) データベースから時間または Process1 によってルールを抽出するのは時間のかかる操作になる可能性があるため、SQL データベースからこのすべてのデータを 1 回フェッチし、Redis キャッシュに保存します。キーは、時間またはプロセス ID ですべてのルールを見つけることができるように作成されます。この操作は、ルール エンジンの起動時に行われます。すべてのプロセスの状態もデータベースとキャッシュに保存されます。
3) Azure サービス バスは、あるコンポーネントから別のコンポーネントにメッセージを渡すために使用されます。
4) Web UI からマスター データが変更されるたびに、イベントがキューに渡され、ルール エンジンがキャッシュを更新します。
システムは、オートスケーリングを念頭に置いて設計されています。ワークロードが増加すると、キューの深さが増加し、ルール エンジンにインスタンスを追加できます。
上記のデザインに改善点があれば提案してください。
高可用性とコンポーネント障害に関して私たちが直面している問題は次のとおりです。
複数の Azure サービスが使用されており、それらすべてが異なる時点で失敗する可能性があります (複数のインスタンスが使用されている場合でも)。
1) Web UI (Web ロール) 99.95 の可用性 - これは現時点では問題ではありません。
2) スケジューラ (ワーカー ロール) 99.95 の可用性
3) ルール エンジン (ワーカー ロール) 99.95 の可用性
4) Azure Service Bus 99.9 の可用性
5) Redis Cache 99.9 の可用性 (データに関する SLA なし)
すべてが正常に機能していると仮定すると、突然、次のいずれかの状況が発生します。
問題 1: ユーザーがルールの定義を UI から変更しています。システムはこのデータを SQL データベースに追加しますが、サービス バスが応答しません。この変更をルール エンジンに伝えることができないため、システムが同期しなくなります。- 解決策の 1 つは、DB 操作をロールバックし、しばらくしてから再試行するようにユーザーに指示することです。- もう 1 つのオプションは、2 フェーズ コミットを行うことです。サービス バスが応答しない場合は、データベースにフラグを保持します。キューが使用可能になるたびに、この変更をキューにプッシュするバックグラウンド プロセスを実行します。
問題 2: ユーザーがプロセスの状態を変更しています。システムはこれを SQL データベースに追加しますが、サービス バスが応答しません。このプロセス状態の変更は、ルール エンジンと通信できません。ルール エンジンは非同期になります。- 前のものと同じ。
問題 3: スケジューラ エンジンが停止する: タイム イベントが発生しないため、ルール エンジンはそれらのイベントを処理できません。- スケジューラーがジョブを実行するたびに時間を記録できます。スケジューラは常に、最初に見逃したすべてのイベントを発生させてから、新しいイベントの実行を開始する必要があります。
問題 4: ルール エンジンからのメッセージを処理しているときに、キャッシュがダウンします。ルール エンジンは、キューのメッセージを処理できません。メッセージを失うことはないので、これで問題ありません。ただし、キャッシュが戻ってきた場合、すべてのキャッシュ データも失われる可能性があります。ルール エンジンはキャッシュを再構築する必要があります (ルール エンジンの開始時に行われたように)。
御時間ありがとうございます。追加案があればよろしくお願いします。