1.4. インスタンスのスケールイン実施 (解答)¶

1.4.1. 問題 (再掲)¶

以下のようなリクエスト数が閾値内に回復したイベントが発生したときに、スケールインのアクションが実行されるようにOASEの設定を行ってください。

表 1.47 通知メール一覧¶
通知内容	２台稼働時にリクエスト数が閾値内に回復した場合	３台稼働時にリクエスト数が閾値内に回復した場合
`件名`	`[info]` `Requests:` `Threshold` `recovery`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `50`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `100`

1.4.2. 自動化する作業の具体的な検討¶

まずは作業計画を立てましょう。

今回のシナリオでは、以下の保守作業を自動的に実行します。

作業C インスタンスをスケールインする作業

今回想定している構成から作業Cが実行されるのは、

すでに1台スケールアウトし2台稼働している状況において、リクエスト数がスケールイン後の閾値50リクエスト/min内に回復したとき。

すでに2台スケールアウトし3台稼働している状況において、リクエスト数がスケールイン後の閾値100リクエスト/min内に回復したとき。

となります。

ここまで整理できたら、具体的に以下のOASEの設定を行っていきましょう。

イベント収集設定
ラベルの設定
OASEエージェントの設定
ルールの設定

1.4.3. イベント収集設定¶

1.4.3.1. イベント収集設定¶

イベント収集設定では、エージェントがどの外部サービスからイベントを収集するかを設定します。

警告

これまでのシナリオで設定したものが残っているようであれば、こちらの設定は不要です。

OASE管理 ▶ エージェントから、外部サービスの情報を登録します。

登録ボタンを押し、以下のエージェントの登録をしていきます。

表 1.48 イベント収集設定値¶
イベント収集設定名	接続方式	リクエストメソッド	接続先	認証情報		TTL
				ユーザー名	パスワード
`リクエスト監視`	`IMAP` `パスワード認証`	`IMAP:` `Plaintext`	`...**`	`***@.***`	`**`	`60`

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

Tip

* の部分は、各自の外部サービスの情報を入力してください。

1.4.4. ラベルの設定¶

収集するイベントに付与するラベルの作成と付与する条件を設定します。

表 1.49 ラベル一覧¶
ラベルキー	利用目的
subject	イベントの内容を特定できるようにするラベル
requestcount	基準となった閾値を把握するためのラベル
instance	作業Cの作業結果を示すためのラベル

注釈

イベントに含まれる全ての情報をラベルとして管理する必要はありません。今後必要になったタイミングで適宜追加や見直しをしましょう。

1.4.4.1. ラベルの作成¶

警告

これまでのシナリオで設定したものが残っているようであれば、こちらの設定は不要です。

ラベル作成では、イベントを特定する時に利用するキー(ラベル)を作成します。

OASE ▶ ラベル ▶ ラベル作成から、ラベルを作成します。

登録ボタンを押し、以下のラベルの設定を追加していきます。

必要に応じて、追加ボタンを押して行数を追加しましょう。

表 1.50 ラベル作成の設定値¶
ラベルキー	カラーコード
`subject`	`#FBFF00`
`requestcount`	`#7F76F9`
`instance`	`#00FF33`

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

注釈

ラベルそれぞれにカラーコードを設定することで、付与されたときに見分けやすくなります。

1.4.4.2. ラベルを付与する条件の設定¶

ラベル付与では、イベントにラベルを付与する条件と、条件に合った際に付与するラベルの内容を設定します。

今回は、リクエスト数閾値内回復を知らせるものであるかどうかを示すラベルを付与する必要があります。

警告

「リクエスト数監視」に関しては、これまでのシナリオで設定したものが残っているようであれば、設定は不要です。

OASE ▶ ラベル ▶ ラベル付与から、ラベルを付与するための設定を行います。

登録ボタンを押し、以下のラベル付与の設定を追加していきます。

必要に応じて、追加ボタンを押して行数を追加しましょう。

表 1.51 ラベル付与の設定値¶
ラベリング設定名	イベント収集設定名	検索条件				ラベル
		キー	値のデータ型	比較方法	比較する値	キー	値
`通知名`	`リクエスト監視`	`subject`	`文字列`	`==`	`[info]` `Requests:` `Threshold` `recovery`	`subject`	`リクエスト数回復`
`リクエスト数監視`	`リクエスト監視`	`body.plain`	`その他`	`RegExp`	`RequestCount` `.` `(\d{2,3})`	`requestcount`	`\1`

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

Tip

ラベリング設定名とイベント収集設定名は任意で設定可能です。わかりやすいものを設定しましょう。
メールの件名から通知内容を特定する、「subject」のラベルを付与する設定を行います。
メールの本文から通知の基準となった閾値を参照でする、「requestcount」のラベルを付与する設定を行います。

1.4.5. OASEエージェントの設定¶

OASEエージェントの設定を行い、エージェントを実行します。

警告

これまでのシナリオで設定したものが残っているようであれば、こちらの設定は不要です。

注釈

OASEエージェントの詳細は、下記のページにてご確認ください。

OASE Agent on Docker Compose - Online

1.4.5.1. .envの設定¶

.envの項目にこれまでの工程で設定した値を設定します。

exastro-docker-compose/ita_ag_oase/.env に下記の内容を入力します。

表 1.52 .envの設定値¶
項目名	設定値
`AGENT_NAME`	`ita`-`oase`-`agent`-`01`
`EXASTRO_URL`	`http://********`
`EXASTRO_ORGANIZATION_ID`	`********`
`EXASTRO_WORKSPACE_ID`	`********`
`EXASTRO_USERNAME`	`********`
`EXASTRO_PASSWORD`	`********`
`EVENT_COLLECTION_SETTINGS_NAMES`	`リクエスト監視`
`EXECUTE_INTERVAL`	`5`
`LOG_LEVEL`	`INFO`

Tip

* の部分は、各自の情報を入力してください。
「EXASTRO_USERNAME」と「EXASTRO_PASSWORD」は、ワークスペースのものになります。
各項目の詳細は、下記のページ 2.8.1. OASE Agentの処理フローと.envの設定値 を参照ください。
OASE 管理

1.4.5.2. エージェントの実行¶

次のコマンドを使い、コンテナを起動してみましょう。

リスト 1.16 docker コマンドを利用する場合(Docker環境)¶

docker compose up -d --wait

リスト 1.17 docker-compose コマンドを利用する場合(Podman環境)¶

docker-compose up -d --wait

状態が Healthy になっていることを確認します。

正常に接続できているか、以下のコマンドでLogの確認をします。

リスト 1.18 docker コマンドを利用する場合(Docker環境)¶

docker compose logs -f

リスト 1.19 docker-compose コマンドを利用する場合(Podman環境)¶

docker-compose logs -f

エラーが出ている場合は、.envファイルの各設定値が正しいか確認してください。

1.4.6. ルールの設定¶

ルール では、イベントを特定する条件と、その条件に合致したイベントが発生した場合に実行したい作業を紐づけることができます。
イベントを特定する条件は フィルター 、実行したい作業は アクション 、でそれぞれ設定します。
ルール では、フィルター と アクション を紐づける形で設定します。

注釈

イベントフロー では、OASEエージェントが収集したイベント等、イベントが時系列に表示されます。
表示されたイベントには、ラベル付与での設定に沿ってラベルが付与されています。
この画面から フィルター 、アクション 、ルール の設定をそれぞれ行うこともできます。

まずは、以下のような、２台稼働時のリクエスト数閾値内回復のイベントを発生させて、設定を進めましょう。

表 1.53 通知メール一覧¶
通知内容	リクエスト数回復
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `50`

1.4.6.1. フィルターの設定¶

フィルターでは、ラベルをもとにイベントを検知するための条件を設定します。

イベントの件名と本文からスケールインを実施する条件に合うイベントを特定できるように条件を設定してみましょう。

注釈

スケールインを実施するのは、インスタンスが3台未満の稼働の状態で、リクエスト数が閾値内に回復した場合です。

閾値は、インスタンス1台につき50リクエスト/minです。

OASE ▶ ルール ▶ フィルターから、フィルターを設定します。

登録ボタンを押し、以下のフィルターの設定を追加していきます。

表 1.54 フィルターの設定値¶
有効	フィルター名	フィルター条件	検索方法
`True`	`request_range`	`[["subject",` `"==",` `"リクエスト数回復"],` `["requestcount",` `"≠",` `"150"]]`	`ユニーク`

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

フィルターは:menuselection:OASE --> イベント --> イベントフローからも設定することが可能です。

Tip

フィルター名は任意で設定可能です。わかりやすいものを設定しましょう。
ラベル「subject」の値から、リクエスト数が閾値内に回復したことを通知するイベントであることを特定できるようにフィルター条件を設定します。
ラベル「requestcount」の値から、通知の基準となった閾値を特定できるようにフィルター条件を設定します。
今回は、閾値として50か100の場合を条件として同じアクションを実行するので150以外と設定しましたが、それぞれの閾値でアクションを変えるなど、個別の設定がしたい場合は、それぞれの閾値で別のフィルターを設定しましょう。

ラベル「requestcount」だけでは超過したイベントなのか回復したイベントなのか判別できないため、ラベル「subject」をフィルター条件に設定し、イベントを一意に特定できるようにします。

このように、イベントごとに特定のラベルを付与しなくても、必要に応じてフィルター条件を複数設定することで、イベントを一意に特定することできます。

注釈

未知のイベントが発生した場合は、OASE ▶ イベント ▶ イベントフローからの設定がおすすめです。

イベントを参照しながら直感的に設定できます。

OASE ▶ イベント ▶ イベントフローからは以下のように設定します。

警告

フィルターでイベントを検出するには、そのイベント発生前に設定しておく必要があります。

1.4.6.2. アクションの設定¶

アクションでは、ITAで作成したConductorとオペレーションを指定できます。

インスタンスを1台スケールインするアクションを登録してみましょう。

OASE ▶ イベント ▶ イベントフローから、アクションを設定します。

表 1.55 アクションの設定値¶
アクション名	Conductor名称	オペレーション名	ホスト
			イベント連携
`scale`-`in`	`インスタンススケールイン`	`インスタンススケールイン`	`false`

Tip

アクション名は任意で設定可能です。わかりやすいものを設定しましょう。

Conductor名称とオペレーション名は、事前に設定してあるものから選択します。今回はスケールイン用に準備したものを選択しましょう。

警告

発生したイベントに適用したい場合、そのイベントのTTL内に設定する必要があります。

TTL内に設定が難しいようであれば、事前に設定しておきましょう。

OASE ▶ ルール ▶ アクションからは以下のように設定します。

登録ボタンを押し、以下のアクションの設定を追加していきます。

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

1.4.6.3. ルールの設定¶

ルールでは、フィルターとアクションを紐づけます。

そのフィルターでイベントを検知した場合に実行したいアクションを紐づけましょう。

OASE ▶ イベント ▶ イベントフローから、ルールを設定します。

表 1.56 ルールの設定値¶
有効	ルール名	ルールラベル名	優先順位	条件	アクション	結論イベント
				フィルターA	アクションID	元イベントのラベル継承		結論ラベル設定	TTL
						アクション	イベント
`True`	`スケールイン`	`スケールイン`	`1`	`request_range`	`scale`-`in`	`True`	`False`	`[["instance",` `"scale`-`in"]]`	`60`

Tip

ルール名・ルールラベル名は任意で設定可能です。わかりやすいものを設定しましょう。
条件では、フィルターの設定で設定したフィルター「request_range」を選択します。
アクションでは、アクションの設定で設定したアクション「scale-in」を選択します。
これにより、フィルタ―「request_range」でイベントを検知したら、アクション「scale-in」が実行されます。

結論ラベル設定には、アクションが実行されたことを示す結論イベントに付与するラベルを設定します。
結論イベントが判別しやすいようなラベルを設定するとよいでしょう。
分間で集計したリクエスト数をもとに通知されるため、TTLは60秒とします。

警告

発生したイベントに適用したい場合、そのイベントのTTL内に設定する必要があります。

TTL内に設定が難しいようであれば、事前に設定しておきましょう。

OASE ▶ ルール ▶ ルールからは以下のように設定します。

登録ボタンを押し、以下のルールの設定を追加していきます。

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

1.4.6.4. 結果の確認¶

以上の設定が完了したら、発生したイベントをもとにアクションが実行される様子を、イベントフロー画面から確認してみましょう。

Tip

ルールの設定の間に発生させたイベントのTTLが切れてしまったら、改めて同じイベントを発生させてください。

表 1.57 通知メール一覧¶
通知内容	リクエスト数回復
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `50`

OASE ▶ イベント ▶ イベントフローの画面では、時系列に沿ってイベントが発生している様子を確認できます。

アクションが実行されたことを示す結論イベントにルールで設定したラベルが付与されていることも確認しましょう。

さて次に、2台稼働時のリクエスト数閾値内回復のイベントを発生させてみましょう。

表 1.58 通知メール一覧¶
通知内容	リクエスト数回復
`件名`	`[info]` `Requests:` `Threshold` `recovery`
`本文`	`リクエスト数が、閾値内に回復しました。` `RequestCount` `<` `100`

そうすると、事前に設定したルールが適用され、結論イベントの発生まで確認できます。

↑ Page Top