|
|
アプリケーションのニーズを十分に満たすために、必要なソフトウェアおよびハードウェア コンフィグレーションを決定するプロセスをキャパシティ プランニングといいます。キャパシティ プランニングは精密科学ではありません。アプリケーションやユーザの動作はそれぞれ異なります。以下の節では、キャパシティ プランニングの概要を説明します。
WebLogic Server インスタンスと特定のアプリケーションをサポートするために、ハードウェア コンフィグレーションにどの程度のキャパシティが必要となるかは、さまざまな要因に左右されます。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーションとコンフィグレーションの詳細によって異なります。それぞれの要因がコンフィグレーションとアプリケーションにどう影響するのかを考える必要があります。
以下の節では、これらの要因のいくつかについて説明します。これらの要因を理解し、アプリケーションの要件を検討しておくと、コンフィグレーション内のサーバのハードウェア要件を作成する際に役立ちます。表 C-1 に示すキャパシティ プランニングに関する確認事項を調べてください。
WebLogic Server には、主に以下の 2 種類のクライアントが接続します。
HTTP はステートレスであるという性質を持つため、サーバはプログラムに基づくクライアントの場合よりも多くのオーバーヘッドを処理する必要があります。しかし、ブラウザの利用性やファイアウォールとの互換性など、HTTP クライアントにはパフォーマンス コストに見合う数多くの利点があります。
T3 はクライアント側のプレゼンテーション作業の多くを処理するので、一般には、プログラムに基づくクライアントの方が HTTP クライアントよりも効率的です。通常、Web クライアントはサーブレットを経由しますが、プログラムに基づくクライアントは EJB を直接呼び出します。このため、サーバがプレゼンテーションを処理する必要がなくなります。T3 プロトコルはソケットを使用して機能するので、サーバとの間で接続を長時間継続します。
プログラムに基づくクライアントだけを利用するようにインストールされた WebLogic Server では、複数の WebLogic Server が利用する HTTP プロキシよりも多いクライアントを同時に処理できます。HTTP 上で T3 をトンネリングした場合、このパフォーマンスの向上は見られません。実際には、パフォーマンスが HTTP に比べて 15% 低下し、同じように WebLogic Server の最適キャパシティも引き下げられます。
クライアントはどのようなサーバ トラフィックを発生させるでしょうか。T3 クライアントを使用する場合は、サーバとのほとんどの対話に Remote Method Invocation (RMI) が関わります。RMI を使用するクライアントは、センダとリスナがそれぞれ 1 つなので、サーバとの間に大量のトラフィックを発生させることはありません。
RMI は、HTTP トンネリングを使用して RMI 呼び出しがファイアウォールを通過するようにできます。通常、HTTP をトンネリングする RMI は、非トンネリング RMI のような高いパフォーマンスを提供しません。
セキュア ソケット レイヤ (SSL) は、セキュアなインターネット通信を実現するための標準です。WebLogic Server のセキュリティ サービスは、X.509 デジタル証明書とアクセス制御リスト (ACL) をサポートして、関係者の認証を行い、ネットワーク サービスへのアクセスを管理します。たとえば、SSL は従業員の給与が記載された JSP ページを保護できます。これにより、機密情報へのアクセスがブロックされます。
SSL では、大量の計算処理が必要となります。SSL プロトコルで暗号化処理を使用すると、その分だけ WebLogic Server が処理可能な同時接続数が減ります。
クライアント総数の中の必要な SSL 接続数に注意してください。一般にサーバは、1 つの SSL 接続を処理する能力で 3 つの非 SSL 接続を処理できます。したがって、SSL を使用すると、サーバのキャパシティは SSL 接続の暗号強度に応じて大幅に低下します。また、SSL によって課せられるオーバーヘッドの量は、SSL 対応のクライアント対話の数に関連します。WebLogic Server には、SSL 処理用のネイティブ パフォーマンス パックが含まれています。
WebLogic Server のほかに何がマシンで実行されているかを調査してください。マシンは、プレゼンテーション ロジックやビジネス ロジックよりもはるかに多くの処理を行っている場合があります。たとえば、Web サーバを実行していたり、株価情報サービスからの株価情報の提供など、リモート情報を提供し続けていたりする場合も考えられます。
WebLogic Server に関係のない処理によって WebLogic Server マシンの処理能力がどのくらい消費されるのかを考慮してください。WebLogic Server (または WebLogic Server が動作しているマシン) が別の重要な処理を実行している場合、その他のプロセスにどの程度の処理能力を割り当てるかを決める必要があります。Web サーバ プロキシが WebLogic Server と同じマシンで実行されている場合は、処理能力の 25 ～ 50% 程度を見込んでおきます。
データベースがボトルネックになっているかどうかを調査してください。また、追加のユーザ ストレージ要件があるのかどうかも調査します。データベース サーバはしばしば、WebLogic Server よりもはるかに早くキャパシティの限界に達します。アプリケーションを処理するためには、十分堅牢なデータベースをプランニングしてください。通常、優れたアプリケーションのデータベースには、アプリケーション サーバのハードウェアよりも 3 ～ 4 倍強力なハードウェアが必要です。したがって、データベース サーバ用に別のマシンを使用することをお勧めします。
一般に、WebLogic Server の CPU 使用率が 85 ～ 95% の範囲に入らない場合、データベースがボトルネックになっていると考えられます。つまり、WebLogic Server はほとんどの時間、アイドル状態でデータベースの応答を待っているということです。クラスタ内でロード バランシングを行うと、ノード間の CPU 使用率はほぼ均等になります。
一部のデータベース ベンダは、アプリケーション サーバ用のキャパシティ プランニング情報を提供し始めています。一般に、これはアプリケーション用の 3 層モデルに対する応答です。
アプリケーションは、データベースと対話しない処理用にユーザ ストレージを必要とする場合があります。たとえば、セキュリティ システムでは、各ユーザのセキュリティ情報を格納するためのディスクとメモリが必要です。1 人のユーザの情報を格納するために必要なサイズを計算し、その数に予期される最大ユーザ数を掛けてください。
どのくらいの数のトランザクションを同時実行する必要があるのかを調査してください。WebLogic Server が処理する必要がある同時セッションの最大数を調べます。効率を上げるには、セッションごとに RAM を増やす必要があります。BEA Systems では、処理が最小限のキャパシティを上回ると予想される WebLogic Server ごとに少なくとも 256MB のメモリを設置することを推奨しています。
次に、同時に要求を送るクライアントの最大数と、各クライアントがどのくらいの頻度で要求を行うかを調べます。WebLogic Server との 1 秒当たりのユーザ対話数は、特定の WebLogic Server デプロイメントによって 1 秒間に処理する必要がある対話の総数を示します。一般に、Web デプロイメントの場合、ユーザ対話は JSP ページまたはサーブレットにアクセスします。アプリケーション デプロイメントにおけるユーザ対話は通常、EJB にアクセスします。
また、要求数が急激に増えた場合に対応するために、指定した期間内のトランザクションの最大数に着目する必要があります。たとえば、株式レポート アプリケーションの場合、株式市場のオープン後とクローズ前の取引の急増に対応したプランニングが必要です。ワールド シリーズやワールド カップ サッカーの決勝戦の間の広告として Web サイトをブロードキャストする場合、需要の急増が予想されます。
帯域幅が十分かどうかを調査してください。WebLogic Server には、クライアントからのすべての接続を処理するだけの十分な帯域幅が必要です。プログラムに基づくクライアントの場合、クライアント JVM ごとにサーバへの 1 つのソケットがあります。各ソケットには帯域幅が必要です。プログラムに基づくクライアントを処理する WebLogic Server では、Web ベース クライアントのサーバが処理する帯域幅の 125 ～ 150% が必要です。Web サーバを実行するために必要な帯域幅は、転送するコンテンツのサイズに応じて、56kbps (キロビット/秒) の帯域幅ごとに 7 ～ 10 の要求を同時に処理できると考えておけばよいでしょう。HTTP クライアントだけを処理する場合は、静的ページを提供する Web サーバと同程度の帯域幅が必要です。
LAN インフラストラクチャの要件に影響を及ぼす主要な要因は、サーブレットおよびステートフル セッション EJB 用のセッション情報のインメモリ レプリケーションの使用です。クラスタでは、セッション情報のインメモリ レプリケーションは LAN 帯域幅を最も消費します。アプリケーションでサーブレットおよび EJB のセッション情報のレプリケーションが必要かどうかを検討してください。
指定のデプロイメントの帯域幅が十分かどうかを調べるには、ネットワーク オペレーティング システム ベンダのネットワーク ツールを利用します。Windows NT、Windows 2000、および Solaris など、多くの場合、ネットワーク システム上の負荷の内容を検査することができます。負荷が非常に高い場合は、帯域幅がシステムのボトルネックになっている可能性があります。
クラスタは、効率とフェイルオーバを大幅に向上させます。クラスタ化していても、ユーザにわかるほどパフォーマンスが低下することはありません。プロダクション環境の WebLogic Server デプロイメントの多くは、WebLogic Server インスタンスのクラスタを 1 つのマルチプロセッサ サーバに配置しています。
エンタープライズ JavaBean (EJB) またはサーブレット用のセッション データのインメモリ レプリケーションを実行する大規模なクラスタは、小規模なクラスタに比べてより広い帯域幅を必要とします。セッション データのサイズとクラスタのサイズを検討してください。
アプリケーションが効率的に設計されているかどうかを調査してください。WebLogic Server は、ユーザ アプリケーション用のプラットフォームです。ユーザ アプリケーションの設計が不適切な場合、または設計が最適化されていない場合、特定のコンフィグレーションでは、10 ～ 50% もパフォーマンスが大幅に低下することがあります。WebLogic Server 向けに開発されたすべてのアプリケーションが最適化されているわけではなく、ベンチマーク アプリケーションほどのパフォーマンスを発揮するわけではない、と考えるようにしてください。予想される最大キャパシティを増やしてください。「アプリケーションのチューニング」を参照してください。
キャパシティ プランニングのこの段階では、サーバ上で予測されるアクティビティのレベルに関する情報を収集します。予想されるユーザの数、要求の数、許容できる応答時間、および望ましいハードウェア コンフィグレーションなどです。サーバ ハードウェアのキャパシティ プランニングでは、最大のパフォーマンス要件に焦点を絞り、キャパシティに関して測定可能な目標を設定します。
提供されているサンプル アプリケーションのいずれかを使って計算される数値はもちろん、お使いのアプリケーションで確認できる数値の概算にすぎません。プロダクション ハードウェアを使った実際のプロダクション アプリケーションでのベンチマークに匹敵するものはありません。特に、実際のアプリケーションでは、提供されているテスト アプリケーションでは捕捉されにくい競合やその他の問題が明らかになる場合があります。
パフォーマンスを調べる場合、所定のハードウェア コンフィグレーションで WebLogic Server と所定のアプリケーションをサポートするためにどのくらいのキャパシティが必要となるかは、多くの要因が影響します。アプリケーションのサポートに必要なハードウェア キャパシティは、アプリケーションとコンフィグレーションの詳細によって異なります。それぞれの要因を、どのように各アプリケーションおよびコンフィグレーションに適用するかを検討する必要があります。
Standard Performance Evaluation Corporation は、コンピュータ システムのパフォーマンスを評価するための標準ベンチマークおよびメトリックを提供しています。
『サポート対象のコンフィグレーション』には、WebLogic Server の各リリースでサポートされているハードウェアおよびオペレーティング システム プラットフォームの最新の動作確認情報があります。
ネットワークのパフォーマンスが低下するのは、リソースの供給が需要に追いつくことができない場合です。最近のエンタープライズ レベルのネットワークは非常に高速で、適切に設計されたアプリケーションであれば、パフォーマンス低下の直接的な原因になることはまれです。しかし、1 つまたは複数のネットワーク コンポーネント (ハードウェアまたはソフトウェア) に問題が見つかった場合は、ネットワーク管理者と協力してその問題を洗い出し、解決する必要があります。WebLogic Server 用に、適切な広さのネットワーク帯域幅、およびアーキテクチャ内の他の層への適切な数の接続 (クライアント接続やデータベース接続など) が用意されているかどうかを検証する必要もあります。したがって、パフォーマンスの潜在的なボトルネックを解消するには、ネットワークのパフォーマンスを継続的にモニタすることが重要です。
帯域幅は、一般には「データ通信の転送レート、通常は通信を送受信するためのリンクの容量を bps (bits-per-second) で表したもの」と定義されます。WebLogic Server を実行するマシンには、そのすべての WebLogic Server クライアント接続を処理できるだけの十分な帯域幅が必要です。プログラムに基づくクライアントの場合、クライアント JVM ごとにサーバへの 1 つのソケットがあり、ソケットごとに専用の帯域幅が必要になります。WebLogic Server インスタンスでプログラムに基づくクライアントを処理するには、同様な Web サーバで処理する場合の 125 ～ 150% の帯域幅が必要になります。HTTP クライアントのみを処理する場合は、静的ページを提供する Web サーバと同程度の帯域幅が必要になると考えてください。
所定のデプロイメントに十分な帯域幅があるかどうかを調べるには、使用しているネットワーク オペレーティング システムのベンダから提供されているネットワーク モニタ ツールを使用して、ネットワーク システム上の負荷を参照します。ネットワークの利用状況は、Solaris の netstat コマンド、Windows のシステム モニタ (perfmon) など、一般的なオペレーティング システム ツールを使用してモニタすることもできます。負荷が非常に高い場合は、帯域幅がシステムのボトルネックになっている可能性があります。
また、アプリケーションとアプリケーション サーバの間およびアプリケーション サーバとデータベース サーバの間で転送されているデータをチェックして、ネットワーク上で転送されるデータの量をモニタします。このデータ量がネットワークの帯域幅を超えないようにします。帯域幅を超える場合、ネットワークがボトルネックとなります。これを確認するには、次のコマンドを使用して、パケットの再転送や重複に関するネットワーク統計値をモニタします。
netstat -s -P tcp
netstat -s -P コマンドを使用してその他の TCP パラメータを表示する手順については、「ndd コマンドを使用した TCP パラメータの設定」を参照してください。
BEA の Web サイトでは、WebLogic Server の全マニュアルが公開されています。キャパシティ プランニングに関連する情報については、『インストール ガイド』の「インストールの準備 : システム要件」を参照してください。
サード パーティの膨大なソフトウェアからも、キャパシティ プランニング関連のトピックに関する情報を入手できます。これには以下のものが含まれます。
|
