フロントエンドにおけるObservability

Copyright © 2023 Bitkey Inc. All right reserved.
フロントエンドにおける Observability
株式会社ビットキー　北村順 2023/06/13

View Slide

2
Outline
1. 話すこと・話さないこと

2. ざっくりアーキテクチャ全体像

3. Metrics/Logs/Traces + Profiles for フロントエンド

4. 実施した改善とその結果

View Slide

3
自己紹介
北村順

Jun Kitamura
2015.4
2019.4
2021.7
株式会社フロムスクラッチ（現・株式会社データＸ）
に入社

SaaSマーケティングツールの導入エンジニア・インフ
ラエンジニアを担当
ビットキーへ参画

最初の製品リリースとほぼ同時期に入社

カギのプラットフォーム: bitkey platform や顔認証プ
ロダクトの開発に従事
SREチームの立ち上げ。SLO/SLIやインシデントレスポ
ンスなど様々な運用設計、構築、ツール導入を実施
し、信頼性向上へ貢献。
2023.06 SREとしてこれまでに、構築してきた様々な施策・仕組
みを各事業・プロダクトへと適切に還元していく活動を
実施中。

View Slide

ઃཱɹɹɿ2018೥5݄ɹ

ڌ఺ɹɹɿ౦ژɾେࡕɾ෱Ԭɾٶ࡚

ࢿຊۚɹɿ14,946,908,300ԁʢ2022೥12݄31೔࣌఺ɹࢿຊ४උؚۚʣ

ैۀһ਺ɿ233໊

View Slide

5

View Slide

6
workhubͷશͯΛͭͳ͛ΔΞϓϩʔν
શͯͷεςʔΫϗϧμʔ͕
࢖͍͍ͨػೳ͕͜͜ʹ
ʮIVCʯ͔ͩΒ࣮ͦ͜ݱͰ͖Δ
ຊ౰ʹศརͳz৽͍͠ಇ͖ํz
ࡉ΍͔ʹઃఆΛબ΂Δ
৺஍Α͍αʔϏεར༻ମݧ
…and more
ϏϧΞΫηείϯτϩʔϧ
͋ΒΏΔ൶ΛҰݩ؅ཧ
ిؾৣ΍ࣗಈυΞɺΤϨ
ϕʔλʔ͔Βϑϥούʔ
ήʔτ·ͰɺશͯͷηΩϡ
ϦςΟΛworkhubʹ࿈ܞɻ
ϗςϦϯάɾ"#8
χϡʔϊʔϚϧͳಇ͘৔ॴͷߏங
QR΍ϏʔίϯͰҐஔΛ൑
ఆɻ࠲੮ʹՃ͑ɺϩοΧʔ
༧໿΍ෳ਺ڌ఺ରԠ΋Մೳ
SEQMBDFԣஅݕࡧ
͙͢ʹݟ͔ͭΔɺΛ࣮ݱ͢Δ஍ਤ
γΣΞΦϑΟε΍ݸࣨϒʔεͳͲɺ
αʔϏεΛ·͍ͨͰݕࡧɾ༧໿ɻ
ݸผʹϩάΠϯͯ͠୳͢खؒ͸΋͏
ඞཁ͋Γ·ͤΜɻ
SEQMBDFӡӦࢧԉ
ू٬͔ΒӡӦ·ͰΛแׅ؅ཧ
ձһɾܖ໿؅ཧ͔Βೖୀࣨɺ
ձٞࣨͳͲͷར༻࣮੷ूܭ͔
Βܾࡁ·Ͱɻ؆қͳ্ཱͪ͛
Ͱ༨৒ΤϦΞͷऩӹԽʹ΋ɻ
ϑϨΩγϒϧͳೝূํ๏
༻్ɾਓ෺ʹԠͯ͡࠷దԽ
Χʔυ΍QRɺإೝূͳͲΤϦΞɾ
ࢪઃ༻్ʹԠͨ͡ೖࣨݖݶΛ࣮
ݱɻࣾһ͚ͩͰͳ͘ɺήετ΍ۀ
ऀɺϏϧ؅ཧऀʹ΋ɻ
ࠞࡶঢ়گҐஔঢ়گ൑ఆ
ີΛճආ͢Δۭؒͮ͘Γ
AIΧϝϥͱ࿈ಈ͠ʮਓܕʯ
Λݕ஌ɻͦͷΤϦΞͷࠞࡶ
ঢ়گΛՄࢹԽ͠ɺີΛආ͚
΍͍ۭؒ͢Λԋग़ɻ
ແਓड෇ձٞࣨ༧໿
ඇର໘͔ͭߴ͍ϗεϐλϦςΟ
QRͰͷड෇͔Βձٞࣨ༧
໿ɾղৣ·Ͱ࿈ಈɻηΩϡ
ϦςΟΛҡ࣋ͭͭ͠ɺ҆શ
ͳඇର໘ແਓड෇Λ࣮ݱɻ
4BB4ΞυΠϯ࿈ܞ
׳Ε਌͠ΜͩπʔϧͰεϜʔζʹਁಁ
ΧϨϯμʔɾνϟοτͳͲ
׳Ε਌͠Μͩπʔϧͱͦͷ
··ܨ͕Γɺࣗવʹਁಁ͠
ͯ࢖ΘΕΔπʔϧʹɻ

αʔϏε΋ͭͳ͕ΔεϚʔτϏϧ
ϥϯν഑ୡɾਗ਼૟ͳͲ
ՄࢹԽɾ෼ੳϓϥοτϑΥʔϜ
ར༻࣮੷σʔλΛجʹͨ͠࠷దͳۭؒ׆༻
ϚωδϝϯτμογϡϘʔυ
৘ใΛू໿͠ɺ෼ࢄͨ͠ಇ͖ํΛέΞ
֤ࣄۀͰͷऔΓ૊Έɾ࣮੷ɹʙWorkspace Domainʙ

View Slide

7

View Slide

8
こんなこと思ったことないですか？

View Slide

9
・バックエンドのリファクタリング・バグ修正しても、事象が改善しない！

・クエリパフォーマンスチューニングしても、画面が遅い！開かない！

・一応、ボトルネック”っぽい”ところをみて改善したつもりのはずなのに。。。

View Slide

10
・バックエンドのリファクタリング・バグ修正しても、事象が改善しない！

・クエリパフォーマンスチューニングしても、画面が遅い！開かない！

・一応、ボトルネック”っぽい”ところをみて改善したつもりのはずなのに。。。
ユーザー視点で

考えられているだろうか？

View Slide

11
話すこと
・GCP x Datadog を利用したフロントエンドのオブザーバビリティの観点について

・Metrics/Logs/Traces + Profiles の 4 つの柱を利用して
 
　SREs の私（not フロントエンドエンジニア）が、どういうことを考えて、何をしたのか。

View Slide

12
話すこと
話さないこと
・フロントエンド以外のオブザーバビリティ

・詳細な設定・改善方法について
・GCP x Datadog を利用したフロントエンドのオブザーバビリティの観点について

・Metrics/Logs/Traces + Profiles の 4 つの柱を利用して
 
　SREs の私（not フロントエンドエンジニア）が、どういうことを考えて、何をしたのか。

View Slide

13

View Slide

14
API
Cloud
Load 
Balancing
Cloud Run
Cloud 
Functions
Database
AlloyDB
Firestore
Contents
Cloud 
Storage
frontendʢSPAʣ
Firebase
hosting
Hardware
RUM Logs
dd-agent
Cloud Run
APM
Logging
Error Tracking Monitor

View Slide

15
API
Cloud
Load 
Balancing
Cloud Run
Cloud 
Functions
Database
AlloyDB
Firestore
Contents
Cloud 
Storage
Hardware
RUM Logs
dd-agent
Cloud Run
APM
Logging
Error Tracking Monitor
frontendʢSPAʣ
Firebase
hosting

View Slide

16

View Slide

17
ref. https://learning.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html
1 Metrics
2 Logs
3 Traces
時間の経過とともに発生した個別のイベントの

不変のタイムスタンプ付き記録
一定の時間間隔で測定されたデータを数値で表現したもの
分散システムを介したエンドツーエンドの

リクエストフローをエンコードする

因果関係のある一連の分散イベントを表現したもの

「サービス間」でのボトルネック特定に有効

View Slide

18
ref. https://learning.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html
1 Metrics
2 Logs
3 Traces
分散システムを介したエンドツーエンドの

リクエストフローをエンコードする

因果関係のある一連の分散イベントを表現したもの

「サービス間」でのボトルネック特定に有効
4 Profiles
CPU 使用率や関数呼び出しの頻度と時間など

プログラムの複雑さをコードレベル、かつ

時間ベースでその表現したもの

「サービス内」のボトルネック特定に有効
時間の経過とともに発生した個別のイベントの

不変のタイムスタンプ付き記録
一定の時間間隔で測定されたデータを数値で表現したもの

View Slide

19
Metrics

View Slide

20
Metrics
ʲಡΈࠐΈͷύϑΥʔϚϯεʳ
ϖʔδಡΈࠐΈ։͔࢝Β

ϝΠϯίϯςϯπ͕ಡΈࠐ·ΕΔ
·Ͱͷ࣌ؒ

2.5 sec ҎԼ͕Goodʂ
ʲࢹ֮తͳ҆ఆੑʳ
ϖʔδͷදࣔதʹൃੜͨ͠

༧ظ͠ͳ͍ϨΠΞ΢τγϑτ

ΛఆྔԽͨ͠஋

0.1 ҎԼ͕Goodʂ
ʲಡΈࠐΈͷԠ౴ੑʳ
Ϣʔβʔ͕࠷ॳʹ

ϖʔδΛૢ࡞ͨ͠ͱ͖͔Β

ͦͷૢ࡞ʹԠͯ͡ϒϥ΢βʔ͕

࣮ࡍʹΠϕϯτ ϋϯυϥʔͷॲཧΛ։࢝͢
Δ·Ͱͷ࣌ؒ

https://web.dev/i18n/ja/vitals/

View Slide

21
Metrics
ʲಡΈࠐΈͷύϑΥʔϚϯεʳ

ϖʔδಡΈࠐΈ։͔࢝Β

ϝΠϯίϯςϯπ͕ಡΈࠐ·ΕΔ
·Ͱͷ࣌ؒ

ʲࢹ֮తͳ҆ఆੑʳ

ϖʔδͷදࣔதʹൃੜͨ͠

༧ظ͠ͳ͍ϨΠΞ΢τγϑτ

ΛఆྔԽͨ͠஋

0.1 ҎԼ͕Goodʂ

https://web.dev/inp/
೥݄͔Β
'*%ʢ'JSTU*OQVU%FMBZʣ
͔Β
*/1ʢ*OUFSBDUJPOUP/FYU1BJOUʣ
ʲಡΈࠐΈͷԠ౴ੑʳ

View Slide

22
フィールドデータ・ラボデータ

View Slide

23
Metrics - フィールドデータ・ラボデータ -
ϑΟʔϧυσʔλ
ϥϘσʔλ 一貫性のある管理された環境で、ページの読み込みをシミュレートするためのツールを使用して計測される指標

e.g. CPU や Network の Throttling
実際にページを読み込み、操作しているユーザーについて

測定される指標

View Slide

24

View Slide

25
ϑΟʔϧυσʔλ

View Slide

26
ϥϘσʔλ

View Slide

27
計測ツール

View Slide

28
Metrics - 計測ツール -
計測ツール（フィールドデータ）の選定
PageSpeed
Insights
ʢPSIʣ
導入

しやすさ
認証
継続的

計測
詳細

分析
備考
Datadog
RUM
web-vitals
ʢlibraryʣ
実環境へのパフォーマンス影響が

多少発生してしまうが

詳細な分析が可能。
自前で分析する仕組みを用意
する必要がある
サクッと分析するには最適だが

サイトにbasic 認証経由でアクセスを

許可とかして、頑張ればいける。
主にtoC向け。

BigQuery x Looker Studio

認証が必要なサイトはできなさそう
Chrome
UX Report
ʢCrUXʣ

View Slide

29
計測ツール（フィールドデータ）の選定
PageSpeed
Insights
ʢPSIʣ
Chrome
UX Report
ʢCrUXʣ
導入

しやすさ
認証
継続的

計測
詳細

分析
備考
Datadog
RUM
実環境へのパフォーマンス影響が

多少発生してしまうが

詳細な分析が可能。
主にtoC向け。

BigQuery x Looker Studio

認証が必要なサイトはできなさそう


自前で分析する仕組みを用意
する必要がある
web-vitals
ʢlibraryʣ

View Slide

30
計測ツール（ラボデータ）の選定
PageSpeed
Insights
ʢPSIʣ
Chrome
DevTool
ʢLighthouseʣ
導入

しやすさ
認証
継続的

計測
詳細

分析
備考
Lighthouse
CI
ローカル環境で簡単かつ詳細に

分析ができる。


環境整備が少し手間だが

より再現性の高く継続的な

計測が実現可能。

View Slide

31
計測ツール（ラボデータ）の選定
PageSpeed
Insights
ʢPSIʣ
Chrome
DevTool
ʢLighthouseʣ
導入

しやすさ
認証
継続的

計測
詳細

分析
備考
Lighthouse
CI
環境整備が少し手間だが

より再現性の高く継続的な

計測が実現可能。
ローカル環境で簡単かつ詳細に

分析ができる。



View Slide

32
Datadog RUM（フィールドデータ）

View Slide

33
Metrics - Datadog RUM（フィールドデータ） -
フィールドデータ
ɾDatadog RUM ͷઃఆ͸ɺdatadogRum.init Λ࠷
ॳʹಡΈࠐΉ͚ͩͰ؆୯ɻ

ɾpackage.json ͷ version Λऔಘͯ͠ɺversion Λ
ࢦఆ͢Δͱɺversion ຖͷ web vitals ΍ error rate
ͱ͔΋ΈΕΔΑ͏ʹͳΔɻ
ref. https://docs.datadoghq.com/ja/real_user_monitoring/browser/

View Slide

34
Metrics - Datadog RUM（フィールドデータ） -

View Slide

35
Lighthouse CI（ラボデータ）

View Slide

36
Lighthouse CI
Metrics - Lighthouse CI（ラボデータ） -
Lighthouse CI Server
Cloud
Load 
Balancing
Cloud Run
PostgreSQL
Cloud SQL
Backend Service
Backend Service
Identity-
Aware Proxy
upload

Developers
frontendʢSPAʣ
Firebase
hosting
監査
(参考)ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)

https://techblog.yahoo.co.jp/entry/2022090530337093/
lighthouse CI を使うことで簡単に、Lighthouse による監査をコマンドラインで実施することができます。

また、Lighthouse CI Sever で Web UI による可視化。

View Slide

37
lighthouserc.js
puppeteer-script.js
認証が必要な url においては、puppeteerScript を利用して、監査前に都度実行するスクリプトの中で、ログイン
を実施するように puppeteer のスクリプトを実行してあげればok

View Slide

38
Lighthouse CI Server の Web UI で URL x Branch 単位で、Lighthouse のスコアを時系列に確認することができ、
いつそのスコアが下がったのかなどを観測できるようになった。

View Slide

39
Logs

View Slide

40
フロントエンドにおける Logs

ɾͬ͘͟Γ Chrome DevTools > Console ʹग़ྗ͞ΕΔΠϕϯτͷه࿥

ɾͱ͸͍͑ɺຊ൪؀ڥͰɺconsole.log Λग़͢ͷ͸͍͔͕ͳ΋ͷ͔ɻ

ɾͦ͜ͰɺDatadog RUMͱDatadog Logs
Logs

View Slide

41
■ Datadog RUM

・datadogRum.addError すると、対象のRUM session に対して、発生したエラーを紐づけて送信し、分析することができます。

・その際、任意の context も付与することもできます。

■ Datadog Logs

・datadogLogs.logger.xxx すると、Datadog Logs へ指定したログを送信することができます。

・当然 error だけではなく、debug・info も送信できるので、実際のユーザーの任意の操作をログで確認することもできます。

・Firebase Analytics（Google Analytics）でも似たようなことができるが、導入のしやすさ、リアルタイム性等の点において、
Datadog Logs の方が使いやすいなと感じています。
Logs
フロントエンドにおける Logs

View Slide

42
Logs
datadogRum.addError で、ブラウザのエラーを収集すると Error Tracking を活用して、ブラウザのエラーをグルーピング
して管理・監視することができます。

View Slide

43
Logs
CI ͰɺࣄલʹɺDatadog ΁ sourcemap Λ upload ͓͚ͯ͠͹ɺIDE΍GitHubͱ࿈ܞ͢Δ͜ͱ΋Ͱ͖·͢ɻ

View Slide

44
Logs
Error Tracking x Monitor Λར༻͢Ε͹ɺ࣮ࡍͷϢʔβʔͷ؀ڥͰൃੜͨ͠ϒϥ΢βΤϥʔΛ؂ࢹ͢Δ͜ͱ͕Ͱ͖·͢ɻ

View Slide

45
Traces

View Slide

46
フロントエンドにおける Traces

ɾେલఏɺTraces ͸ɺ෼ࢄτϨʔγϯάͳͷͰɺϑϩϯτΤϯυ͚ͩͰ׬݁͢Δ͓࿩Ͱ͸ͳ͍ɻ

ɾόοΫΤϯυ͚ͩͰ͸ͳ͘ɺϑϩϯτΤϯυ΋ؚΊͨγεςϜશମͰΈͨ࣌ͷϘτϧωοΫΛಛఆ͢Δ͜ͱ͸ɺ
Ϣʔβʔࢹ఺తʹ΋ॏཁɻ
Traces

View Slide

47
Traces
・当初 Opentelemetry + Cloud Trace を利用して、バックエンド間のトレーシングを実現
していた。

Traces を活用すると、ユーザーのセッション・操作と実行されているSQLを紐付けて観測することができるようになり
ます。

View Slide

48
Profiles

View Slide

49
Profiles
https://blog.sentry.io/profiling-101-what-is-profiling/
そもそも Profiles を取得するための手法（Profiling）にはどういったものがあるのか

View Slide

50
Profiles
https://blog.sentry.io/profiling-101-what-is-profiling/
そもそも Profiles を取得するための手法（Profiling）にはどういったものがあるのか
フロントエンド

バックエンド

？？
Cloud
Profiler
v8-profiler

（Sentry…?）

View Slide

51
Profiles
Chrome DevTools > Performances から Profiling することができます。どのコンポーネント・処理にどれくらいの
時間・リソース（e.g. CPU）がかかっているのか等が特定できます。

View Slide

52

View Slide

53
■ Metrics（Lighthouse）

・不要なコンポーネント削除

・link タグに、preconnect・dns-prefetch 付与

・適宜、Dynamic Importへ変更

・webpack bundle analyzer 導入、webpack v4 -> v5 へ version up

　・Tree Shaking、splitChunks 最適化

　・ついでに、CICD速度改善

・Firebase Storage Region 移行（Storage Transfer Service利用

・Cloud CDN導入

・画像リサイズ（Firebase Resize Images
 
　・ref. https://extensions.dev/extensions/firebase/storage-resize-images
frontendʢSPAʣ
Firebase
hosting
Contents
Cloud 
Storage 3-5s

速度改善
End
Users Cloud
Load 
Balancing
100-200s

速度改善
preconnect

dns-prefetch

View Slide

54
■ Logs（ブラウザエラー監視）

・リリース直後に、発生した新しいエラーを通知することで、すぐにブラウザでのエラーを検知し、修正・リリースする
流れを構築することができた。
Developers
End
Users
■ Profiles（Chrome DevTools）

・コードレベルで、ボトルネック特定し、不要な処理の削除、及び、メモ化等のリファクタリング

・フロントエンドの重複した処理を、バックエンドに寄せるように API 追加・修正　etc...
frontendʢSPAʣ
Firebase
hosting
Developers
frontendʢSPAʣ
Firebase
hosting
エラー発生！
新しい

エラーのみ

Profiling

View Slide

55
■ 結果

・Lighthouse のスコアは若干上がったけど、全然上がらん。。。！？

　・主要な URL をいくつか監査したが、全体平均5ポイント程度しか改善しなかった。

・逆にがっつりリファクタリングしたコンポーネントを含む URL とかは、25 -> 55 と 30 ポイントくらい改善しているの
で、ちまちま改善するより、書き直した方がいい場合もあるなーという感想。（もはやフロントエンド関係ない

　・傾向として、TBT が大きい（メインスレッドを占有している）コンポーネントとかは、その傾向が高いかも？

・（ここまで言っておいてなんだが）Lighthouse のスコアやDatadogの指標を改善することは

　結果論であって、目的ではない。

　・そもそも SEO とか関係ないプロダクトはそこまで意識する必要はないかも？という前提がある。

　・かつ、改善したいのは、「スコア」ではなく、「ユーザー体験」ということを忘れてはならない。

　　・ステークホルダーと「ユーザー体験に基づいた指標（SLI）とスコアの基準（SLO）」を、合意することが大切。

View Slide

56
さいごに

View Slide

57
さいごに
ユーザー視点で

考えられているだろうか？

View Slide

58
・「ユーザー視点」によるオブザーバビリティの構築・運用

　・フロントエンド ~ ハードウェア一気通貫したオブザーバビリティの実現へ

・「ユーザー視点」によるSLO/SLIの構築・運用

　・ハードウェアを絡めた解錠体験等に対する SLO・SLI の実装、運用へ

・「ユーザー視点」による運用体制構築

　・アラート ~ サポート対応までのシームレスな体制へ
さいごに

View Slide

End of File
59

View Slide

フロントエンドにおけるObservability

フロントエンドにおけるObservability

株式会社ビットキー / Bitkey Inc.
PRO

More Decks by 株式会社ビットキー / Bitkey Inc.

Featured

Transcript

フロントエンドにおけるObservability

フロントエンドにおけるObservability

株式会社ビットキー / Bitkey Inc. PRO

More Decks by 株式会社ビットキー / Bitkey Inc.

Featured

Transcript

株式会社ビットキー / Bitkey Inc.
PRO