[社内勉強会]ワークフローエンジンdigdag研究&プロダクトF.O.Xに導入 CyberZ社内勉強会資料@201809

1. ワークフローエンジンdigdag研究し、
プロダクトF.O.Xに導入した
F.O.X moteki takahiro

2. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

3. Force Operation X(F.O.X)概要
レポーティング1
アプリ解析機能2
マーケット分析3
リターゲティング機能4
スマートフォン広告におけるマーケティング統合プラットフォーム(アドプラットフォーム)

4. F.O.X位置づけ
メディア連携数
1,300
計測端末数
1.2億台
導入アプリ数
6,500
F.O.X
サーバ
メディア
App Store スマホ
2. リダイレクト
1. 広告click
3. Install
4. 初回起動
5. 広告成果を連絡

5. F.O.X連携メディア
Facebook Mobile
Measurement Partner
Twitter Official
Partner
App Attribution
Partner

6. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

7. 背景: F.O.Xシステム全体像
計測サーバ
データ収集 処理(ETL/集計) 利用/分析
保存
ストレージ
分析アプリ
ケーション
計測ログ
ストレージ ストレージ
データパイプライン

8. 背景: F.O.Xシステム規模感
データ収集
8
最大30万リク
エスト/秒
処理(ETL/集計/保存) 分析/可視化
計測サーバ 休眠・復旧分析
アクション(イベント)分析
KPI分析
国別分析
ユーザー分析売上分析
プラットフォーム
総UU: 15億~
DAU: 7億~
query: 数千
/day(batch)
ストレージ
total data : 1PB
RDB
弊社 分析アプリケーション

9. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

10. 案外難しい処理(ETL)バッチ開発/管理

11. 課題
オペレーションが複雑
状態確認/管理しにくい
追加の開発コスト高

12. 課題(1): 状態確認/調査しにくい
svr001サーバのcron svr002サーバのcron
… svr011サーバのcron … svr0112サーバのcron
①バッチ
②バッチ
バッチ③
バッチ④
svr001サーバの②が動いてる間は①止まる, ③が動いたら② / ④は動かす
バッチ数百あったら??? -> 今何が動いていて、何が止まってるのかわからない
バッチ依存(依存関係)と呼ぶ

13. 課題(2): オペレーションが複雑
①バッチ
②バッチ
③バッチ
④バッチ
⑤バッチ
⑥バッチ
⑦バッチ
②障害発生
④障害発生
⑥障害発生
step1) AAAをkill
step2) BBB.shの実行引数変えてCCCまで実行
….
step8) …..
step1) AAAを動かしたままBBBをkill
step2) AAAをkill
….
step12) …..
step1) CCCを残り3回手動で実行
...
step5) DDDを実行
↑ バッチ7本の例...これがバッチ数百あったら???
最悪case = バッチの状態 × バッチ数 -> 1千リカバリ手順??
リカバリ手順

14. 課題(3): 追加の開発コスト高
● アラート発行をプログラム開発...
○ バッチコケた/バッチが時間内に終わらないアラート...
● リトライ制御をプログラム開発...
○ リトライ方式? リトライ回数?...面倒
● バッチインタフェース開発
○ リトライ時を考慮してゴリゴリ変数計算...
● データロード、S3データ取得 ETL基本処理の開発
○ DAO、JDBCロジック書いて... 面倒
長い道のり...

15. ワークフローエンジン
digdag導入

16. digdagとは?
依存関係が複雑な大量ジョブを良い感じにしてくれる
TresureData開発のOSS
● xxx.dig拡張子のファイルにジョブ定義をスゴイyml記載し実行
● スゴイyml javascript / python / rubyも書ける
● 実行 Web-UIとCUIで可能
スゴイyml(例

17. digdagの機能とは?
実行状態
可視化
アラート
実行制御
エラー
制御
バッチ
開発支援
バッチ
スケールサポート
高速化/
最適化

18. digdagどう使う?
xxx.dig
ローカルPCで
dig編集
digdag-devサーバ
デプロイ/実行
digdag-devサーバ上
で実行
xxx.dig xxx.dig
ローカルPC実行
ローカルPCで
dig編集
digdag-devサーバで
dig編集
デプロイして
digdag-devクライアン
ト実行
xxx.dig
ローカルPCで
dig編集
開発時
サクッと試した
いくらい

19. digdagアーキテクチャ設計/構築
digdagの検証
やったとこ(工数3~4ヶ月)
バッチ数 数千/day
データパイプライン設計/ETL置き換え

20. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

21. 解決
オペレーションが簡素
状態確認/管理しやすい
追加の開発コスト低

22. 解決(1): 状態確認/調査がしやすい
ジョブどこでコケ
たのか? わかる
コケたジョブの
ログにたどり着
ける
今何が動いてる
か? わかる

23. demo

24. 解決(2): オペレーションが簡素
ジョブがコケた
コケたジョブのみ
全部再実行
全ジョブの再実
行

25. demo

26. 解決(3): 追加の開発コスト低
並列実行
アラート実装
javascriptによ
る変数計算
これだけ
リトライ制
御
豊富なオペレー
タで開発レス

27. demo

28. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

29. 設計: アーキテクチャ
複数サーバで
バッチ分散
クラスタ

30. 設計: 耐障害性
● SPOFは0
● PostgreSQL以外はス
ケールアウト可
● 高可用性に向けて
○ task graceful
shutdown / restart
○ task permissive対応
○ task logのS3化

31. 設計: ワークフロー
● ディレクトリ分けすると思わ
ぬ罠があるので構成をテン
プレート化
● 新規に取り組みやすい
● プロジェクトのバッティング
防止

32. 運用: 効率化/サポート
デプロイテンプレート
ansibleロール
docbaseと動作再現可能なsample dig

33. 目次
● プロダクトF.O.X説明
● 背景
● 課題
● 解決
● 設計
● digdagに関して
○ 比較 / 市場動向 / 運用して

34. 他ツールと概要比較
type 言語型 GUI型 GUI分散型 DSL型 特化型 イベント型
tool Airflow /
Luigi
Rundeck /
Jenkins
Chronos /
Dkros
Digdag / Patriot /
Azkaban
Glue Job /
CloudCompo
ser / Argo
Stack Storm
pros * ワークフロー
の自由度高い
* 簡素なワー
クフロー構築
ラク
* 簡素なワーク
フロー構築ラク
* 性能スケール
する
* 再現性がある
* version管理出来
る
* 自由度はGUI型
>DSL型<言語型
* 特定条件下で
親和性が高い
* イベントドリブ
ンなワークフ
ロー構築可
cons * 簡素なもので
もプログラミン
グ必要
* 移植性低い
* version管理
しにくい
* 性能スケー
ルしにくい
* 移植性低い
* version管理し
にくい
* 定形処理以外の
動的ワークフロー
構築面倒
* マルチテナン
トしにくい
* observavility
的な情報少ない

35. 市場動向
● 日本Web系 digdag or airflow多い印象
○ 内製ワークフローエンジンもちらほや(kuroko2 / patriot)
● 日本SI系 JP1多い印象
● 海外はairflowが多く、digdagはほとんど使われてない印象
● 特化型のGlue Job / Cloud Composer / Argoがどう市場で伸び
ていくか気になる

36. digdagに関して: 運用して(要望系)
● 動的な依存関係が組みにくい
● requireオペレータ利用時、謎にCPU負荷上がる
● 各種オペレータの細かい設定
○ 例) s3_waitオペレータのタイムアウト欲しい
● WEB-UIもう少しリッチになると...

37. とはいえ完成度高い

38. おわり