NetDrive を使う VFX・3D レンダリングスタジオ — ローカルコピー不要のレンダーファーム

読了目安 7 分 use-case google-cloud-storage
Morgan
MorganStaff Engineer
VFX・3D レンダリングスタジオが NetDrive で Google Cloud Storage をドライブとしてマウントし、事前同期なしにレンダーノードがフレームとテクスチャを読み込む方法。

ある中規模の VFX スタジオは、キャッシュされた流体シミュレーション、EXR フレームシーケンス、そして進行中のプロジェクト全体で 30TB を超えて増え続ける共有テクスチャライブラリを Google Cloud Storage に保管しています。レンダーファーム内のすべてのレンダーノードがこのライブラリへの読み取りアクセスを必要としますが、ジョブを開始する前に作業セット全体を各マシンにダウンロードすると、ローカルのスクラッチファイルに使えるはずのディスク容量が無駄になり、同期にかかる時間だけレンダリングが遅れてしまいます。NetDrive でバケットをドライブとしてマウントすれば、事前のコピー手順なしに、各ノードはジョブが実際に触れるフレームとテクスチャだけをオンデマンドで読み取れます。

NetDrive drive manager showing Google Drive, S3 and pCloud mounted as drive lettersMounted clouds appearing as native drives in Windows File Explorer

レンダーファーム全体でクラウドストレージをマウント

NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。

  • 読み取り専用ドライブによりレンダーノードが元アセットに触れないようにする
  • 最大1TBのキャッシュサイズオプションで繰り返しのテクスチャ読み込みを吸収
  • 起動時の自動マウントでユーザーセッションなしにドライブを準備完了状態に保つ
WindowsmacOS
NetDrive をダウンロード →

無料トライアル。永久ライセンスとサブスクリプションプランあり。

事前同期よりオンデマンドアクセスが優れている理由

レンダーファームのノードは通常、同一かつ使い捨て可能なものとしてプロビジョニングされます——どのノードでもどのジョブでも処理できるという前提です。これは、アセットライブラリ全体をローカルディスクに事前同期する方式と相性が悪くなります。ジョブが50台のノードのどれにでも割り当てられうる以上、50台すべてが巨大で常に古くなっていく完全なローカルコピーを持つか、あるいはジョブが始まるたびに同期ステップを実行する必要があり、1フレームあたり数秒しかかからないかもしれないレンダリングに数分の無駄な待ち時間が加わってしまいます。

NetDrive は Google Cloud Storage バケットをネットワークドライブまたは読み取り専用ドライブとしてマウントし、レンダーエンジンからは R:\assets\textures\ のような通常のファイルパスに見えます。フレームやテクスチャはジョブが実際に読み込む時にだけ転送され、NetDrive のキャッシュ機能により、最近使用したファイルはバケットから毎回再取得することなく、同じテクスチャを必要とする次のジョブで利用可能な状態に保たれます。

NetDrive でバケットをドライブとしてマウントするための Google Cloud Storage プロバイダーのロゴ

レンダーノード向けに読み取り専用アセットドライブをセットアップする

  1. NetDrive を開き、Drive Manager で + Add Drive をクリックします。
  2. プロバイダー一覧から Google Cloud Storage を選択します。
  3. ショットライブラリのバケットに限定したサービスアカウントの認証情報を入力します——アセットを消費するだけのノードには読み取り専用の IAM ロールで十分です。
  4. バケット名を入力します。
  5. Drive Type で Read-only drive を選択します。レンダーノードが元のアセットバケットに書き戻す理由はなく、読み取り専用マウントにより誤った設定のジョブが誤って共有テクスチャを上書きする可能性がなくなります。
  6. レンダーノードはログイン済みのワークステーションではなく無人稼働のマシンとして動作するため、Mount on を Boot に設定します。
  7. ドライブ設定でキャッシュサイズを上げます——NetDrive は 100GB から 1TB までのキャッシュサイズ(3.16.589 で追加)をサポートしており、これは1つのシーケンス内の多数のフレームにわたって同じテクスチャセットを繰り返し参照するレンダーノードにとって重要です。
  8. Mount をクリックします。

レンダーノードが読み込める状態でドライブとしてマウントされたクラウドストレージを示す NetDrive Drive Manager

レンダリングを止めずにフレームを書き戻す

読み取りアクセスはテクスチャとシミュレーションキャッシュをカバーしますが、完成したフレームはどこかに保存する必要があります。出力用バケットに対して読み書きでマウントされた2つ目のドライブがこの部分を担当します。NetDrive のバックグラウンドアップロードモードは、完成したフレームをまずローカルキャッシュに書き込み、その後非同期で Google Cloud Storage にアップロードするため、レンダリングプロセスは書き込みのたびにネットワーク I/O で止まることなく次のフレームへ進めます。

クラウドストレージへの非同期書き込みを示す NetDrive のバックグラウンドアップロードキュー

この分離——共有アセットライブラリには読み取り専用、出力にはバックグラウンドアップロード付きの読み書き——により、2つのデータパスが互いに干渉することがなくなります。4K テクスチャを読み込むレンダーノードは、同じ接続のセマンティクスを自身のフレーム出力キューと奪い合うことはありません。

多数のノードへのスケーリング

各ノードが同じバケットを独立してマウントするため、ファームの容量を増やすには、共有ストレージの競合を調整するのではなく、同じ NetDrive ドライブ設定で別のマシンをプロビジョニングするだけで済みます。ジョブの途中でオフラインになるノードがあっても、各ノードは自分自身のローカルキャッシュしか保持していないため、共有ファイルシステムが不整合な状態のまま残ることはありません——バケット自体が唯一の信頼できる情報源であり続けます。

混在環境を運用するスタジオでは、同じバケットが Windows のレンダーノードと macOS のアーティスト用ワークステーションの両方に同一の形でマウントされるため、ショットをレビューするアーティストも、ファームがレンダリングに使ったのと同じパス構造からデータを取得できます。

まとめ

クラウドストレージをドライブとしてマウントすることで、レンダーファームは Google Cloud Storage バケットを通常のローカルパスのように扱えるようになり、読み取り専用マウントが元アセットを保護し、バックグラウンドアップロードがフレーム出力によって次のレンダリングがブロックされるのを防ぎます。基盤となるセットアップについては、Windows で NetDrive を使って Google Cloud Storage をマウントするまたはmacOS で NetDrive を使って Google Cloud Storage をマウントするを参照してください。CI 方式の自動レンダリングパイプラインを運用しているスタジオには、無人ノードが依存する起動時マウントのパターンについて、CI チーム向け S3 テストフィクスチャも役立つかもしれません。

— Morgan, NetDrive

← 記事一覧 フォーラムで議論する →