Cisco Unified Customer Voice Portal（CVP）ソリューション リファレンス ネットワーク デザイン（SRND）Release 8.0(x)

サイジング

---

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

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

• 「サイジングの概要」

• 「Unified CVP コール サーバ」

• 「Unified CVP VXML Server（VXML Server）」

• 「Unified CVP Co-Residency」

• 「Unified Presence Server」

• 「Unified CVP Video Service」

• 「Unified CVP Reporting Server」

この章の新規情報

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

サイジングの概要

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

• セルフ サービス：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 Presence Server と Unified CVP Reporting Server について検討します。この項では、Unified CVP システムをサポートするために必要な物理コンポーネントの数およびタイプのみを取り上げ、冗長性については説明していません。これらの数を増やして信頼性を高める方法については、「ハイアベイラビリティのための Unified CVP の設計」を参照してください。

Unified CVP コール サーバ

（注） Unified CVP コール サーバ（コール サーバ）は、モデル #1 のスタンドアロン セルフサービスでは使用されません。この項は、こうした展開には適用されません。

Unified CVP コール サーバは、最大コール到着率に加えて Unified CVP コール サーバが処理できるコール数に応じてサイジングされます。

（注） UCS パフォーマンスの数値については、シスコの doc-wiki リンク（http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP）を参照してください。

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

各コール サーバは、1200 の SIP コールまたは 500 の H.323 コールを処理できます。各コール サーバには、さらに平均コール到着率（SIP の場合は 14 コール数/秒（cps）、H.323 の場合は 7 cps）という制限があります。ただし、モデル #4 は、H.323 または SIP 処理を行わないためこの制限から除外されます。

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

(セルフサービス + キューとコレクト + トーキング) / 1200（H.323 の場合は 500）、切り上げ

または

平均コール到着率 / 14、切り上げ（H.323 の場合は 7。ただし、モデル #4 は除く）

コール サーバが SIP コールと H.323 コールの両方を処理している場合、各コール タイプに使用されるパフォーマンスを比例配分することで、サーバをサイジングできます。たとえば、コールの 60% が H.323 で、40% が SIP の場合のアクティブ コールに関する最大負荷は次のようになります。

60% ∗ H.323 コール 500 件 + 40% ∗ SIP コール 1200 件 = 780 アクティブ コール

また、Cisco Unified Communications Manager クラスタに配信されるコールについて、そのクラスタ内のサブスクライバ間でロード バランシングが行われる必要があり、各サブスクライバで 2 コール数/秒（cps）を超えないようにする必要があります。

Unified CVP VXML Server（VXML Server）

下の表および例で、VXML Server のコール率計算について説明します。

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

HTTP の場合の Unified CVP VXML Server のサイジングは単純です。1 つの Unified CVP VXML Server は最大 1200 のコールを処理できます。複数の Unified CVP VXML Server を使用している場合は、次の式に従ってこれらのマシンをサイジングする必要があります。

コール / 1200、切り上げ

ここで、 コール は、ビジーな瞬間のスナップショットでそのときに Unified CVP VXML Server セルフサービス アプリケーションに実際に存在するコール数を示します。

（注） UCS パフォーマンスの数値については、シスコの doc-wiki リンク（http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP）を参照してください。

Unified CVP は、Unified VXML Server および Unified CVP IVR サービスで HTTPS を使用するように設定することもできます（IVR サービスは、非常に基本的な VoiceXML ドキュメントを生成でき、Unified CVP コール サーバの一部です）。HTTPS の処理オーバーヘッドが大きいため、Tomcat アプリケーション サーバは、コンフィギュレーションによっては、最大でも 100 の同時接続しか確立できません。

表 14-4 に、さまざまなアプリケーションおよびコール フロー モデルを使用する HTTPS コールに関する同時コール情報を示します。

（注） UCS パフォーマンスの数値については、シスコの doc-wiki リンク（http://docwiki.cisco.com/wiki/Virtualization_for_Unified_CVP）を参照してください。

上記すべてのシナリオで、[Reporting] オプションと [Datafeed] オプションは無効になっています。次のことにも注意してください。

• HTTPS オプションをサポートするには、Cisco IOS Release 12.4(15)T5 以降のリリースが必要です（メインラインの Cisco IOS は現在サポートされていません）。

シスコでは、Cisco IOS VoiceXML ゲートウェイでの HTTPS オプションの次のコンフィギュレーションを推奨します。この設定を使用しないと、VXML ゲートウェイと包括的なソリューション（通常、HTTPS とともに使用）のパフォーマンスおよびサイジングに重大な影響を与える可能性があります。

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 台のサーバ上で実行できることを意味します。

H.323 共存サーバでは、500 の H.323 コールと 500 の VXML Server セッションを同時に処理でき、1 秒当たり 6 コールの平均コール到着率を処理できます。

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

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

（セルフサービス + キューとコレクト + トーキング）/ 1200（H.323 の場合は 500）、切り上げ

または

平均コール到着率 / 14（H.323 の場合は 6）、切り上げ、VRU のみのモデルの場合を除く

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

これは、1200 ポート ライセンスで、SIP 呼制御を行うコール サーバの 1200 ポートと、VXML Server の 1200 のポートをすべて 1 台のサーバ上で実行できることを意味します。H.323 共存サーバでは、500 の H.323 コールと 500 の VXML Server セッションを同時に処理でき、1 秒当たり 6 コールの平均コール到着率を処理できます。これは、500 ポート ライセンスで、H.323 呼制御を行うコール サーバの 500 ポートと、VXML Server の 500 のポートをすべて 1 台のサーバ上で実行できることを意味します。

例

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

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

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

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

(セルフサービス + キューとコレクト + トーキング) / 1200（H.323 の場合は 500）、切り上げ

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

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

Cisco Unified Border Element を SBC として使用して、フロースルー コールのみ（VXML なし）を処理している場合は、Voice Activity Detection（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 または H.323 コールをいっさい処理せず、単に VXML Server からのレポーティング データを中継します。

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

（注） CUBE を SBC として使用し、VAD を考慮してフロースルー コールまたはフローアラウンド コールのみ（VXML なし）を処理する場合、サイジングのために CUBE 発注ガイドを使用できます。

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

Unified Presence Server

Cisco Unified Presence Server は、シスコが Unified CVP で使用するために提供している SIP プロキシ サーバです。 表 14-5 に、さまざまなサーバ タイプのパフォーマンスを示します。

表 14-5 に示すサイジング数は、専用 SIP プロキシの場合を想定しています。プレゼンス サービスにも同じ Cisco Unified Presence Server を使用している場合、使用されるキャパシティに応じて数を調整する必要があります。たとえば、Cisco Unified Presence Server が 2500 のプレゼンス ユーザをサポートするが、実際に存在するのは 1250（50%）のみである場合、SIP プロキシのキャパシティは約 50% が使用されないままです。

表 14-5 に示すキャパシティは、1 秒当たりのコール数（cps）で測定されています。ただし、PSTN からの 1 つの着信コールは、Cisco Unified Presence を介した 1 つのコールと同等ではありません。実際には、キューイング、呼び出し音、および以降のエージェントへの転送のために、着信顧客コールごとに複数のコールが生成されます。典型的な着信コールは、Unified CVP によって 4 回転送されるため、着信 PSTN コール率は 4 倍する必要があります。

例：

Unified CVP が 1 秒当たり 20 の PSTN コールを受信する場合、Cisco Unified Presence は 1 秒当たり約 80 のコールを確認します。

CUSP の公開データ シート 「Performance Measured in the Number of New Call Attempts per Second」の表 2 には、CUSP サーバに関する追加のパフォーマンス データが示されています。

Unified CVP Video Service

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

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

Unified CVP Reporting Server

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

• アプリケーションで使用される要素のタイプ

• 必要なデータの精度

• アプリケーション内でユーザが使用するコール フロー

• コールの長さ

• コールの数

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

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

1. アプリケーションによる VoiceXML コール処理をお客様が受信するのに何分かかるかを見積もります。

2. アプリケーションが受信する 1 秒当たりのコールを見積もります。

3. アプリケーションで生成されるレポーティング メッセージの数を見積もります。

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

A# = %CPS ∗ CPS ∗ MSG / Min / 60

定義：

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

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

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

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

Min は、アプリケーションで消費される時間（分単位）です。

60 は、1 分の秒数です。

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

A（合計）= A1 + A2 + ..... + A n

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