プロセッサ要件の見積もりの例
ここでは、配備例に必要な処理能力を見積もる 1 つの方法を示します。配備例は、1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースによる通信ソリューションの論理アーキテクチャーに基づいています。「アイデンティティーベースの通信の例」の節を参照してください。
この例で使用される CPU とメモリの値は、図で使用するための任意の見積もり結果に過ぎません。これらの値は、理論上の例が基になっている任意のデータから計算されています。プロセッサ要件を見積もるには、さまざまな要因を徹底的に分析する必要があります。この分析には次の情報が含まれているものとしますが、これらに限定されません。
-
徹底的なビジネス分析に基づいた詳細なユースケースと使用パターン分析
-
ビジネス要件の分析によって決定されたサービス品質要件
-
処理およびネットワークハードウェアの具体的なコストと仕様
-
類似の配備を実装した過去の経験
注意 – これらの例に示される情報は、何らかの具体的な実装の提案を示すものではなく、システムの設計プロセスの説明を目的に記載されています。
ユーザーエントリポイント用の基準 CPU の見積もり
ユーザーエントリポイントとなる各コンポーネントの想定負荷を処理するために必要な CPU の数を見積もることから開始します。次の図は、「アイデンティティーベースの通信の例」で説明したアイデンティティーベースの通信シナリオの論理アーキテクチャーを示しています。
図 5–1 アイデンティティーベースの通信シナリオの論理アーキテクチャー
次の表は、配備のエンドユーザーと直接インタフェースをとる、論理アーキテクチャーのプレゼンテーション層のコンポーネントを示しています。この表には、技術要件の分析から得られた基準 CPU の見積もり、ユースケース、具体的な使用パターン分析、および同種の配備に関する過去の経験が反映されています。
表 5–1 アクセスユーザーのエントリポイントを含むコンポーネントの CPU の見積もり|
コンポーネント |
CPU の数 |
説明 |
|---|---|---|
|
Portal Server |
4 |
ユーザーエントリポイントであるコンポーネント。 |
|
Communications Express |
2 |
Portal Server のメッセージングチャネルおよびカレンダチャネルにデータを配信します。 |
サービス依存関係に関する CPU 見積もり値の取り込み
ユーザーエントリポイントとなるコンポーネントは、他の Java Enterprise System コンポーネントからのサポートを必要とします。パフォーマンス要件の特定を継続するには、必要となる他のコンポーネントからのサポートを考慮して、パフォーマンスの見積もり値を組み込みます。コンポーネント間のインタラクションの種類は、論理アーキテクチャーを設計する際に詳細化します。「論理アーキテクチャーの例」の節で、論理アーキテクチャーの例を参照してください。
表 5–2 サポートするコンポーネントのための CPU の見積もり|
コンポーネント |
CPU の数 |
説明 |
|---|---|---|
|
Messaging Server MTA (着信) |
1 |
Communications Express および電子メールクライアントからの着信メールメッセージをルーティングします。 |
|
Messaging Server MTA (発信) |
1 |
発信メールメッセージを受取人に配信します。 |
|
1 |
電子メールクライアントの Messaging Server メッセージストアにアクセスします。 |
|
|
1 |
電子メールメッセージを取得および保存します。 |
|
|
2 |
認証と承認のサービスを提供します。 |
|
|
2 |
Communications Express、Calendar Server フロントエンドのカレンダデータを取得および保存します。 |
|
|
2 |
LDAP ディレクトリサービスを提供します。 |
|
|
0 |
Portal Server および Access Manager に対して Web コンテナサポートを提供します。 追加の CPU サイクルは不要です。 |
ユースケースによるピーク負荷の調査
ユースケースおよび使用パターン分析に戻り、ピーク負荷の領域を特定し、CPU の見積もりを調整します。
たとえば、この例に関して次のようなピーク負荷状況を特定したとします。
-
ユーザーが同時にログインすることによる、初期のユーザー数の増加
-
特定の時間枠内での電子メールの交換
このピーク負荷時の使用パターンを考慮に入れるには、これらのサービスを提供するコンポーネントに対する調整を行います。次の表は、このピーク負荷時の使用パターンを考慮した調整の概要を示しています。
表 5–3 ピーク負荷による CPU 見積もりの調整|
コンポーネント |
CPU の数 (調整後) |
説明 |
|---|---|---|
|
Messaging Server MTA 着信 |
2 |
ピーク時の着信電子メール用に 1 CPU を追加します |
|
Messaging Server MTA 発信 |
2 |
ピーク時の送信電子メール用に 1 CPU を追加します |
|
Messaging Server MMP |
2 |
増加する負荷用に 1 CPU を追加します |
|
Messaging Server STR (メッセージストア) |
2 |
増加する負荷用に 1 CPU を追加します |
|
Directory Server |
3 |
増加する LDAP 検索用に 1 CPU を追加します |
その他の負荷条件による見積もりの修正
CPU の見積もりを続行し、負荷に影響を与える可能性のあるその他のサービス品質要件を考慮に入れます。
-
セキュリティー: 技術要件フェーズで、セキュリティー保護されたデータ転送が負荷要件に与える影響を特定し、それに応じて見積もりを修正します。後述の、「セキュリティー保護されたトランザクションのためのプロセッサ要件の見積もり」の節では、調整を行うプロセスについて説明しています。
-
サービスのレプリケーション: 可用性、ロードバランス、およびスケーラビリティーのためのサービスのレプリケーションを考慮して、CPU の見積もりを調整します。後述の、「可用性戦略の決定」の節では、可用性ソリューションのためのサイズ設定について説明します。「スケーラビリティーのための戦略の決定」の節では、ディレクトリサービスへのアクセスによるソリューションについて説明します。
-
潜在処理能力およびスケーラビリティー: 配備上での予期しない大きな負荷に対処するために必要な潜在処理能力に応じて、CPU の見積もりを修正します。規模拡大の段階的な達成目標および時間の経過とともに想定される負荷の増加を考慮し、水平方向または垂直方向にシステムを拡張する目標を達成できることを確認します。
CPU 見積もりの更新
通常は、CPU の数を偶数値に切り上げます。偶数値に切り上げることで、2 つの物理サーバーに CPU 見積もりを均等に分割できるとともに、潜在処理能力の小さな要因が追加されます。ただし、サービスのレプリケーションに対する特定のニーズに基づいて切り上げる必要があります。
原則として、CPU ごとに 2G バイトのメモリを許容します。必要な実際のメモリは、特定の使用パターンによって異なります。 これは、テストで決定できます。
次の表は、アイデンティティーベースの通信に関する最終見積もりの例です。これらの見積りには、セキュリティーおよび可用性のために追加される可能性のある、追加の処理能力は含まれていません。セキュリティーおよび可用性のための各合計は、この後の節で加えられます。
表 5–4 サポートするコンポーネントのための CPU 見積もりの調整|
コンポーネント |
CPU の数 |
メモリ |
|---|---|---|
|
Portal Server |
4 |
8G バイト |
|
Communications Express |
2 |
4G バイト |
|
Messaging Server (MTA、着信) |
2 |
4G バイト |
|
Messaging Server (MTA、発信) |
2 |
4G バイト |
|
Messaging Server (MMP) |
2 |
4G バイト |
|
Messaging Server (メッセージストア) |
2 |
4G バイト |
|
Access Manager |
2 |
4G バイト |
|
Calendar Server |
2 |
4G バイト |
|
Directory Server |
4 |
8G バイト (3 CPU/6G バイトメモリから切り上げ) |
|
Web Server |
0 |
0 |
- © 2010, Oracle Corporation and/or its affiliates