Sun Java Enterprise System 2005Q4 配備計画ガイド

プロセッサ要件の見積もり

ここでは、配備設計で、サービスをサポートするために必要な CPU プロセッサ数および対応するメモリを見積もるプロセスについて説明します。また、通信配備シナリオの例を使用して、見積もりプロセスを段階的に説明します。

CPU 処理能力の見積もりは、次のことを考慮して繰り返し検討します。

見積もりプロセスには、次の手順が含まれます。これらの手順の順序は、あまり重要ではありませんが、最終結果に影響する要因を分析する 1 つの方法を提供するものです。

  1. システムへのユーザーエントリポイントとなるコンポーネントの、基準となる CPU の見積もりを決定します。

    設計上の意思決定の 1 つは、CPU をフルに搭載するか、一部だけ搭載するかについてです。CPU をフルに搭載すると、システムの処理能力は最大化されます。処理能力を向上するために、保守コストおよび場合によっては CPU の追加による停止時間が発生します。増大するパフォーマンス要件を満たすために、マシンの追加を選択できる場合もあります。

    CPU を一部だけ搭載した場合は、保守コストをただちに発生させることなく、パフォーマンス要件に対応できる余裕が持てます。ただし、活用し切れないシステムへの先行投資費用が発生します。

  2. コンポーネント間のインタラクションを考慮して、CPU の見積もりを調整します。

    論理アーキテクチャーのコンポーネント間のインタラクションを調べて、依存コンポーネントのためにさらなる搭載が必要であるかを決定します。

  3. 使用パターン分析で特定のユースケースを調べてシステムのピーク負荷を割り出し、ピーク負荷を処理するコンポーネントに対する調整を行います。

    最も重み付けされた (最も負荷を必要とする) ユースケースから始めて、各ユースケースに進み、計画したすべての使用シナリオを考慮したことを確認します。

  4. CPU の見積もりを調整して、セキュリティー、可用性、スケーラビリティーの各要件を反映します。

この見積もりプロセスは、実際に必要な処理能力を決定するための開始点となります。通常は、これらの見積もりに基づいてプロトタイプ配備を作成し、その後、想定されるユースケースに対して厳格なテストを実行します。テストを繰り返したあとに初めて、配備設計の実際の処理要件を決定できます。

プロセッサ要件の見積もりの例

ここでは、配備例に必要な処理能力を見積もる 1 つの方法を示します。配備例は、1,000 〜 5,000 人の従業員を持つ中規模企業用のアイデンティティーベースによる通信ソリューションの論理アーキテクチャーに基づいています。「アイデンティティーベースの通信の例」の節を参照してください。

この例で使用される CPU とメモリの値は、図で使用するための任意の見積もり結果に過ぎません。これらの値は、理論上の例が基になっている任意のデータから計算されています。プロセッサ要件を見積もるには、さまざまな要因を徹底的に分析する必要があります。この分析には次の情報が含まれているものとしますが、これらに限定されません。


注意 – 注意 –

これらの例に示される情報は、何らかの具体的な実装の提案を示すものではなく、システムの設計プロセスの説明を目的に記載されています。


ユーザーエントリポイント用の基準 CPU の見積もり

ユーザーエントリポイントとなる各コンポーネントの想定負荷を処理するために必要な CPU の数を見積もることから開始します。次の図は、「アイデンティティーベースの通信の例」で説明したアイデンティティーベースの通信シナリオの論理アーキテクチャーを示しています。

図 5–1 アイデンティティーベースの通信シナリオの論理アーキテクチャー

多層アーキテクチャーに配備されたアイデンティティーベースの通信シナリオの論理コンポーネントを示す図。

次の表は、配備のエンドユーザーと直接インタフェースをとる、論理アーキテクチャーのプレゼンテーション層のコンポーネントを示しています。この表には、技術要件の分析から得られた基準 CPU の見積もり、ユースケース、具体的な使用パターン分析、および同種の配備に関する過去の経験が反映されています。

表 5–1 アクセスユーザーのエントリポイントを含むコンポーネントの CPU の見積もり

コンポーネント 

CPU の数 

説明 

Portal Server 

ユーザーエントリポイントであるコンポーネント。 

Communications Express 

Portal Server のメッセージングチャネルおよびカレンダチャネルにデータを配信します。 

サービス依存関係に関する CPU 見積もり値の取り込み

ユーザーエントリポイントとなるコンポーネントは、他の Java Enterprise System コンポーネントからのサポートを必要とします。パフォーマンス要件の特定を継続するには、必要となる他のコンポーネントからのサポートを考慮して、パフォーマンスの見積もり値を組み込みます。コンポーネント間のインタラクションの種類は、論理アーキテクチャーを設計する際に詳細化します。「論理アーキテクチャーの例」の節で、論理アーキテクチャーの例を参照してください。

表 5–2 サポートするコンポーネントのための CPU の見積もり

コンポーネント 

CPU の数 

説明 

Messaging Server MTA (着信) 

Communications Express および電子メールクライアントからの着信メールメッセージをルーティングします。 

Messaging Server MTA (発信) 

発信メールメッセージを受取人に配信します。 

Messaging Server MMP

電子メールクライアントの Messaging Server メッセージストアにアクセスします。 

Messaging Server STR (メッセージストア)

電子メールメッセージを取得および保存します。 

Access Manager

認証と承認のサービスを提供します。 

Calendar Server (バックエンド)

Communications Express、Calendar Server フロントエンドのカレンダデータを取得および保存します。 

Directory Server

LDAP ディレクトリサービスを提供します。 

Web Server

Portal Server および Access Manager に対して Web コンテナサポートを提供します。 

追加の CPU サイクルは不要です。 

ユースケースによるピーク負荷の調査

ユースケースおよび使用パターン分析に戻り、ピーク負荷の領域を特定し、CPU の見積もりを調整します。

たとえば、この例に関して次のようなピーク負荷状況を特定したとします。

このピーク負荷時の使用パターンを考慮に入れるには、これらのサービスを提供するコンポーネントに対する調整を行います。次の表は、このピーク負荷時の使用パターンを考慮した調整の概要を示しています。

表 5–3 ピーク負荷による CPU 見積もりの調整

コンポーネント 

CPU の数 (調整後) 

説明 

Messaging Server MTA 着信 

ピーク時の着信電子メール用に 1 CPU を追加します 

Messaging Server MTA 発信 

ピーク時の送信電子メール用に 1 CPU を追加します 

Messaging Server MMP 

増加する負荷用に 1 CPU を追加します 

Messaging Server STR (メッセージストア) 

増加する負荷用に 1 CPU を追加します 

Directory Server 

増加する LDAP 検索用に 1 CPU を追加します 

その他の負荷条件による見積もりの修正

CPU の見積もりを続行し、負荷に影響を与える可能性のあるその他のサービス品質要件を考慮に入れます。

CPU 見積もりの更新

通常は、CPU の数を偶数値に切り上げます。偶数値に切り上げることで、2 つの物理サーバーに CPU 見積もりを均等に分割できるとともに、潜在処理能力の小さな要因が追加されます。ただし、サービスのレプリケーションに対する特定のニーズに基づいて切り上げる必要があります。

原則として、CPU ごとに 2G バイトのメモリを許容します。必要な実際のメモリは、特定の使用パターンによって異なります。 これは、テストで決定できます。

次の表は、アイデンティティーベースの通信に関する最終見積もりの例です。これらの見積りには、セキュリティーおよび可用性のために追加される可能性のある、追加の処理能力は含まれていません。セキュリティーおよび可用性のための各合計は、この後の節で加えられます。

表 5–4 サポートするコンポーネントのための CPU 見積もりの調整

コンポーネント 

CPU の数 

メモリ 

Portal Server 

8G バイト 

Communications Express 

4G バイト 

Messaging Server (MTA、着信) 

4G バイト 

Messaging Server (MTA、発信) 

4G バイト 

Messaging Server (MMP) 

4G バイト 

Messaging Server (メッセージストア) 

4G バイト 

Access Manager 

4G バイト 

Calendar Server 

4G バイト 

Directory Server 

8G バイト (3 CPU/6G バイトメモリから切り上げ) 

Web Server