New Relic_開発・運用チームを生成AIで繋ぐビジネス視点を醸成するオブザーバビリティ戦略

at クラウドWatch Day

Transcript

1. © 2024 New Relic, Inc. All rights reserved. 開発・運用チームを生成 AIが繋ぐ ビジネス視点を熟成する オブザーバビリティ戦略 New Relic Hiroko Umetsu BuySell Technologies Junichi Mitsunaga Takahiro Fukumoto
2. © 2024 New Relic, Inc. All rights reserved. 本セッションの対象者とゴール 対象者 ・複雑なシステムのユーザ満足度や信頼性担保に課題感をお持ちの方 ・ビジネスを高速に促進するためにも開発生産性を上げる方法を検討されている方 ・より効率的な開発と運用の連携に AIの活用を検討されている方 本セッションのゴール ・複雑化するシステムにおいて開発や運用を止めず信頼性やサービス品質を保つ秘訣を知る ・ビジネスとシステムの相関を定量的に把握し、効率的な開発や改善を行うためのノウハウを知る ・開発や運用に携わるメンバーが AIをどのように活用できるか、今後の運用のヒントを知る
3. © 2024 New Relic, Inc. All rights reserved. New Relic会社概要 米国本社 New Relic, Inc. 事業内容 オブザーバビリティプラットフォームの提供 設立 2008年 CEO アシャン・ウィリー (Ashan Willy)　 従業員数 約2,700人 拠点数 16拠点 日本法人 New Relic 株式会社 設立 2018年8月 代表取締役社長 小西 真一朗 出典：株式会社テクノ・システム・リサーチ
4. ©2008–20 New Relic, Inc. All rights reserved Hiroko Umetsu New Relic Solutions Consultant Cloud Consultant for Gaming Industry Infrastructure, Azure
5. © 2024 New Relic, Inc. All rights reserved. 開発・構築は速くなったが アーキテクチャは複雑化 アジリティのある改善や 運用の効率化が課題に デジタルビジネスの 加速を後押しする テクノロジーの進化 モバイル タブレット マイクロ サービス サーバレス コンテナ k8s マネージド サービス APIエコノミー ID連携 マルチクラウド マルチ アカウント オンプレ連携
6. © 2024 New Relic, Inc. All rights reserved. ツールの習得や メンテコストの増加 ツール併用やデータの 付け合わせで効率低下 属人化の加速による 負荷の集中、生産性低下 システムを観測する 良いツールは多く存在 しかし、ツールや データのサイロが起きる
7. © 2024 New Relic, Inc. All rights reserved. リアクティブな障害対応 責任の押し付け合い 非効率な調査 インシデント対応増加 顧客満足度低下 サービス視点・ ユーザー視点での 観測性・品質把握の欠如 インフラ 中心監視 問い合わせ多発 インシデント増 加 責任の押し 付け合い 非効率な 調査 Infra Dev CS ユーザー離れ
8. © 2024 New Relic, Inc. All rights reserved. システム全体を計装 アプリケーション 監視 インフラ 監視 ネットワーク 監視 顧客体験 監視 オブザーバビリティ ビジネス 監視 監視は個々のデータを必 要に応じて収集するが、 オブザーバビリティは全て を収集する “サービスに支障をきたさないようにする ためには、アプリケーションのあらゆる側 面を観察、分析し、あらゆる異常を認識し てすぐに修正する必要があります。” (出 典：CNCF) デジタルビジネス と システムをまとめて観測 できるようにすることで、 ビジネスのシステム問題 とその原因を特定できる 状態に AIを活用し 状況を把握するための アシストとして活用し次世 代の運用へ
9. © 2024 New Relic, Inc. All rights reserved.
10. 開発・運用チームを生成 AIで繋ぐ　 ビジネス視点を醸成するオブザーバビリティ戦略 2024.09.27 10
11. 11 自己紹介 名前 　満永 淳一 所属 　株式会社BuySell Technologies テクノロジー戦略本部 　開発1部　SREグループ マネージャー 名前 　福本 隆弘 所属 　株式会社BuySell Technologies テクノロジー戦略本部 　開発1部　SREグループ
12. 12 事業説明 12
13. 1 3 事業紹介 買取・販売の循環を実現する総合リユースビジネスを展開しています。 お客様のニーズに合わせた各種買取・販売チャネルで、自宅に眠るさまざまな不要なものを、誰かの必要なも のへと変えています。
14. 1 4 バイセルグループのリユースビジネス グループ各社がそれぞれの強みを活かして、買取から販売まで、幅広い商材を取り扱う総合リユースビジネ スを展開しています。 特に出張訪問買取事業 は業界最大級の規模で全国展開する、バイセルの強みです。 着物・切手・貴金属・ ブランド品・時計 等 買取 店舗・催事 店舗 販売 一般 顧客 外部 業者 EC販売 催事 卸販売 オークション ・自社EC（バイセルオンライン 等） ・ECモール（ヤフオク！・楽天 等） 　着物・ブランド品・時計・お酒 等 ・越境EC（ライブコマース 等） 　ジュエリー、ブランド品等 ・百貨店 　着物 ・他社市場、相対取引 等 　貴金属・ジュエリー・切手 等 ・自社市場（タイムレスオークション） 　時計・ジュエリー・ブランド品 等 一般 顧客 出張訪問・ 宅配・店舗 販売顧客 買取顧客 買取商品
15. 事業紹介 15 販売 在庫管理 買取・査定 買取申込 • 紙オペレーションをデジタル化 ◦ 契約書　→　電子データ • ノウハウ化した業務プロセスを自動化・補助 顧客特定 ルーティング プライシング 買取契約書作成 ささげ(採寸・撮影・原稿) 棚卸し 出品管理 販路最適化
16. 16 プロダクト群「バイセルリユースプラットフォーム Cosmos」の開発が進行中 リユースに必要なすべての機能を提供する 「リユースプラットフォーム Cosmos」を開発中です。 Cosmosを活用して、バイセルグループ全体での業務効率改善やデータドリブン経営の深化を目指していま す。 リユースプラットフォーム Cosmos 自社開発のリユース特化業務基幹システムでありサービス群の集合体 買取申込 買取・査定 在庫管理 販売 多様なチャネルで収益最大化 CRM -顧客対応 - 買取種別に応じた最適なシステム構 築 Visit -訪問買取 - Store -店舗買取 - Promas -商材マスタ - Appraisal -専門査定 - Stock -在庫管理 - EXS -販売管理 - Core -会員管理 - Portal -データ利用 - Pocket -データ基盤 - 買取 専門チームによる真贋・査定と連携 査定 申込 効率的な顧客対応 在庫 在庫管理の最適・効率化 販売 データ 各事業プロセスにある データを一元管理 ：基幹システム
17. 17 技術スタック インフラ・開発環境 CI / CD モニタリング アプリケーション UI / モック その他 プロダクトによってその時点で最適な技術・ツールの選定をしています。常にモダンな開発環境を整えていま す。
18. 18 Database Cloud SQL プロジェクトC Virtual Private Cloud Application Cloud Run Clou d Arm or BackEnd Cloud Load Balancing Clou d Arm or GCP構成図 簡易版 Cloud CDN プロジェクトB Database Cloud SQL Cloud Load Balancing Gateway Cloud Run プロジェクトA Database Cloud SQL Application Cloud Run BackEnd Cloud Load Balancing Cloud Armor
19. 19 バイセルSREのミッション 19
20. 20 バイセルのSRE 会社が継続的に利益を上げ続けられる システムの安定運⽤ • システムの信頼性と可⽤性の確保 • プロダクトの⽣産性向上の⽀援 • 堅牢で⻑期運⽤可能なシステムの設計と開発
21. 21 バイセルのSRE 会社が継続的に利益を上げ続けられる システムの安定運⽤ • システムの信頼性と可⽤性の確保 • プロダクトの⽣産性向上の⽀援 • 堅牢で⻑期運⽤可能なシステムの設計と開発
22. 22 利益を上げられるとはどういう状態か？
23. 23 • プロダクトの価値が⾼い状態 利益を上げられるとはどういう状態か？
24. 24 • プロダクトの価値が⾼い状態 プロダクトの価値 = システム利⽤による⽣産性向上 + プロダクトが動いている 利益を上げられるとはどういう状態か？
25. 25 • プロダクトの価値が⾼い状態 プロダクトの価値 = システム利⽤による⽣産性向上 + プロダクトが動いている 利益を上げられるとはどういう状態か？
26. 26 • プロダクトの価値が⾼い状態 プロダクトの価値 = システム利⽤による⽣産性向上 + プロダクトが動いている 「プロダクトが動いている」を維持できる ◦ 事前に問題発⽣を検知できること ◦ 問題が発⽣しても業務へ与える影響が少ないこと 利益を上げられるとはどういう状態か？
27. 27 • プロダクトの価値が⾼い状態 プロダクトの価値 = システム利⽤による⽣産性向上 + プロダクトが動いている 「プロダクトが動いている」を維持できる ◦ 事前に問題発⽣を検知できること ◦ 問題が発⽣しても業務へ与える影響が少ないこと 利益を上げられるとはどういう状態か？ 可観測性を高める
28. 28 利益を上げられるとはどういう状態か？
29. 29 • 顧客価値に注⼒できる時間を増やすこと 利益を上げられるとはどういう状態か？
30. 30 • 顧客価値に注⼒できる時間を増やすこと 顧客価値に注⼒ = トイルの撲滅 + 認知負荷の低減 + 問題解決の時間を短くする 利益を上げられるとはどういう状態か？
31. 31 • 顧客価値に注⼒できる時間を増やすこと 顧客価値に注⼒ = トイルの撲滅 + 認知負荷の低減 + 問題解決の時間を短くする 利益を上げられるとはどういう状態か？
32. 32 • 顧客価値に注⼒できる時間を増やすこと 顧客価値に注⼒ = トイルの撲滅 + 認知負荷の低減 + 問題解決の時間を短くする 認知負荷の低減 ◦ 本質ではないところにかけるコストを減らす ◦ 簡単にプラットフォームを利⽤できる環境を作る 利益を上げられるとはどういう状態か？
33. 33 • 顧客価値に注⼒できる時間を増やすこと 顧客価値に注⼒ = トイルの撲滅 + 認知負荷の低減 + 問題解決の時間を短くする 認知負荷の低減 ◦ 本質ではないところにかけるコストを減らす ◦ 簡単にプラットフォームを利⽤できる環境を作る 利益を上げられるとはどういう状態か？ プロダクトチームの 負荷を最小限にする
34. 34 • プロダクトの価値が⾼いこと ◦ 可観測性を⾼める • 顧客価値に注⼒できる時間を増やすこと ◦ プロダクトチームの負荷を最⼩限にする 利益を上げられるとはどういう状態か？
35. 35 New Relicを使った取り組み ~ システムの状況を把握しやすくする ~ 35
36. 36 • (昔からあるような)インフラ観点のダッシュボードを作成 New Relicを導⼊して可観測性を上げる
37. 37 • チームの定例でダッシュボードを⾒るように • インフラの変動に応じたダッシュボード修正が 成されるようになった • 負荷に対して定量的に⾔及できるようになった チームに起こった変化
38. 38 • チームの定例でダッシュボードを⾒るように • インフラの変動に応じたダッシュボード修正が 成されるようになった • 負荷に対して定量的に⾔及できるようになった …のは⼀部のメンバーのみ。 チームに起こった変化
39. 39 • チームの定例でダッシュボードを⾒るように • インフラの変動に応じたダッシュボード修正が 成されるようになった • 負荷に対して定量的に⾔及できるようになった …のは⼀部のメンバーのみ。 チームに起こった変化 ダッシュボードが見れるチームが 限定された
40. 40 • チームの定例でダッシュボードを⾒るように • インフラの変動に応じたダッシュボード修正が 成されるようになった • 負荷に対して定量的に⾔及できるようになった …のは⼀部のメンバーのみ。 チームに起こった変化 多くのメンバー・チームは ダッシュボードが読めないまま
41. 41 • チームの定例でダッシュボードを⾒るように • インフラの変動に応じたダッシュボード修正が 成されるようになった • 負荷に対して定量的に⾔及できるようになった …のは⼀部のメンバーのみ。 チームに起こった変化 SREが説明すればいい？
42. 42 SREがレポート作成して共有する試み
43. 43 • ブラックボックスな状態から現状把握できるようになる • 定量的にシステムを分析できるようになる • 困難な部分はSREがレポーティングする ◦ ⼀時的な解決は⾒られた 可観測性を⾼めた結果
44. 44 新たな課題 44
45. 45 プラットフォームの歴史
46. 46 プラットフォームの歴史 2 0 2 2 2 0 2 3 2 0 2 4 2021/12~ Promas 2022/9~ Deal-Store 2023/7~ Stock 2022/6~ Core 2022/9~ Deal-Appraisal 2023/7~ Category 2023/6~ 査定アシストAI 2023/4~ Portal　 2023/8~ Deli 2023/10~ CRM 2023/10~ Visit
47. 47 プラットフォームの歴史 2 0 2 2 2 0 2 3 2 0 2 4 2021/12~ Promas 2022/9~ Deal-Store 2023/7~ Stock 2022/6~ Core 2022/9~ Deal-Appraisal 2023/7~ Category 2023/6~ 査定アシストAI 2023/4~ Portal　 2023/8~ Deli 2023/10~ CRM 2023/10~ Visit 2022/10~ SREチーム発足
48. 48 • ダッシュボードの構築コストが⾼い ◦ SREが構築しているため⼿が回らない ◦ ダッシュボードの作成スキルの向上が難しい • レポーティングコストの増加 ◦ SREによるレポーティングは⼿が回らない ◦ 状況観測を⾏うことがプロダクトチームには難しい プロダクトが増えて⾒えてきたもの
49. 49 • ダッシュボードの作成スキルの向上が難しい • 状況観測を⾏うことがプロダクトチームには難しい これらをNew Relic AIで⽀援することによって プロダクトチーム内で解決できるようにならないだろうか？ プロダクトが増えて⾒えてきたもの
50. 50 New Relic AI を活⽤した取り組み ~ ダッシュボード作成負荷を軽減する ~ 50
51. 51 New Relicでのダッシュボード作成
52. 52 • 業務の知識 ◦ 業務特性から何を監視すべきかを選定する • インフラ監視の知識 ◦ インフラ特性から何を監視すべきかを選定する ダッシュボードを作成するのに必要なスキル
53. 53 NRQLというクエリ⾔語を⽤いて表⽰する情報を指定する New Relicでのダッシュボード作成
54. 54 • 業務の知識 ◦ 業務特性から何を監視すべきかを選定する • インフラ監視の知識 ◦ インフラ特性から何を監視すべきかを選定する • NRQLの知識 ◦ 必要な情報を収集するためのクエリを書く ダッシュボードを作成するのに必要なスキル
55. 55 • 業務の知識 ◦ 業務特性から何を監視すべきかを選定する • インフラ監視の知識 ◦ インフラ特性から何を監視すべきかを選定する • NRQLの知識 ◦ 必要な情報を収集するためのクエリを書く ダッシュボードを作成するのに必要なスキル
56. 56 NRQLの学習コストが⾼いためNew Relic AIを活⽤ 目的： リクエストURIのリクエスト回数をカウントしたい アプリケーション名： Stock（Production） 条件：リクエストURIが 'dashboard' を含まないこと グループ：リクエスト URI 出力： 各グループのリクエスト数をカウントし、リクエスト数の降順で並べ替える 期間：1日
57. 57 New Relic AIで作成したダッシュボード(⼀部抜粋)
58. 58 New Relic AIで作成したダッシュボード(⼀部抜粋) AIで全て生成できたわけではない
59. 59 New Relic AIで作成したダッシュボード(⼀部抜粋) AIの生成したものを基本形として 人によるブラッシュアップを実施
60. 60 New Relic AIで作成したダッシュボード(⼀部抜粋) プロンプトを定義すれば 人依存を減らせる
61. 61 New Relic AI を活⽤した取り組み ~ レポーティングコストを下げる ~ 61
62. 62 ダッシュボードを⾒るために必要なスキル • 平常時の傾向の認知 • 指標ごとの相関に対しての知⾒ • 異常が認められたときに起こり得る利⽤者への影響 • どのように⾒られる事を意図して作られたダッシュボードなのか ◦ 配置‧図表表現の⽅法 ◦ フィルタ条件
63. 63 ダッシュボードを⾒るために必要なスキル • 平常時の傾向の認知 • 指標ごとの相関に対しての知⾒ • 異常が認められたときに起こり得る利⽤者への影響 • どのように⾒られる事を意図して作られたダッシュボードなのか ◦ 配置‧図表表現の⽅法 ◦ フィルタ条件AIに説明してもらう
64. 64 ⼈間による説明 1. アクセス数 サービスごとのアクセス数分布。 普段と異なるアクセス傾向が発⽣していないかをチェックする 2. レイテンシ分布 サービスごとのレイテンシ(速度)ヒートマップ。 ユーザ体験が悪化している傾向として、 レイテンシの悪いものだけではなく レイテンシ幅が広い事を認知するための表現 3. 5xx エラー サーバサイドで発⽣している致命的エラーの検出に⽤いる 4. 400 エラー 認証ミスの検出に⽤いる 外部からの攻撃による認証ミスは”Attack”として表⽰している 5. 4xx エラー 403,404といったリソースの配置ミスを主としつつ、 その他の異常なリクエストの検知に⽤いる New Relic AIにダッシュボードの読み⽅を説明させる
65. 65 New Relic AIによる説明 1. アクセス数 タイトル: アクセス数 ビジュアライゼーション: スタックバー クエリ: 異なるサービスのアクセスログの数をカウントします。 2. レイテンシ分布 タイトル: レイテンシ分布 ビジュアライゼーション: ヒートマップ クエリ: 異なるサービスのリモート持続時間（レイテンシ）の ヒストグラムです。 3. 5xx エラー タイトル: 5xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの5xxエラーをカウントし、リストします。 4. 400 エラー タイトル: 400 エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの400エラーをカウントし、リストします。 5. 4xx エラー タイトル: 4xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの4xxエラー（400を除く）をカウントし、 リストします。 New Relic AIにダッシュボードの読み⽅を説明させる
66. 66 New Relic AIによる説明 1. アクセス数 タイトル: アクセス数 ビジュアライゼーション: スタックバー クエリ: 異なるサービスのアクセスログの数をカウントします。 2. レイテンシ分布 タイトル: レイテンシ分布 ビジュアライゼーション: ヒートマップ クエリ: 異なるサービスのリモート持続時間（レイテンシ）の ヒストグラムです。 3. 5xx エラー タイトル: 5xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの5xxエラーをカウントし、リストします。 4. 400 エラー タイトル: 400 エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの400エラーをカウントし、リストします。 5. 4xx エラー タイトル: 4xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの4xxエラー（400を除く）をカウントし、 リストします。 New Relic AIにダッシュボードの読み⽅を説明させる ⼈間による説明 1. アクセス数 サービスごとのアクセス数分布。 普段と異なるアクセス傾向が発⽣していないかをチェックする 2. レイテンシ分布 サービスごとのレイテンシ(速度)ヒートマップ。 ユーザ体験が悪化している傾向として、 レイテンシの悪いものだけではなく レイテンシ幅が広い事を認知するための表現 3. 5xx エラー サーバサイドで発⽣している致命的エラーの検出に⽤いる 4. 400 エラー 認証ミスの検出に⽤いる 外部からの攻撃による認証ミスは”Attack”として表⽰している 5. 4xx エラー 403,404といったリソースの配置ミスを主としつつ、 その他の異常なリクエストの検知に⽤いる
67. 67 New Relic AIによる説明 1. アクセス数 タイトル: アクセス数 ビジュアライゼーション: スタックバー クエリ: 異なるサービスのアクセスログの数をカウントします。 2. レイテンシ分布 タイトル: レイテンシ分布 ビジュアライゼーション: ヒートマップ クエリ: 異なるサービスのリモート持続時間（レイテンシ）の ヒストグラムです。 3. 5xx エラー タイトル: 5xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの5xxエラーをカウントし、リストします。 4. 400 エラー タイトル: 400 エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの400エラーをカウントし、リストします。 5. 4xx エラー タイトル: 4xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの4xxエラー（400を除く）をカウントし、 リストします。 ⼈間による説明 1. アクセス数 サービスごとのアクセス数分布。 普段と異なるアクセス傾向が発⽣していないかをチェックする 2. レイテンシ分布 サービスごとのレイテンシ(速度)ヒートマップ。 ユーザ体験が悪化している傾向として、 レイテンシの悪いものだけではなく レイテンシ幅が広い事を認知するための表現 3. 5xx エラー サーバサイドで発⽣している致命的エラーの検出に⽤いる 4. 400 エラー 認証ミスの検出に⽤いる 外部からの攻撃による認証ミスは”Attack”として表⽰している 5. 4xx エラー 403,404といったリソースの配置ミスを主としつつ、 その他の異常なリクエストの検知に⽤いる New Relic AIにダッシュボードの読み⽅を説明させる 🤔
68. 68 New Relic AIによる説明 1. アクセス数 タイトル: アクセス数 ビジュアライゼーション: スタックバー クエリ: 異なるサービスのアクセスログの数をカウントします。 2. レイテンシ分布 タイトル: レイテンシ分布 ビジュアライゼーション: ヒートマップ クエリ: 異なるサービスのリモート持続時間（レイテンシ）の ヒストグラムです。 3. 5xx エラー タイトル: 5xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの5xxエラーをカウントし、リストします。 4. 400 エラー タイトル: 400 エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの400エラーをカウントし、リストします。 5. 4xx エラー タイトル: 4xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの4xxエラー（400を除く）をカウントし、 リストします。 ⼈間による説明 1. アクセス数 サービスごとのアクセス数分布。 普段と異なるアクセス傾向が発⽣していないかをチェックする 2. レイテンシ分布 サービスごとのレイテンシ(速度)ヒートマップ。 ユーザ体験が悪化している傾向として、 レイテンシの悪いものだけではなく レイテンシ幅が広い事を認知するための表現 3. 5xx エラー サーバサイドで発⽣している致命的エラーの検出に⽤いる 4. 400 エラー 認証ミスの検出に⽤いる 外部からの攻撃による認証ミスは”Attack”として表⽰している 5. 4xx エラー 403,404といったリソースの配置ミスを主としつつ、 その他の異常なリクエストの検知に⽤いる New Relic AIにダッシュボードの読み⽅を説明させる 意図までは汲み取れない
69. 69 New Relic AIによる説明 1. アクセス数 タイトル: アクセス数 ビジュアライゼーション: スタックバー クエリ: 異なるサービスのアクセスログの数をカウントします。 2. レイテンシ分布 タイトル: レイテンシ分布 ビジュアライゼーション: ヒートマップ クエリ: 異なるサービスのリモート持続時間（レイテンシ）の ヒストグラムです。 3. 5xx エラー タイトル: 5xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの5xxエラーをカウントし、リストします。 4. 400 エラー タイトル: 400 エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの400エラーをカウントし、リストします。 5. 4xx エラー タイトル: 4xx エラー ビジュアライゼーション: スタックバーとログテーブル クエリ: 異なるサービスの4xxエラー（400を除く）をカウントし、 リストします。 ⼈間による説明 1. アクセス数 サービスごとのアクセス数分布。 普段と異なるアクセス傾向が発⽣していないかをチェックする 2. レイテンシ分布 サービスごとのレイテンシ(速度)ヒートマップ。 ユーザ体験が悪化している傾向として、 レイテンシの悪いものだけではなく レイテンシ幅が広い事を認知するための表現 3. 5xx エラー サーバサイドで発⽣している致命的エラーの検出に⽤いる 4. 400 エラー 認証ミスの検出に⽤いる 外部からの攻撃による認証ミスは”Attack”として表⽰している 5. 4xx エラー 403,404といったリソースの配置ミスを主としつつ、 その他の異常なリクエストの検知に⽤いる New Relic AIにダッシュボードの読み⽅を説明させる 読み方の説明ではなく 状況評価自体を AIに任せてみる
70. 70 右記のダッシュボードについて ⼈間の評価とNew Relic AIを ⽐較する New Relic AIによるダッシュボード評価
71. 71 ⼈間による評価 • 9/10にpromasのアクセスが急増している New Relic AIによるダッシュボード評価
72. 72 New Relic AIによるダッシュボード評価 ⼈間による評価 • 9/10にpromasのアクセスが急増している • crm,deal-visitのレイテンシ分布が広い
73. 73 New Relic AIによるダッシュボード評価 ⼈間による評価 • 9/10にpromasのアクセスが急増している • crm,deal-visitのレイテンシ分布が広い • visitにおいて503,520エラーが多く、11⽇ にかけて増加している
74. 74 New Relic AIによるダッシュボード評価 ⼈間による評価 • 9/10にpromasのアクセスが急増している • crm,deal-visitのレイテンシ分布が広い • visitにおいて503,520エラーが多く、9/11 にかけて増加している • 9/8に攻撃らしき400エラーが多数確認 されている
75. 75 New Relic AIによるダッシュボード評価 New Relic AIによる評価 ユーザーが現在表⽰しているNew Relicダッシュボードのデータに基づいて、主要な発⾒と次のステップの提案を⽇本語で要約します。 ウィジェット結果の要約: アクセス数（積み上げ棒グラフビジュアライゼーション） アクセス数は、deal-store、crm、deal-visit、promas、deal-appraisal、stock、portal、exs、categoryなどのサービス名で区切られています。 deal-storeサービスは、261アクセスに達する⾼く変動するアクセス数を⽰しています。 crmやdeal-visitなどの他のサービスもかなりのアクセス数を⽰していますが、⼀般的にはdeal-storeよりも低いです。 レイテンシー分布（ヒートマップビジュアライゼーション） レイテンシーデータは異なるサービスに分布しています。 deal-storeとcrmサービスは、潜在的なパフォーマンス問題を⽰す⾼いピークを含む広範囲のレイテンシー値を⽰しています。 promas、deal-appraisal、stockなどの他のサービスもさまざまなレイテンシー分布を⽰しており、promasにはいくつかの⾼いレイテンシーピークがあります。 5xxエラー（積み上げ棒グラフとログテーブルビジュアライゼーション） 5xxエラーは主にvisitサービスに関連しており、特にHTTPステータス520です。 ログテーブルは、詳細なパスとタイムスタンプを含む520エラーの特定のインスタンスを⽰しています。 400エラー（積み上げ棒グラフとログテーブルビジュアライゼーション） 400エラーはサービス名で区切られており、appraisalとattackサービスが最も多いカウントを⽰しています。 ログテーブルは、パスとタイムスタンプを含む400エラーの詳細なインスタンスを提供しており、多くのエラーがappraisalとattackサービスに関連しています。 4xxエラー（積み上げ棒グラフとログテーブルビジュアライゼーション） 4xxエラーには、409、422、404、403などのさまざまなHTTPステータスコードが含まれています。 crmとvisitサービスは、複数の409および422エラーを⽰しています。 ログテーブルは、これらのエラーの特定のインスタンスを提供しており、パスとタイムスタンプが含まれています。 注意が必要な異常な挙動: deal-storeサービスの⾼いアクセス数: deal-storeサービスは⾼く変動するアクセス数を⽰しており、これは⾼い負荷または潜在的な問題を⽰している可能性があります。 deal-storeとcrmサービスのレイテンシーピーク: deal-storeとcrmサービスの顕著なレイテンシーピークは、調査が必要な潜在的なパフォーマンスのボトルネックを⽰唆しています。 visitサービスの頻繁な5xxエラー: visitサービスは複数の520エラーを⽰しており、対処が必要なサーバー側の問題を⽰しています。 appraisalとattackサービスの400エラーの⾼い数: appraisalサービスは多数の400エラーを⽰しており、これはクライアント側の問題または不正なリクエストを⽰している可能性があります。 attackサービスも多数の400エラーを⽰しており、潜在的なセキュリティ脅威または無効なアクセス試⾏を⽰唆しています。 サービス全体のさまざまな4xxエラー: crm、visit、stockなどの異なるサービスで複数の4xxエラーが発⽣しており、クライアントリクエストの問題を解決する必要があります。 提案される次のステップ: deal-storeの⾼いアクセス数を調査する: deal-storeサービスの負荷を分析し、⾼いアクセス数を処理できることを確認してください。 （要点） • deal-storeのアクセスが他に⽐べて多い • crm,deal-storeのレイテンシ分布が広い • visitにおいて5xx, 特に520エラーが多い • attack, appraisalで400エラーが多発して いる
76. 76 New Relic AIによるダッシュボード評価 New Relic AIによる評価（要点） • deal-storeのアクセスが他に⽐べて多い • crm,deal-storeのレイテンシ分布が広い • visitにおいて5xx, 特に520エラーが多い • attack, appraisalで400エラーが多発して いる ⼈間による評価 • 9/10にpromasのアクセスが急増している • crm,deal-visitのレイテンシ分布が広い • visitにおいて503,520エラーが多く、9/11 にかけて増加している • 9/8に攻撃らしき400エラーが多数確認 されている • AIは概況評価が主となり、細かな動きに対しては鈍い • 分布評価においてはdeal-visitではなくdeal-storeを広分布と評価している • 5xx, 4xxエラーの評価については概ね同様
77. 77 New Relic AIによる評価（要点） • deal-storeのアクセスが他に⽐べて多い • crm,deal-storeのレイテンシ分布が広い • visitにおいて5xx, 特に520エラーが多い • attack, appraisalで400エラーが多発して いる New Relic AIによるダッシュボード評価 ⼈間による評価 • 9/10にpromasのアクセスが急増している • crm,deal-visitのレイテンシ分布が広い • visitにおいて503,520エラーが多く、9/11 にかけて増加している • 9/8に攻撃らしき400エラーが多数確認 されている • AIは概況評価が主となり、細かな動きに対しては鈍い • 分布評価においてはdeal-visitではなくdeal-storeを広分布と評価している • 5xx, 4xxエラーの評価については概ね同様 人による評価との差はある
78. 78 New Relic AIによるダッシュボード評価 熟練者 初学者 New Relic AI 事象への知識 ◯ インフラ・実装双方の知 見を持つ ✗ 図形上の異変以上は わからない △ NRQLやダッシュボード 名を元に理解する 事業ドメインの知識 ◯ ◯ 知見のある人を介する必 要はある ✗ RAGによる知識注入は 使用できない 傾向の評価 ◯ △ ノイズに惑わされがち ◯ 数値の評価 ◯ △ 数値をどう採るかの 判断が困難 △ 値の認識ミスが多いが 着目点は良い
79. 79 New Relic AIによるダッシュボード評価 熟練者 初学者 New Relic AI 事象への知識 ◯ インフラ・実装双方の知 見を持つ ✗ 図形上の異変以上は わからない △ NRQLやダッシュボード 名を元に理解する 事業ドメインの知識 ◯ ◯ 知見のある人を介する必 要はある ✗ RAGによる知識注入は 使用できない 傾向の評価 ◯ △ ノイズに惑わされがち ◯ 数値の評価 ◯ △ 数値をどう採るかの 判断が困難 △ 値の認識ミスが多いが 着目点は良い 初学者がNew Relic AIを併用する事で ダッシュボード評価が簡便に
80. 80 プロダクトの価値を⾼めるための取り組みとして、 New Relicによる可観測性の向上を図った • ダッシュボードの作成による可観測性向上 • レポーティングによる認知負荷の低減 → ダッシュボード作成‧レポーティングの属⼈化が発⽣ 属⼈化の解消のためにNew Relic AIの活⽤を試みた • 観測⽤ダッシュボードの構築補助 • ダッシュボードの読解法‧概況説明 → AIによる成果は⼀定あるが、AIのみで完結とはいかない まとめ
81. 81 SREとして • ダッシュボードのコード化による可観測性構築の容易化 • 定期的な負荷レポートのAIを活⽤した作成 New Relic AIへの期待 • RAGによる事業ドメイン‧補⾜情報の付与  • ⽇本語による出⼒(現状は英語出⼒になるため、別途翻訳させるプロンプトが必要) • Variablesを使ったダッシュボードへの対応 今後の展望
82. THANK YOU 82
83. © 2024 New Relic, Inc. All rights reserved. ご質問のある方はこの後ブースへ！ New Relicブースにてご質問をお受けします！ デモをご覧になりたい方もぜひお越しください。
84. © 2024 New Relic, Inc. All rights reserved. お手元のアンケートに ご回答をお願いします！
85. © 2024 New Relic, Inc. All rights reserved.