Digdagバッチの基本設計とビルドの実例紹介 - MicroAd Developers Blog
サーバサイドエンジニアの大澤です。主にETL処理のバッチ開発を行っています。 以前の記事で紹介していますが、マイクロアドではバッチ処理のワークフローを主にDigdagを使用して管理しています。 今回は、Digdagを1年以上使ってきてたどり着いた構成について紹介したいと思います。 Digdagバッチ CI/CDの構成 GitHub Enterprise上のバッチを管理しているリポジトリの変化に応じてJenkinsがビルド、テスト、コードチェック、デプロイまで行うようになっています。 バッチはDigdagとDockerを使用して動作するように作っているので、DockerレジストリとDigdagサーバに成果物を登録します。 成果物は対象のブランチに応じて行き先が変化し、masterブランチの変更の場合本番用の環境へ、その他の場合開発用の環境にデプロイされます。 CIの内容はリポジトリ内のJen
Digdagを使ったジョブ管理 - MicroAd Developers Blog
はじめまして。アプリケーションエンジニアの中野です。 以前、MicroAdのデータ基盤の記事で紹介されていましたが、マイクロアドではデータ基盤刷新のタイミングでワークフロー管理ツールのDigdagを採用しました。 今回の記事では、Digdag採用の経緯やワークフローを作成する際に注意した点を紹介します。 Digdag採用の経緯 マイクロアドのDSP*1であるBLADEではBidRequestやImpression*2、Click、Conversion*3、その他BLADEから出力される様々なログやマイクロアドの他のプロダクトのログ、他社から提供されるデータなど、様々なデータを広告配信最適化の分析に活かしています。 これらのログを分析するバッチ処理は各々のジョブが複雑な依存関係を持っています。 これまではcronやJenkinsを用いてこれらの処理を行っていましたが コード管理が出来ていない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
