Tweet
Tweet

Slide 1

Slide 1 text

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


Slide 2

Slide 2 text

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 


Slide 3

Slide 3 text

稀にいただく声 
 #frontend_o11y 


Slide 4

Slide 4 text

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


Slide 5

Slide 5 text

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


Slide 6

Slide 6 text

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


Slide 7

Slide 7 text

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


Slide 8

Slide 8 text

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


Slide 9

Slide 9 text

01
 閑話休題
 #frontend_o11y 


Slide 10

Slide 10 text

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


Slide 11

Slide 11 text

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


Slide 12

Slide 12 text

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 


Slide 13

Slide 13 text

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


Slide 14

Slide 14 text

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


Slide 15

Slide 15 text

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


Slide 16

Slide 16 text

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


Slide 17

Slide 17 text

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


Slide 18

Slide 18 text

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


Slide 19

Slide 19 text

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


Slide 20

Slide 20 text

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


Slide 21

Slide 21 text

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


Slide 22

Slide 22 text

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


Slide 23

Slide 23 text

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


Slide 24

Slide 24 text

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


Slide 25

Slide 25 text

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


Slide 26

Slide 26 text

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


Slide 27

Slide 27 text

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 


Slide 28

Slide 28 text

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 


Slide 29

Slide 29 text

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 


Slide 30

Slide 30 text

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 


Slide 31

Slide 31 text

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 


Slide 32

Slide 32 text

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


Slide 33

Slide 33 text

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 


Slide 34

Slide 34 text

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 


Slide 35

Slide 35 text

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 


Slide 36

Slide 36 text

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 


Slide 37

Slide 37 text

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


Slide 38

Slide 38 text

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


Slide 39

Slide 39 text

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


Slide 40

Slide 40 text

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


Slide 41

Slide 41 text

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


Slide 42

Slide 42 text

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


Slide 43

Slide 43 text

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


Slide 44

Slide 44 text

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


Slide 45

Slide 45 text

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


Slide 46

Slide 46 text

06
 まとめ
 #frontend_o11y 


Slide 47

Slide 47 text

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


Slide 48

Slide 48 text

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


Slide 49

Slide 49 text

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