こちらの記事は、Azure Cosmos DB を使用して現実世界のニーズを満たす方法と Azure Cosmos DB がもたらす効果について解説する 2 部構成シリーズのパート 1 です。パート 1 では、Minecraft Earth サービス開発者が Azure Cosmos DB を選択する要因となった課題、およびこれらの開発者が Azure Cosmos DB を使用して、非常に短い待機時間で、世界中の全プレイヤーのほぼすべてのアクションをキャプチャする方法について考察します。パート 2 では、ソリューションのワークロード、および Minecraft Earth サービス開発者が Azure Cosmos DB をベースにしてこれを構築することでどのようなメリットがあったかについて考察します。

Minecraft の世界を現実世界に拡張

Minecraft というゲームをご自身でプレイしたことはなくても、名前は聞いたことがあるでしょう。Minecraft は史上最多の販売本数を誇るビデオ ゲームで、2011 年以降の累計販売本数は 1 億 7,600 万本を超えています。現在、Minecraft の月間プレイヤー数は 1 億 1,200 万人以上に上ります。プレイヤーは、ゲーム内の自動生成された、イマーシブな 3D の世界 (英語) で、材料を見つけて収集し、道具を制作し、建築物を立てたり、土を掘ったりすることができます。ゲーム モードによっては、コンピューターが操作する敵と戦ったり、他のプレイヤーと協力したり、競い合ったりすることもできます。

マイクロソフトは、2019 年 5 月に Minecraft Earth を近々リリースすると発表し、2019 年 12 月に全世界へロールアウトを開始しました。Minecraft Earth は、これまでリリースされてきた Minecraft フランチャイズのゲームとは異なり、拡張現実 (AR) の機能を利用して Minecraft の世界を現実世界で体験できるようにすることで、さまざまな要素をまったく新しいレベルへと引き上げています。

エクスペリエンスが周りの世界と緊密に統合されていますが、Minecraft Earth のプレイヤーはすぐそれに慣れることができます。一方、マイクロソフトの Minecraft チームの開発者は、Minecraft Earth、特に、このゲームをサポートするのに必要となる信頼性の高いバックエンド サービスを提供するために、まったく新しいものを構築する必要がありました。

Minecraft Earth サービス開発チームのシニア ソフトウェア エンジニアである Nathan Sosnovske は次のように説明しています。

「通常の Minecraft では、独自のサーバーをホストできる一方で、一元化されたサービス機関が存在していませんでした。Minecraft Earth は、一元化された信頼できるサービスを基盤としています。これは、Minecraft フランチャイズ史上初の構築となる "重厚" なサービスです」

このケース スタディでは、Minecraft Earth サービス開発者に求められることを実現する際に直面した課題、および開発者が Azure Cosmos DB を使用してこれらのニーズに応えた方法について見ていきます。

技術的な課題ゲーム内のラグ回避

iOS および Android ベースの AR 対応デバイスで実行される Minecraft Earth クライアント内でプレイヤーがアクションを行うと、ほとんどの場合、中核となる Minecraft Earth サービスへの書き込みが行われます。各書き込みは REST POST であり、ゲーム内の著しいラグを回避するために、即座にそれを受理し、確認する必要があります。

Sosnovske は次のように説明しています。「Minecraft Earth では、サービスの観点から書き込みの待機時間を短くし、読み取りの待機時間を中程度にする必要があります。書き込みを迅速に行う必要があるのは、クライアントがレンダリングする必要があるかなど、クライアント側でそれぞれの確認が必要になるからです。たとえば、プレイヤーがリソースをタップしてその中身を確認する際、対応する REST 要求の処理中にビジュアルをハングさせたくありません。読み取りの待機時間が中程度で許容されるのは、読み取りのためにサービス支援モデルを更新できるようになるまで、クライアント側のシミュレーションを使用できるからです」

Minecraft Earth サービス開発者は、プレイヤーの所在地に関係なく、書き込みの待機時間を短くする必要があり、それが課題を複雑にしていました。これを実現するには、サービスが展開されている最も近い場所に Minecraft Earth クライアントをルーティングする組み込みのインテリジェンスが必要なだけでなく、Minecraft Earth が提供されている各地域内の複数の場所でサービスのコピーを実行する必要がありました。

Sosnovske は次のように述べています。「米国の東海岸と西海岸間の一般的なネットワーク待機時間は 70 ～ 80 ミリ秒です。ニューヨークのプレイヤーがサンフランシスコで稼働しているサービスを利用しなければならない場合、またはその逆の場合でも、ゲーム内のラグは許されません。また、このゲームは Minecraft Earth というタイトルですから、サンフランシスコとニューヨークのプレイヤーがゲーム内で同じエクスペリエンスを共有できるようにしなければなりません。これらをすべて提供するには、各地域内の地理的に分散された複数のデータセンターにサービスとそのデータをレプリケートする必要があります」

解決策: Azure Cosmos DB をベースにしたイベント ソーシング パターン

Minecraft Earth サービス開発者は、技術要件を満たすために、Azure Cosmos DB をベースにしたイベント ソーシング パターンを実装しました。

Sosnovske は次のように述べています。「当初、Azure Table Storage を使用して、追加専用イベント ログを保管することを検討していましたが、読み取りと書き込みの待機時間の SLA が保証されておらず、実現しませんでした。最終的に、私たちは Azure Cosmos DB を選択しました。各地域内の複数の場所にサービスをレプリケートするのに必要となるグローバル分散機能とマルチマスター機能を備えているだけでなく、読み取りと書き込みの両方で 10 ミリ秒の SLA が保証されているからです」

イベント ソーシング パターンにより、Minecraft Earth サービスは、データの現在の状態だけを保管する代わりに、Azure Cosmos DB をベースにした追加専用データ ストアを使用し、データに対して行われた一連のアクションをすべて記録します。今回のケースでは、プレイヤーがゲーム内で行った各アクションにこれが対応しています。書き込みの成功が即座に確認され、クライアントに返された後、追加専用イベント ストアをサブスクライブするキューが後処理を行い、収集されたイベントを Azure Blob Storage で維持管理されているドメインの状態に非同期的に適用します。さらなる最適化を目指して、Minecraft Earth の開発者は、イベント ソーシング パターンとドメイン駆動設計を組み合わせました。ドメイン駆動設計では、在庫アイテム、キャラクター プロファイル、実績などのアプリ ドメインがそれぞれ独自のイベント ストリームを保有します。

Sosnovske は次のように述べています。「私たちは、データをイベント ストリームとしてモデル化しました。これは、追加専用ログに保管され、メモリ内のモデルの状態を変化させ、さまざまなクライアント ビューを駆動する目的で使用されます。このキャッシュされた状態は Azure Blob Storage で維持管理されます。読み取りに十分な速度を備えた Azure Blob Storage を利用して、Azure Cosmos DB の要求ユニット コストを最小限に抑えることが可能です。私たちが Azure Cosmos DB で実行したことは、非常に高い回復性を備えた書き込みキャッシュの構築と多くの点で似ています」

次の図は、Azure Cosmos DB をベースにしたイベント ソーシング パターンの仕組みを示しています。

Azure Cosmos DB の導入

開発者は、Azure Cosmos DB を使用するにあたり、設計に関していくつか意思決定を行う必要がありました。

Azure Cosmos DB API: 開発者は、Azure Cosmos DB Core (SQL) API を使用することにしました。パフォーマンスが最も高く、一番使いやすく、その他の必要な機能を備えていたからです。

Sosnovske は次のように説明しています。「システムを一から構築したため、既存のコードを移行するための互換性レイヤーは不要でした。また、TransactionalBatch (英語) など、私たちが利用している Azure Cosmos DB の一部の機能は、Core (SQL) API でのみサポートされています。さらに、Core (SQL) API には、非常に直感的に使用できるというメリットもありました。私たちのチームがすでに SQL 全般に慣れ親しんでいたからです」

詳細については、.NET SDK への TransactionalBatch の導入 (英語) を参照してください。

パーティション キー: 開発者は、最終的に、ユーザーに基づいて Azure Cosmos DB 内でデータを論理的にパーティション分割することにしました。

Sosnovske は次のように述べています。「当初、ユーザーと、在庫アイテムや実績などのドメインでデータをパーティション分割していましたが、過度に細分化され、Azure Cosmos DB 内でデータベース トランザクションを十分に活用できないことがわかりました」

整合性レベル: 開発者は、Azure Cosmos DB がサポートする 5 つの整合性レベルの中からセッション整合性を選択し、これを厳格な etag チェックと組み合わせることで、データが適切に書き込まれるようにしました。

Sosnovske は次のように説明しています。「これがうまく機能しているのはデータの保管方法のおかげです。このデータは、ログ末尾へのポインターとして機能するヘッド ドキュメントで追加専用ログとしてモデル化されています。データベースへの書き込みは、ヘッド ドキュメントとその etag の読み取り、N+1 ログ ID の導出、すでに読み取られた etag を使用してヘッド ポインターを上書きし、ログ エントリ用の新しいドキュメントを作成するトランザクション バッチ操作の構成を伴います。可能性は低いですが、すでにログが書き込まれている場合、etag チェックを行い、すでに存在するドキュメントを作成しようとすると、トランザクションが失敗します。これは、他の要求が先に書き込みを行ったか、または私たちの要求が少し古いデータを読み取ったかに関係なく起こりました。」

本シリーズのパート 2 では、ソリューションの現行のワークロード、および Minecraft Earth サービス開発者が Azure Cosmos DB をベースにしてこれを構築するメリットについて考察します。

Azure Cosmos DB の使用開始

• Azure Cosmos DB にアクセスしましょう。
• ゲーム用 Azure の詳細については、こちら をご覧ください。