2.2. OASEを設定する際の事前設計について¶
2.2.1. アクション実行の条件の整理¶
では具体的な設定について考えてみましょう。
アクションが実行される状況を見ると、
インスタンスが何台稼働している状況で、どのような通知が来たか
という形で条件づけられているのがわかります。
つまり、ルールを設定する際の条件となるフィルターは、
インスタンスが何台稼働しているかをフィルタリングするフィルター
どのような通知が来たかをフィルタリングするフィルター
というものがあればよいことになります。
2.2.1.1. それぞれのパターンが成立する状況の整理¶
ただ、各パターンの状況のなかには、
通知が来た時の状況と、通知内容によって成立する場合通知が来たことによりアクションが実行されたことによって成立する場合
の二つの状況がまとめられたものがあります。
例えば、
パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150
の状況が成立する場合を考えてみましょう。
まず、
インスタンス2台稼働しているときに、リクエスト数超過通知:100/150が届いた場合
があります。
ただこれだけではなく、
インスタンス1台稼働しているときにリクエスト数超過通知:100/150が届き、一度スケールアウトのアクションが実行されたあとの場合
もあります。
ちなみに、後者のときは以下のような動きになります。
インスタンスが1台稼働している状況で、閾値100リクエスト/minを超過したというリクエスト数超過通知が来たら、
インスタンス1台稼働 + 閾値100リクエスト/min超過 ⇒ インスタンス2台にスケールアウトインスタンス2台稼働 + 閾値100リクエスト/min超過 ⇒ インスタンス3台にスケールアウト
のように、
パターン1 インスタンス1台のとき、リクエスト数超過通知:50/100/150
の状況が成立しアクションが実行されたあとにパターン2の状況が成立する形になり、
スケールアウトというアクションが2回実行されることになります。
以上のように、パターンによっては、
① 通知内容 + 通知が来る前の状況② 通知内容 + 前パターンのアクションが実行された後の状況
の二つの状況をフィルタリングできるように条件を設定する必要があります。
では実際に上記のような条件付けが必要なパターンはどのパターンでしょうか。
それは、
パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150
パターン3 インスタンス3台のとき、リクエスト数超過通知:150
パターン5 インスタンス3台のとき、リクエスト数回復通知:50/100
パターン6 インスタンス2台のとき、リクエスト数回復通知:50
です。
それぞれ、前パターンの通知の閾値によって次のパターンでのアクションを必要とするものになります。
2.2.2. 条件の実現方法と注意点¶
①については、 Sorry画面からの切り戻し実施 (解答) で設定したように、通知メールのイベントと結論イベントからフィルタリングする形で実現可能です。
では、
② 通知内容 + 前パターンのアクションが実行された後の状況
をどうすればフィルタリングできるか、考えてみましょう。
2.2.2.1. 通知内容に関するフィルタリング方法¶
②では、すでに前パターンが成立したときに通知メールのイベントがフィルタリングされてしまっています。
一度フィルターでフィルタリングされたイベントは、再度、別のルールの条件としてフィルタリングすることはできません。
そのため、②で通知内容を参照するには、ルールに複数の条件を設定した場合のイベントのTTL問題について で用いた「元イベントのラベル継承」の設定を行う必要があります。
この設定により、前パターンの結論イベントに元となった通知メールのイベントからラベルを継承されます。
その継承された通知内容を示すラベルを②でフィルタリングできるので、前パターンの結論イベントのラベルから条件を成立させることができるようになります。
2.2.2.2. 前パターンのアクションが実行された後の状況をフィルタリングする方法¶
こちらは、インスタンスが何台稼働しているかをフィルタリングするフィルターを用いることになります。
スケールアウトやスケールインのアクションが実行されれば、インスタンスの稼働台数が変化します。
そのため①も②も「インスタンスが現在何台稼働しているか」は、ひとつ前の結論イベントからフィルタリングする形になります。
そこで、スケールアウトやスケールインのアクションのあとの稼働台数が結論ラベルの値に入るように設定することで問題ないかのように見えます。
2.2.2.3. 「前パターンのアクションが実行された後の状況をフィルタリングする方法」の注意点¶
ただ、それぞれのパターンにおいて、条件となっているインスタンス数を見てみると、
パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150
パターン6 インスタンス2台のとき、リクエスト数回復通知:50
のように、条件となっているインスタンス数が被っているパターンがあります。
そのため、「インスタンスが2台稼働している状況をフィルタリングするフィルター」をそれぞれのルールで用いることになります。
そうなると、 ルールに複数の条件を設定した場合のイベントのTTL問題について で確認した仕様があるので、どちらのルールが適用されるのか、関連するイベントのTTLが経過するまで判断を待つことになってしまいます。
次の工程でフィルタリングされるため、結論イベントのTTLを長めに設定する必要があります。
その長めに設定した結論イベントのTTLが過ぎるまで待ってアクションが実行される形になってしまいます。
今回は、各ルールの条件が成立した時点でルールが適用され、アクションが実行される必要がありますので、条件となるフィルターがほかのルールと被らないように設定する必要があります。
結論イベントにそれぞれのパターンを示すラベルを付与するようにし、インスタンス数の台数を示すラベルと自らのパターン以外のものをフィルタリングするようにすることで、
各パターンの条件は各パターン特有のものとなり、その条件が成立し次第、アクションが実行されることになります。
ただ「元イベントのラベル継承」の設定を行うと、
パターン3 インスタンス3台のとき、リクエスト数超過通知:150
このパターンでは、スケールアウトやスケールインといったアクションのように、アクションのあとの稼働台数が変わるわけではありません。
その結果、結論イベントに付与されるラベルは元イベントに付与されていた、
稼働しているインスタンス数が3台であることを示すラベルリクエスト数超過通知:150という通知内容を示すラベル
と、新たに追加される
「Sorry画面への切り替え」を示すラベル「パターン3」の結論イベントであることを示すラベル
となります。
このままだと、
パターン4 インスタンス3台のとき、リクエスト数回復通知:50/100/150
パターン5 インスタンス3台のとき、リクエスト数回復通知:50/100
の条件である、
パターン4 インスタンス数:3台 パターン4以外
パターン5 インスタンス数:3台 パターン5以外
の両方が成立してしまうことになります。
パターン3のあとに回復通知が来た場合は、パターン4のルールが実行され、Sorry画面からの切り戻しが行われる必要があります。
そのため、パターン5の条件と被らないようにパターン4の条件を以下のように設定しましょう。
パターン4 Sorry画面が切り替わっているとき、リクエスト数回復通知:50/100/150
またパターン3のあとにパターン5の条件が成立しないように、パターン3のルールでは「元イベントのラベル継承」の設定を「false」にしましょう。
2.2.2.4. 「通知内容に関するフィルタリング方法」の注意点¶
以上までで、通知内容と状況をフィルタリングする方法が確認できました。
ここまでの設計をもとに具体的な設定を行って頂いて問題ありません。
ただ関連して、「元イベントのラベル継承」を設定する際の注意点もこちらで解説しておきます。
それは、ルールに複数の条件を設定した場合のイベントのTTL問題について で見たように、「元イベントのラベル継承」の設定をすることでループが発生してしまう場合があるということです。
今回の6パターンの中では、
パターン3 インスタンス3台のとき、リクエスト数超過通知:150
のルールで「元イベントのラベル継承」の設定をするとループが発生してしまう可能性がありました。
このパターンでは、スケールアウトやスケールインといったアクションのように、アクションのあとの稼働台数が変わるわけではありません。
そのため、パターンを示すラベルが付与されていないと、
その結果、結論イベントに付与されるラベルは、元イベントに付与されていた、
稼働しているインスタンス数が3台であることを示すラベルリクエスト数超過通知:150という通知内容を示すラベル
と、新たに追加される
「Sorry画面への切り替え」を示すラベル
となります。
これにより、元イベントから継承されたラベルからパターン3の条件である、「インスタンス3台のとき、リクエスト数超過通知:150」が改めてフィルタリングされてしまう、
という意図しないループが無限に発生してしまいます。
今回はインスタンス数を示すラベルだけでなく、パターンを示すラベルも合わせてフィルタリングするためループは発生しませんが、上記のような可能性があることを念頭に設定を考えていただければと思います。
2.2.2.5. まとめ¶
以上、今回の事例をもとにOASEの設計について考えてみました。
まとめると、OASEの設定を考えるうえで重要なのは、まず、どのような状況がありうるのかを事前に整理することです。
これによって、アクションを実行する際の条件が見えてきます。
どのような条件が成立したときにアクションが実行されるのかがわかれば、その条件を把握できるようなラベルの設定がわかります。
また、そのラベルをどうすればフィルタリングできるか、ということを考えれば、ルールでの設定の仕方が明確になります。
今回は、「元イベントのラベル継承」の設定を行う必要性がありました。
そうした設定をする際には注意点もありました。
その注意点を事前に確認し、どうすれば回避できるか、という点も事前に設計する際には重要になってきます。
ここまで整理できたら、具体的なOASEの設定を ルール設定について でみていきましょう。