こんにちは、サービス開発の丸山です。
今回は 2021年 9月 15日に発売された『New Relic 実践入門』を読んだので、感想や気づいたことなどを書いてみたいと思います。
この本はNew Relic Japanの方から献本いただいたものです。
(New Relic Japanさん この度はご恵贈いただきありがとうございました！)
目次は以下のようになっています。
■Part 1 New Relicを知る
第1章 オブザーバビリティの重要性
1.1 オブザーバビリティとは？
1.2 オブザーバビリティに必要なテレメトリーデータとは？第2章 New Relic Oneとは？
2.1 New Relic Oneの全体像
2.2 サービスを支えるシステム基盤とセキュリティ■Part 2 New Relicを始める
第3章 New Relicの始め方
3.1 アカウントの作成方法
3.2 アカウント構造とアクセス制御の考え方第4章 Telemetry Data Platform
4.1 Telemetry Data Platform の概要
4.2 Data explorerとQuery builder
4.3 Dashboards
4.4 Log Management
4.5 API
4.6 Manage Data
4.7 Build on New Relic One第5章 Full-Stack Observability
5.1 Full-Stack Observabilityの概要
5.2 New Relic APM
5.3 New Relic Infrastructure
5.4 New Relic Synthetics
5.5 New Relic Browser
5.6 New Relic Mobile
5.7 Serverless
5.8 Logs in Context
5.9 Distributed Tracing（分散トレーシング）第6章 Alerts and Applied Intelligence（AI）
6.1 AlertsとApplied Intelligence（AI）
6.2 New Relic Alertsの設定
6.3 Applied Intelligence（AI）の概要■Part 3 New Relicを活用する─16のオブザーバビリティ実装パターン
□第3部の構造と読み方
00 オブザーバビリティ成熟度モデル─第3部の内容について□レベル0 Getting Started／レベル1 Reactive
01 バックグラウンド（バッチ）アプリおよびGUIアプリの監視パターン
02 メッセージキューでつながる分散トレーシング
03 Mobile Crash分析パターン
04 Kubernetesオブザーバビリティパターン
05 Prometheus＋Grafana連携
06 W3C Trace Contextを使ったOpenTelemetryとNew Relic Agentでの分散トレーシングパターン□レベル2 Proactive
07 Webアプリのプロアクティブ対応パターン─Webアプリの障害検知と対応例
08 データベースアクセス改善箇所抽出パターン
09 ユーザーセントリックメトリクスを用いたフロントエンドパフォーマンス監視パターン
10 モバイルアプリのパフォーマンス観測
11 動画プレイヤーのパフォーマンス計測パターン
12 アラートノイズを発生させないためのアラート設計パターン□レベル3 Data Driven
13 SRE：Service Levelと4つのゴールデンシグナル可視化パターン
14 ビジネスKPI計測パターン
15 クラウド移行の可視化パターン
16 カオスエンジニアリングとオブザーバビリティ
ちなみに私の監視・New Relicの事前知識は次のような感じです。
- 後から調査しやすいログ出力や例外の設計を意識し始めてしばらくたった
- New Relic は Heroku のアドオンで使っている。重いトランザクションやリクエストをたまにNewRelicで確認したりしているが、使いこなせている感覚はあまりない
概要
この本はNew Relicの使い方について書かれている本というわけではなく、どちらかというともっと普遍的な「オブザーバビリティ」についてNew Relicを使って実現するという内容の本でした。
具体的な操作方法はドキュメントに任されていて、考え方やパターンなどに多くのページが割かれているので、New Relicを利用しない人も一読の価値はあるかもしれません。
逆にいうとNew Relicの実際の設定や操作を行う場合はドキュメントも合わせて読む必要がありそうです。
New Relicが目指し提案する機能の全体像は 4章から6章までで説明されています。
第4章 Telemetry Data Platform
第5章 Full-Stack Observability
第6章 Alerts and Applied Intelligence（AI）
ざっくり説明すると 「Telemetry Data Platform」でデータの管理と可視化を実現し、「Full-Stack Observability」ではそのデータを問題解決の高速化や顧客体験の改善に役立てます。さらに「Alerts and Applied Intelligence」ではAIなどを活用して運用を効率化したり、実際に問題が発生する前に能動的に改善していく仕組みを作ります。
このように最初はデータの収集や管理から始まり、後の章になるにつれ高度な内容になっていきます。
この全体像については 26ページの図が非常にわかりやすいので立ち読みする機会があれば見てみてください。
4~6章について気になったところや考えたところなどを書いていきます。
Telemetry Data Platform
New RelicのTelemetry Data Platform は、全ての運用データを格納した単一の情報源であり、ペタバイト級の情報をミリ秒単位で応答することができます。
あらゆるソースから全てのメトリクス、イベント、ログ、トレースを収集することでデータサイロを排除し、収集したデータを直感的に検索、確認できます
(p.40 から引用)
早速データの収集管理についてですが、「データサイロ」というのは、データの収集ツールや保存先が分断されることで、可視化ができなくなったり困難になったりする状態のことを指すようです。
これを読んだ段階で、私が所属するチームは「データサイロ」的なものに陥っているかもしれないと気づきました。
例えば ウェブ・バックエンド・その他サーバレスで非同期に動くサービスの大きく3つのコンポーネントに分かれているのですが、それぞれのログやメトリクスを確認するときは次のような場合分けになっています。
- ウェブアプリのログ(過去3日以内)
- Heroku のアドオンで利用しているPaperTrailで確認する
- ウェブアプリのログ(4日以上前のもの)
- Amazon Athenaでクエリして確認する
- バックエンドサービスのログ
- Amazon Athenaでクエリして確認する
- サーバレスで動くサービスのログ
- Cloud Watch Logsで確認する
- メトリクスや異常検知
- その他DatadogやNew Relic
こう並べてみると新人はどこをみたら良いのか迷ってしまいそうですね。 (ウェブアプリのログが過去3日以内かどうかで分かれているのは利用しているPaperTrailのプランの関係です。)
New Relicではこれらの情報を一か所にまとめることを想定しているようです。
特にログに関しては方法としてよくあるAgentを導入する方法だけでなくfluentdなどからNew Relicに転送することもできるようなので今ある仕組みをそのまま使って比較的簡単に試すことができそうです。
Logs in Context
その他にはこのLogs in Contextという機能も気になりました。
アプリケーションで出力されるログをAPMのパフォーマンス情報やエラー情報と紐付けて参照できるようにするLogs in Contextを提供しています。 最初の対応としてログの調査から開始するのではなく、APMのError Analytics内で特定されているエラーの詳細や、後述するDistributed Tracingから直接ログにたどり着くことができます
(p.150 から引用)
これはアプリケーションのロガー にNew Relicのフォーマッターを追加することでエラーとログを関連づけて扱えるようにできる機能のようです。
私の所属するチームでは Sentry(エラー管理サービス)などの通知でエラーに気づいた後はAthenaやPaperTrailなどに移動してログを確認するというフローをよくやっているので、エラーを気づいたらそのままログやトレース情報を確認できると便利になりそうだなと思いました。
もちろんSentryでもBreadcrumbs Loggerのような機能でエラーとログを関連づけて残すこともできますが、先述のようにNew Relicにいろいろなログデータを集約するという考え方を合わせて考えると、このLogs in Contextも実現できればかなり効率的にエラーに対応できるようになりそうです。
オブザーバビリティの実装パターン
ここまでNew Relicの主要な機能を取り上げた 4~6章についての感想でしたが、第6章の後の第3部では、「オブザーバビリティの実装パターン」の紹介があります。
これはオブザーバビリティの成熟度モデル4段階に分けられたレベルを元にそれぞれのレベルでウェブアプリ・バッチ処理・モバイルなどコンポーネントの種類ごとにオブザーバビリティの実装パターンがまとめられています。
パターンとNew Relicを使って実現する方法がセットで紹介されていますが、ここだけをざっとみても勉強になりそうな内容でした。
特に「アラートノイズを発生させないためのアラート設計パターン」や「ビジネスKPI計測パターン」などはNew Relicを使わなくても、運用を見直すための考え方として使えそうな内容で参考になりそうです。
ちなみにオブザーバビリティの成熟度モデルは、以下の4段階でレベルを定義しているようです。(p.198を元に整理)
- データ駆動: 需要に合わせたリソースのキャパシティプランニングができる。ビジネスデータとシステムパフォーマンスを組み合わせて試行錯誤できる
- 積極的対応: 障害発生前に積極的にパフォーマンスを改善し制御できる
- 受動的対応: システムの正常性を認識できる。異常を検知して発生した障害に対応できる
- 計測を始める: 必要な情報を収集できる
自分が担当しているサービスやコンポーネントについて現状どのあたりのレベルにいるのかを確認してみるのも面白いかもしれません。
今のチームでは一見0や1くらいのレベルなら実現できていそうなできていそうな雰囲気でしたが、0番に関しても次のような記述があり、レスポンスタイムやスループットなどの一般的な指標以外にも計測したり収集したりできるところはあるかもという気づきがありました。
すでにいくつか計測がされているなら、目的に応じて必要な軽装を追加していきましょう。たとえば、たびたび発生するエラーを解消するための情報、レスポンスタイムが悪化する原因を特定するための情報、提供する機能は意図通り使われているかの情報など、必要な情報を集めるための計装(テレメトリーデータを取得するために必要な設定やコード)を追加していきましょう。
以上、ざっと本書の内容の紹介と気づいたことを書いてみました。 この本の内容の一部を実践してみたという記事も他のチームメンバーから投稿されているので、こちらも読んでいただけたら幸いです。
丸山 礼 (記事一覧)
サービス開発課でCloud Automatorを開発しています。
