SharePoint でより多くのコンテンツとユーザーを対象に、エンタープライズ検索トポロジを再設計する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
ほとんどの検索環境では、時間の経過と共に、コンテンツの量とユーザーの数の両方が増えていきます。 どこかの時点で、検索環境が検索アーキテクチャの容量とパフォーマンスを超えてしまいます。 解決するには、以下のように検索アーキテクチャのトポロジをスケーリングします。
トポロジの再設計 (この記事)
再設計されたトポロジの実装 (SharePoint Serever で検索トポロジを管理する)
SharePoint Server の検索システムのコンポーネントと、それらの操作方法についてよく理解していますか? 「SharePoint Server での検索アーキテクチャの概要」と「SharePoint Server 2016 の検索アーキテクチャ (または SharePoint Server2013 の検索アーキテクチャ)」を参照すると、検索アーキテクチャ、検索コンポーネント、検索データベース、および検索トポロジについて理解できるようになります。
この記事では、検索トポロジを再設計する手順について説明します。
これらの手順を実行すると、以下が判明します。
使用するトポロジで必要となる、検索コンポーネントと検索データベースの種類ごとの数。
各検索コンポーネントの展開先となるアプリケーション サーバーとデータベース サーバー。
各アプリケーション サーバーとデータベース サーバーに必要なハードウェア リソース。
手順 1: コンテンツがどのくらいあるか。
検索インデックスにあるコンテンツのボリュームは、ファームをホストするためにどんなリソースが必要になるかということに影響します。 既存の検索環境で検索できる項目の数を確認します。 この番号は、SharePoint サーバーの全体管理 Web サイトの [検索管理 ] ページにあります。 検索管理ページを開くには、サーバーの全体管理で [サービス アプリケーションの管理 ] をクリックし、検索サービス アプリケーションの名前をクリックします。
検索可能な項目の数が今後 12 か月間にどのくらい増加すると予想されるかを見積もり、その量の検索トポロジを設計します。 たとえば、インデックス付きアイテムが 8,000,000 個あり、そのコンテンツの量が今後 12 か月間で 50% 増加すると予想される場合です。 12,000,000 個の検索可能な項目を設計する必要があります。
手順 2: 検索アーキテクチャをどのくらいのサイズにスケーリングするか。
検索アーキテクチャをどのくらい大きくまたは小さくするか評価することは必ずしも簡単なことではありません。 検索アーキテクチャのサイズは、必要とするコンテンツのボリューム、クロール レート、クエリ スループット、および高可用性のレベルにより異なります。 Microsoft がテストしたサンプルの検索アーキテクチャがあるので、これをご自身のファームの計画の基礎として使用することをお勧めします。 現在の検索アーキテクチャとサンプルの検索アーキテクチャを比較し、現在の検索アーキテクチャを表わすのに最適なサンプルを決定します。 それから、どのサンプル検索アーキテクチャをスケーリングするか検討します。 選択するサンプルの検索アーキテクチャは、検索可能にする必要のあるコンテンツの量で決まります。
| コンテンツの量 (SharePoint 2016) | サンプルの検索アーキテクチャ | コンテンツの量 (SharePoint 2013) |
|---|---|---|
| 0 - 2,000 万アイテム | 小規模検索ファーム | 0 - 1,000 万アイテム |
| 0 - 8,000 万アイテム | 中規模検索ファーム | 0 - 4,000 万アイテム |
| 0 - 2 億アイテム | 大規模検索ファーム | 0 - 1 億アイテム |
| 0 - 5 億アイテム | 超大規模検索ファーム | サポート対象外 |
これらのサンプル検索アーキテクチャでは仮想マシンが使用されますが、検索アーキテクチャの SharePoint Server ソリューション全体の戦略に従って、物理サーバーと仮想マシンの両方を使用できます。
小規模検索ファーム
この検索アーキテクチャは毎秒 50 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに最大 2,000 万個のアイテムがある場合は、おそらく小規模な検索ファームが最適なファームになります。 毎秒 50 ドキュメントのクロール レートでは、最初のフル クロールで 2,000 万個のアイテムをクロールするには、検索に 110 時間かかります。
中規模検索ファーム
この検索アーキテクチャは毎秒 100 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに 2,000 万から 8,000 万個のアイテムがある場合は、おそらく中規模の検索ファームが最適なファームになります。 毎秒 200 ドキュメントのクロール レートでは、最初のフル クロールで 8,000 万個のアイテムをクロールするには、検索に 280 時間かかります。
大規模検索ファーム
この検索アーキテクチャは毎秒 200 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できると推定されています。 SharePoint Server 2016 ファームに 80 から 2 億個のアイテムがある場合は、おそらく大規模な検索ファームが最適なファームになります。 毎秒 200 ドキュメントのクロール レートでは、最初のフル クロールで 2 億個のアイテムをクロールするには、検索に 280 時間かかります。
超大規模検索ファーム
Microsoft ではこの検索アーキテクチャをテストし、毎秒 300 から 500 ドキュメントをクロールし、毎秒 10 クエリ程度を処理できることを測定しました。 このサイズ検索アーキテクチャは、SharePoint Server 2016 でのみサポートされています。 最大 5 億個のアイテムがある場合は、超大規模検索ファームのようなファームが適しています。 毎秒 500 ドキュメントのクロール レートでは、最初のフル クロールに 5 億個のアイテムをクロールするには、検索に 300 時間かかります。
このサイズの検索ファームを作成するには、必要なパフォーマンスを得られるようファームを慎重に計画し調整する必要があります。 専門家の指導を受けることが適切な場合があります。 また、このサイズの検索ファームをバックアップおよび復元する方法と、データ センターで大規模な停止が発生した場合にファームを復旧する方法を計画することも重要です。 バックアップ、復元および復旧を練習することをお勧めします。
手順 3: 認識しておくべきハードウェア要件は何か。
コンテンツのボリュームを決定し、移動先の新しいトポロジを選択したので、次の手順は、このセクションで説明するように、必要なハードウェアを計画することです。
サーバーを物理的に実行するか仮想的に実行するかを選択する
最初に検索アーキテクチャを計画した時点で、物理サーバー、仮想マシン、またはその組み合わせを使用することを決めています。 この決定がまだ有効かどうかを検討します。 たとえば、中規模サンプル検索アーキテクチャから大規模アーキテクチャに移行する場合、仮想マシンを使用すると、数が増えたサーバーの管理が簡単になることがあります。 仮想環境は管理が簡単ですが、パフォーマンス レベルは物理環境よりも若干低くなる場合があるのでご注意ください。 物理サーバーは仮想サーバーよりも、同じサーバー上でより多くの検索コンポーネントをホストできます。 「Overview of farm virtualization and architectures for SharePoint 2013」に役立つガイダンスがあります。
小規模、中規模、大規模、または超大規模の検索アーキテクチャ のサンプルは仮想マシンで実行されますが、物理サーバーでも実行できます。 サンプル ファーム アーキテクチャでは、検索コンポーネントを仮想マシンからホスト サーバーに移動し、仮想マシンを取り除きます。 各物理サーバーは最大 4 つのインデックス コンポーネントをホストできますが、他の検索コンポーネントの種類ごとに 1 つだけです。 たとえば、物理サーバーを使用するように中規模のサンプル検索アーキテクチャを変更すると、ホスト E に 2 つのコンテンツ処理コンポーネントがあることがわかります。解決策は、コンテンツ処理コンポーネントの 1 つを取り除くものです。 これは、クロール、コンテンツの処理、分析の処理は、コンテンツ処理コンポーネントの数ではなく、使用可能なリソースの量によって異なるためです。
ホスト サーバーのハードウェア リソースを選択する
各検索コンポーネントと検索データベースが良好に機能するには、ホスト サーバーからの最小限のハードウェア リソースが必要です。 しかし、ハードウェア リソースは多ければ多いほど、検索アーキテクチャのパフォーマンスが向上します。 そのため、最小限のハードウェア リソースよりも多くのハードウェア リソースを用意することをお勧めします。 各検索コンポーネントで必要なリソースはワークロードによって異なり、大部分はクロール速度、クエリ速度、およびインデックス付けされたアイテムの数によって決まります。
たとえば、仮想マシンを Windows Server 2008 R2 Service Pack 1 (SP1) でホストする場合、仮想マシン 1 台につき最大で 4 個の CPU コアしか使用できません。 Windows Server 2012 以降では、仮想マシンごとに 8 個以上の CPU コアを使用します。 したがって、より多くの仮想マシンを使用してスケール アップする代わりに、仮想マシンごとにより多くの CPU コアを使用してスケール アウトできます。 同じ検索コンポーネントをホストし、同じハードウェア リソースを持つサーバーまたは仮想マシンをセットアップします。 例としてインデックス コンポーネントを取り上げます。 仮想マシンでインデックス パーティションをホストする場合、最低のパフォーマンスの仮想マシンによって検索アーキテクチャ全体のパフォーマンスが決まります。
各ホスト サーバーに、Windows Server オペレーティング システムの基本インストールと SharePoint Server プログラム ファイル用の十分なディスク領域があることを確認します。 また、ホスト サーバーでは、ログ記録、デバッグ、メモリ ダンプの作成などの診断用、日々の操作用、およびページ ファイル用の空きハードディスク領域も必要です。 通常、Windows Server オペレーティング システムと SharePoint Server プログラム ファイルには、80 GB のディスク領域で十分です。
データベース サーバーごとに SQL ログ スペース用のストレージを追加します。 データベースを頻繁にバックアップするようにデーベース サーバーを設定していない場合は、SQL ログ スペースに大量のストレージが使用されます。 SQL データベースを計画する方法の詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)」を参照してください。
分析レポート データベースが必要とする最低限のストレージは、異なる場合があります。 これは、ストレージの量は、ユーザーが SharePoint Server とやり取りする方法によって異なるためです。 ユーザーが頻繁に操作すると、通常は保存されるイベントが多くなります。 現在の検索アーキテクチャがデータベースの分析に使用しているストレージの量を確認し、再設計するトポロジにこの量以上を割り当ててください。
小規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| クロール、検索管理、分析、およびコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | A、B | 200 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| すべての検索データベースを備えたデータベース サーバー。 | C、D | 100 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
2SharePoint Server 2013 では、500 GB のストレージ、16 GB の RAM、4 つの CPU コアが必要な最小リソース量が必要です。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、および 4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
中規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| 分析コンポーネントとコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | E、F | 300 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| クロール、検索管理、およびコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | E、F | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| すべての検索データベースを備えたデータベース サーバー。 | G、H | 400 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
2SharePoint Server 2013 では、500 GB のストレージ、16 GB の RAM、4 つの CPU コアが必要な最小リソース量が必要です。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、および 4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
大規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D、E、G、H | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A、B、C、D、E、F、G、H、I、J | 500 GB2,3 | 32 GB2,3 | 1.8 GHz 8x CPU コア2,3 | 1 Gbps |
| 分析コンポーネントとコンテンツ処理コンポーネントを備えたアプリケーション サーバー。 | K、L、M、N | 300 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| クロール コンポーネントと検索管理コンポーネントを備えたアプリケーション サーバー。 | K、L | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 検索データベースを備えたデータベース サーバー。 | O、P、Q、R | 500 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
2SharePoint Server 2013 では、必要なリソースの最小量は 500 GB RAM、16 GB RAM、および 4 つの CPU コアです。
3SharePoint Server 2016 では、250 GB のストレージ、16 GB RAM、および 4 つの CPU コアを使用することもできますが、各インデックス コンポーネントは 1,000 万個のアイテムのみを保持でき、検索ファームは SharePoint Server 2013 検索ファームと同じ量のコンテンツのみをサポートします。
超大規模検索ファーム用の最低限のハードウェア リソース
各アプリケーション サーバーまたはデータベース サーバーに必要なハードウェア リソースの最小量を次の表に示します。 このサンプル ファームは、SharePoint Server 2016 でのみ構築できます。
| サーバー | 稼働するホスト | ストレージ | RAM | プロセッサ1 | ネットワークの帯域幅 |
|---|---|---|---|---|---|
| インデックス コンポーネントを備えたアプリケーション サーバー。 | A-X | 500 GB | 32 GB | 1.8 GHz 8x CPU コア | 1 Gbps |
| クエリ処理コンポーネントとインデックス コンポーネントを備えたアプリケーション サーバー。 | Y、Z | 500 GB | 32 GB | 1.8 GHz 8x CPU コア | 1 Gbps |
| クロール、検索管理、またはコンテンツ処理コンポーネントを備えたアプリケーション サーバー | AA-AF | 100 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 分析処理コンポーネントを備えたアプリケーション サーバー | AG、AH | 800 GB | 8 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
| 検索データベースを備えたデータベース サーバー | AI-AL | 500 GB | 16 GB | 1.8 GHz 4x CPU コア | 1 Gbps |
1 ここで指定しているのは、CPU スレッドの数ではなく、CPU コアの数です。
ストレージ パフォーマンスの計画
ストレージの速度は検索のパフォーマンスに影響します。 ご使用のストレージが、検索コンポーネントおよびデータベースからのトラフィックを処理するのに十分な速度であることを確認してください。 ディスク速度は、IOPS (1 秒あたりの I/O 操作数) で測定されます。
検索コンポーネントおよびストレージのオペレーティング システムからデータをどのように分散するかによって、検索パフォーマンスに影響が出ます。 以下のようにすることをお勧めします。
Windows Server オペレーティング システム ファイル、SharePoint Server プログラム ファイル、診断ログを、通常のパフォーマンスで 3 つの個別のストレージ ボリュームまたはパーティションに分割します。
検索コンポーネントのデータを別個のストレージ ボリュームまたはパーティションに保存します。 インデックス コンポーネントの場合、このストレージには高いパフォーマンスも必要となります。
注:
SharePoint Server をホストにインストールするときに、検索コンポーネント データのカスタムの場所を設定できます。 ホスト上の検索コンポーネントは、データを保存する必要がある場合、この場所に保存します。 この場所を後で変更するには、SharePoint Server を再インストールする必要があります。
ストレージの種類を選択する
ストレージのアーキテクチャおよびディスクの種類についての概要は、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2013)」をご覧ください。 インデックス コンポーネント、分析処理コンポーネント、および検索管理コンポーネント、または検索データベースをホストするサーバーでは、十分な IOPS (1 秒あたりの I/O 操作数) を確保しながら短い待機時間を維持できるストレージが必要とされます。 以下の表は、これらの検索コンポーネントおよびデータベースの各々で必要とされる IOPS 数を示しています。
SAN/NAS などの共有ストレージを展開する場合、通常 1 つの検索コンポーネントのピーク ディスク負荷が別の検索コンポーネントのピーク ディスク負荷と同時に発生します。 共有ストレージから検索が必要とする IOPS 数を取得するには、これらのコンポーネントそれぞれの IOPS 要件をまとめる必要があります。
検索コンポーネントの IOPS 要件
| コンポーネント名 | コンポーネントの詳細 | IOPS 要件 | 別々のストレージ ボリューム/パーティションの使用 |
|---|---|---|---|
| インデックス コンポーネント | インデックスの結合時およびクエリの処理および応答時にストレージを使用します。 | 64 KB のランダム読み取りに 300 IOPS。 256 KB のランダム書き込みに 100 IOPS。 順次読み取りに 200 MB/s。 順次書き込みに 200 MB/s。 |
はい |
| 分析コンポーネント | データをローカルで一括処理で分析します。 | いいえ | はい |
| クロール コンポーネント | ダウンロードされたコンテンツをコンテンツ処理コンポーネントに送信する前にローカルに保存します。 ストレージはネットワーク帯域幅に制限されます。 | いいえ | はい |
検索データベースの IOPS 要件
| データベース名 | IOPS 要件 | I/O サブシステムでの一般的な負荷。 |
|---|---|---|
| クロール データベース | 中～高レベルの IOPS | 1 DPS (1 秒あたりのドキュメント) クロール レートあたり 10 IOPS |
| リンク データベース | 中速度の IOPS | 検索インデックスにおいて 100 万アイテムにつき 10 IOPS。 |
| 検索管理データベース | 低速度の IOPS | なし。 |
| 分析レポート データベース | 中速度の IOPS | なし。 |
検索アーキテクチャがどのように高可用性をサポートするかを選択する
高可用性の戦略について理解できていない場合には、はじめに「SharePoint Server の高可用性のアーキテクチャと戦略を作成する」の記事をお読みください。 冗長検索コンポーネントとデータベースを別々の障害ドメインでホストしている場合、ファームの一部で機能が停止しても、サービス全体が使用不可になることはありません。 ただし、検索コンポーネントが負荷を共有できなくなるために、検索のパフォーマンスは低下します。 1 台のサーバーを失う可能性を減らすには、ローカルの冗長性を向上することをお勧めします。 検索アーキテクチャ内のホスト サーバーごとに、以下を行ってください。
各サーバー上で RAID ストレージを使用する。
各サーバー上に複数の冗長ネットワーク接続をインストールする。
専用配線を持つ複数の冗長電源装置をインストールするか、各サーバーに無停電電源装置 (UPS) をインストールする。
すべてのサンプルの検索アーキテクチャは、個別のサーバー上で冗長検索コンポーネントをホストしています。 サンプルの検索アーキテクチャでは、各ホスト ペアの右側のホストが冗長です。 次の図は、冗長ホストの概要が示された大規模な検索アーキテクチャです。
