AWS Batch で サブミットしたジョブがRUNNABLEのまま止まりました。
この場合はよくあるのはジョブ、ジョブ定義で指定した vCPU、メモリの値が、実際に起動する EC2 インスタンスの vCPU、メモリ量より大きな値となっているケースです。詳細はこちらのブログをご確認ください。
本件はvCPU、メモリの指定が原因ではありませんでした。切り分けした過程と、対処方法を紹介します。
確認結果
- コンピューティング環境のプレイスメントグループの指定の誤りが原因で
RUNNABLE状態のまま止まっていた - コンピューティング環境を更新するとエラーは解消された
切り分け過程と対処方法
エラー切り分け
サブミットしたジョブがRUNNABLEのまま変化がありません。
ジョブをキャンセルしました。ジョブは失敗し理由は自らジョブをキャセルしたためと表示され原因はわかりません。
コンピューティング環境からジョブで指定したコンピューティング環境を確認します。
ステータスを確認するとINVALIDとなっています。理由は指定プレイスメントグループ（ここではbatchという名前のプレイスメントグループ）がないと原因を特定できました。
今回の原因は表示されていたとおりプレイスメントグループの指定ミスでした。AWS Batch でジョブ定義でマルチノードの並列を有効にしたためプレイスメントグループを利用する予定でした。そのプレイスメントグループを作成し忘れていました。
対処方法
プレイスメントグループが未作成であればクラスターを指定して作成します。
コンピューティング環境から該当のコンピューティング環境を選択して編集します。
プレイスメントグループ名の指定を再確認します。注意事項は先にプレイスメントグループ名を指定してコンピューティング環境を作成しており、あとで指定した名前のプレイスメントグループ作成した場合、コンピューティング環境をなにも設定変更しなくても一度保存して更新かけないと反映されません。
変更を保存して更新をかけます。
ステータスがUPDATINGと表示されました。
まとめ
- コンピューティング環境を作成時に
batchという名前のプレイスメントグループを指定しました - ジョブをサブミットすると
RUNNABLEで止まり、原因はわかりませんでした - その後でプレイスメントグループ名
batchを作成しました - 事後で作成したプレイスメントグループをコンピューティング環境に反映させるために一度保存による更新が必要でした
覚えておきたいことはコンピューティング環境に設定を反映させるにはコンピューティング環境を一度保存し直さないと反映がかからないことです。
おわりに
AWS Batch で サブミットしたジョブがRUNNABLEのまま止まってしまうケースの紹介でした。プレイスメントグループの指定を誤るケースは少ない方だとは思います。
前提としてジョブ定義で EC2 起動かつ、マルチノードの並列を有効時にプレイスメントグループ（クラスター）を利用した方が好ましいと判断した際に、コンピューティング環境でプレイスメントグループ名を指定することになります。
- 作成済みと思っていたプレイスメントグループ名が存在していなかった
- プレイスメントグループ名のタイポ
理由は上記2つくらいでしょうか、とくにタイポには気をつけたいところです。
2
