StackStormによるARの実現
ARの動作をシンプルに定義する
StackStorm公式ブログでAuto-Remediation Definedとして触れられているように、ARはStackStormの主要なユースケースの1つと位置付けています。また、Netflixでは実際にStackStormによるARを実現しており、StackStormの公式ブログで紹介されています。
上記のようにStackStormがAR基盤として使われるのは何故でしょうか。それは、Event-Driven Automationという考え方と実装がARにマッチしているからです。
ここで、StackStormの掲げるEvent-Driven Automationという思想にのっとり、ARの動作を整理してみます。
| 登場人物 | 機能 |
|---|---|
| Server | 自身の状態をMonitorに通知する |
| Monitor | Serverの状態を受け取り、任意のルールに従ってStackStormに通知する |
| StackStorm | Monitorからの通知をイベントとし、所定の窓口へ通知する&対象のServerをRemediateする |
このように、非常にシンプルな構成でARの動作を定義することができます。
ZabbixやSensuなどの監視ツールは、ログの内容によって所定のスクリプトを実行する機能を備えていますが、StackStormという登場人物を増やすことによって、
- 監視と処理の責任主体が明確になる
- 処理がActionとWorkflowによって定義されるので、復旧手順の再利用性が高まる
- 有志が公開しているWorkflowなどを流用できる
というメリットがあります。
StackStormによるARの実装
上記のARを実現するためには、
- Monitorから通知を受けとること
- 通知に従って対象機器を復旧すること
の2つの機能がStackStorm上に必要です。それぞれ、どのように設定すればいいのかを確認していきます。
まず、監視システムからの通知を受けとる部分はruleとして定義されます。外部からの通知を受け取るruleには大きくWebhook ruleと製品別 ruleの2種類があり、それぞれ使い分けることが重要です。
Webhookは汎用的なruleであり、Zabbixやsensuなどの監視システムに「POSTリクエストを飛ばすカスタムスクリプト」を設定することで利用することができます。EndpointやCriteria（Actionを起動する条件）などを柔軟に設定できるというメリットがありますが、上記のカスタムスクリプトを作り込まなければいけないというデメリットがあります。
製品別に用意されたruleは、一般的にPackの形で提供されています。監視システムを例にするとSensu用のPackなどが提供されており、初めから機能と品質が担保されたruleを使えることがメリットです。監視システムに対応したPackが存在する場合は、それを使って通知ルールを作成するのがよいでしょう。
対象の機器を復旧する部分はWorkflowとして定義され、基本的には自分で作り込んでいく部分になります。
ActionやWorkflowの作成方法については公式ドキュメントや公式のサンプルコードを参考にしてください。
Workflowには大きくActionChainとMistralの2種類がありますが、それぞれ特徴があるので使い分けていきましょう。
ザックリと使い分けの基準を示すと、
- Actionの成功/失敗のみの分岐でよい→ActionChain
- ActionのForkやJoin、変数を条件とした分岐を実現したい→Mistral
のようなイメージです。基本的にActionChainの方が安定して高速に動作し、記法も単純なので、最初はActionChainで書くのがオススメです。
最後に、次節でOpenStack環境にどうやってARを適用していくかについて解説します。
OpenStack×StackStormによるARを含めた運用自動化
OpenStackでは、VMや仮想NWなどの資源をDBを用いて管理しています。しかし、何らかの原因によって仮想資源の実態とDB上の情報が不一致を起こすことは珍しくありません。情報の不一致が起こったとき、どのようにDBを修正するか or 仮想資源を再配置するかという判断には知識と経験が要求されます。
また、何らかのエラーが発生した場合のトラブルシューティングにおいて、エラーに対応したDBテーブルや関連ログの収集には、やはり高いレベルの知識と経験が必要であり、運用チームの高負荷に繋がっています。
上記のような問題を解決するための方法の1つとして、StackStormを用いたARが有効です。
具体的には、
- DBと実態の不一致→関連情報を収集し、DBと実態の対応関係を自動修復
- その他AR手順が登録済である問題→ARによる自動修復
- ARに登録されていない問題→エラー発生時刻近辺の関係するログを自動収集し、時系列順にまとめて担当者へ通知
などの動作をStackStorm上に定義することにより、定型的な問題については自動修復し、複雑な問題についても担当者の調査&原因特定にかかる稼動を大幅に削減することができるでしょう。
また、問題の大きさや関係するログの範囲などの指標によって対処にかかる、人的稼動量を自動で見積もる、ということもできるようになるかもしれません。
上記のような運用効率化システムを実現することを目指し、成果は積極的に発表していこうと考えているので、ご期待いただければと思います。
