Enterprise Search の展開とサポート
SharePoint Server 2007 による業務支援: Microsoft における情報と人の検索
テクニカルホワイトペーパー
発行 : 2007 年 7 月 19 日
トピック
エグゼクティブ サマリ
はじめに
関連組織
SharePoint Portal Server 2003 を使用した以前のエンタープライズ検索サービス
共有サービスのアーキテクチャ
エンタープライズ共有検索サービスの管理
インデックス付けされたサイトとコンテンツの管理
エンタープライズ検索サービスのユーザー エクスペリエンス
Office SharePoint Server 2007 への移行
ベスト プラクティス
結論
連絡先
エグゼクティブ サマリ
Microsoft では、120,000 名を超える社員や契約社員が仕事をしています。これらの従業員は Microsoft® Office ドキュメント、画像、ビデオ、Web ページなどのさまざまな形式で、途方もない量のデジタル情報を作成し、作成された情報は Microsoft ネットワークをとおしてサーバー上に格納されます。多くの場合、従業員は自分が保管場所を知っているドキュメントやファイルのみを資料を使用して、仕事を遂行します。
たとえば、Office ユーザー アシスタンス チームに所属している従業員が、Microsoft Office Word 用のユーザー ドキュメントを作成します。時を同じくして別の従業員が特定の業種を対象としたマーケティング キャンペーン用にマーケティング資料を作成し、この中に Office Word に関する資料が含まれるとします。キャンペーンを実施する従業員が、別の従業員が作成したユーザー ドキュメントの存在を知らないでいると、このドキュメントは十分に活用されないことになります。エンタープライズ検索を使用すると、他の従業員の知識や情報を探し出して活用できるようになります。このように、エンタープライズ検索はうもれている情報を探しだして活用することでビジネス価値をもたらします。Microsoft の企業規模と、製品開発、マーケティング、運用、営業、および管理など職務の多様性を考慮すると、関連情報の量は圧倒的な量になります。
ファイルや情報は、Exchange Server 2007 データ ストア、ファイル共有、データベース、およびローカルのハード ディスク ドライブの内部コンテンツ ソース (ドキュメント ライブラリやイントラネット Web サイトなど) に格納されます。現状をさらに難しいものにしているのは、従業員が新しい種類のコンテンツを追加するということです。しかも、この操作は日々、継続的に行われます。
このような状況では、Microsoft が所有している最新の情報をどのように確認し、クロールするかということが問題になります。そして、さまざまなユーザーに対して有用な方法で、将来的にどのように最新のコンテンツやコンテンツの種類を反映したインデックスを維持していくか、ということが課題になります。当然ながら、エンタープライズ検索にとってインデックスが最新のものであることが必要不可欠であるということと同時に、セキュリティを維持することも必須です。
これを解決するためのソリューションが、Microsoft Office SharePoint® Server 2007 で提供される Enterprise Search です。検索機能では高速検索とインデックス サービスの機能が新たに強化されています。高速検索は Office 2003 のインデックス サービスを作り直したもので、コンピュータのハード ディスク上にあるプロジェクトや SharePoint Web フォルダで利用できる Office ファイルのデータベース カタログを作成します。
Microsoft は、Microsoft Windows 2000 の Index Server テクノロジを基にインデックス サービスを構築し、検索用に従来よりも優れたカタログを作成して、Office ファイルに含まれる情報の検索機能を提供します。
Enterprise Search を使用すると、従業員同士の共同作業が容易になり、作業の重複を削減できます。また、より効率的に職務を遂行し、従来よりも仕事の内容を深めることが可能です。Enterprise Search を利用する従業員は、日常的な職務遂行に必要な人、情報、ツール、およびソフトウェアを、今までよりも簡単に見つけることができます。従業員の生産性は向上し、その質も高まります。作業を完了するために他の従業員に頼ることもありません。
Office SharePoint Server 2007 では、柔軟で革新的なインデックス ルールを使用して関連データを検索できます。これにより、Microsoft の従業員は目的とする人や情報を正確に見つけることができます。さらに、Office SharePoint Server 2007 ではパフォーマンスが改善されたため、以前よりも高速に検索操作を実行できるようになりました。
このホワイト ペーパーでは、次の内容について説明します。
ソリューションの開発、展開、継続的な管理に関与した Microsoft チーム
Microsoft における Enterprise Search の背景情報
Enterprise Search ソリューションの展開によってもたらされるビジネス価値
ソリューションのアーキテクチャ設計
ソリューション構築に使用する製品およびテクノロジ
ソリューションとしての共有検索サービスの管理
ソリューションでインデックス付けされたサイトとコンテンツの管理
Enterprise Search ソリューションを使用するときのユーザー エクスペリエンス
Microsoft Office SharePoint Portal Server 2003 から Office SharePoint Server 2007 への Enterprise Search の移行
ソリューションの開発と展開において Microsoft が採用したベスト プラクティス
このドキュメントを通じて、Microsoft の Enterprise Search 展開作業で Microsoft チームが行った情報を共有します。Microsoft チームが得た情報はかなりの量であるため、ここでは、Enterprise Search の展開によって従業員の生産性向上、仕事の質の向上、作業の重複の削減、デジタル情報資産への財政投資利用の実現を目指す組織に対して、それに関連するガイダンスを提供します。
このホワイト ペーパーは、SharePoint Portal Server 2003、Office SharePoint Server 2007、および Microsoft SQL Server™ 2005 に関して既に詳しい知識を持っている、技術上の意思決定者を対象としています。ここで紹介する原則や技法の多くは、組織内での展開や運用に関する危機管理に採用できます。また、エンタープライズ検索の設計上の検討事項は、Microsoft 製品を使用した IT 環境に対して、その規模を問わず、同様に適用可能です。ただし、このホワイト ペーパーは、初期の導入者である Microsoft Information Technology (Microsoft IT) の経験と推奨事項に基づいています。また、手順を示すガイドとして利用できるようには記述されていません。企業の持つ環境や状況はそれぞれ異なります。したがって、このホワイト ペーパーで説明している計画や得られた教訓を各自の要件に合わせて調整する必要があります。
メモ : このホワイト ペーパー内で使用されているフォレスト、ドメイン、内部リソース、組織、および内部で開発されたセキュリティ ファイルの各サンプル名は、セキュリティの理由から、Microsoft 内部で実際に使用されているリソース名ではなく、例示するためだけのものです。
はじめに
エンタープライズ検索は、10 年以上にわたって Microsoft イントラネット上でなんらかの形でサービスを提供してきました。SharePoint Portal Server 2003 のリリースと共に、Microsoft におけるエンタープライズ検索の展望に変化が生じてきました。SharePoint Portal Server 2003 は、Microsoft イントラネットで情報を検索するための全体論的なアプローチと、サービスの一元管理による統合型の検索サービスを提供してきました。これが、現在のソリューションの基礎となっています。
このホワイト ペーパーでは SharePoint テクノロジの Enterprise Search 機能を中心に説明しますが、Microsoft では SharePoint の他の共同作業機能 (ドキュメント ライブラリに始まり、リスト、ブログ、Wiki に至るまでのさまざまな機能) も頻繁に使用しています。この 10 年間で共同作業の多様化が進み、Microsoft がクロールするコンテンツの量も急激に増加しています。
共有サービス プロバイダ
Office SharePoint Server 2007 のアーキテクチャは、共有サービス プロバイダ (SSP) に基づいています。SSP は一連のサービスを表すもので、構成は一度に行うことができ、さまざまな Office SharePoint Server 2007 ポータル サイトや Windows SharePoint Services サイトで共有することができます。SSP の機能により、共有サービスや関連する共有リソースのグループを作成します。作成したグループは、中央の管理コンソール上で管理が可能です。管理者は、ファーム内で複数のイントラネット サイトを利用できるように SSP を作成し、構成します。管理者はファーム内の各 Web アプリケーションを SSP に割り当てます。1 つのファームに複数の SSP を作成できますが、各 Web アプリケーションやサイトは 1 つの SSP にしか関連付けることができません。
Microsoft IT では、ワシントン州レドモンド、ダブリン、およびシンガポールにエンタープライズ共有サービスを提供するデータ センターを設置しています。SSP 機能を使用すると、Microsoft IT は 3 つの地域での主要なデータ センターにおける検索サービスの管理を簡素化できます。SSP の管理は 3 名の常勤の社員が専任しています。
レドモンドにある SSP は Microsoft イントラネット上にある世界中のコンテンツをクロールします。この SSP に接続するサイトでは検索範囲を指定して、世界中のコンテンツから結果を得ることができます。ダブリンとシンガポールにある SSP では、各地域にあるコンテンツのインデックスを作成し、欧州、中東、アフリカ (EMEA) 地域、アジア地域のそれぞれの地域で Web アプリケーションに対して検索サービスを提供します。
図 1 は、Microsoft におけるエンタープライズ共有検索サービスの展開図です。
.gif "図 1 Microsoft におけるエンタープライズ共有検索サービス")
図 1 Microsoft におけるエンタープライズ共有検索サービス
3 か所に配置されたデータ センターは、Microsoft で世界中に展開した SharePoint サービスとインフラストラクチャをサポートします。世界中に展開されている SharePoint サービスとインフラストラクチャについての現時点での情報は、次のとおりです。
350,000 を超えるサイトおよびサブサイト
400 を超える地域
おおよそ 13 TB のコンテンツ (SharePoint 展開に格納されている情報量、ホスト担当は Microsoft IT)
Microsoft では、大部分のエンタープライズ組織とは異なり、すべての SharePoint サイトを Microsoft IT で管理することを要件としていません。従業員は、いつでも、独自の SharePoint サイトを作成できます。このような環境であっても、SSP によって該当サイトのコンテンツのインデックスが作成されます。表 1 を使用して、レドモンドに配置されている現在のエンタープライズ検索サービスの特徴を説明します。
表 1 エンタープライズ検索サービスの特徴 ( レドモンド )
特徴 |
説明 |
|---|---|
コンテンツのインデックス付け |
|
ユーザー プロファイル |
|
統合 |
|
データベースとインデックスのサイズ |
|
クエリ回数 |
|
注 : 表 1 に示したデータベースとインデックスのサイズは、Microsoft がインデックス付けしたコンテンツの種類と量を反映したものです (13 TB の SharePoint コンテンツを含みます)。その他の環境でサイズを推定する方法の詳細については、「Search 環境でのパフォーマンス要件とキャパシティ要件の見積 (https://technet.microsoft.com/library/cc262574.aspx) 」を参照してください。
エンタープライズ共有検索サービスを使用するサイト
Microsoft の従業員は、日常的に、エンタープライズ検索サービスが組み込まれているサイトを使用します。表 2 に、エンタープライズ共有検索サービスを使用している Microsoft イントラネット上のサイト一覧と各サイトについての説明も記載します。
表 2 エンタープライズ共有検索サービスを使用するサイト
サイト |
説明 |
|---|---|
MSW |
Microsoft の主要なイントラネット ポータル サイトです。従業員は、Microsoft での自分の雇用や職務に関連する情報を探すときに、このサイトから検索を開始します。 一般に、このサイトは次のような情報を検索するときに使用されます。
|
部門レベルまたは支社レベルのポータル |
たとえば、次のようなものがあります。
|
チーム サイト |
ITWeb サイトのサインアップ ページを介して自分で提供するサイトです (数千もの数に上ります)。 |
個人用サイト |
各従業員が利用できる個人用のサイトです。 |
表 2 に示したサイトは、それぞれ、エンタープライズ検索サービスの共通のインフラストラクチャを使用します。エンタープライズ共有検索サービスの展開によって Microsoft が認識したメリットは、次のとおりです。
検索機能と検索結果における一貫性の向上
エンタープライズ検索の可用性の向上
エンタープライズ検索の管理およびサポートに対する作業負荷の軽減
複数のシステムを使用した冗長なクロールの削減
関連組織
Microsoft でのエンタープライズ検索サービスの展開には、Microsoft IT と Office SharePoint Server 2007 開発チームが関与しました。
Microsoft IT
Microsoft IT は、できる限り多くのフィードバックを製品開発グループに提供することを最優先の職務としています。このため、Microsoft IT は他の IT 組織とは異なる存在であると言えます。Microsoft IT がこの職務を最優先事項とすることで、顧客の手元に Microsoft 製品を届ける前に、エンタープライズ規模の運用環境で徹底的に製品をテストすることが確保されます。たとえば、運用上の観点から、Microsoft IT は他の組織が行うよりも長時間にわたってサーバーをオフライン状態にしておくことがあります。こうすることで、製品開発グループが Microsoft 製品を改良するのに役立つ貴重なデータを提供します。
Microsoft IT の第 2 の優先事項は、従業員に対して優れたサービス レベルを提供することです。エンタープライズ検索では Microsoft IT はサービスを使用するさまざまな人々のビジネス要件と技術要件について、その基準を満たすか、期待以上のサービスを提供する必要があります。
チームの第 3 の優先事項は、Microsoft 製品を使用する顧客とベスト プラクティス情報を共有することです。Microsoft IT は製品リリース前にソフトウェアを実行するため、そこで得た知識を (このホワイト ペーパーやその他のドキュメントのように) 顧客に提供することができます。
Microsoft IT は Microsoft におけるエンタープライズ共有サービスの設計、開発、展開、および運用に責任を持って取り組みます。Microsoft IT は次のようなグループで構成されています。各グループにはエンタープライズ検索の管理において特定の責任があります。
Information Services チーム
Operations チーム
Engineering チーム
Information Services チーム
Information Services チームは、ソリューションの開発、テスト、およびドキュメント作成に加え、共有サービスのビジネス要件と管理を担当します。表 3 に Information Services チームの構成チームと、各チームの責任範囲の一覧を示します。
表 3 Information Services チームの説明と責任範囲
チーム |
説明と責任範囲 |
|---|---|
プログラム マネジメント |
このチームは、共有サービスのビジネス上の所有権を提供します。また、新たなテクノロジや機能のビジネス要件、ルール、エンド ユーザー エクスペリエンス、および展開にも責任を持って取り組みます。責任範囲には、製品開発グループへの連絡、テスト プロセス管理、予算管理、プロジェクト管理報告の提供も含まれます。さらに、第 2 層のサポートを提供し、共有検索サービスを使用するサイトの管理者に対するコンサルタントとしての役割も果たします。 このチームは、次のメンバで構成されます。
|
ソリューションの計画 - 開発とテスト |
このチームは、主として主要な企業ポータルにサービスを提供する、共有リソースです。ただし、他のチームに助言したり、イントラネット上で再利用可能なソリューションを構築したりすることも行います。このチームは移行期間中にエンタープライズ検索に関連する特定のプロジェクトで作業しますが、展開面での他の仕事にも取り組みます。 12 名で構成され、次のことを担当します。
|
Operations チーム
Operations チームは、共有サービス、顧客ポータル、およびコンテンツ ホスティングをサポートする共有リソースです。このチームは、サーバーのインフラストラクチャ、インシデント管理、エンド ユーザーのテクニカル サポート、ヘルプデスク トレーニング、監視、アップグレード、修正プログラム管理、hotfix 管理、バックアップおよび復元サービスの維持管理を担当します。チームには 1 名の常勤社員が配置され、主に 3 つの地域にある SSP における構成変更の監視に責任を持って取り組みます。
Engineering チーム
Engineering チームは、新規展開やインフラストラクチャ変更の設計、テスト、ドキュメントやガイダンスの発行を担当する共有リソースです。責任範囲には、Operations チームに対する、ガイダンス、運用、および構成について詳述したドキュメントの提供が含まれます。
Office SharePoint Server 2007 開発チーム
Office SharePoint Server 2007 開発チームは Microsoft IT への機能や構成の設定に関するガイダンスを提供します。Microsoft IT は Microsoft 運用環境での Office SharePoint Server 2007 の使用に関するフィードバックや、エンド ユーザー エクスペリエンスでのフィードバックを提供します。Microsoft IT が提供するフィードバックの大部分は、最終的に製品の新機能や機能強化として組み込まれます。
SharePoint Portal Server 2003 を使用した以前のエンタープライズ検索サービス
SharePoint Portal Server 2003 のエンタープライズ検索サービスは、図 1 に示すように展開されていました。現在のソリューションと同様に、レドモンドのデータ センターでは Microsoft イントラネット上にある世界中のソースからのコンテンツにインデックスを作成していました。ダブリンとシンガポールにあるデータ センターでは、EMEA 地域とアジア地域ごとにコンテンツのインデックスを作成し、各地域のコンテンツについて検索サービスを提供していました。
SharePoint Portal Server 2003 ベースのソリューションで (以前のソリューションに対する) 改良が加えられましたが、SharePoint ベースのサイトにおける Microsoft 社内の共同作業が拡散するという結果に至りました。大部分の従業員が従来のファイル共有を切り替えるために新たなサイトを作成し、仮想現実的なソーシャル コンピューティング手法を使用して共同作業を行うようになりました。以前の SharePoint Portal Server 2003 ベースのソリューションに対応するレドモンドのサーバー インフラストラクチャには、次に挙げるサーバーが実装されていました。
さまざまな Web フロントエンド サーバー。上位レベルのポータルには、スケーラビリティ要件に応じた数のサーバーが配置されていました。
2 台のクエリ サーバー。各サーバーには、デュアル プロセッサと 4 GB のメモリが搭載されていました。
3 台のインデックス サーバー。各サーバーには、デュアル プロセッサと 3 GB のメモリが搭載されていました。
2 台のデータベース サーバー。アクティブ/パッシブ クラスタ構成で Microsoft SQL Server 2000 を実行していました。
SharePoint Portal Server 2003 に改良が加えられたにもかかわらず、Microsoft 社ほどの規模のある組織でのサービス管理には依然として課題が残っていました。特に、クロールのパフォーマンスと複数のインデックスに関する問題が挙げられます。インデックスが大規模であるため、クロール完了までに最長で 2 週間を要することがありました。クロールが完了してインデックスがクエリ サーバーに反映されるまで、コンテンツは結果に表示されませんでした。また、すべてのコンテンツを対象にエンタープライズ検索機能を提供することにも課題が残っていました。なぜなら、サイズにばらつきのある複数のインデックスのクエリを実行している間に、妥当性がゆがめられてしまうことがあったからです。
Microsoft IT は、SharePoint Portal Server 2003 ベースのエンタープライズ検索ソリューションに関するユーザー調査を実施しました。調査は、ユーザーが満足していることと不満を抱いていることの特定に役立ちました。ソリューションのサポートにおいて Microsoft IT が得た運用上の経験と Microsoft IT が直面した課題に、この情報が加わりました。
SharePoint 開発チームが SharePoint の次リリースを計画しているときに、Microsoft IT は開発チームと連携して次の作業を行いました。
ユーザーの満足度を高めるための新機能を見極める。
運用およびサポートにかかるコストをさらに軽減できるように、一般的な管理作業の効率性を高める。
実際の運用環境でコードの改良内容をテストする。
ユーザー インターフェイスのデザインを検証する。
検索機能に関する従業員のフィードバックを集める。
SharePoint Portal Server 2003 のリリース後、SharePoint 開発チームは次のことを実現するための方法を決定しました。
インデックス付けするアイテムの数を増加させる。
同量のコンテンツにインデックス付けする時間を短縮する。
検索結果を返すまでの応答時間を短縮する。
共有サービスのアーキテクチャ
Microsoft は数多くの製品やサービス (Microsoft Exchange Server 2007、Active Directory、ファイル サービス、プリント サービス、SharePoint ベースの共有サービスなど) に対して、一元管理による共有サービスを提供しています。大部分の組織と同様に、Microsoft でも支社レベルのサービスからデータ センターでの中央管理サービスへの転換を図っています。
Office SharePoint Server 2007 では、SharePoint Portal Server 2003 で提供していた共有サービスの数多くの機能が強化されました。Office SharePoint Server 2007 は組織が共有型のコラボレーション サービスとエンタープライズ検索サービスを提供できるように、特別に設計されています。
Microsoft 社内で提供される共有サービス
Microsoft IT は、Microsoft 社内で多数の共有サービスを管理し、運用しています。これらのサービスは、Microsoft IT がホストする中央管理型の Web ファームに接続されているすべての SharePoint サイトをサポートします。
エンタープライズ検索サービスは Microsoft 社内で提供される主要なサービスであり、このホワイト ペーパーでもこのサービスに重点を置いて説明しています。これは、Microsoft 共有サービスでホストされている SharePoint Web サイト (MSW、InfoWeb、個人用サイト、および Microsoft イントラネット上にあるその他のサイト) 向けの検索サービスです。
エンタープライズ検索サービスとやり取りを行うその他の共有サービスには、次のようなものがあります。
Active Directory からの情報のインポート : Active Directory は、従業員に関する大部分の情報を扱う中央管理型のリポジトリです。この情報を Office SharePoint Server 2007 にインポートして、共有サービスやユーザー検索でホストされる SharePoint サイトで使用できます。
ユーザープロファイル情報の同期化 : Microsoft はユーザー提供のプロファイル データを地域間で複製するためのカスタム コードを開発しました。ユーザーがプロファイルに変更を加えると、このコードによって各地域の SSP ストアが変更されます。
注 : この機能は、Office SharePoint Server 2007 の標準機能ではありませんが、Microsoft は公開されたアプリケーション プログラミング インターフェイス (API) を使用して、変更ログやプロファイル ストアの Web サービスなどのカスタム コードを開発しました。Microsoft の顧客は Microsoft サービス契約下で同じコードを使用できます。
ビジネスデータカタログを使用した基幹業務アプリケーション統合の維持管理 : ビジネス データ カタログを使用すると、エンタープライズ検索サービスは基幹業務アプリケーションの情報にインデックスを作成できます。Microsoft IT はビジネス データ カタログの構成を維持管理し、適切な情報にインデックスが作成されるようにします。
利用状況のレポートの生成 : Office SharePoint Server 2007 は、検索の利用状況のレポートを提供します。SSP レベルのレポートとローカル サイト コレクション レベルのレポートの 2 種類があります。これらのレポートにより、コンテンツ所有者やサイト管理者に対して、ユーザーがサイト上で検索する情報についてのデータが提供されます。たとえば、コンテンツ所有者に対して、該当のサイト上で最も好評な検索結果を通知できます。
共有サービスには、サイトのさまざまなカテゴリが接続されます。たとえば、次のようなサイト カテゴリがあります。
セルフサービスサイト : 個人用サイトや、従業員が自分で提供できるサイトなどが該当します。このようなサイトは多数に上りますが、一般にカスタマイズを行う必要はほとんどありません。これらのサイトを作成して使用するために、ユーザーに課金されることもありませんし、Microsoft ヘルプデスクのサポートを受けることもできます。
カスタムサイトとカスタムポータル : これらのサイトは一般にトラフィック量が多く、専任の Web 開発チームとコンテンツ管理チームが配置されています。サイトには、検索のカスタマイズ、Web パーツ、その他のサービスが必要です。Microsoft IT はこれらのサイトに対して多層化したサービス レベルを採用しています。サービス レベルは、カスタマイズやサポートのレベルが最も高いプラチナ サービスから、カスタマイズが限定的であるシルバー レベルのサポートまであります。これらのレベルには料金体系が関連付けられており、必要なカスタマイズやサービスのレベルに応じて、ホスティング、コンサルティング、およびサポート サービスへの課金が行われます。
Microsoft 社内の検索サービス
Microsoft は、ポータルやチーム サイトをホストするファームとは独立した SSP 上でエンタープライズ検索サービスを実行しています。レドモンドにある SSP は、世界中のコンテンツをクロールします。あるトピックに関する特定の情報を検索するユーザーは、その情報の格納場所には関係なく、レドモンドのデータ センターから提供される検索サービスを使用します (通常は、MSW の検索機能を使用します)。
Microsoft は、レドモンドだけでなく、他の地域にも検索サービスを展開しています。Microsoft がこのようなアプローチを採用する理由は、共有検索サービスがワイド エリア ネットワーク (WAN) リンク上ではサポートされないことにあります。さらに、ローカルな領域で検索サービスを利用できるようにすることでその地域内のユーザー向けのパフォーマンスが向上することも、理由の 1 つとして挙げられます。このアプローチにより、地域でアップロードされているコンテンツに対して、ローカル サイトでの検索を目的に、より迅速にインデックスを作成できるようになります。
地域内でコンテンツの検索を行うユーザーは、その地域のデータ センター内で地域検索サービスを使用して、検索を実行します。たとえば、フランスにいるユーザーが、フランスとスペインにある情報の中からできる限り多くの結果を得たいと考えている場合、ダブリンの地域データ センターの共有サービス プロバイダに接続されているサイト上で検索を実行します。
サーバー インフラストラクチャ (レドモンド)
レドモンドにあるサーバー インフラストラクチャは、Office SharePoint Server 2007 ベース ソリューションの SSP サービスをサポートします。MSW サーバー ファームやホストされている http://team サーバー ファームなど、より大規模なファームには Web フロントエンドとしてのコンピュータや、専用のクロール ターゲット サーバーとして使用するコンピュータがあります。"クロール ターゲット" サーバーは、サービス要求を処理する Web フロントエンド サーバーのプールから削除された Web ファームにあるサーバーであるため、インデックス サービスはユーザーへの応答時間に悪影響を及ぼすことなく、コンテンツをクロールできます。
表 4 を使用して、レドモンドに配置されている Office SharePoint Serve 2007 ベース ソリューション用のサーバー インフラストラクチャについて説明します。
表 4 Office SharePoint Server 2007 インフラストラクチャ ( レドモンド )
サーバー |
数 |
説明およびサーバー構成 |
|---|---|---|
Web フロントエンド |
不特定 |
SSP ファームとは別のサーバー ファームに属する Web サイトをホストするコンピュータ。 たとえば、MSW には Web フロントエンド サーバーとして機能するアクティブなコンピュータが 2 台あります。3 台目のコンピュータは、クロール ターゲット サーバー専用のコンピュータとして使用されます。このコンピュータは、必要に応じて、Web サーバー ファームに追加できます。 |
クエリ サーバー |
3 |
プロセッサ 2 基 (2 つのコアを内蔵した 64 ビット プロセッサ × 1 基) 8 GB のメモリ ディスク構成 :
|
インデックス サーバー |
1 |
プロセッサ 8 基 (2 つのコアを内蔵した 64 ビット プロセッサ × 4 基) 16 GB のメモリ ディスク構成 :
|
データベース サーバー |
2 |
Windows クラスタによるクラスタ化 プロセッサ 8 基 (4 つのコアを内蔵した 64 ビット プロセッサ × 2 基) 10 GB のメモリ ディスク構成 :
|
運用ファーム環境に加えて、Microsoft は準備ファーム環境の維持管理も行っています。準備ファーム環境には、クエリ サーバー (2 台)、インデックス サーバー (1 台)、データベース サーバー (1 台) が配置されています。どのサーバーも、運用環境で対応するサーバーと同様の構成を備えています。
Microsoft IT は、運用環境に移行する前に準備環境を使用して、更新プログラムの展開などの構成上の変更のテストを行っています。準備環境は、開発期間中はカスタム ポータルとしても利用できます。これにより、開発者は共有サービスへの接続テストを行って、カスタム コードを検証できます。
準備環境では、クロールは定期的にスケジュールするのではなく、Microsoft IT が必要に応じてクロールを実行しています。Microsoft IT は運用環境のバックアップを復元することで、ときどき、準備環境と運用環境との同期も行っています。
次に挙げる詳細情報については、それぞれの参考資料を参照してください。
Search 環境のパフォーマンス要件およびキャパシティ要件を見積もるには、「Search 環境でのパフォーマンス要件とキャパシティ要件の見積 (https://technet.microsoft.com/library/cc262574.aspx) (英語)」を参照してください。
検索サービスの計画については、「検索を計画する (Office SharePoint Server) (https://technet.microsoft.com/library/cc263400.aspx)」を参照してください。
サーバー インフラストラクチャ (EMEA およびアジア)
ダブリン (EMEA) およびシンガポール (アジア) 地域にある検索サービスでは、レドモンドと同様のインフラストラクチャが使用されていますが、その規模は小さくなります。表 5 を使用して、EMEA とアジアに配置されている Office SharePoint Server 2007 ベース ソリューション用のサーバー インフラストラクチャについて説明します。
表 5 Office SharePoint Server 2007 インフラストラクチャ (EMEA とアジア )
サーバー |
数 |
説明およびサーバー構成 |
|---|---|---|
Web フロントエンド |
不特定 |
SSP ファームとは別のサーバー ファームに属する Web サイトをホストするコンピュータ。 |
クエリ サーバー |
2 |
プロセッサ 2 基 (2 つのコアを内蔵した 64 ビット プロセッサ × 1 基)8 GB のメモリ ディスク構成 :
|
インデックス サーバー |
1 |
プロセッサ 32 基 (8 つのコアを内蔵した 64 ビット プロセッサ × 4 基) 8 GB のメモリ ディスク構成 :
|
データベース サーバー |
2 |
Windows クラスタによるクラスタ化 プロセッサ 8 基 (4 つのコアを内蔵した 64 ビット プロセッサ × 2 基) 10 GB のメモリ ディスク構成 :
|
エンタープライズ共有検索サービスの管理
エンタープライズ共有検索サービスの主要な利点の 1 つに、日常的な管理業務の大部分を一元的に実行できるということがあります。一元的に管理作業を実行するため、Microsoft はエンタープライズ検索サービスを維持管理して運用するための作業負荷 (およびコスト) を大幅に削減できます。その他の利点として、複数台のインデックス サーバーに起因するシステム上のネットワーク負荷を全体的に軽減できることが挙げられます。
エンタープライズ共有検索サービスの管理 (レドモンド)
Microsoft のエンタープライズ共有検索サービスの最大規模のプロバイダとして (インデックス付けされる情報量と、検索サービスを実行するサイトの数により "最大規模" と判断されます)、レドモンドにおける管理レベルは、規模や複雑度が同様である他の組織でも起こり得る状況を示します。Microsoft は、最初にレドモンドにおいて数多くの管理手順や管理プロセスを検証してから、地域のデータ センターでそれを使用します。
以降のセクションを使用して、レドモンド SSP の構成について詳細を説明します。構成設定の情報は、Microsoft IT が SSP を管理する背景情報を示すものです。
注 : Office SharePoint Server 2007 での構成設定は、以降のセクションで説明する管理レベルを実現するのに十分な柔軟性がありますが、ここに示す管理レベルがすべてのエンタープライズ シナリオに必要であるとは限りません。
コンテンツ ソースとインデックス クロールの構成
コンテンツ ソースは、インデックス作成の基礎となります。検索サービス管理の主要部分として、Microsoft IT はコンテンツ ソースの検証と改訂を定期的に実施しています。コンテンツ ソースの構成によって、実行するインデックス作成の種類 (たとえば、インデックスを完全に作成するか、増分作成するか、など) や、コンテンツのインデックス作成を行うスケジュールが決定されます。
コンテンツ ソースの維持管理
コンテンツ ソースには 1 つまたは複数の開始アドレス (URL) を指定できますが、1 つのコンテンツ ソース内の開始アドレスはそれぞれ同じ種類のコンテンツを参照します。たとえば、Web サイトをクロールするコンテンツ ソースには Web サイトの URL を多数含めることができますが、Exchange パブリック フォルダの URL を含めることはできません。
管理作業の全体的な目標は、必要なコンテンツ ソースの数を最小化することにあります。Microsoft では、コンテンツ ソースの数を 200 以上 (SharePoint Portal Server 2003 ベース ソリューション) から 25 (Office SharePoint Server 2007 ベース ソリューション) に削減しました。このような削減を行うことができたのは、主として Office SharePoint Server 2007 の新たな検索範囲機能に理由があります。この機能を使用すると、従来よりも柔軟に範囲を指定でき、従来のように特定のソース グループでコンテンツ ソースをタグ化する必要はありません。Microsoft では、コンテンツ ソースの検証を定期的かつ継続的に実施し、コンテンツ ソースを統合する方法や、既存のコンテンツ ソースによってクロールされる新しいコンテンツを含める方法を模索しています。このような取り組みにより、クロールのスケジュールと管理の複雑度を軽減することができます。
表 6 に、レドモンド SSP にあるコンテンツ ソースの種類と、その種類ごとの数を示します。
表 6 コンテンツソースの種類と数 ( レドモンド SSP)
コンテンツの種類 |
数 |
|---|---|
SharePoint サイト |
13 |
Web サイト (SharePoint サイト以外) |
6 |
ネットワーク共有フォルダ |
1 |
Exchange パブリック フォルダ |
1 |
ビジネス データ カタログ |
3 |
カスタム |
1 |
表 6 に示したコンテンツ ソースの中には、複数の開始アドレスを含むものがあります。ホスト対象のファームは、その規模が大きければサーバー レベルでクロールが行われますが、少数ではあるもののコンテンツ ソースの中には中央の SharePoint ファームではホストされないサイトの URL を開始アドレスとして含むものがあります。その URL の数は、数百に上ります。サイト コレクションに上位レベルのサイトの URL を追加すると、(特別に除外されている場合を除き) すべてのサブ サイトがクロールの対象となります。
インデックス作成の種類の選択
Microsoft は完全なインデックスの作成 (コンテンツ ソースのすべてのコンテンツをクロールします) とインデックスの増分作成 (変更が加えられたコンテンツだけを対象にインデックスを更新します) を実行します。完全なインデックスの作成は、新しい管理プロパティの追加やクロール関連の hotfix の展開など、システム変更上の必要に応じて実行されます。ただし、インデックスの増分作成を迅速化するため、完全なインデックスの作成の頻度を (可能であれば) 3 か月に 1 回以下に減らすことを目標としています。
Microsoft は Office SharePoint Server 2007 でのインデックスの増分作成を最適化しています。これは、変更ログ機能やセキュリティ情報のみをクロール対象とする機能などの新機能を使用することにより実現しました。変更ログ機能を使用すると、システムにおいて SharePoint ストア内の新しいコンテンツまたは変更が加えられたコンテンツだけを対象にインデックス付けすることができます。セキュリティ情報のみをクロール対象とする機能は、管理者がセキュリティ設定を変更するたびにコンテンツの完全なクロールを行うのではなく、セキュリティ情報だけを対象にインデックスを作成します。これらの 2 つの機能により、Microsoft IT は検索インデックスの更新処理を以前よりも迅速かつ効率的に行うことができます。
インデックス クロールのスケジュール
レドモンドにある最大規模のサーバー ファームでインデックスを更新するためにコンテンツのクロールをスケジュールするとき、Microsoft IT は多層化したアプローチを採用しています。チームは、インデックスの増分作成が必要になる頻度に基づいて、各コンテンツ ソースを層に分類します。Microsoft IT では、次に挙げる層にスケジュールを分けています。
1 日に 1 回または複数回
週に 3 回
週に 1 回
管理されたコンテンツが含まれる大規模なポータル (MSW ポータルや、IT、財務、セールス、およびマーケティングのポータルなど) については、より頻繁にクロールを実行します。管理の程度が低いコンテンツが含まれ、共同作業の多い環境 (個人用サイトなど) である大規模なポータルについては、週に 1 回、クロールを実行します。ユーザー プロファイルのデータは、1 日に 1 回、インデックス作成を行います。
インデックスの伝達の構成
Microsoft 内部での展開において、インデックス サービスと検索サービスは別々のコンピュータで実行されます。インデックス サービスとクエリ サービスを異なるサーバー上で実行する場合、検索サービスは、インデックス サーバーからクエリ サーバーに対してコンテンツ インデックスをコピー (または伝達) する必要があります。Office SharePoint Server 2007 の間断ない伝達機能により、コンテンツのインデックスが作成されてから数分以内に、そのコンテンツが検索結果に表示されるようになります。
コンテンツ アクセス アカウントの構成
インデックス作成を目的にコンテンツにアクセスするとき、Microsoft は地域ごとに 1 つのコンテンツ アクセス アカウントを使用します (複数のアカウントやパスワードの管理は行いません)。このアカウントを使用して、その地域にあるすべてのコンテンツ ソースへのアクセスが行われます。Microsoft は地域ベースのアカウントを使用して、WAN 接続全体の認証トラフィックを最小限に抑えます。
SharePoint Portal Server 2003 では、SharePoint コンテンツのインデックス作成とそのコンテンツのセキュリティ権限の収集を効率的に行うために、コンテンツ アクセス アカウントは管理者レベルの権限を要求していました。Office SharePoint Server 2007 では、新たな権限 ("すべて読み取り" アクセス) によってインデクサが情報を収集できるため、管理者レベルの権限は必要なくなりました。
Microsoft IT は、サーバー ファームのサーバー レベルで適切な権限が設定されるように、地域ごとにコンテンツ アクセス アカウントを構成します。また、ホストされる環境ではないサイトの管理者に対しても情報を提供し、管理者が地域で使用するクロール アカウントに適切なアクセス レベルを付与できます。
カスタム プロトコル ハンドラの構成
Microsoft はエンタープライズ検索ソリューションに対してカスタム プロトコル ハンドラを 1 つだけ展開しています。このハンドラにより、内部のカスタム アプリケーションのインデックスを作成できます。プロトコル ハンドラは、ネイティブ形式でコンテンツ ソースにアクセスするためのプロトコルを実装します。インデックス サービスはプロトコル ハンドラを使用して、インデックスの作成が可能なデータ ソースを展開します。
この場合、カスタム アプリケーションのデータ ストアにはカスタム要件があり、新しいプロトコル ハンドラが求められます。Microsoft は、最初に SharePoint Portal Server 2003 展開用のプロトコル ハンドラを開発し、その後で 64 ビット環境で使用できるようにハンドラに多少の変更を加えました。
クロール ルールの構成
現在のソリューションでは、約 120 のクロール ルールを使用しています。クロール ルールを使用すると、特定のパスに対するインデックス エンジンの動作をカスタマイズできます。これらのルールは、クロール (およびインデックス作成) の対象として明示的に含めるか、明示的に除外する必要のあるパスや、その他の設定 (パラメータを使用する複雑なリンク構造など) を示すものです。
Microsoft は SharePoint Portal Server 2003 ベース ソリューションと比較してルールの数を削減しましたが、最終的には、クロール ルールの数を最小限に抑え、コンテンツのインデックス作成に含めるか除外するかをローカルに設定するようにサイトのコンテンツ管理者に求めることを目標としています。
Office SharePoint Server 2007 を使用すると、インターネット上でコンテンツをクロールできますが、Microsoft IT は現時点ではイントラネット上のエンタープライズ検索にのみ取り組んでいます。Microsoft IT は http://*.* パスを除外することで、インデクサがファイアウォールから外部に出ないように明示的に指定するクロール ルールを構成しています。
クローラ影響ルールの構成
クローラ影響ルールを使用すると、管理者は、特定の URL に対して同時に要求できるページの数と、各要求の間で待機する秒数を設定できます。Microsoft では大規模なサーバー ファーム用のクロール ターゲットとして専用の Web フロントエンド サーバーを使っているため、前述の表 3 に載っているチームが直接には管理していないサイトに対してのみ、クローラ影響ルールを構成しています。
たとえば、Microsoft の内部サイトには、中央でホストされているファームの外部でチームがホストしているものがあります。このようなチームには、その環境でのクロールの負荷を軽減するために 1 秒あたりの要求の数を既定の 8 から 3 に低減するように求められています。
インデックスを作成するファイルの種類の選択
インデックス作成に含めるか、除外するかを指定するファイルの種類の一覧には、クローラがインデックス作成に含める (または除外する) ファイルの種類を指定する拡張子が示されています。クローラを使用して、特定の種類のファイルのコンテンツとプロパティを抽出するには、インデックス サービスを実行するサーバー上に、そのファイルの種類に対応したフィルタ (iFilter) をインストールする必要があります。
Microsoft はファイルの種類について最低限の構成とカスタマイズを行っています。既定のファイルの種類に加えて、新しい XML Paper Specification (XPS) と Microsoft Office OneNote® のファイルに対応した iFilter をインストールしています。Microsoft では、近い将来、.zip ファイルも対象に含める予定です。また、64 ビット版の .pdf iFilter が利用できるようになったときには、.pdf ファイルも対象に含めることを計画しています (インデックス サービスを実行するコンピュータに 64 ビットのプロセッサが搭載されている場合)。64 ビット版の .pdf iFilter は、Adobe 社やその他のベンダによって開発されたものです。
クロール パフォーマンスの最適化
レドモンドの SSP でインデックス作成の対象となるコンテンツの規模や複雑度に基づいて、Microsoft はクロールに関連する構成設定を行っています。表 7 に示す構成設定を使用することで、コンテンツ クロールのパフォーマンスが改善されました。
注 : この情報は、Microsoft での内部展開において参考資料として共有されたものであり、すべての展開に適するとは限りません。
表 7 クロールパフォーマンスの向上を図るために構成設定に加えた変更
構成設定 |
説明 |
|---|---|
パフォーマンス レベル |
共有サービス プロバイダのサーバーの管理セクションの構成設定 (インデックス サービスの応答性を高めます)。 Microsoft IT は、この値を "5" に変更しました。 |
接続までの待機時間 |
共有サービス プロバイダのサーバーの管理セクションの構成設定 (クロールするコンテンツのホスト コンピュータにアクセスするとき、クロールを実行するコンピュータが待機する時間を秒数で指定します。この時間を過ぎると、タイムアウトが発生します)。 Microsoft IT は、この値を "120" 秒に変更しました。 |
要求承認の待機時間 |
共有サービス プロバイダのサーバーの管理セクションの構成設定 (クロールするコンテンツのホスト コンピュータからの要求承認を、クロールを実行するコンピュータが待機する時間を秒数で指定します。この時間を過ぎると、タイムアウトが発生します)。 Microsoft IT は、この値を "120" 秒に変更しました。 |
管理プロパティの構成
ユーザーの検索機能の一部を構成するプロパティを、"管理プロパティ" と言います (検索結果や高度な検索で利用できるプロパティ)。"クロールされたプロパティ" は、検索インデックス サービス コンポーネントがコンテンツのクロール時に検出したプロパティを指します。検索機能で利用できる "クロールされたプロパティ" を作成するには、管理者が "クロールされたプロパティ" を "管理プロパティ" にマップする必要があります。
Microsoft では既定の "管理プロパティ" を使用することにして、次のようなカスタマイズを行いました。
プロファイル : ビジネス要件と、ユーザープロファイルストアに格納されている情報に基づいて、プロファイルにプロパティ ( 言語、優先する名前、地域など ) を追加しました。
ビジネスデータカタログ : ビジネス要件と、CRM および Library カタログ システムに格納されている情報に基づいて、ビジネス データ カタログにプロパティ (地域、地域担当販売、Web サイトなど) を追加しました。
さらに、ローカルの検索センター固有のプロパティが必要なポータルには、その他のカスタム プロパティを追加しています。これらのローカル サイトの管理者は、SSP 管理者に連絡し、管理プロパティの作成を依頼する必要があります。その後で、プロパティをローカルで利用できるようになります。Microsoft は必要に応じて管理プロパティを追加しますが、更新は 3 か月に 1 回行うようにスケジュールすることを試みています。新しく管理プロパティを追加するには、コンテンツ ソースを完全にクロールすることが必要になるためです。
共有スコープとローカル スコープの作成
検索範囲は、ユーザーがクエリを実行できる検索インデックスにおける情報のサブセットを定義します。共有スコープは SSP*で作成されます。*ローカル スコープは、各サイトのコレクション レベルで作成されます。共有スコープは、特定の SSP を使用するように構成されたすべてのサイトで利用できます。ローカル スコープは、ローカル サイトの管理者によって作成されるもので、管理者が作成したサイト コレクションやサブ サイトでのみ利用できます。スコープは、コンテンツ ソース、フォルダ パス、または特定のプロパティ (特定のユーザーが執筆したコンテンツなど) に基づいて作成できます。
レドモンド SSP では、MSW (イントラネット、ユーザー、顧客) 用に定義された検索範囲を共有スコープとして利用しています。その他のスコープは、すべてローカル スコープです。サイト管理者は、レドモンドの SSP で 200 を超えるローカル スコープを作成しています。
管理者は、現在のインデックスに基づいてスコープを再作成することにより ("スコープのコンパイル" と呼ばれます)、共有スコープとローカル スコープを作成します。Office SharePoint Server 2007 は自動的なスコープのコンパイルを実行します。スコープのコンパイルは、スコープ変更の数に応じて、時間の経過と共にその実行頻度が調整されます。スコープのコンパイルが必要である理由は、スコープを増分的に更新するからではなく、タスクとしてコンパイルを行うためです。
SSP 管理者は、いつでもコンパイルを開始できます。レドモンドの SSP で実行するスコープのコンパイルにかかる時間は 1 分未満です。
権限を持つサイトの指定
権限を持つサイトには、他のサイトと比較して、組織との関連性の高い情報が格納されています。権限を持つサイトを指定することは、検索結果内のコンテンツの関連性を高める (または低める) ための方法であると言えます。権限を持つサイトから得た結果は、権限を持たないサイトから得た結果よりも関連性が高いと判断されます。
権限を持つサイトは、検索結果の一覧に表示されるアイテムについて Office SharePoint Server 2007 が関連性の順位付けを算出する方法に影響します。アイテムの関連性の順位付けは、最上位レベルの権限、第 2 レベルの権限、第 3 レベルの権限を持つサイトとして一覧表示された URL で、結果アイテムとして表示されるまでにクリックされた回数などに基づいて決定されます。1 回のクリック操作で最上位レベルの権限を持つサイトから得られた結果は、最も関連性が高いと判断されます。1 回のクリック操作で第 2 レベルの権限を持つサイトから得られた結果や、2 回のクリック操作で第 3 レベルの権限を持つサイトから得られた結果は、その関連性は低いと判断されます。たとえば、1 回のクリック操作で第 3 レベルの権限を持つサイトから得られた結果アイテムは、1 回のクリック操作で第 2 レベルの権限を持つサイトから得られた結果アイテムよりも関連性が低くなります。
管理者は、権限を持たないサイトとして構成することで、関連性のより低いサイトを設定することもできます。権限のないサイトへの降格は、クリック回数のペナルティとは関係なく行われます。Microsoft では、検索結果内での順位付けが高すぎると判断されるサイトを、権限を持たないサイトとして指定しています。
Microsoft では、大部分の従業員に対して最上位レベルの権限を持つサイトとして適用する、内部的に重要なコンテンツを格納するサイトの数を制限しています (前述の表 2 は、これらのサイトの一覧を示したものです)。また、Windows 部門のサイトや Microsoft Office 部門のサイトなどの主要製品グループのポータルは、第 2 レベルの権限を持つサイトとして追加しています。
類義語辞典とノイズ ワードの構成
検索の管理者は、類義語辞典を使用して、クエリの拡張または置換によるクエリの処理方法をカスタマイズします。たとえば、管理者はシステムを次のように構成できます。
ユーザーが "hot fixes" または "hotfixes" を入力した場合、"hot fixes" と "hotfixes" の両方を検索します。
クエリの実行時、"hot fixes" を "hotfixes" で置換します。
ノイズ ワードは、発生頻度が高く、かつ検索クエリの観点からは価値が低いことを理由に、コンテンツのクロール時にインデックスから除外される語 ("the" や "that" など) を示します。
Microsoft では Thesaurus.xml と NoiseWords.txt のファイルのカスタマイズは行っていません。既定の構成には、ほとんどのインスタンスに適切な構成が含まれていることと、この設定が SharePoint 開発チームが既定の設定を検証するのに役立ったことがその理由です。Microsoft では、将来的には Thesaurus.xml ファイルのカスタマイズを行う可能性がありますが、NoiseWords.txt は現状のままで十分であるため、このファイルを変更する予定はありません。
検索の利用状況分析
Microsoft IT は SSP レベルとローカル サイト レベルで実行される検索の利用状況を定期的に分析しています。Microsoft IT は Office SharePoint Server 2007 が提供する次のような検索関連データを含め、数多くのソースからのデータを分析します。
過去 30 日間のクエリ
過去 12 か月間のクエリ
過去 30 日間にクエリを使用した上位のサイト コレクション
過去 30 日間の範囲あたりのクエリ
過去 30 日間の上位クエリ
検索結果の上位ジャンプ先ページ
結果が 0 個のクエリ
最もよくクリックされたおすすめコンテンツ
おすすめコンテンツが 0 個のクエリ
クリックスルー率の低いクエリ
Microsoft IT はこの分析を以下のことに役立てています。
エンタープライズ検索サービスでのユーザー エクスペリエンスの向上
サイト コレクション用のおすすめコンテンツ キーワードの作成
コンピュータのハードウェア構成とソフトウェア構成、オペレーティング システム、および検索サービスの最適化
経営陣に対する、エンタープライズ検索サービスの効率性に関するフィードバック提供
日常業務の遂行
Microsoft IT は日常的な業務遂行の中で、エンタープライズ検索サービスの継続性と応答性を確保しています。前述の管理作業に加えて、Microsoft IT では検索サービスに関するビジネス管理、監視、およびバックアップと復元の手順を行っています。
検索サービスに関するビジネス管理
MSW のビジネス管理と、検索サービスの全体的な正常性については、Information Services チームの Program Management チームが担当しています。作業には、次のようなものがあります。
コンテンツソースの管理 : 必要に応じて、コンテンツ ソースの開始アドレスを追加または削除します。また、3 か月に一度、開始アドレスを全面的に検証します。
権限を持つサイトの管理 : ビジネス要件、ポータルの更新や変更、エンド ユーザーからのフィードバックに基づき、必要に応じて、権限を持つサイトの検証や更新を実施します。
サイト管理者との共同作業 : 中央の SharePoint ファームでコンテンツがホストされていない場合、サイト管理者と共同作業を行うことで、適切なサイト コンテンツがエンタープライズ検索に含まれるようにします。この共同作業には、サイト コレクションの管理者が行うサイトのカスタマイズ作業を支援することも含まれます。
エ ンドユーザーとサポート問題への対応 : チームは検索に関するエンド ユーザーからの質問と、サポートの問題に対応します (コンテンツ範囲、関連性、クエリ構文など)。また、検索サービスの操作上または技術上の問題についても対応します。
おすすめコンテンツの編集 : この作業には、特定の検索文字列に対して候補となる URL の特定、有用なタイトルや説明 (検索結果に表示されます) の記述、適切なキーワードや類義語のタグ付けなどが伴います。このほか、定期的に実施されるキーワードやおすすめコンテンツの検証、検索の利用状況レポート (おすすめコンテンツが 0 個の上位クエリなど) に基づく新たなおすすめコンテンツの特定などが含まれることもあります。
クエリログの分析 : チームはクエリ ログを定期的に検証し、実行されたクエリと結果の詳細を確認します。さらに、最新の傾向を見極め、"企業用語集" に追加する用語を決定します。"企業用語集" は、組織に固有な用語を一覧表示したものです。
監視正常性状態の関連作業
Microsoft は、Microsoft Operations Manager 2005 を使用して、検索サービスの監視正常性状態の関連作業を行っています。エンタープライズ検索サービスに対しては、次に挙げる管理パックを使用しています。
Microsoft Operations Manager 2005 用 Microsoft Office SharePoint Server 2007 管理パック
Microsoft Operations Manager 2005 用 Microsoft Windows SharePoint Services 3.0 管理パック
Microsoft Operations Manager 2005 用 Microsoft Web Sites and Services 管理パック
Microsoft Operations Manager 2005 用 Internet Information Services (IIS) 管理パック
Microsoft Operations Manager 2005 用 Windows Base Operating System 管理パック
Microsoft Operations Manager 2005 が提供する監視機能に加えて、MSW サーチの可用性を追跡する専用の URL 監視を実行しています。URL 監視ソフトウェアは MSW サイトに対して 4 つのクエリを実行します (検索センターには、クエリごとに 1 つのタブが用意されています。このほかに、もう 1 つタブがあります)。クエリの実行後、URL 監視ソフトウェアは応答時間を追跡し、しきい値として指定された時間内に応答が返ってくるようにします。
また、Microsoft では、クエリの応答ページに特定の用語が表示されているかどうかについて、ソフトウェアを使用したチェックも行っています。特定の用語が表示されていない場合は、ソフトウェアによって警告が生成され、Operations チームに送信されます。Microsoft はこのソフトウェアを使用して、クエリのパフォーマンスを測定するというよりは、全体的な可用性を監視しています。
前述した監視作業のほかに、Microsoft は次のような監視正常性状態の関連作業を定期的に行っています。
クローラ影響ルールの調整 : クローラ影響ルールを検証し、必要に応じて調整します。
クロールログの検証 : クロール ログを定期的に検証し、エラーがないかどうかを確認します。エンド ユーザーやサイト管理者から、検索結果にコンテンツが含まれないなどの報告を受けた場合はトラブルシューティングを実施します。
クエリ結果アイテムの削除 : Microsoft が検索結果からコンテンツを即座に削除しなくてはならないことがまれにあります (ビジネス要件や法的要件を理由とすることが一般的です)。このような場合、Microsoft は単一アイテムを削除するための管理者用ユーザー インターフェイスを使用して、個々のアイテムをクエリ結果から削除します。
Microsoft はイベント ログやパフォーマンス監視カウンタ (ディスク、メモリ、アプリケーションのパフォーマンス カウンタなど) を使用して、キャパシティ計画を行い、パフォーマンスの傾向を分析する作業も実施します。これらのログやカウンタは、Windows Server® 2003 オペレーティング システムや、Windows Server 2003 上で実行する製品によって提供されます。
バックアップおよび復元の実行
Microsoft は、レドモンド、ダブリン、シンガポールの 3 か所にある SSP のそれぞれについて、週に 1 回 (火曜日の夕方)、完全なバックアップを実行します。この処理には Office SharePoint Server 2007 に同梱されているバックアップ ツールを使用します (実行には GUI または stsadm.exe を使います)。バックアップでは SQL Server データベースと検索インデックスの両方を対象としています。
Microsoft は Office SharePoint Server 2007 で実行するバックアップだけでなく、サードパーティ製のデータベース圧縮アクセラレータ ツールを使用して、毎晩、SQL Server データベースのバックアップを実行しています。
レドモンドの SSP ファームの完全なバックアップには平均で 8 時間かかります。環境を完全に復元するには、おおよそ 12 時間が必要です。
エンタープライズ共有検索サービスの管理 (その他の地域)
EMEA とアジア地域に配置されている SSP に関する日常的な管理は、レドモンド ファームと同様ですが、その規模は小さくなります。地域のデータ センターではローカル地域にあるコンテンツだけを対象にインデックスを作成するため、インデックス付けされているアイテムの数は、各ファームで 500 万アイテムに届きません。ただし、レドモンド ファームと同様に、その数は増加しています。Microsoft ではレドモンドと他の地域の設定に一貫性を持たせることができるように、可能な限り、ファーム間での設定を標準化するように取り組んでいます。
他の地域ではコンテンツ ソースの数は 10 に満たず、クロール ルールも最低限の数しかありません。各地域のファームに対して、Microsoft IT は次の作業を行っています。
各コンテンツ ソースの増分クロールを毎日行うようにスケジュールする
地域間でプロファイル データを複製する
レドモンドにある共有サービスとプロファイル データを同期化する
インデックス付けされたサイトとコンテンツの管理
クロールなど、検索に関する管理作業の大部分は SSP レベルの管理者が実行します。ただし、ローカル サイトの管理者も、数多くの検索関連作業を行います。
レドモンドの SSP に接続された多くのサイトでは、Microsoft がファーム上にサイトを提供した後で、サイトで利用可能な基本的な検索を使用します。新しくサイトが作成されると、そのサイトの既定の検索範囲は "このサイト" になります。ユーザーがサブ サイトを閲覧するとき、この検索範囲により、自動的に、検索結果にサブ サイトが含まれるようになります。"このサイト" という検索範囲には、現在の Web サイトとサブ サイトのコンテンツが含まれます。
Microsoft では、各サイトのローカルな SharePoint 管理者が責任を持ってサイト コレクション内でのローカル検索範囲を作成し、定義します (この機能が必要な場合)。"このサイト" 以外の検索範囲が必要な場合や、SSP が提供するいずれかの共有スコープを使用する場合は、ローカル管理者が検索範囲を作成します。管理者は、追加した検索範囲に基づいて、コンテンツ ソース、フォルダ パス、または管理プロパティに対して検索が行われるようにします。管理者は、サイト内での検索範囲の使用法についても決定します (検索範囲のドロップダウン リストや高度な検索など)。
特定のキーワードへの関連性が最も高いコンテンツを判断するのに最適な担当者は、ローカル コンテンツの所有者であるため、ローカル サイト レベルでは、ローカル コンテンツの所有者がおすすめコンテンツを管理しています。
エンタープライズ検索サービスのユーザー エクスペリエンス
Microsoft IT がホストする SharePoint ファーム上に新しい Web アプリケーションを提供すると、Office SharePoint Server 2007 により、ローカル サイト用の検索サービスが自動的に作成されます。サイト コレクション管理者は、検索センターの作成、カスタム スコープの追加、検索結果の外観の変更、おすすめコンテンツの追加などを実行し、ユーザーの検索機能をカスタマイズできます。
ユーザー エクスペリエンス (MSW)
MSW は Microsoft で最もよく使用されているイントラネット サイトであり、企業内で従業員が情報検索を開始する場所です。MSW は Office SharePoint Server 2007 に最初に移行されたサイトの 1 つで、製品がベータ版であるときから運用環境に展開されています。
MSW ホーム ページの [検索] タブを図 2 に示します。[検索] タブでは、上位レベルの検索範囲を指定します。ユーザーは [イントラネット]、[人]、または [顧客] を使用して検索結果を絞り込むことができます。
![図 2 MSW ホーム ページの [検索] タブ](images/dd283214.bb735129_image002(ja-jp,technet.10).gif "図 2 MSW ホーム ページの [検索] タブ")
図 2 MSW ホームページの [ 検索 ] タブ
ユーザーが検索を実行すると、Office SharePoint Server 2007 の検索センターに結果が表示されます (図 3 を参照)。検索センターには、検索範囲ごとに 1 つのタブが用意されています。
図 3 検索センターに表示される結果 (MSW)
検索センターの [イントラネット] タブ
[イントラネット] タブ (および MSW ホーム ページの [イントラネット] 検索範囲) には、インデックス付けされたすべてのコンテンツから取得した結果が表示されます。ただし、[人] タブと [顧客] タブに表示されるコンテンツは除きます。ここで検索を行うと、最も広い範囲にわたるコンテンツのインデックスが返されるため、Microsoft イントラネットのコンテンツに関する全般的な情報を検索する際には従業員はこのタブを使用します。
[イントラネット] タブのカスタマイズ
Microsoft IT は [イントラネット] タブでの検索処理の動作について、次のようにカスタマイズしています。
検索結果ページに Web パーツとして表示する、おすすめコンテンツの場所を変更する : おすすめコンテンツは、既定で、検索結果の一覧を表示するメイン ページの右側に Web パーツとして表示されます。ユーザーからのフィードバックに基づき、結果を見やすくするように、MSW チームは Web パーツの表示を左側の検索結果の上部に移動することにしました。
グロッサリ定義用にカス タムの Web パーツを含める : Microsoft は検索結果の右側の余白にカスタムの Web パーツを追加しました。ここには、以前は検索に含まれる既存のキーワード定義 Web パーツが表示されていました。ユーザーがイントラネット検索クエリに用語 (略語など) を入力すると、グロッサリ定義の一覧が表示されます。たとえば、ユーザーがクエリに「DOS」と入力すると、DOS の定義の一覧が表示されます (サービス拒否、ディスク オペレーティング システムなど)。Microsoft はこの表示にカスタムの Web パーツを使用して、内部的にカスタマイズして構築された分類管理システムを利用しています。このシステムには、数千にも上る企業用語集とその定義が格納されています。
Windows Internet Explorer® 7 検索プロバイダへのリンクを追加する : ユーザーがこのリンクをクリックすると、 Internet Explorer 7 への検索プロバイダとして MSW サーチが追加されます。 Internet Explorer 7 は複数の検索プロバイダをサポートしています。 Internet Explorer 7 に検索プロバイダを追加する方法の詳細については、「 Internet Explorer 7 での検索プロバイダの拡張 ( https://msdn.microsoft.com/library/cc848862.aspx ) ( 英語 ) 」を参照してください。
新しい検索のリンクを含める : ユーザーがこのリンクをクリックすると、検索センター内で新しい検索が開始します。MSW ホーム ページには (ユーザー インターフェイスのスペースの関係上) [検索センター] タブがないため、このリンクは重要です。
おすすめコンテンツのカスタマイズ
Microsoft IT は企業用語集からキーワードと類義語を選択しました。Microsoft IT では検索結果の指標 (クエリ量の傾向、実行頻度の最も高いクエリ、クエリ結果のクリックスルー率、結果が 0 個のクエリなど) を検証することで、おすすめコンテンツを定期的に改良しています。
おすすめコンテンツに加えた変更は即座に有効になるため、ユーザーは最新のおすすめコンテンツを参照できます。管理者はアイテムの優先順位を設定することもできます。Microsoft では 1 つのキーワードに対するおすすめコンテンツの URL を 5 個未満に抑えるように試みています。
検索センターの [人] タブ
[人] タブ (および MSW ホーム ページの [人] 検索範囲) には、Microsoft に勤務する従業員に関する結果が表示されます。従業員は、このタブを使用して、他の従業員を特定したり、他の従業員に関する情報を検索したりします。
Microsoft は他のソースからの情報を Office SharePoint Server 2007 にインポートして、インデックス付けされた情報を [人] タブ用に収集します。ソースには、次のようなものがあります。
Active Directory : Microsoft は Active Directory から Office SharePoint Server 2007 に、インデックス付けされた従業員情報のインポートを行いました。Office SharePoint Server 2007 には 126,000 を超えるアクティブ ユーザー プロファイルが格納されています。この情報は、Active Directory にある情報と同期されています。Office SharePoint Server と Active Directory の情報の同期は、毎日実行されています。Microsoft は Active Directory から取得したユーザー プロファイルを使用して、ユーザー用にカスタマイズしたページを作成します。
フィードストア : データ ソースから Office SharePoint Server 2007 にデータの複製を提供するデータベースです。データベースは、39 の内部ソースから情報を取得し、500 のサブスクライブ側アプリケーションに対して情報を提供しています。
検索センターの [顧客] タブ
[顧客] タブ (および MSW ホーム ページの [顧客] 検索範囲) には Microsoft の顧客に関連する結果が表示されます。従業員はこのタブを使用して、Microsoft のエンタープライズ顧客や提携先企業の上位レベルのアカウントに関する情報を検索します。このタブは、Office SharePoint Server 2007 のビジネス データ カタログ機能を利用しています。この機能を使用すると、管理者は基幹業務アプリケーションの構造化されたデータ セットを SharePoint に統合することができます。Microsoft では、ビジネス データ カタログ機能を使用して [顧客] タブを作成しています。図 4 に、このタブを示します。
![図 4 検索センターの結果 ([顧客] タブ)](images/dd283214.bb735129_image004(ja-jp,technet.10).gif "図 4 検索センターの結果 ([顧客] タブ)")
図 4 検索センターの結果 ([ 顧客 ] タブ )
Microsoft は、MSW サーチ用に約 200,000 のエンタープライズの上位レベルのアカウント (親アカウント、内部の CRM システムに保存されています) を対象にインデックスを作成しています。ユーザーは検索結果から利用できる顧客プロファイル ページ (CRM システムで提供されます) から、関連するアカウント (子会社など) にドリルダウンできますが、Microsoft はユーザーのフィードバックに基づいて上位レベルのアカウントにインデックスを作成することを決定しました。このソリューションでは、顧客または提携先企業と、その子会社との関係も定義します。
Microsoft IT は SharePoint 開発チームの支援を受け、約 1 か月の時間をかけて [顧客] タブの情報にインデックスを作成するために必要な統合作業を行いました。この初期の展開は Office SharePoint Server 2007 のベータ版を基礎にしています。
ビジネス データ カタログのアプリケーション定義ファイル
ビジネス データ カタログは、基幹業務アプリケーションから特定のデータ フィールドを検索し、そのフィールドをローカル データベースに保存します。ビジネス データ カタログは、次の種類の XML アプリケーション定義ファイルをサポートしています。
モデル : システムの基礎となる XML メタデータを含むアプリケーション定義ファイル。
リソース : ローカライズされた名前、プロパティ、権限を、ユーザーが任意に組み合わせてインデックスを作成したり読み取ったりできるようにするためのアプリケーション定義ファイル。
ビジネス データ カタログを使用すると、内部の CRM システムに保存されているデータに対して次の操作を実行できます。
列挙 : インデックス作成を目的として、企業の一覧をクロールします。
特定の情報の検索 : 企業の ID に基づいて 1 つのアイテムを検索します。各企業に関する詳細なコンテンツをクロールし、詳細なデータを取得して、顧客の詳細情報を表示する Web ページに Web パーツを設定します。
検索 : 親アカウントの下位にある子アカウントの一覧を取得します。子アカウントごとの詳細なコンテンツをクロールし、詳細なデータを取得して、子アカウントの詳細情報を表示する Web ページに Web パーツを設定します。
顧客プロファイルのページ
[顧客] タブに表示された結果の中から顧客の名前をクリックすると、Office SharePoint Server 2007 によって顧客プロファイルのページが表示されます。顧客プロファイルのページには、各顧客アカウントの詳細情報 (地理的な位置、業種、連絡先情報など) が表示されます。また、顧客とアカウント階層 (親アカウントと子アカウント) に対応する Microsoft アカウント チームの連絡先も表示されます。
顧客プロファイルのページには、顧客のアカウント情報を表示する Web パーツが含まれています。これらの Web パーツにより、ビジネス データ カタログでの "特定の情報の検索" や "検索" の操作をとおして取得した情報が表示されます。
検索センターの [Web キャスト] タブ (今後、導入予定)
近日中に、Microsoft は MSW サイトに [Web キャスト] タブ (および検索範囲オプション) を追加する予定です。Microsoft の経営陣は、一般に、Web キャストを使用して "ワイヤーサイド" のチャットをホストし、定期的に開催することは困難な、多数の聴衆が参加するミーティングを開きます。従業員は [Web キャスト] タブを使用して、イベントやイベントの補足資料を検索できます。初期のインデックス データは Studioscast サービス (従業員に Web キャストを提供するイントラネット ベースのサービス) から入手する予定です。
ユーザー エクスペリエンス (その他のイントラネット サイト)
エンタープライズ共有検索サービスを使用するその他の Web サイトとして、ITWeb があります。MSW と ITWeb は同じエンタープライズ共有検索サービスを使用していますが、ITWeb の検索サービスでのユーザー エクスペリエンスは MSW とは少し異なります。図 5 に、ITWeb のホーム ページを示します。
.gif "図 5 検索用ユーザー インターフェイス (ITWeb ホーム ページ)")
図 5 検索用ユーザーインターフェイス (ITWeb ホームページ )
ITWeb のデザイナは検索用ユーザー インターフェイスをページの右側に追加しました。ユーザーはドロップダウン リストを使用して検索範囲を選択します。表 8 を使用して、ITWeb の検索用ユーザー インターフェイスで使用できる検索範囲と、限定される検索結果について説明します。
表 8 ITWeb の検索範囲と検索結果
検索範囲 |
限定される検索結果 |
|---|---|
このサイト |
検索結果は、現在のサイト内に限定されます。ホーム ページで検索を実行すると、ITWeb のみが検索対象となります。その他のサイトでは、そのサイト内だけが検索対象となります。 |
ITWeb |
検索結果は、ITWeb 内に限定されます。この検索範囲を指定すると、他のサイトやコンテンツ ソースは検索結果から除外されます。 |
InfoPlus |
検索結果は、InfoPlus 内に限定されます。この検索範囲を指定すると、他のサイトやコンテンツ ソースは検索結果から除外されます。 |
イントラネット |
検索は、Microsoft イントラネット全体に対して行われます。この検索範囲を指定すると、インデックス付けされたすべてのサイトと、すべてのコンテンツ ソースを検索した結果が表示されます。この検索範囲を指定すると、ユーザーは MSW サーチ インターフェイスの [イントラネット] タブにリダイレクトされます。 |
エンタープライズ共有検索サービスを使用する別の例として、個人用サイトのポータルがあります。レドモンドでは、個人用サイトのポータルでの既定の検索範囲は SSP レベルで MSW のイントラネット検索を指すように構成されています。
ユーザー エクスペリエンスの効果の測定
Microsoft はエンタープライズ共有検索サービスのユーザー エクスペリエンスを向上するように、継続的に取り組んでいます。次のリソースを使用して、エンタープライズ共有検索サービスにおけるユーザー エクスペリエンスの効果の測定を行っています。
Office SharePoint 2007 検索の利用状況のレポート : Microsoft IT は Office SharePoint 2007 で提供されるレポートを検証し、ユーザーが実行した検索を特定してその結果を調べます。統計情報には、ユーザーによるクリック回数が最も多いリンクに関する情報も含まれます。
WebTrends レポートコンソールによるレポート : Microsoft IT は WebTrends レポート コンソールで提供されるレポートを検証し、ページの使用状況と検索エンジンに関する統計情報を収集します。WebTrends は Web サイトの使用状況を監視し、追跡する製品です (Microsoft 製品ではありません)。
ユーザーおよび調査結果からのフィードバック : 従業員に対して検索サービスの満足度調査を行います。従業員は Microsoft IT に電子メール経由で直接連絡してフィードバックを提供することもできます。
操作性テスト : 設計、開発、テストのプロセスの一環として、Microsoft IT はユーザー エクスペリエンスの観点から操作性をテストします。操作性テストに参加した従業員は、ユーザー インターフェイス、プロセス フロー、コンピュータとの対話について意見を述べ、改良の余地がある領域について特定します。
フォーカスグループによるフィードバック : 製品開発において、Microsoft IT はユーザー インターフェイスとユーザー エクスペリエンスのさまざまな側面について、フォーカス グループ法を採用します。この方法は、ユーザー インターフェイスを全体的に改良する方法を見極めるのに役立ちます。
Office SharePoint Server 2007 への移行
Microsoft IT は、SharePoint Portal Server 2007 への移行について 2005 年初旬から準備を始めました。エンタープライズ検索サービスを以前のソリューションから Office SharePoint Server 2007 に移行するにあたり、必要なサービスの停止を最小限に抑えるようにする必要がありました。これを実現し、適切な場所で移行を完了させるため、ホストを共有してサービスを提供することにしました。つまり、移行プロセスの間、Microsoft IT は SharePoint Portal Server 2003 ベース ソリューションと Office SharePoint Server 2007 ベース ソリューションを異なるハードウェア上で実行しました。
Microsoft は、サイトとコンテンツを新プラットフォームに移行するにあたり、異なるアプローチを採用しました。新たな SSP のインストールと構成を行った後、Microsoft IT は "データベースのアタッチ" と "段階的なアップグレード" の 2 つの方法を使用してサイトのアップグレードを行いました。こうして、新しい SSP から検索を実行できるようになりました。
"データベースのアタッチ" では、SharePoint Portal Server 2003 から Office SharePoint Server 2007 に対して SharePoint コンテンツ データベースをアタッチします。"段階的なアップグレード" では、以前のバージョンと新しいバージョンの両方を実行し、サイトを段階的に新しい環境に移行できるようにしました。カスタマイズ内容の転送や比較に、両バージョンのサイトを利用することもできます。
MSW などの規模の大きいポータルを所有するチームは、サイトのアップグレードではなく、移行する方法を選択しました。この方法では、サイトを新たなデザインと構成に移行し、Office SharePoint Server 2007 で利用可能な新しいコンテンツ発行機能とワークフロー機能を活用できます。
(Microsoft の環境のように) 複雑な IT 環境でエンタープライズ全体での Office SharePoint Server 2007 へのアップグレードを成功させるには、計画と準備が重要です。Microsoft IT では新 SSP の検索に関する構成を計画するときに、次の手順を採用しました。
既存のコンテンツ ソースを確認する
開始アドレスの更新
適切なコンテンツのクロールを確保
サイトのアップグレード、コンテンツの移行、および関連プロセスによる変更内容の記録コンテンツ ソース一覧を整理統合し、下記情報に基づく一覧を新規作成する
必要なポータル ハンドラ
コンテンツの場所検索対象とするコンテンツの種類を新たに追加する
新ビジネス データ カタログ ソースでインデックス付けすることが必要な、新たなコンテンツを特定
接続の開発プロジェクトの開始 (必要な場合)既存のクロール ルール一覧を確認し、整理統合されたコンテンツ ソースに適合するように必要に応じて更新する
権限を持つサイトの階層を決定する
A. MSW のおすすめコンテンツのルート URL 一覧に基づいて初期の一覧を作成
B. 組織図に基づいて一覧を更新
C. 大規模な上位レベルのサイトに基づいて一覧を更新 (前述の表 2 の一覧)管理プロパティの要件を確認する
新しいハードウェアに Office SharePoint Server 2007 をインストールする
新しいコンテンツ ソースを作成する
改良したクロール ルールを追加する
ファイルの種類を構成し、新しいファイルの種類と iFilters を追加する (必要な場合)
コンテンツ ソースのコンテンツ アクセス アカウント、およびその他の SSP レベルの設定を構成する
コンテンツのインデックスを作成する
管理プロパティのマッピングを構成する
権限を持つサイトを構成する
共有スコープを作成する
クロールのスケジュールを作成する
サービス監視を設定し、利用状況分析を有効にする
2006 年 1 月、Microsoft は MSW サーチの検索機能を Office SharePoint Server 2007 SSP ファームに切り替えました。その他のポータルでは、引き続き SharePoint Portal Server 2003 を使用します。Microsoft は既存の検索サーバーを新しい検索サーバーに置換することによって、この移行を実施しました。新しい検索サーバーは、新ファーム上に作成されたサイトの検索センターを対象に処理を実行します。
Microsoft はこの新サイトの検索には関係のないナビゲーションと要素はすべて削除しました。ただし、2 つのサイト間で、一部のユーザー エクスペリエンスについて一貫性を持たせるため、既存の MSW ブランドと外観を新規サイトに追加しています。Office SharePoint Server 2007 製品開発の初期段階で移行を実施したため、必要に応じてサイトを SharePoint Portal Server 2003 ベースの検索に戻すことができるようにコードを記述しました。
2006 年 6 月、Microsoft は運用環境で Office SharePoint Server 2007 をベースとする MSW の使用を開始しました (Office SharePoint Server 2007 Beta 2 Technical Refresh をベースとしています)。同時に、SSP ファームも同じリリースにアップグレードしました。それから数か月をかけて、Microsoft は一部の内部ビルドを SSP ファームに展開しました。
2006 年は引き続き各地域ファームのベータ版へのアップグレードを実施し、2006 年末までには、すべてのファームを公式にリリースされたバージョンにアップグレードしました。
ベスト プラクティス
Microsoft IT は Office SharePoint Server 2007 と SQL Server 2005 を使用して、エンタープライズ検索の設計、展開、管理、および運用を実現しました。この経験に基づき、展開とアーキテクチャについて、次に挙げるベスト プラクティスを推奨します。
Windows クラスタリングを使用した SQL Server へのフォールトトレランスの実装 : Office SharePoint Server は SQL Server がホストするデータベースに検索インデックスを格納します。クラスタのノードとして SQL Server 2005 を実行するコンピュータを 2 台以上構成することで、サービスを停止せずに作業を進めることができます。管理者は Windows クラスタリングを使用してクラスタを作成できます。
検索データベースと TempDB データベースを専用の高速ディスクドライブに配置 : インデックス作成や検索クエリを実行すると、検索データベースや TempDB データベースが格納されるディスクドライブでのディスク使用率が高くなります。パフォーマンスを高めるには、各データベースを、独立した専用の高速ドライブに配置します。
インデックスサービス、検索サービス、および SQL Server を高パフォーマンスのコンピュータ上で実行 : インデックス作成や検索を実行するコンピュータでは、プロセッサやメモリの使用率が高くなります。インデックス作成や検索の応答時間を短縮するには、十分なシステムリソース ( プロセッサおよびメモリ ) を搭載した専用のコンピュータを使用して、 Office SharePoint Server 2007 と SQL Server 2005 でインデックスサービスと検索サービスを実行します。
注 : Office SharePoint Server 2007 を 32 ビット サーバー上に展開することはできますが、Office SharePoint Server 2007 ファームの展開では 64 ビット サーバーを使用することをお勧めします。詳細については、「Search 環境でのパフォーマンス要件とキャパシティ要件の見積 (https://technet.microsoft.com/library/cc262574.aspx)) (英語)」を参照してください。
Web ファームのフロントエンドサーバーを、大規模サイトのクロールターゲットサーバーとして専用 : 大規模なサイトでコンテンツのクロールを実行すると、サイトをホストするサーバーのシステムリソースが大量に消費されます。 Web ファームにあるサーバーの 1 台を専用のクロールターゲットサーバーとすることで、リソースの使用率が最も高い期間でもインデックスの更新を行うことができます。
運用環境で取得した SSP インデックスのバックアップを使用して開発、テスト、または準備環境を整備 : 運用環境で取得した SSP インデックスのバックアップを、開発とテストを目的に復元します。バックアップの復元後、これらの環境で一部のインデックス作成処理が発生しますが、運用環境のインデックスを復元すると、コンテンツ全体に対して改めてインデックスを作成する必要はありません。
すべてのサーバーで最新の hotfix 、更新プログラム、サービスパックを実装 : すべてのサーバーに最新の hotfix 、更新プログラム、サービスパックをインストールすると、セキュリティの脅威を最小限に抑えることができ、機能に関連する製品上の問題も可能な限り少なくすることができます。すべてのサーバー上で、同じレベルの hotfix とサービスパックを実行するようにします。異なるレベルが混在すると、予測できない結果になることがあります。
次に、管理面でのベスト プラクティスを紹介します。
コンテンツ ソースの数を最小限に抑制 : コンテンツ ソースの数を抑えると、管理作業の複雑さを軽減できます。コンテンツ ソースが少ないほど、管理や監視の対象が減少します。
ユーザープロファイルに個別のコンテンツソースを使用 : 大規模な個人用サイトの展開では、ユーザー プロファイルに個別のコンテンツ ソースを作成することで、個人用サイトのコンテンツのクロール構成 (クロールの種類や頻度など) を別個に設定できます。
開始アドレスの検証 : 開始アドレスの数が多いほど、多くのコンテンツのインデックスを作成することになります。各コンテンツ ソースの開始アドレスを検証し、不要な開始アドレスを削減します。
クロールルールを定期的に検証して更新 : クロールするコンテンツ ソース、クロールするファイルの種類、クロール関連の他の条件は、クロール ルールで指定します。クロール ルールを検証して更新し、すべてのコンテンツがインデックスに含まれるようにします。
おすすめコンテンツとキーワードを定期的に検証して更新 : おすすめコンテンツとキーワードにより、コンテンツの関連性が指定されます。おすすめコンテンツとキーワードを検証して更新し、すべてのコンテンツの関連性を明確にします。
検索メタデータのプロパティスキーマを定期的に検証して更新 : クロールされたプロパティ、管理プロパティ、およびこれらのプロパティ間のマッピングにより、インデックスを作成して検索クエリに含めるコンテンツ メタデータが決まります。検索メタデータのプロパティ スキーマを更新し、コンテンツに追加された新しいメタデータを含めるようにします。
次に、コンテンツの管理面でのベスト プラクティスを紹介します。
ファイル名にキーワードを含める : インデックス サービスでは、URL パス内のファイル名にキーワードが含まれているコンテンツは、ファイル名にキーワードが含まれていないコンテンツよりも関連性が高いと認識されます。可能であれば、ファイル名 (URL の右端部分) を読み取ることができるようにします。ファイル名のキーワード間にスペース (%20) を配置すると、検索エンジンが URL 内のキーワードを特定できるようになります。
アンカーテキストにキーワードまたは説明文を含める : ハイパーリンクの <A HREF> タグと </A> タグの間にあるテキスト (Web ページ上に表示され、ユーザーがクリックするとコンテンツに移動するテキスト) を "アンカー テキスト" と言います。通常、このテキストは、リンクの参照先のコンテンツに関連する内容を示します。検索エンジンは、インデックス作成後に実行する関連性の順位付けにおいて、このこと (リンクの参照先のコンテンツに関連する内容を示していること) を前提としてテキストを使用します。
アンカー テキストは、多くの場合、(インデックス作成との関係上) ドキュメントそのものよりもドキュメントに関する情報をわかりやすく表しています。検索では、アンカー テキスト内の次の要素をクロールします。
HTML アンカー要素
Windows SharePoint Services リンクの一覧
Office SharePoint Portal Server 2003 の一覧
Microsoft Office Word 2007、Microsoft Office Excel® 2007、および Microsoft Office PowerPoint® 2007 のハイパーリンク (新しい Open XML Formats を使用するファイルのみが対象)
タイトルにキーワードおよび説明文を含める : Web ページやドキュメントのタイトルをコンテンツに含め、検索結果として出力されるようにします。"ホーム" や "インデックス" のようなタイトルは避け、ページで取り上げている内容に関するタイトルを作成します。検索エンジンによって順位付けが行われるとき、フルテキストよりもタイトルに重きが置かれます。
Microsoft Office ドキュメントと HTML ページに、関連するメタデータを含める : Microsoft Office で作成されるファイルには、ファイルの属性を説明する情報 (作者、管理者、キーワード、カスタム プロパティなど) を含めることができます。インデックス サービスはメタデータをクロールし、クエリ プロセッサはメタデータを使用して検索クエリにおけるファイルの関連性を判断します。Microsoft Office ドキュメントや HTML ページにキーワードの形式でメタデータを追加することを検討します。この方法は、ドキュメント内のテキスト量が多くない場合 (スプレッドシートや、画像の多いドキュメントなど) に、特に有用です。
SharePoint ドキュメントライブラリに格納されているファイルに、関連するメタデータを含める : SharePoint ドキュメントライブラリに格納されているファイルには、ファイルの属性を説明する情報 ( 作者、支社、キーワード、カスタムプロパティなど ) を含めることができます。インデックスサービスはメタデータをクロールし、メタデータを使用して検索クエリにおけるファイルの関連性を判断します。たとえば、作者のプロパティには、テンプレートを作成した人やドキュメントをサイトにアップロードした人ではなく、実際にドキュメントを書いた人の情報が反映されます。
重要なコンテンツをサイト階層の上位に配置する : 組織内で (スラッシュ記号の少ない形式で) URL 階層の上位に表示されるドキュメントや Web ページは、重要度が高いと認識される傾向にあります。コンテンツの優先順位や重要性を設定できる場合には、より重要なコンテンツを含むサイトをサイト階層の上位に配置することで、ユーザーが自分にとって役立つコンテンツを見つけやすくなります。次に、監視および運用面でのベスト プラクティスを紹介します。
Microsoft Operations Manager 2005 を使用してインデックスサービスと検索サービスを監視する : インデックスサービスと検索サービスを監視するには、 Office SharePoint Server 2007 管理パック、 SQL Server 管理パック、 Microsoft Operations Manager 2005 用 Windows Base Operating System 管理パック、および Microsoft Operations Manager 2005 用 Internet Information Services (IIS) 管理パックをダウンロードします。これらの管理パックは、サービスが実行されていないときを確認したり、サービスの正常性状態に関する統計情報を収集したりするときに役立ちます。
クロールを一時的に停止する必要がある場合は、インデックス作成を中止するのではなく中断する : インデックスの作成を中止すると、次にインデックスを作成するときに完全な更新を実行することが必要になります。インデックスの作成を中断することで、管理者はプロセスを停止した時点からインデックス作成処理を再開できます。
インデックスデータベースと SSP データベースの計画的なバックアップを実行する : この処理を行うことで、起こり得る障害から迅速に復旧できます。たとえば、レドモンド SSP などでインデックスを完全にクロールするには、数週間の時間がかかります。
結論
組織内で適切な情報や人を検索する作業は、時間のかかる困難な作業となることがあります。エンタープライズ検索サービスを使用しなかったら、Microsoft の従業員は次のような状況に陥ることも考えられます。
複数のプロジェクトやチームで、数え切れないほどの時間をかけて重複する作業を実施する
他の従業員からもたらされる重要な情報に気付かない
不完全かつ不正確な情報に基づいてビジネス上または技術上の意思決定を行う
技術的な問題を解決するために必要なテクニカル サポートの時間が長くなったり、より多くのヘルプデスク リソースを要する
職務上の問題に取り組む、経営管理上のリソースや人的リソースがより多く必要になる
Microsoft IT はインデックス付けされた既存のコンテンツ、既存のコンテンツ リソース、ビジネス要件、および技術要件を検証しました。そして、従業員が日常的な職務を遂行するために重要な最新の関連情報を検索できるように、従業員向けにエンタープライズ共有検索サービスを展開しました。このエンタープライズ検索サービスによって、Microsoft の従業員は世界に散在する同僚と互いに連絡を取り、従来よりも迅速かつ容易に共同作業を行うことができるようになりました。
Microsoft IT は Office SharePoint Server 2007 の Enterprise Search 機能、SQL Server 2005、Windows Server 2003、独自に開発した Web パーツを組み合わせ、他の基幹業務サービスやアプリケーションをエンタープライズ検索サービス ソリューションに組み込みました。このソリューションを開発して展開したことで、次のような利点がもたらされました。
Microsoft イントラネット上で関連コンテンツを検索する機能が向上した
エンタープライズ検索サービスに対する従業員の満足度が高まった
コンテンツの発行機能が高まり、コンテンツ検索が容易になった
従業員や主要な連絡先の検索機能が改善された
基幹業務アプリケーションとの一体化が進んだ
検索機能と検索結果における一貫性が向上した
エンタープライズ検索サービスの稼動時間が長くなり、サービスを利用できる時間が増えた
連絡先
Microsoft の製品やサービスの詳細については、米国では Microsoft Sales Information Center ((800) 426-9400) まで、カナダでは Microsoft Canada information Centre ((800) 563-9048) までお問い合わせください。それ以外の国や地域の方はお近くの Microsoft 支社までお問い合わせください。インターネットでは、次の Web サイトで当社の情報をご覧いただけます。
https://www.microsoft.com/ja/jp
https://www.microsoft.com/japan/showcase/
IFilters の詳細については、次の Web サイトをご覧ください。
https://msdn.microsoft.com/library/ms691105.aspx
このドキュメントに記載されている情報は、このドキュメントの発行時点におけるマイクロソフトの見解を反映したものです。変化する市場状況に対応する必要があるため、このドキュメントは、記載された内容の実現に関するマイクロソフトの確約とはみなされないものとします。また、発行以降に発表される情報の正確性に関して、マイクロソフトはいかなる保証もいたしません。
このホワイト ペーパーに記載された内容は情報提供のみを目的としており、明示、黙示、または法律の規定に関わらず、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
お客様ご自身の責任において、適用されるすべての著作権関連法規に従ったご使用を願います。このドキュメントのいかなる部分も、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。
マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその他の無体財産権に関する権利をお客様に許諾するものではありません。
別途記載されていない場合、このドキュメントで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、キャラクタ、データなどの名称は架空のものです。実在する会社名、団体名、製品名、ドメイン名、電子メール アドレス、ロゴ、個人名、場所名、などは一切関係ありません。
© 2007 Microsoft Corporation. All rights reserved.
Microsoft、Active Directory、Excel、Internet Explorer、OneNote、PowerPoint、SharePoint、Windows、および Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
その他、記載されている商標は、すべてそれぞれの所有者が権利を有しています。
ダウンロード
テクニカル ホワイト ペーパー
725 KB
Microsoft Word ファイル
PowerPoint プレゼンテーション (英語)
1.55 MB
Microsoft PowerPoint ファイル
現状
Microsoft のイントラネットに格納されている情報量が加速的に増加しており、情報検索の問題が深刻化しています。
ソリューション
Microsoft IT は Microsoft Office SharePoint Server 2007 の Enterprise Search 機能を展開し、関連情報検索の迅速化と容易化を図っています。
利点
Microsoft イントラネット上で関連コンテンツを検索する機能が向上します。
コンテンツの発行機能が高まり、コンテンツ検索が容易になります。
従業員や主要な連絡先の検索機能が改善されます。
基幹業務アプリケーションとの一体化が進んだ
検索機能と検索結果における一貫性が向上します。
エンタープライズ検索の管理作業の負荷が軽減します。
製品とテクノロジ
Microsoft Office SharePoint Server 2007 Enterprise Edition
Microsoft SQL Server 2005
Windows Server 2003