2024-12-20

「New Relic Browser」で実現するフロントエンドのパフォーマンス改善

NewRelic

これは New Relic 使ってみた情報をシェアしよう！ by New Relic - Qiita Advent Calendar 2024 - Qiita [シリーズ2] の 20 日目のエントリーです。

今年の技術書典17で実践フロントエンドオブザーバビリティという本を出しました。

techbookfest.org

この本の最後の章ではフロントエンドのパフォーマンス計測を行うために、 New Relic Browser を使った計測方法を紹介しています。

本エントリーでは私が開発に関わっているハッカー飯という Web サービスに New Relic Browser を導入して得られた知見を紹介します。

hackermeshi.com

Core Web Vitals

本題に入る前にまずユーザーエクスペリエンスを評価するための指標である Core Web Vitals について説明します。

Core Web Vitals はユーザーがウェブページを訪問した際に感じる「快適さ」を数値で評価するもので、ウェブサイトのパフォーマンスを具体的に改善するための道しるべとなります。

LCP（Largest Contentful Paint）

LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.

参考: Largest Contentful Paint (LCP) | Articles | web.dev

LCP はビューポート内で最大の要素(画像やテキストブロックなど)が表示されるまでの時間です。目標値は 2.5 秒以内でサーバー応答時間の短縮やリソースの最適化によって改善できます。

INP（Interaction to Next Paint）

INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers.

参考: Interaction to Next Paint (INP) | Articles | web.dev

ユーザーのインタラクションに対するページの応答性能を評価したものです。例えばボタンをクリックしたときに画面が反応するまでの速さを測ります。

目標値としては 200 ミリ秒以内が良好とされており、安定してページの応答性が高ければ高いほどユーザーにとって快適な操作感を提供できます。

CLS（Cumulative Layout Shift）

CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.

参考: Cumulative Layout Shift (CLS) | Articles | web.dev

CLSはページの読み込み中に発生する予期せぬレイアウトのズレの累積スコアを測定したものです。目標値は 0.1 以下で、画像や広告スペースのサイズを明示的に指定すると改善できます。

New Relic Browser をインストール

New Relic の管理画面で生成した JavaScript スニペットをフロントエンドのアプリケーション内に埋め込むことで測定が可能になります。

しかし、ハッカー飯には dev、stg、prd の 3 つの環境があるためそれぞれの環境毎に New Relic Browser をインストールする必要がありました。

この問題を解決するために各環境ごとに環境変数を使って設定を行いました。

ハッカー飯ではフロントエンドの開発に Vite を使用していたので .env ファイルを用いて環境変数を定義し、ビルド時に適用するようにしました。

.env (環境毎に .env ファイルを用意する)

VITE_NEW_RELIC_APPLICATION_ID=5555555555

JavaScript スニペット

NREUM.loader_config = {
  accountID: "0000000",
  trustKey: "1111111",
  agentID: import.meta.env.VITE_NEW_RELIC_APPLICATION_ID,
  licenseKey: "*****",
  applicationID: import.meta.env.VITE_NEW_RELIC_APPLICATION_ID
};

同一アカウント内で複数環境の New Relic Browser をインストールしたい場合 agentID と applicationID を変えれば環境を分けることが出来るようです。

（New Relic が生成した JavaScript スニペットを見ると agentID と applicationID は同一のもので良いようです。）

New Relic Browser を使ってみた

Summary を確認すると LCP と INP は良いスコアを出していることが分かりました。一方 CLS は good になっているものの LCP と INP に比べると改善の余地があることが分かりました。

CLS をドリルダウンしていくと https://hackermeshi.com/profiles/*** というハッカー飯のプロフィールページで特に CLS のスコアが悪いことが分かりました。

該当ページにアクセスして実際にレイアウトシフトが発生しているかを確認しました。

この時、ただリロードするだけだと確認し辛かったので Chrome の開発者ツール内にある Network タブの「No throttling」を「3G」に変更してから検証を行いました。

これにより通信速度を遅くできるため、レイアウトシフトを目視で確認しやすくなります。

矢印で示した箇所を注目してください。初めは画面の真ん中らへんにあるのですが、その後ページが読み込まれるとレイアウトシフトが発生していることが分かりました。

レイアウトシフト発生前

レイアウトシフト発生後

このように New Relic Browser を使ったことでクライアントがアクセスした各ページ毎のパフォーマンスを可視化することができ、ユーザーエクスペリエンスを向上させるための改善点を見つけることができました。

もう一度 Summary の画面に注目するとフロントエンドでいくらかエラーが発生していることも分かりました。

エラーの詳細をクリックすると Session replay の機能でエラーが発生した瞬間の画面を確認することができます。

この機能を使うことでエラーが発生した状況を再現しやすくなり、エラーの原因を特定しやすくなりました。

まとめ

本エントリーではハッカー飯に New Relic Browser を導入し、Core Web Vitals を基にパフォーマンスを評価した経験について紹介しました。

Core Web Vitalsの重要性

LCP、INP、CLS といった指標がユーザーエクスペリエンスを評価するための具体的な基準となることを紹介しました。それぞれの目標値を意識し、改善の指針とすることでユーザにとって快適なWebサービスを提供できるようになります。

New Relic Browserの導入手法

環境ごとのデータを分離するため Vite の .env ファイルを活用して設定を行いました。これにより複数の環境での計測データの管理ができるようになりました。

パフォーマンスデータの可視化と改善

New Relic Browser によってハッカー飯の CLS スコアに問題があるページを特定し Chrome の開発者ツールを活用して実際のレイアウトシフトを確認できました。その結果、具体的な改善点を見つけることができました。

エラーのトラブルシューティング

New Relic の Session Replay 機能によりエラー発生時の状況を再現しやすくなり、問題解決に役立つ情報を得ることができるようになりました。

また、これらの取り組みによってフロントエンドのパフォーマンス向上だけでなく、開発者の作業効率も向上させることができるようになったと考えています。

今回の知見が皆さんのプロジェクトにおけるパフォーマンス改善の参考になれば幸いです。

2023-12-02

ISUCON13 に New Relic を導入して挑んできた

NewRelic

※ New Relic Advent Calendar 2023 に投稿した記事です。

こんいす〜！今年も ISUCON に参加してきました！コンテスト中に New Relic を使ってみたので導入してみた感想とか苦労したことを書いてみます。

こんいす〜！こんいす〜！
今日だけ特別にISUCON公式は「いすこ」になります🥰みんな〜！8時間後に私のライブを復活させて🙏
ISUCON13 問題はライブ配信サービス「ISUPipe」の高速化だよ🚀がんばれ〜〜〜！ #isucon https://t.co/w6ImVK2gqq pic.twitter.com/Mcb4dSDVtg
— ISUCON公式 (@isucon_official) 2023年11月25日

ISUCON とは

ISUCON は「Iikanjini Speed Up Contest（いい感じにスピードアップコンテスト）」の略で、お題となるWebサービスを決められたルールの中で高速化を図るチューニングコンテストです。

今年のお題は「ISUPipe」というライブ配信サービスの高速化がテーマになっており、 ISUPipe の投げ銭機能により、送金・寄付された金額がスコアになるといったものでした。

チーム情報

チーム名: あしたから本気出す

言語: Pyhton

最終スコア: 6,885

事前に準備したこと

去年初参加した ISUCON12 では New Relic の導入がうまくいかず 2 時間半ぐらいかかったので、今年は色んな過去問を解き New Relic の導入パターンを学んでおきました。

インフラエージェントはコマンド一発でインストールが可能なのですが、 APM に関してはアプリケーションがコンテナ上で動いているのか pyenv で動いているのかによって微妙に導入方法が変わってくるので、本番で New Relic を使おうという人は事前に導入方法を確認しておくと良いと思います。

ISUCON13 Python の環境で APM を導入する方法

今年は virtualenv 上で動いていたので、最終的には以下のような手順で APM を導入することが出来ました。

1.仮想環境をアクティベート

. .local/share/virtualenvs/python-RZQ_zDKY/bin/activate

2.仮想環境上で newrelic ライブラリをインストール

pip install newrelic

3.newrelic.ini を作成

4.isupipe-python.service を以下のように変更

[Unit]
Description=isupipe-python
After=syslog.target
After=mysql.service
Requires=mysql.service

[Service]
WorkingDirectory=/home/isucon/webapp/python
EnvironmentFile=/home/isucon/env.sh
# Environment を追加★
Environment=NEW_RELIC_CONFIG_FILE=/home/isucon/newrelic.ini

User=isucon
Group=isucon
# ExecStart を変更★
# ExecStart=/home/isucon/.x pipenv run python app.py
ExecStart=/home/isucon/.x pipenv run /home/isucon/.local/share/virtualenvs/python-RZQ_zDKY/bin/newrelic-admin run-program python app.py
ExecStop=/bin/kill -s QUIT $MAINPID

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

苦労した点

という感じにさらっと書きましたが実際には本番で New Relic の導入に手こずりました。

pipenv が使われてそうだったので pipenv install newrelic を実行してインストールしたものの newrelic-admin が見つからないといったエラーが出てしまいました。

その後色々考えたところ手順1で書いたような仮想環境をアクティベートした後に newrelic をインストールしたところ上手くいきました。

あとは Environment に記述した内容が最初絶対パスになっていなかったため newrelic.ini が見つからないというエラーも出てしまい、なんやかんやあって今年は APM の導入に 1 時間ぐらいかかってしまいました。

導入に時間かかっては元も子もないので来年ももし New Relic を導入するならもっと早く APM を入れられるようになりたい…！

New Relic を使って分析してみた

ベンチマーカーを回して負荷を確認した所 mysql の使用率が高いことは分かっていました。

New Relic の Database の結果を見ると MySQL users select の時間が掛かっていることが分かりました。

Transactions のページで Throughput 順にソートすると get_icon_handler が多く叩かれていることが判明しました。

コードを読んでみると users テーブルからユーザの ID を取得した後に icons テーブルからユーザ ID に紐付く画像のバイナリーデータを取得していました。

そこで DB に登録されたバイナリーデータを参照するのではなく、ディスク上に保存された画像ファイルを参照するようにすれば users テーブル（と icons テーブル）が叩かれずに済むので負荷が減るのではと考えました。

上記のような修正を行った結果 Most time consuming における users テーブルのランキングを下げることができ、スコアを上昇させることが出来ました！

感想

今年もなんやかんや導入に手こずってしまいましたが去年よりは早く APM を使える状態に出来て良かったなと思いました。

ISUCON ではしばしばアクセスログの分析には alp 、スロークエリログの分析には pt-query-digest 等が用いられることが多いですが、これは CLI を使って分析する手法なので New Relic よりもこっちの方が手軽に導入することが出来ます。

一方 New Relic はベンチーマーカーを回した結果を GUI 上で可視化することが出来るのでアプリケーション全体を俯瞰して見やすいというのが強みなのかなと考えています。

とは言ったものの今メトリクスを見返してみるともっと他に優先するべき変更点等があったなという気もしていて、まだまだ観察力が足りないなと痛感しました。

今年も ISUCON を楽しんで参加することが出来ました。運営の皆様本当にありがとうございます。

また来年も参加したいと考えているので、次こそは1万点を目標に頑張っていきたいと思います。

2022-12-10

New Relic の無料プランを約 1 年間ほど使ってみた感想

NewRelic

はじめましての方ははじめまして、そうでない方はこんにちは。どうも菊池宣明（@kikulabo）です。

New Relic Advent Calendar 2022 というものに参加したので New Relic に関するブログを1 本書きました。

このブログを通して少しでも役立つ情報を提供できたら幸いです。

前置き

友人と一緒に開発をしたサービスに New Relic を導入して約 1 年間ほど経過しました。

このサービスはまだ収益が出ているものでは無いため、コストの観点から New Relic の無料プランの範囲内で利用しています（ New Relic さん本当にごめんなさい）。

この記事では実際に無料プランを 1 年間使ってみてどうだったか、注意するべき点は何かについて書いていきます。

New Relic 料金体系について

まず、無料プランの話の前に現在の New Relic の料金体系について簡単に説明します。

<参考記事>

newrelic.com

2022 年 12 月時点では取り込まれたデータ量とコア/フルプラットフォームユーザ数に応じて料金が変わってくるモデルになっています。

New Relic の料金モデルは他のサービスと比べると特徴的であり、一般的なモニタリングサービスとの相違点を以下にまとめました。

一般的な SaaS 系のモニタリングサービス
- 監視エージェントの導入台数分だけ課金が発生
- 例えばスケールアウト等でインスタンスの台数が増えるとその分課金が追加で発生する
- サービスを利用するユーザ数が増えても請求金額は変わらない
New Relic
- コア/フルプラットフォームユーザ数単位での課金形式
- 監視対象のホストがいくつ増えても課金額は変わらない
- 無料で追加できるベーシックユーザというものも存在するが機能が限られておりダッシュボードとログの確認程度しか出来ない