守りから「攻め」の開発へ！New Relicを活用してサービスと共に成長するチームになる

オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜
2023年5月23日（火）19:00〜
LT1-1『守りから「攻め」の開発へ！New Relicを活用してサービスと共に成長するチームになる』

Transcript

1. https://www.dip-net.co.jp/ 1 守りから「攻め」の開発へ！ New Relicを活⽤してサービスと共に成⻑するチームになる ディップ株式会社 小森谷良輝
2. https://www.dip-net.co.jp/ 2 早速ですが
3. https://www.dip-net.co.jp/ 3 こんなこと、ありませんか？
4. https://www.dip-net.co.jp/ 4 こんなこと、ありませんか？ 調査に⼈的コストがかかる システム全体が監視できていない 担当者間で伝言ゲームになる 有識者が手作業で調査している （目grep最強！） 原因の切り分けが難しい… インフラ？ミドルウェア？ ソースコード？はたまた？ サーバーに入れない （ログが見られない…）
5. https://www.dip-net.co.jp/ 5 こんなこと、ありませんか？ 監視ツールが浸透していない アラートの対応方法がわからない アラートが無視されている ツールが複数ある （どれを見たらいいの？） 一部のエンジニアのみ 活用できている 監視ツール向けの 教育までやる余裕がない…
6. https://www.dip-net.co.jp/ 6 こんなこと、ありませんか？ エンジニアのパフォーマンスがわからない 最近動きが悪いような？ 定量的な指標がない 人は増えたけど、成果出てるっけ？ ボトルネックはどこだろう？
7. https://www.dip-net.co.jp/ 7 New Relicを使ってこれらを解決したい！
8. https://www.dip-net.co.jp/ 8 その頑張りを⾒てほしい
9. https://www.dip-net.co.jp/ 9 そんな話です
10. https://www.dip-net.co.jp/ 10 バイトルのユーザーサイト開発 小森谷良輝 最近はスクラムマスター バイトルユーザーサイト開発で 社員エンジニア第一号 Twitter: @ramiyon_chan ディップ株式会社 エンジニア歴6年目 バイトルは20周年！ 2022年4月入社
11. https://www.dip-net.co.jp/ 11 本題の前に
12. https://www.dip-net.co.jp/ 12 宣伝です
13. https://www.dip-net.co.jp/ 13 カジュアル⾯談やってます！ この辺を読み込んでね！
14. https://www.dip-net.co.jp/ 14 さて本題
15. https://www.dip-net.co.jp/ 15 New Relic導⼊の経緯 「ガンガン作れる200⼈体制」（内製化）の推進
16. https://www.dip-net.co.jp/ 16 New Relic導⼊の経緯 「ガンガン作れる200⼈体制」（内製化）の推進 - 多⾓的なシステム全体の「⾒える化」 - ≠インフラ担当から⾒えればいい - ≠パートナーから⾒えればいい - 担当‧領域を限定せず各エンジニアが⾒られるように - 監視から「オブザーバビリティ」へ - （バイトルでは）インフラ担当による監視がメイン - 各エンジニアが価値創造に貢献する主体性がほしい
17. https://www.dip-net.co.jp/ 17 New Relic導⼊の経緯 「ガンガン作れる200⼈体制」（内製化）の推進 「噂によると、New Relicってのがいいらしい…」
18. https://www.dip-net.co.jp/ 18 といって導⼊したものの…
19. https://www.dip-net.co.jp/ 19 困難の数々 - ⾔語のバージョンが古くてAPMが⼊らない - スクリプトではなく、パッケージインストールで対応 - ⼀部機能がそのままでは使えない - Logs in Contextを使うためのライブラリが⼊らない… - アラートが次々と上がる - 裏からアクセスするAPIの処理時間が⻑い - 動作上の問題はないけど… - 既存のアラートはどう移植するの？NRQLって何よ？
20. https://www.dip-net.co.jp/ 20 困難の数々 - エラーが補⾜できない - 握り潰してるじゃん！！ - ログが⾒づらい - アプリのログが構造化されてなく意図した表⽰にならない - アクセスログが独⾃のフォーマットでパースできない
21. https://www.dip-net.co.jp/ 21 でも便利な点もある
22. https://www.dip-net.co.jp/ 22 APM - トランザクションタイム‧Apdexスコアなどを可視化 - 今まで「なんとなく遅いよね」と⾔っていた部分が⼀⽬瞭然 - ⼿動で調査⽤ログを設置するなどの対応が不要に - Key Transactions - 価値のあるページを集中的にモニタリングできる - 開発者も「価値を届ける」部分によりフォーカス
23. https://www.dip-net.co.jp/ 23 APM
24. https://www.dip-net.co.jp/ 24 APM - リリース前後の影響調査が容易に - Deploymentsでリリースタイミングを記録できる - エラーレートの向上‧パフォーマンスの悪化などを確認 - Service LevelsでSLI/SLOを設定できる - サービスの状態が丸わかり - 障害報告の基準にできる
25. https://www.dip-net.co.jp/ 25 分散トレーシング - トランザクションの処理を追うことができる - 複数のサービスを経由しても処理を追うことができる - エラー箇所の特定が容易に 出典 : Find and Fix Issues Fast with Distributed Tracing | New Relic https://newrelic.com/jp/blog/how-to-relic/distributed-tracing-general-availability
26. https://www.dip-net.co.jp/ 26 計測をはじめて、いろいろ⾒えてきた （成熟モデルの「レベル0: Getting Started」かも？）
27. https://www.dip-net.co.jp/ 27 ここで考える
28. https://www.dip-net.co.jp/ 28 スムーズに⾏かない点を考える - バージョンが古い‧アラートが次々と上がるなど - 標準的なシステムの開発/運⽤環境から遠い部分 - アラートが出ているのも「いつか改善したい」箇所 - エラーが補⾜できない‧ログが⾒づらい - 握り潰すこと⾃体が問題 - ログも他プロダクトでは構造化が進んでるし… →いずれ直⾯する問題が表出しているだけでは？
29. https://www.dip-net.co.jp/ 29 スムーズに⾏かない点を考える →いずれ直⾯する問題が表出しているだけでは？ - ちょうどいい機会なので⾒直していこう！ - 導⼊して1年弱、問題は残っているが解決に向けて頑張っている - 今まで（問題だけど）⾒えていなかった点を解消できた
30. https://www.dip-net.co.jp/ 30 便利な点を考える - 障害検知‧調査‧対応をみんなでやる - レトロスペクティブでNew Relicを⾒る「定期点検」を実施 - 属⼈化されている障害対応フローを⽂書化 - 軽い障害の対応を新卒者に任せてみる - パフォーマンスチューニングをみんなでやる - リリース前後にNew Relicをみてパフォーマンスを計測する - チューニングにおすすめのページを教えてくれるので、各⾃で やってみる
31. https://www.dip-net.co.jp/ 31 便利な点を考える - カスタマイズを考える - ダッシュボードを活⽤して運⽤に必要な指標をまとめる - Core Web Vitalsなどユーザー体験 - 応募関係リクエストのエラー - カスタムパラメータの送信 - ユーザー識別⼦を送信して、ヘビーユーザーの⾏動パターンやボトル ネックを分析 - Adobe Analyticsのユーザー識別⼦を送信すると、マーケティング担当と の会話がスムーズに
32. https://www.dip-net.co.jp/ 32 便利な点を考える
33. https://www.dip-net.co.jp/ 33 開発チームのパフォーマンス - Four Keysの計測 - デプロイ時間‧リードタイム‧変更障害率‧復旧時間 - 開発チーム向けにダッシュボードを作成 - Github Actionsを使ってNew Relicにデータを送信する - パフォーマンスのデータを結びつける - サービスと開発チームでパフォーマンスのデータを結びつける ことで、定量的な貢献度を測る試みを実施
34. https://www.dip-net.co.jp/ 34 開発チームのパフォーマンス
35. https://www.dip-net.co.jp/ 35 開発チームのみんなで 障害やパフォーマンスに向き合うようになった （成熟モデルの「レベル1: Reactive」かも？）
36. https://www.dip-net.co.jp/ 36 New Relicを導⼊して1年弱
37. https://www.dip-net.co.jp/ 37 だいぶ形になってきた
38. https://www.dip-net.co.jp/ 38 New Relic導⼊の成果 調査の人的コスト 監視ツールの浸透 エンジニアの パフォーマンス 総合的にデータが見えるため、 調査が早くなった 新卒者にも任せられるほど、調 査のハードルが低くなった アラートを整理することで、必要 なもののみ移植した ツールを見る文化ができて、誰 もが扱えるようになった Four Keysの計測を通じて、数 値としてパフォーマンスがわか るようになった 数値の向上の他に、活用法も 見出していきたい
39. https://www.dip-net.co.jp/ 39 もっともっと良くしたい
40. https://www.dip-net.co.jp/ 40 今後の展望 - 計測を豊かにして、データから企画⽴案へ - データがビジネスにどう紐づいているか？がわかるように - ⾃ら企画⽴案するカッコイイ開発を極めたい - 開発チームのパフォーマンスをKPIにできないか？ - 定量的な評価ができるように活⽤を考えたい - Four Keys以外の指標も追加していきたい - 他プロダクトとの連携‧展開 - 社内勉強会の発⾜など進めたい
41. https://www.dip-net.co.jp/ 41 これからも頑張ります！
42. https://www.dip-net.co.jp/ 42 最後に再び宣伝です
43. https://www.dip-net.co.jp/ 43 カジュアル⾯談やってます！ この辺を読み込んでね！
44. https://www.dip-net.co.jp/ 44 おしまい
45. https://www.dip-net.co.jp/ 45 守りから「攻め」の開発へ！ New Relicを活⽤してサービスと共に成⻑するチームになる ディップ株式会社 小森谷良輝