VALORANTがいかにしてリリース以降最高のサーバー環境を実現したか

Aaron Cheney

2023/3/9

リリースのはるか前から、ティックレート128Hzの専用ゲームサーバーでVALORANTを提供することは最優先事項でした。私たちの目標は常に、ティックレート128Hzのサーバーで世界レベルのコンペティティブ体験をすべての人に届けることにありました。リリース前にこの目標を達成した経緯については、こちらの記事"VALORANT’s 128-Tick Servers"（英語）をお読みください。

サーバーパフォーマンスの維持は、終わりのない戦いです。ゲームの機能を更新し続けるということは、128ティックのサーバーを提供し続けるためのパフォーマンス基準を満たしているか、常に気を配る必要があるということです。時間とともに軽微な劣化が蓄積し、時折即座にメンテナンスを必要とするような大きな不具合が発生することがあります。

2022年8月、リリース以来最大のパフォーマンス低下が発生しました。この問題で、標準的な10人対戦よりも参加人数が多い試合（カスタムマッチやeスポーツの試合など）が影響を受けました。問題の解消にはエンジニア、プロデューサー、リーダーシップ、そして昨年最大級の大会が行われる直前のイスタンブールにいたeスポーツチームからなる大規模チームが動員されました。

劣化の修正に対応するのと並行して行われた調査では、サーバーのフレームレートを大幅に改良できる部分がいくつか発見され、そのことが後にパフォーマンスの大きな改善につながりました。パッチ5.07以降は、VALORANTが2020年6月にサービスを開始して以来、最も安定してティックレート128Hzのサーバーを楽しんでいただけています。

VALORANTのパフォーマンスチームでエンジニアをしているAaron Cheneyです。この記事の概要は以下の通りです。

パフォーマンスチームが劣化を検出するプロセスについて
Champions 2022の直前に発覚した大きなパフォーマンスの劣化について
トリアージプロセスの評価、緊急事態へのチームの対応、インシデントから得た学び

まずは、パフォーマンスの劣化をどうキャッチするかについて解説し、劣化の深刻度を理解するための背景について説明しましょう。

パフォーマンスの劣化はどう検出するのか

パフォーマンスの劣化は、ゲーム開発において目を逸らすことのできない現実です。ゲームとは巨大で複雑なシステムです。可動パーツが多数あり、それぞれが全体のパフォーマンスに影響を及ぼします。この複雑さは、機能やシステムが追加されてゆくに連れて拡大されます。なので劣化が実際に起きた場合、それを正確に検出して根源的な原因を突き止めることが重要となるのです。

VALORANTにはそのための専属チーム「パフォーマンスチーム」があります。このチームの業務は、多様なハードウェアにまたがるクライアントとサーバー両方のパフォーマンスを監視、維持して改良することです。私たちは様々なツールやプロセスを駆使して、劣化を早い内に検出し、プレイヤーの皆さんに影響を与える前に修正していくのです。

サーバーパフォーマンスのターゲット

ティックレート128Hzのサーバーを維持するということは、各サーバーフレームが7.8125ミリ秒（ms）未満で完了しなければならないということを意味します。ですが、それを実現しようとすると、1つのゲームでCPUコアを丸ごと占めてしまうことになります。128ティックという厳密な要件とオペレーションターゲットをクリアするため、VALORANTのサーバーは3フレームを約7.8msに収めるように最適化されています。すなわち、各サーバーフレームは平均して2.6msより短い必要があるということで、実際にVALORANTのサーバーフレームレートのパフォーマンスターゲットは2.34msになっています。このパフォーマンスターゲットは、2つの重要な目的を達成しています。

必要な余裕を持たせること。パフォーマンスターゲットに余裕を持たせることで、長めのフレームも吸収して128ティック以下を実現できます。これにより、サーバーに不測の事態に耐える余力が生まれ、OSやスケジュール、またその他のサーバー上のソフトウェアが稼働する余裕ができます。
VALORANTの経済的維持。サーバーインフラストラクチャーには高額な費用がかかります。VALORANTが試合ごとにそれぞれ独立したハードウェアで実行できればよいのですが、それは維持可能なビジネスモデルではありません。

AskVal_Feb22_Champions_Article_Graph_3_JA_(1).jpg

現在を計測し、未来を予想する

パフォーマンスチームが劣化を測定するための主なデータは2つあります。

プレリリースデータ – 内部プレイテストや自動テスト、PBEなど複数のソースから生成されるデータ
ライブデータ – 世界中で実際にゲームをプレイしているプレイヤーから収集されるデータ

プレリリースデータでは、リリース前のコンテンツや機能を分析することで将来を予測します。このデータはライブデータよりもはるかにデータ量が少なく、ノイズやばらつきのために結論を導くことが難しい場合もあります。少ないサンプルではトレンドは見えてこないということです。稀にしか起きないケースは、テストされないこともあります。もちろんテストはしたいのですが、すべてを網羅してテストすることは不可能です。

一方、ライブデータではプレイヤーがゲーム内で何を見ているかを観測することにより、現在のプレイヤー体験を理解することができます。こちらのデータセットは内部データよりもはるかに大きく（何十億もの記録が作成されているので）、処理が難しいという側面もあります。このデータは統合することで、情報として活かせるようになります。

一般的に、プレリリースデータは私たちがリリース前のコンテンツを扱う上で予防的な行動を促し、ライブデータは実際の状況に反応する行動を促します。両方のデータを一緒に使うことで、ほとんどの問題を捕捉することが可能になるのです。

VALORANTの典型的なゲームモード

VALORANTプレイヤーの大部分は、アンレートやコンペティティブのキューを通して試合に参加しています。どちらのキューも10人用の同じゲームモードですが、目的はそれぞれ異なります。レプリケーション、スパイクラッシュ、デスマッチなど、VALORANTには他にも様々なプレイ方法がありますが、私たちはスパイクモード（基本的なスパイク設置モード）が最も良い体験となるよう、ここに特に多くのリソースを投入しています。

VALORANTの試合はほとんどが10人でプレイするようにできていますが、一部には10人を超える参加者が必要な特別（かつ重要）な状況があります。

VALORANTの非典型的な試合

eスポーツの配信では、最大22のクライアントがスパイクモードに接続します。これは試合の視聴も目的としたカスタムマッチで、通常、これらの試合における内訳は次のようになっています。

10スロット - プレイヤー（各チームに5）
2スロット - コーチ（各チームに1）
10スロット - 配信チームがコントロールするオブザーバー（観戦者）これらのスロットによって、自宅やアリーナで応援しているファンの視聴体験がサポートされています！

このような22のクライアントが接続する試合は、VALORANTの典型的な試合とは大きく異なります。試合に接続するクライアントは、それぞれが試合の様子を画面に映し出すために必要な情報をサーバーから受け取るために、サーバーからチェックされる必要があります。これは、通常のライブ環境では問題となる可能性があります。しかし、eスポーツの試合では専用のローカルハードウェアを用意して、選手のためにゲームプレイの公平さを確保しています。

VALORANTの非典型的な試合におけるパフォーマンスターゲット

先述のサーバーパフォーマンスのターゲットのことを覚えていますか？サーバーフレームごとに2.34msというターゲットは、10人用のVALORANTの典型的な試合のために設定された基準です。10人以上のプレイヤーが接続する状況では、パフォーマンスは追加プレイヤーの人数に比例して変化すると私たちは予想しています。

例えば、22クライアントでは平均フレームレートは2.34msから約2.2倍の5.2msに上がります。これでも128ティックを維持するのに必要な7.8msは大幅に下回っています。

非典型的な試合における私たちの経験と、VALORANTのサーバーパフォーマンスに対する確固たる理解に基づくと、典型的な試合のパフォーマンスデータからの推定を用いて非典型的な試合を理解することは、有効な手法でした。

でも何かが変わってしまった場合は？もしサーバーパフォーマンスの変化が接続クライアントの数に比例しなくなったら、どうなるのでしょう？

劣化

ここで時を2022年8月に戻します。最初のトラブルの兆しは、22クライアントでのプレイテスト中に現れました。プレイテストに参加していたプレイヤーが、ティックレートの変動を察し、ゲームプレイ全般に違和感を感じ始めたのです。試合の録画により、なにかがおかしいと確定しました。この問題を早期に捕捉することができたのは、かなり幸運でした。この当時、22クライアントでのプレイテストはまだ標準的な運用ではなかったからです。Champions 2022の準備のためにチームが飛び回っている最中、とある頼りになるVALORANT開発者の1人が、テストベンダーに22クライアントでのプレイテストを要請することを忘れずにいてくれました。

そして、このときはまだ警告を発すべきタイミングではなかったものの、私たちは直ちに問題の検証に取り組み、トリアージを行って修正に向けて動き出しました。

問題の検証

単一のデータポイントはトレンドを示すものではありません。私たちはライブ環境からテレメトリを処理することで不具合の深刻度と影響度合いの把握に努めることとし、試合を10～22のクライアント数別に分類して分析しました。すると、驚くべき事実が発覚しました。

はっきりとした問題の原因は特定できなかったものの、グラフでは接続されるクライアントの数とサーバーパフォーマンスに驚くべき関係が見られました。問題の悪化は、プレイヤーの人数とは比例していなかったのです。

このデータにより、大きな問題が発生していると確定しました。しかも、パッチ5.04が使用されるChampions 2022が目前に迫っているという最悪のタイミングです。私たちは警告を発し、直ちに問題のトリアージに進みました。

（パッチごとのサーバーフレームレートを示すチャートです。線はそれぞれ標準的な10人の試合から最大の22クライアントの試合まで、クライアントの数別のデータを表しています。予想通り、接続しているクライアントが多いほど、パフォーマンスは悪化していますが、パッチ5.03での急な悪化は、劣化が数に比例していないことを示しています。）

劣化のトリアージ

問題のトリアージとは、一般的には根本的な原因を完全に理解しないままに問題の影響を軽減することを意味します。この手法は、医療では状況を評価して容態の悪化を防ぐために使用されるものですが、ライアットでは緊急事態に即応するために使用しています。

問題のトリアージのため、2つの対応が同時進行的に行われました。

非常事態計画の策定

まず、VALORANTチームのリーダーシップはイスタンブールにいるパートナーと共に、非常事態計画の策定に取り組みました。これはChampions 2022の開幕までに問題を修正できなかった場合にどうするかを定めるものです。

問題は接続するクライアントの数に比例して発生することは分かっていたため、最低何人のオブザーバーがいればeスポーツの視聴体験を損なわずに提供できるかということを重点的に検討しました。22台のクライアントの運用はすでに検討対象外でした。では、理論的に何台のクライアントならこの状況でも大会を実行できるのでしょう？eスポーツパートナーと協力して検討した結果、接続するクライアントが15台なら安定してティックレート128Hzを実現しながら、オブザーバースロットが5でも配信の質を損なうことはないとの結論が出ました。これは、元々標準のサーバーフレームレートに余裕が組み込まれていたから可能になったことです。

根本的原因の特定

VALORANTの開発チームは、問題をより明確に理解して劣化の主要因を特定するために調査を続けていました。これほどの規模の問題が発生する場合、原因が複数のシステムに跨がっている可能性は低いと思われました。

運良く根本的原因を速やかに特定して、Champions 2022の開幕までに問題を修正できるのではないかと期待していましたが…残念ながらそうはなりませんでした。

劣化の修正

劣化が初めて特定されたのは2022年8月25日で、問題が解消されたのはその1週間後でした。この7日の間に、大勢のエンジニアが対応に呼ばれ、複数の解決法を探ることになりました。

調査初日、劣化の原因となっていたコードベースの部分が特定されました。レプリケーションです（いえ、ゲームモードのことではありません）。レプリケーションとは、Unreal Engineがサーバーとクライアントの間の一貫性を確保するために、アクタとコンポーネントのプロパティを同期する処理のことです。Unreal Engineのレプリケーションに関する詳細についてはこちらをご覧ください。

当初は、パッチ5.02から5.03の間の変更を分析して、レプリケーションでなにかが変わったという証拠を発見することを優先していました。ところが、Unreal Engine 4.26にアップグレードした直後だったため、エンジンのコアとなる部分が一部更新されており、これは困難となりました。VALORANTでのUnreal Engineのアップグレードについては、VALORANTの技術リードであるMarcus ReidのTwitterスレッド（英語）でご覧いただけます。

レプリケーションの調査は困難でした。VALORANT開発チームでは、何年もかけてベストプラクティスを確立しており、レプリケーションは著しく注意を必要とするようなシステムではなかったからです。さらに、レプリケーションはライアットのエンジニアが作ったシステムではないため、必要に応じて基本のエンジンに手を加えることはあっても、高度に専門的なことは私たちでは分かりません。

次に、私たちはゲームの様々な部分を分解してパッチ5.02から5.03の間の変更を調べることにより、問題の原因を絞り込もうとしました。Unrealのプロファイリングツールとライアットの社内ツールの両方を活用して、2つのパッチの間のパフォーマンスの特徴を比較しました。これが功を奏して、最終的にキャラクター、武器、およびアビリティーが、5.03では5.02よりも著しく頻繁にレプリケートされているという結論に至ることができたのです。

この間に検討されたルートは次の2つです。

劣化そのものを発見して修正する。これが達成したかった理想のシナリオです。
他にもパフォーマンスを改善できる部分がないか追求する。他に改良できる部分（失われたフレームレートを取り戻すのに十分なもの）が見つかれば、問題の根源を特定して修正できなくても、パフォーマンスを許容範囲まで改善できるというシナリオです。

エンジニアたちはグループに分かれていくつもの調査を行い、修正や改良の可能性をテストし、その中で多くのエンジニアがレプリケーションに精通し、専門知識を得ることができました。また、この時期にパフォーマンス改善につながる部分が複数発見されましたが、その時点では実装にはリスクがあるということで将来の開発のために記録されました。

そして2022年9月1日、ついに問題の根源が特定されました。UE 4.26のエンジンアップグレードに含まれていたコードのひとつが、VALORANT内の特定の状況下では通常よりも顕著に多くレプリケーションを起こしていたのです。これがパフォーマンスの劣化を引き起こし、サーバーに接続するクライアントが増えるほどパフォーマンスを悪化させていました。問題は標準的な10クライアントの試合でも感知されましたが、クライアントが22になるとプレイ可能な範疇を超えていました。

これで劣化の原因は特定され、修正によるリスクもなく、信頼性は高いと思われました。つまり、良いことばかりです。すぐにシャンパンを開けて祝ったりはしませんでしたが、コードの変更は実に満足のいくものでした。

劣化の後

劣化の原因が特定され修正されると、私たちは広範なテストを行い、パフォーマンスが期待に沿うものとなっているかどうかを検証し、変更による新たなバグが発生していないことを確認しました。

修正のリリース

修正方法が判明したのは2022年9月1日でしたが、変更が実際にeスポーツ環境に実装されたのは、グループステージが終わった2022年9月8日のことでした。実装を遅らせたのは、テストと検証のために十分な時間を取ってリスクを低減し、イスタンブールでの大会に与える影響を最小化するためです。

パッチ5.05でライブ環境にも修正が適用され、大きく改善が見られました。

Champions 2022以降

パッチ5.05以降も面白いことは続きます。レプリケーションシステムを調査していた1週間で、パフォーマンス改善につながる多くの機会が発見され、今後の開発スケジュールに組み込まれました。当時は問題の根本的原因が未解明で、そうした修正をすぐに適用するにはリスクがあるとみなされたのです。大元の劣化が修正された後、私たちは新たに会得したレプリケーションの技術で、サーバーパフォーマンスを改良し得るエリアに取り組み始めました。

こうした努力の結果、パフォーマンスが全体的に著しく改善され、全体のサーバーフレームレートが劣化前よりも15%短縮されました。またこれらの変更により、全地域のばらつきも減少して、サーバーフレームレートの安定性が向上しました。

パッチ5.07以降、サーバーフレームレートの99.3%以上がティックレート128Hzの基準を満たしており、プレイヤーの皆さんはVALORANTのリリース以来、最も安定して一貫性のあるサーバー環境でプレイしていることになります。

（パッチ別のサーバーフレームレートを示すチャート。線はそれぞれ標準的な10人の試合から最大の22クライアントの試合まで、クライアントの数別のデータを表しています。パッチ5.03と5.04の大幅な劣化の後、劣化が修正され、パッチ5.05では通常の値に戻っています。その後パッチ5.07でさらにサーバーパフォーマンスが改良され、劣化前と比べて15%の改善が見られます。）

学んだこと

このパフォーマンスにおける緊急事態には多くの人々の協力を要しました。十数人のエンジニア、eスポーツパートナー、テストベンダー、プロデューサー、チーム幹部、そして私たちに惜しみなく助言や指導をしてくださったパートナーチームの方々です。このインシデントからは多くの学びがあり、対処の中で今後改善したいプロセスのギャップもいくつか見つかりました。

非典型的な試合のモニタリング - 私たちは、10人でプレイするスパイクモードの試合に代表される典型的な"VALORANT体験"に概ね集中しています。私たちのデータには、接続するプレイヤーの人数に応じた分析がなく、新たなチャートが作られるまで劣化の規模は見えていませんでした。私たちはこの経験を踏まえて、10台以上のクライアントが接続する非典型的な試合におけるパフォーマンスの特徴をチェックし理解するための新たなプロセスを設計しました。
非典型的な試合のテスト範囲を拡大 – 今後も10人でプレイする標準的なスパイクモードの試合が優先事項ではありますが、22クライアントが接続する環境でのサーバーパフォーマンスをよりよく理解するための新たなプロセスとテスト手順を構築する予定です。22クライアントの試合のサンプルサイズは他と比べて格段に小さいため、データを収集するには定期的に22クライアントでのプレイテストを行うことが必要となります。今後は大きなトーナメントの前だけでなく、リリースごとに22クライアントのプレイテストを行うことを標準とします。恐らく、現在よりも洗練されたテスト手順が必要となるでしょう。
特定分野の専門家（SME）の育成 – 時間はかなりかかりますが、チームにSMEがいることで知識のギャップを補助し、チーム全体のレベルアップにつなげることができるでしょう。劣化を修正する過程で何人かのエンジニアがレプリケーションの専門技術を身につけたことは、素晴らしい人的リソースの投資となりました。
トーナメントのリスク最小化 – 導入されたばかりのパッチ──特にUnreal Engineのアップグレード直後で、Champions 2022を実行するということは、大きなリスクがありました。これまではゲームプレイの変更（バランス調整、キャラクターなど）は大きな大会に間に合わせるように導入してきましたが、今後はこのような綱渡り状態で大会に挑むことはなくなるでしょう。少なくとも、そのような状況が避けられないシナリオでは、厳密にリスク評価を行うこととします。

私たちは今後もこのような改良を続け、皆さんが一層VALORANTを楽しめる環境を作っていきます。それでは、ティックレート128Hzのサーバーでの戦いをお楽しみください！