Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンドオブザーバビリティ on Google Cloud
Search
Yunosuke Yamada
March 07, 2025
Programming
0
210
フロントエンドオブザーバビリティ on Google Cloud
Yunosuke Yamada
March 07, 2025
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
200
ChatGPTのアルゴリズム
yunosukey
0
360
React and XSS
yunosukey
0
290
DB Tree Algorithms
yunosukey
0
96
Tests in Go
yunosukey
1
110
Bugless Code
yunosukey
0
130
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
260
Other Decks in Programming
See All in Programming
Being an ethical software engineer
xgouchet
PRO
0
220
Jakarta EE Meets AI
ivargrimstad
0
290
大LLM時代にこの先生きのこるには-ITエンジニア編
fumiyakume
7
3.1k
Ruby on Railroad: The Power of Visualizing CFG
ydah
0
210
AIコーディングの理想と現実
tomohisa
32
35k
Optimizing JRuby 10
headius
0
490
Laravel × Clean Architecture
bumptakayuki
PRO
0
110
Orleans + Sekiban + SignalR でリアルタイムWeb作ってみた
tomohisa
0
130
小田原でみんなで一句詠みたいな #phpcon_odawara
stefafafan
0
350
The Evolution of the CRuby Build System
kateinoigakukun
0
720
State of Namespace
tagomoris
4
2k
PHPで書いたAPIをGoに書き換えてみた 〜パフォーマンス改善の可能性を探る実験レポート〜
koguuum
0
180
Featured
See All Featured
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Optimising Largest Contentful Paint
csswizardry
37
3.2k
Music & Morning Musume
bryan
47
6.5k
Bash Introduction
62gerente
611
210k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Practical Orchestrator
shlominoach
187
11k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Unsuck your backbone
ammeep
670
57k
Statistics for Hackers
jakevdp
798
220k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
It's Worth the Effort
3n
184
28k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.2k
Transcript
フロントエンドオブザーバビリティ on Google Cloud Jagu'e'r オブザーバビリティ分科会 Meetup#1 株式会社スリーシェイク 山田悠之介 Copyright
© 3-shake, Inc. All Rights Reserved.
自己紹介 - 名前:山田悠之介 - 所属:株式会社スリーシェイク Sreake事業部 - 職種:フルスタックエンジニア - Webアプリのフロントエンド、バックエンド、
生成AIアプリの開発とその支援 - 趣味:筋トレ - 週4ほどBIG3を中心に 2
モチベーション フロントエンドの監視は、バックエンドやインフラと比べ、優先度が低くなりがち。 - バックエンド/インフラの障害はサービス継続に影響しやすい - コンピューティングリソースをサービス提供側で管理していない しかしフロントエンドはユーザが直接触るものであり、 そこで何が起きているか知ることは重要なはずです。 3
本日の内容 主に話すこと - フロントエンド(というかブラウザサイド)のテレメトリを、 監視にGoogle Cloudを利用している場合にどのように収集するか - 最近はNext.jsなどでサーバーサイドのフロントエンドもあるが そちらは普通に取れば良いため -
テレメトリは今回はログ、トレース、メトリクスを対象とします。 少しだけ話すこと - フロントエンドにおけるオブザーバビリティとは何か - どんなテレメトリを収集すると良いか 4
フロントエンドにおけるオブザーバビリティ フロントエンドでオブザーバビリティを高めるにあたって、 いくつかのマイルストーンがあると考えています。 1. アプリケーションが正常に動作すること a. エラーが出ていないか 2. アプリケーションが素早く動作すること a.
描画や動作が遅くなっていないか 3. アプリケーションを快適に利用できること a. ユーザが操作に迷っていないか これらを知るためにはフロントエンドのテレメトリが必要です。 フロントエンド監視の全体像と実現方法 5
テレメトリとして何を取るか - ログ - ロジックについてはバックエンドと同じようなログ - 例外 - トレース -
API呼び出し - メトリクス - パフォーマンス:Core Web Vitals - 地理位置情報:IP Geolocation, Geolocation API - デバイス:Navigator.connection, Navigator.deviceMemory, Navigator.hardwareConcurrency, innerHeight, innerWidth などが必要と考えています。 フロントエンドで収集するべきテレメトリは何か 6
どのようにテレメトリを取るか:バックエンドの場合 Google Cloudの各コンピューティングサービスについて、 テレメトリを収集する推奨方法がドキュメンテーションされています。 Choose an instrumentation approach | Google
Cloud Observability 大体OTel SDKかPrometheusのクライアントライブラリが推奨されています。 しかし...... 7
どう取るか:バックエンドの場合 どちらもフロントエンドでは成熟していません。 - OTel SDK JavaScript | OpenTelemetry - Prometheusクライアントライブラリ
JS/TS未対応 Client libraries | Prometheus 別の方法を考える必要があります。 8
監視SaaSの場合 Datadog、New Relic、Sentryなどの監視SaaSにはフロントエンド監視の機能があります。 これらのサービスでどのように実現しているか見てみます。 9
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, })
New Relicの場合 New Relicではブラウザエージェントを追加する形でフロントエンド監視を有効にします。 Install the browser agent | New
Relic Documentation アプリにIDやキーを埋め込む形になっています。 11
Sentryの場合 クライアントライブラリ経由でブラウザから送信します。 初期化時にパブリックキーを指定する形です。 Sentry for React 12 import * as
Sentry from "@sentry/react"; Sentry.init({ dsn: "https://
[email protected]
/0", ... });
ここまでのまとめ - OTel SDKやPrometheusクライアントライブラリなど、 バックエンドで推奨されている方法はブラウザJSではまだ微妙です。 - フロントエンド監視を提供する各監視SaaSでは、 トークンやキーを埋め込み、直接送信する形で実現しています。 - トークンなどを含むJSがブラウザに配信されるため、露出する形
- 権限は制限されている - 汎用的なやり方がこれしかないためと考えられます。 13
Google Cloudでどうやるか:方法1 監視SaaSのやり方を真似ます。 - 最低限の権限を持つサービスアカウントを作成し、キーを生成 - キーをフロントエンド側に持たせて、Google CloudのAPIをコール サンプルコード https://github.com/YunosukeY/frontend-o11y-on-gcloud
14
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
注意 SAキーをフロントエンドで持つのは、Google Cloud的にはバッドプラクティスです。 - キーを含むJSがブラウザに配信されるため またSAキーは公開されているのが検知されると、デフォルトでは無効化されます。 - どのような場合に検知されるかは非公開? - 今回のサンプルアプリでは公開までは試していないため実際どうなるかは未検証です。
- 公開を検知しても悪影響があるまで無効化しないオプションもあります。 Restricting service account usage | Resource Manager Documentation | Google Cloud Google CloudにはAPIキーもあり、こちらは利用するAPIとアプリケーションに 制限をかけられますが、今回利用するAPIには対応していません。 16
Google Cloudでどうやるか:方法2 フロントエンドからの通常のAPI呼び出しと同様に認証をかけるやり方が考えれられます。 どこで認証をしているかによって大きく2つに別れるかと思います。 1. アプリケーションサービス内で認証している場合 2. リバースプロキシで認証している場合 17
方法2-1:アプリケーションサービス内で認証している場合 - バックエンドで認証している場合 - Next.jsなどを使っておりServer Actionsで認証している場合 などが該当します。 サーバーサイドに一旦送って認証した後、 そのままGoogle Cloudに転送すれば良いと思います。
18
方法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
まとめ - フロントエンドはユーザが直接触れるものなのでオブザーバビリティは重要 - OTelなどの一般的な方法はブラウザJSではまだ成熟していない。 - 監視SaaSのフロントエンド監視機能は、トークンやキーを埋め込み、 直接送信する形で実現されている。 - この方法をGoogle
Cloudで採用することは可能だが、 一般的にはバッドプラクティスであることを認識すること。 - セキュリティが重要な場合には、通常のリクエストと同様の認証をかけ、 Google Cloudに転送する方式になると思われる。 20