Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Digdagを導入してみて

B6d9eb9a3825f15c84b5e7588c56a405?s=47 DMM.com
February 15, 2018

 Digdagを導入してみて

PLAZMA OSS Day: TD Tech Talk 2018 (https://techplay.jp/event/650389)
の資料となります。

−−−
DMM.comラボ ビッグデータ部ではETLをはじめとしたバッチ処理をDigdagを利用して行っています。 今回は実際の現場においてDigdagをどのように活用しているかをはじめとし、導入により改善できたことや運用面での取り組み(e.g. 監視…etc.)についてご紹介しました。

B6d9eb9a3825f15c84b5e7588c56a405?s=128

DMM.com

February 15, 2018
Tweet

Transcript

  1. DMM.comラボ ビッグデータ部 鈴木 翔太 2018/02/15 @ PLAZMA OSS Day: TD

    Tech Talk 2018 #tdtech Digdagを導入してみて
  2. © DMM.comラボ 自己紹介 データ分析基盤の開発・運用 ミドルウェアが好き Presto / Digdag 導入 Digdag

    へも (…チョットだけ) Contribute 推しPR: digdag#664 mog / digdag-go-client など 趣味で細々と…開発中… 2 鈴木 翔太 DMM.comラボ システム本部 ビッグデータ部 Github: szyn / Twitter: @i_szyn
  3. © DMM.comラボ アジェンダ 3 はじめに Digdagを導入してみて 活用事例 運用について 現状の課題 今後の展望

  4. © DMM.comラボ 4 はじめに Digdag導入に至った背景とシステム構成

  5. © DMM.comラボ 背景 - なぜDigdagなのか? - 5 移行前は Jenkins でバッチを運用

    - 当時の課題 - Jenkins依存 ※1 時間依存の処理 ※2 処理フローをコードで管理できていない 各データソースの依存関係の認識が難しい ※1) 日次バッチ/ CI / デプロイ等に利用し、当時チーム管轄のジョブ数だけで 約200 (!) ※2) 依存ジョブは毎日大体4時くらいには終わっているし、5時から後続ジョブをスタート…など
  6. © DMM.comラボ ワークロードをリプレイスするプロジェクトが発足 先述の課題が解決できるワークフローエンジンを選定 検証 & 本番環境導入へ!その後、事例紹介 ↓ 2017/06/07『Digdagへ日次バッチを移行して幸せになるお話』 背景

    - なぜDigdagなのか? - 6
  7. © DMM.com Group Digdagとは? 7 ref: Digdag - Open Source

    Workflow Engine for the Multi-Cloud Era https://www.digdag.io EmbulkとDigdagとデータ分析基盤と https://www.slideshare.net/ToruTakahashi4/embulkdigdag Digdagによる大規模データ処理の自動化とエラー処理 https://www.slideshare.net/frsyuki/digdag-76749443 Treasure Data が開発するワークフローエンジン SIMPLE, OPEN SOURCE, MULTI-CLOUD WORKFLOW ENGINE 基本機能 タスクの順次実行 ワークフローをコード (YAMLベースのDSL) で管理 スケジュール実行 エラーハンドリング リトライ機能 (特にリジューム) 高速化 タスクの並列実行 複数サーバでタスクの分散実行
  8. © DMM.comラボ X システム構成 オンプレミスで運用 サーバ / クライアント構成 構成管理: Ansible

    DBはPostgreSQL pgpool-Ⅱ も同サーバに ビッグデータ部におけるDigdag • ruby / python • hadoop client ※ • mog API & Scheduler & Executor ※ hadoop / hdfs / beeline / sqoop
  9. © DMM.comラボ 8 システム構成 オンプレミスで運用 サーバ / クライアント構成 構成管理: Ansible

    DBはPostgreSQL pgpool-Ⅱ も同サーバに ビッグデータ部におけるDigdag ※ hadoop / hdfs / beeline / sqoop 4 Core 20 GB 60 GB CPU Mem Disk • ruby / python • hadoop client ※ • mog API & Scheduler & Executor
  10. X Copyright © since 1998 DMM All Rights Reserved. Golang製

    Digdag CLI (※ 非公式) 特定の プロジェクト / ワークフロー / セッション / タスク の ステータス確認 ができる ワークフローの スタート & リトライ 別ホストに対しても実行可能 他システムとの連携ができるように Githubにて公開中 (https://github.com/szyn/mog) mogについて 9
  11. © DMM.comラボ Project  Workflow Session  3秒スリープするタスクを用意 上記タスク (+test+step1) の完了待ちをする場合 10

    mog 利用例 +step1: sh>: sleep 3 : sample : test : daily
  12. © DMM.comラボ 11 タスクが正常終了すると、 JSONが返却 コマンドの exit-status = 0 1秒毎に取得

    コマンド実行 { "id": "4", "fullName": "+test+step1", "parentId": "3", "config": { "sh>": "sleep 3 }, "upstreams": [], "state": "success", "exportParams": {}, "storeParams": {}, "stateParams": {}, "updatedAt": "2018-01-30T08:12:02Z", "retryAt": null, "startedAt": "2018-01-30T08:11:52Z", "isGroup": false } mog polling status --interval 1 \ --project sample \ --workflow test \ --session daily \ +test+step1 INFO[0003] task `+test+step1` state is running INFO[0003] state is not success. waiting 1 sec for retry... INFO[0006] task `+test+step1` state is running INFO[0006] state is not success. waiting 1 sec for retry... INFO[0009] task `+test+step1` state is running INFO[0009] state is not success. waiting 1 sec for retry... $
  13. © DMM.comラボ 12 導入してみて 良くなったところ / 改善したところ

  14. © DMM.comラボ 13 良くなった点はどこですか? ジョブの依存関係が分かりやすい 2 ワークフローの見通しが良くなった 3 Web UIが分かりやすい

    4 各タスクの実行時間が分かりやすい 5 コードベースでの管理 6 運用が楽になった チームメンバーにアンケートを実施
  15. © DMM.comラボ 14 +task: +sleep_5sec: sh>: sleep 5 +sleep_3sec: sh>:

    sleep 3 +sleep_1sec: sh>: sleep 1 serial.dig
  16. © DMM.comラボ 15 parallel.dig +task: _parallel: true +sleep_5sec: sh>: sleep

    5 +sleep_3sec: sh>: sleep 3 +sleep_1sec: sh>: sleep 1
  17. © DMM.comラボ 16 活用事例 Digdag at Big Data Department

  18. © DMM.comラボ 17 ビッグデータ部における Digdag 160 workflows 60 schedules 1900

    tasks / day dig
  19. © DMM.comラボ 18 1. ETLバッチ 2. API向けバッチ  3. BI向けバッチ ビッグデータ部における

    Digdag 現状3つのプロジェクトが存在 (2018/02 時点) ※ call されるワークフローも含んだ数字 : 117 workflows ※ : 31  workflows : 11  workflows ※
  20. © DMM.comラボ 1. ETLバッチ 集計頻度: Daily / Monthly Hadoopに対するETL処理 19

    Extract RDBMSから データ取得処理 Transform 取得した データ加工処理 Load DWH / Data Mart へ データ転送
  21. © DMM.comラボ 20 1. Extract 内製データ収集ツール実行 Sqoop import (MySQL to

    Hive) 2. Transform Hiveクエリによる集計 ※ MapReduceはDigdag ServerではなくHadoop Clusterで 分散実行されるためリソース周りは安心 3. Load 各種集計結果を DWH/S3/MariaDB に転送 Hadoop Client Haddop ClusterへCLI (sqoop / beeline / hdfs) でアクセス
  22. © DMM.comラボ 2. API向けバッチ 21 Polling ETL処理の終了待ち ※ 必要な場合 Aggregation

    Prestoへクエリ実行 Create Table As Select~ (CTAS) Distribution 集計結果がDBに保存され APIから参照される 集計頻度: Hourly / Daily 基本的にETL処理したデータを元に集計
  23. © DMM.comラボ 22 1. Polling mog を利用し、 集計に必要なETLタスクのステータスが success になるまで待機

    2. Aggregation 集計バッチ CLI 実行 (Golang) Prestoで集計処理を行いCTASで集計結果を MariaDBに書き込み 3. Distribution REST API で集計結果を返却 mog 集計バッチ CLI 実行
  24. © DMM.comラボ 23 運用について Monitoring / CI

  25. © DMM.comラボ 24 Monitoring Digdag における 監視

  26. © DMM.comラボ Digdag Server JMX 監視 (Heap Size / MetaSpace

    / GC / Threads …) Web 監視 (/api/projects にHEADリクエストし200かチェック) PostgreSQL / pgpool-Ⅱ pg_monz (http://pg-monz.github.io/pg_monz) を利用 Steaming Replication / pgpool-Ⅱ クラスタの稼働状況 Monitoring - Zabbix 25 これまでの障害件数 : 0
  27. © DMM.comラボ Zabbixによる監視 (Digdag Serverの一部抜粋) 26 ※ 上記は Grafana で表示したもの

  28. © DMM.comラボ Digdag ワークフロー運用時に心がけていること 定期実行するものは必ずSLAを設定し通知 ワークフローが増えてくると、 全てが正常に動いているかどうか確認は難しいため SLAにひっかかるようになったら改善を図る Monitoring -

    Digdag 27
  29. © DMM.comラボ 28 CI Digdag における CI への取り組み

  30. © DMM.comラボ Digdagはワークフローの push 時などにバリデーションがあり、 動かないワークフローはリリースできないようになっている しかし、2つの悩みがあった… なぜCIをするのか? 29

  31. © DMM.comラボ 30 悩み ① 重複タスク +task: sh>: +task: sh>:

    error: Validating project failed workflow xxxx Duplicated keys: [+task] (model validation) タスク名 (+task)が 重複してしまっている
  32. © DMM.comラボ 31 悩み ② 異なるインデント インデントが微妙に異なる Digdagとしてはエラーにならないが… なるべく統一してキレイに保ちたい! 見落としがち

    & レビューで指摘し辛い +task1: sh>: +task2: sh>:
  33. © DMM.comラボ 動かないものをmasterへマージしたくない! ワークフローの品質向上 細かなミスを防ぐ仕組みが欲しい… モチベーション 32

  34. © DMM.comラボ CircleCI を使って… 1. digdag check 実行 digdag check

    コマンドで動かないワークフローを検知 2. yamllint による 静的解析 digファイルも YAML なので… yamllint を利用し 重複するキー / 空の値 / インデント違い などを解析 reviewdog でPRにコメントするように + EditorConfig も導入 考えた解決策 33
  35. © DMM.comラボ yamllint × reviewdog 重複するキー (+task) があった場合など、PRにコメントしてくれるように 例: yamllintによる静的解析

    34 ref. https://github.com/szyn/ossday-digdag/pull/1
  36. © DMM.comラボ 35 現状の課題 運用している中で出てきている課題

  37. © DMM.comラボ 課題 36 Operator 関連 sh> に頼りがち (クラウド関連のOperator使いたい…) emr>

    でスポットインスタンスが利用できない Web UI 関連 過去に辿れるセッション数が現状 100 固定 ※ REST API での仕組みはありそう 通知関連 digdag-slack を利用し通知しているが改善が必要   具体的には digdag issue (#669) で議論されている
  38. © DMM.comラボ 37 今後の展望 どうしていきたいか (๑• ̀ ŷ• ́ )و✧

  39. © DMM.comラボ やろうと思っていること 38 sh> からの脱却 AWS (EMR / Athena

    / Glue) の Operator使いたい! 通知周りの改善 digdag issue (#669) の対応を検討 監視周りの強化 Zabbix → Prometheus へ Web UI周りの改善
  40. © DMM.comラボ X +plazma_oss_day: +talk_by_szyn: finally>: Thanks! ※ finally> は実際には存在しません