AWS Batch に優先順位を自分で決められる配分戦略が追加されたので図解で整理してみた
はじめに
AWS Batch のコンピューティング環境にインスタンスタイプの優先順位を自分で指定できる配分戦略が 2 つ追加されました。オンデマンド向けの BEST_FIT_PROGRESSIVE_ORDERED と、スポット向けの SPOT_CAPACITY_OPTIMIZED_PRIORITIZED です。この 2 つの戦略がどういったものなのか、図解を交えて整理しました。
確認結果
- 新しい戦略は優先順位を制御したい特定ニーズ向けの追加オプション
- 優先順位は専用パラメータではなく
instanceTypesリストに書いた並び順そのもので指定する - BEST_FIT_PROGRESSIVE_ORDERED は EC2 オンデマンド専用で順番を厳密に守る
- SPOT_CAPACITY_OPTIMIZED_PRIORITIZED はスポット専用で、空きキャパシティを最優先しつつ順序をベストエフォートで反映する
- スポットで順序を厳密に守る戦略は存在しない、容量が逼迫すれば優先順位より空いているプールが優先される
なにが嬉しいのか
配分戦略に優先順位を指定できると次のようなケースで効果を発揮します。
- 新世代インスタンスファミリーを優先しつつ、確保できなければ旧世代を使う（例:
c7aを優先しc6aにフォールバック） - ライセンス制約や性能検証の結果から、特定のインスタンスタイプを他より優先して使いたい
今ある配分戦略まとめ
AWS Batch の配分戦略は今回追加された 2 つを含めて現在 6 種類あります。対象コンピューティングリソース、選択基準、優先順位指定の有無で整理すると次のとおりです。
| 戦略 | 対象 | 選択基準 | 優先順位指定 |
|---|---|---|---|
| BEST_FIT | 制限なし（Fargate 除く） | 一番安いインスタンスタイプを優先。空き容量がなければ待機 | なし |
| BEST_FIT_PROGRESSIVE | 制限なし（Fargate 除く） | ジョブの要件を満たす範囲内で vCPU あたりコストが最小のタイプを優先 | なし |
| BEST_FIT_PROGRESSIVE_ORDERED（NEW） | オンデマンド | 指定した並び順でインスタンスタイプが選ばれる | あり（厳密） |
| SPOT_CAPACITY_OPTIMIZED | スポット | 中断されにくさのみ | なし |
| SPOT_PRICE_CAPACITY_OPTIMIZED | スポット | 価格と中断されにくさの両方を考慮（推奨） | なし |
| SPOT_CAPACITY_OPTIMIZED_PRIORITIZED（NEW） | スポット | 中断されにくさを最優先、順序はベストエフォート | あり（ベストエフォート） |
※ allocationStrategy は Fargate 起動には適用されません。
BEST_FIT_PROGRESSIVE_ORDERED とは
BEST_FIT_PROGRESSIVE_ORDERED は、EC2 オンデマンドインスタンス専用の配分戦略です。優先順位を指定する専用のパラメータはなくinstanceTypes の並び順がそのまま優先順位になります。
既存の BEST_FIT_PROGRESSIVE と異なり、instanceTypes リストに書いた順序を厳密に守ります。リストの先頭から順にインスタンスタイプが評価され、要件を満たすタイプが見つかった時点でそのタイプが採用されます。
リストにファミリー名（例: m7a）を指定すると、そのファミリー内のサイズは BEST_FIT_PROGRESSIVE と同じロジックが使われます。ジョブの要件に最も合うサイズが優先され、それで足りなければより大きいサイズにフォールバックします。ファミリー名と、そのファミリーに属する明示的なインスタンスタイプを両方リストに含めた場合は挙動が異なります。明示的なタイプはリスト上の位置を保ったまま、ファミリー展開の対象から除外されます。たとえば ["m7a.4xlarge", "m7a", "m6a"] と指定すると、m7a.4xlarge は常に最優先で採用され、m7a ファミリーの展開からは除外されます。
公式ドキュメントでも、明示的な優先順位付けを望む利用者向けの上級オプションとしてこの戦略を位置づけています。「ですよね」という感じはします。
This is an advanced allocation strategy only for customers who want to control which instance types are preferred during scaling.
SPOT_CAPACITY_OPTIMIZED_PRIORITIZED とは
SPOT_CAPACITY_OPTIMIZED_PRIORITIZED は、スポットインスタンス専用の配分戦略です。
容量（中断されにくさ）を最優先し、指定した順序はベストエフォートで反映されます。1 つは容量プールが同程度に空いている通常時、もう 1 つは特定プールの容量が逼迫している時のインスタンスタイプ選択のイメージです。
容量プールが同程度に空いている場合は、instanceTypes リストの優先順位どおりにインスタンスタイプが選ばれます。一方、特定のプールの空き容量が少なくなると、優先順位よりも中断されにくさが優先され、最も空いているプールが選ばれます。スポット向けの他の戦略と同じ考え方です。
こちらも公式ドキュメントで、優先順位を反映させたい利用者向けの上級オプションとしてこの戦略を位置づけています。
This is an advanced allocation strategy for customers who want to influence instance type selection during scaling. This strategy optimizes for capacity first, and honors instance type priorities on a best-effort basis (priorities are honored when they do not significantly reduce available Spot capacity).
使い分けについて
配分戦略の選択方法（自動選択／ユーザー定義順序）と、オンデマンドかスポットの 2 軸で整理したものです。「AWS におまかせで最適化したい」なら既存の BEST_FIT_PROGRESSIVE や SPOT_PRICE_CAPACITY_OPTIMIZED のままで十分です。「順序を自分で決めたい」場合に新戦略を検討しましょう。
スポットインスタンスを使う場合、公式ドキュメントは引き続き SPOT_PRICE_CAPACITY_OPTIMIZED を第一候補として推奨しています。
We recommend that you use SPOT_PRICE_CAPACITY_OPTIMIZED rather than SPOT_CAPACITY_OPTIMIZED in most instances.
なお、スポットで順序を厳密に守る戦略は存在しません。SPOT_CAPACITY_OPTIMIZED_PRIORITIZED でも容量が逼迫すれば優先順位は無視され、最も空いているプールが選ばれます。
まとめ
AWS Batch にインスタンスタイプの優先順位を自分で指定できる配分戦略が 2 つ追加されました。BEST_FIT_PROGRESSIVE_ORDERED はオンデマンド専用でリスト順を厳密に守ります。SPOT_CAPACITY_OPTIMIZED_PRIORITIZED はスポット専用で、容量を最優先しつつ順序をベストエフォートで反映します。どちらも「AWS におまかせ」ではなく順序を自分で決めたい利用者向けの上級オプションという位置づけです。
おわりに
スポットの配分戦略は SPOT_PRICE_CAPACITY_OPTIMIZED が定番という認識でしたが、特殊な要件があるときに優先順位を制御できる選択肢が増えました。オンデマンドの方は、ファミリー指定（c7a、c6a のような）で使うと扱いやすそうです。
