ソリューションライフサイクルの配備設計フェーズでは、上位レベルの配備アーキテクチャーと下位レベルの実装仕様を設計し、ソリューションを実装する上で必要な一連の計画と仕様を作成します。プロジェクトの承認は、配備設計フェーズで行われます。
この章で説明する内容は、次のとおりです。
配備設計は、ソリューションライフサイクルの論理設計フェーズと技術要件フェーズで作成された配備シナリオに基づいて行います。配備シナリオには、ソリューションの論理アーキテクチャー要件とサービス品質 (QoS) 要件が含まれています。論理アーキテクチャーで特定されている、物理サーバーおよびその他のネットワークデバイスにわたるコンポーネントをマッピングして、配備アーキテクチャーを作成します。QoS 要件により、パフォーマンス、可用性、スケーラビリティー、およびその他の関連 QoS 仕様に対応するハードウェア構成についてのガイドラインが提供されます。
配備アーキテクチャーの設計は、繰り返しのプロセスです。通常、QoS 要件を再確認し、予備設計を再検討します。得失評価および保有コスト問題のバランスをとりながら QoS 要件間の相互関連を考慮することで、最終的にプロジェクトのビジネス上の目的を達成する最適なソリューションに到達します。
プロジェクトの承認は、配備設計フェーズで行われます。 一般には、配備アーキテクチャーを作成したあとになります。配備アーキテクチャーと、場合によっては次に説明する実装仕様も使用して、配備の実際のコストを見積もり、利害関係者の承認を得るために提出します。プロジェクトが承認された場合は、配備の完了に関する契約に署名がなされ、プロジェクトの実装に必要なリソースの確保と割り当てが行われます。
配備設計フェーズでは、次の仕様および計画のいずれかを作成します。
配備アーキテクチャー: 論理アーキテクチャーから物理環境へのマッピングを表す、上位のアーキテクチャー。物理環境には、イントラネットまたはインターネット環境にあるコンピュータノード、プロセッサ、メモリ、ストレージデバイスなどのハードウェアおよびネットワークデバイスが含まれます。
実装仕様: 配備を構築するための青写真として使用される詳細な仕様です。これらの仕様は、必要なコンピュータおよびネットワークハードウェアについての詳細を示すとともに、配備ネットワークの配置を説明するものです。実装仕様には、ディレクトリ情報ツリー (DIT: Directory Information Tree) の詳細やディレクトリアクセスに定義されているグループとロールなど、ディレクトリサービスに関する仕様も含まれます。
実装計画: 企業ソフトウェアソリューションの実装におけるさまざまな側面をカバーする計画の集合です。実装計画には、次の計画が含まれます。
移行計画: 企業データの移行および企業ソフトウェアのアップグレードを行うための戦略とプロセスを説明します。移行したデータは、新しくインストールした企業アプリケーションの形式と標準に適合する必要があります。相互運用するには、すべての企業ソフトウェアは正しいリリースバージョンレベルにある必要があります。
インストール計画: 配備アーキテクチャーから派生します。 分散型の配備をインストールおよび設定するために必要なハードウェアサーバー名、インストールディレクトリ、インストール順序、各ノードのインストールタイプ、および設定情報を指定します。
ユーザー管理計画: 既存のディレクトリおよびデータベース内のデータの移行戦略、配備アーキテクチャーで指定されているレプリケーション設計を考慮に入れたディレクトリ設計仕様、およびディレクトリに新しいコンテンツをプロビジョニングする手順が含まれます。
テスト計画: 配備されたソフトウェアをテストする手順を説明します。 プロトタイプの作成とパイロット実装の具体的な計画、想定される負荷を処理する能力を判定するストレステスト、および計画した機能が期待どおり動作するかどうかを判定する機能テストが含まれます。
ロールアウト計画: 実装を計画およびテスト環境から本稼働環境に移行するための手順とスケジュールを説明します。本稼働環境への実装の移行は、通常、さまざまなフェーズで行われます。たとえば、最初のフェーズでは、限られたユーザーグループ用にソフトウェアを配備し、配備全体が完了するまで、各フェーズでユーザーベースを拡大していきます。段階的な実装には、配備全体が完了するまでの、特定のソフトウェアパッケージの計画的な実装も含まれることがあります。
障害回復計画: 予期しないシステム全体の障害からシステムを回復させる手順を説明します。回復計画には、大規模な障害と小規模な障害の両方の場合の手順が含まれます。
トレーニング計画: 新しくインストールされた企業のソフトウェアに関して、オペレータ、管理者、およびエンドユーザーをトレーニングするためのプロセスと手順を説明します。
配備設計における決定にいくつかの要因が影響します。次の主要な要因を考慮します。
論理アーキテクチャー: 論理アーキテクチャーでは、提案ソリューションの機能サービスおよびそれらのサービスを提供するコンポーネント間の相互関係が詳しく説明されています。論理アーキテクチャーを、サービスを提供する最善の方法を決定するための鍵として使用します。配備シナリオには、次に説明するサービス品質要件と対応する論理アーキテクチャーが含まれています。
サービス品質要件: サービス品質 (QoS) 要件には、ソリューションの運用に関するさまざまな条件が指定されています。QoS 要件を参照して、パフォーマンス、可用性、スケーラビリティー、保守性などのサービス品質上の目標を達成する戦略を策定します。配備シナリオには、前述の論理アーキテクチャーをサービス品質要件と対応付けて記述します。
使用パターンの分析: ソリューションライフサイクルの技術要件フェーズで作成された使用パターンの分析結果は、配備されたシステムに対する負荷とストレスを見積もる上で役立つ情報を提供します。使用パターンの分析結果を使用して、パフォーマンス障害を特定するとともに、QoS 要件を満たす戦略を策定します。
ユースケース: ソリューションライフサイクルの技術要件フェーズで作成されたユースケースには、配備に対するものとして特定された、特徴のあるユーザーインタラクションが示されています。多くの場合は、最も一般的なユースケースが特定されています。ユースケースは使用パターン分析に組み込まれていますが、配備設計を評価する際は、ユースケースを参照して、それらが適切に取り上げられていることを確認する必要があります。
サービスレベル契約: サービスレベル契約 (SLA) には、最小パフォーマンス要件およびそれらの要件が満たされない場合に提供する必要のあるカスタマーサポートのレベルと範囲が規定されています。配備設計は、サービスレベル契約で規定されているパフォーマンス要件を十分に満たすものである必要があります。
総保有コスト: 配備設計では、可用性、パフォーマンス、スケーラビリティーなどの QoS 要件に対応できるソリューションを検討する必要があります。ただし、検討するソリューションごとに、そのソリューションのコストおよびそのコストが総保有コストに及ぼす影響についても考慮する必要があります。決定によって具体化する得失評価を考慮してください。 また、ビジネス制約内のビジネス要件を達成するために、リソースを最適化したことを確認してください。
ビジネス上の目的: ビジネス上の目的は、ソリューションライフサイクルのビジネス分析フェーズで明確にされるもので、それらの目的を達成する上でのビジネス要件とビジネス制約が含まれています。配備設計は、ビジネス上の目的をどれだけ達成できるかによって最終的に評価されます。
配備計画のほかの作業と同様に、配備設計は技術であるとともに技法でもあるため、具体的な手順とプロセスを詳細に説明することは不可能です。配備設計の成功に貢献する要因は、過去の設計経験、システムアーキテクチャーに関する知識、ビジネス領域に関する知識、およびクリエイティブな思考の応用です。
通常、配備設計は、パフォーマンス要件の達成を中心に展開し、その他の QoS 要件も達成します。採用する戦略は、設計上の意思決定による得失評価のバランスをとることでソリューションを最適化するものである必要があります。一般的に採用される方法には、次の作業が伴います。
プロセッサ要件の見積もり: 多くの場合、配備設計は、論理アーキテクチャーの各コンポーネントに必要な CPU の見積もりに基づきます。最大の負荷を示しているユースケースから始めて、各ユースケースに進みます。そのユースケースをサポートしているすべてのコンポーネントの負荷を考慮し、それに応じて見積もりを修正します。また、企業システムの設計に関するこれまでの経験も参考にします。
セキュリティー保護された転送のためのプロセッサ要件の見積もり: セキュリティー保護された転送を必要とするユースケースを分析して、それに応じて CPU の見積もりを修正します。
可用性とスケーラビリティーのためのサービスのレプリケーション: プロセッサの見積もりを十分に行なったあと、可用性とスケーラビリティー の QoS 要件に対応するために、設計を修正します。可用性およびフェイルオーバーの考慮事項に対処するロードバランスソリューションについて考慮します。
分析時に、設計上の意思決定による得失評価を考慮します。たとえば、可用性とスケーラビリティーの戦略がシステムの保守性 (保守) に与える影響です。また、戦略のその他のコストには何があるかなども考慮できます。
リスクの管理: ビジネス分析および技術分析の設計面を見直して、計画の早期時点で予測されていなかった可能性のあるイベントや状況に対応できるように修正を行います。
ここでは、配備設計で、サービスをサポートするために必要な 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 |
セキュリティー保護されたデータ転送には、SSL (Secure Seckets Layer) や TLS (Transport Layer Security) など、セキュリティー保護された転送プロトコルを通じたトランザクションの処理が伴います。多くの場合、セキュリティー保護された転送を通じて処理されるトランザクションは、セキュリティー保護されたセッションの確立 (ハンドシェークと呼ばれる) および転送データの暗号化と復号化のために、追加の処理能力を必要とします。使用する暗号化アルゴリズム (たとえば、40 ビットまたは 128 ビットの暗号化アルゴリズム、など) によっては、かなりの追加処理能力が必要になることもあります。
セキュリティー保護されたトランザクションを、保護されていないトランザクションと同一レベルで実行するには、追加の処理能力を計画する必要があります。トランザクションおよびそれを処理する Sun JavaTM Enterprise System サービスの性質によっては、セキュリティー保護されたトランザクションの処理に、保護されていないトランザクションの場合の 4 倍の処理能力が必要になることもあります。
セキュリティー保護されたトランザクションを処理するための処理能力を見積もるには、ユースケースを分析し、セキュリティー保護された転送を必要とするトランザクションの割合を求めます。セキュリティー保護されたトランザクションと保護されないトランザクションのパフォーマンス要件が同じであれば、セキュリティー保護されたトランザクションに必要な追加の処理能力を考慮して CPU の見積もりを調整します。
場合によっては、セキュリティー保護された転送が認証時にだけ必要になることもあります。システムに対するユーザーの認証が完了すれば、データの転送に追加のセキュリティー対策は必要なくなります。また、場合によっては、セキュリティー保護された転送がすべてのトランザクションで求められることもあります。
たとえば、オンラインの電子商取引サイトで製品カタログを参照する場合、顧客が商品の選択を終え、購入のための支払い手続きを開始するまでは、すべてのトランザクションはセキュリティー保護の必要がありません。しかし、銀行や仲介取引業向けの配備では、ほとんど、またはすべてのトランザクションをセキュリティー保護し、セキュリティー保護されたトランザクションと、保護されていないトランザクションの両方に同じパフォーマンス標準を適用する必要があります。
ここでは、引き続き同じ配備例を使用して、セキュリティー保護されたトランザクションと保護されないトランザクションの両方を含む理論上のユースケースに基づいて CPU 要件を計算する方法について説明します。
セキュリティー保護されたトランザクションの CPU 要件を見積もるには、次の計算を行います。
前節の、「プロセッサ要件の見積もりの例」に示されている CPU 見積もりの基準値から開始します。
セキュリティー保護された転送を必要とするトランザクションの割合を計算し、セキュリティー保護されたトランザクションの CPU 見積もりを計算します。
セキュリティー保護されないトランザクションによって減少する分の CPU 見積もりを計算します。
セキュリティー保護されたトランザクションと保護されないトランザクションの見積もりを集計し、合計 CPU 見積もりを計算します。
合計 CPU 見積もりを偶数値に切り上げます。
「セキュリティー保護されたトランザクションのための CPU の見積もり」は、次を前提とした Portal Server の場合のユースケースおよび使用パターン分析に基づいた計算例を示しています。
すべてのログインは、セキュリティー保護された認証を必要とする。
すべてのログインは、Portal Server の負荷全体の 10% に相当する。
セキュリティー保護されたトランザクションのパフォーマンス要件は、セキュリティー保護されないトランザクションのパフォーマンス要件と同じである。
セキュリティー保護されたトランザクションの処理によって必要となる追加処理能力を考慮するには、これらのトランザクションを処理するための CPU の数を 4 倍に増やします。この例のその他の 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 処理専用に使用され、通常は、セキュリティー保護されたセッションを確立するための「ハンドシェーク」処理だけに使用されます。
このハードウェアは、配備の最終的なアーキテクチャーにメリットをもたらす可能性があります。しかし、これは特殊なハードウェアであるため、まず、セキュリティー保護されたトランザクションのパフォーマンス要件を CPU の処理能力単位で見積もり、そのあとで追加負荷を処理する専用ハードウェアの導入メリットを検討してください。
専用ハードウェアの導入を検討するときは、ユースケースがそのハードウェアの利用をサポートするかどうか (たとえば、多数の SSL ハンドシェーク処理を必要とするユースケースなど)、また、このようなハードウェアによって設計にもたらされる追加処理層の複雑さを考慮します。この複雑さには、これらのデバイスのインストール、設定、テスト、管理が含まれます。
可用性要件のための戦略を策定する際は、コンポーネントのインタラクションと使用パターンの分析に基づいて、検討する可用性ソリューションを決定します。コンポーネントごとに分析を行い、可用性とフェイルオーバーの要件に最も適したソリューションを決定します。
次に、可用性戦略の決定に役立つ情報の例を示します。
可用性の「ナイン」はいくつ必要か。
フェイルオーバー状況に関するパフォーマンス仕様は何か (たとえば、フェイルオーバー中も 50% 以上のパフォーマンス、など)。
使用パターンの分析によって、ピーク時と非ピーク時は特定されるか。
地理的に考慮すべき事項は何か。
可用性戦略は、「リソースの最適な使用方法の設計」で説明する保守性要件も考慮した上で選択する必要があります。膨大な管理や保守を必要とする複雑なソリューションは避けます。
Java Enterprise System 配備の可用性戦略には、次のものがあります。
ロードバランス: 冗長ハードウェアコンポーネントおよびソフトウェアコンポーネントを使用して、処理による負荷を分散します。ロードバランサは、サービスに対するあらゆる要求を、そのサービスの複数の対称インスタンスのいずれかに送信します。インスタンスの 1 つが失敗した場合は、ほかのインスタンスにその負荷を負わせることができます。
フェイルオーバー: コンポーネントで障害が発生した場合、サービスの継続的なアクセスと重要なデータのセキュリティーを提供するためには、冗長ハードウェアおよびソフトウェアの管理が必要とされます。
Sun Cluster ソフトウェアは、Messaging Server のメッセージストレージや Calendar Server のカレンダデータなど、バックエンドコンポーネントによって管理される重要なデータのためのフェイルオーバーソリューションを提供します。
サービスのレプリケーション: サービスのレプリケーションにより、同じデータへのアクセス用に複数のソースが提供されます。Directory Server は、LDAP ディレクトリアクセス用に、多数のレプリケーション戦略および同期戦略を提供します。
以降の各節では、さまざまなレベルのロードバランス、フェイルオーバー、およびサービスのレプリケーションを提供する可用性ソリューションの例をいくつか示します。
サービスのすべてのコンピュータリソースを 1 つのサーバーに配置します。サーバーに障害が発生した場合、サービス全体が失敗します。
Sun は、次の利点を提供するハイエンドサーバーを提供しています。
システムが稼働した状態でのハードウェアコンポーネントの交換と再設定
サーバー上の、障害から分離されたドメインで複数アプリケーションを稼働する機能
システムの再起動を必要とせずに、処理能力、パフォーマンス速度、および I/O 設定をアップグレードする機能
通常、ハイエンドサーバーは、同等の機能を持つマルチサーバーシステムより高価になります。ただしシングルサーバーでは、管理、監視、データセンターでのサーバーのホスティング費用が軽減されます。ロードバランス、フェイルオーバー、障害シングルポイントの除去は、マルチサーバーシステムのほうが柔軟に対応できます。
ロードバランスとフェイルオーバーの両方を提供する平行冗長サーバーを使用することで、いくつかの方法で可用性を向上できます。次の図は、N+1 フェイルオーバーシステムを構成する 2 つのレプリカサーバーを示しています。N+1 システムには、1 つのサーバーで障害が発生した場合に、その処理能力の 100% を提供するための追加サーバーが含まれます。
上の「水平方向の冗長システム」に示される各サーバーは、同一処理能力を持ちます。1 つのサーバーが単独でパフォーマンス要件を満たします。もう一方のサーバーは、バックアップとしてサービスに適用された場合に 100% のパフォーマンスを提供します。
N+1 フェイルオーバー設計の利点は、フェイルオーバー状況でも 100% の処理能力を提供できることです。欠点には、1 つのサーバーはフェイルオーバー状況でだけ使用されるスタンバイであるため、パフォーマンス全体の向上なしにハードウェアコストが上昇することが挙げられます。
次の図は、2 つのサーバーの間でパフォーマンスを分散するロードバランスとフェイルオーバーを実装するシステムを示しています。
上の「水平方向の冗長システム」で示されているシステムでは、一方のサーバーに障害が発生した場合に、処理能力は低下しますが、すべてのサービスを利用できます。残ったサーバーは 6 CPU の処理能力を提供します。 これは、10 CPU という要件の 60% に相当します。
この設計の利点は、両方のサーバーを利用可能な状態では、2 CPU の潜在処理能力を追加されることです。
次の図は、パフォーマンス向上とロードバランス用に、多数のサーバーの間でパフォーマンスを分散する例を示しています。
「水平方向の冗長システム」に示される設計では 5 つのサーバーが使用されるため、1 つのサーバーに障害が発生した場合に、残りのサーバーが 8 CPU の処理能力を提供します。 これは、10 CPU のパフォーマンス要件の 80% に相当します。この設計に 2 CPU の処理能力を持つサーバーを追加すると、効率的に N+1 設計を実現できます。1 つのサーバーに障害が発生しても、残りのサーバーによってパフォーマンス要件は 100% 満たされます。
この設計には、次のような利点があります。
1 つのサーバーに障害が発生した場合のパフォーマンスの追加
複数のサーバーがダウンした場合の可用性
保守とアップグレードのためにサーバーを順に停止できる
複数のローエンドサーバーは、通常は 1 つのハイエンドサーバーより安い
ただし、サーバーを追加することで、管理と保守のコストは大きく上昇します。データセンターでのサーバーのホスティング費用も考慮する必要があります。サーバーの追加投入によるメリットは、ある時点から減少に転じます。
高い可用性 (4 ナインまたは 5 ナインなど) が必要となる状況では、可用性設計の一部として Sun Cluster ソフトウェアの利用を検討することができます。クラスタシステムは、冗長サーバーとストレージやその他のネットワークリソースを結合したものです。クラスタ内のサーバーは、継続的に相互通信します。1 つのサーバーがダウンした場合、クラスタ内の残りのデバイスはそのサーバーを分離し、障害のあるノードから別のノードにアプリケーションまたはデータをフェイルオーバーします。このフェイルオーバープロセスは、比較的迅速に行われるため、システムの利用者がサービスの中断を感じることはほとんどありません。
Sun Cluster ソフトウェアは、専用ハードウェアの追加と、設定、管理、維持のための特別なスキルを必要とします。
ここでは、「アイデンティティーベースの通信の例」で説明されている、1,000 〜 5,000 人の従業員を持つ中規模企業用の、アイデンティティーベースの通信ソリューションに基づいた、可用性戦略の 2 つの例を示します。1 つ目の可用性戦略では、Messaging Server のロードバランスについて説明します。2 つ目では、Sun Cluster ソフトウェアを使用するフェイルオーバーソリューションについて説明します。
次の表は、論理アーキテクチャー内の論理 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 バイト |
たとえば、技術要件フェーズで、次のサービス品質要件が指定されたとします。
可用性: システム全体の可用性は 99.99% (予定された停止時間は含めない) とする。個々のコンピュータシステムの障害によってサービス障害が発生してはならない。
スケーラビリティー: 日々のピーク負荷時において、どのサーバーも 80% を超えて利用されてはならない。 また、システムは 1 年当たり 10% の長期成長に対応する必要がある。
可用性要件を満たすには、各 Messaging Server コンポーネントについてインスタンスを 2 つずつ、それぞれを異なるハードウェアサーバーに提供します。一方のコンポーネントのサーバーに障害が発生した場合、もう一方がサービスを提供します。次の図は、この可用性戦略のネットワーク図です。
上の図では、CPU の数は元の見積もりの 2 倍になっています。CPU の数は、次の理由から 2 倍になりました。
一方のサーバーに障害が発生した場合、残りのサーバーが CPU 能力を提供して負荷を処理するため。
ピーク負荷時にどのサーバーも 80% を超えて利用されてはならないとするというスケーラビリティー要件に基づき、追加分の CPU 能力でこの安全マージンを提供するため。
1 年当たり 10% の負荷増大に対応することというスケーラビリティー要件に基づき、追加分の CPU 能力により、さらなる拡張が必要とされるまで増大する負荷を処理できる潜在処理能力を高めるため。
次の図は、Calendar Server バックエンドおよび Messaging Server メッセージストアのフェイルオーバー戦略の例を示しています。Calendar Server バックエンドおよびメッセージストアは、別個のハードウェアサーバーにレプリケートされ、Sun Cluster ソフトウェアを使用してフェイルオーバー用に設定されます。CPU の数および対応するメモリは、Sun Cluster で各サーバー上にレプリケートされます。
ディレクトリサービスをレプリケートして複数のサーバーにトランザクションを分散すると、高い可用性が得られます。Directory Server により、サービスのレプリケーションためのさまざまな戦略が提供されます。これには、次の戦略が含まれます。
複数データベース: 別個のデータベースに、ディレクトリツリーのさまざまな部分を保存します。
連鎖およびリフェラル: 分散されたデータを 1 つのディレクトリツリーにリンクします。
シングルマスターレプリケーション: マスターデータベース用の中央ソースを提供します。これはその後、コンシューマレプリカに分散されます。
マルチマスターレプリケーション: 複数のサーバーにマスターデータベースを分散します。これらのマスターはその後、それぞれのデータベースをコンシューマレプリカに分散します。
Directory Server の可用性戦略は複雑な事項であり、このマニュアルの範囲に含まれません。以降の各節、「シングルマスターレプリケーション」および 「マルチマスターレプリケーション」では、基本的なレプリケーション戦略の概要を説明します。詳細については、『Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide』の第 12 章「Designing a Highly Available Deployment」を参照してください。
次の図は、基本的なレプリケーション概念を表すシングルマスターレプリケーションを示しています。
シングルマスターレプリケーションでは、Directory Server の 1 つのインスタンスがマスターディレクトリデータベースを管理し、すべての変更を記録します。マスターデータベースは、任意の数のコンシューマデータベースにレプリケートされます。Directory Server のコンシューマインスタンスは、読み取り操作および検索操作用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。
シングルマスターレプリケーションには、次の利点があります。
データベースの読み取り操作および書き込み操作用に最適化された Directory Server のシングルインスタンス
読み取り操作および検索操作用に最適化された、Directory Server の任意の数のコンシューマインスタンス
Directory Server のコンシューマインスタンスの水平方向のスケーラビリティー
次の図は、ディレクトリアクセスをグローバル規模で分散するために使用される可能性のあるマルチマスターレプリケーション戦略を示しています。
マルチマスターレプリケーションでは、Directory Server の 1 つ以上のインスタンスがマスターディレクトリデータベースを管理します。各マスターは、マスターデータベースの同期手順を規定するレプリケーションアグリーメントを持ちます。各マスターは、任意の数のコンシューマデータベースに対してレプリケートを行います。シングルマスターレプリケーションの場合と同様に、Directory Server のコンシューマインスタンスは、読み取りアクセスおよび検索アクセス用に最適化されています。コンシューマに対する書き込みは、マスターに反映されます。マスターは、定期的にコンシューマデータベースを更新します。
マルチマスターレプリケーション戦略では、シングルマスターレプリケーションのすべての利点が提供されることに加えて、マスターに対する更新にロードバランスを実行できる可用性戦略が提供されます。また、ディレクトリ操作のローカル制御を提供する可用性戦略も実装できます。 このことは、グローバル規模で分散しているデータセンターを持つ企業にとって重要な考慮事項です。
スケーラビリティーとは、システムに処理能力を追加する能力です。 これは、通常はシステムリソースの追加によって行われ、配備アーキテクチャーの変更はスケーラビリティーの対象に含まれません。要件を分析するときに、通常は、ビジネス要件と使用パターンの分析に基づいて、システムの成長予測が立てられます。システムのユーザー数や、目的達成に必要なシステムの処理能力に関する予想は、配備されるシステムの実際の数値とは大きく異なることが珍しくありません。予想の不一致に対応できるだけの十分な柔軟性を設計に盛り込む必要があります。
スケーラブルな設計とは、システムが追加リソースでアップグレードされるまで、増大する負荷を処理できる、十分な潜在処理能力が含まれている設計です。スケーラブルな設計では、システムの設計を変更することなく、増大する負荷の処理に容易に対応できます。
潜在処理能力は、例外的なピーク負荷に容易に対応できるように、パフォーマンスと可用性のためのリソースをシステムに含めることで得られるスケーラビリティーです。また、配備されるシステムで潜在処理能力がどのように使用されるかを監視することも、リソースの追加によるシステムの規模拡大が必要となるタイミングを計る上で役立ちます。潜在処理能力は、設計に安全性を組み込む手法の 1 つです。
ユースケースの分析は、例外的なピーク負荷が発生するシナリオを特定する上で役立ちます。例外的なピーク負荷の分析と、予期せぬ急成長に対応するための方法を考慮して、システムに安全性をもたらす潜在処理能力を設計します。
システム設計は、想定される負荷を妥当な期間にわたって処理できる必要があります。 この期間は、通常、運用開始後の最初の 6 〜 12 か月です。定期的に行われる保守を通じて、必要に応じてリソースを追加したり、処理能力を向上します。システムの定期的なアップグレードをスケジューリングできれば理想的ですが、多くの場合、処理能力向上の必要性を予測することは困難です。システムをいつアップグレードするかは、リソースの慎重な監視と、ビジネス予測に頼ることになります。
ソリューションを段階的に実装する計画の場合は、各フェーズで予定されるその他の向上内容に合わせて、システムの処理能力の向上をスケジューリングする必要がある場合もあります。
この節の例では、Messaging Server を実装するソリューションの水平方向のスケーリングおよび垂直方向のスケーリングを説明します。垂直方向のスケーリングの場合、CPU をサーバーに追加することで、増大する負荷を処理します。水平方向のスケーリングの場合、負荷の分散に使用するサーバーを追加することで、増大する負荷を処理します。
この例の基準は、ロードバランスのために分散された 2 つのメッセージストアインスタンスによってサポートされる 50,000 ユーザーベースを前提としています。各サーバーには 2 つの CPU があり、合計で 4 CPU です。次の図は、25 万人または 200 万人のユーザーに増大する負荷を処理するために、このシステムの規模をどのように拡大できるかを示しています。
「スケーラビリティーの例」は、垂直方向のスケーリングと水平方向のスケーリングの違いを示しています。この図には、ロードバランス、フェイルオーバー、使用パターンの変化など、スケーリング時に考慮するべきその他の要因は示されていません。
成功する配備設計の鍵の 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」を参照してください。この章では、次の内容が取り上げられています。
メモリおよびディスクの最小容量要件: さまざまなサイズのディレクトリに必要なディスクとメモリの見積もりが示されています。
キャッシュアクセス用の物理メモリのサイズ設定: Directory Server の使用計画に応じたキャッシュサイズの見積もりおよびメモリの合計使用量の計画に関するガイドラインが示されています。
ディスクサブシステムのサイズ設定: ディレクトリサフィックスおよびディスクの使用に影響する Directory Server 要因に応じたディスク容量要件の計画について説明されています。また、ディスクへのファイルの分散についても、さまざまなディスクアレイの選択肢を挙げながら説明されています。
配備設計は、QoS 要件を満たすために必要となるリソースを見積もるだけではありません。配備設計では、可能な選択肢をすべて分析し、コストを最小化しつつ QoS 要件を満たす最善のソリューションの選択も行います。ある領域での利点が、別の領域のコストで相殺されないように、設計上のそれぞれの意思決定による得失評価を分析する必要があります。
たとえば、可用性のための水平方向のスケーリングは、全体的な可用性を向上するかもしれませんが、保守とサービスのコストは上昇します。パフォーマンスのための垂直方向のスケーリングは、費用効率良く処理能力を向上できるかもしれませんが、一部のサービスでは追加された処理能力を活用し切れない可能性があります。
設計戦略を完成させる前に、リソースの使用と提案ソリューションの全体的なメリットのバランスについて、決定事項をよく見直してください。通常、この分析では、ある領域のシステム品質が、別のシステム品質にどのように影響するかを調べます。次の表は、いくつかのシステム品質と、それに対応するリソース管理に関する考慮事項を示しています。
表 5–8 リソース管理に関する考慮事項
システム品質 |
説明 |
---|---|
個々のサーバーに CPU を集中させるパフォーマンスソリューションで、サービスは処理能力を効率的に活用できるか。(たとえば、一部のサービスでは、効率的に利用できる CPU の数に制限がある。) |
|
潜在処理能力 |
採用した戦略により、想定されるパフォーマンスを超過した負荷が処理されるか。 過度な負荷の処理に、サーバーの垂直方向のスケーリング、他のサーバーへのロードバランスのどちらを使用するか、または両方使用するか。 配備の規模拡大に関する次回の目標を達成するまで、例外的なピーク負荷を処理できるだけの潜在処理能力があるか。 |
セキュリティー保護されたトランザクションの処理に必要なパフォーマンス上のオーバーヘッドは十分に考慮されているか。 |
|
水平方向の冗長性ソリューションで、長期的な保守コストを十分に想定しているか。 システムの保守に必要な予定された停止時間は考慮されているか。 ハイエンドサーバーとローエンドサーバーのコストのバランスはとれているか。 |
|
配備の規模拡大に関する一連の達成目標は設定されているか。 配備の規模拡大に関する次回の目標を達成するまで、想定される負荷の増大に対応できるだけの十分な潜在処理能力を提供する戦略を持っているか。 |
|
管理、監視、保守のコストを踏まえて可用性を設計しているか。 管理コストを作成するために、委任管理ソリューション (エンドユーザーが一部の管理作業を実行できるようにする) を検討したか。 |
サービス品質要件や使用パターンの分析など、配備設計が基づく情報の多くは、実証的なデータではなく、ビジネス分析から最終的に得られた予測に基づいています。これらの予測は、ビジネス動向での予期しない状況、データ収集方法上の問題、あるいは単なる人為ミスなど、さまざまな理由から正確でない可能性があります。配備設計を完了する前に、設計の土台となった分析結果を再確認し、見積もりや予測のずれが設計で十分に考慮されているかどうかを確認してください。
たとえば、使用パターンの分析でシステムの実際の使用状況が低く見積もられている場合、発生するトラフィックに対応し切れないシステムを構築してしまうリスクが生じます。予定を下回るパフォーマンスを示す設計は、失敗と見なされます。
一方で、必要処理能力より数倍強力なシステムを構築した場合、別の場所で使用できたはずのリソースを無駄にすることになります。重要なことは、要件に加えて安全性のマージンを含めるが、リソースの浪費は回避するということです。
リソースの浪費も設計の失敗をもたらします。 十分に活用されなかったリソースを別の領域に適用できたためです。また、行き過ぎたソリューションを適用することは、利害関係者に、誠実に契約を履行していないと見なされる可能性もあります。
次の図は、この白書ですでに紹介した配備例の完全な配備アーキテクチャーを示しています。この図は、配備アーキテクチャーを表現する方法を示しています。
次の図の配備アーキテクチャーは、説明のためのアーキテクチャーに過ぎません。実際に設計、構築、またはテストされた配備を示しているわけではないので、配備計画のアドバイスと見なさないでください。