Migrating Minecraft Realms from AWS to Azure
Microsoft recently announced plans to completely migrate Minecraft from AWS to Azure. As part of this journey, we wanted to share a story of the successful migration of Minecraft Realms – Minecraft's private multiplayer server hosting service.
The migration of Minecraft Realms from one cloud platform to another was a massive undertaking that the team would not have considered pursuing if not for Azure's robust toolset. Thanks to Azure, we completed the migration with minimal disruption to the Minecraft Realms user base; in fact, the process was completely invisible to most players. Now that the Realms migration is complete, our deployments on Azure are significantly simpler with more efficient resource utilization and more flexibility in our architecture.
Moving critical workloads for one of the world's most beloved games with millions of monthly active players can seem daunting, and even risky. This case study aims to make the idea of migration less intimidating and more predictable for organizations of any size.
In the coming months, we will release a series of blogs that will dive into the work that went into migrating Minecraft Realms to Azure. The Realms stack included tens of thousands of cloud-hosted multiplayer game servers, compute fabric running service code, subscription databases and game world state data storage containers, all initially hosted on AWS. In this first blog of the series, we provide a high-level walkthrough of the planning, and the execution of the migration of Realms to Azure.
Planning the migration
Minecraft offers both single player and multiplayer modes of gameplay. Minecraft Realms enables players to create personal multiplayer servers, providing a private online multiplayer gaming experience.
Orginally, Realms was completely hosted on AWS; this included the cloud-hosted multiplayer game servers, world state data storage, subscription and metadata databases, and the service code's compute fabric. This migration was ultimately motivated by (1) cost efficiency, (2) better interoperability with the Microsoft ecosystem, and finally, (3) Improved gameplay through lower latency experiences that leverage Azure's global footprint.
The entire migration was planned and executed in two phases. Phase-1, cloud-hosted multiplayer servers' migration, and Phase-2, lift-and-shift workloads migration. The isolation of various pieces helped spread the cost and reduce the overall risk. The migration breakdown is summarized in Table 1.
Table 1: Migration Breakdown
Executing the migration
The service architecture pre-migration is illustrated in Figure 1. Phase-1 targetted the migration of the multiplayer game servers from AWS to Azure, while Phase-2 moved the remaining workloads to Azure.
Figure 1: Pre-Migration Architecture
Phase-1: Migrating cloud-hosted Multiplayer Servers
Minecraft Realms hosts tens of thousands of multiplayer servers in the cloud. These servers are dynamically allocated as users connect to their Realm. Each Realm runs on a single virtual server at a given point in time, and those servers are allocated and reclaimed as demand waxes and wanes.
During Phase 1, Realms migrated from the Minecraft-managed AWS EC2 virtual servers to Azure PlayFab's managed multiplayer hosting services. Azure PlayFab offers everything needed to build and operate a live game at scale. Specifically, it is tailor-made to provide global low-latency multiplayer hosting services, Remote content management – for game asset updates, Virtual payment management, LiveOps – to run a game as a services, and real-time analytics on game performance.
Prior to migrating to PlayFab Multiplayer Servers, the Realms service contained a significant amount of logic for allocating, deallocating and managing those virtual servers using AWS EC2. After the migration to PlayFab Multiplayer Servers the Realms team was able to shift focus away from managing virtual machines and are now able to spend more time enhancing the customer experience for its product offering.
The Achitecture Post Phase-1 Migration is shown in Figure-2.
Figure 2: Post-Phase-1 Migration Architecture viz. after migration of the Multiplayer Game Servers
Phase-2: Migrating lift-and-shift workloads
The lift-and-shift workload migration comprised three major components viz. Database, Storage and Compute Migration. Breaking up the migration into such components allowed effective parallelization, enabling completion in less than 5 months.
Database Migration: Pre-Migration, disparate MySQL databases on AWS were used to catalog user world metadata. The minecraft team leveraged the Azure Database Migration Service (DMS) to replicate data from Amazon RDS MySQL instances to Azure Database for MySQL .
Storage Migration: The Minecraft team aimed to lift-and-shift the user world data from AWS S3 buckets to Azure Blob Storage. Leveraging AzCopy, they were able to bulk copy data from the source AWS S3 to Azure Storage using simple scripts.
Compute Migration: Minecraft's service code used to run entirely on AWS EC2 instances. To initiate the migration, a customized linux VM image was created by modifying a standard library linux image with necessary dependencies. The custom image was subsequently loaded to Azure Virtual Machine Scale Sets (VMSS). Finally, the Realms service code was deployed to the VMSS instances at startup time.
The architecture at the end of the entire migration is shown in Figure-3.
Figure 3: After Complete Migration
- Always have a rollback plan, preferably that prevents data loss!
- A blue/green deployment strategy was used to validate the compute migration and is highly recommended.
- The Azure Fast Track Team can help you with its team of Azure experts on migration related troubleshooting and deployment.
While migration of large-scale business-critical systems can seem overwhelming, having a clear idea of the end-goal, a solid migration plan and breakdown of the relevant components can simplify the process. The Realms migration achieved core tactical improvements for the business including better cost efficiency and service maintainability – using PlayFab instead of self-managing multiplayer server state reduced cost and developer time, and improved gameplay – by leveraging Azure's global footprint.
Stay tuned for deep dives into specific components of the migration discussed above viz. Realms Database Migration, World Data Storage Migration, and Compute Fabric Migration. We hope that the Minecraft Realms migration blog series eases your organization's move to Azure.
Learn more about how the migration in parts 2 and 3 of this blog series: