僕らはStackStormをどう使うべきか / NTT TechConference #2 StackStorm

8/10 に NTT TechConference #2で発表した資料です。
https://ntt-developers.github.io/ntt-tech-conference/02/

Twitter Hashtag: #NTTTech

Transcript

1. Copyright© 2017 NTT TechnoCross Corporation 僕らはStackStormをどう使うべきか NTTテクノクロス株式会社 クラウド&セキュリティ事業部 萬治 渉 <manji.wataru@po.ntt-tx.co.jp>
2. Copyright© 2017 NTT TechnoCross Corporation 2 自己紹介 名前 萬治 渉 (Manji Wataru) 所属 NTTテクノクロス クラウド&セキュリティ事業部 業務 OpenStack, StackStorm, etc... 好物 ビール、日本酒、焼き茄子
3. Copyright© 2017 NTT TechnoCross Corporation 3 今回の概要 • StackStormってどんなもの？ • 他のWorkflow Engineとはどう違うの？ • 何をするときに使うべきなの？
4. 4 Copyright© 2017 NTT TechnoCross Corporation アジェンダ 1. どんなもの？ • StackStormとは • StackStormの特徴 2. StackStormがやるべきこと • そもそも自動化したい業務とは • 他製品との機能比較 • StackStormに任せるべきこと 3. ユースケース • 紹介 • 試してみたい人向け • 実例 4. おまけ(時間があれば) • 個人的に興味のある使い方 • NWCI
5. Copyright© 2017 NTT TechnoCross Corporation 5 StackStormとは？ イベントに応じた動作を実行、管理するためのOSSプラットフォーム “OOが起こったら、XXを実行する” Amazon Lambda Amazon Step Functions コンセプトがよく似てるサービス AWSで例えると
6. Copyright© 2017 NTT TechnoCross Corporation 6 WorkflowとAction OOを実行する、に入るのが「Workflow」や「Action」 • Workflow → 手順の項目と順序が記されたファイル。 YAML DSLで記述。 • Action → スクリプト bash, pythonなどで記述
7. Copyright© 2017 NTT TechnoCross Corporation 7 StackStormによるWorkflowの動作イメージ (かなり省略) Rule イベント Workflow Action Action Workflow Action Task Task Task Task Task Task ... イベントに応じた Workflowを起動 Workflow内のTaskとして 別のWorkflowを起動できる
8. Copyright© 2017 NTT TechnoCross Corporation 8 StackStormの特徴 (次項から解説) APIフレンドリー 大抵の操作はAPIで可能 JSONで返せるので外部連携も楽 実行契機を柔軟に設定できる ・Webhook ・WebUI ・CLI ・ファイル更新 ・Polling ・RabbitMQ Workflowの記述が楽 • Metadataによって Actionの引数定義などを把握できる • Workflowの形式の使い分け コードの再利用性が高い Action, Workflowの流用が楽 また、Packによって再配布が容易
9. Copyright© 2017 NTT TechnoCross Corporation 9 特徴1: APIフレンドリー 大抵の操作はAPIでできる • Action, Workflowの起動 • Rule, Action, Workflowの登録、参照 • Datastore(内部にあるkvs) への登録、参照、削除 • 認証 • etc... → 他のツール、システムとの連携が容易 詳しくは以下参照 https://api.stackstorm.com/
10. Copyright© 2017 NTT TechnoCross Corporation 10 特徴2: 実行契機を柔軟に設定できる ・Action, Workflowの起動 ・ファイル操作 ・チャットへの通知 など 。。。 Webhook Timer ファイル監視 Sensor
11. Copyright© 2017 NTT TechnoCross Corporation 11 特徴3: Workflowの記述が楽 metadataという仕組みによって、 実コードを読まなくてもActionやWorkflowの概要を把握できる # metadataの例 --- name: “hoge_ssh“ pack: test runner_type: "python-script" description: “sshで何かする" enabled: true entry_point: “ssh.py" parameters: port: type: “integer" description: “ssh port" required: true default: 22 • YAMLで記述する • ActionやWorkflowのコードとセットで 作成しなくてはいけない • 見れば 「何をするものなのか」 「何を与えればいいのか」 がおおよそ分かる
12. Copyright© 2017 NTT TechnoCross Corporation 12 特徴3: Workflowの記述が楽 実現したい手順によって、異なる記法を使い分けることができる 記法 メリット デメリット ActionChain • 記法がシンプルで、 覚えることが少ない • 成功/失敗による分岐しか サポートしていない • 条件分岐が不可 Mistral • 条件分岐が可能 • タスクの並列実行が可能 (fork, join) • ループ処理が可能 • 有料版(BWC)ではGUIに よるWorkflow作成が可能 • ActionChainより覚えることが 多い (YAQLなど) • 旧バージョンのst2では ASCII外文字の取り扱いに 難あり CloudSlang • Mistralとほぼ同じ • 市中に情報が少ない...
13. Copyright© 2017 NTT TechnoCross Corporation 13 特徴4: コードの再利用性が高い 既存のWorkflowやActionを別のWorkflowへ簡単に組み込める → metadataで定義された名前と引数をタスクに書くだけ PackをGitで管理可能、インポートもコマンド1つで可能 → 保守、再配布が楽
14. Copyright© 2017 NTT TechnoCross Corporation 14 イベントとそれに対応する実行手順の 管理ツールとして、かなりイケてる実装 ※個人の感想です
15. Copyright© 2017 NTT TechnoCross Corporation 15 じゃあ、何でもかんでもStackStormで 自動化すればいいの？ と聞かれると、そうでもないような気がする... イケてるとはいえ、ユースケース次第では Jenkinsとかの方が使いやすいのではないか？
16. Copyright© 2017 NTT TechnoCross Corporation 16 そもそも論: 開発、運用で自動化したいユースケース 開発&運用業務の中で、自動化したい業務手順(Workflow)は 大きく3つだと考えている • 開発: CI/CD → ビルド、テスト、デプロイ など • 開発&運用: 定型処理 → チケットの集計、ログ収集&蓄積、収集データのクリーニングなど • 運用: イベント対応処理 → 稼動中システムの障害対応など
17. Copyright© 2017 NTT TechnoCross Corporation 17 すべてにStackStormがハマるのか？が気になるので、 他のWorkflow Engineと機能比較して 「StackStormを使うべきユースケース」 について考えてみた
18. Copyright© 2017 NTT TechnoCross Corporation 18 Workflow Engineと呼ばれる製品たち • Apache Airflow (Apache) • Luigi (Spotify) • Digdag (Treasure Data) • Jenkins Pipeline (Jenkins) ... → 比較するには数が多いので、絞る Workflow Engineの定義: • タスクを実行順序に従って実行できること • タスクの実行順序とその結果を一連の処理 として管理できること
19. Copyright© 2017 NTT TechnoCross Corporation 19 比較対象の選定基準 前述の製品は、以下の2種類に分類できる • 汎用言語(Pythonなど)によってWorkflowを記述する • DSLでWorkflowを記述する StackStormは後者なので、後者にあたる製品と比較する。
20. Copyright© 2017 NTT TechnoCross Corporation 20 • いわずと知れた自動化ツールの定番 • 色んな拡張機能が揃っていて、周辺ツールとの連携に強み • Workflow管理機能として、Jenkins Pipelineがある • WorkflowはGroovy DSLで記述 比較するのはPipeline周り 調査で参考にした情報(2017/08/01): • Jenkins Pipeline: https://Jenkins.io/doc/book/pipeline/ • How to set current build result in Pipeline?: https://support.cloudbees.com/hc/en-us/articles/218554077-How-to-set-current-build-result-in-Pipeline-
21. Copyright© 2017 NTT TechnoCross Corporation 21 • 去年OSS化されたWorkflowエンジン • Treasure Data製品との連携機能が豊富 • サーバとして動作させなくても、ローカル環境で Workflowを実行することが可能 • WorkflowはYAML DSLで記述 調査で参考にした情報(2017/08/01): • Digdag: http://docs.digdag.io/ • Digdagによる大規模データ処理の自動化とエラー処理: https://www.slideshare.net/frsyuki/digdag-76749443
22. Copyright© 2017 NTT TechnoCross Corporation 22 StackStormとの機能比較 操作 WebUI ◦ ◦ ◦ CLI ◦ ◦ ◦ 実行契機 手動 ◦ ◦ ◦ 時間 ◦ ◦ ◦ Webhook ◦ × ◦ Workflow の機能 タスク返り値に よる分岐 △ できるが面倒 ◦ ◦ 引数付き実行 ◦ × ◦ 失敗箇所からの 再実行 × ◦ ◦ タスク並列実行 ◦ ◦ ◦ タスク分散実行 ◦ 実行ノード指定可能 △ 各ノードに分散される △ Runnerに分散される 管理 Workflowの ファイル分割 ◦ ◦ ◦
23. Copyright© 2017 NTT TechnoCross Corporation 23 Jenkins, digdagのユニークな機能 • ジョブ毎にWorkspaceを自動作成する • Git上のWorkflowファイルを 動的に取得して実行できる • Workflowを動作させるノードを指定する 記述が可能 • Workflowの実行結果を視覚的に表示できる • 無料でRBACができる • ローカルでWorkflowを実行可能 • 単体でWorkflowファイルのバージョン管理が 可能 • TreasureData, Embulkなどのデータ処理 ツールとの連携機能がデフォルトセット
24. Copyright© 2017 NTT TechnoCross Corporation 24 比較の結論 ユースケース Jenkins Digdag StackStorm CI/CD ◦ △ △ 定型データ処理 △ ◦ △ イベント対応処理 △ × ◦ ◦ = 機能的に実現可能かつ専用機能アリ △ = 機能的には実現可能だが、専用機能は無いor工夫が必要 × = 機能的に実現が難しい
25. Copyright© 2017 NTT TechnoCross Corporation 25 比較の結論 • Jenkinsはコードの自動ビルド、テストに向いてる ・自動で専用の作業ディレクトリを作ってくれるなど、 ビルド用Workflowの記述量を抑えられる仕組みがある。 ・Git上でWorkflowファイルを単体管理することができるので、 開発物に依存するビルド手順などをセットで管理できる。 ・ビルド、デプロイ、テストそれぞれについて、Ansibleなどを使わず 任意のノード上で実行できる
26. Copyright© 2017 NTT TechnoCross Corporation 26 比較の結論 • digdagは定時、定型的なデータ処理に向いてる ・大量データを捌くための外部アプリ連携機能 (TreasureData, Embulk)が標準搭載なので、 定期的なデータ処理をWorkflowとして表現しやすい。 ・失敗箇所からの再実行も可能なので、長大な処理に向いている。 ・「いつ実行するか」をWorkflow内に記述できるので、 実行タイミングと手順をセットで管理することに向いている。
27. Copyright© 2017 NTT TechnoCross Corporation 27 比較の結論 • イベント対応処理はStackStormに任せるべき ・Webhookなどで動的にWorkflowを実行できる ・パラメータ付きのWorkflowを管理できる ・タスクの返り値に応じた分岐などが標準機能で実現できる ...という特徴をすべて備えているのはStackStormのみ
28. Copyright© 2017 NTT TechnoCross Corporation 28 参考: 自動ビルドWorkflowの記述比較 vars: clone_dir: ‘/tmp/{{ action_contents.execution_id}}’ chain: - name: git_clone ref: git.clone parameters: source: ‘https://~’ ref: ‘master’ destination: ‘{{ clone_dir }}’ on-success: bundle_install - name: bundle_install ref: core.local parameters: cmd: ‘bundle install’ cwd: ‘{{ clone_dir }}’ node(server1){ stage ‘git clone’ git url: ‘https://~’ stage ‘bundle install’ sh: ‘bundle install’ } +git_clone: sh>: > tasks.git_clone.sh --src=‘https://~’ --dest=‘/tmp/${session_uuid}’ --ref=‘master’ +bundle_install: sh>: > /tmp/${session_uuid} bundle install Jenkins Pipelineが最も記述が短くなり、 意図をシンプルに表現できている
29. Copyright© 2017 NTT TechnoCross Corporation 29 ～今回のまとめ～ StackStormを「イベント対応処理」以外に使うと 逆に手間がかかる場合がある！ イベント対応処理には自信を持ってStackStormを使おう！
30. Copyright© 2017 NTT TechnoCross Corporation 30 代表的なイベント対応処理 → Auto-Remediation
31. Copyright© 2017 NTT TechnoCross Corporation 31 監視アラートに応じた自動復旧 (Auto Remediation) イベント = 監視基盤 (ELK, Zabbixなど)からのアラート やること = 所定の復旧作業&通知 監視基盤 監視 Ruleに従って所定の復旧手順 (Workflow)を流す どんなエラーを 拾ったらどういう webhookを飛ば すかは事前定義 状況、結果を通知
32. Copyright© 2017 NTT TechnoCross Corporation 32 Auto RemediationにおけるWorkflowの動作例 • ActiveなWebサーバが503を返した →・LBが正しく状態を拾っているかチェック ・プロセスの状態チェック ・プロセス再起動、疎通チェック ・サーバ再起動、疎通チェック ・sby機の起動 ・LBがsby機に振り分け開始しているかチェック (よい意味で)人間味のあるトラブルシュート、復旧が可能
33. Copyright© 2017 NTT TechnoCross Corporation 33 Workflowの記述例 それぞれの操作をActionとして抽象化しておけば、 書きやすく読みやすいコードになる chain: - name: block_ip ref: fw.block parameters: ip: ‘{{ ip }}’ phy_port: ‘{{ global }}’ on-success: get_ip_info - name: get_ip_info ref: ip.reverse_resolv parameters: global_ip: ‘{{ ip }}’ publish: whois: ‘{{ get_ip_info.stdout }}’ on-success: post_slack # 後略 例) 特定のアドレスからアクセスが集中 → ・FWを操作してアクセスを遮断 ・IPの逆引き情報などを管理者に通知
34. Copyright© 2017 NTT TechnoCross Corporation 34 Auto-Remediationを試してみたい人向け • StackStorm公式が設定例を載せてるので、気軽に試せる → Auto-remediation by example: handling out-of-disk-space. https://stackstorm.com/2015/10/05/auto-remediation-out-of-disk-space/ • 検証環境を作るのが面倒な方へ → Vagrantを使ってVirtualboxなどで立てるのがオススメ https://github.com/StackStorm/st2vagrant
35. Copyright© 2017 NTT TechnoCross Corporation 35 StackStormによるAutoRemediationの実例 • Auto-Remediation with StackStorm & Splunk → https://stackstorm.com/2016/10/21/auto-remediation-stackstorm-splunk/ • Event Driven Auto-Remediation with the Elastic Stack → https://stackstorm.com/2017/01/12/event-driven-auto-remediation-elastic-stack/ • Netflix: StackStorm-based Auto-Remediation – Why, How, and So What → https://stackstorm.com/2015/11/21/netflix-stackstorm-based-auto-remediation-why-how- and-so-what/
36. Copyright© 2017 NTT TechnoCross Corporation 36 おまけ: 興味のある使い方 Amazon Lambda Amazon Step Functions Step Functions = Workflowと考えたら、 Lambda = Rule + Actionに近い → Lambdaのようにシンプルなコード実行基盤を StackStormで実現できるのでは？ 冒頭に出した例
37. Copyright© 2017 NTT TechnoCross Corporation 37 おまけ: 興味のある使い方 = FaaS 既に実現されていて、OpenStack Summit Bostonで発表されてる Serverless on OpenStack with Docker Swarm, Mistral, and StackStorm https://www.openstack.org/videos/boston-2017/serverless-on-openstack-with-docker-swarm- mistral-and-stackstorm • StackStormとDockerで実現されていて、 OSS版Lambdaっぽい仕組み • どういうユースケースがあるか考え中。 使って嬉しいものを作りたい！
38. Copyright© 2017 NTT TechnoCross Corporation 38 TechConference内展示の紹介 StackStormを使って • NW機器操作の抽象化 • NW物理工事手順のコード化 • 設定確認の自動化 を実現する「NWCI」というNTT SICの取り組みについて、 Showcaseで展示中です。興味がある方は是非。
39. Copyright© 2017 NTT TechnoCross Corporation 39 以上