Webアプリケーションのフロントエンドを運用していると、「特定のユーザーからだけ画面が開かない・エラーになるという報告が来るが、手元では再現しない」といった厄介な問題に直面することがあります。
今回は、New Relic Browserを使って「特定のインターネットプロバイダ（ISP）でだけ発生している異常」をサクッとあぶり出す方法をご紹介します。

なんでこんなピンポイントな記事を書いたのか

プライベートの話ですが、自宅Wi-Fiは某個別回線を利用しており、その会社製のルーターの初期設定の場合だけ、Chromeでサブスクの動画配信サイトを見ると ERR_CONNECTION_RESET が頻発するという謎の現象に遭遇しました。

調査の末、原因はルーター側のWi-Fi 6（802.11ax）設定にあることが判明しました。
内容としては、Wi-Fi 6特有の複雑な制御（OFDMAやTWTなど）と、Chromeが積極利用するHTTP/3（QUIC/UDP）通信の相性が悪かったようで、ルーター側の設定でWi-Fi 6をOFFにし、通信モードを「ac/n/a」に変更したところ、あっさりと解決したのです。

もし自分がWebサービスの運営側で、オフィスや別のプロバイダ環境では絶対に再現しないこの事象を切り分けるの大変だなーと思ったので書きました。
New Relic Browserを活用すれば、特定のプロバイダだけで発生している問題も切り分けて見ることができる簡単なTipsをご紹介できればと思います。

結論: 以下のようなNRQL書いていただくと、プロバイダ別のエラー率がわかります。

単にエラー数を見るだけでは、「そもそもアクセス数が多いプロバイダ」のエラーが多く見えてしまう罠にはまります。そこで、PageView（ページビュー数）と JavaScriptError（エラー数）を組み合わせて、プロバイダごとのエラー率を算出します。

SELECT 
  filter(count(*), WHERE eventType() = 'JavaScriptError') / 
  filter(count(*), WHERE eventType() = 'PageView') * 100 
  AS 'Error Rate (%)'
FROM PageView, JavaScriptError 
WHERE appName = 'YOUR_APP_NAME'
FACET asnOrganization 
SINCE 1 day ago

前提知識：ネットワークプロバイダを特定するキー属性 asnOrganization

具体的な方法に入る前に、New Relicがどうやってプロバイダ情報を識別しているかを少し解説します。

New Relic Browserのエージェントは、エンドユーザーのIPアドレスを一時的に取得し、バックグラウンドで自律システム番号（ASN）情報にマッピングしています。（※IPアドレス自体はルックアップ後に破棄され、保存されません）

この仕組みにより、アクセス元のネットワークプロバイダ情報が以下の属性（Attribute）として各イベントに自動付与されます。

asn: Autonomous System Number（自律システム番号）

asnOrganization: ISP / 事業者 / 機関名（ネットワークプロバイダーの名称）
この asnOrganization を使うことで、「どのプロバイダからのアクセスか」を軸にした分析が可能になります。今回はこれを使って調査を進めます。

方法1つ目 UI で切り分ける

まずは、一番手軽な標準UI（ダッシュボード）から当たりをつける方法です。複雑なクエリを書かなくても、ポチポチとクリックするだけで特定のプロバイダに異常が偏っていないかを確認できます。

New Relicの左側メニューから [Browser] を選択し、対象のアプリケーションを開きます。

左メニューの [Errors]（または JS Errors）画面を開きます。

画面上部にある「Group By（グループ化）」のドロップダウンメニューを開き、asnOrganization を選択します。

下部のリストがプロバイダごとにグルーピングされて表示されます。

ここで、特定のプロバイダ（例えば ASxxxxx - 〇〇 Corporation）のエラーカウントだけが異常に突出している場合、「コードではなく回線やプロバイダ側の問題かもしれない」という強力な仮説を立てることができます。

方法2つ目 NRQLで切り分ける。

最初の結論でご紹介させていただいた内容になります。UIでの確認は手軽ですが、「単にそのプロバイダを使っているユーザー数（アクセス数）が多いから、エラー数も多く見えているだけ」という罠にはまることがあります。
より正確にトラブルシューティングを行うためには、プロバイダごとの「エラー率（%）」を算出する必要があります。ここではNRQL（New Relic Query Language）を使ってピンポイントに切り分けてみましょう。

プロバイダごとのアクセス数（ページビュー数）を確認するクエリ

SELECT count(*) FROM PageView WHERE appName = 'YOUR_APP_NAME' FACET asnOrganization 
SINCE 1 day ago

特定のアプリ名でのプロバイダー別のエラー率（％）を計算

SELECT
  filter(count(*), WHERE eventType() = 'JavaScriptError') /
  filter(count(*), WHERE eventType() = 'PageView') * 100
  AS 'Error Rate (%)'
FROM PageView, JavaScriptError
WHERE appName = 'アプリ名'
FACET asnOrganization
SINCE 1 day ago

まとめ

今回の私の遭遇したケースの場合は、上記のクエリにさらに、どのブラウザからのアクセスかを示すuserAgentName FACET句に追加して、実行すれば問題の切り分けが可能でした。

SELECT
  filter(count(*), WHERE eventType() = 'JavaScriptError') /
  filter(count(*), WHERE eventType() = 'PageView') * 100
  AS 'Error Rate (%)'
FROM PageView, JavaScriptError
WHERE appName = 'Frontend'
FACET asnOrganization, userAgentName 
SINCE 1 day ago

発生する事象自体はシンプルな事象ですが、エラーが起こった際はインフラやアプリケーションから調査をしてしまうので、プロバイダーが最終到着地点になってしまい、時間をロスしてしまいがちです。調査時間の短縮のためにぜひ活用してみてください！

New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。