1.7. ルールに複数の条件を設定した場合のイベントのTTL問題について

1.7.1. 状況の整理

今回、Sorry画面切り戻しの設定でも明らかなように、複数のフィルターを条件に設定することが可能です。
そこで条件が成立するためには、それぞれのフィルターで検知されるイベントがTTL内である必要があります。
例えば今回のシナリオでは、後続するリクエスト数が閾値内に回復するイベントが、先行するSorry画面切り替えをした結論イベントのTTL内に発生する必要があります。
ただ、後続するイベントがいつ発生するかは正確には把握できない場合も多いと思います。
こうした状況に対処するには、以下の二つの方法が有効です。
  1. TTLをできるだけ長くする

TTLは最大で2147483647秒(=約68年)まで設定することが可能です。
余裕をもって設定することで、ルールに評価されるまで時間切れになることを避けることができます。
  1. TTLが過ぎたら、改めて、同じラベルが付与された結論イベントを発生させる

ルールの条件にしたフィルターで検出されるためには、同じラベルが付与されたTTL内のイベントが発生していれば問題ありません。
そのため、すでに発生しているイベントのTTLが切れそうになったら、
「必要な後続のイベント発生まで同じラベルが付与された新たなイベントを発生させる」
ということを続ければ、後続のイベントの発生時期が正確にわからない場合にも対応が可能になります。
まず、同じラベルが付与されたイベントを発生させ続けるには、イベントの発生とフィルターでの検知をループさせる設定をすることで実現できます。
具体的には、以下のような動きになります。
  1. 「ラベルA」を検知するフィルターとそのフィルターを条件にしたルールを作成する。その際に、元のイベントに付与されている「ラベルA」を結論イベントに継承するように設定する。

  2. 「ラベルA」が付与されたイベントが発生する

  3. 1.で作成したフィルターに検知され、ルールに従い、「ラベルA」が付与されたイベントが発生する → 2.に戻る

  4. 2.と3.の工程がループする形になり、「ラベルA」が付与されたイベントが発生し続ける

1.7.1.1. ラベルの作成

ループして作成された、後続イベント待ちのイベントに付与する結論ラベルに使用するラベルを作成します。
OASE ▶ ラベル ▶ ラベル作成 から、ラベルを作成します。
登録 ボタンを押し、以下のラベルの設定を追加していきます。
ラベル作成画面
表 1.71 ラベル作成の設定値

ラベルキー

カラーコード

event_status

入力が終わったら、編集確認 ボタンを押して登録します。

1.7.2. ルールの設定

前のシナリオで作成した「sorry画面切り戻し」のルールでは、「sorry_switch」というフィルターが条件の一部になっています。
そこに、「sorry_switch」というフィルターのみを条件とした、「Sorry表示中」のルールを作成してみましょう。
登録 ボタンを押し、以下のルールの設定を追加していきます。
ルール
表 1.72 ルールの設定値

有効

ルール名

ルールラベル名

優先順位

条件

アクション

結論イベント

フィルターA

アクションID

元イベントのラベル継承

結論ラベル設定

TTL

アクション

イベント

True

Sorry表示中

Sorry表示中

1

sorry_switch

True

True

["event_status", "progress"]

3600

入力が終わったら、編集確認 ボタンを押して登録します。

Tip

ルール名やルールラベル名は任意で設定可能です。わかりやすいものを設定しましょう。
必要な結論イベントを発生させるためのルールなので、選択するアクションはありません。
「元イベントのラベル継承」の「イベント」を「true」とすることで、結論ラベルに、フィルター「sorry_switch」で検知された元のイベントのラベルを引き継ぐことができます。
結論ラベルには、結論イベントの性格がわかるようなラベルを設定しておくことで、イベントの判別が容易になります。
同じフィルターが別のルールの条件の一部となっている場合、どちらのルールの条件に合致するかどうか、関係するイベントのTTLまで待ちます。
どちらのルールに合致するか、一意に決まった段階で、合致したルールが適用されます。
これにより、「sorry_switch」というフィルターに合致する[["page", "==", "sorry"], ["_exastro_type", "==", "conclusion"]]のラベルが付与された結論イベントが発生したら以下のような動きとなります。

注釈

["_exastro_type", "==", "conclusion"]のラベルは、結論イベントにシステム側で付与するデフォルトのラベルになります。
  1. そのイベントのTTLが経過するまで、「sorry画面切り戻し」のルールに沿うか、「Sorry表示中」のルールに沿うか、評価を待ちます。

「sorry画面切り戻し」の条件がそろえば、「sorry画面切り戻し」のルールに従って動作します。
「sorry画面切り戻し」のルールの沿う条件が揃う = もう一つの条件である「request_range_max」というフィルターに合致するイベントが発生する
  1. もしTTLが経過するまで 「sorry画面切り戻し」のルールの沿う条件がそろわなければ、「Sorry表示中」のルールの評価対象となり、ルールに従って、結論イベントが改めて発生することになります。

警告

以下の画像のようにTTLを必要以上に短くすると、ループしてイベントを発生させる回数が必要以上に多くなってしまいます。
ループを抜けるための、後続するイベントが発生するまでの予測される期間に合わせて、適切なTTLを設定しましょう。
イベントフロー_結論イベント