この記事はfreee データに関わる人たち Advent Calendar 2019 18日目のエントリーです。
概要
nakamichiと言います。freeeのデータ基盤でエンジニアやってます。
弊社ではデータ分析のためのあれやこれやの処理ワークフロー制御にdigdagを使っているのですが、最近弊社内でのdigdagの使い方が若干便利になったので、それについて紹介しようと思います。
なおdigdagの内部構造や仕様についてはほぼ触れていません。
先にまとめ
- 開発者の人数が増えるにつれ、唯一のsandbox環境が混み合ってきて幸せでない
- GitHubのPR毎に検証環境を作成できるようにして幸せ
これまでの使い方
digdag構成
ざっくりですが、弊社のdigdag環境は以下のような構成なっています。LB ListnerとかTargetGroupとかACMとか細かい部分は端折っちゃいます。
だいぶ端折ってますが、digdag自体はとあるECSクラスターの1サービスとして稼働していて、ワークフローのメタデータ等はRDSに保管する、この構成がsandboxとproductionそれぞれに用意された状態となっています。
digdag自体が具体的なデータ処理を実行することはほとんどなく、基本的にはワークフローエンジンとしての役割に徹し、具体的な処理はAWS BatchやらGlueに任せ、それらのジョブを起動するシェルスクリプトをdigdag内で叩いているイメージです。
digdagのワークフロー更新
digdagが関与する開発プロセスは基本的に以下の流れに則ります。
- PR提出 → sandboxにデプロイ → 動作検証
- 1の動作検証結果が問題なければPRをmasterにmerge → productionにデプロイ
1と2いずれもGitHubのイベントを受けてCircleCIジョブが発火します。CircleCIジョブはおおまかに以下の処理を実行します。
- (sandbox|production)のコンテナイメージをビルドし、latestタグを付けてECRにpush
- デプロイ用のECSタスクを(sandbox|production)のECSクラスタで起動。コンテナイメージのエントリポイントからワークフローのデプロイ処理が走る。
図にしてみました。ごちゃごちゃしてて心苦しい。
課題
sandbox環境のdigdagで検証を行うわけですが、sandboxには直近のPRのワークフロー内容が反映される仕組みとなっていたため、複数人で別のワークフローの編集を行っている場合、後出ししたPR(もしくはPRへのpush)が勝ちます。
並行してワークフローをいじる人数が少ないときは、
「sandbox更新してよかですか？」
「どうぞどうぞ」
の忖度でやり過ごせたのですが、人数が増えてくるに連れこの忖度が辛くなってきました。
やがてsandboxの渋滞が起こりはじめました。
打開策
そこでPR毎に検証用のdigdagを作ってしまえ！あとは各自が自由にワークフローいじってこう！という機運が高まりました。
必要なもの
まず検証環境共通で使うものとして、あらかじめ以下を準備します。
- ロードバランサ
- ドメインと証明書
またPR毎に必要なものとして、以下すべてをPR毎になんらかのイベント駆動でまるっと作成する仕組みを作ります。(今回はGitHub Actionsを採用)
- digdagサーバ
- メタデータ管理用のDB
- Target Group
- Listner Rule
検証環境生成フロー図
今日3度目の図です。検証環境が生成される一連のフローを表しました。
ちょっとうまく図で説明しきれなかったので、ポイントだけ補足します。
- これまでsandboxのECRリポジトリにsandbox:latestのタグしか付与していなかったところに、PR番号を取得してそれをタグとして採番するようにした
- latestではなく各自が開発しているPR内容を含んだコンテナイメージを使ってデプロイが可能
- PRコメントの特定ワードにGitHub Actionsが反応し、図の番号順に検証用のAWSリソースを作成
- オンデマンドで環境のご用意が可能
- 検証環境用のDNSホストゾーンにワイルドカード付きレコードを作成して、検証用ALBのドメインにALIASで紐付ける(ACMもワイルドカード付きで登録)
-
pr-XXX.digdag.co.jpのようにサブドメインがPR番号のドメインの名前解決が可能
-
- Target GroupとALBのListnerをPR毎に作成
- 各PRのドメインと紐付け、ブラウザから各PRのdigdag環境にアクセス可能
また図では表わせていないのですが、PRへの追加push時は既存のCircleCIジョブで対応しています。該当のPR番号の検証環境が存在していたらワークフローの更新処理をするタスクを追加しました。これで都度変更があっても検証環境が更新されます。
ちなみに週末に一度お掃除ジョブが走り、検証環境用のAWSリソースのみ削除しにかかるので、ゴミが残って無駄コストを払い続けるとかはないようにしてあります。
効果
各自思い思いにワークフローを更新できるので、少なくとも譲り合いで開発や検証作業が止まることはなくなり、生産性は間違いなく上がりました。
週末までは環境が残っているので、エビデンスとしてワークフローの実行実績をそのまま残しておくなど、レビュー時にも役立っています(sandboxオンリーの時代にできていたことが検証環境でもできている)。
感想
深夜のノリで描いた構成図は色々とヤバい。