Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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> は実際には存在しません