Heroku Container Registry & Runtime + digdagで お手軽バッチ処理環境 を作ってみた

Heroku Meetup #22でLTした内容です。

Transcript

1. Heroku Container Registry & Runtime + digdagで お手軽バッチ処理環境 を作ってみた 2018-09-05 須貝俊
2. 自己紹介 - 須貝俊 - IESHILというWebサービスでエンジニアやってます。 - 主にRailsアプリケーションの開発を担当。 - Heroku大好き。個人で2011年から利用してます。
3. 僕が使い始めた頃のHeroku
4. 一番右に（権利的に）ヤバいのがいる
5. 今日一番伝えたかったこと 以上。
6. 本題行きます
7. Heroku上で Docker動かすやつで バッチ処理走らす話
8. イエシルとは - IESHIL https://www.ieshil.com/ - マンションの査定価格を載せてるカ タログ的なサイト - Ruby on Rails + Heroku
9. 査定価格、災害リスクなどの住環境データ
10. 新たに販売中の物件を掲載（8/1〜）
11. この機能の裏側で 頑張っているものが 今日の本題
12. 作ったもの
13. 作ったもの - データ提供元のFTPサーバにアクセスしてデータを取ってくる - それをTreasureDataに放り込む - TD上でIESHILの建物マスターデータと取得した物件データを 名寄せする - 名寄せしてフロント用に整形したデータをJSONL形式でS3に 吐き出す
14. なぜdigdag + embulkなのか？ - TreasureDataを利用しているから - チーム内ですでに実績があるツールだから - ちなみにdigdagはローカルモードです
15. なぜHerokuなのか？（表向き） - 時間がなかったから。 - バッチ処理環境がないわけではないが、アドホックに立てた Digital Oceanのインスタンスで負債感あり。 - 別途、AWS上にdigdagサーバーを構築する動きがあったが、 今回のリリースには間に合わなそうだった。 - イエシル上の建物マスターデータと、販売物件データを名寄せ する処理に集中したかった。
16. なぜHerokuなのか？（裏） - Container Registry & Runtimeを本番で使ってみたかったか ら - だいたいのものはHerokuで動かせると思っているから - Herokuが好きだから
17. どうやって作るのか - ドキュメントに詳しく書いてあります。 https://devcenter.heroku.com/articles/container-registry-and-runtime - Dockerfile書いてpushするだけ - リリース時はheroku container:releaseする必要あり
18. どうやって作るのか - Add-ons - Heroku Scheduler : 定期実行に必要 - Papertrail : ログ収集 - Dead Man’s Snitch : 死活監視 - SendGrid : メール送信
19. Add-ons 全部無料ですみません
20. やってみた感想
21. 感想：メリット - 本番相当の環境ですぐに動かせた - リリースが簡単 - 足りないものはAdd-onsでなんとかなる - とにかく楽
22. 感想：デメリット - Heroku SchedulerはDailyだと時間が30分刻みでしか設定で きない - 実行時間が24時間以上になる場合は工夫する必要がある dynoは24時間 + αで再起動するため。 （今回は30分程度で終わる処理なので問題なし）
23. 感想：余談 - 別途AWS上に構築したdigdagサーバーが本番運用されてい るので、今後そちらに移行していく予定。 - ただし傍から見ているとdigdagのサーバーモードはいろいろ 大変そうだなという印象。
24. おわり