test

Sun Java System Portal Server 7.1 配備計画ガイド

第 5 章 配備設計の計画

ソリューションのライフサイクルにおける配備設計の段階では、高レベル配備アーキテクチャーと低レベル実装仕様を設計し、ソリューションの実装に必要な一連の計画および仕様を準備します。プロジェクトの承認は、配備設計の段階で行われます。

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

配備設計について

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

配備アーキテクチャーの設計は反復プロセスです。サービス品質要件を通常何度も確認し、初期設計を再検証します。サービス品質要件の相互関係を考慮に入れ、トレードオフと所有コストに伴う課題のバランスを取り、最終的にプロジェクトのビジネス目標を満たすことのできる最適なソリューションを考案します。

配備計画に着手するには、すでに詳細にわたって文書化され、テストされている参照アーキテクチャーや構築ブロックアーキテクチャーから始める方法が最適です。ゼロの状態から着手するよりも、このアーキテクチャーに対して適宜変更を加えるほうが簡単です。配備設計を成功に導く要因とは、過去の設計実績、システムアーキテクチャーに関する知識、ドメインに関する知識、および創造的思考の応用です。

配備設計は通常パフォーマンス要件の達成を中心に行われますが、同時にほかのサービス品質要件にも対応する必要があります。採用する戦略は、設計に関する決定のトレードオフと、ソリューションの最適化のバランスを取る必要があります。使用される方法には、通常、次のタスクが含まれます。

  1. プロセッサ要件を見積もる。配備設計は、通常、論理アーキテクチャーのポータルのサイジングから始まります。ユースケースを活用し、適宜見積りを修正します。また、過去のエンタープライズシステム設計の実績も考慮に入れます。

  2. セキュリティー保護されたトランスポートのプロセッサ要件を見積もる。セキュリティー保護されたトランスポートを必要とするユースケースを調査し、それに応じて CPU の見積りを修正します。

  3. サービスをレプリケートし、可用性とスケーラビリティーを実現する。可用性とスケーラビリティーのサービス品質要件に対応するため、設計に修正を加えます。可用性とフェイルオーバーの検討事項に対応可能な負荷分散ソリューションを考慮に入れます。

  4. 分析において、設計に関する判断のトレードオフを見出します。たとえば、可用性とスケーラビリティーの戦略は、システムのサービス性 (保守) にどのような影響を与えるか。戦略の導入には、ほかにどのような代償が伴うか。

  5. ボトルネックを特定する。配備設計を検証し、データ伝送が要件を下回る原因となるボトルネックを特定し、調整を行います。

  6. リソースを最適化する。リソース管理の配備設計を検証し、要件を満たしながらコストを削減できるオプションを検討します。

  7. リスクを管理する。ビジネスおよび技術面の分析を再確認し、初期計画では予測し得なかったイベントまたは状況を反映した設計に変更します。

プロセッサ要件の見積り

利用分析において基準が確立されれば、その数値を検証、微調整して、スケーラビリティー、高可用性、信頼性、および良好なパフォーマンスを実現できます。

Procedureプロセッサ要件の見積り手順

  1. 「基準サイズのカスタマイズ」

  2. 「基準サイズの検証」

  3. 「基準サイズの微調整」

  4. 「最終基準サイズの検証」

    以下のセクションではこれらのステップについて説明します。

基準サイズのカスタマイズ

Portal Server を配備する場合の適切な 見積もりサイズを設定する作業は反復プロセスです。 入力値を変更すれば、幅のあるサイジング結果を生成できます。Portal Server 配備をカスタマイズすると、パフォーマンスに多大な影響が及ぶことがあります。

サイジングの見積もりが完了したら、次の点を考慮します。

LDAP トランザクション数

以下の、工場出荷状態でポータルを配備する場合の LDAP トランザクション数を使用して、LDAP マスターとレプリカのサービス要求に与える影響を理解してください。これらの数字は、システムのカスタマイズを開始すると変更されます。これらの数字は開発者用サンプルとして取り出され、Access Manager の作業が含まれます。

Web コンテナの要件

Web コンテナにインストールされた Portal Server の主な使用法の 1 つ は、ポータルプロバイダを、アプリケーションサーバーで動作している Enterprise JavaBeansTM アーキテクチャー、または Java Database Connectivity (JDBC) および LDAP (LDAPSDK) などの J2EE テクノロジスタック構造体と統合することです。このような、ほかのアプリケーションとモジュールはリソースを消費するので、ポータルのサイジングに影響を及ぼします。最適な方法は、接続プールや、Web コンテナを通じて提供される JNDI ツールを使用することです。

基準サイズの検証

ここまでで、ポータルを配備する場合の CPU の見積もり数が算出されるので、試験的な配備を行なってポータルのパフォーマンスを測定します。ロードバランス機能を使用して、ストレステストを実行して、次の要素を決定します。

Portal Server にはポータルのサンプルが用意されています。使用するチャネルに類似のチャネルでサンプル使用し、システムに負荷をかけることができます。サンプルはポータルデスクトップにあります。

試験的な配備を使用して、最終的なサイジング見積もりを決定します。試験的な配備により、バックエンド統合をサイジングし、Portal Server の動作に関係する潜在的なボトルネックを回避します。

基準サイズの微調整

次のステップでは、導き出したサイズを微調整します。このセクションでは、スケーラビリティー、高可用性、信頼性、および優れたパフォーマンスを特長とするポータルサイトを配備できるように、適切な量の余裕値を組み込みます。

基準サイズは多くの見積もり値に基づいて導き出されるので、微調整してから使用してください。

基準サイズを微調整する場合は、次の指示に従います。

最終基準サイズの検証

試験的な配備を使用して、ポータルの配備方法がビジネス要件と技術要件を満たすことを検証します。

パフォーマンスのボトルネックの特定

設計段階で潜在的なボトルネックを特定することで、ポータルのパフォーマンスニーズを計画することができます。

メモリー消費と、パフォーマンスに与えられる影響に関するセクションに進む前に、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 パラメータを使用します。

リソースの最適化

次の手順を実行すると、リソースを最適化できます。

ロードバランサへの SSL オフロード

Secure Remote Access ゲートウェイのような SSL 集中サーバーは、毎回のセキュリティー保護トランザクションで要求される暗号化を実行するために、大きな処理能力を必要とします。SSL 機能を実装したロードバランサを使用すると、暗号化アルゴリズムの実行をオフロードすることで Portal Gateway を高速化できます。

DMZ のロードバランサの SSL トラフィックを終了すると、ポータルトポロジが簡素化されます。Access Manager セッションはクッキーに保持されます。パフォーマンスの観点から非常に重要となるのは、正しいサーバーがブラウザの要求を処理できるということです。たとえば、キャッシュの中に特定のセッションを格納したサーバーなどです。セッションのスティッキー性は、すべてのバックエンドサーバーに対して https を使用するよりも、クッキーと http を使用することによってより容易に実現できます。

Sun Enterprise ミッドフレームライン

通常の本稼働環境では、Portal Server と Secure Remote Access を別々のマシンに配備します。ただし、複数のハードウェアドメインをサポートする Sun EnterpriseTM ミッドフレームマシンの場合は、同じ Sun Enterprise ミッドフレームマシンの異なるドメインに Portal Server と SRA の両方をインストールできます。Portal Server と Secure Remote Access に関係する通常の CPU とメモリーの要件は引き続き適用されるので、それぞれの要件を別々のドメインに実装します。

このタイプの設定では、セキュリティーの問題に注意します。たとえば、ほとんどの場合、Portal Server ドメインはイントラネットに配置され、Secure Remote Access ドメインは DMZ に配置されます。

リスクの管理

このセクションでは、サイジングプロセスで役立つヒントを紹介します。