Workflow Engines Night https://atnd.org/events/88470 #workflowenginesnight

LT.md

とあるマーケティング部隊でのdigdagの活用事例

お前、誰よ

• よしだ

  • twitter: @grimrose

• とある人材紹介会社のマーケティング部門のデータエンジニア

• 好きな言語: Groovy

• 好きなIDE: IntelliJ IDEA

普段の仕事

• 事業KPIの可視化を行うためのWebアプリケーションの設計から運用
• Scalaを使って日次や月次の集計バッチを実行するアプリケーションの作成
• 帳票や外部APIなどからデータベースへデータを投入するツールの作成
• 部門の日常業務を改善するためのちょっとしたツールの作成

digdag導入に至る経緯

Job Schedulerを利用中。

全てをJob Schedulerに任せるのが難しくなってきた。

XMLを人間が管理するのは難しい。

ローカルで試せないので、本番で試行錯誤。

Job Scheduler Pros and Cons

Pros

• 日本語化対応済

• インストールが簡単

• GUIでジョブの定義などが作れる

  • ただし、XMLで吐き出される

• ジョブの実行にjavascriptやshellscriptが使える

  • ただし、XMLのCDATAに書くので、動かすまで分からない

Cons

• ジョブ、フロー、スケジューリング設定ファイルがXML

• RESTのリクエストのbodyがXML

• 公式ドキュメントがXML

  • 新しいドキュメントはJIRAに移行

• Agentを使えば複数台で実行可能だが、無償版は1台のみ

• 標準出力にログを出しすぎるとエラー扱いされる

• 標準エラーに出力されるとエラー扱いされる

  • エラーじゃないのに標準エラーに出力するとエラー扱いに
  • ignore_stderr のオプションで回避出来るが、exit codeだけで判定する必要がある

移行中

スケジューリングはJob Schedulerへ。ワークフローの定義はDigdagへ。

Digdagはlocal modeで動かしています。

Macと本番環境でpararellの同時実行数が違うので、digdagのconfigにagent.max-task-threads=Nを設定して実行してました。

v0.9.13以降は、digdag run (local mode) で並列実行数を制御するにある通り コマンドオプションで渡せるようになるそうです。

Digdag Pros and Cons

Pros

• ymlなのでsyntaxのサポートが効きやすい

• 既存のshファイルをそのままsh operatorに渡せる

• プログラマブルにしたければ、rb operatorかpy operatorを使えばいい

• embulkと組み合わせて -> とあるマーケティング部隊でのembulkの活用事例

• includeがあるおかげで、ジョブやタスクの粒度を調整しやすい

Cons

• sh operatorのstdoutもログに出せるようにしてほしい

• rb operator の実行環境が固定

• サーバーにインストールされているrubyに依存したくない

  • dockerが使えない環境なので、[feature-request] rb operator supports bundler #318が実現されると嬉しい

• operatorでエラーになっても原因が分かりにくい

  • エラーになったときのタスク名をerrorオブジェクトに持ってほしい

今後

Digdagもserver, client, uiの構成で試したい。

また、より良いワークフローライフを夢見て、以下のプロダクトも検証中。

• Apache Airflow
• AWS Step Functions
• AWS Data Pipeline

まとめ

ローカルへの導入が簡単なので、直ぐに試せたのが良かった。

cronでcrontab -rで設定をふっ飛ばしたことがある人、ログを/dev/nullに捨ててる人にこそおすすめしたい。

local modeがあるおかげで、既存のシステムに組み込むことが出来てよかった。