| Oracle Access Managerデプロイメント・ガイド 10g(10.1.4.3) B55479-01 |
|
 戻る |
 次へ |
キャパシティ・プランニングは、使用量の見積りに基づいて、Oracle Access Managerデプロイメントに対応できる最適なサーバー・ハードウェアを割り出す作業です。この章では、キャパシティ・プランニングの基礎について説明します。この情報は、Oracle Access Managerデプロイメントで負荷ピークの処理に十分対応できるサーバー・ハードウェアを使用するのに役立ちます。この章に含まれる内容は次のとおりです。
Oracle Access Managerデプロイメントの一般的な概要は、第1章を参照してください。
Managerデプロイメントのキャパシティ・プランニングの目標は、次に示す様々な要素を考慮しながら、許容されるレベルのシステム・パフォーマンスを維持することです。
ユーザーがシステムと対話すると予想される時間枠
特定の時間枠にシステムにアクセスすると予想されるユーザーの数
ユーザー・セッションの平均継続時間、一連のトランザクションの継続時間
ユーザー・セッションを構成するページの平均数
それぞれの環境に適したハードウェアを絞り込むには、Oracle Access Managerのサイズ設定およびスケーラビリティの特徴を理解することが重要です。Oracle Access Managerのコンポーネントは、標準的なハードウェアで良好に機能します。ただし、不十分なハードウェアで間に合せようとするより、ハードウェアの性能を強化したほうが費用効率は高くなります。パフォーマンスの低いシステムを維持管理するコストと比較した場合、ハードウェアにかかるコストのほうが低くなります。
キャパシティ・プランニングに含まれる作業は次のとおりです。
この章で説明する方法および手順は、1台のコンピュータへの単一のデプロイメントから多数のサイトへの複数のデプロイメントまで、それぞれのデプロイメントのキャパシティおよびサイズ設定のニーズを特定するのに役立ちます。
|
注意: この章に含まれるガイドラインおよび例は、あくまでデモンストレーション専用です。ユーザーがソフトウェアを使用している特定のハードウェアについて説明しているわけではないため、実際のデータを示していない場合があります。この章に記載されている情報を使用した結果、損失、費用または損害が発生しても、オラクル社は一切の責任を負いかねます。 |
適切なサーバー・サイズ設定によって、特定の時間間隔に予想される最大数の操作をサーバー・ハードウェアに処理させることができます。言い換えれば、Oracle Access Managerデプロイメントのサーバー・ハードウェアは、負荷ピーク時にすべてのユーザーに対処する必要があります。
任意の時間間隔の負荷ピークに関する情報は、通常、次のようにして求められます。
Oracle Access Managerはステートレス・システムです。そのため、予想されるトランザクション・スループットおよびネットワーク通信量の最大値は、キャパシティ・プランニングの重要な要素です。
この項の内容は次のとおりです。
ここでは、Oracle Access Managerデプロイメントのピーク時の負荷を測定するための2つの方法を説明します。この情報を使用して、システム容量全体の要件を見積ることができます。
負荷推定（1秒当たりのユーザーごとのトランザクション数）をサーバー・ハードウェアの機器製造元の仕様書と比較します。比較結果を基に、すでに所有しているコンピュータが予想される負荷を処理できるかどうかを判断できます。既存のコンピュータが不十分な場合は、スループットの要件を1つの基礎として機器を選択できます。
この項で説明する方法には、使用できるネットワーク通信量およびWebサイト使用量のモニタリング・ツールが多数あります。ただし、サード・パーティのツールに関する情報は、このマニュアルには含まれていません。
この項の内容は次のとおりです。
|
注意: ユーザー数が2万未満のデプロイメントであれば、これらの見積り方法でも問題はありません。「中規模から大規模のサンプル・デプロイメント」で説明されているように、標準的なサーバー・クラス・ハードウェアは、ほとんどのデプロイメントに対応できます。 |
負荷の測定には、任意の時間間隔での1秒当たりの最大ページ数および最大リクエスト数を割り出すことが含まれます。これにより、システム容量全体の要件が絞り込めます。
使用量の測定期間は最短で24時間ですが、数週間にわたって使用量を測定することをお薦めします。1年の特定の期間に使用量が急増する場合、最も使用量が大きくなる期間の測定値を取得してください。これにより、最も使用量が大きくなる期間にも当てはまる、より正確なシステム容量要件を引き出せます。
標準的なビジー状態の負荷を見積るには、平均的な高負荷の値に2や3などの小さな整数をかけます。こうすると、負荷のガウス分布（釣鐘曲線）として、平均的な高負荷の値よりも標準偏差が2または3だけ高い使用量のパターンを取得することができます。
使用量が最も大きくなる期間の測定値を取得するために、長期にわたって使用量を測定します。
次の手順で使用する、本番デプロイメントでの最大値を選択します。
平均的な高負荷の値に2や3などの小さな整数をかけて、標準的なビジー状態の負荷のパラメータを見積ります。
次に説明するもう1つの方法では、複数サイトのデプロイメントのアクティブなユーザー・セッションを測定できます。
複数サイトのデプロイメントの場合は、すべてのサイトについてピーク使用量の表を作成し、全サイトの予想合計使用量に基づいて負荷ピークを見積ることをお薦めします。そのためには、1日の異なる時間帯に各サイトでログインしているユーザーの数を記録することも1つの方法です。
|
注意: この方法で正確を期すためには、ピーク時の実際のユーザー・リクエスト数を、使用している稼働中のシステムを監視するか履歴データを使用して割り出す必要があります。 |
表2-1のような表を使用することで、サイトごとに多数のユーザーが最も忙しい時間帯（影付き部分）を見積ることができます。各列は1日のうちの1時間（ローカル時刻）を表し、グリニッジ標準時（GMT）を基準に記録されます。各行は、その1時間に監視されたログイン済ユーザーの数を表します。この例では、メキシコ・シティーでの使用はグリニッジ標準時の12時から24時までで、ピークはグリニッジ標準時の16時から19時の間です。
表2-1 各サイトの予測使用量に基づく負荷ピーク
| グリニッジ標準時によるピーク時間 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
メキシコ |
0 |
0 |
0 |
3 |
75 |
150 |
175 |
225 |
225 |
225 |
225 |
225 |
225 |
225 |
225 |
175 |
|
スペイン |
35 |
50 |
75 |
50 |
25 |
35 |
50 |
75 |
75 |
75 |
75 |
35 |
20 |
0 |
0 |
0 |
|
エジプト |
45 |
45 |
50 |
50 |
50 |
50 |
50 |
55 |
55 |
45 |
30 |
10 |
0 |
0 |
0 |
0 |
|
アメリカ |
0 |
2 |
5 |
10 |
30 |
80 |
95 |
95 |
95 |
95 |
86 |
80 |
80 |
90 |
75 |
60 |
|
コロンビア |
0 |
2 |
7 |
15 |
30 |
45 |
45 |
50 |
50 |
50 |
55 |
55 |
55 |
55 |
45 |
35 |
|
コスタリカ |
0 |
0 |
0 |
0 |
2 |
5 |
10 |
10 |
10 |
12 |
12 |
12 |
12 |
12 |
12 |
12 |
|
インドネシア |
60 |
45 |
30 |
10 |
4 |
2 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
3 |
5 |
|
台湾 |
125 |
115 |
100 |
60 |
30 |
5 |
0 |
0 |
0 |
0 |
0 |
0 |
0 |
10 |
25 |
75 |
|
合計 |
265 |
269 |
267 |
198 |
372 |
425 |
425 |
510 |
510 |
502 |
483 |
417 |
392 |
392 |
385 |
362 |
ログインしているユーザーの数に基づいて負荷ピークを見積る場合は、次のことを前提とすることをお薦めします。
ピーク時にはすべてのログイン済ユーザーがアクティブである。
それぞれのアクティブなユーザーが1分間に平均4つのリクエストを行う。
アクティブなユーザーの最大数（表2-1では510）に基づいて、1秒当たりの最大リクエスト数を次のように見積ります。
次に例を示します。
負荷のガウス分布（釣鐘曲線）として、平均的な高負荷の値よりも高い標準偏差を考慮に入れるには、1秒当たりの予想リクエスト数に2や3などの小さな整数をかけます。この場合、予想最大使用量の値は次のようになります。
1秒当たりのリクエスト数*標準偏差= 1秒当たりの予想最大リクエスト数
次に例を示します。
34（1秒当たりのリクエスト数）* 2（標準偏差）= 68（1秒当たりのリクエスト数）
34（1秒当たりのリクエスト数）*3（標準偏差）= 102（1秒当たりのリクエスト数）
表2-1を参考にして、独自のデプロイメントのすべてのサイトを含む表を作成します。
各サイトを監視するか履歴データに基づいて、その日の1時間ごとのログイン済ユーザー数を調べます。
最大ユーザー数に1分当たりの予想リクエスト数（たとえば4。より正確なデータがある場合はその数値を使用）をかけて、1分当たりの合計リクエスト数を割り出します。
1分当たりの合計リクエスト数を60で割り、1秒当たりのリクエスト数を算出します。
1秒当たりのリクエスト数に小さな整数（2または3）をかけて、平均より高い負荷を考慮した最終的な見積りを出します。
使用量を単純に測定できない場合や履歴データが使用できない場合は、ここで説明する方法を使用してOracle Access Managerデプロイメントでのシステム使用量を見積ることができます。
ユーザー数の見積り: 社内の人事管理部門または別の信頼できる情報源から各オフィスのユーザー数のデータを入手します。このデータを基に、負荷ピーク時にリソースにアクセスするユーザーの合計数を見積ることができます。見積りには、正社員、パート従業員および契約社員を必ず含めてください。
地理的に分散されたデプロイメントでの時間間隔の見積り: 地理的に分散されたデプロイメントの場合、サイトごとにログインしているユーザーの統計を集めるよりも、使用量が最大になる時間間隔を突き止め、その時間間隔にアクティブなユーザーの数を見積るほうが効果的です。
たとえば、ある企業のオフィスが世界の数か国にあるとします。この場合、グリニッジ標準時（GMT）に対する各オフィスの勤務時間の表を作成します。表2-2のような表を作成することで、多数のオフィスが最も忙しい時間帯（影付き部分）を見積ることができます。これは、負荷ピーク時の有効な目安になります。表2-2の各行に含まれる数字の1は、ローカル時刻の12:00 00AMを示すと同時に、グリニッジ標準時との関係も示しています。たとえば、メキシコ・シティーの夏時間の12:00AMは、グリニッジ標準時の07:00AMです。
表2-2 グリニッジ標準時に対する勤務時間の表（夏時間）
| グリニッジ標準時 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
|
|
メキシコ |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
|
スペイン |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
|
エジプト |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
|
アメリカ |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
|
コロンビア |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
|
コスタリカ |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
|
インドネシア |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
台湾 |
9 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
表2-3のような表を作成すると、各オフィスのユーザー・コミュニティ統計が得られます。これを基に、ピーク時にOracle Access Managerによって保護されているリソースにアクセスしているユーザーの合計数を見積ることができます。
表2-3 社内の信頼できる情報源から入手した従業員および契約社員のデータ
| 国 | 正社員 | パート従業員 | 契約社員 | 合計 |
|---|---|---|---|---|
|
メキシコ |
3021 |
496 |
35 |
3552 |
|
スペイン |
755 |
356 |
5 |
1116 |
|
エジプト |
329 |
275 |
0 |
604 |
|
アメリカ |
134 |
25 |
55 |
214 |
|
コロンビア |
1290 |
245 |
11 |
1546 |
|
コスタリカ |
175 |
130 |
0 |
305 |
|
インドネシア |
250 |
97 |
18 |
365 |
|
台湾 |
286 |
88 |
44 |
418 |
次の要素に基づいて単純なスループットの見積りを作成できます。
同時にログインすると考えられるユーザーの最大合計数の見積り
特定の時間内における1ユーザー当たりのトランザクション数の見積り
処理が必要な1秒当たりのトランザクション数の見積り
1秒当たりのトランザクション数の見積りは、ハードウェアの製造元が作成した数値と比較できます。
たとえば、表2-2および表2-3の情報をサンプルとして使用した場合、合計ユーザー数および負荷ピークを次のように見積ることができます。
最大ユーザー合計数: 各サイトの合計ユーザー数をすべて足します。サンプルとして表2-3のデータを使用した場合: 3552+1116+604+214+1546+305+365+418=8120（合計ユーザー数）
負荷ピーク: この計算は、「複数サイトのデプロイメントのアクティブなユーザー・セッションの測定」で説明した計算と似ています。合計ユーザー数に1分当たりの予想リクエスト数（たとえば4。より正確なデータがある場合はその数値を使用）をかけて、1分当たりのリクエスト数を60秒で割り、1秒当たりのリクエスト数を割り出します。
サンプルとして表2-3のデータを使用した場合の見積り:
これが、人事管理データに基づいた、発生し得る最大負荷です。そのため、負荷のガウス分布を考慮するために負荷ピークを乗算する必要はありません。ただし、システム使用量の将来の増加を見積る安全係数を考慮する必要があります。
システム使用量の見積りの手順
サンプルの表2-2を参考にして、独自のデプロイメントのグリニッジ標準時に対する時間表を作成します。
表の最上部には、グリニッジ標準時の時間を1列に1時間ずつ入力します。
デプロイメントに含まれるオフィスのサイトの数だけ行を作成し、各サイトを表の左側の列に入力します。
表2-2を参考に、ローカル時間を示す1～24の数字を入力します。これらの数字は各サイトとグリニッジ標準時との差に対応します。
各サイトの使用量のピーク時を表で調べ、これらの時間帯に色付けします。
サンプルの表2-3を参考にして、各サイトの従業員および契約社員のデータの表のテンプレートを作成します。
社内の人事管理部門または別の信頼できる情報源から各サイトのユーザー数を入手します。
表のサイトごとに次の人数を入力します。
各サイトの合計ユーザー数を計算して入力します。
各サイトの合計を足して、同時にログインしていた可能性があるユーザーの最大数を見積ります。
次の計算式を使用して最大負荷を見積ります。
将来のシステム使用量の増加を見積るために、安全係数の追加を検討してください。
第1章の「Oracle Access Managerデプロイメントの概要」では、Oracle Access Managerのインストールに関する一般的な推奨事項を説明しました。これに加えて、次に示すコンポーネント固有の項目を考慮する必要があります。
パフォーマンス・チューニングのガイドラインは、第3章を参照してください。
第1章で説明したように、1つのアイデンティティ・サーバーまたはアクセス・サーバーのみを専用のコンピュータにインストールすることをお薦めします。これは、85%の使用率がごく標準的な負荷とみなされるためです。プライマリ・アイデンティティ・サーバーとアクセス・サーバーのペアの合計使用率が85%未満になると見込まれる場合は、次のオプションを検討して必要なハードウェアの予想値を下げることができます。
プライマリ・サーバーは、フェイルオーバーの発生時以外に負荷を処理します。フェイルオーバー時には、セカンダリ・サーバーが負荷を処理します。セカンダリ・サーバーがアクティブになったときに、両サーバーの使用率の合計は85%以内に収まる必要があります。負荷の合計が85%をはるかに超えると予想される場合は、セカンダリ・アイデンティティ・サーバーまたはアクセス・サーバーを別のコンピュータにインストールすることをお薦めします。
第1章の 「Webサーバーの推奨事項」を参照してください。
第1章で説明した一般的なアクセス・システムの推奨事項に加えて、次の内容を考慮してアクセス・システムのキャパシティ・プランニングを行うことをお薦めします。
負荷によっては、アクセス・サーバーの使用率は、CPUおよびメモリーともに非常に高くなる可能性があります。デプロイメント内のアクセス・サーバーの数を計画する際には、これを考慮することが重要です。
システム構成およびデプロイメント・シナリオも、パフォーマンスに重大な影響を与えるキャパシティ・プランニングの重要な要素です。たとえば、次の項目は、キャパシティ・プランニング、サイズ計算およびパフォーマンス・チューニングの判断に影響します。これらの機能を構成してオンにするかオフにするかは、各企業の要件によって異なります。
層と層の間のトランスポート・セキュリティ・モード（オープンまたはSSL有効）
監査対象
パスワード・ポリシー
『Oracle Access Managerインストレーション・ガイド』には、トランスポート・セキュリティ・モードの説明が記載されています。パフォーマンス・チューニングの推奨事項は、第3章を参照してください。これらの機能の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』および『Oracle Access Managerアクセス管理ガイド』を参照してください。
一般的に使用されるWebGateとアクセス・サーバーの比率は10:1です。本番デプロイメントでは、開発デプロイメントやステージング・デプロイメントよりも比率が高くなる場合があります。デプロイメントごとの実際の比率は、実際の負荷ピークによって異なります。状況を入念に監視しながら、より高い比率に増やすことができます。
WebGateは、既存のWebサーバー・インスタンスまたは新しいWebサーバー・インスタンスに対してインストールできます。
WebサーバーとWebGateのペアの数は、デプロイメント内での使用量のパターンによって異なります。WebGateをホストする際には、Webサーバーのベースライン・パフォーマンスが多少（約10～20%）低下します。この見積りに基づき、デプロイメント内の5組のWebサーバーとWebGateのペアに対して、WebサーバーとWebGateのペアを1組追加することをお薦めします。言い換えると、Webサーバーのパフォーマンスを保つためには、5組のWebサーバーとWebGateのペアごとに、6組目のWebサーバーとWebGateのペアを追加する必要があります。
Webサーバーの要件の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
次の各項目では、オラクル社によるテストに基づくOracle Access Managerのパフォーマンスおよびスケーラビリティの特徴の概要を説明します。
スケールアップとは、容量を増やすためにデプロイメントにプロセッサを追加することです。このテストの結果では、プロセッサの数に対してスループットがほぼ一定の割合で増加しています。
図2-1は、4つのCPUを搭載したWintel脚注1システムでのOracle Access Managerのスケールアップの特徴を示しています。ハイパースレッディング（Pentium 4マイクロアーキテクチャでの同時マルチスレッド）は、Oracle Access Managerに有益です。オペレーティング・システムは、ハイパースレッディングが有効なPentium 4プロセッサを1台ではなく2台のプロセッサとして扱います。脚注2 図2-1では、4つのCPUを搭載したシステムでのスケールアップ・テストのスループットの比率を計算できます。
図2-1 Oracle Access Managerのスケールアップ（4 x 2.2Ghz CPU）
図2-1の棒グラフでは、縦のy軸はスループット比率のデータ値を示しています。横のx軸は次のカテゴリ・データを示しています。
P: プロセッサの数を表します。
L: ハイパースレッディング対応プロセッサの論理プロセッサ数を表します。
同じハイパースレッディング対応プロセッサでも、システムでハイパースレッディングがオンの場合は2台の論理プロセッサ、オフの場合は1台の論理プロセッサがシステムによって表示されます。
1P+1Lおよび2P+2Lのデータは、ハイパースレッディングがオフの場合のパフォーマンスを示しています。
1P+2L、2P+4L、3P+6Lおよび4P+8Lのデータは、ハイパースレッディングがオンの場合のパフォーマンスを示しています。
1～3.4のスループット比率は、各テストのスループットを1P+1Lのスループットの結果で割って算出されています。そのため、1P+1Lのデータは1になります。
スケールアウトは水平スケールとも呼ばれ、物理サーバーを追加してデプロイメントの容量を増やすことを意味します。
図2-2は、同等のWintelサーバーを1～4台使用して実行した一連のテストに基づく、Oracle Access Managerのスケールアウトの特徴を示しています。この一連のテストでは、各Oracle Access ManagerサーバーのCPU使用率が100%に達してからスループットが測定されています。サーバー数の増加とともに、スループットがほぼ一定の割合で増加していることがわかります。
図2-2の棒グラフでは、縦のy軸はスループット比率のデータ値を示しています。横のx軸は、Oracle Access Managerをホストする同等のWintelサーバーを1、2、3または4台含めた個々の構成のカテゴリ・データを示しています。単一サーバーのデータは比較の基準として使用されるため、比率は1.0になります。
このテストの結果から、Oracle Access Managerの水平スケールの方法がわかります。
図2-3は、様々なデプロイメント構成によるOracle Access Managerのパフォーマンスへの影響を示しています。このテストでは、スループットの比率が構成1を基準に算出されています。理由は、構成1の負荷が最も重いオプションであること、および最も一般的なデプロイメントであることです。
図2-3の棒グラフでは、縦のy軸はスループット比率のデータ値を示しています。水平のx軸は、個々のデプロイメント構成のカテゴリ・データを示しています。
表2-4は、図2-3で表したスループット比率のテストで使用された4つのデプロイメント構成の詳細を示しています。
表2-4 パフォーマンス・テストの構成の設定
| 構成番号 | トランスポート・セキュリティ: Webコンポーネントからアイデンティティ・サーバーおよびアクセス・サーバー | アイデンティティ・サーバー: パスワード・ポリシーおよびロスト・パスワード・ポリシー | アイデンティティ・サーバーおよびアクセス・サーバーの監査 | ユーザー・ログイン | アクセス・サーバーでのユーザー資格証明のキャッシュ |
|---|---|---|---|---|---|
|
構成1 |
簡易またはサード・パーティの証明書 |
有効 |
オン |
フォーム・ベース |
オン |
|
構成2 |
簡易またはサード・パーティの証明書 |
有効 |
オフ |
Basic Over LDAP |
オン |
|
構成3 |
簡易またはサード・パーティの証明書 |
無効 |
オフ |
Basic Over LDAP |
オン |
|
構成4 |
オープン |
無効 |
オフ |
Basic Over LDAP |
オン |
ここでは、ベースライン・パフォーマンスのテスト結果について説明します。このベースライン比率と「スケールアップの特徴」および「スケールアウトの特徴」を併用して、サーバー（またはサーバー・クラスタ）のスループットと容量を見積ることができます。
このテストでは、Oracle Access Managerのアイデンティティ・サーバーとアクセス・システムが結合されたデプロイメントを使用し、Sun Java System Directory Server 5.2に100万のユーザーをロードしています。このテスト中にアイデンティティ・サーバーとアクセス・サーバーでアクティブだったユーザー・セッションの数は、10万です。このデプロイメントの構成に含まれる設定は、次のとおりです。
Webサーバー・コンポーネントとアイデンティティ・サーバーおよびアクセス・サーバーの間の通信を保護する、簡易またはサード・パーティの証明書。
アイデンティティ・サーバーでは、パスワード・ポリシーおよびロスト・パスワード・ポリシーが次のように構成および有効化されています。
パスワード・ポリシーでは大文字、数字および小文字が要求され、3回間違えるとアカウントがロックされます。
ロスト・パスワード・チャレンジが設定されており、3回の試行のパスワード履歴が保存されます。
アイデンティティ・サーバーおよびアクセス・サーバーに対してファイルの監査がオンになっています。
フォーム・ベースのログインが構成されています。必要な資格証明はユーザー名とパスワードです。
アクセス・サーバーでユーザー資格証明のキャッシュがオンになっています。
ベースライン・スループット数は、前述のテストの設定から取得されています。このテストの結果を表2-5に示します。これらの数値は正規化されており、図2-1に示されている1P+2Lサーバーのデータと同じです。
表2-5 構成1のサンプル・スループット
| 操作 | スループット（CPUごとの1秒当たりのリクエスト数） | コメント |
|---|---|---|
|
自己登録 |
32 |
ユーザーが自己登録のみを実行する |
|
パスワード変更 |
86 |
ユーザーがパスワード変更のみを実行する |
|
ロスト・パスワード |
69 |
ユーザーがロスト・パスワードのリカバリのみを実行する |
|
ログイン |
116 |
ユーザーがログインのみを実行する |
|
LoginNavi |
366 |
ユーザーがログインおよびページのナビゲーションを実行する |
|
AllMix |
341 |
ユーザーがこれらの全アクションを次のような割合で実行する
|
表2-5に示すように、LoginNavi操作ではCPUごとの1秒当たりのリクエスト数のスループット値が最も高く、AllMix操作では、スループット値が2番目に高くなっています。表2-5のテスト結果の元となった、アイデンティティ・システムとアクセス・システムが結合されたデプロイメントには、アイデンティティ・サーバーおよびアクセス・サーバーが含まれており、それぞれが単一の専用コンピュータにインストールされています。ベースライン・デプロイメントおよびテスト・ケースの詳細は、「中規模から大規模のサンプル・デプロイメント」および「ベースライン・パフォーマンス・データのテスト・ケース」を参照してください。
表2-5のサンプル情報およびこの章に含まれる情報を使用して、アクセス・サーバーの負荷およびサイズ設定を判断し、その後、アイデンティティ・サーバーの負荷とサイズ設定の詳細を推定します。
ここで使用するサンプル計算は、表2-5のAllMixのスループット・データに基づきます。アイデンティティ・システムおよびアクセス・システムの結合をデプロイした場合、AllMix操作を使用して計算するとほぼ現実的です。LoginNaviのスループットも計算に使用できます。たとえば、AllMix 1P+2Lのベースライン341、図2-1に示されている1P+2Lのスケールアップ比率= 1.3および2P+4Lのスケールアップ比率= 2.3を基にすると、次のことがわかります。
CPUを2つ搭載したサーバーでは、1秒当たり603のリクエストが処理されます。
341:1.3 =スループット:2.3、スループット= 341*2.3/1.3 = 603
CPUを4つ搭載したサーバーでは、1秒当たり892のリクエストが処理されると考えられます（341*3.4/1.3）。
各ボックスに2つのCPUを搭載した2台のサーバーのクラスタでは、1秒当たり1146のリクエストが処理されると考えられます（603*1.9）。
1秒当たり800のリクエストの負荷が予想される場合、アクセス・システム・デプロイメントのハードウェア構成として、次のいずれかを選択できます。
4つのCPUを搭載したサーバー
各サーバーに2つのCPUを搭載したサーバー2台のクラスタ
アクセス・サーバーのサイズを設定したら、アイデンティティ・サーバーの準備段階のサイズ設定を割り出せます。アイデンティティ・サーバーのサイズ設定には、アクセス・サーバーの性能の半分を表す数値を開始点として使用します。その後、表2-5に示されている予想トランザクション・スループット・データを使用して、次の項目を詳細に調整できます。
自己登録
パスワード変更
ロスト・パスワード
アクセス・サーバーについて1秒当たり800のリクエストの例を基準にした場合（このアクセス・サーバーではサーバー2台のクラスタのデプロイメントを使用）、アイデンティティ・サーバーの容量がこの半分ということは、2つのCPUを搭載した1台のサーバーになります。ただし、表2-5の自己登録、パスワード変更およびロスト・パスワードの詳細をもう一度使用して、2つのCPUを搭載する1台のアイデンティティ・サーバーで十分かどうかを判断する必要があります。
次に示す手順は、表2-5の情報およびこの章で後述する内容を使用してアクセス・サーバーおよびアイデンティティ・サーバーの負荷とサイズ設定を判断する方法の一例です。
ここでは、様々なサイズの実行中のデプロイメントにおける、Oracle Access Managerコンポーネントの基準を設定するためにオラクル社が作成したユースケースに基づいて、詳細を説明します。
小規模デプロイメントはユーザー数2万以下と推定されます。小規模から中規模のデプロイメントには、一般的に10万以下のユーザーが含まれます。大規模デプロイメントには、10万～200万のユーザーが含まれます。
Oracle Access Managerのコンポーネントは、標準的なハードウェアで良好に機能します。様々な構成（構成4ではメモリー使用量が最高）でのテストから、次のことがわかります。
10万のアクティブなユーザー・セッションでは、アクセス・サーバーのメモリーが600MB～1GB消費されます。
32ビットのシステムを使用する場合、通常オペレーティング・システムで対応できるのは、プロセス当たり2GB以下のメモリーです。
次の項目では、Oracle Access Managerデプロイメントのサイズに対するハードウェアの詳細を説明します。
ユーザー数が2万～10万の小規模から中規模のデプロイメントの場合、アイデンティティ・サーバーおよびアクセス・サーバーに、サポートされているサーバー・クラスのコンピュータおよびオペレーティング・システムのいずれを使用しても十分対応できます。考慮する必要がある項目は次のとおりです。
フェイルオーバー要件により、必要なコンピュータ数は2倍になります。たとえば、冗長性のためには、最低2台のアイデンティティ・サーバーと2台のアクセス・サーバーを使用します。負荷が軽い場合は、これらのサーバーをクロスオーバー構成にデプロイして、ハードウェアの使用量を最適化できます。詳細は、「アイデンティティ・サーバーおよびアクセス・サーバーの推奨事項」を参照してください。
アイデンティティ・システムおよびアクセス・システムの各プロセスに対して最低2GBのメモリー
最低2 x 2GHzのCPUおよびサーバーごとに4～6GBのメモリーを搭載するシステム
システム・コンソールには専用のWebサーバーが1台必要です。このサーバーは、追加のハードウェア要件を排除するために、2つの主要なアクセス・サーバーとアイデンティティ・サーバーのいずれかにデプロイできます。
Oracle Access Managerの要件、Webサーバーの要件、およびコンポーネントに関する準備とインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
ユーザー数が10万～200万のデプロイメントでは、アイデンティティ・サーバーおよびアクセス・サーバー用に、次のようなハードウェアをお薦めします。
各サーバーには、4 x 2GHzまたは2 x 2GHzのCPUを搭載したシステムおよび6～8GBのメモリーおよび2 x 17GBのミラー化された記憶域が必要です。クラスタ設定が推奨されます。
『Oracle Access Manager IDおよび共通管理ガイド』の説明に従って、委任管理モデルにアイデンティティ・サーバーをデプロイする必要があります。
100万単位のユーザーのデプロイメントの場合は、「スケールアウトの特徴」で説明した複数のサーバーを使用するスケールアウトを推奨します。「アイデンティティ・サーバーおよびアクセス・サーバーのベースライン・パフォーマンス」を参照してサイズ設定の要件を割り出します。
Oracle Access Managerの要件、Webサーバーの要件、およびコンポーネントに関する準備とインストールの詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アイデンティティ・サーバー（または結合デプロイメントのアイデンティティ・サーバーとアクセス・サーバー）が関与する大量の更新操作が発生する場合は、第1章で説明したLightweight Directory Access Protocol（LDAP）ディレクトリ・サーバーの考慮事項に加えて、複数のLDAPディレクトリ・サーバーを使用して負荷を分散させることを推奨します。これは、特にパスワード・ポリシー関連の操作に当てはまります。このような場合は、LDAPサーバーのマルチマスターおよびレプリカを使用すると、アイデンティティ・サーバーとLDAPレプリカ（およびアイデンティティ・システムとアクセス・システムの結合デプロイメントの、アクセス・サーバーとLDAPレプリカ）の間のロード・バランシングを構成できます。
LDAPディレクトリに対して認証を行う場合は、アクセス・サーバーのユーザー資格証明キャッシュを有効にすることを検討してください。これにより、認証時のLDAPディレクトリ・サーバーの負荷が大幅に軽減され、スループットが向上します。詳細は、「アクセス・サーバーによるパスワード検証の構成」を参照してください。
ディスク領域のサイズ設定: 一般的な目安として、LDIFファイルのサイズに5をかけて、エントリおよび索引に必要な実際のLDAPディスク領域を割り出します。LDAPの初期化中、ホスト・コンピュータは少なくともLDIFファイル・サイズの5倍の量の一時ディスク領域を必要とします。LDAPコンテンツの各バックアップ・コピーは、実行中のLDAPサーバーと同じ量のディスク領域を必要とします。たとえば、100万のユーザーのLDIFファイルのサイズは、およそ2GBです。2GBのLDIFファイルは、ロードされるとサイズが約10GBに増加します。初期化時の一時領域および3つの完全なバックアップ・コピーに必要な領域を考慮すると、少なくとも2 x 5 x 5 = 50GBのディスク領域が必要になります。詳細は次のとおりです。
メモリーのサイズ設定: これは、選択したLDAPサーバーおよびデプロイメントの構成によって異なります。LDAPのドキュメントで、使用する特定のディレクトリ・サーバーおよびオペレーティング・システムについて確認することをお薦めします。
32ビットのシステムでは、オペレーティング・システムによってプロセスごとに2GBに制限されます。大規模デプロイメントでは、64ビットのシステムおよびオペレーティング・システムが推奨されます。詳細は、次を参照してください。
パフォーマンス・チューニングの推奨事項は、第3章を参照してください。
入手可能な最新の、2GBのメモリーが搭載されたディレクトリ・サーバーは、ユーザー数10万以下の小規模から中規模のデプロイメントに十分対応できます。その他の推奨事項は次のとおりです。
ユーザー数が10万以上のデプロイメントに関する推奨事項は次のとおりです。
200万のユーザーに対して100GBのディスク領域を使用可能にする。
ディレクトリ・サーバーのアクセスおよびエラー・ログの物理ドライブを（索引付けされているまたはされていない）属性データのボリューム・ドライブから分離する。
たとえば、Oracle Internet DirectoryのI/Oサブシステムの要件には、ディスク・コントローラで制御されるディスク・ドライブの配列が含まれます。I/Oサブシステムのサイズ設定時には、記憶域要件のみに基づくサイズ予測を使用するよりも、パフォーマンス要件を考慮することが重要です。詳細は、『Oracle Application Serverベスト・プラクティス・ガイド』を参照してください。
2または4 x 2GHzのCPUを考慮する。アクセス・サーバーのユーザー資格証明キャッシュを構成してオンにすると、LDAPサーバーの負荷が激減してパフォーマンスが向上します。
ユーザー数10万のディレクトリには最低2GBのRAM、大規模なディレクトリには最低4GBRAMを割り当てる。
図2-4は、LDAPディレクトリに100万のユーザーが含まれ、アクセス・サーバーに10万アクティブ・ユーザー・セッションがある、中規模から大規模のデプロイメントのラボ・テスト環境におけるハードウェアおよびソフトウェアの選択肢を示しています。このデプロイメントから取得されたベースライン・スループット数は、「アイデンティティ・サーバーおよびアクセス・サーバーのベースライン・パフォーマンス」で使用されたものです。
このデプロイメントは図2-4で使用されたもので、表2-6に従ってインストールされています。
表2-6に示すように、このデプロイメントには、それぞれが2.8GHzおよび28 SPECInt_rate2000の2つのCPUを搭載したIntel Xenonのサーバー・クラス・コンピュータが含まれます。
表2-6 サーバー・インストールの詳細
| サーバー数 | インストール対象 |
|---|---|
|
5 |
Oracle HTTP Server/WebPass/WebGate |
|
2 |
アクセス・サーバーおよびアイデンティティ・サーバー |
|
2 |
LDAPサーバー |
|
2 |
LRテスト負荷ドライバ |
この章で引用したベースライン・テスト・デプロイメントの詳細は次のとおりです。
サーバー（Sun Java System Directory Server、Oracle HTTP ServerおよびOracle Access Manager）は、Windows 2003 Server（SP1）で稼働しています。
各サーバーには2 x 2.8GHzのCPU、6GBのRAM、140GBのディスク領域があります。
アクセス・サーバーおよびアイデンティティ・サーバーは同じ場所に配置され、プライマリ-セカンダリ設定として構成されています。
1台のLDAPディレクトリ・サーバーが使用されています。
5台のOracle HTTP Serverには、それぞれWebPassおよびWebGateがインストールされています。
Oracle HTTP Serverシステムの1つに、ポリシー・マネージャがインストールされています。
このデプロイメントを次のようにスケール変更できます。
Oracle Access Managerサーバーのホスト数を増やし、負荷を分散して冗長性を高める。
CPUの量、メモリーおよびディスク領域を増やして容量を増やし、サーバーのパフォーマンスを向上させる。
必要に応じてLDAPディレクトリ・サーバーに新しいサーバーを追加し、パフォーマンスと信頼性を向上させる。
デプロイメントのスケール変更の詳細は、「スケールアップの特徴」および「スケールアウトの特徴」を参照してください。
この章で使用しているベースライン・パフォーマンス・データは、Oracle Access Manager Benchmark Suiteテスト・アプリケーションで実行したテストにより取得されたものです。このアプリケーションには100の静的HTMLページが含まれており、各ページのサイズは14kです。このデプロイメントのLDAPディレクトリ・サーバーには、100万のユーザーのデータがあります。
次の項では、アクセス・サーバー、アイデンティティ・サーバーおよび両方のサーバーの統合済テスト・ケースに対するOracle Access Manager Benchmark Suiteのシナリオについて説明します。
Oracle Access Managerアイデンティティ・サーバーのベースライン・パフォーマンスのテスト・ケースについて、次の内容を説明します。
約5%のユーザーが自己登録を実行します。オラクル社は、一連のユーザー属性を使用してユーザーをただちに有効にする、自己登録ワークフローを作成しました。これは、自己登録とパスワード・ポリシーの有効化の両方を含む2ステップのワークフローです。
このテスト・ケース用に、オラクル社は、構文を説明するパスワード・ポリシーおよびパスワードの履歴を構成しました。ログイン済ユーザーの15%がパスワードの変更を試みます。パスワードの変更は、常に約80%の確率で成功します。残りの20%のケースでは、パスワードが短すぎる、弱い、または繰り返されているのいずれかです。
たとえば、パスワードを求められたときに不正なパスワードを入力すると、パスワード変更画面が表示されます。ロスト・パスワードの画面では、不正なユーザーIDの入力によるエラーが10%、不正なチャレンジ/レスポンスが10%、および次の画面（パスワード変更）に進めるのが80%です。
ログイン済ユーザーの15%がパスワードの変更を試みます。このテスト・ケース用に、オラクル社は、構文を説明するパスワード・ポリシーおよびパスワードの履歴を構成しました。ログイン済ユーザーの15%がパスワードの変更を試みます。パスワードの変更は、常に約80%の確率で成功します。残りの20%のケースでは、パスワードが短すぎる、弱い、または繰り返されているのいずれかです。
Oracle Access Managerアクセス・サーバーのベースライン・パフォーマンスのテスト・ケースについて、次の内容を説明します。
ログイン操作は、1つの認証操作と1つの認可操作で構成されます。テスト・デプロイメントでは、テスト中に10万のユーザー・セッションがアクティブになっています。一度作成されたセッションはログアウトされません。かわりに、それぞれのセッションはログイン後に休止状態を保ちます。
このテストは、約85%の認証成功および15%の認証失敗が発生するように設計されています。
脚注
脚注1: Wintelは、いずれかのMicrosoft Windowsオペレーティング・システムを装備したIntelのマイクロプロセッサに基づくパーソナル・コンピュータを指す業界用語です。
