EMR Serverlessの新機能「ライブ設定更新」でアプリケーションを止めずに最大容量を変更してみた

はじめに

2026年6月24日、Amazon EMR Serverlessでアプリケーションを停止せずに設定を変更できる「ライブ設定更新」機能がリリースされました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-emr-serverless/

従来、最大容量（maximumCapacity）やカスタムイメージなどの設定を変更するには、アプリケーションの停止→変更→再起動が必要でした。この間、新規ジョブの投入ができず、実行中のジョブがある場合は完了を待つかキャンセルする必要がありました。

今回のアップデートにより、対応する設定についてはアプリケーションをSTARTED状態のまま更新できるようになりました。本記事では、そのうち maximumCapacity を対象に、実行中ジョブを中断せずに変更できるかを確認します。

公式ドキュメントはこちらです。

https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/updating-running-applications.html

検証環境

• リージョン： ap-northeast-1
• EMRリリース： emr-7.8.0
• アプリケーションタイプ： Spark
• ワークロード： PySpark（モンテカルロ法による円周率計算）

検証内容

ワーカー数増加によるスケールアウト効果を観測するため、並列化が容易なモンテカルロ法（円周率計算）をワークロードに採用しました。

ライブ設定変更と既存ジョブの動作確認

maximumCapacity を段階的に変更し、実行中のジョブに影響が出ないことを確認しました。

アプリケーション作成

最大容量をvCPU=8、memory=16GBで作成しました。

aws emr-serverless create-application \
  --name "live-config-update-test-0628" \
  --release-label "emr-7.8.0" \
  --type "SPARK" \
  --maximum-capacity '{"cpu":"8vCPU","memory":"16GB","disk":"200GB"}'

ジョブA投入

アプリケーション起動後、モンテカルロ法ジョブを投入しました。

aws emr-serverless start-job-run \
  --application-id 00xxxxxxxxxxxx2l \
  --name "job-A-montecarlo" \
  --execution-role-arn "arn:aws:iam::XXXXXXXXXXXX:role/emr-serverless-job-role-0628" \
  --job-driver '{
    "sparkSubmit": {
      "entryPoint": "s3://example-bucket/monte_carlo_pi.py",
      "entryPointArguments": ["500000000", "100"],
      "sparkSubmitParameters": "--conf spark.executor.cores=1 --conf spark.executor.memory=2g --conf spark.executor.instances=2"
    }
  }'

maximumCapacity を拡大（8→16 vCPU）

ジョブA実行中に、最大容量を2倍に変更しました。

aws emr-serverless update-application \
  --application-id 00xxxxxxxxxxxx2l \
  --maximum-capacity '{"cpu":"16vCPU","memory":"32GB","disk":"400GB"}'

{
    "application": {
        "applicationId": "00xxxxxxxxxxxx2l",
        "state": "STARTED",
        "maximumCapacity": {
            "cpu": "16 vCPU",
            "memory": "32 GB",
            "disk": "400 GB"
        }
    }
}

アプリケーションはSTARTEDのまま変更が完了し、ジョブAもRUNNINGを維持していました。

ジョブB投入・スケールアウト確認

拡大直後にジョブBを投入しました。ジョブBもRUNNINGになり、CloudWatchメトリクス（名前空間: AWS/EMRServerless）の RunningWorkerCount でワーカー数の変化を確認しました。

CPUAllocatedが9 vCPUに達しており、変更前の上限8 vCPUを超えています。これにより、ライブ更新した新しい上限（16 vCPU）が有効になったことが確認できました。

maximumCapacity を縮小（16→4 vCPU）

ジョブB実行中に、最大容量を4 vCPUに縮小しました。

aws emr-serverless update-application \
  --application-id 00xxxxxxxxxxxx2l \
  --maximum-capacity '{"cpu":"4vCPU","memory":"8GB","disk":"100GB"}'

縮小後もジョブBは中断されずSUCCESSで完了しました。

縮小後のメトリクス推移を確認すると、上限を4 vCPUに縮小した後もワーカー4台・CPUAllocated 7 vCPUで動作し続けていました。

新しい上限（4 vCPU）を超えるリソースが既存ジョブに割り当てられたまま維持されており、今回の検証では、縮小操作によって既存ジョブのリソースが回収されることはありませんでした。

縮小後の上限は以降の新規リソース割り当てに適用されます。ジョブ完了後に GetApplication で確認すると、maximumCapacity は4 vCPU / 8 GBに更新されていました。

所要時間の比較（ライブ更新 vs 従来フロー）

設定変更を含む一連の操作開始からジョブがRUNNINGになるまでの所要時間を比較しました。ライブ更新では UpdateApplication 実行時点から、従来フローでは StopApplication 実行時点から計測しています。

今回の検証では時間差は12秒でした。従来フローのStop/Startが短時間で完了したため、差が小さくなっています。コールドスタート時には差が大きくなる可能性がありますが、本記事では未検証です。

以下、各フローの詳細タイムラインです。

ライブ更新フロー

17:26:40  UpdateApplication (maximumCapacity 変更)
17:26:40  StartJobRun
17:26:52  SCHEDULED
17:27:23  RUNNING

所要時間: 43秒

従来フロー（Stop→Update→Start→Job）

17:41:10  StopApplication
17:41:21  STOPPED          （開始から+11秒）
17:41:22  UpdateApplication
17:41:22  StartApplication
17:41:23  STARTED          （開始から+13秒）
17:41:24  StartJobRun
17:42:05  RUNNING          （開始から+55秒）

所要時間: 55秒

まとめ

EMR Serverlessのライブ設定更新により、maximumCapacity をアプリケーション停止なしで変更できることを確認しました。今回の検証では、拡大・縮小のいずれの場合も実行中ジョブは中断されず、縮小後も実行中だったジョブはSUCCESSで完了しました。

なお、maximumCapacity の拡大は実行中ジョブに自動でリソースを追加するものではなく、アプリケーション全体のリソース上限を引き上げるものです。拡大後に投入したジョブを含めた並行実行により、アプリケーション全体の割り当てリソースが変更前の上限を超えることも確認できました。

ライブ設定更新は、処理フェーズに応じてリソース上限を切り替える運用でも有用です。たとえば、軽量な前処理は小さい上限で実行し、本処理の投入前に上限を拡大するといった場合に、アプリケーションを止めずに変更できる利点があります。