Unityのための高速かつクラウドネイティブな構造化ロギング及びテレメトリ収集基盤【DeNA TechCon 2022】

Unityのための高速かつクラウドネイティブな構造化ロギング及びテレメトリ収集基盤ゲーム事業本部ディベロップメント統括部技術部第8グループ大竹悠人(Haruto Otake)

今日持ち帰ってほしいもの • テレメトリがどのようなものか • モバイルゲームクライアントでテレメトリを実現することで何が得られるか • モバイルゲームクライアントでテレメトリをどうしたら実現できるのか

今日話すこと • モバイルゲームクライアントでのテレメトリはどのような課題を解決するか • それを満たすためには、どのような課題が存在するのか • 課題を乗り越えるためにどのようなシステム構成を採用したか • 実装上の工夫としてどのような事を行ったかモバイルゲームクライアント開発におけるテレメトリの要件と解決する課題
テレメトリ収集基盤を実際に実現する為に何をしたか • 何がしたいのか • テレメトリというものが何で構成されて、どのような役割を満たすのか • 実現のために、どのような手段が存在するのかテレメトリとはなにか

自己紹介 • 大竹悠人 (Haruto Otake) a.k.a @Trapezoid • 経歴
◦ 2009~2013 ドワンゴ ▪ サーバからクライアントまで、領域を問わない新規開発 ◦ 2013~ DeNA ▪ ブラウザやUnity製ゲームの新規開発/運用 ▪ 現在は横断部門から現場の技術的課題の解決をアシストする傍ら、 Unity用ライブラリ/SDK開発に従事

何がしたいのか? • テレメトリをモバイルゲームクライアントに持ち込むことで、モバイルゲームクライアント開発においてアプリケーションの状態の把握が必要な諸問題を解決したい

テレメトリとは何か、そしてなぜそれを持ち込むのか • 遠隔地にあるノード上で動作するアプリケーションの状態や環境情報を各々が自律的に取得し、通信によって一元化して管理/分析を行えるようにする手法 • ソフトウェアにおいては、主にLogs, Traces, Metricsという3種類のデータを取り扱うテレメトリとは何かなぜテレメトリを持ち込むのか
• モバイルゲームクライアントはまさに遠隔地にあるノードで動作するアプリケーション • アプリケーションの状態の把握が必要になる問題はモバイルゲームクライアント開発でも数多く存在する • 見えている問題ありきで解決するのではなく、既に整理された概念で問題を再定義することで、今後発生しうる同領域の問題を解決していく為の礎とする

テレメトリの構成要素 • 主に3つの視点からシステムを観測したデータによって構成される ◦ Logs ◦ Traces ◦ Metrics

Logs • システムから発行される、メタデータとタイムスタンプ付きのテキストレコード ◦ アプリケーションの処理中に直接埋め込む • 埋め込まれた場所で起きた出来事や、そこから見える状態を残していく
◦ 扱うものは非常に広範囲 • 一般に言うログと同義

Traces • システムのシーケンスを追跡するイベント ◦ 開始と終了のある区間で構成される ◦ 一つの区間はSpanとして表現される ◦ Spanは親となるSpanを持つことができる ◦
ルートとなるSpanに連なるSpan群がTrace • サーバーAPIのリクエスト/レスポンス, アプリケーション内のスタックトレース(の一部)など

Metrics • 実行時のシステムの状態を表す測定値 ◦ 可用性やパフォーマンスを評価する指標 • エラー率, 応答時間, スループット, CPU/メモリの
使用率など

各要素同士の連携 • Logs/Traces/Metricsの各要素を連携させるのが望ましい ◦ あるTraceの間に発行されたLogを特定する ◦ あるLogが発行された時のTraceを特定する ◦ Logから一部のMetricを分析する •
それぞれの発行時にIdを持たせる形で連携する ◦ どういう見せ方ができるかはSaaS次第

現代で取り扱われる高度なテレメトリ Structured Logging (構造化ロギング) • 単なるテキストでなく、オブジェクトとして表現できるような構造を持ったLog • 正規表現等ではなく、ログを構成するフィールドを使って分析ができる ◦ 直感的なフィルタリングや分類を行える
• GoogleのDapper論文に端を発する、分散システムにおける全体のシーケンスを可視化するようなTrace ◦ 複数のシステムを跨るシーケンスを、Traceに親子関係をもたせることで表現 ◦ 通信時に相手から現在のSpanをIDとして受け取り、それを親としたSpanを生成 • 分散システムのなかでどのシステムのどの箇所に時間が掛かったか/問題が起こったかを直感的に把握できる Distributed Tracing (分散トレーシング)

テレメトリの実現手段 • データを集積して分析するので、これを可能にするプラットフォームが必要 • GCPのCloud Logging/Trace/Monitoring, New Relic, Datadog等の多数のベンダがSaaSを提供している ◦
Logs/Traces/Metricsを統合的に扱って、収集から分析までを行えるものが多い • Grafana, Loki, Tempo等のOSSソフトウェアで構築することも可能だが、選択肢は少ないテレメトリを実現するプラットフォームテレメトリを実現するライブラリ • 各々のSaaSのSDKを利用すると、 SaaSやライブラリに対してベンダーロックされてしまうリスクがある ◦ ベンダ依存部分を抽象化したOSSを利用することで回避可能 • 抽象化を行うOSSはOpenCensus, OpenTracingの両プロジェクトが合流した OpenTelemetryが業界標準になりつつある

OpenTelemetry • テレメトリを行うためのオープンな共通仕様であり、実装 ◦ Logs,Traces,Metrics全ての計測、収集、エクスポートをカバーできる ◦ 様々な言語向けのライブラリ、プロトコル、パイプラインを構成するためのCollectorなどがある • 多くのクラウドベンダやテレメトリプラットフォームがOpenTelemetryへの対応を進めている ◦
とはいえまだ発展途上で、OpenCensus/OpenTracingからの移行期にある ◦ Loggingに関してはまだdraft及びbetaの段階。対応している実装もサービスも少なめ ◦ Traces, Metricsは仕様、実装共に概ねstable。対応している実装もサービスも豊富

テレメトリを実現することで解決する課題 • Editorやlogcat上でその場で確認するのに留まっていて、事後の確認が困難 • 大量のLogから見たい情報をフィルタリングする手段が少ない • 実機や他人の環境など、離れた場所でのLogを見ることが難しい • Logsの観測の実現によって解決可能出力されるLogをその場でしか活用できていない
• ゲームへのAIの応用のため、機械学習に必要なデータの出力を埋め込みたい ◦ テキストベースのLogから抽出するのは性能的にも保守性的にも問題が多い ◦ 収集できる環境を整える事自体が導入の大きな障壁になる ◦ 構造化されたデータ構造で、かつタイトル横断で使える枠組みが必要 • Logsの観測と構造化ロギングの実現によって解決可能機械学習等へのLogの応用が難しい

テレメトリを実現することで解決する課題サーバAPI呼び出しを含む複雑なシーケンスのボトルネックの分析が難しい開発中のフレームレート等のパフォーマンス低下を見過ごしやすい • サーバAPIの呼び出しはレイテンシが大きい為、可能な限り並列に呼び出してユーザの待ち時間を短くしたい ◦ 並列に呼び出しを行うと、単純なLogベースでは全容を把握することが非常に困難になる ◦ クリティカルセクションやボトルネックを特定するのが難しくなり、待ち時間の増加につながる •
Tracesの観測と分散トレーシングの実現によって解決可能 • 実行時のパフォーマンスは開発が進むにつれて低くなることが多い ◦ リリース後にも継続して機能追加を続けるモバイルゲームでは顕著 ◦ 属人的な観測ベースでは見過ごされて、深刻な問題になってから発覚する • Metricsの観測とオートパイロットテストのによって解決可能

モバイルゲームクライアントでテレメトリを実現するための要件テレメトリ計測によるパフォーマンス影響を可能な限り小さくすること • 特にメインスレッドを専有すると、ゲームの体験に影響を及ぼし、動作確認の精度を下げてしまう • 負荷を嫌ってテレメトリの計測自体を躊躇すると、本当に残したい情報を十分に残すことができなくなる • メインスレッドの負荷を避けつつ、高スループットも出せる必要がある不安定な環境でもフェイルセーフに動作すること •
クライアントは突然終了することがあり、終端処理を安全に行える保証がない • 通信環境も基本的には無線環境が前提で不安定 ◦ テレメトリの送信は失敗する可能性があるし、常時接続は常に前提にはできない ◦ ネットワーク接続は多くのリソースを消費する • テレメトリは突然アプリケーションが終了しても安全に記録でき、なるべく冪等性をもって再送信ができる必要がある

テレメトリを実現するための課題と要件モバイルゲームクライアントでテレメトリを実現する既存実装はほぼ無い • テレメトリプラットフォームも基本的にはサーバアプリケーションを主眼においているものが多い ◦ モバイルゲームクライアントに適合するものを選定する必要がある • ライブラリ側もOpenTelemetryや各SDKではモバイルゲームクライアントでの要件を満たせない ◦ ライブラリ側もサーバアプリケーションの利用がメインの想定で、アロケーションも多い
◦ 要件を満たすようなライブラリを新たに実装する必要がある

テレメトリ収集基盤の実現 • 何がしたいのか • テレメトリというものが何で構成されて、どのような役割を満たすのか • 実現のために、どのような手段が存在するのかテレメトリとはなにか

テレメトリ収集基盤の実現 • プラットフォームの選定 • テレメトリ収集基盤 Gretel ◦ 全体のアーキテクチャについて ◦ サーバ設計/実装について
◦ クライアント設計/実装について

プラットフォームの選定選定基準分析と開発の2用途を想定 • クエリ言語やWebUIに実用性があるか • 繋ぎこみが可能なAPIインターフェースを持つか • 想定する流量とAPI利用方法で繋ぎこんだ時に、サービスのQuotaや費用は許容範囲に収まるか •
選定自体はやり直せる想定で、一旦ベストなものではなく選びやすい順に適応できるかを考える指針 • 分析やAI活用は各々のプラットフォームではなく、BigQueryから全て取得できるようにする • 開発で活用するにはクエリができるだけでなく、可能な限り使いやすいコンソールが必要 ◦ 物量も需要も高いロギングでは特に重要

Logsの選定 • Google Cloud Loggingを選択 ◦ 様々な属性は勿論、Structured Logの内容でもフィルタ可能な強力なクエリ言語とWebUIを持つ ◦ DeNAのゲーム事業ではGCPを多く活用しており、気軽に採用もしやすい環境
• APIインターフェースやQuotaは十分要件を満たす ◦ 一度に複数のLogを書き出せるentries.writeというAPIが存在する ◦ entries.writeはプロジェクトあたり毎分120000回、1回10MBまで実行可能 • 分析用としてBigQueryにもミラーリングを行う ◦ LogSinkでGCP側で完結してBigQueryへ転送することも可能だが、利用しない ▪ 開発用と分析用のプラットフォームの選定の独立性を保つため ▪ 構造化ロギング時のスキーマ構成にも難がある ◦ Cloud LoggingへのInsertと並行して、BigQueryにもInsertを独自に行う

集積したログのCloud Loggingでの閲覧端末ID 重要度ログカテゴリクエリ

Tracesの選定 • Google Cloud Traceを選択 ◦ Cloud Loggingと連携が可能(Traceに関連するLogを直接表示したり、リンクを表示できる) • Quotaは十分要件を満たす
◦ 複数のTraceを書き出すPatchTracesがプロジェクトあたり毎分4800回、一回25000Spanまで実行可能 ◦ 1日あたりの 3,000,000～5,000,000,000 個のSpanを取り込み可能 ◦ Logsに比べてTracesは量も少ないので、必要十分と判断 • 分析用としてBigQueryにもミラーリングを行う ◦ TraceSinkでGCP側で完結してBigQueryへ転送することも可能だが、構築の自動化が複雑になるうえLogs/Metricsとの統一性も無くなるので、同様の方法を取ることに

Metricsの選定 • Cloud Monitoringの利用を検討したが、サーバ監視用の為いくつか致命的な問題が見つかり、断念 ◦ 計測した値同士に5秒以上の間隔が必要 ◦ APIからは時系列毎に1つのデータしか書き込めない為、バッチ処理が不可能 • BigQueryのみを利用することを選択
◦ 開発に使いやすいUIあるとは言い難いが、他に比べて開発で閲覧する要求は低かった ▪ データを取って分析を可能にすることをまずは優先する ◦ 必要に応じてDataStudioやGrafanaによる可視化を検討する

テレメトリ収集基盤 Gretel • Game-client REvolutionary TELemetry • Unityで作られたモバイルゲームクライアントのテレメトリ収集を行うDeNAの社内システム/ライブラリ ◦ 開発時のテレメトリ収集をファーストターゲットとしている
• Unity及び.NET6向けのクライアントライブラリと、.NET6向けのサーバによって構成 • Logs/Traces/Metricsの三種のテレメトリを低いベンダーロックリスクで全てサポート • モバイルゲームクライアントでの利用に耐える高速なランタイムパフォーマンス • オートスケールするクラウドネイティブなインフラ構成 • terraformによる環境構築の自動化

Client/Server型と中間フォーマットの採用 • クライアント側でテレメトリの全ての処理を行わず、中間フォーマットで出力し、サーバ側に転送する • サーバ側で中間フォーマットのデータのパースと変換を行った上で、プラットフォーム側に登録する • サーバにベンダーロック部分や重い処理を移譲クライアント実装を
ベンダーロックから開放しつつ処理負荷を低く抑えられる

サーバ及び中間フォーマットの設計方針クラウドネイティブな構成にする高速化を優先しつつ、OpenTelemetryの仕様を手本にする • 安価かつメンテナンスフリーに、開発規模に依らないでスケールさせたい • 回収できるデータの規模がサーバが理由で制限されることがなくなる • 今後として、プロダクションでのテレメトリ回収も視野に入れられる •
OpenTelemetryは実装だけでなく、各テレメトリが満たすべき仕様も定義している ◦ 積み重ねられた知見を取り込める • 中間フォーマットをOpenTelemetryを参考にする ◦ OpenTelemetryの仕様に落とし込めるような仕様にする ◦ 業界標準なので、有用なプラットフォームが現れたときの移行が簡単になる

Gretelの全体アーキテクチャ • クライアントは計測したテレメトリを中間フォーマットで出力しファイルシステムに保存 ◦ 基本的にファイルに追記し、随時Rotate • 保存されたテレメトリを定期的にサーバ側(Exporter) で処理できるように送信 ◦
シーン遷移時など ◦ 起動時には、前回終了時に送っていないデータを送信 • Exporterは送信されてきた中間フォーマットのテレメトリを読み取り、各々のプラットフォームのAPIが要求する形式に変換してExport

中間フォーマットの策定 • OpenTelemetryのgRPCによるプロトコル(OTLP)の定義を元に中間フォーマットを策定 ◦ テレメトリはどのような属性を持つべきなのか、という知見がOTLPには詰まっている ◦ あくまで速度重視で、直接OTLPを採用はしない ◦
Logs/Traces/Metrics全てに定義されている • ワイヤフォーマットとしてMessagePackを採用 ◦ MessagePack for C#が非常に高速 ◦ フォーマットはスキーマレスなので柔軟な運用が可能 • ヘッダによるシリアライズ量の削減 ◦ Headerのあとに任意の個数のデータを順に書いていく ◦ データ間で共通するデータはHeaderに保持する ▪ 共通タグや任意のIDなど ◦ Headerが変化した場合、ファイルを新しく作る ◦ アプリケーションの中断に強いフォーマットになる • Logs, Metrics, Traces全ての中間フォーマットに同様の構造を採用

サーバ設計 • サーバはGCPのサービスを使って構築 ◦ Cloud Storage ◦ Cloud Run ◦
Cloud Tasks ◦ Cloud Functions • 常時起動するサーバを持たず、負荷に合わせてオートスケールするServerless構成 ◦ 全て従量課金になり、安価に導入できる完全にServerlessでクラウドネイティブな構成を実現

サーバ設計 1. クライアントから送られる中間フォーマットのテレメトリはCloud StorageにPUTされる ◦ 署名付きURLでPUTを利用 2. Cloud Storageの更新をTriggerにCloud
Functions を起動し、Cloud Tasksにキューを積む ◦ Cloud FunctionsのTriggerはat least once なので重複の可能性をここで排除 ◦ エラー時の一定のリトライも行う 3. Cloud TasksがCloud Run上のExporterを起動 ◦ Cloud TasksのHTTP Targetを用いる ◦ 受け取った中間データを前処理した上で各々の形式に変換して、バックエンドに Insert

サーバ実装 • C#(.NET 6, ASP.NET)で実装 ◦ クライアントとの間でスキーマ定義を含むコアロジック(Gretel.Core)を共有 • System.Threading.Channelsによる並列化とバッチ化
◦ ParseとConvert/Exportを並列実行 ◦ 一定の件数までConvertした時点でExportを実行するバッチ化を施し、Exportする件数を固定 ◦ APIアクセス中にCPUをできるだけ遊ばせない

BigQueryでのNative JSON DataTypeの利用 • 構造化ログやタグ情報は共通したスキーマのない、Dictionary的な構造を持つ ◦ これを扱うにはBigQueryでもダイナミックなスキーマが必要 • BigQueryはカラムを足していく事もできるが、フィールド名が同じで型が違うログが存在した場合に書き込みができない上、カラムを消せない
• 先日パブリックプレビューになった、BigQueryのNative JSON DateTypeを利用 ◦ JSONの値をフィールドやクエリの中で扱えるようになる、BigQueryの新たなプリミティブ型 ◦ 文字列との相互変換は勿論、JSON PathでJSON型の値から内包する値を抽出することもできる ◦ スキーマ定義上でJSON型として宣言することでJSONとしてValidな値しか入らなくなる ◦ 該当するフィールドに文字列としてJSONを与えることでInsertはそのまま行える • 構造化ログやタグ情報の柔軟な運用を安全に行える

terraformによるプロビジョニング • ゲームタイトル毎に完全に分離された環境を用意したい ◦ terraformによってInfrastructure as Codeを実践 ◦ タイトル毎の独立した環境構築が容易に可能 •
サービスアカウントの切り分けによるアクセス制限 ◦ クライアントからテレメトリをCloud Storageにアップロードする専用のサービスアカウントを自動的に作成し、組み込むJSONをファイルとして出力 ◦ 他の権限を与えないことで、ビルドに認証用JSONを組み込む際のリスクを低減

クライアントの実装方針 • 頻度もデータ量も多いLogsを最も優先 • Metricsも毎フレーム単位で実行するため次点で優先 • Tracesはデータ量は場合によって多いものの、頻度は非常に低いので優先度は最低に ◦ 速度が問題になったらLogsと同様の戦略を取るパフォーマンスは呼び出し頻度やデータ量を考えて優先度をつけて対応する
テレメトリに隣接する既存の実装や標準を活かす • .NETのテレメトリAPIインターフェースであるSystem.Diagnostics.DiagnosticSourceに対応 ◦ System.Diagnostics.Metricsはかなり薄い実装なので、参考にするのみ • ZLoggerをベースに利用して、魔改造して実装する ◦ C#でGeneric Hostベースで超高速なLoggerを実現する、@neueccさん発のOSS ◦ 目指す物が非常に似ていて、下回りの実装はLogs以外の実装にも活用できる ◦ 一方で、ZLoggerはテキスト出力が主眼な為拡張する形は難しい

Logs : クライアント設計 • 高パフォーマンスの実現のための全体の構造は ZLoggerのものと殆ど変わらない • System.Threading.Channelsでのサブスレッド化 ◦ ChannelによってLogEntryを書き込み、サブス
レッド上からそれを読み出す ◦ サブスレッド上でシリアライズ ◦ メインスレッドは殆どメモリコピーしかしない • LogEntryのPooling ◦ 型引数毎にLogEntryをPoolingして実質的なゼロアロケーションを実現 ◦ LogEntryはGenericに実装することで、その先の実装が高効率に多態的に振る舞えるようにする

Logs : ZLoggerとの差分 • テレメトリの中間フォーマットでの出力 ◦ ZLoggerではZStringでテキストとして書き出す部分を、MessagePack for C#でバイナリとして
書き出す ◦ ZLoggerでは扱わないメタ情報を付加 ▪ Attributes, Trace, ◦ 任意のサイズに至るかヘッダが変化したら、ログファイルを自動的にローテーションしてヘッダを書き出す • 拡張メソッドで実現されるLogging Methodの構造 ◦ ILoggerではなくwrraperとなるstructに対する拡張メソッドに変更 ▪ ILogger.Logが直接呼ばれると多くの情報が失われてしまうので、その回避策 ◦ Conditional属性でリリースビルド時に (特定のシンボルを定義してなければ)呼び出し自体が消去が行われるメソッドも定義

Logs : ZLoggerとの差分 • MessagePack for C#による構造化ロギングへの対応 ◦ ZLoggerは構造化ロギングにSystem.Text.Jsonを使うため、Unityでは構造化ロギングは非対応
◦ MessagePack for C# によって構造化ログのシリアライズを行うようにする • 文字列フォーマット(string.Format)処理のサーバへの移譲 ◦ ZLoggerはZStringを使うことで文字列フォーマット処理を高速化している ◦ 文字列フォーマット自体をクライアントで行わない ◦ フォーマット書式とフォーマット引数をそのまま MessagePackにシリアライズする ◦ 文字列フォーマットはサーバ側でパース後に行う

Logs : ロギングの呼び出し • 様々なパラメータを渡せる ◦ LogLevel(ログの重要度) ◦ EventId(ログの種別) ◦
Payload(構造化ログを表すオブジェクト) ◦ Attribute(属性を表すオブジェクト) ◦ Message (テキストログのフォーマット文字列) ◦ Args(テキストログのフォーマット引数) ◦ ActivityContext(ログ出力時のTrace) ◦ CallerInfo(呼び出し元ファイル名/行数/関数名) • CallerInfo属性によるロギング時のコードパスの記録 ◦ StackTraceの取得は非常に重いが、 Logからコードパスを辿れることは非常に有用 ◦ Caller(FilePath/LineNumber/Member)属性を関数の省略可能な引数に付ける ◦ 呼び出し元のファイルパス/行数/メンバ名がコンパイル時に埋めこまれる ▪ 限定的だが低コストでコードパスを残せる

Logs : ロギングのバリエーション • 場合によって省略したいパラメータも存在する ◦ 複数のメソッド名とオーバーロードの両面でバリエーションを持たせる • メソッド名のバリエーション
◦ ユースケースレベル ◦ Release~/Debug~ ▪ Conditional属性による呼び出し除去 ◦ ~LogExeption~ ▪ 例外(Exception)の記録 ◦ ~LogMessage~ ▪ Payloadを伴わないテキストログ ◦ ~WithAttribute ▪ ログ個別のAttributeの指定 • オーバーロードでのバリエーション ◦ EventIdの省略(構造化ログの型からEventIdを自動決定)

Logs : オーバーロードの衝突 • フォーマット引数部は複数の型引数を持つ ◦ 引数の数ごとにオーバーロードを定義 ◦ 高速化の為にも必須の構造 •
複数の型引数でのオーバーロードの定義と、デフォルト引数は非常に相性が悪い ◦ 呼び出し時に型引数を推論させてのオーバーロード解決ができず、使いづらくなる • フォーマット引数部をまとめてValueTuple化 ◦ 1引数にまとまるので、隣接する引数と干渉しない ◦ Tupleリテラルを使える上、型推論が可能 ◦ Tupleリテラル(x,y,z)は1引数では使えないが、1引数では無駄な丸括弧になる ◦ 1引数の時だけValueTupleを使わないで定義すると、呼び出し側の記述を統一でき、推論上の問題も解決

Logs : 非対称なシリアライズ • 構造化ログはログ種別毎にC#の型を定義して扱いたい ◦ 扱いやすい上、事前生成されるパフォーマンスの高い実装を利用できる • サーバではクライアントのスキーマを把握しなくても
パースできるようにしたい ◦ 変更毎にスキーマのデプロイが必要になると、並行開発に耐えるアジリティを実現できない • クライアントではスキーマベースにシリアライズして、サーバではスキーマレスにパースする ◦ MessagePackはJSON同様のスキーマレスなファイルフォーマット ▪ Mapモードでスキーマを利用すれば、C# のプリミティブ型によるDictionaryとして Parseすることが可能 ◦ DictionaryをJSONや各SDK側で要求される構造体を表す型に変換して最終的に利用する

Logs : UnityEditor用のLog Console • 特にLogsに関しては、UnityEditorからリアルタイムに確認できることが実用上求められる ◦ UnityEditor上にUIToolkitを用いて専用のLog Consoleを実装
◦ 数十万件のログ表示も高速に処理可能 • コンソールに必要な一通りの機能を完備 • ログの表示 ◦ フィルタ機能付きのリスト表示 ◦ ログごとの詳細表示 • フィルタ機能 ◦ LogLevel, EventId, LogNameによる複数選択可能なフィルタ ◦ Message,Payload,StackTrace,Caller, TraceId,SpanIdでの文字列一致フィルタ ▪ Messageはハイライト付き • 新規ログへの自動スクロール(Tail) • Editor Preview開始時の自動クリア(Clear on Play)

Logs : UnityEditor用のLog Consoleの実装 • 前述のLogConsoleに対してログを出力する実装 ◦ Loggerからの出力先の一つとして構成可能 ◦ 必要に応じてStackTraceを残すことも可能
• Editor上でTCPでTLVベースの独自プロトコルの Consoleサーバを実装し、フロントエンドから転送 ◦ 実機ビルド時でもLogConsoleが利用可能 ◦ 中間フォーマットのデータを転送 ◦ Editorのドメインリロード時にListenし、受信したログがEditorWindow上に表示 ◦ EditorPreviewではlocalhostに接続する • ファイル出力時と同様にサブスレッド化 • USB接続された実機とPC間のTCP通信の経路を担保 ◦ TechCon2020での講演で紹介したdevwire によるリバースポートフォワード over USB ◦ もちろんWiFiなども経路として利用可能

Logs : マーケティング分析ログの送信 • プロダクション環境において、マーケティング分析用のログを出力する ◦ マーケティング分析用のログは、社内mBaaSであるLCXを通して扱うように現状の社内基盤は整っている ◦ LCX SDKを通してログを出力するように、Loggerの出力先の一つとして構成可能
◦ プロダクションの分析ログも開発のログの間での実装方法の差分を最小化できる • 中間フォーマットでの出力を行わない ◦ ログエントリをLCX SDKが要求する形式にコンバートし、SDKを通して直接送信する ◦ 送信頻度は高くないため、パフォーマンスはあまり問題にはならない

Traces : クライアント設計 • System.Diagnostics.DiagnosticSourceのActivitySourceを利用 ◦ StartActivityからその返り値のActivityをDisposeするまでの区間がTraceとして処理される ◦ ActivityのContextプロパティをStartActivity時に与え
ることで、Traceの親子関係を設定できる • Activityの開始や終了はActivitySourceを通じて監視できる ◦ これを利用して終了時にTraceとして記録する ◦ シリアライザ以下の出力部分の実装はLogsのものを共用して、ローテーションを実現 • ゲーム向けのActivity管理を実現するActivityStackを実装 ◦ ActivitySourceは親が無指定の場合、AsyncLocalな状態に基づいて直近のActivityを自動的に親に設定する ◦ コールスタックに紐付いたTraceを残すには合理的 ◦ ゲームはコールスタックを超えた状態が殆どなので、これを無視できるStack型の管理機構を実現する

Traces : 分散トレーシングの実現 • 分散トレーシングを実現して、ゲームサーバとの通信内容,タイミングをTraceに残しつつ、クライアントとサーバのボトルネックを一気通貫で分析する • DeNAの社内ゲームサーバ基盤(Takasho)との連携 ◦
gRPC/OpenCensus/Cloud Traceという構成 • OpenCensusのgRPC向けの実装では、リクエストの grpc-trace-binヘッダをパースして親のTraceとして解釈するようになっている • Takasho SDKを拡張して透過的に分散トレーシングを実現するインテグレーション層を実装 ◦ Takasho SDKにインテグレートして、リクエストとレスポンスを自動的にTraceに残す ◦ 作成中のTraceのIDをgRPCリクエストの grpc-trace-binヘッダとして埋め込む ◦ Takashoサーバ側は何も変更をすることなく分散トレーシングを実現できたクライアント側Trace サーバ側 Trace

Metrics : クライアント設計 • System.Diagnostics.Metricsの設計を下敷きに独自実装 ◦ 計測項目ごとのInstrumentとそれを追跡するMeter • Instrumentに対して必要な間隔で測定した値を Reportして蓄積し、定期的にFlush
• 値そのものではなく分布として集計するHistogram ◦ fpsなどの瞬間的なスパイクを逃したくないもの • 時間あたりの値を計測するCounter ◦ リクエスト数, GC発生数など • その瞬間の値を計測するGauge ◦ メモリ使用率など

Metrics : ヒストグラムの逐次処理 • 瞬間的にスパイクが考えられる値は統計的に処理したい ◦ 値をすべて報告するとデータ量が膨大になる ◦ データ量に比例しない計算量で統計処理を行いたい •
Bucketベースのヒストグラム計算を採用 ◦ 任意の区間で標本化を行う ◦ N個の昇順の境界値で区切ったN+1個の区間(Bucket) の単位に標本化して、分布(それぞれの個数)を記録 ◦ Bucketに属するかを求めてカウントをインクリメントするのみで、計算量がデータ量に比例しない(O(1)) ◦ Sum/Min/Max等のO(1)で計算可能な項目も計算 ◦ 区間を求めるロジックはBurst化 • 分布の状態で中間フォーマット化 ◦ 分布とBucketの閾値を送信 ◦ サーバー側で分布から%tileを必要に応じて計算 ◦ 分布情報のまま受け入れるプラットフォームが数多く存在する

シリアライズ処理上の工夫 • 高速化や仕様の柔軟性のために、Gretelのシリアライズ処理ではさまざまな実装上の工夫を盛り込んでいる

任意の型を含む多態性のあるシリアライズ • 構造化ログで任意の型を与える部分はログ情報のスキーマの一部でしかない ◦ MessagePack.Unionによる動的なシリアライズを行うには、interface側に全ての任意型を列挙する必要がある ◦ フォーマット文字列のパラメータの配列も任意
の型が入りうるので同様 • MessagePack for C#のUnionやMessagePackSerializer は使わず、Low Level APIを利用 ◦ MessagePackWriterで要素数をヘッダとして書き込み、続いて要素の内容を順に書き込む ◦ 型を任意にしたい部分を型パラメータと共に受け取り、Formatterを取得してシリアライズ ◦ T4でパラメータ数毎にオーバーロードを実装 • サーバ側からはスキーマレスに扱う ◦ Dictionary<string,object>やobject[]にパース

Formatterの高速化 • 任意の型のシリアライザをFormatterを独自に実装することで、EventId,TraceId等の既存の構造体を直接扱う ◦ ResolverでそのFormatterの参照を得られるようにする必要がある • MessagePackFormatter属性をフィールドに指定して、利用するFormatterを明示的に指定する
◦ Formatterの解決を省略できる ◦ 実体型でのnonvirtualなメソッド呼び出しは IL2CPP後にvtableを経由しないので高速 ◦ 独自のFormatterでAggresiveInliningを指定すしている場合、inline化も可能 • Nullableの場合も上記のvtable回避/inline後を誘発させる ◦ Genericsの実装共有の関係で、Formatterも値型であることが条件になる

UTF16文字列のシリアライズ • MessagePackの文字列はUTF8 ◦ C#のstringはUTF16なため、シリアライズ時にUTF8に変換された上で書き込まれる ◦ できればこのコストも回避したい • UTF16のままbyte列としてstringを書き出すFormatterを実装
◦ MessagePackのextフォーマットとして書き出す ◦ 任意のTypeCodeと共に任意のbyte列を独自のフォーマットとして組み込めるMessagePackの仕様 • サーバ側では個別のFormatterによる解決が期待できない ◦ object型用のFormatterを通してデシリアライズする必要があるため、標準のFormatterをforkして改造 ◦ 上記の独自フォーマットをstringとしてデシリアライズできるようにする ◦ MessagePackバイナリからJSON変換を行う際にも同様の改造が必要

達成できたパフォーマンス • 300件/frame,60fpsで1000frameの間Android(GalaxyS9) でログ出力するパフォーマンステスト(Unity 2020.3.28f1) ◦ UnityEngine.Debug.LogFormat, ZLoggerとの間で 1frame中のLogのメインスレッド専有時間を比較 ◦
3パラメータの文字列フォーマットを伴うLog ◦ Gretelでは文字列フォーマットと同時に構造化ログも出力する際のパフォーマンスも計測 ◦ Gretel, ZLoggerはテスト後のサブスレッド側の残処理の所要時間も比較(LoggerFactoryのDispose) • 結果 ◦ メインスレッド負荷はDebug.LogFormat比で1/200 ◦ 現実的な密度で構造化ロギングを行ってもリアルタイム処理が可能

• リアルタイム処理できるスループットを追試 ◦ 実機での構造化ロギングで400~500件/frame ◦ 実機での通常ログで2000~3000件/frame ◦ 実機でのZLoggerで3000~4000/frame • Editorではいずれも4000件/frameも捌いた
• 通常ログではZLoggerと遜色ないパフォーマンスを発揮 • ログを過不足無く残すには十分に超高速と言えるパフォーマンスを達成した

達成したこと • モバイルゲームに対して、サーバ分野でメジャーになったテレメトリの概念を持ち込む基盤を実装した ◦ ミクロな実装では高いパフォーマンスを実現するナイーブな実装を行いつつ、マクロなアーキテクチャでは柔軟性とスケーラビリティを両立するクラウドネイティブな構成にできた • 仕様面ではOpenTelemetry、実装面ではMessagePack for C#,
ZLoggerといったOSSを活用することで、規模に対して短い期間で実装しきることができた ◦ 構想から完成まで、全体で概ね2人月程度 • アプリケーションの状態の把握という領域で生じる諸問題に対して、解決の見通しを立てることが出来た

これからの展望 • 基盤が完成したばかりで、まだ実際のゲームタイトルに組み込めていない ◦ 組み込んで利用実績を積み、フィードバックを得て、実用上の問題点をシューティングしていくのを優先 • .NET Standard 2.1 /
Unity 2021.2への対応 • 開発利用のためのプラットフォーム選定に関しては、それぞれの進歩を加味して選択肢を適宜再考していく ◦ サーバ側にOTLP Exporterを実装すれば幅広い選択肢が取れる。特にMetricsは再考の余地あり • (記録の粒度を下げた上での)プロダクション環境での利用のための実装 ◦ 利用者全体でなく、同意を得た上で一定割合でのみ計測する必要がある ◦ サーバサイドでユーザ認証及びQuotaを設ける等のセキュリティ強化 • 社内の技術資産との連携の推進 ◦ リアルタイムサーバとの分散トレーシング ◦ 様々な内製開発用ツールの利用統計のLogsとしての記録

謝辞・注釈 • 本講演のプロダクトはMessagePack for C#, ZLogger, ZStringに大きく助けられて成立しています ◦ @neuecc 様
並びにCysharp社様、いつも素晴らしいOSSをありがとうございます! • このスライドは、CNCFと提携しておらず、CNCFが後援しているものでもありません。 (This slide is not affiliated with or otherwise sponsored by CNCF.)

Thank you for your listening!

Unityのための高速かつクラウドネイティブな構造化ロギング及びテレメトリ収集基盤【DeNA ...

Unityのための高速かつクラウドネイティブな構造化ロギング及びテレメトリ収集基盤【DeNA TechCon 2022】

More Decks by DeNA_Tech

Other Decks in Technology

Featured

Transcript