Cisco Unified Customer Voice Portal(CVP)ソリューション リファレンス ネットワーク デザイン(SRND)リリース 9.0(1)
サイジング
サイジング
発行日;2012/11/27   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

サイジング

 

この章では、注文する物理マシンの数の決定方法、およびゲートウェイの場合は注文するタイプの決定方法について説明します。

この章では、次のトピックについて取り上げます。

新規または変更された章の情報

次の表に、この章に新しく追加されたトピック、またはこのマニュアルの以前のリリースから大幅に改訂されたトピックの一覧を示します。

 
表 1 新規情報、またはこのマニュアルの以前のリリースからの変更情報

新規トピックまたは改訂されたトピック

説明

この章には、SRND の 2012 年 7 月 6 日のバージョンに関する新規トピックはありません。

概要

コンタクトセンターをサイジングする場合、最初に、各状態におけるコール数の観点から最悪の場合のコンタクトセンター プロファイルを決定します。 つまり、最も煩雑する時間に、最も煩雑するインスタンスでコンタクトセンターを監視しなければならない場合に、次のぞれぞれの状態でのコール数を確認します。
セルフ サービス

Unified CVP VXML Server を使用してアプリケーションを実行するコール

キューとコレクト

エージェントのキューに入っているコール、またはプロンプト/コレクト タイプのセルフ サービス アプリケーションを実行するコール

トーキング

エージェント、またはサードパーティの TDM VRU アプリケーションに接続されるコール

トーキング状態のコール数をカウントする場合、Unified CVP またはゲートウェイのリソースを使用しているコールのみをカウントします。 トーキング コールがリソースを使用しているかどうかを判別するには、コールがその VRU またはエージェントにどのように転送されるかを考慮する必要があります。 VoIP を使用して転送されたコールの場合は、入力ゲートウェイ ポートおよび Unified CVP のリソースを使用し続けます。これは、Unified CVP がコールを継続してモニタし、そのコールを取得して後で再配信する機能を提供するためです。 入力と出力の TDM ポートの両方を同じゲートウェイまたは異なるゲートウェイ(つまり、トール バイパス)で使用して TDM ターゲットにトロンボーニングされるコールにも、同じことが当てはまります。 この方法で VRU またはエージェントに転送されるコールは、トーキング コールとしてカウントされます。

ただし、コールが *8 TNT、フックフラッシュ、Two B Channel Transfer(TBCT)、または ICM NIC を介して転送された場合、ゲートウェイと Unified CVP のいずれもこのコールでは何の役割も果たしません。 両方のコンポーネントはそれぞれのリソースを回収したため、このようなコールはトーキング コールとしてカウントされません。

最後に、キューイングやセルフサービスのために、ブラインドまたはウォームのいずれかの転送方法を使用して Unified CVP に戻されたコールは、コールの全体カウントに含めます。 たとえば、ウォーム転送が使用され、エージェントが Unified CVP でポストルート フェーズ時にキューイングされた場合、このコールは、Unified CVP に 2 つの個別呼制御セッションがあるため、2 つのポートを使用します。 これらのコールは、通常、その量がコール ボリューム全体の 5% または 10% を超えることはないため、見落としがちです。

これらのコールの状態の定義は、ポート ライセンシングの目的で使用される定義とは若干異なります。 Automatic Speech Recognition(ASR; 音声自動認識)または Text-To-Speech(TTS; 音声合成)の使用は、どのコールがどの状態にあるかを定義するのには関係しませんが、ライセンシング目的の場合は関係します。 同様に、コール状態の判別は、エージェントが Unified CCE エージェントであるか ACD エージェントであるかには関係ありません。また、ユーザが Unified CVP を使用してコールを取得し、そのコールを別のエージェントに再配信したりセルフサービスに戻したりするかどうかも関係ありません。


(注)  


ソリューションは、トーキング状態のコールをエージェントに転送するために使用するポート数に応じてサイジングする必要があります。 Unified CCE エージェントを使用する場合はこれらのポートのライセンスは必要ありませんが、TDM エージェントにはコール ディレクタのライセンスが必要となります。


コンタクトセンターのコールの全体的なスナップショット プロファイルに加えて、最もビジーな期間のコール到着率を 1 秒当たりのコール数で考慮する必要もあります。 コンタクトセンター全体に関するこの情報が必要です。 正確な最大到着率を特定するのは難しいため、統計的手法を使用してこの数値を割り出すことができます。 非常に小規模な実装を除き、これがサイジング決定の重要な要因となることはほとんどありません。

上記のデータを使用して、ネットワーク内の各コンポーネントのサイジングを開始できます。 この項では、次に Unified CVP 製品(Unified CVP コール サーバと Unified CVP VXML Server)について検討した後、Unified CVP Reporting Server について検討します。 この項では、Unified CVP システムをサポートするために必要な物理コンポーネントの数およびタイプのみを取り上げ、冗長性については説明していません。 これらの数を増やして信頼性を高める方法については、ハイアベイラビリティのための Unified CVP 設計を参照してください。


(注)  


Unified CVP 9.0(1) では、コール サーバ、VXML Server、およびメディア サーバは、1 つのインストールとして統合されます。 CVP Server をインストールすると、3 つすべてのコンポーネントがインストールされます。 以前のバージョンでは、コール サーバ、VXML Server、およびメディア サーバは、異なるマシンにインストールできました。


Unified CVP Co-Residency


(注)  


次のコール率計算は、MCS-7845-I3-CCE2 サーバに関するものです。


次のコンポーネントは、1 つの物理サーバにインストールできます(共存)。

  • Unified CVP コール サーバ(コール サーバ)
  • Unified CVP VXML Server(VXML Server)
  • メディア サーバ

SIP ベースの共存サーバでは、1200 の SIP コールと 1200 の VXML Server セッションを同時に処理でき、1 秒当たり 14 コールの平均コール到着率を処理できます。


(注)  


これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 のポートと、VXML Server の 1200 のポートを 1 台のサーバ上で実行できることを意味します。


必要となる Unified CVP コール サーバの数は、次のうちの大きいほうです。

((セルフ サービス) + (キューとコレクト) + トーキング) / 1200、切り上げ

または

(平均コール到着率) / 14、切り上げ、VRU のみのモデルの場合を除く

プロンプト キャッシングが VoiceXML ゲートウェイで有効になっていることを想定した場合、共存メディア サーバを使用して、最大で 1200 のコールを処理できます。 複数の共存サーバを使用する場合、コールの負荷をこれらのすべてのサーバに分散するために、共存メディア サーバ全体でロード バランシングを行う必要があります。 複数のメディア サーバでのコンテンツ管理の管理オーバーヘッドを減らすために、個別の専用メディア サーバを使用できます。

これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 ポートと、VXML Server の 1200 のポートをすべて 1 台のサーバ上で実行できることを意味します。

たとえば、現在の展開を、1200 のセルフサービス ポート、500 のキューとコレクト ポート、およびエージェントへの 3700 の同時コール用にサイジングするとします。


(注)  


上記の定義例で、セルフサービスは、コールが SIP コール制御を必要とし、VXML Server でアプリケーションを実行することを意味します。 キューとコレクトは、コールが SIP コール制御を必要とし、マイクロアプリケーションのみをコール サーバ上で使用してアプリケーションを実行することを意味します。


次の例は、VoiceXML セッションおよび HTTP セッションだけに適用されます。 同じ値が、コール サーバと VXML Server の共存展開と分散型展開の両方に適用されます。

SIP 呼制御を使用するサーバの必要数は、次のようになります。

((セルフ サービス) + (キューとコレクト) + トーキング) / 1200、切り上げ

(1200 + 500 + 3700) / 1200 = 5 サーバ

フロースルー コールに対して Cisco Unified Border Element をセッション ボーダー コントローラ(SBC)として使用し、VoiceXML 要件を処理する場合は、上記で示しているサイジング情報を使用する必要があります。 特定の状況およびハードウェア プラットフォームについて上記で説明されているように、Cisco Unified Border Element は、同時 VoiceXML セッションまたはコールの最大数に制限されています。

Cisco Unified Border Element を SBC として使用して、フロースルー コールのみ(VoiceXML なし)を処理している場合は、音声アクティビティ検出(VAD)を考慮し、次の URL から入手可能な『Cisco Unified Border Element Ordering Guide』のサイジング情報を参照してください。

http:/​/​www.cisco.com/​en/​US/​prod/​collateral/​voicesw/​ps6790/​gatecont/​ps5640/​order_​guide_​c07_​462222.html

Unified CVP Reporting Server と Unified CVP コール サーバの共存

Unified CVP Reporting Server は Unified CVP コール サーバと共存することもできますが、スタンドアロン VoiceXML 展開の場合に限ります。 スタンドアロン VoiceXML 展開では通常、コール サーバは必要ありませんが、レポートが必要な場合は、レポーティング データを VXML Server から Reporting Server に送信するために、コール サーバが必要となります。 したがって、Reporting Server がコール サーバと共存している場合、コール サーバは SIP コールを一切処理せず、単に VXML Server からのレポーティング データを中継します。

共存コール サーバによるこのモデルへのパフォーマンスの影響は大きくないため、Unified CVP Reporting Serverのこの項のサイジング情報に変更はありません。


(注)  


Unified Border Element を SBC として使用し、VAD を考慮してフロースルー コールまたはフローアラウンド コールのみ(VXML なし)を処理する場合、サイジングのために『Unified Border Element Ordering Guide』を使用できます。



(注)  


フロースルー コールまたはフローアラウンド コールに対して Unified Border Element を SBC として使用し、かつ、Unified Border Element で VXML 要件を処理する必要がある場合は、CVP SRND のサイジング情報を使用する必要があります。 特定の状況およびハードウェア プラットフォームについて説明されているように、Unified Border Element は、同時 VXML セッション/コールの最大数に制限されています。


Unified CVP Video Service

Cisco Unified CVP Release 7.0 で、Cisco Unified Contact Center Enterprise(Unified CCE)のビデオ対応エージェント用の機能が追加されました。

同じ Unified CVP コール サーバを使用して、ビデオ コールと従来の音声コールの両方にサービスを提供できます。ただし、Unified CVP 包括コール フローを使用して音声コールが処理されている場合に限ります。 包括モデル以外のモデルが音声コールに使用されている場合は、ビデオ コールと音声コールに別々のコール サーバを使用する必要があります。

Basic Video Service のサイジング

Unified CVP Basic Video Service では、Unified CVP 包括コール フローを使用します。したがって、Unified CVP コール サーバ、Unified CVP VoiceXML Server、および VXML ゲートウェイが必要です。 これらのコンポーネント用に Basic Video Service をサイジングするには、従来の音声アプリケーションの場合と同じ方法を使用します。

Cisco Unified Videoconferencing ハードウェア、Radvision IVP、および Radvision iContact は、Basic Video Service には必要ありません。

Unified CVP Reporting Server

Unified CVP Reporting Server のサイジングの際には、多数の変数を考慮に入れる必要があります。 さまざまな VoiceXML アプリケーションはそれぞれ異なる特性を持ち、こうした特性が、生成されるレポーティング データの量に大きく関係します。 こうした特性の一部を次に示します。

  • アプリケーションで使用される要素のタイプ
  • 必要なデータの精度
  • アプリケーション内でユーザが使用するコール フロー
  • コールの長さ
  • コールの数

Reporting Server をサイジングするには、最初に VoiceXML アプリケーションで生成されるレポーティング データ量を見積もる必要があります。 この章の以降の項で例として挙げているアプリケーションおよび表は、ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定するのに役立ちます。

ご使用のアプリケーションで生成されるレポーティング メッセージの数を特定した後は、各 VoiceXML アプリケーションに対して次の手順を実行します。

  1. アプリケーションが受信する 1 秒当たりのコールを見積もります。
  2. アプリケーションで生成されるレポーティング メッセージの数を見積もります。

次の式を使用して、各 VoiceXML アプリケーションで 1 秒当たりに生成されるレポーティング メッセージの数を特定します。

A# = %CPS * CPS * MSG

説明:

A# は、アプリケーションで生成される 1 秒当たりのレポーティング メッセージの推定数です。 アプリケーション(A1、A2、...、An)ごとに 1 つの計算を実行します。

CPS は、1 秒当たりのコール数です。

%CPS は、VoiceXML アプリケーションを使用するコールの割合です。

MSG は、このアプリケーションが生成するレポーティング メッセージの数です。 アプリケーションで生成されるレポーティング メッセージの数を特定するには、レポーティング メッセージの詳細およびアプリケーション例の項で示している情報を使用します。

次に、各アプリケーションに関して前の計算で得られた値を合計することで、現在の展開で生成されるレポーティング メッセージの合計数を見積もります。

A(合計) = A1+ A2+.....+An

これは、VoiceXML アプリケーションで 1 秒当たりに生成されるレポーティング メッセージの合計数です。 Cisco MCS-7845 Reporting Server は、1 秒当たり 420 のメッセージを処理できます。 現在の展開における 1 秒当たりのレポーティング メッセージの合計数が 420 よりも少ない場合、1 つの Reporting Server を使用できます。 これよりも多い場合は、複数の Reporting Server を使用し、特定の Reporting Server を使用するように複数の VoiceXML アプリケーションを分ける必要があります。

複数のサーバ

(上記のステップ 1 および 2 で決定した)1 秒当たりのメッセージ数が Unified CVP Reporting Server(Reporting Server)のキャパシティを超える場合は、展開を縦割りで分ける必要があります。

レポーティング データのロード バランシングのために縦割りで分けた場合、Unified CVP システム設計者は、複数の Reporting Server の展開に適用される次の要件を考慮する必要があります。

  • 各 Unified CVP コール サーバおよび各 Unified CVP VXML Server は、1 つの Unified CVP Reporting Server とのみ関連付けることができる。
  • 複数の Informix データベースにまたがったレポートを作成することはできない。

これらの要件の詳細については、次の URL から入手可能な『Reporting Guide for Cisco Unified Customer Voice Portal』を参照してください。

http:/​/​www.cisco.com/​en/​US/​products/​sw/​custcosw/​ps1006/​products_​installation_​and_​configuration_​guides_​list.html

複数の Reporting Server を使用する Unified CVP 展開を設計する場合は、次のガイドラインに従います。

  • コール処理メッセージとアプリケーション メッセージを合計した場合に、1 つの Reporting Server がサポートするよりも多くのメッセージを生成する複数のアプリケーションを分けます。
  • VoiceXML はフィルタリングできます。不要なデータをフィルタで除外すると、より多くのメッセージ量をサポートする使い勝手の良いデータ リポジトリが作成されます。
  • 着信コールを適切なコール サーバおよび VXML Server に転送するように、ダイヤル プランやその他の使用可能な方法を設定します。

複数のデータベースからのデータを結合する必要がある場合、使用できる可能性があるオプションは次のとおりです。

  • レポーティング データを Excel、Comma Separated Value(CSV; カンマ区切り値)ファイル、またはデータベースの外部でデータを結合できるその他の形式にエクスポートする。
  • レポーティング データを CSV ファイルにエクスポートし、それをユーザ指定のデータベースにインポートする。
  • ユーザ指定のデータ ウェアハウスにデータを抽出し、そのデータに対するレポートを実行する。

レポーティング メッセージの詳細

次の表に、さまざまな要素またはアクティビティ、およびそれぞれによって生成されるレポーティング メッセージの数について説明します。

 
表 2 要素またはアクティビティごとのレポーティング メッセージ数

要素またはアクティビティ

レポーティング メッセージの数(フィルタリングなし)

Start

2

End

2

Subdialog_start

2

Subdialog_return

2

Hotlink

2

HotEvent

2

Transfer w/o Audio

2

Currency w/o Audio

2

Flag

2

Action

2

Decision

2

Application Transfer

2

VoiceXML Error

2

CallICMInfo(コールごと)

2

Session Variable(変更ごと)

2

Custom Log(アイテムごと)

2

Play(音声ファイルまたは TTS)

2

Get Input(DTMF)

5

Get Input(ASR)

9

Form

10

Digit_with_confirm

20

Currency_with_confirm

20

ReqICMLabel

30


(注)  


これらの要素は、すべてのアプリケーションで必須であり、フィルタリングすることはできません。


アプリケーション例

この項では、ご使用の特定のアプリケーションで生成されるレポーティング メッセージの数を見積もるために使用できる適用例をいくつか示します。

低複雑度

合計: コールごとに 16 のレポーティング メッセージ。

 

要素タイプ

レポーティング メッセージの概数

Start

2

Subdialog_start

2

Play element

2

Play element

2

Play element

2

Play element

2

Subdialog_end

2

End

2

中複雑度(DTMF のみ)

合計: コールごとに 39 のレポーティング メッセージ。

 

要素タイプ

レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Play element

2

Get input

5

Play element

2

Get input

5

Form

10

Input

5

Transfer with audio

2

Subdialog_end

2

End

2

中複雑度(Automatic Speech Recognition(ASR; 音声自動認識)を使用)

合計: コールごとに 51 のレポーティング メッセージ。

 

要素タイプ

レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Play element

2

Get input

9

Play element

2

Get input

9

Form

10

Input

9

Transfer with audio

2

Subdialog_end

2

End

2

高複雑度(Automatic Speech Recognition(ASR; 音声自動認識)を使用)

合計: コールごとに 107 のレポーティング メッセージ。

 

要素タイプ

レポーティング メッセージの概数

Start

2

Subdialog_strart

2

Icmrequrestlabel

30

Form

10

ASR capture

9

Digit with confirm

20

Form

10

Digit with confirm

20

Subdialog_end

2

End

2