サーバーレス非同期マルチプレイヤーのリファレンスアーキテクチャ

[アーティクル]
09/21/2022

アーキテクチャの図

アーキテクチャのサービス

Azure Functions - 小規模なマッチメイキングロジックを実行するために使用されます。消費計画を使用する場合、関数の定義は File Storage に保存されるため、ストレージアカウントを作成する必要があります。最適なパフォーマンスを得るには、関数と同じリージョンのストレージアカウントを使用する必要があります。
Azure Database for MySQL - 速く、軽量で、信頼性が高く、コスト効果がよいので、情報を格納するために使用されます。
通知ハブ - 多数のプラットフォーム (iOS、Android、Windows、Kindle、Baidu など) に通知を送信できる、使いやすい、スケールアウトされたプッシュエンジンです。
SignalR - HTTP を介してアプリケーションにリアルタイム Web 機能を追加するプロセスを簡素化し、接続されているクライアントデバイスにデータをプッシュできるようにします。
Key Vault - データベース接続文字列など、シークレットを管理するのに最適なサービスです。

設計時の考慮事項

この特定のリファレンスアーキテクチャでは、シンプルなサーバーレスの三目並べゲームを示します。

このリファレンスアーキテクチャでは、ヘルパークラス (データクライアント) はデータベースに接続して対話し、他の関数は必要に応じてそれを使用します。ゲームセッションクラスは、プレイヤーによって送信された情報を使用してターンを実行するため、および勝者を計算するために使用されます。次の 3 つの異なるアクションイベントがサポートされています: forfeit (ゲームを投了する)、addPlayer (プレイヤーをゲームセッションに参加させる)、takeTurn

デプロイテンプレート

Azure サービスの名前付け規則と制限事項をまとめたセクションが含まれる一般的なガイドラインドキュメントを参照してください。

注意

ARM テンプレートの動作に興味がある場合は、このリファレンスアーキテクチャで利用されている各サービスの Azure Resource Manager テンプレートのドキュメントを参照してください。

警告

データベース管理者のパスワードには、8 から 128 文字にする必要があります。また、次のカテゴリのうち 3 種の文字が含まれている必要があります: アルファベット大文字、アルファベット小文字、数字 (0-9)、英数字以外の文字 (!、$、#、% など)。

ヒント

Azure Functions をローカル環境で実行するには、local.settings.json ファイルをこれらの同じアプリ設定で更新します。

ステップバイステップの手順

新しいゲームセッションを作成する

クライアントデバイスは、プレイヤーが選択したゲームの設定をフォーマットし、バックエンドにゲームセッション開始イベントを送信した後、応答を待機します。
バックエンドは、新しいゲームセッションを開始するコマンドを受信します。バックエンドは、最初に、プレイヤーの設定と一致する既存のゲームセッションの検索を試みます。
マッチメイキング用に適切なゲームセッションが利用できない場合は、新しいゲームセッションオブジェクトが作成されます。
新しい永続的オーケストレーター関数が作成されます。
永続的オーケストレーター関数は、ゲームセッションオブジェクトを読み取り、少なくとも 2 人のプレイヤーがゲームセッションに参加するまで待機します。
最初のプレイヤーによって選択されたものと同じ設定を持つ別のプレイヤーが、バックエンドにゲームセッション開始イベントを送信します。
バックエンドがコマンドを受信し、既存のゲームの検索を試みます。この場合は、以前に作成されたゲームセッションが見つかります。
永続的オーケストレーター関数は、addPlayer イベントを受け取り、ゲームセッションに参加するプレイヤーが 2 人になったので待機を停止します。
永続的オーケストレーター関数は、マッチを正式に開始し、ゲームの状態を進行中に設定して、プレイヤーの 1 人をランダムに選んで開始します。一言で言えば、オーケストレーターはゲームのロジックを実行し、ゲームの状態を更新する責任を負います。
永続的オーケストレーター関数は、データベースにデータを保持する操作をトリガーします。データクライアントヘルパークラスを利用して、データを保持するためにデータベースに接続します。
永続的オーケストレーター関数は、ゲームセッションのロジックを実行し、次のプレイヤーのターンであることを返します。
ゲームの状況 (誰かのターン、誰かの勝ち、誰かの投了など) に基づいて、1 人または複数のプレイヤーへの通知をキューに入れます。
その後、永続的オーケストレーターは、新しいゲーム状態で自分自身を呼び出し、次のイベントの受信を待ちます。
クライアントデバイスは、ゲームセッションを管理するオーケストレーター関数の一意の識別子を含む通知を受け取ります。
クライアントデバイスは、通知で受け取った永続的オーケストレーターの一意の識別子が含まれるゲームセッション読み込みイベントをバックエンドに送信します。
バックエンドは、ゲームセッションを読み込むコマンドを受け取り、クライアントデバイスによって表示されるゲームセッションの詳細を返します。
プレイヤーは、X または O を永続的オーケストレーター関数に直接送信し、ターンを終了します。

プレイヤーゲームリストを要求する

クライアントデバイスは、セッションのリストの取得コマンドをバックエンドに送信します。
バックエンドは、データベースのクエリを実行して要求を処理し、データをクライアントデバイスに送信します。クエリによって返される結果の数を制限し、結果を並べ替えることを検討します。
クライアントデバイスは、バックエンドの応答を受け取り、そこに含まれるデータを使用して、関連する UI を設定します。

実装サンプル

読者のための演習

提供されているサンプルには、データベースからの読み取りをスケーリングするロジックは含まれず、書き込みのみが含まれています。データベースへの接続が使い果たされるのを防ぐため、データベースの前面にキャッシュを配置するか、データベースをスケールアップすることを検討してください。

セキュリティに関する考慮事項

データベースの接続文字列を、関数のソースにハードコーディングしないでください。代わりに、少なくとも、関数アプリの設定を利用するか、より強力なセキュリティのためには、代わりに Key Vault を使用します。キーコンテナーを作成する方法、関数でマネージドサービス ID を使用する方法、および最後に関数から Key Vault に格納されているシークレットを読み取る方法について説明されているチュートリアルがあります。

代替手段

このリファレンスアーキテクチャでは、Azure Database for MySQL が使用されていますが、Azure SQL Databaseまたは Azure Database for PostgreSQL に置き換えることができます。

その他のリソースとサンプル

永続的関数と Azure SignalR Service を使用した雑学ゲーム

完全に非同期ではありませんが (20 秒のタイマーで実行されます)、永続的関数と Azure SignalR Service で構築された雑学ゲームの実装を、こちらのリンクで見つけることができます。ヒントは jservice.io から取得されます。実行しているところを確認するには、こちらのリンクを参照してください。

しくみは次のとおりです。

雑学ゲームのホストが、デプロイ時に、または Web 要求経由で、HttpStartSingle Azure 関数を呼び出して、ゲームを開始します。
Azure 関数が、TriviaOrchestrator 永続的 Azure 関数を開始します。
プレイヤーがゲームに参加します。アプリを実行している各プレイヤーのクライアントデバイスが、バックエンドから Azure SignalR Service ハブの詳細を取得します。バックエンドが、SignalRInfo Azure 関数経由で要求を受け取ります。関数バインドにより、接続文字列のキーを使用してトークンが生成され、クライアントデバイスに送信されます。クライアントデバイスは、リッスンする Azure SignalR Service からの 2 つのイベントを設定します: newClue と newGuess。
バックエンドで、TriviaOrchestrator 永続的 Azure 関数によって、GetAndSendClue 永続的アクティビティ Azure 関数が呼び出されます。
TriviaOrchestrator 永続的 Azure 関数によって、20 秒ごとに自分自身を呼び出すタイマーが設定されます。これは、プレイヤーが雑学のヒントに応答するまでの時間の長さです。
GetAndSendClue 永続的アクティビティ Azure 関数により、jservice.io サービスから雑学のヒントが取得されます。
その後、雑学のヒントが、ターゲット newClue を使用して、接続されているすべてのユーザーに対し、Azure SignalR Service によって配信されます。
プレイヤーは、Azure SignalR Service から雑学のヒントを受け取り、回答を考えます。
バックエンドは、SubmitGuess Azure 関数経由でプレイヤーの応答を受け取ります。
この Azure 関数は、プレイヤーによって送信された回答が正しいかどうかを計算します。その後、結果が、ターゲット newGuess を使用して、接続されているすべてのユーザーに対し、Azure SignalR Service によって配信されます。
クライアントデバイスは、Azure SignalR Service からの応答を受け取り、正しい回答または間違えた回答の数を更新します。

価格設定

Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成して 12 か月間の無料サービスの利用を開始できます。それらのサービスの制限を超えない限り、Azure 無料アカウントで無償で提供されているサービスに対して料金が発生することはありません。 Azure Portal または使用状況ファイルを通じて使用状況を確認する方法について説明します。

これらのリファレンスアーキテクチャの実行中に使用される Azure サービスのコストはユーザーが負担します。その合計は使用状況によって異なります。リファレンスアーキテクチャで使用されていた各サービスの価格は、Web ページで確認ください。

また、Azure の料金計算ツールを使用して、使用する予定の Azure サービスのコストを構成および見積もることもできます。

サーバーレス非同期マルチプレイヤーのリファレンス アーキテクチャ