{"id":670,"date":"2020-05-06T00:00:00","date_gmt":"2020-05-06T00:00:00","guid":{"rendered":""},"modified":"2023-05-11T15:26:34","modified_gmt":"2023-05-11T22:26:34","slug":"minecraft-earth-and-azure-cosmos-db-part-2-delivering-turnkey-geographic-distribution","status":"publish","type":"post","link":"https:\/\/azure.microsoft.com\/en-us\/blog\/minecraft-earth-and-azure-cosmos-db-part-2-delivering-turnkey-geographic-distribution\/","title":{"rendered":"Minecraft Earth and Azure Cosmos DB part 2: Delivering turnkey geographic distribution"},"content":{"rendered":"

This post is part 2 of a two-part series about out how organizations are using Azure Cosmos DB to meet real world needs and the difference it\u2019s making to them. In <\/strong>part 1<\/a>, we explored the challenges that led service developers for Minecraft Earth to choose Azure Cosmos DB and how they\u2019re using it to capture almost every action taken by every player around the globe\u2014with ultra-low latency. In part 2 we examine the solution\u2019s workload and how Minecraft Earth service developers have benefited from building it on Azure Cosmos DB.<\/i><\/p>\n

Geographic distribution and multi-region writes<\/h2>\n

Minecraft Earth service developers used the turnkey geographic distribution feature in Azure Cosmos DB to achieve three goals: fault tolerance, disaster recovery, and minimal latency\u2014the latter achieved by also using the multi-master capabilities<\/a> of Azure Cosmos DB to enable multi-region writes. Each supported geography has at least two service instances. For example, in North America, the Minecraft Earth service runs in the West US and East US Azure regions, with other components of Azure used to determine which is closer to the user and route traffic accordingly.<\/p>\n

Nathan Sosnovske, a Senior Software Engineer on the Minecraft Earth services development team explains:<\/p>\n

\u201cWith Azure available in so many global regions, we were able to easily establish a worldwide footprint that ensures a low-latency gaming experience on a global scale. That said, people mostly travel within one geography, which is why we have multi-master writes setup between all of the service instances in each geography. That\u2019s not to say that a player who lives in San Francisco can\u2019t travel to Europe and still play Minecraft Earth\u2014it\u2019s just that we\u2019re using a different mechanism to minimize round-trip latency in such cases.\u201d<\/em><\/p>\n

Request units per second (RU\/s) consumption<\/h2>\n

In Azure Cosmos DB, request units per second (RU\/s) is the \u201ccurrency\u201d used to reserve guaranteed database throughput. For Minecraft Earth, a typical write request consumers about 10 RU\/s, with an additional 2-3 RU\/s used for background processing of the append-only event log, which is driven by Azure Service Bus<\/a>.<\/p>\n

\u201cWe\u2019ve found that our RU\/s usage scales quite linearly; we only need to increase capacity when we have a commensurate increase in write requests per second. At first, we thought we would need more throughput, but it turned out there was a lot of optimization to be done,\u201d says Sosnovske. \u201cOur original design handled request volumes and complexity relatively well, but it didn\u2019t handle the case where the system would shard\u2014that is, physically repartition itself internally\u2014because of overall data volumes.\u201d<\/em><\/p>\n

The reason for this was because allocated RU\/s are equally distributed across physical partitions, and the physical partition with the most current data was running a lot hotter than the rest.<\/p>\n

\u201cFortunately, because our system is modeled as an append only log that gets materialized into views for the client, we very rarely read old data directly from Azure Cosmos DB,\u201d explains Sosnovske. \u201cOur data model was flexible enough to allow us to archive events to cold storage after they were processed them into views, and then delete them from Azure Cosmos DB using its Time to Live feature<\/a>.\u201d<\/em><\/p>\n

Today, with the service\u2019s current architecture, Sosnovske isn\u2019t worried about scalability at all.<\/p>\n

\u201cDuring development, we tested the scalability of Azure Cosmos DB up to one million RU\/s, and it delivered that throughput without a problem,\u201d Sosnovske says.<\/em><\/p>\n

Initial launch of Minecraft Earth<\/h2>\n

Minecraft Earth was formally released in one geography in October 2019, with its global rollout across all other geographies completed over the following weeks. For Minecraft fans, Minecraft Earth provides a means of experiencing the game they know and love at an entirely new level, in the world of augmented reality.<\/p>\n

And for Sosnovske and all the other developers who helped bring Minecraft Earth to life, the opportunity to extend one of the most popular games of all time into the realm of augmented reality has been equally rewarding.<\/p>\n

\u201cA lot of us are gamers ourselves and jumped on the opportunity to be a part of it all,\u201d Sosnovske recalls. \u201cLooking back, everything went pretty well\u2014and we\u2019re all quite satisfied with the results.\u201d <\/em><\/p>\n

Benefits of using Azure Cosmos DB<\/h2>\n

Although Azure Cosmos DB is just one of several Azure services that support Minecraft Earth, it plays a pivotal role.<\/p>\n

\u201cI can\u2019t think of another way we could have delivered what we did without building something incredibly complex completely from scratch,\u201d says Sosnovske. \u201cAzure Cosmos DB provided all the functionality we needed, including low latency, global distribution, multi-master writes, and more. All we had to do was properly put it to use.\u201d <\/em><\/p>\n

Specific benefits of using Azure Cosmos DB to build the Minecraft Earth service included the following:<\/p>\n

Easy adoption and implementation<\/b>. According to Sosnovske, Azure Cosmos DB was easy to adopt.<\/p>\n

\u201cGetting started with Azure Cosmos DB was incredibly easy, especially within the context of the .NET ecosystem,<\/em>\u201d\u00a0 Sosnovske says. \u201cWe simply had to install the Nuget package and point it at the proper endpoint. Documentation for the service is very thorough; we haven\u2019t had any major issues due to misunderstanding how the SDK works.\u201d<\/em><\/p>\n

Zero maintenance<\/strong>. As part of Microsoft Azure, Azure Cosmos DB is a fully managed service, which means that nobody on the Minecraft Earth services team needs to worry about patching servers, maintaining backups, data center failures, and so on.<\/p>\n

\u201cNot having to deal with day-to-day operations is a huge bonus,\u201d says Sosnovske. \u201cHowever, this is really a benefit of building on Azure in general.\u201d<\/em><\/p>\n

Guaranteed low latency.<\/b> A big reason developers chose Azure Cosmos DB was because it provides a guaranteed single-digit (<10ms) latency SLA<\/a> for reads and writes at the 99th percentile, at any scale, anywhere in the world. In comparison, Table storage latency would have been higher\u2014with no guaranteed upper bound.<\/p>\n

\u201cAzure Cosmos DB is delivering as promised, in that we\u2019re seeing an average latency of 7 milliseconds for reads,\u201d says Sosnovske.<\/em><\/p>\n

Elastic scalability. <\/b>Thanks to the elastic scalability provided by Azure Cosmos DB, the game enjoyed a frictionless launch.<\/p>\n

\u201cAt no point was Azure Cosmos DB the bottleneck in scaling our service,\u201d says Sosnovske. \u201cWe\u2019ve done a lot of work to optimize performance since initial release and knowing that we wouldn\u2019t hit any scalability limits as we did that work was a huge benefit. We may have paid a bit more for throughput then we had to at first, but that\u2019s a lot better than having a service that can\u2019t keep up with growth in user demand.\u201d<\/em><\/p>\n

Turnkey geographic distribution.<\/b> With Azure Cosmos DB, geographic distribution was a trivial task for Minecraft Earth service developers. Adjustments to provisioned throughput (in RU\/s) are just as easy because Azure Cosmos DB transparently performs the necessary internal operations across all the regions, continuing to provide a single system image.<\/p>\n

\u201cTurnkey geo-distribution was a huge benefit,\u201d says Sosnovske. \u201cWe did have to think a bit more carefully about how to model our system when turning on multi-master support, but it was orders of magnitude less work than solving the problem ourselves.\u201d <\/em><\/p>\n

Compliance.<\/b> Through their use of Time-to-Live within Azure Cosmos DB, developers can safely store location-based gameplay data for short periods of time without having to worry about violating compliance mandates like Europe\u2019s General Data Protection Regulation (GDPR).<\/p>\n

\u201cIt lets us drive workflows like \u2018This player should only be able to redeem this location once in a given period of time,\u2019 after which Azure Cosmos DB automatically cleans up the data within our set TTL,\u201d explains Sosnovske.<\/em><\/p>\n

In summarizing his experience with Azure Cosmos DB, Sosnovske says it was quite positive.<\/p>\n

\n

\u201cAzure Cosmos DB is highly reliable, easy to use after you take the time to understand the basic concepts, and, best of all, it stays out of the way when you\u2019re writing code. When junior developers on my team are working on features, they don\u2019t need to think about the database or how data is stored; they can simply write code for a domain and have it just work.\u201d<\/em><\/p>\n<\/blockquote>\n

Get started with Azure Cosmos DB<\/h2>\n