|
| |
| Sun Java Enterprise System 配備計画に関する白書 | |
第 5 章
配備アーキテクチャの設計この章では、パフォーマンス、セキュリティ、可用性、およびその他のシステム品質に基づいて配備を設計する方法について説明します。また、この章では、配備設計の最適化に関する情報も提供します。
配備アーキテクチャは、論理アーキテクチャから物理環境へのマッピングを表します。物理環境には、イントラネットまたはインターネット環境内のコンピュータノード、CPU、メモリ、ストレージデバイス、その他のハードウェアおよびネットワークデバイスが含まれます。
配備アーキテクチャの設計には、技術要件フェーズで特定したシステム要件を満たすために必要な物理リソースを決定するための、配備のサイズ設定が伴います。また、配備のサイズ設定を分析し、ビジネス上の制約内でリソースの使用を最適化した設計を作成するために、リソースの最適化も行います。
配備アーキテクチャの設計が完了すると、プロジェクト承認時に配備の実際のコストが見積もられます。プロジェクトが承認された場合は、配備の完了に関する契約に署名がなされ、プロジェクトの実装に必要なリソースが確保されます。
詳細な設計仕様は、プロジェクトの承認前後に作成されます。詳細な設計仕様は、設計の構築のために実装フェーズで使用されます。
この章では、第 4 章の配備例を引き続き使用して、配備アーキテクチャの設計プロセスで行われる各種手順を説明します。
この章で説明する内容は、次のとおりです。
計画中の配備のサイズ設定計画中の配備のサイズ設定は、システム要件を満たし、ビジネス上の目的を最終的に達成するために必要なハードウェアリソースのセットを決定するプロセスです。配備のその他の計画および設計と同様に、サイズ設定にも決定的な方法はなく、公式を提示することはできません。成功するサイズ設定は、過去の設計経験、システムアーキテクチャに関する知識、ビジネス領域に関する知識、クリエイティブな思考の応用を組み合わせた結果です。
サイズ設定は、「システム要件」で説明した次のサービス品質について、すでに特定されているシステム要件を中心に展開されます。配備設計のこれまでの段階で特定された、ビジネス要件、使用パターンの分析、使用のモデルケースもシステムのサイズ設定に重要な役割を果たします。
サイズ設定を試行するときに、使用のモデルケースと使用パターンの分析は、モデルケースのサポートに必要なリソースを決定する上で役立ちます。通常は、最も大きな重みを付けられたモデルケース (最も一般的なトランザクションを表す) から順に、最も軽いモデルケースまでを評価します。重み付けされたモデルケースの使用は、システムに想定される負荷に基づいてリソースを割り当てる上で役立ちます。
以後の各節では、次のシステム品質に関連して、配備のサイズを設定する一般的な方法を解説しています。
パフォーマンスのためのサイズ設定
パフォーマンスと負荷要件のためのサイズ設定は、配備されるシステムでサービスをサポートするために必要となる CPU の数と、それに対応するメモリの量を見積もる繰り返しのプロセスです。サービスのサポートに必要な CPU の数を見積もるときは、次の点を考慮します。
パフォーマンスのためのサイズ設定のプロセスは、通常は次の手順で行われます。これらの手順の順序は、あまり重要ではありません。最終的な結果に影響する要因を分析する方法として考えてください。
ユーザーエントリポイント用の 基準 CPU の見積もり
ユーザーエントリポイントとなる各コンポーネントの想定負荷を処理するために必要な CPU の数を見積もることから開始します。論理アーキテクチャのレイアウト設計に、見積もり結果をメモします。
次の図は、「導入計画の例」で紹介した配備例を使用して、ユーザーエントリポイントとなるコンポーネントの初期見積もりを示しています。これらの見積もりの値は、システム要件、使用のモデルケース、使用パターンの分析に基づく結果である場合もあります。
警告
この白書では、パフォーマンス用のサイズ設定の方法を具体的に説明しません。ここで使用される CPU とメモリの値は、図で使用するための任意の見積もり結果に過ぎません。これは、何らかの具体的な実装を反映したものではなく、システムの設計プロセスの説明を目的に記載されています。
図 5-1 ユーザーエントリポイントとなるコンポーネントの基準 CPU の見積もり
サービス依存関係に基づく CPU 見積もりの調整
ユーザーエントリポイントとなるコンポーネントは、他の Java Enterprise System サービスからのサポートを必要とします。パフォーマンス要件の特定を継続するには、必要となる他のコンポーネントからのサポートを考慮して、パフォーマンスの見積もりを調整します。
この例では、図 4-4 に示される論理データフローを考慮に入れ、他のコンポーネントをサポートするコンポーネントに基づいて見積もりを調整します。次の表は、CPU 見積もりの調整内容を要約しています。見積もりでは、小数単位まで CPU の数を指定します。パフォーマンスのための見積もりが完了したら、CPU 数を合計し、結果を整数値に切り上げます。
前項と同様に、次の表に示すパフォーマンスの見積もりは、説明用の任意の見積もり値に過ぎません。
次の図は、表 5-1 の情報に基づいて更新された、パフォーマンス用の見積もりを示しています。
図 5-2 サービスのサポートに基づいて調整された CPU の見積もり
潜在処理能力、スケーラビリティ、可用性に基づく CPU 見積もりの調整
パフォーマンスのためのサイズ設定の見積もりを完了したら、CPU の値を整数値に切り上げます。通常は、CPU の数を次に大きな偶数値に切り上げます。CPU の見積もり値を切り上げるときは、次の点を考慮します。
次の図は、配備例の CPU 見積もり値の調整結果を示しています。また、この図には各 CPU のメモリ要件も指定されています。この例では、各 CPU が 2G バイトのメモリを必要とすることを前提としています。この例のこれらのメモリ仕様は、説明用の任意の値に過ぎません。各 CPU が必要とするメモリの計算方法は、この白書の対象範囲に含まれません。
図 5-3 メモリ要件を含む、パフォーマンスのための見積もり値
セキュリティのためのサイズ設定
配備のサイズ設定には、セキュリティに関する次の課題が影響します。
セキュリティ保護されたデータ転送には、SSL (Secure Seckets Layer) など、安全な転送プロトコルを通じたトランザクションの処理が伴います。ユーザーの認証でも、安全な転送を通じたトランザクションの処理が必要になることがあります。
多くの場合、安全な転送を通じて処理されるトランザクションは、セキュリティ保護されたセッションの確立 (ハンドシェークと呼ばれます)、および転送データの暗号化と復号のために、追加の処理能力を必要とします。使用する暗号化アルゴリズム (たとえば、40 ビットまたは 128 ビットの暗号化アルゴリズム、など) によっては、かなりの追加処理能力が必要になることもあります。
セキュリティ保護されたトランザクションを、保護されていないトランザクションと同一レベルで実行するには、追加の処理能力を計画する必要があります。トランザクション、およびそれを処理する Java Enterprise System の性質によっては、セキュリティ保護されたトランザクションの処理に 4 倍 (以上) の処理能力が必要になることもあります。
セキュリティ保護されたトランザクションを処理するためのパフォーマンス要件を見積もるには、まず、使用のモデルケースを分析し、安全な転送を必要とするトランザクションの割合を求めます。セキュリティ保護されたトランザクションと保護されないトランザクションのパフォーマンス要件が同じであれば、セキュリティ保護されたトランザクションに必要な追加の処理能力を考慮して CPU の見積もりを調整します。
場合によっては、安全な転送が認証時にだけ必要になることもあります。システムに対するユーザーの認証が完了すれば、データの転送に追加のセキュリティ対策は必要なくなります。また、場合によっては、安全な転送がすべてのトランザクションで求められることもあります。トランザクションの 5 〜 10% が安全な転送を必要とする、という見積もりは、多くの場合妥当です。
たとえば、オンラインの電子商取引サイトで製品カタログを参照する場合、顧客が商品の選択を終え、支払いの手続きを開始するまでは、すべてのトランザクションはセキュリティ保護の必要がありません。さらに、このような電子商取引サイトの多くでは、セキュリティ保護されたトランザクション用に応答要件が緩和されています。しかし、銀行や仲介取引業向けの配備では、ほとんど、またはすべてのトランザクションをセキュリティ保護し、セキュリティ保護されたトランザクションと、保護されていないトランザクションの両方に同じパフォーマンス標準を適用する必要があります。
セキュリティ保護されたトランザクションのためのパフォーマンスの計算
ここでは、引き続き同じ配備例を使用して、セキュリティ保護されたトランザクションと保護されないトランザクションの両方を含む使用のモデルケースに基づいて CPU 要件を計算するためのワークシートについて説明します。
CPU 要件を計算するには、ワークシートで次の計算を行います。
- 前節の「パフォーマンスのためのサイズ設定」で計算した、CPU 要件の基準値から開始する
- SSL を必要とするトランザクションの割合を求め、SSL トランザクションのための CPU 要件を計算する
- セキュリティ保護しないトランザクション用の CPU 計算値を調整する
- セキュリティ保護するトランザクションと保護しないトランザクションの要件を集計し、合計 CPU 要件を計算する
図 5-4 のワークシートは、Portal Server の追加の使用モデルケースと使用パターン分析に基づいています。追加の使用モデルケースと使用パターン分析は、次を前提としています。
この例では、SSL トランザクションの処理によって必要となる追加処理能力を考慮した場合、これらのトランザクションの処理に必要な CPU の数は、5 倍に増えました。この例のその他の CPU の見積もり値と同様に、これは説明用の任意の値に過ぎません。
図 5-4 セキュリティ保護されたトランザクションのための CPU 見積もり計算用ワークシート
SSL トランザクション処理の専用ハードウェア
SSL アクセラレータカードなどの特殊なハードウェアデバイスを使用して、セキュリティ保護されたセッションの確立、データの暗号化と複合、または両方を処理するための追加の処理能力を供給することができます。SSL 操作に特化されたハードウェアを使用した場合、その処理能力は一部の特定の SSL 処理専用に使用され、通常は、セキュリティ保護されたセッションを確立するための「ハンドシェーク」処理だけに使用されます。
このハードウェアは、配備の最終的なアーキテクチャにメリットをもたらす可能性があります。しかし、これは特殊なハードウェアであるため、まず、セキュリティ保護されたトランザクションのパフォーマンス要件を CPU の処理能力単位で見積もり、その後で追加負荷を処理する専用ハードウェアの導入メリットを検討することをお勧めします。
専用ハードウェアの導入を検討するときは、使用のモデルケースがそのハードウェアの利用をサポートするかどうか (たとえば、多数の SSL「ハンドシェーク」処理を必要とするモデルケースなど)、また、このようなハードウェアによってシステムにもたらされる追加処理層の複雑さを考慮します。この複雑さには、これらのデバイスのインストール、設定、テスト、管理が含まれます。
可用性のためのサイズ設定
パフォーマンスのためのサイズ設定が完了したら、可用性のためのシステムのサイズ設定を開始します。論理アーキテクチャに含まれるコンポーネントをホスティングするサーバーの指定、ロードバランスの設定、各種 Java Enterprise System コンポーネントのフェイルオーバー戦略の決定は、この段階で行われます。
使用のモデルケースと使用パターンの分析に基づいて、どの可用性ソリューションを検討するかを決定します。次に、可用性戦略の決定に役立つ情報の例を示します。
コンポーネントごとにモデルケースを分析し、フェイルオーバー要件とロードバランス要件の最適なソリューションを決定します。また、モデルケースと使用パターンの分析に基づいて、サービスの負荷をバランスさせる最適な方法を決定します。
可用性戦略は、「利便性に関する問題」で説明する利便性要件も考慮した上で選択する必要があります。管理が容易なシステムを優先し、膨大な管理やメンテナンスを必要とする複雑なソリューションは回避するようにしてください。
複雑なシステムのディレクトリ設計
多数のユーザーが利用する複雑な配備では、可用性戦略に影響する可能性のある Directory Server のディレクトリ設計が必要になる可能性があります。これは、LDAP ディレクトリの設計が Identity Server と Messaging Server の可用性戦略に影響する可能性があるためで、これらのサーバーが他のシステム品質に影響する可能性もあります。
複雑な配備を設計する場合は、可用性設計に配慮した予備ディレクトリ設計の作成を検討してください。後に、詳細な設計を決定する段階、または開発段階で、完全なディレクトリ設計を行います。
ハードウェアとソフトウェアの障害
可用性の設計は、ハードウェアとソフトウェアの両方の障害からの保護を提供する必要があります。一般に、ソフトウェア障害はハードウェア障害よりもコストが高くつきます。ソフトウェアの平均故障間隔は、ハードウェアの平均故障間隔より長めです。さらに、ソフトウェアの障害の診断と修復はより困難であり、防止のための管理とメンテナンスのコストも高くなります。
可用性設計の一般的なアプローチ
ここでは、可用性要件に基づく設計を行うための一般的な方法について説明します。可用性設計の具体的な方法は、この白書の対象範囲に含まれません。
シングルサーバーシステム
サービスのすべてのコンピュータリソースを 1 つのサーバーに配置します。サーバーに障害が発生した場合、サービス全体が失敗します。
図 5-5 シングルサーバー
Sun は、次の利点を提供するハイエンドサーバーを提供しています。
通常、ハイエンドサーバーは、同等の機能を持つマルチサーバーシステムより高価になります。ただしシングルサーバーでは、管理、監視、データセンターでのサーバーのホスティング費用が軽減されます。ロードバランス、フェイルオーバー、障害シングルポイントの除去の点では、マルチサーバーシステムのほうが柔軟に対応できます。
水平方向の冗長システム
ロードバランスとフェイルオーバーの両方を提供する平行冗長サーバーを使用することで、いくつかの方法で可用性を向上できます。次の図は、N+1 可用性システムを構成する 2 つのレプリカサーバーを示しています。N+1 システムは、1 つのサーバーで障害が発生した場合に、その処理能力の 100% を提供するための追加コンポーネントが含まれます。
図 5-6 2 つのレプリカサーバー
上の図 5-6 に示される核サーバーは、同一処理能力を持ちます。1 つのサーバーが単独でパフォーマンス要件を満たします。もう一方のサーバーは、バックアップとしてサービスに適用された場合に 100% のパフォーマンスを提供します。
レプリカサーバー設計の利点は、フェイルオーバー状況でも 100% の処理能力を提供できることです。欠点には、パフォーマンス全体の向上なしに、ハードウェアコストが上昇することが挙げられます。
次の図は、ロードバランスとフェイルオーバー用に、2 つのサーバーの間でパフォーマンスを分散する例を示しています。
図 5-7 2 つのサーバー間での負荷の分散
上の図 5-7 では、一方のサーバーに障害が発生した場合に、処理能力は低下しますが、すべてのサービスを利用し続けることができます。残ったサーバーは 6 CPU の処理能力を提供します。これは、10 CPU という要件の 60% に相当します。
この設計の利点は、両方のサーバーを利用可能な状態では、2 CPU の潜在処理能力を追加されることです。また、一方のサーバーに障害が発生した場合に、パフォーマンスが低下する可能性はありますが、すべてのサービスを利用し続けることができます。
次の図は、パフォーマンス向上とロードバランス用に、多数のサーバーの間でパフォーマンスを分散する例を示しています。
図 5-8 n サーバー間での負荷の分散
図 5-8 に示される設計では 5 つのサーバーが使用されるため、1 つのサーバーに障害が発生した場合に、残りのサーバーが 8 CPU の処理能力を提供します。これは、10 CPU のパフォーマンス要件の 80% に相当します。この設計に 2 CPU の処理能力を持つサーバーを追加すると、効率的に N+1 設計を実現できます。1 つのサーバーに障害が発生しても、残りのサーバーによってパフォーマンス要件は 100% 満たされます。
この設計には、次のような利点があります。
ただし、サーバーを追加することで、管理とメンテナンスのコストは大きく上昇します。また、データセンターでのサーバーのホスティング費用も上昇します。サーバーの追加投入によるメリットは、ある時点から減少に転じます。
Sun Cluster
高い可用性 (4 ナインまたは 5 ナインなど) が必要となる状況では、可用性設計の一部として Sun Cluster の利用を検討することができます。クラスタシステムは、サーバー、ストレージ、およびその他のネットワークリソースを結合します。クラスタ内のサーバーは、継続的に相互通信します。1 つのサーバーがダウンした場合、クラスタ内の残りのデバイスはそのサーバーを分離し、障害のあるノードから別のノードにアプリケーションまたはデータをフェイルオーバーします。このフェイルオーバープロセスは、比較的迅速に行われるため、システムの利用者がサービスの中断を感じることはほとんどありません。
Sun Cluster は、専用ハードウェアの追加と、設定、管理、維持のための特別なスキルを必要とします。
配備例の可用性設計
次の図は、第 4 章「論理アーキテクチャの設計」で紹介した配備例のカレンダーサービス部分の可用性設計を示しています。この図では、配備例の論理アーキテクチャのうち、Calendar Server の可用性ソリューションだけを取り上げています。配備例の完全な可用性ソリューションの分析は、この白書の対象範囲に含まれません。
この章ですでに行ったサイズ設定の試行では、図 5-3 に示されるように、Calendar Server が 6 つの CPU と 12G バイトのメモリを必要とすることが特定されました。次の図は、送受信される要求のロードバランスのために 2 つのサーバーに配備された Calendar Server のフロントエンドを示しています。Calendar Server のバックエンドは別のサーバーに配備され、フェイルオーバーのために Sun Cluster 3.1 4/04 にレプリケートされます。フェイルオーバーのため、Calendar Server のバックエンドで必要となる CPU とメモリは、Sun Cluster 3.1 4/04 にレプリケートされます。
図 5-9 配備例での Calendar Server の可用性設計
利便性に関する問題
可用性を設計するときは、ソリューションの管理とメンテナンスに要するコストも考慮する必要があります。これらのコストはハードウェアの購入と直接的には関連しないため、設計時に見過ごされがちです。このため、設計の複雑さを反映した、見えない継続的なコストとなってしまう可能性があります。
たとえば、高い可用性を提供するために、多数の水平冗長性サーバーを設計に含めたと仮定します。このとき、サーバーの設定、ソフトウェアの継続的なアップグレード、システムの状態監視のコストを考慮していなかった場合は、可用性の向上に支障をきたす可能性があります。
利便性を設計するときは、次の管理コストとメンテナンスコストを考慮します。
スケーラビリティのためのサイズ設定
スケーラビリティは、システムに処理能力を追加する能力を説明します。これは、通常はシステムリソースの追加によって行われ、配備アーキテクチャの変更はスケーラビリティの対象に含まれません。ここでは、スケーラビリティを設計する上で考慮すべき点について説明します。
要件を分析するときに、通常は、ビジネス要件と使用パターンの分析に基づいて、システムの成長予測が立てられます。システムのユーザー数や、目的達成に必要なシステムの処理能力に関する予想は、配備されるシステムの実際の数値とは大きく異なることが珍しくありません。予想の不一致に対応できるだけの十分な柔軟性を設計に盛り込む必要があります。
潜在処理能力
潜在処理能力は、例外的なピーク負荷に容易に対応できるように、パフォーマンスと可用性のためのリソースをシステムに含めることで得られるスケーラビリティです。潜在処理能力は、設計に安全性を組み込む手法の一つです。
使用のモデルケースを慎重に分析することは、例外的なピーク負荷を生じる使用方法 (たとえば、強制的な Web 放送をスケジューリングした B to E の配備など) の特定に役立ちます。例外的なピーク負荷の分析と、予期せぬ急成長に対応するための方法を考慮して、システムに安全性をもたらす潜在処理能力を設計します。
また、配備されるシステムで潜在処理能力がどのように使用されるかを監視することも、リソースの追加によるシステムの規模拡大が必要となるタイミングを計る上で役立ちます。
システムの処理能力のアップグレード
システム設計は、運用開始後、最初の 6 〜 12 か月に想定される負荷を処理できる必要があります。定期的に行われるメンテナンスを通じて、必要に応じてリソースを追加したり、処理能力を向上します。システムの定期的なアップグレードをスケジューリングできれば理想的ですが、多くの場合、処理能力向上の必要性を予測することは困難です。システムをいつアップグレードするかは、リソースの慎重な監視と、ビジネス予測に頼ることになります。
ビジネス上、または技術的な理由から、システムの一部の配備を遅らせる段階的な配備では、システムの新機能を含むその他のアップグレードに合わせて、システム処理能力のアップグレードをスケジューリングすることができます。
リソースの最適化配備のサイズ設定は、システム要件を満たすために必要となるリソースの見積もりだけではありません。サイズ設定には、リスク管理とリソース管理の試行も含まれます。多くの場合、設計がリスク管理とリソース管理をどのように処理するかが、ビジネス上の目的を達成する鍵となります。
リスク管理
ビジネス要件や使用パターンの分析など、サイズ設定に基づく情報の多くは、実証的なデータではなく、予測に基づいています。計画中の配備のサイズ設定を完了する前にデータを見直し、そのサイズ設定が、妥当な量の予測のずれを考慮しているかどうかを確認してください。
たとえば、ビジネス要件から導かれた予測が、システムの実際の使用状況を下回った場合、発生するトラフィックに対応し切れないシステムを構築してしまうリスクが生じます。予定を下回るパフォーマンスを示す設計は、失敗と見なされます。
一方で、必要処理能力より数倍強力なシステムを構築した場合、別の場所で使用できたはずのリソースを無駄にすることになります。重要なことは、要件に加えて安全性のマージンを含めるが、リソースの浪費は回避するということです。
活用し切れていないリソースを別の領域に適用することが配備の成功に重要であった可能性もあるため、リソースの浪費も設計の失敗と見なされます。また、行き過ぎたソリューションを適用することは、誠実に契約を履行していないと見なされる可能性もあります。
リソース管理
リソース管理は、利用できるすべてのサイズ設定オプションを分析した上で、システム要件を満たすと同時にコストを最小化する最適なソリューションを選択するプロセスです。これには、ある領域での利点が、別の領域のコストで相殺されないように、設計上のそれぞれの意思決定の得失評価を把握する必要があります。
たとえば、可用性のための水平方向のスケーリングは、全体的な可用性を向上するかもしれませんが、メンテナンスとサービスのコストは上昇します。パフォーマンスのための垂直方法のスケーリングは、費用効率良く処理能力を向上できるかもしれませんが、一部のサーバーでは追加された処理能力を活用し切れない可能性があります。
サイズ設定戦略を完成させる前に、リソースの使用と設計の全体的なメリットのバランスについて、決定事項をよく見直してください。通常、この見直しでは、ある領域のシステム品質が、別のシステム品質にどのように影響するかを調べます。次の表は、リソース管理について考慮すべき事項を示しています。
配備例のアーキテクチャ次の図は、この白書ですでに紹介した配備例の完全な配備アーキテクチャを示しています。この図は、配備アーキテクチャを表現する方法を示しています。
図 5-10 配備例のアーキテクチャ
詳細な設計仕様配備アーキテクチャが完成した後は、顧客によるレビューが行われ、問題なく進めばプロジェクトの承認がそれに続きます。場合によっては、承認前に顧客が配備アーキテクチャの変更を求めることもあります。
プロジェクトが承認されたら、詳細な設計仕様を作成します。これは、配備の実装の開始点となります。設計仕様には、特定のハードウェアリソースとネットワークリソースの詳細、および LDAP ディレクトリの詳細な仕様が含まれます。
