キャパシティ プランニング
|
 |
 |
|
以下の節では、WebLogic Server e-コマース プラットフォームのキャパシティ プランニングの概要を説明します。
BEA WebLogic Server は、ローエンドの PC からハイエンドのメインフレームに至るさまざまなハードウェア上で動作します。アプリケーションのニーズを十分に満たすために必要なソフトウェアおよびハードウェア コンフィグレーションを決定するプロセスを、キャパシティ プランニングといいます。このマニュアルでは、サーバのハードウェア要件に焦点を当てて、WebLogic Server のソリューションのキャパシティ プランニングについて解説します。
注意 : キャパシティ プランニングは厳密に科学的な方法ではありません。アプリケーションもユーザの動作もそれぞれ違うからです。このマニュアルは、キャパシティ プランニングの数値を明らかにするための指針として利用することを想定しており、その際は細心の注意を払う必要があることも示します。
このマニュアルで推奨されている内容を特定のシステムに実際に採り入れる場合は、適切な方法で事前に確認してください。最適な方法は、キャパシティ プランニングの数値を試作段階でテストすることです。
WebLogic Server インスタンスおよび特定のアプリケーションをサポートするために特定のハードウェア コンフィグレーションが必要とするキャパシティは、さまざまな要因に左右されます。アプリケーションをサポートするために必要なハードウェア要件は、アプリケーションとコンフィグレーションの詳細によって異なります。これらの要因がそれぞれコンフィグレーションおよびアプリケーションにどのように影響するかを考慮する必要があります。
以下の節では、いくつかの要因を取り上げて説明します。これらの要因について理解した上でアプリケーションの要件を検討すると、コンフィグレーションのサーバ ハードウェア要件を作成しやすくなります。使用するアプリケーションが、「基準アプリケーションの処理結果の検討」に掲載されている基準アプリケーションの数値とどのくらい異なっているかを考慮してください。また、表 1-1 のキャパシティ プランニングに関する質問も考慮してください。
表 1-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 デジタル証明書とアクセス制御リストをサポートして、関係者の認証を行い、ネットワーク サービスへのアクセスを管理します。たとえば、SSL は従業員の給与が記載された JSP ページを保護できます。これにより、機密情報へのアクセスがブロックされます。
SSL では、大量の計算処理が必要となります。SSL プロトコルで暗号化処理を使用すると、その分だけ WebLogic Server が処理可能な同時接続数が減ります。
クライアント総数の中の必要な SSL 接続数に注意してください。一般にサーバは、1 つの SSL 接続を処理する能力で 3 つの非 SSL 接続を処理できます。したがって、SSL を使用すると、サーバのキャパシティは SSL 接続の暗号強度に応じて約 33 ～ 50% 低下します。また、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 や Solaris など、多くの場合、ネットワーク システム上の負荷の内容を検査することができます。負荷が非常に高い場合は、帯域幅がシステムの問題点になっている可能性があります。
クラスタは、効率とフェイルオーバを大幅に向上させます。クラスタ化していても、ユーザにわかるほどパフォーマンスが低下することはありません。プロダクション環境の WebLogic Server デプロイメントの多くは、WebLogic Server インスタンスのクラスタを 1 つのマルチプロセッサ サーバに配置しています。
エンタープライズ JavaBean (EJB) またはサーブレット用のセッション データのインメモリ レプリケーションを実行する大規模なクラスタは、小規模なクラスタに比べてより広い帯域幅を必要とします。セッション データのサイズとクラスタのサイズを検討してください。
アプリケーションの設計は効率化されていますか。WebLogic Server は、ユーザ アプリケーション用のプラットフォームです。ユーザ アプリケーションの設計が不適切な場合、または設計が最適化されていない場合、特定のコンフィグレーションでは、10 ～ 50% もパフォーマンスが大幅に低下することがあります。WebLogic Server 向けに開発されたすべてのアプリケーションが最適化されているわけではなく、ベンチマーク アプリケーションほどのパフォーマンスを発揮するわけではない、と考えるようにしてください。予想される最大キャパシティを増やしてください。
WebLogic Server 向けの最も効率的なアプリケーションを設計するために、WebLogic Server のドキュメントとカスタマ サポート センターを活用できます。最新情報については、WebLogic Server Web サイトを参照してください。
WebLogic Server のデプロイメントは、『WebLogic Server パフォーマンス チューニング ガイド』に従ってチューニングします。サーバをチューニングしていない場合、「基準アプリケーションの処理結果の検討」の基準値に比べてパフォーマンスが約 33% 低下します。
次のステップでは、サンプル アプリケーションの特徴と基準結果を見ていきます。このステップは、使用するアプリケーションのキャパシティ プランニング要件を作成するのに役立ちます。「基準アプリケーションの処理結果の検討」に進んでください。
|
|
|