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