背景
- Webアプリケーションのパフォーマンスチューニングコンテスト「ISUCON10」の予選に参加した。
→ チームメイトの参加ブログ - New Relicから ISUCON10参加チーム向けNew Relic特別無料ライセンスが提供されていたので使ってみた。
導入方法
前提として、NewRelicのAPMライセンス適用済みのアカウントが作成されていること
- NewRelicポータル > APM > Add More で
Node jsを選択 - 画面の案内に沿って導入する
- アプリケーション名を決めて入力する
- Node.jsアプリケーションのディレクトリでnewrelicのNPMパッケージを導入
$ npm install newrelic --save - NewRelicの設定ファイル(newrelic.js)をダウンロードし、Node.jsアプリケーションのディレクトリ直下に配置
(NewRelicのライセンスキーと1.で入力したアプリケーション名が記載されている) - Node.jsのアプリケーション本体(app.jsなど)にrequireを追加する
require('newrelic'); - Node.jsのアプリケーションを再起動する。(
$npm startなど)![image.png]()
どんな情報が見えるのか？
ISUCONの中でどのようなパフォーマンス解析に使っていたかのメモです。
（アプリケーションはコンテスト中で改修した後のもの）
Summary
- アプリケーションのトランザクション処理時間のグラフが確認できる。
- トランザクション全体の時間の中でMySQLの処理時間の割合がわかる
- スループット、エラーレート、Apdexスコア（レスポンスタイムベースのユーザ満足度）
- 下部にはアプリケーションを処理しているサーバ別のレスポンス・スループット・エラーレート・CPU使用率・メモリ使用率の平均値が表示される。
![image.png]()
Distributed Tracing
- アプリケーションのトランザクションのサンプリング一覧を表示する。
全体の処理時間・バックエンドの処理時間でソートし遅いトランザクションを特定することができる。 - 更にドリルダウンすることでトランザクションの中でのバックエンドの呼び出し時間の割合（MySQLならテーブル単位）を確認することができる。キャプチャの例ではトランザクション中でMySQLのchairテーブルに2回selectを発行し、Redisに1回setしていることがわかる。
Service Map
- アプリケーションが依存している外部サービスがマップ上に表示される。
- キャプチャの例ではアプリケーションから2ノードのRedisと1ノードのMySQLにアクセスしていることがわかる
- データベースをクリックするとクエリの処理時間のグラフも表示される
![image.png]()
Dependencies
- Service Mapに表示されていた外部サービスが一覧表示される
Transactions
- 初期表示の「Sort by Most time consuming」でアプリケーションのトランザクションの中で「処理時間 × リクエスト数」が多い順に表示される。(キャプチャ1枚目)
- 特定機能にフォーカスすると処理時間の内訳がグラフ表示される。キャプチャ2枚目の例ではMySQLのchairテーブルのselectが支配的なことがわかる。
- パフォーマンス改善の効果が高い機能を特定しチューニングの方向性を決めるために利用できる。
Databases
- 初期表示の「Sort by Most time consuming」でアプリケーションが接続しているデータベースのクエリの「処理時間 × リクエスト数」が多い順に表示される。
- テーブル単位のselect/insertの処理時間の外観をつかむことができるのでDBチューニングの方向性を決めるために利用できる。
![image.png]()
感想
- NewRelicの導入簡単すぎ。（Node.jsの場合）
- アプリケーションの機能単位での処理時間、データベースのテーブル単位のselect/insertの処理時間が確認できるため、パフォーマンス低下の原因を速やかに特定できる。とても便利。
- ISUCONのスコアベースでは100-200点程度の影響しかなかったので、New Relic APM Agentによるパフォーマンス影響よりも可観測性のメリットの方が大きいと思われる。（競技の最終盤では外しましたが）本番運用しているアプリケーションではNewRelicでモニタリングし続けたほうがいいと思いました。