Digdagを導入してみて

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

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

Transcript

1. DMM.comラボ ビッグデータ部 鈴木 翔太
   2018/02/15 @ PLAZMA OSS Day: TD Tech Talk 2018
   #tdtech
   Digdagを導入してみて
   

   View Slide

2. © DMM.comラボ
   自己紹介
   データ分析基盤の開発・運用
   ミドルウェアが好き
   Presto / Digdag 導入
   Digdag へも (…チョットだけ) Contribute
   推しPR: digdag#664
   mog / digdag-go-client など
   趣味で細々と…開発中…
   2
   鈴木 翔太
   DMM.comラボ システム本部 ビッグデータ部
   Github: szyn / Twitter: @i_szyn
   

   View Slide

3. © DMM.comラボ
   アジェンダ
   3
   はじめに
   Digdagを導入してみて
   活用事例
   運用について
   現状の課題
   今後の展望
   

   View Slide

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

   View Slide

5. © DMM.comラボ
   背景 - なぜDigdagなのか？ -
   5
   移行前は Jenkins でバッチを運用
   - 当時の課題 -
   Jenkins依存 ※1
   時間依存の処理 ※2
   処理フローをコードで管理できていない
   各データソースの依存関係の認識が難しい
   ※1) 日次バッチ/ CI / デプロイ等に利用し、当時チーム管轄のジョブ数だけで 約200 (!)
   ※2) 依存ジョブは毎日大体4時くらいには終わっているし、5時から後続ジョブをスタート…など
   

   View Slide

6. © DMM.comラボ
   ワークロードをリプレイスするプロジェクトが発足
   先述の課題が解決できるワークフローエンジンを選定
   検証 & 本番環境導入へ！その後、事例紹介 ↓
   2017/06/07『Digdagへ日次バッチを移行して幸せになるお話』
   背景 - なぜDigdagなのか？ -
   6
   

   View Slide

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) で管理
   スケジュール実行
   エラーハンドリング
   リトライ機能 (特にリジューム)
   高速化
   タスクの並列実行
   複数サーバでタスクの分散実行
   

   View Slide

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

   View Slide

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
   

   View Slide

10. X
    Copyright © since 1998 DMM All Rights Reserved.
    Golang製 Digdag CLI (※ 非公式)
    特定の プロジェクト / ワークフロー / セッション / タスク の
    ステータス確認 ができる
    ワークフローの スタート & リトライ
    別ホストに対しても実行可能
    他システムとの連携ができるように
    Githubにて公開中 (https://github.com/szyn/mog)
    mogについて
    9
    

    View Slide

11. © DMM.comラボ
    Project　
    Workflow
    Session　
    3秒スリープするタスクを用意
    上記タスク (+test+step1) の完了待ちをする場合
    10
    mog
    利用例
    +step1:
    sh>: sleep 3
    : sample
    : test
    : daily
    

    View Slide

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...
    $
    

    View Slide

13. © DMM.comラボ
    12
    導入してみて
    良くなったところ / 改善したところ
    

    View Slide

14. © DMM.comラボ
    13
    良くなった点はどこですか？
    ジョブの依存関係が分かりやすい
    2 ワークフローの見通しが良くなった
    3 Web UIが分かりやすい
    4 各タスクの実行時間が分かりやすい
    5 コードベースでの管理
    6 運用が楽になった
    チームメンバーにアンケートを実施
    

    View Slide

15. © DMM.comラボ
    14
    +task:
    +sleep_5sec:
    sh>: sleep 5
    +sleep_3sec:
    sh>: sleep 3
    +sleep_1sec:
    sh>: sleep 1
    serial.dig
    

    View Slide

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

    View Slide

17. © DMM.comラボ
    16
    活用事例
    Digdag at Big Data Department
    

    View Slide

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

    View Slide

19. © DMM.comラボ
    18
    1. ETLバッチ
    2. API向けバッチ　
    3. BI向けバッチ
    ビッグデータ部における Digdag
    現状3つのプロジェクトが存在 (2018/02 時点)
    ※ call されるワークフローも含んだ数字
    : 117　workflows ※
    : 31　 workflows
    : 11　 workflows ※
    

    View Slide

20. © DMM.comラボ
    1. ETLバッチ
    集計頻度: Daily / Monthly
    Hadoopに対するETL処理
    19
    Extract
    RDBMSから
    データ取得処理
    Transform
    取得した
    データ加工処理
    Load
    DWH / Data Mart へ
    データ転送
    

    View Slide

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) でアクセス
    

    View Slide

22. © DMM.comラボ
    2. API向けバッチ
    21
    Polling
    ETL処理の終了待ち
    ※ 必要な場合
    Aggregation
    Prestoへクエリ実行
    Create Table As Select~
    (CTAS)
    Distribution
    集計結果がDBに保存され
    APIから参照される
    集計頻度: Hourly / Daily
    基本的にETL処理したデータを元に集計
    

    View Slide

23. © DMM.comラボ
    22
    1. Polling
    mog を利用し、
    集計に必要なETLタスクのステータスが
    success になるまで待機
    2. Aggregation
    集計バッチ CLI 実行 (Golang)
    Prestoで集計処理を行いCTASで集計結果を
    MariaDBに書き込み
    3. Distribution
    REST API で集計結果を返却
    mog
    集計バッチ
    CLI 実行
    

    View Slide

24. © DMM.comラボ
    23
    運用について
    Monitoring / CI
    

    View Slide

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

    View Slide

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
    

    View Slide

27. © DMM.comラボ
    Zabbixによる監視 (Digdag Serverの一部抜粋)
    26
    ※ 上記は Grafana で表示したもの
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. © DMM.comラボ
    30
    悩み ①
    重複タスク
    +task:
    sh>:
    +task:
    sh>:
    error: Validating project failed
    workflow xxxx Duplicated keys: [+task]
    (model validation)
    タスク名 (+task)が
    重複してしまっている
    

    View Slide

32. © DMM.comラボ
    31
    悩み ②
    異なるインデント
    インデントが微妙に異なる
    Digdagとしてはエラーにならないが…
    なるべく統一してキレイに保ちたい！
    見落としがち & レビューで指摘し辛い
    +task1:
    sh>:
    +task2:
    sh>:
    

    View Slide

33. © DMM.comラボ
    動かないものをmasterへマージしたくない！
    ワークフローの品質向上
    細かなミスを防ぐ仕組みが欲しい…
    モチベーション
    32
    

    View Slide

34. © DMM.comラボ
    CircleCI を使って…
    1. digdag check 実行
    digdag check コマンドで動かないワークフローを検知
    2. yamllint による 静的解析
    digファイルも YAML なので… yamllint を利用し
    重複するキー / 空の値 / インデント違い などを解析
    reviewdog でPRにコメントするように
    + EditorConfig も導入
    考えた解決策
    33
    

    View Slide

35. © DMM.comラボ
    yamllint × reviewdog
    重複するキー (+task) があった場合など、PRにコメントしてくれるように
    例: yamllintによる静的解析
    34
    ref. https://github.com/szyn/ossday-digdag/pull/1
    

    View Slide

36. © DMM.comラボ
    35
    現状の課題
    運用している中で出てきている課題
    

    View Slide

37. © DMM.comラボ
    課題
    36
    Operator 関連
    sh> に頼りがち (クラウド関連のOperator使いたい…)
    emr> でスポットインスタンスが利用できない
    Web UI 関連
    過去に辿れるセッション数が現状 100 固定
    ※ REST API での仕組みはありそう
    通知関連
    digdag-slack を利用し通知しているが改善が必要
    　 具体的には digdag issue (#669) で議論されている
    

    View Slide

38. © DMM.comラボ
    37
    今後の展望
    どうしていきたいか (๑•
    ̀ ŷ•
    ́ )و✧
    

    View Slide

39. © DMM.comラボ
    やろうと思っていること
    38
    sh> からの脱却
    AWS (EMR / Athena / Glue) の Operator使いたい！
    通知周りの改善
    digdag issue (#669) の対応を検討
    監視周りの強化
    Zabbix → Prometheus へ
    Web UI周りの改善
    

    View Slide

40. © DMM.comラボ
    X
    +plazma_oss_day:
    +talk_by_szyn:
    finally>: Thanks!
    ※ finally> は実際には存在しません
    

    View Slide