test

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

第 3 章 技術要件の特定

ソリューションライフサイクルの技術要件段階で、使用分析を実行し、使用事例を特定して、配備ソリューション案のサービス要件の品質を判断します。

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

技術要件について

技術要件分析は、ソリューションライフサイクルのビジネス分析段階で作成されたビジネス要件ドキュメントを使用して開始します。ビジネス分析を基礎として使用し、次のことを行います。

サービス品質要件は、ビジネス要件や事前に特定された制約を考慮して、使用分析および使用事例から導き出されます。サービス品質要件は、あとに論理設計段階で論理アーキテクチャーと組み合わされ、配備シナリオを形成します。配備シナリオは、ソリューションライフサイクルの配備設計段階に対する、主要な入力値です。

ビジネス分析と同様に、使用分析、使用事例、およびシステム要件を導き出す技術要件分析の決まった形式は存在しません。技術要件を分析するには、事業領域、事業目標、および基礎となるシステムテクノロジを把握しておく必要があります。

Portal Server の使用分析

論理設計、アーキテクチャー設計および配備設計で使用できる基本サイズを確立する必要があります。 技術担当者は、Portal Server の配備で必要になる CPU の数の見積もりを算出する自動サイジングツールを提供します。

注 –

Sun JavaTM System Secure Remote Access ソフトウェアを使用した安全性の高いポータル配備のサイジング要件は、「Secure Remote Access の使用状況分析」で説明されています。

サイジングツールへの入力値として、次のメトリクスを収集する必要があります。

Portal Server の配備で必要になる CPU の数に影響を与えても、サイジングツールでは使用されないその他のパフォーマンスメトリクスは次のとおりです。

これらのパフォーマンス要因については、続くセクションで説明します。

ピーク数

最大並行セッション数は、配備される Portal Server で処理可能な接続ユーザー数を定義します。

最大並行セッション数を計算するには、次の計算式を使用します。

最大並行セッション数 =
オンラインユーザーの予想割合 * ユーザーベース

企業ポータルの見込みユーザーのユーザーベースサイズまたはプールサイズを特定するには、次の提案を参考にしてください。

ページ要求間の平均時間

ページ要求間の平均時間は、Portal Server からユーザーがページを要求する頻度の平均です。ページには、ポータルにログインしたときの最初のログインページや、ポータルデスクトップからアクセスする Web サイトや Web ページなどがあります。1 ページの表示とは、ページに配置されているアイテム数に関係なく、1 回の呼び出しで表示される 1 つの情報ページを指します。

Web サーバーのログにはページ要求が記録されますが、ログを使用して要求から要求までの平均時間をユーザー単位で計算することはできません。ページ要求間の平均時間を計算するには、WebLoad パフォーマンステストツールのような市販の統計ツールが必要です。ツールを使用して得られた数値を基にして、並行処理ユーザー数を判断できます。

ストレステストを実行する場合は、SLAMD Distributed Load Generation Engine を使用できます。SLAMD の詳細については、http://slamd2.dev.java.net/ を参照してください。

注 –

ページ要求を基準にすると、「ヒット数」を基準にするよりも Web サーバーのトラフィックを正確に測定できます。Web サーバーからのファイル要求は、1 ヒットとして毎回計上されます。ページにあるすべてのアイテムが登録されているので、1 回のページ呼び出しで何度もヒットが記録されます。たとえば、10 個のグラフィックファイルが組み込まれているページの場合は、HTML ページ自体で 1 回、および 10 個のグラフィックファイルそれぞれが 1 回ずつカウントされ、合計 11「ヒット」が記録されます。したがって、ページ要求を基準にしたほうが Web サーバーのトラフィックをより正確に判断できます。

並行処理ユーザー

並行処理ユーザーは、実行中の Web ブラウザプロセスに接続し、Portal Server に要求を送信するか、要求の結果を受信しているユーザーです。最大並行処理ユーザー数は、あらかじめ定義された時間内に接続可能な並行処理ユーザーの最大数です。最大並行処理ユーザー数は、最大並行セッション数を算出してから計算します。最大並行処理ユーザー数を計算するには、次の計算式を使用します。

並行処理ユーザー = 並行セッション数 / ヒット間の平均時間

たとえば、ユーザーが 50,000 人のイントラネット Portal Server の例について考えます。負荷ピーク時に接続されているセッション数を、登録されたユーザーベースの 80% と見積もります。ユーザーは、平均で 10 分に 1 回の割合でポータルデスクトップにアクセスします。

この例の場合の計算方法は次のようになります。

40000 / 10 = 4000

したがって、この Portal Server の負荷ピーク時に接続できる最大並行処理ユーザー数は 4,000 人になります。

平均セッション時間

平均セッション時間は、多くのユーザーを対象に算出した、ログインからログアウトまでの平均時間です。セッション時間の長さは、発生するログイン数に反比例します。つまり、セッション期間が長くなると、同じ並行処理ユーザーベースでの Portal Server に対する毎秒のログイン数が少なくなります。セッション時間は、ユーザーのログインからログアウトまでの時間です。

平均セッション時間は、多くの場合、ユーザーの Portal Server の使い方によって変化します。たとえば、対話型のアプリケーションが関係するユーザーセッションの場合は、情報のみのユーザーセッションの場合よりも、セッション時間が長くなるのが一般的です。

検索サービスの要素

ポータルサイトで検索チャネルを提供する場合は、検索エンジンのサイジング要素をサイジングの計算に含める必要があります。検索エンジンのサイジング要件は、次の要素によって決まります。

ページ設定

認証されたポータルを使用する場合は、自動サイジングツールのページ設定セクションにある「Login Type」と「Desktop Type」の両方を指定する必要があります。

ログインタイプとデスクトップタイプの両方の場合に、次の適切なコンテンツ設定を選択します。

ヒント –

ここまでで、上述の数値を技術担当者に伝え、サイジングツールを実行して CPU の見積もり数を算出するように依頼できます。

ポータルデスクトップ設定

ポータルデスクトップの設定によって、セッション単位でメモリーに保持するデータ量が明確に決定されます。

ポータルデスクトップのチャネルが多くなるほど、データのセッションサイズは大きくなり、Portal Server のスループットが低下します。

もう 1 つの要素は、ポータルデスクトップで提供される対話機能の性能です。たとえば、チャネルをクリックすると、Portal Server または他の外部サーバーに負荷が発生します。チャネルの選択によって Portal Server に負荷が発生すると、ポータルデスクトップをホストするノードのユーザークティビティープロファイルと CPU オーバーヘッドは、他の外部サーバーをホストするノードの場合より高くなります。

ハードウェアとアプリケーション

CPU 速度と、Java プラットフォーム (Java 仮想マシンまたは JVMTM ソフトウェア) のメモリーヒープにおける仮想マシンのサイズは、Portal Server のパフォーマンスに影響を与えます。

CPU 速度が速くなれば、スループットも高くなります。ヒープ生成チューニングパラメータとともに、JVM メモリーヒープのサイズも Portal Server のパフォーマンスを左右します。

バックエンドサーバー

Portal Server は外部ソースからコンテンツを集約します。外部のコンテンツプロバイダが、最大速度で動作する Portal Server に必要な帯域を確保できない場合、ポータルデスクトップのレンダリングとスループットの要求時間は最適化されません。ポータルデスクトップは、ブラウザに要求応答を返す前に、すべてのチャネル動作が完了するかタイムアウトになるまで待機します。

次のチャネルを使用する場合は、バックエンドのインフラストラクチャーを慎重に計画してください。

トランザクション時間

トランザクション時間は、HTTP または HTTPS 処理が完了するまでの遅延時間で、送信時間、処理時間、および応答時間を合計した時間です。

トランザクション時間に影響する要素について計画する必要があります。これには、次の要素があります。

トランザクション時間を計算する場合は、Portal Server のサイジングを行なって、通常またはピーク時の負荷状態がパフォーマンス要件のしきい値を超えないように、また時間が経過しても処理時間を維持できるようにします。

ワークロード条件

ワークロード条件は、システムにおいてもっとも集中的に使用される、システムリソースと JVM ソフトウェアリソースです。これらの条件は、大部分がユーザーの動作と配備するポータルのタイプによって決まります。

Portal Server ソフトウェアで一般的に発生するワークロード条件は、次の要素に影響を与えます。

Secure Remote Access の使用状況分析

このセクションは、組織において、Secure Remote Access をインストールして安全性の高いポータルを実装する場合にのみお読みください。ポータルの場合に行なったのと同様、Secure Remote Access の場合にも、最初にゲートウェイインスタンスの基準見積もりサイズを設定する必要があります。1 台のマシンにインストールできるゲートウェイは 1 つだけですが、複数のインスタンスを持つことはできます。Secure Remote Access により、それぞれが複数のインスタンスで動作する複数のゲートウェイをインストールできます。設計上の決定事項は、Secure Remote Access のユーザーセッションと並行性に関して正確な試算を行うのに役立ちます。

まず、ゲートウェイインスタンスの基準サイジング見積もりを設定する必要があります。この基準値は、ゲートウェイのユーザーセッションと並行処理の必要に応じて満たす必要のある条件を示しています。

Secure Remote Access を配備する場合の適切な見積もりサイズを設定する作業は反復プロセスです。入力値を変更すれば、幅のあるサイジング結果を生成できます。これらの結果をユーザーの本来の要件に照らしてテストします。要件を正しく定義し、Secure Remote Access のパフォーマンスとして実際的な値に設定すれば、パフォーマンスが関係するほとんどの問題を回避できます。

注 –

ゲートウェイを適正にサイジングする作業は複雑なので、ゲートウェイのサイジングツールを使用する段階は単なる始まりにすぎません。ゲートウェイのパフォーマンスはスループットに大きく依存し、それ以外にもユーザー数、アクティブユーザー数、またはユーザーセッション数が影響します。ゲートウェイのサイジング情報は、前提セットに基づいている必要があります。

スケーラビリティー

ゲートウェイインスタンスあたり、1 個、2 個、および 4 個の CPU を選択できます。ゲートウェイインスタンスにバインドされた CPU の数により、配備に必要なゲートウェイインスタンスの数が決まります。

Secure Remote Access のプロトタイプの数値の使用

Secure Remote Access を使用しているポータルのプロトタイプから得られた数値がある場合は、ゲートウェイサイジングツールでそれらの数値を使用して、より正確な結果を導き出すことができます。次の値を入力します。

注 –

試験的な配備数を使用する場合は、「Page Configuration」オプションと「Scalability」オプションを指定する必要はありません。

主要なパフォーマンス要素

主要なパフォーマンス要素とは、技術担当者が自動サイジングツールへの入力値として使用するメトリクスのことです。サイジングツールは、Secure Remote Access を配備する際に必要となるゲートウェイインスタンスの見積もり数を算出します。

これらの主要なパフォーマンス要素を特定し、それを技術担当者に伝えることは、基準サイズを決定するための第一歩です。

主要なパフォーマンス要素は次のとおりです。

注 –

これらの主要なパフォーマンス要素を計算し終えたら、技術担当者に計算値を伝えます。ゲートウェイのサイジングツールを実行して、ゲートウェイインスタンスの見積もり数を導き出すように依頼します。

セッション特性

ゲートウェイのセッション特性は次のとおりです。

Netlet の使用特性

以下に示すゲートウェイの Netlet 特性について考慮してください。これらの特性は、ゲートウェイインスタンス数の計算に影響を与えます。

Portal Server の使用事例

使用事例は、システムの能力をテストして示し、高レベルの設計の重要な部分を形成するために記述されたシナリオです。使用事例シナリオはプロジェクトの終わりの方で実現しますが、要件が定まったら、プロジェクトの早い段階でまとめておきます。

利用できる場合、使用事例はシステムをどのようにテストすべきかを判断する際に役立ちます。使用事例は、ユーザーインタフェースをどのように設計するかを、ナビゲーションの観点から決定する際に役立ちます。使用事例を設計する際には、使用事例を要件と比較して、使用事例の完成度、またテスト結果の解釈方法を判断します。

使用事例は、要件をまとめる手段にもなります。要件の一覧の代わりに、ユーザーがシステムをどのように使用できるかを説明するストーリーのように要件をまとめます。これにより完成度と一貫性が向上し、またユーザーの観点から見た要件の重要性について、さらに理解を深めることができます。

使用事例は、ポータルの機能要件を特定および明確にするために役立ちます。使用事例は、ユーザーとポータル間のやり取りのセット、またポータルが実行する必要があるサービス、タスク、および機能など、ポータルのさまざまな使い方をすべて網羅します。

使用事例は、外部のアクターとポータルシステム間の目的のあるやり取りのセットを定義します。アクターは、システムとやり取りするシステム外に存在するパーティーであり、ユーザーのクラス、ユーザーが担うことのできるロール、またはその他のシステムになります。

使用事例は、対象領域の用語を使用した、理解しやすい構造化された物語として記述されます。

使用事例のシナリオは、使用事例の 1 つの例であり、使用事例の 1 つの筋道を表します。したがって、使用事例の主な筋に対するシナリオ、また使用事例の起こりうるさまざまな筋 (たとえば、各オプションを表す) に対するシナリオを作成できます。

Portal Server の使用事例の開発の準備

ポータルの使用事例を開発する場合は、次に示す要素に注意してください。

使用事例の例: ポータルユーザーの認証

表 3–1 では、ポータルのユーザーがポータルに認証される使用事例について説明します。

表 3–1 使用事例: ポータルユーザーの認証

アイテム 

説明 

優先順位 

必須です。 

使用の背景 

認証済みのエンドユーザーのみがポータルのリソースにアクセスを許可されます。このアクセス制限は、コンテンツおよびサービスを含む、すべてのポータルのリソースに適用されます。このポータルは、企業の LDAP ディレクトリで管理されているユーザー ID を利用します。 

範囲 

ポータルエンドユーザーは、完全なオンラインセッションのために 1 回だけ自分の身元を証明します。アイドルタイムアウトが発生する場合は、ユーザーは自分の身元を再度証明する必要があります。ポータルエンドユーザーの身元証明の失敗回数が指定された許容再試行回数よりも多い場合、システム管理者がアカウントを再び有効にするまで、イントラネットへのアクセスは拒否または制限 (無効) される必要があります。この場合、ポータルエンドユーザーに、担当者に連絡するように勧める必要があります。身元が確認されたポータルエンドユーザーは、許可されたデータおよび情報にだけアクセスできます。 

プライマリユーザー 

ポータルエンドユーザー。 

特別な要件 

なし。 

関係者 

ポータルエンドユーザー。 

前提条件 

ポータルエンドユーザーは、

  • 承認されたユーザー。

  • 標準的な企業 LDAP ユーザー ID を持っている。各従業員に LDAP ユーザー ID を提供する必要があります。

  • 承認された LDAP エントリを持っている。

  • 企業イントラネットにアクセスできる。

  • ゲストアカウントは持っていない。

最小限の保証 

顧客主体の親切なメッセージ。ステータス — 誰に連絡するかを示すエラーメッセージ付き。 

成功の保証 

ポータルデスクトップのホームページを表示します。認証。権利の付与。個人情報。 

トリガー 

ポータルページがアクセスされときに、エンドユーザーがまだログインしていない場合。 

説明 

  1. エンドユーザーがポータル URL を入力します。

  2. カスタマイズパラメータ [remember login] を設定した場合、ユーザーを自動的にログインさせ、セッション ID を提供します。

  3. 初めてのユーザーの場合、LDAP ユーザー ID とパスワードの入力を要求します。

  4. エンドユーザーは、事前に割り当てられたユーザー ID とパスワードを入力します。

  5. 情報は検証のために Access Manager に渡されます。

  6. 認証に成功した場合、セッション ID を割り当て、続行します。

  7. 認証に失敗した場合、エラーメッセージを表示してエンドユーザーをログインページに戻し、残りの試行回数を減分します。事前に設定された試行回数の制限を超えた場合、ユーザーに通知してアカウントをロックアウトします。

サービス品質要件

サービス品質を実現するには、次のトピックに対処します。

パフォーマンス

ポータルシステム管理者およびポータル開発者と話し合い、計画される要件に基づいてポータルのパフォーマンス目標を設定します。目標には、ユーザー数、負荷ピーク時の並行処理ユーザー数、および Portal Server にアクセスする際のユーザーの使用パターンなどがあります。

次の 2 つの要素を決定する必要があります。

並行してポータルに接続するユーザー数が増加すると、ハードウェアとパラメータセットが同じであれば、応答時間が減少します。そのため、Portal Server の予想使用レベル、任意の時刻に予想される並行処理ユーザー数、ポータルデスクトップのアクティビティー要求数、ポータルチャネル使用量、組織によって決定されるエンドユーザーへの許容応答時間、および基準を満たす最適ハードウェア構成に関する情報を収集してください。

可用性

Portal Server の可用性を高めるには、次の各コンポーネントの可用性を高める必要があります。

スケーラビリティー

スケーラビリティーとは、パフォーマンスを低下させることなく、処理リソースを追加することによって、増加するユーザー人口に対応するシステムの能力のことです。システムをスケーリングするための 2 つの一般的な方法には、垂直方向のスケーリングと水平方向のスケーリングがあります。このセクションの主題は、Portal Server のスケーリング技術の応用です。

スケーラブルなシステムの利点を次に示します。

垂直方向のスケーリング

垂直方向のスケーリングでは、CPU、メモリー、Portal Server の複数のインスタンスなどのリソースが 1 つのマシンに追加されます。これより、より多くのプロセスインスタンスが同時に実行できます。Portal Server では、必要な CPU の数に計画およびサイズ指定することによってこれを利用できます。

水平方向のスケーリング

水平方向のスケーリングでは、マシンが追加されます。これは、複数の同時処理とワークロードの分散も可能にします。Portal Server では、Portal Server、Directory Server、および Access Mangaer を異なるノードで実行できるので、水平方向のスケーリングを利用します。水平方向のスケーリングは、さらに CPU を追加するなどして、垂直方向のスケーリングも利用できます。

また、サーバーコンポーネントインスタンスを複数のマシンにインストールすることによって、Portal Server インストールを水平方向にスケールできます。インストールされた各サーバーコンポーネントインスタンスは、HTTP プロセスを実行し、この HTTP プロセスはインストール時に決定された番号の TCP/IP ポートで待機します。ゲートウェイのコンポーネントは、ラウンドロビンアルゴリズムを使用して新しいセッション要求をサーバーインスタンスに割り当てます。セッションが確立されている間は、クライアントに格納された HTTP cookie がセッションサーバーを示します。それ以降の要求はすべてそのサーバーに送られます。

「地域化の設計」のセクションでは、最適のパフォーマンスと水平方向のスケーラビリティーを提供する特定のタイプの構成への取り組み方について説明します。

セキュリティー

セキュリティーとは、サーバーおよびそのユーザーを悪意のある外部の者から保護するハードウェア、ソフトウェア、運用方法、および技術の集合のことです。それに関連して、セキュリティーは予期しない行為から保護します。

セキュリティーには、グローバルに対処し、ユーザーやプロセスだけでなく製品や技術も含める必要があります。あいにく、多くの組織が、唯一のセキュリティー方針としてファイアウォール技術のみに依存しています。それらの組織は、多くの攻撃は外部の者ではなく、従業員によるものであることに気づいていません。したがって、安全なポータル環境を構築するときには他のツールやプロセスを考慮する必要があります。

安全な環境で Portal Server を稼働させるには、SolarisTM オペレーティング環境、ゲートウェイとサーバーの設定、ファイアウォールのインストール、および Directory Server による認証と Access Manager による SSO に対して特定の変更を行う必要があります。また、証明書、SSL 暗号化、グループおよびドメインアクセスを使用できます。

アクセス制御

Portal Server では、UNIX システムのセキュリティー機能に加え、HTTPS 暗号化プロトコルに依存して、Portal Server システムソフトウェアを保護しています。

セキュリティーは Web コンテナによって実現され、必要に応じて SSL を使用するように設定できます。Portal Server は、認証とエンドユーザー登録の場合の SSL もサポートしています。Web サーバーで SSL 証明書を有効にすることにより、ポータルデスクトップや他のアプリケーションにもセキュリティー保護してアクセスできます。Access Manager ポリシーを使用して、URL ベースのアクセスポリシーも設定できます。

Portal Server は、Access Manager によって提供される認証サービスを利用して、Access Manager SSO メカニズムを使用するすべての製品間でのシングルサインオン (SSO) をサポートします。SSO メカニズムでは、エンコードされたクッキーを使用してセッション状態を保持します。

Secure Remote Access には、さらに別のセキュリティー機能があります。Secure Remote Access では、デフォルトで HTTPS を使用して、クライアントのブラウザをイントラネットに接続します。ゲートウェイでは、リライタまたはプロキシレットを使用して、インターネットに直接コンテンツを公開せずにイントラネットの Web サイトにアクセスする仕組みを実現しています。またゲートウェイにより、アクセスされる Web サーバーに変更を加えずに、URL ベースのアクセスポリシーも設定できます。

ゲートウェイからサーバーおよびイントラネットリソースへの通信には、HTTP または HTTPS を使用できます。Web アプリケーションとディレクトリサーバーとの間の通信のように、Portal Server 内での通信では、デフォルトで暗号化を使用しませんが、SSL を使用するように設定できます。

UNIX ユーザーのインストール

次に示す 3 種類の UNIX ユーザー下に Portal Server をインストールおよび構成できます。

アクセス制御の制限

従来の UNIX のセキュリティーモデルは通常、絶対的ですが、代替ツールを使用していくらか柔軟にできます。それらのツールは、異なる UNIX コマンドなどの個々のリソースに対するきめ細かなアクセス制御を可能にするために必要な手段になります。たとえば、このツールセットは、Portal Server を root として稼働させるのを可能にし、また特定のユーザーおよびロールに Portal Server フレームワークの起動、停止、および維持のためのスーパーユーザー権限を与えます。

それらのツールを次に示します。

セキュアアクセスゾーンの使用

最高のセキュリティーを実現するには、2 つのファイアウォール間にゲートウェイをインストールします。もっとも外側のファイアウォールはインターネットからゲートウェイへの SSL トラフィックのみを通し、次にゲートウェイがトラフィックを内部ネットワークのサーバーへ転送します。

地域化の設計

地域化とは、テキストおよび文化的な内容を特定の対象者向けに適合させる処理のことです。地域化には、次の 2 つの方法で取り組むことができます。

高度な言語の地域化の場合、テンプレートのディレクトリのために正しく定義されたディレクトリ構造を作成します。アップグレードパスを保つには、カスタムコンテンツとカスタムコードをデフォルトのディレクトリ外に保持します。地域化については、『Sun Java System Portal Server 7.1 Developer’s Guide 』を参照してください。