Upgrade to Pro — share decks privately, control downloads, hide ads and more …

フロントエンドオブザーバビリティ on Google Cloud

フロントエンドオブザーバビリティ on Google Cloud

Avatar for Yunosuke Yamada

Yunosuke Yamada

March 07, 2025
Tweet

More Decks by Yunosuke Yamada

Other Decks in Programming

Transcript

  1. 本日の内容 主に話すこと - フロントエンド(というかブラウザサイド)のテレメトリを、 監視にGoogle Cloudを利用している場合にどのように収集するか - 最近はNext.jsなどでサーバーサイドのフロントエンドもあるが そちらは普通に取れば良いため -

    テレメトリは今回はログ、トレース、メトリクスを対象とします。 少しだけ話すこと - フロントエンドにおけるオブザーバビリティとは何か - どんなテレメトリを収集すると良いか 4
  2. フロントエンドにおけるオブザーバビリティ フロントエンドでオブザーバビリティを高めるにあたって、 いくつかのマイルストーンがあると考えています。 1. アプリケーションが正常に動作すること a. エラーが出ていないか 2. アプリケーションが素早く動作すること a.

    描画や動作が遅くなっていないか 3. アプリケーションを快適に利用できること a. ユーザが操作に迷っていないか これらを知るためにはフロントエンドのテレメトリが必要です。 フロントエンド監視の全体像と実現方法 5
  3. テレメトリとして何を取るか - ログ - ロジックについてはバックエンドと同じようなログ - 例外 - トレース -

    API呼び出し - メトリクス - パフォーマンス:Core Web Vitals - 地理位置情報:IP Geolocation, Geolocation API - デバイス:Navigator.connection, Navigator.deviceMemory, Navigator.hardwareConcurrency, innerHeight, innerWidth などが必要と考えています。 フロントエンドで収集するべきテレメトリは何か 6
  4. Datadogの場合 Datadogではブラウザログ収集とReal User Monitoringがあります。 どちらもクライアントトークンをフロントエンドアプリケーションに埋め込み、 Datadogに送信する仕組みになっています。 Browser Log Collection Browser

    Monitoring Client-Side Instrumentation 10 import { datadogLogs } from '@datadog/browser-logs' datadogLogs.init({ clientToken: '<DATADOG_CLIENT_TOKEN>', site: '<DATADOG_SITE>', forwardErrorsToLogs: true, sessionSampleRate: 100, })
  5. API - ログ:Cloud LoggingのAPI - POST https://logging.googleapis.com/v2/entries:write - 権限:logging.logEntries.create -

    トレース:Cloud TraceのAPI - POST https://cloudtrace.googleapis.com/v2/{name=projects/*}/traces:batchWrite - 権限:cloudtrace.traces.patch - メトリクス:Cloud MonitoringのAPI - POST https://monitoring.googleapis.com/v3/{name}/timeSeries - 権限:monitoring.timeSeries.create 事前定義ロールは使わずカスタムロールに上記の権限を設定する形 15
  6. 注意 SAキーをフロントエンドで持つのは、Google Cloud的にはバッドプラクティスです。 - キーを含むJSがブラウザに配信されるため またSAキーは公開されているのが検知されると、デフォルトでは無効化されます。 - どのような場合に検知されるかは非公開? - 今回のサンプルアプリでは公開までは試していないため実際どうなるかは未検証です。

    - 公開を検知しても悪影響があるまで無効化しないオプションもあります。 Restricting service account usage | Resource Manager Documentation | Google Cloud Google CloudにはAPIキーもあり、こちらは利用するAPIとアプリケーションに 制限をかけられますが、今回利用するAPIには対応していません。 16
  7. 方法2-2:リバースプロキシで認証している場合 - Cloud IAPで認証している場合 - nginx-ingressでauth-urlを使っている場合 などが該当します。 認証できたら、Google Cloudに転送する -

    Cloud IAPの場合、LBと組み合わせる - nginx-ingressの場合、kind: Service, type: ExternalName など(未検証です) もう少し一般化すると2-1も2-2も、通常のリクエストと同じ場所で認証して、 OKだったら転送する方法と言えます。 19
  8. まとめ - フロントエンドはユーザが直接触れるものなのでオブザーバビリティは重要 - OTelなどの一般的な方法はブラウザJSではまだ成熟していない。 - 監視SaaSのフロントエンド監視機能は、トークンやキーを埋め込み、 直接送信する形で実現されている。 - この方法をGoogle

    Cloudで採用することは可能だが、 一般的にはバッドプラクティスであることを認識すること。 - セキュリティが重要な場合には、通常のリクエストと同様の認証をかけ、 Google Cloudに転送する方式になると思われる。 20