B キャパシティ・プランニング

アプリケーションのニーズを十分に満たすために、必要なソフトウェアおよびハードウェア構成を決定するプロセスをキャパシティ・プランニングといいます。キャパシティ・プランニングは精密科学ではありません。アプリケーションやユーザーの動作はそれぞれ異なります。次の項では、キャパシティ・プランニングの概要を説明します。

キャパシティ・プランニングの要因
アプリケーション・パフォーマンスの目標の評価
ハードウェアのチューニング
ネットワークのパフォーマンス
関連ドキュメント

キャパシティ・プランニングの要因

WebLogic Serverインスタンスと特定のアプリケーションをサポートするために、ハードウェア構成にどの程度のキャパシティが必要となるかは、様々な要因に左右されます。アプリケーションのサポートに必要なハードウェア・キャパシティは、アプリケーションと構成の詳細によって異なります。それぞれの要因が構成とアプリケーションにどう影響するのかを考える必要があります。

次の項では、いくつかの要因を取り上げて説明します。これらの要因について理解した上でアプリケーションの要件を検討すると、構成のサーバー・ハードウェア要件を作成しやすくなります。表B-1のキャパシティ・プランニングに関する質問を考慮してください。

表B-1 キャパシティ・プランニングの要因と情報リファレンス

キャパシティ・プランニングに関する確認事項	詳細の参照先
WebLogic Serverは十分にチューニングされているか。	アプリケーション・パフォーマンスの目標の評価
ユーザー・アプリケーションは効率的に設計されているか。	データベース・サーバーのキャパシティとユーザー・ストレージ要件
帯域幅は十分か。	ネットワーク負荷
同時実行が必要なトランザクション数はどのくらいか。	同時セッション
データベースは制約要因となっているか。追加のユーザー・ストレージ要件はあるか。	データベース・サーバーのキャパシティとユーザー・ストレージ要件
WebLogic Serverのほかに何がマシンで実行されているか。	ネットワーク負荷
クライアントはWebLogic Serverへの接続にSSLを使用しているか。	SSL接続とパフォーマンス
クライアントはどのような種類のトラフィックを生成するか。	RMIとサーバーのトラフィック
WebLogic Serverアプリケーションにはどのような種類のクライアントが接続するか。	プログラムに基づくクライアントとWebベースのクライアント
現在のデプロイメントはクラスタ用に構成されているか。	クラスタリングされた構成
サーバーは移行できるように構成されているか。	サーバーの移行

プログラムに基づくクライアントとWebベースのクライアント

WebLogic Serverには、主に以下の2種類のクライアントが接続します。

Webベースのクライアント(WebブラウザやHTTPプロキシなど) :このクライアントは、HTTPまたはHTTPS (セキュア)プロトコルを使用して、HTMLまたはサーブレットの出力を取得します。
プログラムに基づくクライアント(Javaアプリケーションやアプレットなど) :このクライアントは、RMIを使用してT3プロトコル経由でサーバーに接続します。

HTTPはステートレスであるという性質を持つため、サーバーはプログラムに基づくクライアントの場合よりも多くのオーバーヘッドを処理する必要があります。しかし、ブラウザの利用性やファイアウォールとの互換性など、HTTPクライアントにはパフォーマンス・コストに見合う数多くの利点があります。

T3はクライアント側のプレゼンテーション作業の多くを処理するので、一般には、プログラムに基づくクライアントの方がHTTPクライアントよりも効率的です。通常、Webクライアントはサーブレットを経由しますが、プログラムに基づくクライアントはEJBを直接呼び出します。このため、サーバーがプレゼンテーションを処理する必要がなくなります。T3プロトコルはソケットを使用して機能するので、サーバーとの間で接続を長時間継続します。

プログラムに基づくクライアントだけを利用するようにインストールされたWebLogic Serverでは、複数のWebLogic Serverが利用するHTTPプロキシよりも多いクライアントを同時に処理できます。HTTP上でT3をトンネリングした場合、このパフォーマンスの向上は見られません。実際には、パフォーマンスがHTTPに比べて15%低下し、同じようにWebLogic Serverの最適キャパシティも引き下げられます。

RMIとサーバーのトラフィック

クライアントはどのようなサーバー・トラフィックを発生させるでしょうか。T3クライアントを使用する場合は、サーバーとのほとんどの対話にRemote Method Invocation (RMI)が関わります。RMIを使用するクライアントは、センダーとリスナーがそれぞれ1つなので、サーバーとの間に大量のトラフィックを発生させることはありません。

RMIは、HTTPトンネリングを使用してRMI呼出しがファイアウォールを通過するようにできます。通常、HTTPをトンネリングするRMIは、非トンネリングRMIのような高いパフォーマンスを提供しません。

SSL接続とパフォーマンス

Secure Sockets Layer (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プロセスの負荷

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を増やす必要があります。Oracleでは、処理が最小限のキャパシティを上回ると予想される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つのマルチプロセッサ・サーバーに配置しています。

Enterprise JavaBeans (EJB)またはサーブレットのセッションのレプリケーションを実行する大規模なクラスタは、小規模なクラスタに比べてより広い帯域幅が必要です。セッション・データのサイズとクラスタのサイズを検討してください。

サーバーの移行

サーバーが移行のために構成されているかを確認してください。WebLogic Serverの移行とは、障害が発生した場合に、クラスタリングされたWebLogic Serverインスタンスまたはクラスタリングされたインスタンスで実行中のコンポーネントを別の場所に移動する処理です。サーバー全体を移行する場合は、サーバーのインスタンスは、障害が発生すると別の物理マシン上に手動または自動で移行されます。

本番環境でのキャパシティ・プランニングについては、移行中にサーバーを起動すると、CPUに負荷がかかることがあります。マシンで同時にある台数のサーバーを実行できるので、同じマシンで同時に同じ数のサーバーを起動できるわけではありません。

アプリケーションの設計

アプリケーションが効率的に設計されているかどうかを調査してください。WebLogic Serverは、ユーザー・アプリケーション用のプラットフォームです。ユーザー・アプリケーションの設計が不適切な場合、または設計が最適化されていない場合、特定の構成では、10 - 50%もパフォーマンスが大幅に低下することがあります。WebLogic Server向けに開発されたすべてのアプリケーションが最適化されているわけではなく、ベンチマーク・アプリケーションほどのパフォーマンスを発揮するわけではない、と考えるようにしてください。予想される最大キャパシティを増やしてください。「アプリケーションのチューニング」を参照してください。

アプリケーション・パフォーマンスの目標の評価

キャパシティ・プランニングのこの段階では、サーバー上で予測されるアクティビティのレベルに関する情報を収集します。予想されるユーザーの数、リクエストの数、許容できるレスポンス時間、および望ましいハードウェア構成などです。サーバー・ハードウェアのキャパシティ・プランニングでは、最大のパフォーマンス要件に焦点を絞り、キャパシティに関して測定可能な目標を設定します。

提供されているサンプル・アプリケーションのいずれかを使って計算される数値はもちろん、お使いのアプリケーションで確認できる数値の概算にすぎません。本番ハードウェアを使った実際の本番アプリケーションでのベンチマークに匹敵するものはありません。特に、実際のアプリケーションでは、提供されているテスト・アプリケーションでは捕捉されにくい競合やその他の問題が明らかになる場合があります。

ハードウェアのチューニング

パフォーマンスを調べる場合、所定のハードウェア構成でWebLogic Serverと所定のアプリケーションをサポートするためにどのくらいのキャパシティが必要となるかは、多くの要因が影響します。アプリケーションのサポートに必要なハードウェア・キャパシティは、アプリケーションと構成の詳細によって異なります。それぞれの要因を、どのように各アプリケーションおよび構成に適用するかを検討する必要があります。

パフォーマンスを評価するためのベンチマーク

Standard Performance Evaluation Corporation (http://www.spec.org)は、コンピュータ・システムのパフォーマンスを評価するための標準ベンチマークおよびメトリックを提供しています。

サポートされるプラットフォーム

サポート対象の構成に関するページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)には、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