Cisco IP Contact Center Enterprise Edition ネットワーク デザイン(SRND) Releases 5.0/6.0
偏向のない言語
この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
翻訳について
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
- Updated:
- 2017年6月5日
章のタイトル： IPCC のコンポーネントとサーバの サイジング
IPCC のコンポーネントとサーバのサイジング
システムのパフォーマンスおよびスケーラビリティを最適化するには、Cisco IP Contact Center（IPCC）Enterprise ソリューションを適切にサイジングすることが重要です。サイジングに関する考慮事項には、ソリューションでサポート可能なエージェント数、Busy Hour Call Attempt（BHCA; 最頻時発呼数）の最大数、および配置をサポートするために必要なサーバの数、タイプ、および設定に影響を与えるその他の変数などがあります。選択された配置モデルに関係なく、IPCC Enterprise は高度な分散アーキテクチャをベースとしており、キャパシティ、パフォーマンス、およびスケーラビリティに関する問題はソリューション全体だけでなく、ソリューション内の各要素にも適用されます。
この章では、IPCC Enterprise の配置におけるスケーラビリティおよびキャパシティに関する最適な設計方法について説明します。この章に記載されている設計時の考慮事項、ベスト プラクティス、およびキャパシティは、原則としてテスト結果に基づいて導き出されたものです。それ以外では、テスト データを基にした推定から導き出されています。この情報の目的は、ユーザが IPCC ソリューションを適切にサイジングして、プロビジョニングできるようにすることです。
IPCC のサイジングに関する考慮事項
この項では、次の IPCC サイジングに関する考慮事項について説明します。
•
「IPCC コア コンポーネントの最小限のハードウェア構成」
コア IPCC コンポーネント
IPCC 配置のサイジングを行う場合、キャパシティ計画では IP Telephony コンポーネントが重要になります。多量のコール負荷をサポートするには、複数の Cisco CallManagers およびクラスタなどを適切に設計する必要があります。Cisco CallManager のキャパシティおよび IP Telephony コンポーネントの詳細については、「IPCC における Cisco CallManager サーバのサイジング」、および次の URL にある『Cisco IP Telephony Solution Reference Network Design (SRND)』を参照してください。
また、さまざまなエージェントおよびスキル グループ キャパシティがあるため、CTI OS および Cisco Agent Desktop サーバの適切なサイジングは、IP Telephony コンポーネントと組み合わせて検討する必要があります。
最後に、残りの ICM コンポーネントは、高度なスケーラビリティを実現する一方、システム リソースにも作用する特定の設定要素のサイジング変数の影響を受けます。
この項に記載されているこれらの要因は、どのような配置計画においても必ず考慮して計画に反映する必要があります。
図5-1、図5-2、および 表5-1 に示されている情報は、IPCC のすべての実装に等しく適用されるわけではありません。データは特定のシナリオでのテストに基づくものですが、適用にあたってはあくまでも参考資料として位置付け、この章の他のサイジング情報と同様に変化するという点に注意してください。サイジングは常に慎重に行い、拡張に備えた計画を立てる必要があります。
（注） サイジングに関する考慮事項は、キャパシティおよびスケーラビリティのテスト データに基づいています。主要な ICM ソフトウェア プロセスは各サーバ上で動作し、それぞれの CPU、メモリ、およびその他の内部システム リソースの利用状況を計測しました。共存するソフトウェア プロセスおよび複数の CPU サーバのキャパシティを算出する場合は、合理的な推論が使用されていました。この情報は、どのような場合には単一サーバ内で複数の ICM ソフトウェア プロセスが共存でき、別のどのような場合には特定のプロセスが専用サーバを必要とするのかを判別するときに役立ちます。表5-1 では、二重化して配置されている 2 つの完全冗長サーバを含む配置シナリオを想定しています。理論上は、非冗長配置の方が大きなキャパシティを得ることができますが、この理論を検証するための独立したテストは実行されていません。したがって、シンプレックス配置およびデュプレックス配置に関するサイジング情報については、表5-1 を参照してください。
（注） Cisco IP Contact Center ソリューションには、現時点でクワッドプロセッサを備えた
Media Convergence Server（MCS）は含まれていません。次の表に記載されている制限を超えるパフォーマンスが必要な場合は、MCS 7845 の代わりに、既製のクワッドプロセッサ サーバを使用できます。サーバの使用については、
http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1001/products_usage_guidelines_list.html にある『Cisco Intelligent Contact Management Software Bill of Materials（BOM）』を参照してください。
• エージェント数は、ログインしたエージェント数を示しています。
–APG = Agent Peripheral Gateway
図5-1 一般的な IPCC 配置に必要な最小限のサーバ（CTI Desktop の場合）
図5-1 には、次の注が適用されます。
• サイジングは Cisco MCS 7845（3.0 GHz 以上）の使用およびエージェント 1 名につき 5 つのスキル グループの存在を前提としています。
• Voice Response Unit（VRU; 音声応答装置）および Cisco CallManager コンポーネントは表示していません。
• エージェント数が 2,000 を超える場合は、 表5-1 を参照してください。
• Agent Peripheral Gateway（APG）は Generic PG（Cisco CallManager PIM および VRU PIM）、CTI Server、および CTI OS で構成されています。
• APG の配置および設定オプションの詳細については、図5-3 および図5-4 を参照してください。
図5-2 一般的な IPCC 配置に必要な最小限のサーバ（Cisco Agent Desktop の場合）
図5-2 には、次の注が適用されます。
• サイジングは Cisco MCS 7845（3.0 GHz 以上）の使用およびエージェント 1 名につき 5 つのスキル グループの存在を前提としています。
• Voice Response Unit（VRU; 音声応答装置）および Cisco CallManager コンポーネントは表示していません。
• エージェント数が 2,400 を超える場合は、 表5-1 を参照してください。
• Agent Peripheral Gateway（APG）は Generic PG（Cisco CallManager PIM および VRU PIM）、CTI Server、および CTI OS で構成されています。
|
|
|
|
エージェント数 |
|
|---|---|---|---|---|
アドミン ワークステーション（AW）または Historical Data Server（HDS）と共存できません。 共存する Cisco Agent Desktop サーバを使用している場合、MCS-7845 のエージェント数は最大で 100 です。 共存するダイヤラを使用している場合、MCS-7845 のエージェント数は最大で 50 です。 共存する Cisco Agent Desktop サーバおよびダイヤラを使用している場合、MCS-7845 のエージェント数は最大で 25 です。 |
||||
AW/HDS は Progger、Rogger、Router、Logger、または PG と共存できません。 単一 Logger の場合は最大 4 つの AW/HDS、二重化 Logger の場合は最大 8 つの AW/HDS がサポートされています。 |
||||
Agent PG の設定オプションの詳細については、図5-3 および図5-4 を参照してください。 MCS-7835 サーバ Agent PG では、最大 150 の Cisco Agent Desktop エージェントがサポートされています。 MCS-7845 サーバ Agent PG では、最大 300 の Cisco Agent Desktop エージェントがサポートされています。 VRU ポート数は、サポートされているエージェント数の半数以下である必要があります。追加の VRU PG を配置すると、収容できる VRU ポート数を増やすことができます。 各 Agent PG 配置オプションの詳細については、「ペリフェラル ゲートウェイおよびサーバ オプション」を参照してください。 |
||||
| MCS-7845 ごとに最大 8 PIM、MCS-7835 ごとに最大 4 つの PIM。Generic PG では、300 ポートごとの PIM 数が 2 以下になります。 |
||||
MCS-7835 サーバの Agent PG では、ダイヤラおよび Media Routing（MR; メディア ルーティング）PG を Agent PG と共存させることにより、最大 100 のアウトバウンド エージェントがサポートされています。 MCS-7845 サーバの Agent PG では、ダイヤラを Agent PG と共存させることにより、最大 200 のアウトバウンド エージェントがサポートされています。 |
||||
Agent PG および Media Blender |
Media Routing（MR; メディア ルーティング）PG を共存させるには、MCS-7845 が必要です。キャパシティ値については、この表の次の行を参照してください。 |
|||
| • |
||||
| • |
||||
| エージェント 10 名未満： すべての Cisco Email Manager コンポーネントおよびデータベースが単一サーバ上で共存します（MCS-7845）。 エージェント 250 名まで： 2 台のサーバ。最初のサーバに Cisco Email Manager AppServer、UI Server、および WebView、2 番目のサーバにデータベース サーバ（プライマリ、LAMBDA、および CIR データベース）。 エージェント 500 名まで： 4 台のサーバ。最初のサーバに Cisco Email Manager AppServer、2 番目のサーバに Cisco Email Manager UI Server（1 番目）および WebView サーバ、3 番目のサーバに Cisco Email Manager UI Server（2 番目）、4 番目のサーバにデータベース サーバ （このシナリオでは、MCS-7835 を 2 番目の UI Server ボックスに使用できます）。 エージェント 1000 名まで： 7 台のサーバ。最初のサーバに Cisco Email Manager AppServer（クワッド プロセッサを推奨）、2 番目のサーバに Cisco Email Manager UI Server（1 番目）および WebView サーバ、3 番目のサーバに Cisco Email Manager UI Server（2 番目）、4 番目のサーバに Cisco Email Manager UI Server（3 番目）、5 番目のサーバに Cisco Email Manager UI Server（4 番目、エージェント数が 750 を超える場合に必要）、6 番目のサーバにデータベース サーバ（プライマリおよび LAMDA）、7 番目のサーバにデータベース サーバ（CIR） （このシナリオでは、MCS-7835 を n+1 個の UI Server ボックスに使用できます）。 サイジング情報については、 |
||||
Internet Service Node（ISN）および CVP のサーバ仕様については、 |
||||
IP IVR サーバの仕様については、次の URL にある『Cisco IPCC Express and IP IVR Configuration and Ordering Tool』を参照してください。 http://www.cisco.com/en/US/partner/products/sw/custcosw/ps1846/prod_how_to_order.html |
IPCC コア コンポーネントの最小限のハードウェア構成
サーバのサイジング要件を正確に測定するには、配置ごとに 表5-1 のサイジング情報を適用する必要があります。 表5-1 の情報には、次の考慮事項およびガイドラインが適用されます。
• デュアル CPU サーバ構成を使用する場合（特に Progger の場合）は、コール センターの配置計画を形式どおり厳密に立案するようにしてください。
• システム コンポーネントごとに、エージェント数に関するキャパシティ制限に従う必要があります。エージェント キャパシティは、エージェントあたりの最大 BHCA 数 30、および IVR ポートあたりの最大コール数 90 に基づいています。これらの値は調整はできません。エージェント数が少ない場合に BHCA 数が大きくなるわけではありません。また、BHCA 数が少ない場合にサポートされるエージェント数が増えるわけではありません。
• 各コンポーネントの最大 BHCA 数および最大エージェント数を調べ、『Cisco Intelligent Contact Management Software Bill of Materials (BOM)』に記載されている推奨事項に従っている場合は、Rogger および PG にはさまざまなサーバ モデル構成を使用できます。
• 各構成の最大キャパシティでは、通常の CTI トラフィック量を想定しています。多量の CTI トラフィック（巨大な IVR からのトラフィックなど）が発生すると、最大 BHCA 数および最大エージェント数が少なくなります。
• キャパシティ値は、ICM スクリプト内で連続的に動作する、IVR コールごとに 5 つの実行 Voice Response Unit（VRU; 音声応答装置）スクリプトの平均に基づいています。これよりもさらに複雑な ICM/IVR スクリプトが配置されている場合は、BHCA およびエージェントの最大キャパシティも低下します。
• キャパシティ値は、エージェントあたりのスキル グループ数を 5 とする前提にも基づいています。エージェントごとに 5 つを超えるスキル グループが配置されている場合は BHCA およびエージェントの最大キャパシティも低下するため、ケースバイケースで対処する必要があります。
その他のサイジング要因
ハードウェア要件およびキャパシティは、IPCC 構成の数多くの変数および配置オプションによる影響を受けます。この項では、主要なサイジング変数と、それが各 IPCC コンポーネントのキャパシティへ及ぼす影響について説明します。また 表5-2 には、サイジング変数およびその影響が要約されています。
最頻時発呼数は重要なメトリックです。BHCA が増加するとすべての IPCC コンポーネントの負荷も増加し、特に Cisco CallManager、IP IVR、および Cisco CallManager PG ではこの負荷が著しく増大します。エージェントのキャパシティ値では、各エージェントの 1 時間ごとの最大コール数を 30 と想定しています。
Cisco CallManager クラスタを含むほとんどの IPCC サーバ コンポーネントのパフォーマンスに影響を与える重要なもう 1 つのメトリックは、エージェント数です。Cisco CallManager コンポーネントのパフォーマンスに関するエージェントの影響については、「IPCC における Cisco CallManager サーバのサイジング」を参照してください。
エージェントごとのスキル グループ数は、CTI OS サーバ、Cisco CallManager PG、および ICM Router や Logger に重大な影響を与えます。エージェントごとのスキル グループ数は可能な限り 5 以下に制限し、未使用のスキル グループがもしあれば定期的に削除してシステム パフォーマンスの低下を防いでください。また、統計情報の更新頻度を増やして、CTI OS サーバへの影響を管理することもできます。
IP IVR はコールをキューに格納し、エージェントがコールに応答するまでアナウンスによる応答を行います。サイジングを行う場合は、IVR がすべてのコールを最初に処理（コール処理）してから短いキューイング期間後に発信者をエージェントに転送するのか、またはエージェントがコールを最初に処理し、すべてのエージェントが使用中の場合の未応答のコールだけを IVR のキューに格納するのかの選択が重要になります。この質問に対する回答に応じてさまざまな IVR サイジング要件が決定され、ICM Router/Logger と Voice Response Unit（VRU; 音声応答装置）PG のパフォーマンスに影響が生じます。必要な VRU ポート数を判断するには、Cisco IPC Resource Calculator を使用します（詳細については、「Cisco IPC Resource Calculator」を参照）。
ICM スクリプトが複雑になったり個数が増えたりすると、ICM Router および VRU PG のプロセッサやメモリのオーバーヘッドが著しく増加します。この場合、実行 VRU スクリプトの再生間の遅延時間も影響を受けます。
リアルタイム レポーティングはデータベース アクセスを引き起こすため、Logger、Progger、および Rogger 処理に重大な影響を与えることがあります。Logger、Progger、および Rogger のレポーティング オーバーヘッドを軽減するには、アドミン ワークステーション（AW）または Historical Data Server（HDS）にそれぞれ個別のサーバを提供する必要があります。
データベース クエリーなどの機能によって IVR スクリプトの複雑さが増すと、IVR サーバおよび Router の負荷も増大します。IP IVR で複雑なスクリプト、複雑なデータベース クエリー、またはトランザクションベース処理を使用する場合、パフォーマンスを特徴付ける有効な方法またはベンチマークは存在しません。複雑な IVR 構成はラボまたはパイロット配置でテストし、さまざまな BHCA におけるデータベース クエリー応答時間、IVR サーバ、PG、Router のプロセッサおよびメモリに対する影響を判別することをお勧めします。
配置された IP IVR がセルフサービス アプリケーションにも使用される場合は、セルフサービス アプリケーションの負荷が IPCC の負荷に追加されるため、 表5-1 に記載されているサイジング要件として考慮する必要があります。
サードパーティ データベースおよび Cisco Resource Manager の接続
すべての IPCC ソリューション コンポーネントと外部デバイスまたはソフトウェアとの接続を慎重に調べて、ソリューションに対する全体的な影響を判別します。Cisco IPCC ソリューションは柔軟性が高くカスタマイズ可能ですが、複雑になる場合があります。コンタクト センターは、ミッション クリティカルで収益に直結する、顧客と直接に対話するオペレーションとなることがしばしばです。したがって、適切な経験および IPCC に関する認定を取得しているシスコ パートナー（または Cisco Advanced Services）と、IPCC ソリューションを設計することをお勧めします。
Extended Call Context（ECC; 拡張コール コンテキスト）
ECC を使用すると、PG、Router、Logger、およびネットワーク帯域幅に影響を与えます。ECC は、さまざまな方法で設定および使用できます。キャパシティに関する影響は設定した ECC によって異なるため、ケースバイケースで処理する必要があります。
ペリフェラル ゲートウェイおよびサーバ オプション
ICM Peripheral Gateway（PG; ペリフェラル ゲートウェイ）は、Cisco CallManager サーバ、IP IVR、またはその他のサードパーティ Automatic Call Distributor（ACD）や Voice Response Unit（VRU）から着信したメッセージを ICM で送信および認識される共通の内部形式メッセージに変換します。反対に、周辺装置で送信および認識できるよう ICM メッセージも変換します。
Peripheral Interface Manager（PIM; ペリフェラル インターフェイス マネージャ）は PG で動作するソフトウェア プロセスであり、メッセージの変換および制御を実行します。IPCC ソリューションに含まれている各周辺装置は、PG および PIM に接続する必要があります。
図5-3 および図5-4 に、CTI OS および Cisco Agent Desktop と Agent PG を併用した場合のさまざまな設定オプションを示します。
表5-2 に、PG および PIM のサイジングに関する推奨事項を示します。
図5-3 CTI OS を使用した場合の Agent PG の設定オプション
図5-4 Cisco Agent Desktop を使用した場合の Agent PG の設定オプション
|
|
|
|---|---|
指定したサーバが 表5-1 に記載されているエージェントおよび VRU ポートの上限に従う場合は、サーバごとに最大 2 タイプの PG を使用できます。 |
|
IVR PIM の実数は、IPCC 配置サイズ（エージェント、IVR ポート、BHCA など）によって決まります。通常は、PG（Agent PG）ごとに 5 つの PIM、および PG（スタンドアロン PG）ごとに 8 つの PIM が合理的な制限です。 |
|
http://cisco.com/go/srnd にある『Cisco IP Telephony Solution Reference Network Design』（SRND）を参照してください。 |
|
Media Convergence Server（MCS）の Cisco CallManager と PG を共存できるかどうか |
CTI OS
CTI OS は通常、Agent PG の共存コンポーネントとして設定され（図5-3 および図5-4 を参照）、最大 500 名のエージェントをサポートします。
表5-3 に、CTI OS のその他のサイジング要因を示します。
|
|
|
|
|
|---|---|---|---|
サポートされるエージェントの 10 %1 |
|||
サポートされるエージェントの 10 %1 |
|||
サポートされるエージェントの 20 %1 |
|||
サポートされるエージェントの 2 %1 |
|||
サポートされるエージェントの 20 %1 |
|||
| 1.これらの割合は CTI OS Server エージェントのキャパシティに適用され、Contact Center 全体のキャパシティには適用されません。 |
表5-3 の値は、次の前提に基づいています。
CTI エージェント数が 500 を超える場合は、サーバを追加するごとに（500 エージェントずつ）Agent PG インスタンスの負荷が軽減されます。CTI OS 設定値が 表5-3 の値と異なる場合は、CTI OS のキャパシティが小さくなります。たとえば、エージェントごとのスキル グループ数が増加すると、CTI OS キャパシティが小さくなります。この場合は、エージェントおよびスキル グループを照会して更新するために必要となる作業負荷が増加するため、プラットフォーム リソース使用量は著しく増加します。
Cisco Agent Desktop コンポーネントのサイジング
Cisco Agent Desktop のコンポーネントおよびアーキテクチャの詳細については、「エージェント デスクトップおよびスーパーバイザ デスクトップ」を参照してください。
Cisco Agent Desktop CTI オプションのサーバ キャパシティは、エージェントの総数、Switched Port Analyzer（SPAN; スイッチド ポート アナライザ）のモニタリングおよびレコーディングを使用するかどうか、および同時レコーディング数によって変わります。
この項では、次のインストール可能な Cisco Agent Desktop Server コンポーネントのサイジングに関するガイドラインについて説明します。
• 「Cisco Agent Desktop 基本サービス」
• 「Cisco Agent Desktop VoIP モニタ サービス」
• 「Cisco Agent Desktop 録音再生サービス」
Cisco Agent Desktop 基本サービス
Cisco Agent Desktop 基本サービスは、Microsoft Windows 2000 サービスとして動作する一連のアプリケーション サーバで構成されています。この基本サービスには、チャット サービス、ディレクトリ サービス、エンタープライズ サービス、IP Phone エージェント サービス、LDAP 監視サービス、ライセンスとリソース マネージャ サービス、録音と統計サービス、同期サービスが含まれます。また、この基本サービスのサーバと同じコンピュータまたは異なるコンピュータに配置できるアプリケーション サーバもあります。これらの追加アプリケーションは、VoIP モニタ サービス、録音再生サービスなどです。
Cisco Agent Desktop 基本サービスと追加アプリケーション サーバの組み合わせは、Logical Call Center（LCC; 論理コール センター）に相当します。 表5-4 に、さまざまな規模の企業に対して 1 個所の LCC がサポートできる最大エージェント数を示します。
|
|
|
|
|
|---|---|---|---|
Cisco Agent Desktop VoIP モニタ サービス
VoIP モニタ サービスでは、サイレント モニタリングおよび録音機能を使用できます。デスクトップ モニタリングの場合、VoIP モニタ サービスは Agent PG のスケーラビリティに関する設計ガイダンスに影響を与えません。Switched Port Analyzer（SPAN; スイッチド ポート アナライザ）モニタリングを使用した場合は、最大 100 のエージェントに対して VoIP モニタ サービスを Agent PG と共存させることができます。400 を超えるエージェントに対して Remote Switched Port Analyzer（RSPAN; リモート スイッチド ポート アナライザ）モニタリングおよび録音を使用する必要がある場合は、VoIP モニタ サービスを専用サーバ（MCS-7835 サーバまたは同等サーバ）に配置する必要があります。専用 VoIP モニタ サービスでは、最大 400 のエージェントをサポートできます。
Cisco Agent Desktop 録音再生サービス
録音再生サービスは、会話の録音データを保存して Supervisor Log Viewer アプリケーションで使用できるようにするものです。
CAD サーバと共存させる場合の録音再生サービスでは、最大で 32 本の会話の同時レコーディングが可能です。専用の場合の録音再生サービス（プレミアム提供時に使用可能）では、最大で 80 本の会話の同時レコーディングが可能です。録音再生サービスのキャパシティは使用するコーデックに依存 しません 。
表5-5 に、録音再生サービスのキャパシティの概要を示します。
|
|
|
|---|---|
要約
IPCC コンポーネントを適切にサイジングするには、エージェント数および最頻時発呼数以外の分析が必要です。各エージェントに複数のスキル グループが対応する設定、多量のコール キューイング、およびその他の要因によって、各コンポーネントの合計キャパシティは変化します。製品の購入に先立って慎重に計画と検討を実施し、重要なサイジング変数を特定して、最終的にこれらの考慮事項を反映した設計とハードウェア選択を行うことが不可欠です。
正しいサイジングおよび設計を行うと、最大 6,000 のエージェントおよび 180,000 の BHCA に対応する大規模システムを安定して配置することが可能になります。小規模配置の場合は、慎重な計画に基づいて ICM コンポーネント（Progger、Rogger、Agent PG など）を共存させることにより、コストを削減できます。
設計者は、エージェントごとのスキル グループ数など、サイジング キャパシティに影響を与えるサイジング変数にも注意する必要があります。製品購入前のフェーズでこれらの変数を確定することは困難である場合がしばしばありますが、初期設計時にこれらの点を考慮することが、特に PG と Progger の共存サーバーを配置する場合には重要となります。新規バージョンでスケーラビリティが改善される予定ですが、現在の Cisco Agent Desktop モニタ サーバでは、モニタリングおよび録音が必要となる場合に 1 台のサーバでモニタリング可能な同時セッション数が制限されます。
フィードバック