1. _mapping APIを使用してフィールド情報を取得する

2. _search APIを使用してフィールド値を表示する

3. パラメータ を使用してフィールドをフィルタリングするfields

4. ネストされたフィールドの表示

1. _mapping APIを使用してフィールド情報を取得する

_mapping API を使用すると、1 つまたは複数のインデックスのマッピング定義を取得できます。これには、フィールド、そのデータ型、およびその他のプロパティに関する情報が含まれます。特定のインデックスのマッピングを取得するには、次のリクエストを使用します。

たとえば、 my_indexという名前のインデックスがある場合、次のリクエストでそのマッピングを取得できます。

応答には、フィールドとそのプロパティに関する情報を含むインデックスのマッピング定義が含まれます。

特定のフィールドのマッピングを取得することもできます。これは、マッピングが非常に大きく、特定のフィールドにのみ焦点を当てたい場合に便利です。特定のフィールドのマッピングを取得するには、次のリクエストを使用します。

次のリクエストのように、フィールド名をコンマで区切ることで、複数のフィールドのマッピングを取得することもできます。

2. _search APIを使用してフィールド値を表示する

Elasticsearch インデックス内のフィールドの値を表示するには、 _search API を使用できます。デフォルトでは、 _search API は、インデックスが作成された元の JSON ドキュメントを含む_sourceフィールドを返します。特定のフィールドのみを表示するには、検索リクエストで_sourceパラメータを使用できます。

以下は、 my_indexインデックス内のドキュメントのtitleフィールドとauthorフィールドの値を返す検索要求の例です。

この例では、 _sourceパラメータは返されるフィールドを指定します。

3. フィールドパラメータを使用してフィールドをフィルタリングする

fieldsパラメータを使用して、検索応答で返されるフィールドをフィルタリングすることもできます。これは、特定のフィールドのみが必要で、応答のサイズを縮小したい場合に役立ちます。fieldsパラメータは、フィールド名またはワイルドカード パターンの配列を受け入れます。

たとえば、 my_indexインデックス内のドキュメントのtitleフィールドとauthorフィールドのみを返すには、次の検索リクエストを使用できます。

ソース ドキュメントを返さないように、 _sourceパラメータは false に設定されていることに注意してください。

textデータ型のすべてのフィールドを返すには、次のようなワイルドカード パターンを使用できます。

4. ネストされたフィールドの表示

インデックスにネストされたフィールドが含まれている場合は、ドット表記を使用して、 fieldsパラメータでネストされたフィールド パスを指定できます。たとえば、 address.cityという名前のネストされたフィールドがある場合、次のように検索応答に含めることができます。

この例では、検索応答にはtitle 、 author 、およびaddress.cityフィールドの値が含まれます。

まとめ

結論として、Elasticsearch インデックス内のフィールドを表示するには、 _mapping API を使用してフィールド情報を取得し、 _search API を使用してフィールド値を表示します。_sourceまたはfieldsパラメータを使用して検索応答で返されるフィールドをフィルタリングし、ドット表記を使用してネストされたフィールドを表示できます。これらの手法は、データの構造を理解し、特定のフィールドを識別し、問題のトラブルシューティングを行うのに役立ちます。

透かしの背景

Elasticsearch クラスターには、使用可能なディスク容量を追跡するのに役立つさまざまな「ウォーターマーク」しきい値があります。ノード上のディスクがいっぱいになると、最初に超えるしきい値は「低ディスク ウォーターマーク」になります。2 番目のしきい値は、「高ディスク ウォーターマークしきい値」になります。最終的には、「ディスク洪水段階」に到達します。このしきい値を超えると、クラスターは、ウォーターマークを通過したノード上の 1 つのシャード (プライマリまたはレプリカ) を持つすべてのインデックスへの書き込みをブロックします。読み取り（検索）は引き続き可能です。

ディスクがいっぱいになった場合（過剰使用）の防止と対処方法

Elasticsearch ディスクがいっぱいになった場合の対処方法はいくつかあります。

1. 古いデータ を削除する: 通常、データを無期限に保存しないでください。ディスクがいっぱいになるのを防ぎ、解決する 1 つの方法は、データが一定の期間に達したときに確実にアーカイブされ、削除されるようにすることです。これを行う 1 つの方法は、 ILM を使用することです。

2. ストレージ容量の追加:データを削除できない場合は、パフォーマンスに悪影響を与えずにすべてのデータを保持するために、データ ノードを追加するか、ディスク サイズを増やす必要がある場合があります。クラスターにストレージ容量を追加する必要がある場合は、ストレージ容量だけを追加するのか、それともストレージ容量に加えて RAM と CPU のリソースも比例して追加するのかを検討する必要があります (以下のディスク サイズ、RAM、CPU の比率に関するセクションを参照)。

Elasticsearch クラスターにストレージ容量を追加する方法

1. データ ノードの数を増やします。新しいノードは既存のノードと同じサイズで、同じ Elasticsearch バージョンである必要があることに注意してください。

2. 既存のノードのサイズを増やす:クラウドベースの環境では、通常、既存のノードのディスク サイズと RAM/CPU を増やすのは簡単です。

3. ディスク サイズのみを増やす:クラウドベースの環境では、ディスク サイズを増やすのは比較的簡単です。

4. スナップショット そして 復元:要求に応じて古いデータを自動プロセスでバックアップから取得できるようにする場合は、古いインデックスのスナップショットを作成し、それらを削除して、要求に応じてスナップショットからデータを一時的に復元できます。

5. シャードごとのレプリカの数を減らす:データを削減するもう 1 つのオプションは、各シャードのレプリカの数を減らすことです。高可用性を実現するには、シャードごとに 1 つのレプリカを用意する必要がありますが、データが古くなると、レプリカなしでも作業できる可能性があります。これは通常、データが永続的である場合、または必要に応じて復元できるバックアップがある場合に機能します。

6. アラートを作成する:将来ディスクがいっぱいになるのを防ぎ、積極的に対処するには、ディスクの使用状況に基づいて、ディスクがいっぱいになり始めたときに通知するアラートを作成する必要があります。

ディスク容量が十分に活用されない場合の防止と対処方法

ディスク容量が十分に活用されていない場合は、クラスター上のストレージ ボリュームを削減するさまざまなオプションがあります。

Elasticsearch クラスターのストレージ容量を削減する方法

クラスターのストレージ容量を削減する方法はさまざまです。

1. データノードの数を減らす

データストレージを削減し、RAM と CPU リソースも同じ割合で削減したい場合は、これが最も簡単な戦略です。不要なノードを廃止すると、最大のコスト削減が実現する可能性があります。

ノードを廃止する前に、次の操作を行う必要があります。

• 廃止するノードが MASTER ノードとして必要ではないことを確認します。常に、MASTER ノード ロールを持つノードが少なくとも 3 つ必要です。

• 廃止するノードからデータ シャードを移行します。

2. 既存のノードを小さなノードに置き換える

ノードの数をさらに減らすことができない場合 (通常、最小構成は 3 です)、既存のノードのサイズを縮小することが必要になる場合があります。シャードはノードあたりのシャード数に基づいてバランスが取られるため、すべてのデータ ノードが同じ RAM メモリとディスク サイズであることを確認することをお勧めします。

プロセスは次のようになります。

• クラスターに新しい小さなノードを追加する

• 廃止するノードからシャードを移行する

• 古いノードをシャットダウンする

3. ノード上のディスクサイズを減らす

クラスターの全体的な RAM または CPU を変更せずに、ノード上のディスク サイズのみを削減したい場合は、各ノードのディスク サイズを削減できます。Elasticsearch ノード上のディスク サイズを縮小するのは簡単なプロセスではありません。

最も簡単な方法は通常次のようになります。

• ノードからシャードを移行する

• ノードを停止する

• 適切なサイズの新しいデータボリュームをノードにマウントします

• 古いディスクボリュームから新しいボリュームにすべてのデータをコピーします

• 古いボリュームAを切り離す

• ノードを起動し、シャードをノードに戻す

これには、このプロセス中にノードからの追加シャードを一時的に保存するのに十分な容量が他のノードに必要です。多くの場合、このプロセスの管理にかかるコストは、ディスク使用量の潜在的な節約額を上回る可能性があります。このため、必要なディスク サイズを持つ新しいノードにノード全体を置き換える方が簡単な場合があります (上記の「既存のノードをより小さなノードに置き換える」を参照)。

不要なリソースに料金を支払う場合、リソースの使用率を最適化することでコストを削減できることは明らかです。

ディスクサイズ、RAM、CPUの関係

クラスター内のディスク容量と RAM の理想的な比率は、特定のユースケースによって異なります。このため、ストレージ容量の変更を検討する際には、現在のディスク/RAM/CPU の比率が適切にバランスされているかどうか、また、その結果として RAM/CPU を同じ比率で追加/削減する必要があるかどうかも考慮する必要があります。

RAM と CPU の要件は、インデックス作成アクティビティの量、クエリの数と種類、さらに検索および集約されるデータの量によって異なります。これは多くの場合、クラスターに保存されるデータの量に比例するため、ディスク サイズにも関連している必要があります。

ディスク容量と RAM の比率は、使用事例に応じて変わる可能性があります。ここでいくつかの例をご覧ください:

インデックスアクティビティ

保持

検索アクティビティ

ディスク容量

ラム

エンタープライズ検索アプリ

中程度のログ摂取

長さ

ライト

2TB

32GB

アプリ監視

集中的なログ取り込み

短い

ライト

1TB

32GB

電子商取引

軽量データインデックス

不定

重い

500GB

32GB

ノード マシンの構成の変更は、ノードのダウンタイムが発生する可能性があり、すでに過剰に負荷がかかっている他のノードにシャードが移行しないようにする必要があるため、慎重に行う必要があることに注意してください。

Elasticsearchにおけるレプリカの役割

Elasticsearch では、インデックスは複数のプライマリ シャードに分割されたドキュメントのコレクションです。各プライマリ シャードは自己完結型の Apache Lucene インデックスであり、インデックス内のドキュメントはすべてのプライマリ シャードに分散されます。高可用性とデータの冗長性を確保するために、Elasticsearch では各シャードにレプリカと呼ばれる 1 つ以上のコピーを持たせることができます。number_of_replicas設定は、Elasticsearch がインデックス内の各プライマリ シャードに対して作成するレプリカ シャード (コピー) の数を制御します。デフォルトでは、Elasticsearch はプライマリ シャードごとに 1 つのレプリカを作成しますが、これはシステムの要件に応じて変更できます。

number_of_replicas の設定

number_of_replicas設定は、インデックスの作成時に構成することも、後で更新することもできます。インデックス作成時に設定する方法は次のとおりです。

この例では、Elasticsearch はmy_indexインデックス内のプライマリ シャードごとに 2 つのレプリカを作成します。

既存のインデックスのnumber_of_replicas設定を更新するには、 _settings API を使用できます。

このコマンドは、 my_indexインデックスを更新して、プライマリ シャードごとに 3 つのレプリカを作成します。

number_of_replicas設定の影響

number_of_replicas設定は、Elasticsearchクラスターのパフォーマンスと復元力に大きな影響を与えます。考慮すべき重要なポイントは次のとおりです。

1. データの冗長性と可用性: number_of_replicasを増やすと、各シャードのコピーがさらに作成され、データの可用性が向上します。ノードに障害が発生した場合でも、Elasticsearch は残りのノード上のレプリカ シャードからデータを提供できます。

2. 検索パフォーマンス:レプリカ シャードは読み取り要求を処理できるため、レプリカの数を増やすと、負荷がより多くのシャードに分散され、検索パフォーマンスが向上します。

3. 書き込みパフォーマンス:ただし、各書き込み操作はシャードのすべてのコピーに対して実行する必要があります。したがって、 number_of_replicas大きくすると、書き込みごとに実行する必要がある操作の数が増えるため、インデックス作成のパフォーマンスが低下する可能性があります。

4. ストレージ要件:レプリカが増えると、ストレージ容量も増えます。追加のレプリカを保存するのに十分な容量がクラスターにあることを確認する必要があります。

5. ノード障害に対する耐性:クラスター内のノードの数を考慮してnumber_of_replicasを設定する必要があります。number_of_replicasがノード数以上である場合、クラスターはデータ損失なしで複数のノードの障害を許容できます。

number_of_replicas の設定に関するベストプラクティス

最適なnumber_of_replicas設定は、システムの特定の要件によって異なります。ただし、一般的なベストプラクティスをいくつか示します。

• 単一ノード クラスターの場合、レプリカを保持する他のノードがないため、 number_of_replicas 0 に設定する必要があります。

• マルチノード クラスターの場合、データの冗長性と高可用性を確保するために、 number_of_replicas少なくとも 1 に設定する必要があります。

• 検索パフォーマンスを優先する場合は、 number_of_replicasを増やすことを検討してください。ただし、書き込みパフォーマンスとストレージ要件とのトレードオフに留意してください。

• クラスターに追加のレプリカを保存するのに十分な容量があることを常に確認してください。

この記事では、インデックス作成からフィールドを除外する理由、特定のフィールドを除外するように Elasticsearch を構成する方法、およびそうする際に従うべきベスト プラクティスについて説明します。

フィールドをインデックスから除外する理由

1. パフォーマンス:ドキュメント内のすべてのフィールドにインデックスを作成すると、インデックス作成時間が長くなり、検索パフォーマンスが低下する可能性があります。検索や集計に必要のないフィールドを除外することで、Elasticsearch クラスターの全体的なパフォーマンスを向上させることができます。

2. ストレージ:フィールドのインデックス作成により、ストレージ スペースが消費されます。検索や集計に必要のないフィールドを除外すると、Elasticsearch クラスターのストレージ要件を削減できます。

3. インデックス サイズ: Elasticsearch インデックスのサイズは、インデックスが作成されるフィールドの数に直接関係します。不要なフィールドを除外することで、インデックスのサイズを最小限に抑えることができ、検索とインデックス作成のパフォーマンスが向上します。

フィールドを除外するようにElasticsearchを構成する

Elasticsearch でフィールドをインデックスから除外するには、フィールドのマッピングで「index」プロパティを使用できます。「index」プロパティを「false」に設定すると、Elasticsearch はフィールドにインデックスを付けず、検索や集計に使用できなくなります。

Elasticsearch マッピングを使用してフィールドをインデックスから除外する方法の例を次に示します。

この例では、「field_to_exclude」という単一のフィールドを持つ「my_index」という新しいインデックスを作成しています。「index」プロパティを「false」に設定することで、Elasticsearch にこのフィールドをインデックスしないように指示します。ただし、フィールドはソース ドキュメントでは引き続き使用できます。

インデックスからフィールドを除外するためのベストプラクティス

1. データを分析する:フィールドをインデックスから除外する前に、データを分析し、検索と集計に必要なフィールドを理解することが重要です。これにより、どのフィールドを除外するかについて十分な情報に基づいた決定を下すことができます。

2. 変更をテストする:フィールドをインデックス作成から除外する場合は、検索機能と集計機能が期待どおりに動作することを確認するために、変更をテストすることが重要です。これにより、予期しない問題やパフォーマンスの問題を回避できます。

3. パフォーマンスを監視する:フィールドをインデックスから除外した後、Elasticsearch クラスターのパフォーマンスを監視して、変更が目的の効果をもたらしたことを確認します。これにより、必要となる可能性のある追加の最適化を特定するのに役立ちます。

4. ソース フィルタリングを使用する: Elasticsearch にフィールドを保存する必要があるが、検索可能にしたり集計に使用したりしたくない場合は、ソース フィルタリングの使用を検討してください。これにより、フィールドを _source フィールドに保存しながら、インデックスからは除外することができます。

まとめ

Elasticsearch のインデックス作成からフィールドを除外すると、パフォーマンスの向上、ストレージ コストの削減、インデックスの全体的なサイズの最小化に役立ちます。データを慎重に分析し、検索と集計に必要なフィールドを理解することで、どのフィールドを除外するかについて十分な情報に基づいた決定を下すことができます。常に変更をテストし、Elasticsearch クラスターのパフォーマンスを監視して、最適化が期待どおりの効果をもたらすことを確認してください。

方法1: Update APIを使用する

Update APIを使用すると、ドキュメントのソースを変更するスクリプトを提供することでドキュメントを更新できます。このAPIを使用して、フィールドをnullに設定して、ドキュメントからフィールドを削除できます。以下はその手順のステップ別のガイドです。

1. 更新するドキュメントのインデックス、ドキュメント タイプ (Elasticsearch 6.x 以前を使用している場合)、およびドキュメント ID を特定します。

2. フィールドを null に設定するスクリプト、またはソース ドキュメントからフィールドを削除するスクリプトで Update API を使用します。次の例は、「my_index」インデックス内の ID「1」のドキュメントから「field_to_delete」フィールドを削除する方法を示しています。

3. リクエストを実行します。成功した場合、Elasticsearch はドキュメントが更新されたことを示す応答を返します。

注: このメソッドは、指定されたドキュメントからフィールドのみを削除します。フィールドはマッピングおよびインデックス内の他のドキュメントに引き続き存在します。

方法2：変更されたソースでの再インデックス

インデックス内のすべてのドキュメントからフィールドを削除したい場合、Reindex APIを使用して、変更されたソースで新しいインデックスを作成できます。方法は以下の通りです。

1. 元のインデックスと同じ設定とマッピングを持つ新しいインデックスを作成します。Get Index API を使用して、元のインデックスの設定とマッピングを取得できます。

2. Reindex API を使用して、ソースからフィールドを削除しながら、元のインデックスから新しいインデックスにドキュメントをコピーします。次の例は、「my_index」インデックス内のすべてのドキュメントから「field_to_delete」フィールドを削除する方法を示しています。

3. 新しいインデックスに、フィールドが削除された正しいドキュメントが含まれていることを確認します。

4. すべてが問題なければ、元のインデックスを削除し、必要に応じて、元のインデックス名を持つエイリアスを新しいインデックスに追加できます。

方法3：マッピングの更新と再インデックス

マッピングからフィールドとインデックス内のすべてのドキュメントを削除する場合は、マッピングを更新してからドキュメントのインデックスを再作成できます。やり方は次のとおりです:

1. 元のインデックスと同じ設定で新しいインデックスを作成します。

2. Get Mapping API を使用して、元のインデックスのマッピングを取得します。

3. 削除するフィールドを削除してマッピングを変更します。

4. Put Mapping API を使用して、変更したマッピングを新しいインデックスに適用します。

5. 方法 2 の説明に従って、Reindex API を使用して、元のインデックスから新しいインデックスにドキュメントをコピーします。

6. 新しいインデックスに、フィールドが削除された正しいドキュメントが含まれていること、およびマッピングにフィールドが存在しないことを確認します。

7. 問題がなければ元のインデックスを削除し、必要に応じて元のインデックス名でエイリアスを追加できます。

まとめ

この記事では、Elasticsearch のドキュメントからフィールドを削除する 3 つの方法 (Update API の使用、変更されたソースによる再インデックス、マッピングの更新と再インデックス) について説明しました。それぞれの方法には独自の使用例とトレードオフがあるため、要件に最も適したものを選択してください。変更を本番環境に適用する前に、必ず変更をテストし、結果を確認してください。

Elasticsearchのスコアリングメカニズム

Elasticsearch は、デフォルトで Practical Scoring Function (BM25) と呼ばれるスコアリング モデルを使用します。このモデルは確率的情報検索理論に基づいており、用語頻度、逆文書頻度、フィールド長の正規化などの要素を考慮に入れています。これらの要因について簡単に説明しましょう。

1. 用語頻度 (TF):これは、ドキュメント内で用語が出現する回数を表します。用語の頻度が高いほど、用語とドキュメントの関係が強くなることを示します。

2. 逆文書頻度 (IDF):この要素は、文書コレクション全体における用語の重要度を測定します。多くのドキュメントに出現する用語は重要度が低いとみなされ、より少ないドキュメントに出現する用語は重要度が高いとみなされます。

3. フィールド長の正規化: この要素は、用語が表示されるフィールドの長さを考慮します。短いフィールドでは用語がより重要であるとみなされるため、短いフィールドにはより大きな重みが与えられます。

Explain APIの使用

Elasticsearch の Explain API は、スコアリング プロセスを理解するための貴重なツールです。特定のドキュメントのスコアがどのように計算されたかについての詳細な説明を提供します。Explain API を使用するには、次のエンドポイントに GET リクエストを送信する必要があります。

リクエスト本文には、スコアリングを理解したいクエリを指定する必要があります。次に例を示します。

Explain API からの応答には、個々の要素 (TF、IDF、フィールド長の正規化) とそれらが最終スコアに与える影響など、スコアリング プロセスの詳細な内訳が含まれます。応答の例は次のとおりです。

この例では、応答は、スコア 1.2 が IDF 値 (2.2) と tfNorm 値 (0.5) の積であることを示しています。詳細な説明は、スコアに影響を与える要因を理解するのに役立ち、検索の関連性を微調整するのに役立ちます。

まとめ

Elasticsearch スコアリングは、関連性の高い検索結果を提供する上で重要な要素です。スコアリング メカニズムを理解し、Explain API を使用することで、検索結果に影響を与える要因についての洞察を得て、検索クエリを最適化し、関連性とパフォーマンスを向上させることができます。

• マッピング定義はデータ スキーマを指定します。

• 設定では、シャードのサイズと更新レートを設定します。

• エイリアスは、インデックスに別の名前を付けるために使用されます。

初めてドキュメントのインデックスを作成するとき、または Create Index API を使用して空のインデックスを作成するときは、データ スキーマとエイリアスのないデフォルト設定でインデックスが作成されます。これらのデフォルトは開発環境やテスト環境では適切に機能しますが、実稼働環境の場合はインデックスをカスタマイズする必要がある場合があります。

運用環境でデフォルトのマッピングと設定を使用すると、インデックス作成と検索のパフォーマンスが低下する可能性があります。インデックスを手動でインスタンス化するのは面倒で時間のかかるプロセスです。複雑なマッピング スキーマやカスタマイズされた設定およびエイリアスがある場合、このようなインデックスをすべての環境で再作成することは特に非現実的です。

幸いなことに、Elasticsearch には、インデックステンプレートの形式でインデックスを作成するときに、事前定義された構成を自動的に適用するツールが用意されています。

インデックステンプレート

インデックス テンプレートを使用すると、ユーザー定義の構成でインデックスを作成できます。インデックスは、インスタンス化中に、これらのテンプレートから構成 (シャードとレプリカの数の設定、フィールド マッピングなど) を取得できます。テンプレートは、名前パターンといくつかの構成で定義されます。インデックスの名前がテンプレートの命名パターンと一致する場合、テンプレートで定義された構成で新しいインデックスが作成されます。

Elasticsearch はバージョン 7.8 で、コンポーザブル テンプレートを使用してテンプレート機能をアップグレードしました。この新しいバージョンでは、この記事で示されているように、より再利用可能なインデックス テンプレートが提供されます。

インデックステンプレートの種類

インデックス テンプレートは、次の 2 つのカテゴリに分類できます。

• インデックス テンプレート (または構成可能なインデックス テンプレート) : 構成可能なインデックス テンプレートは、単独で存在することも、0 個以上のコンポーネント テンプレートで構成することもできます (2 番目のカテゴリを参照)。

• コンポーネント テンプレート:コンポーネント テンプレートは、必要な構成を定義する、それ自体が再利用可能なテンプレートです。通常、コンポーネント テンプレートはインデックス テンプレートに関連付けられることが想定されます。各コンポーネント テンプレートには、1 つまたは複数のインデックス テンプレートを添付できます。

下の画像でわかるように、インデックス テンプレート A と B はコンポーネント テンプレート (この場合はテンプレート 3 の 1 つだけ) を共有しています。インデックス テンプレートは、0 個以上のコンポーネント テンプレートで構成でき、各コンポーネント テンプレートは、0 個以上のインデックス テンプレートに関連付けることができます。どちらのタイプのテンプレートも単独で存在できますが、コンポーネント テンプレートはインデックス テンプレートに添付されない限り役に立ちません。

基本的な考え方は、組織がさまざまなニーズに合わせて使用できるコンポーネント テンプレートのカタログを開発し (たとえば、個々の環境に合わせてさまざまなコンポーネント テンプレートを指定する)、それらを構成可能なインデックス テンプレートを介してさまざまなインデックスに添付することです。

構成可能な（インデックス）テンプレートを作成する方法

Elasticsearch は、インデックス テンプレートを管理するための _index_template エンドポイントを提供します。ユーザーは、このテンプレートでインデックス名パターンとともに、必要なすべてのマッピング、設定、エイリアスを指定します。注文生成ロジックを担当するマイクロサービス アプリケーションcustomer-order-serviceのテンプレートを作成する例を見てみましょう。

ワイルドカード *orders を含むパターンで表される顧客注文のテンプレートを作成する必要があるとします。このテンプレートには、order_date フィールド、シャード、レプリカ番号などの特定のマッピングと設定が含まれている必要があります。

作成中にこのテンプレートと一致するインデックスはすべて、このテンプレートで定義された構成を継承します。たとえば、black_friday_orders インデックスには order_date フィールドがあり、シャードは 5 に設定され、レプリカは 2 に設定されます。これに加えて、このテンプレートから作成されたすべてのインデックスも単一のエイリアス名を継承します。*orders として定義されたインデックス パターンと、定義済みの日付形式 dd-MM-yyyy を持つ単一の oder_date フィールドで構成されるマッピング スキーマを使用して、この orders_template を作成しましょう。以下のコードは、このインデックス テンプレートを作成する方法を示しています。

Kibana の DevTools でこのクエリを実行すると、事前定義されたマッピング、設定、エイリアスとともに、インデックス パターン *orders を使用してテンプレートが作成されます。index_patterns は一致パターンの配列です。このパターンに一致するインデックスはテンプレート構成を派生します。実行した内容を繰り返す永続テンプレートを取得するには、以下を実行します。

テンプレートに定義されたテンプレート属性を作成するときに定義される、正の数値の優先度もあります。すべてのテンプレートには優先度が定義されるため、異なるテンプレートからの競合する変更は、この値を使用して解決され、より高い優先度の値が優先されます。テンプレートの優先順位については、以下でさらに詳しく説明します。

テンプレートを使用してインデックスを作成する

これで、インデックスを作成するための設計図であるテンプレートができました。次のステップは、インデックスを作成することです。インデックスの名前が指定されたパターンと一致すると、テンプレート化された構成が自動的に適用されます。この点を証明するために、以下のコードに示すように、blackfriday_orders という名前の新しいインデックスを作成しましょう。

インデックスの名前（blackfriday_orders）はテンプレートで定義された命名パターンと一致します（つまり*orders) の場合、インデックスはテンプレートから派生したすべての構成を取得する必要があります。この新しく作成されたインデックスを取得し、次のコードを実行してこれが本当に当てはまるかどうかを確認しましょう。

次のように返されます:

応答が示すように、blackfriday_orders の構成はテンプレートから継承されています。テンプレート構成を正常に継承するインデックスのさまざまな組み合わせを試すことができます。

ただし、次のインデックスは名前がパターンと一致しないため、構成を継承しません。

覚えておくべき重要な点の 1 つは、この場合、テンプレートから派生したすべてのインデックスが同じエイリアス (all_orders) を持つことです。このようなエイリアスを使用すると、複数のインデックスではなく、この単一のエイリアスに対してクエリを実行できるという利点があります。

*orders のテンプレートを作成する際、一致するインデックスはテンプレート構成を採用することが期待されます。通常、チームは、意識的か無意識的かを問わず、さまざまな理由でさらにいくつかのテンプレートを作成することがあります。つまり、インデックス名が 2 つの異なるテンプレート パターンと一致する場合があるということです。Elasticsearch は、これらのテンプレートからどの構成を適用する必要があるかを決定する必要があります。幸いなことに、このジレンマはテンプレートの優先順位を使用することで解決できます。

コンポーネントテンプレートの作成方法

この記事の前半でインデックス テンプレートについて学習しました。構成が組み込まれたテンプレートを作成することにはいくつかの欠点があります。その 1 つは、構成を他のテンプレートにエクスポートできないことです。たとえば顧客関連のテンプレート（*customers）に対して同様の構成を希望する場合は、テンプレート全体を再作成する必要がある場合があります。つまり、典型的な組織では数十個のコンポーネントが作成されることになります (環境によっては、さらに数個になることもあります)。

私たちは常に再利用性を重視しているため、Elasticsearch は再利用性を念頭に置いてテンプレートを再設計しました。コンポーネント テンプレートはまさにその要件を満たしています。DevOps の経験がある場合、環境ごとに事前設定された構成でインデックスを作成する必要がある可能性が高くなります。これらの各構成を手動で面倒に適用するのではなく、環境ごとにコンポーネント テンプレートを作成できます。

コンポーネント テンプレートは、より多くのインデックス テンプレートを作成するために使用できる再利用可能な構成ブロックです。コンポーネント テンプレートは、インデックス テンプレートと組み合わせない限り価値がないことに注意してください。これらは _component_template エンドポイントを介して公開されます。これらすべてがどのように組み合わさるかを見てみましょう。

インデックステンプレート内の設定

先ほどインデックス テンプレートで定義した設定を抽出し、そこからコンポーネント テンプレートを作成しましょう。settings_component_template には、プライマリ シャードごとに 2 つのレプリカを持つ 5 つのプライマリ シャードがあることが想定されています。最初のステップは、以下のコード リストに示すように、この構成でコンポーネント テンプレートを宣言して実行することです。

上記のコードが示すように、_component_template エンドポイントを使用してコンポーネント テンプレートを作成します。リクエストの本文には、テンプレート オブジェクト内のテンプレート情報が保持されます。これで、settings_component_template はインデックス テンプレートの他の場所でも使用できるようになりました。注目すべき違いの 1 つは、このテンプレートではインデックス パターンが定義されていないことです。これは、いくつかのプロパティを構成する単なるコード ブロックです。

マッピングテンプレート

同じように、もう一つテンプレートを作成しましょう。今回は、スタンドアロン インデックス テンプレートで以前に定義したマッピング スキーマを抽出しましょう。以下のコードはスクリプトを示しています。

エイリアステンプレート

同じフローで、エイリアス（2 つのエイリアス（all_orders と sales_orders））を持つコンポーネント テンプレートも作成できます。

構成可能なインデックステンプレート

これで 3 つのコンポーネント テンプレートができたので、次のステップではそれらを使用します。これを実現するには、たとえば christmas_orders のインデックス テンプレートでこれを使用できるようにします。

compose_of タグは、このテンプレートを構成するすべてのコンポーネント テンプレートのコレクションです。この場合は、設定、マッピング、エイリアスのコンポーネント テンプレートを選択します。また、このテンプレートが他のテンプレートよりも優先されるように、優先順位を上げています。テンプレートの準備が整うと、*orders パターンに一致するすべてのインデックスは、これら 3 つのコンポーネント テンプレートから構成を継承します。

そうは言っても、既存のテンプレート (settings_component_template) と新しく作成したエイリアス テンプレート (aliases_component_template – 以下を参照) のいずれか 1 つを使用して、新しいテンプレート (たとえば、顧客) を作成したい場合は、次のようにします。

インデックス テンプレートは次のようになります。

settings_component_template が 2 つの異なるテンプレートで (再) 使用されていることに気付きましたか?それがコンポーネント テンプレートの力です。

インデックステンプレートの優先度

開発者が既存のストックを確認せずに複数のインデックス テンプレートを作成する可能性があります。これらのテンプレートそれぞれに優先順位を設定し、優先順位の高いテンプレートが使用されるようにすることが重要です。たとえば、次のコード スニペットでは、my_orders_template_1 が my_orders_template_2 をオーバーライドします。

作成中のインデックスに一致するテンプレートが複数ある場合、Elasticsearch は一致するすべてのテンプレートのすべての設定を適用しますが、優先度の高い設定は上書きします。

テンプレートの優先順位

最後に、テンプレートの優先順位について疑問に思われるかもしれません。コンポーネント テンプレートで定義された構成は、メイン インデックス テンプレート自体で定義された構成を上書きするのでしょうか。それとも逆でしょうか?まあ、いくつかルールがあります:

• 明示的に構成を作成して作成したインデックスは、すべてに優先します。つまり、明示的に構成を作成してインデックスを作成した場合、テンプレートによってそのインデックスが上書きされることは想定しないでください。

• レガシー テンプレート (バージョン 7.8 より前に作成されたテンプレート) は、コンポーザブル テンプレートよりも優先順位が低くなります。

まとめ

• インデックスには、マッピング、設定、エイリアスが含まれます。マッピングはフィールド スキーマを定義し、設定はシャードやレプリカの数などのインデックス パラメータを設定し、エイリアスはインデックスに別名を与えます。

• テンプレートを使用すると、事前定義された構成でインデックスを作成できます。特定のテンプレート内で定義されたインデックス パターンと一致する名前でインデックスに名前を付けると、そのインデックスはテンプレートに従って自動的に構成されます。

• Elasticsearch はバージョン 7.8 で構成可能なインデックス テンプレートを導入しました。構成可能なインデックス テンプレートにより、テンプレートのモジュール化とバージョン管理が可能になります。

• 構成可能なテンプレートは、0 個以上のコンポーネント テンプレートで構成されます。

• インデックス テンプレートにも独自の構成を定義することができます。

• コンポーネント テンプレートは、コンポーザブル インデックス テンプレートと同様に、事前定義された構成を持つ再利用可能なテンプレートです。

• ただし、コンポーネント テンプレートはインデックス テンプレートの一部であることが想定されており、インデックス テンプレートに「構成」されていない場合は役に立ちません。

• コンポーネント テンプレートにはインデックス パターンが定義されていません。これが、コンポーネント テンプレートがインデックス テンプレートの一部であると「想定」されるもう 1 つの理由です。

• 各テンプレートには優先度（正の数字）があります。数値が大きいほど、そのテンプレートが適用される優先順位が高くなります。

2つのフィールドで検索を実行する高度なテクニック

1. 複数一致クエリ

複数一致クエリを使用すると、複数のフィールドにわたって単一のクエリ文字列を検索できます。これは、2 つのフィールドのいずれかに指定されたクエリ文字列を含むドキュメントを検索する場合に便利です。以下は、「title」または「description」フィールドで「example」という用語を検索する複数一致クエリの例です。

2. ブールクエリ

bool クエリを使用すると、ブールロジックを使用して複数のクエリを組み合わせることができます。「should」句を使用すると、2 つのフィールドのいずれかでクエリに一致するドキュメントを検索できます。以下は、フィールド「title」と「description」で「example」という用語を検索するブールクエリの例です。

3. クエリ時のフィールドブースティング

場合によっては、検索中にあるフィールドを他のフィールドよりも重視したいことがあります。これを実現するには、クエリ時にフィールドにブースト係数を適用します。ブースト値が高いほど、フィールドの重みが増し、最終的な検索スコアに影響を与える可能性が高くなります。以下は、「タイトル」フィールドにブースト係数を適用した複数一致クエリの例です。

この例では、「タイトル」フィールドのブースト係数は 3 であり、検索スコアの決定において「説明」フィールドよりも 3 倍重要になります。

4. 異なるブースト係数を持つクエリを組み合わせる

bool クエリを使用して、異なるブースト係数を持つ複数のクエリを組み合わせることもできます。これにより、検索結果の各フィールドの重要性を微調整できます。以下は、「title」フィールドと「description」フィールドに異なるブースト係数を適用したブールクエリの例です。

この例では、「タイトル」フィールドのブースト係数は 3 ですが、「説明」フィールドのブースト係数は 1 です。

まとめ

Elasticsearch での 2 つのフィールドによる検索は、マルチマッチ クエリ、ブール クエリ、クエリ時フィールド ブースティングなどの高度な手法を使用して実現できます。これらの技術を組み合わせることで、ユーザーにとってより正確で関連性の高い検索結果を作成できます。さまざまなクエリの組み合わせとブースト係数を試して、特定のユースケースに最適な検索構成を見つけます。

バージョン 7.11 以降、Elasticsearch はデフォルトで、ノードのロールと合計メモリに基づいて JVM ヒープ サイズを自動的に設定します。ほとんどの運用環境では、デフォルトのサイズ設定を使用することをお勧めします。ただし、JVM ヒープ サイズを手動で設定する場合は、一般的なルールとして、-Xms と -Xmx を同じ値に設定する必要があります。これは、使用可能な RAM の合計の 50% で、最大 (約) 31 GB になります。

ヒープ サイズを大きくすると、インデックス作成と検索操作に使用できるメモリがノードに多く割り当てられます。ただし、ノードにはキャッシュ用のメモリも必要なので、50% を使用すると 2 つのメモリのバランスが適切に保たれます。同じ理由から、本番環境では、Elasticsearch と同じノードで他のメモリを大量に消費するプロセスを使用することは避けてください。

通常、ヒープ使用量は鋸歯状のパターンに従い、使用されている最大ヒープの約 30 ～ 70% の間を変動します。これは、ガベージ コレクション プロセスによってメモリが再び解放されるまで、JVM がヒープ使用率を着実に増加させるためです。ガベージ コレクション プロセスが追いつかない場合、ヒープ使用率が高くなります。ヒープ使用量が高いことを示す指標は、ガベージ コレクションでヒープ使用量を約 30% まで削減できない場合です。

上の画像では、JVM ヒープの通常のノコギリ波を見ることができます。

また、ガベージ コレクションには、若い GC と古い GC の 2 種類があることもわかります。

正常な JVM では、ガベージ コレクションは理想的には次の条件を満たす必要があります。

• Young GC は迅速に処理されます (50 ミリ秒以内)。

• Young GC は頻繁に実行されません (約 10 秒)。

• 古い GC はすぐに処理されます (1 秒以内)。

• 古い GC は頻繁に実行されません (10 分に 1 回以上)。

ヒープメモリ使用量が高すぎる場合やJVMパフォーマンスが最適でない場合の解決方法

ヒープ メモリの使用量が増える理由はさまざまです。

オーバーシャーディング

オーバーシャーディングに関するドキュメントはここを参照してください。

大規模な集約サイズ

集約サイズが大きくなるのを避けるには、クエリ内の集約バケットの数 (サイズ) を最小限に抑えます。

低速クエリ ログ (スロー ログ) を使用し、次のように特定のインデックスに実装することができます。

結果を返すのに長い時間がかかるクエリは、リソースを大量に消費するクエリである可能性が高くなります。

バルクインデックスのサイズが大きすぎる

大きなリクエストを送信する場合、ヒープ消費量が多くなる原因となる可能性があります。一括インデックス要求のサイズを小さくしてみてください。

マッピングの問題

特に、「fielddata: true」を使用する場合、これが JVM ヒープの主要なユーザーになる可能性があります。

ヒープサイズが正しく設定されていません

ヒープ サイズは次のように手動で定義できます。

環境変数の設定:

Elasticsearch 構成ディレクトリ内の jvm.options ファイルを編集します。

環境変数の設定はファイルの設定よりも優先されます。

設定を有効にするにはノードを再起動する必要があります。

JVM の新しい比率が正しく設定されていません

Elasticsearch はデフォルトでこの値を設定するため、通常はこれを設定する必要はありません。このパラメータは、JVM 内の「新世代」オブジェクトと「旧世代」オブジェクトに使用可能なスペースの比率を定義します。

古い GC が非常に頻繁に発生していることがわかった場合は、Elasticsearch 構成ディレクトリの jvm.options ファイルでこの値を具体的に設定してみてください。

大規模な Elasticsearch クラスターでヒープサイズの使用量と JVM ガベージコレクションを管理するためのベストプラクティスは何ですか?

大規模な Elasticsearch クラスターでヒープ サイズの使用量と JVM ガベージ コレクションを管理するためのベスト プラクティスは、ヒープ サイズが使用可能な RAM の最大 50% に設定され、JVM ガベージ コレクション設定が特定のユース ケースに合わせて最適化されていることを確認することです。クラスターが最適に実行されていることを確認するには、ヒープ サイズとガベージ コレクション メトリックを監視することが重要です。具体的には、JVM ヒープ サイズ、ガベージ コレクション時間、ガベージ コレクションの一時停止を監視することが重要です。さらに、ガベージ コレクション サイクルの数とガベージ コレクションに費やされた時間を監視することも重要です。これらのメトリックを監視することで、ヒープ サイズやガベージ コレクションの設定に関する潜在的な問題を特定し、必要に応じて修正措置を講じることができます。

_split API は、多くの場合、_reindex API よりも高速な方法です。両方の操作の前にインデックス作成を停止する必要があります。そうしないと、source_index と target_index のドキュメント数が異なります。

方法1 – 分割APIを使用する

分割 API は、設定をコピーし、既存のインデックスをマッピングすることで、必要な数のプライマリ シャードを持つ新しいインデックスを作成するために使用されます。作成時に必要なプライマリ シャードの数を設定できます。分割 API を実装する前に、次の設定を確認する必要があります。

1. ソース インデックスは読み取り専用である必要があります。これは、インデックス作成プロセスを停止する必要があることを意味します。

2. ターゲット インデックス内のプライマリ シャードの数は、ソース インデックス内のプライマリ シャードの数の倍数である必要があります。たとえば、ソース インデックスに 5 つのプライマリ シャードがある場合、ターゲット インデックスのプライマリ シャードを 10、15、20 などに設定できます。

注: プライマリ シャード番号のみを変更する必要がある場合は、再インデックス API よりもはるかに高速な分割 API が推奨されます。

分割APIの実装

テストインデックスを作成します。

分割するには、ソース インデックスが読み取り専用である必要があります。

設定とマッピングはソース インデックスから自動的にコピーされます。

進捗状況は以下で確認できます:

設定とマッピングはソース インデックスからコピーされるため、ターゲット インデックスは読み取り専用になります。ターゲット インデックスへの書き込み操作を有効にしましょう。

元のインデックスを削除する前に、ソース インデックスとターゲット インデックスの docs.count を確認します。

インデックス名とエイリアス名を同じにすることはできません。ソース インデックスを削除し、ソース インデックス名をターゲット インデックスのエイリアスとして追加する必要があります。

test_split_sourceエイリアスをtest_split_targetインデックスに追加した後、次のようにテストする必要があります。

方法2 – 再インデックスAPIを使用する

Reindex API を使用して新しいインデックスを作成すると、任意の数のプライマリ シャード カウントを指定できます。意図した数のプライマリ シャードで新しいインデックスを作成した後、ソース インデックス内のすべてのデータをこの新しいインデックスに再インデックスできます。

分割 API 機能に加えて、再インデックス AP の ingest_pipeline を使用してデータを操作することもできます。取り込みパイプラインでは、フィルターに適合する指定されたフィールドのみがクエリを使用してターゲット インデックスにインデックス付けされます。データの内容は簡単なスクリプトを使用して変更でき、複数のインデックスを 1 つのインデックスにマージできます。

再インデックスAPIの実装

テストの再インデックスを作成します。

ソース インデックスから設定とマッピングをコピーします。

設定、マッピング、および必要なシャード数を使用してターゲット インデックスを作成します。

*注: number_of_replicas: 0 および refresh_interval: -1 を設定すると、再インデックスの速度が向上します。

再インデックスプロセスを開始します。requests_per_second=-1 および slices=auto を設定すると、再インデックス速度が調整されます。

再インデックス API を実行すると、task_id が表示されます。それをコピーして、_tasks API で確認します。

再インデックスが完了したら設定を更新します。

元のインデックスを削除する前に、ソース インデックスとターゲット インデックスの docs.count が同じであることを確認します。

インデックス名とエイリアス名を同じにすることはできません。ソース インデックスを削除し、ソース インデックス名をターゲット インデックスのエイリアスとして追加します。

test_split_source エイリアスを test_split_target インデックスに追加した後、次のコマンドを使用してテストします。

まとめ

既存のインデックスのプライマリ シャード数を増やす場合は、新しいインデックスへの設定とマッピングを再作成する必要があります。これを行うには、主に reindex API と split API という 2 つの方法があります。どちらの方法を使用する前にも、アクティブなインデックス作成を停止する必要があります。

このアプローチの欠点は、ハードウェアの重複が必要となり、すべてのデータをスムーズに転送および同期する際に困難が生じる可能性があることです。

アプリケーションをあるデータ センターから別のデータ センターに移行する必要がある場合にも、同様の手順を実行する必要がある場合があります。

この記事では、Elasticsearch クラスター間でデータを転送する 3 つの方法について詳しく説明します。

Elasticsearch クラスター間でデータを移行するにはどうすればよいですか?

Elasticsearch クラスター間でデータを転送する方法は 3 つあります。

1. リモートクラスタからの再インデックス

2. スナップショットを使用したデータ転送

3. Logstash を使用したデータ転送

通常、スナップショットを使用するのが、データを転送する最も高速かつ信頼性の高い方法です。ただし、スナップショットは同等以上のバージョンのクラスターにのみ復元でき、メジャー バージョンが 1 つ以上異なるクラスターには復元できないことに注意してください。つまり、6.x スナップショットを 7.x クラスターに復元することはできますが、8.x クラスターには復元できません。

メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。

ここで、Elasticsearch クラスター間でデータを転送するための 3 つのオプションをそれぞれ詳しく見ていきましょう。

1. リモートクラスタからのデータの再インデックス

再インデックスを開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、適切なマッピングを使用してインデックスを直接作成するか、インデックス テンプレートを使用する必要があります。

リモートからの再インデックス - 設定が必要

リモートから再インデックスを行うには、データを受信しているクラスターの elasticseearch.yml ファイルに以下の構成を追加する必要があります。Linux システムでは、このファイルは、通常、/etc/elasticsearch/elasticsearch.yml にあります。追加する構成は次のとおりです。

SSL を使用している場合は、各ノードに CA 証明書を追加し、elasticsearch.yml 内の各ノードのコマンドに以下を含める必要があります。

あるいは、SSL 検証を無効にするために、すべての Elasticsearch ノードに以下の行を追加することもできます。ただし、このアプローチは前のオプションほど安全ではないため、あまりお勧めできません。

すべてのノードでこれらの変更を行い、ローリング再起動を実行する必要があります。その方法の詳細については、ガイドをご覧ください。

再インデックスコマンド

elasticsearch.yml ファイルでリモート ホストを定義し、必要に応じて SSL 証明書を追加したら、以下のコマンドでデータの再インデックスを開始できます。

その際、タイムアウト エラーが発生する可能性があるため、デフォルトに頼るのではなく、タイムアウトに余裕を持った値を設定すると便利な場合があります。

ここで、リモートから再インデックスするときに発生する可能性のあるその他の一般的なエラーを見てみましょう。

リモートからの再インデックス時によくあるエラー

1. 再インデックスがホワイトリストに登録されていない

このエラーが発生した場合は、上記のように Elasticsearch でリモート ホストの IP アドレスまたはノード名 DNS を定義しなかったか、Elasticsearch サービスの再起動を忘れたことを示しています。

Elasticsearch クラスターでこの問題を修正するには、リモート ホストをすべての Elasticsearch ノードに追加し、Elasticsearch サービスを再起動する必要があります。

2. SSLハンドシェイク例外

このエラーは、上記のように elasticsearch.yml に reindex.ssl.certificate_authorities を追加するのを忘れたことを意味します。追加するには:

2. スナップショットを使用したデータ転送

前述のように、スナップショットは同等以上のバージョンのクラスタにのみ復元でき、1つ以上のメジャーバージョンの違いがあるクラスタには復元できないことに注意してください。

メジャー バージョンを 1 つ以上増やす必要がある場合は、インデックスを再作成するか、Logstash を使用する必要があります。

スナップショットを介してデータを転送するには、次の手順が必要です。

ステップ 1. 最初の Elasticsearch クラスターにリポジトリ プラグインを追加する – スナップショットを介してクラスター間でデータを転送するには、新しいクラスターと古いクラスターの両方からリポジトリにアクセスできることを確認する必要があります。通常、AWS、Google、Azure などのクラウド ストレージ リポジトリがこれに最適です。スナップショットを撮るには、ガイドを参照して、そこに記載されている手順に従ってください。

ステップ 2. Elasticsearch サービスを再起動します (ローリング再起動)。

ステップ 3. 最初の Elasticsearch クラスターのリポジトリを作成します。

ステップ 4 - リポジトリ プラグインを 2 番目の Elasticsearch クラスターに追加します。

ステップ 5 - リポジトリを 2 番目の Elasticsearch クラスターに読み取り専用として追加する - 最初の Elasticsearch クラスターを作成するときに実行したのと同じ手順を繰り返して、リポジトリを追加する必要があります。

重要な注意: 2 番目の Elasticsearch クラスターを同じ AWS S3 リポジトリに接続する場合は、リポジトリを読み取り専用リポジトリとして定義する必要があります。

これは、同じスナップショットリポジトリ内で Elasticsearch のバージョンが混在するリスクを回避するために重要です。

ステップ 6 - 2 番目の Elasticsearch クラスターへのデータの復元 - 上記の手順を実行した後、データを復元して新しいクラスターに転送できます。新しいクラスターにデータを復元するには、この記事に記載されている手順に従ってください。

3. Logstash を使用したデータ転送

logstash を使用してデータの転送を開始する前に、新しいクラスター上のすべてのインデックスに対して適切なマッピングを設定する必要があることに注意してください。そのためには、インデックスを直接作成するか、インデックス テンプレートを使用する必要があります。

2 つの Elasticsearch クラスター間でデータを転送するには、一時的な Logstash サーバーをセットアップし、それを使用して 2 つのクラスター間でデータを転送できます。小規模なクラスターの場合、2GB の RAM インスタンスで十分です。より大規模なクラスターの場合は、8GB の RAM を搭載した 4 コア CPU を使用できます。

Logstash のインストールに関するガイダンスについては、こちらをご覧ください。

あるクラスターから別のクラスターにデータを転送するための Logstash 構成

クラスター A からクラスター B に単一のインデックスをコピーするための基本構成は次のとおりです。

セキュアな elasticsearch の場合は、以下の構成を使用できます。

インデックスメタデータ

上記のコマンドは、単一の名前付きインデックスに書き込みます。複数のインデックスを転送し、インデックス名を保持する場合は、Logstash 出力に次の行を追加する必要があります。

また、ドキュメントの元の ID を保持したい場合は、以下を追加する必要があります。

ドキュメント ID を設定するとデータ転送速度が大幅に低下することに注意してください。必要な場合にのみ元の ID を保持してください。

更新の同期

上記の方法はすべて比較的長い時間がかかり、プロセスが完了するまでに元のクラスターのデータが更新されている場合があります。

データ転送プロセス中に発生した可能性のある更新を同期できるようにするにはさまざまな戦略があり、そのプロセスを開始する前にこれらの問題について検討する必要があります。特に、次の点を考慮する必要があります。

• データ転送プロセスの開始以降に更新/追加されたデータを識別する方法は何ですか (例: データ内の「last_update_time」フィールド)?

• 最後のデータを転送するにはどのような方法を使用できますか?

• 記録が重複するリスクはありますか?通常は、使用している方法によって再インデックス中にドキュメント ID が既知の値に設定されない限り、存在します。

更新の同期を有効にするさまざまな方法について以下に説明します。

1. 待ち行列システムの使用

一部の取り込み/更新システムでは、過去 x 日間に受信したデータの変更を「再生」できるキューを使用します。これにより、実行された変更を同期する手段が提供される場合があります。

2. リモートから再インデックス

「last_update_time」が x 日前を超えるすべてのアイテムに対して、再インデックス処理を繰り返します。これを行うには、再インデックス リクエストに「クエリ」パラメータを追加します。

3. ログスタッシュ

Logstash 入力では、「last_update_time」が x 日前を超えるすべての項目をフィルターするクエリを追加できます。ただし、document_id を設定していない限り、このプロセスでは非時系列データに重複が発生します。

4. スナップショット

インデックスの一部だけを復元することはできないため、データ転送プロセスの実行以降に行われた変更を更新するには、上で説明した他のデータ転送方法のいずれか (またはスクリプト) を使用する必要があります。

ただし、スナップショットの復元は再インデックス/Logstash よりもはるかに高速なプロセスであるため、スナップショットの転送中に更新を短時間一時停止して、問題を完全に回避できる可能性があります。