Amazon Web Services ブログ
Perforce × FSx for ONTAP で実現する、大規模開発環境のストレージ効率化とコスト削減
このブログ記事は、ネットアップ合同会社 ソリューションアーキテクト 井谷寛と AWS シニアソリューションアーキテクト 長田義広が共同で執筆し、株式会社東陽テクニカ テクニカルサポート 村吉翔大とネットアップ合同会社 シニアクラウドソリューションアーキテクト 藤原善基が監修しています。
はじめに
ソフトウェア開発で利用される VCS ( Version Control System ) には、Git / Git LFS や Subversion、そしてUnity Version Control ( 旧名 Plastic SCM ) などがあります。しかしゲーム開発や映像制作で広く利用されるゲームエンジンである Unreal Engine と連携してよく使われるのが Perforce P4 ( 旧名 Helix Core、以降 Perforce と表記 ) です。
本記事では AWS 上で Perforce と NetApp ONTAP を組み合わせるメリットとして、大規模なソフトウェア開発に使えるストレージの効率化とコスト削減を実現する手法について説明します。
※ Perforce に関する解説はこちらの AWS ブログにも記載があります
Perforce と NetApp ONTAP を組み合わせるメリット
1. データ量の削減とストレージコストの削減
Perforce で管理するデジタルアセット ( 3DCG コンテンツや映像コンテンツ、ソースコードなど ) はプロジェクト間で流用や共有されることが多く、プロジェクト終了時にシステム管理者が削除を要請してもすぐに削除が可能になる訳ではありません。ソースコードであればデータ量は極端に大きくなることはありませんが、映像コンテンツはファイルサイズが大きい為サーバやストレージを圧迫します。どのデータを残してどれを削除するのかを選別するのは時間のかかる作業であり、また「あの時のあのバージョンが欲しい」という状況が将来発生することを考えると、プロジェクト終了時に過去のバージョンは全て捨てて最新バージョンだけ残すと割り切れないケースもあります。
このように多くのデータを保持する為に、重複排除機能を持ったストレージを活用してデータの保持コストを削減するアプローチがあります。バージョン管理システムには差分の少ない異なるデータが複数世代格納されることが多い為、一般的に重複排除が効きやすいです。NetApp ONTAP には重複排除機能があり、このボリュームを Perforce のリポジトリとして設定するだけでストレージコストを削減できます。
AWS 上で Perforce を利用する場合は Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を活用できます。マネジメントコンソールや AWS CLI を用いてユーザの VPC に NFS / CIFS / iSCSI プロトコルで接続可能なストレージを提供できます。Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスにインストールした Perforce サーバが FSx for ONTAP を NFS プロトコルなどでマウントし、そのパスを Perforce サーバ上でリポジトリとして定義すれば設定は完了です。
重複排除に加えて、FSx for ONTAP の階層化設定を追加するとアクセス頻度の低いデータは SSD 層から GB 単価の安いキャパシティ層にデータを透過的に移動するようになります。これにより同容量の Amazon Elastic Block Store (Amazon EBS) を Perforce サーバに割り当てるのに比べ半分以下のコストで運用できるようになります。
※ FSx for ONTAP のコストは AWS Pricing Calculator から算出できます
図 1: EBS と FSx for ONTAP のコスト比較 ( 2025 年 7 月時点 )
これら FSx for ONTAP の機能を活用することでデータの管理コストを下げることが可能です。AWS のガイダンスでは 16TB 未満は EBS の GP3 ボリュームタイプの利用を推奨していますが、Perforce で扱うデータ量がそれ以下であっても、16TB 以上に容量が増えていく想定であれば FSx for ONTAP の利用を検討できます。
図 2: Guidance for Building Perforce Helix Core on AWS
2. Perforce サーバの負荷軽減 ( ストレージオフロード )
開発規模の大きいプロジェクトであったり、複数拠点で大容量のデータ連携をする必要がある場合、そのデータ転送処理にPerforce サーバのリソースがとられることがあります。他の VCS と異なり Perforce では Perforce プロキシサーバや転送レプリカ、エッジサーバなどを立てて分散処理することが可能です。それでもパッチ適用やエラーログ調査などの運用コストが増えることを鑑みるとサーバ台数は最小限にすべきです。
以下の処理を NetApp ONTAP に任せることで、Perforce サーバの負荷を下げることができます。
A. ファイルの圧縮・解凍処理
B. ファイルのサーバ間ネットワーク転送
A. ファイルの圧縮・解凍処理
通常ファイルを受け取った Perforce サーバは、そのデータを圧縮した上でディポ ( リポジトリ ) に格納します。しかし大量のファイルを同時に処理するとこの圧縮処理でサーバの CPU 負荷が 100% になることがあります。また CPU コアが多い環境では、仮に空いているコアがあったとしても、圧縮のオーバーヘッドによりネットワーク帯域に余裕があるにもかかわらず転送レートが低い状態になることがあります。読み出し時にも解凍に CPU を使うため、大量のデータをダウンロードする際同様に Perforce サーバがボトルネックになることがあります。これらはプロキシサーバやエッジサーバで負荷分散していても、特定のサーバで発生し得ます。
※圧縮のオーバーヘッド : Perforce サーバがクライアントから受信したデータは Perforce サーバの CPU を使って圧縮します。もし圧縮が無効であれば Perforce サーバは受信したデータをそのままディポに格納するため、サーバプロセスが圧縮することによる処理遅延 ( = データ転送を低下させる要素 ) が削減されます。
※近年では VCS にデータを格納する前に圧縮をしてしまうアプリケーションも増えています。Unity などのゲームエンジンでは圧縮した状態で VCS にデータを渡すこともあり、VCS 側の圧縮設定をどうするかは注意すべき設計要素になりつつあります
このような時は Perforce によるデータ圧縮を無効にして圧縮処理は外部のストレージに委ねます。NetApp ONTAP ストレージにはハードウェア圧縮・解凍するためのアクセラレータが搭載されています。ネットアップ合同会社のテスト環境では、圧縮済みのデータをサブミットする際に Perforce の gz 圧縮を無効化することで、ネットワーク転送スピードが 3 ～ 8 倍程度高速化することを確認しています。
Perforce で圧縮を無効にする方法は lbr.autocompress と p4 typemap の 2 種類があります。すべてのファイルタイプを非圧縮にするには後者の設定が有効です。
設定 (1) lbr.autocompress
1. 既存の設定を確認 ( p4 configure show )
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure show allservers以下のような行があれば、次の手順に進みます。
any: lbr.autocompress = 1
edge: lbr.autocompress = 1
master: lbr.autocompress = 1
2. 圧縮設定の解除 ( p4 configure unset )
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset any#lbr.autocompress
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset edge#lbr.autocompress
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset master#lbr.autocompress3. 明示的な非圧縮の設定 ( p4 configure set )
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure set any#lbr.autocompress=0edge や commit ではなく any を指定することで、Perforce 全体に設定が反映されます。
設定 (2) p4 typemap
1. p4 typemap ですべてのディポのすべてのファイルを非圧縮に指定
Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT typemapエディタが起動するので、すべてのディポ ( //... ) のすべてのファイル ( * ) を非圧縮 ( binary+F ) として扱うように設定します。
TypeMap:
binary+F //...*エディタを保存して終了すれば、設定完了です。
※ Perforce のバージョン2022.1 以降、lbr.autocompress は “1” がデフォルト値になっています。古いバージョンを使用しているユーザは、現在の設定値を事前にご確認ください
※ Perforce に設定可能なパラメータの一覧は公式サイトに記載があります
図 3: lbr.autocompress の設定
B. バージョン化ファイルの Perforce サーバ間ネットワーク転送
このオフロードは Perforce を分散サーバ構成にしたときに有効です。Perforce の分散アーキテクチャ ( 7 種類 ) はこちらのドキュメントに記載があります。
※ Perforce の中心となるサーバにはセントラルサーバやマスタサーバ、コミットサーバなどいくつかの呼び方がありますが、本ブログでは「コミットサーバ」と表記を統一します
プロキシサーバやエッジサーバがコミットサーバから離れている場所に存在する場合、通常 Perforce クライアントがプロキシサーバなどにデータをリクエストするとプロキシサーバはコミットサーバにファイルを要求し、そのデータをプロキシサーバのキャッシュ領域に保存しつつ Perforce クライアントにデータを渡します。
図 4: 通常の Perforce サーバ間データ同期
これに対して、NetApp ONTAP の機能と連携してデータを同期する場合は以下の様になります。
図 5: NetApp ONTAP の機能を使った Perforce サーバ間データ同期
サーバ間のファイル転送は NetApp ONTAP の FlexCache という機能を使い、Perforce の機能とは別でデータを転送します。。FlexCache が設定された NetApp ONTAP ストレージをプロキシサーバやエッジサーバがマウントすると、キャッシュストレージにはオリジンストレージのファイルシステムのメタデータのみを転送・保存するため、実体データがキャッシュに存在しなくてもコミットサーバ上のすべてのディポのデータにプロキシサーバが直接アクセスできる状態になり、Perforce サーバ間のバージョン化ファイルの転送が不要になります。
※実データの転送は Perforce 間で行われませんが、Perforce 内部でメタデータを管理するデータベースへのアクセスは引き続き Perforce 間で行われます
FSx for ONTAP でもこの FlexCache を使えるため、AWS に立てた Perforce サーバもこの機能の恩恵を受けることができます。
※データを二重持ちするわけではなく、NetApp ONTAP のキャッシュ機能を活用するため、キャッシュ側のストレージコストは最小限となります
※キャッシュストレージの容量が溢れそうになると、ストレージが自動的にアクセス頻度の低いデータをキャッシュから削除して空きスペースを確保します
3. リモート拠点やクラウドとのデータ連携作業の簡易化
Perforce は分散アーキテクチャを採用しているため、2.B. で説明したサーバ間転送を用いなくても利用することは可能です。しかし特に距離の離れた拠点との通信ではネットワークの遅延が大きいことによる性能低下が発生するため、Perforce サーバのチューニングだけでなくその下で動く Linux OS のチューニングも必要になることがあります。
自社の環境にあわせてこれらを適切に設定するには幅広い知識とスキル・経験が必要になりますが、NetApp ONTAP のストレージキャッシュ技術を組み合わせることでそのハードルを下げることができます。リモート拠点のプロキシサーバやエッジサーバはその拠点に設置されたキャッシュ用の NetApp ONTAP、AWS 上では FSx for ONTAP をマウントするだけで、高速なデータ連携が可能になります。
図 6: エッジサーバと組み合わせた場合の構成例
まとめ
ネットアップ合同会社には日本のお客様向けに Perforce と AWS を連携させて検証できる環境があります。また海外リージョンの FSx for ONTAP と接続して性能検証を行う設備もそろっています。バージョン管理システムの運用管理にお困りの方はご相談ください。
AWS では多くのゲーム会社様が AWS のクラウドサービスを使ってゲームを開発・運用するための技術支援をしています。またこのブログの様に AWS パートナー企業と共同でゲーム会社様に役立つ情報をご紹介したり、CEDEC や GDC などのゲーム業界イベントや AWS 主催のイベントでも情報を発信しています。私たちの活動がゲーム業界の発展に貢献できる様、今後も技術とビジネスの両面から全力でお客様をサポートしていく所存です。
著者 ( 敬称略 )
井谷 寛
ネットアップ合同会社 ソリューションアーキテクト部 ソリューションアーキテクト
ハイブリッド・マルチクラウドの提案を得意とするエンジニア。様々な技術を組み合わせて検証し、ソリューション化して、販売から事例化までトータルでお客様をサポートしている。お客様やパートナー様と一緒に手を動かして現実的な提案をするのが得意。
村吉 翔大
株式会社東陽テクニカ
ソフトウェア・ソリューション
テクニカルサポート
藤原 善基
ネットアップ合同会社 AWS SE Support シニアクラウドソリューションアーキテクト
Amazon FSx for NetApp ONTAPの技術支援を担当するエンジニア。NetAppが持つONTAPのナレッジと、AWSとFSx for ONTAPの共同開発・共同営業を通して積み上げた実績と経験に基づくTIPSを資料として公開・トレーニングや案件支援などを行なっている。新卒で国際物流業の物理コンテナを扱う営業になった後、現職まで複数の業種・職種を経験。
長田 義広
アマゾンウェブサービスジャパン合同会社 ゲームスペシャリスト シニアソリューションアーキテクト
ゲーム会社でインフラエンジニア、ゲームプログラマなどを務めた後 AWS Japan に入社。ゲーム業界のお客様だけでなくゲームエンジンを使ったストリーミング配信やメタバースなどノンゲーム分野も支援している。社内ではゲーム・ストレージ・メディアの3つの技術コミュニティで活動中。