「クライアント クリーンアップキャンペーン」の紹介

要約：これから約6ヶ月間にわたって、リーグクライアントのバックエンドの基礎構造にさまざまな変更や改善を行います。改善の成果が明確に分かるよう、クライアントのブートストラップタイム（クライアントが起動するまでに要する時間）と選択したチャンピオンの確定にかかる時間という、2つの主要なパフォーマンスの指標を公開します。また、これらの改善作業と同時に、バグやクラッシュ（強制終了）などの問題の解決にも取り組みます。まとめると、目標は「クライアントの諸問題を解決する」ことです。

「ねえライアット、いつまで壊れたクライアントを放置するつもりなの？」

たくさんのプレイヤーの方から、この質問が寄せられてきました。現行のクライアントはベストと言える状態ではありません。バグが多く、遅延がひどく（特にチャンピオン選択中）、メモリリークやクラッシュ、フリーズなど、多くの問題を抱えています。以前にも私たちはクライアントの問題解決に本腰を入れて取り組みましたが、まだ解消には至っていません。

そこで今回は、別の手法を試します。

今回の計画については、皆さんに曖昧な伝え方をするのではなく、パフォーマンスの目標となる指標を公開して、今後6ヶ月間にわたって予定されている変更内容を具体的にお伝えします。

まず最初に、最近行われたパフォーマンスの改善についてお話しします。次に、これから行われる改善の目標となる具体的な数値について詳しくお話しします。

数字で見るクライアント

昨年末、私たちはクライアントが起動してから全機能が利用可能になるまでの時間（いわゆる「ブートストラップ」）などの基本的なパフォーマンス指標を追跡するツールをクライアントに追加しました。

ブートストラップは低スペックPCの場合でも15秒以内に抑えたいと考えていますが、現状を見ると、一部のプレイヤーのブートストラップはその3倍から4倍の時間がかかっていることが分かりました。

私たちが追跡しているもう1つの主要な指標は「選択したチャンピオンの確定にかかる時間」です。これはプレイヤーがチャンピオン確定時にボタンをクリックしてから、クライアント内にデータが登録されるまでにかかる時間のことです。以下の表はパッチ9.22（オレンジ色）とパッチ10.2（青色）の期間中のチャンピオン確定にかかる平均応答時間を示しています（単位はms（ミリ秒））。

上の表を見ると、プレイヤーによってチャンピオン選択の応答時間に大きな差があることが分かります。もちろん、使用しているPCのスペックに応じてクライアントのパフォーマンスは変わります。たとえば、もしあなたが200ms（0.2秒）以内にチャンピオンを確定できているなら、あなたのPCは10パーセンタイル（※全体のうちの上位10%）以内に位置しており、応答時間は全体の90%のプレイヤーよりも早いことになります。逆に、もし800ms（0.8秒）以上の時間がかかっているなら、あなたのPCの応答時間は90パーセンタイル以降に位置しており、全プレイヤーの90%よりも…遅いことになります。

見てのとおり、チャンピオン確定にかかる時間はパッチ9.22と比較して、パッチ10.2で大きく改善されています。主な理由は、クライアントを実行しているChromiumのバージョンがパッチ9.23でアップデートされたからです。私たちにとっては大きな進歩であるものの、ほとんどのプレイヤーにとってはまだ遅すぎる状態でしょう。

これが何を意味しているか、チャンピオン確定にかかる応答時間について、一定期間内の変動を特定グループごとに詳しく見てみましょう。

青い線は50パーセンタイルで、「中央値」のプレイヤーを示しています。中央値のプレイヤーの応答時間が大幅に短縮されているのは素晴らしいことです。しかし、2020年初頭においても、中央値のプレイヤーはチャンピオン選択の応答時間が300ms（0.3秒）あたりを行き来しています。ひどいというレベルではないですが、まだ知覚できるほどの遅延が存在します。

70パーセンタイルのプレイヤー（緑色の線）でも最近になって大幅な改善が見られますが、チャンピオン選択の応答時間は450ms（0.45秒）あたりに留まっています。これはほぼ0.5秒近い遅延であり、私たちが中程度の性能のPCで実現したいと考えている応答時間よりもはるかに遅いものです。

最後に、目を覆いたくなるような90パーセンタイル（オレンジ色の線）のデータをご覧ください。表が示しているように、これらのプレイヤーは他のほとんどのプレイヤーよりも応答時間が遅いことになります。また、Chromiumのアップデート後で800ms（0.8秒）というのは遅すぎます。

次に、私たちがこの問題にどう対処するのかについてお話しします。

私たちが優先して取り組むこと

クライアントのパフォーマンスに関して、私たちが優先的に取り組んでいく長期的な目標は2つあります。

1. 90パーセンタイルのプレイヤーにおいても、ブートストラップタイムをおよそ15秒まで短縮したいと考えています。これは現在と比較して3倍から4倍高速化することになります。
2. 90パーセンタイルのプレイヤーにおいても、選択したチャンピオンの確定にかかる応答時間を、およそ100ms（0.1秒）まで高速化したいと考えています。これは現状の8倍の速度です。

皆さんが考えていることは分かります──他のバグはどうするんだ？クラッシュは？メモリリークは？

なぜこの2つが優先されるのか？その理由は、「ブーストストラップタイム」と「選択したチャンピオンの確定にかかる時間」の問題に対処する過程では、クライアントのアーキテクチャについて基礎部分のクリーンアップとリワークを行うことになるからです。つまり、この2つの目標を達成するために作業を進めていけば、バグやメモリリーク、クラッシュについても同時に対処できるようになると考えています。

たとえば、チャンピオン選択で「画面が真っ暗になる」バグやルーンページが正しく保存されない問題などが、この作業の過程で対処しようと考えているものの一例です。ただし、これには時間がかかることを正直にお伝えしておきます。現時点ではおよそ6ヶ月間の計画を立てており、これだけの期間があれば、目標実現に向けて意義のある成果が得られると考えています。しかしながら、長期目標を達成するにはもっと長い時間がかかるでしょう。

これらはあくまで目標であり、達成できない可能性もあります。それでもなお皆さんに目標の詳細をお伝えしているのは、これまで以上に透明性を高めないと、クライアントへの信頼を取り戻すことはできないと考えているからです。

そこで皆さんが知りたいことはおそらく──具体的には何をするの？

具体的には何をするのか

ブートストラップタイムを長引かせている大きな原因として、現時点でアーキテクチャの問題が2つ特定されています。1つ目はクライアントのコードを使いやすいチャンク（塊）に分離してくれる、プラグインのアーキテクチャです。クライアントに多くの新機能を追加してきたことで、このアーキテクチャが肥大化しています。2つ目はEmberと呼ばれる、UIを実行しているJavaScriptフレームワークの誤用です。

現在、クライアントはあまりに多くのプラグインとEmberアプリを利用しています。現状では、ブートストラップの処理中に41種類のプラグインと16のアプリが利用されています。これらが少しずつ遅延を積み重ねていくことで、起動に100ms（0.1秒）から800ms（0.8秒）の時間がかかっています。これは理想的な状態ではありません。

そこで、これらのプラグインとアプリの数を大幅に減らし（さらに理論上効率のより高い）プラグインとアプリに集約します。ブートストラップで起動するこれらの集約されたプラグインとアプリへの対応にまず注力することが、クライアント全体の大幅な改善につながると考えています。

フェーズ1：ブートストラップ

現在、多くのプレイヤーはブートストラップに40秒近い時間がかかっています。この「多くのプレイヤー」にあたる方なら、40秒という待ち時間がどれだけ長いか分かるはずです。クライアントがクラッシュして急いで再起動をしているときなら、さらに大きな苦痛となります。

通知やフレンドリスト、コレクションタブなど多くのクライアント機能は、ブートストラップ中に起動するプラグインやアプリの影響を受けています。そのため、前述の「90パーセンタイルにあたるプレイヤーのブートストラップを15秒まで短縮する」という長期目標の達成を目指す過程で、さまざまなバグやクライアント全体に非効率な挙動を引き起こしている問題も同時に解消されると考えています。

数ヶ月間ブートストラップに集中して作業を行ったあと、目標にどれくらい近づいたかを検証します。その後、おそらく今春の終わり頃には、次の目標であるチャンピオン選択の作業に移っていく予定です。

フェーズ2：チャンピオン選択

チャンピオン選択では、さらに多くのプラグインとEmberアプリが使われています。大雑把に言うと、チャンピオン選択で何かを行うたびに、新たなアプリが作成されます。チャンピオンを交換するとアプリが2つ作成されます。サモナースペルの変更も同じです。

1回のセッションでLoLを長くプレイするほど、これらのアプリが山のように積み重なっていき、大幅な遅延を引き起こします。チャンピオン選択中に行うほとんどのアクションは、サーバーとの通信に依存しています。そこでさらに問題が悪化し、あらゆる操作で遅延が増加します。

チャンピオン選択における真の根本的な問題は、バックエンドシステムのデータ管理方法にあります。現在のチャンピオン選択のアーキテクチャは、大量のデータを迅速にシステムに渡すことを可能にしています。たとえば、ライアットがランク戦で特定のチャンピオンを使用停止にすると決めた場合、その時点でチャンピオン選択中だったプレイヤーも含めて、ほぼ瞬時に全プレイヤーに対してそのチャンピオンを使用できなくすることが可能です。

これはとてもパワフルなシステムですが、機能させるために大きな馬力を必要とします。そして現在のシステムのセットアップ方法では、その過程に多くの不必要なゲートやボトルネックが存在します。そのため、小さなインプットが1つ変更されただけで大量のデータが再レンダリングされる事態が頻繁に発生し、結果として皆さんのクライアント体験が大きく損なわれます。

これを修正するには、チャンピオン選択におけるバックエンド基礎構造の仕組みを抜本的に変更する必要があります。そこで、「チャンピオン選択中にサーバーからクライアントに全データが渡される仕組み」をリワークします。これには時間がかかるでしょう。

他にも、チャンピオン選択をさらに効率化するために、「プラグインを一切使わずにクライアント全体を1つのEmberアプリに集約する」といった野心的な長期目標も存在します。ですが、短期的には、十分な改善を行ってここまでに記載してきた数値を実現することが、当面の目標です。

6ヶ月後に「とても良い」と言える状態にどこまで近づけるかは分かりませんが、そのときまでには多くの成果をあげて、次のステップが明確になっていると考えています。

次のステップ

2ヶ月ごとに/devブログでパフォーマンスの具体的な数値を添えて進捗状況をお伝えしていきます。その際、プロジェクトのスケジュールに変更があれば、それもお伝えします。

うまくいくよう祈っていただけると嬉しいです！いつもLoLをプレイしてくださり、ありがとうございます。それでは、また近いうちに！