OpenSearch Service クラスターで検索遅延が急増する場合のトラブルシューティング方法を教えてください。

簡単な説明

検索リクエストに対し、OpenSearch Service は次の式を使用してラウンドトリップ時間を計算します。

ラウンドトリップ = クエリフェーズの所要時間 + フェッチフェーズの所要時間 + キューの待ち時間 + ネットワーク遅延

Amazon CloudWatch の SearchLatency OpenSearch Service メトリクスは、クエリがクエリフェーズで費やした時間を示します。

OpenSearch Service クラスターにおける検索遅延の急増をトラブルシューティングするには、次の手順を実行します。

• インフラストラクチャメトリクス (例: CPU 使用率、ディスク使用率、Java Virtual Machine (JVM) のメモリ負荷、ガベージコレクションに関連するメモリ) を確認します。
• SearchRate メトリクスが急増していないか確認します。
• ThreadpoolSearchRejected メトリクスを参照して検索が拒否されていないかを確認します。
• スローログを使用して長時間実行クエリを特定します。
• "504 gateway timeout" エラーを解決します。
• 構成を最適化して遅延を軽減します。

解決策

インフラストラクチャメトリクスを確認する

リソースの使用率が高い場合、オペレーティングシステム (OS) のデータノードでガベージコレクションが頻発し、長時間実行されます。クラスターに十分なリソースがプロビジョニングされていない場合、検索遅延が急増する可能性があります。

リソース使用率が高い場合のトラブルシューティング

クラスターの CPUUtilization および JVMMemoryPressure メトリクスが 80% 未満であることを確認します。CloudWatch のこれらのメトリクス値が 80% を上回る場合は、高 CPU 使用率や高 JVM メモリ負荷をトラブルシューティングします。

リソース使用率をプロアクティブに監視するために、OpenSearch Service に対する CloudWatch アラームを設定します。

クラスターのノードレベルの統計情報を取得するには、5 分ごとに次のクエリを複数回実行します。

GET /_nodes/stats

出力において、各実行の間にキャッシュ使用率、フィールドデータメモリ、および JVM ヒープの値に有意な変化がないか確認します。一貫した値は、正常に動作していることを示します。何らかの問題がある場合は、突然の急増や急落が発生する可能性があります。

キャッシュ設定を確認する

OpenSearch Service は、パフォーマンスとリクエストの応答時間を向上させるために、次のキャッシュを使用します。

• OS レベルに存在するファイルシステムキャッシュ（ページキャッシュ）
• OpenSearch Service レベルに存在するシャードレベルのリクエストキャッシュとクエリキャッシュ

ファイルシステムキャッシュの情報を確認するには、次のクエリを実行します。

GET /_nodes/stats/indices/request_cache?human

シャードレベルのリクエストキャッシュの情報を確認するには、次のクエリを実行します。

GET /_nodes/stats/indices/query_cache?human

出力から、キャッシュのエビクションがないか確認します。キャッシュのエビクションが多い場合、キャッシュが小さすぎるため、リクエストを処理できません。エビクションを削減するには、よりメモリの多い大容量ノードを使用します。ノードサイズの料金に関する詳細については、「OpenSearch Service の料金」を参照してください。OpenSearch キャッシュに関する詳細については、Elastic のウェブサイトの「Elasticsearch のキャッシングに関する詳細: クエリスピードを高速化できるキャッシュ方法を1つずつ順に解説」を参照してください。

キャッシュをクリアする方法については、OpenSearch のウェブサイトで「Clear cache API」を参照してください。

一意性の高い値を含むフィールドで集計を実行すると、ヒープ使用量が増加する可能性があります。集計クエリに対する検索操作では、フィールドデータを使用します。また、フィールドデータはスクリプト内のフィールド値をソートしてアクセスします。フィールドデータのエビクションは、indices.fielddata.cache.size ファイルの設定に依存します。この値は、JVM ヒープの 20% に相当します。

クラスター内の全ノードでフィールドデータが消費するメモリ量を確認するには、次のクエリを実行します。

GET /_nodes/stats/indices/fielddata?human

SearchRate メトリクスが急増していないか確認する

短期間に複数の検索リクエストを行うと、クラスターのリソースに負荷がかかり、結果的にクエリ処理が低速化し、個別の検索への応答時間が遅くなる可能性があります。OpenSearch Service の検索レートが高い場合、検索遅延が増加する可能性があります。SearchRate メトリクスが急増している場合は、その急増が検索遅延の急増に伴って発生しているかどうかを確認します。これらの急増が同時に発生している場合は、クラスターにリソースを追加するか、クエリを最適化して検索負荷に対処する必要があります。

検索拒否がないかを確認する

ThreadpoolSearchRejected メトリクスを使用して検索拒否を特定し、解決します。

スローログを使用して長時間実行クエリを特定する

長時間実行クエリ、および特定のシャードでクエリが費やした時間を特定するには、スローログを使用します。クエリフェーズのしきい値を設定し、各インデックスのフェーズを取得します。

クエリフェーズでクエリが費やした時間に関する詳細な概要を取得するには、検索クエリで profile を true に設定します。

クエリ例:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

注: ログ記録のしきい値が過度に低い場合、JVM メモリ負荷とクラスター遅延が増加する可能性があります。ログ記録するクエリの増加に伴い、コストも増加します。profile 設定が true であるクエリの大規模な出力が原因で、他の検索クエリのオーバーヘッドが増加します。結果的に、他の検索が一時的に低速化します。

504 gateway timeout エラーの解決

前提条件 特定の HTTP エラーコードを識別するために、エラーログを有効にすること。

OpenSearch Service クラスターのアプリケーションログを参照し、個別のリクエストに対する特定の HTTP エラーコードを確認します。HTTP 504 gateway timeout エラーの解決方法については、「OpenSearch Service で HTTP 504 gateway timeout エラーを予防する方法を教えてください」を参照してください。

構成を最適化する

ガベージコレクションアクティビティを管理する

ガベージコレクションアクティビティが頻発するか、長時間実行されることが原因で、検索パフォーマンスの問題、スレッドの一時停止、検索遅延の増加などの問題が発生する可能性があります。ガベージコレクションの時間を削減するためのベストプラクティスについては、Elastic のウェブサイトで「ヒープというトラブル: Elasticsearch のマネージドヒープを管理する」を参照してください。

インスタンスストレージを最適化する

Amazon Elastic Compute Cloud (Amazon EC2) インスタンスタイプは、Amazon Elastic Block Store (Amazon EBS) 最適化ストレージまたはインスタンスストアボリュームを使用できます。インスタンスストアボリュームは、直接アタッチされたストレージおよび高い IOPS 性能を備えているため、I/O のボトルネック対策に便利です。一方、Amazon EBS 最適化インスタンスでは、一貫したパフォーマンスを備えた永続ストレージを利用できます。I/O、データの永続性、コストに基づき、構成要件に適したストレージタイプを選択してください。

インスタンスタイプを変更する前に、異なるインスタンスタイプでパフォーマンスをテストし、ワークロード要件を満たしていることを確認することをおすすめします。利用可能な OpenSearch Service インスタンスタイプのリストについては、「OpenSearch Service の料金」の「無料利用枠」および「オンデマンドインスタンスの料金」を参照してください。

注: クラスターが仮想プライベートクラウド (VPC) 内に配置されている場合は、アプリケーションを同じ VPC 内で実行することをおすすめします。

シャードとセグメントの構成を簡素化する

クラスター内のシャード数が過剰な場合、クラスターがアクティブでない場合もリソース使用率が増加する可能性があります。シャード数の過剰は、クエリパフォーマンスの低速化にもつながります。レプリカのシャード数を増やすと、検索が高速化します。ただし、単一のノードで 1000 個を超えるシャードを使用することは避けてください。また、シャードサイズは 10 GiB から 50 GiB の間である必要があります。ノード上のシャードの最大数は、ヒープサイズの 20 倍に設定することをおすすめします。再インデックスまたはシャード戦略の変更を行う方法については、OpenSearch のウェブサイトで「OpenSearch インデックスのシャードサイズを最適化する」を参照してください。

セグメント数または削除されたドキュメント数が多すぎる場合も、検索パフォーマンスが影響を受けます。パフォーマンスを向上させるには、読み取り専用インデックスでは強制マージを使用し、アクティブなインデックスでは更新間隔を長くします。詳細については、OpenSearch のウェブサイトで「Force merge API」および「OpenSearch の更新間隔を最適化する」を参照してください。

すべてのノードにレプリカシャードを追加する前に、アプリケーションの要件を評価します。アプリケーションがあらゆるノードのすべてのデータを検索する必要がある場合は、レプリカシャードの数を増やしてデータの可用性を向上させます。その必要がない場合は、すべてのノードにレプリカシャードを配置せずに済む可能性があります。

注: レプリカシャードにより、クラスターが並列処理を行い、検索リクエストをデータの複数コピーに分散させることができます。結果的に、検索パフォーマンスが向上します。ただし、インデックス作成操作は低速化し、完全なデータコピーごとに追加のストレージが必要になります。

インデックスに多数のシャードが含まれる場合は、カスタムルーティングを使用して検索パフォーマンスを改善します。カスタムルーティングにより、すべてのシャードではなく、データを保持しているシャードのみにクエリを実行します。カスタムルーティングの構成方法については、Elastic のウェブサイトで「ドキュメントのルーティングをカスタマイズ」を参照してください。

読み取り専用データに Ultrawarm ストレージを使用する

ホットストレージでは、新しいデータのインデックス作成と検索に最速のパフォーマンスを実現できます。一方、UltraWarm ノードは、クラスター上の大量の読み取り専用データを保存するための費用対効果に優れた方法となります。読み取り専用インデックスで高いパフォーマンスを必要としない場合は、ホットデータストレージではなく、UltraWarm を使用してください。

検索を高速化する

検索するフィールドを可能な限り少なくし、スクリプトやワイルドカードクエリの使用は避けてください。詳細については、Elastic のウェブサイトで「検索高速化のためのチューニング」を参照してください。