パフォーマンスと容量の計画 (FAST Search Server 2010 for SharePoint)

  • [アーティクル]

 

適用先: FAST Search Server 2010

トピックの最終更新日: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint 展開のパフォーマンスと容量を計画するときには、ビジネス環境とシステム アーキテクチャの両面に関して、いくつかの点を考慮する必要があります。

  • ビジネス環境に関する考慮事項

  • システム アーキテクチャに関する考慮事項

Microsoft SharePoint Server 2010 ファーム全体のパフォーマンスと容量を計画する方法の詳細については、「SharePoint Server 2010 の容量計画」を参照してください。

注意

この記事では、コンテンツのクロールに、SharePoint Server 2010 のクローラー、インデックス コネクタ フレームワーク、および FAST Search Server 2010 for SharePoint Content Search Service Application (Content SSA) を使用するものと仮定します。

ビジネス環境に関する考慮事項

使用する環境で、以下を定義します。

コンテンツ ボリュームの処理能力

検索可能にするコンテンツの分量を判断します。アイテムの総数には、ドキュメント、Web ページ、リスト アイテムなど、すべてのオブジェクトを含める必要があります。

可用性

可用性の要件を判断します。ユーザーが必要とするのは、特定のサーバーで障害が発生しても稼働を続けられる検索ソリューションでしょうか。可用性のレベルは大きく分けて 2 つあります。1 つはクエリ照合の可用性、もう 1 つはインデックス処理の可用性です。

コンテンツの新しさ

検索結果の "鮮度" について判断します。ユーザーがデータを変更してから、検索結果に更新後のコンテンツが表示されるようになるまで、どの程度の時間を置く必要があるでしょうか。コンテンツの変更はどの程度の頻度で生じるでしょうか。

クエリ評価の処理能力

コンテンツに対する検索を同時に実行するユーザー数を判断します。これには、人間が検索ボックスに入力するクエリと、背後で実行されるその他のクエリの両方を含みます。背後で実行されるクエリとは、たとえば、Web パーツが自動で行うデータ検索や、Microsoft Outlook 2010 Social Connectors が検索システムに要求する、セキュリティによるトリミングが必要な URL を含むアクティビティ クロールです。

システム アーキテクチャの考慮事項

システム アーキテクチャに関しては、各種トポロジの選択の影響とそこから生じるネットワーク トラフィックに加えて、インデックス処理とクエリ評価プロセスについて理解している必要があります。さらに、Web アナライザー コンポーネントの容量設計にも注意が必要です。このコンポーネントのパフォーマンスは、インデックス処理されたアイテムの数と、それらのアイテムがハイパーリンクを含むかどうかによって変わります。

  • インデックス処理がパフォーマンスと処理能力に及ぼす影響

  • クエリ評価がパフォーマンスと処理能力に及ぼす影響

  • トポロジがパフォーマンスと処理能力に及ぼす影響

  • ネットワーク トラフィックがパフォーマンスと処理能力に及ぼす影響

  • Web リンク分析がパフォーマンスと処理能力に及ぼす影響

インデックス処理がパフォーマンスと処理能力に及ぼす影響

FAST Search Server 2010 for SharePoint ファームでのコンテンツのクロールは、複数の段階を経て進みます。その段階とは、インデックスの取得、インデックスのメンテナンス、およびインデックスのクリーンアップです。

インデックスの取得

インデックスの取得は、完全なクロールを実行する段階です。クロールを同時実行する場合もあります。

新しいコンテンツを追加するときのクロールのパフォーマンスは、構成したアイテム処理コンポーネントの数で主に決まります。結果には、CPU コア数と各コアの速度の両方が影響します。おおよその目安として、1 GHz の CPU コア 1 つにつき、平均的なサイズの Office ドキュメント (約 250 KB) を 1 秒に 1 つ処理できます。たとえば、アイテム処理に使用する CPU コア数が 48 で、各コアが 2.26 GHz というシナリオの場合、推定される総スループットは、1 秒あたり平均で 48 × 2.26、つまり約 100 アイテムとなります。

インデックスのメンテナンス

インデックスのメンテナンスの段階では、全コンテンツの増分クロールを行い、新しいコンテンツや変更されたコンテンツを検出します。通常、SharePoint Server 2010 コンテンツ ソースをクロールするときに検出される変更の多くは、アクセス権に関連するものです。

増分クロールは、次のようなさまざまな操作で構成されます。

  • アクセス権 (ACL) の変更と削除: これらは、アイテムの処理はほとんど必要ありませんが、インデクサーには高い処理負荷がかかります。クロール速度はフル クロールを上回ります。

  • コンテンツ更新: これらは、アイテムの完全な処理が必要で、インデクサーの処理も新コンテンツ追加の場合を上回ります。内部的には、このような更新は、古いアイテムの削除と新しいコンテンツの追加で構成されます。

  • 追加: 増分クロールにも、新たに見つかったアイテムが含まれる場合があります。これらの負荷は、インデックス取得のクロールと同じです。

操作の種類に応じて、増分クロールの速度は、最初のフル クロールより速い場合も遅い場合もあります。ACL の更新と削除が中心の場合は速くなり、アイテムの更新が中心の場合は遅くなります。

コンテンツ ソースからの更新だけでなく、リンク分析、クリックスルー ログ分析、インデックス パーティションの再編成などの内部操作によってもインデックスは変わります。FAST Search Server 2010 for SharePoint のリンク分析とクリックスルー ログ分析では、インデックスに追加的な内部更新が行われます。たとえば、アイテムのハイパーリンクは、参照先アイテムのアンカー テキスト情報の更新につながります。このような更新は、ACL 更新と同様のロード パターンを持ちます。インデクサーは、インデックス パーティションの内部の再編成とデータの最適化を定期的に実行します。最適化は毎日午前 3 時に開始され、必要に応じてパーティション間での再分配が行われます。これらの各内部操作からわかるように、進行中のコンテンツ クロールに伴って、インデックス処理が間隔以外で発生することもあります。

インデックスのクリーンアップ

インデックスのクリーンアップの段階へ移行するのは、Search Service アプリケーションからコンテンツ ソースか開始アドレス (またはその両方) を削除したときです。また、コンテンツを供給するホストをコンテンツ インデックス コネクタが見つけられないときにも移行します。インデックス コネクタは、連続する 3 回のクロールにわたってホストを探しますが、それでもホストが見つからない場合に、コンテンツ ソースを削除し、インデックスをクリーンアップの段階に移行させます。

クエリ評価がパフォーマンスと処理能力に及ぼす影響

インデックス全体のパーティションには 2 つのレベルがあります。インデックス列とインデックス パーティションです。

インデックス全体が大きすぎて 1 つのサーバーに配置できない場合は、共通の要素を持たない複数のインデックス列に分割できます。この場合、クエリ照合コンポーネントは、検索クラスター内の全インデックス列に照らしてクエリを評価し、各インデックス列の結果をマージして最終的なクエリ ヒット リストを作成します。各インデックス列内でインデクサーは、インデックス対象の多数のアイテムを処理するときのインデックス処理とクエリの待機時間を抑えるために、インデックスのパーティション分割を使用します。このパーティション分割は動的で、各インデックス サーバーで内部的に処理されます。クエリ照合コンポーネントがクエリを評価するときには、各パーティションは別個のスレッドで実行されます。パーティション数の既定値は 5 です。サーバー (列) あたり 1500 万以上のアイテムを処理するには、パーティションをもっと大きな数に構成する必要があります。

単一のクエリの評価処理の概略を次の図に示します。

単一のクエリの図

CPU 処理 (薄い青色) の後で、ディスク アクセス サイクルの待機時間 (白色) に続き、ディスク データ読み取りの実際の転送 (濃い青色) が実行されます。これが、クエリ 1 つにつき 2 ～ 10 回程度繰り返されます。ここからわかるように、クエリの待機時間は、記憶域サブシステムの I/O 待機時間に加え、CPU の速度によって左右されます。クエリ照合コンポーネントは、単一の各クエリを別個に評価し、すべてのインデックス列の複数のインデックス パーティションにわたって並行して処理します。つまり、既定値の 5 つのパーティションによる構成の場合、各クエリは、各列内の 5 つの別個のスレッドで評価されます。

クエリの負荷が高まると、次の図に示すように、クエリ照合コンポーネントは複数のクエリを並行して評価します。

複数のクエリの図

クエリの複数のフェーズがそれぞれ別のタイミングで実行されるため、同時実行の I/O アクセスがボトルネックとなる可能性は低くなります。CPU 処理は大きく重複しており、サーバーで使用可能な複数の CPU コアにまたがってスケジュールされます。テストしたすべてのシナリオにおいて、クエリのスループットが最高に達するのは、使用可能なすべての CPU コアを 100% 使用したときです。これは、記憶域サブシステムが飽和する前の段階です。CPU コアを増やし、速度を上げると、クエリのスループットも向上し、最終的にはディスク アクセスがボトルネックとなります。テストしたシナリオの詳細については、「FAST Search Server 2010 for SharePoint Capacity Planning (英語)」のホワイトペーパーを参照してください。

注意

インデックス列が多い大規模な展開の場合、クエリ処理コンポーネントととクエリ照合コンポーネントの間のネットワーク トラフィックがボトルネックとなる可能性があり、このインターフェイスのネットワーク帯域幅を増強することが必要な場合があります。

クエリの待機時間は、最大スループットで CPU スタベーションに達するまでは、クエリの負荷とはあまり関係ありません。各クエリの待機時間は、最大のインデックス パーティションに含まれるアイテム数に応じて変わります。アイドル時間後にクエリの負荷が適用される場合、キャッシュ効果によって、クエリの待機時間は若干向上します。クロールが進行中の場合、クエリの待機時間は多少低下します。しかし、バックアップ インデクサーのある検索行を使用する場合、インデクサーおよびアイテム処理と同じサーバーで検索が動作するシステムに比べれば、影響ははるかに軽微です。

トポロジがパフォーマンスと処理能力に及ぼす影響

インデックス処理とクエリ照合はどちらも CPU リソースを使用するため、インデックス処理とクエリ照合を同じ行で実行する展開では、コンテンツのクロール時にクエリのパフォーマンスが多少下がります。単一行の展開では、インデックス処理、クエリ照合、およびアイテム処理をすべて同じサーバー上で実行する可能性が高くなります。

専用の検索行を展開することで、クエリのトラフィックをインデックス処理およびアイテム処理と分離できます。この場合、検索クラスターで必要なサーバー数は 2 倍になりますが、クエリのパフォーマンスの向上と安定化につながります。また、この構成では、クエリ処理とクエリ照合の冗長性も確保できます。専用の検索行を使用する場合、クロールおよびインデックス処理の際、インデクサーが新しいインデックス (特定のパーティションに対するインデックスの新バージョン) を作成するときに、トラフィックが若干増加することが考えられます。インデクサー コンポーネントは新しいインデックス データをネットワーク経由でクエリ照合コンポーネントに渡します。記憶域サブシステムが適切な場合、クエリのパフォーマンスに及ぶ主な影響は、新しいインデックスを受け取ったときにキャッシュが無効化し、パフォーマンスが若干低下することです。

また、プライマリ インデクサーで回復できないエラーが発生した場合に備えて、バックアップ インデクサーを展開することもできます。通常、バックアップ インデクサーは、検索行と共存させます。このシナリオでは、バックアップ インデクサーと検索行の共存に対し、さらにアイテム処理を展開しないようにする必要があります。バックアップ インデクサーを展開すると、プライマリ インデクサーとバックアップ インデクサーのサーバー間でインデックス データを同期しておくための通信が定期的に発生するため、検索行の I/O 負荷が増加します。また、両方のサーバーでディスクのデータ記憶域も余分に必要となります。負荷の増加に対処できるように記憶域サブシステムをディメンショニングしてください。

ネットワーク トラフィックがパフォーマンスと処理能力に及ぼす影響

各サーバーの CPU パフォーマンスが向上すると、サーバー間のネットワーク接続がボトルネックになる可能性があります。たとえば、サーバー 4 台で構成される小規模な FAST Search Server 2010 for SharePoint ファームであっても、アイテムの処理とインデックス処理は、1 秒あたり 100 アイテムの速度で進められます。各アイテムの平均サイズが 250 KB の場合、ネットワーク トラフィックは平均約 250 Mbps となります。このような負荷では、1Gbps のネットワーク接続でも飽和する可能性があります。

コンテンツのクロールとインデックス処理によって発生するネットワーク トラフィックには以下があります。

  • Content SSA 内のインデックス コネクタが取得元からコンテンツを取得します。

  • Content SSA (SharePoint Server 2010 ファーム内) が、FAST Search Server 2010 for SharePoint ファームのコンテンツ配信元コンポーネントに対し、取得したアイテムをバッチで渡します。

  • コンテンツ配信元コンポーネントが、アイテムの各バッチを、使用可能なアイテム処理コンポーネントに送信します。これは通常は、別のサーバーに配置されています。

  • 処理完了後、アイテム処理コンポーネントは、各バッチをインデックス ディスパッチャーに渡します。インデックス ディスパッチャーは、インデックス列の分散に従ってバッチを分割します。

  • インデックス ディスパッチャーは、処理したアイテムを、各インデックス列のインデクサーに分散します。

  • 複数の検索行がある場合、インデクサーはバイナリ インデックスを追加の検索行にコピーします。

全サーバーおよびコンポーネント間の全体のネットワーク トラフィックは、分散システム内のコンテンツ ストリーム自体の 5 倍以上に及ぶことがあります。このような展開では、高性能なネットワーク スイッチでサーバーを相互接続する必要があります。

クエリのスループットが高い場合、発生するネットワーク トラフィックも増加します。特に、複数のインデックス列を使用している場合にはそれが言えます。クエリによるネットワーク トラフィックと、コンテンツのクロールおよびインデックス処理によるネットワーク トラフィックとがあまり重複しないように、展開構成とネットワーク構成を定義する必要があります。

Web リンク分析がパフォーマンスと処理能力に及ぼす影響

Web アナライザー コンポーネントのパフォーマンス設計は、インデックス処理するアイテムの数と、アイテムにハイパーリンクが含まれるかどうかによって変わります。主な負荷となるのは、ハイパーリンクを含むアイテム (リンクされているアイテム) です。データベース系のコンテンツには、通常はハイパーリンクは含まれていません。イントラネット コンテンツ (SharePoint サイトのコンテンツを含む) には、ハイパーリンクを持つ HTML が含まれていることがよくあります。外部の Web コンテンツは、ほぼすべてが、多くのハイパーリンクを持つ HTML ドキュメントです。

Web アナライザー コンポーネントのパフォーマンス設計では、CPU コアの数は重要ですが、アンカー テキストとランク データを持つインデックスの更新に必要な時間を判断するうえで、最も重要なのはディスク領域です。リンク、アンカー テキスト、またはクリック スルーのログ分析を Web アナライザー コンポーネントが実行するのは、十分なディスク領域がある場合のみです。次の表は、Web アナライザー コンポーネントの設計上の推奨事項の目安です。

コンテンツの種類 CPU コアあたりのアイテム数 100 万アイテムあたりのディスク領域 (GB)

データベース

2000 万

2

SharePoint Server 2010 / イントラネット

1000 万

6

パブリック Web コンテンツ

500 万

25

注意

この表に示す設計規則は、ファーム全体に対する値です。Web アナライザー コンポーネントをサーバー 2 台に分散する場合、サーバー 1 台あたりの要件はこの半分になります。

必要なメモリ容量はコンテンツの種類にかかわらず同じですが、使用するコア数に応じて変わります。100 万アイテムにつき 30 MB に加え、CPU コア 1 つにつき 300 MB を追加した容量とすることをお勧めします。複数の種類のコンテンツを含む環境の場合は、最も要件が厳しい種類のコンテンツを設計の基盤として処理能力を計画するのが最適な戦略です。たとえば、データベースと SharePoint サイトのコンテンツが混在するシステムの場合は、SharePoint サイトのコンテンツのみを含むシステムと仮定して設計することをお勧めします。

See Also

Concepts

パフォーマンスと容量の管理 (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量のテスト (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量の監視 (FAST Search Server 2010 for SharePoint)
パフォーマンスと容量のチューニング (FAST Search Server 2010 for SharePoint)