2.1. OASEを設定する際の事前設計の必要性について¶

2.1.1. 現状整理¶

さて、これまでの作業を通して、OASEでの基本的な設定方法について一通り紹介しました。

ここでは、OASEを設定するにあたり、事前に設計する必要性について考えてみましょう。

まず、前提となる構成について、おさらいしましょう。

インスタンス1台につき、50リクエスト/minを閾値とする。
通常は1台稼働である。
Webサーバ前のLBを監視し、Webサーバへの総リクエスト数に関してメールで通知する。
リクエスト数が閾値に達したらスケールアウトをする。
スケールアウトの上限は3台とし、それ以上のリクエスト数があった場合は、Sorry画面へ切り替える。
リクエスト数が閾値内に回復したら、切り戻しを行う。

リクエスト数に関するメール通知をイベントとして、イベント発生に合わせて4.・5.・6.の保守作業を行うよう、OASEの設定を行います。

リクエスト数を通知するメールの内容は以下のものを想定していました。

表 2.24 通知メール一覧¶
通知内容	リクエスト数超過	リクエスト数閾値内回復
`件名`	`[alert]` `Requests:` `Threshold` `reached`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値を超えました。` `RequestCount` `>` `150`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `150`
`備考`	`値は、50，100，150のどれか`	`値は、50，100，150のどれか`

このような構成では、リクエスト数が超過もしくは回復した通知においてどの閾値を超えたか、またその通知がきたときの状況によって、行う作業が変わってくることが考えられます。
例えば、閾値150リクエスト/minを超過した状況から、リクエスト数が50リクエスト/minに収まる場合です。
その場合、まずSorry画面からの切り戻し作業を行ったうえで、スケールインを2回行う必要があります。

通知が生じる状況と、それに合わせて実行すべきアクションををまとめると以下の通りです。

表 2.25 通知メール発生とそれに伴い実行されるアクション一覧¶
通知前のインスタンス数	通知内容	閾値	アクション	アクション数
`1`	`リクエスト数超過通知`	`50`	`scale`-`out`	`1`
		`100`		`2`
		`100`		`2`
		`150`	`scale`-`out`	`2`
			`sorry画面への切り替え`	`1`
`2`		`100`	`scale`-`out`	`1`
		`150`	`scale`-`out`	`1`
			`sorry画面への切り替え`	`1`
	`リクエスト数回復通知`	`50`	`scale`-`in`	`2`
		`100`	`scale`-`in`	`1`
`3`	`リクエスト数超過通知`	`150`	`sorry画面への切り替え`	`1`
	`リクエスト数回復通知`	`150`	`sorry画面からの切り戻し`	`1`
		`100`	`sorry画面からの切り戻し`	`1`
			`scale`-`in`	`1`
		`50`	`sorry画面からの切り戻し`	`1`
			`scale`-`in`	`2`

ルール1つにつき、実行できるアクションは1つです。

そのため上記の状況に合わせてルールを作成する場合は、実行される必要があるアクションごとにルールを作成する必要があります。

つまり、イベントが発生するたびにその状況に合わせてルールを作成すると、全部で19ものルールを作成する必要が出てきます。

2.1.2. アクションをベースにした状況の整理¶

ただ状況ごとに行われるアクションは以下の4つです。

インスタンスを1台scale-out
インスタンスを1台scale-in
sorry画面への切り替え
sorry画面からの切り戻し

同じアクションが実行される状況をできるだけまとめて、その状況ごとにルールが作成できれば、ルールの数を少なくでき管理もしやすくなります。

そこで、改めて上記の状況をアクションごとにまとめてみます。

scale-outが実行される状況

パターン1 インスタンス1台のとき、リクエスト数超過通知:50/100/150
パターン2 インスタンス2台のとき、リクエスト数超過通知:100/150

sorry画面への切り替えが実行される状況

パターン3 インスタンス3台のとき、リクエスト数超過通知:150

sorry画面からの切り戻しが実行される状況

パターン4 インスタンス3台のとき、リクエスト数回復通知:50/100/150

scale-inが実行される状況

パターン5 インスタンス3台のとき、リクエスト数回復通知:50/100
パターン6 インスタンス2台のとき、リクエスト数回復通知:50

以上の6パターンにまとめられました。

この6パターンに合わせてルールが作成できれば、ルール数を大幅に減らすことができます。

ここに、OASEを設定する際に、フィルターだけでなく、ルールの設定についても事前設計と設定が必要な理由があります。

では、いかにして実現するか、次に具体的な設定について、OASEを設定する際の事前設計についてで考えてみましょう。

注釈

実際には、Conductor側で工夫をすることで、より状況にあったアクションを用意するなどの対応も考えられます。

このシナリオはあくまで、4つのアクションを前提に、OASE側の設定での対応の仕方を提案するものになります。

↑ Page Top