| Oracle® Enterprise Manager Cloud Control Middleware管理ガイド 13c リリース3 E98558-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
アプリケーション・リプレイでは、テスト・システム上に本番のワークロード環境を再作成することにより、アプリケーション・サーバーからディスクに至るまでアプリケーション・スタック全体を対象に、計画された変更の現実的なテストが可能です。アプリケーション・リプレイを使用すると、本番システム上でワークロードを取得し、テスト・システムでオリジナルのワークロードの正確なタイミング、同時実行性およびトランザクション特性を使用して、それをリプレイできます。これにより、変更の影響(望ましくない結果、新しい競合ポイント、計画の品質低下など)を詳細に評価できます。また、広範な分析およびレポートを利用して、新しく発生したエラーやパフォーマンスの相違など、起こりうる問題の特定に役立てることができます。アプリケーション・リプレイでテスト可能な変更には、アプリケーション・サーバーのアップグレード、ハードウェアの更新、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のロギングおよびマスキング・ポリシーを前述のように構成する必要があります。
これらの構成手順の詳細は、Oracle Real User Experience Insightユーザーズ・ガイドのセキュリティ関連情報の管理を参照してください。
アプリケーション・リプレイ機能のユーザーには、次の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つ以上のリプレイ・クライアントが、同時実行性やリクエストのタイミングといった元のプロパティを維持しつつ、取得したワークロードを再現します。さらに、アプリケーション・リプレイ機能では同期化を使用して、リプレイされた各リクエストが取得時とまったく同じアプリケーション状態で処理されるため、レスポンスを直接比較できます。最後に、スタックのすべての層からパフォーマンス・データおよび検証データを大量に収集して、リプレイとその基礎となる元の取得が比較できるようになります。
ワークロードの取得のボリュームと同時実行性によっては、複数のリプレイ・クライアントをデプロイして、それぞれにワークロードの一部を割り当てる必要があります。リプレイを計画する際には、取得したワークロードによって必要なリプレイ・クライアント数の推奨を受けることができます。
アプリケーション・ワークロードの取得を作成するには、次の手順を実行します。
「アプリケーションの表示」をクリックして、指定したRUEIデプロイメントによって現在モニターされているアプリケーションを表示します。各アプリケーションのトラフィック情報を使用して、アプリケーションが取得に適切であるかを確認できます。特に、取得に含めるアプリケーションを選択する際は、アプリケーションが実行されていること、トラフィックのボリュームおよびエラー・レベルが許容範囲内にあることを確認してください。準備ができたら、「次へ」をクリックします。図3-7のページが表示されます。
図3-7 「取得の作成(データベース)」ページ
注意:
取得ファイルは大量のディスク領域を必要とする場合があります。したがって、短時間の取得を実行し、それを基礎データとして使用して、計画された取得に必要なディスク領域を算出することをお薦めします。また、生成された取得ファイルは固有形式であるため、修正できないことに注意してください。
「ターゲットの選択」アイコンをクリックします。新しいウィンドウが開き、利用可能なターゲットが表示されます。ターゲットをクリックして選択します。選択できるホスト・ターゲットは1つのみです。「ターゲット・タイプ」メニューを使用して、ターゲットのリストを特定のタイプに制限できます。また、選択したターゲットのステータスを確認し、計画された取得の処理中、選択したターゲットが使用可能な状態となるようにしてください。選択した記憶域のホストの資格証明を指定します。準備ができたら、「次へ」をクリックします。図3-9のページが表示されます。
注意:
取得が無期限に実行されるように構成している場合、「取得」ページから手動で停止する必要があります。記憶域の容量が不足しないように、作成された取得を定期的に確認することを強くお薦めします。
取得が開始されると、取得プロセスを監視できるようになり、意図したトラフィックが正しく取得されていること、アプリケーション・システムが正常な状態で機能していることを確認できます。取得の進捗レポートの例を図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-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ファイルの内容をインポートする手順:
この項では、ワークロードの取得時およびリプレイ時によく発生する問題の対処方法について説明します。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がすべて正しく再マッピングされている(「アプリケーション・リプレイのURLの再マッピング」を参照)。テスト・システムがHTTPまたはHTTPSとして構成されているかどうかチェックし、Webサーバーのドメイン名と関連するポート番号を確認します。また、ホスト名だけでなく、完全ドメイン名がURLに指定されていることを確認します。
取得したワークロードを本番環境ではリプレイしないことを強くお薦めします。
取得時にマスキングされた機密データの全フィールドに、置換値が設定されていることを確認する。これについては、「アプリケーション・リプレイの機密データでの代用」で説明します。
