StackStorm共同創業者に聞いた、イベントドリブン自動化ツールがDevOpsにもたらすインパクト：サーバレスにもつながる（1/2 ページ）

構成自動化ツールの分野では、さまざまなオープンソースツールがひしめき合っている。この中で、独特な世界を切り開いているのがStackStormだ。Chief StormerのDmitri Zimine氏に、このツールの魅力について詳しく聞いた。

[三木泉，＠IT]

　オープンソースのイベントドリブンな自動化ツール、StackStorm。米国では「DevOpsのためのIFTTT」などと表現されることもあるようだ。

　IFTTTとは、日本でいえば、例えばヤフーのmyThings。さまざまなモノやサービスをつなげ、「IF This Then That」（Aが起こればBというアクションをトリガーする）を実行できるサービスだ。IFTTTやmyThingsは、個人の生活を便利にすることを目的としているが、「StackStormを使い、テスラ（自動車）のクラクションを遠隔で鳴らすようにした人もいる」と、StackStormの共同創立者であるDmitri Zimine（ドミトリ・ジミネ）氏は笑う。

　StackStormはDevOps的な構成自動化ツールだ。この分野ではChef、Puppet、Ansibleなど多様なオープンソースツールがひしめき合っているが、StackStormはこれらと直接競い合うというよりも、イベントに基づいてフローを定義できること、さらに多様なシステムを連携できることが大きな特徴になっている。サーバレスコンピューティングにも応用できるという。

　企業としてのStackStormはブロケードに買収されたが、その後も独立性を保って活動。現在でも「Chief Stormer」としてエンジニアリングのトップを務めるZimine氏に、StackStormの狙いと可能性について聞いた。

　なお、Zimine氏はマイクロソフトに買収された自動化ツールベンダーのOpalis（同ツールは、現在ではSystem Center Orchestratorとなっている）でリードアーキテクトを務め、さらにヴイエムウェアでVMware vSphereの管理ツールであるvSphere Clientの開発チームを率いた後、2013年にStackStormを創業し、開発を率いている。StackStormでは、OpenStackのMistralプロジェクトにも貢献している。

StackStormは、どういうきっかけで生まれたのか

――あらためて、このツールを開発するに至ったきっかけを聞かせてください。

　OpalisはITIL時代のイベントドリブンな自動化製品でした。その後ヴイエムウェアに移りましたが、2012〜13年頃、OpenStackに興味を持つようになりました。「なぜ成熟した、扱いやすいvSphereという存在があるのに、（当時は）スクリプトの塊というくらいでしかないOpenStackを使いたがる企業があるのだろう」と。

――vSphereよりも安価だからでしょう？

　精通したエンジニアを雇わなければならないので、OpenStackの方が高くつきました。考えた挙句、要するに（こうした企業は）DevOpsをやりたいんだと考え、この世界について調べ上げました。そこで、既存のDevOpsツールでは満たされていないニーズに、イベントドリブンオートメーションがあることが分かりました。私のこれまでの経験を生かすこともできました。そこでStackStormを始めたのです。

――PuppetやChefなどと直接競合するようなツールを開発しようとは思わなかったのですか。

　宣言型（Declarative）のアプローチを持ったツールは多数あり、高い人気を誇っています。私のインフラをどう運用したいかを定義し、あるいはシステムをどう設定したいかを示し、後をシステムに任せるというものです。KubernetesやDocker Swarm、Amazon Web ServicesのCloud Formation、OpenStackのHeatもこうしたツールです。

　一方、StackStormが採用している命令型（Imperative）のアプローチは、宣言型アプローチでは対応しきれないユースケースをカバーできます。例えば完全なライフサイクル管理では、プロセスや手順が重要です。出発点において、最終的なあるべき姿を伝えるわけにはいきません。こうした問題を解決することが、そのうち重要になると考え、以前の経験を生かして取り組むことにしました。

　また、ハイパースケールなITサービス企業は、どこも何らかの修復自動化ツールを持っています。例えばFacebookは「F BAR」というツールを自ら開発しました。これはFacebookのインフラと密接に結びついているため、オープンソース化は困難です。そこで、こうしたツールを自社開発できない、あるいは自社開発したくない人たちにも使える、オープンソースソフトウェアが必要だと考えました。実際、NetflixはStackStormに切り替えています。

――オープンソースソフトウェアとしてのユーザーベースの拡大と、ビジネスとの関係をどう考えてきたのですか？

　スタートアップ企業として、私たちもこの問題を考えてきました。何かを売る際には、用途がはっきりしていることが重要です。私たちの生み出したのは汎用プラットフォームなので、事業として成功させるのは簡単ではありませんでした。

　それが、ブロケードによる買収で変わりました。（オープンソースであるため、）ユーザーはITプロセス自動化、修復自動化、IoT、サーバレスコンピューティングなど、あらゆる用途で自由に活用できます。私たちは多くの人々にこのソフトウェアが試され、使われ、他のツールや対象との統合が進むことで、評価を高め、このツールをますます便利なものにしていけます。ブロケードとしてはネットワーク分野での統合度を高めた製品を提供しています。他の企業は別の領域でビジネスを構築していけます。

――ブロケードに買収されることを選んだ理由を聞かせてください。

　役に立つ重要なツールが安定したビジネスモデルを築けるとは限りません。Dockerも安定したビジネスのやり方を探しているくらいですから、私たちにとってはさらに難しいものがありました。StackStormはこのツールがはまる用途を模索していました。収益を確保するため、セキュリティ、ストレージ、ネットワークといった分野を考えていたところ、ちょうどブロケードからの提案がありました。私たちはネットワークがクラウド自動化から学べることは多いと考えました。

　買収後、私たちはブロケード社内でスタートアップとして位置付けられています。オープンソースの重要性を理解している証拠だと思います。今でも私の仕事の80％は、StarkStormがプラットフォームとして健全で、コミュニティに広く受け入れられるようにすることにあります。

――ネットワークベンダーによる買収が、ITプロセス全般を自動化するツールとしての評価を直接高めることにはつながらないと思いますが。

　コミュニティには、そうした懸念も見られました。しかしブロケードのプロダクトマネージャは即座に、「StackStormがネットワークのツールになってしまうなら、それは失敗だ」と明確に宣言しました。私たちはその後4、5カ月をかけて、製品の位置付けを明確化し、コミュニティに報告しました。

　StackStormの有償版、StackStorm Enterpriseの後継として登場したBrocade Workflow Composerは、汎用的な自動化プラットフォームです。そしてネットワーク自動化については、このプラットフォーム上にインストールできるソフトウェアとして、ネットワークとのより抽象化されたやり取りを実現します。

――オープンソース化はいつごろ行ったのですか？

　当初からオープンソースでした。DevOpsツールとしては必須だと考えたからです。また、米国および欧州では、調達するソフトウェアがオープンソースであることを要求する企業が増えています。理由はコントロールにあります。商用ベンダーでは、バグを直してもらうのに6〜9カ月かかることがあります。これでは特に、責任を持ってクラウドサービスを提供しようとする企業には受け入れられません。一方でこうしたユーザー企業は、商用サポートが提供されないようなツールも使いたがりません。そこでエンタープライズ版を通じたサポートを提供しました。

――コミュニティはどれくらいの規模で、どれくらいアクティブなのでしょうか。

　非常にアクティブです。250人程度のコントリビューターがいます。2016年12月と2017年2月にメジャーバージョンアップをしました。また、StackStorm Exchangeという、AppStoreやDocker Hubに似た場（多様なツールや環境との統合を実現するパックのリポジトリ）を作りました。Exchangeにおける最大のパックであるAWS Packのメンテナーは日本人です。