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

Digdagを導入してみて

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.)についてご紹介しました。

DMM.com

February 15, 2018
Tweet

More Decks by DMM.com

Other Decks in Technology

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