クラウドレンダリングのコストは、フレーム数やシーンの重さに比例してじわじわと膨らみます。AWS Deadline Cloud の「Wait and Save」は、ジョブの開始タイミングに少し余裕を持たせる代わりに、コンピューティング料金を大きく抑えられるサービスマネージドフリートの実行方式です。本記事では、CG・映像・VFX・建築などでレンダリングジョブをクラウド実行している開発者やインフラ担当者に向けて、Wait and Save の仕組み、サービスマネージドフリートでの設定手順、コスト削減効果の試算、そして向き不向きまでを実践目線で整理します。
Wait and Save とは何か
Wait and Save は、AWS Deadline Cloud のサービスマネージドフリート（Service-managed fleet、以下 SMF）で選べるインスタンスマーケットオプションのひとつです。SMF では、レンダリングを実行するワーカーの調達方法として「On-Demand」「Spot」「Wait and Save」の3つから選択できます。Wait and Save は、余剰の CPU Spot キャパシティを割引価格で活用し、ジョブの開始タイミングに柔軟性を持たせる代わりにコンピューティング単価を引き下げるという考え方です。
EC2 のスポットインスタンスをご存じであれば、概念はイメージしやすいはずです。スポットは余剰キャパシティを安く使う代わりに中断され得る仕組みですが、Wait and Save はその発想をさらに進めたものと捉えられます。AWS の公式ドキュメントでは、Wait and Save を「コスト削減のために遅延スケジューリングを提供し、オンデマンドおよびスポットのリクエストによって中断され得る」方式と説明しています。つまり Spot よりも中断の優先順位が後ろに置かれる代わりに、より深い割引が期待できる位置づけです。
ジョブは投入後すぐに走るとは限らず、キャパシティに空きが出たタイミングで開始されます。AWS は通常24時間以内にジョブが開始されるとしており、実際の待機時間はリージョンや時間帯、空きキャパシティによって変動します。締切まで時間に余裕のあるレンダリングであれば、この「待つ」という選択がそのままコスト削減につながります。
Wait and Save を検討する前に、適用範囲を押さえておく必要があります。最も重要な点は、Wait and Save が CPU ベースのレンダリングのみに対応し、GPU レンダリングには対応していないことです。GPU を必須とするパイプラインでは、この方式は選べません。
また、SMF では特定の EC2 インスタンスタイプを名指しで指定する必要がありません。必要な vCPU 数とメモリ量の範囲を指定しておけば、その要件を満たす CPU インスタンスを Deadline Cloud が自動的に選んでワーカーを起動します。インスタンス選定の運用負荷が下がる一方で、特定タイプに固定したい場合の細かな制御は前提が異なる点に注意してください。
中断についても理解しておきましょう。Wait and Save のワーカーは、オンデマンドやスポットの需要が高まると中断される可能性があります。さらに SMF 全体の仕様として、ワーカーは最大7日、個々のタスクは最大5日で停止します。1つのタスクが極端に長いジョブでは、中断や上限到達によって進捗が失われるリスクがあるため、フレーム単位で分割しておくなどの設計が現実的です。
サービスマネージドフリートでの設定手順
ここからは AWS マネジメントコンソールでの設定の流れを見ていきます。前提として、ジョブを受け付けるキューと、ワーカーを供給するフリートを用意し、両者を関連付ける構成になります。
まず Deadline Cloud コンソールで対象のファームを開き、フリートの一覧から新規フリートの作成に進みます。フリートタイプには「Service-managed」を選び、インスタンスマーケットオプションで「Wait and Save」を指定します。既定では Spot が選ばれているため、ここを明示的に切り替える点が肝心です。続いてサービスアクセス用の IAM ロールを選択します。
次に、起動するインスタンスの要件を定義します。Wait and Save では CPU のみのインスタンスを選び、OS（Linux または Windows）を指定したうえで、vCPU 数の最小と最大、メモリ量の最小と最大を入力します。特定のインスタンスタイプを並べる必要はありません。最大ワーカー数を設定し、ストレージ要件を選んだら、作成済みのキューを関連付けてフリートを作成します。キュー自体は別途作成しておく必要があります。最後にジョブをそのキューへ投入すれば、Wait and Save のワーカーがキャパシティの空き次第で起動し、レンダリングが始まります。
AWS CLI での設定例
繰り返し作成する場合や IaC に組み込みたい場合は、AWS CLI が便利です。フリートの作成は aws deadline create-fleet で行い、構成 JSON の instanceMarketOptions.type に wait-and-save を指定するのがポイントです。値はハイフン区切りである点に注意してください。
aws deadline create-fleet \
--farm-id "$FARM_ID" \
--display-name "render-smf-wait-and-save" \
--role-arn "$FLEET_ROLE_ARN" \
--max-worker-count 5 \
--configuration '{
"serviceManagedEc2": {
"instanceCapabilities": {
"vCpuCount": { "min": 2, "max": 4 },
"memoryMiB": { "min": 512 },
"osFamily": "linux",
"cpuArchitectureType": "x86_64"
},
"instanceMarketOptions": {
"type": "wait-and-save"
}
}
}'作成したフリートはキューと関連付けて初めてジョブを受け取れます。関連付けは create-queue-fleet-association を使います。
aws deadline create-queue-fleet-association \
--farm-id "$FARM_ID" \
--queue-id "$QUEUE_ID" \
--fleet-id "$FLEET_ID"type に指定できる値は on-demand、spot、wait-and-save の3種類です。同じ構成のまま type を切り替えるだけで、コストと中断耐性のバランスを変えられるため、検証と本番で値を使い分けるといった運用がしやすくなっています。
コスト削減効果の試算と実例
実際の削減幅を、AWS 公式ブログが公開している実例で確認します。200フレームの Maya レンダリングを同条件で比較したもので、コンピューティング費とライセンス費の内訳まで示されています。なおリージョンなどの条件は公開情報に明記がなく、ここでは記事公開時点の参考値として扱います。
マーケットオプション | コンピューティング | ライセンス | 合計 |
|---|---|---|---|
On-Demand | $2.09 | $2.86 | $4.95 |
Spot | $0.76 | $2.04 | $2.80 |
Wait and Save | $0.17 | $2.18 | $2.35 |
注目したいのは、コンピューティング費だけを見ると Wait and Save が $0.17 と圧倒的に安く、On-Demand の $2.09 と比べておよそ9割の削減になっている点です。一方で、合計コストにはレンダリングソフトのライセンス費が含まれ、こちらが支配的になります。そのため合計で見た削減率は、On-Demand 比でおよそ5割、Spot 比でおよそ2割弱にとどまります。つまり「コンピュート単価の割引率」と「請求総額の削減率」は別物であり、混同しないことが見積もりの精度を上げる鍵になります。
言い換えれば、Wait and Save の効果が最大化されるのは、コンピューティング費の比重が大きいワークロードです。長尺で大量のフレームを回すプロジェクトほど、コンピュート削減のインパクトが総額に効いてきます。実行状況は Deadline Cloud Monitor で追跡でき、ジョブが Ready から Running へ遷移するタイミングや、作成から開始までの待機時間を確認できます。AWS 公式ブログの実例では、ジョブが実際に走り出すまで約7時間待機したケースが紹介されています。
向いているユースケースと注意点
Wait and Save が向いているのは、開始時刻を柔軟にできるレンダリングです。夜間やオフピークに回すバッチレンダリング、締切までに十分な余裕がある大量フレームのレンダリング、そしてコストを最優先したいプロジェクトが代表例です。こうした用途では「待てること」がそのまま割引として返ってきます。
逆に、向いていないケースも明確です。GPU が必須のワークロードはそもそも対象外です。納期が厳しく即時に実行したいジョブ、レビュー用に素早く結果が欲しい対話的な用途、そして中断時の影響が大きい極端に長い単一タスクは避けるべきです。これらでは On-Demand や Spot、あるいは GPU 対応の構成を検討するほうが安全です。
実務では、すべてを Wait and Save に寄せる必要はありません。締切に余裕のある工程だけを Wait and Save のキューに振り分け、急ぎの工程は On-Demand のキューへ回すといった使い分けが現実的です。CLI なら type の値を変えるだけでフリートを作り分けられるため、ワークフローに合わせて段階的に取り入れていくとよいでしょう。
まとめ
AWS Deadline Cloud の Wait and Save は、ジョブの開始を「少し待てる」レンダリングに対して、コンピューティング単価を大きく引き下げる実用的な選択肢です。CPU ベースのレンダリングに限られ、ワーカーは中断され得るという制約はあるものの、夜間バッチや締切に余裕のある大量レンダリングではコスト効果が期待できます。サービスマネージドフリートを Service-managed かつ Wait and Save で作成し、キューと関連付けるだけで始められる手軽さも魅力です。まずは締切に余裕のある工程から、コンソールや CLI で小さく試し、Deadline Cloud Monitor で待機時間とコストを観察しながら、自分たちのパイプラインに合う配分を見つけていくことをおすすめします。
