Amazon OpenSearch Service クラスターでの検索レイテンシーの急上昇をトラブルシューティングするにはどうすればよいですか?

所要時間2分

Amazon OpenSearch Service クラスターで検索レイテンシーが急上昇しています。

簡単な説明

検索リクエストでは、OpenSearch Service は以下のようにラウンドトリップ時間を計算します:

ラウンドトリップ = クエリがクエリフェーズで費やした時間 + フェッチフェーズの時間 + キューで費やした時間 + ネットワークレイテンシー

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

OpenSearch Service クラスターでの検索レイテンシーの急上昇をトラブルシューティングする場合、実行できる手順はいくつかあります:

クラスターにプロビジョニングされているリソースが不足していないか確認する
CloudWatch の ThreadpoolSearchRejected メトリックスを使用して検索が拒否されていないか確認する
search slow logs API と profile API を使用する
504 ゲートウェイのタイムアウトエラーがあれば解決する

解決策

クラスターにプロビジョニングされているリソースが不足していないか確認する

クラスターにプロビジョニングされているリソースが不足している場合、検索レイテンシーが急上昇する場合があります。次のベストプラクティスに従って、十分なリソースがプロビジョニングされていることを確認してください。

1. CloudWatch を使用して、クラスターの CPUUtilization メトリクスと JVMMemory 負荷を確認します。推奨のしきい値内であることを確認します。詳細については、「Recommended CloudWatch alarms for Amazon OpenSearch Service」を参照してください。

2. node stats API を使用して、クラスターのノードレベルの統計情報を取得します:

GET /_nodes/stats

出力で、caches、fielddata、jvm の各セクションを確認します。出力を比較するには、各出力の間隔を空けてこの API を複数回実行します。

3. OpenSearch Service は複数のキャッシュを使用してパフォーマンスとリクエストの応答時間を向上させます:

オペレーティングシステムレベルで存在するファイルシステムのキャッシュまたはページのキャッシュ
OpenSearch Service レベルで存在するシャードレベルのリクエストキャッシュとクエリキャッシュ

キャッシュエビクションの node stats API の出力を確認してください。出力のキャッシュエビクションの数が多いということは、キャッシュサイズがリクエストを処理するには不十分であることを意味しています。エビクションを削減するには、より多くのメモリを備えたより大きなノードを使用してください。

node stats API を使用して特定のキャッシュの情報を表示するには、次のリクエストを使用します。2 番目のリクエストは、シャードレベルのリクエストキャッシュ用です:

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

OpenSearch キャッシュの詳細については、Elastic のウェブサイトの「Elasticsearchのキャッシングに関する詳細：クエリスピードを高速化できるキャッシュ方法を1つずつ順に解説」を参照してください。

さまざまなキャッシュをクリアする手順については、OpenSearch のウェブサイトの「Clear index or data stream cache」を参照してください。

4. 一意性の高い値を含むフィールドで集計を実行すると、ヒープ使用量が増加する可能性があります。集計クエリが既に使用されている場合、検索オペレーションではフィールドデータを使用します。また、フィールドデータはスクリプト内のフィールド値をソートしてアクセスします。フィールドデータのエビクションは indices.fielddata.cache.size ファイルのサイズによって異なり、これが JVM ヒープスペースの 20% を占めます。キャッシュを超えると、エビクションが開始されます。

フィールドデータのキャッシュを表示するには、次のリクエストを使用します:

GET /_nodes/stats/indices/fielddata?human

JVM メモリ使用量が多い場合のトラブルシューティングの詳細については、「Amazon OpenSearch Service クラスターで高い JVM メモリ負荷をトラブルシューティングするにはどうすればよいですか?」を参照してください。
CPU 使用率が高い場合をトラブルシューティングするには、「Amazon OpenSearch Service クラスターの高い CPU 使用率をトラブルシューティングする方法を教えてください。」を参照してください。

CloudWatch の ThreadpoolSearchRejected メトリックスを使用して検索が拒否されていないか確認する

CloudWatch を使用して検索の拒否を確認するには、「OpenSearch サービスで検索拒否または書き込み拒否を解決する方法を教えてください。」の手順に従ってください。

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

スローログを使用すると、実行時間の長いクエリと、クエリが特定のシャードに費やした時間の両方を特定できます。クエリフェーズのしきい値を設定し、各インデックスのフェーズを取得できます。スローログの設定の詳細については、「Viewing Amazon Elasticsearch Service slow logs」を参照してください。クエリフェーズでクエリに費やされた時間の詳細な内訳を確認するには、検索クエリに "profile":true を設定してください。

注: ロギングのしきい値を非常に低い値に設定すると、JVM のメモリ負荷が高まる可能性があります。その場合、ガベージコレクションの頻度が高まり、CPU 使用率が上がり、クラスターのレイテンシーが増加する可能性があります。ログに記録するクエリが増えると、コストも増える可能性があります。profile API の出力が長くなると、検索クエリにかなりのオーバーヘッドが加わります。

504 ゲートウェイのタイムアウトエラーがあれば解決する

OpenSearch Service クラスターのアプリケーションログから、個々のリクエストの特定の HTTP エラーコードを確認できます。HTTP 504 ゲートウェイのタイムアウトエラーの解決の詳細については、「Amazon OpenSearch Service での HTTP 504 ゲートウェイのタイムアウトエラーを防ぐにはどうすればよいですか?」を参照してください。

注: 特定の HTTP エラーコードを識別するには、エラーログをアクティブにする必要があります。HTTP エラーコードの詳細については、「Viewing Amazon OpenSearch Service Error Logs」を参照してください。

検索レイテンシーが上昇する原因となるその他の要因

検索レイテンシーが上昇する場合、他にもさまざまな要因があります。次のヒントを参考にして、検索レイテンシーが上昇する場合のトラブルシューティングをさらに進めてください:

ガベージコレクションアクティビティが頻繁に実行されたり、長時間実行されたりすると、検索パフォーマンスの問題が発生することがあります。ガベージコレクションアクティビティによってスレッドが一時停止し、検索レイテンシーが上昇する場合があります。詳しくは、Elastic のウェブサイトの「A Heap of Trouble: Managing Elasticsearch's Managed Heap」を参照してください。
プロビジョンド IOPS (または i3 インスタンス) は、Amazon Elastic Block Store (Amazon EBS) のボトルネックを排除するのに役立つ場合があります。ほとんどの場合、これらは必要ありません。インスタンスを i3 に移動する前に、i3 ノードと r5 ノードの間のパフォーマンスをテストするのがベストプラクティスです。
シャードが多すぎるクラスターでは、クラスターが非アクティブであってもリソースの使用率が高くなる場合があります。シャードが多すぎるとクエリのパフォーマンスが低下します。レプリカのシャード数を増やすと検索が速くなる可能性がありますが、特定のノードでシャードが 1,000 個を超えないようにしてください。また、シャードサイズは 10 GiB から 50 GiB の間になるようにしてください。理想的には、ノード上のシャードの最大数はヒープ \ * 20 です。
セグメントが多すぎたり、削除されたドキュメントが多すぎたりすると、検索パフォーマンスに影響する場合があります。パフォーマンスを向上させるには、読み取り専用のインデックスに対して強制マージを使用してください。また、可能な場合は、アクティブなインデックスの内部更新を増やしてください。詳細については、Elastic のウェブサイトの「Lucene's Handling of Deleted Documents」を参照してください。
クラスターが仮想プライベートクラウド (VPC) 内にある場合は、アプリケーションを同じ VPC 内で実行するのがベストプラクティスです。
読み取り専用データには UltraWarm ノードまたはホットデータノードを使用してください。ホットストレージは、新しいデータのインデックスの作成と検索を可能な限り高速で実行します。ただし、UltraWarm ノードは、大量の読み取り専用データをクラスターに保存する費用対効果の高い方法です。UltraWarm は、書き込む必要がなく、高パフォーマンスを必要としないインデックスの場合、データ 1 GiB あたりのコストを大幅に削減します。
検索対象データをすべてのノードで利用できるようにすることでワークロードにメリットがあるかどうかを判断してください。一部のアプリケーションでは、特にクラスターにインデックスが少ない場合に、このアプローチによってメリットが得られます。そのためには、レプリカシャードの数を増やしてください。
注: この場合、インデックス作成の待ち時間が長くなる可能性があります。また、追加するレプリカを格納するために、Amazon EBS ストレージを追加する必要がある場合もあります。これにより、EBS ボリュームのコストが増加します。
検索するフィールドはできるだけ少なくし、スクリプトやワイルドカードクエリの使用は避けてください。詳細については、Elastic のウェブサイトの「Tune for search speed」を参照してください。
シャードが多いインデックスでは、カスタムルーティングを使用して検索を高速化します。カスタムルーティングにより、すべてのシャードにリクエストをブロードキャストするのではなく、データを保持するシャードのみにクエリを実行できるようになります。詳細については、Elastic のウェブサイトの「Customizing Your Document Routing」を参照してください。