| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
 前 |
 次 |
| Oracle® Real User Experience Insightユーザーズ・ガイド 12c リリース6 (12.1.0.7) for Linux x86-64 E61771-02 |
|
前 |
次 |
この付録では、RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの後に配置した場合に、どのようにして正確なネットワーク・トラフィック・レポートを作成できるかについて説明します。
『Oracle Real User Experience Insightインストレーション・ガイド』で説明しているように、RUEIでネットワーク・トラフィックのコピーを確認できることは非常に重要です。これは、コピー/SPANポートまたはTAPデバイスを使用して取得できます。
図Q-1に、カスケード接続されたデバイスの代表的構成を示します。実際には、デバイス数ではこの図と異なる場合があっても、接続の順序は一般にこの図に示すとおりです。ファイアウォール、SSLオフローダ(SSL暗号化トラフィック)およびロード・バランサ機能は、1つまたは2つのコンポーネントに組み込まれています。
ほとんどのネットワークでは、監視対象となる位置は、ファイアウォールのすぐ後ろ(またはすぐ前)、SSLオフローダのすぐ後ろ、およびロード・バランサのすぐ後ろの3つがあります。これらを図Q-1に示します。これら3つの監視対象位置の意味を表Q-1に示します。
表Q-1 監視対象位置の特性
| 位置 | サーバー/情報が使用可能か | クライアント/情報が使用可能か | SSL証明書が必要か |
|---|---|---|---|
|
1 |
ヘッダーでの応答に入れる場合のみ |
はい |
はい脚注1 |
|
2 |
ヘッダーでの応答に入れる場合のみ |
はい |
いいえ |
|
3 |
はい |
NATデバイスからリクエスト・ヘッダーに入れて配信された場合のみ |
いいえ |
脚注1 SSLオフロード・ポイントの前に配置する場合は、SSL鍵をRUEIコレクタ・システムにアップロードする必要があります。これは、RUEIがSSLトラフィックを復号化できるようにするために必要です。
インターネット・サービスの場合、ロード・バランサは、外部クライアントがサービスにアクセスするために接続するポートをリスニングします。ロード・バランサはリクエストをバックエンド・サーバーの1つに転送し、通常、バックエンド・サーバーがロード・バランサに応答します。これにより、内部では機能が分離されていることをクライアントが認識していない場合でも、ロード・バランサがクライアントに応答できるようになります。また、クライアントによるバックエンド・サーバーへの直接アクセスを防止し、社内ネットワークの構造が隠されるため、セキュリティ上の利点もあります。
RUEIシステムをネットワーク・アドレス変換(NAT)デバイスの前に配置することをお薦めします。これにより、RUEIが即座に適用され、エンドユーザーの発信元IPアドレスをTCPレベルで確認します。図Q-1に示す構成はネットワークによって異なりますが、NATを実行するのは一般にロード・バランサ・デバイスです。
IPアドレス変換がすでに行われたネットワーク・セグメントにRUEIをデプロイしていて、次の項で説明する構成手順を実行していない場合は、NATデバイスの単一IPアドレスのみがエンドユーザーのIPアドレスとしてレポートされます。これは、レポートされるデータの正確性には悪影響を与えませんが、地理的なクライアント情報およびISPのクライアント情報が使用できなくなることを意味します。
|
注意: RUEIの監視位置は常にVPN/解凍デバイスよりも後ろである必要があります。これは、RUEIが暗号化デバイスと復号化デバイスの間のHTTP以外のトラフィックを読み取ることができないためです。 |
|
注意: デバイスが異なるとRUEIデータ収集に対する影響も異なり、監視位置によってはネットワーク・パフォーマンス・メトリックまたはサーバー・パフォーマンス・メトリックのデータが失われる場合があります。一般に、図Q-1の位置1の場合にクライアント・ネットワーク・パフォーマンス・データが最高になり、位置3の場合にサーバー・ネットワーク・パフォーマンス・データが最高になります。たとえば、RUEIの場所として位置3を使用することにした場合、ページがクライアント・ブラウザに配信される前にページ配信の測定が行われることがあります。この場合、RUEIで間違った(短すぎる)ネットワーク時間がレポートされることがあります。 |
前述したように、発信元のエンドユーザーのIPアドレスを取得することは、正確な地理上のクライアント・レポートおよびISPによるクライアント・レポートを作成するために必要です。RUEIでは、IPアドレスは通常、クライアントから送信されたIPヘッダー・パケットから取得されます。IPパケットには、パケットの送信元および送信先の数値アドレスが含まれます。ただし、RUEIをNATデバイスの後ろに配置している場合は、このIPパケットにはエンドユーザーのIPアドレスでなくNATデバイスのIPアドレスが含まれます。
ただし、発信元の(エンドユーザー)IPアドレスは通常、NATデバイスからWebサーバーに送信されたHTTPヘッダーに保存されています。このような場合は、IPパケットでなくこのヘッダーの中でIPアドレスを検索するようRUEIに指定できます。
IPパケットではなくHTTPヘッダーを使用するように指定する手順は、次のとおりです。
「構成」→「アプリケーション」→「アプリケーション」の順に選択します。目的のアプリケーションをクリックします。または、目的のスイートかサービスを選択します。概要が表示されます。
「拡張」タブ→「クライアントIP」タブの順にクリックします。
ヘッダーが定義されていない場合は、「HTTPヘッダーの指定」項目をクリックします。または、「編集」をクリックします。図Q-2のダイアログが表示されます。
追加するヘッダーの「タイプ」を選択します。HTTPヘッダーはHTTPリクエストから導出され、TCPヘッダーはTCPオプション・フィールドから導出されます。現在使用可能なTCPヘッダーはAkamaiのみで、SSL暗号化トラフィックの転送時に使用されます。
「ヘッダー」フィールドを使用して、クライアントIPアドレスの取得元のリクエスト・ヘッダーを指定します。次に、「追加」をクリックします。ヘッダーが複数ある場合は、「上に移動」と「下に移動」コントロールを使用して、試行される順序を指定します。図Q-2に示す例では、Akamaiヘッダーが最初に検索されます。ない場合は、HTTP proxyのクライアントIPヘッダーが使用されます。次に、「保存」をクリックします。
クライアントIPアドレスを指定したリクエスト・ヘッダーから導出できない場合、IPヘッダー・パケットから取得されます。クライアントIPアドレス・ソース設定は、変更すると5分から10分後にRUEI内に表示されます。また、変更は履歴データにでなく現在収集されているデータにのみ適用されます。RUEIがNATデバイスの後ろにデプロイされている場合は、アプリケーション管理チームおよびインフラストラクチャ管理チームとともに、適切な方法でHTTPヘッダーからエンドユーザーのIPアドレスが収集されているかどうかをチェックおよび検証することをお薦めします。
応答するサーバーのIPアドレスを確認することも、役に立つ場合があります。たとえば、サーバー・ファームでページが低速か失敗しているという問題が発生した場合、関連するサーバーのIPアドレスが即座に確認可能であれば、この問題の解決までの時間は大幅に短縮されます。
これは、ロード・バランサに返信されるヘッダーに、応答するサーバーのIPアドレス(またはその他のID情報)を挿入すると確認できます。
図Q-3にHTTPヘッダーの例を示します。これは、Mozilla FirefoxのLive HTTP headersプラグインのものであり、元のWebサーバーのID(www236)がHTTPヘッダーに移送された様子を示しています。
この例におけるヘッダーの要素名はxserverです。これはカスタム・ディメンションを使用して取得できます。この詳細は、3.12項「カスタム・ディメンションの使用」に記載されています。
