【CEDEC 2019】自動化の導入で実機プロファイリングは激変する！　KLabがAndroid実機での全自動プロファイリング方法を紹介

9月4日～6日の期間、CEDEC 2019が、パシフィコ横浜で開催された。初日にあたる4日、KLabによる講演「Android向けUnity製ゲーム最適化のためのCI/CDと連携した自動プロファイリングシステム」が行われた。

本講演では、KLabでエンジニアに従事している細田翔氏と於保俊氏、エンジニアマネジメントを務めている塙与志夫氏が登壇し、Unity製ゲーム向けの自動プロファイリングシステムに関する講演を行なった。


▲本講演で登壇した細田翔氏（写真左）、於保俊氏（写真中央）、塙与志夫氏（写真右）。

モバイルのゲーム制作においては、実機でのプロファイリングのしにくさが問題になっている現場は多いだろう。今回の講演を行なうにあたっても、細田氏が実機プロファイリングに感じている問題点を列挙している。


▲モバイル端末の多様性は、プロファイリングを行なううえでは大きなデメリットとなる。

これらに対する解決策のとして細田氏が紹介するのが、CI/CDと連携した、継続的かつ全自動のプロファイリングという方法だ。こうすることで、専門知識を持たないエンジニア以外の人間であってもダッシュボードから結果を見れるようにもなる。


▲プロファイリングの手順を簡略化することにより、パフォーマンスの劣化を見逃しにくくなる。


▲本講演で解説していくシステムの全体図をまとめたスライド。プロジェクトメンバーはビルドを実行したのち、データポータルを閲覧するだけでよくなっている。

通常のプロファイリング方法は、Unity標準のProfilerを利用するものだ。Unity製のゲームであれば、どの現場でも使っているであろう機能だ。フレーム単位で詳細な分析ができる。



Unity Profilerを使うとなると、通常はPCと端末をUSBケーブルで接続し、プロファイラからアタッチするという手間のかかる形式となる。しかし、APIを使用することで、Unityのアプリ側からプロファイルの開始と終了ができる。

さらに、プロファイリングしたデータはバイナリログとして端末のストレージ内に保存可能になり、PCと接続していないスタンドアローンの状態でも動作する。


▲具体的なスクリプトはスライド下部に記載されている。

自動化を実現するためには、バイナリログの読み取りもUnity Profilerではなく、「Profiler Reader」というツールをKLabでは採用している。これは、バイナリログをCSVに変換し、集計も行なえるツールだ。


▲KLabは、Unityとエンタープライズ契約を結んでいるため、このProfiler Readerが一般公開される前からテスターをしていた。現在では一般公開されており、安定した操作ができると細田氏は語っている。


▲実際にProfiler Readerを活用したケースを紹介したスライド。

自動プロファイリングシステムを導入するにあたっては、放置した状態でゲームが進行するように、自動プレイ機能の実装も考える必要がある。プロファイリング対象となるシーンに遷移し、すべてに遷移したあとはアプリを終了するという流れを自動で行えるように組み込む。

もちろん、プロファイリング用のPCに、プロファイリングの結果を通知するシステムも仕組みも必要だ。今回細田氏が紹介しているケースでは、端末側で通知用のファイルを生成し、それをプロファイリング用PCに通知する形をとっている。



ここまでが、細田氏による自動プロファイリングのためのUnityアプリケーション側の実装にまつわる話となる。以降は於保氏による、Android実機による自動実行システムにまつわる話となる。



▲先ほどもつかったシステム概要のスライド。黄色の枠で囲まれている部分が、於保氏の発表に関連する箇所となる。

自動実行システムに関して、於保氏は泥臭いシステムを使っていると言いながら、1枚のスライドを提示した。

見ての通り、USBハブを使って同時に複数の端末を繋げているという状態だ。このとき繋いでいるPCのOSはWindowsとなっている。つないだ端末はAndroid開発ツールでコントロールしている。


▲USBの仕様上では100以上の端末を繋げること自体は可能だが、4台程度でもかなり動作に不安定な部分は出てくるので、これ以上を繋げるとプロファイリングの行程に影響がでてくる。


▲具体的なプロファイル自動実行の流れを示すフローチャート。こうして図式化すると、工程自体は非常にシンプルにまとまっている。

実機利用は不安定になりがちなため、多くの問題点がでてくる。そのひとつが頻繁に起こるエラーだ。基本的にはadbのエラー終了として発生する。

これに対する解決策は、少し待ってからリトライするという方法が経験上一番有効であると於保氏は語り、apkインストールの失敗時には、adbサーバーの再起動といった方法も有効であることを付け加えた。


▲本講演の冒頭でも述べているように、機種やOSの多様性も大きな問題となる。しかし、これをすべて解決しようとするのは無理があるため、多少の諦めも必要となるそうだ。

次の問題点は、端末の状態をクリーンに保つ必要があるという点だ。プロファイルをするうえでは、できる限り同じ環境で行なうことに意味がある。そのために使うべきコマンドも紹介された。

そして、当然ながら連続稼働を続けていれば端末から熱が発生し、それによるパフォーマンスダウンが起こる。冷却のための待ち時間も必ず考慮すべきだ。端末の再起動を試行した時期もあったそうだが、不安定になりやすいらしく、現在は端末の再起動は行なっていないようだ。



また、端末側の設定にも気を配っておく必要がある。最低限設定しておくべき項目として、開発者モード、充電中のスリープ不可、ファイル転送モードといったところだ。余計なところで電力を使わないよう、画面輝度も下げておきたい。


▲音量に関しては、夜間に音が鳴り続けることでトラブルにならないようになど、職場環境を保つためのマナー的な意味が大きいようだ。

これで、於保氏によるAndroid実機の自動実行システムに関する話が終了した。次は、塙氏による、プロファイリング結果を確認するためのダッシュボードシステムに関する講演となる。



▲このスライドの右側に相当する部分が、塙氏の講演に関連する部分となる。

まずは、例としてブラウザで見れるダッシュボード画面をスライドで提示し、これから話すダッシュボードがどういったものなのかを会場と共有した。



塙氏は、ダッシュボードを作るにあたって考えるべきことは、管理者不要のマネージドサービスで構成することと、コストを抑えることの2点だとしている。それらを同時に実現するための方法として、GCPサービスとBIツールの組み合わせる方法を紹介している。



これまでのスライドでも見せてきた通り、KLabダッシュボードを構成する要素は「Cloud Storage」と「Cloud Functions」でCSVを処理し、分析用データベース「BigQuery」に投入。Googleデータポータルで結果の可視化を行なうといった流れになる。



これらによって構成されるダッシュボード画面が、最初に提示したものとなっている。詳細はドリルダウンリンクで確認できる。



▲そのほかにも、プロファイリングに役立つ情報として、負荷が高くなるタイミングを可視化したグラフもよく使われるそうだ。どの実機で負荷が高くなるのかを個別に見られることも大きく、特定の機種で発生する高負荷を察知しやすくなるとのことだ。

次に見せたスライドは、ウィークリービルドをカテゴリ別に確認するための可視化グラフとなる。



今回、他のサービスではなく「BigQuery」を選んだ理由として、塙氏はGoogleスプレッドシートとの連携がしやすいことを挙げている。Googleスプレッドシート上であれば、チームメンバーで自由に編集ができ、それがすぐダッシュボードにも反映される。

そして、GoogleスプレッドシートはBigQueryのテーブルとしても扱えるので、仕組みを詳しく理解しているものでなくても集計結果のカスタマイズができる。こうした扱いやすさから、BigQueryの採用にいたっている。



実際に運用してみたところ、Unityのマイナーバージョンアップなど、意図しないタイミングで性能とは関係ないと踏んでいた部分が影響するケースの原因究明につながったといったエピソードを紹介しつつ、非エンジニアとのデータ共有をしやすい点を強く推している。



最後にまとめとして、Android実機による自動プロファイリングを開発したことにより、実機プロファイリングのハードルを大きく下げつつ、結果をメンバー内で共有しやすくなったことや、ボトルネックの発見、性能改善のイテレーションが速くなったことを、大きなメリットとして挙げた。



以上で、KLabによる講演「Android向けUnity製ゲーム最適化のためのCI/CDと連携した自動プロファイリングシステム」の内容はすべて終了となる。

   

CEDEC2019公式サイト