外形監視を正しく行う方法：外形テストの最適な実行場所を選定する方法

ブラウザ外形テストでは一見すべてが順調で、テスト結果はすべて正常を示しています。しかし、数分も経たないうちに、フランクフルトの顧客からログインの遅延や決済時のタイムアウトが報告され始めます。簡単な確認を行ったところ、Real User Monitoring (RUM)によってヨーロッパとアジアの一部の地域でその影響が広がっていることがわかりました。

こうした事態は、残念ですが、ブラウザ外形テストを導入したばかりのチームでよく見られます。テスト結果が良好でも、実行場所が適切でなく、顧客の実際の接続場所を反映していません。そのため、結果が測定対象に対しては正確であっても、顧客の実際のエクスペリエンスに対しては不正確になってしまうのです。

テストの実行場所は、その結果に直接影響します。すべてのテストを同じ地域から行っていると、ユーザーエクスペリエンスを1つの視点からしか把握できません。そのような限られた視野では、顧客が最初に気付く問題を見落としてしまうおそれがあります。たとえば、地域固有のパフォーマンスの問題やルーティングの不具合、CDNの不整合などです。

この記事では、ブラウザ外形テストにおいて、実行場所についての戦略が結果にどのような影響を与えるか、また有効性を顧客の地域ごとに評価するにはどうすればよいかについて解説します。

今回は、「外形監視を正しく行う方法」シリーズのベストプラクティス3「顧客に近い場所で外形テストを実施する」についてご説明します。このシリーズを初めてお読みになる場合は、まず「はじめに」の記事で、これらのベストプラクティスを組み合わせてブラウザ外形テストの信頼性と実用性を高める方法の概要をご確認ください。

ブラウザ外形テストにおける実行場所の役割

あらゆるブラウザ外形テストは、1つ以上の地理的な場所から実行されます。すなわち、ブラウザセッションが開始される場所です。それは、主要なクラウドリージョンにあるSplunk管理のパブリックランナーかもしれませんし、組織のネットワーク内にデプロイされたプライベートランナーかもしれません(ランナーについては、後ほど詳しくご説明します)。

こうした場所は、次のように、測定内容のコンテキストを決定します。

• 顧客と同じ地域から実行されるテストは、顧客の実際のエクスペリエンスを反映します。
• 別の地域から実行されるテストは、合格はするかもしれませんが、まったく異なる経路を測定しています。その経路は、顧客が決してたどることのないものかもしれません。

グローバルに利用されるアプリケーションでは、テストを複数の地域から実行して、遅延やパフォーマンスのばらつきを理解することが不可欠です。一方、組織の内部ツールの場合、外部の場所から行うとノイズが増えてしまうことがよくあります。どの場所が適切かを見極め、それらの場所を一貫して利用することで、外形テストはデジタルエクスペリエンス監視(DEM)戦略の重要な柱となります。

重要である理由

すべてのブラウザ外形テストには、重要な要素が3つあります。それは、テスト対象、測定方法、実行場所です。実行場所は、テスト結果の見方を左右します。

すべてのテストを同一地域から実行していると、他の地域でのパフォーマンスがどう異なるかはわかりません。たとえば、テストで示された結果がバージニア州では良好でも、フランクフルトやシンガポールでは異なるかもしれません。地理的な条件は、もちろん指標に影響します。たとえば、TTFB (リクエスト送信から最初の1バイト受信までの時間)やページの読み込み時間などです。これは物理的な問題であって、障害のせいではありません。

こうした背景の理解は、しきい値やアラートを設定するうえで不可欠です。地域間で結果を比較する際に場所を考慮しなければ、誤検出の要因となりかねません。チューニングの第一歩は、地理的条件が各ベースラインに及ぼす影響を把握することです。

場所を固定して実行することで、世界各地にわたってこうしたパターンを把握して測定できるようになります。

実践：外形テストの場所の管理方法

実際のトラフィックや利用パターンに合わせてテストの場所を選定する

Splunkがあれば、さまざまなオブザーバビリティデータソースを統合的に活用して、パフォーマンスをビジネス目標に照らして把握、測定できます。

RUMデータ、分析、またはWebアクセスログ(デフォルトのフィールドに[Region]が含まれます)を活用し、主要な顧客市場と、アプリケーションにとって重要な観測地点を特定します。外形テストでこれらの地域を優先することで、データが顧客の実際のエクスペリエンスを反映し、最も重要な領域でのパフォーマンスの検証に役立つようになります。

Splunk Observability Cloud RUMは、データに地理情報のタグを自動で付与します。たとえば国、都市、地域などです。これらのデフォルトタグはインデックスされ、Tag Spotlightで確認できます。そのため、ブラウザ外形テストの結果を、実際のユーザーアクティビティやアプリケーションのパフォーマンスと容易に相関付けることができます。

場所ベースでテストを実行すると、アプリケーションのパフォーマンスが世界各地の利用場所で一貫していることも確認しやすくなります。さまざまな場所からテストを実行することで、顧客が体験している以下のような問題を発見できます。

• 地域固有の遅延
• ルーティングの違い
• ピアリングの問題
• CDNの不整合(たとえばDNSエントリの誤ったルーティング、キャッシュの欠落、フェイルオーバーパスの不均衡)

Splunkの事前設定済みの視覚オブジェクトを利用することも、独自のダッシュボードを作成して、地理的なコンテキストをさまざまな指標に組み込むこともできます。そうした指標には、遅延、成功率、ページの読み込み時間などが挙げられます。これにより、場所に関するデータを早期警告のシグナルとして活用し、顧客のエクスペリエンスやグローバルなアプリケーションの健全性の維持を図ることができます。

詳細：Splunk Observability CloudでRUMの地理的インサイトを分析する

ユーザーに合わせて適切なランナーの種類を使用する

パブリックランナーでは、オープンインターネット経由での顧客アクセスをシミュレートできます。一方、プライベートランナーでは、VPNや企業のファイアウォール内での組織内アクセスを再現できます。これらを組み合わせることで、顧客向けのプロセスから従業員の業務フローまで、包括的にカバーできます。

例：

• パブリックロケーションを、eコマースの決済機能やAPIの動作のテストに使用します。
• プライベートロケーションを、内部用の人事ポータルや財務ポータルのテストに使用します。

両方のタイプを併用することで、外部CDNの遅延も内部認証の問題も、1つの監視戦略によって検出できます。

詳細：

• プライベートロケーションに関するビデオを見る
• Splunk Syntheticsでの場所の設定方法に関するビデオを見る

テストの場所を一貫して割り当てる

テストの実行場所は、長期にわたって同じである必要があります。場所を頻繁に変更すると、結果にばらつきが生じ、トレンド分析の信頼性が低下します。カバレッジを拡大する場合は、新しい場所を段階的に追加し、その理由を記録しておきましょう。

一貫性があってはじめて、パフォーマンスデータが意味を持ちます。常に同じ地域からテストを行うことで、応答時間の変動の原因がアプリケーションにあって、地理的なものではないことを確信できます。

テストの実行場所を途中で変更すると、実際に起きているパフォーマンスの劣化を見逃したり、逆に改善があったかのように錯覚したりすることがあります。たとえば決済のテストを、ある月はカリフォルニア、翌月はバージニアから行うと、TTFBが短くなったように感じるかもしれませんが、それは単に経路が短くなったためかもしれません。テストの実行場所が一貫していなければ、原因を判断しづらくなります。そのため、アプリケーションの最適化の効果か、それとも単にテストの実行場所がデータセンターに近くなったからなのかを即断できません。

特定のテストで接続処理にかかる時間が突然大きく増加したときは、別のテストの結果と比較してください。比較するテストを選ぶ際には、同じ場所から実行され、テスト対象のアプリケーションのホスト先が同じ地域またはデータセンターであるものにします。いずれのテストでも接続処理にかかる時間の急増が見られた場合、その原因はアプリケーションの不具合ではなく、地域固有の問題やネットワーク関連の問題かもしれません。

場所を主要なディメンションとして扱う

場所は、単なるメタデータではなく、コンテキストです。外形テストのデータで主要なディメンションとして位置付けると、しきい値の設定や異常の解釈、対応策の決定において鍵となる要素となります。

遅延、TTFB、総処理時間などの指標は、当然ながら地域によって変動します。アラートの判定に場所を組み込むことで、正常な地域差による誤検知を防ぐことができます。たとえば、米国にホストされているサイトの応答速度は、シンガポールよりもバージニア州からの方がほぼ確実に速くなります。

スコープごとに失敗を相関付ける

失敗した際には、相関関係とそのコンテキストが非常に重要です。場所というコンテキストは、問題の判断において、範囲が局所的か、地域的か、それとも世界規模かを知る手がかりとなります。以下の例をご覧ください。

• 1つの場所で1つのテストが失敗した場合、問題がネットワークのルーティングやDNSにあることを示している可能性があります。
• 同じ地域で複数のテストが失敗した場合、問題がその地域のインフラやCDNエッジにあると考えられます。
• あらゆる場所で1つのテストが失敗した場合、通常、問題がアプリケーション自体またはバックエンドの依存関係にあることを示しています。

しきい値と対応に場所を組み込む

Splunk Observability Cloudでは、場所がデフォルトのディメンションとして組み込まれており、検出ロジックに直接含めることができます。これにより、アラートの設定や対応を以下のようにより適切に調整できます。

• ベースラインとなるしきい値を地域ごとに設定する。遠隔地ではTTFBが長くなることを考慮します。
• アラートを適切なチームに振り分ける。障害が内部でのみ発生している場合は、カスタマーサポートではなく、ネットワークチームやVPNチームに通知します。
• 必ず複数の場所で確認する。アラートの確定のため、少なくとも2つの地域で同じ問題が起きていることを確かめてから、オンコール担当者に連絡します。

場所を相関付け、しきい値設定、対応戦略の中心に据えることで、ディテクターが常に実際のコンテキストに基づいて機能するようになります。これにより、地理的な要因と真のパフォーマンス低下を区別し、顧客に本当に影響を及ぼす問題への対応に集中できます。

詳細：Splunk Observability Cloud Syntheticsでディテクターとアラートを設定する

場所を考慮したオブザーバビリティで意思決定を向上

ブラウザ外形テストを適切な場所から実行することで、世界各地の顧客がアプリケーションをどのように利用しているかを現実に即して把握できます。テストの実行場所を意図的に選び、一貫して活用することで、地域固有の問題を迅速に検出し、レジリエンスを検証して、運用に関する意思決定をより自信を持って行えるようになります。

次のステップ：作成済みのブラウザ外形テストを見直しましょう。顧客が接続している場所を特定し、それに合わせてテストの実行場所を調整します。Splunk Observability Cloudの無料トライアル版を利用して、今すぐ試してみましょう。

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