2. Objectives
• To understand the requirements of backend architectures in general
• To learn how to build cloud-based backend architectures
2 / 57
3. Games Are Online
• almost every single game has got an online component
▪ cloud savegames
▪ achievements
▪ friends lists
▪ presence (“… is now playing …”)
▪ online multiplayer gameplay
▪ matchmaking
7. Traditional Load Balancing
• estimating the maximum amount of load each backend machine can
take
▪ e.g. 100 players being logged in simultaneously
• setup a number of machines that matches the estimated number of
total players of the game
• add a world selection or implement automatic load balancing
9. Inefficient Resource Management
• Need to always provide enough computing power for maximum
amount of possible players
▪ If there is a peak in players wanting to play, there might not be
enough capacity to handle all requests.
▪ If there is a low in players wanting to play, we're wasting
capacity.
11. Cloud
The cloud provides the combined computation and storage resources
of an undetermined number of machines to other devices at arbitrary
locations on demand.
12.
13.
14. Cloud
• 120+ Azure Products as of July 2017
▪ Computing (e.g. virtual machines)
▪ Networking (e.g. load balancers)
▪ Storage (e.g. file storage)
▪ Containers (e.g. service fabric)
▪ Databases (e.g. SQL)
▪ Data (e.g. machine learning)
▪ AI (e.g. cognitive services)
▪ … and more!
15. Cloud
• 120+ Azure Products as of July 2017
▪ Computing (e.g. virtual machines)
▪ Networking (e.g. load balancers)
▪ Storage (e.g. file storage)
▪ Containers (e.g. service fabric)
▪ Databases (e.g. SQL)
▪ Data (e.g. machine learning)
▪ AI (e.g. cognitive services)
▪ … and more!
16. Scalable Gaming Backend Architecture
Game Client
Unreal / Unity
Web Service
ASP.NET
Lobby
Azure Service
Fabric Actor
Database
Azure CosmosDB
Game
Azure Service
Fabric Actor
17. Web Service
• acts as interface between the frontend and the actual backend
services
▪ protects backend services from direct interaction
• just relays requests, no complicated logic
▪ stateless
▪ scaled indefinitely (scale out)
18. Actors
• universal primitives of concurrent computation
• concurrently handle passed messages
▪ make local decisions
▪ send messages to other actors
▪ create new actors
19. Virtual Actors – Project Orleans
• improve over previous actor platforms such as Erlang or Akka
• straightforward approach to building distributed
interactive applications
• avoids programming patterns for
▪ concurrency
▪ fault tolerance
▪ (distributed) resource management
• scale-up automatically
• heavily used first by 343 Industries (Halo 4)
20. Virtual Actors
• Perpetual existence
▪ always exist
▪ cannot be explicitly created or destroyed
• Automatic instantiation
▪ if there is no in-memory instance of an actor, a message sent to the
actor causes a new instance to be created on an available server
(activation)
▪ an unused actor instance is automatically reclaimed as part of
runtime resource management
▪ actors never fail: if a server S crashes, the next message sent to an
actor A that was running on S causes Orleans to automatically
reinstantiate A on another server
21. Virtual Actors
• Location transparency
▪ actor may be instantiated in different locations at different times,
and sometimes might not have a physical location at all
▪ location of actor instances are transparent to application code
▪ similar concept to virtual memory
• Automatic scale out
▪ create multiple instances of the same stateless actor
▪ seamless scale-out of hot actors
22. Promises
• actors interact by sending asynchronous messages
▪ exposed as method calls
▪ need to return immediately
• return a promise for a future result, rather than blocking until the
actual result is returned
• three-state lifecycle
▪ unresolved: expectation of receiving a result at some future time
▪ fulfilled: result received
▪ broken: error occurred in calculation or in communication
23. The more, the merrier?
• allow us to scale parts of our backend up (and down)
▪ many players trading? create more actors for handling
transactions
▪ many players fighting? create more actors for calculating
collisions and hit chances
• with more different types of actors, we might be required to pass
more messages around to get the actual job done
26. References
• Nick Prühs. Building a Scalable Online Game with Azure.
http://www.gamasutra.com/blogs/NickPruehs/20170214/291318/Buil
ding_a_Scalable_Online_Game_with_Azure__Part_1.php, February
2017.
• Bernstein, Bykov, Geller, Kliot, Thelin. Orleans: Distributed Virtual
Actors for Programmability and Scalability. Microsoft Research,
2010.
• Wikipedia. Actor model. https://en.wikipedia.org/wiki/Actor_model,
June 2017.
28. 5 Minute Review Session
• Name a few typical tasks of frontends and backends in games!
• What is load balancing?
• Name a few types of services that can benefit from the cloud!
• In your own words, describe a simple scalable backend architecture!
• What are promises?
• What are the four primary properties of virtual actors?