ここでは、配備設計で、サービスをサポートするために必要な CPU プロセッサ数および対応するメモリを見積もるプロセスについて説明します。また、通信配備シナリオの例を使用して、見積もりプロセスを段階的に説明します。
CPU 処理能力の見積もりは、次のことを考慮して繰り返し検討します。
論理アーキテクチャーでコンポーネントの依存関係によって示される、論理コンポーネントとそれらのインタラクション
特定されたユースケースの使用パターン分析
サービス品質要件
配備設計と Java Enterprise System に関する過去の経験
さまざまな種類の配備シナリオの設計と実装の経験を持つ、Sun プロフェッショナルサービスとの相談
見積もりプロセスには、次の手順が含まれます。これらの手順の順序は、あまり重要ではありませんが、最終結果に影響する要因を分析する 1 つの方法を提供するものです。
システムへのユーザーエントリポイントとなるコンポーネントの、基準となる CPU の見積もりを決定します。
設計上の意思決定の 1 つは、CPU をフルに搭載するか、一部だけ搭載するかについてです。CPU をフルに搭載すると、システムの処理能力は最大化されます。処理能力を向上するために、保守コストおよび場合によっては CPU の追加による停止時間が発生します。増大するパフォーマンス要件を満たすために、マシンの追加を選択できる場合もあります。
CPU を一部だけ搭載した場合は、保守コストをただちに発生させることなく、パフォーマンス要件に対応できる余裕が持てます。ただし、活用し切れないシステムへの先行投資費用が発生します。
コンポーネント間のインタラクションを考慮して、CPU の見積もりを調整します。
論理アーキテクチャーのコンポーネント間のインタラクションを調べて、依存コンポーネントのためにさらなる搭載が必要であるかを決定します。
使用パターン分析で特定のユースケースを調べてシステムのピーク負荷を割り出し、ピーク負荷を処理するコンポーネントに対する調整を行います。
最も重み付けされた (最も負荷を必要とする) ユースケースから始めて、各ユースケースに進み、計画したすべての使用シナリオを考慮したことを確認します。
CPU の見積もりを調整して、セキュリティー、可用性、スケーラビリティーの各要件を反映します。
この見積もりプロセスは、実際に必要な処理能力を決定するための開始点となります。通常は、これらの見積もりに基づいてプロトタイプ配備を作成し、その後、想定されるユースケースに対して厳格なテストを実行します。テストを繰り返したあとに初めて、配備設計の実際の処理要件を決定できます。
ここでは、配備例に必要な処理能力を見積もる 1 つの方法を示します。配備例は、1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースによる通信ソリューションの論理アーキテクチャーに基づいています。「アイデンティティーベースの通信の例」の節を参照してください。
この例で使用される CPU とメモリの値は、図で使用するための任意の見積もり結果に過ぎません。これらの値は、理論上の例が基になっている任意のデータから計算されています。プロセッサ要件を見積もるには、さまざまな要因を徹底的に分析する必要があります。この分析には次の情報が含まれているものとしますが、これらに限定されません。
徹底的なビジネス分析に基づいた詳細なユースケースと使用パターン分析
ビジネス要件の分析によって決定されたサービス品質要件
処理およびネットワークハードウェアの具体的なコストと仕様
類似の配備を実装した過去の経験
これらの例に示される情報は、何らかの具体的な実装の提案を示すものではなく、システムの設計プロセスの説明を目的に記載されています。
ユーザーエントリポイントとなる各コンポーネントの想定負荷を処理するために必要な CPU の数を見積もることから開始します。次の図は、「アイデンティティーベースの通信の例」で説明したアイデンティティーベースの通信シナリオの論理アーキテクチャーを示しています。
次の表は、配備のエンドユーザーと直接インタフェースをとる、論理アーキテクチャーのプレゼンテーション層のコンポーネントを示しています。この表には、技術要件の分析から得られた基準 CPU の見積もり、ユースケース、具体的な使用パターン分析、および同種の配備に関する過去の経験が反映されています。
表 5–1 アクセスユーザーのエントリポイントを含むコンポーネントの CPU の見積もり
コンポーネント |
CPU の数 |
説明 |
---|---|---|
Portal Server |
4 |
ユーザーエントリポイントであるコンポーネント。 |
Communications Express |
2 |
Portal Server のメッセージングチャネルおよびカレンダチャネルにデータを配信します。 |
ユーザーエントリポイントとなるコンポーネントは、他の 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 の数を偶数値に切り上げます。偶数値に切り上げることで、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 |