AWS Batch のジョブキューがいつの間にか文字通りの FIFO の動作になっていたようなので動作確認してみた
2024.03.11以前までの AWS Batch のジョブキューは先入れ先出し (FIFO) でジョブを実行するのですが、完全な順序保証はない自称 FIFO でした。この度ドキュメントを確認していたら、順序保証をぼやかす表現がなくなっていたため、完全な FIFO になっているのか確認してみました。
確認結果
ドキュメンに FIFO と書いてあると通り、先入れ先出しでジョブは処理されました。
- ジョブキューに 100 件のジョブを登録し、登録した順序通りジョブを順次処理するのか見守った
- 完全な FIFO と呼べる実行順序で処理が開始されていくことを確認できた
FIFO なのに First in First out ではないとは!?
以前の AWS Batch のジョブキューは FIFO と名乗るものの実行順序を保証していませんでした。昔のドキュメントの原文を確認できなかったため、過去の Stack Overflow の質問文より引用しています。
おおよそ（approximately）と説明されています。
The AWS Batch scheduler evaluates when, where, and how to run jobs that have been submitted to a job queue. Jobs run in approximately the order in which they are submitted as long as all dependencies on other jobs have been met. amazon web services - Scheduling strategy behind AWS Batch - Stack Overflow
日本語訳のドキュメントでは以下の様に翻訳されていたようです。
ほぼと説明されています。
ジョブの実行順は、他のジョブへの依存関係がすべて満たされている限り、送信順とほぼ同じです。
上記文言を確認できる以下のブログでは実行順序の検証もしており、実際にジョブをサブミットした順には処理が開始されなかったと記録が残っています。
以上から確認できる通り、完全な FIFO ではありませんでした。
似たようなところではキューのマネージドサービスである Amazon SQS では、標準キューと、FIFO キューの 2 種類提供されています。FIFO キューは文字通り完全な FIFO です。標準キューの順序保証はベストエフォートとなっています。
AWS Batch のジョブキューは、どちらかと言うと SQS の標準キューに近い順序保証でしたね。
この度ドキュメントを確認していたらapproximatelyの単語がなくなっていることに気が付きました。
the AWS Batch job scheduler defaults to a first-in, first-out (FIFO) strategy. A FIFO strategy might cause important jobs to get “stuck” behind jobs that were submitted earlier. Job scheduling - AWS Batch
他にそれっぽい記述はないかと探したのですが、ユーザーガイドにも FIFO と表記されています。
Job queues that don't have a scheduling policy are scheduled in a first-in, first-out (FIFO) model. Job queue parameters - AWS Batch
ドキュメントヒストリーからはいつ変更が入ったか確認できませんでした。
確認できたことは順序保証をぼやかす表現が削除されているということです。動作を確認してみましょう。
ジョブを 100 個投げて確認してみた
以前の検証ではジョブを 20 個キューに入れただけでも順序が保証されていないことを確認できていました。
検証環境
1 ジョブに必要な vCPU 数と、最大 vCPU 数を合わせてかつ vCPU 数を持つインスタンスタイプを 1 種類だけ指定することでジョブの同時実行数に制限をかけました。1 台しか起動できない c7i.2xlarge インスタンスで 1 ジョブずつ処理し、処理が終わると、次のジョブの処理を順次開始できる実行環境です。
| 設定項目 | 設定値 |
|---|---|
| 1 ジョブに必要な vCPU 数 | 8 |
| 最大 vCPU 数 | 8 |
| 許可されたインスタンスタイプ | c7i.2xlarge（8 vCPU） |
| プロビジョニングモデル | Spot |
| 配分戦略 | SPOT_CAPACITY_OPTIMIZED |
ジョブを投げて結果確認
50 件、50 件に分けた塊でジョブを順次サブミットしました。分けた理由は以前の検証では 10 件、10 件に分けていたため、登録方法を準じて登録数を増やすかたちにしました。ジョブの実行内容はsleep 30で 30 秒待機するだけの内容となっています。
for x in {1..50}; do
aws batch submit-job --job-definition devio-job-def-20240308 \
--job-name devio-check2-fifo-A-${x} \
--job-queue devio-job-queue
done
for x in {1..50}; do
aws batch submit-job --job-definition devio-job-def-20240308 \
--job-name devio-check2-fifo-B-${x} \
--job-queue devio-job-queue
done
100 件のジョブがキューにたまり、順調に頭から処理が流れていっています。
結果はサブミットした順番を守って 100 件の実行を完遂してくれました。 実行時間が 30 秒のジョブが 100 件なら 50 分（3,000 秒）あれば終わりそうですが、オーバーヘッド込みで 1 時間 30 分かけて終わりました。ジョブ数が多いためキャプチャは後半部分だけです。
正真正銘の FIFO キューになったようです。
まとめ
AWS Batch のジョブキューは ほぼ FIFO を改めて、完全な FIFO になっていた。
おわりに
ドキュメントに FIFO と書いてあるのだからその通りの結果でした。自称 FIFO を卒業したようで何よりです。お客様へ仕様をご案内するときに FIFO ですと素直に言えるのでよくなりました。
