第 2 章   チューニングとサイジングについて


この章では、パフォーマンスのチューニングに関するヒントと技法について説明します。iPlanet^TM Application Server のチューニング可能な一部のパラメータの簡易ガイドにもなっています。

この章には次のトピックがあります。

• iPlanet Application Server のチューニングが必要な理由

• アプリケーションのサイジングについて

• サイジングに影響を与える要因

• 操作要件について

• パフォーマンスの予測

• 一般的なパフォーマンスのガイドライン

• パフォーマンスチューニングの手順

iPlanet Application Server のチューニングが必要な理由

---

アプリケーションサーバのパフォーマンスに影響を与える変数は非常に多いため、すべてのサイトで最適なパフォーマンスを得られる設定というものはありません。システムのサイズが適切であっても、デフォルトの配置にほんのわずかな変更を加えただけで、パフォーマンスが大きく向上することがあります。

こうした変更によって、システム全体のパフォーマンスが向上することがあります。ある変更は開発環境に良い影響を与えても、運用環境には反対の場合があります。また、その逆のこともあります。

iPlanet Application Server のチューニングを始める前に、チューニングによって得られる結果を正確に評価しておく必要があります。この章では、iPlanet Application Server を最適化するための、さまざまなチューニングオプションやサイジングオプションを紹介します。

確認のために、iPlanet Application Server のプロセスアーキテクチャを次の図に示します。

図 2-1   

iPlanet Application Server のプロセスアーキテクチャ

アプリケーションのサイジングについて

---

システムのサイジングをすると、特定のユーザ負荷をサポートするのに必要なハードウェアの数と種類を予測することができます。

システムを適切なサイズにするには、負荷、アプリケーション、およびプラットフォーム (オペレーティングシステムとハードウェア) の特徴を理解することが重要です。

この節では、負荷、アプリケーション、およびプラットフォームを測定し、アプリケーションサーバのシステム要件を見積もる方法について詳しく説明します。

アプリケーションのサイジング方法を説明する前に、サイジングに影響する各種要因について理解しておく必要があります。

サイジングに影響を与える要因

次の表に、アプリケーションのサイジングに影響を与える要因を示します。

表 2-1    サイジングに影響を与える要因

要因	説明
ユーザ負荷	負荷を処理するのに必要なハードウェアとシステム負荷が釣り合っている必要があります。
アプリケーションの設計と実装	仕事量が非常に少ないアプリケーションでは、同じハードウェアでも多くのユーザを扱うことができます。多くの場合、この種のアプリケーションは共有リソースを待機している時間の割合が大きいため、調整が難しくなります。その反対に大量の計算を実行するアプリケーションは、ユーザごとのハードウェアリソースがより多く必要になる傾向がありますが、この場合のほうがうまく調整されます。
	スレッドが共有リソースを競合するアプリケーションでは、共有リソースを待機する時間が多いので、1 つのサーバ内でうまく調整できない傾向があります。このような状況には、多くの小規模サーバを配置するソリューションが最適です。
	サーバ間で共有リソースを競合するアプリケーションでは、共有リソースを待機するために時間が費やされるので、クラスタ内ではうまく調整できない傾向があります。このような状況には、少数の大規模サーバを配置するソリューションが最適です。
ハードウェアプラットフォーム	必要なハードウェアの数を減らす上でプロセッサそのもののパフォーマンスが重要になります。通常、アプリケーションでは浮動小数点に集中した計算が含まれていないので、内部的なパフォーマンスが、通常もっとも重要な要因となります。応答時間は、プロセッサのパフォーマンスに大きく依存しています。
安全マージン	共有リソースの著しい競合が発生する可能性がある場合は、高速プロセッサを使用していても、サーバをうまく調整できません。通常、プロセッサをサーバに追加すると達成されるパフォーマンスを判断するうえで、キャッシュの設計とメモリの帯域幅が重要な役割を果たします。

操作要件について

---

単純な配置のチューニングを始める場合、実装チームで、iPlanet Application Server と使用するアプリケーションの要件に基づいた操作環境の概要レイアウトを作成することができます。この概要レイアウトに、システムの外部インタフェースの相対位置を示します。概要レイアウトからより具体的な設計に移行する前に、新しいシステムについて次の操作要件を考慮する必要があります。

• セキュリティ

• 可用性

• パフォーマンス

セキュリティ

ブラウザと Web サーバ間の通信を暗号化しようとする場合は、以下の要因を考慮する必要があります。

• アプリケーションのすべてまたは一部で、ブラウザと Web サーバ間の通信を暗号化する必要性

• Web サーバ層を、アプリケーションサーバ層およびバックエンドの企業システムから分離された非武装地帯 (DMZ) に配置するかどうか

• Web サーバとアプリケーションサーバ間での暗号化の必要性

Web サーバと iPlanet Application Server 間の通信を暗号化する方法については、『iPlanet Application Server 管理者ガイド』の第 6 章「サーバリソースの可用性の向上」を参照してください。

可用性

アプリケーションの可用性を高めるために、以下の要因を考慮する必要があります。

• アプリケーション可用性の要件。マシンが利用できなくなったときのサービスの損失を許容できるか

• ユーザのセッション情報の損失を許容できるか

• アプリケーションがほかの操作環境で対話処理する場合、弱点となる可能性のあるリンク

• これらの弱点を適度に強化できるか。それともそのようなリンクは不変なものか

• 多くの企業では、80% の CPU ビジーレートを最高点とみなしている。自分の会社の標準は何パーセントか

パフォーマンス

パフォーマンスに関連する以下の要因を考慮する必要があります。

• アプリケーションとのさまざまな対話処理で、エンドユーザに必要となる応答時間

• 認知可能な安定状態およびピーク時のユーザ負荷

• Web リクエストごとの平均およびピーク時のデータ転送量

• 次の 12 ヶ月のユーザ負荷の増加率

ピーク時のユーザ負荷については、アプリケーションサーバで管理される同時セッションの数に注意する必要があります。多くの組織で、ピーク時のユーザ負荷を、同時ユーザの平均数でなく最大ユーザ数とみなしていることがしばしば見受けられます。ユーザ負荷をより現実的な観点から見ると、理論上ピーク時のユーザ数は、数十万あるいは数百万の同時ユーザから数万の同時ユーザへと劇的に減少します。

これらの操作上の要件を定義したら、配置環境の理解を次の段階に進めることができます。ここで、操作上のセキュリティおよび可用性の要件として、ファイヤウォール群から分離された Web サーバとアプリケーションサーバの複数のインスタンスを環境の基礎とするとします。そのため、DMZ と保護されたバックエンドのビジネスシステムとを区分できるようにするために、独立したマシンの層が必要になります。また、アプリケーションの可用性を高めるため、各層の複数のマシンのインスタンスについても計画する必要があります。

このような前提から操作環境が次第に絞り込まれますが、まだシステムに必要なコンピュータの正確な数やサイズには至りません。次の段階では、パフォーマンスの予測方法とシステムサイズの指定方法についての基本的理解を深めます。

パフォーマンスの予測

---

サイジングのプロセスに影響を与える要因と操作環境の概要レイアウトから、既存のハードウェアの組み合わせで得られる能力または特定の能力を維持するために必要な最小のハードウェアを、どのようにして予測したらよいのでしょうか。その疑問に答えるには、前の節の説明にあるデータを収集し、iPlanet Application Server に含まれているサイジングのカリキュレータでそのデータを使用するのが最良の方法です。

iPlanet には、iPlanet Application Server に配置されるアプリケーションをサイジングする際に役立つ、2 つのカリキュレータが用意されています。最初のカリキュレータは、前の節で説明した要因に基づいて、CPU の数や各層のマシン数などのシステムのサイズを計算します。2 番目のカリキュレータは、与えられたハードウェア設定の最大能力を計算します。

一般的なアプリケーションワークフロー用も含め、複数のテストの組み合わせに基づいて iPlanet はこれらのカリキュレータを構築し、RDBMS とプロセッサ用に広く使用できるベンチマークの結果を利用しています。2つのカリキュレータとも、完全にチューニングされたシステムを前提としています。

サイジングのカリキュレータを使用する以外に、以下の手順に基づいて、アプリケーションのサイジングを理解することをお勧めします。

1. 1 つの CPU のパフォーマンスを判断する

   最初に、既知の処理能力で維持できる最大の負荷を決定する必要があります。この数値は、ユニプロセッサのマシンでアプリケーションのパフォーマンスを測定して得ることができます。似た特性のある処理を行う既存のアプリケーションのパフォーマンス数値、または理想的には、開発中に行われた基本的なパフォーマンステストの結果を使用します。

   単独 CPU でのパフォーマンスを判断する一方で、基本的な環境のチューニングを開始する必要があります。どのようなパフォーマンステストを使用しても、ドライバマシン、Web サーバ、データベースマシンなどのテスト範囲外のシステムがテストを妨害しないようにする必要があります。テストに妨害があった場合は、パフォーマンスの数値が不自然に低くなり、サイジングの結果に悪影響を及ぼすことがあります。

2. 垂直スケーラビリティの判断

   プロセッサを追加すると、どのくらいの追加パフォーマンスを得ることができるかを、正確に知っておく必要があります。つまり、サーバ上で該当のワークフローによって、共有リソースの競合が発生する回数を間接的に測定します。この情報は、マルチプロセッサシステムでアプリケーションに追加の負荷テストを実行して入手することができます。または、すでに負荷テストが実行された類似したアプリケーションの情報を使用することもできます。最大 で4 つの CPU 上で一連のパフォーマンステストを実行すると、通常は、システムの垂直スケーラビリティの特性に関するまずまずの結果が提供されます。

   サイジングの見積もりに基づき、目標とする設定が行われたシステムの負荷のもとで、アプリケーションを実行してみることが重要です。垂直スケーラビリティを判断する一方、可用性の要件を満たした設定がされていることも確認してください。たとえば、1 つの JVM で障害が起こっても、すべてのセッションが喪失されないように保証するには、最低 2 つの JVM で垂直スケーラビリティのテストを実行し、これら JVM 間でセッションの複製を設定してください。

3. 水平スケーラビリティの判断

   サーバを追加するとどのくらいの追加パフォーマンスを得ることができるかを、知っておく必要があります。類似したアプリケーションの情報がまだ利用できない場合は、アプリケーションサーバシステムのクラスタのベンチマークが再び必要になります。水平スケーラビリティテスト環境の概略を作成する際に、高度な可用性の要件に付随するセッション複製の設定を必ず考慮してください。

   この場合、アプリケーションサーバの各インスタンス内の JVM にセッションの複製が作成されるほか、複数のマシンに配置されたアプリケーションサーバのインスタンスにまたがってセッションが複製されます。この一連のテストを実行すると、アプリケーションサーバのパフォーマンスがはっきりと理解できます。この情報を使用して、独自のサイジング式を作成できます。

   最初に、既知の処理能力で維持できる負荷を判断する必要があります。この数値は、マルチプロセッサについて推定するためにユニプロセッサでアプリケーションのパフォーマンスを測定して得ることができます。

単一インスタンスのインストールという基本的な高可用性 (HA) サイトのサイジング式は、次のとおりです。

TotalProcessorCount =(P*(1.0-k) * (ks+P*k*K*(1.0-2.0 * K) +sqrt(4.0 *ks*K*(1.0-K)*(ks+P*k*(1.0-2.0*K)))) / ((ks-P*k*K) * (ks-P*K*K));

ここで、

• P = ピーク時の負荷に必要なパフォーマンス (スループット)。CPU 利用率の最大レベルが指定されている場合は、その値で P を除算します。たとえば、10,000 ユーザの 80% を超えてサーバがビジーになってはならない場合は、 P = 10,000/0.80 = 12,500 とします。

• k= (1 - CPU スケーラビリティ) / (1+ CPU スケーラビリティ)。CPU スケーラビリティは、異なる CPU 数のサーバでアプリケーションを実行して測定します。この場合の CPU スケーラビリティは、2 番目のプロセッサを追加して獲得できる追加のパフォーマンスのことです。CPU スケーラビリティは、ワークフロー、アプリケーションサーバソフトウェア、オペレーティングシステム、およびサーバハードウェアに左右されます。

• ks= CPU 自体のパフォーマンス。これは、このハードウェア上の該当するアプリケーションで必要とされるスループット (P) です。ks は、少なくとも 1 台のプラットフォームで測定され、測定されたプラットフォームに対するものとして新しいプラットフォーム上の SPECint_base95 パフォーマンス率を使用して推定されます。

• K = (1 - サーバのスケーラビリティ)。「(1 + サーバのスケーラビリティ) - サーバのスケーラビリティ」は、異なるサーバ数またはアプリケーションサーバのインスタンス数を使用して、クラスタ上でアプリケーションを実行して測定します。この場合のサーバのスケーラビリティは、最初のサーバと同じ 2 番目のアプリケーションサーバを追加して獲得できる追加のパフォーマンスのことです。

この式は、必要な合計 (最低) プロセッサ数の見積もりです。またこの値は、設定が最適化されることを想定したものです。これらの値はアプリケーションによって異なることに注意してください。最適なクラスタ数、アプリケーションサーバのインスタンス数、およびサーバごとのプロセッサ数を識別するために、さまざまな式の値が使用されます。この値は、1 つのサーバがダウンしても必要なピーク時の負荷を満たす必要があることも想定されています。

単一サーバのサイジングのもう 1 つの方法は、サイトに必要なスループットのレートを確立して、ワークフローが以下の 3 つの例のどれかに適合するかどうかを判断することです。

• Servlet で実装されるオンラインストア。共通してアクセスされるページはキャッシュされる

• Servlet で実装されますが、共通してアクセスされるページがないオンラインストア。そのため、キャッシュは無効にされる

• JSP、Servlet、セッション、およびエンティティ Beans の混合で実装されるオンラインストア。キャッシュは無効にされる

一般的なパフォーマンスのガイドライン

---

次の表は、サイジングとアプリケーションのパフォーマンスに影響を与える要因を示しています。

表 2-2    サイジングに影響を与える要因 - 概念の適用

概念	概念の適用	測定単位	値の根拠
ユーザ負荷	最大同時セッション	トランザクション速度 (RPM、WIPS)	最大同時ユーザ数/クリック間隔
			加入者のセッション時間数/セッション間隔
アプリケーションの設計と実装	CPU パフォーマンス単位ごとのトランザクション速度	SPECint_base95 ごとの RPM	ベンチマークによる測定
	サーバ内のスケーラビリティ (追加 CPU のパフォーマンス)	%	ベンチマークの適合曲線に基づく %
	クラスタ内のスケーラビリティ (追加サーバのパフォーマンス)	%	ベンチマークの適合曲線に基づく %
ハードウェアプラットフォーム	プロセッサのパフォーマンス (通常は整数パフォーマンス)	SPARC®20@40Mhz のパフォーマンス率	SPECint_base95
	スケーラビリティ (多くの場合、キャッシュ設計とメモリ帯域)	%	ベンチマークの適合曲線に基づく %
安全マージン	高可用性要件	当てはまる場合は、サーバシステムが 1 つダウンしたという前提でシステムのサイズを指定	高可用性が要求される場合は別の式を使用
	% ビジー高水位	%	通常は 80%、許容可能なリスクのレベルを計算する必要がある

パフォーマンスチューニングの手順

---

iPlanet Application Server とその関連要素は、次の手順でチューニングすることをお勧めします。

• アプリケーションのチューニング

• iPlanet Application Server のチューニング

• Java 実行時システムのチューニング

• オペレーティングシステムのチューニング

• データベースサーバのチューニング

  これらのトピックについては、次の章で詳しく説明します。