Synthetic Monitoring：複数の地域における読み込み時間を自動測定

Synthetic Monitoringが示すもの

Synthetic Monitoringは、ウェブサイトに対して定義されたテストを自動的かつ定期的に実行します。ある チェック その際、目標、スケジュール、測定ポイント、成功基準などを記述する。各測定ポイントでの実行ごとに独自の結果が生成されるため、構成は単一の測定と同一視することはできない。

一方、1回限りのグローバルパフォーマンステストでは、その実行時の条件下における「その瞬間の状況」しか示されません。繰り返し ウェブサイト監視 逸脱が再発したかどうか、また結果が時間の経過とともにどのように変化するかを可視化します。こうした比較に意味を持たせるためには、目標、測定環境、および測定場所が明確に識別できる必要があります。

クラウドデータセンター内のパブリック測定ポイントは、特定の地域およびインフラストラクチャからウェブサイトを測定します。しかし、その接続環境は、必ずしも現地のプライベートなインターネット接続環境と一致するわけではありません。ルーティング、ネットワークの遅延、およびコンテンツ配信元インフラストラクチャまでの距離などが結果に影響を与える可能性があるため、「速度が遅い」という評価は、まずはこの具体的な測定経路に関するものです。

A プライベートレッスン 別の疑問に答えることができます。それは、プライベートネットワークからアプリケーションにアクセスできるかどうかを確認できるということです。これは例えば社内サービスに関しては重要ですが、パブリックインターネットからのアクセス可能性を証明するものではありません。逆に、パブリックネットワークからのチェックに成功したとしても、あらゆる企業ネットワークからのアクセスが機能するかどうかは分かりません。

したがって、計画を立てる際には、各検証項目を具体的な質問として定式化することが有効です。「重要なターゲット地域から製品ページにアクセスできるか、また、そこで期待されるコンテンツが表示されるか？」という問いです。その答えは、選択した測定ポイントとテスト条件に当てはまるものです。これは再現可能な指標ではありますが、すべての訪問者やその端末を完全に反映したものではありません。

HTTP、ブラウザ、およびジャーニー

A HTTPチェック エンドポイントを照会し、例えばステータスコードやレスポンスを評価します。製品ページの場合、サーバーが期待どおりに応答していないことを即座に表示できます。ただし、HTTP 200が返されたとしても、それは単に検証対象のレスポンス基準が満たされたに過ぎず、インターフェースが表示され、操作可能かどうかは不明のままです。

ブラウザチェックでは、自動化されたブラウザで同じ製品ページを読み込みます。これにより、期待される見出しが表示されるかどうかを確認したり、ブラウザ固有の測定値を収集したりできます。HTTPステータスが成功しているにもかかわらずこのチェックに失敗した場合は、レンダリングやページの内容を調査する価値があります。 ただし、この差異だけでは、特定のエラー原因を証明するものではありません。

A ジャーニー・チェック 単なる読み込みにとどまらず、定義された手順を実行します。例えば、ログイン時にはログインページを開き、適切なテストアカウントでログインを行い、その後、期待される要素を確認します。この最後の基準によって初めて、テスト対象のフローにおいて、単にログインページにアクセスできただけでなく、正常に処理されたことが示されます。

ジャーニーが成功したとしても、それは実際に実行された手順や条件が確認されたに過ぎません。テストされていないパスワードリセットや、別のブラウザでは、それでも問題が発生する可能性があります。そのため、業務上重要なプロセスをいくつか選び、各ステップについて検証可能な結果を明確に定義し、単にページが正常に表示されたという事実だけでサービス全体が正常であると結論づけないようにしてください。

補足的な視覚的検査を行うことで、個々の要素のチェックだけでは検出できない表示上の変化を調査することができます。そのために、例えばスクリーンショットを比較することができます。ただし、目に見える変化がすべてエラーであるとは限らないため、差異についてはその後、適切に分類する必要があります。その他のアプローチについては、以下の記事で解説されています。 ビジュアル検証と自動化されたサイトチェック.

読み込み時間を正しく見分ける

„「読み込み時間」という表現は、特に断りがない限り、明確に比較可能な指標を指すものではありません。ページにアクセスした際、まず注目すべきはサーバーからの最初の応答までの時間です。これは、応答が届くまでの遅延を把握するのに役立ちます。しかし、この時間だけでは、ブラウザが何かを表示し始めた時期や、ページが完全に処理された時期までは分かりません。

最初に表示されるレンダリングは、その後の段階を表しています。つまり、ブラウザが初めてコンテンツを表示する段階です。この時点では、まだ主要なページコンテンツが表示されていない一方で、短いテキストやその他の初期要素がすでに表示されている場合があります。したがって、早期に表示が始まるからといって、必ずしもすぐに利用できる製品ページであるとは限りません。

仝 最大のコンテンツ・ペイント (LCP) は、表示領域内で最も重要なコンテンツ要素が最初に表示されるタイミングを測定します。商品ページの場合、それは例えば大きな商品画像などです。LCP の比較は、適切に指定された LCP 値とのみ行い、ブラウザやネットワークの状態も記録しておいてください。サーバーからの応答までの時間は、別のフェーズで測定されます。

仝 スクリプトの再生時間 とはいえ、これは必ずしも個々のページの読み込み時間とは限りません。スクリプトは複数のページを呼び出し、要素の読み込みを待ち、ログイン処理を行うこともあります。Grafanaのk6ブラウザチェックにおいて、表示されるスクリプト実行時間は通常、k6の起動時間を含んでいません。こうしたツールの制限も、結果の解釈において考慮すべき点です。

「Interaction to Next Paint」（略称：INP）は、ユーザー操作に対する反応に関する指標です。シミュレーションでは、実際に実行した操作のみを分析することしかできません。したがって、所定の条件下で自動生成されたクリックデータだけでは、異なるデバイス、接続環境、操作経路を利用している実際の訪問者全員の体験の分布を把握することはできません。

対象地域向けの測定計画

測定計画は、その機能に不具合が生じた場合にビジネスに重大な影響を及ぼすページやフローから始めましょう。これには、商品ページ、会員登録ページ、インターフェースなどが含まれます。 次に、ターゲット市場に合わせて測定地域を選択してください。重要なユーザー地域をカバーしている場合や、既存の地域別モニタリングを補完する場合、追加の測定地域を設定することは特に有効です。

の場合 同様のチェック ブラウザとバージョン、デバイスの表示モード、ネットワーク環境、キャッシュの状態を記録してください。さらに、実行間隔やタイムリミット、期待される応答や表示される要素についても記録してください。そうすることで、後で測定環境の変更と結果の差異が関連しているかどうかを判断できるようになります。

以下の表は概念的な例であり、実測値に基づくものでも、一般的に推奨される運用計画でもありません。間隔やアラーム条件については、ウェブサイトの重要度や選択したサービスの機能に合わせて調整する必要があります。

この表はあくまで出発点に過ぎません。チェック設定で、具体的な時間制限やその他の測定条件を追加してください。他の拠点で正常に報告されていても、地域ごとのアラームはそれ自体として意味を持ちます。その際、クラウド上の測定ポイントが、必ずしも同じ地域にあるプライベートなインターネット接続を表しているわけではないことに留意してください。

チェックとテスト手順の設定

独自のテストページを作成するには、まず、期待されるステータスコードを確認するHTTPチェックを作成します。さらに、同じページにアクセスし、期待されるヘッダーを検出するブラウザチェックを追加します。 最初のチェックはエンドポイントからの応答を検証し、2つ目のチェックは、期待されるコンテンツがブラウザに表示されているかどうかの確認も併せて行います。

各実行について、測定場所、時刻、結果、および関連する所要時間を記録してください。HTTPチェックが成功したにもかかわらずブラウザチェックが失敗した場合は、すぐに特定のエラーを想定するのではなく、コンテンツとレンダリングを調査してください。 また、見出しが意図的に変更されたのか、それともタイムアウト設定が短すぎたのかについても確認してください。

登録するには、[] をクリックして ジャーニー ログイン後の入力や検証を伴うブラウザ呼び出し。権限を可能な限り制限した別のテストアカウントを使用し、ログイン後の領域において、個人を特定できない安定した要素を検証してください。ログインページへのアクセスが成功しただけでは、ログイン機能が正常に動作しているとは限りません。

選ぶ 安定したセレクタ また、決まった間隔だけで待つのではなく、予想されるコンテンツを的確に待ち受けるようにしてください。アクセス情報は、スクリプトやログではなく、利用しているサービスの「シークレット管理」に保存してください。インターフェースに変更があった場合は、セレクタや成功基準が依然として想定されたフローに合致しているかを確認してください。

テスト手順を安全な操作に限定する：定期的に実行されるジャーニーでは、実際の注文や支払いが発生しないようにする。書き込み操作が避けられない場合は、そのために明示的に用意されたテスト環境、または管理されたテストプロセスが必要となる。 また、テスト実行が失敗した場合の調査やテストデータの管理を担当する者を明確に定めておくこと。

ツールと運用モデルを比較する

ツールを検討する際は、管理型の監視サービスと、当初は単にテストを実行するだけのツールとを区別する必要があります。重要なのは、ブラウザがサポートされているかどうかだけではありません。適切な監視拠点、定期的な実行、結果の保存、そして自社の運用に適したアラート機能も必要です。

Grafana Cloud 合成モニタリング チェック構成をパブリックおよびプライベートのプローブと連携させ、k6ベースのブラウザチェックをサポートします。パブリックとプライベートの測定ポイントは、それぞれ異なる到達可能性に関する質問に答えます。 また、事前に利用可能なチェック頻度も確認してください。ブラウザチェックやスクリプトチェックには、一部の単純なエンドポイントチェックとは異なる制限が適用されます。

現地で実施された k6ブラウザモジュール これは別個に扱う必要があります。これにはk6とChromiumベースのブラウザが必要です。ローカルでのスクリプト実行では、地域ごとの測定ポイントや恒久的なスケジュールは自動的に設定されません。分散型モニタリングを行うには、実行、インフラ、結果管理を別途整備するか、適切なサービスを利用する必要があります。

AWS CloudWatch Synthetics は、スケジュールされたカナリアテストを実行します。その マルチロケーション機能 指定したAWSリージョンにCanaryを複製し、結果をプライマリリージョンに集約します。導入前に、サポートされているNode.jsのPuppeteerまたはPlaywrightランタイムのドキュメントに記載されている最小バージョン、およびこの機能のリージョンごとの利用可能性を確認してください。

自社で運用するプローブは、設置場所や環境をより細かく制御できますが、その一方で、測定インフラのメンテナンス、更新、監視も必要となります。 すべての運用モデルについて、実際に提供されている設置場所、利用量に応じた費用、およびデータ保管の条件を比較検討してください。特に、スクリーンショットやログがどこに保存されるか、そしてそれが自社のデータ保護方針に合致しているかどうかを明確に確認してください。

地域別の結果を適切に分析する

同じページおよび同じ期間について、地域ごとの結果を比較してください。ブラウザ、バージョン、ネットワーク環境、キャッシュの状態は一致している必要があります。一致していない場合、差異は配信ではなく測定環境に起因する可能性があります。また、クラウド測定ポイントは特定の場所とネットワーク経路を反映するものであり、その地域のすべての接続を網羅するものではありません。

測定が繰り返し成功した場合、 中央値 ソートされた結果の中央値。上位のパーセンタイル（例えば95パーセンタイル）は、実行速度の遅いケースを明らかにします。対象となる値の95パーセントは、この値以下となります。この際、分析の範囲がどの程度広いかが分かるよう、期間と測定回数を記録しておいてください。

実行回数が少ない場合、1回の処理に時間がかかると、上位パーセンタイルに大きな影響を与えることがあります。そのため、長期的な地域的なパフォーマンスの低下を想定する前に、時間の経過に伴う推移を確認し、複数の測定期間を比較してください。また、測定ポイントやブラウザのバージョンの変更も、評価結果に変化をもたらす要因として考慮する必要があります。

待って 失敗した実行 個別に表示される必要があります。例えば、エラー数や全実行回数の割合としてです。そうでないと、成功した呼び出しのみを含む読み込み時間統計では、タイムアウトが頻繁に発生している領域が誤って良好に見える可能性があります。有効な読み込み時間値がない失敗の場合、通常の読み込み時間を単純に代用することはできません。

リアルユーザーモニタリングは、管理されたテストに実際の訪問者の体験を補完するものです。 Chrome UXレポートは、28日間のローリングウィンドウを通じて利用可能な実環境データを提供しますが、すべてのページやユーザーグループが対象となっているわけではありません。したがって、この長期的な視点は、最新の合成アラートの代わりとなるものではなく、また単一のテスト実行と直接同等と見なすこともできません。

アラームと地域別のトラブルシューティング

A グローバルアラーム 複数の拠点で繰り返し発生するエラーをまとめて把握することができます。これにより、単一の計測ポイントにおける孤立した不具合と、より広範囲にわたるインシデントとを区別しやすくなります。同時に、地域ごとのアラート条件も設定してください。重要なターゲット市場で障害が発生した場合、他の地域の好調な状況によってその問題が覆い隠されてしまわないようにするためです。

プロセスの重要度に応じて、繰り返し回数と時間枠を選択してください。 連続して複数の検査に失敗した場合、短期的な異常値を捕捉することはできますが、通知が遅れることになります。また、測定ポイント自体も監視し、1つのサンプルに不具合があったのか、それとも同じ場所での他の検査も同様に影響を受けているのかを確認してください。

ある製品ページが特定の場所でのみ表示が遅い場合は、まず同様のアクセス状況と、異常が発生したタイミングを比較することから始めましょう。 その後、DNS解決、CDN配信、リソースの読み込み時間、サーバーの応答時間を調査してください。ネットワーク経路の違いやインフラへの距離は、地域ごとの基準値に影響を与える可能性があります。測定値だけでは、原因を特定することはできません。

他のOriginsのリソースについては、ブラウザ測定の詳細が制限される場合があります。適切な Timing-Allow-Origin-ヘッダーでは、Resource Timing API の個々の値が 0 になることがあります。これは必ずしも接続が極めて高速だったことを意味するわけではありません。まず、外部サーバーが測定のためにどの情報を公開しているかを確認してください。

次の調査段階では、発生時刻、地域、影響を受けた処理を、利用可能なログやトレースと関連付けます。これにより、相関関係から直接原因を断定することなく、例えば処理が遅いリクエストを特定することができます。メトリクス、ログ、トレースがどのように連携するかは、以下の記事で解説されています。 ホスティングにおけるオブザーバビリティ.

モニタリングを継続的に実施する

まずは、重要な公開対象に対する簡単なエンドポイントチェックから始め、ビジネスに不可欠なページやログインページについては、ターゲットを絞ったブラウザ・ジャーニーを追加してください。 HTTPチェックはより頻繁に実行できる一方、より手間のかかるブラウザテストでは、選択した機能を検証します。実行間隔は、一律の分単位ではなく、希望する検知時間、サービスの上限、およびコストに合わせて設定してください。

各チェックについて、次のものを決定してください。 管轄: アラームは誰に通知され、影響を受けたサービスを誰が確認し、測定ポイントを誰が管理するのか。また、アラームがいつ転送されるか、関連する結果がどこで確認できるかも明記しておいてください。繰り返されるエラーに対して何の対応も行わないチェックでは、データは得られるものの、インシデントは解決されません。

インターフェースに変更があった場合は、セレクタや想定されるコンテンツが依然として処理の流れに合っているかを確認してください。 スクリプト内では、固定の遅延時間だけに頼るのではなく、必要な要素が現れるのを待機するようにしてください。ブラウザ、ネットワークプロファイル、またはキャッシュ設定の変更については、後で比較を行う際に、測定条件の違いが気づかれないまま混在してしまうことがないように、必ず記録しておいてください。

スクリーンショットやログは、機密性の高いデータである可能性があるとみなしてください。これらは、セッションの内容やアプリケーションからの情報を含んでいる場合があります。目的に応じてアクセスと保存を制限し、テストで実際に何が記録されているかを確認してください。 ログインには制限付きのテストアカウントを使用し、アクセス情報はスクリプト内ではなく「シークレット」として管理してください。

定期的に以下の点を確認してください。 測定地点 さらに、それらがターゲット市場に適しているか、また料金体系、データ管理、およびデータ保護要件が引き続き運用を許容するかどうかを確認する必要があります。自社で運用するプローブの場合、環境の更新と監視も追加で必要となります。ローカルで起動した k6 ブラウザスクリプトだけでは、永続的な分散型監視インフラストラクチャを構築することはできません。