初めまして、ベガコーポレーション データ戦略部 分析基盤エンジニア 新卒3年目の武本です。分析基盤の構築をメインに担当しています。digdag+embulkでデータを同期するツールを開発しFargateでHA構成にしたのでご紹介したいと思います。 入社した当初の分析基盤の状況 分析基盤をご紹介する前に開発前の状況についてお話しします。 かれこれ2年前の話になりますが私が入社した頃にBigQueryを導入しようという話になっていました。 分析に必要なデータを一元管理し、クエリを高速に実行させ、ストレスなく分析業務ができる環境を作るというのが一つの目標でした。 とりあえず必要になったのがBigQueryでデータを一元管理する為のシステム。つまり分析基盤の構築です。 分析基盤構築の開発に当たって調べているとdigdag + embulkでデータを同期させるという事例が多く、弊社もdigdag +

こんにちは、最近のマイブームはマヌルネコ動画な新事業創造部バックエンドエンジニアの塩崎です。 今回のテックブログでは、以前にDigdagを紹介した記事の続編として、DigdagをHA構成にするためのTipsなどを紹介します。 Digdagとは Digdagはワークフローエンジンと呼ばれるソフトウェアです。 複数個のタスク間の依存関係からなるワークフローを定義し、そのワークフローの実行及び管理を行います。 この説明だけですと、何が便利なのかいまいちピンとこない方が多いかと思います。 ですが、かゆいところに手が届く便利ソフトウェアです。 具体的なかゆいところの紹介は以前にDigdagを紹介した記事の前半部分に書かれています。 Digdagを使用したことのない方はこちらを読んでから本記事を読み進めると理解しやすいかと思います。 tech.starttoday-tech.com さて、前回の記事で

こんにちは、バックエンドエンジニアの塩崎です。 先日、会社の広報のためのインターン生紹介記事にメンターとして掲載していただきました。 大学四年生のインターン生と一緒に写真撮影を行ったのですが、見た目だけではどちらが年上かわからなかったので、「メンターの塩崎（右）」という表記をされてしまいました（笑） インターンでも実際のサービスに触れ、課題を解決！〜VASILY DEVELOPERS BLOGが公開されました〜 さて、VASILYではData WarehouseとしてGoogle BigQuery（BigQuery）を利用しています。 BigQuery内にはプロダクトのマスタデータとユーザーの行動ログが格納されています。 そして、それらに対する横断的なクエリを発行することでプロダクトの成長のためのKPIをモニタリングしています。 そのためAmazon Relational Database

This is a story about running digdag on Kuberentes to create a scalable workflow execution environment

広告技術部のUT@mocyutoです。 ついに桜が開花し、やっと春の訪れを感じはじめましたね。 外で気持ちよく飲みたい季節になってきました。 はじめに システム概要 なぜ移行するのか Celeryをやめたい LevelDBをやめたい 移行計画 アーキテクチャ ECS Athena CI/CDフロー Pluginか自前実装か 移行後 よかったこと まとめ はじめに 今回はEC2上のPythonのバッチをECSのDigdagに置き換えた話をします。 システム概要 今回の移行対象は広告配信に関するバッチ処理を行うシステムでした。 役割としては以下のようなものがあります。 広告の配信候補を作成 広告の枠情報を作成 クリックなどのイベントの集計 なぜ移行するのか 大きく分けて以下の２つの理由がありました。 Celeryをやめたい LevelDBをやめたい Celeryをやめたい 今まではバッチにはP

サーバサイドエンジニアの大澤です。主にETL処理のバッチ開発を行っています。 以前の記事で紹介していますが、マイクロアドではバッチ処理のワークフローを主にDigdagを使用して管理しています。 今回は、Digdagを1年以上使ってきてたどり着いた構成について紹介したいと思います。 Digdagバッチ CI/CDの構成 GitHub Enterprise上のバッチを管理しているリポジトリの変化に応じてJenkinsがビルド、テスト、コードチェック、デプロイまで行うようになっています。 バッチはDigdagとDockerを使用して動作するように作っているので、DockerレジストリとDigdagサーバに成果物を登録します。 成果物は対象のブランチに応じて行き先が変化し、masterブランチの変更の場合本番用の環境へ、その他の場合開発用の環境にデプロイされます。 CIの内容はリポジトリ内のJen

こんにちは、最近Embulk（エンバルク）を調べている川崎です。 タイトルの「DigDag」（ディグダグ） *1と聞いて○ァミコンや○ムコを思い浮かべた方はきっとアラサー以上ですね！ 今回はEmbulkを使い始めると直面するであろう課題について書いていきたいと思います。 これまでに書いたEmbulkエントリー [Embulk] Embulkについての個人的なまとめ [Embulk] guess機能を試してみた【追記】あり [Embulk] guess機能を試してみた Redshift編 [Embulk] タイムスタンプのカラムを追加する [Embulk] タイムスタンプのカラムを追加する add_timeプラグイン編 [Embulk] guess機能を試してみた (テーブルが存在する場合) Embulkを使いはじめると... Embulkはデータファイルの中身をDBにロードするような用途で

Treasure Data社によってOSSワークフローエンジン『Digdag』はその発表以後多くの反響を呼び、社内外を含め良く利用されるようになってきていますが個人的には下記の『試してみた』エントリ以降、あまり触って来ていませんでした。ちょっと個人的にも腰を据えて取り掛かってみようかという感じになってきましたので、仕組みや使い方を把握するという意味で一番参考になるであろう公式ドキュメントの一部を読み進めてみた記録をブログエントリとして残しておきたいと思います。 Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag ｜ Developers.IO Digdagのアーキテクチャ Digdagによるワークフローの自動化 ワークフローを使って、手動で行なっているあらゆる操作を自動化出来ます。一連のタスクを『ワークフロー』として定義し、Digdagを使

こんにちは、MA基盤チームの田島です。私達のチームでは複数のワークフローエンジンを利用し、メールやLINEなどへの配信を含むバッチ処理を行っていました。今回それらのワークフローエンジンをすべてDigdagに統一しました。そして実行環境としてGKEのAutopilot環境を選択したことにより、柔軟にスケールするバッチ処理基盤を実現しましたのでそれについて紹介します。 また、その中で得られた運用Tipsについても合わせて紹介します。 目次 目次 Digdag on GKE Autopilotの構成 Digdagの4つの役割 Worker Scheduler Web API Kubernetes Command Executor Workerでのタスク実行の問題 Command Executor Kubernetes Command Executorの利用 GKE Autopilot環境でのKu

D. M. です。レガシーの crontab が肥大化して困っています。今日はそのリプレイス候補である Digdag を使ってみた話です。 やりたいこと crontab は Linux のスケジューラの仕組みで定期バッチの実行用途でよく利用されますが低機能です。順序の依存関係やアラートは毎回独自に作りこまなければいけません。そのため近年は代替スケジューラを利用するケースが多いです。その候補のひとつである Digdag について検証したいと思いました。 Digdag を使うべき人 一般的にバッチスケジューラに求められる要件的には以下のようなものがあります。 ・スケジュール実行 ・複数バッチの順番の制御（ワークフロー） ・GUIでの管理 ・失敗時のアラート ・SLA 機能（長時間実行していたらアラートを飛ばす） ・分散実行 などなど 代替として広く知られているものですと Jenkins でのワ

2016/06/15に、トレジャーデータがオープンソースとして公開したワークフローエンジンDigdagのリンク集です。内容は随時更新します。またトレジャーデータではDigdagを自社でTreasure Workflowとして提供しています。こちらの情報も収集しています。 変更内容が気になる方は変更履歴をご覧ください。 1. 開催されるイベント 2. オフィシャルページ オフィシャルページ ソースリポジトリ 3. チュートリアル Getting started (英語) Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag (日本語) Digdag 入門 Digdagのアーキテクチャとコンセプトを理解する Treasure Workflow for ビギナー 環境構築編 digファイル書き方編 Digdag公式ドキュメントからDigdagを学ぶ

SREチームの安達(@adachin0817)です。最近ではランサーズ本家のインフラをコンテナに移行しまくっております。今回ランサーズとMENTAで運用しているEC2/分析基盤サーバー(Digdag + Embulk)をECS/Fargateに移行完了しました。では早速概要と苦労した点、今後の展望などを振り返っていきたいと思います。 分析基盤の紹介 > ランサーズの分析基盤(capybara)と運用について紹介 > MENTAをAWSに移行しました ちなみに私が入社して3年経つのですが、運用して変わったことは3年前よりデータの量が膨大になっていることと、現在、社内の分析チームにとって欠かせないシステムとなっております。その中でDigdagによるスケジューラーとEmbulkによるマルチソースバルクデータローダーである分析基盤専用のEC2サーバーがあり、毎日夜中にデータをBigQuryにシンク