AWS Batchの注意点
ということで今回はAWS Batchで実際にシステムを構築したときの
なんやかんやについて解説します。
お品書きは以下です。
１．AWS Batchの概要
まずAWS Batchについて、
AWS Batch を使用することにより、開発者、科学者、エンジニアは、数十万件のバッチコンピューティングジョブを AWS で簡単かつ効率的に実行できます。AWS Batch では、コンピューティングリソース (CPU やメモリ最適化インスタンスなど) の最適な数量とタイプを、送信されたバッチジョブの量と具体的なリソース要件に基づいて動的にプロビジョニングします。AWS Batch を使うと、ジョブを実行するためのバッチコンピューティングソフトウェアやサーバークラスターをインストールしたり、管理したりする必要がなくなります。
ということで、大量のデータをさばくことが可能なコンテナサービスです。
AWS Batchのサービスとして提供されるのは
・ジョブ定義
・ジョブ
・ジョブキュー
・コンピューティング環境
https://aws.amazon.com/jp/blogs/news/webinar-bb-aws-batch-2019/
上記の図のとおり、コンピューティング環境はコンテナなので
コンテナイメージを格納するECR、およびECSが別途必要になります。
基本的に実行モジュール(JARファイルなど)はEFSかS3において、
コンテナ作成後にコンピューティング環境にダウンロードするのが
ベストプラクティスのようです。
※上記の図は実行後のOutputとして記載しているので別の話です
２．AWS Batchのメリット
AWS Batchのメリットは、なんといっても大量データを並列して処理できる
という点につきます。（そのためのサービスですし。。）
ジョブキューに入れれば、その数に応じてコンテナが立ち上がるため
よくLambdaと比較されますが、Lambdaと異なり
コンピューティング環境を自分で設定でき、15分の制約もありません。
そのため、Lambdaではできない重い処理を行うときにも
選択肢にあがります。
今回、私がBatchを採用したのは以下の理由からです。
・基本的にそこまで重い処理ではないが、
inputのサイズがリクエストにより異なるため、
Lambdaを採用しにくい（制約にひっかかる不安があった）
・時間によってリクエストの波があるため、
柔軟なスケール性能が求められた。
・秒間数千を超えるリクエストが想定された。
また、リクエストによりinputのサイズが異なるため、
コンテナによって処理が軽すぎたり重すぎたり、といった事象を緩和するため
下記の構成にしました。
SQSにはinputとなるデータのパスとサイズ情報を格納し、
Lambdaはそれをもとに一定数のリクエストを一つのジョブに成形し
AWS Batchのジョブキューに登録しました。
これにより、各コンテナの負荷が均一になり、安定した性能と可用性が
実現できました。
※ちなみにFargateという選択肢もあったのですが、SQSに取得しにいったあとに
ScalingができるのかがわからなかったのでBatchを採用しました
３．AWS Batchの注意点
さてさて、上記でAWS Batchの良さについて説明しましたが、
実装にあたり、結構こまったこともあったので紹介します。
・Time Outで終了した場合、リトライされない
AWS Batchはジョブが異常終了した場合、基本的には設定回数リトライされますが
TimeOutになった場合はリトライが発生しません。
そのため、運用回避するか、リトライアウトの時間を延ばすか、別途Lambdaで
TimeOutをキャッチして積みなおすような処理が必要になります。
・Cloudwatchのロググループを指定できない。
AWS Batchはロググループをこちらで指定できず、すべてが
/aws/Batch/に格納されるため、運用ルールにうまくはまらない場合があります。
・ECSがEC2hostのみでFargate対応していない
AWS Batchのコンピューティング環境ではFargateが指定できません。
そのため、ネットワークなど結構気にしなければいけない場合があります。
・ジョブキューは文字数制限がある。
まあSQSもあるので当たり前ですが。。
設計によってはひっかかるので気を付けましょう
