3 インライン・サービスに対する負荷のシミュレート

この章のチュートリアルでは、ロード・ジェネレータを使用してシステムのランタイム操作をシミュレートする手順について説明します。

一般的にロード・ジェネレータは、次の3つの目的で使用されます。

• パフォーマンスのチェック: 負荷がかかったときのシステムのパフォーマンスを検証します。レスポンス時間を測定したり、バックエンド・データの入力時などにおいてシステム全体が想定負荷に対応できることを確認します。

• 初期化: 重要なデータを使用して、デモ目的で学習機能および統計機能を初期化します。

• データ処理: オフラインのバッチ・ソースを処理します。たとえば、プロジェクトの初期段階に、以前に収集したデータの分析を行います。

この章には次のトピックが含まれます:

• 第3.1項「負荷下のパフォーマンス」

• 第3.2項「モデルの学習内容のリセット」

3.1 負荷下のパフォーマンス

負荷がかかったときのパフォーマンスを評価するために、インライン・サービスに定義されている統合点(Begin Call、Service CompleteおよびCall End)をコールする負荷シミュレーション・スクリプトを作成します。スクリプトでは、顧客ID、通話理由コード、エージェント名および通話の長さを毎回変えて、これら3つの連続する統合点を複数回コールします。この反復実行ごとにReason Analysisモデルで学習が行われ、その分析結果をデシジョン・センター・レポートにおいて参照できます。

このチュートリアルでは、ロード・ジェネレータをCRMアプリケーションのシミュレーション・プログラムとして扱い、Real-Time Decision Serverに対して統合点のコールを反復実行します。作成するロード・ジェネレータ・スクリプト(xmlファイルとして保存)には、このシミュレーションの定義が記述されます。

注意: ロード・ジェネレータ・スクリプトを定義するときは、インライン・サービス・オブジェクトへのすべての参照を、ラベルではなく、オブジェクトIDの形式で記述する必要があります。StudioでオブジェクトIDを表示するには、「インライン・サービス・エクスプローラ」タスクバーにあるオブジェクトID用「トグル」アイコンを使用します。 たとえば、Service CompleteインフォーマントのIDはServiceCompleteで、reason codeインフォーマント・パラメータのIDはreasonCodeです。他も同様です。

この項には次のトピックが含まれます:

• 第3.1.1項「ロード・ジェネレータ・スクリプトの作成」

• 第3.1.2項「デシジョン・センターにおける分析結果の表示」

• 第3.1.3項「属性の除外」

3.1.1 ロード・ジェネレータ・スクリプトの作成

注意: ロード・ジェネレータなどのクライアント側ツールを実行するには、JAVA_HOMEを設定する必要があります。詳細は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のOracle RTDクライアント・ツールに必要なJava Development Kitのインストールに関する項を参照してください。

ロード・ジェネレータ・スクリプトを作成する手順は次のとおりです。

1. RTD_HOME\scripts\loadgen.cmdを実行することで、ロード・ジェネレータを開きます。次に、「新規ロード・ジェネレータ・スクリプトを作成します」をクリックします。

   [F1]キーを押すと、ロード・ジェネレータのオンライン・ヘルプを参照できます。オンライン・ヘルプでは、このチュートリアルに説明されていないパラメータが説明されています。

2. 「一般」タブを選択し、表3-1に示されているパラメータの値を入力します。

   表3-1 「一般」タブのパラメータ

   パラメータ名	説明	値
   クライアント構成ファイル	サーバーとの通信に使用するプロトコル、接続先サーバーおよび使用するポートを指定するプロパティ・ファイル。デフォルトでは、HTTPを使用して、ローカル・サーバーとポート8080で通信します。ファイル内のHTTP1.urlパラメータを、使用するRTDサーバーとポートの値に更新してください。たとえば、http://wlsserver1.company.com:9704など。	RTD_HOME\client\clientHttp EndPoints.properties
   グラフ・リフレッシュ間隔(秒)	このパラメータはユーザー・インタフェースにのみ影響します。このパラメータにより、UI上のグラフおよびカウンタのリフレッシュ間隔を指定します。デフォルトは2秒間隔のリフレッシュです。	2
   インライン・サービス	前の項で作成したインライン・サービスに割り当てた名前。	Tutorial
   ランダム数値ジェネレータ・シード	ランダムな数値の生成に使用するシード。デフォルトは-1です。	-1
   思考時間	複数のトランザクション間における時間。セッション指向の負荷シミュレーションでは、必要に応じて異なる値を指定します。このチュートリアルでは、可能なかぎり多くのセッションを送信し、最大スループットを調べます。思考時間のタイプは、「固定グローバル思考時間」または「範囲指定されたグローバル思考時間」のいずれかです。	グローバルな思考時間を指定する固定値
   定数	思考時間のタイプを「固定グローバル思考時間」に設定した場合、パラメータ「定数」が表示されます。これはトランザクション間の待機時間(秒数)です。「0」の場合、RTD Decision Serverが統合点リクエストを処理可能になり次第、ロード・ジェネレータはただちにリクエストをDecision Serverに送信する必要があることを意味します。	0
   実行する同時スクリプトの数	並行して実行することで、同時にアクティブになるセッションの数。このシミュレーションでは、一度に1セッションのみを実行します。	1
   実行するスクリプトの最大数	作成されるセッションの合計数。この数値に達した時点で、イベントの送信が停止します。	2000
   ロギングの有効化	loadgenカウンタ・ログを有効化/無効化するオプション。このログには、loadgenのパフォーマンス・データ(ロード・ジェネレータによって送信されたリクエストの数、エラーの数、リクエストの平均レスポンス時間およびピーク時のレスポンス時間など)の履歴が記録されます。このチェック・ボックスの選択が解除されている場合は、残りの3つのログ関連パラメータ(「既存のファイルへ追加」、「ログ・ファイル」および「ロギング間隔」)は無視されます。	選択解除
   既存のファイルへ追加	loadgenスクリプトを実行するたびに既存のログ・ファイルを上書きするか追加するかを指定するオプション。	選択解除
   ログ・ファイル	asciiファイルへのファイル・パス。ロード・ジェネレータのログが、タブ区切りの書式で書き込まれる場所です。	RTD_HOME\log\loadgen.csv
   ロギング間隔	このパラメータはロード・ジェネレータのログにのみ影響します。このパラメータにより、ログへの書込み間隔を指定します。デフォルトは10秒です。	10

   
   

   パス名内のRTD_HOMEは、Oracle RTDクライアント側ツールがインストールされている場所に置き換えてください。

   セッションに関連するパラメータは、実行中に変更できないことに注意してください。正確に言うと変更は可能ですが、ロード・ジェネレータ・スクリプトが停止して再起動されるまで、変更は実行に影響しません。

3. 構成を保存します。ファイルをインライン・サービスのプロジェクト・フォルダ内にあるetcフォルダに保存することにより、インライン・サービスに対して作成したLoadgenスクリプトを同じプロジェクトにバンドルできます。Tutorialインライン・サービスをデフォルトのワークスペースに作成した場合、このパスはC:\Documents and Settings\Win_User\Oracle RTD Studio\Tutorial\etcのようになります。スクリプト(xmlファイル)に任意の名前を付けます(たとえば、TutorialLoadgen.xmlなど)。

4. 統合点に対するパラメータの値を定義するには、「変数」タブをクリックします。「変数」タブにより、統合点の各パラメータ値を、それぞれ異なるソースから取得できます。

   
   

   注意: すべてのツリーが左側に表示されていない場合があります。すべてのツリーを表示するには、バーをドラッグして、2つの領域に分割します。

   
   

5. 「スクリプト」フォルダを右クリックし、「変数の追加」を選択します。名前をvar_customerIdにします。「コンテンツ」で、「整数範囲」を選択し、1から2000までの順次実行を指定します。この定義によって、各セッションで一度処理され、1から2000まで順次実行される変数が作成されます。したがって、最初のセッションではvar_customerId = 1となり、最後のセッションでは2000となります。「スクリプト」を右クリックし、「変数の追加」をさらに3回選択して、表3-2に示すように4つの変数を定義します。

   表3-2ロード・ジェネレータ・スクリプトの変数の名前と値

   パラメータ名	コンテンツ・タイプ	値
   var_customerId	整数値の範囲	最小 = 1、最大 = 2000、アクセス・タイプ = 順次
   var_reasonCode	整数値の範囲	最小 = 17、最大 = 20、アクセス・タイプ = ランダム
   var_agent	文字列配列	文字列を配列に追加するには、表領域を右クリックし、「項目の追加」を選択します。次に、新しく作成された行を選択(ダブルクリック)してカーソルを取得し、使用する名前を入力します。[Enter]キーを押して、新しい行の値を登録します。エージェント名として、いくつかのサンプル値(John、Peter、Mary、Saraなど)を追加します。
   var_length	整数値の範囲	最小 = 75、最大 = 567、アクセス・タイプ = 順次 この値は秒単位で、通話の長さとして使用されます。

   
   

6. 「スクリプトの編集」タブを選択し、左側の領域を右クリックして「アクションの追加」を選択します。それぞれが1つの統合点に対応する3つのアクションを追加します。アクションは適切な順序(つまりCallBegin、ServiceComplete、CallEndの順)にする必要があります。

7. 最初のアクションに対して、タイプを「メッセージ」に、統合点の名前をCallBeginにそれぞれ設定します。「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」の下のスペースをダブルクリックして値customerIdを入力し、[Enter]を押して新しい値を登録します。customerIdに対応する「変数」列で、ドロップダウン・リストから「var_customerId」を選択します。「セッション・キー」を選択し、このフィールドをセッション・キーとして指定します。

8. ServiceCompleteアクションに対して、表3-3に示されているように、3つのフィールドを追加します。

   表3-3 ServiceComplete用の追加入力フィールド

   名前	変数
   reasonCode	var_reasonCode
   agent	var_agent
   length	var_length

   
   

   フィールド名は、デシジョン・スタジオに表示されるServiceCompleteインフォーマントの入力パラメータIDと完全に一致する必要があります。オブジェクトのラベルとそのオブジェクトIDとの間における表示を切り替えるには、デシジョン・スタジオの「インライン・サービス・エクスプローラ」タスク・バーにある「トグル」アイコンを使用します。

   
   

   図3-1は、ServiceComplete用に設定が完了した「入力フィールド」セクションを示しています。

   図3-1 ServiceComplete用の入力フィールド

   
   「図3-1 ServiceComplete用の入力フィールド」の説明
   
   

9. 「スクリプトの編集」タブで、左側の領域を右クリックして「アクションの追加」を選択します。タイプを「メッセージ」に、統合点の名前をCallEndにそれぞれ設定します。「入力フィールド」で右クリックして「項目の追加」を選択し、入力フィールドを追加します。「名前」をcustomerIdに、「変数」をvar_customerIdにそれぞれ設定し、「セッション・キー」を選択します。

10. 「セキュリティ」タブで、「ユーザー名」と「パスワード」を入力します。

11. 再びロード・ジェネレータ構成スクリプトを保存します。この時点で、ロード・ジェネレータ・スクリプトに、3つの統合点へのコールが定義されます。「スクリプトの編集」タブにおけるアクションの順序が正しいこと(つまり、CallBegin、ServiceComplete、CallEndの順になっていること)を確認します。この順序でない場合は、各アクションを右クリックして、上下に移動します。スクリプトを再び保存します。

12. 「実行」タブに移動し、「再生」ボタンを押します。ロード・ジェネレータにおいてスクリプトの実行が完了するまで待ちます。

    
    

    「一時停止」ボタンと「停止」ボタンがあることに注意してください。両者の違いは、「一時停止」では順次実行が記憶され一時停止した箇所から再開するのに対して、「停止」では完全にリセットされる点にあります。

    
    

    ヒント: 問題が発生した場合、「実行」タブの「エラー合計」を調べます。この値が0よりも大きい場合は、クライアント側とサーバー側のログ・ファイルを調べます。ログ・ファイルに問題の内容が記録されている場合があります。 クライアント側のログは、ディレクトリRTD_HOME\logにあります。例: RTD_HOME\log\client.log.0 サーバー側のメッセージへのアクセス方法は、『Oracle Fusion Middleware Oracle Real-Time Decisions管理者ガイド』のサーバー側ログ・ファイルの検索と表示に関する項を参照してください。 サーバー側のメッセージは、WebLogic Serverの診断ファイルに記録されています。例: <mw_home>\user_projects\domains\bifoundation_domain\servers\bi_server1\logs\bi_server1-diagnostic.log 一般的な間違いは次のとおりです。 インライン・サービスがデプロイされていない。 インライン・サービスや統合点の名前に、スペルの間違いや大文字と小文字の間違いがある。 サーバーが実行していない。 「リクエスト合計」の値が1から増えていない場合、loadgenスクリプトの定義に間違いがある可能性があります。次の点を調べてください。 「整数範囲」の変数で、最小値が最大値よりも小さいこと。 メッセージで送信される変数への値のマッピングが正しいこと。たとえば、変数名を変更した場合は、そのマッピングをやりなおす必要があります。 クライアント構成ファイルが正しいこと。

    
    

3.1.2 デシジョン・センターにおける分析結果の表示

ロード・ジェネレータの実行後に、デシジョン・センターを使用すると、モデルの学習結果を参照できます。その手順は次のとおりです。

1. Webブラウザを起動してURLにhttp://server_name:9704/uiを指定して、デシジョン・センターを起動します。第2.2項「デプロイおよびデシジョン・センターのセキュリティについて」に説明されているように、提供されているユーザー名とパスワードを使用してログインします。

2. 「インライン・サービスを開く」をクリックします。「インライン・サービスの選択」ウィンドウが表示されます。「Tutorial」を選択し、「Call Reason」を展開して「Make Payment」などの選択肢を1つ選択します。右側のペインで、「分析」タブ→「最適」サブタブにナビゲートします。このレポートには、この通話理由が該当した回数と、このコール理由と各属性値間の相関関係に関する要約がそれぞれ記載されます。

   興味深いデータが表示されます。図3-2に示されているように、call reason codeとMake Paymentとの間に、予想外に強い相関関係があります。

   図3-2 Make Paymentと相関関係がある属性の値

   
   「図3-2 Make Paymentと相関関係がある属性の値」の説明
   
   

   通話データはロード・ジェネレータ変数によってランダムに生成されているため、強い相関関係は想定範囲にありません。ただし、ここでは、通話理由コード(ServiceCompleteインフォーマントによって送信される)が、この通話理由に大きく関係しています(ロジックの詳細は、第2.9.5項「全体のテスト」を参照)。

   この誘発的な相関関係を解消するには、この属性がモデルへの入力として使用されないように除外します。モデルから除外する属性の別のタイプとして、顧客の電話番号があります。個々の電話番号と通話理由との間には、特定の相関関係が存在する可能性は低いです。一方、顧客の地域コードと通話理由との間には相関関係が存在する場合があるため、この属性はモデルから除外しません。次の項では、通話理由コードの属性をモデルから除外し、ロード・ジェネレータ・スクリプトを再び実行します。

3.1.3 属性の除外

reason code属性を除外する手順は次のとおりです。

1. デシジョン・スタジオで、Tutorialプロジェクトを開きます。

2. 「インライン・サービス・エクスプローラ」から「サーバー・メタデータ」→「モデル」 を開き、「Reason Analysis」をダブルクリックします。

3. 「属性」タブに移動します。下側にある表(表のタイトルは「除外された属性」)で、「選択」をクリックし除外する属性を選択します。「セッション」ノード→「call」エンティティを開き、「reason code」を選択します。「OK」をクリックします。

4. すべてを保存し、localhostサーバーに再デプロイします。

5. ロード・ジェネレータ・スクリプトを再び実行できます。

再実行後にデシジョン・センターを使用してカウントの値を調べると、ロード・ジェネレータを2回実行したときのイベントが含まれています。これは、ロード・ジェネレータ・スクリプトを属性除外前に実行してから属性除外後に実行する前にモデルをリセットしていないためです。

3.2 モデルの学習内容のリセット

次に示すように、モデルの学習内容をリセットするには、Enterprise Managerを使用します。

1. 自分のユーザー名とパスワードを使用してEnterprise Managerにログインします。

2. 左側のナビゲーション・ペインで、「アプリケーションのデプロイ」エントリを開いて、「OracleRTD」を表示します。

3. 「OracleRTD」エントリを右クリックして「システムMBeanブラウザ」を選択します。

4. 表示される「システムMBeanブラウザ」ナビゲーション・ペインで、「アプリケーション定義のMBean」まで下にスクロールします。

5. 「アプリケーション定義のMBean」の下の「OracleRTD」を開き、Oracle RTDがデプロイされているサーバーを開きます。

6. 「InlineServiceManager」を開き、「Tutorial.Development」エントリを選択します。

7. 「操作」タブをクリックし、deleteAllOperationalData操作を使用して、このインライン・サービスのすべての操作データを、スタディも含めて削除します。

8. 新しい分析結果をデシジョン・センターで参照するために、ロード・ジェネレータ・スクリプトを再び実行します。

3.2.1 インライン・サービスの要約

これまで、単純ですが完全な機能を持つインライン・サービスを作成しました。それには、データ環境、データ・ソースおよび顧客エンティティの定義から始めて、現在の通話データのエンティティを定義しました。基本的な機能をテストした後、分析実行用の統合点とモデルを作成しました。顧客の通話理由を調べて通話理由の発生回数を記録するロジックを、モデルに分析目的で追加しました。次に、ロード・ジェネレータを使用して、Real-Time Decision ServerおよびTutorialインライン・サービスに対するリクエストをシミュレートしました。最後に、結果をデシジョン・センターに表示しました。