test

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

第 5 章 配備設計

ソリューションライフサイクルの配備設計フェーズでは、上位レベルの配備アーキテクチャーと下位レベルの実装仕様を設計し、ソリューションを実装する上で必要な一連の計画と仕様を作成します。プロジェクトの承認は、配備設計フェーズで行われます。

この章で説明する内容は、次のとおりです。

配備設計について

配備設計は、ソリューションライフサイクルの論理設計フェーズと技術要件フェーズで作成された配備シナリオに基づいて行います。配備シナリオには、ソリューションの論理アーキテクチャー要件とサービス品質 (QoS) 要件が含まれています。論理アーキテクチャーで特定されている、物理サーバーおよびその他のネットワークデバイスにわたるコンポーネントをマッピングして、配備アーキテクチャーを作成します。QoS 要件により、パフォーマンス、可用性、スケーラビリティー、およびその他の関連 QoS 仕様に対応するハードウェア構成についてのガイドラインが提供されます。

配備アーキテクチャーの設計は、繰り返しのプロセスです。通常、QoS 要件を再確認し、予備設計を再検討します。得失評価および保有コスト問題のバランスをとりながら QoS 要件間の相互関連を考慮することで、最終的にプロジェクトのビジネス上の目的を達成する最適なソリューションに到達します。

プロジェクトの承認

プロジェクトの承認は、配備設計フェーズで行われます。 一般には、配備アーキテクチャーを作成したあとになります。配備アーキテクチャーと、場合によっては次に説明する実装仕様も使用して、配備の実際のコストを見積もり、利害関係者の承認を得るために提出します。プロジェクトが承認された場合は、配備の完了に関する契約に署名がなされ、プロジェクトの実装に必要なリソースの確保と割り当てが行われます。

配備設計のアウトプット

配備設計フェーズでは、次の仕様および計画のいずれかを作成します。

配備設計に影響する要因

配備設計における決定にいくつかの要因が影響します。次の主要な要因を考慮します。

配備の設計方法

配備計画のほかの作業と同様に、配備設計は技術であるとともに技法でもあるため、具体的な手順とプロセスを詳細に説明することは不可能です。配備設計の成功に貢献する要因は、過去の設計経験、システムアーキテクチャーに関する知識、ビジネス領域に関する知識、およびクリエイティブな思考の応用です。

通常、配備設計は、パフォーマンス要件の達成を中心に展開し、その他の QoS 要件も達成します。採用する戦略は、設計上の意思決定による得失評価のバランスをとることでソリューションを最適化するものである必要があります。一般的に採用される方法には、次の作業が伴います。

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

ここでは、配備設計で、サービスをサポートするために必要な 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 

4 

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

Communications Express 

2 

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

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

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

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

コンポーネント 

CPU の数 

説明 

Messaging Server MTA (着信) 

1 

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

Messaging Server MTA (発信) 

1 

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

Messaging Server MMP

1 

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

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

1 

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

Access Manager

2 

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

Calendar Server (バックエンド)

2 

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

Directory Server

2 

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

Web Server

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 の数を偶数値に切り上げます。偶数値に切り上げることで、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 

セキュリティー保護されたトランザクションのためのプロセッサ要件の見積もり

セキュリティー保護されたデータ転送には、SSL (Secure Seckets Layer) や TLS (Transport Layer Security) など、セキュリティー保護された転送プロトコルを通じたトランザクションの処理が伴います。多くの場合、セキュリティー保護された転送を通じて処理されるトランザクションは、セキュリティー保護されたセッションの確立 (ハンドシェークと呼ばれる) および転送データの暗号化と復号化のために、追加の処理能力を必要とします。使用する暗号化アルゴリズム (たとえば、40 ビットまたは 128 ビットの暗号化アルゴリズム、など) によっては、かなりの追加処理能力が必要になることもあります。

セキュリティー保護されたトランザクションを、保護されていないトランザクションと同一レベルで実行するには、追加の処理能力を計画する必要があります。トランザクションおよびそれを処理する Sun JavaTM Enterprise System サービスの性質によっては、セキュリティー保護されたトランザクションの処理に、保護されていないトランザクションの場合の 4 倍の処理能力が必要になることもあります。

セキュリティー保護されたトランザクションを処理するための処理能力を見積もるには、ユースケースを分析し、セキュリティー保護された転送を必要とするトランザクションの割合を求めます。セキュリティー保護されたトランザクションと保護されないトランザクションのパフォーマンス要件が同じであれば、セキュリティー保護されたトランザクションに必要な追加の処理能力を考慮して CPU の見積もりを調整します。

場合によっては、セキュリティー保護された転送が認証時にだけ必要になることもあります。システムに対するユーザーの認証が完了すれば、データの転送に追加のセキュリティー対策は必要なくなります。また、場合によっては、セキュリティー保護された転送がすべてのトランザクションで求められることもあります。

たとえば、オンラインの電子商取引サイトで製品カタログを参照する場合、顧客が商品の選択を終え、購入のための支払い手続きを開始するまでは、すべてのトランザクションはセキュリティー保護の必要がありません。しかし、銀行や仲介取引業向けの配備では、ほとんど、またはすべてのトランザクションをセキュリティー保護し、セキュリティー保護されたトランザクションと、保護されていないトランザクションの両方に同じパフォーマンス標準を適用する必要があります。

セキュリティー保護されたトランザクションのための CPU の見積もり

ここでは、引き続き同じ配備例を使用して、セキュリティー保護されたトランザクションと保護されないトランザクションの両方を含む理論上のユースケースに基づいて CPU 要件を計算する方法について説明します。

セキュリティー保護されたトランザクションの CPU 要件を見積もるには、次の計算を行います。

  1. 前節の、「プロセッサ要件の見積もりの例」に示されている CPU 見積もりの基準値から開始します。

  2. セキュリティー保護された転送を必要とするトランザクションの割合を計算し、セキュリティー保護されたトランザクションの CPU 見積もりを計算します。

  3. セキュリティー保護されないトランザクションによって減少する分の CPU 見積もりを計算します。

  4. セキュリティー保護されたトランザクションと保護されないトランザクションの見積もりを集計し、合計 CPU 見積もりを計算します。

  5. 合計 CPU 見積もりを偶数値に切り上げます。

「セキュリティー保護されたトランザクションのための CPU の見積もり」は、次を前提とした Portal Server の場合のユースケースおよび使用パターン分析に基づいた計算例を示しています。

表 5–5 セキュリティー保護されたトランザクションのための CPU の見積もりの修正

手順 

説明 

計算 

結果 

1 

すべての Portal Server トランザクションの基準見積もりから始めます。 

「ユースケースによるピーク負荷の調査」から、基準見積もり値は 4 CPU です。

- - - - - 

2 

セキュリティー保護されるトランザクションの追加の CPU 見積もりを計算します。セキュリティー保護されたトランザクションには、保護されないトランザクションの 4 倍の CPU 能力が必要であると仮定します。 

基準見積もり値の 10% がセキュリティー保護された転送を必要とします。 

 

0.10 x 4 CPU = 0.4 CPU

 

4 倍して、セキュリティー保護されたトランザクションのための CPU を増やします。 

 

4 x 0.4 = 1.6 CPU

1.6 CPU 

3 

セキュリティー保護されないトランザクションによって減少する分の CPU 見積もりを計算します。 

基準見積もり値の 90% が、セキュリティー保護されない転送です。 

 

0.9 x 4 CPU = 3.6 CPU

3.6 CPU 

4 

セキュリティー保護されるトランザクションと保護されないトランザクションの調整後の合計 CPU 見積もりを計算します。 

セキュリティー保護される場合の見積もり + セキュリティー保護されない場合の見積もり = 合計 

 

1.6 CPU + 3.6 CPU = 5.2 CPU

5.2 CPU 

5 

偶数値に切り上げます。 

5.2 CPU ==> 6 CPU

6 CPU 

この例でのセキュリティー保護されるトランザクションのための計算に基づいて、追加の 2 CPU と 4G バイトのメモリを加算して 「セキュリティー保護されたトランザクションのための CPU の見積もり」の CPU 見積もりの合計を修正すると、Portal Server について次の合計が得られます。

コンポーネント 

CPU の数 

メモリ 

Portal Server 

6 

12G バイト 

SSL トランザクション処理の専用ハードウェア

SSL アクセラレータカードなどの特殊なハードウェアデバイスを使用して、セキュリティー保護されたセッションの確立およびデータの暗号化と復号化を処理するための追加の処理能力を供給することができます。SSL 操作に特化されたハードウェアを使用した場合、その処理能力は一部の特定の SSL 処理専用に使用され、通常は、セキュリティー保護されたセッションを確立するための「ハンドシェーク」処理だけに使用されます。

このハードウェアは、配備の最終的なアーキテクチャーにメリットをもたらす可能性があります。しかし、これは特殊なハードウェアであるため、まず、セキュリティー保護されたトランザクションのパフォーマンス要件を CPU の処理能力単位で見積もり、そのあとで追加負荷を処理する専用ハードウェアの導入メリットを検討してください。

専用ハードウェアの導入を検討するときは、ユースケースがそのハードウェアの利用をサポートするかどうか (たとえば、多数の SSL ハンドシェーク処理を必要とするユースケースなど)、また、このようなハードウェアによって設計にもたらされる追加処理層の複雑さを考慮します。この複雑さには、これらのデバイスのインストール、設定、テスト、管理が含まれます。

可用性戦略の決定

可用性要件のための戦略を策定する際は、コンポーネントのインタラクションと使用パターンの分析に基づいて、検討する可用性ソリューションを決定します。コンポーネントごとに分析を行い、可用性とフェイルオーバーの要件に最も適したソリューションを決定します。

次に、可用性戦略の決定に役立つ情報の例を示します。

可用性戦略は、「リソースの最適な使用方法の設計」で説明する保守性要件も考慮した上で選択する必要があります。膨大な管理や保守を必要とする複雑なソリューションは避けます。

可用性戦略

Java Enterprise System 配備の可用性戦略には、次のものがあります。

以降の各節では、さまざまなレベルのロードバランス、フェイルオーバー、およびサービスのレプリケーションを提供する可用性ソリューションの例をいくつか示します。

シングルサーバーシステム

サービスのすべてのコンピュータリソースを 1 つのサーバーに配置します。サーバーに障害が発生した場合、サービス全体が失敗します。

図 5–2 シングルサーバーシステム

パフォーマンス要件を満たすために 10 CPU を搭載したシングルサーバーを示しています。

Sun は、次の利点を提供するハイエンドサーバーを提供しています。

通常、ハイエンドサーバーは、同等の機能を持つマルチサーバーシステムより高価になります。ただしシングルサーバーでは、管理、監視、データセンターでのサーバーのホスティング費用が軽減されます。ロードバランス、フェイルオーバー、障害シングルポイントの除去は、マルチサーバーシステムのほうが柔軟に対応できます。

水平方向の冗長システム

ロードバランスとフェイルオーバーの両方を提供する平行冗長サーバーを使用することで、いくつかの方法で可用性を向上できます。次の図は、N+1 フェイルオーバーシステムを構成する 2 つのレプリカサーバーを示しています。N+1 システムには、1 つのサーバーで障害が発生した場合に、その処理能力の 100% を提供するための追加サーバーが含まれます。

図 5–3 2 つのサーバーで構成される N+1 フェイルオーバーシステム

10 CPU のパフォーマンス要件を満たすために、それぞれが 10 の CPU を搭載した 2 つのレプリカサーバーを示しています。

上の「水平方向の冗長システム」に示される各サーバーは、同一処理能力を持ちます。1 つのサーバーが単独でパフォーマンス要件を満たします。もう一方のサーバーは、バックアップとしてサービスに適用された場合に 100% のパフォーマンスを提供します。

N+1 フェイルオーバー設計の利点は、フェイルオーバー状況でも 100% の処理能力を提供できることです。欠点には、1 つのサーバーはフェイルオーバー状況でだけ使用されるスタンバイであるため、パフォーマンス全体の向上なしにハードウェアコストが上昇することが挙げられます。

次の図は、2 つのサーバーの間でパフォーマンスを分散するロードバランスとフェイルオーバーを実装するシステムを示しています。

図 5–4 2 つのサーバー間のロードバランスとフェイルオーバー

10 CPU のパフォーマンス要件を満たすために、それぞれが 6 CPU を搭載した 2 つのサーバーを示しています。

上の「水平方向の冗長システム」で示されているシステムでは、一方のサーバーに障害が発生した場合に、処理能力は低下しますが、すべてのサービスを利用できます。残ったサーバーは 6 CPU の処理能力を提供します。 これは、10 CPU という要件の 60% に相当します。

この設計の利点は、両方のサーバーを利用可能な状態では、2 CPU の潜在処理能力を追加されることです。

次の図は、パフォーマンス向上とロードバランス用に、多数のサーバーの間でパフォーマンスを分散する例を示しています。

図 5–5 n サーバー間での負荷の分散

10 CPU のパフォーマンス要件を満たすために、それぞれが 2 CPU を搭載した 5 つのサーバーを示しています。

「水平方向の冗長システム」に示される設計では 5 つのサーバーが使用されるため、1 つのサーバーに障害が発生した場合に、残りのサーバーが 8 CPU の処理能力を提供します。 これは、10 CPU のパフォーマンス要件の 80% に相当します。この設計に 2 CPU の処理能力を持つサーバーを追加すると、効率的に N+1 設計を実現できます。1 つのサーバーに障害が発生しても、残りのサーバーによってパフォーマンス要件は 100% 満たされます。

この設計には、次のような利点があります。

ただし、サーバーを追加することで、管理と保守のコストは大きく上昇します。データセンターでのサーバーのホスティング費用も考慮する必要があります。サーバーの追加投入によるメリットは、ある時点から減少に転じます。

Sun Cluster ソフトウェア

高い可用性 (4 ナインまたは 5 ナインなど) が必要となる状況では、可用性設計の一部として Sun Cluster ソフトウェアの利用を検討することができます。クラスタシステムは、冗長サーバーとストレージやその他のネットワークリソースを結合したものです。クラスタ内のサーバーは、継続的に相互通信します。1 つのサーバーがダウンした場合、クラスタ内の残りのデバイスはそのサーバーを分離し、障害のあるノードから別のノードにアプリケーションまたはデータをフェイルオーバーします。このフェイルオーバープロセスは、比較的迅速に行われるため、システムの利用者がサービスの中断を感じることはほとんどありません。

Sun Cluster ソフトウェアは、専用ハードウェアの追加と、設定、管理、維持のための特別なスキルを必要とします。

可用性設計の例

ここでは、「アイデンティティーベースの通信の例」で説明されている、1,000 〜 5,000 人の従業員を持つ中規模企業用の、アイデンティティーベースの通信ソリューションに基づいた、可用性戦略の 2 つの例を示します。1 つ目の可用性戦略では、Messaging Server のロードバランスについて説明します。2 つ目では、Sun Cluster ソフトウェアを使用するフェイルオーバーソリューションについて説明します。

Messaging Server のロードバランスの例

次の表は、論理アーキテクチャー内の論理 Messaging Server コンポーネントの CPU 能力の見積もり値を示しています。この表は、「CPU 見積もりの更新」の節で計算した最終見積もり値を再掲しています。

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

コンポーネント 

CPU の数 

メモリ 

Messaging Server (MTA、着信) 

2 

4G バイト 

Messaging Server (MTA、発信) 

2 

4G バイト 

Messaging Server (MMP) 

2 

4G バイト 

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

2 

4G バイト 

たとえば、技術要件フェーズで、次のサービス品質要件が指定されたとします。

可用性要件を満たすには、各 Messaging Server コンポーネントについてインスタンスを 2 つずつ、それぞれを異なるハードウェアサーバーに提供します。一方のコンポーネントのサーバーに障害が発生した場合、もう一方がサービスを提供します。次の図は、この可用性戦略のネットワーク図です。

Messaging Server MMP および MTA の各コンポーネントの可用性を示すアーキテクチャー図。

上の図では、CPU の数は元の見積もりの 2 倍になっています。CPU の数は、次の理由から 2 倍になりました。

Sun Cluster ソフトウェアを使用したフェイルオーバーの例

次の図は、Calendar Server バックエンドおよび Messaging Server メッセージストアのフェイルオーバー戦略の例を示しています。Calendar Server バックエンドおよびメッセージストアは、別個のハードウェアサーバーにレプリケートされ、Sun Cluster ソフトウェアを使用してフェイルオーバー用に設定されます。CPU の数および対応するメモリは、Sun Cluster で各サーバー上にレプリケートされます。

図 5–6 Sun Cluster ソフトウェアを使用したフェイルオーバー設計

Sun Cluster ソフトウェアを使用して配備した、フェイルオーバー用の Calendar Server および Message Server ストレージを示すアーキテクチャー図。

ディレクトリサービスのレプリケーションの例

ディレクトリサービスをレプリケートして複数のサーバーにトランザクションを分散すると、高い可用性が得られます。Directory Server により、サービスのレプリケーションためのさまざまな戦略が提供されます。これには、次の戦略が含まれます。

Directory Server の可用性戦略は複雑な事項であり、このマニュアルの範囲に含まれません。以降の各節、「シングルマスターレプリケーション」および 「マルチマスターレプリケーション」では、基本的なレプリケーション戦略の概要を説明します。詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』の第 12 章「Designing a Highly Available Deployment」を参照してください。

シングルマスターレプリケーション

次の図は、基本的なレプリケーション概念を表すシングルマスターレプリケーションを示しています。

図 5–7 単一マスター複製の例

シングルマスターレプリケーション戦略のデータフローを示す図。

シングルマスターレプリケーションでは、Directory Server の 1 つのインスタンスがマスターディレクトリデータベースを管理し、すべての変更を記録します。マスターデータベースは、任意の数のコンシューマデータベースにレプリケートされます。Directory Server のコンシューマインスタンスは、読み取り操作および検索操作用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。

シングルマスターレプリケーションには、次の利点があります。

マルチマスターレプリケーション

次の図は、ディレクトリアクセスをグローバル規模で分散するために使用される可能性のあるマルチマスターレプリケーション戦略を示しています。

マルチマスターレプリケーションでは、Directory Server の 1 つ以上のインスタンスがマスターディレクトリデータベースを管理します。各マスターは、マスターデータベースの同期手順を規定するレプリケーションアグリーメントを持ちます。各マスターは、任意の数のコンシューマデータベースに対してレプリケートを行います。シングルマスターレプリケーションの場合と同様に、Directory Server のコンシューマインスタンスは、読み取りアクセスおよび検索アクセス用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。

図 5–8 マルチマスターレプリケーションの例

マルチマスターレプリケーション戦略のデータフローを示す図。

マルチマスターレプリケーション戦略では、シングルマスターレプリケーションのすべての利点が提供されることに加えて、マスターに対する更新にロードバランスを実行できる可用性戦略が提供されます。また、ディレクトリ操作のローカル制御を提供する可用性戦略も実装できます。 このことは、グローバル規模で分散しているデータセンターを持つ企業にとって重要な考慮事項です。

スケーラビリティーのための戦略の決定

スケーラビリティーとは、システムに処理能力を追加する能力です。 これは、通常はシステムリソースの追加によって行われ、配備アーキテクチャーの変更はスケーラビリティーの対象に含まれません。要件を分析するときに、通常は、ビジネス要件と使用パターンの分析に基づいて、システムの成長予測が立てられます。システムのユーザー数や、目的達成に必要なシステムの処理能力に関する予想は、配備されるシステムの実際の数値とは大きく異なることが珍しくありません。予想の不一致に対応できるだけの十分な柔軟性を設計に盛り込む必要があります。

スケーラブルな設計とは、システムが追加リソースでアップグレードされるまで、増大する負荷を処理できる、十分な潜在処理能力が含まれている設計です。スケーラブルな設計では、システムの設計を変更することなく、増大する負荷の処理に容易に対応できます。

潜在処理能力

潜在処理能力は、例外的なピーク負荷に容易に対応できるように、パフォーマンスと可用性のためのリソースをシステムに含めることで得られるスケーラビリティーです。また、配備されるシステムで潜在処理能力がどのように使用されるかを監視することも、リソースの追加によるシステムの規模拡大が必要となるタイミングを計る上で役立ちます。潜在処理能力は、設計に安全性を組み込む手法の 1 つです。

ユースケースの分析は、例外的なピーク負荷が発生するシナリオを特定する上で役立ちます。例外的なピーク負荷の分析と、予期せぬ急成長に対応するための方法を考慮して、システムに安全性をもたらす潜在処理能力を設計します。

システム設計は、想定される負荷を妥当な期間にわたって処理できる必要があります。 この期間は、通常、運用開始後の最初の 6 〜 12 か月です。定期的に行われる保守を通じて、必要に応じてリソースを追加したり、処理能力を向上します。システムの定期的なアップグレードをスケジューリングできれば理想的ですが、多くの場合、処理能力向上の必要性を予測することは困難です。システムをいつアップグレードするかは、リソースの慎重な監視と、ビジネス予測に頼ることになります。

ソリューションを段階的に実装する計画の場合は、各フェーズで予定されるその他の向上内容に合わせて、システムの処理能力の向上をスケジューリングする必要がある場合もあります。

スケーラビリティーの例

この節の例では、Messaging Server を実装するソリューションの水平方向のスケーリングおよび垂直方向のスケーリングを説明します。垂直方向のスケーリングの場合、CPU をサーバーに追加することで、増大する負荷を処理します。水平方向のスケーリングの場合、負荷の分散に使用するサーバーを追加することで、増大する負荷を処理します。

この例の基準は、ロードバランスのために分散された 2 つのメッセージストアインスタンスによってサポートされる 50,000 ユーザーベースを前提としています。各サーバーには 2 つの CPU があり、合計で 4 CPU です。次の図は、25 万人または 200 万人のユーザーに増大する負荷を処理するために、このシステムの規模をどのように拡大できるかを示しています。

注 –

「スケーラビリティーの例」は、垂直方向のスケーリングと水平方向のスケーリングの違いを示しています。この図には、ロードバランス、フェイルオーバー、使用パターンの変化など、スケーリング時に考慮するべきその他の要因は示されていません。

図 5–9 水平方向のスケーリングと垂直方向のスケーリングの例

基準のアーキテクチャーと比較して、垂直方向のスケーリングおよび水平方向のスケーリングを示すアーキテクチャー図。

パフォーマンス障害の特定

成功する配備設計の鍵の 1 つには、潜在的なパフォーマンス障害を特定し、それらを回避するための戦略を策定することです。パフォーマンス障害は、データにアクセスする速度が指定されたシステム要件に満たない場合に発生します。

システム内のデータアクセスポイントに関する次の表に示されているように、障害はハードウェアのクラス別に分類されます。この表は、各ハードウェアクラスにおける障害に対する対応策も示しています。

表 5–7 データアクセスポイント

ハードウェアクラス 

相対アクセス速度 

パフォーマンス改善のための対応策 

プロセッサ 

ナノ秒 

垂直方向のスケーリング: 処理能力の追加、プロセッサキャッシュの強化を行います 

水平方向のスケーリング: ロードバランス用の並列処理能力を追加します 

システムメモリ (RAM) 

マイクロ秒 

システムメモリを特定の作業専用にします 

垂直方向のスケーリング: メモリを追加します 

水平方向のスケーリング: 並列処理およびロードバランス用に追加インスタンスを作成します 

ディスクの読み書き 

ミリ秒 

ディスクアレイ (RAID) でディスクアクセスを最適化します 

ディスクアクセスを、読み取り専用や書き込み専用など、特定の機能専用にします 

頻繁にアクセスされるデータをシステムメモリにキャッシュします 

ネットワークインタフェース 

ネットワーク上のノードの帯域幅とアクセス速度によって異なります 

帯域幅を増やします 

セキュリティー保護されたデータを転送する際、アクセラレータハードウェアを追加します 

ネットワーク内のノードのパフォーマンスを改善して、データを利用しやすくします 

注 –

「パフォーマンス障害の特定」は、相対アクセス速度に基づくハードウェアクラスを示しています。ディスクなど、低速なアクセスポイントは、障害の原因となる可能性が高いことを意味しています。また、大きな負荷を処理する能力がないプロセッサも、障害の原因となる可能性があります。

通常、配備設計は、配備内の各コンポーネントとそれらの依存関係について、基準となる処理能力の見積りから始めます。その後、システムメモリおよびディスクアクセスに関連する障害の回避方法を決定します。最後に、ネットワークインタフェースを調べて潜在的な障害を特定し、それらを克服する戦略に力を注ぎます。

ディスクアクセスの最適化

配備設計で不可欠な要素の 1 つは、LDAP ディレクトリなど、頻繁にアクセスされるデータセットに対するディスクアクセスの速度です。ディスクアクセスは、データに対する最も低速なアクセスであり、パフォーマンス障害の原因となる可能性があります。

ディスクアクセスを最適化する方法の 1 つは、書き込み操作と読み取り操作を分けることです。書き込み操作が読み取り操作より負荷が大きいばかりでなく、読み取り操作 (LDAP ディレクトリに対する検索操作) は、通常、書き込み操作 (LDAP ディレクトリのデータに対する更新) よりはるかに頻繁に実行されます。

ディスクアクセスを最適化する別の方法は、ディスクをさまざまな種類の入出力操作の専用とすることです。たとえば、トランザクションログやイベントログなどの Directory Server のロギング操作と、LDAP の読み書き操作に別個のディスクアクセスを提供します。

また、読み書き操作専用の Directory Server のインスタンスを 1 つ以上実装すること、読み取りと検索のためのアクセス用に、ローカルサーバーに分散された、レプリケートされたインスタンスを使用することも検討します。連鎖およびリンクのオプションも、ディレクトリサービスへのアクセスを最適化するために利用できます。

ディスクアクセスの計画におけるさまざまな要因については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』の第 6 章「Defining System Characteristics」を参照してください。この章では、次の内容が取り上げられています。

リソースの最適な使用方法の設計

配備設計は、QoS 要件を満たすために必要となるリソースを見積もるだけではありません。配備設計では、可能な選択肢をすべて分析し、コストを最小化しつつ QoS 要件を満たす最善のソリューションの選択も行います。ある領域での利点が、別の領域のコストで相殺されないように、設計上のそれぞれの意思決定による得失評価を分析する必要があります。

たとえば、可用性のための水平方向のスケーリングは、全体的な可用性を向上するかもしれませんが、保守とサービスのコストは上昇します。パフォーマンスのための垂直方向のスケーリングは、費用効率良く処理能力を向上できるかもしれませんが、一部のサービスでは追加された処理能力を活用し切れない可能性があります。

設計戦略を完成させる前に、リソースの使用と提案ソリューションの全体的なメリットのバランスについて、決定事項をよく見直してください。通常、この分析では、ある領域のシステム品質が、別のシステム品質にどのように影響するかを調べます。次の表は、いくつかのシステム品質と、それに対応するリソース管理に関する考慮事項を示しています。

表 5–8 リソース管理に関する考慮事項

システム品質 

説明 

パフォーマンス

個々のサーバーに CPU を集中させるパフォーマンスソリューションで、サービスは処理能力を効率的に活用できるか。(たとえば、一部のサービスでは、効率的に利用できる CPU の数に制限がある。) 

潜在処理能力 

採用した戦略により、想定されるパフォーマンスを超過した負荷が処理されるか。 

過度な負荷の処理に、サーバーの垂直方向のスケーリング、他のサーバーへのロードバランスのどちらを使用するか、または両方使用するか。 

配備の規模拡大に関する次回の目標を達成するまで、例外的なピーク負荷を処理できるだけの潜在処理能力があるか。 

セキュリティー

セキュリティー保護されたトランザクションの処理に必要なパフォーマンス上のオーバーヘッドは十分に考慮されているか。 

可用性

水平方向の冗長性ソリューションで、長期的な保守コストを十分に想定しているか。 

システムの保守に必要な予定された停止時間は考慮されているか。 

ハイエンドサーバーとローエンドサーバーのコストのバランスはとれているか。 

スケーラビリティー

配備の規模拡大に関する一連の達成目標は設定されているか。 

配備の規模拡大に関する次回の目標を達成するまで、想定される負荷の増大に対応できるだけの十分な潜在処理能力を提供する戦略を持っているか。 

保守性

管理、監視、保守のコストを踏まえて可用性を設計しているか。 

管理コストを作成するために、委任管理ソリューション (エンドユーザーが一部の管理作業を実行できるようにする) を検討したか。 

リスクの管理

サービス品質要件や使用パターンの分析など、配備設計が基づく情報の多くは、実証的なデータではなく、ビジネス分析から最終的に得られた予測に基づいています。これらの予測は、ビジネス動向での予期しない状況、データ収集方法上の問題、あるいは単なる人為ミスなど、さまざまな理由から正確でない可能性があります。配備設計を完了する前に、設計の土台となった分析結果を再確認し、見積もりや予測のずれが設計で十分に考慮されているかどうかを確認してください。

たとえば、使用パターンの分析でシステムの実際の使用状況が低く見積もられている場合、発生するトラフィックに対応し切れないシステムを構築してしまうリスクが生じます。予定を下回るパフォーマンスを示す設計は、失敗と見なされます。

一方で、必要処理能力より数倍強力なシステムを構築した場合、別の場所で使用できたはずのリソースを無駄にすることになります。重要なことは、要件に加えて安全性のマージンを含めるが、リソースの浪費は回避するということです。

リソースの浪費も設計の失敗をもたらします。 十分に活用されなかったリソースを別の領域に適用できたためです。また、行き過ぎたソリューションを適用することは、利害関係者に、誠実に契約を履行していないと見なされる可能性もあります。

配備例のアーキテクチャー

次の図は、この白書ですでに紹介した配備例の完全な配備アーキテクチャーを示しています。この図は、配備アーキテクチャーを表現する方法を示しています。

注意 – 注意 –

次の図の配備アーキテクチャーは、説明のためのアーキテクチャーに過ぎません。実際に設計、構築、またはテストされた配備を示しているわけではないので、配備計画のアドバイスと見なさないでください。

図 5–10 配備例のアーキテクチャー

この図では、配備アーキテクチャーのレイアウト例を示しています。