キャッシュサーバー

重要: Cache Server は Asset Import Pipeline バージョン 1 のみをサポートします。AssetImport Pipeline バージョン 2 を使用する場合は、代わりに Unity Accelerator を使用してください。

Unity は完全に自動的なアセットパイプラインを持っています。アセット元となる psd ファイルや fbx ファイルが変更されると、Unity は変更を検知し、自動的に再インポートします。ファイルからインポートされたデータはすぐに内部形式に変換されて保存されます。

この処理は個人のユーザーに対し、ワークフローをできるだけ効果的で柔軟にするためにデザインされています。ただし、チームで作業をしている場合には、他のユーザーが頻繁にアセットの変更していることがあります。それらもすべてインポートされます。さらに、デスクトップとモバイルのビルドターゲットプラットフォーム間で切り替えをするとき、アセットを再インポートしなければなりません。そのため、そのような変更は大きなプロジェクトでは長時間かかります。

インポートしたアセットデータを キャッシュサーバー にキャッシュすることで、アセットのインポートにかかる時間を著しく縮めることができます。

Unity は以下の点に基づいて各アセットインポートをキャッシュします。

• アセットファイルそのもの
• インポート設定
• アセットインポーターのバージョン
• 現在のプラットフォーム

以上のどれかが変更された場合、Unity はアセットを再インポートします。それ以外の場合は、Unity はキャッシュサーバーからアセットをダウンロードします。

キャッシュサーバーを使用すると、複数のプロジェクトでアセットインポートを共有することもできます (つまり、インポート作業は 1 台のコンピューターで行い、結果を複数コンピューターで共有できます)。

ノート: いったんキャッシュサーバーを 設定 し 有効 にすると、この処理は完全に自動で行われるため、追加のワークフローの必要はありません。これにより、ユーザーが処理する必要なしにプロジェクトのインポートにかかる時間を削減します。

キャッシュサーバーの有効化

キャッシュサーバーを有効にするには、以下の手順を行います。

1. Unity Preferences ウィンドウ (MacOS ではメインメニューの Unity > Preferences Windows と Linux の場合は Edit > Preferences) を開きます。
2. 左のカテゴリから Cache Server を選択します。 Cache Server 設定が右側の詳細ペインに表示されます。
3. Cache Server Mode ドロップダウンから Remote か Local を選択します。選択したモードに固有のプロパティが表示されます。
4. 選択したモードの Cache Server 環境 を設定します。

ヒント ハードドライブのサイズ制限のため、キャッシュサーバーは可能な限り別のコンピューターでホストして下さい。

注意 カスタムの場所を持つローカルのキャッシュサーバーの場所が使用できなくなると、Unity は以下の警告を表示します。

Local cache directory does not exist - please check that you can access the cache folder and are able to write to it (ローカルのキャッシュディレクトリが存在しません - キャッシュフォルダーにアクセスし、書き込むことができるかどうかを確認してください)

キャッシュサーバー の設定 (管理者側)

管理者はキャッシュされたアセットを置いておくための キャッシュサーバー コンピューターを設定する必要があります。

リモートサーバー上にキャッシュサーバーを設定するには、以下の手順を行います。

1. キャッシュサーバーをダウンロードします。
   • Unityの ダウンロード アーカイブ ページを開きます。
   • 使用している Unity バージョンを探し、ターゲットサーバーのオペレーティングシステムの ダウンロード ボタンをクリックします。
   • Cache Server リンクをクリックしてダウンロードを開始します。
2. ファイルを解凍すると図のようになります。
3. オペレーティングシステムに合ったコマンドスクリプトを実行します。キャッシュサーバーがバックグラウンドで実行されていることを示すターミナルウィンドウが表示されます。

重要: キャッシュサーバーは、非常に大きなストレージ (インポートされたリソースの複数バージョンが保管されるため、プロジェクト自体よりもはるかに大きいサイズ) を持つ信頼性の高いコンピューター上にある必要があります。ハードディスクがいっぱいになると、キャッシュサーバーの動作は遅くなります。

キャッシュサーバーの設定 (サービス側)

Unity が提供している .sh や .cmd のスクリプトは、サーバーのサービスとして設定する必要があります。キャッシュサーバーはアトミックなファイル操作を行うため、そうすることで、いつでもキャッシュサーバーは安全に中断や再起動ができます。

新旧のキャッシュサーバー

デフォルトで 2 種類のキャッシュサーバー処理が開始します。古いキャッシュサーバーは5.0 以前のバージョンの Unity で使用できます。新しいキャッシュサーバーは 5.0 以降の Unity で使用できます。2 種類のキャッシュサーバーの設定、有効化、無効化に関する詳細は後述のキャッシュサーバー設定を参照してください。

キャッシュサーバーの設定

スクリプトを実行して Cache Server を起動する方法では、古いキャッシュサーバーはポート 8125 を、そして、新しいキャッシュサーバーではポート 8126 を使って起動します。また、スクリプトと同じディレクトリに “cache” と “cache5.0” が作成され、そこにデータが保存されます。それらのキャッシュディレクトリには、デフォルトで最大 50GB まで保存することができます。このサイズの設定やディレクトリの場所は、以下のコマンドラインで変更することが可能です。

./RunOSX.command --path ~/mycachePath --size 2000000000

または

./RunOSX.command --path ~/mycachePath --port 8199 --nolegacy

以下のコマンドラインオプションを使用して、キャッシュサーバーの設定を行えます。

• --port 特定のサーバーポートを使用します。新規でキャッシュサーバーを構築するときのみ使用してください。デフォルトは 8126 です。
• --path 特定のパスにキャッシュフォルダーを作成します。新キャッシュサーバーを構築するときのみ使用してください。デフォルトは ./cache5.0 です。
• --legacypath 特定のパスにキャッシュフォルダーを作成します。古いキャッシュサーバーを構築するときのみ使用してください。デフォルトは ./cache です。
• --size キャッシュサーバーでキャッシュできる最大キャッシュサイズを設定します。キャッシュサイズを超えた場合、使用されていないファイルから自動で削除されていきます。
• --nolegacy 古いキャッシュサーバーを開始しない場合にこのオプションを使用します。古いキャッシュサーバーを使用する場合はポートは 8125 になります。

キャッシュサーバーでホスティングするマシンの必要スペック

最高のパフォーマンスを得るために、インポートされたプロジェクト全体を網羅できるだけの十分なメモリ容量 (RAM) が必要です。加えて高速なハードディスクと高速なイーサーネット接続があるのがベストでしょう。また、ハードディスクは十分な空き容量が必要です。ただ一方、キャッシュサーバーには CPU パワーはほとんど必要ではありません。

キャッシュサーバーとバージョンコントロールとの主な違いは、キャッシュ化されたデータはいつでもローカルで再ビルドできる、ということです。これは単に、パフォーマンス改善のためのツールということです。この理由で、キャッシュサーバーをインターネットで利用することは意味がありません。分散しているチームならば、それぞれのロケーションでキャッシュサーバーを立てるべきでます。

できれば、Linux か Mac OS X マシンでキャッシュサーバーを走らせるべきです。Windows のファイルシステムはキャッシュサーバーがデータを保存する方法にあまり適しておらず、ファイルロックに関する問題が発生する場合があります。Linux や Mac OS X ではそのようなことがありません。

キャッシュサーバー FAQ

キャッシュサーバーの DB サイズはインポートしたりリソースを保存したりするたびに無限にどんどん大きくなってしまうのでしょうか？

キャッシュサーバーは自動的に一定周期に使われなくなったアセットを削除します（もちろん再度必要になれば、次に使われる間に再び作られるでしょう）。

キャッシュサーバーは Asset Server でしか動かないのですか？

キャッシュサーバーはソースバージョンコントロールと切り離してデザインされているので、Unity の Asset Server に制限されることはありません。

何を変更するとインポートしたファイルが再度生成されるのでしょうか？

Unity は一つのアセットをインポートしようとする際、元となる全てのデータの MD5 ハッシュを生成します。

例えばテクスチャでは、以下のように成り立っています。

• 元となるアセット: “myTexture.psd” ファイル
• メタファイル: “myTexture.psd.meta” （全てのインポート設定を保存しています）
• テクスチャインポーターの内部バージョン番号
• 全ての AssetPostprocessors のバージョン番号のハッシュ

もしハッシュがキャッシュサーバーに保存されているものと違っていたら、アセットが再インポートされるか、キャッシュ化されたバージョンがダウンロードされます。クライアント側の Unity エディターは必要な時にサーバーからアセットを持ってくるだけです。つまりアセットは変更のたびにそれぞれのプロジェクトにプッシュされることはありません。

依存関係のあるアセットはどう扱ったら良いですか？

キャッシュサーバーは依存関係を扱いません。Unity のアセットパイプラインは依存関係のコンセプトを処理できません。アセット間の依存を避けるように作られています。 AssetPostprocessor クラスは、アセットインポーターを自分用にカスタマイズする一般的なテクニックです。例えば、決められた名前やタグに基づいて .fbx ファイルのゲームオブジェクトに MeshCollider を追加することも可能です。

AssetPostprocessor を使って、依存関係を示すことも簡単にできます。例えば、アセットの次に、テキストファイルから得たデータを使って、インポートしたゲームオブジェクトにコンポーネントを追加することも可能です。これはキャッシュサーバーではサポートされません。もしキャッシュサーバーを使いたいなら、プロジェクトフォルダーの他のアセットの依存関係を排除しなければなりません。キャッシュサーバーはポストプロセッサの依存関係について何も検知しないので、変更を検知せず、キャッシュされた古いバージョンのアセットを使用してしまいます。

実際に、キャッシュサーバーと連携して AssetPostprocessor を走らせる方法はたくさんあります。以下を利用します。

• インポートされたアセットのパス
• アセットの全てのインポート設定
• 元となるアセット自身か、アセットポストプロセッサー内で生成されたデータ

マテリアルで動かす際に問題がありませんか？

すでに存在するマテリアルを変更すると、問題が発生する場合があります。キャッシュサーバーを使用すると、Unity はマテリアルへの参照が維持されていることを検証します。しかし、ポストプロセスの呼び出しが発生しないため、キャッシュサーバーを通してモデルがインポートされても、マテリアルのコンテンツは変更されません。このため、キャッシュサーバーを使用する場合と使用しない場合で異なる結果になる場合があります。

ディスク上にすでに存在するマテリアルを、アセットのポストプロセッサーから変更しないでください。なぜなら、キャッシュサーバーを通して fbx ファイルをダウンロードすると、インポート処理が実行されないためです。そのため、モデルインポーターが実行されるたびに生成されたマテリアルを生成されたデフォルトにリセットすることに頼る場合、キャッシュされた fbx ファイルをインポートするときに、このアセットのポストプロセッサーは実行されません。

サーバーによってキャッシュされないアセットの種類はありますか？

サーバーにキャッシュされない種類のアセットはいくつかあります。スクリプトファイルをキャッシュすることによって得られたものは、サーバーでは無視されるので、キャッシュされません。3D モデリングソフト (Autodesk® Maya®, Autodesk® 3ds Max® 等) で使われているネイティブのファイルはそのアプリケーション自体を使って fbx にコンバートされます。アセットサーバーは、ネイティブのファイルとインポートプロセスで生成された fbx ファイルのどちらもキャッシュ化しません。ただし、モデリングソフトから fbx としてエクスポートし、Unity プロジェクトに加えることでサーバーによるキャッシュ化が可能になります。

---

• 2018–11–09 修正されたページ