Amazon Web Services ブログ
FlexMatchマッチング状態を確認するためのサーバレスアプリケーションの実装例
マッチメイキングシステムでは、セッションベースのマルチプレイゲームにおいて重要な1つの要素であり、良いマッチメイキングの結果は良いゲーム体験に繋がります。しかし、マッチングの速度、接続先に対するレイテンシー、マッチングの条件設定など考慮するべき要素が多く、実装工数がしばしば問題になります。Amazon GameLift の FlexMatchを使用すれば誰でも堅牢なプレイヤーマッチメイキングをすばやく簡単に作成できます。大人数のマッチメイキングでもレイテンシーが最も少ないサーバーインスタンスで、最大 200 人のプレイヤーを接続させることができます。
FlexMatchを利用する際にプレイヤーはマッチング状態(成功、失敗)を確認する必要があります。今回では、マッチング状況を確認できるサーバレスアプリケーションの実装例を紹介したいと思います。
アーキテクチャ
今回の構成では、マッチング状況のイベント通知をGameLiftからSNS経由しLambdaで処理した後、DynamoDBに保存します。ゲームクライエントはAPI Gatewayを経由し、Lambdaで現在のマッチング状況を確認します。アーキテクチャはゲームクライエントとバックエンドサーバ間にコネクションが確立されていないことを想定した構成です。もしバックエンドサーバから直接クライエントにプッシュ通知を送ることが可能の構成の場合、DynamoDBに保存せず、マッチングの情報をSNS経由でバックエンドサーバのHTTPエンドポイントを受付、ゲームクライエントに直接送信するシンプルな構成も考えられます。またモバイル端末なら、SNSから直接プッシュすることも可能です。詳細はこちらのドキュメントに参照してください。
マッチング結果の保存
まずマッチング状況のイベント通知をDynamoDBに保存するまでの設定を行いましょう。
SNSを設定
こちらのドキュメントを参照して新規SNS Topicを作成、GameLift の関連権限を JSON に追記します。
GameLiftと連携するには、GameLiftのコンソール画面から、”マッチメイキング設定の作成を選択肢“、‘通知先“のところで設定することが必要です。本記事では、SNSからメッセージの発行を行い、全体をテストするため、GameLiftとの連携は行わなくても大丈夫です。
DynamoDBの設定
- DynamoDBのコンソールを開き、”テーブル作成”をクリックします。
- テーブル名は先程環境変数に入れたmatchmakingを設定し、プライマリキーはticketIdを設定します。
- ”作成”をクリックし、テーブルを作成します。
今回はdefaultの設定になりますが、本番ゲームで利用する際に十分なキャパシティを設定する必要があります。ゲームリリース時はプレイヤーの数は予測困難の場合、キャパシティーモードをオンデマンドに変更することがおすすめです。オンデマンドキャパシティーモードの詳細についてこちらのドキュメントを参照してください。
Lambda関数の作成と関連の権限設定
AWS Lambda関数とは、ユーザによるサーバー管理が不要なAWSサーバーで実行されるコードです。GameLiftからSNSの通知をLambdaで受けて、マッチング成功しましたら、DynamoDBに保存します。
詳細の手順は以下のようになります。
- Lambdaのコンソールを開き、”関数の作成”をクリックします。
- “一から作成”を選択します。
- 関数の名前に”FlexMatchEventHandler”を入力します。
- ランタイムで”Python 3.8″を選択します。
- アクセス権限で”実行ロールの選択または作成”を表示し、”基本的なLambdaアクセス権限で新しいロールを作成”が選択されていることを確認します。
- “関数の作成”をクリックします。
- Lambdaエディタが開きます。Lambda関数がDynamoDBにアクセスできるか確認する必要があります。アクセス権限のタブを開き、”実行ロール”セクションがあることを確認します。
- 新しく作成されたロールは”service-FlexMatchEventHandler-role-abc1defg”のような名前です。そのロールリンクをクリックします。
- 新しいウインドウもしくはタブでロール設定のIAMのページが開きます。アクセス権限タブでポリシーのリストが確認できます。そこにはすでに”AWSLambdaBasicExecutionRole”が存在します。DynamoDB へのアクセスを許可するために2番目のポリシーを追加する必要があります。
- “ポリシーをアタッチします”をクリックします。そのリンクを新しいウインドウもしくはタブで開くことをおすすめします。あとで本ページに戻ってきます。
- “ポリシーの作成”をクリックします。
- ビジュアルエディタを利用します。(JSONのテンプレートを提供することもできましたが、いろいろなAPIが利用可能で、それらがどのように構築されているかを確認いただくのも興味深いと思います)
- “サービスの選択”をクリックします。
- DynamoDBを検索し、結果をクリックします。
- アクセスレベルで”読み込み”を展開し、”GetItem”をチェックします。
- “書き込み”を展開し、”BatchWriteItem”をチェックします。今回のLambdaではnofiticationを受付、成功したチケットを一気に書き込む機能を持ち、本来であればBatchWriteItemのみが必要になりますが、その後ゲームユーザからTicketIdを用いて現在のマッチング結果的を検索する機能もあるのでGetItemも付与しました。AWSのベストプラクティスとしてIAM権限は最小限に留めておくことをおすすめしますが、もしLambda 関数で他のDynamoDBの操作(QueryやScan)を実装する予定があれば、関連する権限付与を忘れないでください。
- リソースはすべてのリソースを指定します。
- “ポリシーの確認”をクリックし、ポリシーの名前に“MatchingEventDynamoDBServicePolicy”と入力します。完了後、”ポリシーの作成”をクリックします。
- そして、IAMロールのアクセス権限のページに戻ります。画面を更新し、新しいポリシーである”MatchingEventDynamoDBServicePolicy”を検索し、選択、”ポリシーのアタッチ”をクリックします。
- Lambda関数にコードを追加します。Lambdaエディタのページに戻り、以下のコードを関数コードのエディタにペーストします。元々存在していたコードもすべて上書きします。
21.今回はMatchingの結果成功した場合だけDynamoDB書き込みを行うシンプルなLambda関数になっています。FlexMatchから通知イベントは「マッチング開始」、「マッチング候補が作成された」や「マッチング成功・失敗」など、全部8種類があります。今回はMatchingの結果成功した場合だけDynamoDB書き込みを行っていますが、他のタイミングも記録したい場合は、その処理を追加することが必要です。イベントのフォーマットと通知タイミングは、こちらのドキュメントを参照してください。
22.Lambda内のDynamoDBテーブル名を環境変数から読み込みます。コードエディタの下に環境変数のブロックで、“編集”をクリック。
23.“環境変数の追加“をクリックし、KeyをMATCHING_TABLE、Valueをmatchmakingを入力し、保存します。
24. エディタの右上の“保存”をクリックすれば、Lambdaの部分は準備完了になります。
SNSとLambdaの連携設定
- Amazon SNSのコンソールを開き、先程作成したSNSトピックを開きます。
- “サブスクリプションの作成”をクリックします
- プロトコルはLambdaを選択します。
- エンドポイントは先程作成したLambdaのエンドポイントを選択します。
- サブスクリプションを作成します。
作成後、FlexMatchEventHandlerのLambda関数に戻りますと、snsのトリガーが追加されたことが確認できます。
結果確認
- 作成されたSNSのトピックのコンソール画面から、”メッセージの発行“をクリックします。
- 下記のリンクでMatchmakingSucsssのサンプルjsonをコピーし、エンドポイントに送信するメッセージ本文のところに貼り付けます。
https://docs.aws.amazon.com/ja_jp/GameLift/latest/developerguide/match-events.html#match-events-matchmakingsucceeded-example - DynamoDBのコンソールを開き、マッチング成功したチケットが保存されたことを確認できます。
Serverless Applicationでマッチング状況を確認
まずマッチング状況のイベント通知をDynamoDBに保存するまでの設定を行いましょう。APIGatewayとLambdaを利用し、DynamoDBに保存します。
サーバレスのアプリケーションについて、より詳細を確認したい場合は、こちらの資料を参照してください
Lambda関数の作成と関連の権限設定
先程と同様の手順で、Lambda関数を作成することができますので詳細手順は割愛しますが、差分を説明します。
- step3関数の名前は設定部分は、”MatchingResultHandler”を入力します
- 先程作成したDynamoDBポリシーは流用できるため、Step 10~18は不要です。
- 環境変数の設定は上記と同様になります。KeyをMATCHING_TABLE、Valueをmatchmakingを入力し、保存します。
- 今回Lambda functionのコードは下記の内容を利用します。下記のlambda関数はticketIdを用いて、DynamoDBで検索するシンプルな実装になります。
API Gatewayの設定
- Lambdaのコンソールを開き、”API作成”をクリックします。
- REST APIを選択します。
- プロトコルは“API”を選択し、新しいAPIの作成では新しいAPIを選択します。
- API名を“matchevent”を入れ、“API作成”をクリックします。
- アクション”、“メソッドの作成”をクリックし、Getのメソッドを作成します。
- “Lambda プロキシ統合の使用“を有効し、lambda関数は先程作成したMatchingResultHandlerを入力します。
作成後、MatchingResultHandlerのLambda関数に戻りますと、ApiGatewayのトリガーが追加されたことは確認できます。 - “アクション”、”APIのデプロイ”を選択し、“新しいステージ”を選びます。
- ステージ名を”test“を入れて、APIをデプロイします。
成功したら下記のようにtestのステージのURLが生成されます。
結果確認
先程生成されたURLの後ろに“?id=ticket-1“をつけて、ブラウザでアクセスしてみると、先程保存されたチケット情報が確認できます。
id=ticket-3に変更すると成功したマッチングの中に存在しないため、”Match not available”が表示されます。
これでマッチングイベントの保存と読み込みも実装完了です。
最後
今回はFlexMatchイベント通知のサーバレスによる実装例を紹介しました。ログの処理、失敗時の処理、データの処理関連はかなり省略した形のサンプルのため、本番運用ではその周りのロジックも細かく設定する必要があります。例えば、クライエントにnotificationが届かない時のリトライ処理、マッチングのログ分析、マッチングのデータ管理など考えられます。詳細は割愛しますが、もし困ったことがあれば、Solutions Architectにお気軽にご相談いただければと思います。また、個別相談会も受け付けております。お気軽にお問い合わせください。
ソリューションアーキテクト Fan Liang