要約
-----
ライアットゲームズeスポーツテクノロジーグループはこの数日間、Mid-Season Invitational 2022（MSI）で発生した一連の技術的問題に取り組んできました。この問題は現地参加プレイヤー/リモート参加プレイヤー間でping値を均等化するツールで生じていたものです。
最初の問題はLatency Service Tool（遅延サービスツール）と呼ばれるソフトウェアに関連するものです。具体的には、参加プレイヤー全員の遅延（ping）を35 msに調整するための本ソフトウェアでバグが発見されました。このバグにより、韓国・釜山の会場内で競技に参加したプレイヤーのping実際値が、画面に表示される35 msよりも高くなっていました。このため中国から参加していたプレイヤーのpingは35 msであったのに対し、釜山で参加していたプレイヤーのpingがそれ以上となっていました。大変遺憾ながら、私たちはイベント開幕前にこのバグを発見することができませんでした。早い段階で発見できなかった理由は、これが遅延値の計算を誤るコードバグであり、そのためログファイルにも実際とは異なるping値が記録されていたためでした。その結果、実際のイベント中のモニタリングとイベント前のテストの両方において、（実際には誤っているにもかかわらず）数値上は正常な挙動をしているように見えてしまうという事態が生じていました。
本バグについては5月13日にLatency Service Toolの設定を変更し、修正が完了しています。また本バグにより、釜山会場側プレイヤーは必要以上の遅延の中でプレイする不利を被っていたため、私たちは大変難しい、しかし絶対に欠かすことのできない決断をし、ping値が均等化されないままプレイされたグループBの3試合について、再試合を実施する判断を下しました。
しかし、5月13日の修正は新たな問題も生み出しました。釜山参加プレイヤーの画面に表示されるping値が実際（正確な値）よりも低く表示されていたのです。結果的に、配信でプレイヤーの画面を表示した際には不正確で実際よりも低いpingが表示されることとなり、本問題の状態を事前に告知できなかったために「釜山会場のプレイヤーは（実際よりも）低pingでプレイしている」と視聴者の皆さまに誤認させてしまう事態を生み出していました。
本記事ではこれらの問題について、イベント前から現在（グループステージ終了時点）までの経緯を技術的視点から振り返っていきます。
イベント前
---------
チームが本年のMSI開幕前に技術準備の計画を詰めている頃、新型コロナウイルス感染症の流行に関係する課題がひとつ発生しました。LPL代表のRoyal Never Give Up（RNG）が上海から釜山へ移動できず、リモート参加を余儀なくされたのです。
最もシンプルな解決策はリモート参加のチームがMSI用サーバーに接続し、現地参加チームはLAN環境でプレイするというものです。しかしこの案を実現するにはいくつか問題があり、望ましくない選択肢となっていました。
ひとつめの問題は地理的な距離です。釜山と上海は（黄海をまたいで）約850 km離れています。これは上海と韓国内MSI競技サーバーの間でデータの往復が発生することを意味します。
この往復にかかる時間がping（あるいは遅延）です。まず、RNGの所在地とMSI競技サーバーの間では約35ミリ秒（ms）の遅延が発生していました。一方、12チーム中10チームは釜山会場内でプレイしており、会場内のpingはそれよりもずっと低い約15 msでした（ping値は±5 msほど変動するため、いずれもおおよその数値であることをご了承ください）。
この35 msと15 msの差は、平均的なリーグ・オブ・レジェンドプレイヤーであれば気づかない場合もありますが、プロプレイヤーの場合には小さいながらも知覚できる違いを生み出します。しかし、「競技の公平性」はライアットの最重要指針のひとつであるため、全参加チームは平等な競技環境でプレイできなければなりません。
平等な競技環境を実現するには、ping値の差異を解決する必要がありました。
リモート参加の実現に向けた取り組み
---------------------------------------
eスポーツの試合は必然的にネットワークを経由して行われます。このため、MSI 2022ではリモート参加の新たな環境を模索することにしました。
これには2つの疑問に答えを導き出す必要があります。
- 上海-釜山間の35 msというping値は最高峰の競技レベルで許容しうる範囲か？
- 全プレイヤーが同じ遅延でプレイする競技環境は提供可能か？
疑問1の回答はイエスでした。League of Legends Esportsの規定では、最高峰の競技シーンにおける遅延の最大許容値は40 ms（変動幅±5 ms）とされています。これは2020年中期に議論・分析を重ねて決定した数値で、策定に際しては社内メンバー、外部パートナー、および社内ゲーム分析・デザイングループが参加しています。ここで意見を求めたプレイヤーの大半がドラフト中のピック操作、スキルショットの命中精度、対戦相手への反応速度などで遅延を体感し始めた変曲点が40 msでした。
疑問2については、複数の選択肢を検討しました。
**選択肢1：各チームがネットワーク遅延無調整の環境でプレイする**
リモート参加のチームが現実的に最も高速なインターネット接続を用いてMSI競技サーバーに接続する案です。この場合、MSI会場でプレイするチームは超低遅延（～15 ms）でプレイし、リモート参加チーム（今回のケースではRNG）は遅延無調整の状態（中国の場合～35 ms）でプレイすることになります。
しかし全チームが平等な環境で競技に臨める環境を目指すならば、この案は競技の公平性が損なわれると判断したため、精査した上で除外することにしました。
**選択肢22：サーバーを中国と韓国の中間地点に配置する**
次に検討したのは、中国-韓国間のping値が35 msであったことを踏まえ、その中間地点にサーバーを設置して遅延値の中間を取り、ping値17.5 msにするという案でした。この案にも多数の課題がありましたが、最大の課題は当然ながら「中間地点が海上で、そこにサーバーは設置できない」ということでした。
**選択肢3：人工的遅延均等化技術を導入する**
韓国側では超低遅延で、中国からの接続では高遅延になることが問題ならば、韓国側環境に人工的なディレイ（待機時間）を設定して遅延を均一化すれば良いのではないか？という案です。うまくいくでしょうか？そもそも実現可能なのでしょうか？
調べていくと、すでにLoL開発チームが人工的遅延均一化機能を導入する手段、通称「Latency Service」を開発していたことが分かりました。一部では「フェイクping」と呼ばれているこのサービスはクライアント・サーバー機能の一種で、新型コロナウイルス感染症による渡航制限に対応し、リモート接続でも競技の公平性を確保するべく開発されたものです。Latency Serviceでは指定した目標ping値（今回であれば35 ms）に基づいて各プレイヤーのクライアントとサーバーの両方にディレイを挟み込み、遅延均等化を実現します。
しかしLatency Serviceはeスポーツイベントでの採用実績があったものの、すべて完全リモートのイベントでの採用で、グローバルイベント、かつ一部チームが現地参加している環境での使用は前例がありませんでした。使用実績があるとはいえ、僅かな違いが予期せぬバグを引き起こす可能性は排除できません。そこで私たちはまずスクリム（練習試合）サーバーの標準ネットワークインフラに人工的遅延均等化を導入し、ネットワークテストを実施しました。その結果、グループステージ開幕前に「現実的に重大な問題なく実用可能」であると評価するに至りました。
**選択結果**
各案を比較検討し、競技の公平性を追求することが最重要であると結論付け、人工的遅延均等化案が最善であると判断しました。
人工的遅延均等化の実装案：しくみ
------------------------------------------
Latency Serviceはリーグ・オブ・レジェンドソフトウェア上でネイティブクライアント・サーバーのネットワークスタックに組み込まれます。このサービスは各プレイヤー-サーバー間でネットワーク遅延の実際値を測定し、必要に応じてディレイを追加することで目標遅延値を実現します。クライアント・サーバーモデルであるため、ディレイはネットワークの両端で平等に差し込まれます。
上の図はシステムの構成図です。上側がゲームサーバーのコンポーネント群、下側がクライアント（プレイヤーのPC）を示します。この図のLatency Serviceは遅延を35 msで均等化するよう構成されています。赤色の矢印はネットワーク遅延の実際値を示しており、釜山にいるPlayer 1とPlayer 2の「実際の」ping値は15 ms、上海にいるPlayer 10のping値は35 msとなっています。黄色の矩形は、クライアント側、サーバー側でそれぞれ挿入された人工的な遅延の長さを表しています。この図ではPlayer 1とPlayer 2にクライアント側、サーバー側で10 msずつのディレイが挿入され、目標遅延値35 msを実現しています。一方、Player 10の遅延は既に実際値が目標値と同じ35 msであるため、ディレイは挿入されていません（0 ms）。
プレイ環境をまとめるか分けるか
----------------------------------------------------
本事案をより詳細に説明するには、リモート環境vs会場内環境の比較に関する大きな決断について触れないわけにはいきません。
ライブイベントに携わる時、eスポーツテクノロジーグループは常にリスクを最小化する手段を模索します。2012年にロサンゼルスで開催されたシーズン2 Worldsにおいて、インターネット接続の問題で日程途中のキャンセルが発生した記憶はあまりに鮮烈で、今もeスポーツに携わるすべてのライアターの脳裏に焼き付いています。
MSI 2022のネットワークトポロジーを決定するに時も、私たちは2つの戦略のうち一方を選択する必要に迫られました。
**戦略1：単一トポロジーですべて対応する**
これまでグローバルな競技トーナメントでは、ゲームサーバーは常に会場内に（物理的に）設置されてきました。これはネットワークとサーバーハードウェアを直接的に管理できる環境のほうが高度な信頼性を保てるためです。しかし1チームがリモート参加するとなると、少なくとも当該チームがインターネット経由で接続する環境をサポートする必要は生じます。そしてインターネット経由で接続するチームの存在を前提とするならば、サーバーの現地設置を完全にやめ、全チームがインターネット経由で接続する環境を整えるという戦略もあり得ます。
しかし信頼性を考えるならば、インターネット経由のゲームサーバーには最も優れた実績を持つ環境を選ばなければなりません。ここで最有力候補となるのが韓国のeスポーツゲームサーバー（プロ専用のサーバー、韓国のパブリックサーバーと同じデータセンターで稼働しており、韓国リーグLCKでも定期的に使用されている）です。プレイヤーが実際にプレイしてきた時間も長いため、ネットワーク接続の安定性とインフラの信頼性も充分です。1チームは間違いなくリモート参加することを前提とすれば、これ以上に信頼性が高い競技環境はないでしょう。しかしここで新たな疑問が浮かんできます。全試合をこのサーバーで行うのか、リモート参加チームの試合だけ行うのか？という点です。こうして私たちは「戦略2：外部ネットワークを経由するリスクを最小化する」の検討を開始しました。
**戦略2：リモート専用ネットワークを使い分け、外部ネットワークを経由するリスクを最小化する**
一部の試合がインターネット経由で実施されることが確定しているなら、なぜ全試合をインターネット接続で実施しないのか？という疑問が出てきたことは先述の通りです。この問いに対する回答は極めてシンプルで、「インターネットの信頼性」です。インターネット経由でも何一つ問題が起きない可能性はありますが、突き詰めれば「運次第」の側面が絶対に残ります。MSIの全試合をインターネット経由で実施する場合、インターネットの接続問題が試合に影響する潜在的リスクが排除できないのです。しかしリモート参加チームの試合だけをインターネット経由で実施すれば、インターネット接続の信頼性リスクはそれらの試合だけに限定できます。仮にインターネット接続で問題が生じても、対応策を幾重にも用意しておけばおそらく解決できるでしょう。しかしリスクは最小化しておくに越したことはありません。あとは人工的遅延均等化サービスの状態を考慮し、複雑さと信頼性のどちらを優先するかを判断するだけでした。ここで私たちは、多少の複雑さ（トポロジーを2つにする）を受け入れてでも、リスク（インターネット接続の信頼性）を低減することを選びます。
こうして私たちは、ネットワークの信頼性/イベントの競技性リスクを最小化する案を検討・評価し、戦略2を採用することにしました。
以下の図は、今回採用したネットワークトポロジーの構成図です。様々なシナリオを想定してネットワークの接続性を確保する構成になっています。
計画倒れ
----------------
先述のとおり、私たちは各種要因を考慮した上で2種類のトポロジーを使い、Latency Serviceで競技の公平性を保つという方針を固めました。韓国入りしたチーム同士の試合はMSI会場内のゲームサーバー上でプレイされ、リモート参加のチームが出場する試合は韓国国内のデータセンターにあるeスポーツゲームサーバーでプレイされる、という構造です。そしてシステムを構築し、インフラテストを実施し、ping値の計測・監視、ネットワークジッタの対応、パケットロス発生有無のチェックなどを含めてすべてが正常に動作していることを確認しました。また出場チームにはeスポーツゲームサーバー上でのスクリムや、ステージ上での技術チェックなどを行ってもらいました。
しかしイベント初日の終了後、プレイヤーからは「何か違和感がある」というフィードバックが寄せられます。一部のプレイヤーは、画面上のping値は35 msと表示されているけれどもっと遅延しているように感じるとも話していました。監視ツールのログファイル上ではすべて正常と記録されていましたが、私たちはその声を受けて原因調査を継続していきました。
**見えない標的を探して**
しかし調査を勧めても根本原因は判明しません。インフラ監視ツールからも問題は報告されておらず、pingが高いように感じるという報告はある一方で、調査対象となるバグやゲーム状況が存在しなかったのです。そこで私たちは基本に立ち返りました。どんなデータがある？どんなログがある？他にどんな情報が収集できる？…と。
その後は調査を二手に分け、一方は状況を正確に理解する手がかりとなりそうな質問をまとめ、プロチームに尋ねました。誰が問題を体感したか？現地サーバーとeスポーツゲームサーバーで、より遅延が大きいと感じたのは？会場ネットワークとスクリムネットワークで、より遅延が大きいと感じたのは？全試合でそう感じたか、特定の試合だけだったか？一方、別働隊は（標準レポートには問題が見つからなかったため）他のログや指標に不一致がないか調査を開始します。トーナメント中のクライアントとサーバーのログを引っ張り出し、データを突き合わせていきました。
たとえばある時点では、「ゲームサーバーのフレームレートが安定していなかったのではないか？」という仮説を立てて調査していました。この時に開幕後数日の全試合のログから生成したグラフが上の図です。このグラフからは、サーバー上でのフレームレートが試合ごとに安定していたことが読み取れます。これでゲームサーバーのパフォーマンスが安定していたことがデータで裏付けられたので、プロプレイヤーから報告された「操作の応答性が不安定」問題の原因ではないことがほぼ確定します。
ログの調査はとても骨の折れる作業です。生のデータはランダムな数値が延々と並んでいるだけのものであるため、可視化して意味を見出すためには様々なツールで処理しなくてはなりません。しかし何を試してみても、異常なしという結果が出るばかりでした。
その後もログとコードの調査を進めていると、やがてプロチームの回答が返ってきました。しかし回答は問題は主にMSI会場環境で発生しているという内容で、一般的な理屈とは真逆の内容でした。会場環境の試合はプレイヤーと同じ建物内に設置されたハードウェアで行われています。完璧に管理されたネットワーク環境下での試合のほうが、インターネット経由での試合よりも遅延が大きいと感じられるというのは、どうにも説明がつきません。
こうして私たちは新たな仮説を立てます。ログに記録された遅延データに問題がないのにゲーム体験側で違和感が感じられるならば、ログに問題があるのではないか？遅延の測定手法に問題があるのではないか？という仮説です。
これを検証するため、開発チームはコードを書き、デバッグ専用クライアントを作成しました。通常のログは、サーバーのネットワーク層とクライアントのネットワーク層の間でゲームデータパケットが「往復」する時間を記録します。しかし、このログ中にはエラーが見つかりませんでした。そこでチームは新ツールを用い、遅延を別の方法でテストすることにしました。これはネットワーク層のトラフィック遅延ではなく、エンドツーエンド（終端間）でループ全体の遅延をテストするものです。ユーザーのクリック操作がゲーム上に反映される瞬間までの時間を計測するツール、あるいは、ネットワークのパフォーマンスではなく、ゲームエンジン内における全システムのやりとりを計測するツール、とも言えるでしょう。
上の図は新ツールのコンセプトを示したものです。既存のネットワーク監視システムでは緑色矢印で示されたネットワーク層の遅延を計測していました。一方、新ツールではネットワーク層間の遅延、Latency Serviceのディレイを含むすべてを計測します。赤色の矢印は新監視ツールで計測する遅延の各項目を示したものです。ご覧の通り、新ツールは入力層からサーバー側のゲームエンジンまで到達し、その後クライアントに反応として戻されるまでの過程すべてを網羅しています。
こうして私たちは、専用環境で新診断計測ツールを用いて実験を行い、プレイヤーから報告された問題が再現するかどうかを確認しました。
この実験では、まずLatency Serviceを無効化した状態で「ベース測定値」を求めました。パブリックサーバーには凄まじい総プレイ時間の実績があるため、まずはサーバー側にバグがないことを明確にし、以後のテストにおける「対照群」として扱おう、という狙いです。このベース測定値を求める最初の実験では、まず韓国内のチームと中国内のチームがインターネット経由でゲームサーバーに接続するケースをシミュレートしました。
**実験1：Latency Service無効、韓国/中国のネットワーク比較**
この種の実験で用いるデータはかなり複雑ですが、チームはなんとかデータを揃えて視覚化し、状況の分析に着手できました。
X軸（ゲーム時間）を見てみると、当初（チャート左側）の遅延値は低いことが分かります。その数分後、今度はping値の高いネットワーク（上海から接続する側）の測定を開始しました（チャート中央線から右側）。ご覧の通り、遅延の測定値（垂直軸）は大きく上昇しています。ping値の低いネットワークでは遅延が少なく、ping値の高いネットワークでは遅延が大きくなる。これは想定通りの結果です。
こうして対照群となる実験1では、新ツールを使った検証でも想定通りの結果が得られることが確認できました。出だしは好調です。
次の実験ではネットワーク条件とテスト内容はそのままに、Latency Serviceを有効化してみることにしました。
**実験2：Latency Service有効、韓国/中国のネットワーク比較**
先述の通り、Latency Serviceは通常時のネットワークping値に関係なく遅延を均等化するツールです。このため実験環境にpingの異なるネットワークを用意すれば、Latency Serviceがその差を補完し、遅延測定値は同一になるはずです。しかし結果データはそうなりませんでした。ご覧の通り、上海ネットワークのシミュレーション側のほうが韓国ネットワーク側よりも遅延測定値が下がっていたのです。Latency Serviceが上海側よりも韓国側を高遅延化している。これは想定外の結果でした。
このレポートにより、私たちは以下3点を断定しました。
- これは重大な問題であり、新データはプレイヤーからの報告内容と一致する
- 本問題は、実験環境で再現できる
- 原因は人工的遅延均等化ツールである可能性が高い
この情報は原因調査すべきコードの範囲を推測する上で大きな助けとなりました。そして実験用ネットワークの条件を変更しながらさまざまな追加テストを実施した結果、「pingの実際値が目標遅延値よりも大幅に低い場合に計算エラーが生じる」ことが判明します。この条件を満たす環境では、遅延の実際値がプレイヤー画面に表示されるping値よりもかなり高くなっていたのです。
これならば各種問題にも説明がつきます。ログ上にエラーがなかった原因は、計算が間違っていたため。会場からインターネットサーバーに接続した時に遅延が大きくなっていた原因は、当該バグが低ping環境で特に強く発生するため。釜山側プレイヤーが35 msよりも遅延しているように感じていた原因は、画面上に表示されている35 msよりも、実際のping値が**本当に悪かった**ため。
これで問題が特定されたため、次の目標は可能な限り速やかに修正することになります。
幸い、調査中にコードの全体像を把握できていたため、問題箇所を特定して計算エラーを補完するところは順調に進みました。
また両環境のシミュレーション環境は実験時に構築済みで、遅延の実際値を測定するカスタムツールも揃っていたため、両方のネットワークで遅延が正しく均等化されるよう設定を調整する作業も進めることができました。
以下の図はLatency Serviceのバグを補正する措置を施した上で実験1、2と同じネットワークシミュレーションを実行した結果です。
**実験3：Latency Service有効、設定修正済み**
今回もこれまでの実験と同様、まず低ping環境をシミュレーションし、数分後に設定を変更して高ping環境をシミュレートしました。これまでの実験との違いはLatency Serviceが修正されて正しい挙動をしている点です。そしてこのグラフでは低pingから高pingに変更しても遅延の変化は認識できないレベルになっています。
**これで問題は解決…？**
しかし設定を変更してゲーム内ping計算のバグは修正したものの、その結果としてプレイヤーの画面にFPSとpingを表示する画面オーバーレイ（CTRL+V）には不正確な数値が表示される問題が生じていました。実際の遅延値よりも約13 ms低い数値が表示されていたのです。これはLatency Serviceの設定変更時に、計算エラーによって生じたズレを「相殺」することで目標値と一致させたことが原因でした。この相殺処理により、クライアント側のログ数値・表示値に影響が生じていたのです（詳細は後述）。この結果、表示されるping値は実際よりも13 ms低くなっていました。結果的には、大変残念ではありますが、画面に不正確な数値が表示されることになったとしても遅延を正しく均等化し、競技の公平性を保つことを優先するという判断を下しました。
その後の対応と大きな現実的課題
---------------------------------------------
こうして遅延の実際値を正しく測定する方法と計算エラーを相殺する設定を特定した私たちは、すぐに修正の導入とプレイヤー・コミュニティーへの経緯説明に向けた計画立案に着手しました。
しかし問題の理解を深めるほどに、状況の難しさは明確になっていきます。
MSI会場のプレイヤーは35 ms超の遅延下でプレイしており、上海のリモート接続チームは想定される35 msの範囲内（上海-釜山間の無補正ping）でプレイしていたということは、競技の公平性に求められる平等なping環境を提供できていなかった、ということです。
私たちは、即座にチームに状況を伝える必要がありました。しかしそれにはひとつの重要な疑問「遅延の差は再試合実施を正当化するほど大きかったか？」に明確な回答を用意する必要があります。競技運用上の判断が求められる状況です。両環境の推定ping差は15～20 ms前後であり、影響を受けた3試合を競技公平性が確保された新環境で再実施するかどうかの判断は大変難しいものでした。
ping値オーバーレイ表示に関する説明
----------------------------------------
バグの影響を受けた（トーナメント序盤に行われた）試合の再実施を決断した後は、全体スケジュールの調整、対象チームへの充分な状況・経緯説明などやるべき事が山積していました。私たちはまず設定変更をゲームサーバーに適用した上で各種テストを実施して動作確認をし、続いてプロプレイヤーを会場に招いて新設定導入済みサーバーでテストをしてもらい、問題が解決したことを二重、三重に確認していきました。また万全を期すため一部のプロプレイヤーにブラインドテストへの協力を依頼し、旧設定/新設定の両方でプレイしてもらって「どちらが35 msだと感じるか」を尋ねることもしました。
しかしここで私たちはひとつ痛恨のミスを犯しています。オーバーレイ表示されるping値が不正確であることを、プレイヤー、ファンの皆さん、配信チームに伝えられなかったのです。
トーナメントが再開されると、ファンの皆さんからは「釜山側チームのほうが遅延が低いように見えるが、これは公平性に欠けるのではないか」という声が寄せられました。SNSには次々と公式配信のスクリーンショットが投稿されていきます。想定は～35 msのはずなのに、22 msと表示されていると。
明確な説明が求められていました。
先述の通り、今回私たちがLatency Serviceバグの迂回策として採用したのは、計算エラーによって生じたズレを「相殺」するものでした。オーバーレイ上の数値に問題が生じたのはこの相殺処理に起因するものです。
- 上海側プレイヤーに表示されているping値は正確
- 釜山側プレイヤーに表示されているping値は不正確で、実際値は表示値よりも約13 ms高い
改めて原因を説明すると、上海側では元々の遅延値が35 msで目標値と同一であったため、先の相殺処理が行われず、結果として正確なping値が表示されていました。一方、釜山側ではエンジン内での遅延値計算エラーに対する相殺処理が行われており、実際値は～35 msに均等化されていたにもかかわらず、ログおよび画面表示値は実際よりも約13 ms高くなっていました。
これを検証するため、調査チームは30セッション以上のクライアントログデータを収集し、プレイヤー画面に表示されていた数値に対応する実際のping/遅延データをグラフ化しました。
上のグラフはRNGが出場した試合のみを抽出したデータです。Y軸は記録されたping値を示します。一方のX軸（横軸）は前項までは時間経過を示していましたが、この図のX軸はデータセットを試合単位で区切ったものとなっています。緑色の四角はクライアントに記録されたping値のヒストグラムをプロットしたものです。それぞれの四角はプレイヤー1名と使用PC 1台について、1試合で記録されたデータを示します。値の変動は最小限で、いずれも33 ms～39 msの範囲に収まっています。これはRNGの無補正ping値35 ms（±5 ms）と一致します。
続いては釜山側プレイヤーのクライアントログに記録されたデータセットに着手し、設定変更前と後でグラフ化しました。
上のグラフでは、釜山会場でプレイされた試合のデータのみを抽出しています。上下矢印よりも左側に表示されているのが「変更適用前」のデータです。記録されている値は33～39 msで、35 ms ±5の範囲に収まっています。ただし、これらの値はプレイヤーから違和感が報告された試合のもので**不正確**です（その後、エンドツーエンドの新監視ツールで不正確であることが確認されたデータ）。
そして上下矢印よりも右側にあるのはpingの**実際値**を修正した後、「変更適用後」のデータです。ログ上のping値は19～25 msの範囲まで下がり、22ms ±5msとなっています。このグラフで左右の差異を見てみると、**ログ上のping値**の差はほぼ一定で、13ms（35ms - 22ms = 13ms）になっていることが分かります。つまり設定変更によりpingの実際値が修正された後は、釜山側プレイヤーのオーバーレイで22 msと表示されている場合、実際値は35 msになっていたのです。
先程のT1 vs SGB戦のスクリーンショットの時点で全プレイヤーの遅延は均等化されており、実際値は35 msだったにもかかわらず、Zeusの画面上ping値が22 msと表示されていた背景にはこのような経緯がありました。この22 msにクライアントログのデータから推測される差分13 msを加算すると、実際の正確なping値である35msとなります。
終わりに
----------
私たちはライブイベントに携わるテクノロジーチームとして、問題のない環境を実現するべく最善を尽くし、テストと（二重、三重の）確認を行っていきます。そして、最優先事項はこれからも変わらずプロチームに公平な競技環境を届けることです。テクノロジーは当然のものとしてそこにあり、競技・ゲームプレイが主役としてスポットライトを浴びる状態こそが目標です。
今後も技術チームは最高峰の競技環境を維持し、世界中のファンに最善のeスポーツ視聴体験を届けられるよう尽力していきます。計画変更には必ずリスクが生じます。しかしそれでも、チームとファンの双方にとって最高の体験を届けるために、私たちは計画立案・リスク判断に全力を尽くしていきます。
今回は私たちがひとつのバグ見逃した結果、試合に影響を及ぼしてしまいました。本件が引き起こした混乱と不満について、ここに心より謝罪申し上げます。また、ping値のオーバーレイ表示が不正確である点の情報共有が不足したせいで混乱を招いてしまった点についても、重ねてお詫び申し上げます。
今後はテスト・検証手順を強化し、ランブルステージ、ノックアウトステージをスムーズに進行できるよう努めてまいります。また、トラブルに直面してもなお粘り強く戦い続けたプロチームとプレイヤーの皆さまに改めて大きな賛辞を贈り、併せて問題解決への協力に感謝します。こうしたバグが競技に影響を与える事態は二度と起こさない、と確約することはできません。しかし、私たちはこれに学び、改善し、チーム/ファンとより能動的にコミュニケーションすることを目指し、同時に一層のリソースを投入してイベント運営環境の管理・確認体制を改善してまいります。
