Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[2024/09/28 - フロントエンド・オブザーバビリティ Meetup] フロントエンド...

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

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

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

Yukako IIDA

August 28, 2024
Tweet

More Decks by Yukako IIDA

Other Decks in Technology

Transcript

  1. 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 

  2. ©NewsPicks Inc. All Rights Reserved.
 “フロントエンドエンジニアなのに 
 オブザーバビリティも 
 ケアしてるんですね!

    ”
 稀にいただく声
 労いはいつでもありがたいものだ 🙏
 
 なんだけど、 

  3. 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 

  4. 01
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain 内の Web

    Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ(新基盤への移行) 
 
 3. Web 開発をする Unit のサポート 
 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
 #frontend_o11y 

  5. 00
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain 内の Web

    Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ(新基盤への移行) 
 
 3. Web 開発をする Unit のサポート 
 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
 開発者が自分たちであろうと、他 Unit であろうと、 
 
 トップスピードでハイウェイを 
 突っ走れるシステムを用意してたい 

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

    
 
 
 
 
 
 
 *deploy 時間の短縮や万全なテストの仕組みなども必要だと思いますが、今回は上記に絞って喋ります 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 まずは、
 #frontend_o11y 

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

    
 
 
 
 
 
 
 *deploy 時間の短縮や万全なテストの仕組みなども必要だと思いますが、今回は上記に絞って喋ります 
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 まずは、
 ここで奇跡的な出会いが!
 #frontend_o11y 

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

    
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、 
 デバッグが必要なコードがシステムの 
 どこにあるかを見つけ出すためのもの 
 “ 👆が本の帯に書いてあって、「これじゃん」ってなった 
 #frontend_o11y 

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

    
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、 
 デバッグが必要なコードがシステムの 
 どこにあるかを見つけ出すためのもの 
 “ 👆が本の帯に書いてあって、「これじゃん」ってなった 
 オブザーバビリティ、 
 やるしか? 

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

    
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 とにかくユーザー視点を優先した可視化 が必要です。 
 ユーザ視点優先での監視によって、 
 より効果的な可視化ができます。 
 “ 我々 Web 基盤のメインメンテナーだからこそ、やる意味がある …!!
 #frontend_o11y 

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

    
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 とにかくユーザー視点を優先した可視化 が必要です。 
 ユーザ視点優先での監視によって、 
 より効果的な可視化ができます。 
 “ 我々 Web 基盤のメインメンテナーだからこそ、やる意味がある …!!
 オブザーバビリティ、 
 やるしか!! 

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

    
 01
 
 
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 上記を実現するために、
 
 フロントエンドからオブザーバビリティを意識した 
 基盤設計が必要と判断 
 #frontend_o11y 

  13. 01
 
 
 なぜ大事だと思うのか〜普段の我々の Unit のミッション〜 
 NewsPicks Product Domain

    内の Web Platform Unit の責務
 
 1. Web 基盤のメインメンテナー 
 
 2. Web プロダクトのリアーキテクチャ(新基盤への移行) 
 
 3. Web 開発をする Unit のサポート 
 
 その他、デザインシステム整備、 SEO、メディアパートナーシップ周辺 等のケアもしています 🫡
  この範囲内でオブザーバビリティを 
  推進することに
 #frontend_o11y 

  14. • 基盤設計の序盤から Observability ツールとして new relic を採用
 a. リアーキテクチャ PJ

    で追加された基盤(新基盤)に対しても new relic を導入した 
 (既存の App Server には new relic が入っていた)
 02
 Web 基盤設計時に取り入れたこと 
 [番宣]
 Software Design 6月号で基盤設計について執筆させていただきました。 o11y 以外の視点についても気になる方は是非お 手にとってみてください。
 なんとその号では @sadnesojisan の特集もあり、お買い得(?)です!
 #frontend_o11y 

  15. 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 

  16. 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 

  17. 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 

  18. 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 

  19. 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 

  20. 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 

  21. 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 

  22. 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 

  23. 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 

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

    
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、デバッグが必要なコードが 
 システムのどこにあるかを見つけ出すためのもの 
 とにかくユーザー視点を優先した可視化が必要です。 
 ユーザ視点優先での監視によって、より効果的な可視化ができます。 
 “ “ #frontend_o11y 

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

    
 01
 なぜ大事だと思うのか〜何が「トップスピード」を生むか〜 
 オブザーバビリティは、デバッグが必要なコードが 
 システムのどこにあるかを見つけ出すためのもの 
 とにかくユーザー視点を優先した可視化が必要です。 
 ユーザ視点優先での監視によって、より効果的な可視化ができます。 
 “ “ #frontend_o11y 
 ここをふりかえり

  26. 04
 
 ふりかえり 
 
 
 
 
 
 


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

  27. 04
 
 
 
 
 
 
 
 
 実話


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

  28. いずれのパターンにおいても
 
 オブザーバビリティを通して 
 解消を実感できるシーンがあった。 
 「トップスピード」のベースになると言える状態。 
 以下を実現できたか? 


    04
 
 同僚のトップスピードを阻害しないために「迷いをなくす」 
 a. 不具合発生時に何が起こっているのかわからない(該当 /関連システム、該当/関連コード)
 b. ユーザー体験に既存の問題があるかどうかわからない(不具合として検出されないもの) ふりかえり 
 ✔ ✔ #frontend_o11y 

  29. • ユーザー体験を通したデータからプロダクトの状態がわかる 
 イレギュラーもレギュラーも含めたプロダクトの側面を知ることができる 
 
 • 可視化したものが “生きるドキュメント ”

    になる
 可視化されたものが、プロダクトの今を表している(アーキテクチャのオンボ資料になりえる!) 
 
 • 開発者の担当領域や経験値に依存しないシステム理解を後押しできる 
 同じ目線、同じ情報を得ることができる(個人的には、理想的な組織作りに繋がると思っている) 
 05
 取り入れたことで肌で感じたこと 
 #frontend_o11y 

  30. • ユーザー体験を通したデータからプロダクトの状態がわかる 
 イレギュラーもレギュラーも含めたプロダクトの側面を知ることができる 
 
 • 可視化したものが “生きるドキュメント ”

    になる
 可視化されたものが、プロダクトの今を表している(アーキテクチャのオンボ資料になりえる!) 
 
 • 開発者の担当領域や経験値に依存しないシステム理解を後押しできる 
 同じ目線、同じ情報を得ることができる(個人的には、理想的な組織作りに繋がると思っている) 
 05
 
 取り入れたことで肌で感じたこと 
 「フロントエンドエンジニアとして」だけではなく、 
 「基盤を支えるエンジニア」として、「もっとユーザー理解をしたい開発者」として、 
 オブザーバビリティにコミットすることって 
 かなり価値があると思う 
 #frontend_o11y 

  31. 06
 • 同僚の開発のトップスピードを阻害しないために「迷いをなくす」のに、 
 オブザーバビリティは有用 
 
 • 領域に関係せず、プロダクトを開発するエンジニアにとって、 


    オブザーバビリティにコミットするのはかなり意味があること 
 ◦ 特にフロントエンド(クライアントに近い部分を実装担当する人)が意識していること が大事
 ◦ みんなで、ユーザーを知ろう、プロダクトを知ろう、より良いシステムを作ろう 
 まとめ
 #frontend_o11y 

  32. 【再掲】
 満員御礼、ありがとうございます! 
 短い時間ですが、楽しんでいってください 🥳
 登壇者のみなさんも、ご快諾ありがとうございます! 
 [番宣]
 Software Design

    6月号で基盤設計について執筆させていただきました。 o11y 以外の視点についても気になる方は是非お 手にとってみてください。
 なんとその号では @sadnesojisan の特集もあり、お買い得(?)です!
 #frontend_o11y