SolrCloud冗長構成はいらない？
SolrCloudは、24時間365日連続稼働を宿命付けられたミッションクリティカルなシステムでの利用を可能にするために進化してきた分散検索システムです。検索インデックスを複製して多数のノードに配置する（冗長構成を取る）ことで、少数のノードにハードウェア障害がおきても検索システム全体としてはデータを失わず、機能を停止すること無く稼働を続けることが可能です。
冗長構成にはもちろんメリットがありますが、ハードウェアを余計に必要とするため、環境構築の費用は間違いなく高くつきます。FileBlogの目的である「ファイルサーバ全文検索」は、24時間365日、１分間の停止も許されないほどの要件では必ずしもありません。ファイルサーバ検索エンジンにそこまでの可用性は、やりすぎではないか？と私たちは考えました。
「レプリカを１つしか持たない構成が可能です」
レプリカを持てばデータの安全が保てます。SolrCloudの教科書的な資料を見ると、いずれもレプリカを複数ノード上に持ってインデックスデータを冗長化している例が目立ちます。
しかし、ファイルサーバ全文検索システムにおいては、ファイルサーバ上の元ファイルさえ無事であれば、検索システムが持つインデックスデータに障害が発生しても、元ファイルを参照してインデックスデータを再構築することが可能です。ただただ時間がかかるかもしれませんが、時間だけの問題です。
そこで、FileBlogのSolrCloud管理機能では、デフォルトでレプリカを持たないで検索インデックスを構築するようにしています。
RAIDにはJBOD/RAID0/RAID1/RAID5などいろいろがありますが、冗長性の無いRAID0やJBODも用途に応じて利用されているように、SolrCloudでもレプリカ無し構成を使う意味はあるのです。
Zookeeperを1台の簡易構成に省略できます
SolrCloudを構成する場合、複数ノードが協調して動作するためのコーディネイトを行うためにミドルウェアとしてzookeeperが使用されます。無停止が求められるミッションクリティカル環境では、3台の独立のハードウェアにzookeeperをインストールする必要があります。そうしておけば、3台中1台が故障しても大丈夫です。
しかし、ファイルサーバ検索を実現するために、FileBlogサーバと合わせて4台ものマシンが必要というのでは、現実的ではありません。
実際にはFileBlogが稼働するサーバ1台にzookeeperを同居させ,1台構成のzookeeperでSolrCloudを立ち上げることが可能です。開発環境・テスト環境など、高可用性が求められない環境に限定される構成ですが、この構成で本番運用してはいけないなんていうルールはありません。
zookeeperを1台だけで稼働させた場合、その1台がクラッシュすればSolrCloudとしては機能不全状態となりますが、個別の全文検索エンジンは動き続け、インデックスは無傷で残ります。広範囲にわたる横断的検索は不可能となりますが、復旧は時間の問題です。
高可用性を諦めれば、3台少ないマシンでSolrCloudを構築できるのです。
