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

Transcript

1. フロントエンドオブザーバビリティ on Google Cloud Jagu'e'r オブザーバビリティ分科会 Meetup#1 株式会社スリーシェイク 山田悠之介 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 - 名前：山田悠之介 - 所属：株式会社スリーシェイク Sreake事業部 - 職種：フルスタックエンジニア - Webアプリのフロントエンド、バックエンド、 生成AIアプリの開発とその支援 - 趣味：筋トレ - 週4ほどBIG3を中心に 2
3. モチベーション フロントエンドの監視は、バックエンドやインフラと比べ、優先度が低くなりがち。 - バックエンド/インフラの障害はサービス継続に影響しやすい - コンピューティングリソースをサービス提供側で管理していない しかしフロントエンドはユーザが直接触るものであり、 そこで何が起きているか知ることは重要なはずです。 3
4. 本日の内容 主に話すこと - フロントエンド（というかブラウザサイド）のテレメトリを、 監視にGoogle Cloudを利用している場合にどのように収集するか - 最近はNext.jsなどでサーバーサイドのフロントエンドもあるが そちらは普通に取れば良いため - テレメトリは今回はログ、トレース、メトリクスを対象とします。 少しだけ話すこと - フロントエンドにおけるオブザーバビリティとは何か - どんなテレメトリを収集すると良いか 4
5. フロントエンドにおけるオブザーバビリティ フロントエンドでオブザーバビリティを高めるにあたって、 いくつかのマイルストーンがあると考えています。 1. アプリケーションが正常に動作すること a. エラーが出ていないか 2. アプリケーションが素早く動作すること a. 描画や動作が遅くなっていないか 3. アプリケーションを快適に利用できること a. ユーザが操作に迷っていないか これらを知るためにはフロントエンドのテレメトリが必要です。 フロントエンド監視の全体像と実現方法 5
6. テレメトリとして何を取るか - ログ - ロジックについてはバックエンドと同じようなログ - 例外 - トレース - API呼び出し - メトリクス - パフォーマンス：Core Web Vitals - 地理位置情報：IP Geolocation, Geolocation API - デバイス：Navigator.connection, Navigator.deviceMemory, Navigator.hardwareConcurrency, innerHeight, innerWidth などが必要と考えています。 フロントエンドで収集するべきテレメトリは何か 6
7. どのようにテレメトリを取るか：バックエンドの場合 Google Cloudの各コンピューティングサービスについて、 テレメトリを収集する推奨方法がドキュメンテーションされています。 Choose an instrumentation approach | Google Cloud Observability 大体OTel SDKかPrometheusのクライアントライブラリが推奨されています。 しかし...... 7
8. どう取るか：バックエンドの場合 どちらもフロントエンドでは成熟していません。 - OTel SDK JavaScript | OpenTelemetry - Prometheusクライアントライブラリ JS/TS未対応 Client libraries | Prometheus 別の方法を考える必要があります。 8
9. 監視SaaSの場合 Datadog、New Relic、Sentryなどの監視SaaSにはフロントエンド監視の機能があります。 これらのサービスでどのように実現しているか見てみます。 9
10. 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, })
11. New Relicの場合 New Relicではブラウザエージェントを追加する形でフロントエンド監視を有効にします。 Install the browser agent | New Relic Documentation アプリにIDやキーを埋め込む形になっています。 11
12. Sentryの場合 クライアントライブラリ経由でブラウザから送信します。 初期化時にパブリックキーを指定する形です。 Sentry for React 12 import * as Sentry from "@sentry/react"; Sentry.init({ dsn: "https://examplePublicKey@o0.ingest.sentry.io/0", ... });
13. ここまでのまとめ - OTel SDKやPrometheusクライアントライブラリなど、 バックエンドで推奨されている方法はブラウザJSではまだ微妙です。 - フロントエンド監視を提供する各監視SaaSでは、 トークンやキーを埋め込み、直接送信する形で実現しています。 - トークンなどを含むJSがブラウザに配信されるため、露出する形 - 権限は制限されている - 汎用的なやり方がこれしかないためと考えられます。 13
14. Google Cloudでどうやるか：方法1 監視SaaSのやり方を真似ます。 - 最低限の権限を持つサービスアカウントを作成し、キーを生成 - キーをフロントエンド側に持たせて、Google CloudのAPIをコール サンプルコード https://github.com/YunosukeY/frontend-o11y-on-gcloud 14
15. 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
16. 注意 SAキーをフロントエンドで持つのは、Google Cloud的にはバッドプラクティスです。 - キーを含むJSがブラウザに配信されるため またSAキーは公開されているのが検知されると、デフォルトでは無効化されます。 - どのような場合に検知されるかは非公開？ - 今回のサンプルアプリでは公開までは試していないため実際どうなるかは未検証です。 - 公開を検知しても悪影響があるまで無効化しないオプションもあります。 Restricting service account usage | Resource Manager Documentation | Google Cloud Google CloudにはAPIキーもあり、こちらは利用するAPIとアプリケーションに 制限をかけられますが、今回利用するAPIには対応していません。 16
17. Google Cloudでどうやるか：方法2 フロントエンドからの通常のAPI呼び出しと同様に認証をかけるやり方が考えれられます。 どこで認証をしているかによって大きく2つに別れるかと思います。 1. アプリケーションサービス内で認証している場合 2. リバースプロキシで認証している場合 17
18. 方法2-1：アプリケーションサービス内で認証している場合 - バックエンドで認証している場合 - Next.jsなどを使っておりServer Actionsで認証している場合 などが該当します。 サーバーサイドに一旦送って認証した後、 そのままGoogle Cloudに転送すれば良いと思います。 18
19. 方法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
20. まとめ - フロントエンドはユーザが直接触れるものなのでオブザーバビリティは重要 - OTelなどの一般的な方法はブラウザJSではまだ成熟していない。 - 監視SaaSのフロントエンド監視機能は、トークンやキーを埋め込み、 直接送信する形で実現されている。 - この方法をGoogle Cloudで採用することは可能だが、 一般的にはバッドプラクティスであることを認識すること。 - セキュリティが重要な場合には、通常のリクエストと同様の認証をかけ、 Google Cloudに転送する方式になると思われる。 20