メタバースプラットフォームにおけるSentryの導入と活用

導入検討された背景

メタバースプロジェクトの「ホロアース」ではサービスの品質向上のため、クライアントのエラー監視ツールを見直すことになりました。

当時の状況

プロジェクトの規模が大きくなるにつれ、エラーの発生頻度も増加し、ユーザーからの問い合わせも増えてきたため、エンジニアが能動的にエラーを監視し改善できる仕組みを作る必要がありました。

しかし当時クライアント側に導入していたエラー監視ツールでは、コストや機能面での制約があり、サービスの品質改善に活かすことが難しくなっていました。

技術的な課題

Unity/Web Frontend/Backendの統一的なエラートラッキングを行うために、現状サーバーのテレメトリデータを集約しているDatadogを使用したいと考えていましたが、以下の技術的制約がありました：

• Desktop UnityのSDKの対応状況：Datadogはモバイル版Unity向けのRUMを提供していますが、デスクトップ版や、WebGLのUnityビルドには対応していません
• Cloudflareにおける問題：Webフロントエンドの実行環境との互換性に課題がありました

そのため、クライアントのエラートラッキングに対してSentryを使用し、Datadog Integrationでエラーを集約することでエラー監視基盤を実現する方針としました。

• Backtrace
• Datadog
• New Relic
• Embrace

詳しくは以下の記事をご覧ください： https://zenn.dev/cover_corp/articles/fa3be55ecb1d78

以下の2点を重視して比較しました。

• 複数の動作環境で統合的にエラー監視ができること
• 管理者側のユーザー数が増えてもコストを抑えられること

• Unity向けのSDK/WebのCloudflare対応が公式に対応されており、動作環境が広いこと
• 管理者側のユーザー数に応じた課金がなく、純粋なエラー数の従量課金であること
• 各種IntegrationやTerraform等のIaC化が可能、他SaaSとの連携が容易であること

どのような成果が得られたか

現在では実際にユーザーが使用する環境にSentryが導入され、全てのクライアントエンジニアがSentryのエラーログを確認することができるようになりました。 これにより、リリースに対してSentryで検知したエラー修正が含まれるようになり、リリースの品質向上に寄与することができています。 鋭意改善中ではありますが、エラー情報のユーザー情報（端末など）と問い合わせとの紐付けやエラーのトリアージ運用を進めています。

コスト試算の難しさ

Sentryはエラー数に応じた従量課金制のため、単純に導入するとコストが想定を超える懸念がありました。そこで、既存ツールで取得していたエラー数を参考に、Sentry導入後のエラー発生数を予測し、コストを試算しました。

Unity実装の知見不足

UnityでのSentryの利用実績の情報が少なかったため、Unityエンジニアと協力しつつ、各種ビルドに組み込んでもらいテストを行いつつ進める必要がありました。

エラー通知設計

大量のエラーが発生することが予想されていたため、fingerprintによる集約と頻度別の通知設計を行い本当に必要なエラーのみをSlackへ通知するようにする必要がありました。

コストと機能のバランスが取れた非常に使いやすいツールです。WebのみならずUnityクライアントにも利用ができます。

エラー情報のユーザー情報（端末など）と問い合わせとの紐付けやエラーのトリアージ運用、クライアント・サーバを横断したSLI定義にも利用できるように監視基盤との統合を目指しています。