ソリューションのライフサイクルにおける配備設計の段階では、高レベル配備アーキテクチャーと低レベル実装仕様を設計し、ソリューションの実装に必要な一連の計画および仕様を準備します。プロジェクトの承認は、配備設計の段階で行われます。
この章で説明する内容は次のとおりです。
配備設計は、ソリューションライフサイクルの論理設計および技術要件の段階で作成される配備シナリオから始めます。配備シナリオには、論理アーキテクチャーとソリューションのサービス品質要件が含まれます。論理アーキテクチャーで特定されたコンポーネントを、物理サーバーおよびその他のネットワークデバイスにマッピングし、配備アーキテクチャーを作成します。サービス品質要件は、パフォーマンス、可用性、スケーラビリティー、およびその他のサービス品質関連仕様に関するハードウェア構成のガイダンスを提供します。
配備アーキテクチャーの設計は反復プロセスです。サービス品質要件を通常何度も確認し、初期設計を再検証します。サービス品質要件の相互関係を考慮に入れ、トレードオフと所有コストに伴う課題のバランスを取り、最終的にプロジェクトのビジネス目標を満たすことのできる最適なソリューションを考案します。
配備計画に着手するには、すでに詳細にわたって文書化され、テストされている参照アーキテクチャーや構築ブロックアーキテクチャーから始める方法が最適です。ゼロの状態から着手するよりも、このアーキテクチャーに対して適宜変更を加えるほうが簡単です。配備設計を成功に導く要因とは、過去の設計実績、システムアーキテクチャーに関する知識、ドメインに関する知識、および創造的思考の応用です。
配備設計は通常パフォーマンス要件の達成を中心に行われますが、同時にほかのサービス品質要件にも対応する必要があります。採用する戦略は、設計に関する決定のトレードオフと、ソリューションの最適化のバランスを取る必要があります。使用される方法には、通常、次のタスクが含まれます。
プロセッサ要件を見積もる。配備設計は、通常、論理アーキテクチャーのポータルのサイジングから始まります。ユースケースを活用し、適宜見積りを修正します。また、過去のエンタープライズシステム設計の実績も考慮に入れます。
セキュリティー保護されたトランスポートのプロセッサ要件を見積もる。セキュリティー保護されたトランスポートを必要とするユースケースを調査し、それに応じて CPU の見積りを修正します。
サービスをレプリケートし、可用性とスケーラビリティーを実現する。可用性とスケーラビリティーのサービス品質要件に対応するため、設計に修正を加えます。可用性とフェイルオーバーの検討事項に対応可能な負荷分散ソリューションを考慮に入れます。
分析において、設計に関する判断のトレードオフを見出します。たとえば、可用性とスケーラビリティーの戦略は、システムのサービス性 (保守) にどのような影響を与えるか。戦略の導入には、ほかにどのような代償が伴うか。
ボトルネックを特定する。配備設計を検証し、データ伝送が要件を下回る原因となるボトルネックを特定し、調整を行います。
リソースを最適化する。リソース管理の配備設計を検証し、要件を満たしながらコストを削減できるオプションを検討します。
リスクを管理する。ビジネスおよび技術面の分析を再確認し、初期計画では予測し得なかったイベントまたは状況を反映した設計に変更します。
利用分析において基準が確立されれば、その数値を検証、微調整して、スケーラビリティー、高可用性、信頼性、および良好なパフォーマンスを実現できます。
Portal Server を配備する場合の適切な 見積もりサイズを設定する作業は反復プロセスです。 入力値を変更すれば、幅のあるサイジング結果を生成できます。Portal Server 配備をカスタマイズすると、パフォーマンスに多大な影響が及ぶことがあります。
サイジングの見積もりが完了したら、次の点を考慮します。
以下の、工場出荷状態でポータルを配備する場合の LDAP トランザクション数を使用して、LDAP マスターとレプリカのサービス要求に与える影響を理解してください。これらの数字は、システムのカスタマイズを開始すると変更されます。これらの数字は開発者用サンプルとして取り出され、Access Manager の作業が含まれます。
認証なしの匿名ポータルへのアクセス - 6 BINDS、49 SRCH
ログインチャネルを使用したログイン - 1 BIND、2 SRCH
ポータルデスクトップからのチャネルの削除 - 14 SRCH、2 MOD
ポータルデスクトップの再ロード - 0 ops
Web コンテナにインストールされた Portal Server の主な使用法の 1 つ は、ポータルプロバイダを、アプリケーションサーバーで動作している Enterprise JavaBeansTM アーキテクチャー、または Java Database Connectivity (JDBC) および LDAP (LDAPSDK) などの J2EE テクノロジスタック構造体と統合することです。このような、ほかのアプリケーションとモジュールはリソースを消費するので、ポータルのサイジングに影響を及ぼします。最適な方法は、接続プールや、Web コンテナを通じて提供される JNDI ツールを使用することです。
ここまでで、ポータルを配備する場合の CPU の見積もり数が算出されるので、試験的な配備を行なってポータルのパフォーマンスを測定します。ロードバランス機能を使用して、ストレステストを実行して、次の要素を決定します。
スループット: 指定された時間内に処理されるデータ量です。
待ち時間: 1 つのコンポーネントが別のコンポーネントを待つときの時間です。
最大並行セッション数。
Portal Server にはポータルのサンプルが用意されています。使用するチャネルに類似のチャネルでサンプル使用し、システムに負荷をかけることができます。サンプルはポータルデスクトップにあります。
試験的な配備を使用して、最終的なサイジング見積もりを決定します。試験的な配備により、バックエンド統合をサイジングし、Portal Server の動作に関係する潜在的なボトルネックを回避します。
次のステップでは、導き出したサイズを微調整します。このセクションでは、スケーラビリティー、高可用性、信頼性、および優れたパフォーマンスを特長とするポータルサイトを配備できるように、適切な量の余裕値を組み込みます。
基準サイズは多くの見積もり値に基づいて導き出されるので、微調整してから使用してください。
基準サイズを微調整する場合は、次の指示に従います。
見積もられた基準サイズを基準点として使用します。
基準サイズからの変動量を予想します。
ほかの人の経験から学びます。
自分の判断力と知識を活用します。
配備におけるほかの要素について検討します。
Portal Server の配備に、いくつかの大陸におよぶ複数のデータセンターと一様なトラフィックが関係している場合は、1 つの大陸でトラフィックの大きな 2 つの単独データセンターを使用する場合よりも、最終サイズを大きくする必要があります。
変更計画
ポータルサイトは、運用を開始してからさまざまな変更が加えられることがよくあります。たとえば、次のような変更が加えられることがあります。
チャネル数の増加
ユーザーベースの増大
ポータルサイトの目的の変更
セキュリティーの必要事項の変更
電源障害
メンテナンス要求
これらの要素について考慮すれば、柔軟性に富んだ見積もりサイズを導き出すことができ、ポータルの想定内容が配備後に変更される場合のリスクを回避できます。
導き出される見積もりサイズにより、ポータルサイトの次の特長を確保することができます。
スケーラビリティー、高可用性、信頼性、および優れたパフォーマンス
望むサービスをすべて提供する余裕
変更に対応する柔軟性
試験的な配備を使用して、ポータルの配備方法がビジネス要件と技術要件を満たすことを検証します。
設計段階で潜在的なボトルネックを特定することで、ポータルのパフォーマンスニーズを計画することができます。
メモリー消費と、パフォーマンスに与えられる影響に関するセクションに進む前に、Java 仮想マシンのバージョン 1.4.2 のチューニングに関するマニュアルを一読してください。Sun Java System Application Server または Sun Java System Web Server に配備する場合、Java 仮想マシンはバージョン 1.5 になります。ただし、サードパーティーの Web コンテナに配備する場合は、バージョン 1.4.2 を使用することもできます。
http://java.sun.com/products/hotspot/index.html
Portal Server では、可能なかぎり最高のスループットを実現するために、かなりの量のメモリーが必要になります。初期化時に、最大アドレス領域が実質的に確保されますが、必要でないかぎり物理メモリーは割り当てられません。オブジェクトメモリー (ヒープ) 用に確保したアドレス領域全体は、新世代 (eden) と旧世代 (tenured) に分割できます。その名の通り、新世代とは新たに作成された Java オブジェクトであり、旧世代とは現存の Java オブジェクトに割り当てられた空間を指します。
ほとんどのアプリケーションでは新世代用にヒープ全体のかなりの割合を使用するように勧めていますが、Portal Server では、Portal Server が使用するメモリーの大半は長期的に使用されるので、新世代用の領域の 1/8 のみを使用するのが適切です。メモリーを旧世代にコピーするのが早いほど、ガベージコレクション (Garbage Collection、GC) のパフォーマンスは向上します。
デフォルトでは、ヒープのサイズが大きい場合でも、ポータルインスタンスが中程度の負荷で数日間実行されたあとは、GC の遅れによりほとんどのヒープが使用されたように見えます。GC は、常駐セットサイズ (RSS) がヒープ領域全体の約 85 パーセントに達するまで完全なガベージコレクションを実行します。85 パーセントに達すると、ガベージコレクションがパフォーマンスにある程度の影響を及ぼすことがあります。
たとえば、900MHz UltraSPARCIIITM では、2G バイトのヒープに対するフル GC には10 秒を超えることがあります。その間、システムは Web 要求に応答できません。信頼性のテスト時に、フル GC は応答時間の急激な上昇としてはっきり目に見えるようになります。本稼働時には、ほとんどの場合フル GC が認識されることはありませんが、システムのパフォーマンスを測定する監視スクリプトはフル GC が発生する可能性があることを考慮する必要があります。
フル GC の頻度を測定するのが、Web コンテナにメモリーリークが発生していることを確認する手段となる場合があります。(基準システムの) 予測頻度を示す分析を行い、その結果を観測したフル GC の頻度と比較します。GC の頻度を記録するには、vebose:gc JVMTM パラメータを使用します。
次の手順を実行すると、リソースを最適化できます。
Secure Remote Access ゲートウェイのような SSL 集中サーバーは、毎回のセキュリティー保護トランザクションで要求される暗号化を実行するために、大きな処理能力を必要とします。SSL 機能を実装したロードバランサを使用すると、暗号化アルゴリズムの実行をオフロードすることで Portal Gateway を高速化できます。
DMZ のロードバランサの SSL トラフィックを終了すると、ポータルトポロジが簡素化されます。Access Manager セッションはクッキーに保持されます。パフォーマンスの観点から非常に重要となるのは、正しいサーバーがブラウザの要求を処理できるということです。たとえば、キャッシュの中に特定のセッションを格納したサーバーなどです。セッションのスティッキー性は、すべてのバックエンドサーバーに対して https を使用するよりも、クッキーと http を使用することによってより容易に実現できます。
通常の本稼働環境では、Portal Server と Secure Remote Access を別々のマシンに配備します。ただし、複数のハードウェアドメインをサポートする Sun EnterpriseTM ミッドフレームマシンの場合は、同じ Sun Enterprise ミッドフレームマシンの異なるドメインに Portal Server と SRA の両方をインストールできます。Portal Server と Secure Remote Access に関係する通常の CPU とメモリーの要件は引き続き適用されるので、それぞれの要件を別々のドメインに実装します。
このタイプの設定では、セキュリティーの問題に注意します。たとえば、ほとんどの場合、Portal Server ドメインはイントラネットに配置され、Secure Remote Access ドメインは DMZ に配置されます。
このセクションでは、サイジングプロセスで役立つヒントを紹介します。
企業対顧客用ポータルの場合、Secure Remote Access がゲートウェイおよび SSL を使用するよう配備する必要があります。サイジング要件には、必ずこの点を盛り込んでください。SSL を有効にすると、SSL なしの場合に比べ、ポータルのパフォーマンスが最大で 1/10 にまで低下します。
どんなポータルであっても、余裕をもって構築して成長に備えます。つまり、現状の必要に合わせてサイジングするだけでなく、将来の必要と能力も考慮に入れます。これには、週末や祝日などの休日明けに生じる通常のピークの場合、またはポータルがより「スティッキー」であるために時間の経過とともに使用量が増加する場合などがあります。
地理的に複数のサイトに渡ってポータルソリューションを配備する場合は、ネットワークとデータセンターの配置を十分理解している必要があります。
必要な冗長機能のタイプを判断してください。生産ダウンタイム、アップグレード、およびメンテナンス作業などの要素を考慮します。ポータルサーバーの運用を停止する場合は、通常、処理能力に与える影響が全体の処理能力の 4 分の 1 を超えないようにします。
一般に、企業対社員用ポータルの使用並行性は、企業対顧客用ポータルの場合より高くなります。