Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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ラボ 自己紹介 データ分析基盤の開発・運用 ミドルウェアが好き Presto / Digdag 導入 Digdag

    へも (…チョットだけ) Contribute 推しPR: digdag#664 mog / digdag-go-client など 趣味で細々と…開発中… 2 鈴木 翔太 DMM.comラボ システム本部 ビッグデータ部 Github: szyn / Twitter: @i_szyn
  2. © DMM.comラボ 背景 - なぜDigdagなのか? - 5 移行前は Jenkins でバッチを運用

    - 当時の課題 - Jenkins依存 ※1 時間依存の処理 ※2 処理フローをコードで管理できていない 各データソースの依存関係の認識が難しい ※1) 日次バッチ/ CI / デプロイ等に利用し、当時チーム管轄のジョブ数だけで 約200 (!) ※2) 依存ジョブは毎日大体4時くらいには終わっているし、5時から後続ジョブをスタート…など
  3. © 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) で管理 スケジュール実行 エラーハンドリング リトライ機能 (特にリジューム) 高速化 タスクの並列実行 複数サーバでタスクの分散実行
  4. © DMM.comラボ X システム構成 オンプレミスで運用 サーバ / クライアント構成 構成管理: Ansible

    DBはPostgreSQL pgpool-Ⅱ も同サーバに ビッグデータ部におけるDigdag • ruby / python • hadoop client ※ • mog API & Scheduler & Executor ※ hadoop / hdfs / beeline / sqoop
  5. © 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
  6. X Copyright © since 1998 DMM All Rights Reserved. Golang製

    Digdag CLI (※ 非公式) 特定の プロジェクト / ワークフロー / セッション / タスク の ステータス確認 ができる ワークフローの スタート & リトライ 別ホストに対しても実行可能 他システムとの連携ができるように Githubにて公開中 (https://github.com/szyn/mog) mogについて 9
  7. © 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... $
  8. © DMM.comラボ 13 良くなった点はどこですか? ジョブの依存関係が分かりやすい 2 ワークフローの見通しが良くなった 3 Web UIが分かりやすい

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

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

    5 +sleep_3sec: sh>: sleep 3 +sleep_1sec: sh>: sleep 1
  11. © DMM.comラボ 18 1. ETLバッチ 2. API向けバッチ  3. BI向けバッチ ビッグデータ部における

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

    Extract RDBMSから データ取得処理 Transform 取得した データ加工処理 Load DWH / Data Mart へ データ転送
  13. © 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) でアクセス
  14. © DMM.comラボ 2. API向けバッチ 21 Polling ETL処理の終了待ち ※ 必要な場合 Aggregation

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

    2. Aggregation 集計バッチ CLI 実行 (Golang) Prestoで集計処理を行いCTASで集計結果を MariaDBに書き込み 3. Distribution REST API で集計結果を返却 mog 集計バッチ CLI 実行
  16. © 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
  17. © DMM.comラボ 30 悩み ① 重複タスク +task: sh>: +task: sh>:

    error: Validating project failed workflow xxxx Duplicated keys: [+task] (model validation) タスク名 (+task)が 重複してしまっている
  18. © DMM.comラボ CircleCI を使って… 1. digdag check 実行 digdag check

    コマンドで動かないワークフローを検知 2. yamllint による 静的解析 digファイルも YAML なので… yamllint を利用し 重複するキー / 空の値 / インデント違い などを解析 reviewdog でPRにコメントするように + EditorConfig も導入 考えた解決策 33
  19. © DMM.comラボ 課題 36 Operator 関連 sh> に頼りがち (クラウド関連のOperator使いたい…) emr>

    でスポットインスタンスが利用できない Web UI 関連 過去に辿れるセッション数が現状 100 固定 ※ REST API での仕組みはありそう 通知関連 digdag-slack を利用し通知しているが改善が必要   具体的には digdag issue (#669) で議論されている
  20. © DMM.comラボ やろうと思っていること 38 sh> からの脱却 AWS (EMR / Athena

    / Glue) の Operator使いたい! 通知周りの改善 digdag issue (#669) の対応を検討 監視周りの強化 Zabbix → Prometheus へ Web UI周りの改善