| Oracle® Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド リリース12.1.0.8 B66835-11 |
|
 前 |
 次 |
| Oracle® Enterprise Manager Cloud Control Oracle Fusion Middlewareマネージメント・ガイド リリース12.1.0.8 B66835-11 |
|
前 |
次 |
この章では、Enterprise Managerのアプリケーション・リプレイ機能を使用して、本番環境のワークロードでアプリケーションの負荷およびパフォーマンスをテストする方法について説明します。アプリケーション・リプレイを使用すると、本番システムのアプリケーション・ワークロードを取得して、そのワークロードとまったく同じタイミング、同時実行性およびトランザクションの順番を維持しながら、テスト・システムでリプレイできます。
この章の内容は次のとおりです。
アプリケーション・リプレイでは、テスト・システム上に本番のワークロード環境を再作成することにより、アプリケーション・サーバーからディスクに至るまでアプリケーション・スタック全体を対象に、計画された変更の現実的なテストが可能です。アプリケーション・リプレイを使用すると、本番システム上でワークロードを取得し、テスト・システムでオリジナルのワークロードの正確なタイミング、同時実行性およびトランザクション特性を使用して、それをリプレイできます。これにより、変更の影響(望ましくない結果、新しい競合ポイント、計画の品質低下など)を詳細に評価できます。また、広範な分析およびレポートを利用して、新しく発生したエラーやパフォーマンスの相違など、起こりうる問題の特定に役立てることができます。アプリケーション・リプレイでテスト可能な変更には、アプリケーション・サーバーのアップグレード、ハードウェアの更新、O/Sの変更、構成の変更などがあります。実際の本番ワークロードを取得することで、シミュレーション・ワークロードやスクリプトを開発する必要がなくなり、コストと時間を大幅に節約できます。アプリケーション・リプレイを使用すると、従来はロード・シミュレーション・ツールを使用して数か月かかっていた複雑なアプリケーションの現実的なテストを数日で完了できます。その結果、より高度な信頼性をより少ないリスクで確保しながら、計画された変更を迅速にテストして新しいテクノロジを導入できます。
今日のエンタープライズ・アプリケーションのデプロイメントは非常に複雑で管理が困難です。Webサーバー、アプリケーション・サーバー、データベースなどの複数の層で構成され、それぞれが複数のホスト上で稼働しています。これらのソフトウェア・アーキテクチャでは、通常はHTTP経由で構築されるクライアント/サーバーのステートフルなプロトコルに加え、クライアント側のユーザー・インタフェース、ビジネス・ロジック、データ・アクセス・メカニズムといった複数の独立したコンポーネントが組み合されています。
このように構造が複雑なため、本番環境におけるスタック全体の動作を予測することは非常に困難です。デプロイメントが複雑で、システム全体の検証方法がない場合、インフラストラクチャを変更した後でデプロイメントを正常に実施するには、効果的なテストが不可欠です。
アプリケーション・リプレイ機能のテスト構成では、最初に本番サイトでアプリケーションに関連するワークロード全体(アプリケーションのWebインタフェースによって生成される)を取得します。
次に、取得したアプリケーション・ワークロードをテスト環境に移行し、1つ以上のホスト上のリプレイ・ドライバ・インストラクチャによって、同時実行性やリクエストのタイミングといった元のプロパティを維持しながら、取得したワークロードが再現されます。
最後に、スタックのすべての層からパフォーマンスと正確性に関する広範なデータが収集およびレポートされます。これにより、リプレイと取得元のワークロードを比較できます。この方法では、リプレイ中に発生したインフラストラクチャの変更に起因する問題を特定し、適切なトラブルシューティングを行って、それが本番環境で発生するのを防ぐことができます。さらに、正常なデプロイメントを実施する信頼性が高まります。
実際のワークロードを使用することで、模擬的なワークロードに基づいたテスト方法よりも、はるかに優れた数多くのメリットが得られます。詳細は次のとおりです。
ユーザーのアクティビティからシステムの全体像を把握します。これは、個々のコンポーネントを断片的にテストし、実際のワークロード下における複合的な動作やパフォーマンスの情報がほとんど提供されない従来のテスト方法とは対照的です。
事前に決められたシナリオに依存せず、実際のワークロードを使用することで、実際のユーザー操作による影響を受けながら、システムの包括的なテストを行います。Webアプリケーションの場合は、ユーザーがシステムに対して行うであろうすべての操作だけでなく、想定される負荷の状態もすべて検討することになります。ワークロードの特性(同時実行ユーザー数など)が異なればシステムの動作も大きく異なるため、これは重要です。
発生する可能性のあるエラーをより明確に把握します。テスト結果にはスタック各層のデータが含まれ、それらを異なる層間で相互に関係付けることができます。パフォーマンス以外にも、エラーまたは予期しないサーバー・レスポンスをチェックして適切な実行を検証する方法が用意されています。
アプリケーション・リプレイでは、Oracle Real User Experience Insight(RUEI)を使用して、Webアプリケーションのワークロードを取得します。これはWebベースのユーティリティで、Webインフラストラクチャによってリクエストされる、またはWebインフラストラクチャから生成される実際のユーザーのトラフィックに関するレポートを作成します。ネットワーク・インフラストラクチャの最も重要となるポイントで、ページおよびユーザー・フローのレスポンス時間が測定されます。ネットワークおよびビジネス・インフラストラクチャの強力な分析を提供し、その一方でアプリケーション・マネージャおよびIT技術スタッフは、鋭い診断機能を活用して、根本原因解析を行うことができます。
通常、RUEIはWebサーバーの前、DMZ内のファイアウォールの後ろにインストールされます。データ収集方法は、ネットワーク・プロトコル分析(NPA)テクノロジに基づいています。このデータ収集方法を図3-1に示します。
ビジターがオブジェクトをリクエストすると、RUEIはそのリクエストを確認し、リクエストされたオブジェクトをビジターに表示するためにWebサーバーが要する時間の測定を開始します。この時点で、誰がそのページをリクエストしたか(IPクライアント)、どのオブジェクトがリクエストされたか、およびどのサーバーからオブジェクトが要求されたか(IPサーバー)がRUEIで認識されています。
RUEIでは、Webサーバーが応答し、オブジェクトをビジターに送信するときに、そのレスポンスを確認し、サーバーのレスポンス時間の計測を中止します。この段階でRUEIにより、サーバーからのレスポンスがあるかどうか、このレスポンスが正しいかどうか、リクエストされたオブジェクトの生成にWebサーバーで要する時間、およびオブジェクトのサイズを確認できます。
RUEIにより、オブジェクトがビジターに完全に受信されたかどうか、またはビジターがダウンロードを中断したかどうか(配信の証明)も確認できます。したがって、RUEIでは、オブジェクトがインターネットからビジターに渡されるまでの時間を測定し、ビジターとサーバー間のインターネット・スループット(ビジターの接続速度)を計算できます。
RUEIの詳細は次のサイトを参照してください。
http://www.oracle.com/us/products/enterprise-manager/index.html
この項では、アプリケーション・リプレイ機能を使用してワークロードの取得およびリプレイを行うために満たす必要のある要件および考慮すべき問題について説明します。ワークロードの取得に進む前に、この情報を慎重に検討することを強くお薦めします。
|
重要: Oracle SupportのWebサイトを参照して、サポートされているRUEI、アプリケーション・サーバーおよびデータベースのバージョン、パッチ、構成、既知の問題および回避策に関する最新情報を確認することを強くお薦めします。 |
この項の内容は次のとおりです。
RUEIを使用してアプリケーション・ワークロードを取得するには、次の点を確認する必要があります。
目的のアプリケーションを監視するようにRUEIリリース12.1以上が構成されている。必要なリリースおよびホット・フィックスについては、Oracle SupportのWebサイト(http://www.oracle.com/support/contact.html)を参照してください。デプロイメント・オプションおよび要件については、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
ユーザー名とパスワードの有効な組合せを保持している。必要に応じて、RUEIの管理者に連絡してください。ユーザー・アカウントにはセキュリティ責任者の権限が付与されている必要があります。ロールと権限の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
RUEIインストールへのアクセスに使用するURLを把握している。必要に応じて、RUEIの管理者に連絡してください。
RUEIのロギングおよびマスキング・ポリシーの構成がアプリケーション・リプレイで使用する場合と一致している。これについては、次の項で説明しています。
アプリケーション・リプレイに対応したRUEIの構成
次の手順を実行して、RUEIのロギングおよびマスキング・ポリシーを前述のように構成する必要があります。
「構成」、「セキュリティ」、「マスキング」、「URL接頭辞マスキング」の順に選択して、デフォルトのマスキング処理の設定をクリックします。これを「ロギング」に設定する必要があります。
ワークロードの取得時に大量のトラフィックが予想される場合は、「構成」、「セキュリティ」、「コレクタ・データ保持ポリシー」の順に選択し、取得を計画している各アプリケーションに十分な記憶域を割り当てておくことをお薦めします。
これらの構成手順の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』の第13章「セキュリティ関連情報の管理」を参照してください。
アプリケーション・リプレイ機能のユーザーには、次のEnterprise Manager権限が割り当てられている必要があります。
ASREPLAY_VIEWER(取得、リプレイおよびリプレイ・タスクの表示)
ASREPLAY_OPERATOR(取得、リプレイおよびリプレイ・タスクの作成、変更、または送信)
この他、PERFORM_OPERATION_ANYWHERE権限がユーザーに割り当てられている必要があります。
データベース・ユーザーがデータベース取得を含むアプリケーション・リプレイ機能を実行するには、次の権限がユーザーに付与される必要があります。
GRANT ADMINISTER ANY SQL TUNING SET TO asreplay; GRANT EXECUTE ON DBMS_LOCK TO asreplay; GRANT EXECUTE ON DBMS_WORKLOAD_CAPTURE TO asreplay; GRANT EXECUTE ON DBMS_WORKLOAD_REPLAY TO asreplay; GRANT CREATE SESSION TO asreplay; GRANT CREATE ANY DIRECTORY TO asreplay; GRANT SELECT_CATALOG_ROLE TO asreplay; GRANT BECOME USER TO asreplay; GRANT DROP ANY DIRECTORY to asreplay;
前述の例では、データベース・ユーザーはasreplayと呼ばれることに注意してください。
ワークロードをリプレイするには、リプレイ・システムのアプリケーション・データの論理状態を、リプレイの開始時における取得システムのデータの状態と同じにする必要があります。したがって、テスト・システムでアプリケーション・サーバーとデータベースの状態をリストアするための方針を定める必要があります。アプリケーション・サーバーの状態をリストアするには、アプリケーション管理者に問い合せてください。データベースの状態をリストアするには、次のいずれかの方法を使用することを検討してください。
Recovery Manager(RMAN)のDUPLICATEコマンド。詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。
スナップショット・スタンバイ。詳細は、『Oracle Data Guard概要および管理』を参照してください。
データ・ポンプのインポートおよびエクスポート。詳細は、『Oracle Databaseユーティリティ』を参照してください。
取得したワークロードを格納するディレクトリを決定および設定します。取得を開始する前に、ワークロードを格納するために十分なディスク領域がディレクトリにあることを確認します。取得中にディレクトリのディスク領域が不足すると、取得が停止します。
必要なディスク領域を見積もるには、短期間(通常は数分間)、ワークロードのテスト取得を実行し、これを使用して完全取得に必要な容量がどれくらいかを推定することをお薦めします。潜在的なパフォーマンスの問題を回避するため、ターゲットのリプレイ・ディレクトリが別のファイル・システムにマウントされていることも確認する必要があります。
図3-2は、アプリケーション・リプレイ機能のアーキテクチャを示しています。
アプリケーション・リプレイの取得処理は、本番環境のコンテキスト内で実行されます。このデプロイメントは、Webサーバー、アプリケーション・サーバーおよびデータベースで構成されます。Web層の取得メカニズムはRUEIが提供します。これにより監視対象のトラフィックに関する情報が取得ファイルに書き込まれます。そこには、HTTPリクエスト、レスポンス、時刻、およびテスト・システムで本番のワークロードを正確に再現するために必要なその他のデータが含まれています。取得が完了すると、生成されたファイルには本番のワークロード全体が完全に表現されています。
アプリケーション・リプレイのリプレイ処理は、テスト・システムのコンテキスト内で実行されます。これは、テスト中のシステム構成を実行するアプリケーション・スタックで構成されます。1つ以上のリプレイ・クライアントが、同時実行性やリクエストのタイミングといった元のプロパティを維持しつつ、取得したワークロードを再現します。さらに、アプリケーション・リプレイ機能では同期化を使用して、リプレイされた各リクエストが取得時とまったく同じアプリケーション状態で処理されるため、レスポンスを直接比較できます。最後に、スタックのすべての層からパフォーマンス・データおよび検証データを大量に収集して、リプレイとその基礎となる元の取得が比較できるようになります。
ワークロードの取得のボリュームと同時実行性によっては、複数のリプレイ・クライアントをデプロイして、それぞれにワークロードの一部を割り当てる必要があります。リプレイを計画する際には、取得したワークロードによって必要なリプレイ・クライアント数の推奨を受けることができます。
アプリケーション・ワークロードの取得を作成するには、次の手順を実行します。
「エンタープライズ」メニューから、「クオリティ管理」、「アプリケーション・リプレイ」の順に選択します。
「取得」をクリックします。現時点で定義されている取得がリストされます。例を図3-3に示します。
「作成」または 「類似作成」をクリックします。図3-4のページが表示されます。
新規取得に一意の名前を指定します。オプションで、取得するトラフィックに短い説明を指定します。取得の目的や範囲についての説明を含めることをお薦めします。前提条件情報を十分に確認し、前提条件が満たされていることを示すために「確認」チェック・ボックスをクリックします。準備ができたら、「次へ」をクリックします。図3-5のページが表示されます。
「システムの選択」アイコンをクリックし、トラフィックの取得対象であるアプリケーションを表すターゲットを選択します。選択したコンポーネントのステータスを確認し、計画された取得の処理中、それが使用可能な状態となるようにしてください。選択したターゲットにサポートされているバージョンのOracle Fusion MiddlewareおよびOracle Databaseのコンポーネントがない場合、「取得の作成(データベース)」ページ(図3-7に表示)は使用不可となりスキップされることに注意してください。準備ができたら、「次へ」をクリックします。図3-6のページが表示されます。
RUEIインストールへのアクセスに使用するURLを指定します。これはセキュアな(HTTPS)接続に基づいている必要があります。ユーザー名とパスワードの有効な組合せを指定します。指定したユーザーは、セキュリティ責任者の権限を持っている必要があります。必要に応じて、この情報をRUEI管理者に問い合せてください。
「アプリケーションの表示」をクリックして、指定したRUEIデプロイメントによって現在監視されているアプリケーションを表示します。各アプリケーションのトラフィック情報を使用して、アプリケーションが取得に適切であるかを確認できます。特に、取得に含めるアプリケーションを選択する際は、アプリケーションが実行されていること、トラフィックのボリュームおよびエラー・レベルが許容範囲内にあることを確認してください。準備ができたら、「次へ」をクリックします。図3-7のページが表示されます。
アプリケーションの取得中にデータベースの取得を有効にするかどうかを指定します。同期リプレイの場合、これは必須です。有効にする場合、必要なデータベースおよびホストの資格証明、取得の中間記憶域として使用するデータベース・ホスト・システム上のファイル・システムの場所、および自動ワークロード・リポジトリ(AWR)データをエクスポートするかどうかを指定します。AWRエクスポートを有効にする場合、エクスポートをいつ開始するかを指定する必要があります。デフォルトでは、取得の完了後ただちに開始されます。準備ができたら、「次へ」をクリックします。図3-8のページが表示されます。
取得データが格納されるホストとファイル・システムの場所を指定します。これには、取得ファイルそのものだけではなく、導出元のRUEIファイルの記憶域、およびデータ同期情報も含まれることに注意してください。
|
重要: 取得ファイルは大量のディスク領域を必要とする場合があります。したがって、短時間の取得を実行し、それを基礎データとして使用して、計画された取得に必要なディスク領域を算出することをお薦めします。また、生成された取得ファイルは固有形式であるため、修正できないことに注意してください。 |
「ターゲットの選択」アイコンをクリックします。新しいウィンドウが開き、利用可能なターゲットが表示されます。ターゲットをクリックして選択します。選択できるホスト・ターゲットは1つのみです。「ターゲット・タイプ」メニューを使用して、ターゲットのリストを特定のタイプに制限できます。また、選択したターゲットのステータスを確認し、計画された取得の処理中、選択したターゲットが使用可能な状態となるようにしてください。選択した記憶域のホストの資格証明を指定します。準備ができたら、「次へ」をクリックします。図3-9のページが表示されます。
計画された取得の開始時間と停止時間を指定します。デフォルトでは、取得はただちに開始されます。また、デフォルトでは、取得は15分間実行されます。取得の実行期間を十分に検討し、無期限に実行するようスケジュールする場合は、定期的に取得プロセスを確認して、極端に大きな取得ファイルが作成されないようにすることを強くお薦めします。準備ができたら、「次へ」をクリックします。図3-10のページが表示されます。
|
重要: 取得が無期限に実行されるように構成している場合、「取得」ページから手動で停止する必要があります。記憶域の容量が不足しないように、作成された取得を定期的に確認することを強くお薦めします。 |
計画した取得のプロパティを実行前に確認します。必要に応じて、「戻る」および「次へ」ボタンを使用して、取得のプロパティを追加します。新しい取得を起動する準備ができたら、「発行」をクリックします。
取得が開始されると、取得プロセスを監視できるようになり、意図したトラフィックが正しく取得されていること、アプリケーション・システムが正常な状態で機能していることを確認できます。取得の進捗レポートの例を図3-11に示します。
取得の開始後、その進捗情報が確認できるようになるまでに、10分程度のリード・タイムがあることに注意してください。これは、「アプリケーション・リプレイ」ページ(図3-3)で確認できます。いずれの場合も、ボリューム、パフォーマンスおよびエラーの観点から取得の特性が詳細表示されます。このようにして、取得の品質およびテストでの有効性を評価できます。
取得プロセス中に監視されたリクエストの数は、取得の進捗を評価する上で特に役立ちます。異常に高いレベルのエラーが発生した場合は、「ジョブ」ページ(「RUEI取得ジョブ」設定をクリックすると表示される)から特定のエラーにドリルダウンできます。
ワークロードの取得をテスト・システムでリプレイできます。同じHTTPリクエストを発行できるだけでなく、同時実行性やタイミングの条件に合せて、取得の特性を再現する機能もあります。この項で説明するリプレイ・プロセスの内容は次のとおりです。
ワークロードのリプレイを適切に計画すると、リプレイの正確性が保証されます。ワークロードの取得をリプレイするには、次の手順が必要です。
テスト・システムのアプリケーション・データの状態を、ワークロードの取得の開始時における取得システムと論理的に同じにする。これについては、「アプリケーション・リプレイのテスト・システム・データベースの設定」で説明します。
外部システムへの参照がすべて解決されている。これについては、「アプリケーション・リプレイの外部システムへの参照の解決」で説明します。
リプレイとはワークロードの取得の実行(再生)であることを理解することが重要です。リプレイ・タスクとは、同じ取得に基づいてリプレイをグループ化したものです。リプレイが完了したら、リプレイ・レポートを表示してリプレイと最初の取得を比較したり、同じリプレイ・タスク内に別のリプレイを作成することができます。通常、リプレイ・タスク内のリプレイは、同じ目的を実行します。たとえば、データベースまたはホスト・システムの構成で複数のパラメータを変更するなどです。
リプレイを同じリプレイ・タスクにグループ化して、比較を容易にすることをお薦めします。たとえば、同じデータベース・アップグレード・パッチのテストに関連するリプレイを同じリプレイ・タスクにグループ化するなどです。
取得したワークロードに、データベース・リンクや外部表などの外部システムへの参照が含まれている場合があります。このような外部相互作用への参照は、リプレイ時に他の本番システムに影響が及ばないように再構成する必要があります。ワークロードのリプレイ前に解決する必要がある一般的な外部参照を表3-1に示します。
表3-1 外部システムへの参照
| タイプ | 説明 |
|---|---|
|
データベース・リンク |
通常、リプレイ・システムが他のデータベースと相互作用するのは好ましくありません。したがって、リプレイに必要なデータが含まれている適切なデータベースを指すように、すべてのデータベース・リンクを再構成する必要があります。 |
|
外部表 |
外部表から参照されているディレクトリ・オブジェクトを使用して指定されたすべての外部ファイルは、リプレイ時にデータベースおよびアプリケーション・サーバーに対して使用可能である必要があります。これらのファイルのコンテンツは、取得時と同一である必要があり、外部表の定義に使用されるファイル名およびディレクトリ・オブジェクトも有効である必要があります。 |
|
ディレクトリ・オブジェクト |
本番システムのディレクトリへの参照は、データベースのリストア後にリプレイ・システムに存在するディレクトリ・オブジェクトを適切に再定義することによって再構成する必要があります。 |
|
URL |
取得時にアクセスしたWebサービスがリプレイ時に適切なURLをポイントするよう、データベースやアプリケーション・サーバーに格納されるURL/URIを構成する必要があります。ワークロードが本番システムに格納されているURLを参照する場合、リプレイ時にそのテスト・システム・ネットワークを切り離す必要があります。 |
|
電子メール |
リプレイ時に電子メール通知が再送信されないようにするには、送信電子メールのリクエストを無視するように、リプレイ・システムにアクセス可能な電子メール・サーバーを構成する必要があります。 |
|
重要: リプレイ時に他の本番システムに影響が及ばないようにするために、リプレイは、本番環境のホストにアクセスできない切り離されたプライベート・ネットワーク内で実行することを強くお薦めします。 |
ワークロードの取得ファイル内のURLは、テスト環境でリプレイする前に、別の値に再マップする必要があります。たとえば、すべてのリクエストのWebアプリケーションURLは、テスト・システムのURLに再マップする必要があります。
再マップされるURLではワイルドカード文字はサポートされません。要求されたドメインおよびポート番号はすべて完全指定されている必要があります。
ネットワーク・トラフィックを監視しているRUEIインストールは、機密情報をログに記録しないように構成できます。これはマスキングと呼ばれ、パスワードなどの機密情報がディスクに記録されるのを防ぎます。この機能の使用方法については、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
アプリケーション・リプレイでは、マスキングされるフィールドごとに1つの値しか置換できないことを理解する必要があります。たとえば、アプリケーションのログイン・パスワードをマスキングする場合は、テスト・システム内のすべてのユーザー・アカウントに対して1つの共通の代替ログイン・パスワードを設定する必要があります。
Enterprise Managerを使用してワークロードの取得をリプレイするには、次の手順を実行します。
「エンタープライズ」メニューから、「クオリティ管理」、「アプリケーション・リプレイ」の順に選択します。図3-3のページが表示されます。
「リプレイ・タスク」セクションで、「作成」または「類似作成」をクリックします。図3-12のページが表示されます。
「取得の選択」アイコンをクリックします。新しいウィンドウが開き、リプレイ・タスクの基となる取得を選択できます。新しいリプレイ・タスクに一意の名前を指定します。オプションで、短い説明を指定します。リプレイ・タスクの目的や範囲についての説明を含めることをお薦めします。準備ができたら、「OK」をクリックします。図3-3に表示されたページに戻ります。
新しく作成されたリプレイ・タスクをクリックします。図3-13のページが表示されます。
リプレイの名前を指定します。これは選択したリプレイ・タスク内で一意にする必要があります。オプションで、リプレイするトラフィックに簡単な説明を指定します。リプレイの目的や範囲についての説明を含めることをお薦めします。必要な情報を十分に確認し、必要な情報が満たされていることを示すために「確認」チェック・ボックスを選択します。準備ができたら、「システム」をクリックします。図3-14のページが表示されます。
「システムの選択」アイコンをクリックし、取得をリプレイするテスト環境を表すターゲットを選択します。選択したコンポーネントのステータスを確認し、計画されたリプレイの処理中はそれらが使用可能な状態となるようにしてください。準備ができたら、「取得の記憶域の資格証明」をクリックします。図3-15のページが表示されます。
選択した記憶域のホストの資格証明を指定します。準備ができたら、「リプレイ・クライアント」をクリックします。図3-16のページが表示されます。
テスト・システム上でワークロードの生成に使用するリプレイ・クライアントを指定します。計画されたリプレイのスケール変更には、提示された推定数を基礎データとして使用してください。取得ファイルおよびリプレイ結果の格納に使用するファイル・システムの場所を指定します。この場所は、共有ファイル・システム上にあり、リプレイ・クライアント・ホストおよびデータベース・ホスト(同期化が有効な場合)がまったく同じファイル・ディレクトリ・パスを使用してアクセスできる必要があります。準備ができたら、「同期化」をクリックします。図3-17のページが表示されます。
リプレイ時にデータベースの同期化を有効にするかどうかを指定します。有効にする場合は、関連するデータベースおよびホストの資格証明を提示する必要があります。準備ができたら、「URLマッピング」をクリックします。図3-18のページが表示されます。
リプレイ時に使用するURLマッピングを指定します。つまり、取得時に出現したURLをテスト環境でリプレイする際に置換する方法を指定します。準備ができたら、「マスキングされたデータの置換え」をクリックします。図3-19のページが表示されます。
RUEIは、機密情報(パスワード、クレジット・カード情報など)のログをディスクに記録しないように構成できます。これらのフィールドの値は記録されないため、リプレイでは明示的に指定する必要があります。準備ができたら、「追加のリプレイ・パラメータ」をクリックします。図3-20のページが表示されます。
リプレイの進行速度を元の取得と同じにするか、または変更するかを指定します。後者の場合は、適切なセッション開始時間のスケールおよび思考時間のスケールを指定し、さらに元のリクエスト率を維持するかどうかを指定する必要があります。「リプレイの拡張パラメータ」セクションを展開し、標準の拡張設定に標準値またはカスタム値のいずれを使用するか指定します。準備ができたら、「スケジュール」をクリックします。図3-21のページが表示されます。
リプレイの開始時間を指定します。次に、「確認」をクリックします。
計画されたリプレイのサマリーが表示されます。必要に応じて、「戻る」および「次へ」ボタンを使用して、セクション間を移動します。準備ができたら、「送信」をクリックしてリプレイを開始します。
「アプリケーション・リプレイ」ページで選択したリプレイをクリックすると、その詳細情報が表示されます。リプレイの概要の例を図3-22に示します。
これは次の3つに分かれています。
ホーム: リプレイ、関連付けられたリプレイ・タスク、および基礎となる取得の概要が表示されます。リプレイの進捗および元の取得との比較も表示されます。
結果: リクエスト相違のより詳細な情報が表示されます。これには、元の取得とリプレイのページ・パフォーマンスの比較や、最も高いレベルの相違を示したアプリケーション・ページなどが表示されます。
例を図3-23に示します。
このセクション内の「ページ分析」セクションでは、選択したメトリック全体について各アプリケーション・ページを分析できます。「相違」セクションでは、特定の相違のタイプ(アクセス、コンテンツなど)に限定した情報を表示できます。「グラフ」セクションでは、特定のメトリック(平均ページ・ロード時間など)全体の詳細なリプレイ情報を表示できます。
確認: リプレイ環境(資格証明、ホスト、リプレイ・クライアントなど)およびリプレイ時に使用したURLマッピングとマスキング・データの置換に関する情報が表示されます。
Oracle Application Testing SuiteのOpenScriptモジュールを使用すると、セッションごとに表示して相違エラーをさらに分析できます。現在のアプリケーション・リプレイは、相違統計を計算して、ページごとに表示します。Enterprise Managerでは、このセッション・データを.zipファイルにエクスポートし、このデータをOpenScriptにインポートできます。
セッション.zipファイルの作成
Enterprise Managerから生成されるセッション.zipファイルには、取得データおよびリプレイ・データが含まれています。
.zipファイルを作成する手順:
リプレイの相違ページに移動します。
表示する「モード」として「セッション別のビュー」を選択します。
「セッション」リストで、相違(「相違」列に表示されます)を含むセッションIDをクリックします。「セッションの相違の詳細」ダイアログが表示されます。
「ページ」リージョンで、「フェッチ・ページ詳細」をクリックします。
「セッション・データのエクスポート」リージョンで、「エクスポート」をクリックします。
エクスポート操作が完了すると、セッション・データ.zipファイルへのリンクが表示されます。
リンクをクリックして、セッション・データ.zipファイルをダウンロードし、ファイルをローカル・システムに保存します。
OpenScriptへのセッション.zipファイルのインポート
取得およびリプレイ・データを含む.zipファイルを作成した後、このデータをOpenScriptにインポートする必要があります。
.zipファイルの内容をインポートする手順:
OpenScriptから、次に負荷テスト・スクリプトを作成する必要があります。
「file」メニューから、「新」を選択します。「新規プロジェクト」ダイアログ・ボックスが表示されます。ここから、ウィザードを選択して新しい負荷テスト・スクリプトを作成できます。
ツリー・リストから、アプリケーション・タイプを選択して、「次」をクリックします。「新規スクリプト」ダイアログが表示されます。
スクリプト名を入力して「終了」をクリックします。OpenScriptは新しいスクリプトを作成します。
OpenScriptの「ツール」メニューから、「Oracle Real User Experience Insight (RUEI)セッション・ログのインポート」を選択します。RUEIログのインポートダイアログが表示されます。
「参照」をクリックします。RUEIログを開くダイアログが表示されます。
以前に作成したセッション.zipファイルに移動して、ファイルを選択し、「開く」をクリックします。
「OK」をクリックします。
この項では、ワークロードの取得時およびリプレイ時によく発生する問題の対処方法について説明します。Oracle SupportのWebサイトで、既知の問題および回避策について確認することもお薦めします。次のサイトを参照してください。
https://support.oracle.com
RUEIインストール
ワークロードの取得時にアプリケーションを監視するRUEIインストールが、次の要件を満たしていることを確認します。
Oracle SupportのWebサイトで、サポートされているバージョンと必要なホット・フィックスについて確認する。
目的のアプリケーションを監視するようにRUEIが構成されていることを確認します。デプロイメント・オプションおよび要件については、『Oracle Real User Experience Insightインストレーション・ガイド』を参照してください。
ユーザー名とパスワードの有効な組合せを保持していることを確認します。必要に応じて、RUEIの管理者に連絡してください。ユーザー・アカウントにはセキュリティ責任者の権限が付与されている必要があります。ロールと権限の詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
フル・セッション・リプレイ(FSR)機能が有効になっており、取得が計画されているアプリケーションごとに十分な記憶域が割り当てられていることを確認します。各アプリケーションのデータ・リプレイのロギング設定およびマスキング設定が、FSRで使用する場合と一致していることも確認する必要があります。詳細は、『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
静的なSSL証明書を使用するようにWebサーバーが構成されていることを確認する。RUEIでは動的なSSL証明書がサポートされていないため、これが必要になります。
アプリケーションでジャンボ・フレームを使用する場合は、RUEIレポータ・システム上でrootユーザーとして次のコマンドを実行し、RUEIの取得サイズをデフォルトの2KBから64KBに増やします。
execsql config_set_profile_value wg System config CaptureLength replace 65536
取得のチェックリスト
前述の要件の他に、次の点も確認する必要があります。
RUEIが適切なロギングおよびマスキング・ポリシーを使用して、必要なトラフィックを正常に取得している。構成の検証の詳細は、次のサイトで入手可能な『Oracle Real User Experience Insightユーザーズ・ガイド』を参照してください。
http://www.oracle.com/technetwork/documentation/realuserei-091455.html
データベース・ホストのユーザーIDが、Enterprise Managerエージェントのユーザー・アカウントと同じグループに属している。
リプレイのチェックリスト
前述の要件の他に、次の点も確認する必要があります。
必要なURLがすべて正しく再マッピングされている(3.8.4項「アプリケーション・リプレイのURLの再マッピング」を参照)。テスト・システムがHTTPまたはHTTPSとして構成されているかどうかチェックし、Webサーバーのドメイン名と関連するポート番号を確認します。また、ホスト名だけでなく、完全ドメイン名がURLに指定されていることを確認します。
取得したワークロードを本番環境ではリプレイしないことを強くお薦めします。
取得時にマスキングされた機密データの全フィールドに、置換値が設定されていることを確認する。これについては、第3.8.5項「アプリケーション・リプレイの機密データでの代用」で説明します。
