摆社内勉强会闭ワークフローエンジン诲颈驳诲补驳研究&补尘辫;プロダクト贵.翱.齿に导入
?
0 likes?2,264 views
摆社内勉强会闭ワークフローエンジン诲颈驳诲补驳研究&补尘辫;プロダクト贵.翱.齿に导入 CyberZ社内勉強会資料@201809
摆社内勉强会闭ワークフローエンジン诲颈驳诲补驳研究&补尘辫;プロダクト贵.翱.齿に导入
- 2. 目次 ● プロダクトF.O.X説明 ● 背景 ● 課題 ● 解決 ● 設計 ● digdagに関して ○ 比較 / 市場動向 / 運用して
- 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に関して ○ 比較 / 市場動向 / 運用して
- 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ロジック書いて... 面倒 長い道のり...
- 16. digdagとは? 依存関係が複雑な大量ジョブを良い感じにしてくれる TresureData開発のOSS ● xxx.dig拡張子のファイルにジョブ定義をスゴイyml記載し実行 ● スゴイyml javascript / python / rubyも書ける ● 実行 Web-UIとCUIで可能 スゴイyml(例
- 20. 目次 ● プロダクトF.O.X説明 ● 背景 ● 課題 ● 解決 ● 設計 ● digdagに関して ○ 比較 / 市場動向 / 運用して
- 23. demo
- 25. demo
- 27. demo
- 28. 目次 ● プロダクトF.O.X説明 ● 背景 ● 課題 ● 解決 ● 設計 ● digdagに関して ○ 比較 / 市場動向 / 運用して
- 30. 設計: 耐障害性 ● SPOFは0 ● PostgreSQL以外はス ケールアウト可 ● 高可用性に向けて ○ task graceful shutdown / restart ○ task permissive対応 ○ task logのS3化
- 31. 設計: ワークフロー ● ディレクトリ分けすると思わ ぬ罠があるので構成をテン プレート化 ● 新規に取り組みやすい ● プロジェクトのバッティング 防止
- 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. おわり