外形監視とは？

外形監視で重視するのはWebサイトのパフォーマンスです。クライアントとアプリケーションサーバー間のトランザクションパスをエミュレートし、何が起きるかを監視します。

その目標は、ユーザーがアプリケーションやWebサイトで実際にどのような体験をしているかを理解することです。

このブログ記事では、外形監視について詳しくご説明します。外形監視ツールと戦略からより多くのメリットを得る方法もご紹介します。

外形監視とは

外形監視は、IT監視の一種で、Webサイトのパフォーマンスに重点を置いています(IT監視にはほかに、アプリケーションパフォーマンス監視やリアルユーザー監視などがあります。それぞれ独自の強みと弱みがあるため、別のカテゴリとして分類されています)。

外形監視では、以下のような疑問点を明らかにできます。

• Webサイトのパフォーマンスと可用性：Webサイトは正常に動作しているか？ページの読み込み速度は十分か？
• インシデントの解決：ショッピングカートでの処理が失敗する問題は解決したか？
• 最適化の機会：このトランザクションの中でユーザーが操作に行き詰まる箇所はないか？どこをどのように最適化できるか？

適切な外形監視ツールを使えば、すべての開発工程でテストを実施し、管理された環境で24時間365日体制の監視を行うことができます。また、A/Bテストによるパフォーマンスの効果測定、ベンチマークによる競合企業との比較、地域ごとのパフォーマンスのベースライン設定や傾向分析などもできます。

(大規模環境に対応した先進的な機能を提供するSplunk Synthetic Monitoringについては、こちらのWebサイトをご覧ください。)

外形監視の仕組み

外形監視ツールのベンダーは、リモートの(多くの場合はグローバルな)インフラを提供しています。このインフラがWebサイトに定期的にアクセスし、毎回、パフォーマンスデータを記録します。

重要なのは、測定されるトラフィックは実際のユーザーのものではなく、ページのパフォーマンスに関するデータを収集するために合成されたものであることです。

シンプルな外形監視シミュレーションは、3つのコンポーネントで構成されます。

• エージェントノード：Webサービスコンポーネントを能動的に調査します。
• シナリオ生成コンポーネント：クライアント/サーバー間のトランザクションが行われる環境の特性を指定します。
• 動的Webサービスコンポーネント：指定された環境特性を通じてワークロードをシミュレートします。

外形監視では、スクリプトを作成して、さまざまなシナリオ、オブジェクトタイプ、環境変数に対応したクライアント/サーバー間のトランザクションパスを生成できます。外形監視ツールは、このスクリプトに記述されたカスタマージャーニーに沿ってアプリケーションやWebサーバーとやり取りし、アプリケーションパフォーマンスデータを収集および分析します。

1. 外形監視エージェントが、ターゲットのWebサービスコンポーネントを能動的に調査して、トランザクションの応答を生成します。
2. 外形監視ツールが、ターゲットとの接続を確立し、エンドユーザーが通常実行する操作でのパフォーマンスデータを収集します。

外形監視でのチェック対象

外形監視でのチェックは定期的に行われます。チェックの実行頻度は通常、チェックする対象によって決まります。たとえば、可用性をチェックする場合は、1分に1回程度が最適です。

以下の項目を含め、あらゆる種類のパフォーマンスを監視できます。

ブラウザ監視：最新のWebブラウザを使ってWebサイトにアクセスするユーザーのエクスペリエンスをシミュレートします。複数の位置情報を使って短い間隔で実行し、以下のような場合にアラートを送信することもできます。

• サイトやアプリケーションを利用できない
• パフォーマンスがベースラインを下回った

クリックパス監視：ユーザーのアクセスを監視する点はブラウザ監視と同じですが、クリックパス監視では特定のワークフローを監視します。Webサイトの操作をシミュレートする独自のスクリプトを作成し、定期的に実行して、クリックなどの特定のユーザー操作を監視できます。

リンク切れ監視：スクリプトを作成して、特定のURLのリンクすべてをテストします。すべてのエラーが報告されるため、それに基づいて、切れているリンクを個別に調査できます。

HTTP監視：HTTPリクエストを送信して、特定のAPIエンドポイントやリソースが利用できるかどうかを確認します。パフォーマンスのしきい値を設定して、ベースラインを下回ったときにアラートを送信できる製品もあります。

外形監視とリアルユーザー監視の違い

• 外形監視：合成した(実際のユーザーや操作のデータではない)トラフィックデータを使って、ページパフォーマンスのデータを収集します。
• リアルユーザー監視(RUM)：Webサイトやアプリケーションの各ページにエージェントを組み込みます。エージェントは、各ページが実際にリクエストされるたびに、ページの読み込みに関する実データを報告します。

クライアント/サーバー間通信の遅延シナリオ

クライアント/サーバー間通信のさまざまな遅延シナリオについて考えてみましょう。

• ネットワーク障害または依存システムの問題で発生したサービス全体での遅延：この場合、すべてのユーザーで応答時間の大幅な遅延が発生します。サービス全体の遅延シナリオの例としては、新機能をリリースしたものの、そこに時間のかかるデータベースクエリ―が含まれ、QAプロセスで見落とされていた場合などがあります。
• Webサービスインフラの一部にのみ影響する部分的な遅延：たとえば、ハードウェアの問題がロードバランサーに影響したために、1台のサーバーで起きた問題による部分的な遅延が他のすべてのサーバーに波及する場合などがあります。
• 定期的または非定期に繰り返される遅延：たとえば、定期的なデータバックアップがネットワーク帯域幅を占有し、サービス利用のピーク時間帯に遅延が発生する場合などがあります。

外形監視エージェントが実際のユーザーの行動をエミュレートし、外形監視ツールが、事前定義されたメトリクス(可用性や応答時間など)のデータを収集します。エージェントは、プログラムされたテストルーチンに従って動作します。ルーチンでは以下のような項目を設定します。

• テスト対象のWebサービスコンポーネントのID
• エージェントとWebサービス間で行われる一連のプロセス、アクティビティ、やり取り
• データのサンプリング間隔とテスト時間

シナリオ生成コンポーネントを通じて、パフォーマンス低下やネットワーク障害を再現するさまざまなテストシナリオを挿入できます。各種エージェントの分散方法を指定して、異なるデータセンターからWebサービスにアクセスするグローバルなユーザーベースをシミュレートし、その状況での展開や変化を指定することができます。

外形監視で注目すべき結果

外形監視レポートの出力には、グラフや時系列データが含まれます。各種の統計分析手法や機械学習手法を使って、これらの出力をさらに詳しく分析できます。

アナリストは通常、以下の調査を行います。

• スパイク：データトラフィックの急増によるパフォーマンスの急激な変化を示す指標です。
• 定期的なインジケーター：クライアントエージェントからのリクエストに対するサービスの応答で定期的に発生する遅延などが該当します。
• 傾向：時系列データ全体にわたって見られる、緩やかであるものの一貫した変化を指します。
• 外れ値：異常な行動を示している可能性があります。必要に応じて、詳細分析によって重大度を特定し、費用便益分析によってその問題に対処すべきかどうかを判断します。
• 探索的分析：時系列データで、問題発生やエージェントによる操作の前後の変化を評価します。
• 変化点分析：移動平均を計算し、傾向分析と関連付けて変化を評価します。この手法を使えば、ユーザーエクスペリエンスジャーニー内での大きな変化を評価できます。
• フィードバックサイクル/ループ：現在の監視結果から得た知見に基づいて、今後の監視シナリオを計画します。

エージェントによる能動的な調査は、API監視、コンポーネント監視、パフォーマンス監視、負荷テストなど、幅広いタイプの監視に活用できます。

重要なのは、実際の利用シナリオをオンデマンドでエミュレートする点です。これにより、発生頻度が低くいつ起きるかわからないやり取りも調査できます。

組織で利用するために必要な外形監視機能

外形監視の基本を理解したら、次に考えるべきは、組織のニーズに最適なツールの選び方です。エンタープライズクラスの強力な外形監視ツールに求められる機能をご紹介します。1つずつ詳しく見ていきましょう。

ユーザーフローとビジネストランザクションのスクリプト作成

外形監視の主なメリットの1つは、テストするアクションを具体的に定義して、アプリケーションの主な処理の流れ(決済フロー、登録フローなど)を再現し、その機能やパフォーマンスを検証できることです。この機能は一般に、スクリプト作成と呼ばれます。スクリプト作成機能がどれだけ充実しているかは、ツールの有用性に直結します。

スクリプト作成機能については、以下のような点をチェックしましょう。

• スクリプトをどのように記録するか
• ブラウザベースのレコーダーはあるか
• コードや手順を手動で記述する必要があるか
• 記録されたテストを手動で編集できるか、または全体を記録し直す必要があるか
• スクリプトを記録するためにどの程度の技術的知識が必要か
• 業界標準の形式(Selenium IDEなど)のスクリプトをインポートできるか

組織のWebサイトは頻繁に変更されるため、スクリプトが機能しなくなることがあります。そのため、ツールが以下のようなトラブルシューティング機能を備えているかどうかも重要なポイントです。

• スクリプトをテストできるか
• 失敗したステップとその原因が報告されるか
• スクリプト実行中のスクリーンショットやビデオをキャプチャして、ボタンやフォームフィールドが見つからなかったときの画面の様子を確認できるか
• 必要に応じて、スクリプトを業界標準の形式でエクスポートして別のツールでトラブルシューティングできるか

例として、ミッションクリティカルなユーザー決済フローをテストするときの業界標準のSelenium IDEレコーダーの画面を次に示します。

パフォーマンスの測定と比較

What-Ifシナリオを使ってさまざまな状況を試し、パフォーマンスへの影響を確認できることも、外形監視ツールの大きなメリットです。各シナリオでのパフォーマンスの変化を簡単かつ明確に把握するための高い柔軟性と幅広いオプションを備えているかどうかが重要なチェックポイントです。

一般的なシナリオをいくつかご紹介します。

• コンテンツ配信ネットワーク(CDN)を利用する場合、利用しない場合、または異なるCDNを利用する場合の、サイトのパフォーマンスをテストする
• 特定のサードパーティサービスを除外した場合の、パフォーマンスへの影響を確認する
• モバイルとデスクトップ、または異なるモバイルデバイスでのパフォーマンスを比較する
• 単一障害点の影響を調査する
• さまざまなA/Bテストグループのパフォーマンスを測定する
• 一部のユーザーのみにリリースする新機能をテストする
• 地理的な場所を変えてテストを行い、地理的な要因によるパフォーマンスへの影響を確認する

これらのシナリオをどれだけ細かくテストできるかは、外形監視ツールにテスト制御オプションがどれだけ用意されているかによって決まります。一般的なWebパフォーマンステストの結果を評価するために役立つ設定オプションには以下のものがあります。

• 特定のドメインまたはURLのリクエストをテストで除外するように設定できるか
• DNSまたはホスト名をオーバーロードして別のIPアドレスを指すように設定できるか
• テスト用に特定のCookieをプリロードできるか
• 4Gや5Gなど、ネットワーク接続を変えてテストできるか
• 独自のHTTPヘッダーを指定してリクエストに追加できるか
• 使用するデバイス、ビューポート、ユーザーエージェントを指定できるか
• 位置を指定できるか、また、位置をどのくらい詳細に定義できるか(「カナダ」だけか、または「カナダのブリティッシュコロンビア州バンクーバー」まで指定できるか)

テストオプションを設定することは、まだ道のりの半分にすぎません。これから、すべてのシナリオについて、さまざまな条件の下でテストを実行し、サイトやアプリケーションのパフォーマンスデータを収集、比較する必要があります。

外形監視ソリューションでは、データの比較や差の視覚化の機能も重要です。これらの機能が充実していれば、結果をすばやく簡単に理解できます。チェックすべき必須機能をいくつかご紹介します。

• 2つの具体的な測定値を比較できるか
• 絶対的な改善と相対的な改善の両方を確認できるか(たとえば、ページの表示時間を示すVisually Completeが絶対値で400ミリ秒、割合として24%改善したなど)
• 動画やウォーターフォールを並べて比較できるか
• 各設定の複数のサンプルを収集してグラフで比較できるか

例として、Splunk Synthetic Monitoringでの比較レポートの画面を次に示します。

強力なアラート機能とインテグレーション

サイトを外部から能動的にテストする外形監視は、障害や可用性の問題を検出するのに最適です。そのために重要なのが、障害を定義して通知を送信する機能です。

チェックすべきポイントをいくつかご紹介します。

• 利用者が多い主な地域内のさまざまな場所から実行できるか
• テストの頻度はどれくらいか
• テキストの有無を検証できるか
• レスポンスコードで検証できるか
• 接続の問題(DNS、TCPなど)で障害は起きるか
• SSL証明書の問題で障害を引き起こせるか

サイトに1回アクセスできないだけでは、障害が発生したとは限りません。誤検知はアラート疲れを生む可能性があります。それを避けるために、以下のような高度な機能を備えているかどうかも確認しましょう。

• エラーが発生した箇所のスクリーンショットやソースコードを表示できるか
• 障害を検証できなかったときにテストが自動的に再試行されるか
• 複数の場所からテストできるか
• 複数の場所の結果から、地域的な障害か、世界全体の障害かを自動的に検出できるか

例として、Splunk Synthetic Monitoringで表示された、エラーが返されたページの実際のスクリーンショットを次に示します。

外形監視ツールでは、障害の検出時に担当者やチームに通知する機能も重要です。最適な通知方法はチームのワークフローによって異なりますが、メールとSMSは必須です。

また、チームのワークフローや仕事スタイルとできるだけ緊密に統合できる通知オプションがあるかどうかも重要なチェックポイントです。最適なオプションがあれば、障害をすばやく確認して対応できます。

チェックすべきオプションをいくつかご紹介します。

• 複数の国のチームが連携し、モバイルデバイスを活用している場合：プッシュ通知を送信できるか
• チームメンバーが分散している場合： メッセージをチームに一斉送信できるか、またはチャットアプリケーション(SlackやMicrosoft Teamsなど)のチャネルに送信できるか
• 運用ツールを使用している場合：運用ツールと簡単に統合できるインテグレーションが提供されているか
• アラートとしてWebフックを送信するオプションがあるか：これは、プロセスで使用するツールを変更しても他のステップとの統合を維持できる万能なオプションです。

例として、一般的なカスタムWebフックの設定画面を次に示します。このようなWebフックの設定機能は外形監視ツールを選定するうえで重要なチェックポイントです。

本稼働前テスト

外形監視ツールの大きな強みの1つは、実際のユーザーによる大量トラフィックを再現せずに、高負荷時のサイトのパフォーマンスとユーザーエクスペリエンス(UX)を評価できることです。

そのため、本稼働前テストやテスト環境(ステージング、UAT、QAなど)で、本稼働を想定したサイトパフォーマンスを確認できます。このテストは、パフォーマンスを品質ゲートとして使用し、時間とともにパフォーマンスが劣化するのを防ぐために非常に役立ちます。

本稼働前テストを行うには、ツールからテスト環境にアクセスして、パフォーマンスデータを収集できる必要があります。また、テスト環境固有の細かい設定の違いに対応できる必要もあります。本稼働前テストを行ううえでチェックすべき点をいくつかご紹介します。

テスト環境の外からテストを行う場合、必要に応じて、IPアドレスをホワイトリストに登録します。セキュリティチームの協力が必要な作業もあるかもしれません。

• SSL証明書エラーを無視できるか(内部認証局または自己署名証明書を使用するため)
• テストを実行するために環境に何らかのプログラムをインストールできるか、また、ポートを開く必要があるか
• 物理システムか仮想環境か、仮想環境の場合は、どのテクノロジーが使用されているか(VM、Docker、ソフトウェアパッケージなど)
• 内部でテストを実行する場合にどのようなリソースが必要になるか
• 何件のテストを同時実行できるか、テスト数を増やすにはどのような作業が必要か

例として、Splunk Synthetic Monitoringで、Dockerインスタンスを起動して本稼働前サイトのテストを行うための指示画面を次に示します。

競合/業界ベンチマーキング

外形監視ツールのもう1つの主要ユースケースは、競合他社のパフォーマンスを測定して自社のパフォーマンスと比較し、業界内での自社の立ち位置を明確にすることです。

これは外形監視ならではのユースケースです。リアルユーザー監視やアプリケーションパフォーマンス監視など、他のツールでは、サイトにJavaScriptタグを挿入したり、バックエンドインフラにソフトウェアエージェントをインストールしたりする必要がありますが、こうした作業は当然、他社のWebサイトには行えません。

外形監視ツールを使えば、URLを指定するだけで、自社のサイトと同じくらい簡単に他社のサイトのパフォーマンスを測定できます。

ただし、Webサイトが各種のWebセキュリティ製品で保護されている場合、攻撃、ボット、その他の悪質なトラフィックをブロックする機能により、結果的に外形監視ツールからのトラフィックもブロックされることがあります。実際、外形監視ツールのベンダーが利用するクラウドプロバイダーやデータセンターのIPアドレスがブロックされるのは珍しいことではありません。そのため、外形監視ツールを選定する際は次の点をチェックしましょう。

競合他社がブロックしていないアクセス元からテストを実行できるか

競合他社が使用するセキュリティ製品で外形監視トラフィックがブロックされるもう1つの要因として、ユーザーエージェントも考えられます。ユーザーエージェントが実際のブラウザで使用されているものと異なる場合、ブロックされる可能性があります。そのため、次の点も確認しましょう。

ユーザーエージェントをカスタマイズして、外形監視ツールのトラフィックとして認識される要素をすべて排除できるか

競合他社のパフォーマンスデータとユーザーエクスペリエンスデータを収集できたら、その結果を自社のサイトと比較できるようになります。そのための機能に関して、さらに以下の点をチェックしましょう。

• 複数の競合他社のデータを1つの画面で簡単に比較できるか
• どのサイトのどの点が優れているかを非技術者でも簡単に理解できるようにするための工夫があるか
• サイトを簡単に比較するための、Google Lighthouseパフォーマンススコアのような複合スコアが提供されるか

例として、Splunk Synthetic Monitoringの競合ベンチマークダッシュボードの画面を次に示します。

最後にまとめると、外形監視ツールの価値を最大限に引き出すには以下の点を確認することが大切です。

• テストの設定を簡単に行えるか、テストを柔軟に制御できるか
• 既存のアラートワークフローに簡単に統合できるか
• 本稼働前テスト環境に簡単に統合できるか
• 各種のテスト結果や傾向を簡単に時系列で表示し、比較できるか

外形監視の課題

外形監視の主な課題は、利用シナリオを作成する際に立てる前提の妥当性です。テストでは、ユーザーの振る舞いをすべて理解していると仮定することはできません。実際の環境では、ユーザーは思わぬ行動をすることがあります。前述のシナリオ生成コンポーネントによるエミュレーションでは、現実世界の複雑なシナリオを網羅できない可能性があります。

ただし、これらの制約を緩和することはできます。外形監視とリアルユーザー監視を組み合わせることで、外形監視によるデータとリアルユーザー監視によるデータを1つの画面に表示すれば、適切な情報に基づく実用的な統計分析を行うことができます。

Splunk Synthetic Monitoring

Splunk Synthetic Monitoringは、クライアント側のパフォーマンスやユーザーエクスペリエンスを監視して、改善や最適化の方法を提案します。このプロセスをCI/CDワークフローに統合して、手動でのパフォーマンス調査を自動化し、ビジネス全体でパフォーマンスを管理することもできます。

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。