PR

数十万超の文書は分散処理で対処

 検索エンジンは基本的に,イントラネットのどこにあっても構わない。専用の検索サーバーを構築してもいいし,検索対象のサーバー上で稼働させてもいい。製品によっては三つのモジュールを分散させることができ,例えば社内ポータル・サーバーにサーチャーだけを組み込み,ほかのマシンで稼働するインデクサに検索要求を送るようにすることも可能だ(図2)。

図2●エンタープライズ・サーチ導入時のシステム構成例
図2●エンタープライズ・サーチ導入時のシステム構成例
ボトルネックになるモジュールを分散配置することで,ドキュメント数の増量や検索速度の向上を図る。  [画像のクリックで拡大表示]

 一番シンプルな構成は,クローラ,インデクサ,サーチャーを1台のサーバーで稼働させるもの。ただ耐障害性を考慮すると,冗長化を図り,負荷分散させるのが望ましい。

 検索対象の文書の数が増えてくると,インデクサによるインデックスの作成時間が延び,運用面で問題になる。通常,インデックスの更新は夜間などにバッチ処理する。文書の数が増えればインデックス作成作業が始業時間になっても終わらなくなる可能性が出てくる。そこで考えたいのは,それぞれのモジュールを別のサーバーで稼働させる方法である。アプライアンス製品を除くほとんどのエンタープライズ・サーチ製品は,役割ごとにサーバーを分けられる構造になっている。

 具体的には,クローラ,インデクサ,サーチャーを別々のサーバーに分散させ,さらにインデックスは複数のサーバーに分割する。検索時にはサーチャーが複数のインデクサに問い合わせた結果をマージしてユーザーに返す。こうしておけば文書数が増えた場合でも,インデックスを追加していくことで理論上は無制限に拡張できる。

 同時に,検索要求を出すユーザー数が増えてきた場合は,検索の応答処理にかかる負荷が高まる。この場合は,全く同じインデックスを持つインデクサを複数設置して,負荷分散させる。

アクセス制御の手法で応答性能が変わる

 エンタープライズ・サーチではセキュリティの観点から,ユーザーの権限に合わせて結果の表示内容を変える必要がある。このためエンタープライズ・サーチ製品は,LDAPサーバーActive Directoryといったディレクトリ・サービスを参照してユーザーの権限をチェックする仕組みを備えている。この権限と,それぞれの文書やサーバーに設定されているアクセス制御リスト(ACL)を付き合わせ,検索結果の表示内容を変える。

 注意が必要なのは,ACLの参照のしかたによって,サーチャーにかかる負荷やエンドユーザーへの応答性能が変わる点だ。方法は大別して2通りある。検索対象のサーバーにリアルタイムに問い合わせる方法と,各サーバーが持つACLをあらかじめインデックスにインポートしておく方法である(図3)。

図3●検索対象文書に対するアクセス制御の実装形態
図3●検索対象文書に対するアクセス制御の実装形態
検索結果を表示する際に,ユーザーがアクセス権を持つ文書のみを検索結果に表示する。

 リアルタイムに問い合わせる方法では,検索実行時にユーザーのアクセス権限と検索対象のACLを突き合わせ,検査結果からアクセス権限のない文書を取り除いた応答ページを作成する。最新のアクセス権を検索結果に反映できる点がメリットだが,ACLを持つサーバーへの問い合わせが多くなるため,検索結果が数千件に及ぶとエンドユーザーへの応答性能が劣化しやすい。

 ACLをインデックスにインポートする場合は,エンタープライズ・サーチのシステム内で検索処理が完結する。インデックス作成の負荷は高まるものの,社内システムのアクセス権が変わるのは,部署の異動や昇格など日単位のタイミングである。社内システムに限れば,1日に1回夜間に更新すれば,社内システムとエンタープライズ・サーチとの間で,アクセス制御について実用上のタイムラグが発生することはない。

 どちらの方法を選ぶかは,利用する製品によって決まる場合が多い。ほとんどの製品はACLにインデックスをインポートするようになっている。ただ,中にはインデックスにACLを取り込んだうえで,一部の検索対象についてだけリアルタイムに照合する仕組みを加えられる製品もある。