PLAZMA OSS Day: TD Tech Talk 2018 (https://techplay.jp/event/650389) の資料となります。
−−− DMM.comラボ ビッグデータ部ではETLをはじめとしたバッチ処理をDigdagを利用して行っています。 今回は実際の現場においてDigdagをどのように活用しているかをはじめとし、導入により改善できたことや運用面での取り組み(e.g. 監視…etc.)についてご紹介しました。
DMM.comラボ ビッグデータ部 鈴木 翔太2018/02/15 @ PLAZMA OSS Day: TD Tech Talk 2018#tdtechDigdagを導入してみて
View Slide
© DMM.comラボ自己紹介データ分析基盤の開発・運用ミドルウェアが好きPresto / Digdag 導入Digdag へも (…チョットだけ) Contribute推しPR: digdag#664mog / 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 GroupDigdagとは?7ref:Digdag - Open Source Workflow Engine for the Multi-Cloud Erahttps://www.digdag.ioEmbulkとDigdagとデータ分析基盤とhttps://www.slideshare.net/ToruTakahashi4/embulkdigdagDigdagによる大規模データ処理の自動化とエラー処理https://www.slideshare.net/frsyuki/digdag-76749443Treasure Data が開発するワークフローエンジンSIMPLE, OPEN SOURCE, MULTI-CLOUD WORKFLOW ENGINE基本機能タスクの順次実行ワークフローをコード (YAMLベースのDSL) で管理スケジュール実行エラーハンドリングリトライ機能 (特にリジューム)高速化タスクの並列実行複数サーバでタスクの分散実行
© DMM.comラボXシステム構成オンプレミスで運用サーバ / クライアント構成構成管理: AnsibleDBはPostgreSQLpgpool-Ⅱ も同サーバにビッグデータ部におけるDigdag• ruby / python• hadoop client ※• mogAPI & Scheduler & Executor※ hadoop / hdfs / beeline / sqoop
© DMM.comラボ8システム構成オンプレミスで運用サーバ / クライアント構成構成管理: AnsibleDBはPostgreSQLpgpool-Ⅱ も同サーバにビッグデータ部におけるDigdag※ hadoop / hdfs / beeline / sqoop4 Core20 GB60 GBCPUMemDisk• ruby / python• hadoop client ※• mogAPI & Scheduler & Executor
XCopyright © since 1998 DMM All Rights Reserved.Golang製 Digdag CLI (※ 非公式)特定の プロジェクト / ワークフロー / セッション / タスク のステータス確認 ができるワークフローの スタート & リトライ別ホストに対しても実行可能他システムとの連携ができるようにGithubにて公開中 (https://github.com/szyn/mog)mogについて9
© DMM.comラボProject WorkflowSession 3秒スリープするタスクを用意上記タスク (+test+step1) の完了待ちをする場合10mog利用例+step1:sh>: sleep 3: sample: test: daily
© DMM.comラボ11タスクが正常終了すると、JSONが返却コマンドの exit-status = 01秒毎に取得コマンド実行{"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+step1INFO[0003] task `+test+step1` state is runningINFO[0003] state is not success. waiting 1 sec for retry...INFO[0006] task `+test+step1` state is runningINFO[0006] state is not success. waiting 1 sec for retry...INFO[0009] task `+test+step1` state is runningINFO[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 1serial.dig
© DMM.comラボ15parallel.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ビッグデータ部における Digdag160workflows60schedules1900tasks / daydig
© DMM.comラボ181. ETLバッチ2. API向けバッチ 3. BI向けバッチビッグデータ部における Digdag現状3つのプロジェクトが存在 (2018/02 時点)※ call されるワークフローも含んだ数字: 117 workflows ※: 31 workflows: 11 workflows ※
© DMM.comラボ1. ETLバッチ集計頻度: Daily / MonthlyHadoopに対するETL処理19ExtractRDBMSからデータ取得処理Transform取得したデータ加工処理LoadDWH / Data Mart へデータ転送
© DMM.comラボ201. Extract内製データ収集ツール実行Sqoop import (MySQL to Hive)2. TransformHiveクエリによる集計※ MapReduceはDigdag ServerではなくHadoop Clusterで分散実行されるためリソース周りは安心3. Load各種集計結果を DWH/S3/MariaDB に転送Hadoop ClientHaddop ClusterへCLI (sqoop / beeline / hdfs) でアクセス
© DMM.comラボ2. API向けバッチ21PollingETL処理の終了待ち※ 必要な場合AggregationPrestoへクエリ実行Create Table As Select~(CTAS)Distribution集計結果がDBに保存されAPIから参照される集計頻度: Hourly / Daily基本的にETL処理したデータを元に集計
© DMM.comラボ221. Pollingmog を利用し、集計に必要なETLタスクのステータスがsuccess になるまで待機2. Aggregation集計バッチ CLI 実行 (Golang)Prestoで集計処理を行いCTASで集計結果をMariaDBに書き込み3. DistributionREST API で集計結果を返却mog集計バッチCLI 実行
© DMM.comラボ23運用についてMonitoring / CI
© DMM.comラボ24MonitoringDigdag における 監視
© DMM.comラボDigdag ServerJMX 監視 (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 - Zabbix25これまでの障害件数 : 0
© DMM.comラボZabbixによる監視 (Digdag Serverの一部抜粋)26※ 上記は Grafana で表示したもの
© DMM.comラボDigdag ワークフロー運用時に心がけていること定期実行するものは必ずSLAを設定し通知ワークフローが増えてくると、全てが正常に動いているかどうか確認は難しいためSLAにひっかかるようになったら改善を図るMonitoring - Digdag27
© DMM.comラボ28CIDigdag における CI への取り組み
© DMM.comラボDigdagはワークフローの push 時などにバリデーションがあり、動かないワークフローはリリースできないようになっているしかし、2つの悩みがあった…なぜCIをするのか?29
© DMM.comラボ30悩み ①重複タスク+task:sh>:+task:sh>:error: Validating project failedworkflow 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ラボ課題36Operator 関連sh> に頼りがち (クラウド関連のOperator使いたい…)emr> でスポットインスタンスが利用できないWeb UI 関連過去に辿れるセッション数が現状 100 固定※ REST API での仕組みはありそう通知関連digdag-slack を利用し通知しているが改善が必要 具体的には digdag issue (#669) で議論されている
© DMM.comラボ37今後の展望どうしていきたいか (๑•̀ ŷ•́ )و✧
© DMM.comラボやろうと思っていること38sh> からの脱却AWS (EMR / Athena / Glue) の Operator使いたい!通知周りの改善digdag issue (#669) の対応を検討監視周りの強化Zabbix → Prometheus へWeb UI周りの改善
© DMM.comラボX+plazma_oss_day:+talk_by_szyn:finally>: Thanks!※ finally> は実際には存在しません