Zenシリーズに関する質問

先日はDevDay開催及びセッションの方ありがとうございました。

開発効率化のための Zen 利用ベストプラクティスのスライドの内容に関していくつか質問がございます。

​

1) ZenCookのスナップショットに関しまして

スナップショットはクック済みのデータということなのですが、あくまでクック済みデータなのでローカルで確認する場合は

  • スナップショットをZenLocalへインポート、ZenStreamingを使用してステージング工程をスキップして実機から直接ロードしながら実行する
  • スナップショットをZenLocalへインポート、ローカルでインクリメンタルクックとステージング、作成されたStagedBuildsを使用して実行する

のどちらかの流れになるであっていますでしょうか?

もしStageBuilds自体を共有したい場合には、今まで通りNAS等でStageBuildsフォルダを丸ごと共有するという形になりますか?

​

2) LocalDDCの必要性について

ZenLocalとLocalDDCが重複して動作している理由は何か理由があってそうなっているのでしょうか?

機能的には重複しているものなので、SSDのスペースや書き込みの多重化を省くうえでもLocalDDCをオフにしたほうが良いのかなと思ったのですが、しないほうが良い理由などあるのでしょうか?(ZenではフォローできないものがLocal/SharedDDCには存在するのでしょうか?)

​

3) ZenStorageをNASに置く方法

ZenServerはWindowsとLinux版があり、Windows版がProduction Readyという状態かなと思うのですが、ZenServerをPCで運用しているときのアクセス集中によるフォーマンスの低下を懸念しています。

ZenServerはPCで運用するとしてもデータの置き場をNASにするような運用はアリなのでしょうか?

ZenServerの仕様を見ますと細かいファイルアクセスが多そうなので、ある程度はホストPCにキャッシュが必要かなと思うのですが(ZenData\cache)、キャッシュがあればZenStorageの保存先はNASでも問題ないのでしょうか?

Epic様の方では通常のPCでZenServerを運用してZenStorageもPC内のSSDで運用しても問題ない状態なのでしょうか?

以上3つ質問になります。

よろしくお願いいたします。​

[Attachment Removed]

お世話になっております。

資料を読み込んでいただきありがとうございます。以下にご質問への回答を記載いたします。

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]

ご回答ありがとうございます。

1. ZenCookのスナップショットに関しまして

> 「提出に近い.pak 実機確認するケース」として、Import後に、-pak -iostore -stage (-skipcook) とすることで、oplog から コンテナファイルを作成して、「ZenStreaming を使用しない、コンテナファイルでの実機確認」をすることもできます

こちらも検討はしたのですが、ローカルでの再ステージングは工程を複雑にするだけなのでステージング済みのデータを再配布する形にしようと思います。

2. LocalDDCの必要性について

LocalDDCはフォールバックとして残っているとのことで、SharedDDCを使用しない場合はOFFにしてしまおうと思います。

3. ZenStorageをNASに置く方法

> オフィスの共有PC上(ここで述べる"通常のPC"上)にZenSharedを立てて運用し、ZenStorageもPC内のSSDで運用することを期待しています

こちら了解しました。NASでもパフォーマンス不足に陥ったことがあるので通常のPCで耐えられるのかが不安だったのですが、問題が出たときに再度ご相談させていただきます。

ZenSharedに関して追加で質問があります。

4) ZenSharedを同オフィス内で複数台運用する場合の挙動について

ZenSharedを複数台運用する場合、自分のエディターより全てputが行われるので同じデータの書き込みが行われますが、読み取りは起動時に取捨選択されたZenSharedより常に行われるのでしょうか?

複数台運用する場合、起動時はレスポンスが良くてもタイミングによっては負荷がかかっている場合があり、その負荷がかかっているPCはgetが後回しにされるといいなと思っています。

ZenSharedの複数のリストがレスポンスによって前後するような機能はあったりしますか?

(HordeにZenStorageの最後のアクセス者によるレスポンスメトリクスがあってそれによって最速のZenSharedにアクセスするなど)

5) 拠点が別のZenSharedのDDCデータの共有に関して

拠点が別のZenSharedへは物理的につながっていなかったりしていてputが行われないケースがあると思います。

この場合別の拠点へのDDCデータのコピーの機能はないのでしょうか?FS版のDDCの場合は物理的にデータをコピーすれば同じデータがコピーできたのでrobocopyの/MIRなどで完全同期できたのですが、ZenStorageの場合は拠点ごとにfillするしかないのでしょうか?

DDCデータはDDCキーに紐づいている情報が洩れているとDDCキーが同じでも同じDDCデータが生成されない場合があり、完全に同じデータで運用できる状態を作っておきたいと考えています。

クック済みデータはImportがあるとのことでしたが、通常のDDCをコピーするコマンドなどが存在したりするのでしょうか?

ない場合はSharedDDCを拠点間のコピーの機能として使おうかと思っているのですが、ディスク消費量がZenSharedと合わせて2倍になってしまうのでZenSharedを同期できた方がシンプルでいいなと思っています。

[Attachment Removed]

追加のご質問に関しましては以下の通りとなります。

4) ZenSharedを同オフィス内で複数台運用する場合の挙動について

読み書きどちらも「起動時に選ばれた1台」に固定されます。負荷で Get 先が後ろへ回る機能はありません。DDCグラフはノードごと に「読みは順に、書きは書き込み可能な全ノードへ」実行します。ZenShared は通常ノードが1つで、そのHostが";"区切りの候補リストです。初期化時に1台へ解決し、以後そのノードのGet/Putはすべてその1台に対して実行します。候補が2台以上なら /health/ready を並列で叩き、先に 200 が返った側(ほぼ「その瞬間いちばん応答が速い台」)を採用して残りはキャンセルします。

機能としてあるのは"その1台が遅すぎたらZenSharedノードごと切ること(DeactivateAt=60ms)で、実測レイテンシが閾値を超えるとQueryもStoreも外します。回復待ちは30秒おきの/health/readyで、同じホストの再活性化です。別のZenSharedへフェイルオーバーしません。切れたあとのGetはグラフの次の層(Local FS、Cloud など)へ落ちます。

希望されている「負荷が乗っている PC の Get を後回し」とは逆で、悪い台を選び続けるか、Shared ごと黙るか、のどちらかです。

5) 拠点が別のZenSharedのDDCデータの共有に関して

robocopy/MIR 相当の「DDC 名前空間をオンラインで完全同期する」コマンドはありません。 クック済み oplog の Import/Export とは別物です。zen cacheにあるのは info/stats/get(1キー)/drop/record/replay で、バルクの cache export/import はありません。

このコマンドは稼働中ではなくサーバー停止中を前提としますが、代替案として以下のコマンドは FS DDC の robocopy に一番近く、サーバを止めた状態のdata-dirを丸ごとコピーする機能を利用できます。コピーされるのは cache(DDC)も projects/oplog もまとめた data-dir です。FS DDC の robocopy /MIR に一番近い Zen 版、という位置づけです。

コマンド:zen copy-state --data-path ... --target-path ...
コマンド実行例1:zen copy-state --data-path C:\ZenData --target-path D:\ZenData
コマンド実行例2:zen copy-state --data-path C:\ZenData --target-path D:\ZenData --skip-logs
 
--data-path は既存の Zen 保存先で、中に root_manifest が無いと拒否されます。--skip-logs はインデックス類だけコピーし、ログは捨てます。

Shared 機のSSD載せ替え、新しい専用機への引っ越し、バックアップ(その瞬間のスナップショット)の用途として提供されている機能です、これをFSと同様に別拠点のZenSharedに配置(つまりコピー)することで、DDCおよびその中身を同期することはできます。ZenServerを動かしたままの常時同期、DDCだけ/ある名前空間だけの指定、NASへの常用レプリカ作成、には向いていません。

拠点間でのDDC同期において、「同じキー空間を育てていくケース」なら、IPが届くなら拠点Bの Shared に readonly か readwrite の upstreamを指定(以下、コマンド)して、拠点Bをバックアップとして利用することです。IPが届かない場合は Fill するしかありません。

--upstream-zen-url http://<拠点AのZen>:8558
--upstream-cache-policy readonly

[Attachment Removed]

お返事ありがとうございます。

4)

>「起動時に選ばれた1台」に固定されます

このあたりはSharedDDCの頃と挙動は変わっていないということですね。

> その1台が遅すぎたらZenSharedノードごと切ること

こちらの機能は知りませんでした、この挙動でしたらSharedDDCを高負荷時のサブのDDCとして運用することで負荷分散ができそうなことに気が付きました。

SharedDDCはOFFにせずにNASなどHordeとは別のハードで運用する形にしようと思います。

5)

ZenDataのまるっとコピーも検討したのですが、プロセス停止がボトルネックで難しいなと思って質問しました。

異なる拠点での運用の環境としては、A(メイン)とB(サブ)という拠点間は基本的に通信が分断されているのですが、エディターやパッケージはp4やNASで共有している状態です。

AからBへ一方通行なので、A側からpushはできても、B側のpullをA側から能動的に発行することはできない状態です。

BからAにアクセスができるのであれば、B側でAのZenに読み取り専用でアクセスしてFillを実行すればB側のDDCはAからコピーされて埋まるのですが、それは難しそうです。

やはりSharedDDCを拠点間のコピーとして運用して、A側からはBのSharedDDCにpushしておき、B側ではZenStorageにないデータは共有されたSharedDDCから引っ張ってB側のZenSharedを育ててもらう形にしようと思います。

これで疑問はすべて解決できました、いろいろありがとうございました。

[Attachment Removed]