Amazon Web Services ブログ

AWSを使ったUnreal Engine Pixel Streamingの大規模デプロイ

Epic Games が開発した Unreal Engine は、フォトリアリスティックなビジュアルや没入感のある体験を作成およびレンダリングするための最も高度なツールの 1 つです。これは最新のゲームとメタバースを強化するために必要です。従来、このような体験には、ディスクリートGPUを搭載した重厚なクライアント、たとえばデスクトップコンピューターが必要でした。Unreal Engine の Pixel Streaming を使用すると、クラウド内のサーバーで Unreal Engine アプリケーションを実行し、レンダリングされたフレームとオーディオを WebRTC を使用してブラウザやモバイルデバイスにストリーミングできます。

AWS と Unreal Engine の Pixel Streaming を使用することで、開発者は Unreal Engine でコンテンツを作成し、それを Windows または Linux 上の Amazon Elastic Compute (EC2) にデプロイできます。この記事では、Unreal Engine アプリケーションを大規模にデプロイする方法に焦点を当てます。つまり、ユーザーのストリーミングリクエストに基づいて EC2 インスタンスを起動および停止できるということです。この記事では、これらの EC2 インスタンスでのユーザーストリーミングセッションの管理についても説明します。

Pixel Streaming コンポーネントの概要

ホスティングとデプロイの観点から、Pixel Streaming ソリューションには 4 つの主要コンポーネントがあります。

  1. ゲームロジックを実行する Unreal Engine アプリケーションパッケージ
  2. WebRTCプロトコルを介してクライアントにトラフィックを処理するためのシグナリングおよびWebサーバー、およびCoTURN（TURNサーバー用）
  3. 複数のゲームインスタンスに負荷を分散し、クライアントとゲームアプリケーション間の接続を処理するマッチメーカーサーバー
  4. クライアント (ブラウザ) でパッケージセッションを実行するフロントエンドコンポーネント

シグナリングサーバー、CoTurn サーバー、およびUnreal Engine アプリケーションは同じ Amazon EC2 インスタンスでホストできます。インスタンスには、G4dn などのインスタンスファミリーが提供する GPU 機能が必要です。インスタンスには、CoTURN がクライアントとの WebRTC セッションを維持するためのパブリック IP アドレスも必要で、パブリックサブネットにデプロイできます。この記事の残りの部分では、この Amazon EC2 インスタンスをシグナリングサーバーと呼びます。

マッチメーカーサーバーは、プライベートサブネットにデプロイされた別の汎用 Amazon EC2 インスタンスでホストできます。この記事の残りの部分では、この Amazon EC2 インスタンスをマッチメーカーサーバーと呼びます。

フロントエンドコンポーネントは、プライベートサブネットにデプロイされた別の汎用 Amazon EC2 インスタンスでホストできます。この Amazon EC2 インスタンスをフロントエンドサーバーと呼びます。

これらのコンポーネントがデプロイされると、ユーザーのデバイス (Web ブラウザーなど) からのストリーミングセッションのリクエストにより、次の一連の手順が開始されます。

  1. フロントエンドサーバーはユーザーのリクエストを受け取り、ユーザーのブラウザーに Web ページをレンダリングします。
  2. ユーザーは Web ページ上のボタンを選択してセッションをリクエストし、そのボタンがマッチメーカーサーバーを呼び出します。
  3. マッチメーカーサーバーはユーザーリクエストを受信し、リクエストを処理できるシグナリングサーバーがあるかどうかを確認します。
  4. シグナリングサーバーが使用可能な場合、マッチメーカーサーバーはシグナリングサーバーの詳細をユーザーのブラウザーで実行されている Web ページに送信します。
  5. Web ページは、シグナリングサーバーへの WebSocket 接続を確立します。
  6. シグナリングサーバーは、ストリーマーポートで Unreal Engine アプリケーションパッケージに接続し、ユーザー情報を渡します。
  7. Unreal Engine アプリケーションパッケージは CoTURN を使用してすべてのストリームトラフィックをユーザーのウェブページに転送します。

注:フロントエンドサーバーのデフォルト実装は、シグナリングサーバーと直接通信します (ステップ 5)。マッチメーカーを利用する場合はフロントエンドサーバーを修正してください。

上記の一連の手順では、ストリーミングセッションが単一のユーザーリクエストでどのように機能するかを説明していますが、複数の同時ユーザーセッションリクエストを処理するにはどうすればよいでしょうか。 また、セッションが完了したら、シグナリングサーバーはどうしますか？ 最後に、シグナリングサーバーがユーザーストリーミングリクエストにすぐに対応できない場合はどうなるでしょうか。そのようなシナリオでのユーザーインタラクションの処理方法をはどうすべきでしょうか。 さらに重要なのは、このストリーミングフレームワークを設定する際に、コストとセキュリティをどのように管理するかということです。

ソリューションの概要

このセクションでは、これらの要件を満たすソリューションアーキテクチャを定義することで、これらの質問のいくつかに答えます。まず、ユーザーセッションのリクエストに基づいてシグナリングサーバーを作成できるカスタムの水平スケーリングフレームワークを構築します。スケーリングフレームワークは 2 つの主要コンポーネントで構成されています。

  1. シグナリングサーバーをいつ作成する必要があるかを判断するトリガー
  2. シグナリングサーバーを作成するプロセス

トリガーは、受信したユーザーセッションリクエストを識別し、そのリクエストを処理できるシグナリングサーバーをマッチメーカーサーバーに確認する必要があります。マッチメーカーサーバーが使用可能なシグナリングサーバーを返すことができない場合、トリガーロジックは新しいシグナリングサーバーの作成を開始します。このオーケストレーションは、ユーザーセッションリクエストでこのロジックを実行する AWS Lambda 関数によって行われます。

シグナリングサーバーを作成するプロセスは、新しい Amazon EC2 インスタンスを起動し、シグナリングサーバーのコンポーネントをデプロイする AWS Lambda 関数に実装されます。さらに、シグナリングサーバーをアプリケーションロードバランサー (ALB) のターゲットグループに登録して、ロードバランサーの URL を使用してシグナリングサーバーにアクセスできるようにすることができます。Amazon EventBridge ルールを作成できます。このルールは、シグナリングサーバーの状態が「実行中」に変更されたときにトリガーされます。次に、AWS Lambda 関数を呼び出して、シグナリングサーバーをターゲットグループに登録します。以下の図は同じフローを示しています。

シグナリングサーバーが実行されると、その状態はマッチメーカーサーバーに通知されます。その後、マッチメーカーサーバーはこのシグナリングサーバーを利用して新しいユーザーセッションリクエストを処理できます。Pixel Streaming の概要で説明したように、マッチメーカーサーバーには、ユーザーセッションリクエストを処理するために利用可能なシグナリングサーバーインスタンスを見つけるロジックがあります。さらに、使用中のシグナリングサーバが新しいユーザセッション要求を処理するように選択されないようにします。

シグナリングサーバーはユーザーセッションリクエストに基づいて作成されるため、シグナリングサーバーがリクエストを処理できるようになるまで、リクエストを追跡する必要があります。この要件には、Amazon Simple Queue Service(SQS) FIFO が適しています。これにより、ユーザーのリクエストを処理する準備ができるまで保存し、先入れ先出し（FIFO）などの何らかの順序付けを適用して、どのリクエストが最初に処理されるかを決定することもできます。トリガーはキューをポーリングして、受信するユーザーセッションリクエストを監視できます。

さらに、シグナリングサーバーがリクエストを処理できるようになったら、その情報をユーザーに中継する必要があります。これで、ユーザーはサーバーを利用してセッションを開始できます。WebSocket 接続はこの要件に適合します。これにより、ユーザーに定期的にポーリングしてシグナリングサーバーの可用性を問い合わせる必要がなくなり、シグナリングサーバーの情報をユーザーに中継できます。Amazon API Gateway は WebSocket 接続をサポートしており、AWS Lambda 関数を使用して、WebSocket 接続を介してシグナリングサーバーの詳細をユーザーに送信します、取得されたIPなどの情報からユーザーはシグナリングサーバーに接続することができます。 次の図は、ユーザー要求を管理するためのキューと WebSocket 接続の使用方法を示しています。

前のセクションでは、AWS Lambda 関数と EventBridge を組み合わせてシグナリングサーバーを ALB ターゲットグループに登録する方法について説明しました。ただし、ALB URLが、ユーザーセッションのマッチメーカーサーバーによって識別された指定されたシグナリングサーバーにトラフィックを転送するようにする必要があります。これを実現するもう 1 つの方法は、ターゲットグループに関連付けられた ALB リスナー内のルールを使用して、固有のクエリ文字列で特定のシグナリングサーバーにアクセスできるようにすることです。このクエリ文字列は、新しく作成されたシグナリングサーバーをALBターゲットグループに登録するときに定義されます。次に、AWS Lambda 関数がこのクエリ文字列を（WebSocket接続を介して）ユーザーに中継し、ユーザーがセッションの指定されたシグナリングサーバーに誘導されるようにします。

最後に、ユーザーセッションが完了したらシグナリングサーバーをスケールインするメカニズムが必要になります。これを実現するには複数の方法がありますが、1 つの選択肢は、シェル/バッチスクリプトを使用して一定期間後にインスタンスを停止することです。この期間は、ユーザーセッションリクエストが通常どのくらいの期間続くかによって決まります。 たとえば Linux インスタンスの場合、ユーザーデータに sudo shutdown -halt +20 を追加すると、20 分後にインスタンスが自動的に停止します。Amazon EventBridge ルールは、インスタンスの状態が停止状態になったときにトリガーされ、AWS Lambda 関数を呼び出してインスタンスを終了するように記述できます。

セキュリティコントロール

送信中の暗号化をサポートするために、マッチメーカーサーバー、フロントエンドサーバー、およびシグナリングサーバーの ALB で HTTPS リスナーを設定できます。これにより、お客様のデバイスとのすべての通信がSSL経由になります。

認証用:

フロントエンドサーバーでホストされているアプリケーションを ID プロバイダー (Amazon Cognito など) と統合してユーザーを認証し、bearer token を Amazon API Gateway に送信できます。
Amazon API Gateway には、WebSocket 接続上のトークンを検証する AWS Lambda 関数 (AuthorizeClient) を含めることができます (ソリューションダイアグラムの項目 #2、3、4)。
マッチメーカーサーバーは、クライアント ID とシークレットを使用して API 呼び出しを認証するように設定できます。

最適化のその他の範囲

マッチメーカーサーバーには、使用可能なすべてのシグナリングサーバーを追跡するためのパーシスタンスレイヤーがありません。これを管理するには、Redis 用 Amazon ElastiCache のようなものを使用することを検討してください。詳細については、「Redis 用 Amazon ElastiCache 入門」の記事を参照してください。
シグナリングサーバーは、認証にトークンを要求するように変更できます。トークンは、フロントエンドからの WebSocket 接続の最初のメッセージとして渡すことができます。これは、WebSocket 接続の認証パターンを調べることで実現できます。

コスト最適化に関する考慮事項

このソリューションでは、オンデマンドをシグナリングサーバーインスタンスの購入オプションと見なしています。コストを最適化するために、ストリーミングセッションの完了時にインスタンスを終了するようにスケーリングフレームワークを設定できます。また、任意の時点で実行中のインスタンスの最大数の上限を設定することもできます。そのサンプル実装がリポジトリに含まれています。

年間を通じて消費量がほぼ一定であれば、シグナリングサーバーのコスト削減の手段として、Reserved Instances または Savings plans を検討する価値があります。

マッチメーカーとフロントエンドサーバーの場合、それらをコンテナ化して AWS Fargate でホストできるため、需要に応じたスケーリングが可能になります。ただし、これには、使用可能なシグナリングサーバーを追跡するための persistence layer をマッチメーカーサーバーに追加する必要があります。

まとめ

この記事では、Unreal Engine Pixel Streaming を Amazon EC2 インスタンスに大規模にデプロイし、AWS のサービスを活用して複数のユーザーにオンデマンドでセッションを提供できるソリューションを構築する方法を示しました。この記事で提案されているソリューションのリファレンス実装は、このリポジトリでホストされています。これをフレームワークとして使用してソリューションをさらに構築および最適化し、AWS で Pixel Streaming をすぐに使い始めることができます。

翻訳はソリューションアーキテクトの嶋田が担当しました。原文はこちらです。