WireGuard 暗号化 · BBR 輻輳制御 · 共有キャッシュ · グローバルに分散したクリエイティブチーム向けの構成です。
現代のクリエイティブ業務はますます分散しています。3D パイプラインには、ニューヨークのアートディレクター、ベルリンのライティングチーム、ソウルのフリーランス look-dev アーティスト、さらに別の大陸の render farm が同時に存在し得ます。これら 4 者が同じギガビット LAN にいるなら render farm へのアクセスは問題になりません。そうでない場合、ワークフローは公共インターネットを通過し、長距離ルーティングのあらゆる癖がスケジュールに現れ始めます。
この種の構成では 3 つの問題が繰り返し起こります。1 つ目はレイテンシです。大陸間の 150〜250 ms の往復時間はリモートデスクトップの感触を変え、レンダーマネージャーやアセットストリーミングプロトコルのおしゃべりさを増幅します。2 つ目はジッターです。国際リンクは多くの場合ぎりぎりで運用されており、パケットタイミングが揺れます。3 つ目は帯域コストと競合です。40 GB のシーンを大陸間リンクで一度引くのは許容できますが、各レンダーノードが自前のキャッシュを持つため 20 回引くのは許容できません。
ローカル render farm はこれらの大半を回避できます。アーティストと同じデータセンターリージョンに既にクラスタを持つチームは、このページの大半が必要ありません。次のいずれかが当てはまるとき、cross-country レンダリングが正しいアーキテクチャ選択になります。
これらのいずれかが当てはまるとき、問いは運用的になります。すなわち、世界の反対側にある render farm を、アーティストのローカルネットワークの一部のように振る舞わせるにはどうするか、という問いです。このページの残りは、Super Renders Farm でこれにどう取り組んでいるかを説明します。
Cross-country リンクは、ひとつずつではなく 4 要素を一緒に適用して最適化します。
顧客エンドポイントから render farm への各接続は WireGuard を経由します。顧客のマシンは WireGuard ピアとなり、メインデータセンターはハブを運営します。暗号化は自動でエンドツーエンドです。顧客は公共インターネット上で平文トラフィックを見ませんし、私たちも見ません。WireGuard は長距離リンクのボトルネックにならない程度に軽量であり、そのオーバーヘッドは従来の IPsec スタックより明らかに小さいです。
Linux カーネルのデフォルト輻輳制御である CUBIC は、ジッターやパケットロスに対して保守的です。ロスを減速のシグナルとして解釈しますが、そのロスが実際の輻輳ではなく断続的な国際ルーティングに由来する場合でもそうします。BBR(Bottleneck Bandwidth and RTT)はリンクの実帯域幅遅延積を測定し、容量がある限りパイプを満たし続けます。安定した大陸間ルートで BBR は同じハードウェアで CUBIC の通常 2〜3 倍のスループットを提供します。ジッターのあるルートでは差はさらに大きくなります。
パケットが WireGuard のようなトンネルを通過するとき、実効 MTU は基盤インターフェースより小さくなります。TCP 接続がトンネルが運べるサイズより大きい MSS を交渉すると、2 つのことが起こります。小さいパケットは通過し、大きいパケットは静かに落とされます。症状はリモートワークでも特に厄介な部類です。SSH も ping も動くのに、TLS ハンドシェイク、RDP セッション、有意なサイズの SMB ファイルコピーがすべてハングします。私たちは WireGuard ゲートウェイで MSS をクランプし、すべての TCP 接続がトンネルが実際に届けられるセグメントサイズを交渉するようにします。
ファーム内部では内部 DNS 解決のために `dnsmasq` を、時刻のために `chrony` を運用します。どちらも静かなインフラ要素ですが、見た目以上に重要です。内部 DNS によりレンダーノードは共有キャッシュを IP アドレスではなく `cache.lan` として参照でき、トポロジーを再配置しやすくなります。時刻同期は大半のレンダーマネージャーとログパイプラインがクロックずれに弱いため重要です。フリート全体から 30 秒ずれたノードは紛らわしいジョブ割り当て挙動を生み出すことがあります。両サービスは内部ネットワークでのみ待ち受け、公共インターネットから直接話しかけられることはありません。
これら 4 要素を組み合わせると、長距離 render farm はリモートマシンというよりアーティストワークステーションの低速 LAN 拡張のように感じられるようになります。どれも珍奇ではありません。価値はこれらをスタックとして適用し、顧客トラフィックが実際に通る経路に合わせてパラメータを調整することにあります。
Cross-country 構成に用いる配備形態はハブアンドスポークトポロジーです。単一の主要データセンターをハブとし、ひとつ以上のセカンダリサイトが site-to-site WireGuard で接続されます。
このトポロジーには、毎回の設置で繰り返し出てくる決定事項がいくつかあります。
エッジとキャッシュは 3 台ではなく 1 台のボックスで動かします。 外部から WireGuard を終端する同じ Ubuntu マシンが、Samba キャッシュ、内部 DNS、時刻サービスも併せてホストします。具体的な理由がない限り、これらの役割を複数マシンに分割しません。ライトサイジングは意図的です。専用キャッシュボックス 1 台は入りと出のネットワークパスがそれぞれひとつで、ルーティングの計算がシンプルになります。障害モードの推論も容易になります。キャッシュが上がっていれば内部サービスは上がっており、落ちていれば内部は何も動きません。この単一シグナルは別々の 3 シグナルよりアラート設定が容易です。
Site-to-site WireGuard がセカンダリ拠点を扱います。 配備が 2 つの物理拠点にまたがるとき — たとえば、メインデータセンターと同一メトロ内の小さな賃借拠点 — の 2 拠点は公共 ISP 上の site-to-site WireGuard トンネルで結ばれます。ホストの視点では両者間のトラフィックは 1 つの大きなサブネットのように見えます。セカンダリ拠点のレンダーグループ B は、グループ A と同じ方法でメイン DC のキャッシュを読みますが、ホップ数が多くなります。
ネットワークは Layer-3 ルーティング可能です。 全ノードは他のノードが直接アドレス可能な実 IP ホストです。特定のレンダーマネージャーを強制しません。Deadline を好むチームは顧客側コーディネーターノードで自前の Deadline リポジトリを動かせますし、別のものを好むチームはそれを使えます。ファームはホスト、ネットワーク、キャッシュ、最適化スタックを提供し、その上のオーケストレーション層は顧客の選択です。
より深いウォークスルーは 運用配備ガイド が手順全体を順に扱い、アーキテクチャ詳細分析 が WireGuard とキャッシュ設計の詳細に踏み込みます。
大陸間帯域は 2 つの意味で高価です。クラウド egress 請求書で金がかかり、アーティストがアセットがパイプを下りてくるのを待つ間に時間がかかります。この点を考えないレンダーフリートは、各ジョブの wall-time のかなりの割合を、建物内の他の場所のキャッシュに既にあるシーンファイルをコールドで引くことに使ってしまうことがあります。
共有キャッシュパターンは最もシンプルで最大のレバーです。メインデータセンターの Samba(SMB3)キャッシュサーバーがプロジェクトアセットを保持します。各レンダーノードはキャッシュをマウントし、シーンファイルを LAN 経由で読みます。新しいアセットがジョブから参照されるとき、キャッシュは顧客のクラウドストレージからそれを 1 回だけ引きます。同じアセットを必要とする以降のノードは LAN コピーから読みます。本来 40 GB のシーンファイルを 20 回引くはずだった 20 ノードフリートが 1 回だけ引くようになります。
原理は素直です。実務では 2 つの設計要素が重要になります。
ノード単位キャッシングを避けます。 各レンダーノードに大きなローカル SSD を与え、好きにキャッシュさせたくなります。10 TB のプロジェクトデータを持つ 20 ノードフリートでは、これは共有無効化ロジックなしの 200 TB の重複ストレージになります。私たちはそれを行いません。共有キャッシュが唯一のキャッシュであり、ノードはローカルディスクをスクラッチ領域として扱い、プロジェクトアーカイブとしては扱いません。
D-day 前にキャッシュを温めておきます。 顧客がプロジェクトが月曜開始であると伝えてきたら、私たちは週末にキャッシュを温めます。月曜の最初のジョブは 20 時間のコールドプルを引き起こす代わりに温まったキャッシュから読みます。これがプロジェクトの最初のレンダーを速く感じさせる最も信頼できる方法です。
ライトサイジングについての注記です。キャッシュボックスは ext4 ファイルシステム上の単一 SATA SSD を使います。キャッシュの場合 — プライマリストレージとは異なり — 単一ディスク構成が正しいトレードオフです。キャッシュは真実の源ではありません。源は顧客のクラウドストレージであり、キャッシュはクラウドから再プルするか、プロジェクトバックアップから rsync で再構築できます。暗号化ボリュームの上に冗長アレイを構築することはコストと複雑性を加えますが、運用上の物語を変えません。キャッシュを失ったノードは一晩の再構築であり、データ損失イベントではありません。キャッシュハードウェアを役割に合わせてサイジングすることは、運用コストを予測可能に保つ最も簡単な方法のひとつです。
単一の cross-country 配備ではなく恒久クラスタを検討するチームには、dedicated cluster options ページでその構成を詳しく扱っています。
Cross-country render farm は普遍的に優れた選択肢ではありません。特定タイプのワークフローには意味があり、ローカルファームに対して予測可能なトレードオフを持ちます。
GPU ノードを対話的に操作する必要があるアーティスト — たとえば Cinema 4D シーンを Redshift とともに開く、IPR プレビューを行う、フルジョブ送信前にフレーミングを行う — の場合、私たちは Moonlight をクライアントとして、Sunshine をホストとして使います。両者ともレンダーノードの GPU 上の NVENC ハードウェアエンコードを使い、ソフトウェアエンコードのリモートデスクトッププロトコルより目に見えて滑らかなストリームを生み出します。チューニングされた長距離リンク上のエンコード済みビデオは、高密度ビューポート操作を含む実作業に使える体験を提供します。同じワークロードを素の RDP では多くの場合そうなりません。Parsec は Sunshine がセッション交渉に困難を抱える稀なケースのためのフォールバックとして構成されています。
チューニング済みの大陸間リンクは通常 150〜250 ms の往復に収まります。数値は地理的隔たりと顧客トラフィックが実際に通る経路に依存します。このページには特定の都市ペアレイテンシを公開しません。それは一般化しないためです。顧客自身の ISP、ピアリング、ローカルホップが、私たちが引用し得るどんな数値とも同じ程度に体験を左右します。計画段階で候補エンドポイントからプローブを実行し、チームが使用する経路の実測値を共有することができます。
私たちの cross-country 配備は、顧客自身のクラウドプラットフォーム上のプロジェクトストレージとともに、現行世代のコンシューマー GPU(RTX 5090 クラスのハードウェア)で 20 ノードクラスタ規模で動作してきました。これは前節のアーキテクチャ選択が意味を持ち始めるおおよその規模です。それより小さなフリートでは、最適化が緩い構成でもある程度通用します。
Cross-country レンダリングは、アーティストが分散していてレンダーフリートはどこかに置く必要があるとき、プロジェクトデータが既に特定のクラウドリージョンにあるとき、ローカルオプションでは提供できない IP 分離されたインフラを顧客が必要とするとき、または GPU の可用性やコストが特定リージョンで有利なときに適合します。
チーム全員がレンダーフリートと同じ事務所や国で働くなら、このページの最適化はおおむね不要なオーバーヘッドです。短いパイプとシンプルなルーティングを持つローカルファームは運用が容易で、BBR や MSS クランプから同じ恩恵は受けません。誠実な対比ポジショニングが大切です。すべてのチームがこのアーキテクチャを必要とするわけではありません。アーティストとレンダーハードウェアが同じリージョンに置ける負荷については、標準の render farm rental options ページがそのケースを十分に扱っています。
一般的に、チューニングの行き届いた長距離リンクは往復 150〜250 ミリ秒の範囲に収まり、正確な数値はアーティストの ISP、トラフィックが通る経路、エンドポイントの地理的位置に依存します。計画段階で候補ワークステーションからプローブを実行し、実際の経路で測定した数値を共有することができます。
BBR 輻輳制御が主な緩和策です。リンクにジッターがあるときスループットを安定に保ち、デフォルト CUBIC のようにパケットロスで崩れることがありません。WireGuard 自体も IPsec トンネルのようにセッション状態を保持しないため、短いネットワーク途切れに寛容です。ISP レベルの障害については、上流経路が戻った時点でトンネルが再接続されます。進行中のレンダージョブは、アーティストの接続状態と無関係にファーム側で実行を続けます。
はい。すべてのリンクが WireGuard で暗号化されます。アーティストエンドポイントからメインデータセンターまで、そしてメイン DC と任意のセカンダリ拠点間の site-to-site までです。公共インターネット上に観察者がチームとレンダーフリート間の平文トラフィックを読める地点はありません。中間トランスポートへの信頼を求めません。暗号化は WireGuard 層にあり、後付けのオプションとして上に追加されたものではありません。
はい。WireGuard ハブは複数のピアを受け入れるため、任意の数のアーティストが任意の数の場所から同じファームに同時接続できます。各アーティストは自分のワークステーションで WireGuard クライアントを実行し、Moonlight を開いて、自分に割り当てられたレンダーノードに接続します。キャッシュと DNS のような内部サービスはフリート全体で共有されるため、別大陸から同じシーンを作業する 2 人のアーティストは同じアセット集合を見ます。
共有 SMB キャッシュ経由で扱います。レンダージョブがまだキャッシュが見たことのないアセットを参照するとき、キャッシュは顧客のクラウドストレージからそれを 1 回だけ引きます。同じアセットを必要とする以降のノードは大陸間リンクではなく LAN 経由でラインレートでキャッシュから読みます。開始日が予測できるプロジェクトでは、プロジェクトの最初のレンダーがコールドプルのカスケードを引き起こすのではなく温まったキャッシュの恩恵を受けるよう、D-day 前にキャッシュを温めておきます。
同じように動作します。地理的隔たりは、キャッシュへの初回プルが同リージョンストレージより時間がかかることを意味するに過ぎません。一度アセットがキャッシュに入れば地理的隔たりは関係なくなります。レンダーノードは LAN から読みます。このシナリオでは通常キャッシュを温め、クロスリージョンプルがプロジェクト開始前に私たちの側で起こり、最初のレンダー中に起こらないようにします。
データ居住はレンダーフリート自体がプロビジョニングされる場所に依存し、これは顧客と事前に計画します。特定の居住要件を持つチームについては、プロジェクトデータがどこに保持されるか、レンダーがどこで生成されるか、ログがどこに保存されるか、契約終了時にデータがどのように消去されるかを議論する必要があります。これは単一のはい/いいえの回答ではなく計画の対話です。具体的な事情については当方にご連絡ください。
レンダー自体は継続します。レンダージョブはアーティストのトンネル状態と無関係にファーム側で実行されます。ジョブが配信されると、アーティストは完全に切断してもフレームは生成され続けます。トンネルが復旧すると、アーティストは WireGuard ピアを再構築し、Moonlight 経由で同じセッションに再接続します。レンダー途中のトンネル切断のもっとも一般的な実用上の影響は、切断の間アーティストが進行を実時間で監視できないことです。レンダー自体は再起動しません。
