ブラウザの JavaScript エラーを検知したお話

再生速度

AI が生成した要約です。正確な内容は本文をご確認ください。

要約を読む

JavaScript のエラーをクライアント側で検知する仕組みを作りました。この仕組みにより、ユーザーが画面遷移できなくなるといった問題が、事前に気づけるようになりました。これまでの監視では、サーバー側のエラーしか見えておらず、クライアント側の問題は気づけませんでした。その問題のきっかけは、カスタマーセンターから「画面が遷移しない」という問い合わせでした。 API ログを確認したところ、不具合の原因が見つかりませんでしたが、アクセスログから古い Android 端末からのアクセスが確認されました。そのページのソースを調べたところ、JavaScript の replaceAll 関数が使われており、Chrome 85 以降のバージョンでしか対応されていないことがわかりました。この関数の使用は、FACTORY の推奨環境としての最新版のブラウザを想定しているため、テストされていませんでした。そのため、実際にユーザーが使っている古いブラウザで問題が起きていることが判明しました。そこで、AWS の CloudWatch RUM を活用して、ブラウザ内で発生した JavaScript エラーを自動で検知する仕組みを作りました。 RUM はブラウザ上で JavaScript のイベントを送信できるため、エラーが起きた瞬間をリアルタイムでキャッチできます。その結果、エラーが発生した場合に、CloudWatch Alarm が反応し、SNS へ通知されます。 SNS が SQS に送信され、Lambda がメッセージを拾い、OpenSearch へエラー内容を記録します。この流れで、開発チームがすぐに問題を把握できるようになりました。数ヶ月の運用で、重大なエラーは発生していませんが、検索エンジンのクローラーなどからの意図しないアクセスでエラーが起きるケースも検知できました。これまでは気づかなかったアクセスに気付けるようになったため、監視の重要性を改めて感じました。今後は、エラーが発生した場合に、ユーザーにわかりやすいメッセージを表示するようにし、開発チームが早く気づける仕組みを整えたいと考えています。

 はじめにこんにちは。ご覧いただきありがとうございます！

KINTO FACTORY（以下 FACTORY）という今お乗りのクルマをアップグレードできるサービスで、フロントエンド開発をしている中本です。
今回は、AWS の CloudWatch RUM を用いてブラウザ等のクライアントで発生したエラーを検知する方法について、紹介させて頂きたいと思います。
 導入するきっかけ導入するきっかけとなったのが、カスタマーセンター（CC）からの連絡で、とあるユーザー様が FACTORY の WEB サイトから商品の注文へ進もうとしたところ、画面が遷移しない不具合が発生していると調査依頼を受けたことでした。

すぐさま、API ログなどを解析しエラーが発生しているか確認しましたが、これといって不具合につながるものは発見できませんでした。
そこで次に、フロントエンドでどのような機種やブラウザからアクセスされているか確認してみました。

Cloud Front のアクセスログから、該当ユーザーのアクセスを調べ User-Agent を見てみると、、
Android 10; Chrome/80.0.3987.149
割と古い Android 端末からのアクセスでした。
そのことを念頭に置き、不具合が起きているページのソースを解析したりしていると、ある FE 開発メンバーから、JavaScript の replaceAll が怪しいのではという助言が、、、

こちらの関数、Chrome version が 85 以上での対応でした。。（FACTORY の推奨環境は各ブラウザの最新版としているため、QA でもここまで古いバージョンはテストしておりませんでした）
※チーム内の他メンバーからは、こちら にて使用する関数を検索することで、どのブラウザではどのバージョンから対応しているか、簡単に検索できることも教えてもらいました！
これまでの FACTORY の監視は、BFF レイヤー以下でのエラーを検知し、PagerDuty や Slack へ通知しておりましたが、クライアンでのエラー検知はできておらず、このようにお客様からのご連絡で初めて気付ける状態でした。

このままだと、お客様から何かしらのアクションを頂かない限り、このようなクライアント側で起こるエラーに気づくことさえできないと思い、対策をすることにしました。
 検知方法もともと、FACTORY のフロントエンドには、AWS の CloudWatch RUM（Real-time User Monitoring）の client.js を読み込んでいました。しかし、この機能を特に何かに使うこともしておらず（ユーザージャーニーなどは別途 GA で分析している）、少し勿体無い状況でした。
調べていくと、RUM の仕組みによりブラウザ等のクライアント上で、JavaScript からイベントを CloudWatch へ送信できることを知り、 この仕組みを用いることで何かしらのエラーが起きた際、カスタムイベント送信し、検知する仕組みを作ることにしました。
 通知方法通知のおおまかな流れは以下のとおりです。
ブラウザでエラーを検知した場合、CloudWatch RUM でエラー内容をメッセージに含んだ、カスタムイベントを送信する
window.crm("recordEvent", {
  type: "error_handle_event",
  data: {
    /* 解析に必要な情報。exception errorの中身等 */
  },
});
Cloud Watch Alerm で上記イベントを検知し、イベントが発生した場合にエラー内容を SNS へ送信
上記 SNS が SQS へ通知し Lambda がメッセージを拾って OpenSearch へエラー通知（こちらの仕組みは既存の API エラーを検知・通知する仕組みを流用）
 運用してみてこちらの仕組みを本番環境にも反映して、数ヶ月運用して来ましたが、幸いなことに導入のきっかけとなった JavaScript のエラー等、クリティカルな問題は発生しておりません。
ただ、検索エンジンのクローラーや bot などからの、意図しないアクセスでエラーが発生するケースも検知できており、導入するまで特に気に留めていなかったアクセスにも気付けるようになったので、監視の大事さを改めて知る戒めにもなりました。
 最後にFACTORY のように WEB サイトでお買い物を頂くには、エラーが発生し商品が購入できなくなったりページが見えなくなるというケースを、できる限り防ぐ必要があります。しかし、すべてのお客様の端末・ブラウザにて動作を保証するにも限界があるかと思います。

そこで、エラーが発生してしまった場合には、できるだけわかりやすいメッセージ（対処法など）を画面へ返してあげることと、運用面として開発している我々が、発生した事実と不具合内容に早急に気づける仕組みが必要かなと思います。
今後も様々なツールや仕組みを駆使して、安定した WEB サイトの運用を目指していきたいです。