スケーリング

セルフホスティングの Nodaro のスケーリングとは、そのプロセスを複数のコンテナで動かすことです。デフォルトの Compose 構成では、API、ワーカー、オーケストレーター、Web サーバーのすべてを 1 つのコンテナで動かします。アクティブユーザーが 5 人程度までなら、この構成で問題ありません。それより多い場合は、ワーカーを専用のコンテナで動かします。各コンテナは 1 つの Redis、1 つのデータベース、1 つのストレージバケットを共有し、Redis のキューだけを通じて連携します。

プロセス

イメージの起動スクリプト /app/start.sh は、/app/backend から次のプロセスを並行して起動します。

起動スクリプトは、単一のプロセスだけを動かすコンテナでは行われない、次の 4 つの処理も行います。

• API の前段で、ポート 3000 の Web サーバーを動かします。
• 同梱のスタックでは、マイグレーションを適用します。
• INTERNAL_ORCHESTRATOR_SECRET が設定されていない場合は、その値を生成します。
• 同梱のスタックでは、暗号化キーを生成します。

プロセスを分割する前に、イメージ内のスクリプトを読んでください。

一般的な分割例

• API コンテナ 1 つ：server.js を実行します。
• メディアワーカーのコンテナを複数：それぞれ、デフォルトの VIDEO_WORKER_CONCURRENCY=50 のままで問題ありません。
• レンダリングワーカーのコンテナ 1〜2 つ：それぞれ専用のマシンで動かします。
• オーケストレーターのコンテナ 1 つ。

コンテナどうしが直接通信することはありません。すべてのコンテナが同じ Redis、Supabase、ストレージを使い、Redis が唯一の連携ポイントになります。

すべてのコンテナで共有する必要があるもの

同時実行数

Compose ファイルは、.env のこれらの変数をコンテナに渡しません。必要なサービスごとに、environment: に追加してください。

実行の各ノードにかけられる時間は最大 90 分、実行全体では最大 120 分です。独自の制限時間を宣言するノードには、代わりにその時間が割り当てられ、実行全体の上限も同じだけ延びます。EDL 適用（Apply EDL）はそのようなノードで、制限時間はレンダリングする編集の内容によって決まります。

Redis の高可用性

ジョブキューは、Redis のクラスターモードに対応しています。REDIS_URL に、クラスターのエンドポイントか Sentinel の URL を設定してください。

API は、キューのほかに、小さな共有キャッシュも Redis に保存します。これにより、複数の API コンテナが、時間のかかる同じプロバイダーの処理をそれぞれ繰り返さずに済みます。現在キャッシュしているのは、HeyGen のアバターとボイスのカタログ（約 4 MB）です。1 つのコンテナが HEYGEN_CATALOG_REFRESH_HOURS（デフォルトは 24）時間ごとに、ロックをかけてカタログを更新し、ほかのコンテナは 30 秒ほどで新しいコピーを取り込みます。ここにあるものは、すべてキャッシュです。Redis に接続できない場合、各コンテナは自身のメモリを使い、失われたエントリーは次回の起動時にプロバイダーから再取得されます。

2 つの環境で 1 つのデータベースを使う

ステージング用のコピーなど、2 つ目の環境を、同じ Supabase プロジェクトと専用の Redis に接続できます。その場合は、環境ごとに異なる RUNTIME_ENV を設定してください。Railway では、RAILWAY_ENVIRONMENT_NAME がすでにこの役割を果たします。

各実行には、その実行を引き受けたオーケストレーターが属する環境の名前が記録され、各環境のクリーンアップ処理は、自分の実行だけを確認します。名前が区別されていないと、各環境は相手の環境のジョブを自分の Redis で探し、見つけられないため、正常な実行を Execution orphaned で失敗として扱ってしまいます。環境が名前を記録するようになる前に始まった実行には、名前がありません。これらの実行は、production という名前の環境が処理します。

ストレージのライフサイクル

Nodaro は、保存したメディアを自動では削除しません。ファイルをキーで参照するだけです。古いメディアを期限切れにするには、90 日後に削除するなどのライフサイクルルールをバケットに追加します。ルールには video-analysis-tmp/ プレフィックスも含めてください。このプレフィックスには分析用の一時ファイルが保存されますが、セルフホスティング環境には、それらを削除するクリーンアップジョブがありません。

Railway でのコンテナの停止

Railway では、RAILWAY_DEPLOYMENT_DRAINING_SECONDS で、置き換えられるコンテナに停止シグナルを送ってから強制停止するまでの時間を設定します。メディアワーカーは、その時間から 5 秒を引いた時間だけドレインします。そのため、時間のかかるモデルの呼び出しも、ジョブが新しいコンテナに移る前に完了して保存されます。未設定の場合、ワーカーは 25 秒間ドレインします。