re:Invent 2024: Riot GamesがLeague of LegendsをAWSで展開、コスト削減を実現
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Effortless game launches: How League of Legends runs at scale on AWS (GAM307)
この動画では、Riot GamesがLeague of LegendsとTeamfight TacticsのゲームサーバーをAWSに移行し、Auto Scalingを活用してインフラコストを削減した事例を紹介しています。15年以上の歴史を持つLeague of LegendsをWindowsからLinuxへ移行し、Game Provisioning Platformを構築する過程で直面した技術的課題と、それらの解決方法が詳しく説明されています。特に、ゲームサーバーの配置アルゴリズムの最適化によって年間1,000万USDものコスト削減を実現し、さらにSwarmやTeamfight Tacticsの新モードなど、異なるパフォーマンスプロファイルを持つゲームモードの柔軟な展開を可能にした点が印象的です。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Riot GamesとAWSのパートナーシップ：本日のトピック紹介
みなさん、こんにちは。私はAWSのSenior Solutions ArchitectのAshwin Raghuramanです。私はBrian Miller、Riotのシニアプリンシパルエンジニアです。そして私はDavid Pressで、同じくシニアプリンシパルエンジニアとしてLeague of LegendsとTeamfight Tacticsを担当しています。 Riot Gamesをご存じない方のために説明しますと、カリフォルニアを拠点とするAAAゲームスタジオで、League of Legends、Valorant、Wild Rift、Teamfight Tactics、Legends of Runeterra、そして近日公開予定の2XKOなどの基本プレイ無料のゲームを提供しています。
ゲーム開発だけでなく、何百ものチームと何千人ものプレイヤーが参加する、世界最大規模のEsportsサーキットも構築しています。 さらに、スポーツ、メディア、エンターテインメント、ファッションの領域を超えてブランドを展開しています。 2022年、Riot GamesとAWSは パートナーシップを結び、多くの成果を上げてきました。Esports史上初のグローバルパワーランキングの構築、AWSを活用した最先端のリモート放送センター、機械学習を活用した初のEsports統計システム、さらにはRiotのすべてのデータセンターのAWSへの移行など、様々な実績を残してきました。これらは過去の成果ですので、詳しくはaws.amazon.com/sports/riotをご覧ください。
本日のトークでは、RiotがAWS EC2 Auto Scalingを活用してゲームのインフラコストを削減した方法についてご紹介します。さらに、Riotのゲームプロビジョニングプラットフォームについて深く掘り下げ、最高のプレイヤー体験を実現する方法について詳しく見ていきます。
League of LegendsとTeamfight Tacticsの概要とアーキテクチャ
League of Legendsは、すでに15年以上の歴史を持つゲームです。プレイヤー対プレイヤーのチームベースのゲームで、4人の仲間とチームを組んでチャンピオンを操作します。 現在約160のチャンピオンがおり、それぞれが独自の能力や相手をかわすことのできるスペルを持っています。 試合の目的は相手チームの本拠地を破壊することで、非常にテンポの速いゲームです。 ゲーム中は様々な展開が繰り広げられます。
また、Teamfight Tacticsというゲームも提供しています。こちらはより戦略的なゲームで、テンポはゆっくりめです。チャンピオンの配置を考える時間があり、その後は自動的に戦闘が進行します。チームプレイではなく、7人の他のプレイヤーと1対1で対戦し、各ラウンドで1人のプレイヤーと戦い、最後まで生き残った人が勝者となります。
League of Legends と Teamfight Tactics の両方を動かすために、私たちは大きく分けて2つのアーキテクチャを持っています。一方はプラットフォームサーバーで、これは標準的なWebサービススタックであり、ゲーム外体験を提供するJavaサービスです。ログイン、ストア、マッチメイキング、プログレッションシステム、バトルパスなどが含まれます。クライアントは通常、REST HTTPを介してこれらのサービスと通信します。もう一方は、ゲーム内体験を提供するゲームサーバーで、スペルを唱えたり、TFTではキャラクターを配置して戦わせたりする部分を担当します。これは非常にレイテンシーに敏感な体験であり、大量のUDPパケットをゲームサーバーや他のプレイヤーにできるだけ早く届ける必要があります。
オンプレミスからクラウドへ：Riot Gamesのインフラ移行の課題
先ほど申し上げたように、League of Legendsは15年以上の歴史があり、クラウド以前から存在していました。プレイヤーの近くに配置する必要のあるこれらのゲームサーバーを動かすために、私たちは世界中に大規模なオンプレミスのメタルデータセンターを構築しなければなりませんでした。北米やヨーロッパだけでなく、南米、東南アジア、トルコといった遠隔地にも設置する必要がありました。これは大きな課題でしたが、世界中に広く展開し、League of Legendsの熱心なファンである従来サービスを受けられなかったプレイヤーたちにサービスを提供できたことは、私たちの競争優位性の一つでもありました。これにより、私たちは真のグローバルなeスポーツになることができました。これらのプレイヤーにサービスを提供するために、
ゲームサーバーには特別なニーズがあります。 低レイテンシーの要件に加えて、ソフトリアルタイムシミュレーションを実行するための計算負荷の高いプロセスでもあります。 私たちは各フレームのシミュレーションを約30フレーム/秒で実行するようにゲームサーバーを維持しようとしており、 そのスピードで実行するためのCPU時間を確保することが非常に重要です。一方で、コスト効率を考えると、1台のサーバーにできるだけ多くのゲームを詰め込む必要もあります。
ゲームサーバーとクライアント間では、小さなUDPパケットを通じて重要な通信が行われています。これらのパケットはできるだけ早くゲームサーバーに到達する必要があり、サーバーはそれを処理してシミュレーションを進め、そのプレイヤーの行動結果を他のプレイヤーに表示することで、彼らが唱えられたスペルを回避する機会を与えます。ゲームサーバーの従来のWebサービスとは異なるもう一つのユニークな点は、各サーバーが個別にアドレス指定可能である必要があることです。ロードバランサーの背後にある一般的なWebサービスでは、どのWebサーバーがリクエストを処理するかは重要ではありません - あるプレイヤーからの1つのリクエストが1台のWebサーバーで処理され、同じプレイヤーからの次のリクエストが別のサーバーで処理されることもあります。しかし、ゲームサーバーの場合は、 そのゲームのシミュレーションは1台のサーバーでホストされているため、プレイヤーはその特定のサーバーにアクセスできる必要があります。 つまり、各ゲームサーバーはクライアントから直接アクセス可能である必要があるかもしれません。
この公開アクセス可能性は、私たちをDDoS攻撃にさらすことになります。悪意のあるプレイヤーがゲームで負けそうになった場合、そのサーバーにトラフィックを向けてゲームサーバーを停止させ、自分の試合記録に影響を与え、そのシーズンのランクを上げようとする可能性があります。 試合終了時には、何が起こったかについての詳細なデータを収集して、下流のプログレッションシステムに送信する必要があります。これは単なる勝敗だけではなく、 その試合で発生したすべてのイベントを含みます。例えば、特定のタイプのチャンピオンを5体倒すといった様々なチャレンジを達成した場合、 そのすべてのデータをゲームサーバーからゲーム外体験に送信する必要があります。
このアーキテクチャは、長期にわたって私たちのゲームサーバーを支えてきました。左側にはクライアント、中央の水平線上にはゲーム開始のパス、右側には数千台存在する可能性のあるEC2インスタンスの1つがあり、それぞれが複数のゲームをホストしています。これらのEC2インスタンス（AWSの前は全てWindowsサーバー）は、クライアントが主にWindowsで動作し、開発者もWindowsに慣れていたため、League of Legendsのゲームサーバーを当初からWindowsで開発していました。ゲームが終了すると、全ての終了時データをEnd-of-gameデータサービスに送信し、その後下流のサービスがそのデータを処理して、一部をクライアントに表示します。クライアントからゲームサーバーへの接続は、ゲームサーバーを保護するDDoS対策アプライアンスを経由します。
このアーキテクチャにはいくつかの課題がありました。まず、オンプレミスでのスケーリングの問題です。ゲームが常に成長を続け、特に初期段階では新機能の追加に伴って新たなキャパシティが必要でした。これに責任を持って対応するため、予測が完璧でない場合に備えて、かなりの余剰キャパシティを購入する必要がありました。これは必要なコストではありましたが、大きな無駄も生んでいました。そこで、Auto Scalingを活用する明確な機会が見えてきました。
私たちは、有名なネットワークベンダーと契約して、FPGAベースのカスタムDDoS対策ソリューションを構築しました。これは良く機能しましたが、いくつかの制限がありました。主な制限の1つは、ホストあたり255ゲームしかサポートできないことでした。これは当初は問題ありませんでしたが、サーバーが強力になり、1台のサーバー内により多くのコアを搭載できるようになると、大きな制約となりました。もう1つの制限は、同時に実行できるゲームのバージョンが2つまでということでした。これは、Teamfight Tacticsをモバイル製品としてリリースした際に問題となりました。モバイルゲームは、アプリストアの承認プロセスの関係で、複数のバージョンを同時に管理する必要があるためです。
Windowsゲームサーバーに関しては、いくつかの課題が浮上しました。ライセンスに関しては、コストだけでなく、ライセンス管理、監査の実施、適切な使用の確認などのオーバーヘッドが発生しました。AWSでWindowsライセンスを使用する場合、自社ライセンスの持ち込みにはEC2 Dedicated Instancesの使用が必要で、これによってプロビジョニングと管理がより複雑になりました。Riotでは、Windowsのシステム管理が失われつつある技術となっていました。より大規模なLinuxサーバー群の管理に向けた研修や投資に注力しており、大規模なWindowsフリートの運用の複雑さに対応するスキルは向上していませんでした。この分野での専門知識を失っていくことは、ますます深刻な問題となっていきました。
2020年に進むと、 私たちはFPSゲームのValorantをリリースしました。このゲームはインフラに対してより厳しい要件を持っていました。League of Legendsよりもさらに低いレイテンシーが求められ、 全プレイヤーに対して35ミリ秒を目標としていました。 そして、League of Legendsで経験した課題から学んだ教訓を活かしました。Valorantは、クラウドファーストのインフラ展開を実現しました。 12のAWS Region、4つのAWS Outpost、そして5つのRiotデータセンターに展開し、必要な場所での存在感を維持しました。 2つの異なるエッジネットワーク（私たちのRiot Directエッジネットワークと、AWS Global Accelerator）を活用して、ゲームサーバーからプレイヤーへのパケットを可能な限り迅速に配信しました。
Valorantのローンチは非常に成功を収めました。ゲームはクラウド上のコンテナ内のLinuxゲームサーバーで動作し、Auto Scalingの利点を活用することができました。League of Legendsから学んだ貴重な教訓を活かし、非常に成功したローンチを実現できたのです。しかし、これによってLeague of Legendsは時代遅れに見えてしまいました。というのも、まだベアメタルで動作しており、それに伴うさまざまな課題を抱えていたからです。Valorantのインフラを見て、League of Legendsに同様の改善を実装するにはどうすればよいか検討しました。分析の結果、ゲームの保守と改善を続けながら大規模な作業が必要になることが分かったため、RiotのPlayer Platformチームに支援を求めることにしました。
Game Provisioning Platform（GPP）の開発と実装
Leagueが私たちに支援を求めてきた状況を理解するために、Player Platformが解決する課題について説明することが重要です。Player Platformは、ゲームが直面する一般的な問題に対処する共通の中央チームです。 私たちは、アカウント、ソーシャル機能、行動システムなど、複数のゲームで使用されるさまざまなサービスを提供しています。また、ゲーム領域自体でのソリューションの探求も始めていました。
元々は、私たちの新作格闘ゲームである2XKOのために開発されるはずでした。彼らは、Valorantのソリューションをベースに、自分たちのゲームや他の複数のゲームで使用できるクラウドベースのゲームプロビジョニングシステムを作ってほしいと依頼してきました。そこで私たちは、これまでに確立したベストプラクティスを緩やかに基にしたデザインを考案していました。
デザインは、スケーラブルでフォールトトレラントである必要がありました。これはすべてのゲームプロビジョニングシステムに求められる要件です。また、世界規模のサポートも必要でした。ValorantのゲームサーバーはLinuxで動作していたため、効果的にスケールできるようにすることも要件の1つでした。他の多くのゲームはUnrealで動作しており、私たちが使用しているUnrealのディストリビューションもLinuxで動作していたからです。
この時点で、GDD後にLeagueが私たちに接近し、2XKOの課題解決ではなく、方向転換してLeague自体のソリューションを提供してほしいと依頼してきました。 そこで私たちはその要望に応えることにしました。 ただし、そのためにはValorantのアーキテクチャを修正する必要がありました。というのも、Valorantのアーキテクチャは非常に効果的に機能していましたが、ゲーム固有の選択がいくつかなされていたからです。確かに、彼らが説明していたUDPトラフィックの汎用パケットウォーターマーキングによるAnti-DDoSソリューションは持っていましたが、私たちが望むほど汎用的ではなく、Leagueのエコシステムに私たちが望むほど効果的に組み込めるものではありませんでした。
ネイティブなパッチャーのサポートが必要でした。これは実際にとても素晴らしい機能です。ゲームサーバーのパッチャー配信モデルをGPP自体に組み込んで、マルチバージョンのサポートを提供しました。これにより、ゲームチームがクライアントアセットをプッシュすると、対応するゲームサーバーも利用可能になり、バージョンの整合性を活用できます。ゲームをプレイしてダウンロードする際、適切なバージョンのゲームサーバーに接続できるようになります。同時に複数のゲームサーバーバージョンをサポートできます。また、ゲーム終了時の処理を組み込んだソリューションを持つことは、特にゲーム結果の理解において重要でした。全プレイヤーがBattle Passを確実に受け取れるようにする必要があったのです。
こちらは、Leagueのものと似ているものの、若干異なるアーキテクチャ図です。主な違いは、4つの中央スケジューリング拠点を設けたことです。ゲームチームのプラットフォームは、ゲームを開始するために4つの拠点のうち1つだけを考慮すれば良く、その中に多くのPodがあり、さらにその中に多くのPodインスタンスがあって、ゲームのライフサイクルを管理するエージェントを実行しています。これにより、ゲームプラットフォームがゲームサーバーインスタンスの起動と管理を行う方法が大幅に簡素化されました。また、ゲームチームはスケジューラーにゲームを送信することだけを考えればよく、新しいPodをターゲットにしたい場合でも、リソースが利用可能であれば、そこでゲームを開始できるため、大規模な拡張が可能になります。
この取り組みは2XKOからの方向転換でしたが、開始するにあたって追加のメンバーを集めました。というのも、Leagueの移行は、新しくローンチするゲームのセットアップよりもはるかに大規模な作業だったからです。Leagueチームからリソースを集め、中央インフラチームから多くのメンバーを招集し、さらにAWSの担当者からのサポートも得ました。Leagueが現在運用されているすべての環境、つまりテスト環境、本番環境、Esports、そしてすべてのパートナー地域にわたって展開することを目指していました。しかし、すべてが順調というわけではなく、その点についてはDavidが説明します。新しいGPPプラットフォームへのLeagueの移行には多くの課題がありました。Brianが言及したように、Valorantは特定の方法で問題を解決しましたが、それはValorantには適していても、すでにローンチされているLeague of Legendsにはすべてが
同じようには適用できませんでした。稼働中のシステムを移行するには多くの作業が必要でした。最初の課題は、データセンターで稼働していたすべてのゲームサーバーをAWSに移行することでした。この取り組みについては、昨年のre:Inventで詳しく説明しました。Global Data Center Decommissionプロジェクトと呼ばれるもので、数年かかりました。2014年頃の状態から、現在では世界中のさらに多くの場所に展開しています。現在はAWS Region、Local Zone、Outpostsを組み合わせて使用しており、実際に先月、最後の本番データセンターであるトルコのイスタンブールをAWS Outpostに移行しました。これですべてのゲームサーバーがAWSとCloudに完全に移行されました。
2番目の課題は、ゲームサーバーをWindowsからLinuxに移行することでした。15年間にわたって特定のプラットフォーム上でコードベースを開発してきた場合、そのプラットフォームに依存した多くの前提があります。特定のOS固有のAPIを使用しているため、それらすべてを移植してコンパイルできるようにする必要がありました。ゲームサーバーはパフォーマンスに非常に敏感なアプリケーションなので、多くのパフォーマンステストを行う必要がありました。少なくともWindowsと同等のパフォーマンスを確保する必要がありました。ローカルとテスト環境でテストを行い、パブリックベータ環境を使用して、1台のホストに可能な限り多くのゲームを詰め込んで、どこで破綻するかを確認しました。実際、WindowsのパフォーマンスにLinuxを合わせるために必要なパフォーマンスチューニングが予想以上に少なくて済んだことには驚きました。
また、プラットフォーム固有のバグにも多く遭遇しました。Windowsでは特定の決定論的な方法で動作するC++の未定義動作に依存していましたが、Linuxで実行すると少し異なる動作をしていました。標準ライブラリのコンテナの一つを使用していた事例があり、これは順序なしコンテナでしたが、Windowsでは私たちのゲームスクリプトが依存していた決定論的な順序がありました。Linuxに移行すると、異なる決定論的な順序になっていました。Linuxに移行した地域のプレイヤーがGangplankをプレイ中に、複数の樽を設置して同時に撃つという特定のアビリティコンボが使えなくなっていることが、サービス開始後に判明しました。一方で、まだ移行していないWindows環境の地域では正常に動作していました。これがコンテナのバグだと特定し、同じ動作をする別のコンテナに切り替えました。結果として、パケットの到着と処理が1フレーム遅れることになり、そのコンボが使えなくなっていたのです。
Auto Scalingの活用：ゲームサーバーの最適化への挑戦
次に深く掘り下げたい最後の課題は、これらのゲームサーバーでAuto Scalingをどのように活用するかということです。一般的なWebサービスでAuto Scalingを設定する際、まず把握する必要があるのは、顧客が問題を感じ始めるCPUのしきい値です。これは、リクエストのレイテンシーが高くなりすぎたり、トランザクション処理に時間がかかりすぎたりする時点です。ゲームサーバーの場合、ゲームサーバーのフレームレートが継続的に30FPSを下回ると、プレイヤーがゲームの反応が悪くなったと感じ始めます。チャンピオンの動きがカクカクして、プレイヤー体験が悪化します。League of LegendsとTeamfight Tacticsでは、経験的にこれがCPU使用率約80%であることが分かりました。これは、そのしきい値を下回っている必要があります。
次に把握する必要があるのは、スケールアップを開始するCPU使用率のしきい値です。Auto Scalerがそのしきい値を超えていることを認識し、新しいインスタンスを起動して他のインスタンスの負荷を軽減するまでに十分な時間を確保する必要があります。このしきい値をどれだけ下げるかを決める要因の一つは、平均値からの分散の大きさです。
ここで示しているように、分散が非常に大きい場合、そのしきい値を下げる必要があります。なぜなら、平均値よりも大きく上振れするホストがあると、超えたくないプレイヤーの痛みのしきい値に近づいてしまうからです。ここに2つのグラフを示しています。一つは分散が大きい場合、もう一つは分散が小さい場合です。分散が小さい場合、プレイヤーの痛みのしきい値に実際に到達することなく、しきい値をより高く設定することができます。
これは実際のコストに直結します。CPUのAuto Scalingのしきい値を40%をベースラインとした場合、これを45%に上げるだけでコストを11%削減でき、60%まで上げれば3分の1のコスト削減が可能です。ゲームサーバーは私たちのインフラ全体で最大のコストを占めているため、そこで3分の1のコストを削減できることは大きな意味を持ちます。このしきい値を可能な限り高く設定できるようにすることは、私たちにとって非常に重要でした。
問題は、League of LegendsとTeamfight Tacticsのパフォーマンスがゲーム中で大きく変動するということでした。 これはVALORANTとは異なります。VALORANTのマッチでは、サーバー上で発生する処理は試合を通してかなり一定しています。VALORANTの最初のラウンドと最後のラウンドで行われることは基本的に同じです。一方、LeagueとTeamfight Tacticsは非常に変動が大きいのです。
こちらのグラフで両方を示しています。左側のグラフはゲーム時間の分布を表しています。League of Legendsの場合、最も一般的な試合時間は24〜26分程度で、Teamfight Tacticsの試合はそれよりもやや長く、さらにLeagueの場合は長時間に及ぶ試合も少なくありません。右側のグラフは、試合中のCPU使用率を示しています。Leagueでは、試合開始時は非常に低く、中盤にかけて上昇し、中盤はある程度一定を保ちますが、試合終盤になると大幅に上昇することがわかります。
ゲームの進行を考えてみると、チャンピオンは最初1つか2つのアビリティしか持っておらず、それらのクールダウンも長めです。ゲームが進むにつれて、より多くのアビリティを獲得し、より頻繁にそれらを使用できるようになります。また、ゲームは終盤に向けて大規模なチームファイトを促す設計になっており、同時に多くの処理が発生します。これがLeagueの試合でこのような挙動につながっているのです。
Teamfight Tacticsは少し異なります。こちらも開始時は処理が少なく、ボード上に配置できるチャンピオンが増えるにつれてCPU使用率は上昇します。しかし、ゲームが進むにつれてプレイヤーが脱落していき、最後は2人だけになるため、終盤に向かって実は下がっていきます。これらはどちらも、試合を通して一定したパフォーマンスを示すVALORANTとは異なる特徴を持っています。
では、1台のホストに注目して見てみましょう。ホストにゲームを追加し始めると、最初は4つのゲームを15%程度のCPU使用率で実行できます。さらにゲームを追加していくと使用率は上昇していきます。80%の閾値に近づくと、そのホストはほぼ満杯となり、これ以上ゲームを追加したくない状態になります。しかし、先ほど説明したように、League of Legendsの試合は時間とともにリソース消費が増えていくため、実際にはそれほど多くのゲームを同時に実行することはできません。結果として、序盤の軽いゲームと終盤の重いゲームが混在する形で、より少ない数のゲームしか実行できないということになります。
このような分布のため、初期のゲームと比べて平均的なゲームを多く配置することができません。そのため、ゲームサーバーのフリートがある中で、新しいゲームをどのサーバーに配置するかを決定するという課題に直面しました。 これは本質的にロードバランシングの問題です。
最初は、最も負荷の低いゲームサーバーを選んで新しいゲームを配置するという、ナイブなロードバランシングのアプローチから始めました。 このシナリオで何が起こるか見てみましょう。同じように負荷がかかっているゲームサーバーのフリートがあり、あるホストの最小CPUが80%のしきい値を下回る70%だとします。新しいゲームがある場合、70%のゲームサーバーにそれを配置することになります。しかし、このフリートに新しいホストを追加すると、最小値は新しいホストの0%になります。 そうすると、そのホストにゲームを配置することになります。
ズームインして何が起こるか見てみましょう。 0%のホストがあり、4つのゲームを追加すると10%になりますが、依然として最も負荷が低い状態です。 さらにゲームを追加し続けます。 このホストを追加する前の最小値だった70%に達するまで続けます。この時点で他のホストも使えるようになり、より均等にバランスが取れます。しかし、それまではすべての新しいゲームをこのホストに配置し続けていました。
問題は、これらがすべて同時期に追加された初期のゲームだということです。 これらのゲームがより負荷の高い状態になるにつれて、プレイヤーの痛みのしきい値に達し、終盤に向かうにつれてそれを超えてしまいます。これは避けたい状況です。これらのゲームはすべて同じ時期に追加されたため、すべて同時に終了します。終了すると、また0%に戻り、同じことが繰り返されます。 これにより、平均値の周りで非常に大きな変動が生じます。 このため、しきい値を80%よりもかなり低く設定しなければなりません。 最も負荷の低いアプローチでは私たちのニーズを満たせないため、より良い配置アルゴリズムが必要です。
そこで、特定の設計制約を持つより良い配置アルゴリズムを見つけるための探求を始めました。すべてのホストを常に80%のしきい値以下に保つことを確実にしたいと考えました。また、異なる動作をする League of Legends と Teamfight Tactics の両方に対応できる柔軟性も必要でした。さらに、地域によってパフォーマンスの変動が異なるため、異なる地域でも機能する必要がありました。例えば、韓国のプレイヤーはアメリカのプレイヤーとは異なるチャンピオンの使い方をしているかもしれません。韓国に最適なアルゴリズムとEUに最適なアルゴリズムを別々に選ぶことは避けたかったのです。もちろん、CPU Auto Scalingのターゲットを上げられるようにするため、コスト最適であることも求められました。
GPPの成果と今後の展望：コスト削減からゲーム開発の革新へ
オンラインで様々なアプローチを試してみて、何が効果的かを確認するだけではなく、私たちはシミュレーションを構築しました。24時間の間にホスト上で開始されたすべてのゲームについて、実際の本番環境のシャードからデータを収集しました。各ゲームの進行に伴うCPU使用率を分析し、異なる配置アルゴリズムでそれらのゲームを再現できるシミュレーションを構築しました。最も負荷の低いアルゴリズムでシミュレーションを実行したところ、 このような結果が得られました - CPU使用率が0%から100%まで大きく変動する非常に高い分散を示し、これは最小負荷配置に関する私たちの理論的アプローチを裏付けるものでした。
私たちは、様々な負荷分散アプローチを含む多くの異なるアルゴリズムを考案しました。Round Robin、Round Robinのバリエーション、ランダムなサーバーの選択、2つのランダムなサーバーから最もCPUの低いものを選ぶ方式など、様々な手法を検討しました。
これらのアルゴリズムをシミュレーションで実行し、データに対する性能と、 各ホストのCPUを80%のしきい値以下に維持できる効果について、広範な結果を収集しました。League of LegendsとTeamfight Tactics の両方に対して効果的なアルゴリズムのショートリストを作成しました。 これら2つのゲームは異なる動作パターンを持っているため、異なるリストが得られました。設計目標の1つに立ち返り、私たちは両方のゲームに適用できる1つのアルゴリズムを選択したいと考えていました。このリストを検討した結果、Round Robinが両方のゲームでうまく機能し、実装も非常にシンプルだったため、このアプローチを選択しました。
本番環境のシャードの1つ、 EUシャードを見てみると、最初に導入したランダムアルゴリズムからの移行の様子がわかります。平均値の周りで非常に大きな変動が見られます。Round Robinを実装した後は、同じ50%の平均値の周りでより小さな変動に収まりました。これにより、避けたい80%のしきい値に達することなく、平均しきい値を徐々に引き上げることができました。このグラフは、 約2ヶ月かけてしきい値を引き上げていった様子を示しています。これらの段階的な引き上げが、先ほどのスライドで示したコスト削減につながりました。
私たちはLeague of LegendsをオンプレミスのインフラストラクチャからAWSとGPPに移行し、Auto Scaling機能を追加しました。このグラフは、 移行の前、最中、そして後のコストを示しています。移行前のコストは安定していましたが、両方のシステムを同時に運用していた移行期間中にスパイクが発生しました。移行完了後、以前の半分近いコストで運用できる状態を実現しました。最終的に、Auto Scalingの活用としきい値の段階的な引き上げにより、年間で最大1,000万USDのコスト削減を達成しました。これは、Riot Gamesにおける単一のコスト削減施策としては最大規模のものとなりました。
これはプレイヤーにとって何を意味するのでしょうか？ 私たちはただコストを削減しようとしているわけではありません - プレイヤーにとって正しいことをしたいと考えているのです。このプロジェクトは、単なるコスト削減が目的ではありませんでした。 Auto ScalingとGPPを使用することで得られた大きな利点の1つは、異なるパフォーマンスプロファイルに対応できることでした。この夏、League of LegendsではSwarmという新しいゲームモードをリリースしました。これはPvEモードで、4人のプレイヤーが協力して、徐々に強くなっていくモンスターの大群と戦うものです。Swarmは通常のLeagueとは非常に異なるパフォーマンスプロファイルを持っており、ゲームあたりのプレイヤー数が少なく、最大4人、通常は1～2人でした。プレイヤー数が少ないため各ゲームのコストは通常のLeague of Legendsよりも若干低かったものの、Swarmをサポートするにはより多くのキャパシティが必要でした。
これは、プレイヤーに特別な体験を提供するための期間限定モードでした。Auto Scalingを使用することで、このモードのために素早くスケールアップし、その後スケールダウンすることができました。Auto Scalingが対応してくれるため、事前に必要なキャパシティを慎重に計算する必要もありませんでした。物理インフラを使用していた時には、このような体験は不可能でした - 2ヶ月のイベントのためだけにサーバーフリートを3倍に増やすことなど考えられませんでした。
これらは、インフラの柔軟性が高まったことで実現できるようになった体験の一例です。Swarmに続いて、新しいTeamfight Tacticsのゲームモードも導入しましたが、これも独自のパフォーマンスプロファイルを持っていました。実際、こちらはCPUよりもメモリの使用が多かったため、CクラスインスタンスからMクラスインスタンスに切り替えました。物理サーバーを使用していた場合、単純にメモリを増設するというわけにはいきませんでした。今回は、インスタンスタイプを切り替えてGOを押すだけで済み、これらの異なるパフォーマンスプロファイルをサポートできることで、より多くの実験の余地が生まれました。
現在、私たちは素晴らしいクラウドベースのGame Provisioning Platformを持っており、各ゲームで利用できるようになっています。これはRiotの他のプロジェクトにとって何を意味するのでしょうか？R&Dゲームの開発チームとの間で、素晴らしい議論が始まっています。以前は、サーバーの設置場所やフットプリントの計算など、インフラに関する議論が多くを占めていました。今では、レイテンシーのSLAやゲームを提供したいターゲット市場についての議論に焦点が移り、ゲーム開発チームは本当に重要な領域に集中できるようになっています。これはもはやコモディティであるべきです - プレイヤーがいる場所にゲームサーバーを配置し、最高の体験のために彼らのニーズを満たすことに注力すべきなのです。
また、レイテンシーベースのマッチメイキングに関しても、とても興味深い可能性が開けています。私たちにはマッチメイキングソリューションがあり、GPPにはPing実装が組み込まれています。これはValorantでも使用されている機能です。同様のPing値を持つプレイヤーを地理的に最適なゲームサーバーロケーションに配置することで、プレイヤー体験を維持または向上させることができます。Davidが話してきた素晴らしい内容を聞いて、具体的な結論は何なのかと思われているかもしれません。Game Provisioningは複雑な問題です。Valorantでさえ、この特定の問題に対するソリューションではなく、実現可能な問題から始めました。
League のエコシステム全体を移行し、既存の知見を活かして最適なソリューションを作ろうとした際、私たちの基本的な想定が間違っていることに気づきました。価値のあるものを移行すれば、その価値は維持されるはずだという先入観があります。これは、再評価すべきものに投資し続けてしまうサンクコストの誤謬です。異なるエコシステムに移行する際は、期待値を見直し、その期待値が適切に満たされているかを実験・評価する方法を作るべきです。単に「Metal で動いたのだから AWS でも動くはず」と考えるのではありません。
私たちには素晴らしい Game Platform があるのですが、これをどうするかという問題があります。これは Valorant から派生したものですが、まだ Valorant チームにこのプラットフォームを使ってもらうには至っていません。現状では、彼らが持っているものも、私たちが持っているものも、どちらもしっかりと機能している状況だと思います。
彼らにとって移行する価値が見いだせないのです。そこで、Valorant チームが移行したいと思えるような魅力的な機能を Game Provisioning Platform に追加することに取り組んでいます。今年の社内ハッカソンである Riot Thunderdome は非常に興味深いものでした。ゲーム会社で働く醍醐味の一つですが、約30のゲームプロトタイプが作られました。
そのプロトタイプの半分が、マルチゲーム機能のために Game Provisioning Platform を使用していました。これは最初から使える状態で、Unreal の提供にも組み込まれており、インフラも用意されていました。多くのゲームが開発の一環としてマッチメイキングやゲームプレイを実装しており、これは非常に強力でした。Thunderdome からもう一つ素晴らしい成果が生まれました。Game Provisioning Platform チームの意欲的なエンジニアの一人が、League を Graviton で動かせるかどうか試してみたいと考え、数人のチームを集めました。彼らは実際に低コストでゲームポッドをセットアップし、実現可能性を確認することができました。これは素晴らしい成果でした。
先ほど申し上げたように、MMO を含むすべての R&D タイトルが現在 Game Provisioning Platform 上で動作しています。MMO には、マッチベースではない、よりエバーグリーンなゲームサーバーモデルをサポートする上で、解決しなければならない興味深い課題がたくさんあります。やるべきことがたくさんありますが、以上で発表を終わります。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion