あのときのログ

思ったこと、経験したことを忘れないようにするためのメモ。

Workflow Engines Night 参加メモ

開催日：2017/6/7

場所：DMM.comラボ 六本木オフィス

『StackStorm ワークフローエンジンによる運用コスト・リスク低減の取り組み』

株式会社DMM.comラボ 大山 裕泰氏

  • StackStorm Contributor
  • StackStorm AWS maintainer

発表資料

digdagじゃなく別のWorkflowエンジンの話

運用者を悩ませる問題

  • ユーザ（社内）との折衝コスト（口頭、チケット、メールで依頼）
  • オペレーションコスト（多種多様なシステム環境、機器）
  • オペミスのリスク、熟練オペレータしか触れない、教育コスト高い
  • (確かに新人にLBは触らせないとかある…）

理想的な運用形態

  • 定型運用のAPI化
  • システムの適切な抽象化
  • ×個別機器を操作する ◯操作して得たい結果を機械に教える

StackStormとは

  • IFTTT x Workflow
  • センサーが反応するイベントを受けて、一定のルールでActionを実行
  • 例えばイベントに併せてリソースを増やす
  • VMを作るだけの単体タスクじゃなく、VM作る→Provisioning→DNS登録→ELBにぶら下げるなど一連のタスク

Stackstormのある環境

  • オペレーション用APIの提供
  • 知っている人誰かに聞いたり、ドキュメントを漁ったり(用意したり)しなくてもStackStormを見れば分かる
  • システムの抽象化（欲しい結果だけを指定する）
  • 運用の自動化（個別のシステム状況に応じた対応を機械的に実施）

StackStormが実現するであろう未来

  • 折衝業務を行うエンジニアの開放
  • オペレータの運用・学習コストの逓減
  • サービス運用リスクの削減

Q&A

  • スケジュール実行はどのように？
  • センサーからのイベントドリブンなので定期実行するのは可能
  • 定期実行の際に重複実行を避けたい、どうする？
  • 複数ノードに分散しているが、同じノードで同時に複数リクエスト来た場合のことは考慮されてない

参考資料

https://stackstorm.com/

http://qiita.com/unchemist/items/0e6425396ba1a1e6b43c

『JenkinsからDigdagへ日次バッチを移行して幸せになるお話』

株式会社DMM.comラボ 鈴木 翔太氏

発表資料

なぜDigdagなのか

  • 多数の日次バッチ
  • 所謂ETL
  • これまではJenkinsで運用
  • 問題
  • Jenkins依存
  • コードで管理できない
  • 失敗時のリトライが大変

  • 処理が時間依存

  • 課題解決のためにワークフローエンジン導入を検討

選定ポイント

  • ◎可用性
  • ◎スケーラビリティ
  • コード管理
  • 失敗したタスクからリトライ可能
  • 進捗確認ができるIF

構成

  • Digdag2台、サーバ兼クライアント
  • PostgreSQLサーバ2台(PgPool-II使って Active&Standby構成）

Workflow設計

  • 設定はYAML
  • 進捗状況が視覚的に分かるIFサイコー
  • タスクはRuby&Shを利用する事が多い

プラグイン自作

  • Slack通知を実現するdigdag-slackを作った
  • SLAの通知に利用

チーム間連携（＝システム間連携）

  • あっちのシステムでファイルができたらこれを実行、みたいなの
  • 時間に依存しない形で実行させたい
  • mog(go製CLIツール)を作成し提供
  • タスク名ベースでステータス確認可能に
  • ワークフローのスタート＆リトライも対応
  • Github公開していない（が、渋ってるわけじゃないので公開します）

まとめ

  • Jenkinsからの脱却
  • 全てコード管理可能に
  • コードで依存関係も表現
  • バッチ失敗時のリトライも楽ちん
  • mog CLIにより時間依存の処理を排除

『Treasure DataにおけるDigdagによる大規模データ処理の自動化とエラー処理』

トレジャーデータ株式会社 古橋 貞之

あまりメモ取らなかったけど詳しいレポートができてた

そもそもなぜDigdagを作ったか

  • あらゆる手作業を自動化するため
  • マルチクラウド、多数のミドルウェア、どんどん新しく出て来るのにエラーコードやハンドリング方法を全部覚えないといけないのか
  • シェルで複数ジョブを順次実行するには上から並べることになるが、エラーハンドリングやモジュール化での再利用などに問題がある

デモ

  • Treasuredata Workflowの画面で説明（ロゴが違う以外は一緒）
  • Timelineにタスクの進捗状況、経過時間がビジュアルに見える（すごい）
  • タスクを動的に増やせる
  • ループタスクも書ける

使用事例紹介

LT『Digdagを使ってみて便利だったとこ、はまったとこ』

株式会社VASILY 塩崎 健弘

発表資料

IQONを提供してる（若い女性ターゲットのファッショなプリ）

  • クローラを開発してcronでジョブ管理
  • 複数クローラのジョブを並列にcron定義
  • 30分毎に実行
  • でも30分で終わらなかったら？重複実行は？
  • ハンドリングつらい
  • Digdagは設定ファイルがシンプル
  • AirflowやLuigiとくらべて自由度低い（高い自由度は不要、複雑なジョブができちゃうから）
  • dockerサポート嬉しい

  • 一時ディレクトリを切って実行してくれるので他のタスクからの影響を最小化できる

  • pythonのバージョンでハマった

  • py>:オペレータはpythonコマンドを呼び出すが、OSによってバージョンが2で呼ばれる
  • python3のdockerイメージを使用することで解決

  • ruby(rb)でも同じ問題が

  • 一時ファイルの受け渡し

  • 一時ディレクトを毎回ジョブ毎に切ってくれるのでまとめて読めない
  • 一時ファイルはS3に書いて読み出し