Office SharePoint Server の検索のベスト プラクティス
この記事は、Microsoft Office SharePoint Server 2007 のベスト プラクティスの記事の 1 つです。エンタープライズ検索のベスト プラクティスについて説明します。別途記載のない限り、この記事は Office SharePoint Server 2007 および Microsoft Search Server 2008 の両方に適用されます。他の記事については、「ベスト プラクティス」を参照してください。Office SharePoint Server 2007 のベスト プラクティスに関するその他の情報や資料については、「Best Practices Resource Center (英語)」(https://go.microsoft.com/fwlink/?linkid=125981&clcid=0x411) を参照してください。
1. 展開を計画する
検索性を計画する。検索技術をエンドユーザーにとって役立つようにするには、探しているものを最小限の手間で見つけられることが必要です。検索性の詳しい説明については、『Microsoft Office SharePoint Server 2007 Best Practices (英語)』 (Ben Curry、Bill English 著) (Microsoft Press、Redmond、WA、2008) の「Chapter 15: Implementing an Optimal Search and Findability Topology」を参照してください。
管理プロパティを使用する。検索管理者はこの機能を使用して、関連するプロパティの 1 対多のマッピングを作成できます。このプロセスにより、ユーザーが詳細なクエリを実行するときに使用する必要があるプロパティ名の数が減ります。たとえば、検索管理者が "author" という名前のプロパティを "writer" プロパティと "author2" プロパティにマップすると、クエリに "author" プロパティを含めたユーザーは "writer" と "author2" に関する検索結果も得ることになります。管理プロパティの詳細については、「エンド ユーザーの検索操作性を計画する (Office SharePoint Server)」および「Plan the end-user search experience (Search Server 2008)」を参照してください。
サービス レベル契約を作成する。展開の前に、コンテンツ クロールのサービス レベル契約 (SLA) が合意されていることを確認します。
2. 適切な構成のインフラストラクチャを使用して開始する
可用性を高めるために 2 つ以上のクエリ サーバーを展開します。複数のクエリ サーバーを使用すると、エンドユーザー クエリのための冗長性が実現します。1 つのクエリ サーバーで障害が発生しても、クエリは自動的に正常なクエリ サーバーに送られます。詳細については、「冗長性を計画する (Office SharePoint Server)」およびブログ「Microsoft Enterprise Search Blog」の投稿「SearchBeta Hardware Configuration (英語)」(https://go.microsoft.com/fwlink/?linkid=126330&clcid=0x411) を参照してください。
コンテンツ データベースと共有サービス プロバイダ (SSP) の SQL Server を実行するために別のコンピュータを使用します。その他のデータベースの推奨事項については、「物理ストレージに関する推奨事項 (Office SharePoint Server)」を参照してください。
ファイル グループを使用して、検索データベースのクエリ テーブルとクロール テーブルを分けます。
ファーム内の接続にギガビット ネットワークを使用します。詳細については、「パフォーマンスと容量の計画に影響を与えるその他の要因 (Office SharePoint Server)」を参照してください。
3. Windows セキュリティ グループを使用してアクセスを管理する
次に示す理由から、ユーザーを SharePoint グループに追加する代わり Windows セキュリティ グループに追加することをお勧めします。
Windows セキュリティ グループの変更は、SharePoint サイトのアクセス制御エントリ (ACE) に直接影響しないため、Windows セキュリティ グループ内のユーザー アカウントが変更されても、再クロールする必要がありません。
インデックス プロセスでは、SharePoint グループそのものの ACE ではなく SharePoint グループに追加された各ユーザーの ACE が格納されます。このプロセスにより、1 つのアクセス制御リスト (ACL) につき約 1,000 名のユーザーがサポートされますが、その後 [パラメータが正しくありません] というエラーによってクロールが失敗します。
4. 検索データベースをデフラグする
検索データベースにはクロール対象コンテンツのメタデータと ACL が含まれます。クロールを繰り返すうちに、検索データベースの断片化が進むことがあります。クロールとクエリのパフォーマンスを向上させるには、定期的に検索データベースをデフラグします。詳細については、「ホワイト ペーパー : Microsoft® SharePoint® 製品とテクノロジのデータベース メンテナンス」を参照してください。
重要
SQL Server を実行するコンピュータをミラー化している場合は、検索データベースをデフラグする前にミラー化を停止し、デフラグが終了してから再開します。
5. システムを常に最新状態に保つ
テスト環境で更新プログラムをテストしてから、Office SharePoint Server 2007、Search Server 2008、および SQL Server の最新のソフトウェア更新プログラムをできるだけ早くインストールします。ソフトウェア更新プログラムの展開方法に関する一般的なガイドラインについては、「Office SharePoint Server 2007 のソフトウェア更新プログラムを展開する」を参照してください。
6. SQL Server の待機時間を監視する
検索は、SQL Server の I/O が集中的に発生する処理であり、一時データベースと検索データベースの I/O 待機時間の影響を強く受けます。検索とコンテンツのホストでは、どちらも一時データベースが重点的に使用されます。検索データベース、SSP データベース、一時データベース、コンテンツ データベース、およびそれらに対応するログ ファイルはすべて別のスピンドルに置くことをお勧めします。そうすることにより、各ファイルを固有のニーズに基づいて最適化することができます。非常に規模が大きいサーバー ファームでは、SQL Server を実行する別のコンピュータにコンテンツ データベースを置くことも適切です。この方法では、コンテンツ データベースとは別の一時データベースと SQL Server インスタンスが検索データベースと SSP データベースに提供されます。検索で最高のパフォーマンスを得るために、次の待機時間を維持することをお勧めします。
一時データベース: 10 ミリ秒 (ms) 以内
検索データベース: 10 ms 以内
データベース ログ ファイル: 20 ms 以内
ブログ「Microsoft Enterprise Search Blog」の投稿「SQL Monitoring and I/O (英語)」(https://go.microsoft.com/fwlink/?linkid=123950&clcid=0x411) にあるその他の推奨事項に従います。SQL Server のパフォーマンスの問題をトラブルシューティングする方法については、SQL Server 技術解説記事「Troubleshooting Performance Problems in SQL Server 2005 (英語)」(https://go.microsoft.com/fwlink/?linkid=123952&clcid=0x411) の「I/O Bottlenecks」セクションを参照してください。
7. 検索中止を防ぐために監視する
検索中止が発生するのは、クローラがクロール キューの次のドキュメントを取り出すために別のスレッドを割り当てられないときです。中止の原因は次のとおりです。
SQL Server を実行しているコンピュータでのリソース (I/O) の競合。
同時にクロールされるホストが多すぎる。
スレッドをすぐに解放しないハングリ ホスト。ハングリ ホストには次のようなホストが含まれます。
遅いホスト。クロールされているホストには、クローラが送るすべての要求を処理するための能力がありません。
増分クロールのために追加処理が必要なホスト。基本の HTTP クロールもドキュメントごとにサーバーへの往復が必要なため、部分的にこのカテゴリに含まれますが、基本の HTTP クロールでは変更日付が確認されてからドキュメントがダウンロードされます。
プロパティがリッチなホストとコンテンツ。コンテンツ格納タイプがビジネス データ カタログ、ユーザー インポート、ユーザー クロールで多く見られます。
バックアップの実行中にはクロールが一時停止される。
詳細については、ブログ「Microsoft Enterprise Search Blog」の投稿「Creating crawl schedules and starvation - How to detect it and minimize it (英語)」(https://go.microsoft.com/fwlink/?linkid=123794&clcid=0x411) を参照してください。
8. システムを監視してクエリのボトルネックを理解する
9. 各クロール対象サイトの検索表示設定を検証する
検索エンジンのためにサイトやページを最適化するための標準的なベスト プラクティスは、SharePoint 展開の Web コンテンツ管理 (WCM) サイトにも同じく作用します。検索エンジンに対して適切に最適化されたサイトまたはページは、検索結果の上位に表示され、サイトへのトラフィックの増加を促進します。詳細については、「How to Optimize SharePoint Server 2007 Web Content Management Sites for Search Engines (英語)」(https://go.microsoft.com/fwlink/?linkid=123956&clcid=0x411) を参照してください。
10. クエリ サーバーの初期化またはファームのバックアップの前にクロールを手動で一時停止する
検索に使用する SSP のバックアップまたはクエリ サーバーの初期化の前に、すべてのクロールを一時停止することをお勧めします。バックアップが終了したら、一時停止したクロールを手動で再開する必要があります。詳細については、「クロールの一時停止と再開 (Office SharePoint Server 2007)」を参照してください。
11. 構成を変更した後でクロール サブシステムおよびクエリ サブシステムをテストする
構成を変更した後には、サーバー ファームのクロールおよびクエリの機能をテストすることをお勧めします。テストの簡単な方法は、この目的専用の一時的なコンテンツ ソースを作成することです。テストに際しては、10 項目 (たとえばファイル共有の .txt ファイル) をクロールしてから、それらについて検索クエリを実行することをお勧めします。それらの項目が現時点でインデックスに含まれないことを確認します。クエリを実行したときに検索結果ページの上部に表示される特殊な語がそれらの項目に含まれていると役立ちます。テストが終了したら、テストのために作成したコンテンツ ソースを削除してください。これは、クロールした項目をインデックスから削除するためです。こうすることで、このテストを実行する必要が生じた場合には、再びそれらの項目をクロールすることができ、テストを終了するまでは検索結果に表示されなくなります。コンテンツのクロールの詳細については、「コンテンツをクロールする (Office SharePoint Server 2007)」または「How to crawl content (Search Server 2008)」を参照してください。
12. クロール対象オブジェクトのウイルス対策ポリシーを確認する
Windows SharePoint Services 3.0、Office SharePoint Server 2007、または でファイルレベルのウイルス対策ソフトウェア プログラムを使用している場合、スキャンの対象から特定のフォルダを除外する必要があります。それらのフォルダを除外しないと、予期しない問題が数多く発生することがあります。詳細については、マイクロソフト サポート技術情報の記事「952167: Folders may have to be excluded from antivirus scanning when you use a file-level antivirus program in Windows SharePoint Services 3.0 or in SharePoint Server 2007 (英語)」(https://go.microsoft.com/fwlink/?linkid=123963&clcid=0x411) を参照してください。
13. カスタム クエリがある場合は、クロールされたプロパティの UI で適切なプロパティを "scope-able" とマークし、コストの高い SQL クエリを実行しないようにする
謝辞
Office SharePoint Server 2007 Content Publishing チームは、この記事に投稿していただいた以下の方々に感謝します。
Luca Bandinelli、Microsoft SharePoint Customer Advisory Team
Dan Blood、Microsoft Search Server
Sid Shah、Microsoft Search Server
Richard Riley、Microsoft SharePoint Marketing
Mitch Prince、Microsoft Consulting Services
Larry Kuhn、Microsoft Consulting Services