SolrCloudとは

FileBlogの検索エンジン（Solr）にあるSolrCloud機能を利用して、大規模ファイルサーバーを対象とした検索インデックスを構築することができます。

  • FileBlogが採用している検索エンジンは「Apache Solr」です。

  • 「Apache Solr」はオープンソースの検索エンジンであり世界中で広く普及しています。

SolrCloudは、Apache Solrが用意したスケールアウトソリューションの呼び名です。 互いに通信しあう複数台のSolrサーバーによってSolrCloudクラスタを構成することで、検索インデックスデータの分割とそれらを複数台のサーバーに分散配置させることができる機能です。

SolrCloudでは、検索インデックスデータを冗長化させたり分散配置させたりすることでデータの安全性担保や処理速度向上が期待でき、マシン1台のCPU・メモリ・ディスクの限界を超えた大きなインデックスを保持することを可能にします。

FileBlogでは冗長化や分散配置はせずとも、マシン1台でのSolrCloud機能利用でも十分に意味のあることと捉えています。

大規模インデックスデータの運用課題

Solrの検索インデックスデータは「コレクション」という論理的単位ごとに構築されます。

FileBlogの標準仕様は、全ドキュメントルートの全ファイルを単一のコレクション（検索インデックスデータ）として登録します。

大規模な検索インデックスを構築するとインデックスデータの肥大化によって次のような問題に直面します。

  • 検索エンジン（Solr）の起動・再起動に時間を要する
    Fb5Indexerサービスの起動時にインデクスデータのほぼ全量の読み込み処理があり、データサイズが大きいほど起動（読み込み）に時間を要します。

  • ハードディスクの運用が難しくなる
    ディスク容量が逼迫したときなど、インデックスデータの全てを一括して別のディスクへ移行するときに時間を要し、難易度があがります。

  • サーバーのリソース（メモリ/CPU）が不足する

  • インデックスデータの再構築や掃除に時間を要する
    定期的に検索エンジンに登録された全ファイルのリストをファイルサーバーに実存する全ファイルのリストと突合し、その差分を抽出して整合性をとっています。1回の処理に何日も何週間もかかるようになると定常運用が困難になります。

  • ドキュメントルートの追加/廃止の運用が難しい

    • 多数の共有フォルダを管理している現場では、部門の統廃合や業務の見直しによって共有フォルダの廃止や統合が行われる可能性があります。

    • 検索対象となっていたフォルダが廃止されると、当該フォルダにあったファイル情報を検索インデックスから取り除くのに時間を要します。

  • インデックスデータの破損による再構築に時間を要する
    インデックスデータが壊れると初期化が必要になり、初期化後のインデックスデータ初期構築には長時間を要します。

コレクション分割という解決策

上記のような問題に対処するために大規模環境向けにはSolrCloud機能を提供しています。

SolrCloudを有効にするとコレクション（検索インデックスデータ）をドキュメントルートフォルダ単位に分割することができます。

分割のメリット

  • ドキュメントルートが廃止されたときは、それに対応するコレクションを破棄することで検索インデックスのメンテナンスが瞬時に完了します。

  • 特定のドキュメントルートフォルダを選択して検索すれば、検索は1つのコレクション内で完結するため少ないリソース消費で高速な検索ができます。

分割のデメリット

  • トップで検索すると全コレクションで検索した結果をマージして表示するために処理時間を要します。

SolrCloud活用の解

検索エンジンは対象文書のテキストを読み込んで検索インデックス（索引情報）を構築します。この検索インデックスの作り方次第で検索性能には大きな差が生まれます。

たとえば、同じ1億文書でも「1億文書の巨大な索引 ✕ 1個」よりも「100万文書の小さな索引 ✕ 100個」の方が断然に扱いやすくなります。

本来のSolrCloudは複数台マシンを利用して処理を分散しますが、必ずしもSolrCloudの全機能を使うことはないと判断しています。

1台のマシンであってもSolrCloud環境を構築することに意味があります。FileBlogは一億超文書のファイルサーバー検索を1台のマシンで実現可能であり、1台のマシンでもSolrCloud環境を構築して運用することを推奨します。

1台でまかなえるうちは1台で運用する方がよいというのが現時点での結論です

1台のサーバーであっても十分なリソース（CPU・メモリ・ディスク容量）があれば処理は可能です。むしろ複数台に分散することは通信のオーバーヘッドなどによって処理効率が下がってしまいます。

可用性とコストのバランス

複数台に分散することの明らかなメリットはデータを冗長化・分散配置できることで、ハードウェア障害時に無停止運用ができるという点があります。しかしエンタープライズサーチ製品（FileBlog）の運用の性質上、24時間365日の無停止が至上命題というほどではありません。