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

XCopyright © 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取得した

データ加工処理

LoadDWH / 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

PollingETL処理の終了待ち

※ 必要な場合

AggregationPrestoへクエリ実行

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

MonitoringDigdag における 監視

© 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

CIDigdag における 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による静的解析

34ref. 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> は実際には存在しません