本ブログは株式会社電通総研とAmazon Web Services Japan が共同で執筆いたしました。 電通総研様が開発された リアルタイム 3DCG ソリューション「UNVEIL」 において、「1,000 名の同時接続」と「100〜500ms の低レイテンシー」という厳しい要件を、わずか約 1 ヶ月の準備期間で大規模 GPU 環境を構築し、乗り越えた事例をご紹介します。 まず、「UNVEIL」 についてご紹介します。「UNVEIL」とは電通総研様が開発されているブラウザでのリアルタイム 3DCG メタバース/仮想空間のソリューションで、現実に近い高品質な 3D 体験を、多人数同時参加で提供する商用向けサービスです。 (出展: 株式会社電通総研) お客様の状況と課題 電通総研様は、「UNVEIL」の商用展開に向けた取り組みの一環として、2025 年 12 月に実施された社内イベントでの活用を計画されていました。同イベントでは、1,000 名の同時接続と、レスポンス 100〜500 ms 程度という要件がありました。 課題は、 大規模な GPU 環境（ Amazon EC2 の g4dn 系、g5 系インスタンス）を効率的に構築する ことでした。イベント駆動型のワークロードであるため、コスト効率を保ちながら、必要な規模の環境を短期間で立ち上げる必要がありました。 戦略1: コスト最適化のためのリージョン選択 当初はアジアパシフィック (東京) リージョンで基盤を構築されていましたが、大規模な GPU 環境を構築するにあたり、 コスト効率 の観点から、海外リージョンの活用を検討しました。 Amazon EC2 の料金はリージョンによって異なるため、コスト効率の良い米国東部 (バージニア北部) リージョンと米国西部 (オレゴン)リージョンが候補として浮上しました。また、リージョンに依存しないアプリケーション設計を採用されていた点も、海外リージョンを選択できた大きな理由でした。 リージョン g5.xlarge のオンデマンド料金 ($/Hour) ※ アジアパシフィック (東京) 1.459 米国東部 (バージニア北部) 1.006 米国西部 (オレゴン) 1.006 ※ 2026 年 3 月時点の料金 戦略2: レイテンシーを考慮した実測テスト 海外リージョンを活用する際の最大の懸念は、日本からのアクセスにおけるレイテンシーでした。電通総研様は、 机上の計算だけでなく、実際のアプリケーションで測定する というアプローチを採用されました。 まず 米国東部 (バージニア北部) で検証を実施しましたが、日本からのアクセスでは遅延が大きく、ユーザー体験に影響があることが判明しました。次に米国西部 (オレゴン) で検証した結果、米国東部 (バージニア北部) よりもレスポンスが改善され、目標のレイテンシー数値に抑え、視聴体験を損なわない範囲に収まることを確認できました。この結果から コスト効率とレイテンシーの両面で最適な米国西部 (オレゴン) リージョンを採用 することが決定しました。 テストに向けた環境構築において、AWS の各リージョンで同一のサービスや API が提供されていたため、環境を別のリージョンへ再現することが容易でした。加えて、 Amazon EKS をはじめとするマネージドサービスを活用していたことで、リージョン間の環境移行も約 1 週間で完了し、迅速な検証が可能になりました。 戦略3: 複数回の事前テストによるリスク軽減 イベント本番での失敗を避けるため、 複数回のテスト を実施しました。数百台規模での動作確認を実施することで、以下のような潜在的な問題を事前に発見・対処することができました： 数百台規模のオートスケーリング起動が問題ないことの確認 (スケール起動検証) Service Quota の事前確認と調整 Amazon VPC の IP アドレス設計などインフラ面での考慮事項の確認 リージョンごとのレイテンシー特性の把握 また、大規模な GPU 環境を構築する際のキャパシティ確保の観点から、g4dn 系と g5 系の複数世代の GPU インスタンスタイプを混在させる構成を採用しました。単一のインスタンスタイプに依存せず、複数のインスタンスタイプを組み合わせることで、特定のインスタンスタイプで必要な台数が確保できない場合でも、他のインスタンスタイプで補完できる柔軟な環境を実現しました。 ソリューション概要 UNVEIL は、Amazon EKS を中心としたアーキテクチャで構成されています： フロントエンド: Amazon CloudFront + Amazon S3 による高速コンテンツ配信 アプリケーション層: Amazon EKS 上で動作する MatchMaker（ユーザーと GPU サーバーを割り当てる仕組み）、GPU サーバー、TURN/STUN サーバー 監視層: Amazon CloudWatch による包括的な監視 ユーザーは Amazon CloudFront 経由でアクセスし、MatchMaker が利用可能な GPU サーバーに割り当て、Unreal Engine でレンダリングされた映像を WebRTC 経由で配信します。 導入効果 2025 年 12 月のイベントでは以下の成果を得ることができました： 最大 1,000 台規模 GPU インスタンスを稼働 既存の東京リージョンと比較してコスト効率の良い環境構築を実現 電通総研様からは、「1,000 人規模のスパイクアクセスに対しても、インフラをオートスケーラブルに増減できることを検証できた点が大きな成果でした。未使用時にコスト増となり得る GPU リソースを、利用人数に応じて自動的にスケールできることを確認し、品質とコストの両立の可能性を示せました。また、事前検証によりボトルネックを特定できたことも、商用化に向けた重要な学びとなりました。一方で、アプリケーション面では大規模・多人数同時利用時の考慮が十分でなく、一部挙動が不安定となる課題も確認でき、改善項目として整理できました」とのコメントをいただきました。 大規模 GPU 環境構築の学び 今回のプロジェクトから得られた重要な学びをまとめます： 1. コスト最適化のためのリージョン戦略 海外リージョンの活用により、コスト効率の良い大規模 GPU 環境を構築できます。 2. 実測ベースの意思決定 複数リージョンで実際にレイテンシーを測定し、机上の計算だけでなく実際のアプリケーションでの検証が重要です。 3. 複数回の事前テストの重要性 複数回のテストを実施し、各テストでボトルネックを特定することで、イベント本番のリスクを最小化できます。また、g4dn 系と g5 系など複数世代の GPU インスタンスタイプを混在させることで、大規模環境でのキャパシティ確保の柔軟性を高めることができます。 4. イベント当日の運用設計 イベント開始前に十分な台数を確保し、Amazon CloudWatch による包括的な監視で問題の早期発見を実現します。 まとめ 今回は、電通総研様の UNVEIL において、大規模 GPU 環境を効率的に構築するための戦略的アプローチをご紹介しました。 電通総研様の「まず試してみる」という実践的なアプローチと、事前テストで計測したデータに基づく意思決定が、短期間でのシステム構築を可能にしました。大規模な GPU 環境を構築される際は、ぜひ今回ご紹介した戦略を参考にしていただければ幸いです。 AWS では定期的に技術イベントを開催しております。ぜひご参加ください。 https://aws.amazon.com/jp/events/ 執筆者 株式会社電通総研 事業開発室 姫野 智也氏、孫 辰氏 Amazon Web Services Japan: ソリューションアーキテクト 本多 和幸

本記事は、2026年 1 月 22 日に公開された “ Game development infrastructure simplified with AWS Game Dev Toolkit ” を翻訳したものです。翻訳は Solutions Architect の鷲見啓志が担当しました。 注釈: AnyCompany Gamesは、ゲーム開発における一般的な課題と解決策を説明するために作成された架空の会社です。 分散したチームでゲームを開発している場合、バージョン管理、ビルドシステム、クラウドインフラストラクチャのセットアップという課題に直面したことがあるのではないでしょうか。この記事では、AnyCompany Games の事例を例に、 AWS Cloud Game Development Toolkit を使用して、完全なゲーム開発パイプラインを数週間ではなく数時間でデプロイする方法を紹介します。 多くのインディーゲームスタジオと同様に、AnyCompany Games は大きな野望を抱く小規模なリモートチームから始まりました。業界暦の長い5人のベテランが、没入感のあるロールプレイングゲーム( RPG )体験を創造するという共通のビジョンを持って集まりました。しかし、彼らはすぐにゲーム開発における共通の課題に直面しました。彼らの野心的なプロジェクトには、堅牢なインフラストラクチャが必要だったのです。 AnyCompany Games のチームには、特別なものを作り上げる才能とビジョンがありました。彼らの前に立ちはだかる最大の問題は、インフラストラクチャの欠如でした。手元にあるハードウェアでは、ビルド時間が長くなり、ビルドはよく失敗していました。アーティストはシェーダーの読み込みに1時間以上待たされ、大容量のアセットの共有やバージョン管理が開発を遅らせていました。 彼らの開発に求められる環境は本格的なものでした。 Perforce P4 などのバージョン管理用サーバー、Unreal Engine Horde などの継続的インテグレーション・継続的デリバリー( CI/CD )ツール、そしてこれらすべてを支える基盤となるネットワークインフラストラクチャが必要でした。このシナリオは、ゲーム業界ではよく見られるものです。大容量なアセットを含む複雑なゲームには、スケーラブルなインフラストラクチャが必要ですが、大多数のゲームスタジオは、オンプレミスでスケーラブルなインフラを維持するのに苦労しています。 チームがクラウドソリューションを検討する中で、 Amazon Web Services（ AWS ）  は有望な選択肢であることが分かりました。AWS は必要に応じてリソースのプロビジョニングと削減を可能にし、大規模なハードウェア要件に対応できました。しかし、1つの課題が残っていました。それは、AWSリソースをゲーム開発ツールと効率的に連携するように設定することでした。 ここで Cloud Game Development Toolkit が登場します。これは、 AWS for Games によって開発された、公開されているオープンソースリポジトリに格納された Terraform モジュールと Packer テンプレート専用のコレクションです。この記事では、このツールキットが AnyCompany Games や同様のスタジオが開発ツールを AWS インフラストラクチャとシームレスに統合するのにどのように役立つかを探ります。 クラウドインフラストラクチャ構築の前提条件 多くのクラウドコンピューティング初心者の開発者と同様に、AnyCompany Games は AWS アカウントの作成から始めました。アカウント作成が完了すると、チームはゲーム開発のニーズに最適なクラウドインフラストラクチャについて調査を行いました。 その時、彼らは Cloud Game Development Toolkit を発見しました。このリポジトリは、AWS 上で重要なゲームインフラストラクチャコンポーネントのデプロイを効率化する、カスタマイズ可能な Terraform と Packer のテンプレートを提供していました。 ネットワーク基盤の構築 クラウド基盤を構築する最初のステップは、ネットワークアーキテクチャの作成でした。リソースは複数のアベイラビリティーゾーンにわたって高可用性を確保する必要がありました。 ネットワークインフラストラクチャを構築するための Amazon Virtual Private Cloud（ Amazon VPC ） リソースをデプロイするために、彼らは Terraform AWS プロバイダー のリソースとデータソースを使用しました。これらのプロバイダーを使用して、複数のアベイラビリティーゾーンにわたってパブリックサブネットとプライベートサブネットをデプロイし、仮想プライベートクラウド（ VPC ） からのインターネットアクセス用のインターネットゲートウェイ、およびプライベート AWS リソースからのアウトバウンドインターネットトラフィックを開始するための Amazon VPC NAT ゲートウェイを作成しました。ルートテーブルがこれらのサブネット間のトラフィックフローを管理し、適切なネットワークセグメンテーションを提供しました。 開発ツールやサービスへの信頼性の高いアクセスを提供するため、AnyCompany Games にはドメイン管理が必要でした。彼らは自社ドメイン用に Amazon Route 53 ホストゾーンを設定し、以下を実現しました。 一元化されたドメイン管理 DNS レコードの自動更新 他の AWS サービスとの統合 AWS Certificate Manager を通じた SSL 証明書管理 このネットワークと DNS のインフラストラクチャ基盤により、AnyCompany Games はゲーム開発ツールとサービスをサポートするために必要な、安全でスケーラブルな基盤を手に入れました。彼らは Infrastructure as Code（ IaC ） アプローチを使用して、インフラストラクチャ構成をバージョン管理し、異なる環境間で一貫してデプロイしました。 AnyCompany Games は Infrastructure as Codeとしてインフラストラクチャをデプロイし、Perforce を使用するためのネットワークインフラストラクチャの準備ができました。 以下のアーキテクチャ図は、この記事全体を通じてこのアーキテクチャ内に配置される Perforce と Horde リソースをホストする基盤を表しています。 図1: ネットワークアーキテクチャ クラウドでのバージョン管理に Perforce P4 サーバーを使用する ゲーム開発における重要なコンポーネントはバージョン管理であり、AnyCompany Games には、大容量のバイナリアセット、複雑なブランチ戦略、そして分散した労働力に対応できる堅牢なソリューションが必要でした。Perforce P4 サーバーが適切な答えとなるでしょう。しかし、そのセットアップに貴重な開発時間が奪われてしまいます。 Cloud Game Development Toolkit の Perforce モジュール の 例 を使用して、彼らはわずか数行のコードでバージョン管理システム全体をデプロイすることができました。 terraform apply コマンドを実行するだけで、Perforce サーバー、コードレビューシステム、認証サービスがクラウド上で稼働しました。 Perforce モジュールは3つの統合されたコンポーネントをデプロイしました。P4 サーバーは、バージョン管理のパフォーマンスに最適化された Amazon Elastic Block Store（ Amazon EBS ） ボリュームを備えた Amazon Elastic Compute Cloud（ Amazon EC2 ） インスタンス上で実行されています。次に、P4 Code Review と P4 Authentication Service の両方が、 Amazon Elastic Container Service（ Amazon ECS ） の共有クラスター上のタスクとして実行され、安全な認証とコラボレーション機能を提供しています。 セットアップには数週間ではなく数時間しかかからず、モジュールはチームが P4 One クライアントを接続するための接続文字列と設定詳細まで提供しています。 このツールキットは、Perforce の認証のセットアップを自動化し、Helix Authentication Extension のインストールを処理し、P4 Authentication Service をデプロイし、安全なアクセスのための認証サービスを設定しています。 Perforce をデプロイした後、AnyCompany Games の分散チームはついに効果的にコラボレーションできるようになりました。シアトルのアーティストが大容量ファイルをチェックインする一方で、フロリダのプログラマーは同時にエンジンの変更作業を行うことができました。 以下のアーキテクチャ図は、P4 Server、P4 Code Review、P4 Auth サービスを含む、AWS 上の Perforce のデプロイ構成を示しています。 図2: アーキテクチャ図 Horde でビルドパイプラインを加速する 次の課題は、Unreal Engine プロジェクト用の CI/CD パイプラインのセットアップでした。チームには、現在のハードウェアを置き換えるための2つの選択肢がありました。高額で最新のハードウェアを購入し、必要な容量を見積もるか、AWS クラウドの従量課金モデルを活用して、必要に応じてサーバーをプロビジョニングおよびデプロビジョニングするかです。 バージョン管理に使用した Cloud Game Development Toolkit を見直してみると、チームは、すぐにデプロイ可能な専用 CI/CD ツールも含まれていることを発見しました。Unreal Engine を使用していたため、彼らはツールキットの Horde モジュール をデプロイすることに決めました。 Hordeとは？ Unreal Engine Horde は、Epic Games によって開発された、ビルドとテストの自動化のための専用 CI/CD システムです。Epic Games によって設計され、Unreal Engine と統合するように作られており、Fortnite などの主要タイトルの開発に使用されています。Unreal Engine Horde は、プロジェクトのビルドとコンパイル方法を定義する Unreal Engine ビルドグラフシステム（ Unreal BuildGraph ）を標準で理解しています。これにより、汎用的な CI/CD ツールと比較して、Unreal ビルドプロセスとのより優れた統合が可能になります。 Horde は、アセットコンパイルやシェーダー処理などのリソース集約的なタスクの管理など、ゲーム開発に特化して最適化された分散ビルド機能を提供することで、CI/CD パイプラインの強化を支援します。これらの機能は、 Unreal Build Accelerator のリモート実行機能と組み合わせることで、ビルド時間の短縮を可能にし、チームの生産性を向上させることができます。Hordeの機能の詳細については、公式の Unreal Engine Documentation を参照してください。 ツールキットの例 を使用して、AnyCompany Games は AWS 環境に Horde を迅速に追加することができました。 Horde モジュールは、Horde サーバー用の Amazon DocumentDB（ MongoDB互換 ） クラスターと Amazon ElastiCache クラスターを自動的にデプロイし、サーバー設定用の環境変数を提供し、Auto Scalingグループを使用したエージェントのデプロイをサポートしています。 全体的に見ると、CI/CDに関するチームの要件も実現しています: Horde Controller  – ビルドジョブとエージェントを管理する中央サービス ビルドエージェント – 実際のビルド作業を実行する Auto Scaling EC2 インスタンス Perforce 統合 – バージョン管理システムへのシームレスな接続 Webインターフェース – ビルドを監視するためのユーザーフレンドリーなダッシュボード 認証  – 既存システムと統合された安全なアクセス制御 Horde のデプロイにより、2つの要件が満たされました。第一に、チームは Unreal Build Accelerator を使用できるようになり、Wine を使用して Linux マシン上で Windows ターゲットへのコンパイルを分散することで、ビルド速度の向上を実現しました。第二に、Horde の機能により、ゲームクライアント、マルチプレイヤーサーバー、エディターを含む異なる環境向けのビルドを構成するツールが提供されました。 以下の拡張されたアーキテクチャ図は、サポートするAWSサービスとともに、Amazon ECS上で実行されているPerforceとHordeの両方を示しています。 図3: 拡張されたアーキテクチャ図 Cloud Game Development Toolkit がもたらす効果 AnyCompany Games にとって、Cloud Game Development Toolkit は単に技術的な課題を解決しただけでなく、開発プロセス全体の変革を支援しました。パイプラインのセットアップ後、チームは実際のゲーム開発に集中できるようになりました。Cloud Game Development Toolkit は、インフラストラクチャの構築を簡素化し、ゲームの開発ニーズに合わせてAWSリソースを自動的に設定しました。 AnyCompany Games にとって、Cloud Game Development Toolkit は以下のような重要なメリットを提供しました: ゲームに特化した最適化 – ツールキットは、Unreal Engine 、大容量バイナリアセット、分散チームに必要なアプリケーションを、ベストプラクティスを組み込んだ状態でデプロイしました。 Infrastructure as Code（ IaC ） – IaCを定義できる機能により、チームは変更を追跡し、構成をテストし、環境を確実に複製できるようになりました。 組み込まれた AWS ベストプラクティス – AWS ベストプラクティスが組み込まれているため、チームはゲーム開発を優先でき、ツールキットはより安全で、スケーラブルで、再現可能なインフラストラクチャを実現しました。 スケーラビリティ – AnyCompany Games が成長を続けるにつれて、インフラストラクチャも共に成長できます。ビルドエージェントを5台から50台に拡張することは、簡単な設定変更で実現できます。オンプレミスで同じ結果を達成するには、サーバーラックのプロビジョニングとデプロビジョニングに数か月を要するでしょう。 スタートアップとして、コスト管理は AnyCompany Games にとって重要でした。ツールキットによるAWSベストプラクティスの実装により、費用の最適化も実現しています: Auto Scaling – オフピーク時にリソースを縮小 スポットインスタンス – ビルドエージェントが EC2 スポットインスタンス を使用し、コンピューティングコストを最大90%削減 適切なサイジング – インフラストラクチャコンポーネントが実際のニーズに合致 従量課金制 – 多額の初期ハードウェア投資が不要 リポジトリのフォーク  – スタジオの成長と変化に合わせてリポジトリを拡張可能 インフラ管理ではなく、ゲーム制作に集中 AWS で Cloud Game Development Toolkit を使用することで、架空の AnyCompany Games は、インフラストラクチャの習得に時間を費やすのではなく、彼らが最も得意とすること、つまり革新的なゲームの創造に集中できるようになりました。 Cloud Game Development Toolkit を使い始めるには、まずインフラストラクチャの課題を特定します。それがバージョン管理、ビルド自動化、またはその両方であるかを見極めましょう。Amazon VPC と Route 53 モジュールを使用してネットワーク基盤をデプロイし、次に Perforce モジュールでバージョン管理を追加します。チームメンバーがアセットを共有して作業できるようになったら、ビルド自動化のために Horde モジュールを実装します。このプロセス全体を通じて、スタジオ固有の要件に合わせて Terraform モジュールを調整してください。 AWS の豊富なドキュメントとサポートリソースを活用することで、さまざまな規模のゲームスタジオが自信を持ってクラウドへの移行を開始できます。Cloud Game Development Toolkit は、業界のベストプラクティスと一般的なゲーム開発ワークフローに沿った事前設定済みテンプレートを提供することで、この移行を簡素化します。AWS の担当者に連絡して、貴社のゲームスタジオがクラウドを始めるためにどのようにサポートできるかをご確認ください。 参考資料 ゲームスタジオのクラウド移行を加速する準備はお済みですか？準備ができているようであれば以下のリソースも併せてご参照ください: Building Games with Unreal Engine and Horde on AWS Deploying Perforce with AWS Cloud Game Development Toolkit AWS for Games — Cloud Game Development Toolkit はオープンソースプロジェクトです。AnyCompany Games は、ゲーム開発における一般的な課題と解決策を説明するために作成された架空のスタジオです。AWS および AWS ロゴは、米国および/またはその他の国における Amazon.com, Inc. またはその関連会社の商標です。 Basim Siddiqui Basim Siddiqui は、AWS で3年以上働いているソリューションアーキテクトです。ゲーム業界に焦点を当て、あらゆる規模の新規および既存の AWS ゲーム顧客にベストプラクティスと技術的なガイダンスを提供しています。彼は、ゲームスタジオが可能な限り最高の体験を創造できるよう支援するため、新しい AWS クラウド技術を学ぶことに情熱を注いでいます。 Issac Accord Issac Accord は AWS のソリューションアーキテクトで、ゲーム業界の顧客と協力して、既存の AWS フットプリントの改善と強化に取り組んでいます。 Josh Albert Josh Albert は、ゲーム業界に特化したソリューションアーキテクトです。新規および小規模なゲームスタジオが AWS サービスを活用して、より効率的にゲームを構築し、開発サイクルを強化できるよう支援することを専門としています。

このブログ記事は、ネットアップ合同会社 ソリューションアーキテクト 井谷寛と 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.autocompress 3. 明示的な非圧縮の設定 ( p4 configure set ) Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure set any#lbr.autocompress=0 edge や 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つの技術コミュニティで活動中。