Remotion の縦動画を個人 VPS でレンダーしている構成

Angla Admin では、日次スコアの縦動画を Remotion で作っています。レンダー先はクラウドの専用ワーカーではなく、いつもの個人 VPS です。

「できること」より、「朝までに手元にあること」を優先した構成です。

なぜ Remotion か

スコア画像は Playwright でも出せますが、尺のある縦動画（TikTok / Shorts 向け）は、フレーム単位で組み立てられる Remotion の方が扱いやすいでした。開示文をフレームに焼き込む、ビートで尺を切る、といった要件とも相性がよいです。

CI と VPS の分担

重い準備と、本番レンダーを分けています。

• CI（GitHub Actions）: next build に加え、Remotion の bundle を作る
• VPS: 保存した bundle を使って mp4 をレンダーする

VPS 側に毎回フルビルドを強いないための分担です。デプロイでは bundle も一緒に載せ、必要なブラウザ／コンポジタの存在確認をしてから PM2 を再起動します。

Playwright の PNG 生成と Remotion の動画は、朝の ingest とぶつからないよう 別レーンで直列化しています。同じマシンでも、同時に全部回すとメモリと時間が足りなくなります。

ingest のあとに待たない

スコアの ingest API は、動画レンダー完了を待ちません。保存が先、レンダーはバックグラウンドです。ingest 側にも時間の予算があるので、動画を await すると設計が壊れます。

朝管理画面を開いたときには、もう「生成済みでダウンロードするだけ」に近い状態を目指しています。失敗してもスコア本体は残る、が前提です。

失敗したときに痛いところ

実害として印象に残っているのは、次のようなものです。

• デプロイの pm2 stop が、レンダー中に当たると DB 上は rendering のまま固まる
• UI のボタンが rendering を見て disabled のままになり、リロードでも回復しない
• 復旧はステータスを failed に戻して再実行、といった運用になる

「長い処理がある時間帯に、ドキュメントだけの push で再デプロイしない」は、痛い目を見てからのルールです。

個人 VPS での限界

専用の動画ワーカーと比べると、同時実行も冗長性も弱いです。その代わり、構成が短く、障害時に SSH で辿れます。全国1本に動画を寄せるなど、本数を減らす判断とセットで成立しています。

半自動の投稿思想は、こちらです。
半自動 SNS コンソール