エンタープライズサーチ導入の苦労

エンタープライズサーチは、なぜ高速か？

あらかじめ索引を作ってあるから速い

エンタープライズサーチを導入すれば、Googleがインターネット上からファイルを高速に見つけ出すように、お客様組織のファイルが、高速に検索できるようになります。

全文検索エンジンによる検索が高速なのは、キーワードを入力してからファイルを探すのではなく、あらかじめ全ファイルを一度読み込んで、索引を作ってあるためです。漢和辞典・国語辞典・百科事典など、辞書を速く引けるのは、50音順などに全体が並べ替えられていた李、巻末の索引が付加されているためであるのと同様です。

導入時のインデックス構築・日常のインデックス保守が必要

高速に検索できるようにするためには、索引の存在が重要です。一般的には、索引の構築、保守は下記のように行われます。

• エンタープライズサーチ製品の導入時に、全ファイルを一度読み込んで、索引を初期構築します
• その後は、定期的（毎週末だったり、毎晩だったり）に、全ファイルのタイムスタンプをチェックして新しいファイルを見つけ、索引を更新します
• 全ファイルのチェックを行う代わりに、ファイルサーバの変更をリアルタイムで検知できる場合には、それを利用して、リアルタイムでインデックスを最新状態に保ちます

エンタープライズサーチ運用、どこで苦労するか？

私たちがこれまでに導入支援してきたお客様は、約500社ほどに上りますが、FileBlog導入作業の流れは基本的に共通です。

どこで苦労するかも、実施する前の段階である程度読めるようになりました。

インデックス初期構築が一番苦労します

やはり、初めて検索エンジンを導入するときの、インデックス初期構築が一番大変です

単純にファイル数が多ければ、所要時間は比例的に大きくなります

多数のファイルがあって、目的のものが見つからないという理由で、エンタープライズサーチ製品は導入されます。ですから、相当な数のファイルがあるのは当たり前ではありますが、導入時に必要なインデックスの初期構築では、原則として必ず一度は全ファイルを読み取る必要があります。

そのため、ファイル数が膨大になれば、インデックス初期構築所要時間も大きくならざるを得ません。

一億文書以上の大量文書のインデクシングも、一台のマシンで処理できます

まずは良いニュースからお伝えします。近年のコンピュータの処理能力向上は著しいので、かつては1台の検索エンジンで扱える文書数は1千万文書程度でしたが、いまでは1台のマシンで1億文書を超えるような大量文書もインデクシングできるようになっています。（数千万文書クラスになった場合、メモリ大盛り、CPUコア数大盛りなど、それなりのスペックの物理マシンが必須になります）

このような状況ですので、ファイルサーバと検索エンジンとがともに同一LAN内にあれば、1000万文書未満ぐらいのエンタープライズ検索案件は、「中小規模」といってもよく、基本的には性能問題をあまり気にする必要がありません。

インデックス初期構築には、半日から1か月程度の期間がかかります

弊社では、お客様環境での導入規模ヒアリングにもとづいて、推奨マシンのスペックを回答しています。推奨構成のマシンがあれば、1000万文書未満の規模であれば、おおよそ、半日から1週間程度で、インデックスの初期構築が終わらせることが可能です。

マシンパワー不足は、性能低下の原因となります

FileBlogサーバは、インデックス初期構築を高速化するために、いくつかのチューニングパラメータを持っています。マシン性能が良いに越したことはありません。

• CPUコアが多数利用できるならば、同時並列的に処理できるファイル数を引き上げて、高速化が可能です。
• メモリが大量に利用できるならば、検索エンジンに割り当てるメモリを引き上げて、高速化が可能です。（少なすぎると、稼働不能になります）

このため、マシンパワーが不足してしまうと、当初の予想よりも処理時間が大きくなってしまいます。

例えば、仮想マシンを利用する場合には、物理マシンを用意した場合とくらべて、どうしてもマシンパワーに劣ってしまいますので、ご注意ください。

遠隔拠点ファイルサーバの、WAN越しインデクス構築は、遅い！

ネットワーク上の共有フォルダのインデックス構築は、ネットワークの通信速度が速いほど早く完了します。私たちは通常、1GbpsのLAN内で処理することを想定しています。

FileBlogは、複数のファイルサーバ上の複数の共有フォルダを扱えますが、時として、他拠点のファイルサーバをVPN越しにインデクシングしたいという場合があります。拠点間ネットワークは、拠点内LANとくらべてどうしても一桁以上低速ですので、インデックス構築所要時間も、10倍～50倍になってしまいます。ゆえに、原則としてFileBlogサーバとファイルサーバとは同一拠点にあるべきです。

ただし、FileBlogサーバを拠点数分運用するのも現実的ではありませんので、遠隔インデックスも、少量であれば致し方ないでしょう。どうしてもインデックス構築の所要時間が長くなりますので、初期導入時のスケジュールには余裕を持たせてください。LAN内で3日間で終わるものが、WAN越しでは数週間かかるかもしれません。また、定常運用に入ってからもインデックスの定期的な更新が必要です。このときのインデックス差分更新の所要時間も伸びてしまいます。LAN内のフォルダは毎週一回インデックス差分更新するという場合でも、他拠点のファイルのインデックス差分更新は隔週に一回や1か月に一回など、頻度を減らす必要があるかもしれません。（インデックス更新頻度を減らすと、最新ファイルが検索結果から漏れる可能性が高まりますが、遅いネットワークの弊害として受け入れてください。）

あくまで目安ですが、数十万件の小規模ならば問題は小さいでしょう。ぎりぎり200万文書未満程度であれば、何とか運用できると思います。

（詳しい実績データなどはお問い合わせください）

ファイルサーバ暗号化との相性で苦労

機密データの漏洩を防止するために、ファイル暗号化ソリューションを導入しているお客様が近年ちらほらと増えています。暗号化ソリューションを導入すると、ファイルサーバ上のファイルが暗号化されて保管され、許可を与えられたユーザがファイルを読み出す都度、暗号の復号化（解読）が行われる仕組みとなっています。そのため、ファイルを単純にコピーして持ち出しても、暗号が解読できなければデータが漏洩しないようになります。ファイルアクセスの都度、復号化が発生するために、性能を犠牲にして安全性を高めている方式といえます。

暗号化されたファイルは、検索エンジンにとっても簡単には読みだせません。全文検索エンジンが使えなくなってしまうことも普通です。FileBlogは、インデックス構築時に1ファイルづつ復号化してインデックスを構築する方式で、いくつかの暗号化ソリューションに対応してきましたが、ファイルの読出しは通常よりも大幅に遅くなります。

ファイルのプレビュー作成も性能が低下しますし、セキュリティと利便性はそもそも相反するものなので、ファイルを見やすくするプレビュー機能は、暗号化ソリューションとの組み合わせでは無効化したほうがよいでしょう。

その他導入時に苦労するポイント

アクセス権限不足でファイルが見えない

FileBlogサーバは、インデックス構築のために全ファイルを一度読み取る必要があります。そのためのアクセス権限を有するユーザのIDとパスワードを入力いただきますが、私たちが導入支援でお客様を訪問した際に、肝心のパスワードがわからない、ということが時々あります。

お客様自身がパスワード設定しているのではなく、協力会社がシステム管理を行っている場合や、親会社のネットワーク管理者が管理しているという場合で、管理者さんと連絡がつかない場合には、そこで数時間待ったり、出直してもう一度訪問したりする必要があります。

技術的には何も難しいことではありませんが、徒労はこたえます。

シングルサインオン環境の構築

FileBlogではWindows統合認証（Windows PCにログインしたユーザアカウントで、そのままログインできるようにする）や、SAML認証（Office365のユーザ認証など、Active Directoryドメインと連動した外部のIdP（認証・認可インフラ）を用いたシングルサインオンを実現する）を利用することが可能です。

Windows統合認証の試験は、端末の「インターネットオプション」で、ローカル・イントラネットゾーンの設定が必要です。個々の端末で設定変更できる場合は問題ありませんが、グループポリシーで設定を集中管理している場合には、ポリシーの変更ができるドメイン管理者さんにお願いして設定変更が必要になります。

また、SAML認証のほうは、クラウドアプリ側の設定との連携をとる必要があります。セキュリティにかかわる設定は、（悪意ある攻撃者に手掛かりを与えないようにするため）エラーメッセージが不親切という傾向があるので、骨が折れる設定作業になりがちですが、それでも、最後までサポートします。

ドメインネットワーク・ファイヤウォール問題

FileBlogは、Windows Active Directoryドメインのユーザ認証に連動します。また、親会社／小会社や、本社／工場／研究所など、拠点ごとに独立のドメインを運用していて、相互に信頼関係を結んでいる環境でも動作します。

ただし、ドメインコントローラが複数台ある環境では、原則としてすべてのドメインコントローラとの通信ができるように、ファイヤウォールはじめとするネットワーク環境が整備されている必要があります。

なぜか、特定のドメインのユーザがログインに失敗したり、時々ログインできたり・できなかったりする、というようなトラブルの場合、原因はFileBlogのアプリケーションというよりも、ドメイン環境・ネットワーク環境のほうにあることが普通です。AD、DNSやルータ・ファイやウォールの管理者さんと直接話し合って、地道に一歩づつ調査して問題解決する必要があります。

日々の運用で苦労するポイント

軌道に乗ってしまえば、基本的にはノートラブルで運用できることが多いといえますが、時々悩まされるポイントを紹介します。

アクセス集中問題

一般的な企業ユースにおいて、FileBlogのWebアプリが過負荷でフリーズするようなことはめったにありませんが、学生さんに多数のアカウントを発行している学校での運用では、時として短時間に大量のアクセスが集中することがあります。

この手のトラブルは、とにかく4月に起こることが多いです。

初回の授業オリエンテーションで、使い方を説明しているその場で、大教室の全員がログインを試みるというのは、システムに対するDoSアタックなので、100人ほどがタイミングを合わせて同時にアクセスすると、応答が返されずにエラーとなるユーザさんが発生してしまうことがあります。

パラメータチューニングによって、ある程度は予防できますが、5月中旬をすぎると、この手のトラブル報告は不思議と消えてしまいます。一方、一般企業ユーザでライセンス数が不足してしまうのは、正月休み明け・四月1日・十月1日・お盆休み明けということが多いです。

巨大ファイル問題

全文検索エンジンにとって、容量の大きなファイルは、時として重荷となります。

たとえば動画ファイルなどは、サイズが大きいだけで、テキスト情報を持たず、ファイル名検索の対象にしかなりませんから、サイズは問題になりません。

しかし、Excelワークブックで作られた、十万人分の名簿ファイルだったり、辞書データをエクスポートしたテキストファイルであったり、分厚い書籍を丸ごと電子化した数百ページ以上あるPDFファイルだったり、そいういう巨大ファイルには、何十万語という大量のテキスト情報が含まれます。（多くの企業でよく見つかるのは、全国の郵便番号と市区町村名の一覧データや、全国の金融機関名と支店の一覧や、などです）

実際にこれら巨大ファイルを検索で見つけたいことは稀ですが、世に「80対20の法則」として知られているとおり、ファイルサーバ内の全文書のごく一部の巨大ファイル内のテキストのために、検索インデックスの大部分が埋め尽くされてしまうことがあります。

そこでFileBlogでは、一定サイズ（デフォルトでは32Mバイト）以上の大きなファイルはインデックス構築時に無視するように設定することができ、少数の例外的に巨大なファイルによってインデックスの総量が肥大化するのを防ぐ安全装置の役割を果たしています。