# Amazon EMR on EKS、ジョブの同時実行数をついに制御できるようになったよ！

こんにちは、しぃちゃんだよ！今日は Amazon EMR on EKS に届いた、地味だけどすごく実用的なアップデートを見つけちゃったから、みんなに紹介するね！

## なにが発表されたの？

AWS の What's New で、Amazon EMR on EKS に「ジョブラン admission control(受付制御)」が追加されたことが発表されたよ。

Amazon EMR on EKS は、Apache Spark や Flink みたいなオープンソースのビッグデータフレームワークを AWS の EKS(Elastic Kubernetes Service)クラスタ上で動かせるサービスなの。ジョブは「仮想クラスタ」(EKS クラスタ上の namespace にマッピングされる論理的な単位)に投げると、パッケージング・スケジューリング・実行までを EMR on EKS がやってくれる仕組みだよ。

今回のアップデートで、StartJobRun API 由来のジョブ同時実行数制御と、バックプレッシャー(混雑時に受付を絞る仕組み)のシグナルがサポートされたよ。

## 今までどうだったの？

これまでは仮想クラスタに同時実行数の制限がなかったから、複数チームが同じ共有 EKS クラスタにジョブを投げ込むマルチテナント環境だと、誰かの大量ジョブがクラスタのリソースを食い尽くしてしまう「noisy neighbor(うるさい隣人)」問題が起きやすかったの。大事なジョブがリソース不足でスケジューリングに失敗する、なんてこともあったんだって。

## これで何が変わるの？

今回の機能で、仮想クラスタごとに「同時に何個までジョブを走らせていいか」「待機キューに何個まで積んでいいか」を細かくコントロールできるようになったよ。共有クラスタを過負荷から守れるので、需要が急増しても大事なワークロードを予測どおりに動かし続けられるの。キューが溢れたときはリクエストを弾いて別クラスタに逃がす、みたいなグレースフルな制御もできるようになったよ。

## 深く潜ってみよう

仮想クラスタには、任意設定として次の 2 つの上限を設定できるよ。

- `maxConcurrentJobRuns`: 同時に実行できるジョブ数の上限
- `maxInQueueJobRuns`: PENDING(まだ受付済みだけど実行前)/ SUBMITTED 状態で待機できるジョブの最大キュー深度

動きとしてはこんな感じ。

- キューが上限に達しているときに `StartJobRun` を呼ぶと、HTTP の `ValidationException` が返ってくる
- これを受けて、呼び出し側は新しいジョブをグレースフルに諦めたり、別の EKS クラスタにルーティングし直したりできる
- `DescribeVirtualCluster` を呼べば、現在設定されている上限値と、いま実行中・待機中のライブなジョブ数をいつでも確認できる
- デフォルトでは両方とも制限なし。つまりオプトイン方式で、既存のワークロードは何もしなければ今までどおり動く

## まとめ

- 仮想クラスタ単位で `maxConcurrentJobRuns`(同時実行数)と `maxInQueueJobRuns`(キュー深度)の 2 つの上限を設定できる
- 上限に達すると `StartJobRun` が `ValidationException` を返すので、呼び出し側でグレースフルに弾いたり別クラスタへ逃がしたりできる
- `DescribeVirtualCluster` で現在の設定値とライブのジョブ数を確認できる
- デフォルトは無制限(オプトイン)なので、既存ワークロードへの影響はなし

複数チームで同じ EKS クラスタに Spark や Flink のジョブを投げ込んでいるようなマルチテナント環境を運用しているエンジニアに、特に刺さるアップデートだよ！