新型コロナウイルス感染拡大の影響により、Webサイトのパフォーマンスやユーザーエクスペリエンスに対する要求はかつてないほど高まっています。そもそも、コンテンツの読み込みに時間がかかる、操作性が悪い、表示が不安定、エラーが多いといった要因は、ユーザーエンゲージメントやコンバージョンを低下させます。Splunkは本日、顧客に影響する問題の迅速なトラブルシューティングとユーザーエクスペリエンスの最適化をサポートするSplunk Real User Monitoring (RUM)の一般提供の開始を発表しました。Splunk RUMを使用すれば、Splunk Synthetic Monitoring、Splunk APM、Splunk Infrastructure Monitoring、Splunk Log Observer、Splunk On-Callと連携して、顧客に対するコードの影響を測定および改善し、デジタルエクスペリエンスを向上できます。
顧客に影響する問題を迅速にトラブルシューティング
通常、社内のインシデント対応手順や問題の重要度(本番環境のインシデントか、困っているユーザーからの一般サポートチケットかなど)に応じて対応のアプローチは異なりますが、Splunk RUMを使用すれば、オンコールエンジニアやサービスオーナーは、問題の重要度に関わらず、ユーザーエクスペリエンスに悪影響を及ぼす遅延、エラー、異常をすばやく検出して修復できます。
エンドツーエンドの可視化でエンドユーザーエクスペリエンスに影響を及ぼす依存関係を把握
エンドユーザーエクスペリエンスには、Webブラウザとバックエンドサービスの両方の処理時間が影響するため、Splunk RUMは、すべてのサービス、コンポーネント、リソース、サードパーティの依存サービスをエンドツーエンドで可視化します。RUMではまず、概要画面で全体的なユーザーエクスペリエンスを確認します。この画面には、ページ読み込みの90パーセンタイル、フロントエンドサービスとバックエンドサービスのエラー数、コアウェブバイタルなど、エンドユーザー視点でアプリケーションパフォーマンスを理解するために重要なメトリクスが表示されます。
トラブルシューティングを開始するには、概要画面でいずれかのリンクをクリックします。ここでは例として「/cart/*」をクリックします。「/cart/*」の遅延の値が高いということは、「/cart/*」タイプのエンドポイント(この場合は「/cart/checkout」)で処理に時間がかかり、エンドユーザーエクスペリエンスが低下している可能性があります。
クリックするとTag Spotlightに移動します。ここでは「/cart/*」の遅延と相関付けられるタグとディメンションを確認できます。パーセンタイル(P50、P90、P99)を見ることで、エンドポイントの遅延の影響を受けているユーザーセッション数を定量的に把握でき、また、パーセンタイルと並んで、国、地域、Webブラウザ、デバイスタイプ、HTTP呼び出しの送受信など、ユーザーセッションに関するディメンション情報が表示されます。いずれかのタグ値をクリックすると、そのデータに基づくフィルターをすばやく適用して、影響を受けているユーザーのタイプを確認できます。
[Sessions] (セッション)をクリックすると、エンドポイントの遅延の影響を受けている個々のユーザーセッションが、適用したフィルターごとに表示されます。さらにいずれかのセッションIDをクリックすると、すべてのページリソースとサードパーティの依存サービスを含むページ読み込みの全処理がウォーターフォール形式で表示されます。
次の図が、セッションIDをクリックしたときのユーザーセッションのウォーターフォール表示です。この例では「/cart/checkout」を呼び出す処理が強調表示され、展開されます。遅延のグラフの上にマウスポインターを置くと、このスパンのエンドツーエンドの詳細が表示されます。この例では、Webサーバー(バックエンドサービス)が最初の1バイトを送信するまでの時間を示す測定値、TTFBが、セッションのほぼすべてを占めていることがわかります。これは、バックエンドのいずれかのサービスで問題が起きている可能性が高いことを示します。
これがフロントエンドとバックエンドのどちらの問題であるかを詳しく調査してみましょう。Splunk RUMでは、フロントエンドのトレースとバックエンドのトレースをつないで、ユーザーアクティビティをエンドツーエンドで追跡できます。この例では、POST要求によりバックエンドでアクティビティが生成されているため、このスパンの横に[APM]ハイパーリンクが表示されます。[APM]リンクの上にマウスポインターを置くと、重要なバックエンドコンポーネントのパフォーマンスの概要が表示されます。
そこからワークフロー名をクリックするとサービスマップが表示されます。サービスマップでは、バックエンドアーキテクチャに含まれる各種のコンポーネントやサービスの遅延を視覚的に確認できます。この図から、遅延が決済サービス(paymentservice)でのエラーに関係があることは明らかです。
サービスマップでいずれかのコンポーネントの上にマウスポインターを置くと、遅延、エラー、異常を切り分けるために役立つ追加の詳細が表示されます。図では、ワークフロー全体での決済サービスのエラー、リクエスト、遅延がエンティティタグとともに表示されています。
セッションのウォーターフォール表示に戻り、[APM]ハイパーリンクの上にマウスポインターを置いたときに表示されるウィンドウで、トレースIDをクリックすることもできます。これにより、「/cart/checkout」が呼び出されたときに生成された正確なバックエンドトレースを確認できます。バックエンドのサンプリングされたトレースではなく正確なトレースを確認することは、パフォーマンス低下の正確な原因を突き止めるために重要です。
トレースを確認すると、チェックアウトサービス(checkoutservice)が決済サービス(paymentservice)を複数回呼び出していて、そのたびにステータスコード401(資格情報が無効)が返され、最終的に「無効な要求」の応答によってタイムアウトになっていることがわかります。
このようにSplunk RUMでは、ページパフォーマンスの全体的な把握から、バックエンドサービスの健全性の確認まで、分散システムの中でエンドユーザーエクスペリエンスに影響を及ぼしているコンポーネントや依存サービスをすばやく特定できます。
高カーディナリティで問題をすばやく特定
トラブルシューティング全般で、Splunkのほぼ無限のカーディナリティにより、依存関係が数百に及ぶような複雑な分散システムでも問題をすばやく相関付けて根本原因を早期に特定できます。RUMの概要画面でエンドユーザーエクスペリエンスの全体的な状況をすばやく把握した後、APMとRUMでエンドツーエンドのトレースを詳しく調査してエラーや遅延の原因を探り、Splunk Log Observerで個々のログを分析できます。
ページパフォーマンスをベンチマークして改善
Splunk RUMでは、他のRUMソリューションにない独自の方法でフロントエンドのパフォーマンスを測定して改善します。ユーザーセッションの開始から終了まで、ブラウザとリソース間で行われたすべての通信が測定され、その結果からユーザージャーニーや、すべての動的コンポーネントのパフォーマンスを理解できます。そのため、1つのページで数十または数百の内部/外部リソースと通信してコンテンツを動的に読み込むようなフロントエンドフレームワークでもパフォーマンスを定量化することができます。
Splunk RUMは、オープンソースに対応し、フレームワークに依存せず、OpenTelemetryをサポートするため、オンコール対応時には、Webブラウザからデータベース呼び出し、さらにはサードパーティの依存サービスまで切れ目なく記録されたトランザクションの標準化されたトレースを追跡できます。
コアウェブバイタルとロングタスク
Splunk RUMの概要画面には、Google社のコアウェブバイタル、主要なW3Cタイミング、ロングタスクを中心とした情報が表示されます。
コアウェブバイタルでは次の3つの測定値が表示されます。
- LCP (Largest Contentful Paint)：最も大きいコンテンツが表示されるまでの時間を表す測定値です。ページのメインとなる画像やコンテンツ(ナビゲーションバー、動画プレーヤーなど)がエンドユーザーに表示されるまでの時間を把握できます。
- FID (First Input Delay)：ページの操作性を表す測定値です。エンドユーザーが操作(クリック)を行ってからWebブラウザが反応するまでの時間を把握できます。
- CLS (Cumulative Layout Shift)：ページの表示の安定性を表すスコアです。エンドユーザーが意図しないページレイアウトのずれがどのくらい発生したかを把握できます(このようなずれは通常、動的にサイズが変わるコンテンツによって発生します)。
Google社は今年の夏から、ページのコアウェブバイタルスコアをページのランキング要因として組み込む予定です。コアウェブバイタルの測定値は、ウォーターフォール図の詳細や各ユーザーセッションIDの中でも表示されます。
ロングタスクは、Webブラウザのメインスレッドを妨害するJavaScriptタスクを指します。これは、ブラウザのUIをフリーズさせて、ユーザー入力にページが反応しなくなる要因となります。Splunk RUMでは、ロングタスクの長さ(操作が妨害された時間)とロングタスク数(1ページあたりに発生したロングタスク数)が表示されます。
TTFB (Time to First Byte)は、サーバー側の応答の測定値で、クライアントのWebブラウザの要求に応じてWebサーバーがページの最初のバイトを送信するまでにかかった時間を表します。TTFBを見ることで、バックエンドサービスの遅延とクライアント側のパフォーマンスをすばやく比較できます。
Splunk Digital Experience Monitoring (DEM)とSynthetic Monitoring
ページパフォーマンスを改善するには、ラボデータとフィールドデータの活用が欠かせません。Splunk RUMは、任意のWebブラウザ、インターネットサービスプロバイダー、デバイスを組み合わせて使用する実際のユーザーからのフィールドデータを提供します。一方、Splunk Synthetic Monitoring (旧称Rigor)は、本番リリース前にWebエクスペリエンスをテスト、測定、アラート、改善するための、管理されたラボ環境を提供します。
Splunk Synthetic Monitoringは、APMスイートやオブザーバビリティスイートの中でも特にWeb最適化に重点を置いた機能を備えています。この優れたソリューションでは、以下の機能を使用してページパフォーマンスを最適化できます。
- エンドポイントの稼働時間をSplunk APM、Infrastructure Monitoring、On-Call、コア機能、Enterpriseと関連付け
- Lighthouseのスコアやコアウェブバイタルを含む50種類以上のパフォーマンスメトリクスでパフォーマンスをベンチマーク
- Webとモバイルのフィルムストリップと画面録画により実際のユーザーエクスペリエンスを確認
- パフォーマンスバジェットに基づいてJenkinsパイプラインでビルドの合否を自動的に判定
エンドユーザーエクスペリエンスをさらに向上
Splunk RUMでは、動的に読み込まれるコンテンツのエンドユーザーエクスペリエンスから、バックエンドサービス、データベース呼び出しのエラーや遅延まで、スタック全体の遅延をすばやく可視化できます。Splunkの統合プラットフォームとの連携により、ユーザーエクスペリエンスを簡単に測定し、エンドユーザーに対するアーキテクチャ全体の影響を把握できます。
ぜひ、Splunk Real User Monitoringの無料トライアル版をお試しになるか、製品ページで詳細をご確認ください。
このブログはこちらの英語ブログの翻訳、池山 邦彦によるレビューです。
