SvelteKitでAWS上でのWebフロントエンドモニタリングを考える

written by naoketa(Naoki Tazawa)

はじめに

• SvelteJapanOnlineMeetup#2でWebフロントエンドのモニタリングをテーマに登壇したので、登壇の背景等のメモ第一弾になります。
• 発表ではWebフロントエンドのモニタリング & Amplify上のSSRなSvelteKitを構築しつつ、AWSのwebフロントエンドの監視系サービスを構築してしばらく稼働させてみた所感について、発表で触れられなかった内容含めて記載しておきます。今回は第一弾としてWebフロントエンドのモニタリングについて記載します。

発表資料/動画

• 資料

  • https://speakerdeck.com/naoketa/sveltejapanonlinemeetup-number-2-naoketa

• 動画

  • https://www.youtube.com/watch?v=ph617ip9Nbo

テーマの背景

• 今回のテーマは主に(1)一般的にSvelteKitではWebフロントエンドのモニタリングはどうするべきか、(2)AmplifyでSvelteKitをSSRで動かすの2点になります。

SvelteKitをはじめとしたWebフロントエンドのモニタリング

• 私はもともとバックエンド→フロントエンド→インフラを扱ってきたエンジニアになりますが、フロントエンドの監視/ObservabilityはtoCプロダクトをサービスする中でユーザ体験に直結する重要なテーマでありながら、どうしてもフロントエンドエンジニア目線でもインフラエンジニア目線でも手が回らず優先度を落としてしまいがちという課題感を持っています。前者のテーマについてはこういった課題感から、特にWebフロントエンドコミュニティで意見をもらいたくテーマに挙げていたものでした。

テーマ自体の所感など

• 上記テーマの結果自体は資料記載の通りですが、Amplifyや今回利用したAWSサービス自体の利用してサービス提供してみた所感としては以下になります。
  • CloudWatch RUMのJSエラー解析で、ソースマップ対応していないのが辛い。
    • クライアント側で発生しているJSエラーを検知/解析できるのは本当に便利なのですが、競合のSentryなどのようにソースマップ対応していないので、解析が結構手間でした。SvelteKit限らず出てくる課題かと思うので、このへんはおいおいサポートされることを期待しています。
      • https://docs.sentry.io/platforms/javascript/guides/svelte/sourcemaps/
    • 今回のケースでは結果的にCloudWatch RUMのマネージドなJSエラー機能だけでなく、個別にClouWacth RUMのカスタムイベントを作り込んで送信するよう変更しました。

さいごに

• その他、SvelteJapanOnlineMeetupに参加させていただき、貴重な場をご提供いただき運営の方、他の登壇者の方には本当に感謝です。ありがとうございました。
• SSRで動かすAmplify用のSvelteのAdapterはいつか作り直します。。