Cloud Memorystore for Redis リードレプリカを使用したスケーラブルなマッチメイカーのパフォーマンス

※この投稿は米国時間 2022 年 8 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

近年オンラインゲームの人気が上昇し、マルチプレーヤー ゲームに多数のプレーヤーが流入したことで、需要の高まりへの対応がゲーム業界の既知の課題となっています。Google ではこの課題を解決するため、オープンソースのマルチプレーヤー マッチメイキング フレームワークである Open Match を開発しました。Open Match は、ほとんどのマッチメイキング サービスで使用されるコアサービスを Kubernetes 上でホストして、提供します。これにより、開発者は大規模な運用にかける時間を削減し、マッチロジックに注力できるようになります。

Open Match はプレーヤーの活動に応じてスケーリングするように設計されていますが、すべての読み取りや書き込みはデフォルトではプライマリ Redis ノードで実行されます。そのため容量の限界に近付く可能性があります。すべての読み取りオペレーションをレプリカに移すことでプライマリの負荷を軽減できますが、このアプローチで十分なスケーリングが可能か、また、Open Match から古くなったマッチメイキングの結果が返される可能性がないかという懸念もあります。

今年の初めにリリースされた Cloud Memorystore for Redis リードレプリカにとって、Open Match は大規模な実行テストに最適な環境です。Cloud Memorystore for Redis リードレプリカは読み取りエンドポイントを公開して、読み取りクエリの負荷を複数のゾーンにまたがる最大 5 つまでのレプリカに分散します。これにより、可用性を高め、アプリケーションのダウンタイムを最小化できます。また、Memorystore は M3 以上の構成でマルチスレッド I/O を導入した Redis 6 にも対応しています。このパフォーマンスにより、最大で 100 万人のプレーヤーという大規模でマッチング相手を探す（そして見つける）ことができます。

大規模に実行

Open Match リポジトリで提供されている構成例では、プライマリ ノードで実行されるすべての読み取りと書き込みを 3 つのレプリカで処理する、可用性の高い Redis Sentinel を使用しています。ここでは、構成を迅速に切り替えることで、コードを変更することなく、リードレプリカを使用した Memorystore for Redis のスタンダード インスタンスを代替として使用できることを実証します。Memorystore はさらに多い数のリードレプリカをサポートしていますが、Sentinel の構成例との比較のため、Memorystore でも 3 つのレプリカが使用されています。

Open Match リポジトリにはベンチマークのためのスケールテストが含まれています。リードレプリカの適合性とシステムの耐久性を試すため、1 秒 あたりにシミュレートされたプレーヤー 15,000 人がマッチメイキングをリクエストするというベンチマークを実行します。この数字は、ゲームの人気が急速に高まり、マッチメイキングを利用するプレーヤーが急増した場合を想定しています。以下は、このアプリケーションが安定しておりパフォーマンスも良好であることを確認するために、数日間にわたるテストで収集された指標の例です。

Redis レプリカが最新であることを確認する

Open Match はプレーヤーのマッチメイキング システムでのプロセスを Redis のステータス フィールドで追跡していますが、同期されていない Memorystore レプリカがあると、さまざまな問題が発生する可能性があります。マッチメイキング対象ではなくなったプレーヤーの例には、次のようなものがあります。

• すでにマッチングされたプレーヤー

• マッチング キューから抜けることを選択したプレーヤー

このような問題を避けるため、レプリカには最新の状態を持たせる必要があります。これを追跡するため、プライマリからレプリカへの 1 秒未満のデータ複製レイテンシを確認しました。

このグラフはプライマリ ノードからの 1 秒未満のレイテンシを測定したものです。このわずかなレイテンシでレプリカが最新状態になり、マッチメイキング リクエストが実行され、プレーヤーはゲームを楽しむことができます。

メモリ使用量

プレーヤーがマッチメイキング キューで待機するとき、Open Match はプレーヤーを Redis に保存します。パフォーマンスのボトルネックのためにマッチメイキングが遅くなると、待機するプレーヤーの数が増えていきます。待機中のユーザー数が Redis の使用可能なメモリ容量を超えないようにすることが重要です。

図に示すように、テスト期間中にキーの数は徐々に増え、2,000 に到達しました。そこで数値はとどまり、アプリケーションのオペレーションも安定し、マッチメイキング キューにプレーヤーが入ってくるのとほぼ一定の速さでマッチングが行われています。この指標から、Redis Sentinel 構成をリードレプリカを使用した Cloud Memorystore for Redis 構成に置き換えても、正常に動作し、すべてのプレーヤーが問題なくマッチングされることがわかりました。

まとめ

このテストでは、3 つの Cloud Memorystore for Redis リードレプリカを、Redis Sentinel の代わりに使用し、シミュレートされたプレーヤーが同様のマッチメイキング結果を得られることが示されました。Cloud Memorystore for Redis は追加のリードレプリカをサポートしているため、Open Match のパフォーマンスをさらに向上させることができます。この機能により、オンライン ゲームをスムーズかつ迅速にスケーリングできるため、プレーヤーが急増した場合でもマッチメイキング リクエストを処理できます。

Cloud Memorystore for Redis リードレプリカについて詳しくは、こちらのドキュメントをご覧ください。

Open Match について詳しくは GitHub リポジトリを確認し、ドキュメントでチュートリアルやサンプルをご確認ください。また、Slack チャンネルに参加してデベロッパーや投稿者とやりとりすることもできます。

Open Match やゲーム コンテンツの情報についてさらに詳しく知りたい場合は、Twitter で Jon をフォローしてください。