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

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

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

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

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

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

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

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

© 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

© 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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