| Oracle® Real User Experience Insightインストレーション・ガイド 12cリリース6 (12.1.0.7) for Linux x86-64 E61774-01 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightインストレーション・ガイド 12cリリース6 (12.1.0.7) for Linux x86-64 E61774-01 |
|
前 |
次 |
この章では、Oracle Real User Experience Insight (RUEI)の役割を示します。特に、RUEIのデータ・トラフィックの監視方法、操作要件および使用可能なデプロイメント・オプションを説明します。RUEIレポータ・データベース内で使用できる情報の量を増やす方法に関する情報も提供されます。
Webアプリケーションおよびサービスの利用は増え続けています。これには、マーケティング手段としてのインターネットの利用だけでなく、エクストラネットベースのサプライ・チェーンやバックオフィス統合、内部アプリケーションのイントラネット・デプロイも含まれます。明確に定義されたビジネス機能を実装したWebサービスの利用もますます増えています。アプリケーションはモバイル・デバイスからアクセスでき、また、on-premises、SaaS、hybridを含む多数のクラウド・ベース・デプロイメント・オプションがあります。RUEIは、これらすべてのデプロイ・シナリオの可用性およびパフォーマンスの測定、分析、改善のために設計されています。これを実現するために、RUEIには、ネットワーク・トラフィックやADFサーバーからのデータ収集や、JavaScriptブラウザ・インストゥルメンテーションを使用したデータ収集を実行する機能が備わっています。
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
図1-1は(以前のRUEIリリースで使用可能な)ネットワーク・データ・コレクタを示し、図1-2はタグ・データ・コレクタを示しています(このオプションを使用すると、JavaScriptを使用してデータを収集でき、ネットワーク監視の必要はありません)。
表1-1に、RUEIで使用可能な様々なデータ収集の概要を示します。
表1-1 データ収集方法
| ネットワーク | タグ | |
|---|---|---|
|
概要 |
このオプションは、ネットワークを通過するデータを収集するもので、以前のリリースでのデフォルト・オプションでした(ローカルまたはリモートのコレクタが必要です)。すべてのネットワーク・トラフィックが無差別モードで監視されます。 |
このオプションは、タグ・ベースの監視とも呼ばれ、リクエストを監視して、すべてのページに挿入される特定のWeb URL (タグ)を処理することによりデータを収集します(ローカルまたはリモートのコレクタが必要です)。ローカルIPアドレスに関連するトラフィックのみが監視されます。 |
|
アプリケーション |
アプリケーションを定義する必要があります。ユーザーズ・ガイドの「Webページの識別とレポート作成」を参照してください。 |
OnLoadオブジェクトを定義し、生成されたJavaScriptをアプリケーションで使用する必要があります。ユーザーズ・ガイドの「Webページの識別とレポート作成」を参照してください。 |
|
スイート |
スイートを定義する必要があります。ユーザーズ・ガイドの「スイートおよびWebサービスの使用」を参照してください。 |
タグ・ベースのデータ収集を使用して監視できるのは、WebCenter Sitesのみです。ユーザーズ・ガイドの「スイートおよびWebサービスの使用」を参照してください。 |
|
関連情報 |
|
|
|
ADF監視 |
ADFベースのアプリケーションの監視には、ADF監視サービスを含む様々なデータ収集オプションを使用できます。このサービスを使用すると、ネットワーク・データ収集によるデータよりも多い、アプリケーション・サーバーからADFベースのアプリケーションのデータ(ユーザー名など)が収集されます。これらのオプションの詳細は、第4章「ADF監視のためのRUEIの構成」を参照してください。 |
|
このオプションの詳細は、2.1.1項「ソフトウェア・インストールの計画」を参照してください。
ネットワーク・データ収集方法は、ネットワーク・プロトコル分析(NPA)テクノロジに基づいています。この方法は100%非侵入的です。したがって、Webサーバーには負荷はかからず、パフォーマンスに影響を与えるソフトウェア・エージェントをインストールする必要もありません。さらに、現行のアプリケーションまたはインフラストラクチャに変更を加える必要もありません。アプリケーションの新リリースがデプロイされた場合、またはWebサーバーが増設された場合にも、RUEIの監視環境に対する変更はまったく、またはほとんど必要ありません。通常、RUEIはWebサーバーの前、DMZ内のファイアウォールの後ろにインストールされます(図1-3)。
ビジターがオブジェクトをリクエストすると、RUEIではそのリクエストを確認し、リクエストされたオブジェクトをビジターに示すまでにWebサーバーで要する時間を測定します。この時点で、RUEIは、ページをリクエストしたユーザー(クライアントのIP)、リクエストされたオブジェクト、オブジェクトのリクエスト元のサーバー(サーバーのIP)を知ることができます。
RUEIでは、Webサーバーが応答し、リクエストされたオブジェクトをビジターに送信するときに、そのレスポンスを確認します。この時点で、RUEIでは、サーバーからのレスポンスがあるかどうか、そのレスポンスが適切かどうか、リクエストされたオブジェクトの生成にWebサーバーが要した時間、およびオブジェクトのサイズを把握できます。また、RUEIでは、ビジターがオブジェクトを完全に受信したかどうか、またはビジターがダウンロードを中断したかどうか(つまり配信証明)も把握できます。したがって、RUEIはオブジェクトがインターネットを経由してビジターに到達するまでの時間を計算できるとともに、ビジターとサーバー間のインターネット・スループット(ビジターの接続速度)を計算できます。
RUEIは、図1-4に示すように、3つのレイヤーからなる製品アーキテクチャに基づいています。
監視対象のパケットは、表1-2に示すレイヤーによって処理されます。
表1-2 製品アーキテクチャ・レイヤー
| レイヤー | 説明 |
|---|---|
|
データ収集 |
このレイヤーは、RAWデータの取得とデータ・プロセッサ・レイヤーへの配信を担当します。このデータは、複数のソースから収集できます。使用可能な接続オプションについては、この項で後述します。 |
|
データ処理 |
このレイヤーでは、RAWデータがOLAPデータ・セットに変換されます。これは多次元データ構造を構成し、データ・ブラウザで表示できます。 |
|
データ・プレゼンテーション(レポータ) |
このレイヤーは、RUEIの分析およびレポート作成環境です。これは、Webベースの情報ポータルで、サポートされている任意のブラウザからアクセスできます。 |
後の項で説明するように、これらの各レイヤーを同じシステムまたはスケーラビリティの問題で個別のシステムにデプロイできます。
HTTP(S)データ・ストリームを読み取るために、専用のソフトウェア・モジュールでTCP/IPパケット・ストリームを再アセンブルします。ネットワーク・データ・コレクタにIP番号が割り当てられていないことと、これらのデータ・コレクタを使用するソフトウェアに機能的なIPスタックがないことから、RUEIはデータ・コレクタで受信された受信トラフィックに応答できません。これにより、RUEIは監視対象のネットワークから見えなくなり、完全にセキュアになります。
|
注意: RUEIでは非侵入的な方法でデータを収集するため、測定ポートでエラーが発生しても、再転送のリクエストはできません。 |
データ収集は、暗号化データを記録するように構成できます。これを容易にするには、WebサーバーのプライベートSSLキーのコピーをデータ・コレクタに設定する必要があります。また、RUEIを構成して、フォームまたはコンテンツのPOSTリクエストの引数の機密データのロギングを省略できます(データ・マスキング(またはブラインド)と呼ばれます)。
RUEIでは、ネットワーク通信の監視のために、コピー・ポート脚注1 とTAP脚注2 の両方の使用がサポートされています(10/100 Mbpsおよび1/10 Gbpsイーサネット接続がサポートされています)。コピー・ポートとTAPは、銅回線またはファイバ・ベースのネットワーク・インフラストラクチャで使用できます。どちらのデバイスでもネットワーク通信の非侵入的監視が可能ですが、これら2つの接続オプションには違いがあります。これについては、この項の後半で取り上げます。
SSLトラフィックおよびFormsトラフィックの監視
SSLトラフィックおよびOracle Formsトラフィックは、TCPパケット・ストリームの中断によって影響を受けやすいことに注意してください。これらのトラフィックでは、接続中は状態情報を維持する必要があり、パケットが失われるとこの情報が失われる可能性があるためです。この場合は、RUEIが接続の監視およびレポートを正しく実行できなくなります。
したがって、各コレクタがTAPなどの信頼できるネットワーク・デバイスに接続されていることを確認する必要があります。さらに、コレクタの「統計」ウィンドウ(「システム」、「ステータス」、「コレクタ・ステータス」の順に選択)から入手できる情報を定期的に調べ、TCPパケット・ストリームが完全な状態であることを確認するよう強くお薦めします。TCPおよびSSLの接続エラーのレポートには特に注意する必要があります。また、コレクタ・ソフトウェアには物理ネットワーク・インタフェースへの直接アクセスが必要であることと、複数のサーバーが1つの物理ネットワーク・インタフェースを共有する構成(特定のブレード・サーバー・タイプなど)では動作の信頼性が低くなる可能性があることにも注意してください。構成に関して疑問な点がある場合は、ハードウェア・ベンダーにお問合せください。
コピー・ポートは、受信する様々なパケットのソースMACアドレスに基づいてレイヤー2転送表の作成を開始するスイッチです。この転送表の作成後、スイッチは、MACアドレス向けの通信を直接対応するポートに転送します。
たとえば、図1-5のWebサーバーMACが確認されると、ブラウザからWebサーバーへのユニキャスト通信は、Webサーバー・ポートにのみ転送されます。したがって、コレクタではこの通信は確認されません。
図1-5の下の部分に示した構成では、コレクタはブラウザが送信するすべてのパケットのコピーを受信するように構成されているポートに接続されています。このポートをコピー・ポートと呼びます。コピー・ポートは、任意またはすべてのデータ・ポートからの通信を1つの未使用ポートにコピーでき、ポート上での双方向の通信を防いで、ネットワークに通信が逆流しないように保護します。
スイッチ上でコピー・ポートをアクティブ化するとパフォーマンスに影響する可能性がある点に注意してください。通常、コピー・ポートでは広範な構成オプションがサポートされていますが、これらのオプションの詳細は、使用しているスイッチのドキュメントを参照するか、ベンダーにお問い合せください。
TAPは、任意の2つのネットワーク・デバイス(ルータやファイアウォールなど)の間に配置できます。TAPに接続されたすべての監視デバイスは、すべてのエラーも含めて、インラインであるかのように同じ通信を受信します。これは、TAPでリンク上のすべての通信を複製し、それを監視ポートに転送することにより実現します。図1-6の例は、1つのコレクタに対する典型的なTAPのデプロイを示しています。
重要:
コピー・ポートと異なり、TAPでは停電の場合にも、引き続きネットワーク・デバイス間でデータが流れます。また、コピー・ポートは負荷がかかったとき、パケットが失われやすくなります。TAPデバイスは、銅回線またはファイバ・ベースのインフラストラクチャに使用できます。さらに、必要な時と場所に簡単にデプロイでき、しかもスイッチの再構成や、ネットワーク・リンクのケーブル再配線に必要なエンジニアも必要ありません。これらの理由で、コピー・ポートよりもTAPの使用を強くお薦めします。
概して、TAPには、ネットワークTAP、再生成TAPおよび集約TAPの3タイプがあります。RUEIでは、ネットワークTAPと再生成TAPの使用がサポートされています。パケット・ストリーム内でパケットの順序が維持されている場合にのみ集約TAPはサポートされています。監視ポートが飽和した場合に集約TAPを使用すると、報告の精度は影響を受けることがあり、パケット・ロスが発生し、タイミング情報が不正確になります。また、ネットワークTAPでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。
RUEIで複数ネットワークからのデータの監視および処理を可能にするには、各ネットワーク・セグメントにTAPをデプロイし、これらをセントラル・コレクタに接続するか、複数のコレクタをデプロイして、それぞれを監視対象セグメントにします(1.6項「スケール・シナリオ」を参照)。
RUEIシステムをレポータ、コレクタまたは処理エンジンのいずれかにインストールできます。これらの各インストール・オプションについては、この後の項で説明します。
レポータ
レポータ・システムは、接続されたコレクタによって収集されるデータを処理します。処理後に、このデータがレポータ・データベースと呼ばれるOracleデータベースに格納されます。システム・ユーザーは、ブラウザベースのインタフェースを通して収集されたデータを確認できます。
RUEIでネットワーク・トラフィックを正確に監視して結果をレポートするには、ネットワークおよびアプリケーション・インフラストラクチャの特定の情報が必要です。これには、ページ、サービス関数コールおよびエンド・ユーザーの識別方法、ネットワーク環境での監視範囲、特定のKPIおよびSLAの監視、システム・ユーザーに割り当てられるロールおよび権限が含まれます。この情報は、個別の構成データベースに保持されます。
コレクタ
コレクタは、データを収集し、そのデータをレポータに送信します。複数のコレクタを同じレポータに接続することができます。コレクタ・システムおよびレポータ・システムの間に直接接続が必要なことに注意してください。2.1.1項「ソフトウェア・インストールの計画」で説明しているように、コレクタはネットワーク・ベース・コレクタまたはタグ・ベース・コレクタにできます。
各レポータ・インストールには、ローカルのコレクタ・インスタンスも含まれていることに注意してください。レポータを構成して、このローカルのコレクタで収集される情報を処理したり、追加のコレクタから情報を受信できます。レポータ・システム上のローカルのコレクタ・インスタンスは、必要なければ無効にすることもできます。
処理エンジン
処理エンジンは、通常はレポータによって実行されるデータ処理を負担するRUEIデプロイメントのオプション・コンポーネントです。基本的に、コレクタによって収集されるデータを処理するオーバーヘッドを1つ以上の個別のシステムにオフロードすることが含まれます。
各処理エンジンには、中間ネットワーク・トラフィック監視結果が格納される固有(ローカル)のデータベースがあります。処理されると、このデータを使用してレポータのデータベースを更新します。すべての構成情報もこのデータベース内に維持されます。処理エンジン・システムごとに、関連付けられたコレクタ・システムおよびレポータ・システム間の直接接続が必要です。
前述のように、レポータ・システムを介して入手可能なデータは、レポータ・データベースと呼ばれるOracleデータベースに格納されます。監視対象のアプリケーションおよびシステム・ユーザーの情報など、Webインフラストラクチャで正しく監視およびレポートするためにRUEIで必要な情報は、データベースの個別の構成部分に保持されます。データベースは、ローカルのレポータ・システムに置くことも、リモート・データベース・サーバー(データベース・クラスタなど)に置くこともできます。
リモート・データベース・サーバーを使用すると、ローカルにインストールされたデータベースより潜在的に多くの利点があります。特に、既存のセキュリティおよびバックアップのポリシーと統合しやすく、さらに専用サーバーの使用によりパフォーマンスが向上します。
現在、RUEIではOracle 11gおよび12cリリース1のデータベース・インストールがサポートされています。Oracle 10g(またはそれ以前の)データベースはサポートされていない点に注意してください。
この項では、使用できる様々なデプロイメント・シナリオに焦点を当てます。最適なデプロイメント・シナリオの選択は、監視されるネットワーク・トラフィックのレベル、レポート要件およびデプロイメント・システムのハードウェア仕様によって主に決定されます。
単一サーバーのデプロイメント
これは最も単純なデプロイメントで、トラフィックが小または中程度のレベルのWeb環境の監視に適しています。図1-7に例を示します。
このデプロイメントで、単一のシステムは、コレクタおよびレポータとして機能します。前述の項のように、レポータ・データベースをレポータ・システムまたはリモート・データベース・サーバーにローカルに置くことができます。
複数のサーバーのデプロイメント
非常に高レベルの通信を監視する必要がある場合、複数のサーバーの使用を検討できます。さらに、このデプロイにより、セキュリティが強化される可能性もあります。たとえば、コレクタをオフィス・ネットワーク外に配置する一方で、レポータ・システムをネットワーク内に配置する方法です。図1-8は、複数のコレクタのデプロイメントの例を示しています。
両方のデータ回線が同じレポート環境で監視されるデプロイメントを説明しています。このデプロイメントは、各回線上の通信が互いに排他的であることを前提としていることに注意してください。セキュリティ上の理由で使用されるデプロイメントも示しています。WebサーバーAおよびBからの通信が監視され、レポートが作成されるのに対し、WebサーバーCからの通信は監視もレポート作成も行われません。これは、コレクタがスイッチの上に配置されていない理由でもあります。レポータ・システムのコレクタ・インスタンス(システム1)が無効であることに注意してください。
セキュリティ上の理由から、レポータ・システムに対するアクセスは、信頼できるIPの範囲に制限することをお薦めします。同様に、レポータ・システムを内部ネットワークに配置して、セキュリティを最大限にすることができます。コレクタのデータ収集ポートはDMZ内に置く必要があります。
データベースに保持されるアプリケーションおよびインフラストラクチャ構成情報は、ブラウザベースのインタフェースを通してシステム・ユーザーが提供する情報に基づいて、レポータによって維持されます。各コレクタは、この情報を使用して、収集されるデータのレポート方法を決定します。
3層のデプロイメント
前述のように、処理エンジンは、通常はレポータによって実行される多くの処理を個別のシステムにオフロードします。レポータ・システムのCPU使用率が上限に達している場合、デプロイメント内の処理エンジンの使用を検討することを強くお薦めします。図1-9は、複数のコレクタのデプロイメント内の処理エンジンの例を示しています。
|
注意: 処理エンジンの使用はリモート・コレクタにのみサポートされます。処理エンジンとコレクタを組み合せて同じシステムにインストールすることはサポートされていません。 |
レポータ・システムで実行される処理に、接続されたコレクタで収集されたデータの処理だけでなく、エンリッチ・データ・エクスポート機能の使用も含まれることを理解する必要があります。これを使用すると、RUEIで収集されたデータを他のデータ・ソースと組み合せることができます。有効にすると、この機能がレポータ・システムに多くの追加の負荷をかけることに注意してください。エンリッチ・データ・エクスポート機能の使用方法の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
選択した構成(第1.4項「インストール・オプション」で説明)に必要な最低限のシステム仕様については、この後の項で説明しています。
インフラストラクチャ用のネットワーク・カードの選択は、慎重に検討することをお薦めします。1.3項「ネットワーク・データ収集の接続オプション」で選択した接続オプションによっては、銅回線ベースおよびファイバベースの両方のネットワーク・カードが必要な場合があります。必要に応じて、ネットワークおよびシステムの両方の管理チームに相談してください。
結合グループ内のネットワーク・カード
結合グループの一部であるネットワーク・カードを使用したネットワーク・トラフィックの監視はサポートされていないことに注意してください。
|
注意: 必須および推奨のシステム仕様の詳細は、Oracleサポート・サービスにお問い合せください。 |
表1-3 単一サーバー・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
ネットワークTAPデバイスを使用する場合は脚注4 、3つ以上のネットワーク・インタフェースが必要。
|
|
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート( |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
脚注4 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成の使用はサポートされていません。
表1-4 レポータ・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
1つ以上のネットワーク・インタフェースが必要。 |
|
GSMモデム(オプション) |
テキスト・メッセージを送信するためのGSMモデムのオプション・サポート。モデムはGSM07.05またはGSM07.07互換であることが必要です。シリアル・ポートまたはUSBポートを介して接続できます。USBが使用されている場合、RUEIは使用可能な最初のポート(ttyUSB0)を使用します。テキスト・メッセージ送信の代替方法を使用できます(http/e-mail)。 |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
コレクタ・システムの要件を表1-5に示します。
表1-5 コレクタ・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルコア・プロセッサまたは同等のもの。 |
|
メモリー |
8GB。 |
|
ディスク領域 |
200GB以上のHDD空き領域脚注1 。 |
|
ネットワーク・インタフェース |
ネットワークTAPデバイスを使用する場合は脚注2 、3つ以上のネットワーク・インタフェースが必要。
ネットワーク・コピー・ポートを使用する場合、2つ以上のネットワーク・インタフェースが必要。
|
脚注1 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
脚注2 ネットワークTAPデバイスでデータを取得する場合、カスケード式のTAP構成は使用できません。
脚注3 アップストリーム通信およびダウンストリーム通信用。アップストリームとダウンストリームの通信を1つの回線に統合するTAP(つまり、リンク集約TAP)の使用はお薦めできません。
処理エンジン・システムの要件を表1-6に示します。
|
注意: 個別の処理エンジン・サーバーは、(1日に数億回のクリックを処理するような)非常に規模の大きい環境でのみ必要です。処理エンジンをレポータと別々に実行する場合は、少なくとも2台のサーバーを処理エンジン専用にする必要があります。 |
表1-6 処理エンジン・システムの最低要件
| 要素 | 要件 |
|---|---|
|
CPU |
64ビットIntelまたはAMDデュアルCPU、デュアルコア・プロセッサ(> 2GHz)または同等のもの。 |
|
メモリー |
16GB。 |
|
ディスク領域 |
|
|
ネットワーク・インタフェース |
1つ以上のネットワーク・インタフェースが必要。 |
脚注1 RUEIインストールで満足なパフォーマンスを確保するには、70MB/秒以上のI/O速度をサポートする高性能のディスク・システムの使用をお薦めします。大量の通信を監視する場合、さらに強力なディスク・システムが必要になる可能性があります。(ハードウェア)RAID-10または同等の記憶域構成を強くお薦めします。
脚注2 データ交換機能が強化されている場合は、増やす必要があります。
脚注3 ローカル・データのNFS共有の使用(つまり、$RUEI_DATAおよび$RUEI_HOME)はサポートされていません。この制限は$RUEI_DATA/processor/dataおよび$RUEI_DATA/collector/wg/REPLAYに適用されないので注意してください。
|
重要: Intel(またIntelと互換性のある)64ビット・プラットフォームは、すべてのデプロイメント・シナリオにおけるハードウェアとオペレーティング・システムでの必須要件です。 |
この項では、RUEIのデプロイメントを最適化するベスト・プラクティス・フレームワークを紹介します。次の情報を注意深く再検討することをお薦めします。
デプロイの計画
RUEIデプロイメント計画を決定する前に、監視対象のネットワーク環境の性質を明確に理解することが重要です。これには、基本的なネットワーク接続性、ポート、アドレス指定および物理デバイス要件だけではなく、監視対象のアプリケーションのしっかりした理解も含まれます。
さらに、RUEIをデプロイする前に、ネットワーク内の基本的な通信フローが確認されている必要があります。これには、平均およびピーク時の通信量に関する情報が必要です。物理デプロイ要件(スペースの制限、距離、電力計画、ラックのスペースおよびレイアウト、または配線など)も確認されている必要があります。
付録H「インストール・チェックリスト」で紹介しているチェックリストを使用すれば、この情報の大部分を取得できます。
Formsベースの通信
Formsベースの通信を監視する場合、メモリー要件は、第1.7項「サーバーの要件」に概説されているものよりも大きくなる可能性があることに注意してください。特に大量のForms通信を伴うデプロイの場合がこれに当てはまります。この場合は、分割サーバーのデプロイを検討する必要があります。
フル・セッション・リプレイ機能
フル・セッション・リプレイ(FSR)機能を利用する場合は、記憶容量追加の構成が必要になる可能性があります。これについては、第1.7.7項「フル・セッション・リプレイの記憶域要件」で説明しています。
暗号化通信
監視対象の通信の相当な量が暗号化される場合、CPUのオーバーヘッドが増える可能性があります。この場合、CPUの追加または分割サーバー・デプロイの構成を検討することをお薦めします。
大量の通信
非常に多い量の(つまり、1日当たりのページ・ビューが1000万件を超える)通信を監視している場合、分割サーバー・デプロイを検討することを強くお薦めします。または、リモート・データベース・サーバーの使用を検討してください。後者には、レポート・システム上のCPUオーバーヘッドを大幅に(最大30%)減らす効果があります。監視対象環境の1日当たりのページ・ビューが2000万件を超える場合、分割サーバー・デプロイとリモート・データベース・サーバーの両方の使用を検討する必要があります。
データ・ブラウザ内に特定データとそのデータに基づくレポートを表示できるかどうかは、コレクタ・システムおよびレポータ・システムで使用可能なディスク領域の量、およびレポータ・システムで使用可能なデータベース領域の量によって異なります。
監視中に収集されたデータは、まず、コレクタ・システムに格納されているログ・ファイルに書き込まれます。これらのファイルはレポータにコピーされて処理され、データ・ブラウザおよびレポートで表示可能な多次元のデータ構造を持つデータベースに移入されます。これらの一時ログ・ファイルは、3日後にはコレクタ・システムから自動的に削除され、レポータ・システムからは7日後に削除されます(デフォルト)。
レポータ・システムのデータベース・ユーザー割当て制限のサイズは、インストール中に設定されます。デフォルトでは500GBに設定されます。レポータ定義の保存ポリシーで必要なくなるとデータが統合されることを理解しておく必要があります。たとえば、デフォルトでは直前の32日間について日単位の情報が保持されます。これより古い日単位の情報は月単位の情報に統合されます。同様に、月単位の情報は年単位の情報に統合されます。
RUEIではデータは複数の集計レベルで保持され、その保存は日単位で構成されます。次に、様々な集計レベルとそのデフォルト値について説明します。
インスタンス: 8日
5分: 15日
毎時: 32日
日次: 90日
月次: 60か月
これらの数値はデータのカテゴリ(アプリケーション、スイート、サービス、SLA)ごと、および個別のタイプ(たとえば、すべてのページ、失敗したページ)ごとに微調整できます。エンリッチ・データ交換のデフォルト値はタイプごとに8日です。
DB領域は期間ごとに約5GBです。これは、トラフィックの負荷および多様性に大きく依存します。特に最初の月はレポータ・データ保存画面を時々チェックし、十分なディスク領域が使用可能であることを確認する必要があります。
統計データはCLIから構成できます。ただし、統計保存は構成できません。ユーザー・フローの完了およびFusion製品保存は、コマンドラインからのみ構成できます。
データ保存設定の最小値および最大値は自動的に決定されます。それほど詳細ではない集計レベルには、少なくとも、より詳細なレベルと同じ程度の保存が必要です。
新しいインストール済RUEIは、最初の32日間に最も急成長を遂げます。その期間が過ぎると、成長率は低下します。もちろん、成長率は、監視されているトラフィック・レベルによって異なります。
フル・セッション・リプレイ(FSR)機能を使用する場合、コレクタ・システムで使用可能な記憶容量の追加が必要になる可能性があります。これは、コレクタ・サーバーの既存のハード・ドライブのパーティションではなく、別のデバイスにし、RUEIファイル・システムにアクセスできるようにする必要があります。この手順は、記憶域の要件に関する指標とともに、この項の残りの部分で説明します。この手順は、フル・セッション・リプレイ情報が必要なコレクタごとに繰り返す必要があります。
フル・セッション・リプレイ用追加記憶域の構成
この後説明する手順は、完全に機能しているシステムがあり、FSRが有効になっていることを前提としています。追加の必須記憶域を構成するには、次のようにします。
デバイスをマウントします。たとえば、/mnt/external_storageの下にマウントします。
次のコマンドを発行して、一時的にコレクタを停止します。
appsensor stop wg
$APPSENSOR_HOME/wg/REPLAYディレクトリを新しいデバイスに移動します。上の例では、これは/mnt/external_storageで、その結果、リプレイ・ファイルは/mnt/external_storage/REPLAYディレクトリに置かれるようになります。
/mnt/external_storage/REPLAYから$APPSENSOR_HOME/wg/REPLAYへのシンボリック・リンクを作成します。
次のコマンドを発行して、コレクタを再起動します。
appsensor start wg
必須記憶域容量を計算します。これには、毎日の平均ページ・ビュー数に平均ページ・サイズを掛けます。次に、この数にフル・セッション・リプレイ・データの希望保存日数を掛けます。表1-7を指標として使用してください。
表1-7 フル・セッション・リプレイ記憶域の推定値
| データ量が小さいページ(10KBまで) | データ量が中程度のページ(50KBまで) | データ量が大きいページ(100KBまで) | ||||
|---|---|---|---|---|---|---|
|
1日当たりのページ・ビュー数(100万単位) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
1日当たりのサイズ(GB) |
ディスクI/O(MB/秒) |
|
0.5 |
5 |
0.1 |
25 |
0.3 |
50 |
0.6 |
|
2 |
20 |
0.2 |
100 |
1.2 |
200 |
2.3 |
|
5 |
50 |
0.6 |
250 |
2.9 |
500 |
5.8 |
|
10 |
100 |
1.2 |
500 |
5.8 |
1000 |
11.6 |
|
20 |
200 |
2.3 |
1000 |
11.6 |
2000 |
23.1 |
|
50 |
500 |
5.8 |
2500 |
28.9 |
5000 |
57.9 |
|
注意: FSR機能では、多数の非順次読込み操作が使用されることに注意してください。I/Oパフォーマンスを最適化する方法の情報は、ハードウェアのベンダーにお問合せください。 |
「構成」、「一般」、「詳細設定」、「コレクタ・データ保持ポリシー」の順に選択します。フル・セッション・リプレイ記憶域のサイズ(GB)設定をクリックします。必須記憶域のサイズを指定(GB単位)します。指定できる最大値は100TBです。次に、「保存」をクリックします。
RUEIインストールに必要なRAMの量を計算するとき、次の点を検討することをお薦めします。
構成された処理エンジンのないレポータ・システムまたは処理エンジン・システム自体で、1日当たり100万ビジター・セッションの場合、256MBが必要です。したがって、1日当たり300万ビジター・セッションの場合、768MBが必要になります。さらに、100万ページ・ビューごとに100MBから256MBが必要です。正確な量は、監視対象のURLの長さ、平均セッション持続時間およびイベント(カスタム・ディメンションなど)の数によって決まります。
各コレクタ・システムでは、100同時ヒットごとに2MB、1000件のSSL接続ごとに1MBが必要です。さらに、ネットワーク通信は、個々のTCPセッションが削除され始める前に、600MBpsまでバッファリングできます。コンテンツ・チェック(XPath問合せやエラー文字列など)用にも最大600MBpsを想定しておく必要があります。多数のコンテンツ・チェックを定義したり、コンテンツ・チェックにNLS文字セットを指定したりする場合、必要なメモリーが増える可能性があることに注意してください。
次のGNU/Linuxディストリビューションがサポートされています。
Oracle Linux 5.xまたは6.x 64ビットIntelまたはAMD互換性。
RedHat Enterprise Linux 5.xまたは6.x 64ビットIntelまたはAMD互換性。
次のデータベース・バージョンがサポートされています。
11gR2
12cリリース1
RUEIで必要なOracle Databaseの最小リリースは11gR2です。RUEI 12.1.0.7のベスト・パフォーマンスはOracle Database 12cリリース1で実現されます。
機密データの暗号化
機密データの暗号化が必要な場合、Linuxのインストール手順におけるディスク・パーティションの段階で、ディスク構成全体を暗号化する機会があります。
すべてのサーバーのシステム・クロックを、UDPポート123を介してNTPを使用し、同期化。
TCPおよびUDPポート53でのDNS情報リクエストのサポート。
TCPポート25を使用したレポートおよび電子メール・アラートのサポート。
UDPポート161/162を使用したSNMPマネージャからのリクエストでのSNMPトラップのサポート。
RUEIユーザー・インタフェースが、HTTPSポート443を通じてアクセス可能であること。
リモート・データベース設定の場合、レポータとリモート・データベース・サーバー間でTCPポート1521へのアクセスが必要。
各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。他のすべてのポートはブロックすることをお薦めします。
フェイルオーバー・レポータ・システムを構成する場合は(第9章「フェイルオーバー・レポータ・システムの構成」で説明)、プライマリおよびセカンダリ・レポータ・システムがICMPを使用して相互通信可能でなければなりません。
フェイルオーバー・コレクタ・システムを構成する場合は(第10章「フェイルオーバー・コレクタ・システムの構成」で説明)、プライマリおよびセカンダリ・コレクタ・システムがICMPを使用して相互通信可能でなければなりません。
コレクタとレポータおよびコレクタと処理エンジンのバンド幅
リモート・コレクタとレポータ・システム間で転送されるデータ量は、主としてRUEIによって監視されるネットワーク・アプリケーション通信のタイプやレベルによって決まります。さらに、RUEIの構成(定義済の機能エラー、コンテンツ・チェック、ページ命名スキームなど)も、レポータ・システムに転送する必要のあるコレクタ・ファイルのサイズに影響を与えます。
ピーク時には、転送が必要なデータの量は、通信量の少ない期間より多くなります。リモート・コレクタからレポータ・システムへのデータ送信の正確な量は、実際のRUEIデプロイ後でなければ確認できません。
初期のデプロイには、次の簡単なルールを使用できます。1日のページ・ビュー500万件ごとに、ピーク時のピーク転送量は約125MB、1日当たり約1GBになります。したがって、通常、コレクタによって格納され、レポータに転送される通信は、実際に監視される通信の数パーセントにすぎません。このデータ転送量を最小限に抑える必要がある場合、RUEIで必要のない監視対象HTTP通信の量を最小限に抑えることをお薦めします。たとえば、サブネットまたはVLANフィルタ設定ネットワークを使用します。
処理エンジンを使用するデプロイメントの場合、上記の内容がコレクタと処理エンジン接続にも適用されます。
ファイアウォール要件
表1-8に、各RUEIデプロイメントのファイアウォール要件を示します。
表1-8 RUEIファイアウォール・ルール
| コピー元 | コピー先 | ポート | ソケット・タイプ | 必須 | 説明 |
|---|---|---|---|---|---|
|
レポータ |
コレクタ |
22 (SSH) |
TCP |
Y |
各リモート・コレクタ・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。 |
|
レポータ |
処理エンジン |
22 (SSH) |
TCP |
Y |
処理エンジン・システムに、TCPポート22を介してレポータ・システムでアクセスできなければなりません。 |
|
レポータ |
処理エンジン |
1521脚注1 (NET8) |
TCP |
Y |
各処理エンジン・システムは、データベース接続(デフォルトでは、ポート1521以上)からアクセスできる必要があります。 |
|
レポータ |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
処理エンジン |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
処理エンジン |
コレクタ |
22 (SSH) |
TCP |
Y |
各コレクタ・システムに、TCPポート22を介して処理エンジン・システムでアクセスできなければなりません。 |
|
処理エンジン |
レポータ |
1521 (NET8) |
TCP |
Y |
各処理エンジン・システムは、データベース接続(デフォルトでは、ポート1521以上)からアクセスできる必要があります。 |
|
コレクタ |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
Remote DB server |
NTPサーバー |
123 (NTP) |
UDP |
Y |
サーバーのシステム・クロックはすべてNTPを介して同期化される必要があります。 |
|
レポータ |
DNSサーバー |
53 (DNS) |
TCP/UDP |
N脚注2 |
DNS情報のリクエストをサポートします。 |
|
コレクタ |
DNSサーバー |
53 (DNS) |
TCP/UDP |
N脚注 2 |
DNS情報のリクエストをサポートします。 |
|
Remote DB server |
DNSサーバー |
53 (DNS) |
TCP/UDP |
N脚注 2 |
DNS情報のリクエストをサポートします。 |
|
レポータ |
メール・サーバー |
25 (SMTP) |
TCP |
N |
レポートと電子メールのリクエストをサポート。 |
|
レポータ |
SNMPマネージャ・サーバー |
161、162 (SNMP) |
UDP |
N |
SNMPマネージャからのリクエストでのSNMPトラップのサポート。 |
|
クライアント・ブラウザ |
レポータ |
443 (HTTPS) |
TCP |
Y |
RUEIユーザー・インタフェースが、HTTPSポートでアクセス可能であること。 |
|
クライアント・ブラウザ |
タグ・ベースのコレクタ |
80/443 |
TCP |
N |
タグ・ベースのデータ収集をサポートします。 |
|
ADFアプリケーション |
レポータ |
443 (HTTPS) |
TCP |
N |
ADF監視サービスをサポートします。 |
脚注1 このポートが構成可能なことに注意してください。
脚注 2 オプションですが、強くお薦めします。
RUEIユーザー・インタフェースにアクセスするワークステーションには、次のいずれかのブラウザがインストールされている必要があります。
Mozilla Firefox 3.6(以上)。
Internet Explorer 7、8または9。
Safari 4および5。
Google Chrome 17(以上)。
JavaScriptは有効にする必要があります。その他に必要なブラウザ・プラグインはありません。
また、ワークステーションの画面解像度は、1024×768(以上)が必要です。
|
重要: ブラウザ内のポップアップ・ブロッカが無効になっていることを確認してください。 |
AJAXサポート
RUEIではAJAXを使用して、ユーザーとの対話を強化します。Internet Explorerでは、MSXML制御を利用してAJAXの操作を容易にします。AJAXに依存すると、厳格なセキュリティ設定を使用している場合に、セキュリティの警告が発せられる可能性があります。
脚注の説明
脚注1: コピー・ポートは、スイッチ・ポート・アナライザ(SPAN)・ポートとしても知られる、Ciscoスイッチの機能です。
