SharePoint Server でインターネット サイトの検索をスケーリングする
適用対象:2016 2019 Subscription Edition SharePoint in Microsoft 365
この記事では、インターネット サイト向けの検索トポロジに対する、仮想マシンおよび物理サーバーのハードウェアの最小要件について説明します。
また、この記事では、パフォーマンスと可用性を向上するための検索トポロジのスケーリングに関する基本的指針を示します。
概要
この記事では、インターネット サイトの最小要件について説明すると共に、インターネット サイトの検索トポロジをスケールアウトする方法およびタイミングに関する指針を示します。
トポロジの例については、技術ダイアグラム「SharePoint Server 2016 のインターネット サイト検索アーキテクチャ」を参照してください。
検索コンポーネントの概要と説明、および全体的な検索アーキテクチャについては、「SharePoint Server での検索アーキテクチャの概要」および技術ダイアグラム「SharePoint Server 2016 の検索アーキテクチャ 」を参照してください。
インターネット サイト向けの検索トポロジのハードウェア要件
インターネット サイト向けの中規模の検索トポロジをホストするサーバーのハードウェア要件を以下の表に示します。 ハードウェア要件は以下のサーバーに適用されます。
検索コンポーネントが含まれるアプリケーション サーバーと Web サーバー。
検索データベースが含まれるデータベース サーバー。
記載されている、検索コンポーネントをホストするサーバーの最小 RAM 要件は、そのサーバーで必要な RAM 容量の合計です。 たとえば、1 つのサーバー上でコンテンツ処理コンポーネント、検索管理コンポーネント、クロールコンポーネントをホストする場合、そのサーバーには最小で 24 GB の合計 RAM 容量が必要です。
各サーバーには、Windows Server オペレーティング システムの基本インストールに十分なディスク領域、およびログ記録、デバッグ、メモリ ダンプ作成などの診断用の十分なディスク領域が必要です。 また運用環境では、サーバーに毎日の業務およびページ ファイルのためのディスクの空き領域が余分に必要になります。 ご使用の Windows Server インストールに対応するディスクの空き領域およびページ ファイル サイズのガイダンスに従ってください。
注:
中規模の検索トポロジの例は、物理ハードウェア用に最適化されていますが、仮想マシンにも展開できます。
検索コンポーネントをホストするアプリケーション サーバーと Web サーバー。
物理サーバー上の検索コンポーネント | RAM | ハード ディスク | プロセッサ |
---|---|---|---|
インデックス コンポーネント | インデックス コンポーネント、クエリ処理コンポーネント、および Web フロント エンドをホストするファーム内のサーバーごとに 48 GB。 | 500 GB の追加ディスク容量 (個別のディスク ボリューム/パーティションが望ましい)。 | **すべてのコンポーネント:**64 ビット、最小 4 コア、8 コアをお勧めします。 |
分析処理コンポーネント | 分析処理管理コンポーネント、クロール コンポーネント、コンテンツ処理コンポーネント、および検索管理コンポーネント、あるいはこれらのコンポーネントのいずれかをホストするファーム内のサーバーごとに 24 GB。 | 300 GB の追加ディスク容量 (個別のディスク ボリューム/パーティションが望ましい)。 | |
クロール コンポーネント コンテンツ処理コンポーネント | 分析処理コンポーネントの要件を参照してください。 | システム ドライブに 80 GB。 | |
クエリ処理コンポーネント | インデックス コンポーネントの要件を参照してください。 | ||
検索管理コンポーネント | 分析処理コンポーネントの要件を参照してください。 |
検索データベースをホストするデータベース サーバー
コンポーネント | 最小要件 |
---|---|
プロセッサ | 小規模のトポロジに 64 ビット、4 コア。 中規模のトポロジに 64 ビット、8 コア。 |
RAM | 小規模のトポロジに 8 GB。 中規模のトポロジに 16 GB。 |
ハード ディスク | システム ドライブに 80 GB。 ハード ディスク容量はコンテンツの量によって異なります。 |
中規模インターネット サイト トポロジのパフォーマンスに関する考慮事項
3,400,000 アイテムのコーパス サイズ、1 秒あたり約 100 ~ 200 ドキュメントの処理 (言語に依存)、1 秒あたり 85 ページ ビューの使用パターン (1 秒あたり 100 クエリに対応) に対応するように中規模インターネット サイト (FIS) を最適化します。
パフォーマンスに関する考慮事項
検討項目 | 重要な理由 |
---|---|
キャッシュ | クエリとその結果は、キーと値のペアで Windows Server AppFabric でキャッシュされます。クエリはキーであり、結果は値です。 クエリごとに、約 50% のキャッシュ比率があります。 つまり、1 秒あたり 200 クエリの使用パターンがある場合、約 100 個のクエリが検索インデックスに送信され、他の 100 個のクエリがキャッシュされます。 キャッシュからの結果のクエリ待機時間は、検索インデックスから取得した結果よりも短くなります。 たとえば、頻繁に実行されるフロント ページ クエリの結果はキャッシュされる可能性があります。 |
継続的クロール | 既定の 15 分間隔ではなく 1 分間隔の継続的クロールを有効にすることをお勧めします。 継続的クロールは、SharePoint コンテンツ ソースに対してのみ有効にできます。 |
匿名アクセス | 匿名アクセスを使用すると、ユーザーは SharePoint インターネット サイトにログオンするのに資格情報を使用する必要はありません。 匿名クエリはキャッシュに入れられるので、クエリの待機時間が短くなり、コストが低くなります。 匿名アクセスを Web フロントエンドおよびサイトの 2 つの場所で有効にする必要があります。 |
クエリの待機時間 | クエリの待機時間は、キャッシュ、匿名アクセス、および適用およびトリガーされるクエリ ルールの数や複雑さなどの他の要因の影響を受けます。 また、検索インデックスが格納されているディスクについても検討してください。複数のスピンドルを持つディスクは、ディスクのアクセス速度を向上させ、クエリの待機時間を短縮できます。 |
関連項目
SharePoint Serever で検索トポロジを管理する
SharePoint Server で既定の検索トポロジを変更する