深夜の呼び出しを過去にする：Event-Driven Ansible（EDA）で構築する「自己修復」インフラの極意
こんにちは。システムを止めることに心血を注ぎ、深夜の障害対応を過去のものにしようと企んでいるSREの先輩です。
多くの現場では、監視ツールがアラートを鳴らし、人間が管理画面を開き、SSHでサーバーにログインし、手作業でサービスを再起動する——そんな光景が繰り返されています。しかし、「その作業、AIや自動化に任せたくないですか？」
今回は、Ansibleの新時代を切り拓くEvent-Driven Ansible（EDA）を使って、Webhookをトリガーにシステムが「自ら考え、自ら治す」仕組みの構築方法を伝授します。これをマスターすれば、あなたのインフラはただの箱から、自律的に最適化を繰り返す「生き物」に進化します。
—
1. なぜ今、Event-Driven Ansibleなのか？
これまでのAnsibleは「プッシュ型」のツールでした。人間がコマンドを叩くか、スケジュール実行するまで動きません。しかし、障害は夜中にやってきます。
EDAの役割は「耳」を持つこと。
Webhookや監視ツールからの通知（イベント）をリアルタイムで検知し、あらかじめ定義されたルール（Drools）に従って、適切なAnsible Playbookを即座にキックします。
- 監視ツール（Prometheus等）：異常を検知
- EDA Server：Webhookを受信し、ルールを評価
- Ansible Playbook：修復を実行
このパイプラインを構築することで、「障害発生→検知→自動修復」のリードタイムを限りなくゼロに近づけられます。
—
2. 環境構築：EDAを叩き起こす準備
まずは、EDAを実行する環境を整えましょう。今回は軽量な `ansible-rulebook` を使用します。
Python環境を整える（仮想環境推奨）
python3 -m venv venv
source venv/bin/activate
EDA実行エンジンをインストール
pip install ansible-rulebook
—
3. 「Hello World」：Webhookを受け取ってログを吐く
まずは、システムが正しくイベントを捉えられるか確認しましょう。これがすべての自動化の基礎となります。
ルール定義ファイル (`rulebook.yml`)
Droolsエンジンがどのようにイベントを判断するかを記述します。
—
- name: Webhookリスナーのテスト
hosts: all
sources:
# 5000番ポートでWebhookを待ち受ける
- ansible.eda.webhook:
host: 0.0.0.0
port: 5000
rules:
- name: 正常系イベントの検知
condition: event.payload.message == “ping”
action:
# 条件に合致したらログを出力する
debug:
msg: “システムからのpingを受信しました！”
動作確認（別ターミナルで実行）
実行コマンド
ansible-rulebook –rulebook rulebook.yml -i inventory.ini –verbose
別のターミナルから、`curl` でイベントを飛ばしてみましょう。
curl -H ‘Content-Type: application/json’ -d ‘{“message”: “ping”}’ http://localhost:5000/endpoint
ターミナルに「システムからのpingを受信しました！」と表示されれば成功です。これで、あなたのインフラは外部からの信号を聞き取れるようになりました。
—
4. 現場で震えるほど役立つ「自動修復」の実装
では、Webサーバーがダウンした時に自動で再起動するシナリオを考えてみましょう。
ルール定義の応用 (`auto_heal.yml`)
rules:
- name: Apacheサービスがダウンしたら再起動する
condition: event.payload.alert == “service_down”
action:
run_playbook:
name: /path/to/playbooks/restart_apache.yml
肝となるPlaybook (`restart_apache.yml`)
冪等性（何度実行しても同じ結果になること）を保つのが鉄則です。
- name: Apacheを強制再起動
hosts: webservers
become: yes
tasks:
- name: サービスを起動状態にする
ansible.builtin.service:
name: httpd
state: restarted
—
5. SREが現場で意識すべき「極限の知見」
初心者の方が最初につまずきやすいポイントを、経験則から教えます。
1. 「無限ループ」を避ける: 修復Playbookが失敗し続けると、EDAが無限に再起動を繰り返す可能性があります。ルール定義には `throttle`（一定時間内の実行回数制限）を必ず組み込んでください。
2. 冪等性の追求: 自動修復スクリプトは、「既に起動しているなら何もしない」という賢さが必要です。`state: restarted` ではなく `state: started` を活用し、状態を宣言的に管理してください。
3. 可観測性（Observability）: 自動修復した記録は、必ずログサーバー（Elasticsearch等）やSlackに飛ばしてください。「いつの間にか直っていた」は、SREにとって一番怖い「原因不明のブラックボックス」になります。
—
最後に：自動化は「怠惰」ではなく「情熱」です
インフラを自動化する理由は、楽をしたいからではありません。人間が人間らしい「より創造的な設計」に集中するための時間を確保するためです。
EDAはまだ新しい技術ですが、そのポテンシャルは計り知れません。まずは今日、Webhookを一つ受け取るところから始めてみてください。あなたのインフラが、深夜に勝手に問題解決してくれる頼もしい相棒に変わる日は、すぐそこです。
応援しています。困ったときは、またいつでも聞きに来てくださいね。