はじめに
新規プロダクトの開発期間中にNew Relicを導入してみたところ、リリース前でも良い効果がありました。
- デグレードの検知と原因特定
- N+1問題の特定と改善
- インフラリソースの利用状況の分析
- 運用を意識したログ設計&チューニング
プロダクトの構成
- クライアント、コンシューマー、社内システムとユーザー層が複数に分かれている
- 既存プロダクトとの連携もあるが、なるべくマイクロサービスに寄せる
このような構成で、複数チームで開発が進められていました。
開発中にNew Relicを入れてよかったところ
デグレードの検知と原因特定
疎結合な設計や網羅性の高いテストを用意していても、システム同士の結合などでデグレードが発生することがあります。
今回は早期にエラーログの監視・アラート設定を行い、「エラーログが1件でも上がったらアラートを発砲する（Slackチャンネルへ投稿する）」という仕組みを整えました。
通常の運用では厳しい基準ですが、開発中は不具合の早期発見につながりました。Slackチャンネルを通じて関係者がすぐ認識できて、複数チームにまたがる開発でも情報共有が迅速に行えました。
また、分散トレーシングによって、一連のトランザクションの中でどのサービスにエラーが起きているかがすぐ分かるようになり、原因の特定も容易でした。
N+1問題の特定と改善
APIのアーキテクチャにGraphQLを採用しているサービスにおいて、GraphQLライブラリの習熟度が低くN+1問題を起こしてしまいました。
「レスポンスがなんとなく遅い」という感覚から始まりましたが、APMを使ったデータベースの分析で原因を特定して解消しました。
今回は処理速度が早いクエリがn+1回発行されていたため、原因の特定に少し苦労しました。
最初はスロークエリを探していましたが特段遅いものはなく、対象処理のループ回数が多くなってようやく顕在化しました。
原因の特定に役立ったのがAPMによるデータベースの分析結果のソート順でした。most time consuming（頻繁に発行されるクエリ）とslowest query time（遅いクエリ）を見比べて、「処理は速いが発行数が多いクエリ」を発見できたのが解決の糸口になりました。
インフラリソースの利用状況の分析
負荷試験結果の分析のため、インフラリソースの利用状況をまとめたダッシュボードを作成しました。オートスケールの設定に大いに参考になり、複数回の試験結果を見比べながらチューニングを進めました。
死活監視やリソースの利用状況、アプリケーションのエラーレートに応じたアラートも設定できるため、統合的な監視ができる点が気に入っています。
運用を意識したログ設計&チューニング
ログにカスタム属性を追加することで、ログ解析を豊かにすることができます。
今回は開発段階から運用で使うツールを利用することで、実運用の目線を持てたことが大きかったです。
不具合の修正時に「この項目があると障害調査が楽そう」「この情報もあるとユーザー行動が分析しやすい」といった声が上がり、実運用を意識したログ設計にチューンアップしていきました。
同意のもとで提供され匿名化したユーザー識別IDや、リクエストパラメータをカスタム属性に含めることで、運用時の調査がスムーズに進められるようになりました。
特にユーザー識別IDを含めるのはおすすめです。
問題が発生したユーザーをログから割り出して、分散トレーシングと組み合わせることで、ユーザーの行動が一通り推測できるようになります。
不具合の再現手順を発見したり、計測ツールのデータからユーザーの属性を解析したりと、幅広い使い方で運用の助けになりました。
さいごに
New Relicはオブザーバビリティに主軸を置いたツールですが、観測したいデータを深掘りしていくことで、開発中にもいろいろな活用方法がありました。
開発体験のベースにあることで、プロダクトと同様にNew Relicの活用も進化していくのだと思います。
また、リリース後の運用を意識した使い方を学んでいくことができるので、学習期間として触れていくのもおすすめです。
打って変わって、昨年は数十年と続くレガシーシステムにNew Relicを入れて試行錯誤しておりました。
気になる方は、昨年はアドベントカレンダーの記事もぜひご覧ください↓
それでは、みなさま素敵なNew Relicライフを！