Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

StackStormで変わる運用

StackStormで変わるシステム運用と活用事例 第1回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 本連載では、2017年3月23日に来日講演を行ったStackStorm CTO Dmitri Zimine氏の発表を踏まえ、StackStormがどういった形態のシステム運用に対し、どのような効果をもたらすかを解説します。また、実際にStackStormを利用されているNTTテクノクロス、インターネットマルチフィード、そしてDMM.comラボのStackStormの利用事例と、どのような効果があったか(効果を見込んでいるか)を紹介します。本記事が、システム運用に携わる人にとってStackStormがどのような運用効果をもたらすか、理解する手助けになれば幸いです。また、運用改善のソリューションはStackStorm以外にさまざまなものが存在しますが、他のソリューションを比較検討する際の判断材料としても本記事がお役に立てると思います。

StackStormで変わる運用

 2016年5月にStackStormを買収したBrocade Communications Systems, Inc. (以下「Brocade」)はStackStormを「ネットワーク・オートメーション・プラットフォーム」と呼んでいます(その後Brocadeを買収したBroadcom Ltd.が、StackStormを含むネットワーク部門をExtreme Networks, Inc.に売却)。この他にも「ワークフローエンジン」や「運用自動化ツール」などといった呼び方でStackStormを紹介するブログエントリなどが多数存在します。

 それぞれが注目する特徴ごとにさまざまな呼び方をしていますが、StackStorm CTOのDmitri Zimine氏は、StackStormの本質は「IFTTT for DevOps」だと語っています(固有名詞として「IFTTT」というサービスがありますが、ここでは一般名詞としての「IFTTT」を想定しています)。

 以下では「IFTTT」と「DevOps」の概念を解説します。これらの理解を通じて、StackStormの本質を紐解いて行きます。

IFTTTについて

 「IFTTT(読み:イフト)」という単語は「IF This Then That」の略語で、あるシステムからの入力(イベント)に対して、全く別のシステムへ出力(アクション)するという考え方を表します。

図1 IFTTT概要
図1 IFTTT概要

 IFTTTを実現する一例として、図1の上段のGitHub/JenkinsによるCI(Continuous Integration)、 CD(Continuous Delivery)がソフトウェア開発者にとって、なじみ深いと思います。

 StackStormはStackStorm Exchangeがサポートするさまざまなシステム間で、相互にIFTTTを実現する仕組みを提供します。例えば、仮想基盤のイベントに対して、ロードバランサに対するオペレーションを行ったり、IaaSクラウドにおけるリソースの変更に伴い、Excelを更新するといった処理(またはそれらの組み合わせ)をYAML形式のファイルで記述することができます。

 これにより、複数のシステムに跨る複雑なオペレーションを統一的に処理することができるため、多種多用なシステムの管理・運用コストを低減できると見込んでいます。

DevOpsについて

 DevOpsは既にバズワードとなって久しく、「DevOpsを正しく理解しビジネスの価値を高める(中山 貴尋[著])」など多数の解説があります。

 一般的に「DevOps」とは、何がしかの情報サービスに関わる人間を開発者(Developer)と運用者(Operator)に分類し、それぞれの職責を「サービスに対する機能開発によるビジネス価値の向上」と「サービスの継続稼働によるビジネス価値の向上」とした場合、それぞれの仕事がお互いのリスクになる構造に対して、アジャイル開発などの技法や各種ツールを用いて、お互いのリスクを最小化しながら目的(ビジネス価値の向上)を実現する取り組みを表します。

 冒頭で示した記事で紹介されている「DevOps導入指南 Infrastructure as codeでチーム開発・サービス運用を効率化する」でも、DevOpsは

 Dev(開発)とOps(運用)が密に協調・連携して、ビジネス価値を高めようとする働き方や文化(「Chapter1-1:DevOps登場の背景」より抜粋)

と解説されています。

 注意していただきたいのは「DevOps」が成立する対象は必ずしも「開発者(Dev)」と「運用者(Ops)」だけではないことです。「DevOps」の本質は、それぞれの役割が局所最適化した組織・人同士において、それぞれが連携して全体最適(ビジネス価値の向上)を図ることなので、大局的な利害が一致する組織・人同士であれば、立場の名称に関係なく「DevOps」は成立すると考えられます。ここでStackStormがどのように「DevOps」を実現するかの一例を簡単にご紹介します。

 次の図2は何がしかのビジネスを支えるシステム(System)と、システムを管理・運用するチーム(Team)、及びそれぞれのシステムを利用するユーザー(User)を表しています。

図2 一般的なシステムの運用
図2 一般的なシステムの運用

 ここではユーザーが業務を効率的に行うためにそれぞれのシステムを利用し、各チームはそれらのシステムを維持し、ユーザーに提供する役割を負っていると仮定します。

 チームはユーザーに対してシステムの存在を周知し、システムの使い方を示したマニュアルを作成します。

 しかし、チームによる周知不足のためユーザーがシステムについて認知していない場合(System-A)や、マニュアルがないなどの理由でシステムの使い方がわからない場合(System-C)には、ユーザーはそれらのシステムを利用できません。

 またユーザーがシステムを認知し、使い方を把握していたとしても、複数のシステムを利用する場合には、ユーザーはそれぞれのシステムの使い方を覚えなければなりません。

 これに対しStackStormは、それぞれのシステムを抽象化し、ユーザーに対して全てのシステムを統一的に扱えるインターフェイスを提供します。

図3 StackStormを活用したシステムの運用
図3 StackStormを活用したシステムの運用

 StackStormによるシステムの抽象化により、システムを運用する各チームがシステムの各機能をStackStormに登録することで、全てのユーザーが全てのシステムの機能を認知・利用できるようになります。

 システムを利用するユーザーにとっては、全てのシステムを統一した方法で横並び(システムごとの使い方の差異をほとんど意識せず)に利用することができるため、より効率的に業務ができると考えられます。

 システムを提供するチームにとっては、システムのオペレーションをStackStormに統合することによってユーザー周知のための作業コストが減り、またインターフェイスを統一化させることによって、使い方を説明するための作業コストも減らすことができます。

 このように、ユーザーとチームの双方がStackStormを共通認識として持つことで、機能の追加・利用・フィードバックのサイクルをスムーズに循環させ、冒頭で解説した「DevOps」を実現できると考えられます。

まとめ

 StackStorm CTOのDmitri Zimine氏が語った「IFTTT for DevOps」が何を意味するかについて解説しました。ここまでの内容で、多種多様なシステムを組織的に運用する場面でStackStormが効果を発揮しそうだということを理解いただけたかと思います。

 次回は、各社がどのようにStackStormを利用しているかの事例を紹介します。



  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 大山 裕泰(株式会社DMM.comラボ)(オオヤマ ヒロヤス)

    DMM.com ラボ所属ソフトウェアエンジニア。アリエル・ネットワーク株式会社、グリー株式会社を経て現在に至る。最近は主にインフラ基盤の構築、運用、機能開発を行う。共著書に「次世代ネットワーク制御技術 OpenFlow入門」がある。

バックナンバー

連載:StackStormで変わるシステム運用と活用事例
All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5