Solrクラスタの種類

Solrクラスタは、それぞれSolrを実行するサーバー(ノード)のグループです。

Solrノードクラスタを運用する一般的なモードは2つあります。1つのモードはSolrノードの中央制御を提供し(SolrCloudモード)、もう1つのモードは、この中央制御なしでクラスタを運用することを可能にします(ユーザー管理モード)。

どちらのモードも一般的な概念を共有していますが、最終的には、それらの概念が機能と特徴にどのように反映されるかが異なります。

まず、いくつかの一般的な概念を説明し、次に2つのモードの違いの概要を説明します。

クラスタの概念

シャード

どちらのクラスタモードでも、単一の論理インデックスはノード間でシャードとして分割できます。各シャードには、全体のインデックスのサブセットが含まれています。

シャードの数は、Solrにインデックスできるドキュメント数の理論上の上限を示します。また、個々の検索リクエストで可能な並列処理量も決定します。

レプリカ

各シャードにフェイルオーバーを提供するために、各シャードはレプリカとしてコピーできます。レプリカは、シャードと同じ構成と、同じインデックスの他のレプリカと同じ構成を持ちます。

シャードを作成せずにレプリカを持つことが可能です。この場合、各レプリカは全体のインデックスの完全なコピーになり、全体のインデックスの一部のコピーだけではありません。

レプリカの数は、ノード障害が発生した場合のクラスタ全体のフォールトトレランスのレベルを決定します。また、重い負荷の下で処理できる同時検索リクエストの理論上の上限も決定します。

リーダー

レプリカが作成されると、リーダーを特定する必要があります。リーダーの役割は、各レプリカの真実の源となることです。インデックスへの更新が行われると、まずリーダーによって処理され、次に各レプリカによって処理されます(これを行う方法の正確なメカニズムは異なります)。

リーダーではないレプリカはフォロワーです。

コア

リーダーまたはフォロワーのいずれであっても、各レプリカはコアと呼ばれます。複数のコアを1つのノードにホストできます。

SolrCloudモード

SolrCloudモード(「SolrCloud」とも呼ばれる)は、Apache ZooKeeperを使用して、その主要な機能である集中クラスタ管理を提供します。ZooKeeperは、クラスタの各ノードと、各ノード上の各コアの状態を追跡します。

このモードでは、設定ファイルは各ノードのファイルシステムではなく、ZooKeeperに保存されます。設定が変更された場合、ZooKeeperにアップロードする必要があり、ZooKeeperは各ノードに変更が行われたことを確実に通知します。

SolrCloudは、新たな概念としてコレクションを導入します。コレクションとは、インデックスを表すコアの全体グループであり、論理シャードと各シャードの物理レプリカを含みます。コレクションはすべて、同じ設定(スキーマ、solrconfig.xmlなど)を共有します。これは、コレクション全体に対して一度に操作を実行できるため、クラスタ管理のさらなる集中化となります。

設定に変更を加えた場合、コレクションをリロードする単一のコマンドによって、コレクションのメンバーである各コアが自動的にリロードされます。

シャーディングは、コレクション作成時にSolrに希望するシャード数を指定するだけで自動的に処理されます。その後、インデックスの更新は一般的に各シャード間で自動的にバランスされます。必要に応じて、どのシャードにどのドキュメントを保存するかをある程度制御することも可能です。

ZooKeeperは、ロードバランシングとフェイルオーバーも処理します。ドキュメントのインデックス作成またはユーザクエリに対する着信要求は、クラスタの任意のノードに送信でき、ZooKeeperが要求を各シャードの適切なレプリカにルーティングします。

SolrCloudでは、リーダーは柔軟で、リーダーの障害発生時に自動的なリーダー選出を行うメカニズムが組み込まれています。つまり、別のコアがリーダーになることができ、その時点からすべてのレプリカの真実の情報源となります。

関連する各シャードのレプリカが1つでも使用可能な限り、SolrCloudモードで実行している場合でも、ユーザクエリやインデックス作成要求を満たすことができます。

ユーザ管理モード

Solrのユーザ管理モードでは、SolrCloudが通常ZooKeeperを使用するクラスタ調整アクティビティを手動またはローカルスクリプトで実行する必要があります。

ドキュメントのコーパスが単一シャードのインデックスに対して大きすぎる場合、シャードを作成するロジックは完全にユーザに委ねられます。インデックス作成中にSolrがシャードを自動的に作成するプログラムによる方法はありません。

ドキュメントのシャードへのルーティングは、単純なハッシングシステムまたは、各ドキュメントを異なるシャードに送信するシャードの単純なラウンドロビンリストを使用して手動で処理されます。ドキュメントの更新は正しいシャードに送信する必要があります。そうでないと、ドキュメントが重複する可能性があります。

ユーザ管理モードでは、リーダーとフォロワーの概念が重要になります。どのノードがリーダーレプリカをホストし、どのノードがレプリカになるかを特定することで、各ノードの設定方法が決まります。このモードでは、すべてのインデックス更新はリーダーのみに送信されます。リーダーがインデックス作成を完了すると、レプリカはインデックス更新を要求し、リーダーからそれらをコピーします。

ロードバランシングは、要求トラフィックをリーダーまたはそのレプリカのいずれかだけで管理できる場合を除き、外部ツールまたはプロセスによって実現されます。

リーダーがダウンした場合、組み込みのフェイルオーバーメカニズムはありません。クエリが特定のレプリカに送信された場合、そのレプリカはクエリを処理し続けることができます。レプリカをリーダーとして機能させるには、すべてのレプリカのsolrconfig.xml設定を変更し、各コアをリロードする必要があります。

ユーザ管理モードにはコレクションの概念がないため、事実上、各Solrノードは他のノードとは別個です。いくつかの設定パラメータだけが、各ノードが独立したエンティティとして動作するのを防ぎます。