StackStorm共同創業者に聞いた、イベントドリブン自動化ツールがDevOpsにもたらすインパクト：サーバレスにもつながる（2/2 ページ）
構成自動化ツールの分野では、さまざまなオープンソースツールがひしめき合っている。この中で、独特な世界を切り開いているのがStackStormだ。Chief StormerのDmitri Zimine氏に、このツールの魅力について詳しく聞いた。
StackStormはどういう自動化ツールなのか
――StackStormを使った自動化構築の難しさについては、どう表現しますか？
誰に聞くかによって、難しさについての答えは変わってきます。これはStackStormにおける哲学を反映している部分でもあります。企業顧客は「難しい」と苦情を言います。これは、私がVMwareからOpenStackの世界に足を踏み入れた時に感じたことと似ています。一方、AnsibleやChefを使っている人たちなら、複雑さは同じ程度だと感じるでしょう。
――つまり、プログラミングに近いレベルですよね。
ええ、コードを書きます。YAMLを作り、Pythonやその他の言語でスクリプトを作ることになります。これはDevOpsツールにとって必要です。私は先ほど、DevOpsの世界で成功する条件の1つとしてオープンソースを挙げました。もう1つの条件は「Infrastructure as Code」です。全てのアーティファクトをコードとして表現できないのでは、従来型のエンタープライズ向けツールと変わりありません。つまり、設計上、従来の意味でのエンタープライズユーザーには使いにくいものとなっています。こうした人たちにとってはAnsibleが扱いにくいのと同様、StackStormも扱いにくいといえます。
一方、StackStormを使うと、従来型のエンタープライズツールにはできないようなことができます。例えばある顧客は社内向けのサービスカタログアプリケーションを、従来型の自動化ツールからStackStormに切り替えました。
これはもともと、Webポータルからのリクエストに応え、ITサービスをプロビジョニングするものです。時には50〜100台の仮想マシンを特定のネットワーク構成で作成し、社内の構成管理データベース（CMDB）に自動登録し、DNSに登録し、モニタリングを設定するなど、約200のステップで構成されていました。4カ所あるデータセンターに1カ所ずつ順に、直接仮想サーバクラスターを構築するようになっていました。
しかし、DevOpsに移行したことで、事情が変わりました。DevOpsでは、ローカルマシンで自動化スクリプトを構築し、コードをリポジトリに移してコードレビューを受けた後、ステージング環境でテストを受け、その後に本番環境へ移します。こうして確実に動くことが確かめられたStackStormスクリプトを使い、この企業の場合は4カ所のデータセンターへの環境構築を同時に、Puppetでやることにしました。これにより、欲しい環境を迅速・確実に構築できるようになりました。
DevOpsに移行すると、こうしたツールは必須になってくるのです。
――すると結局、「アプリケーション開発者がやりたいことを何でもやればいい」というタイプのDevOpsになるのではないですか？
私たちはStackStormの開発を通じて、これを利用するユーザー像（ペルソナ）を想定しました。それはアプリケーション開発者と運用担当者の中間に位置する人々です。アプリケーション開発者ではないが、Pearl、Python、Rubyなどを使ったスクリプティングに長けていて、インフラを深く理解していなければなりません。一般企業で考えれば、インフラの拡張や安定稼働にまつわる複雑さはアーキテクトに任せ、これをスクリプトで自動化することに集中する人々です。
――ネットワーク管理者の中には、コーディングが不得意な人もたくさんいます。こうした人たちはStackStormのようなツールに抵抗感を持つのではないでしょうか。
そうですね。非常に進歩的なネットワーク運用チームはDevOps的なマインドセットを持っています。しかし、ブロケードの顧客の大多数は一般的な企業で、スクリプトを書きたがらない従来型のネットワークエンジニアが多くいます。このため、StackStormのプラットフォーム上に、使いやすいパッケージを構築し、提供しています。従来型のネットワークエンジニアは、快適に感じられるレイヤで使い始めることができます。ネットワークの言葉で操作でき、コーディングは必要ありません。
ただし、私はこうした管理者の人たちが、最終的にはDevOpsの世界に移行してほしいと思っています。未来はDevOpsのアプローチにあります。クラウドに加え、ネットワーキングについてもコーディングする時代がやってくるのです。
――StackStormは、他の自動化ツール間をつなげることが得意なのは理解していますが、あらためてこれらとの役割分担を説明してください。
StackStormは「バッテリが付属している」ツールです。インフラに対してアクションを実行するのに他のツールは不要です。SSHコマンド、HTTPリクエストを簡単に発行できますし、Web Hooks、タイマーも使えます。
しかし、現実には、何の自動化も行われていない環境はほとんどありません。私たちの当初からの哲学は、ツールチェーンの一部になることです。使われているツールを代替するものではありません。例えばAnsibleとStackStormの組み合わせは非常によく使われています。
StackStormは2つの点でユニークです。1つはイベントドリブンな点です。「センサー」と「ルール」の組み合わせに基づいてアクションを確実に実行できます。Saltstackにも「ビーコン」というコンセプトがありますが、後から加わったもので、あまり使われていません。StackStormは、「イベントドリブン」を実現するために生まれました。
――つまり、「IF THIS〜」に基づいて何かを実行したかったら、StackStormを使ってくれということですね。
はい、他のどんなオープンソースツールにも同じようなことはできないと、強く思っています。
もう1つのユニークな点は、統合プラットフォームとしての機能です。コミュニティでは100以上の統合が行われています。非常に成熟したワークフローエンジンを備え、組織において「入り」と「出」の双方向で、センサーとアクションの適用ができます。異なるシステムをつなぎ合わせる糊のような役割を果たせます。
スクリプトで同じことをやろうとすると、信頼性に欠け、動作における透明性も失われ、文字列しか扱えません。StackStormはPower Shellに非常に近いとも表現できます。構造化されたJSONオブジェクトを、ワークフローエンジンが制御するロジックに基づいて、あるドメインから別のドメインへ運ぶことのできる、メッセージバス的な機能を果たします。処理の失敗が発生しても、その時点から再実行できます。
まとめると、「IF THIS〜」に従って処理を行いたい場合と、複数のビジネスドメイン間を統合を行いたい場合は、StackStormのスイートスポットだと言えます。
IoTやサーバレスコンピューティングにおける新たな可能性
――StackStormの面白い使われ方を教えてください。
例えば、あるスウェーデンのゲノムプロジェクトでは、ゲノム解析処理の複雑なワークフローを自動制御するために、StackStormを使っています。こうした普通ではない使い方は、StackStormの価値をあらためて認識させてくれます。
IoTは、これから面白い使われ方がされていきそうです。現在のところはホビープロジェクトが多く、StackStorm Exchangeに最初に登場したのはTeslaのクラクションを鳴らすというものでした。そのうちSlackを使って車を呼ぶとか、ガレージのドアを自動的に開けるといったプロジェクトが出てきました。
植物の水やりの自動化や一般的なホームオートメーションも進み始めています。「WeChatをGPSトラッキングとつなげた」という人もいます。このようにほとんどはホビーの域を出ませんが、今後IoTが成熟してくれば、本格的なプロジェクトが登場するでしょう。
もう1つ、私が個人的に大変興味深いと思っているのはサーバレスコンピューティングです。Apache OpenWhiskのWebサイトで説明を読むと分かりますが、イベント、トリガー、ルール、アクションで構成されています。StackStormと全く同じです。OpenWhiskはStackStormの2年後に登場しましたが、当初は非常に似通っていました。
私はあるパートナーと組んで、遺伝子アノテーションのサービス化を手伝っています。サーバレスコンピューティングに適した事例ですが、他のサーバレスのフレームワークではうまくいかないことが分かりました。例えば数日かかる処理がありますが、Amazon Lambdaでは5秒間の処理しかできません。規模も関係しています。
そこでStackStormとDocker Swarmを組み合わせてサーバレスフレームワークとして適用し、素晴らしい成果を得ることができました。当初は思いつきませんでしたが、今ではStackStormはサーバレスコンピューティングフレームワークの世界で、十分伍してやっていけるプレイヤーだと考えています。
Copyright © ITmedia, Inc. All Rights Reserved.