【アップデート】AWS Glue がジョブキューイング機能を提供開始

# はじめに
こんにちは。株式会社ジールの[@yakisobapan](https://qiita.com/yakisobapan)です。

AWS Glueにて、**ジョブのキューイング機能**が提供開始されましたので、試してみました！

# 目次
 - アップデート内容
 - やってみた
 - 所感

# アップデート内容

AWSはAWS Glueジョブのジョブキューイングを追加しました。
この新しい機能により、アカウントレベルのクォータや制限を管理することなく、AWS Glue ジョブを投入することができます。

AWS Glue ジョブキューイングは、アカウントレベルのクォータと制限を監視します。
ジョブの実行を開始するためにクォータやリミットが不足している場合、Glue は自動的にジョブをキューに入れ、リミットが解放されるのを待ちます。
制限が利用可能になると、Glue はジョブの実行を再試行します。

ジョブは
　・アカウントあたりの最大同時実行ジョブ数
　・最大同時実行データ処理ユニット数（DPU）
　・Amazon VPCのIPアドレス枯渇によるリソース利用不可
 などの制限のために、キューに入れられます。

AWS Glue のジョブキューイングは、AWS Management コンソールまたは API/CLI を使用して有効にすることができます。
>AWS Glue now provides job queuingより引用
（2024/09/04 What's New with AWS?）

https://aws.amazon.com/jp/about-aws/whats-new/2024/09/aws-glue-job-queuing/

今回のアップデート機能を利用することで、
サービスクォータの制限によるエラーや、
サブネット内で利用できるIPアドレスが枯渇した際に発生する「The specified subnet does not have enough free addresses to satisfy the request」エラー
などにも、簡単に対応できるようになりました。

通常であれば、エラーとなりジョブが失敗してしまうところ、
リソースが確保できるまで待ち、失敗させずにジョブを継続させるようにできます！

# やってみた

サービスクォータの上限に触れてみました。
<br>
**サービスクォータの確認**

- マネジメントコンソールからアカウントのGlueのクォータを確認
　※アカウント、リージョンごとにデフォルト値は異なります。

一番お手頃（？）そうな Max task DPUs per account
（アカウントあたりの最大タスク DPU）、こちらを選択

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/b0109476-80e2-988d-defc-fab78b83bfcd.png" width=100%>

クォータに抵触するパターンとして挙げられる候補は他には以下かなと思います。
　・ Max concurrent job runs per account （アカウントあたりの最大同時ジョブ実行数）
　※デフォルト：2,000
　・ Max concurrent job runs per job （ジョブあたりの最大同時実行数）
 　※デフォルト：4,000<br><br><br><br>
**従来の挙動**
DPUが同じ2つのジョブを用意して、前ジョブが動いているうちに後ジョブを動かしてみます。

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/79f2ccbf-dcfb-8598-5b32-d98e03d000db.png" width=80%><br><br>
- 前ジョブくん(Job_Run_Queuing) / 後ジョブくん(Job_Run_Queuing_waiting)の作成
・Engine：Spark
・WorkerType：G.1X
・Number of workers：600
　G.1X = 1DPUなので、1回の実行で600DPUを利用

<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/071b0b34-8666-5e7a-8774-29574c74efb2.png" width=100%><br>


- 前ジョブくん(Job_Run_Queuing)の実行
　ここは普通に開始します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/31ade282-9cb4-9ae6-859a-a14dabe1c723.png" width=100%><br>

 - 後ジョブくん(Job_Run_Queuing_waiting)の実行
 　前ジョブくんが実行中のうちに、後ジョブくんを実行開始します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/6d945107-33c3-9f7d-bb30-9ce89dc60b93.png" width=100%><br>
　しばらくして、以下メッセージと共にエラーで終了します。
<font color="red">failed to execute with exception Exceeded maximum concurrent compute capacity for your account: 1000. Please retry after currently running jobs complete.</font>
　
 　ここまでは、従来の挙動でした。
 <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/d3e91e04-ae88-4751-c40f-1016e7f21766.png" width=100%><br>

**キューイング使用**
後ジョブくんにキューイング機能を付けて実行してみます。
 - 後ジョブくん(Job_Run_Queuing_waiting)の設定変更
　・**<font color="red">Job Run Queuing：✓</font>**
　　**※キューイングを有効にすると、Flex execution（フレックスジョブ）、Number of retries（ジョブリトライ）が無効になります**
 <img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/4dd11eda-093f-a77b-13d1-b51476653c61.png" width=100%>

 - 前ジョブくん(Job_Run_Queuing)の実行
　ここは普通に開始します。
<br>

 - 後ジョブくん(Job_Run_Queuing_waiting)の実行
　・前回なら、ここでエラーになりましたが
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/52eaf165-bd62-f297-240a-14538bad0dca.png" width=100%><br><br>

　・今回はWaitingというステータスになっています！
 　　理由も表示してくれています。
　   　　Exceeded maximum concurrent compute
   
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/bf427c9d-42d2-842f-7722-3bce19099051.png" width=100%><br>
　・前ジョブくんの完了を待って、Runningに移行しました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/863d6175-9a22-654e-ac50-1d6466d43a74.png" width=100%><br>
　・何事もなかったかのように正常終了しました。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2737731/63573ce8-0cdb-9827-11fa-45f291351bd9.png" width=100%>

# 所感
 - まとめ、ユースケース
今回のアップデートによって、従来サービスクォータやリソースの利用上限到達によって発生するジョブの異常終了を、回避できるようになりました。

　これにより、想定外の「ジョブ同時実行」や「リソース使用」が発生した場合でも、処理を停止することなく、継続することができます。

　私自身、サブネットのIPアドレス枯渇により、ジョブが失敗した事例は遭遇したことがあります。
 
 ユースケースとして、
　・恒久対応（サブネット拡張やクォータ緩和申請）にリードタイムがかかる場合を考慮して、その間の暫定対応として利用
　・上記に関連して保険として設定
というケースが考えられると思います。

　最大同時実行数やリソースのピークを測定し、ジョブ設計をしっかり行うことで上限に抵触するケースはほぼ避けられると思います。
　ですので、キューイング機能に頼るのではなく、保険的に実装するのが良いと考えました。

 - 気になる点
当然ですが、「キューイングされたジョブ」をトリガーとして動く
後続ジョブやイベントが待機していた場合、伴って後ろ倒しにはなるので、こちらの考慮は必要です。

また、Glue Trigger等で明確に前後関係が作られているジョブ間でしたら、問題ないですが、
「ジョブAの1時間後に、ジョブBを起動」等の実装がされている場合、実行順番が入れ替わる等の事象は発生するので注意が必要です。
本キューイング機能が、「どの程度のジョブを保持して待機させてくれるのか」は気になるポイントですが、今後発表される情報を追いつつ、確認していこうと思います。

# 参考

https://aws.amazon.com/jp/about-aws/whats-new/2024/09/aws-glue-job-queuing/

https://aws.amazon.com/jp/blogs/big-data/introducing-job-queuing-to-scale-your-aws-glue-workloads/

***
株式会社ジールでは、「ITリテラシーがない」「初期費用がかけられない」「親切・丁寧な支援がほしい」「ノーコード・ローコードがよい」「運用・保守の手間をかけられない」などのお客様の声を受けて、オールインワン型データ活用プラットフォーム「ZEUSCloud」を月額利用料にてご提供しております。
ご興味がある方は是非下記のリンクをご覧ください：
https://www.zdh.co.jp/products-services/cloud-data/zeuscloud/?utm_source=qiita&utm_medium=referral&utm_campaign=qiita_zeuscloud_content-area