この記事はCodex製です。
##依頼内容と課題
専用Web画面で本番約1分の動画を10本生成しようとしても、何が起きているか分からないという報告を受けた。 確認時の空き容量は約6.1 GiBで、本番10本の開始条件約9.3 GiBを満たしていなかった。 既存画面は容量不足でボタンを無効化し、工程表示も生成中かどうかに限られていた。
##アプローチ
容量不足をボタンの近くに常時表示し、開始操作にも不足量を含む応答を返す。 受付ID、工程、探索試行数、描画フレーム数、検査済み作品数、経過時間、更新時刻、エラーを表示する。 進捗をジョブ単位のファイルへ保存し、CLIと日次処理からも同じ情報を更新する。 ブラウザーは2秒間隔で取得し、通信失敗時は最後に取得した状態であることを示す。 プロセスが消失した場合は停止として表示し、再開操作を提供する。 作曲などの数値進捗がない工程には、推測の進捗率を付けない。
##アウトプット
生成画面、API、生成器、進捗読み取り、回帰テスト、運用説明を更新した。 容量不足で処理を起動しないこと、フレーム進捗の読み取り、プロセス消失、既存の動画配信・認証境界を自動テストで検証する。 自動テスト16件が通過した。実際の画面で本番10本の容量エラーを確認し、動作確認用10本は2分26秒で完了した。サーバー停止中の接続エラー表示、再起動後の進捗復元、10本の完了表示も確認した。本番10本の再生成は容量不足のため実施していない。
現行生成器のCloudflare Workers移植は見送った。 生成器はApple Metalとネイティブffmpegを使う。 Workersのメモリー上限は128 MBで、有料プランでもCPU時間は最大5分である。 Cloudflare Containersもlinux/amd64向けであり、Metal版をそのまま移せない。 この実装には、生成をMacまたは別のGPUワーカーへ置き、Web制御をWorkers、完成動画の保存を非公開R2へ分ける構成が適すると判断した。これは現行実装と公式仕様を照合した設計上の判断であり、クラウド版の実測結果ではない。 今回はクラウドへのデプロイやR2バケットの作成は行っていない。