New Relic Browserエージェントを使用する際のCORS（Cross-Origin Resource Sharing）設定について紹介します。CORS設定は、異なるオリジン間でのデータの安全なやり取りを可能にするもので、正しく設定されていないとデータの監視や可視化に影響を及ぼします。この記事では、フロントエンドから異なるオリジンへのAPIリクエストのトレースを有効化することでAPIリクエストのトラブルシューティングを効率化する方法を紹介します。
今回のポイント
この記事で紹介しているポイントは、次の２つです。
-
New Relic の Browserエージェントで CORS の設定が必要な理由がわかる
New Relic の Browser エージェントがAPIを呼び出した情報を収集してフロントエンドからバックエンドまでの一連の処理をトレースする際に必要な設定を紹介します。 -
New Relic の Browserエージェントで CORS の設定を有効にする方法がわかる
AWS Lambda と Amazon API Gateway を使用した API を例にAPIリクエストのトレースを有効化する手順を紹介します。
最新のアップデートの詳細はこちら
New Relic アップデート一覧
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
New Relic Browser エージェントと CORS 設定の必要性
New Relic の分散トレーシングの機能は、問題が起きた際のトラブルシューティングやパフォーマンスのボトルネックを見つける際に活躍する大変強力な機能です。分散トレーシングは、HTTPリクエストのリクエストヘッダーに含まれる W3C に準拠したの2つのトレースコンテキストヘッダー（traceparent, tracestate）をサービス間で伝搬することによりトレーシングを実現しています。
Cross-Origin Resource Sharing（CORS）は、ウェブアプリケーションが自分のオリジン(ドメイン、プロトコル、ポート番号) と異なるオリジンに対してフロントエンドからの API リクエストを制限する仕組みです。下記のサイトで詳しく紹介されているので参考にしてください。
CORS によって API リクエストを実行するオリジンやメソッド, ヘッダーが API のサーバー側で制限されています。ここで問題になるのがヘッダーです。分散トレーシングは、HTTPリクエストのリクエストヘッダーにトレースコンテキストを設定することでフロントエンドでのAPIリクエストとバックエンド処理をトレースしています。しかし、CORS によってヘッダーの情報が制限されているため、フロントエンドからバックエンドへトレースコンテキストを伝搬することができません。
トレースコンテキストの伝搬を可能にするのが New Relic Browser エージェントの CORS 設定です。異なるオリジンへのリクエストを分散トレーシングでトレースする場合は、対象のオリジンの情報を設定することでリクエストヘッダーにトレースコンテキストが付加されるようになります。
分散トレーシングで CORS の設定を有効にしないとどうなるのか
では分散トレーシングで CORS の設定を有効化していない場合に異なるオリジンへ API リクエストが発生した場合は、New Relic 上ではどのように見えるのか確認してみましょう。
フロントエンド（Browser）側
Browser の AJAX を開くと対象の API へのリクエストが記録されていることが確認できます。
一方で Distributed tracing（分散トレーシング） を開いても API リクエストは記録されていません。これは異なるオリジンへのリクエストであるため、分散トレーシングの対象になっていないことが原因です。
バックエンド（APM・Optentelemetry・Lambda 統合 等）側
次にバックエンドの分散トレーシングを見てみます。こちらは分散トレーシングのデータが記録されていますが、関連するエンティティの数が 1 になっているため、バックエンド単体で記録した情報のみでフロントエンドからのトレースとは認識されていません。
この状態では、フロントエンドのリクエストとバックエンドの処理に関するデータが分離されて収集されてしまうため、APIリクエストがエラーになった際の調査は、関連するリクエスト情報を探しながら行わなければならず、効率的ではありません。これでは、分散トレーシングのメリットを十分に活かすことができません。
分散トレーシングで CORS の設定を有効にするとどうなるのか
次に分散トレーシングで CORS の設定を有効化した状態で異なるオリジンへ API リクエストが発生した場合は、New Relic 上ではどのように見えるのか確認してみましょう。
分散トレーシング
Browser の分散トレーシングでトレースの情報が表示されるようになります。
また、トレースの詳細を開くとフロントエンドからバックエンドのAPIへのリクエストがトレースされ、リクエストの流れが図示されています。
サービスマップ
サービスマップでも同様にフロントエンドからバックエンドのAPIへのリクエストがマッピングされて表示されます。
Browser エージェントの分散トレーシングにおけるCORS設定の有効化を通じて、異なるオリジンへのリクエストをフロントエンドからバックエンドまで追跡できることをご理解いただけたかと思います。このトレース情報を活用することで、ユーザー体験に影響を与えるAPIリクエストのエラー原因や、パフォーマンスが低下した際のボトルネックを容易に特定できるようになります。
New Relic Browserエージェントの分散トレーシングで CORS 設定を有効化する手順
ここからは、あるWebアプリケーションから AWS Lambda と Amazon API Gateway で作成した API へのリクエストを実行するケースを例にBrowserエージェントの分散トレーシングで CORS 設定を有効化する手順を紹介します。また、フロントエンドにはBrowserエージェントを導入し、バックエンドの Lambda には New Relic のLambda 統合 を導入しています。
今回は AWS Lambda を使用しているため Lambda 統合を使用していますが、New Relic の APM エージェントや OpenTelemetry を使った場合も同じようにトレース情報を追跡することが可能です。
フロントエンドへのBrowserエージェントを導入方法については、こちらの記事を参考にしてください。
また AWS Lambda への Lambda 統合(Lambda Layer)の導入方法は、こちらの記事で紹介されています。
注意事項
今回の手順は、下記の公式ドキュメントの手順を参考にして設定を行っています。
公式ドキュメントに設定時の注意事項が記載されています。必ず確認してください。
注意 CORSの設定を変更する作業を実施する際、正しく設定されていない場合にAPIのリクエストが正常に動作しなくなる可能性があります。また、設定変更を実施する順番を誤るとリクエストエラーが発生する可能性もあります。設定変更のリスクを理解して本番環境で設定する前に、必ずテスト環境で CORS を有効にして設定内容や手順の確認を行なってください。
サーバー側で必要な設定
まずサーバー側で Access-Control-Allow-Headers の設定を行います。今回は API Gateway の CORS 設定を変更して Access-Control-Allow-Headers に traceparent と tracestate の2つを追加します。
API Gatewayの設定は以上です。
New Relic UI 上での設定とスクリプトの更新
次に Browser エージェントの設定変更を行います。分散トレーシングの設定は、SETTINGS の Application settings から設定が可能です。また分散トレーシングを有効にするため、Browser Pro+SPA エージェントを使用します。
Distributed tracing の Cross origin resource sharing (CORS) を有効化します。
また、Use trace context header にチェックを入れます。今回はバックエンドに新しいバージョンのエージェントを使用しているため、trace context header のみを使用します。古いバージョンのAPMエージェントを使用する場合は、newrelic header もチェックしてください。詳しいエージェントのバージョンについては、こちらドキュメントをご確認ください。
Add origin にフロントエンドからリクエストする API のオリジン（今回はhttps://xxx.execute-api.ap-northeast-1.amazonaws.com）を入力し Add origin を選択します。するとこのような画面が表示されます。注意事項で記載したように設定を変更したことによってAPIリクエストが失敗する可能性に言及した確認画面です。問題がなければ Accept を選択して次に進みましょう。
設定変更は以上です。画面右下の Save を選択して設定を保存しましょう。
保存した設定が反映された新しいスニペットが生成されています。最後に元のスニペットを更新して作業は完了です。
新しいオリジンを追加する等の変更を行なった際は、その都度スニペットの更新が必要です。
これで Browser エージェントで分散トレーシングを使用するための CORS の設定は完了です。
データの確認
実際にリクエストを発生させて分散トレーシングのデータが生成されると New Relic Browser の Distributed tracing の画面でこのようにトレースのデータが確認できます。
まとめ
New Relic Browser エージェントの分散トレーシングで CORS 設定を適切に実装することで、より精密なデータ収集とパフォーマンス解析が可能になります。この記事を参考に、設定を実施する際には、サーバー側とクライアント側双方の構成をテストした上で行うことをお勧めします。API リクエストが正常に動作することを確認するためにテスト環境で設定内容と手順の検証を行うようにしましょう。分散トレーシングの効果を最大限に引き出し、ユーザー体験の改善につなげてください。
New Relicでは、新しい機能やその活用方法について、QiitaやXで発信しています！
無料でアカウント作成も可能なのでぜひお試しください！
New Relic株式会社のX(旧Twitter) や Qiita OrganizationOrganizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！