[2024/09/28 - フロントエンド・オブザーバビリティ Meetup] フロントエンドエンジニアとして、オブザーバビリティにコミットすること

2024/09/28に開催した「フロントエンド・オブザーバビリティ Meetup」での資料です。

https://uzabase-tech.connpass.com/event/324317/

Transcript

1. フロントエンドエンジニアとして、 
 オブザーバビリティにコミットすること 
 2024/08/28 フロントエンド・オブザーバビリティ Meetup
 NewsPicks Product Domain
 Web Platform Unit イイダユカコ（@becyn）

2. 00
 自己紹介
 2013 年 4 月より
 株式会社 CyberaAgent にサーバーサイドエンジニアとして入社。
 2015 年 12 月より
 社内異動をきっかけにフロントエンドエンジニアとして従事。
 2019 年 9 月より
 株式会社ユーザベースにエンジニアとして入社。
 フロントエンド領域の開発をメインに、design system の推進、
 Observability（o11y）& Accessibility（a11y）の布教活動などを行う。
 
 現在は Web プロダクトのメインメンテナーを担当する
 Web Platform Unit のリーダーを担当。
 Unit では、Web プロダクトにおける
 リアーキテクチャ（基盤移行）& デザインリニューアル PJ 推進中 💪
 イイダ ユカコ
 NewsPicks Web エンジニア
 @becyn on #frontend_o11y 

3. 稀にいただく声 
 #frontend_o11y 

4. “フロントエンドエンジニアなのに 
 オブザーバビリティも 
 ケアしてるんですね！ ”
 稀にいただく声
 #frontend_o11y 

5. ©NewsPicks Inc. All Rights Reserved.
 “フロントエンドエンジニアなのに 
 オブザーバビリティも 
 ケアしてるんですね！ ”
 稀にいただく声
 労いはいつでもありがたいものだ 🙏
 
 なんだけど、 

6. 00
 個人的な感覚 
 • フロントエンドエンジニア（だけど、）だからこそ、 
 オブザーバビリティは結構大事だと感じている 
 
 • オブザーバビリティに職種の壁は無いように感じている 
 #frontend_o11y 

7. 実際のところ、 
 みんなどう思ってるんだろう 🤔？
 フロントエンド担当だけど（だからこそ？）、オブザーバビリティ気にならない？ 
 最近 OpenTelemetry も盛り上がってるし、波きてない？ 
 #frontend_o11y 

8. 00
 ということで、イベント開催してみました！ 
 満員御礼、ありがとうございます！ 
 短い時間ですが、楽しんでいってください 🥳
 登壇者のみなさんも、ご快諾ありがとうございます！ 
 #frontend_o11y 

9. 01
 閑話休題
 #frontend_o11y 

10. フロントエンドエンジニアとして、 
 オブザーバビリティにコミットすること 
 2024/08/28 フロントエンド・オブザーバビリティ Meetup
 NewsPicks Product Division
 Web Platform Unit イイダユカコ（@becyn）

11. 01
 オブザーバビリティ、 
 なんで大事なの？ 
 #frontend_o11y 

12. NewsPicks Product Domain 内の Unit 構成の特徴 
 01
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain（全11Unit、約80名の組織） 内 6 Unit が Web 開発を担当する Unit Web 基盤では、多くのメンバーによる開発が行われている 基本的にみんな
 フルスタックエンジニア💪
 dev dev dev dev SRE
 dev analytics
 dev dev dev Web
 Platform Unit
 dev mobile app
 dev admin
 姉妹PJ
 dev #frontend_o11y 

13. 01
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain 内の Web Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ（新基盤への移行） 
 
 3. Web 開発をする Unit のサポート 
 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
 #frontend_o11y 

14. 00
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain 内の Web Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ（新基盤への移行） 
 
 3. Web 開発をする Unit のサポート 
 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
 開発者が自分たちであろうと、他 Unit であろうと、 
 
 トップスピードでハイウェイを 
 突っ走れるシステムを用意してたい 

15. 何が「トップスピード」を生む？ 
 #frontend_o11y 

16. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 
 
 
 
 
 
 *deploy 時間の短縮や万全なテストの仕組みなども必要だと思いますが、今回は上記に絞って喋ります 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 まずは、
 #frontend_o11y 

17. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 
 
 
 
 
 
 *deploy 時間の短縮や万全なテストの仕組みなども必要だと思いますが、今回は上記に絞って喋ります 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 まずは、
 ここで奇跡的な出会いが！
 #frontend_o11y 

18. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、 
 デバッグが必要なコードがシステムの 
 どこにあるかを見つけ出すためのもの 
 “ 👆が本の帯に書いてあって、「これじゃん」ってなった 
 #frontend_o11y 

19. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、 
 デバッグが必要なコードがシステムの 
 どこにあるかを見つけ出すためのもの 
 “ 👆が本の帯に書いてあって、「これじゃん」ってなった 
 オブザーバビリティ、 
 やるしか？ 

20. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 #frontend_o11y 

21. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 とにかくユーザー視点を優先した可視化 が必要です。 
 ユーザ視点優先での監視によって、 
 より効果的な可視化ができます。 
 “ 我々 Web 基盤のメインメンテナーだからこそ、やる意味がある …！！
 #frontend_o11y 

22. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 とにかくユーザー視点を優先した可視化 が必要です。 
 ユーザ視点優先での監視によって、 
 より効果的な可視化ができます。 
 “ 我々 Web 基盤のメインメンテナーだからこそ、やる意味がある …！！
 オブザーバビリティ、 
 やるしか！！ 

23. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. 既存のユーザー体験に問題があるかどうかわからない（不具合として検出されないもの） 
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 上記を実現するために、
 
 フロントエンドからオブザーバビリティを意識した 
 基盤設計が必要と判断 
 #frontend_o11y 

24. 01
 
 
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain 内の Web Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ（新基盤への移行） 
 
 3. Web 開発をする Unit のサポート 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
 　この範囲内でオブザーバビリティを 
 　推進することに
 #frontend_o11y 

25. 02
 Web 基盤設計時に取り入れたこと 
 #frontend_o11y 

26. • 基盤設計の序盤から Observability ツールとして new relic を採用
 a. リアーキテクチャ PJ で追加された基盤（新基盤）に対しても new relic を導入した 
 （既存の App Server には new relic が入っていた）
 02
 Web 基盤設計時に取り入れたこと 
 [番宣]
 Software Design 6月号で基盤設計について執筆させていただきました。 o11y 以外の視点についても気になる方は是非お 手にとってみてください。
 なんとその号では @sadnesojisan の特集もあり、お買い得（？）です！
 #frontend_o11y 

27. 02
 
 Web 基盤設計時に取り入れたこと 
 DB App Server Java/Kotlin project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（ Web を切り離す） Web Client #frontend_o11y 

28. 02
 
 Web 基盤設計時に取り入れたこと 
 DB App Server Java/Kotlin project GraphQL Next.js project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（ Web を切り離す） 初回来訪時 Next.js project 内の ページ遷移時に発生する API Request 対応状況により path ごとに振り分け （Path-based routing） Web Client TypeScript project Web server ELB #frontend_o11y 

29. 02
 
 Web 基盤設計時に取り入れたこと 
 DB App Server Java/Kotlin project GraphQL Next.js project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（ Web を切り離す） 初回来訪時 Next.js project 内の ページ遷移時に発生する API Request 対応状況により path ごとに振り分け （Path-based routing） Web Client TypeScript project Web server ELB #frontend_o11y 

30. 02
 
 Web 基盤設計時に取り入れたこと 
 DB App Server Java/Kotlin project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（ Web を切り離す） Web Client ✔ ✔ ✔ #frontend_o11y 

31. 02
 
 Web 基盤設計時に取り入れたこと 
 DB App Server Java/Kotlin project GraphQL Next.js project API & Web 用 rendering を担う、Spring base で作られた project。 re-architecture 未対応ページについては NP Server にリクエストする。 最終的に API に特化した project になることを目指す（ Web を切り離す） 初回来訪時 対応状況により path ごとに振り分け （Path-based routing） Next.js project 内の ページ遷移時に発生する API Request Web Client TypeScript project Web server ELB ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ #frontend_o11y 

32. 03
 実際の運用例 
 new relic 内おすすめ可視化機能厳選集 
 #frontend_o11y 

33. 1. Distributed tracing（分散トレーシング） 
 （言わずもがなですが、）クライアントの体験を起点に DBアクセスまで可視化 
 
 2. Deployment marker 
 全 repository のリリースタイミングとログを同一画面に可視化 
 
 3. Change tracking
 Response time や Error Rate を deploy 前後で比較し、可視化 
 
 4. Service levels
 SLO 設定&実際のユーザーの利用データを使用した現状の可視化 
 03
 実際の運用例〜 new relic 内おすすめ可視化機能厳選集〜 
 *すみません、時間的に厳しそうなので、詳細は new relic さんのドキュメント見てもらえると 🙏
 #frontend_o11y 

34. 1. Distributed tracing（分散トレーシング） 
 （言わずもがなですが、）クライアントの体験を起点に DBアクセスまで可視化 
 
 2. Deployment marker 
 全 repository のリリースタイミングとログを同一画面に可視化 
 
 3. Change tracking
 Response time や Error Rate を deploy 前後で比較し、可視化 
 
 4. Service levels
 SLO 設定&実際のユーザーの利用データを使用した現状の可視化 
 03
 実際の運用例〜 new relic 内おすすめ可視化機能厳選集〜 
 #frontend_o11y 

35. 1. Distributed tracing（分散トレーシング） 
 （言わずもがなですが、）クライアントの体験を起点に DBアクセスまで可視化 
 
 2. Deployment marker 
 全 repository のリリースタイミングとログを同一画面に可視化 
 
 3. Change tracking
 Response time や Error Rate を deploy 前後で比較し、可視化 
 
 4. Service levels
 SLO 設定&実際のユーザーの利用データを使用した現状の可視化 
 03
 実際の運用例〜 new relic 内おすすめ可視化機能厳選集〜 
 #frontend_o11y 

36. 1. Distributed tracing（分散トレーシング） 
 （言わずもがなですが、）クライアントの体験を起点に DBアクセスまで可視化 
 
 2. Deployment marker 
 全 repository のリリースタイミングとログを同一画面に可視化 
 
 3. Change tracking
 Response time や Error Rate を deploy 前後で比較し、可視化 
 
 4. Service levels
 SLO 設定&実際のユーザーの利用データを使用した現状の可視化 
 03
 実際の運用例〜 new relic 内おすすめ可視化機能厳選集〜 
 乞うご期待💪
 #frontend_o11y 

37. 04
 運用イメージも湧いたところで、 
 ふりかえり 
 #frontend_o11y 

38. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. ユーザー体験に既存の問題があるかどうかわからない（不具合として検出されないもの） 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、デバッグが必要なコードが 
 システムのどこにあるかを見つけ出すためのもの 
 とにかくユーザー視点を優先した可視化が必要です。 
 ユーザ視点優先での監視によって、より効果的な可視化ができます。 
 “ “ #frontend_o11y 

39. • 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当 /関連コード） 
 b. ユーザー体験に既存の問題があるかどうかわからない（不具合として検出されないもの） 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、デバッグが必要なコードが 
 システムのどこにあるかを見つけ出すためのもの 
 とにかくユーザー視点を優先した可視化が必要です。 
 ユーザ視点優先での監視によって、より効果的な可視化ができます。 
 “ “ #frontend_o11y 
 ここをふりかえり

40. 04
 
 ふりかえり 
 
 
 
 
 
 
 
 実話
 • 他 Unit の方が、本番で問題が起こった時、 distributed tracing を確認し、 
 特定ページ => API request を探し当て障害対応できた 
 ◦ 担当領域に関係なく、オブザーバビリティをケアしたシステム構築は開発チームにとって有効 
 
 • SRE の方が可視化された Web 基盤の状態を見て、 
 インフラコスト、リクエストの偏り等を調査し、判断できる 
 ◦ （1つ目のようなデバッグ時はもちろん）開発チームに所属する人全員が、担当領域や経験値に関わらず、 
 同じ情報、目線を持つことを可能にするのが「オブザーバビリティ（可視化）」だと実感 
 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当/関連コード）
 b. ユーザー体験に既存の問題があるかどうかわからない（不具合として検出されないもの） #frontend_o11y 

41. 04
 
 
 
 
 
 
 
 
 実話
 • 開発環境での状態も可視化し、リリース前の「体験」から 
 ユーザーに渡る前に Performance 改善ができた
 ◦ ユーザー視点でのデータ収集を行うことによって、よりクリティカルな改善に繋げられた 
 ふりかえり 
 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当/関連コード）
 b. ユーザー体験に既存の問題があるかどうかわからない（不具合として検出されないもの） #frontend_o11y 

42. いずれのパターンにおいても
 
 オブザーバビリティを通して 
 解消を実感できるシーンがあった。 
 「トップスピード」のベースになると言える状態。 
 以下を実現できたか？ 
 04
 
 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない（該当 /関連システム、該当/関連コード）
 b. ユーザー体験に既存の問題があるかどうかわからない（不具合として検出されないもの） ふりかえり 
 ✔ ✔ #frontend_o11y 

43. 05
 Observability を取り入れたことで 
 肌で感じたこと 
 #frontend_o11y 

44. • ユーザー体験を通したデータからプロダクトの状態がわかる 
 イレギュラーもレギュラーも含めたプロダクトの側面を知ることができる 
 
 • 可視化したものが “生きるドキュメント ” になる
 可視化されたものが、プロダクトの今を表している（アーキテクチャのオンボ資料になりえる！） 
 
 • 開発者の担当領域や経験値に依存しないシステム理解を後押しできる 
 同じ目線、同じ情報を得ることができる（個人的には、理想的な組織作りに繋がると思っている） 
 05
 取り入れたことで肌で感じたこと 
 #frontend_o11y 

45. • ユーザー体験を通したデータからプロダクトの状態がわかる 
 イレギュラーもレギュラーも含めたプロダクトの側面を知ることができる 
 
 • 可視化したものが “生きるドキュメント ” になる
 可視化されたものが、プロダクトの今を表している（アーキテクチャのオンボ資料になりえる！） 
 
 • 開発者の担当領域や経験値に依存しないシステム理解を後押しできる 
 同じ目線、同じ情報を得ることができる（個人的には、理想的な組織作りに繋がると思っている） 
 05
 
 取り入れたことで肌で感じたこと 
 「フロントエンドエンジニアとして」だけではなく、 
 「基盤を支えるエンジニア」として、「もっとユーザー理解をしたい開発者」として、 
 オブザーバビリティにコミットすることって 
 かなり価値があると思う 
 #frontend_o11y 

46. 06
 まとめ
 #frontend_o11y 

47. 06
 • 同僚の開発のトップスピードを阻害しないために「迷いをなくす」のに、 
 オブザーバビリティは有用 
 
 • 領域に関係せず、プロダクトを開発するエンジニアにとって、 
 オブザーバビリティにコミットするのはかなり意味があること 
 ◦ 特にフロントエンド（クライアントに近い部分を実装担当する人）が意識していること が大事
 ◦ みんなで、ユーザーを知ろう、プロダクトを知ろう、より良いシステムを作ろう 
 まとめ
 #frontend_o11y 

48. フロントエンドエンジニアとして、 
 オブザーバビリティにコミットすること 
 2024/08/28 フロントエンド・オブザーバビリティ Meetup
 NewsPicks Product Division
 Web Platform Unit イイダユカコ（@becyn）

49. 【再掲】
 満員御礼、ありがとうございます！ 
 短い時間ですが、楽しんでいってください 🥳
 登壇者のみなさんも、ご快諾ありがとうございます！ 
 [番宣]
 Software Design 6月号で基盤設計について執筆させていただきました。 o11y 以外の視点についても気になる方は是非お 手にとってみてください。
 なんとその号では @sadnesojisan の特集もあり、お買い得（？）です！
 #frontend_o11y