軽めの定期処理にAWS Batchを使ってみた感想 - Casual Startup

AWS Batchを業務系アプリケーションにありそうな軽めの定期処理に使ってみたので、感想をまとめておきます。

実装した処理は、1日1回、あるWebサイトからファイルをダウンロードし、軽く加工してRDBにロードし、解析するという処理です。

ユーザーは自分だけですが、実装してから半年ぐらい継続して使っています。この間に、Webサイト側の更新遅れなどのイレギュラー対応や、解析処理の追加などもやっており、小規模ですがちゃんと運用していると言えると思います。

この経験を踏まえて、ジョブ管理用途でのAWS Batch利用について気付いたことは以下3点です。

トリガーがかかってから、実際に実行されるまでの遅延が結構大きい(1～3分ぐらい)。
ジョブの依存関係は、ジョブ定義には書くことができず、ジョブの投入時にしか指定できない。
ジョブの実行結果(成功・失敗など)を一覧できる画面がない(job queueごとの成功・失敗件数しかない。どんなものか気になる方は"AWS Batch Dashboard"で画像検索してみてください)。

全体的な印象として、AWS Batchは、流体シミュレーションのような大型機で何時間もかかる処理向きで、軽めの定期処理はあまり想定されてなさそうだと思っています。

この点について、AWSの方が同様なことを言っていました。下記URLにある資料の9ページ目です。

まず思い付く選択肢です。

ただ、cronだと、処理途中でのイレギュラー発生時の通知やリカバーで運用が泥沼化しやすいという課題があります。

このためエンタープライズ向け開発だと、JP1/AJSなど、「ジョブ管理」「ジョブネット」と呼ばれるような専用のミドルウェアを使うことがあります。Hinemosにも同様な機能があるようです。

私自身はいずれも使う機会がないまま来ていたため、一度何か試してみたいと考え、今回はcronは不採用としました。

他に、自宅のPCを24時間稼働させたくない、というのも「自宅PCでcron」を不採用とした理由の1つです。自宅PCは手軽ではあるのですが、旅行中に自宅で停電があったらその日のうちに緊急帰宅するのかとか、結構悩ましいのです。

AWSだと、AWS Lambdaも定期起動が可能です。

ただ今回は、解析処理の都合上、データベースとしてリレーショナルなDBであるRDSを使う必要がありました。そして、RDSはVPCの中で動かす必要があります。

一方でLambdaは、VPCの中で使うと起動が結構遅いという情報がありました。

今なら、LambdaをVPCの外で動かして、RDS ProxyでVPC内のRDSに接続するという構成もありえると思いますが、自分が検討した当時はまだリリースされていなかったため、Lambdaは不採用としました。

以下の2つの処理に分かれています。

2番目の処理は、本来であれば、RDSへのロードと解析の2つのジョブに分けたいのですが、ジョブ定義に依存関係を設定することができないため、2つの処理を結合するようコンテナを修正しました(実際には、コンテナ内で実行するPythonスクリプトを修正しただけですが)。

以上のように、軽量な定期処理にAWS Batchはいまひとつ向いていないのですが、それでも使い続けている理由は以下の通りです。

毎日手動でファイルダウンロードしていたときと比べると、処理のことを完全に忘れることができて快適だから。
自分の用途が分単位の遅延も許容できるものだから。
AWS Batchをとりあえず使い慣れてしまったから(サービス本体の習得だけならまだなんとかなるのですが、ソースコードのディレクトリ構成とか、デプロイ手順の確立とかまで含めると、別サービスに乗り換えるのは結構な学習コストになります)。

5分に1回Webサイトのスナップショットが取りたいみたいなニーズが出てくると、分単位の誤差があるAWS Batchでは対応できなくなります。

そのときには、OSレベルの管理をしないで済むAWS ECSを使って、Hinemosを入れたイメージを作って動かしてみようかなと思ってます(ECSは常時動作させておく)。

そのニーズが発生するまでに、クラウドネイティブなジョブ管理サービスに登場していて欲しいものです。