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
1
240
フロントエンドオブザーバビリティ on Google Cloud
Yunosuke Yamada
March 07, 2025
Tweet
Share
More Decks by Yunosuke Yamada
See All by Yunosuke Yamada
AIエージェントのオブザーバビリティについて
yunosukey
1
650
OpenTelemetry + LLM = OpenLLMetry!?
yunosukey
2
500
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
270
ChatGPTのアルゴリズム
yunosukey
0
370
React and XSS
yunosukey
0
300
DB Tree Algorithms
yunosukey
0
99
Tests in Go
yunosukey
1
110
Bugless Code
yunosukey
0
140
圏論とコンピュータサイエンス / Category Theory and Theoretical Computer Science
yunosukey
0
290
Other Decks in Programming
See All in Programming
セキュリティマネジャー廃止とクラウドネイティブ型サンドボックス活用
kazumura
1
180
Kotlin エンジニアへ送る:Swift 案件に参加させられる日に備えて~似てるけど色々違う Swift の仕様 / from Kotlin to Swift
lovee
1
240
コード書くの好きな人向けAIコーディング活用tips #orestudy
77web
3
320
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
360
[初登壇@jAZUG]アプリ開発者が気になるGoogleCloud/Azure+wasm/wasi
asaringo
0
130
実践ArchUnit ~実例による検証パターンの紹介~
ogiwarat
2
270
赤裸々に公開。 TSKaigiのオフシーズン
takezoux2
0
140
レガシーシステムの機能調査・開発におけるAI利活用
takuya_ohtonari
0
600
ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化
knih
11
1.9k
F#で自在につくる静的ブログサイト - 関数型まつり2025
pizzacat83
0
310
Spring gRPC で始める gRPC 入門 / Introduction to gRPC with Spring gRPC
mackey0225
2
510
A2A プロトコルを試してみる
azukiazusa1
2
650
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
How to train your dragon (web standard)
notwaldorf
92
6.1k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
Producing Creativity
orderedlist
PRO
346
40k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
RailsConf 2023
tenderlove
30
1.1k
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