クラスター化されたElasticsearchインデックスシャードとレプリカのベストプラクティス

元々は2020年11月27日にObjectRocket.com/blogで公開されました。

Elasticsearch®は、デフォルト設定でクラスター全体にデータを分散するのに優れていますが、クラスターが成長し始めたら、効果を高めるためにデフォルト設定を調整する必要があります。シャーディングの基本をいくつか確認し、インデックス作成とシャードのベストプラクティスをいくつか紹介しましょう。

Elasticsearchシャーディングの概要

Elasticsearchシャードがどのように機能するかについては多くのドキュメントがありますが、シャーディングの基本的な概念は、検索が複数の部分で並行して動作できるように、データをいくつかの小さな部分に分割することです。インデックス関数のクラスタリングと並列化を容易にするために、Elasticsearchインスタンスの各インデックスを番号付きのスライスにスライスします。これらのスライスはシャードと呼ばれます。彼らの主な行動のいくつかを見てみましょう：

• 各シャードは、レプリカの数に応じて複製されます インデックスの設定。したがって、レプリカの数 1を設定すると、各シャードのコピーが2つあります。1つはプライマリ シャードと1つのレプリカ シャード。プライマリシャードはメインシャードであり、indexing/writeに使用されます およびsearch/read レプリカシャードはsearch/readにのみ使用されます。 操作と、プライマリに障害が発生した場合の回復のため。
• レプリカシャードは、親とは異なるホストに存在する必要があります プライマリシャード。
• シャードはデフォルトでクラスター内のホストの数に自動的に分散しますが、同じ物理ホストに複数のプライマリシャードが含まれる場合があります。 Elasticsearchの設定を使用して、この動作（リバランス、シャードの割り当てなど）を変更できますが、その手順はこの投稿の範囲を超えています。
• シャードは分割できないため、各シャードは1つのホストにのみ存在する必要があります。
• インデックスの作成中にインデックスが作成するシャードの数を設定することも、グローバルデフォルトを使用することもできます。インデックスを作成した後は、インデックスを再作成せずにシャードの数を変更することはできません。
• インデックスの作成中にインデックスが持つレプリカの数を設定することも、グローバルデフォルトを使用することもできます。インデックスを作成した後、この番号を変更できます。

小さな例を見てみましょう。シャード数が3、レプリカ設定が1のインデックスを作成しました。前の図でわかるように、Elasticsearchは6つのシャードを作成します。3つのプライマリシャード（Ap、Bp、およびCp）と3つのレプリカシャード（Ar、Br、およびCr）です。

Elasticsearchは、レプリカとプライマリが異なるホスト上にあることを確認しますが、同じホストに複数のプライマリシャードを割り当てることができます。ホストについては、シャードをホストに割り当てる方法について詳しく見ていきましょう。

シャードの割り当てとクラスター化されたElasticsearch

Elasticsearchは、デフォルトで利用可能なすべてのホストにシャードを割り当てようとします。 Rackspace ObjectRocketでは、各クラスターはマスターノード、クライアントノード、およびデータノードで構成されています。私たちのアーキテクチャのデータノードはバケットを形成します シャードを割り当てることができます。

前の例を使用して、これらの6つのシャードを取得し、2つのデータノード（最小）を持つObjectRocketforElasticsearchクラスターに割り当てます。次の図では、シャードごとに、プライマリが1つのデータノードに到達し、レプリカが他のノードに存在することが保証されていることがわかります。ここでの例は、可能な割り当てを1つだけ示していることに注意してください。割り当てに関係なく、唯一の明確なことは、レプリカが常にプライマリとは異なるデータノードに配置されることです。

次に、この例を拡張して、3番目のデータノードを追加しましょう。 2つのシャードが新しいデータノードに移動されるため、各ノードに2つのシャードがあることに注意してください。

最後に、シャード数が2で、レプリカの数が2に設定された、このクラスターに新しいインデックスを追加しましょう。これにより、次の画像に示すように、2つの新しいプライマリ（XpとYp）と4つのレプリカ（Xr0、Xr1、Yr0、Yr1）がクラスター全体に広がることができます。

それだけです。

落とし穴

Elasticsearchはあなたのためにすべての大変な仕事をしますが、避けるべきいくつかの落とし穴があります。

落とし穴＃1-大規模なインデックスと大規模なシャード

大規模なシャードを使用した大規模なインデックスのトラブルシューティングは、Elasticsearchで軽減するのが最も簡単な問題の1つです。ユーザーは、非常に管理しやすい単一のインデックスから始めます。ただし、アプリケーションが大きくなると、インデックスも大きくなります。シャードのサイズはクラスターデータの量に直接関係しているため、これは巨大なシャードにつながります。

これが引き起こす最初の問題は、クラスター使用率の効率が悪いことです。シャードが大きくなると、データノードに配置するのが難しくなります。そこにシャードを格納するには、データノードの空き領域の大きなブロックが必要です。この状態は、多くの未使用の無駄なスペースを持つノードにつながります。たとえば、8 GBのデータノードがあり、各シャードが6 GBの場合、各データノードで2GBをストランドします。 2番目の問題はホットスポッティングです 。データをいくつかのシャードに統合すると、複雑なクエリを多数のノードに分割して並行して実行することはできません。

インデックスにけちをつけないでください

複数のインデックスを使用して、停止したスペースの問題を解決します。データを複数のインデックスに分散して、クラスター内のシャードの数を増やし、データを均等に分散します。さらに、ゲームTetrisのように、Elasticsearchがシャードを配置すると、複数のインデックスをキュレートするのが簡単になります。 Elasticsearchのエイリアス機能により、複数のインスタンスをアプリに対して単一のインデックスとして表示することができます。ほとんどのElastic Stackは、デフォルトで毎日のインデックスを作成します。これは良い習慣です。次に、エイリアスを使用して検索範囲を特定の日付範囲に制限し、キュレーターを使用して古いインデックスを古くなったときに削除し、古いデータのインデックスを再作成しなくても、データの増加に応じてインデックス設定を変更できます。

インデックスサイズが大きくなるにつれてシャード数を増やします

インデックスをより頻繁に追加し、インデックスが大きくなるにつれてシャード数を増やします。シャードサイズが目的のスペースを超え始めたら、インデックステンプレート（または新しいインデックスの作成に使用するもの）を更新して、各インデックスにさらに多くのシャードを使用できます。ただし、これは、新しいインデックスを頻繁に作成する場合にのみ役立つため、この推奨事項2番目にリストされています。それ以外の場合は、インデックスを再作成してシャードカウントを変更する必要があります。これは、複数のインデックスを管理するよりも多くの作業を意味します。

経験則：シャードがデータノードのサイズの40％より大きい場合、そのシャードはおそらく大きすぎます。この場合、シャードの数が多いインデックスにインデックスを再作成するか、プランサイズを大きくする（データノードあたりの容量を増やす）ことをお勧めします。

落とし穴＃2-インデックスまたはシャードが多すぎます

逆は、インデックスまたはシャードが多すぎます。前のセクションを読んだ後、あなたはただこう言うかもしれません。すべてのドキュメントをインデックスに入れて、100万個のシャードを作成します。」そこにある問題は、インデックスとシャードにオーバーヘッドがあることです。そのオーバーヘッドは、ストレージ、メモリリソース、および処理パフォーマンスに現れます。

クラスタはすべてのシャードの状態とそれらが配置されている場所を維持する必要があるため、大量のシャードがより大きなブックキーピング操作になり、メモリ使用量に影響を与えます。また、クエリをより多くの方法で分割する必要があるため、クエリを分散または収集するためにより多くの時間を費やします。この落とし穴は、クラスターのサイズ、ユースケース、およびその他の要因に大きく依存しますが、一般的に、いくつかの推奨事項でこれを軽減できます。

シャードは50GB以下にする必要があります

一般に、25 GBは大きなシャードに理想的なサイズであり、50GBはインデックスの再作成が必要です。この考慮事項は、シャードのパフォーマンスと、必要に応じてそのシャードを移動するプロセスに関連しています。リバランスするときは、シャードをクラスター内の別のノードに移動します。50GBのデータ転送には時間がかかりすぎ、プロセス全体で2つのノードが拘束される可能性があります。

シャードサイズをデータノードサイズの40％未満に保ちます

前述のように、関心のある2番目のシャードサイズメトリックは、シャードが占めるデータノード容量のパーセンテージです。RackspaceObjectRocketサービスでは、データノードのストレージ量に関連するさまざまなプランサイズを提供します。最大のシャードがデータノードの容量の40％を超えないように、クラスターとシャードのサイズを調整してください。さまざまなサイズの複数のインデックスがあるクラスターでは、これはかなり効果的です。ただし、大きなインデックスがほとんどないクラスタでは、さらに積極的になり、データノードの容量を30％未満に維持しようとします。

理想的には、データノードの容量を制限していないことを確認してください。シャードがデータノードのサイズの約45％である場合、そのシャードを配置するには、使用率が約半分のデータノードが必要です。未使用の予備容量がたくさんあります！

結論

適切なシャードとインデックス設定を選択するのは難しい場合がありますが、計画を立て、事前にいくつかの適切な決定を行い、進行中に調整することで、クラスターを正常に維持し、最適に実行できます。私たちは、企業が常にElasticsearchinstancesを改良するのを支援します。

RackspaceDBAサービスの詳細をご覧ください。

コメントや質問をするには、[フィードバック]タブを使用します。 セールスチャットをクリックすることもできます 今すぐチャットして会話を始めましょう。