サーバーレスベースのゲームバックエンドアーキテクチャ

プレイヤー認証: プレイヤーは Amazon Cognito を使用して認証します。Amazon Cognito は、プレイヤー ID 管理用のユーザーディレクトリを使用した安全な認証を提供します。

サーバーレス関数としてのゲームロジック: ゲーム機能およびバックエンドビジネスロジックは、イベントに応答して開始される関数として実行され、 AWS Lambda 関数の実行時にのみ料金を支払うため、コストが削減されます。Lambda では、選択したプログラミング言語を使用して、各ゲーム機能を個別のマイクロサービスとして柔軟に記述できます。たとえば、C# を使用して Unity ゲームを構築した経験がある場合は .NET Lambda 関数を開発するか、JavaScript でウェブベースのゲームのフロントエンドとバックエンドをプログラムする場合は Node.js Lambda 関数を開発するかを選択できます。

ゲームおよびプレイヤーデータ用の NoSQL データストア: DynamoDB を使用してプレイヤーおよびゲームデータを保存します。これは、マイクロサービスから大量のデータを保存するために構築されているためです。このアーキテクチャで示されているように、ゲーム機能のデータストレージのニーズごとに個別のデータストアを使用するのがベストプラクティスです。これにより、機能を個別にモニタリングおよび管理しやすくなります。これにより、チーム内で機能またはサービスの所有権が変更された場合にも、分離の境界が作成されます。このリファレンスアーキテクチャでは、DynamoDB テーブルを使用して、接続状態、ゲームの詳細、プレイヤーの進行状況、リーダーボード情報などのデータを保存します。

シングルプレイヤーゲームプレイ: シングルプレイヤー機能を使用すると、プレイヤーはゲームの選択やプレイ、リーダーボードの表示などのアクションを実行できます。これらの機能は、適切な Lambda 関数を呼び出して DynamoDB テーブルでデータを取得して設定する Amazon API Gateway HTTP API でホストされる RESTful バックエンドサービスとして実装されます。ゲームプレイが完了すると、バックエンドは Amazon SNS トピックにも通知を送信し、Lambda 関数を非同期的に開始してプレイヤーの進行状況と統計を保存します。

マルチプレイヤーゲームプレイ: マルチプレイヤーゲーム機能では、プレイヤーはpoint-to-point通信のためにゲームとやり取りでき、他の接続されたプレイヤーから更新をブロードキャストおよび受信できる必要があります。WebSockets の実装は、トリビアなどの軽量ゲームでのpoint-to-point通信に適しています。プレイヤーは Amazon API Gateway WebSockets への WebSockets 接続を確立できます。これにより、接続を管理し、プレイヤーに対して送受信するメッセージがある場合にのみ Lambda 関数を呼び出します。プレイヤー間で one-to-manyの通信が必要なユースケースの場合、 は MQTT 経由で WebSockets を使用したメッセージングのサポート AWS IoT Core を提供します。これにより、クライアントはトピックをサブスクライブし、受信したメッセージに対応できます。このアーキテクチャでは、MQTT 経由の WebSockets は、ゲーム内のライブ更新のブロードキャストや、接続されたプレイヤーへの質問などのユースケースをサポートするために使用されます。代わりに AWS IoT、メッセージ配信に Redis Pub/Sub を選択するか、メッセージ保持が必要な場合は Redis Streams を選択できます。

VPC 対応 Lambda 関数を使用してプライベートサブネット内のリソースにアクセスする: Amazon ElastiCache などの VPC のプライベートサブネット内のリソースにアクセスするように VPC 対応 Lambda 関数を設定します。これは、ライブリーダーボードなどの低レイテンシーデータセットのクエリ時間を短縮するために使用されます。