ElasticSearchでロードバランサーを使用する必要はありませんか？
AWS EC2で実行されている3つのElasticSearchノードのクラスターがあります。これらのノードは、OpsWorks/Chefを使用してセットアップされます。私の意図は、このクラスターを非常に回復力と弾力性があるように設計することです（必要に応じてノードが出入りできます）。
ElasticSearchについて読んだすべてのことから、クラスターの前にロードバランサーを配置することを誰も推奨していないようです。代わりに、推奨事項は次の2つのいずれかを実行することです。
1つのノードのURL/IPにクライアントを向け、ESに負荷分散を行わせ、そのノードがダウンしないようにします。
すべてのノードのURL/IPをクライアントアプリにハードコーディングし、アプリにフェールオーバーロジックを処理させます。
私のバックグラウンドは主にWebファームで、そこでは自律Webサーバーの巨大なプールを作成し、それらの前にELBをスローし、ロードバランサーにどのノードが生きているか死んでいるかを判断させるのが常識です。 ESがこの同じアーキテクチャをサポートしていないように見えるのはなぜですか？
ロードバランサーは必要ありません— ESはすでにその機能を提供しています。誤動作する可能性があり、不必要なネットワークホップを追加する可能性がある別のコンポーネントになります。
ESはデータを分割し（デフォルトでは5つの断片に分割）、インスタンス間で均等に分散しようとします。あなたの場合、2つのインスタンスには2つのシャードと1つだけのシャードが必要ですが、均等に分配するためにシャードを6に変更することができます。
デフォルトでは、レプリケーションは"number_of_replicas":1に設定されているため、各シャードのレプリカが1つです。 6つのシャードを使用していると仮定すると、次のようになります（Rは複製されたシャードです）。
- node0：1、4、R3、R6
- node1：2、6、R1、R5
- node2：3、5、R2、R4
Node1が停止すると仮定すると、クラスターは次のセットアップに変更されます。
- node0：1、4、6、R3 +新しいレプリカR5、R2
- node2：3、5、2、R4 +新しいレプリカR1、R6
接続設定に応じて、1つのインスタンス（トランスポートクライアント）に接続するか、クラスターに参加できます（ノードクライアント）。ノードクライアントを使用すると、常に正しいシャード/インデックスに接続するため、二重ホップを回避できます。トランスポートクライアントを使用すると、リクエストは正しいインスタンスにルーティングされます。
そのため、負荷を分散する必要はありません。オーバーヘッドを追加するだけです。自動クラスタリングはおそらくESの最大の強みです。
Elasticsearchクラスターの負荷分散は良いアイデアだと思います（単一ノードの障害に強いフォールトトレラントシステムを設計する）。
クラスターを設計するには、Elasticsearchの2つの主要な機能の背景が必要です。1。ドキュメントの作成と更新、2ドキュメントのクエリ。
elasticsearchでのドキュメントの作成/インデックス作成：
- 新しいドキュメントがインデックス化されるElasticsearchに来ると、Elasticsearchは、「シャードルーティングアルゴリズム」を使用して、ドキュメントに割り当てる「プライマリシャード」を決定します。
- シャードに関連付けられたLuceneプロセスは、ドキュメント内のフィールドを「マッピング」します。
- Luceneプロセスは、ドキュメントをシャードのLuceneの「逆インデックス」に追加します
- 次に、「レプリカシャード」がドキュメントを受け取ります。レプリカシャードはドキュメントを「マッピング」し、レプリカシャードのLucene「反転インデックス」にドキュメントを追加します
Elasticsearchのドキュメントのクエリ：
- デフォルトでは、クエリがElasticsearchに送信されると、クエリはノードにヒットします。これは、そのクエリの「クエリノード」または「ゲートウェイクエリノード」になります
- ノードは、インデックス内のすべてのシャード（プライマリレプリカ）にクエリをブロードキャストします
- 各シャードは、シャードのローカルLucene逆索引に対してクエリを実行します。
- 各シャードは、上位10〜20の結果を「ゲートウェイクエリノード」に返します。
- 「ゲートウェイクエリノード」は、他のシャードから返された結合結果に対してマージソートを実行します。
- マージソートが終了すると、「ゲートウェイクエリノード」が結果をクライアントに返します
- マージソートはCPUとメモリのリソースが重い
書き込み/インデックス作成/更新のためにロードバランサーを設計する
Elasticsearchは、ノード上のシャードの場所を自己管理します。 「マスターノード」は、「シャードルーティングテーブル」を保持および更新します。 「マスターノード」は、シャードルーティングテーブルのコピーをクラスター内の他のノードに提供します。
一般的に、マスターノードがクラスターのヘルスチェックやルーティングテーブルの更新、シャードの管理以上のことを行うのは望ましくありません。
「データノード」（データノードはデータ=シャードを含むノード）への書き込み用にロードバランサーを指定し、データノードがシャードルーティングテーブルを使用して正しいシャードへの書き込みを取得できるようにすることをお勧めします。
クエリのアーキテクティング
Elasticsearchは、「データなし」を含む「クライアントノード」という特別なノードタイプを作成し、「マスターノード」になることはできません。クライアントノードの機能は、クエリの最後に最終リソースの大量マージソートを実行することです。
AWSの場合、おそらく「クライアントノード」としてc3またはc4インスタンスタイプを使用します。
ベストプラクティスは、クエリのロードバランサーをクライアントノードに向けることです。
乾杯！
参照：
「フェイルオーバー」用に設計することは非常に正しいことです。AWSでは、これを行うことをお勧めします。
1）マスターに選出できるクラスター内のノードを制限します。残りについては、node.client：trueを設定します。選択可能なマスター選択可能ノードの数は、フェイルオーバーに使用可能な数に基づいて選択します。
2）マスター選択可能ノードのみを含むELBを作成します。
3）Route 53で、クラスターのCNAMEを作成し、値をELBのDNS名に設定します。