EDA（Event-Driven Ansible）とは
今回は、最近発表された”Red Hat Ansible Automation Platform 2.4(以降AAP 2.4)”の新機能のうち、
目玉となる「Event-Driven Ansible(以降EDA)」について紹介します。
EDAを使用する事で「監視や検知したイベントをトリガーにした対応の自動化」を実現でき、
・セキュリティ対応や障害対応の迅速化
・ルーチンタスクの工数削減
・サービスの品質や安全性の向上
などが図れるとされています。
つまり、何かしらの事象が発生してからの、初動対応のスピードと作業の確実性、更にその対応工数でお困りの組織にはピッタリな機能となっています。
また、Red Hat社のプレスリリース記事(1)の、サポートコメントの中では
「Event-Driven Ansibleは、決して帰宅しないチームメンバーです」
とも記載されていましたが、具体的にどのような機能で、どのように使われる事を想定しているのかを次項から記載します。
www.redhat.com
さらっと機能概要を簡単にご紹介
・AAP 2.4から実装された新機能
・ Automation Controllerと連携して動作する
・ 手動実行していたジョブテンプレート(Playbook)を自動実行する
・ Playbookと同様、Rulebookという可読性の高いテキスト形式ファイルで操作を定義する
・ トリガーとしてサードパーティ製品と連携できる
・システム障害対応のユースケース
なんらかのシステム障害が起こった際に、管理職の方たちが必ず思われるのは
「早く直せ（復旧しろ）」
だと思います。
その為に、監視ツールやメール通知などの何かしらの方法で、
障害の発生に気づける仕組みを導入されている事と思います。
では気づいたその後のアクションはどうでしょうか？
・発生事象と影響度の確認
・原因調査のための情報取得
・上記を含めた関係者へのエスカレーション
等、色々とありますね。
実際の現場では、
監視のオペレータだけでは次のアクションが取れない。↓
上長を経由して別のチームの詳しい人を深夜に捕まえる。↓
それらに時間を取られて復旧が遅れて他の箇所にも障害が広がる・・・↓
詳しい人間に聞いたら特定のサービスを再起動するだけで復旧した。
なんて事もあるかと思います。
そして今後同様の事象（"イベント"）が再発した時にオペレータが対応できるように、
① 詳しい人間が、イベント発生時に実行して欲しい事の手順書を作る
② イベントと手順書を紐づけてナレッジ化する
③ オペレータはナレッジを検索して手順書に沿って手動で操作する
が、オペレータが操作を間違える
④ 手順を見直す、手順実行は二人で行う・・・
そんな負のスパイラルが見えますね。
これを解決してくれるのがEDAです。
監視ツールなどとEDAが連携し、
発生したイベント毎にあらかじめ定義した手順を自動実行します。
Red Hat社のデモ（https://www.youtube.com/watch?v=rfrtYn7s3IA）では、
実際にWEBサーバがサービス停止した場合に自動復旧させるケースを紹介しています。
詳細は省きますが、以下のような流れでした。
① イベント発生（WEBサーバのサービス停止）を検知
② ITSMツールへの起票と同時にWEBサーバのサービスを再デプロイ＆再起動
③ 復旧したらITSMツールのチケットをクローズ
復旧しなかった場合や、通信出来なかった場合は次の手順へ
④ 仮想基盤にアクセスしWEBサーバの仮想マシンを正常な時のスナップショットに戻す
⑤ 復旧を確認し、ITSMツールのチケットをクローズ
これらが、ものの数分で実行されサービスが復旧に至っています。
そしてどこにも人間の手による操作は必要ありません。
また、オペレータからのエスカレーションも、
「障害が発生しましたが、すでに復旧済みです 収集されたログとともにベンダに調査依頼を実施します」と言った内容になり、場合によっては事後報告だけで良く、管理者は安心して眠る事が出来るでしょう。
障害復旧にかかる工数の削減が実現され、システムに詳しい人間≒優秀な人間の稼働は、より高度な業務に集中させる事が可能になります。
しかし、EDAおよび自動化の本質は単なる「工数削減」ではありません。
このケースで言うと、迅速な対応によるシステムの安定性向上、つまりサービスレベルの向上です。
さらに発展させると、顧客満足度の向上や社内システムであれば生産性の向上だと思います。
是非、サービス自体の価格や利益率向上につながるものとお考えください。
・セキュリティ対応のユースケース
次にセキュリティ対応のケースを紹介します。
セキュリティの世界では"対応速度"がとても重要である事はご存じかと思います。
外部からの攻撃に関しては、特に即時性が求められます。
ひと昔前までは、海外や特定の国のグローバルIPアドレスからの通信を全てブロックするような方法をとっていたケースもあるかと思います。しかし最近では国内のグローバルIPアドレスを使用した攻撃も多く観測されるようになって来ました。
また、攻撃者は多種多様な方法で攻撃を連続的に行ってきます。適切に設置・定義更新されているWAFやUTMなどによりほとんどの攻撃は無効化できるとはいえ、ゼロデイ攻撃やDDoS攻撃など放置しておいて良いものではありません。攻撃を検知したら早急にWAFやUTMのポリシーを変更して防御する対応が必要です。
しかしシステムのセキュリティに関わる設定変更を、手動で、事前の手順レビューや作業承認無く、だれでも即時行える組織は存在しないでしょう。また、誰かの意思決定を待ったり、作業準備している間にも攻撃は続き、最悪突破されるかもしれません。
これもEDAで解決できます。
F5社のコミュニティブログで、
EDAを使って、ログをもとにBIG-IPの設定変更(追加)を自動化する
以下のようなケースが紹介されていました。
community.f5.com
具体的には以下のような流れとなっています。
① BIG-IP(WAF)のログを監視しているツール(Elastic Stack)で基準を超えたものを検知
② Elastic Stackから自動的に、EDAに送信元IPアドレス等の情報を含めて送信(Webhook)
③ EDAがElastic Stackから渡された情報を元にBIG-IPのWAFポリシーを自動的に追加
こちらはまだDemo動画はUPされていませんでしたが、GitHubにコードが公開されており、
とてもシンプルな構成になっています。
基準値のチューニングが難しいかもしれませんが、設定追加対応自体は非常に迅速に行う事が出来そうです。
・製品サポート対応のユースケース
なんらかのソフトウェア製品のサポートを行っている場合、
使用しているソフトのバージョンや、動作させているOSなどの情報は1次受付の際にヒアリングされる事が多いと思います。単純な仕様に関する問い合わせや、既知の事象であれば特に問題ありませんが、新規の不具合が疑われる場合は実際にヒアリングしたバージョンとOSを検証環境に用意して動作検証を行う事があるでしょう。
しかし、エンジニアをアサインして確認依頼を行ってから、エンジニア自身が検証環境を用意していてはその分時間がかかってしまいます。検証環境に潤沢なリソースがあれば多種の組み合わせの環境を事前に用意しておけば良いかもしれませんが、現実的で無い場合も多いです。
例えば以下のようにEDAを使えば、限られたリソースの中で迅速な検証環境の用意が可能です。
① 1次受付時にバージョン等の環境情報を受付管理システムに入力するor入力してもらう
② 受付管理システムに入力された時点で内容をEDAに自動的に送信（Webhook）
※利用しているシステムがWebhook送信に対応していない場合は、
別途Google FormsやMicrosoft Forms等をベースにしたシステムを用意しても良いでしょう。
③ EDAが受け取った内容をもとに自動的に、検証環境用の仮想基盤やクラウド基盤に検証サーバ等を作成、
指定されたバージョンのソフトをインストール
※検証が不要だと判断された場合は、別途環境削除用のトリガーを用意してそれを動かす等も可能です。
こうする事で、エンジニアがアサインされた時にはすでに検証環境が出来ており、
すぐに検証が可能な運用が可能になります。
・パスワードリセットやアカウント発行/削除などの日常の定型業務対応ユースケース
いわゆる定型業務などにもEDAを使用できると思います。
セルフパスワードリセットに対応していないシステムのパスワードリセットや、
アカウント連携に対応していないシステムへの新規アカウント作成や削除等です。
今回は例として新規に入社された方がいた場合を想定します。
例えば・・・
・Active Directory への新規ユーザ作成、各プロパティ登録、グループやOUへの配置
・社内へのリモート接続用のVPN機器（Fortigate）へのユーザ追加
・社内ファイルサーバへの個人フォルダ作成
等が発生しそうです。
こういった一連の作業も、例えばGoogle FormsやMicrosoft Forms等をベースにしたシステム（入力フォームと入力された内容をWebhookで送信する仕組み）を作成し、各パラメータをEDAに連携する事で自動的に行う事が可能です。社内の各システム部門の手を煩わせる必要はありません。
まとめ
ここまででEDAを利用した具体的な想定ユースケースを紹介しました。
改めてメリットをまとめます。
・問題や機能停止に迅速に対処できる
・セキュリティリスクに迅速に対処できる
・ユーザの新規作成に伴う処理、検証用VMの作成、等のルーチンタスクを軽減できる
・Rulebookというテキスト形式のファイルで対応を管理する事で、体系化して管理できる
・Ansible Automation Platformという一つのソリューションで、幅広いIT自動化ニーズに対応する事が出来る
結論
EDAの登場により、Ansible Automation Platformで出来る事の可能性は飛躍的に高まりました。
Ansible Automation Platformを使用して、これからのビジネスやそれを支えるITに、さらなるスピードと可用性を付加しませんか？
