検索環境のパフォーマンスと容量の要件を予測する

この記事の内容 :

• 主要特性

• テスト環境

• 推奨事項

このパフォーマンスおよび容量の計画シナリオには、企業環境の Office SharePoint Server コンテンツの検索およびインデックス作成に使用する単一の Microsoft Office SharePoint Server 2007 ファームが組み込まれています。

主要特性

主要特性では、環境の要因、 使用法の特性、および、このシナリオに基づいた展開におけるその他の考慮事項について説明します。

このシナリオの主要特性は次のとおりです。

• ユーザー応答時間   一般的な処理、一般的でない処理、長時間実行処理、まれに発生する処理のユーザー応答時間は、「ソフトウェア境界を計画する (Office SharePoint Server)」の「ユーザー応答時間」の表に記載されています。組織によっては、ユーザー応答時間がこれより遅くなることが許容される場合も、より速いユーザー応答時間が要求される場合もあります。予想されるユーザー応答時間は、全体のスループット目標を決定する重要な要素です。スループットとは、1 秒間にサーバー ファームが処理できる要求数です。ユーザー数が増えた場合に同じユーザー応答時間を実現するには、スループット目標を高くする必要があります。

• ユーザーの同時実行   同時実行率は 10 パーセントで、特定のタイミングで要求を行う同時実行ユーザーは 1 パーセントであると想定されています。たとえば、ユーザー数が 10,000 の場合、ソリューションを同時に使用する実際のユーザー数は 1,000、アクティブに要求を行うユーザー数は 100 になります。

• 長時間実行の非同期タスク   コンテンツのクロール、データベースのバックアップなどのタスクによって、サーバー ファームのパフォーマンス負荷が増大します。トポロジの例の一般的なパフォーマンス特性では、これらのタスクを夜間などのオフピーク時に実行することが想定されています。このため、業務時間中のユーザー応答速度は影響を受けません。

テスト環境

このシナリオのテストは、次のさまざまな要因の変更に対応するファーム構成の変化を予測して、開発に役立つように設計されました。

• システムを同時に使用するユーザー数。

• 実行されるユーザー操作の種類。

• クエリが実行されるインデックス内のドキュメント数。

このテスト結果から何らかの結論を得ることができますが、このセクションの特定の容量およびパフォーマンス値が現実の環境の数値とは異なることに注意する必要があります。この記事の数値は、適切に拡張された環境を設計するための出発点を提供することを目的としています。初期システム設計の計算の終了後に構成をテストして、環境に内在する要因をシステムがサポートできるかどうかを判断します。

展開のテストの詳細については、「パフォーマンスと容量を計画するためのツール (Office SharePoint Server)」を参照してください。

前提

• 64 ビット アーキテクチャ   テスト環境では 64 ビット サーバーのみが使用されました。Office SharePoint Server 2007 を 32 ビット サーバーに展開することもできますが、Office SharePoint Server 2007 ファームの展開には 64 ビット サーバーを使用することを推奨します。詳細については、「パフォーマンスと容量の計画について (Office SharePoint Server)」の「64 ビット版と 32 ビット版」を参照してください。

• ディスクベースのキャッシュの有効化   ディスクベースのキャッシュにより、コード フラグメントや、イメージ、サウンド、ビデオなどのサイズの大きなバイナリ ファイルを取得するためにデータベースに何度もアクセスする必要がなくなります。ディスクベースのキャッシュを有効にすることで、展開全体のパフォーマンスが向上します。ディスクベースのキャッシュは既定では有効になっていません。ディスクベースのキャッシュを有効にする方法の詳細については、「バイナリ ラージ オブジェクトのディスクベースのキャッシュ」(https://msdn.microsoft.com/ja-jp/library/aa604896.aspx?amp;clcid=0x411) を参照してください。

ラボのトポロジ

テストには、1 つから 8 つまでのクエリ サーバー、1 つのインデックス サーバー、1 つの SSP、Microsoft SQL Server 2005 データベース ソフトウェアが実行されている 1 つのデータベース サーバー コンピュータをはじめとして、複数のファーム構成が使用されました。また、すべてのサーバー コンピュータでは、Microsoft Windows Server 2003 Service Pack 1 (SP1), Enterprise x64 Edition オペレーティング システム上で Office SharePoint Server 2007 Enterprise Edition の既定の構成が実行されていました。

テストに使用したハードウェアを次の表に示します。

コンピュータの役割	ハードウェア	ハード ディスク容量
クエリ サーバー	デュアルコア Intel Xeon 2.66 ギガヘルツ (GHz) プロセッサ × 4 32 ギガバイト (GB) RAM	オペレーティング システム用に 40 GB (RAID (Redundant Array of Independent Disks) 5) コンテンツ インデックスおよびオペレーティング システム ページング ファイル用に 956 GB (RAID 10)
インデックス サーバー	デュアルコア Intel Xeon 2.66 GHz プロセッサ × 4 32 GB RAM	オペレーティング システム用に 40 GB (RAID 5) コンテンツ インデックスおよびオペレーティング システム ページング ファイル用に 956 GB (RAID 10)
データベース サーバー	デュアルコア Intel Xeon 2.66 GHz プロセッサ × 4 32 GB RAM	オペレーティング システム用に 40 GB (RAID 5) SharedServices_Search_DB データベース用に専用の SCSI (Small Computer System Interface) コントローラ付きの 956 GB (RAID 10) SCSI コントローラは以下のディスクで共有 SharedServices_DB データベース用に 273 GB (RAID 10) TempDB データベース用に 273 GB (RAID 10) ログ ファイル用に 273 GB (RAID 10) SharePoint_Config データベース用に 136 GB (RAID 10)

テスト環境では、ギガビット (10 億/秒) ネットワークが使用されました。適切なネットワーク帯域幅を確保するために、Office SharePoint Server ファーム内のサーバー間でギガビット ネットワークを使用することをお勧めします。

使用プロファイル

以下の表に、Office SharePoint Server 2007 検索のテスト環境で使用したプロファイルを示します。

テストでのクロール対象は約 5,000 万のアイテムでした。以下の表に、クロール対象アイテムの種類と数を示します。アイテムのサイズは 10 キロバイト (KB) から 100 KB で、リスト アイテム、Web ページなどさまざまな種類のドキュメントで構成されています。

アイテムの種類	アイテム数
SharePoint サイト上のコンテンツ	以下で構成される 1,000 万アイテム 420 のサイト コレクション 4,000 のサイト 24,200 のリスト 47,780 のドキュメント ライブラリ
ファイル共有のコンテンツ	1,500 万アイテム
HTTP コンテンツ	1,500 万アイテム
ユーザーのプロファイル	250 万
stitch (メモり内にドキュメントを生成するメモリ内テスト ツール)	750 万
プロパティ (メタデータ)	100 万

次の表に、ディスク領域の使用状況を示します。

使用した種類	容量
クエリ サーバーのインデックス サイズ	100 GB*
インデックス サーバーのインデックス サイズ	100 GB*
検索データベースのサイズ	600 GB

テストにおいて、フル クロールの実行にかかった期間は 35 日でした (1 秒あたり約 15 ドキュメント)。これらのテスト結果は、ネットワーク遅延とクロール対象のリポジトリがクロール速度に影響を及ぼす運用環境で得られたものであることに注意してください。純粋なテスト環境や、帯域幅がより大きくクロール対象リポジトリの応答がより速い運用環境では、1 秒あたりのドキュメント数で測定されるクロール速度は大幅に速くなります。

テスト環境で使用されるコーパスのサイズの 2 パーセントが変化すると、この変更に対応するための増分クロールは、クロール対象サイトの遅延と応答速度に応じて約 8 ～ 12 時間かかります。メタデータや外部へのリンクが変更された場合の処理は、ドキュメントの内容が変更された場合より時間がかかります。

推奨事項

ここでは、一般的なパフォーマンスの推奨事項および容量の推奨事項について説明します。これらの推奨事項を参考にして、「冗長性を計画する (Office SharePoint Server)」で作成した開始トポロジの容量特性およびパフォーマンス特性を決定し、開始トポロジのスケール アウトやスケール アップが必要かどうかを判断してください。

推奨ハードウェア

次の表に、Web サーバー、インデックス サーバー、およびデータベース サーバーの推奨ハードウェアの一覧を示します。

サーバーの役割	推奨ハードウェア
Web (クエリ) サーバー	2.5 GHz 以上のデュアル プロセッサ (3 GHz 以上を推奨) 2 GB 以上の RAM を推奨 3 GB の空き領域 DVD ドライブ、ローカルまたはネットワーク アクセス
インデックス サーバー	2.5 GHz 以上のデュアル プロセッサ (3 GHz 以上を推奨) 4 GB 以上の RAM を推奨 3 GB の空き領域 DVD ドライブ、ローカルまたはネットワーク アクセス
データベース サーバー	2.5 GHz 以上のデュアル プロセッサ (3 GHz 以上を推奨) 4 GB 以上の RAM を推奨 コンテンツ データベースのハード ディスク領域は、コンテンツ サイズとデータベース容量の比率 1:1.2 に基づいています。たとえば、100 GB のコンテンツを計画している場合は、コンテンツ データベース用として少なくとも 120 GB の空きディスク領域と、トランザクション ログ用の空き領域が必要です。 検索データベースのハード ディスク領域は、インデックス サイズとデータベース容量の比率 1:4 に基づいています。たとえば、100 GB のインデックス サイズを想定している場合は、検索データベース用として少なくとも 400 GB の空きディスク領域と、トランザクション ログ用の空き領域が必要です。 DVD ドライブ、ローカルまたはネットワーク アクセス

システムの最小要件および推奨要件の詳細については、「Determine hardware and software requirements (Search Server 2008)」を参照してください。

開始点トポロジ

開始点トポロジのパフォーマンスは、使用するトポロジと「冗長性を計画する (Office SharePoint Server)」に示されている開始点トポロジを比較することで予測できます。これにより、目標とするパフォーマンスと容量の条件を満たすために、使用する開始点トポロジをスケール アップまたはスケール アウトする必要があるかどうかを簡単に判断できます。

スケール アップおよびスケール アウトを実行したトポロジの容量とパフォーマンス

1 つの開始点トポロジの容量を増やし、パフォーマンスを向上させるには、サーバー コンピュータの容量を増やしてスケール アップする方法とトポロジにサーバーを追加してスケール アウトする方法があります。ここでは、トポロジに対してスケール アップまたはスケール アウトを実行した場合の一般的なパフォーマンス特性について説明します。トポロジの例では、検索環境のトポロジをスケール アップまたはスケール アウトする、次の一般的な方法を示します。

• ユーザー負荷が大きい場合の対応では、クエリ サーバー コンピュータを追加します。インデックス サーバーと専用のクエリ サーバーを追加して、Web サーバーの処理の負荷を一部軽減することもできます。

• データ負荷が大きい場合の対応では、1 つの (クラスタ化またはミラー) サーバーの容量を増やすか、64 ビット サーバーにアップグレードするか、クラスタ化サーバーまたはミラー サーバーを追加して、データベース サーバーの役割のサーバーの容量を増やします。

• 1 つの (クラスタ化またはミラー) データベース サーバー コンピュータに対するクエリ サーバー コンピュータの数を 8 以下に保ちます。ラボのテストでは、最適な比率が 7x1x1 (7 つのクエリ サーバー、1 つのインデックス サーバー、1 つのデータベース サーバー) であるという結果が得られました。

スループット目標の予測

ここでは、クエリ サーバー数を増やした場合とユーザー接続が増えた場合のファームのスループットを示すテスト データについて説明します。

Office SharePoint Server 2007 の展開および構成は多数の方法で行うことができるため、特定のサーバー数でサポート可能なユーザー数を予測する方法は 1 つではありません。したがって、運用環境に Office SharePoint Server 2007 を展開する前に、独自の環境でテストを実行することが重要です。

スループットに影響を及ぼす要素には、ユーザー数、ユーザー操作の複雑さと頻度、キャッシュ、ページおよび Web パーツのカスタマイズ状態などがあります。これらの各要素は、ファームのスループットに大きな影響を及ぼす可能性があります。このため、展開を計画する際には、これらの各要素を十分に検討する必要があります。

Office SharePoint Server 2007 のキャッシュについては、次のリソースを参照してください。

• カスタム キャッシュの概要 (https://msdn.microsoft.com/ja-jp/library/aa589700.aspx?amp;clcid=0x411)

• 「パフォーマンスと容量の計画に影響を与えるその他の要因 (Office SharePoint Server)」の「キャッシュ」

組織内で使用している既存の検索ソリューションがある場合、インターネット インフォメーション サービス (IIS) のログを参照して、現在の環境の使用パターンと動向を判断することができます。IIS ログの解析の詳細については、「Analyzing Log Files (IIS 6.0) (英語)」(https://go.microsoft.com/fwlink/?linkid=78825&clcid=0x411) を参照してください。

新しい検索ソリューションを展開する計画がある場合は、以下の情報を参考にして使用パターンを予測してください。

テスト結果 : 各ファーム構成のスループット

ここでは、この記事の「テスト環境」に示したハードウェアおよび使用プロファイルを使用して、さまざまなユーザー操作を実行した場合のテスト結果を表に示します。ファーム構成については、1 つのインデックス サーバーおよび 1 つのデータベース サーバーに対して 1 つから 8 つまでのクエリ サーバーを接続した場合をテストしました。3x1x1 というファーム構成は、3 つのクエリ サーバーに対して、1 つのインデックス サーバーと 1 つのデータベース サーバーを使用した場合を表します。インデックス サーバーまたはデータベース サーバーを複数使用するファーム構成については、テストを実行していません。

検索に関連するユーザー操作のテスト結果を次の表に示します。

ファーム サイズ	RPS	クエリ サーバーの CPU の使用率 (%)	インデックス サーバーの CPU の使用率 (%)	データベース サーバーの CPU の使用率 (%)	データベース サーバーのディスクへの 1 秒あたりの平均書き込み数
1x1x1	24.01	99.49	1.98	7.23	6.11
2x1x1	48.04	96.98	3.95	13.02	2.66
3x1x1	71.07	94.73	5.61	20.56	2.29
4x1x1	93.11	91.77	8.81	29.21	2.41
5x1x1	114.95	90.50	10.27	39.38	2.45
6x1x1	133.34	87.29	11.91	52.94	2.83
7x1x1	148.52	80.20	15.24	63.72	3.14
8x1x1	146.94	65.65	15.15	69.15	2.87

クエリ サーバーの数を変更した場合の検索操作のスループットの変化を、次のグラフに示します。

クロール ウィンドウを予測する

Office SharePoint Server 2007 の検索環境では、コンテンツのクロールは一般的に長時間実行する処理であり、ユーザーが開始するものではありません。独自の環境でテストを実行して、特定のコンテンツ ソースを使用した場合にコンテンツのクロールにかかる時間と、このコンテンツのクロールのスループットで目標とするユーザー応答時間を実現できるかどうかを判断する必要があります。一般的には、特定のコンテンツ ソースのクロールを夜間の 12 時間以内で実行できることを確認する必要があります。

ディスク空き領域要件を予測する

以下の情報を参考にして、使用環境で必要なインデックス サーバー、クエリ サーバー、およびデータベース サーバーのディスク空き領域を計画してください。

インデックス サーバーおよびクエリ サーバーのディスク空き領域要件

次の情報を使用して、サーバー ファーム内にあるインデックス サーバーとクエリ サーバーのディスク空き領域要件を計画してください。

コンテンツ インデックスを格納するハード ディスクのディスク空き領域要件を予測するには

1. クロールするコンテンツの量と、各ファイルの平均サイズを予測します。コーパス内のファイルの平均サイズがわからない場合は、1 ドキュメントあたり 10 KB と考えます。

   次の式を使用して、コンテンツ インデックスの格納に必要なディスク空き領域を計算します。

   必要なディスク空き領域 (GB) = Total_Corpus_Size (GB) x File_Size_Modifier x 2.85

   File_Size_Modifier は、コーパス内のファイルの平均サイズに基づいた、次のいずれかの数字です。

   • コーパスに含まれるファイルが非常に小さい場合は 1.0 (平均ファイル サイズ = 1 KB)。

   • コーパスに含まれるファイルが標準的な大きさの場合は 0.12 (平均ファイル サイズ = 10 KB)。

   • コーパスに含まれるファイルが大きい場合は 0.05 (平均ファイル サイズ = 100 KB 以上)。

この式では、Total_Corpus_Size (GB) と File_Size_Modifier を乗算して、インデックス ファイルのサイズを予測します。次に 2.85 を乗算して、クロールされたデータをインデックスと結合する際のマスタ結合の余地を確保します。最終結果が、ディスク空き領域要件の予測値です。

たとえば、1 GB のコーパスに平均サイズ 10 KB のファイルが主に含まれている場合、次の値を使用してインデックス ファイルの予測サイズを計算します。

1 GB x 0.12 = 0.12 GB

この計算によると、インデックス ファイルの予測サイズは 120 MB です。

次に、インデックス ファイルの予測サイズに 2.85 を乗算します。

120 MB x 2.85 = 342 MB

よって、インデックス作成処理を考慮したインデックス ファイルのディスク空き領域要件は 342 MB (0.342 GB) です。

1. 予測結果に基づき、インデックス サーバーとクエリ サーバーで使用可能なハード ディスク領域にコンテンツ インデックスが収まる場合は、手順 3. に進みます。それ以外の場合は、手順 3. に進む前に、ディスク空き領域を増やすか、手順 1. を再評価します。

2. コンテンツの一部をクロールします。

3. コンテンツ インデックスのサイズと、クロールされたファイル数を評価します。この情報を使用して、手順 1. で行った計算の精度を高めます。

4. ハード ディスク空き領域が十分に残っている場合は、コンテンツをさらにクロールします。それ以外の場合は、必要に応じてハード ディスク空き領域を増やすか、クロールするコンテンツの量を再評価します。

5. すべてのコンテンツがクロールされるまで、手順 3. ～ 5. を繰り返します。

   コーパス全体をクロールしたら、平均増大率を算出できるように、コンテンツ インデックスのサイズと検索データベースのサイズをクロールごとに記録しておくことをお勧めします。ファームに新しいコンテンツが追加されるとコーパスは増大する傾向があるので、使用可能なハード ディスク領域を監視し、インデックス作成処理のために十分な容量を保つ必要があります。

検索データベースのディスク空き領域要件

検索システム用のメタデータとクローラ履歴情報が格納されている検索データベースに必要なディスク空き領域は、通常、インデックスより大きくなります。特に、メタデータが豊富な SharePoint サイトを主なクロール対象とする場合にはこの傾向があります。

次の式を使用して、検索データベースに必要なディスク空き領域を計算します。

必要なディスク空き領域 (GB) = Total_Corpus_Size (GB) x File_Size_Modifier x 4

File_Size_Modifier は、コーパス内のファイルの平均サイズに基づいた、次のいずれかの数字です。

• コーパスに含まれるファイルが非常に小さい場合は 1.0 (平均ファイル サイズ = 1 KB)。

• コーパスに含まれるファイルが標準的な大きさの場合は 0.12 (平均ファイル サイズ = 10 KB)。

• コーパスに含まれるファイルが大きい場合は 0.05 (平均ファイル サイズ = 100 KB 以上)。

たとえば、1 GB のコーパスに平均サイズ 10 KB のファイルが主に含まれている場合、次の値を式に代入してインデックス ファイルの予測サイズを計算します。

1 GB x 0.12 = 0.12 GB (120 MB)

次に、インデックス ファイルの予測サイズに 4 を乗算します。

120 MB x 4 = 480 MB

よって、検索データベースに必要なディスク空き領域は 480 MB (0.48 GB) です。

インデックス サーバー、クエリ サーバー、およびデータベース サーバーの仕様の決定

Office SharePoint Server 2007 では、検索は SSP レベルで利用できる共有サービスです。Office SharePoint Server 2007 の検索システムは、インデックス サーバーおよびクエリ サーバーという 2 つの主なサーバーの役割で構成されています。

クロールおよびインデックス作成は大量のリソースを必要とする操作です。コンテンツのクロールは、システムがコンテンツにアクセスしてコンテンツとコンテンツの特性を解析し、検索クエリを提供するコンテンツ インデックスを構築する処理です。クロールでは、インデックス サーバー、クロール処理を実行するクエリ サーバー (複数の場合あり)、クロール対象のコンテンツ リポジトリをホストするサーバー (複数の場合あり)、および Office SharePoint Server 2007 ファームを提供するデータベース サーバーの処理リソースおよびメモリ リソースが使用されます。

クロールはシステム全体のパフォーマンスに影響を及ぼすだけでなく、ユーザー応答時間、ファーム内の他の共有サービスのパフォーマンス、クロール処理を実行するクエリ サーバー上の Web サービスにも直接影響します。1 つのクエリ サーバーをクロール処理専用にすることで、ファーム内の他のサーバーの負荷を軽減することができます。

また、クロール処理を専用のクエリ サーバーに割り当てない場合、クロールしたコンテンツのインデックス作成がシステム全体のパフォーマンスに影響を及ぼす可能性もあります。検索関連の処理がファームで実行される処理の大部分を占める場合は、専用のクエリ サーバーを展開することを検討してください。詳細については、この記事の「クロール専用クエリー サーバー」を参照してください。

インデックス サーバーの仕様の決定

ここで説明する情報を参考にして、Office SharePoint Server 2007 ファームで使用するインデックス サーバーの要件を決定してください。

インデックス サーバーの CPU

インデックス サーバーのプロセッサ速度は、クロール速度と、インスタンス化可能なクロール スレッドの数に影響します。特に推奨されるプロセッサ数や種類はありませんが、インデックス サーバーの要件を決定する際には、クロール対象のコンテンツの量を考慮する必要があります。企業環境では、インデックス サーバーがインデックス作成の大量の負荷を担うため、複数のプロセッサが必要です。

インデックス サーバーで使用するプロセッサ数を増やした場合のクロール速度の向上率を次の表に示します。

プロセッサ数	クロール速度の向上率 (%)
1	0.00
2	10.89
4	19.77
8	30.77

インデックス サーバーのメモリ

インデックス サーバーでは、クローラ エンジンによる処理のため、ドキュメントがバッファに読み込まれます。約 100 万ドキュメントのコーパスがあるファームでは、インデックス サーバーに約 1.5 GB のメモリが必要です。ドキュメントはメモリで処理されてから、ディスクに書き込まれます。メモリ容量が大きいほど、クローラが並行処理できるドキュメント数が多くなり、クロール速度が速くなります。

100 万以上のドキュメントのコーパスをインデックス サーバーでクロールする場合は、4 GB 以上の RAM を搭載することをお勧めします。

インデックス サーバーのディスク速度

アクセス時間が 2 ミリ秒 (ms)、高速書き込み時の書き込み時間が 150 MB/秒以上の RAID 10 を使用することをお勧めします。

単一インデックスと関連性

SharePoint Portal Server 2003 では、コンテンツ インデックスを複数のサーバーに分割して、インデックスが作成されたコンテンツのサブセットを作成し、コンテンツの増加に適切に対応することができます。Office SharePoint Server 2007 では、複数のインデックス サーバーを使用するスケール アウトがサポートされていますが、インデックス サーバー 1 つに対して個別に SSP が必要であり、個々のインデックスを集約する方法はありません。

インデックス サーバーの数

各 SSP を完全に分離する必要がある場合、またはシステムのスケール アウトを実行する場合は、複数のインデックス サーバーをファーム内に展開できます。ファームのインデックス サーバー数に厳密な制限はありませんが、テストでは最大で 4 つのインデックス サーバーを使用しました。

ファームで使用するインデックス サーバー数は、目標とする検索方法に依存します。検索において、クロールされたコンテンツが 1 つの結果セットに含まれている必要がある場合は、1 つの SSP と 1 つのインデックス サーバーを展開します。ほとんどの組織では、クロールされた全コンテンツをユーザーが検索できることが求められるため、複数の検索範囲を設定する必要はありません。

検索範囲を分割し、各コンテンツ リポジトリに対応する個別の検索結果を提供する場合は、複数の SSP とインデックス サーバーを使用できます。個別の検索範囲が求められるシナリオの例としては、企業において、特定のユーザー グループのみが検索できる機密性の高いドキュメントを保管している部署がある場合が挙げられます。

システムの規模とセキュリティ要件に応じて、すべての SSP を 1 つのインデックス サーバーに関連付けたり、各 SSP を個々のインデックス サーバーに関連付けたりすることができます。

堅牢なハードウェア構成の 1 つのインデックス サーバーで最大 5,000 万のドキュメントをサポートできます。1 つのインデックスをこのサイズで構築する場合は、インデックスがすべてのクエリ サーバーへ伝達されるため、ファーム内のインデックス サーバーを 1 つだけにすることをお勧めします。インデックス サーバーをもう 1 つ追加すると、そのインデックス サーバーのインデックスもファーム内のすべてのクエリ サーバーに伝達されるため、クエリ サーバーの負荷が増大します。

SSP を追加して検索容量を増やすには、スケール アウトを実行する必要もあります。少なくとも、インデックス サーバー、データベース サーバー、および専用の Web サーバーを 1 つ追加する必要があります。現在のハードウェアにおいて、1 つの SSP で 1,000 万のドキュメントのインデックス作成がサポートされている場合、20 SSP をホストする同一ハードウェアを使用してスケール アップできます。

これにより、1 つの SSP で約 200 万、合計で約 4,000 万のドキュメントのインデックスを作成することができます。

クロール専用クエリ サーバー

1 つのクエリ サーバーをクロール処理専用にすることをお勧めします。

既定では、検索機能が有効にされているファーム内のすべてのクエリ サーバーがクロール処理を実行します。クロール処理が開始されると、インデックス サーバーからクエリ サーバーに対して要求が送信され、クロールされたコンテンツがフェッチされてから、インデックス サーバーに送信されます。ユーザー負荷が大きい場合、クロール処理によって、ユーザーからの要求に対するシステムの応答が遅くなる可能性があります。

クロール処理によるファームのパフォーマンスへの影響を軽減するために、クロール専用のクエリ サーバーを構成できます。1 つのクエリ サーバーをクロール処理専用にすることで、すべてのクロール処理が専用サーバーを使用して実行され、ファーム内のこれ以外のクエリ サーバーはユーザーの要求に対するサービスを継続できます。この構成は、クロール処理を夜間に限定できない環境や、ユーザー要求が 24 時間いつでも行われる地理的に分散した環境で特に便利です。

1 つのクエリ サーバーをクロール専用にする方法の詳細については、「クロール専用のフロントエンド Web サーバーを構成する (Office SharePoint Server 2007)」を参照してください。

インデックス サーバーのパフォーマンスの最適化

インデックス作成処理によってデータベース サーバーにかかる負荷が増大し、ファームの応答速度が落ちる場合があります。また、Search インデックス サービスが実行されている他のアプリケーション サーバー上の他の共有サービスに影響が及ぶ可能性もあります。各インデックス サーバーのインデックス作成のパフォーマンス レベルを、次の 3 つの値のいずれかに調整できます。

• 低下

• 一部低下

• 最大

既定の設定は [低下] です。この設定は特定のインデックス サーバーに対してのみ構成でき、SSP に対しては構成できません。

Office SharePoint Server Search サービスによって、クロールしたドキュメントのすべてのメタデータがデータベース テーブルに書き込まれるため、クロールはデータベース サーバーのパフォーマンスに影響を及ぼします。データベース サーバーの過負荷が発生する速さで、インデックス サーバー (複数の場合あり) がデータを生成する可能性があります。

独自のテストを実行して、クロール速度、ネットワーク遅延、データベースの負荷、およびクロール対象コンテンツ リポジトリの負荷のバランスをとる必要があります。

テスト時のパフォーマンス レベル設定とインデックス サーバーおよびデータベース サーバーの CPU 使用率との関係を、次の表に示します。

パフォーマンス レベルの設定	インデックス サーバーの CPU の使用率 (%)	データベース サーバーの CPU の使用率 (%)
低下	20	20
一部低下	24	24
最大	25	26

以下に示すパフォーマンス レベル設定に関するシナリオと推奨事項を参考にしてください。

• インデックス サーバーおよびデータベース サーバーが Office SharePoint Server Search サービスのみで使用されている場合は、レベルを [最大] に設定できます。ただし、[最大] に設定した場合のデータベース サーバーの CPU 使用率の増加がインデックス サーバーに対して 30% 以下になるようにすることをお勧めします。パフォーマンス レベルを [最大] に設定した際に、データベース サーバーの CPU 使用率の増加が 30% を超える場合は、パフォーマンス レベルを次に低い設定にすることをお勧めします。

• アプリケーション サーバーおよびデータベース サーバーが Office SharePoint Server Search サービス、Excel Calculation Services など複数の共有サービスによって共有されている場合は、パフォーマンス レベルを低く設定することをお勧めします。ただし、インデックス作成処理のレベルを [最大] より低くすると、アイテムのインデックス作成速度が遅くなり、検索結果の情報が古くなる可能性があります。ローカル サーバーのパフォーマンスを監視して、インデックス サーバーの適切なパフォーマンス レベルを判断してください。

インデックス サーバーのパフォーマンス レベルを指定するには、次の手順を実行します。

インデックス サーバーのパフォーマンスを調整する

1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Office Server] をポイントし、[SharePoint 3.0 サーバーの全体管理] をクリックします。

2. サーバーの全体管理のホーム ページで [サーバー構成の管理] をクリックします。

3. [サーバー構成の管理] ページで、[トポロジおよびサービス] セクションの [サーバーのサービス] をクリックします。

4. [サーバーのサービス] ページの [サーバー] メニューで管理するインデックス サーバーを選択します。

5. [以下の表のサービスを起動] セクションの [Office SharePoint Server Search] をクリックします。

6. [Office SharePoint Server Search サービス設定の構成] ページの [インデクサのパフォーマンス] セクションで適用するパフォーマンスレベルを選択します。

7. [OK] をクリックして変更を保存します。

クローラ影響ルール

クローラ影響ルールは、Office SharePoint Server Search サービスが指定されたコンテンツ ソースを使用してクロールする際に同時に生成する要求の数を指定する、ファームレベルの検索構成設定です。同時要求数が多いほど、クロール速度は速くなります。クローラ影響ルールで指定する要求頻度は、データベース サーバーにかかる負荷およびクロール対象のコンテンツをホストするサーバーにかかる負荷に直接影響を及ぼすため注意が必要です。特定のサイトに関する要求頻度を増やす場合は、クロール対象サーバーを注意深く監視して増大した負荷が許容範囲であるかどうかを判断する必要があります。

既定値は、インデックス サーバーのプロセス数です。したがって、クワド プロセッサ コンピュータの既定値は 8 です。値を調整し、対象サーバーの負荷を計測して、最適な同時要求数を決定することをお勧めします。同時要求数は 1、2、4、8、16、32、64 の値から選択できます。

また、一度に 1 つのドキュメントを要求し、次の要求まで指定した時間待機するルールを作成することもできます。このようなルールは、ユーザー負荷が一定しているサイトをクロールする際に便利です。

同時要求数とインデックス サーバーおよびデータベース サーバーの CPU 使用率との間の関係を、次の表に示します。

クロール スレッド数	インデックス サーバーの CPU の使用率 (%)	データベース サーバーの CPU の使用率 (%)
4	35	12
8	40	15
12	45	15
16	60	20

クローラ影響ルールは、次の手順を使用して作成できます。

クローラ影響ルールを作成する

1. [スタート] ボタンをクリックし、[すべてのプログラム] をポイントします。次に、[Microsoft Office Server] をポイントし、[SharePoint 3.0 サーバーの全体管理] をクリックします。

2. サーバーの全体管理のホーム ページで、[アプリケーション構成の管理] をクリックします。

3. [アプリケーション構成の管理] ページの [検索] で、[Search サービスの管理] をクリックします。

4. [Search サービスの管理] ページの [ファームレベル検索の設定] セクションで、[クローラ影響ルール] をクリックします。

5. [クローラ影響ルール] ページの [ルールの追加] をクリックします。

6. [クローラ影響ルールの追加] ページの [サイト] セクションに、ルール作成対象のサイト名を入力します。プロトコル名は含めないでください (たとえば、「http://」は入力しないでください)。

7. [要求頻度] セクションで、このサイトのドキュメントをクローラが要求する方法を指定します。

   1. 同時に複数のドキュメントを要求するには、[指定した数のドキュメントを一度に要求し、次の要求まで待機しない] を選択し、[同時要求数] の一覧から値を選択します。

   2. 一度に 1 つのドキュメントを要求するには、[1 度に 1 つのドキュメントを要求し、次の要求まで指定した時間待機する] を選択し、[待機時間 (秒数)] ボックスに次の要求まで待機する秒数を入力します。

8. [OK] をクリックして、ルールを作成します。

クエリ サーバーの仕様の決定

ここで説明する情報を参考にして、Office SharePoint Server 2007 ファームで使用するクエリ サーバーの仕様を決定してください。

クエリ サーバーのメモリ

使用できるメモリ容量が大きいほど、Office SharePoint Server Search サービスが特定のクエリを実行するためにハード ディスクにアクセスする回数が減少します。また、十分なメモリ容量があれば、より効率的にキャッシュを使用できます。インデックス全体を格納できるメモリをクエリ サーバーに搭載することが理想です。

クエリ サーバーのインデックス サイズと 1 つのクエリあたりのユーザー応答時間との関係を、次の図に示します。

クエリ サーバーのディスク速度

高速ディスク書き込み対応の RAID 10 を使用することをお勧めします。

クエリ サーバー数

ファームに複数のクエリ サーバーを展開して、冗長性と負荷分散を実現できます。使用するクエリ サーバー数は、ファームに存在するユーザー数とピーク時の負荷の予測に基づいて決定します。テストでは、1 つのファームで最大 8 つのクエリ サーバーを使用しました。

ファームにクエリ サーバーを追加した際の、クエリのスループット、検索データベースのデータベース サーバーの CPU の使用率 (%)、およびクエリ サーバーの CPU の使用率 (%) の変化を、次の図に示します。このデータが得られたテストで使用したデータベース サーバーは、コンテンツ データベースおよびサービス データベースで共有されていました。

リモート サーバーの遅延

サーバーの遅延は、クロールのパフォーマンスに影響する主要な要素です。クロール全体のパフォーマンスを最大限にするには、ファーム サーバーのパフォーマンスのバランスをとる必要があります。たとえば、優れたインデックス サーバーがあったとしても、クロールされるデータベース サーバーの応答が速くなければ、インデックス サーバーは能力の 25% しか発揮できない場合があります。この場合、データベース サーバーをスケール アップして、ファーム全体のクロール速度を速くすることが考えられます。

独自のテストを実行して、使用環境のサーバーの応答速度を判断する必要があります。クロールのパフォーマンスが低い場合、対象ファームを提供するデータベース サーバーがボトルネックであることがよくあります。クロールのパフォーマンスを向上させるには、次の方法があります。

• プロセッサの追加またはアップグレード、メモリの追加、シーク時間および書き込み時間が速いハード ディスクへのアップグレードを行って、データベース サーバーをスケール アップする。

• ファーム内のクエリ サーバーのメモリを増やす。

• クロール対象のデータベース サーバーが、日中はユーザー トラフィックをサービスし、クロールにはオフピーク時に応答できるように、ピーク時以外にクロールを実行する。

データベース サーバーの仕様の決定

Office SharePoint Server 2007 の検索システムは、コンテンツに関連付けられているテキスト データとメタデータの両方をクロールします。Office SharePoint Portal Server 2003 では、インデックス システムによって収集された全メタデータが JET データベース プロパティ ストアに格納されました。Office SharePoint Server 2007 では、完全なテキストの反転されたインデックスがインデックス サーバーに格納され、メタデータが検索データベースに格納されます。インデックス サーバーによってメタデータがデータベースに書き込まれ、クエリ サーバーがそのデータを読み込んで、ユーザーによって発行されたプロパティベースのクエリを処理します。

ここで説明する情報を参考にして、Office SharePoint Server 2007 ファームで使用するデータベース サーバーの仕様を決定してください。

データベースのスループット

データベースのメタデータ ストアは、ファーム内のインデックス サーバーとすべてのクエリ サーバーで共有されています。すべてのメタデータはインデックス サーバーによって書き込まれ、このデータをクエリ サーバーが読み込んで検索要求を処理します。クエリのスループットは、メタデータ ストアの応答速度の影響を大きく受けます。

ファーム内のクエリ サーバー数が増えると、データベース サーバーにかかる負荷も増大し、クエリのスループット全体に影響を及ぼします。インデックス サーバーやクエリ サーバーをファームに追加する場合は、データベース サーバーを注意深く監視して、データベースのパフォーマンスが十分であることを確認する必要があります。

データベース サーバーのハード ディスクの分散

Office SharePoint Server Search サービスはクロール中に膨大な量のデータを検索データベースに書き込むので、インデックスに 500 万以上のアイテムが含まれるシナリオでパフォーマンスを向上させるためには、SharedServices_Search_Db、SharedServices_Db、および TempDb データベース用に個別のスピンドルを使用することをお勧めします。

データベース サーバーのディスク速度

高速ディスク書き込み対応の RAID 10 を使用することをお勧めします。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

• Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2

入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。

関連項目

概念

クロール専用のフロントエンド Web サーバーを構成する (Office SharePoint Server 2007)