0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS RUMをNext.jsに入れようとして詰まった話

Last updated at Posted at 2023-12-08

AWS RUMをNext.jsに入れてクラッシュログを収集しようとしたときに、詰まったので同じように詰まっている人の為に、情報を残しておきます。

tl;dr

  • RUMを作成するterraformのコード記載例をそのまま使ってもうまく動かない。
  • RUMには何らかの認証情報が必要。元々Cognitoを使った認証をしていないなら、新規で匿名認証を使う。
  • Cognitoの制御をaws-rum-webでは出来ないので、Identity poolを切り替えたりした場合は何らかの方法でLocal storageを削除するなどの方法で回避する必要がある。

AWS RUMとは?

Amazon CloudWatch RUM(Real User Monitoring)は、Webアプリケーションのパフォーマンスに関するクライアント側のデータをリアルタイムで収集し、ユーザーモニタリング結果を提供するサービスです。
SentryやGoogle Analyticsのように、フロント側に仕込んでおいて、クライアント側で何が起こっているかを収集する類のサービスです。

Cloud WatchのApplication Signalsというサービスの中の1機能として位置づけられている(?)ようですが、RUM自体は2021年から使える機能です。

何が起こったのか

私ははじめ単純にクライアントにタグを埋め込んだらそれだけで基本的な部分は使えるようになると思っていました。

IaCとしてTerraformを使っていたので、以下の公式ドキュメントを参考にRUMのリソースを作成しました。

resource "aws_rum_app_monitor" "rum" {
  name   = "${var.environment}-rum"
  domain = var.domain

  app_monitor_configuration {
    allow_cookies       = true
    session_sample_rate = 1.0
    telemetries         = ["performance", "errors", "http"]
  }
}

一応これでエラーなく作成でき、マネジメントコンソールからスニペットが表示されるので、それをコピーしてNext.jsの_app.tsxに追加しました。

しかし、フロント側でエラーが出ることもなく、いくら待っても一向にデータが飛んできませんでした。

Cognitoによる認証が必須だった

スニペットを書き換えたり、ログを仕込んで見たり色々デバッグして試行錯誤していましたが、そんな中以下のブログにあるマネジメントコンソールから作る方法を試した際に、Authorizationの項目が選択式になっていることに気づきました。

スクリーンショット 2023-12-06 9.45.03.png

この選択肢を見ると、新しくidentity poolを作成するか、既存のidentity poolを指定するか、もしくは別の認証の仕組みを使うかして、とにかく認証を通す必要がありそうでした。

なので、コンソールからCreate new identity poolを選択して、スニペットを書き換えると無事ログが飛んでくるようになりました。
terraform上はoptionalとなっていたので任意項目だと思っていましたが、RUMでは必ず何らかの認証を通す必要がありました。

Cognitoの認証が通らなくなる

上記で問題が解決したので、terraform側で改めて匿名認証用のCognitoのidentity poolを作成して、RUMに設定しました。

resource "aws_cognito_identity_pool" "identity_pool" {
  identity_pool_name               = "${var.environment}-rum-identity-pool"
  allow_unauthenticated_identities = true
  allow_classic_flow               = true
}

resource "aws_cognito_identity_pool_roles_attachment" "identity_pool_role_attachment" {
  identity_pool_id = aws_cognito_identity_pool.identity_pool.id
  roles = {
    "unauthenticated" = aws_iam_role.rum-role.arn
  }
}

resource "aws_rum_app_monitor" "rum" {
  name   = "${var.environment}-rum"
  domain = var.domain

  app_monitor_configuration {
    allow_cookies       = true
    session_sample_rate = 1.0
    telemetries         = ["performance", "errors", "http"]
    identity_pool_id    = aws_cognito_identity_pool.identity_pool.id
  }
}

これでapplyしたところ、なんとまたログが飛ばなくなってしまいました😭

こちらも原因を探るのにかなり時間を要したのですが、結論から言うとスニペットで利用しているaws-rum-webというパッケージが新しいIdentity Poolに切り替えれていないためでした。

aws-rum-webのドキュメントにこんな記載が、、、

The web client requires AWS credentials to sign RUM payloads. When the RUM web client does not have AWS credentials, it will not attempt to send events to CloudWatch RUM. Your application must either (1) provide the web client with an anonymous Cognito identity using identityPoolId and guestRoleArn, or (2) provide the web client with AWS credentials using the cwr('setAwsCredentials', credentials); command.

要するにRUMは内部でAWSの認証情報を利用していて、cwrコマンドでクレデンシャルを渡すか、identityPoolIdをつかって認証させる必要があるとのこと。

IdentityPoolが切り替えれずに認証に失敗しているのが原因ぽかったので、以下のブログに書いてある方法を試せればよかったのですが、Cognitoのパッケージを使っているわけではないので、こういった解決策も使えませんでした。

最終的には切り替え前から存在するCognito認証用のlocalStorageを削除したら治った

cookieとLocal storageにそれぞれcwr_icwr_cというようなキーの情報が保存されるようになります。
Local storageを削除すると、無事新しい方のidentity poolに認証しにいくようになり、解消しました。
Cognito のidentity poolを切り替えたために発生したと思うので、そのような場合にはこの辺を調べていただくと、なにか解決のヒントが得られるかもしれません。

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?