Realtime Multiplayer Game — Solution Architecture

High-level Solution Architecture based on Microsoft Azure PaaS

Photo by Anandhu Santhosh on Unsplash

Problem Context

The problem is adapted from the Mountkirk Games case study from the GCP exam. As stated — they require a new game, which is expected to be very popular. They plan to deploy the game’s backend on Azure so that they can capture streaming metrics, run intensive analytics, and take advantage of its autoscaling environment and integrate with a managed NoSQL database.

They have the following business requirements —

Increase to a global footprint, improve uptime — downtime is loss of players, increase the efficiency of the cloud resources and reduce the latency to all customers.

They want to accomplish the following technical capabilities:

Dynamically scale up or down based on game activity, process incoming data on the fly directly from the game servers, process data that arrives late because of slow mobile networks, and process files that are regularly uploaded by users’ mobile devices.

Pankaj Jainani - Cloud Architect

The Solution

Considering the above business objective I have come up with the following solution architecture on Azure:

Solution Architecture: Multiplayer Game on Azure PaaS — click to expand the image

Salient features of the proposed architecture —

Multiplayer servers for real-time games need to be stateful (memory), can’t be explicitly shut down since players might be still enjoying their game and, as a rule of thumb, their connection with the players must be of minimal latency. Adhering to the Well-Architected Cloud Framework: —

1. Azure Traffic Manager — Connects the player to the most appropriate regional zone based on latency. Its purpose is to accomplish global to regional routing
2. The Regional Matchmaker is a Serverless based deployment that implements the following functionalities:- Add player to the queue, delete a player from the queue, give the player a match, add game servers and look for game sessions that can be started, and find a server for each of them.
3. The core of the architecture is the Regional Game Server pools. They are specific to the player’s region and presence. This Game Server is provisioned dynamically on AKS by using Custom Resource Definition (CRDs) objects. These objects will be used to represent the dedicated game server entities, such as — DedicatedGameServer: represents the multiplayer game server itself, this can expand into collections of the same Pod template and can be scaled in/out.
4. Reliability & Availability: Highly available infrastructure deployments in multiple Azure regions for global customers. Enabling global footprints. Also, set up backup and recovery.
5. Cost-optimized & Performance by Serverless or PaaS services for matchmaking, game servers, data stores. Modify SKUs/Tiers as desired for better throughput and performance. Overall elastic, reliable, fault-tolerant
6. Redis Cache, CDN, and regional deployments for Game servers minimize latency and lag.
7. Azure B2C to enable authentication and identity management by third-party providers — Google/Facebook etc.
8. Unified Platform Architecture — Launch various games, onboard players, vendors, third parties.
9. Enable Player analytics, insights, user patterns, recommendation engine — supporting prescriptive and predictive analytics.
10. Synapse Data Analytics — integration with Data Bricks, ADF & BI: Comprehensive suite to handle the entire analytical workload. Massively scalable and parallel execution.
11. Operational Excellence — integrate and implement cloud operations, DevSecOps, Application Performance Metrics, Log Metrics, alerts, notifications. Automatic workflows for quick remediation and self-healing.
12. Azure Security Center — Incorporate security posture at each layer and depth.

Key Risks

Following are the key risks for this architecture: —

• Unavailability of Azure region, it cause customer from unsupported geographies suffer n/w lags
• Strategy to deal the perception of Lag from the user. Try to overcome by architecture choices or system pre-requisites.
• Internationalization — for geographies across the World
• Too much cloud native proposition can lead towards vendor lock-in for specific cloud provider.

Assumptions

• Assuming the solution is required for real-time Multiplayer game. For turn based multiplayer game the architecture choices will be different.
• Architecture to assume number of players per game. The infra requirements will vary accordingly.
• Not considered regulatory and Compliance: Global website, data and residency compliant.

Alternate Tech Options

• Provision Game servers through VM images. Auto scale using Azure Automation and Batch jobs
• SignalR or Azure Web Pub-Sub services integration with Azure Notification can be utilized in case of multiplayer turn-based games.

Pankaj Jainani - Cloud Architect

Conclusion

The high-level architecture view is purely based on Azure platform services, the solutions can be deployed on Google Cloud or AWS leveraging the the similar services. I am presenting the opinion based on information available from the case study.

This may not be the final state of architecture, but, still a representation for the stated requirements. I open to questions, discussions and suggestions. Please feel free to comments.