Amazon Web Services ブログ

Perforce Helix Core を AWS 上に構築する (Part1)

みなさんお元気ですか？

今年からゲーム開発のコンサルティングパートナーや ISV といったテクノロジーバートナーと AWS との連携強化を担当している AWS ソリューションアーキテクトの保里 善太です。

ところでみなさん、Perforce Helix Core はお使いですか？

Perforce は高速な同期操作を特徴とする商用のバージョン管理システムであり、主にゲーム業界等の開発現場で多く利用されています(導入企業)。

多くの現場では Perforce はオンプレミスのマシンで稼働していますが、この記事では AWS 上で Perforce を構築することの利点を解説し、実際の構成案と構築方法を紹介します。構築にあたっては AWS CloudFormation テンプレートも用意しています。Perforce の導入にあたっては無料の Perforce Helix Core Studio Pack for AWS というプログラムも用意されてます。

３回に分けてシリーズ化してお送りします。

 

Perforce Helix Core とは？

バージョン管理システム (VCS) の代表的なものとして、Git、Subversion (SVN)、CVS、Mercurial、そして Perforce などがありますが、それぞれには特徴的な性質があります。バージョン管理システムには、大きく分けてソースコード等を中央集権的にマスターサーバで管理する集中型 (Subversion、CVSなど) と各開発者のローカル PC にソースコードを保存し必要な時に共有する分散型 (Git、Mercurialなど) とに大きく分かれます。この中で Perforce Helix Core (以下Perforce) は集中型のバージョン管理システムに分類されます。

Perforce はテキストファイルの変更差分のみを保持することと、バイナリファイルに関しては各バージョンを圧縮してまとめて保持するという特徴があります (バージョン化ファイルと言います)。大規模開発の過程で総ファイル数や総コミット数が増加してもリポジトリ (Perforce の場合は depot と言います) が肥大化しにくい点 (*注1) やクライアントがマスターサーバからネットワーク的に離れていても高速に動作する仕組み (**注2) が提供されています。このため Perforce はテキストファイルのみならず、画像や動画といった大容量のバイナリファイルのバージョン管理にも適してます。

また、Perforce にはソースコードは git で管理してバイナリファイルは Perforce で管理するといったような git と Perforce の両者を横断的に役割分担して統合管理するような仕組みもあります。

 

(*注1) バージョン管理システムとしてよく利用されている git は分散型開発による優れたワークフローを持つ反面、変更差分を保持する方式ではなくコミットごとに一つのスナップショットを保持するのでバイナリのような巨大なデータに対して多数の更新や追加や削除が頻繁に行われるとどうしてもリポジトリが肥大化する傾向にあり、リポジトリの逼迫に伴って動作が遅くなってきてしまいます。このため git で画像や動画ファイル、3D グラフィック用のファイルなどのバイナリデータを扱うのはどうしても不向きで、バイナリデータのバージョン管理には Perforce の出番となります。git にも大容量ファイルを扱う拡張機能の git LFS というものもありますが、これはバイナリファイルの実体を追加料金を払って Large File Storage (LFS) と呼ばれるリポジトリとは別の領域に格納してリポジトリにはそのポインタを格納しているだけです。あくまで拡張機能なので対応するには全てのクライアントにインストールしておく必要があります。

(**注2) 開発者が世界中多数の拠点で分散開発している場合、一つのマスタサーバーに対して世界中からアクセスが集中します。毎回 sync や submit (commit) を実行する度にサーバーとクライアント間でデータ転送が発生する上にクライアント側の帯域幅が限られていたり、クライアントが遠隔地にある場合には sync や submit の度にパフォーマンスが低下します。Perforce ではこういった遠隔地にあるクライアントのパフォーマンスを改善するために Perforce プロキシ (P4P) というプロキシ機能やエッジサーバという仕組みが用意されています。

 

AWS 上に構築するメリットとは？

さて、Perforce は多くの場合、オフィス内やデータセンタ内にあるオンプレミスマシン上にホストされていることも多いと思いますが、Perforce を AWS 上に構築する利点は何でしょうか？

以下、それぞれの項目に対して利点を考察してみたいと思います。

サーバーの可用性

Perforce には、マスターサーバの負荷とダウンタイムを低減するために複製機能(レプリカサーバ)があります。マスターサーバとレプリカサーバを AWS 内の別々の Availability Zone に配置することで高い可用性を担保することができます。これは、通常オンプレミスマシンを同一のデータセンター内にマスターサーバ、レプリカサーバとして配置するよりも高い可用性となります。

容易なディスクサイズの拡張性

EC2 にアタッチされるブロックストレージの Amazon Elastic Block Store (EBS) は、ボリュームサイズやボリュームタイプを動的に後から変更できるようになっています。このディスクサイズの拡張性により、プロジェクト途中で思いのほか Perforce depot のファイルサイズが肥大化してディスク領域が逼迫した場合にも容易にディスクを拡張することができます。
また、Amazon Elastic File System (Amazon EFS) は自動で伸縮自在な完全マネージド型の NFS ファイルシステムであり、Amazon EFS を Perforce のファイルストレージとして利用した場合は事前にボリュームサイズをプロビジョニングする必要はありません。

AWS グローバルインフラストラクチャー

様々な地域に開発者が分散しているような分散開発において世界中に展開する AWS のグローバルインフラストラクチャーのメリットを生かすことができます。

Perforce では頻繁に転送されるファイルリビジョンをキャッシュするための Perforce プロキシ (P4P) というプロキシ機能を用意しています。Perforce プロキシはクライアントに近い側のネットワークに置かれ、Perforce アプリケーションとバージョニングサービスとの間を調整してパフォーマンスを改善します。

例えば、ある一つのリージョンに Perforce マスターサーバが設置されており、開発者が様々なリージョンや世界中に分散して共同開発を行なっている場合には、各開発者のいる地域に近接する AWS リージョンに Perforce プロキシを置いてデータ転送のパフォーマンスを改善することができます。この時、マスターサーバとプロキシサーバ間をインターリージョン VPC ピアリングで接続する事で一般的なインターネット回線ではなく AWS のバックボーン回線を利用して通信できるようになり、データ転送のパフォーマンスをさらに改善できます。

AWS のサービス群との連携

Perforce を AWS 上にホストすることで、他のサービスとの連携が可能となり AWS のエコシステムを利用できるようになります。

例えば、Perforce に保存されているコードをビルドする際には、EC2 インスタンスを利用してビルドからテストまでの一連のビルドパイプラインを構築することができます。オンプレミスマシンでのビルドはサーバーの初期費用、固定費用がかかりますが、EC2 インスタンスはビルドが必要な時に起動してビルドが終了したら削除することができます。料金は使用した時間のみに発生します。

処理量に応じて GPU を搭載したEC2インスタンスから最大 4.0 GHz の CPU、最大 24 TiB のメモリマシンまで豊富なラインアップの中から選択できます。

並列処理可能な大規模処理においては EC2 の台数をスケールアウトして実行することも可能です。このような用途においては AWS Batch も利用可能です。また、さらに低料金でサーバーを利用したい場合は EC2 スポットインスタンスを利用するという選択肢もあります。

 

 AWS 上で利用する Perforce の構成パターン

では、実際に AWS 上に Perforce をホストするにはどのような構成パターンがあるのでしょうか？
AWS だけで Perforce を構成する All-in アプローチと AWS とエッジ側のオンプレマシンを組み合わせてパフォーマンスを向上させる Hybrid 構成などを含めてここでは４パターンをご紹介します。

1. Perforce マスターサーバ (P4D) のみを AWS 上に構築する

この方法は Perforce マスターサーバ及び必要に応じて冗長化のためのレプリカサーバを AWS 上にホストする All-in パターンで、もっともオーソドックスな構成です。
全てのソースコードやデータアセットは AWS 上に保存され、開発者はオフィスにある開発用 PC から Amazon VPC に対して VPN や AWS Direct Connect で接続を行いデータを Perforce マスターサーバに対して直接 sync したり submit します。

この基本構成はもっとも核となるもので、最初のうちはコストをかけたくないといった場合にはまずは Perforce マスターサーバのみを AWS 上で動かし徐々に拡張していきながら次に述べる Hybrid 構成へ移行していく方法があります。

2. AWS とオンプレの Hybrid 構成

1のようにAWS 上で Perforce マスターサーバを構築すると同時に、オフィス内など Perforce のユーザー側ネットワーク上のオンプレミスマシンに Perforce プロキシサーバ (P4P) やエッジサーバを配置する方法です。

このようにユーザー側に近いオンプレミスマシンにプロキシサーバ (P4P) やエッジサーバを配置して、ユーザー側のパフォーマンスを向上したのがこの Hybrid 構成(クラウド+オンプレミス)です。

  • Perforce プロキシサーバ (P4P)
    • 開発者のオフィス内など開発者側のネットワークに配置して頻繁に転送されるバージョン化ファイルをキャッシュするためのプロキシ機能です。Submit は処理できないので、クライアント (P4) は Submit を直接マスターサーバにリクエストします。
  • Perforce エッジサーバ
    • Perforce マスターサーバのレプリカ機能の一種で、開発者のオフィス内など開発者側のネットワークに配置して利用します。マスターサーバの部分複製とマスターサーバとは分離した独立のメタデータ(データベース)を持つことができます。独立したメタデータの更新処理においては、エッジサーバ側で処理を完結できます。マスターサーバを介さずに開発者側に近い環境で大部分の処理を完結できるためパフォーマンスを向上します。Submit の処理においてはマスターサーバに処理を転送します。
  • 転送レプリカ (Forwarding Replica)
    • Perforce マスターサーバのレプリカ機能の一種で、マスターサーバの完全複製、または一部複製 (バージョン化ファイル + メタデータ + ジャーナル) を持つ読み取り専用のレプリカサーバです。Sync などのクライアントからの読み取り操作において、データベースの更新が必要な時以外は転送レプリカが直接データを返します。クライアントからのメタデータの更新リクエストに関しては、自身では処理せずにマスターサーバへ処理を転送します。

3. Perforce プロキシサーバ (P4P) のみを AWS に構築する

この方法はすでにデータセンターやオフィス内にあるオンプレミスのマシン上で Perforce マスターサーバが稼働している場合に、AWS上にはPerforce プロキシサーバのみを配置する方法です。

オンプレミスのデータセンターにある Perforce マスターサーバから地理的に離れた場所で開発している開発者に対して、もっとも近いAWSリージョンに Perforce プロキシサーバやエッジサーバを配置することで、遠隔地の開発者のパフォーマンスを向上します。

また、別の用途としては AWS 上でコードのビルドパイプラインを組んでいるような場合には、そのパイプラインと同一の AWS リージョンに Perforce プロキシサーバを配置することで、データセンターにある Perforce マスターサーバからのデータの sync 時間を短縮し高速化します。この際、データセンターの場所によっては Amazon VPC との間で AWS Direct Connect 接続が可能です。

4. Perforce Replica のみを AWS に構築する

すでにオンプレミスで Perforce マスターサーバが稼働している場合には、Disaster Recovery 用途の Hot Standby としてPerforce レプリカサーバ だけをAWS上で構築する方法があります。こちらは用途としてはそれほど多くないかもしれませんが、将来的に AWS ヘ Perforce マスターサーバを移行する際の足がかりになるかもしれません。

 

Perforce マスターサーバの設定と構築

実際に Perforce マスターサーバを AWS 上に構築する場合の技術選定の要点をここでは紹介します。
細かい設定の手順に関しては次回以降のブログでご紹介します。

EBS ストレージの設定について

用途に応じたボリュームの設定
ボリューム名 用途 ボリュームサイズ (Base Size) EBS ボリュームタイプ EBS 暗号化オプション
hxdepots アーカイブファイル格納
depot 用の volume		 1TB st1 暗号化あり
hxmetadata メタデータ用の volume 64GB gp2 暗号化なし
hxlogs ジャーナルファイルやアクセスログなどを格納するログ用の volume 128GB gp2 暗号化なし

Perforce はリポジトリですので、マスターサーバを設定するにせよ、HA 用のレプリカサーバを作成するにせよデータを保存するためのストレージの設定が重要になります。

Perforce のデータ構造は、主にバージョン化ファイル自体を格納する領域とファイルのメタデータ(データベース)の領域とライブジャーナルを格納する３つの領域に分かれています。

このため、EC2 には OS root volume 以外に用途に応じて下記の３つの volume を作成するのが理想です。プロジェクト規模にも依存しますがそれぞれの volume に対して下記のボリュームタイプとボリュームサイズを設定することを Perforce の技術ガイドでは推奨しています。

  1. hxdepots : Perforce のアーカイブファイルを全て格納する depot 用のボリューム

    • 大容量が必要でありシーケンシャルアクセスが多くなることから、ストレージ単価が安価でありながらある程度のスループットも保証されたスループット最適化 HDD (st1) を利用します。プロジェクト規模にも依存しますがテラバイト級のボリュームサイズの確保が必要でしょう。1TB 以上を確保することを Perforce の技術ガイドでは推奨しています。

  2. hxmetadata : 頻繁にランダム I/O アクセスが発生するメタデータ用のボリューム

    • 低レイテンシーの汎用 SSD (gp2) を利用します。ユーザー数が増えてアクセスが頻繁になりメタデータ用のvolume (hxmetadata) の IOPS がさらに必要となる場合にはプロビジョンド IOPS SSD (io1) のボリュームタイプを検討してみてもいいでしょう。ボリュームサイズは 64GB を Perforce の技術ガイドでは推奨しています。

  3. hxlogs : ジャーナルファイルやアクセスログなどを格納するログ用のボリューム

    • 低レイテンシーの汎用 SSD (gp2) を利用します。ボリュームサイズは 128GB を Perforce の技術ガイドでは推奨しています。

EC2インスタンスの設定について

Perforce マスターサーバを稼働させる EC2 インスタンスはどれを使ったらいいのでしょうか？
Perforce サーバは通常システムリソースをあまり多く消費しませんが、特に選定にあたっては下記の２点の Perforce の特徴に留意する必要があるでしょう。

  1. CPU リソースについて

    • ゲームの開発用途で多数の巨大なバイナリファイルを利用している場合、そのバージョン化ファイルのデータの圧縮、展開処理において CPU 負荷がかかるので CPU パフォーマンスを重視する必要があります。EC2 インスタンスではコンピュート最適化インスタンスの C5 ファミリーがこの要件に合致します。

  2. メモリ (RAM) のリソースについて

    • 大量のクエリを実行中のサーバにページングをさせないようにすることと、メタデータに格納されているデータベースファイルの一部のテーブルをメインメモリにキャッシュさせることによって動作を高速化させることができます。EC2 インスタンスではメモリ最適化インスタンスの R5 ファミリーが要件に適合します。

さらに C5 ファミリーにおいても R5 ファミリーにおいても EBS 最適化インスタンスであり、また同時にネットワーク帯域幅に関しても「最大 10 Gbps」以上の性能を兼ね備えています。

 

条件によりどちらのファミリータイプを選定するかは変わってきますが、Perforce の技術ガイドでは 32 GiB の十分な RAM を積んだコンピュート最適化インスタンスである c5.4xlarge の利用を推奨しています。

これは CPU リソースが最適化されていることはもちろん、ゲームデータの全アセットがテラバイト級になったとしても、32 GiB の十分なメモリがあるので上記のメモリ条件をも満たしているからです。

Security Group の設定について

Perforce サーバーの稼働する EC2 インスタンスに対して、セキュリティグループの Inboud Rules に以下のポートを設定します。

  • Port 1666
    • p4broker のプロセスは Port 1666 で Listen するので、Port 1666 を解放します。
  • Port 1999
    • p4d のプロセスは Port 1999 で Listen するので、Port 1999 を解放します。
  • Port 22 (SSH)
    • Perforce サーバーのインスタンスにログインして作業をするため、Port 22 を解放します。

ただし、p4broker を利用しない場合は、p4broker の代わりに p4d のプロセスが port 1666 で Listen しますので、Port 1999 の解放は必要なくなります。

また、セキュリティの観点から社内ネットワークからのアクセスのみに限定する場合は、Inboud Rules の設定で Source IP を指定してアクセス元を制限することを推奨します。

 

Perforce Helix Core Studio Pack for AWS で Perforce Helix Core を使ってみよう

最近、 Perforce と AWS Game Tech は共同で Perforce Helix Core Studio Pack for AWS というパッケージをリリースしました(リリースブログ)。

こちらはまずは AWS 上で Perforce Helix Core を構築して試してみたいというユーザーのために下記のコンテンツを無料で提供するスターターパックです。

  • Helix Core 上の最大５ユーザーと最大20ワークスペースの無料提供
  • AWS クラウドの12 か月間の無料枠の提供
  • Best Practices For Deploying Helix Core on AWS というタイトルの無料の技術ガイドの提供

では、早速使ってみましょう！利用にあたっては、こちらのPerforce様のサイトでHelix Coreの利用登録手続きを済ませてください。

まとめ

ここまで読んでいただき、ありがとうございました。

本記事では、AWS 上で Perforce Helix Core を構築することの利点を解説し、実際の構成パターンと構築における注意点を解説しました。

次回の第2回目のブログでは上記でご紹介した Perforce 構築パターンのうち「Perforce マスターサーバ (P4D) のみを AWS 上に構築する」CloudFormation テンプレートをご案内して、実際の構築手順と利用法を紹介していきます。

 

乞うご期待！！

 

著者について

保里 善太 (Zenta Hori)
AWS 技術統括本部 ソリューションアーキテクト

半導体関連精密機器の組み込み制御エンジニアとして研究開発のキャリアをスタートさせ、モバイルゲーム業界での開発経験、FinTech 業界でのエンジニア経験、スタートアップでの CTO 経験を生かして日々技術支援を必要としている AWS ユーザー様をサポートしています。現在はもっぱら機械学習を利用したセキュリティリスクの自動検知や機械学習をゲーム開発にどう活用するかに興味関心があり、日々研究や学習に励んでいます。