StackStormがもたらしたもの

システム連携を実現する「ダクトテープ」的な役割

　StackStormを導入したことによって得られたメリットとしてまず挙げられるのは、ずばり、複数のシステムを横断した業務フローの実現です。弊社のケースでは、業務フローは複数のシステムに対する個別処理の組み合わせによって構成されるものですが、これをStackStormのWorkflowを使って実装しました。各システムに対する個別の処理はActionで実装しています。Actionを組み合わせてWorkflowでつなぎ合わせているところが、まさにダクトテープを使って各システムをつなぎ合わせているかのようです。

　このようにして、それまで独立に実装し導入されていたパーツ同士を、StackStormを使ってつなぎ合わせることで、例えばデータを設備管理システムに登録すると、そのとおり機器を設定まで実施する、といった業務フローの自動化を実現することができました。

高い再利用性

　WorkflowもActionも、StackStormではYAMLファイルで定義し、それらをPack（AWS、Docker、Sensuなどサードパーティーのシステムごとの監視・制御する機能をまとめたもの）単位でまとめて管理します。ここで、社内の各システムに対応するPackを作ってActionをまとめておくと、そのシステムを使う他の業務フローも定義しやすくなります。

キューイングと排他制御の実現

　我々が取り組む自動化の中で、ネットワーク機器へコンフィグを投入する部分は非常に重要なパートです。前述したとおり、ネットワーク機器側でトランザクションのような排他制御を行えない場合は、同時に設定変更を行おうとして事故が発生する、といったことを防ぐために、外部でこれを実装する必要があります。この安全性に関わる重要な課題も、StackStormが持つ並列度ポリシーの機能を使うことで容易に実現することができました。機器への設定を行うActionに対し、同時実行数を1に制限するポリシーをセットすることで、複数のワークフローが同時に走っていても、機器を設定するActionは全体で常に1つしか動いていないことを保証できます。将来的に規模が大きくなり、同時に走るワークフローが増えてきた時には、もう少し緩いポリシー、例えば設定先ホストごとに同時実行数を1に制限する、といったポリシーに変えることで、スループットを維持するといったことも可能です。

開発を行う上でのメリット

　これまで述べたとおり、StackStormを導入することで、それまで足りていなかったピースを埋め、課題を解決することができました。それだけでも十分なのですが、実はStackStormを採用したことで、自動化の取り組みにおける開発に、大変大きな効果がありました。

ワークフローの実装方法の統一

　ワークフローをある特定のシステムの中に実装してしまうと、実装方法はそのシステム自体の実装に依存してしまいます。例えば、Rubyで書かれているシステムからスタートする業務フローがあるとします。そこで業務フローを単にシステムの一部として実装してしまうと、その業務フローはRubyで実装されることになります。一方別のシステムがPythonで書かれている……となると、そこで実装される業務フローはPythonで書くことになり、業務フローの実装があっちとこっちで言語からして違う、といった状況になってしまいます。アーキテクチャーを考える上で、これは当然避けたいことでした。

　そこでStackStormを用いると、もちろんStackStormに依存することにはなってしまいますが、

• あらゆる業務フローに対応するWorkflowを、定められた共通の形式で記述できる
• そして、その表現形式をYAMLに統一することができる

という2点から、大きなメリットを得ることができます。

アーキテクチャーの見通しが良くなる

　「システム間の連携をStackStormがすべて担う」と定めた時から、アーキテクチャーの全体的な見通しが良くなりました。システムが他のシステムを呼び出すことは、つまりシステム間に依存関係を作ることになります。「StackStormのワークフローを複数のシステムにまたがる唯一のポイントとする」とルールを定めることで、呼び出し元が常に一定になります。これにはさまざまなメリットがありますが、その一つとして、「呼び出し先のシステムの変更を行う際に、影響する他のシステムを容易に調べることができる」といったことが挙げられます。

　また、あらゆる業務フローについて、そのワークフロー設計を容易に実現できるようになりました。ワークフローは特定のシステムに依存しないので、本来は自由に考えることができます。当然といえば当然のことですが、いざ実際にワークフローを考えるとなった時、既存のシステムをベースに考えてしまいがちで、無意識のうちに何らかの制約条件を考えていることがあります。しかしStackStormのおかげで、いわば既存システムの呪縛から独立して、ワークフローを業務フローから純粋に考え出せるようになり、ワークフローから逆算して各システムに必要なActionを見つけ出せるようになりました。ここで洗い出しているのは、まさにそのシステムが持つ外部に公開すべきAPIになります。

　ワークフローの開始点をStackStormに統一できたことも、アーキテクチャーの見通しの改善に大きく寄与しています。今のところこの呼び出しはStackStormのWebhookからのみ行っていますが、これを別の「IF」に置き換えて、例えば特定のログが流れてきたらこのワークフローを実行する、といったことも将来的には簡単にできる仕組みになっています。

ワークフローのコードレビューやCI/CDが可能

　StackStormではActionやWorkflowはすべてYAMLで記述します。つまり、GitなどのSCMで変更管理ができることになります。これによって、ソフトウェアのソースコードと同様に、業務のフローもYAMLによって変更の差分を表示できるようになったり、プルリクエストを使ってレビューを行えるようになったりしました。また、従来のCIのソフトウェアと同じような仕組みでCI/CDが可能だったため、開発者にとってとっつきやすく、他のアジャイルで開発しているシステムと同様に速い速度で開発を進めることが可能でした。

さらなる自動化の促進へ

　ここまで、弊社でのStackStormの具体的な使用例と、それによって得られた効果を紹介しました。今後は、既に作ったPackを活用しさらに自動化を進めていきたいと考えています。また、Auto Remediation（＝障害が発生した際の自動復旧）なども検討していこうと思います。

　ちなみに余談ですが、Auto Remediationで使う場合は特に、StackStorm自体のHAが課題になると思います。弊社ではStackStormの公式DockerイメージをKubernetesクラスタ上で動かすことを検証しており、これによってHAを実現しようと考えております。興味のある方はStackStorm Docker Imageのドキュメントをご覧ください。またStackStorm公式Slackの#dockerチャネルでも質問などを受け付けておりますので、お気軽にご参加ください。お待ちしております。