乾物 | Elasticsearch 8.X パフォーマンス最適化の実践

Elasticsearch は、ユーザーにシームレスな検索エクスペリエンスを実現するための重要なツールです。高速かつ正確で関連性の高い検索結果を提供することで、ユーザーがアプリケーションを操作する方法に革命をもたらしました。ただし、Elasticsearch デプロイメントの最適なパフォーマンスを確保するには、主要なメトリックと、インデックス作成、キャッシュ、クエリ、検索、ストレージなどのさまざまなコンポーネントの最適化に注意を払う必要があります。

このブログ投稿では、クラスターの健全性、検索パフォーマンス、インデックス作成の最適化から、キャッシュ戦略とストレージオプションの習得まで、最適なパフォーマンスと最大の可能性を実現するために Elasticsearch を調整する方法に関するベストプラクティスとヒントを詳しく説明します。Elasticsearch の経験豊富な専門家であろうと、この分野の初心者であろうと、デプロイメントのパフォーマンス、信頼性、およびスケーラビリティを確保するには、いくつかのベストプラクティスに従うことが重要です。

1. 一般的な最適化に関する提案

1.1 適切なハードウェアを使用する

Elasticsearch はメモリを大量に消費するアプリケーションであるため、十分なメモリを備えたハードウェアを使用することが重要です。また、インデックス作成と検索のパフォーマンスを大幅に向上させることができるソリッドステートドライブ (SSD) をストレージデバイスとして推奨します。

SSD の I/O パフォーマンスは従来のハードドライブよりも優れていますが、Elasticsearch クラスター内のノード数が多い場合、I/O パフォーマンスが依然としてボトルネックになる可能性があります。パフォーマンスを確保するために、RAID 構成、適切なディスクパーティショニング、負荷分散の使用など、いくつかの最適化措置を講じることができます。

RAIDレベル	アドバンテージ	欠点がある	該当シーン
RAID 0	高いI/O性能、並列読み書きを実現	冗長性がないため、ディスク障害が発生するとデータが失われる可能性があります	許容可能なデータ回復時間を持つパフォーマンス重視のアプリケーション
RAID 1	データの冗長性により、ディスク障害が発生した場合でもデータが失われることはありません	書き込みパフォーマンスは RAID 0 ほど良くありません	高いデータセキュリティと信頼性を備えたアプリケーション
RAID 5	データの冗長性、ある程度の I/O パフォーマンスの利点	書き込みパフォーマンスは RAID 0 ほど良くありません	パフォーマンスとデータセキュリティのバランスが必要なアプリケーション
RAID 10	RAID 0 と RAID 1 の利点、高い I/O パフォーマンスとデータ冗長性を組み合わせたもの	より多くのディスクが必要になり、コストも高くなります	パフォーマンスとデータセキュリティの両方を必要とするアプリケーション

1.2 インデックス戦略の立案

Elasticsearch は大量のデータを処理するように設計されていますが、このデータにインデックスを付ける方法を検討する必要があります。これには、必要なシャードとレプリカの数、データのインデックス付け方法、更新と削除の処理方法が含まれます。

フラグメントの数

水平スケーリングと負荷分散を実現するには、適切な数のシャードを選択します。

デフォルトでは、各インデックスには 1 つのプライマリシャードがあります。データ量とノード数に応じてシャード数を調整します。各シャードには追加のリソースとオーバーヘッドが必要となるため、シャードの使用が多すぎないように注意してください。

部数

検索パフォーマンスとシステムの耐障害性を向上させるためにコピー数を増やしますが、これは弁証法的でなければなりません。これについては後で詳しく説明します。

デフォルトでは、各シャードには 1 つのレプリカがあります。負荷と可用性のニーズに基づいてレプリカの数を調整します。

データのインデックス作成戦略

時間ベースのインデックスライフサイクル管理戦略(ILM) を使用して、クエリのパフォーマンスを向上させ、リソース消費を削減します。たとえば、日次、週次、または月次データの新しいインデックスを作成します。

適切なフィールドタイプとアナライザーを選択します。マッピングを最適化してストレージ容量を削減し、クエリのパフォーマンスを向上させます。

インデックステンプレートを使用して、マッピングと設定を自動的に適用します。

更新および削除の処理

Update API を使用すると、ドキュメント全体を削除したりインデックスを再作成したりせずにドキュメントを更新できます。

Elasticsearch のバージョン管理機能を合理的に利用してください。

インデックスのライフサイクル管理 (ILM) を使用して、インデックスのライフサイクルを自動的に管理することを検討してください。特定のビジネスニーズとシナリオに応じて、上記の提案を柔軟に調整して、Elasticsearch クラスターのパフォーマンスを最適化します。

1.3 クエリの最適化

Elasticsearch は強力な検索エンジンですが、クエリのパフォーマンスが最適化されていることを確認してください。これには、可能な場合はクエリの代わりにフィルターを使用すること、返される結果の数を制限するためにページネーションを使用することが含まれます。

クエリの代わりにフィルターを使用します。

クエリ速度の向上: フィルターは関連性スコアを計算しません。
結果はキャッシュできます。同じフィルター条件で結果を直接取得します。

ページネーションを使用して、返される結果の数を制限します。

計算と転送の負担を軽減し、クエリのパフォーマンスを向上させます。
深いページネーションはパフォーマンスの問題を引き起こす可能性があることに注意してください。search_afterパラメーターの使用を検討してください。

クエリのパフォーマンスを最適化すると、応答時間が短縮され、スループットが向上し、高負荷下でもクラスターが安定した状態を維持できるようになります。

1.4 Elasticsearch バージョンを常に最新の状態に保つ

Elasticsearch はアクティブなプロジェクトであり、バグを修正し、新機能を提供するために新しいバージョンが定期的にリリースされます。これらの改善点を活用し、既知の問題を回避するには、バージョンを更新し続けることが重要です。

1.5 クラスタの監視

Elasticsearchは、クラスターの健全性とパフォーマンスを監視するために使用できる、Elasticsearch Head、Kibana 監視 (推奨) プラグインなどのさまざまな監視ツールを提供します。ディスク使用量、CPU とメモリの使用量、検索リクエストの数に注目してください。

一般的なベストプラクティスに基づいて、インデックス作成、クエリと検索、スケーリング、パフォーマンス、監視などの特定の領域について詳しく説明します。

2. 最適化提案の作成 (インデックス作成)

2.1 バッチリクエストの使用

Elasticsearch の一括 API を使用すると、複数のインデックス/削除操作を 1 回の API 呼び出しで実行できます。これにより、インデックス作成速度が大幅に向上します。リクエストの 1 つが失敗した場合、トップレベルのエラーフラグが true に設定され、関連するリクエストの下でエラーの詳細が報告されます。

Elasticsearch の一括 API を使用する理由:

性能を上げる

ネットワークのオーバーヘッドと接続確立時間を削減し、インデックス作成速度を向上させます。

リソース消費量の削減

サーバーとクライアントのリソース消費を削減し、システムの効率とスループットを向上させます。

エラー処理

柔軟で制御可能なエラー処理。一部の操作が失敗した場合でも、他の操作は実行を継続できます。

一括 API を使用すると、システムの安定性と信頼性を向上させながら、効率的なデータのインデックス作成と削除操作が可能になります。

2.2 マルチスレッドクライアントを使用したデータのインデックス作成

単一スレッドでバッチリクエストを送信すると、Elasticsearch クラスターのインデックス作成機能を最大限に活用できません。

複数のスレッドまたはプロセスを通じてデータを送信すると、クラスターのすべてのリソースが活用され、各 fsync のコストが削減され、パフォーマンスが向上します。

2.3 リフレッシュ間隔を長くする（index.refresh_interval）

Elasticsearch のデフォルトの更新間隔は 1 秒ですが、検索トラフィックが少ない場合は、この値を増やしてインデックス作成速度を最適化できます。

2.4 自動生成された ID の使用

明示的な ID を使用してドキュメントにインデックスを作成する場合、Elasticsearch は同じ ID を持つドキュメントが既に存在するかどうかを確認する必要がありますが、これはコストのかかる操作です。

自動生成された ID を使用すると、このチェックがスキップされ、インデックス作成が高速化されます。

2.5 インデックス.translog.sync_interval

この設定は、書き込み操作に関係なく、トランスログがいつディスクにコミットされるかを制御します。デフォルトは 5 秒ですが、100 ミリ秒より小さい値は許可されません。

公式文書のアドレス:

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html

2.6 大きな文書を避ける

サイズの大きいドキュメントはネットワーク、メモリ使用量、ディスクに負荷を与え、インデックス作成の速度を低下させたり、近接検索や強調表示に影響を与えたりする可能性があります。

ハイライト処理はfvhハイライト方式を推奨します。

推奨読書: Elasticsearch の大きなファイルの検索パフォーマンスが 20 倍の練習で向上しました(ドライグッズ)

2.7 マッピングを明示的に設定する

Elasticsearch はマッピングを動的に作成できますが、すべてのシナリオに適しているわけではありません。(厳密な) マッピングを明示的に設定すると、最適なパフォーマンスを確保するのに役立ちます。

マッピングを明示的に設定する利点:

正確なフィールドタイプ

クエリと集計の操作が正しいことを確認してください。

ストレージとパフォーマンスを最適化する

ストレージ容量を削減し、クエリのパフォーマンスを向上させます。

不必要な地図更新を避ける

マップ更新操作とパフォーマンスのオーバーヘッドを削減します。

2.8 ネストされた Nested 型の使用を避ける

ネストされた型は特定のシナリオでは便利ですが、パフォーマンスにも一定の影響を及ぼします。

クエリが遅い

ネストされたフィールドのクエリは、ネストされていないドキュメントの通常のフィールドのクエリよりも遅くなります。

これは、ネストされたフィールドに対するクエリにはフィルターや結合などの追加の処理手順が必要なためです。これにより、特に大量のデータを処理する場合、クエリのパフォーマンスが低下する可能性があります。

追加の減速

ネストされたフィールドに一致するドキュメントを取得する場合、Elasticsearch はネストされたドキュメントを関連付ける必要があります。これは、どのドキュメントに一致するネストされたフィールドが実際に含まれているかを判断するために、ネストされたドキュメントをその外側のドキュメントと照合する必要があることを意味します。このプロセスは、特にクエリ結果セットが大きい場合に、追加のパフォーマンスオーバーヘッドを引き起こす可能性があります。

ネストされた型によるパフォーマンスへの影響を回避するには、次の方法の使用を検討してください。

フラット化されたデータ構造 (一般的に大きくて幅の広いテーブルとして知られています): ネストされたフィールドを可能な限りフラット化されたデータ構造に変換します。たとえば、元のネストされたフィールドを表すために複数の共通フィールドを使用します。
キーワードタイプを使用する (キーワードタイプ): 固定の設定値を持つフィールドの場合、インデックス作成にキーワードタイプを使用して、クエリ速度を向上させることができます。
結合タイプ (親子関連付けタイプ) を使用する: 一部のシナリオでは、ネストされたタイプの代わりに結合タイプを使用できます。

ただし、特にドキュメントの関係を頻繁に変更する必要がある場合、結合タイプによってパフォーマンスの問題が発生する可能性があることに注意してください。

3. クエリと検索の最適化の提案

3.1 可能な限りクエリではなくフィルタを使用する

クエリ句は、「この文書はこの句とどの程度一致しますか?」に答えるために使用されます。
filter 句は、「このドキュメントはこの句と一致しますか?」という質問に答えるために使用されます。Elasticsearch は「はい」または「いいえ」で答えるだけで済みます。フィルター句の関連性スコアを計算する必要はなく、フィルター結果をキャッシュできます。

3.2 更新間隔を長くする

更新間隔を長くすると、セグメントの数が減り、検索の IO コストが削減されます。

また、リフレッシュが発生してデータが変更されると、キャッシュは無効になります。更新間隔を長くすると、Elasticsearch がキャッシュをより効率的に利用できるようになります。

3.3 コピー数の増加が検索パフォーマンスに与える影響の弁証法的考察

エンタープライズレベルのテストの結論を直接与えると、コピー数が検索パフォーマンスに与える影響には正の相関関係がありません。つまり、コピー数が多ければ多いほど検索パフォーマンスが向上するわけではありません。

レプリカの数を増やすことの利点:

負荷分散

クエリリクエストの負荷を分散して負荷分散を実現します。

高可用性

クラスターの可用性と耐障害性が向上します。

並列処理

クエリを高速化し、スループットを向上させます。

注: レプリカの数を増やすと、追加のストレージスペースとコンピューティングリソースが消費されます。レプリカの数は、需要とリソースの制約を考慮して決定する必要があります。

3.4 必須フィールドのみを取得する

ドキュメントが大きく、少数のフィールドのみが必要な場合は、stored_fields を使用して、すべてのフィールドではなく、必要なフィールドのみを取得します。

3.5 ワイルドカードクエリを避ける

ワイルドカードクエリは時間がかかり、リソースを大量に消費する可能性があります。できるだけ避けるのが最善です。

代替案: Ngram 単語分割、ワイルドカードデータ型の設定。

Elasticsearch ではワイルドカードの取得に注意してください。じゃあ何？

3.6 ノードクエリキャッシュの使用

フィルターコンテキストで使用されるクエリ結果は、高速検索のためにノードクエリキャッシュにキャッシュされます。

フィルターコンテキストクエリ結果のキャッシュの利点:

キャッシュヒット率

フィルタークエリはキャッシュヒット率が高く、複数のクエリで再利用されることがよくあります。

コンピューティングリソースを節約する

結果をキャッシュすると、計算の繰り返しが減り、リソースが節約されます。

クエリ速度の向上

キャッシュにより、クエリ、特に複雑なクエリやデータ量の多いフィルタクエリが高速化されます。

同時クエリの動作が向上

ノードクエリキャッシュは、同時実行性が高いシナリオでパフォーマンスを向上させる役割を果たします。

注: キャッシュの使用量とメモリ消費量の間にはバランスがあります。頻繁に変更されるクエリやキャッシュヒット率が低いクエリの場合、キャッシュの有効性が限定される可能性があります。

Elasticsearchキャッシュの詳細な説明

3.7 シャード化されたクエリキャッシュの使用

シャードクエリキャッシュは、「index.requests.cache.enable」を true に設定することで有効にできます。

設定の参考は以下の通りです。

PUT /my-index-000001
{
  "settings": {
    "index.requests.cache.enable": false
  }
}

公式文書のアドレス:

https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html

3.8 インデックステンプレートの使用

インデックステンプレートは、新しいインデックスに設定とマッピングを自動的に適用するのに役立ちます。

インデックステンプレートを使用する利点:

一貫性

クラスターの一貫性のために、新しいインデックスの設定とマッピングが同じであることを確認してください。

操作を簡素化

事前定義された設定とマッピングを自動的に適用し、手動構成を削減します。

拡張しやすい

同じ構成で新しいインデックスをすばやく作成し、クラスターのスケーリングを容易にします。

バージョン管理とアップデート

テンプレートのバージョン管理を実装して、新しいインデックスが最新の構成を使用するようにします。

4. パフォーマンス最適化のための提案

4.1 アクティブなシャーディングは CPU に比例する必要があります

アクティブなシャード = プライマリシャード + レプリカシャードの合計。

アクティブなシャードが CPU に比例する理由:

並列処理

アクティブなシャードが増えると並列処理が増加し、クエリとインデックス作成リクエストが高速化されます。CPU コアの数に比例して、CPU リソースを最大限に活用します。

リソースの競争を避ける

アクティブなシャードを CPU コアの数に比例させて、複数のシャードが同じ CPU コアをめぐって競合するのを回避し、パフォーマンスを向上させます。

負荷分散

アクティブなシャードの数が比例するため、リクエストが複数のノードに分散され、単一ノードでのリソースのボトルネックが回避されます。

パフォーマンスの最適化

CPU コアの数に比例するシャードの数により、利用可能なコンピューティングリソースに応じて処理能力がシャードに割り当てられ、クエリとインデックス作成の操作が最適化されます。

注: 実際の展開では、メモリ、ディスク、ネットワークリソースなどの他の要素を考慮する必要があります。

前述したように、書き込み集中型のユースケースのパフォーマンスを向上させるには、更新間隔を大きな値 (30 秒など) に増やし、プライマリシャードを増やして書き込みリクエストをさまざまなノードに分散する必要があります。読み取り集中型のユースケースでは、レプリカシャードを増やしてレプリカ間でクエリ/検索リクエストのバランスを取ると効果的です。

4.2 クエリに日付範囲フィルターがある場合は、データを日付別に整理します。

ログ記録または監視シナリオの場合、インデックスを日、週、または月ごとに整理し、指定した日付範囲ごとにインデックスのリストを取得すると、パフォーマンスが向上する可能性があります。

Elasticsearch は、データセット全体ではなく、より小さなデータセットのみをクエリする必要があり、データの有効期限が切れたときに古いインデックスを縮小/削除するのは簡単です。

否定的なケース: 以前は、100 TB を超える顧客のデータに日付形式フィールドがないか、フィールド形式が標準化されていないという問題がありました。

4.3 クエリにフィルターフィールドがあり、その値が列挙可能な場合、データを複数のインデックスに分割します。

クエリに列挙可能なフィルターフィールド (地域など) が含まれている場合、データを複数のインデックスに分割することでクエリのパフォーマンスを向上させることができます。

たとえば、データに米国、ヨーロッパ、その他の地域のレコードが含まれており、クエリが「地域」を使用して頻繁にフィルターされる場合、データは 3 つのインデックスに分割され、それぞれに一連の地域のデータが含まれる可能性があります。

これにより、フィルター句「region」を使用してクエリを実行するときに、Elasticsearch はそのリージョンのデータを含むインデックスを検索するだけで済み、クエリのパフォーマンスが向上します。

5. 拡張に関する提案

5.1 インデックスのステータス管理

カスタム管理ポリシーを定義して一般的なタスクを自動化し、それらをインデックスとインデックススキーマに適用します。たとえば、30 日後にインデックスを読み取り専用にし、90 日後に削除するポリシーを定義できます。

ILM (インデックスライフサイクル管理) は、インデックスの管理とメンテナンスを自動化する Elasticsearch の機能であり、次の利点があります。

インデックス管理の簡素化: インデックスの作成、更新、削除、アーカイブなどのインデックスのライフサイクル管理を自動化し、管理者の負担を軽減します。
パフォーマンスの向上: フラグメントのサイズの調整、インデックスの縮小、期限切れデータの削除などのインデックス設定を自動的に最適化して、クエリのパフォーマンスを向上させ、ストレージスペースの使用量を削減します。
コストの削減: 期限切れのデータを自動的にアーカイブおよび削除し、ストレージコストを削減し、管理者の作業負荷と時間コストを削減します。
スケーラビリティの向上: 必要に応じてインデックス設定とストレージポリシーを自動的に調整し、データの増大や変化に対するインデックスの適応性を高めます。

ILM を使用すると、インデックス管理がよりシンプルになり、信頼性が高まります。

5.2 スナップショットのライフサイクル管理

SLM (スナップショットライフサイクル管理) は、スナップショットの管理とメンテナンスを自動化する Elasticsearch 機能であり、次の利点があります。

簡素化されたスナップショット管理: スナップショットの作成、管理、削除、クリーンアップなどのスナップショットのライフサイクル管理を自動化し、管理者の負担を軽減します。
効率の向上: スナップショットを自動的に作成、管理、削除、クリーンアップして管理効率を向上させます。
ストレージコストの削減: 不要なスナップショットを自動的に削除して、ストレージコストを削減します。
スケーラビリティの向上: 必要に応じてスナップショットの設定とストレージポリシーを自動的に調整し、データの増大や変化に対するスナップショットの適応性を高めます。

SLM を使用すると、スナップショット管理がより簡単かつ信頼性が高くなり、管理効率が向上し、ストレージコストが削減されます。

Elasticsearch スナップショットライフサイクル管理 (SLM) の実践ガイド

5.3 モニタリングを上手に活用する

Elasticsearch クラスターのパフォーマンスを監視し、潜在的な問題を検出するには、次のメトリクスを定期的に追跡する必要があります。

クラスターの健全性ノードとシャード: クラスター内のノードの数、シャードとその分布を監視します。
検索パフォーマンス: リクエストの遅延とレート - 検索リクエストの遅延と 1 秒あたりの検索リクエストの数を追跡します。
インデックスのパフォーマンス: リフレッシュ時間とマージ時間 - インデックスのリフレッシュにかかる時間とセグメントのマージにかかる時間を監視します。
ノード使用率: スレッドプール - インデックスプールなど、各ノードのスレッドプールの使用状況を監視します。

6. まとめ

これらのベストプラクティスに従うことで、パフォーマンスが高く、信頼性が高く、スケーラブルな Elasticsearch デプロイメントを確保できます。

Elasticsearch は、大量のデータを迅速かつほぼリアルタイムで処理できる強力な検索および分析エンジンですが、それを最大限に活用するには、展開の計画、最適化、監視が必要であることに注意してください。

上記の提案は参考のみであり、実際の操作は、Elasticsearch の公式ドキュメントと独自のクラスターのパフォーマンステストの結果に基づいています。普遍的な最適化の提案はありません。自分に合った最適化のみが最良の最適化です。

推奨読書

より多くの乾物をより短時間で素早く入手できます。

世界中の約 2,000 人以上の Elastic 愛好家と一緒に改善しましょう!

同僚より一足先に上級乾物を学ぼう！