AWS Deadline Cloud のジョブを意図的に失敗させようとしたら意外と難しかった話
はじめに
別記事 AWS Deadline Cloud の AI トラブルシューティング機能を試してみた で、Deadline Cloud アシスタント機能を検証しました。アシスタントは失敗したジョブを分析する機能なので、検証のためには「失敗するジョブ」が必要です。これが思いのほか難しい作業でした。
結論を先に書くと、Blender のレンダリングジョブを意図的に失敗させようと複数のシナリオを試しましたが、Blender 自体や Deadline Cloud の仕組みが想像以上にエラーを吸収してくれて、なかなか FAILED 状態にできませんでした。最終的に Conda パッケージ指定を壊すことでようやく失敗させられました。
本記事はその試行錯誤の記録であり、結果として AWS Deadline Cloud のサービスマネージドフリート (以下、SMF) と Blender 用アダプターの堅牢さを逆説的に紹介する内容になっています。
用語
- Blender サブミッター: ローカルの Blender に組み込むアドオン。ジョブを Deadline Cloud に投入する
- BlenderAdaptor: ワーカー側で Blender を起動・制御する仕組み
- サービスマネージドフリート (SMF): AWS が管理するワーカーフリート
検証環境
- リージョン: ap-northeast-1
- Deadline Cloud のファーム・キュー・SMF を作成済み
- ローカル環境: macOS, Blender 5.0, Blender サブミッター
- ジョブ投入は Blender サブミッターまたは Deadline Cloud CLI
対象読者
- Deadline Cloud を使い始めて挙動を把握したい方
- Deadline Cloud アシスタントを試したいが、検証用の失敗ジョブが用意できなくて困っている方
- レンダーファームの運用を検討していて、エラー時の挙動が気になる方
参考
- AWS Deadline Cloud
- AWS Deadline Cloud User Guide
- aws-deadline/deadline-cloud-for-blender (GitHub)
- Conda queue environment - AWS Deadline Cloud User Guide
失敗しなかったシナリオ
シナリオ A: テクスチャ欠落
マテリアルが参照する画像ファイルを欠落させれば、レンダリングが失敗するはずだと予想しました。
しかし結果はジョブ SUCCEEDED でした。Blender はピンク色のフォールバックテクスチャを使ってレンダリングを完遂し、出力 PNG を S3 にアップロードしました。
CloudWatch のログを抜粋します。
cycles | ERROR Image file '/sessions/.../textures/icon_hige.png' does not exist.
01:28.575 render | Saved: '/sessions/.../output/ViewLayer_Camera_Renamed_output_0001.png'
ERROR と書かれているのに、その後でレンダリング結果が保存されています。Blender の Cycles レンダラーは欠落アセットを非致命的エラーとして扱うようです。レンダリング結果が一部欠けても出力を得られる方が、現場では価値が高いという設計思想なのでしょう。
シナリオ B: カメラ名のリネーム
ジョブパラメータ Camera のデフォルト値は Camera です。シーン内のカメラ名を Camera_Renamed に変更すれば、パラメータと不一致になり失敗するはずだと予想しました。
しかし結果はジョブ SUCCEEDED でした。Blender サブミッターがシーン内のカメラ名を読み取って、そのままパラメータに渡してくれたためです。
Performing action: {"name": "camera", "args": {"frame": 1, "camera": "Camera_Renamed"}}
リネーム後の名前 Camera_Renamed がそのまま渡されています。
なお、全カメラを削除する手段も試しましたが、サブミッター側のバリデーションで There are no renderable cameras in the scene. と弾かれて投入できませんでした。サブミッターは、アーティストが意図せずミスをしないように整合性を保ってくれる仕組みになっているようです。
シナリオ C: StrictErrorChecking パラメータの有効化
ジョブテンプレートには StrictErrorChecking というパラメータが定義されています。デフォルトは false ですが、これを true にすればテクスチャ欠落のような ERROR で失敗するはずだと予想しました。
しかし結果はジョブ SUCCEEDED でした。テンプレートを読み込んで原因を確認したところ、StrictErrorChecking は parameterDefinitions で宣言されているものの、実際に Blender に渡される init-data の内容には含まれていませんでした。パラメータが UI 上で表示されても、テンプレート本体で参照されていなければ無効になります。
シナリオ D: Blender 起動時 Python スクリプトでの raise
.blend ファイルに use_module=True で埋め込んだ Python スクリプトに raise RuntimeError を仕込めば、Blender 起動時にエラーが発生して失敗するはずだと予想しました。
ローカルの Blender ではエラーが発生してレンダリングが止まります。
% /Applications/Blender.app/Contents/MacOS/Blender /path/to/test.blend
00:00.631 blend | Read blend: "/path/to/test.blend"
scripts disabled for "/path/to/test.blend", skipping 'startup_error.py'
00:04.871 blend | Read blend: "/path/to/test.blend"
ERROR: Required plugin custom_renderer_addon is not installed
Error in bpy.app.handlers.render_init[0]:
しかしワーカー側ではジョブが SUCCEEDED 扱いになりました。
原因として、いくつかの可能性が考えられます。ワーカー側は BlenderAdaptor 経由で Blender を独自に起動するため、起動シーケンスがローカルとは異なります。また、.blend ファイルに埋め込まれた自動実行スクリプトはセキュリティ機構によりスキップされる可能性があります。仮にスクリプトが実行されたとしても、BlenderAdaptor がそのエラーをどう扱うかに依存します。
なお、ローカルの Blender で初回起動時には For security reasons, automatic execution of Python scripts in this file was disabled と表示されました。
Permanently allow execution of scripts を有効にすればローカルでは実行されますが、ワーカー側ではこの制約はそのまま残ると考えられます。
唯一確実に失敗させられた方法
ここまで紹介した 4 つのシナリオではすべてジョブが SUCCEEDED になりました。最終的に確実に失敗させられたのは、ジョブパラメータの CondaPackages に存在しないバージョン (例: blender=99.0.*) を指定する方法です。SMF はジョブ実行前に Conda 環境を構築します。ここで存在しないパッケージを指定すれば、レンダリング以前の段階で確実に失敗するはずです。
ジョブバンドルの parameter_values.yaml で CondaPackages を以下のように設定したうえで、Deadline Cloud CLI で投入しました。
{
"parameterValues": [
{
"name": "CondaPackages",
"value": "blender=99.0.* blender-openjd=0.6.*"
}
]
}
deadline bundle submit ./failed-job-bundle --yes --known-asset-path /path/to/blender-project --name "test-assistant-failure"
ジョブを投入して数秒で FAILED 状態になりました。
PackagesNotFoundError: The following packages are not available from current channels:
- blender=99.0*
openjd_fail: Conda environment setup failed with exit code 1.
考察
試行錯誤を振り返って、いくつか気づいた点をまとめます。
BlenderAdaptor は単なるコマンド実行ではなく、Blender のレンダリングエンジンと連携してエラーを吸収する仕組みになっているようです。Cycles の ERROR 出力はジョブの成否に直接影響しません。StrictErrorChecking のような明示的な仕組みが用意されているように見えますが、現状のテンプレートでは効果がありませんでした。
これらはアーティストの作業中断を防ぐ設計思想として理にかなっています。レンダリング結果が一部欠けても出力を得られる方が、現場では価値が高い場面も多いはずです。一方、本当に失敗扱いにしたい場合 (たとえばエラー検知の仕組みを別途構築したい場合) は、Conda 環境レベルで止めるか、独自のジョブテンプレートで失敗条件を組み込むなどの工夫が必要になります。
まとめ
AWS Deadline Cloud のジョブを意図的に失敗させようと試したところ、想像以上に難しい作業でした。テクスチャ欠落、カメラ名のリネーム、StrictErrorChecking パラメータの有効化、Python スクリプトでの raise はいずれも失敗扱いにならず、Blender や Deadline Cloud の堅牢な仕組みに吸収されました。最終的に Conda パッケージレベルで壊すことでようやく FAILED 状態に到達できました。Deadline Cloud を利用する方の参考になれば幸いです。
