キャパシティ プランニング ガイド
|
 |
 |
|
BEA WebLogic Portal が稼動するハードウェアは、ローエンドの PC からハイエンドのメインフレームまでさまざまです。アプリケーションのニーズを十分に満たすために必要なソフトウェアおよびハードウェア コンフィグレーションを決定するプロセスを、キャパシティ プランニングといいます。
このドキュメントでは、WebLogic Portal 8.1 のキャパシティ プランニングに必要な手順と、BEA のキャパシティ プランニング評価ツールを使用したこれらの技法の応用について説明します。
キャパシティ プランニングは精密科学ではありません。アプリケーションやユーザの動作はそれぞれ異なります。このドキュメントは、キャパシティ プランニングの数値を求めるためのガイドとしてのみ利用されることを目的としています。利用の際には細心の注意を払うようにしてください。
注意 : このガイドで推奨されている事項はすべて、システムをプロダクション環境に移行する前に十分に検証する必要があります。プロトタイプを十分にテストすることが、キャパシティ プランニングの数値を求める最善の手段です。
このキャパシティ プランニング ガイドには、WebLogic Portal 8.1 のキャパシティ プランニングに関する情報が記載されています。その他のキャパシティ プランニングの詳細については、最寄の BEA の販売代理店にお問い合わせください。
WebLogic Portal と特定のアプリケーションをサポートするために、ハードウェア コンフィグレーションにどの程度のキャパシティが必要となるかは、さまざまな要因に左右されます。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーションとコンフィグレーションの詳細によって異なります。それぞれの要因がコンフィグレーションとアプリケーションにどう影響するのかを考える必要があります。
以下の節では、これらのいくつかの要因について説明します。これらの要因を理解し、アプリケーションの要件を検討しておくと、コンフィグレーション内のサーバのハードウェア要件を作成する際に役立ちます。
詳細については、WebLogic Server の『キャパシティ プランニング』を参照してください。
セキュア ソケット レイヤ (Secure Sockets Layer : SSL) は、セキュアなインターネット通信を実現するための標準プロトコルです。WebLogic Server のセキュリティ サービスは、X.509 デジタル証明書とアクセス制御リスト (ACL) をサポートすることにより、参加者を認証し、ネットワーク サービスへのアクセスを管理します。たとえば、SSL を使用すると、従業員の給与が一覧された JSP ページを保護して、機密情報へのアクセスを遮断できます。
SSL には大量の計算処理が必要となります。SSL プロトコルで暗号化処理をサポートすると、その分だけ WebLogic Server で同時接続を処理できなくなります。
クライアントの合計数のうち、必要となる SSL 接続の数に注意してください。一般に、サーバは、1 つの SSL 接続を処理する能力で 3 つの非 SSL 接続を処理できます。SSL を使用すると、SSL 接続に使用される暗号化の強度に応じて、サーバのキャパシティは約 33 ～ 50% 低下します。また、SSL によって強いられるオーバーヘッドの量は、SSL に対応しているクライアントの対話数にも関係してきます。
SSL は、ハードウェア アクセラレータを使用して実装することもできます。WebLogic Server のドキュメントを参照してください。
WebLogic Portal 以外に、何がマシン上で実行されていますか。WebLogic Portal を実行しているマシンでは、プレゼンテーションやビジネス ロジックより、はるかに多くの処理が実行されている場合があります。たとえば、Web サーバを実行していたり、株価情報サービスからの株式情報の供給など、リモート情報が常時供給されている可能性があります。
WebLogic Portal マシンの処理能力が、WebLogic Portal に関係のないプロセスによってどのくらい消費されるのかを考慮してください。WebLogic Portal (または WebLogic Portal が稼動しているマシン) が、他に大量の処理を実行している場合は、他のプロセスにどの程度の処理能力を割り当てるかを判断する必要があります。
データベースはボトルネックになっていますか。追加のユーザ ストレージ要件はありますか。多くのインストール環境では、データベース サーバの方が WebLogic Portal よりかなり早くキャパシティを消費します。アプリケーションを処理するには、十分に堅牢なデータベースをプランニングする必要があります。通常、優れたアプリケーションには、アプリケーション サーバ ハードウェアの 3 ～ 4 倍強力なデータベースが要求されます。したがって、データベース サーバには個別のマシンを使用することをお勧めします。
一般に、WebLogic Portal CPU の使用率が 80 ～ 90% の範囲を維持できない場合、データベースがボトルネックになっていると言えます。これは、WebLogic Portal が、ほとんどの時間、アイドル状態でデータベースの応答を待っていることを示します。この場合、クラスタ内のロード バランシングを行えば、CPU の使用率はノード間でほぼ均等になります。
一部のデータベース ベンダは、アプリケーション サーバ用のキャパシティ プランニング情報を提供し始めています。通常、これはアプリケーションの 3 層モデルに対応しています。アプリケーションによっては、データベースと対話しない処理にユーザ ストレージを必要とする場合があります。たとえば、セキュアなシステムでは、各ユーザのセキュリティ情報を格納するディスクとメモリが必要です。この場合は、1 人のユーザの情報を格納するのに必要なサイズを計算し、その値に予想されるユーザ数を掛けてください。
ここでは、400 万人のユーザを作成する場合に行われるテーブルスペースの変更に基づいた、RDBMS Authenticator ユーザの Oracle サイズ見積もり例を示します。この見積もりには、ポータル フレームワークのカスタマイズ用の容量は含まれません。USER_SECURITY テーブルと ENTITY テーブルのみをテストしました。
サイズの見積もりは、Oracle9i Enterprise Edition Release 9.2.0.5.0 に対して行いました。
注意 : この調査で使用したベンチマークで得られた基準値は、WebLogic Portal と、同様のベンチマークを実行した他のポータルやハードウェアを比較するためには使用しないでください。この調査では、独自のベンチマーク方式とチューニングが使用されています。
WebLogic Portal で処理する必要がある同時ユーザ セッションの最大数を調べます。処理するユーザ数が多いほど、効率化を図るため RAM を多く追加する必要があります。BEA Systems では、WebLogic Portal インスタンスごとに、少なくとも 256 MB のメモリをインストールすることを推奨しています。
次に、同時にリクエストを発行するクライアントの最大数と、各クライアントがリクエストを発行する頻度を調べます。WebLogic Portal とユーザ間の 1 秒当たりの対話数が、Portal デプロイメントで 1 秒間に処理する必要がある合計対話数になります。
また、需要の急激な増加に対応するために、特定期間内のトランザクションの最大数も考慮する必要があります。たとえば、株価レポート アプリケーションでは、株式市場のオープン直後とクローズ直前のトランザクションの急騰に備えたプランニングを行います。ワールド シリーズやワールド カップ サッカーの決戦中に Web サイトを広告としてブロードキャストする企業も、需要の急増を予測する必要があります。同時ユーザに関するベンチマーク情報については、「思考時間を伴う同時ユーザ」を参照してください。
帯域幅は十分ですか。需要に応じてリソースの供給を増やすことができないと、ネットワーク パフォーマンスに影響します。WebLogic Server では、クライアントからのすべての接続を処理するために十分な帯域幅を必要とします。HTTP クライアントのみを処理する場合は、静的ページを処理する Web サーバと同程度の帯域幅が必要です。
LAN インフラストラクチャの要件を左右する主な要因は、セッション情報のインメモリ レプリケーションの使用です。クラスタ内では、セッション情報のインメモリ レプリケーションが LAN 帯域幅の最大の消費者となります。アプリケーションでセッション情報のレプリケーションが必要かどうかを検討してください。
特定のデプロイメントの帯域幅が十分かどうかを調べるには、ネットワーク オペレーティング システム ベンダから提供されているネットワーク ツールを使用します。Windows NT、Windows 2000、Solaris などのほとんどのケースでは、ネットワーク システム上の負荷を調べることができます。負荷が非常に高い場合は、帯域幅がシステムのボトルネックになっている可能性があります。
ネットワーク トラフィックを最適化するために、ギガビット ネットワークとハードウェア ロード バランサを実行することをお勧めします。
WebLogic Portal Server は、クラスタをサポートするようにコンフィグレーションされていますか。クラスタをコンフィグレーションすることにより、セッションが保護され、状態のレプリケーションによるフェイルオーバが実現します。クラスタを使用している場合、パフォーマンスの低下を著しく感じることはありません。プロダクション環境への WebLogic のデプロイメントの多くは、1 つのマルチプロセッサ サーバに WebLogic Server のクラスタを配置しています。
Web サーバを使用して WebLogic Server クラスタにリクエストを転送している場合は、Web サーバがボトルネックになることがあります。この問題は、付属の HttpClusterServlet とプロキシ サーバを使用している場合、またはサポート対象のいずれかのプラグインを使用している場合に発生する可能性があります。クラスタにサーバを追加しても応答時間が改善されず、Web サーバ マシンの CPU 使用率が 95% を超える場合は、Web サーバをクラスタ化するか、Web サーバを実行しているハードウェアを強化することを検討してください。
チューニングされたアプリケーションでのキャパシティ テストによると、WebLogic Portal は通常 CPU 処理の割合が高いので、プロダクション環境用に購入するハードウェア数を決定する場合は、プロセッサの速度を最優先にする必要があります。
ほとんどの場合、WebLogic Server クラスタは、2 つの CPU につき 1 つの WebLogic Server インスタンスの割合でデプロイするのが最適です。ただし、すべてのキャパシティ プランニングと同じように、サーバ インスタンスの最適数および分散方法を決定する場合は、対象となるポータル アプリケーションで実際のデプロイメントを事前にテストする必要があります。
アプリケーションは適切に設計されていますか。ユーザ アプリケーションの設計が不適切だったり、最適化されていない場合、コンフィグレーションのパフォーマンスが 10 ～ 50% も大幅に低下する可能性があります。WebLogic Portal 用に開発されているアプリケーションは、すべてが最適化されるとは限らず、ベンチマーク アプリケーションほどのパフォーマンスも期待できないと考えるようにしてください。万一に備えて、計算または予測される最大キャパシティを増やす必要があります。
ポータルの設計の詳細については、次のドキュメントを参照してください。
WebLogic Portal は十分にチューニングされていますか。提供されているチューニング ガイドを参照して、WebLogic Server をチューニングする必要があります。サーバをチューニングしないと、パフォーマンスが低下します。
WebLogic Server のチューニングの詳細については、『WebLogic Server パフォーマンス チューニング ガイド』を参照してください。
WebLogic Portal では 2 種類のキャパシティ テストを実行しました。1 つはスループットへのアクセス (思考時間はゼロ) で、もう 1 つは同時ユーザの最大数の判定 (平均思考時間 5 秒) です。
どちらのデータ セットでも、X 人のユーザを 1 時間の間 Y 秒ごとに追加してからテストを終了するランプアップ スタイルのテストを使用しました。
テストでは、各ユーザがログインしてからページをクリックして進み (非常に小規模のポータルを除いて 50 ページ/ブックのクリック)、最後のページに達すると最初のページが繰り返されるスクリプトを使用しました。非常に小規模のポータルのページ数は 8 ページであるため、クリックは 8 回でした。テスト スクリプトは 60 分間実行しました。
テスト アプリケーションは、.portal ファイルと .portlet ファイルを含む EAR としてクラスタにデプロイされます。各ユーザがテストの間セッションを維持できるように、フォームベースの認証を使用しました。ポータル自体のサイズとポートレット タイプはさまざまです。テストした各ポータルには、JSP、JSR 168、ページフロー、Struts、プリファレンスなどのポートレット タイプが 1 つ含まれ、使用したポートレットは「Hello World」タイプのポートレットのような単純なポートレットと考えられます。ツリー最適化が使用されました。資格またはカスタマイズは有効になっていませんでした。
ポートレット サイズは、次のパラメータによって変化します (ポータル内のポートレットの総数を各パラメータの後に示します)。
非常に小規模のポータル (合計で 1 つのブック、8 ページ、およびページ当たり 8 つのポートレット) を除き、各ポータル サイズのブック数はさまざまで (小規模 - 5、中規模 - 10、大規模 - 20、および非常に大規模 - 40)、各ブックのページ数は 10 ページ、ページ当たりのポートレット数は 10 個です。
ベンチマークは、HP Linux と Sun Solaris という 2 つのハードウェア コンフィグレーションで実行しました。
注意 : この調査で使用したベンチマークで得られた基準値は、WebLogic Portal と、同様のベンチマークを実行した他のポータルやハードウェアを比較するためには使用しないでください。この調査では、独自のベンチマーク方式とチューニングが使用されています。
HP Linux テストでは、4 台の物理マシンで構成された 8 CPU のコンフィグレーションを使用しました。各マシンで 1 つ、クラスタ内で計 4 つの管理対象サーバが実行されており、これらのサーバは各物理マシン上で 1 つのポータルおよび 1 つの JVM になります。
-gc:parallel を設定した JRockit。各サーバに 1.5GB のヒープを割り当てました。 25 の実行スレッドと JDBC 接続プールで開始したサーバは、50 接続にまで拡張できる 25 接続から開始するように設定しました。ポータル表示キューは 5 (デフォルト) に設定しました。サーバがすぐに飽和するように、これらのテストは思考時間を 0 秒として実行しました。
Sun Solaris テストでは、2 台の物理マシンで構成された 8 CPU のコンフィグレーションを使用しました。各マシンで 2 つ、クラスタ内で計 4 つの管理対象サーバが実行されており、これらのサーバは各物理マシン上で 2 つのポータルおよび 2 つの JVM になります。
-server を設定した Hotspot。各サーバに 1.5GB のヒープを割り当てました。 25 の実行スレッドと JDBC 接続プールで開始したサーバは、50 接続にまで拡張できる 25 接続から開始するように設定しました。ポータル表示キューは 5 (デフォルト) に設定しました。サーバがすぐに飽和するように、これらのテストは思考時間を 0 秒として実行しました。
このテストでは、テスト ポータルが一定の応答時間でサポートできる同時ユーザ数を明らかにしました。2 秒と 5 秒の目標応答時間を使用しました。表に記載されている同時ユーザ数は、2 秒または 5 秒での最大同時実行ユーザ数を表します。一方のデータ セットでは WebLogic Server に Apache プラグインを使用し、もう一方では BigIP F5 ハードウェア ロード バランサを使用しました。このテストでは、HP Linux コンフィグレーションを使用しました。「HP Linux のハードウェアとサーバのコンフィグレーション」を参照してください。
これらのテストは、思考時間を使用して現実のアプリケーションを模倣しているという点でベンチマーク テストとは異なります。思考時間 (ユーザ リクエストの間隔) は、5 秒 +/- 25% でランダムに設定しました。
WebLogic Portal では、WebLogic Platform のさまざまなコンポーネントを使用します。WebLogic Portal のチューニングの詳細については、次のドキュメントを参照してください。
|
|
|