New Relicを活用したシステム監視の強化とオブザーバビリティ向上

NRUG (New Relic User Group) 名古屋 Vol.0（https://nrug-nagoya.connpass.com/event/327257/） の登壇資料です。

Transcript

1. © 2024 Ateam Inc. New Relicを活⽤したシステム監視の強化と オブザーバビリティ向上 〜チームの⽴ち上げから、オブザーバビリティ向上に向けて〜 株式会社エイチームライフデザイン / 後藤 卓 2024.10.04 NRUG 名古屋 Vol.0 #nrugnagoya
2. © 2024 Ateam Inc. 2 ⽬次 • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと
3. © 2024 Ateam Inc. • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと 3 ⽬次
4. © 2024 Ateam Inc. ⾃⼰紹介 • 所属：基盤技術グループ • 役割：インフラや監視、O11yをいい感じにする • 興味/関⼼：SRE, O11y, Monitoring, IaC, Cloud • ひとこと：5年ぶりの社外登壇で震えてます 4 後藤 卓（ごとう すぐる） 株式会社エイチームライフデザイン Webエンジニア
5. © 2024 Ateam Inc. • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと 5 ⽬次
6. © 2024 Ateam Inc. 6 事業領域
7. © 2024 Ateam Inc. 7 事業内容
8. © 2024 Ateam Inc. 8 サービス紹介 ※ 2024.9.26時点の情報
9. © 2024 Ateam Inc. 9 サービス紹介 ※ 2024.9.26時点の情報
10. © 2024 Ateam Inc. • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと 10 ⽬次
11. © 2024 Ateam Inc. 11 本⽇の発表内容について • 「組織やシステムの課題をどう解決してきたか∕していくか」が中⼼の内容です ◦ システム監視の強化に向けて取り組んだできたこと ◦ オブザーバビリティを向上させるために取り組んでいきたいこと（予定） ◦ また、それらに取り組むための専任チームの⽴ち上げ • 取り組み中⼼にはNew Relicがありますが、New Relic⾃体の機能や技術的な要素は薄めです 󰢛 • 時間の都合上、⽤語の解説は最低限にしています󰢛
12. © 2024 Ateam Inc. • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと 12 ⽬次
13. © 2024 Ateam Inc. • 特定領域において、組織横断的に⽀援し続けるための体制構築 ◦ (1)「基盤技術グループ」の設⽴ • 基盤技術グループから開発チームへの⽀援活動 ◦ (2) 「システム監視」の基礎知識を習得 ◦ (3) 既存の監視を⾒直し 13 「これまで」やってきたこと
14. © 2024 Ateam Inc. 「これまで」やってきたこと まずは体制を整える：(1)「基盤技術グループ」の設⽴ • ストリームアラインドチーム(開発チーム)の⽀援を⽬的に設⽴ ◦ チームトポロジーにおけるイネイブリングチーム ◦ ファシリテーションモードをベースとして活動 ◦ 複数の開発チームを組織横断的に⽀援する ◦ インフラ技術、システム監視に関する⽀援が主な役割領域 ◦ 役割領域において、⼿薄な開発チームから⽀援していく • 背景/狙い ◦ 解決には中⻑期的な取り組みが必要な課題が多く存在 ◦ チームを⽴ち上げ、中⻑期的に取り組むための体制を構築 14
15. © 2024 Ateam Inc. 「これまで」やってきたこと まずは体制を整える：(1)「基盤技術グループ」の設⽴ • ストリームアラインドチーム(開発チーム)の⽀援を⽬的に設⽴ ◦ チームトポロジーにおけるイネイブリングチーム ◦ ファシリテーションモードをベースとして活動 ◦ 複数の開発チームを組織横断的に⽀援する ◦ インフラ技術、システム監視に関する⽀援が主な役割領域 ◦ 役割領域において、⼿薄な開発チームから⽀援していく • 背景/狙い ◦ 解決には中⻑期的な取り組みが必要な課題が多く存在 ◦ チームを⽴ち上げ、中⻑期的に取り組むための体制を構築 15 【補⾜】 • チーム⽴ち上げ時、開発チームに 対してヒアリングを実施 • 発⾒した課題の多くがインフラ技術、シ ステム監視に関連するものだった
16. © 2024 Ateam Inc. 「これまで」やってきたこと まずは体制を整える：(1)「基盤技術グループ」の設⽴ • ストリームアラインドチーム(開発チーム)の⽀援を⽬的に設⽴ ◦ チームトポロジーにおけるイネイブリングチーム ◦ ファシリテーションモードをベースとして活動 ◦ 複数の開発チームを組織横断的に⽀援する ◦ インフラ技術、システム監視に関する⽀援が主な役割領域 ◦ 役割領域において、⼿薄な開発チームから⽀援していく • 背景/狙い ◦ 解決には中⻑期的な取り組みが必要な課題が多く存在 ◦ チームを⽴ち上げ、中⻑期的に取り組むための体制を構築 16 【背景】 • 2022年に⼦会社統合（3社→1社） • ⼦会社時代のスタイルや⽂化、 その後の⼈事異動等により、 チーム間で能⼒ギャップが⽣じていた
17. © 2024 Ateam Inc. Appendix チームトポロジーの⽤語解説 17 • ストリームアラインドチーム ◦ ビジネスの主な変更フロー（ストリーム）に沿って配置される、いわゆる開発チーム • イネイブリングチーム ◦ 他のチームが新しい技術やスキルを⾝につけるのを⽀援するチーム ◦ ストリームアラインドチームの認知負荷を下げるために存在する • ファシリテーションモード ◦ ⼀⽅のチームが他⽅のチームが新しい技術を⾝につけたり学習したりするためにファシ リテーションする ◦ 他のチームの障害を取り除く 引⽤元: https://www.ryuzee.com/contents/blog/14566
18. © 2024 Ateam Inc. 「これまで」やってきたこと 何ごとも基礎から：(2)「システム監視」の基礎知識を習得 18 • 知識習得のために「⼊⾨ 監視」の輪読会を開催 ◦ 基盤技術グループが主催、⽀援対象の開発チームが参加 ◦ 全員参加型、ディスカッションを中⼼とした進め⽅ ◦ New Relicを活⽤するための前準備的な取り組み • 背景/狙い ◦ ⽀援対象のチームはシステム監視の知識が不⾜しており、 システム監視の不備による検知の遅れが多発していた ◦ 効果的な監視の実装、アンチパターンを踏まないためにも、 多少時間はかかるが基礎知識の習得に注⼒
19. © 2024 Ateam Inc. 【補⾜】 • 基盤技術グループは輪読会のファシリ テーション役 • 開発チームが独り⽴ちできるよう、 リード、アシストを⾏う 「これまで」やってきたこと 何ごとも基礎から：(2)「システム監視」の基礎知識を習得 • 知識習得のために「⼊⾨ 監視」の輪読会を開催 ◦ 基盤技術グループが主催、⽀援対象の開発チームが参加 ◦ 全員参加型、ディスカッションを中⼼とした進め⽅ ◦ New Relicを活⽤するための前準備的な取り組み • 背景/狙い ◦ ⽀援対象のチームはシステム監視の知識が不⾜しており、 システム監視の不備による検知の遅れが多発していた ◦ 効果的な監視の実装、アンチパターンを踏まないためにも、 多少時間はかかるが基礎知識の習得に注⼒ 19
20. © 2024 Ateam Inc. 【補⾜】 • 「全員参加」はあくまでスタンス • 実際には、開発チームから選抜メン バーのみ参加 • 参加メンバーは得た知識を持ち帰り、 開発チーム内に伝搬させる 「これまで」やってきたこと 何ごとも基礎から：(2)「システム監視」の基礎知識を習得 • 知識習得のために「⼊⾨ 監視」の輪読会を開催 ◦ 基盤技術グループが主催、⽀援対象の開発チームが参加 ◦ 全員参加型、ディスカッションを中⼼とした進め⽅ ◦ New Relicを活⽤するための前準備的な取り組み • 背景/狙い ◦ ⽀援対象のチームはシステム監視の知識が不⾜しており、 システム監視の不備による検知の遅れが多発していた ◦ 効果的な監視の実装、アンチパターンを踏まないためにも、 多少時間はかかるが基礎知識の習得に注⼒ 20
21. © 2024 Ateam Inc. 「これまで」やってきたこと 素早く効果を出す：(3) 既存の監視を⾒直し • 既存の監視を⾒直すためSynthetic Monitor（外形監視）を整備 ◦ 「ユーザーがWebサイトを利⽤できない」といった症状を監視、検知することが⽬的 ▪ Synthetic Monitorはその症状を監視するための⼿っ取り早い⼿段（お⼿軽） ▪ 「原因ではなく ”ビジネス上の機会損失に繋がる症状” を監視しよう」 ◦ TerraformによるIaCの整備も同時に実施 ▪ IaCやTerraformのオンボーディングを⾏いつつ実施、開発チームの⾃⾛を⽀援 • 背景/狙い ◦ べき論をいえば、もっと効果的な監視の⼿法や⼿段はある ◦ 開発チームの⼯数は有限...事業開発を優先しつつ取り組むため、導⼊しやすい⼿段を選択 21
22. © 2024 Ateam Inc. • 「基盤技術グループ」の設⽴ ◦ Good ：特定領域の課題解決において集中して取り組める体制を作れた、取り組めた ◦ Bad ：開発チームの状況次第では技術⽀援の時間を確保できず、思うように進まない • 「システム監視」の基礎知識を習得 ◦ Good ：開発チーム⾃ら解決⽅法を考えられるようになり、⽂化醸成にも繋がった ◦ Bad ：輪読会の特性上、進⾏のスピードは遅め • 既存の監視を⾒直し ◦ Good ：早い段階でIaCを整備したこともあり、素早く効果的な監視を整備できた ◦ Bad ：⼿軽さを優先した⾒直しに留まっているため、改善の余地は残っている状態 22 「これまで」やってきたこと “やってきたこと” による結果、効果
23. © 2024 Ateam Inc. • ⾃⼰紹介 • 会社紹介 • 本⽇の発表内容について • 「これまで」やってきたこと • 「これから」やっていきたいこと 23 ⽬次
24. © 2024 Ateam Inc. 24 「これから」やっていきたいこと 「オブザーバビリティの向上」
25. © 2024 Ateam Inc. “システムがどのような状態になったとしても、それがどんなに 斬新で奇妙なものであっても、どれだけ理解し説明できるかの 尺度です。（中略） もし、新しいコードをデプロイする必要がなく、どんなに斬新 で奇妙な状態でも理解できるなら、オブザーバビリティがある と⾔えます。” 「これから」やっていきたいこと 「オブザーバビリティ」「オブザーバビリティが⾼い状態」とは 25 引⽤元: 「オブザーバビリティ‧エンジニアリング - 1章 オブザーバビリティとは？」 「システムの内部状態を外部から観測可能にする能⼒」のこと
26. © 2024 Ateam Inc. 「これから」やっていきたいこと オブザーバビリティを向上させたい背景 • (1) トラブルシュートしづらい、属⼈化してしまう問題 • (2) 監視システムが分散している問題 26
27. © 2024 Ateam Inc. 「これから」やっていきたいこと (1) トラブルシュートしづらい、属⼈化してしまう問題 • 事業成⻑と共に肥⼤化してきたレガシーシステム • システム全体の⾒通しが悪く、トラブル発⽣時に原因箇所の特定がしづらい • トラブルシュートが経験豊富なベテランエンジニア頼りになりがち（属⼈性） • ベテランエンジニアだとしても特定が難しい、時間を要してしまう場合も 27 引⽤元: https://www.businessinsider.jp/post-1652 ？ ？ ？ ？ ？ ？
28. © 2024 Ateam Inc. 「これから」やっていきたいこと (1) トラブルシュートしづらい、属⼈化してしまう問題 28 • 事業成⻑と共に肥⼤化してきたレガシーシステム • システム全体の⾒通しが悪く、トラブル発⽣時に原因箇所の特定がしづらい • トラブルシュートが経験豊富なベテランエンジニア頼りになりがち（属⼈性） • ベテランエンジニアだとしても特定が難しい、時間を要してしまう場合も システム⾃体の問題もあるが‧‧‧ オブザーバビリティが低いことも要因としてあるのでは？ 従来のモニタリングでは、対応しきれない💦 O11y
29. © 2024 Ateam Inc. • システム全体の⾒通しが悪く、トラブル発⽣時に原因箇所の特定がしづらい 「これから」やっていきたいこと こうしていきたい 29 • オブザーバビリティを向上させ、システムの動作状態を探索可能にする • ex. ◦ 動作状態を把握するためのデータの取得（計装） ◦ Service Mapによるシステム全体の俯瞰 ◦ Distributed Tracing（分散トレーシング）による追跡
30. © 2024 Ateam Inc. Appendix: “Service Mapによるシステム全体の俯瞰” のイメージ 30 引⽤元: https://docs.newrelic.com/jp/docs/new-relic-solutions/new-relic-one/ui-data/service-maps/service-maps/
31. © 2024 Ateam Inc. 「これから」やっていきたいこと こうしていきたい 31 • トラブルシュートが経験豊富なベテランエンジニア頼りになりがち • ベテランエンジニアだとしても特定が難しい、時間を要してしまう場合も • オブザーバビリティを向上させ、経験の浅いエンジニアでも探索、問題の 診断を可能な状態にする ◦ トラブルシュートの⺠主化 ◦ ⼈に依存させない、組織的にスケール可能な状態にする • 問題の早期解決に貢献し、MTTR/MTTIの削減に繋げる
32. © 2024 Ateam Inc. 「これから」やっていきたいこと こうしていきたい “モニタリングベースのアプローチでは、年功序列が知識への鍵である という考えに基づいて、チームが⽅向づけられることがよくありま す。チームに最も⻑く在籍しているエンジニアが、チーム最⾼の デバッガーであり、最後の砦のデバッガーとなることが多いのです。 （中略） 逆に、オブザーバビリティを実践しているチームは、根本的に違う⽅ 向に傾きます。オブザーバビリティツールでは、チーム内の最⾼の デバッガーは、通常、最も好奇⼼の強いエンジニアです。” 32 引⽤元: 「オブザーバビリティ‧エンジニアリング - 2章 オブザーバビリティとモニタリングにおけるデバッグ⽅法の違い」
33. © 2024 Ateam Inc. 「これから」やっていきたいこと (2) 監視システムが分散している問題 • ログ、トレース、メトリクスといった、オブザーバビリティを⽀えるPrimary Signalsが 複数の監視システムに分散している • 複雑なシステムに加えて、Primary Signalsが分散して保存されており、 トラブルシュートがしづらい（探索しづらい）、時間が掛かってしまう 33 ログ トレース メトリクス
34. © 2024 Ateam Inc. • ログ、トレース、メトリクスといった、オブザーバビリティを⽀えるPrimary Signalsが 複数の監視システムに分散している 「これから」やっていきたいこと こうしていきたい 34 • New Relicに集め、関連付けることで、オブザーバビリティを向上させる • （将来的には）監視システムをNew Relicに統合 トレース ログ メトリクス メトリクス トレース ログ
35. © 2024 Ateam Inc. 35 「これから」やっていきたいこと 「オブザーバビリティの向上」を どう進めていくか
36. © 2024 Ateam Inc. 「これから」やっていきたいこと 「オブザーバビリティの向上」をどう進めていくか • 基本⽅針 ◦ ⼩さく始めて、⼤きくしていく ▪ 計装 → New Relic上での⾒え⽅を確認 → 計装を追加 ‧‧‧の繰り返し • その理由 ◦ 計装に関する知識、ノウハウが薄い ▪ New Relicの機能で？OpenTelemetryで？ ◦ 我々が求める「オブザーバビリティの⾼さ」「向上させるための道のり」が不明確 ▪ 求める状態を模索しつつ、コストも気にしながら、探索的に進めていく ▪ なんにせよ “オブザーバビリティにはお⾦がかかる” 問題もある 36
37. © 2024 Ateam Inc. • まずは、Observability成熟度モデルの “1（Reactive）” を⽬指して進んでいく 「これから」やっていきたいこと 「オブザーバビリティの向上」をどう進めていくか 37 引⽤元: https://speakerdeck.com/newrelic2023/20230523-findy-newrelic-o11y1?slide=30
38. © 2024 Ateam Inc. ご清聴ありがとうございました 38