【要約】New Relic で N+1などの隠れたボトルネックを自動検知！Performance Risks Inbox の使い方 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者は、エラーログには記録されないが、システムを徐々に劣化させる潜在的なボトルネックの特定に苦慮している。具体的には、以下の課題に直面している。
- ・エラーログには残らない、リソースを食いつぶす非効率なコードの存在。
- ・開発環境では気づきにくく、本番環境のデータ量で初めて発覚するアンチパターン。
- ・NRQLを用いた能動的な調査や、複雑なダッシュボード作成に多大な工数がかかる点。
// Approach
New Relicは、APMエージェントのデータを活用してリスクを自動抽出する、受動的な発見のアプローチを採用した。具体的な手法は以下の通りである。
- ・N+1問題や連続したHTTPリクエストなど、6つのアンチパターンを自動検知する。
- ・検知したリスクを種類ごとにグループ化し、優先順位付け（トリアージ）を支援する。
- ・分散トレーシングと連携し、問題が発生しているメソッドやSQLをピンポイントで特定する。
- ・Jira等の外部ツールと連携し、リファクタリング作業をチームのタスクとして管理する。
// Result
開発者は、障害が発生する前にパフォーマンスリスクを特定し、リファクタリングを行うことが可能になった。具体的な成果は以下の通りである。
- ・Java環境でのN+1問題解消により、クエリ数が601回から1回へ激減。
- ・レスポンスタイムが1200msから35msへ、約97%の劇的な改善を達成。
- ・「事後対応」から「事前対処」への、プロアクティブな運用モデルへの転換を実現。
Senior Engineer Insight
> 運用負荷を劇的に下げる機能だ。従来のNRQLによる「能動的な監視」は、監視設計にスキルと工数を要した。本機能による「受動的な検知」は、開発者の意識を「調査」から「修正」へシフトさせる。特に、マイクロサービス環境での「Sequential HTTP requests」の検知は、分散システム特有のレイテンシ問題を捉える上で極めて価値が高い。ただし、検知されたリスクが必ずしも修正対象とは限らないため、トリアージの判断基準をチーム内で定義しておく必要がある。