この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな ネクストモード株式会社 の吉井です。
re:Invent 2021 期間中、アメリカ時間 2021年11月29日に CloudWatch RUM (Real User Monitoring) が発表されました。
CloudWatch RUM はウェブアプリケーションのパフォーマンス、特にクライアント目線でのパフォーマンス問題の解析や解決に約立つモニタリングです。
私が大好きな One Observability Workshop でも CloudWatch RUM ハンズオンが追加されていましたのでさっそく試してみました。
One Observability Workshop CloudWatch RUM
Real User Monitoringの前提知識
ワークショップをやる前に Real User Monitoring についてほとんど知識が無かったので調べてみました。
Apdexスコア
Apdex スコアはウェブアプリケーションのレスポンスタイムについてのユーザー満足度を計測する標準的な指標です。
Application Performance Index の略です。
Apdex スコアは 0 ～ 1 の間で表現され、0が最も満足度が低く 1がもっとも満足が高いスコアです。
CloudWatch では以下のように定義されています。
| 満足度 | しきい値レンジ | 説明 |
|---|---|---|
| ポジティブ | 2k ミリ秒以下 | Apdex しきい値以下 |
| 許容できる | 2k ～ 8k ミリ秒 | しきい値より大きく、しきい値の4倍以下 |
| イライラする | 8k ミリ秒以上 | しきい値の4倍以上 |
Apdex スコアは以下の式で計算されます。
(positive scores + tolerable scores/2)/total scores * 100
Apdexスコア参考
Apdex スコアのしきい値は CloudWatch RUM では 2k ミリ秒固定のようです。(調べたかぎり)
モニタリング系 SaaS ではしきい値を任意で変更できるサービスがあります。
How CloudWatch RUM sets Apdex scores
Apdex：ユーザー満足度の測定
サービスごとに Apdex スコアを構成する
CloudWatch RUMでのApdexスコア
ウェブバイタル
ウェブバイタルの説明は CloudWatch で表示されるヘルプから引用します。
ウェブバイタルは、ページロード全体のユーザーエクスペリエンスの品質を示すパフォーマンス測定値です。
執筆日時点では以下の3つの観点でのメトリクスが提供されています。
取得されたメトリクスの75パーセンタイルがポジティブしきい値であることが一つの基準です。
これを目指してチューニングしていきます。
| 観点 | 説明 | ポジティブのしきい値 |
|---|---|---|
| LCP(Largest Contentful Paint)、最大コンテンツの描画 | ページ読み込みタイムラインにおいてメインコンテンツの読み込みが完了したと思われる時点。 | 2.5秒以内 |
| FID(First Input Delay)、最初の入力遅延 | 初回入力可能になるまでの遅延時間 | 100ミリ秒以下 |
| CLS(Cumulative Layout Shift)、累積レイアウトシフト | 表示されているページコンテンツの予期しないレイアウトシフトの量 | 0.1以下 |
Web Vitals
Core Web Vitals の指標のしきい値の定義
CloudWatch RUMでのウェブバイタル
経時的なページロードのステップ
この説明も CloudWatch で表示されるヘルプから引用します。
ページのロードプロセスの各ステップにかかった平均時間が表示されます。
グラフには、さまざまな期間の各ステップにかかった平均時間が表示され、経時的な傾向を確認できます。下の棒グラフには、グラフに示されているすべてのユーザーセッションで各ステップにかかった平均時間が表示されます。
ウォーターフォール図、と呼んだほうが馴染み深いかもしれません。
ステップと期間(ステップに要した時間) からどこにボトルネックがあるかを判断します。
このワークショップを試したかぎりでは以下のステップが確認できました。
- アンロードのプロンプト
- リダイレクト
- ワーカー時間
- DNS ルックアップ
- 初期接続
- SSL
- 最初のバイトまでの時間
- ダウンロードされたコンテンツ
- DOM 処理時間
- ロードされた DOM コンテンツ
- ロード
デバイスやブラウザ
これらの情報はブラウザ別、デバイス別、国別に表示することが可能です。
パフォーマンス問題の調査・切り分けにはブラウザ別やデバイス別の表示はとても助かります。
やってみた
One Observability Workshop をやってみます。
サンドボックス AWS アカウント を用意しました。
私は料金を抑えるためにオレゴンリージョンを使います。
ワークショップ環境の作成
Using your own AWS account の手順に従って Cloud9 からデモアプリをデプロイします。
ペットショップのようなサイトが表示されれば OK です。
CloudWatch RUM セットアップ
CloudWatch RUM の手順に従って CloudWatch RUM をセットアップします。
手順を進めていくと途中コードスニペットが表示される箇所があります。
ここに表示されたコードを html ファイルの head 部分に挿入します。
アクセステスト
アクセステストを行います。
テストツールを使ったりチーム内に声をかけて人力でアクセスしてもらうのもあります。
CloudWatch RUM に豊富なデータを表示するためには様々なブラウザ、デバイスでテストを実施したほうが良いです。
私は Windows & Chrome でしか試さなかったので少々後悔しました。
データ探索
CloudWatch RUM を探索してみます。
CloudWatch RUMを選ぶ理由
Real User Monitoring を CloudWatch RUM で行う大きな理由は AWS との統合にあると考えます。
ServiceLens や X-Ray との組み合わせ、CloudWatch コンソールでの完結 (1-Console)、IAM での権限管理など管理面の優位性はあります。
世の中には様々な RUM 関連製品がリリースされております。
Real User Monitoring に求める要件を整理してもらい最適なサービスを選択していただければと思います。
参考
新機能 – Amazon CloudWatch のリアルタイムユーザーモニタリング
One Observability Workshop
以上、吉井 亮 がお届けしました。
7
