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

1.4.1. 問題 (再掲)

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

通知内容

2台稼働時にリクエスト数が閾値内に回復した場合

3台稼働時にリクエスト数が閾値内に回復した場合

件名

[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の設定を行っていきましょう。
  1. イベント収集設定

  2. ラベルの設定

  3. OASEエージェントの設定

  4. ルールの設定

1.4.3. イベント収集設定

1.4.3.1. イベント収集設定

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

警告

これまでのシナリオで設定したものが残っているようであれば、こちらの設定は不要です。
OASE管理 ▶ エージェント から、外部サービスの情報を登録します。
登録 ボタンを押し、以下のエージェントの登録をしていきます。
エージェント登録画面
表 1.47 イベント収集設定値

イベント収集設定名

接続方式

リクエストメソッド

接続先

認証情報

TTL

ユーザー名

パスワード

リクエスト監視

IMAP パスワード認証

IMAP: Plaintext

**.***.**.***

*****@**.***

**

60

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

Tip

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

1.4.4. ラベルの設定

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

ラベルキー

利用目的

subject

イベントの内容を特定できるようにするラベル

requestcount

基準となった閾値を把握するためのラベル

instance

作業Cの作業結果を示すためのラベル

注釈

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

1.4.4.1. ラベルの作成

警告

これまでのシナリオで設定したものが残っているようであれば、こちらの設定は不要です。
ラベル作成 では、イベントを特定する時に利用するキー(ラベル)を作成します。
OASE ▶ ラベル ▶ ラベル作成 から、ラベルを作成します。
登録 ボタンを押し、以下のラベルの設定を追加していきます。
必要に応じて、追加 ボタンを押して行数を追加しましょう。
ラベル作成画面
表 1.49 ラベル作成の設定値

ラベルキー

カラーコード

subject

#FBFF00

requestcount

#7F76F9

instance

#00FF33

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

注釈

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

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

ラベル付与 では、イベントにラベルを付与する条件と、条件に合った際に付与するラベルの内容を設定します。
今回は、リクエスト数閾値内回復を知らせるものであるかどうかを示すラベルを付与する必要があります。

警告

「リクエスト数監視」に関しては、これまでのシナリオで設定したものが残っているようであれば、設定は不要です。
OASE ▶ ラベル ▶ ラベル付与 から、ラベルを付与するための設定を行います。
登録 ボタンを押し、以下のラベル付与の設定を追加していきます。
必要に応じて、追加 ボタンを押して行数を追加しましょう。
ラベル付与
表 1.50 ラベル付与の設定値

ラベリング設定名

イベント収集設定名

検索条件

ラベル

キー

値のデータ型

比較方法

比較する値

キー

通知名

リクエスト監視

subject

文字列

==

[info] Requests: Threshold recovery

subject

リクエスト数回復

リクエスト数監視

リクエスト監視

body.plain

その他

RegExp

RequestCount . (\d{2,3})

requestcount

\1

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

Tip

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

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

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

警告

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

注釈

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

1.4.5.1. .envの設定

.envの項目にこれまでの工程で設定した値を設定します。
exastro-docker-compose/ita_ag_oase/.env に下記の内容を入力します。
.env
表 1.51 .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の設定値 を参照ください。

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エージェントが収集したイベント等、イベントが時系列に表示されます。
表示されたイベントには、ラベル付与での設定に沿ってラベルが付与されています。
この画面から フィルターアクションルール の設定をそれぞれ行うこともできます。
まずは、以下のような、2台稼働時のリクエスト数閾値内回復のイベントを発生させて、設定を進めましょう。
表 1.52 通知メール一覧

通知内容

リクエスト数回復

件名

[info] Requests: Threshold recovery

本文

リクエスト数が、閾値内に回復しました。
RequestCount < 50

1.4.6.1. フィルターの設定

フィルター では、ラベルをもとにイベントを検知するための条件を設定します。
イベントの件名と本文からスケールインを実施する条件に合うイベントを特定できるように条件を設定してみましょう。

注釈

スケールインを実施するのは、インスタンスが3台未満の稼働の状態で、リクエスト数が閾値内に回復した場合です。
閾値は、インスタンス1台につき50リクエスト/minです。
OASE ▶ ルール ▶ フィルター から、フィルター を設定します。
登録 ボタンを押し、以下のフィルターの設定を追加していきます。
フィルター
表 1.53 フィルターの設定値

有効

フィルター名

フィルター条件

検索方法

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.54 アクションの設定値

アクション名

Conductor名称

オペレーション名

ホスト

イベント連携

scale-in

インスタンススケールイン

インスタンススケールイン

false

Tip

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

警告

発生したイベントに適用したい場合、そのイベントのTTL内に設定する必要があります。
TTL内に設定が難しいようであれば、事前に設定しておきましょう。
OASE ▶ ルール ▶ アクション からは以下のように設定します。
登録 ボタンを押し、以下のアクションの設定を追加していきます。
アクション
入力が終わったら、編集確認 ボタンを押して登録します。

1.4.6.3. ルールの設定

ルール では、フィルターとアクションを紐づけます。
そのフィルターでイベントを検知した場合に実行したいアクションを紐づけましょう。
OASE ▶ イベント ▶ イベントフロー から、ルール を設定します。
イベントフロー_ルール
表 1.55 ルールの設定値

有効

ルール名

ルールラベル名

優先順位

条件

アクション

結論イベント

フィルター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.56 通知メール一覧

通知内容

リクエスト数回復

件名

[info] Requests: Threshold recovery

本文

リクエスト数が、閾値内に回復しました。
RequestCount < 50
OASE ▶ イベント ▶ イベントフロー の画面では、時系列に沿ってイベントが発生している様子を確認できます。
アクションが実行されたことを示す結論イベントに ルール で設定したラベルが付与されていることも確認しましょう。
イベントフロー_結論イベント
さて次に、2台稼働時のリクエスト数閾値内回復のイベントを発生させてみましょう。
表 1.57 通知メール一覧

通知内容

リクエスト数回復

件名

[info] Requests: Threshold recovery

本文

リクエスト数が、閾値内に回復しました。
RequestCount < 100
そうすると、事前に設定したルールが適用され、結論イベントの発生まで確認できます。
イベントフロー_結論イベント_2回目