パフォーマンスのモニタリングによりエンドユーザーを理解する
Director Product | Managing Director - NYC
Fastly では、世界中のできるだけ多くの地域やネットワークプロバイダーのコンテンツ配信ネットワーク (CDN) パフォーマンスを常にモニタリングしています。パフォーマンスのモニタリングは、サーバーやネットワーク機器のみでなく、エミュレートやエンドユーザーエクスペリエンスの理解においても重要です。
パフォーマンスをモニタリングするためのツールは数多く存在しますが、この投稿では Catchpoint に的を絞ってお話します。以下の原則は、あらゆるサードパーティのパフォーマンスモニタリング (TPM) を行うベンダーに適用できます。
パフォーマンスを測定する理由
パフォーマンスは、Web を活用するあらゆる業界にとって必要不可欠です。サイトまたはモバイルアプリケーションでのユーザーインタラクションは、直接コンバージョンやエンドユーザーの満足度に影響します。たとえば、Marissa Mayer による Google の実験では、Google 検索結果の表示件数を30件に増やすと、Google のトラフィックと収益が20%低下しました。ユーザーは表示件数の増加を望んでいたのに、トラフィックと収益が低下したのはなぜでしょうか。調査の結果、表示件数の増加によってページの読み込み時間が0.4秒から0.9秒に増加したことがわかりました。0.5秒の遅延が20%のトラフィック低下を招き、ユーザーの満足度低下に直接影響を与えたのです。
最も重要なのは、ユーザーがパフォーマンスを重視しているということです。だからこそパフォーマンスを監視、把握する必要があります。
モニタリング : 可用性とパフォーマンス
可用性のモニタリングの実行は、インフラストラクチャが問題なく作動しているかどうかを確認するのに大きな役割を果たしますが、エンドユーザーエクスペリエンスについて把握することはできません。
インフラストラクチャの可用性をモニタリングする場合、ストレージ容量が十分であること、ネットワークポートに空きがあること、サーバーに負荷がかかりすぎていないこと、すべてのインフラストラクチャコンポーネントが健全であることを確認します。サーバーが稼働しているかどうか、サーバーにより大きな RAM が必要かどうか、ISP に新しいネットワークポートを注文すべきかどうかなど、インフラストラクチャ指標自体に焦点を当て、バイナリ計測により結果を評価することも一般的です。こうした指標を内部で確認するだけでは、シンセティックまたはリアルなユーザー計測が欠如した、近視眼的な環境の観測につながります。また、これは主に緊急事態 (何かが停止した場合など) に対応するために使用され、過去のインサイトやレポートツールが含まれない場合が多々あります。
一方、パフォーマンスのモニタリングでは、ユーザーに表示される内容を確認し、ユーザーとブラウザまたはアプリケーションの動作をより深く理解できます。可用性のモニタリングは、内部のインサイトのみに制限されます。パフォーマンスのモニタリングでは、グローバルで多様性に富み、シンセティックまたはリアルなユーザーベースの表示、そしてブラウザ表示が可能で、より包括的な状況を確認できます。また、価値のあるトランザクションのインサイトを収集し、過去の傾向を評価できるため、パフォーマンスの向上と効果的な調整を行うことが可能です。
サードパーティモニタリングツールが可視性を向上させる方法
TPM ツールを使用すると、ネットワークの多様性や地理的な配分、データに対して複雑なクエリを実行する機能、各トランザクションのパフォーマンスに関するインサイト、さまざまな種類のエンドポイントをエミュレートする機能など、グローバルにユーザーエクスペリエンスを確認できます。これらを独自データと組み合わせることも可能です。
こうしたツールを使用すると、重要なイベントに関連して必要となる過去のデータ (ソフトウェアの新リリースなど) を確認し、スタックの使用状況に関するアプリケーションレベルのインサイトを取得できます。TPM では、効果的な A/B テストを実行し、ベンターとパートナーをモニタリングすることが可能です。例えば、ホームページに埋め込んだパートナーがきちんとキャパシティプランニングを行っていないため、サイトのパフォーマンスが優先されていないことなどを確認できます。
Fastly では、すべてのお客様に Fastly のパフォーマンスを追跡するようおすすめしています。すべてのベンダー、特に CDN のパフォーマンスを把握することは重要です。
配慮すべき主要コンポーネント
次に、配慮すべき主なモニタリング要件の一部をご紹介します。
DNS ルックアップ。DNS は、ほぼすべての Web トランザクションの根源です。Fastly のお客様の場合、このプロセスはアップストリームリゾルバから DNS ルックアップを行うテストエージェントによって構成され、リゾルバはお客様の Fastly の設定によって CNAME または A レコードを使用して応答します。通常、お客様には1つ以上の A レコードを提供します。理想としては、権威 DNS プロバイダー (Fastly では Dyn) がこれらのリクエストを地理的に近いロケーションで受信し、リクエスト元のクライアントに最も近いサーバーの適切な IP アドレスを提供することです。権威 DNS (お客様の大半が NSOne、Dyn、Verisign などを使用) をアウトソースする場合、改善または問題はこれらのアウトソース先に依存するため、情報を確認してください。独自の権威 DNS サーバーを実行している場合は、これらのサーバーをグローバルに分散させ、エニーキャストネットワークを実行する方法を確認してください (この作業は簡単ではありません)。これに関連する話題としては、サードパーティツールの DNS 時間が実際の時間と比較して「重み付け」されている点ですが、これは別の投稿で説明します。
接続。ネットワークセッションと初期 TCP セッション (SYN<>ACK<>SYN/ACK) のエンドツーエンドの確立です。Web ページのルートオブジェクトを取得する場合 (www.yoursite.com のプライマリ URL)、単一の接続が確立され、それが接続時間となります。Web ページ全体をテストする場合、多くのブラウザが6つ同時に接続を確立します。そのため、テストベンダーが報告している指標の実際の内容と参照元を確認してください。この指標は、往復のレイテンシ (主流のインプット) とハードウェアの過負荷によって発生するペナルティによって導き出されます。地理的 (例えば、このコンポーネント改善の主要な方法として、新しいロケーションの追加など) および物理的 (TCP 接続が過負荷状態の場合、サーバーまたはロードバランサーを追加) にインフラストラクチャ分散を増加させることで改善できます。
TLS ハンドシェイク。多くの Webサイトがサイト全体をトランスポートレイヤーセキュリティ (TLS) に移行しており、Google は安全な HTTPS 接続を使用しているサイトを検索結果の上位に表示するようになりました。TLS ハンドシェイクの確立に要する時間には、注意が必要です。TLS ハンドシェイクでは往復の通信が複数回発生するため、ページの読み込み時間に大きく影響します。そのため、できる限りユーザーの近くで TLS を終端すること (CDN の使用など) が重要です。独自 (またはベンダー) の TLS スタックが最適化されていることも確認してください。サードパーティのベンダー (CDN、ELB) を使用して TLS を終端させている場合は、パフォーマンスとセキュリティの両方を確認します。
WAIT または最初の1バイト。接続が設定された後の WAIT とは、プライマリ URL のレスポンスの最初の1バイトを受信するまでにかかる時間です。簡単に言うと、接続時間と、最初の1バイトをクライアントに戻すまでのディスクペナルティを指します。コンピューティングの遅延 (ディスクまたは RAM から画像を取得する時間など) が0の場合、これが接続時間となります。物理的に、WAIT 時間が接続時間より短くなることはなく、巧みに設計され適切に測定されたアーキテクチャでは、平均値は2ミリ秒未満です。CDN ユーザーへの注意事項としては、パススルーでは (中間キャッシュにはコンテンツを保存しないよう伝え、CDN はオリジンからコンテンツを取得する必要がある) WAIT と接続時間は大きく異なるということです。
コンテンツダウンロードまたは LOAD。テストする URL の最初の1バイトの読み込みから最後の1バイトの読み込みまでにかかる時間です。これは帯域幅のレイテンシの機能であり、クライアントとサーバー間の TCP フロー制御アルゴリズムの機能を示します。OS レベルでの多くの調整によって向上させることが可能ですが、単純に送信データの削減が最も効果的なため、できる限り圧縮することをおすすめします。すべての最新ブラウザは gzip 圧縮に対応しているので、Web サーバーまたはロードバランサー側で設定するか、CDN を使用している場合は CDN で設定できます。
以下は Catchpoint Performance Chart です。同じオブジェクトを CDN 経由とオリジンから直接読み込んだ場合のパフォーマンスを示しています (こちらで使用する用語には Catchpoint 特有のものが多くあります。これらのコンポーネントを他の言葉で表すツールも多く存在します)。本ブログで取り上げた5つのコンポーネントと、すべての個別コンポーネントの合計値を示す「Webpage Response (ms)」をご確認いただけます。
次のステップ
まずは、サイトでテストを実行し、Web Page Test で最適化スコアを確認することから始めましょう。異なる TPM ベンダー (Fastly の推奨は Catchpoint ですが、他にも多くのベンダーが存在します) について調べ、ベンダーがどのようにパフォーマンスをテストしているのかを把握します。このプロセスに対する時間と資金の投資を惜しまないでください。節約すべき領域ではありません。
上記に示したとおり、パフォーマンスのモニタリングはエンドユーザーを理解するために必要不可欠です。取得したデータを活用し、主要な指標への注力や改善を実現しましょう。
