お世話になっております。
資料を読み込んでいただきありがとうございます。以下にご質問への回答を記載いたします。
1. ZenCookのスナップショットに関しまして
a. ローカルで確認する場合は…のどちらかの流れになるであっていますでしょうか?
はい、合っています。
「スナップショットをZenLocalへインポート、ZenStreamingを使用してステージング工程をスキップして実機から直接ロードしながら実行する」は、「Snapshotをそのまま実機確認するケース」で、Cookも実行しないため、高速な起動で特定のSnapshotの状況を確認することができます。
「スナップショットをZenLocalへインポート、ローカルでインクリメンタルクックとステージング、作成されたStagedBuildsを使用して実行する」は、「ローカルの変更をIncremental Cookによって最短のクックで反映して実機確認するケース」、ローカルの変更を高速に確認することができます。
上記はZenServerを使用した確認方法の"理想的な使い方"(特に前者)ですが、 もし上記につけ加えるとすれば、「提出に近い.pak 実機確認するケース」として、Import後に、-pak -iostore -stage (-skipcook) とすることで、oplog から コンテナファイルを作成して、「ZenStreaming を使用しない、コンテナファイルでの実機確認」をすることもできます。
b. もしStageBuilds自体を共有したい場合には、今まで通りNAS等でStageBuildsフォルダを丸ごと共有するという形になりますか?
はい、提出に近い確認なら、Zen Streaming を使用せずに、従来どおり -pak -iostore の StagedBuilds を NAS 共有する運用は今も有効です。
2. LocalDDCの必要性について
ご認識されている理解で正しいですが、プロジェクトによっては外して頂いても問題はありません。現在は後方互換性を維持することを目的として(UE5内においてもZenLocalがデフォルト有効化されたのはUE5.4であり、デフォルトで消してしまうことで何らかの弊害が出る可能性があるため)、DefaultGraphからは削除されずに残っています。社内で以下のようにファイルシステムDDCを使用していないケースもありました。
[DerivedDataCacheGraphs]
; Disable use of filesystem shared DDC entirely within Epic. We use zen shared DDC instead now.
Default=(ProjectPak, EnginePak, ZenLocal, ZenShared, Cloud)
DerivedDataBackendGraph=(ProjectPak, EnginePak, ZenLocal, ZenShared, Cloud)
実際に「Zenではキャッシュできないものがあるか」といった観点でいえば特に無いのですが、InstalledEngineやUEFNなど一部のZenServerがStagedされないケース、ZenServer に接続できない環境のフォールバック、既存の .udd 資産を移行期に読みたい場合(ファイルシステムDDCを使用)への対処として、残してあります。
3. ZenStorageをNASに置く方法
NASにZenStorageを置くのは非推奨です(p22「クラウド同期フォルダ‧ネットワークドライブは厳禁」の内容がそれに該当する文面です)。技術的な理由としては、ZenServerがファイルシステムのブロッククローン(CoW)に強く依存している点が大きいです。コマンドがCoW前提でテストされています。ネットワークファイルシステム上ではこの特性が失われるため、ZenData\cache があれば吸収できるという設計にはなっていません。
a. ZenServerはPCで運用するとしてもデータの置き場をNASにするような運用はアリなのでしょうか?
上記理由により「なし」です。ZenSharedを立てたくない場合は、ZenSharedを外してSharedDDCをNASにする運用も1つの方法かもしれませんが、弊社ではこのような運用は未検証です(理論上は動作するはずです)。
b. Epic様の方では通常のPCでZenServerを運用してZenStorageもPC内のSSDで運用しても問題ない状態なのでしょうか?
この質問は非常に良い観点です。公開された資料では、オフィスの共有PC上(ここで述べる"通常のPC"上)にZenSharedを立てて運用し、ZenStorageもPC内のSSDで運用することを期待しています。実際に、これは一般的に想定される運用で、小~ある程度の規模のプロジェクトでは問題なく運用できるはずです。
弊社では、複数の拠点でかつ大人数で開発しているため、やや特殊な状況です。各リージョンのオフィス近傍のデータセンターにあるサーバ、またはクラウドインスタンス上のサーバーを Zen Sharedとして運用しています。そのため、多くのプロジェクトで推測される開発環境の条件から外れる(設備構築や運用コストの面で一般的ではないため)ことからそのような運用を記載していません。
アクセス集中によるパフォーマンスの懸念をなされているようでしたら、ネットワークを1GbEなら10GbE化することを検討してみてください。データセンターのVMは10GbE以上が普通ですが、オフィスのPCは1GbEのことが多く、島ハブを経由していればさらに細くなります。チーム全員のDDC要求が集中する用途なので、このボトルネックは想定されうる事象の1つとなります。アクセスが集中しすぎると DeactivateAt=60 によりZenSharedとの自動切断が頻発するため、ネットワーク環境を強くするか、サーバーを強くするか、をまずはご検討頂くことになるかと思います。
[Attachment Removed]