Event-Driven Ansibleで実現する「自律型インフラ」の極致：監視から修復までの0秒化戦略
SREの現場において「夜中の3時にページャーが鳴る」という体験は、もう過去の遺物にするべきだ。
かつてのインフラ自動化は「定期実行」や「オンデマンド実行」が主流だった。しかし、今の時代に求められているのは「観測（Observability）とアクションの完全な同期」だ。Event-Driven Ansible（EDA）は、単なる自動化ツールではない。監視系からのシグナルをトリガーに、人間を介さず「思考」して「修復」する、インフラの自律神経系である。
本稿では、現場の血肉となるEDAの設計思想と、明日から使える実装テクニックを伝授する。
—
1. なぜ「Drools」なのか？ ― 意思決定の非同期処理
EDAの心臓部は、JavaベースのルールエンジンであるDroolsを採用している。なぜ複雑な条件分岐をここに持ち込むのか？ それは、「ノイズと障害の判別」をインフラ側で処理させるためだ。
PrometheusのアラートをそのままPlaybookに渡すと、スパイク的な負荷やフラッピング（瞬間的なダウン）で自動修復が走り、かえってシステムを不安定にする。EDAでは、以下のように「状態」を定義する。
ルール定義のベストプラクティス (rulebook.yml)
—
- name: Auto-remediation for Web Server
hosts: all
sources:
- ansible.eda.webhook:
host: 0.0.0.0
port: 5000
rules:
- name: Handle High CPU Load
condition: event.payload.alertname == “HighCPUUsage” and event.payload.severity == “critical”
action:
run_job_template:
name: “Restart-Service-Or-Scale-Out”
job_args:
extra_vars:
target_host: “{{ event.payload.instance }}”
極意: `condition` に「直近5分間に3回以上の連続したアラートが発生した場合」という条件を組み込め。単発のアラートで修復を走らせるな。それは自動化ではなく、ただの破壊工作だ。
—
2. チーム開発を加速させる「設定の共有化」とプラクティス
EDAを導入すると、PlaybookとRulebookが乖離し、インフラ構成管理が崩壊する。これを防ぐための「絶対ルール」を共有する。
チーム開発の黄金律
1. Rulebookは責務で分割せよ: 監視ツールごとではなく、「Web系」「DB系」「ネットワーク系」とドメインごとにRulebookを管理する。
2. `extra_vars` の標準化: Webhookのペイロードをそのまま渡すな。EDA側で`transform`フィルターを使い、共通のスキーマに変換してPlaybookに渡すこと。これにより、Playbook側は「何が起きたか」ではなく「どう修復するか」のみに集中できる。
3. 冪等性の担保（最重要）: 修復Playbookは、たとえ対象が正常であっても「何もしない（変更なし）」で終了するように設計せよ。`check_mode`を活用した事前検証は必須だ。
—
3. 生産性を極限まで高める「隠れたテクニック」
プロが愛用するVS Code拡張機能
- Ansible (Red Hat): 言わずもがな。`.yml`を開いた瞬間にLintが走る環境を作れ。
- YAML (Red Hat): スキーマ検証を強制し、インデントミスによる「デプロイ失敗」を物理的に排除する。
開発スピードを上げるキーボードショートカット
- `Ctrl + Shift + P` -> `Ansible: Run at Cursor`: 特定のタスクだけを即座に検証するために使う。
- `Alt + Shift + F`: YAMLのフォーマット整形。チームでこのコマンドの挙動を統一せよ。
—
4. Webhook連携の神構成例：Prometheus Alertmanagerとの統合
AlertmanagerからWebhookを受け取る際は、認証と冪等性の確保が鍵となる。
/
Alertmanagerから送られてくるペイロードを想定した型定義
この構造をEDAのFilterで正規化する
/
{
“receiver”: “eda-webhook”,
“status”: “firing”,
“labels”: {
“alertname”: “ServiceDown”,
“instance”: “web-01”
},
“annotations”: {
“summary”: “Service is unreachable”
}
}
実装の勘所:
Prometheusの `alertmanager.yml` には、必ず `send_resolved: true` を設定せよ。修復が完了した際、EDA側で「修復成功」のイベントを拾い、チケット管理ツール（JiraやSlack）に自動クローズを通知するループを作る。これが「運用完全自動化」の完成形だ。
—
SREへのメッセージ
EDAを導入するということは、「自分たちの運用の癖をコードとして記述する」ということだ。
最初は「怖い」と感じるかもしれない。だが、人間が手作業でSSHしてサービスを再起動するのと、コードがその瞬間に判断して修復するのと、どちらが安全か？ 答えは明白だ。
コードは疲れないし、感情でミスをしない。我々SREの役割は、自動修復を構築することではなく、「自動修復が完璧に動作する環境を設計し、その上のビジネス価値を最大化すること」にある。
さあ、今夜のページャーはオフにして、コードに仕事を任せよう。