15 ユーザー・エクスペリエンスの理解

この章ではReal User Experience Insight (RUEI)スタンドアロン製品を紹介します。Enterprise ManagerコンソールからRUEIの監視機能を使用する方法の詳細は、第18章「ビジネス・アプリケーションの監視」を参照してください。

RUEIを使用してアプリケーションのパフォーマンスを監視できます。特にRUEIは、分散アプリケーションでは通常最初の入口(アプリケーション・コンポーネント)であるWebブラウザとユーザーとのやり取りを監視します。この最初の入口は、ユーザーに最も見えやすい問題を特定するため、また、対ユーザーの各種サービスの設計と有効性の改善につながるユース・パターンを検出するため、非常に重要な場所です。

この項ではユーザー・エクスペリエンスを理解するための、RUEIの操作に関連する基本的な概念とタスクを説明します。内容は次のとおりです。

RUEIの検出対象
RUEIデータの表示と分析
RUEIにより回答できる質問
EMコンソールからアクセスできるRUEIの側面
RUEIのBTMおよびJVM診断との連携

RUEIは豊富な機能を提供します(詳細はOracle Real User Experience Insightユーザーズ・ガイドを参照してください)。

RUEI 12.1.0.6以降では、ネットワーク・データ収集以外の構成も可能です。これらの新しい構成を使用すると、ネットワーク・インフラストラクチャにアクセスせずにパフォーマンスを監視できます。この章では、ネットワーク・データ収集が使用されることを想定していますが、ここで説明する機能は他の非ネットワーク・データ収集の構成でも使用できます。特に、この章の第15.1項「RUEIの検出対象」では、ネットワーク・データ収集を構成する場合にのみ必要となる要件(ポート構成、ネットワーク・データ収集)について説明しています。非ネットワーク・データ収集の詳細は、RUEIのドキュメントを参照してください。RUEIを使用する方法のデモンストレーションを表示するには、次のURLにアクセスして「Begin Video」をクリックします。

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5783,1

15.1 RUEIの検出対象

ユーザーは1つ以上のオブジェクトを含むWebページと対話を行うことにより、アプリケーションを操作します。たとえば、リンクをクリックしてオブジェクトと対話することで、ユーザーは分散アプリケーションを構成するサービスを呼び出す一連のコールを開始します。RUEIが1ページ以上のWebページとの最初のやり取りに重点を置くのに対し、Business Transaction Management (次の章で説明します)はその最初のやり取りに続く一連のコールを監視します。

通常、単一のRUEIインスタンスが、Webサーバーの前、DMZ内のファイアウォールの後ろにインストールされて、ネットワーク・データを収集します。RUEIはWebページにアクセスするすべてのユーザーを監視しますが、それによってサーバーやネットワークのレスポンス時間に影響を与えることはありません。

RUEIをインストールし、構成するときには、次の情報を指定します。

トラフィックの監視対象とするポート(監視の範囲)
ユーザーの識別方法(Cookie情報かログイン情報か)
セキュリティ問題の対処法と暗号化されたデータの監視方法
RUEIアプリケーションと関連付けられたページの識別方法

RUEIアプリケーションはページの集合です。構成プロセスで、ユーザーはRUEIにどのページが所定のアプリケーションと関連付けられるかを指示します。

指定したポートで、RUEIがトラフィックの監視を始めると、RUEIの構成時に定義したスキームに基づいて検出した情報が識別されて整理されます。

図15-1はページ・リクエストに関連付けられたデータをRUEIが収集する方法を示しています。

ユーザーが監視対象ページでアクションを実行すると、RUEIはそのリクエストを確認し、ネットワーク・タイミングの測定、およびリクエストされたオブジェクトをビジターに表示するためにWebサーバーが要する時間の測定を開始します。

この時点で、誰がそのページをリクエストしたか(IPクライアント)、どのオブジェクトがリクエストされたか、およびどのサーバーからオブジェクトが要求されたか(IPサーバー)がRUEIで認識されています。
RUEIでは、Webサーバーが応答し、オブジェクトをユーザーに送信するときに、そのレスポンスを確認し、サーバーのレスポンス時間の計測を中止します。

この時点で、RUEIでは、サーバーからのレスポンスがあるかどうか、そのレスポンスが適切かどうか、リクエストされたオブジェクトの生成にWebサーバーが要した時間、およびオブジェクトのサイズを把握できます。

RUEIにより、オブジェクトがユーザーに完全に受信されたかどうか、またはユーザーがダウンロードを中断したかどうかも確認できます。したがって、RUEIでは、オブジェクトがインターネットからビジターに渡されるまでの時間を測定し、ユーザーとサーバー間のインターネット・スループット(接続速度)を計算できます。

図15-1 RUEIがネットワーク・データ収集のユーザー・リクエストを監視する方法

RUEIアプリケーションに関連付けられたページのオブジェクトにアクセスするたびに、RUEIは次の情報を収集します。

だれがそのページをリクエストしたか、そしてどのオブジェクトをリクエストしたか
どのサーバーがページをホストしたか
レスポンス時間およびレスポンスの正確性
オブジェクトのサイズ
オブジェクトが完全に受信されたか、あるいは中断されたか
このリクエスト/レスポンス順序のインターネット・スループット

次の項ではRUEIを使用してこのデータを表示し、分析する様々な方法について説明します。

15.2 RUEIデータの表示と分析

ユーザーがアプリケーションと対話している間に収集する情報を使用して、RUEIはユーザー・エクスペリエンスに関連するパフォーマンス問題およびユース・パターンの理解につながる多くのビューを表示できます。

現在進行形のデータ監視に加え、期待されるサービス・レベルを指定できるサービス・レベル合意を作成するオプションも用意されています。この合意は、ベンチマーク値を定義するいくつかのキー・パフォーマンス・インジケータ(KPI)を使用して明示されます。詳細は、「KPIとサービス・レベル合意」を参照してください。

パフォーマンスを評価するもう1つの側面は、ユース・パターンの監視です。ユーザーはユーザー・フローを一連のページとして定義し、フローの手順が終了したかどうかを監視します。詳細は、「ユーザー・フロー」を参照してください。

レポートされるデータはアクティブ・セッション(5分間)か閉じたセッションのいずれかにスコープ指定され、数日間におよぶこともあります。

この項では最もよく使用されるRUEIビューをいくつか紹介し、また、収集した情報を分析する別の方法についても説明します。次の項目について説明します。

ダッシュボード
レポート
セッション診断
ユーザー・フロー
KPIおよびサービス・レベル合意

15.2.1 ダッシュボード

RUEIのダッシュボードはユーザー・アクティビティの最も包括的なビューを提供します。過去24時間のアクティビティの次のビューを提供します。

現行セッションのアクティビティの地域的な、マップベースのビュー
ページ・ビューで見た、最もアクティブな上位5つのアプリケーション
問題のあるページ上位5位
すべての管理対象アプリケーションでの最新のアラート
すべての監視対象アプリケーションに対して定義されたKPIのステータス。前回記録された値からどのくらい変更されたかを示します。
ネットワーク・エラー、クライアントによる終了、サーバー・エラー、Webサイト・エラー、コンテンツ・エラーによるエラーの割合を示すチャート
平均ページ・ロード時間およびページ・ビューとセッションとの関係を示すチャート
複数のRUEIインスタンスからのデータを表示するか、または接続されているすべてのRUEIインスタンスからの集計されたデータを表示できます。

図15-2 RUEIの「ダッシュボード」タブ

15.2.2 レポート

RUEIには事前定義されたレポートの大きなライブラリが用意されており、収集されたユーザー情報を標準的な方法で表示できます。「レポート」タブのコントロールを使用して、レポートを生成し、表示します。

「レポート」タブのコントロールを使用してまず期間を指定し、生成するレポートを選択します。レポートはたとえば「アプリケーション」や「クライアント」のように、カテゴリでグループ化されています。各カテゴリには様々なレポート・オプションがあります。たとえば、「クライアント」カテゴリでは、国ごとのパフォーマンス、ブラウザごとのセッション数、OSごとのセッション数などのレポートを生成できます。

レポートは表形式またはグラフ形式で表示され、PDFファイルとして保存することも、他のツールにエクスポートすることもできます。

レポートのカスタマイズ、新規レポートの作成、お気に入りのレポートのショートカットの作成、レポートの結果を制限するためのフィルタの定義を行うことができます。

15.2.3 セッション診断

セッション診断機能では、ある期間に発生した操作上の問題の根本分析を実行できます。

診断情報は、すべてのセッション、失敗したURL、遅いURL、失敗したページなど、様々なカテゴリで利用できます。個々の検索基準は各グループで異なります。たとえば失敗したページのカテゴリでは、アプリケーション名、クライアントのIPアドレス、ユーザーIDで検索を絞り込むことができます。さらにフィルタをかけて結果を制限することもできます。

一部の診断カテゴリでは検索の順番を指定することも可能です。たとえば、まず最もアクティブなセッションを検索します。

この機能を使用するには、期間、検索基準(フィルタを含む)、検索順を指定します。RUEIは検索基準に一致するすべてのユーザー・レコードを、指定された順序で返します。次に、現在表示されているユーザー・レコードをさらに検索して、特定のセッションを切り出すことができます。

戻されるユーザー・レコードには5分間についての完全なセッション・ページ履歴が含まれています。各ページを検査し、ロード満足度、重要なページかどうか、ページにはエラーがないかを調べることができます。また、あるページを選択して、サーバーおよびクライアントにより受信された全ページ・コンテンツとその基になっているhtmlコードを表示することもできます。

場合によっては、表示しているページの横にある「リプレイ」アイコンをクリックして、完全なユーザー・セッションを再生できます。こうすることで、ビジターがセッション中に表示した各ページとレポートされたエラー・メッセージを確認できます。

さらに、選択した機能領域のセッション診断機能から外部ツールへクリックアウトすることもできます。詳細は、「RUEIのBTMおよびJVM診断との連携」を参照してください。

全セッション・コンテンツを外部ユーティリティにエクスポートしてさらに分析を行い、他のデータと統合したり、テスト・スクリプトを生成するためのベースを作成することができます。

15.2.4 ユーザー・フロー

論理タスクを定義するために、ユーザー・フローを作成します。ユーザー・フローとはWebページとアクションの集合です。タスクを完了するために実行する必要がある多数のステップが含まれます。たとえば、購入ユーザー・フローには次のステップが定義されます。

品目の選択
出荷情報
請求書情報
確認

各ステップは複数のページで構成できます。たとえば、「品目の選択」ステップには品目を選択するためのページが多数存在する可能性があります。

ユーザー・フローのステップは、そのステップを完了とみなすために必要な要件を指定する条件の観点で定義します。たとえば、請求書情報に支払いの代替方法に関する条件が複数含まれる場合に、そのステップが完了するために満たす必要がある条件は、これらの条件のうち1つだけだとします。ステップには「必須」または「任意」とラベルを付けることができます。また、ステップに期間を関連付けて、それを超えたらタイムアウトを発生させ、ユーザー・エクスペリエンスを評価することもできます。

ユーザー・フローは特定のアプリケーションと関連付けることも、関連付けないで独立させておくこともできます。

ユーザー・フロー・アクティビティは最も一般的なレベルでレポートされ、所定の期間にフローのステップを通過するビジターの移動が、ファンネルの形状で示されます。ファンネルの幅が狭くなると、ビジターはタイムアウトのために接続が切れたか、またはビジターにより操作が中止されたことを表します。図15-3は、ユーザー・フローのサンプル図です。

図15-3 ユーザー・フローの図

フローは一番上で開始され、ユーザーが少なくなるにつれ、狭まってきます。フローの各ステップは異なる色で表示されます。図形の右にはいくつかの数字があり、何件のユーザーによる中断とユーザーのタイムアウト件数を足して、一定時間のユーザーのロス合計件数になったかを示しています。ファンネルの図に続き、各ステップのアクティビティについてさらに詳細な情報が表示されます(図15-3では見えません)。

RUEIはユーザーのアクティブ時間とアイドル時間を各フローについて比較したビューで、ユーザー・フロー・アクティビティに関するさらに深い洞察を提供します。この種の分析は、ユーザーにとって完了することが最も難しいページはどれかを示す場合があります。このビューの例を図15-4に示します。

フェリーの予約と飛行機の予約の平均アイドル時間の差に注目してください。アイドル時間が長いということは、Webページのデザインが悪いことを反映している場合があります。

ユーザー・フローは障害スポットを検出し、ユース・パターンを識別し、全体的なユーザー・エクスペリエンスを向上させるための優れた手段を提供します。

図15-4 ユーザー・フロー・ステップのアクティブ時間とアイドル時間

15.2.5 KPIおよびサービル・レベル合意

RUEIにより提供される連続的で受動的な監視に加えて、キー・パフォーマンス・インジケータ(KPI)を使用してパフォーマンスの特定の側面を監視するアクティブ監視を設定できます。さらに、指定したベンチマークに違反した場合にアラートを出すサービス・レベル合意を定義することができます。このデータをダッシュボードとレポートを使用して確認できます。

SLAは期待されるレベルのサービスを定義するもので、通常は1つ以上のキー・パフォーマンス・インジケータの観点から表されます。たとえば、KPIにより、あるサービスが99%の時間で利用可能かどうかを検査し、SLAは可用性がこの値を下回った場合にレポートするように定義しておきます。

KPIは、ロード時間、セッション、スループットなどのカテゴリにグループ化されます。ユーザー・フローの完了やWebサイトの可用性など、独自のカテゴリを定義できます。

KPIを定義する際には次の情報を指定します。

特定のアプリケーションのデータと関連付けるか、または汎用にするか
適用するメトリック
KPIの範囲をさらに定義するためにフィルタが必要かどうかたとえば、ユーザー・フロー・ロード時間または終了したユーザー・フローのメトリックを選択した場合は、参照先のユーザー・フローを指定する必要があります。
そのKPIに最大または最小のターゲット範囲を持たせるかどうか。ターゲットは履歴パフォーマンスに対して固定にすることも、相対的にすることもできます。
KPIをSLAに組み込むかどうか、組み込む場合はどのように組み込むか
アラートをKPIと関連付けるかどうか

RUEIではアクティブ監視を非常に繊細に制御できます。通常の定期的なものに比べて敏感なサービスレベルとアラート・スケジュールをターゲットの値に作成し、アラート・プロファイルとエスカレーション・プロシージャを定義して、アラートがトリガーされたときの通知先を指定できます。

15.3 RUEIにより回答できる質問

RUEIはユーザー・エクスペリエンスに関する次のような質問に答えることができます。

1日のうちでページのヒット数が最大なのはいつか。

「ダッシュボード」タブにある、ページ・ビューとセッションを関連させたチャートをご覧ください。
ユーザー・アクティビティが最大であるのはヨーロッパのどの地域か。

「ダッシュボード」タブにあるセッションの発生元のマップをご覧ください。
すべてのエラーのうち何パーセントがクライアント側の中止によるものか。

「ダッシュボード」タブにある機能エラーのチャートをご覧ください。
最も問題の多いページはどれか。

「ダッシュボード」タブにある問題ページのリストをご覧ください。
フランスの顧客が最もよく使用しているブラウザはどれか。

「レポート」タブの「クライアント」カテゴリからブラウザ当たりのセッション数レポートを選択し、クライアントの場所/国でフィルタをかけます。
特定のECIDを持つ予約アプリケーションのユーザー・レコードを表示したい。

「セッション診断」グループを選択し、アプリケーション名および当該ECIDを指定します。ECIDの詳細は、第14.2項「ECIDを使用してリクエストを追跡する」を参照してください。
予約ユーザー・フローのうち、最も顧客を失うステップはどれか。

ユーザー・フローのファンネルとステータス詳細をご覧ください。
ユーザー・フローで、前のステップに戻ったユーザーは何人か。

ユーザー・フローの「ステータスの詳細」を見て、各ステップで戻っているユーザーの数を確認してください。戻っているユーザーが多いことは、なんらかのステータス情報を後続の画面に入れる必要があることを示す場合があります。
creditCheckサービスの可用性が95％を下回ったのはいつか。

そのメトリックのKPIを定義し、指定した値が突破されたときにアラートを発行するサービス・レベル合意を定義します。

15.4 EMコンソールからアクセスできるRUEIの側面

ユーザー・エクスペリエンスに関する監視情報にはEnterprise Managerコンソールからアクセスできます。ただし、Enterprise Managerコンソールではユーザー・フローやKPI、SLA、カスタム・レポートの定義や編集はできません。必要なすべての操作はRUEIコンソールを使用して行います。

Enterprise Managerコンソールで提供される情報の内容は、RUEIでアプリケーションと監視機能をどのように定義したかにより異なります。表示される情報量を変更する必要があると考えた場合は、RUEIコンソールを使用して、該当する要素を編集します。Enterprise Managerは新しい定義により自動的に更新され、ユーザーが追加トラフィックを実行すると、必要な情報が表示されます。

全般的に、Enterprise Manager Consoleからアクセスできる情報には、現在のビジネス・アプリケーションに関連付けられた各RUEIアプリケーションに関する次のような情報があります。

「ビジネス・アプリケーション」ホーム・ページで、アプリケーションに定義したキー・パフォーマンス・インシデント(KPI)、そのステータスおよびそれらの定義済しきい値を表示できます。また、ビジネス・アプリケーションに関連付けられたインシデントと問題の概要も表示できます。これらの中にはRUEIで生成されたものもある可能性があります。
RUEIアプリケーションのために定義されたKPIにより生成されたアラートは、「インシデント・マネージャ」でイベントとしてレポートされます。これらのイベントを表示するには、「エンタープライズ」メニューから「監視」、「インシデント・マネージャ」の順に選択します。次に「インシデントのないイベント」事前定義済ビューを開きます。詳細情報を表示するには、目的のイベントをクリックします。

RUEIアプリケーションのさらに詳細な監視情報を表示するには、「Real User Experience (RUEI)」を選択し、「ビジネス・アプリケーション」ドロップ・ダウンから「Real User Experience (RUEI)データ」を選択します。次のリージョンを表示できます。

「RUEI - キー・パフォーマンス・インジケータ(KPI)」リージョン: 定義済KPIのさらに詳細な情報が表示されます。
「上位ユーザーとアプリケーション違反」リージョン: 最も違反件数の多いアプリケーション・ページを検証できます。
「上位実行済ユーザー・リクエスト」リージョン: 最も頻度の高いユーザー・リクエストとアクションを表示し、それらによるビジネス・アプリケーションへの影響を評価できます。
「上位ユーザー」リージョン: ビジネス・アプリケーションに関連付けられたターゲットの最もアクティブなユーザーを監視できます。

操作上の問題の根本原因分析を実行するには、「RUEIセッション診断」機能を使用できます。この機能にアクセスするには、「Real User Experience (RUEI)」を選択し、「ビジネス・アプリケーション」ドロップ・ダウンから「RUEIセッション診断」を選択します。

「RUEIメトリック」ページを表示するには、「Real User Experience (RUEI)」を選択し、「ビジネス・アプリケーション」ドロップ・ダウンから「RUEIメトリック」を選択します。

Enterprise Manager ConsoleでのRUEIの操作の詳細は、「ビジネス・アプリケーションの監視」を参照してください。

15.5 RUEIのBTMおよびJVM診断との連携

RUEIはBTMおよびJVMDとシームレスに連携できます(「エンドツーエンド監視の設定」で説明されているように、これらをインストールし、構成した場合)。オプションには次のものがあります。

JVMDにクリックアウトすると、ECIDに基づき選択されたリクエストに関するアクティビティの情報を入手できます。「RUEIセッション診断」ビューでレコードを右クリックすると、「インスタンス診断リクエスト」ページにアクセスできます。
Business Transaction Managementにクリックアウトすると、ビジネス・トランザクションに関するセッション診断機能からの情報を表示できます。
Business Transaction Managementにクリックアウトして、選択されたリクエストに関連付けられている特定の作業フローに関する集計情報を表示できます。このオプションは、URL診断グループ内のBTMサービス/操作ディメンションを介して使用できます。
Business Transaction Managementにクリックアウトして、選択されたリクエストに関連付けられているアプリケーション環境内でデプロイされたサービスに関する集計情報を表示できます。このオプションは、URL診断グループ内のBTMサービス・ディメンションを介して使用できます。

RUEIを外部ツールと連携させる方法の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』の「外部ツールへのクリックアウトの構成」を参照してください。