Red Hat で Ansible のソリューションアーキテクトをしている中島でございます。
本エントリーは Ansible Advent Calendar 2024 の3日目の記事となります。 Ansible Advent Calendar 2024 にはAnsible 関する様々なTIPSやナレッジが投稿されておりますの、Ansible を触っている方はご一読いただくと、自動化のステップアップのきっかけを得られるかもしれません。
さて、Ansible には Event-Drive Ansible(以下EDA)という機能があります。これは、監視システムや分析システムなどの周辺システムからのメッセージを受取り、そのメッセージ内容によって対応するAnsibleの自動化を起動するための機能です。 この機能を使うことで、監視アラートへの自動対応、セキュリティ侵害検知への自動対応などを行うことが可能となります。EDA自身のイメージについて過去記事をご参照ください。
- Event-Driven Ansible + Zabbix で実現する障害対応の自動化
- Event-Driven Ansible の始め方
- Event-Driven Ansible と IBM Turbonomic / Instana の連携
- Ansible Automation Platform 2.4 注目の新機能紹介
ここからが本題となります。 このようなイベント駆動型の仕組みを構築しようとした時に最も問題になるのが「イベントの精度」です。 「アラートAが来たら自動化1を流す」という仕組みを作った時に、アラートAが正確ならば何ら問題がないですが、現実のシステムではアラートAが何度も送信されてしまったり、別のアラートBに起因してアラートAが送信されるケースもあります。このようにアラートが不正確では当然自動対応をするEDA側も想定外の自動化を実行してしまう可能性が出てきます。もちろんアラート送信側で精度を上げることも必要ですが、100%完璧な仕組みを作ることは困難です。そのため、自動対応を行うEDA側でも「アラートの不正確さ」をある程度吸収する仕組みが必要となります。
今回は、そんなアラートの不正確さを吸収するEDA機能である「Throttle（スロットル）」機能をご紹介します。
Throttle は EDA の rulebook の中で定義することができます。実際に rulebook を見てみましょう。
---
- name: Listen for webhook 8112 for throttle demo
hosts: all
sources:
- ansible.eda.webhook:
host: 0.0.0.0
port: 8112
rules:
- name: throttle enabled
condition: >-
event.payload.message == 'enabled'
throttle:
once_within: 1 minutes
group_by_attributes:
- event.payload.message
actions:
- run_job_template:
name: throttle_enable_job
organization: Default
- name: throttle disabled
condition: >-
event.payload.message == 'disabled'
actions:
- run_job_template:
name: throttle_disabled_job
organization: Default
この rulebook ではポート8112番でWebhookを待ち受け、受け取ったイベントに応じて、2つのルールが定義されています。
| ルール | 条件 | 実施するアクション | Throttle |
|---|---|---|---|
| name: throttle enabled | 受信したデータが以下の条件を満たした時 event.payload.message == 'enabled' |
以下のジョブを起動 throttle_enable_job |
on |
| name: throttle disabled | 受信したデータが以下の条件を満たした時 event.payload.message == 'disabled' |
以下のジョブを起動 throttle_disable_job |
off |
name: throttle enabled では以下の記述によって、Throttle が有効化されています。
throttle:
once_within: 1 minutes
group_by_attributes:
- event.payload.message
この記述の説明は後回しにして、実際にこの2つのルールに対して、複数回のイベントを送信して挙動を確認してみます。
まず最初はThrottle無効のルールを起動するために event.payload.message == 'disabled' を含むメッセージを5回送信してみます（このイベント送信もAAPから行っています）。定義通りに動けば、throttle_disable_job が5回起動されるはずです。実際に以下の動画で確認してください(想定通り5回起動されてしまっています)。
次に、Throttleを有効にした event.payload.message == 'enabled' を5回送信しています。こちらも動画で確認してください（同一イベントへの対応が抑制され、1回しか起動されません）
このように Throttle 機能を使うことで、同一イベントに対する自動化の起動を抑制することが可能です。
では挙動が確認できたところで、Throttle の基本的な記述について確認していきます。といって、マニュアルに記載されていますので、重要な部分のみ抜粋します。
まずイベント受信した場合の「自動化の起動タイミング」を制御するための記述として、
once_within: イベントを受信したら即自動化を起動して、その後指定した時間内は同一イベントを無視するonce_after: イベントを受信したら指定時間分だけ待ち、その間に受け取った同一イベントを無視する。指定時間経過後に自動化を実行する
また、「何を同一イベントとするか」については group_by_attributes で指定します。受信したメッセージ含まれるデータを指定し、指定されたデータが同じものを「同一イベント」と判断します。
今回ご紹介した Throttle 機能を使うことで、イベント駆動の自動化は飛躍的に使いやすくなり、適用できるシーンが増えます。9割正確なアラートシステムと、9割正確なrulebook の組み合わせは99%の精度で処理できるからです。単独で99%の精度を得るのはコストが高すぎて実現が困難ですが、90%の精度であれば現実的なコストで実装が可能です。 またEDAはRed Hat Ansible Automation Platform に含まれる標準機能ですので、すでにサブスクリプションをお持ちの方は追加コスト無しで利用することができます。
ぜひ、この機能を活用して、自動化の適用範囲を広げ、日々の作業の効率化役立ててください。
