New Relic で始めるアプリプラットフォームのオブザーバビリティ

こちらのイベントで登壇した資料になります
https://yappli.connpass.com/event/359014/

# 発表内容
近年、オブザーバビリティという概念が広く注目されており、モバイルアプリケーションの領域においても、その重要性が高まってきています。

ヤプリではNew Relicを導入し、モバイルアプリのオブザーバビリティ基盤を構築しています。本発表では、その導入背景からCI/CDとの連携、そして実際の運用体制についてご紹介します。本発表が、モバイルにおけるオブザーバビリティについて皆様と一緒に考えるきっかけとなれば幸いです。

#YapTechPlayground

Transcript

1. New Relic で始める アプリプラットフォームの オブザーバビリティ YapTech Playground #1 モバイルアプリ開発編 #YapTechPlayground
2. SPEAKER 株式会社ヤプリ プロダクト開発本部 開発1部 iOSグループ 菅 直之（Nao-RandD / ナオランド） • 2022年に中途⼊社。iOSエンジニア歴 5年 • ノーコードアプリプラットフォーム 「Yappli」の保守‧新規開発, R&D領域 @Nao_RandD
3. みなさん オブザーバビリティ してますか？
4. 今回はヤプリで オブザーバビリティ を 整備した背景と流れをご紹介
5. 1. オブザーバビリティ とは？ 2. New Relic 導⼊までの流れ 3. 運⽤の「これまで」と「これから」 🗣 本⽇お話しすること
6. オブザーバビリティ とは？
7. 可観測性のこと（Observe + Ability = 観測する能⼒） オブザーバビリティとは？ オブザーバビリティ‧エンジニアリング： https://www.oreilly.co.jp/books/9784814400126/
8. 可観測性のこと（Observe + Ability = 観測する能⼒） • 監視とは異なることに注意 ◦ 監視は「何が起きたかを⾒続けること」 ◦ 対象としきい値を設定しておき、超えたところで アラートとして通知する仕組みは「結果」しか得られない オブザーバビリティとは？ オブザーバビリティ‧エンジニアリング： https://www.oreilly.co.jp/books/9784814400126/
9. 可観測性のこと（Observe + Ability = 観測する能⼒） • 監視とは異なることに注意 ◦ 監視は「何が起きたかを⾒続けること」 ◦ 対象としきい値を設定しておき、超えたところで アラートとして通知する仕組みは「結果」しか得られない • 何らかの異常発⽣時に 通知だけでなくどこで‧なぜ 起こったのか把握する能⼒ ‧仕組み オブザーバビリティとは？ オブザーバビリティ‧エンジニアリング： https://www.oreilly.co.jp/books/9784814400126/
10. New Relic 導⼊までの流れ
11. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 □ ヤプリで実現したいオブザーバビリティ □ SDKの組み込み □ ビルド基盤での考慮
12. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 □ ヤプリで実現したいオブザーバビリティ □ SDKの組み込み □ ビルド基盤での考慮
13. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 New Relic 導⼊までの流れ
14. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 ひとつのコードベースで約900のアプリ（2025年2⽉時点）を⽣成している New Relic 導⼊までの流れ
15. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 ひとつのコードベースで約900（2025年2⽉時点）のアプリを⽣成している New Relic 導⼊までの流れ ビルド基盤の仕組み‧プラットフォームの開発に ご興味ある⽅はぜひ！💡
16. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 ひとつのコードベースで約900のアプリ（2025年2⽉時点）を⽣成している New Relic 導⼊までの流れ
17. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 ひとつのコードベースで約900のアプリ（2025年2⽉時点）を⽣成している → ひとつの不具合 が 複数のアプリ に影響する New Relic 導⼊までの流れ 不具合💥 💥 💥 💥
18. ヤプリで実現したいオブザーバビリティ 前提：ノーコードアプリプラットフォーム「Yappli」を提供 ひとつのコードベースで約900のアプリ（2025年2⽉時点）を⽣成している New Relic 導⼊までの流れ 特定の1アプリだけでなく ヤプリで運⽤しているアプリ全体について 利⽤状況が観測できること
19. ヤプリで実現したいオブザーバビリティ 導⼊する選択肢としては2つ New Relic 導⼊までの流れ
20. ヤプリで実現したいオブザーバビリティ 導⼊する選択肢としては2つ Firebase Crashlytics + Firebase Performance New Relic New Relic 導⼊までの流れ
21. ヤプリで実現したいオブザーバビリティ 導⼊する選択肢としては2つ Firebase Crashlytics + Firebase Performance ◦ アプリごとにプロジェクト管理が必要になる ◦ Big Queryに出⼒することで全体の分析が可能になる New Relic New Relic 導⼊までの流れ Export Firebase Crashlytics data to BigQuery： https://firebase.google.com/docs/crashlytics/bigquery-export
22. ヤプリで実現したいオブザーバビリティ 導⼊する選択肢としては2つ Firebase Crashlytics + Firebase Performance New Relic ◦ ひとつの管理画⾯で全体の観測とアプリ単位の情報を取得できる ◦ ユースケースに応じてダッシュボードの雛形が存在する ◦ 他チームで採⽤されておりベンダーとの関係値が築けている New Relic 導⼊までの流れ
23. ヤプリで実現したいオブザーバビリティ 導⼊する選択肢としては2つ Firebase Crashlytics + Firebase Performance New Relic New Relic 導⼊までの流れ ⭕ ヤプリでは New Relic を採⽤
24. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ✅ ヤプリで実現したいオブザーバビリティ □ SDKの組み込み □ ビルド基盤での考慮
25. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ☑ ヤプリで実現したいオブザーバビリティ □ SDKの組み込み □ ビルド基盤での考慮
26. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ☑ ヤプリで実現したいオブザーバビリティ □ SDKの組み込み □ ビルド基盤での考慮 🍎 iOSで New Relic に実装した 内容をご紹介
27. SDKの組み込み New Relic 導⼊までの流れ 対応したこと • iOS向けに提供されたSDKを利⽤する • 初期化処理や、必要に応じて計測情報を設定する実装を追加する newrelic-ios-agent： https://github.com/newrelic/newrelic-ios-agent
28. SDKの組み込み New Relic 導⼊までの流れ 初期化： • トークンを渡して start メソッドを呼ぶだけで計測が⾏える newrelic-document： https://docs.newrelic.com/docs/mobile-monitoring/new-relic-mobile-ios/ios-sdk-api/ios-sdk-api-guide/
29. SDKの組み込み New Relic 導⼊までの流れ 初期化： • トークンを渡して start メソッドを呼ぶだけで計測が⾏える import NewRelic // トークンを渡して計測開始 NewRelic.start(withApplicationToken: "[New Relic Token]") newrelic-document： https://docs.newrelic.com/docs/mobile-monitoring/new-relic-mobile-ios/ios-sdk-api/ios-sdk-api-guide/
30. SDKの組み込み New Relic 導⼊までの流れ import NewRelic NewRelic.start(withApplicationToken: "[New Relic Token]") New Relic モバイル: グループクラッシュタブ： https://docs.newrelic.com/jp/docs/errors-inbox/mobile-tab/ 初期化： • トークンを渡して start メソッドを呼ぶだけで計測が⾏える
31. SDKの組み込み カスタム属性をセット： • デフォルトの属性（OSバージョンやアプリバージョンなど） 以外に計測で必要なカスタム属性を追加できる New Relic 導⼊までの流れ Create a custom attribute： https://docs.newrelic.com/jp/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/create-attribute/#ios
32. SDKの組み込み カスタム属性をセット： • デフォルトの属性（OSバージョンやアプリバージョンなど） 以外に計測で必要なカスタム属性を追加できる New Relic 導⼊までの流れ // アプリを識別する情報をセット NewRelic.setAttribute( "SKU", value: "XXXXXXXXX" // アプリの識別子 ) Create a custom attribute： https://docs.newrelic.com/jp/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/create-attribute/#ios
33. カスタム属性をセット： • デフォルトの属性（OSバージョンやアプリバージョンなど） 以外に計測で必要なカスタム属性を追加できる SDKの組み込み New Relic 導⼊までの流れ // アプリを識別する情報をセット NewRelic.setAttribute( "SKU", value: "XXXXXXXXX" // アプリの識別子 )
34. パンくずリストによる⾏動分析： • ユーザーがどういった⾏動をしたかを計測できる SDKの組み込み New Relic 導⼊までの流れ Record breadcrumbs： https://docs.newrelic.com/docs/mobile-monitoring/new-relic-mobile/mobile-sdk/record-breadcrumb/
35. パンくずリストによる⾏動分析： • ユーザーがどういった⾏動をしたかを計測できる SDKの組み込み // 処理A NewRelic.recordBreadcrumb( "処理A", // パンくずに記録する名称 attributes: attributes // 必要な属性追加 ) ・・・ // 処理B NewRelic.recordBreadcrumb( "処理B", // パンくずに記録する名称 attributes: attributes // 必要な属性追加 ) ・・・ // ここでクラッシュ 💥 （処理 A→ 処理B を踏んでクラッシュしたことがわかる ） New Relic 導⼊までの流れ
36. パンくずリストによる⾏動分析： • ユーザーがどういった⾏動をしたかを計測できる SDKの組み込み New Relic 導⼊までの流れ
37. パンくずリストによる⾏動分析： • ユーザーがどういった⾏動をしたかを計測できる SDKの組み込み New Relic 導⼊までの流れ クラッシュまでの ⾏動が追える ✨ どのユーザーが、どんな⾏動をして クラッシュしたかわかるため とても便利
38. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ☑ ヤプリで実現したいオブザーバビリティ ✅ SDKの組み込み □ ビルド基盤での考慮
39. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ☑ ヤプリで実現したいオブザーバビリティ ☑ SDKの組み込み □ ビルド基盤での考慮
40. ビルド基盤への組み込み 組み込み後、無事にクラッシュを検知 ✨ New Relic 導⼊までの流れ
41. 組み込み後、無事にクラッシュを検知 ✨ ビルド基盤への組み込み New Relic 導⼊までの流れ
42. 組み込み後、無事にクラッシュを検知 ✨ ビルド基盤への組み込み New Relic 導⼊までの流れ ⾮常に⾒やすいスタックトレースですね😊
43. 組み込み後、無事にクラッシュを検知 ✨ ビルド基盤への組み込み New Relic 導⼊までの流れ ⾮常に⾒やすいスタックトレースですね シンボリケーション されてない 😇
44. 組み込み後、無事にクラッシュを検知 ✨ ビルド基盤への組み込み New Relic 導⼊までの流れ ✅ ビルド時にdSYMファイルを   New Relicにアップロードする
45. New Relic 導⼊までの流れ 導⼊における⽬的と運⽤開始までのできごとを共有 ☑ ヤプリで実現したいオブザーバビリティ ☑ SDKの組み込み ✅ ビルド基盤での考慮
46. 運⽤の「 これまで 」と「 これから 」
47. 現在の運⽤体制 以下を元に体制を整備している 1. Slack でのクラッシュ通知 2. 未対応のクラッシュをチケット化 運⽤の「 これまで 」と「 これから 」
48. 現在の運⽤体制 以下を元に体制を整備している 1. Slack でのクラッシュ通知 ◦ 2種類の通知 i. 1時間で発⽣したクラッシュの通知 ii. 24時間以内で発⽣件数が200件以上のクラッシュの通知 運⽤の「 これまで 」と「 これから 」
49. 現在の運⽤体制 以下を元に体制を整備している 1. Slack でのクラッシュ通知 2. 未対応のクラッシュをチケット化 ◦ 定例でメンバーにアサインして緊急度など⼀次調査まで⾏う ◦ 緊急度に応じてインシデント対応や各所への連携を進める 運⽤の「 これまで 」と「 これから 」
50. 現在の運⽤体制 以下を元に体制を整備している 1. Slack でのクラッシュ通知 2. 未対応のクラッシュをチケット化 運⽤の「 これまで 」と「 これから 」 ✅ 定点観測： • 異常事態を早めに検知して対応できる • 問い合わせで初めて問題に気づく状態をなくす ✅ チケット管理 • 緊急度に応じてメンバーにアサインして進められる
51. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 • オブザーバビリティもタダじゃない • 「オブザーバビリティは必要」という抽象的なものでは不⼗分 • 費⽤をかけてでもやる意義があることを⽰す指標を定める 運⽤の「 これまで 」と「 これから 」
52. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 1. 事前検知によって問題解決できること 2. アプリ全体の集計情報から復旧が判断できること 運⽤の「 これまで 」と「 これから 」
53. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 1. 事前検知によって問題解決できること 2. アプリ全体の集計情報から復旧が判断できること 運⽤の「 これまで 」と「 これから 」
54. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 1. 事前検知によって問題解決できること ◦ クライアントの問い合わせ前に問題を検知して解決を⽬指す 運⽤の「 これまで 」と「 これから 」
55. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 1. 事前検知によって問題解決できること a. クライアントの問い合わせ前に問題を検知して解決を⽬指す 運⽤の「 これまで 」と「 これから 」 事前検知で解決した件数の 積み上げから有効性を提⽰する
56. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 1. 事前検知によって問題解決できること 2. アプリ全体の集計情報から復旧が判断できること 運⽤の「 これまで 」と「 これから 」
57. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 2. アプリ全体の集計情報から復旧が判断できること ◦ 修正バージョンリリース後のアップデート判断は クライアント依存 になる 運⽤の「 これまで 」と「 これから 」
58. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 2. アプリ全体の集計情報から復旧が判断できること ◦ 修正バージョンリリース後のアップデート判断はクライアント依存になる 運⽤の「 これまで 」と「 これから 」 💥 💥 💥 不具合💥
59. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 2. アプリ全体の集計情報から復旧が判断できること ◦ 修正バージョンリリース後のアップデート判断はクライアント依存になる 運⽤の「 これまで 」と「 これから 」 アップデート済み 💥 解消 ✅ ✅ ✅ 未アップデート😢 （まだ問題がある状態） アップデート済み
60. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 2. アプリ全体の集計情報から復旧が判断できること ◦ 修正バージョンリリース後のアップデート判断はクライアント依存になる ◦ クラッシュ件数から現在のアプリ状態を把握して提案できる数値を得る （たとえば、クラッシュの減少率が50%未満なら強制アップデートなどをクライアント提案など） 運⽤の「 これまで 」と「 これから 」
61. 今後の運⽤体制 導⼊の有効性を⽰す具体的な⽬標 2. アプリ全体の集計情報から復旧が判断できること a. 修正バージョンリリース後のアップデート判断はクライアント依存になる b. クラッシュ件数から現在のアプリ状態を把握して提案する数値を得る より多くのエンドユーザーの体験向上のために 集計からアップデート施策を提案できることを⽬指す 運⽤の「 これまで 」と「 これから 」
62. まとめ 本⽇お話ししたこと • オブザーバビリティの導⼊背景： ◦ どのような効果や要件を求めて導⼊したか • New Relic SDK の組み込み‧考慮点： ◦ 実装に組み込んだ機能や、ビルド基盤で必要だった考慮点について • 運⽤体制の「これまで」と「これから」： ◦ 現在の運⽤体制と、今後の⽬標について New Relic で始めるアプリプラットフォームのオブザーバビリティ
63. まとめ 本⽇お話ししたこと • オブザーバビリティの導⼊背景 • New Relic SDK の組み込み‧考慮点 • 運⽤体制の「これまで」と「これから」 New Relic で始めるアプリプラットフォームのオブザーバビリティ 💡 ポイント オブザーバビリティはすぐに課題解決できる銀の弾丸ではないが、 より良いサービスにつなげる基盤となるもの
64. オブザーバビリティ で より良いアプリ体験を 実現していきましょう！
65. ご清聴ありがとうございました！