Synthetic monitoringの分析

Synthetic Monitoring(合成監視)

因果関係を明確にする実験データを取得する

Synthetic Monitoring(合成監視)とは

Synthetic Monitoring(合成監視)とは、1ユーザとして計測機器から能動的に対象のWebサイトにアクセスして監視や計測する手法です。
計測機器から能動的にWebサイトにアクセスして計測する事から、Active Monitoringとも云います。
Synthetic Monitoring(合成監視)は、Webパフォーマンスを計測する方法としてはオーソドックスで、世界的に広く使われています。

Synthetic Monitoringの語源は、Synthetic Dataを取得するところから来ています。
参照:「Synthetic Dataとは」

品質管理のための計測・監視

Synthetic Monitoringは、品質管理のための計測・監視手法です。
品質管理では、管理可能な範囲、限界を明確にします。
管理できない箇所のデータを取得しても、無駄になってしまうからです。

Webパフォーマンスのためにコントロールできる範囲

ユーザの利用環境は、コントロールできるでしょうか？
ユーザの利用環境で、Webサイトの運用側が管理できるのは、HTML、CSS、JavaScriptなどのフロントエンド周りのみです。
それらはユーザがブラウザにインストールしたプラグインや端末性能の影響を受ける事を考慮する必要があります。

ネットワークについては、どうでしょうか？ 1次ISPぐらいまでであれば、CDNを導入したり、トランジット回線を敷設することで管理が可能です。
しかし、ユーザが実際に使っている回線(ラストマイル)については、Webサイトの運用側は管理できません。

「どこまでなら、管理できるのか？」
それを確認し、認識を合わせる事で、管理できる範疇に、人・時間・資金を投じて注力し、品質管理を行います。

品質管理できる範囲・できない範囲

昔、樹木希林さんと岸本佳代子さんが出演していた富士フィルムのコマーシャルで「美しい方はより美しく、そうでない方はそれなりに」という台詞がありました。
この言葉は、品質管理の対象と限界を見事に言い表しています。
フィルムの品質と、被写体がどうかは別だという事です。

それと同じく、Webページを高速に配信するという事と、受信側の端末性能やブラウザのプラグインのインストール状況による遅延は別なのです。

Synthetic Monitoringにおけるフィッシャー三原則の適用

Synthetic Monitoringは、Webパフォーマンスを管理する上で、因果関係を明確にするために利用します。
因果関係を明らかにするには、実験介入して、実験データを取得します。
実験データのみが、因果関係を証明します。

実験は、実験計画法に基づいて行います。
実験計画法の中でも、フィッシャー三原則が基本となります。
参照:「実験計画法とは」

Synthetic Monitoringにおいては、以下のようにフィッシャー三原則を適用しています。

局所管理化

影響を調べたい要因(変数)以外を統一して計測します。
これを局所管理化(Blocking)と云います。
Synthetic Monitoringの場合は、以下の変数を統一します。

マシンスペック
計測・監視に用いるマシンのCPU、メモリ、NICなどを統一します。
OS
OS、OSのバージョンを統一します。
ブラウザ
Webブラウザのバージョンを統一します。

統一した要因(変数)は、Webパフォーマンスに影響を与える変数として除外できます。
以上の変数を固定化できれば、Webパフォーマンスに影響を与える変数は以下のものに絞られます。

ネットワークについては、ISPや、キャリアによって、レイテンシやスループット、経路が異なります。
ネットワークに着目するのであれば、NTT、KDDI、J:COMとネットワーク別に各回線の計測データを分析する必要があります。
物理的な距離に着目するのであれば、札幌、東京、大阪、福岡と都市別に各回線の計測データを分析する必要があります。

このように、ある特徴や性質、共通点に着目してグループ化することを「層別化」と云います。
層別分析を行うことで、あるネットワークでは遅延が生じているとか、ある都市では遅延がエラーになっている等の問題を見つける事ができます。
層別分析を行うためには、複数のネットワーク、複数の都市で計測して、そのデータを比較する必要があります。

次の散布図は、ある全文検索エンジンサービスのDNSの名前解決が、東京のKDDIだけで遅延している例です。
もしも、東京のNTTだけで計測していたら、見つけることはできなかったでしょう。
またAWSの回線で計測していたとしたら、当然ながら見つける事ができなかったでしょう。

層別分析することで、そのグループに特有の遅延などを検出して、ピンポイントで改善することが可能になります。

とある全文検索エンジンサービスのDNSの名前解決が東京のKDDIだけで遅延している例

反復

Webパフォーマンスは、物理的なシステムが関係し、物理的なシステムはかならず性能が揺らぎ、バラツキを生み出します。
このバラツキの分布を把握するために、同条件で反復して計測します。
継続・反復して計測して得られる標本の大きさ(サンプルサイズ)を大きくする事で、計測された値によってつくられる「標本の分布」は、「真の分布」に確率的に近づいていきます。
例えば、15分に1回の計測だと、1日あたり96の標本の大きさとなります。

Webパフォーマンス計測で誤解されがちなのが、Webパフォーマンス計測は、高速であることを確認するためではなく、遅延が生じていない事を確認するために行います。
品質管理の目的は、品質不適合品を世の中に出さない事です。
しかし、Webパフォーマンスについては、表示速度の目標数値を超えたものは配信させないという事ができません。
出荷前の品質検査で品質不適合品を除外できる製造業の品質管理と比べて、Webパフォーマンスの難しい点です。

仮に、表示速度の分布が左右対称で、指標を「表示完了1.5秒」と設定したならば、バラツキを考えて、もう少し高速に「表示完了1秒」で処理できるようにチューニングする必要があります。

表示完了時間の平均が1.5秒の分布と、平均が1秒の分布

標本の大きさは、統計的検定での「検出力」を左右します。
今日のWebパフォーマンスに問題が無かったかどうかを確認するのに、1日1時間に1回計測して標本の大きさが24の場合と、15分に1回計測して標本の大きさが96の場合、どちらが信頼できるかを考えると分かりやすいですよね。

検査の精度を2倍にするためには、標本の大きさを2乗にする必要があります。
ですから、15分に1回の計測で標本の大きさが96の場合、精度を2倍にするには、標本の大きさを96の2乗で9,216にする必要があります。
6.4秒に1回計測する必要があります。

Webパフォーマンス計測を行う場合、以下の3つのフェーズに分かれます。

  1. Webパフォーマンスの現状を把握するために計測するフェーズ
  2. Webパフォーマンスの高速化のために計測するフェーズ
  3. 高速化を達成してからその品質を維持するために監視するフェーズ

いずれのフェーズにおいても、値はバラツキ、そして時間の推移と共に変わっていき、決して一定ではありません。
従って、計測し続けることが大事です。

無作為化

局所管理化や反復でも制御できない可能性のある要因の影響を取り除き、偏りを小さくするために、計測する時間を無作為化します。
Webパフォーマンス計測の場合、15分に1回の頻度で計測するにしても、18:00、18:15、18:30、18:45と、きっかり15分間隔で計測しません。
18:02、18：14、18:29、18:48という具合に、15分の間隔をランダムにばらつかせて計測させます。

代表性

計測を行う際に重要なのが、代表性です。
代表性とは、調査・統計において、標本が母集団をよく代表しているかどうかの程度を指します。

モバイルサイトの計測をするのに、4Gエミュレートをして計測した結果は、携帯網でのパフォーマンスを真に代表するにふさわしいのかといえば、それは違いますよね。
自社のネットワークで計測した値は、NTTやKDDIの値を代表するにふさわしいのかといえば、これも違います。
東京で計測した値は、札幌、大阪、福岡を代表する値かというと、これも違います。

Catchpointが世界各国の各都市の各ネットワークに、私達が全国に計測センターを展開して増やしているのも、この「代表性」が理由です。
代表性は、計測拠点都市の人口を計算することで、人口カバー率として定量化できます。

「Garbage in, Garbage out」(ゴミなデータを入れれば、ゴミな結果が出る)という言葉があります。
せっかく、費用を投じて計測するのであれば、代表性の担保はとても重要なのです。
代表性が担保できていないと、現実世界と乖離してしまうため、計測に投じた費用が無駄になってしまいます。

統計的品質管理のノウハウが詰まったSynthetic Monitoring

以上のように、Synthetic Monitoringは、統計学、統計的品質管理のノウハウを活用して計測します。