マルチプレイヤー バックエンドのリファレンス アーキテクチャ
これらのリファレンス アーキテクチャでは、さまざまなマルチプレイヤー バックエンドの使用例と実装およびさまざなま代替手段が説明されており、自分のゲームで動作するクラウド ソリューションを設計できます。
使用例
ゲームのマルチプレイヤー バックエンドを設計するときに考慮できる変数が数多くあります。 次に例を示します。
- 管理のレベル - すべての作業を自分で行う場合から、すべての処理をプラットフォームに任せる場合まで
- オペレーティング システム - Windows または Linux
- ゲーム セッションを実行する場所 - 専用サーバーまたはピア ツー ピア (P2P)
- ハードウェア - ゲーム セッションで実行できる必要があるもの
- 処理時間 - リアルタイムまたは非リアルタイム (NRT)
- 待機時間 - 遅延時間があるかどうかで、プレイヤーは不利になります
- 永続化 - ゲームの世界は、プレイヤーが対話していない場合でも内部的に存在して発展し続けるか、またはセッションごとに独自の開始と終了があります。
- 同時プレイヤーの数 - 小、中、大
- 再接続の許可 - プレイヤーは、切断された場合、ゲームに戻ることができるか、または新しいゲーム セッションを開始する必要があります。
参考用のマルチプレイヤー バックエンドの使用例を次に示します。
ヒント
すぐに使えるマルチプレイヤー サーバー スケーリング ソリューションを探している場合、PlayFab は、マルチプレイヤー サーバーのサポートを備えたクラウド接続ゲームを構築、公開、拡大するための完全なバックエンド プラットフォームです。
マルチプレイヤーの設計
管理のレベル
コンピューティング サービスによって提供される管理のレベルは、ユーザーがすべてを自分で管理するものから、プラットフォームによって完全に管理されるものまでさまざまです。
- そのままの仮想マシン - ユーザーがすべてを管理します。カスタム スケーリング ソリューションが必要です。
- Azure Container Instances (ACI) - ユーザーがすべてを管理しますが、コンテナー内で行います。カスタム スケーリング ソリューションが必要です。
- Virtual Machine Scale Sets / Batch - ユーザーが定義した規則に基づき、ユーザーに代わって仮想マシンのスケーリングを管理します
- Service Fabric / Azure Kubernetes Service (AKS) - ユーザーに代わって、コンテナーのオーケストレーションを管理します
- PlayFab マルチプレイヤー サーバー - Azure 上でユーザーに代わって実行される、ゲーム サーバーの高レベルのオーケストレーションです。 詳しくは、PlayFab マルチプレイヤー サーバーに関するページをご覧ください。
オペレーティング システム
次の表では、さまざまな Azure コンピューティング サービスでサポートされているオペレーティング システムの概要を示します。
| サービス | Windows のみ | Linux のみ |
|---|---|---|
| 未加工の仮想マシン | 〇 | 〇 |
| Azure Container Instances (ACI) | 〇* (Windows 10 1607 のみ) | 〇 |
| Virtual Machine Scale Sets | 〇 | 〇 |
| Batch | 〇 | 〇 |
| Service Fabric | 〇 | 〇 |
| Azure Kubernetes Service (AKS) | AKS エンジンによってのみ | 〇 |
| Functions | 〇 | 〇 (専用モード) |
* 注: 現在、マルチコンテナー グループは Linux コンテナーに制限されています。
ゲーム セッションが実行される場所
専用サーバー
プレイヤーは、ゲームをプレイするために、クライアント デバイスをサーバーに接続します。
専用サーバーの使用を検討している場合は、次の点に注意します。
- 接続性と信頼性に関してメリットがあります。
- 実装とスケーリングが非常に簡単です。
- プレイヤーによる不適切な行為は困難です。
- ゲームがフレーム同期されている場合、他のプレイヤーのインターネットが影響を受ける可能性があります。
- ゲームの種類によっては、専用サーバーに非常に近いプレイヤーは、より遠くに住んでいるプレイヤーより明確に優位になる場合があります。
ピア ツー ピア (P2P)
P2P モデルを検討している場合は、次の点に注意します。
- 運用コストは、専用サーバーを利用する場合ほど高くありません。
- 専用サーバー ソリューションより、真の実装を適切に成功させることは困難です。
- 多くの場所では、ホーム インターネット サービスに、多数のプレイヤーに対処するのに十分なアップロード速度がありません。
- 接続状態が悪いプレイヤーは、他のプレイヤーのゲームに影響を与える可能性があります。
- NAT パンチスルーの問題のため、クライアントが接続できないことがあります。 ポート転送が必要な場合があります。
- 各プレイヤーの IP アドレスを他のすべてのプレイヤーに直接渡すことは避けてください。そうしないと、プレイヤーはゲーム内の他のプレイヤーからの DDoS 攻撃に対して無防備になります。
- ニュートラル サーバーの形式の中央機関がない場合、不正行為を防ぐ簡単な方法はありません。
ロビー
ロビー システムは、実際にゲーム セッションを開始する前にプレイヤーをまとめるためによく使用されます。プレイヤーは、同じ初期状態から開始する必要があります。 遅延参加のサポートを有効にすることは技術的に可能ですが、非常に複雑になるため一般的ではありません。 ロビー システムにはサーバーが必要であり、通常は次のように動作します。
- プレイヤーはロビーを開始し、必要に応じてゲーム パラメーターを設定します。
- 他のプレイヤーは、ゲームで提供されている任意のクエリ メカニズムを使用して、ロビーを表示/検索できます。
- いずれかのプレイヤーがロビーに参加します。
- (ゲームおよびロビー作成者 (いる場合) によって設定されたルールに基づいて) 十分なプレイヤーがいる場合、ロビーで待機している各プレイヤーの詳細がロビーで安全に配布され、その作業は完了します。
- その後、プレイヤーは分散化された方法でパケットの送信を開始します。
監視とアラート
優先的なテレメトリ ソリューションだけでなく、Azure Monitor を利用して、バックエンド ソリューションで使用されている Azure サービスのメトリックと、診断ログおよびアクティビティ ログを公開することができます。 Azure Monitor は、ゲームに影響する問題を特定するのにも役立ちます。 次のアラートを有効にすることを検討してください。
- CPU 使用率 - ホストの CPU が飽和状態に近づいた場合に通知を受け取ります。
- ディスク I/O - ゲームによるディスクの読み書きが予想より多い場合に、アラートを設定します。
- メモリ使用率 - メモリのページングが異常に多い場合は、アラートを受け取る必要があります。
- ネットワーク トラフィック - ネットワーク トラフィックが飽和状態に近い場合、または突然低下する場合は、アラートを生成することを検討する必要があります。
Azure Resource Manager を使用して、Azure Monitor の構成を自動化できます。 Azure Monitor の詳細については、「Azure Monitor を使用したフル スタックのエンド ツー エンドの監視」を参照してください。
ハードウェア
ゲーム セッションを実行するために必要な処理能力、ストレージ、メモリ、およびネットワーク トラフィックを十分に把握できるようにします。これは、マルチプレイヤー バックエンドに必要な仮想マシンの種類に直接関係します。
ゲーム セッションの実行に必要な CPU の数以外に、意思決定プロセスに関連するデータ ポイントがいくつかあります。
- ゲームで必要なスレッドの数。
- 1 つのゲーム セッションに必要な RAM の量。
- ゲームをプレイしているユーザーが必要とする帯域幅の量。
- 1 つのゲーム セッションに含まれるユーザーの数。
- ゲームにハイパースレッディングが必要かどうか。 ゲーム サーバーがハイパースレッディングに依存している場合は、ハイパースレッド化されたコアを使用する必要があります。
- メモリとコアの比率
この情報を収集することで、次のことを把握できます。
1 つのセッションに必要なコアの数。
ゲーム サーバーが 1 つのスレッドで実行されている場合は、1 つのコアで十分です。 ゲーム サーバーが 1.5 のスレッドで実行されている場合は、2 つのコアが必要です。
サーバーで 5 つのゲーム セッションをホストし、各ゲーム セッションに 1 個のスレッドが必要な場合は、少なくとも 5 つのコアが必要です。 サーバーで 5 つのゲーム セッションをホストし、各ゲーム セッションに 1.5 個のスレッドが必要な場合は、少なくとも 8 つのコアが必要です。
オペレーティング システムの消費量を考慮します。 経験則として、1 または 2 コアだけ仮想マシンを多めにプロビジョニングします。
送信される egress のサイズ
これは、経済的な影響があるため、関連する数値です。 また、1 つの仮想マシンのプレイヤーが多すぎる場合、ネットワーク制限や (特に、1 つの NIC で数千人のユーザーを処理しようとするとき)、ボトルネックが発生する可能性があります。
これをすべてまとめて、必要な仮想マシンを決定し、それらに対してどのくらいの費用を支払う必要があるかを判断できます。 仮想マシンの種類が異なると、帯域幅のスループットが異なります。 ネットワーク インターフェイスが要求を処理できることを確認する必要があります。 仮想マシンあたりのプレイヤー数に、プレイヤーごとに消費される帯域幅を乗算します。 その量が、各 VM サイズについてドキュメントで示されている最大 NIC/予想ネットワーク帯域幅 (Mbps) を超えてはなりません。
1 インスタンスの仮想マシンの可用性を向上させるため、Premium ストレージを使用することをお勧めします。 Premium ストレージでは、仮想マシンの SLA は 99.9% です。
遅延の影響
特定のゲームでは、別に第 2 の反射が必要であり、プレイヤーの反応時間と遅延を加えると、ゲームのエクスペリエンスに悪影響を及ぼす可能性があります。
遅延時間を短縮または軽減するには、いくつかの点を考慮する必要があります。 実装の観点からは、クライアント側での予測を有効にし、プレイヤーが画面上で目にするものとゲーム内で実際に発生していることがまれに食い違うことを我慢して、プレイヤーの行動を "事前に取得する" のは、極めて標準的な手法です。 このような食い違いを減らすには、ゲーム オブジェクトを表示する場所の決定に外挿や補間などのメカニズムを使用して、遅延に対する補正を適用することができます。
インフラストラクチャの観点からは、プレイヤーとゲーム サーバーの間の距離が長くなるほど、最終的な遅延が大きくなります。 プレイヤーを最も近いゲーム サーバーに接続すると、影響があります。 Azure には他のクラウド プロバイダーより多くのグローバル リージョンがあり、世界中のプレイヤーに近くなるスケールが提供されます。 高速ネットワークを使用すると、サーバー側の待機時間が短縮される可能性がありますが、少なくとも 4 vCPU の仮想マシンでのみ有効になることに注意してください。 また、Linux 仮想マシンを使用する場合、同じ仮想マシンに多数のプレイヤーがいるときは、DPDK を使用して待機時間とスループットを最適化することも考慮できます。
グループをサポートするゲームでは、グループのメンバー同士が離れている場合に対処する必要があります。 ゲームで、接続先のリージョンを手動で選択できるようにするか、または最小遅延時間共通項アルゴリズムを追加します。
軽減策がうまくいかないシナリオでは、ネットワーク待機時間が管理不能なレベルに達する可能性があります。 そのような場合は、最大の待機時間をもたらしているプレイヤーを切断するなど、より思い切った手段を適用する必要があります。
ヒント
ベスト プラクティスとしては、プレイヤーの待機時間を測定するためのテレメトリを有効にし、QA チームまたはベータ テスターのフィードバック メカニズムとそれを組み合わせることで、遅延の発生を把握できるようにします (つまり、キーの組み合わせ、ゲームパッドのボタンの組み合わせ、または画面上のアイコン)。 どちらの場合も、プレイヤーに遅延と感じさせたものが何かを簡単に見つけられます。
プロトコル
リアルタイムの通信を必要とするゲームでは、ユーザー データグラム プロトコル (UDP) を使用して送信するのがベスト プラクティスです。 実装は伝送制御プロトコル (TCP) より複雑になることが多くありますが、パフォーマンスの点ではるかに優れています。
非同期またはターンベースの通信では、HTTPS 経由の JSON で十分です。
ゲーム セッションごとの同時プレイヤー数
プレイヤーが 2 人だけの三目並べのスポーツマンシップから、100 人のプレイヤーによるバトル ロイヤル ゲームの生き残りの虐殺や、一部の永続世界ゲームの数千人のプレイヤーまで、同じゲーム セッションでの同時プレイヤーの数は、利用するアーキテクチャとサービスに影響を及ぼします。 これらの使用例で考慮された 3 つの範囲は次のとおりです。
- 小 - 10 人以下の同時プレイヤー。
- 中 - 11 から 50 人の同時プレイヤー。
- 大 - 50 人を超える同時プレイヤー。
ベスト プラクティス
キャパシティ プランニングが重要
他のスケーリング サービスと同様に、時間をかけて必要なインスタンス数の計画を立てることが、重要な手順です。 使用するインスタンスが少なすぎると、パフォーマンスが低下します。 使用量が多すぎると、不要なコストが発生します。
早めにテストを行い、時間をかけて計画します。 ゲームをリリースする前に 1 つまたは複数のベータで早期に概念実証を実行し、1 日のうちでプレイヤーが最も頻繁に使用する時間帯と、それをサポートするための容量を把握します。
ソフトウェアがスケーラブルであり、プレイヤーがログインやマッチメイキングからゲーム サーバー自体まで、ゲームを楽しめるようになっていることを確認します。 異なるレベルの同時実行プレイヤー数 (100、1,000、10,000、100,000 など) でテストします。同時プレイヤー数のゼロが増えるたびに、新しいボトルネックが明らかになり、調整が必要になるはずです。
デプロイの方法
Virtual Machine Scale Sets、Service Fabric、または Batch を利用している場合は、1 つのクラスターと、複数の仮想マシン スケール セットを使用し、一度に 1 から 4 ノードずつの少ない単位でスケーリングします。 複数の仮想マシン スケール セットを利用すると、コストは増加しますが、スケールアップが高速化されることに注意してください。
早期のテストで毎日のワークロードを把握したら、その情報を使用して、容量が必要になる 1 時間前に、先行してスケールアップ操作を計画します。
インフラストラクチャを変更しない
Azure Logic Apps を使用し、できる限りインフラストラクチャを変更しないようにします。 実行中のインスタンスのウォーム プールを維持すると、プレイヤーをすぐにゲームに参加させることができますが、コストは増加します。
フェイルセーフ
仮想マシンで障害が発生した場合、ゲーム セッションはどうなりますか。 ゲームの種類と、実装に追加する複雑さの度合いに応じて、いくつかの選択肢があります。
セッションの継続時間が数分の出入りが激しいゲームでは、プレイヤーにそれほど悪い影響はないので、何もせず、プレイヤーをロビーに戻して再び開始することができます。 永続世界ゲームの場合は、仮想マシンの障害の影響はより重大になり、状態を維持したままプレイヤーを新しいサーバーに自動的に移動する、などの操作が必要になることがあります。
モニター サービスを使用して、ノードに障害が発生したかどうかを確認し、アラートを有効にします。 また、環境が失敗した理由を調べるために障害が発生した仮想マシンを維持するか、または単に削除するかも検討します。