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

最終更新日: 2021 年 8 月 5 日

Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) クラスターで検索レイテンシースパイクが発生しています。検索レイテンシースパイクをトラブルシューティングして解決するにはどうすればよいですか?

簡単な説明

検索リクエストの場合、往復時間は次のように計算されます。

Round trip = Time the query spends in the query phase + time in the fetch phase + time spent in the queue + network latency

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

OpenSearch Service クラスターでの検索のレイテンシースパイクのトラブルシューティングを行うには、次のような手順があります。

  • クラスターでプロビジョンされたリソースが不足していないか確認する
  • CloudWatch で ThreadpoolSearchRejected メトリクスを使用して検索拒否をチェックする
  • 検索スローログとプロファイル API を使用する
  • 504 GatewayTimeout エラーを解決する

解決方法

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

クラスターでプロビジョニングされたリソースが不足している場合、検索レイテンシーのスパイクが発生する可能性があります。十分なリソースがプロビジョンされていることを確認するには、次のベストプラクティスを使用します。

1.    Amazon CloudWatch を使用して CPUUtilization メトリックと JVMMemory の負荷をチェックし、推奨されるしきい値内であることを確認します。詳細については、推奨 CloudWatch アラームを参照してください。

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

GET /_nodes/stats

出力で、caches、fielddata、および jvm のセクションを確認します。この API を複数回、時間をおいて実行して出力を比較します。

3.    OpenSearch Service はファイルシステムキャッシュを使用して、検索リクエストを高速化します。NodeStats API 出力でキャッシュの削除を確認します。出力内のキャッシュ削除の数が多い場合は、要求を処理するのにキャッシュサイズが不十分であることを意味します。この場合、より多くのメモリを持つ大きなノードを使用することを検討してください。

4.    高度に一意の値を含むフィールドに対して集計を実行すると、ヒープ使用量が増加する可能性があります。集計クエリが既に使用されている場合、検索オペレーションでは FieldData が使用されます。FieldData は、スクリプト内のフィールド値の並べ替えとアクセスにも使用されます。FieldData の削除は、indices.fielddata.cache.size ファイルのサイズと、JVM ヒープ領域の 20% を占めるこのアカウントに依存します。削除は、キャッシュを超えたときに開始されます。

高い JVM メモリのトラブルシューティングの詳細については、Amazon OpenSearch Service クラスターで高い JVM メモリ負荷をトラブルシューティングするにはどうすればよいですか? を参照してください。

高い CPU 使用率をトラブルシューティングするには、Amazon OpenSearch Service クラスターにおける高い CPU 使用率をトラブルシューティングするにはどうすればよいですか? を参照してください。

CloudWatch で ThreadpoolSearchRejected メトリクスを使用して検索拒否をチェックする

CloudWatch を使用して検索拒否を確認するには、Amazon OpenSearch Service での検索または書き込み拒否を解決するにはどうすればよいですか? を参照してください。

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

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

注: ログのしきい値を非常に低い値に設定すると、JVM メモリ負荷が増加する可能性があります。その場合、ガベージコレクションが頻繁に発生し、CPU 使用率が増加して、クラスターのレイテンシーが増加する可能性があります。より多くのクエリを記録するとコストも増加します。プロファイル API の出力は長くなる場合があります。この場合、検索クエリに大きなオーバーヘッドが追加されます。

504 Gateway Timeout エラーを解決する

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

注: 特定の HTTP エラーコードを識別するには、エラーログを有効にする必要があります。HTTP エラーコードの詳細については、Viewing Amazon OpenSearch Service error logs を参照してください。

検索レイテンシ―が高くなるその他の要因

検索レイテンシ―が高くなる原因には、他にもさまざまな要因があります。検索レイテンシ―が高い場合のトラブルシューティングを行うには、次のヒントを参考にしてください。

  • ガベージコレクションアクティビティが頻繁に実行された場合、または長時間実行された場合と、検索パフォーマンスの問題が発生する可能性があります。ガベージコレクションアクティビティによってスレッドが一時停止し、検索レイテンシ―が増加することがあります。詳細については、Elasticsearch ウェブサイトの Managing Elasticsearch's managed heap を参照してください。
  • プロビジョンド IOPS (または i3 インスタンス) は、Amazon Elastic Block Store (Amazon EBS) のボトルネックを取り除くのに役立つ可能性があります。ほとんどの場合、これは必要ありません。i3 に目を向ける前に、i3 ノードと r5 ノードの間のパフォーマンスをテストすることがベストプラクティスです。
  • クラスターのシャードが多すぎると、クラスターが非アクティブであってもリソースの使用率が増加する可能性があります。シャードが多すぎると、クエリのパフォーマンスが低下します。レプリカシャード数を増やすと検索の高速化に役立ちますが、特定のノードで 1000 シャードを超えないようにしてください。また、シャードのサイズが 10 GiB から 50 GiB の間であることを確認してください。理想的には、ノード上のシャードの最大数はヒープ x 20 です。
  • セグメントが多すぎる場合や削除されたドキュメントが多すぎる場合、検索のパフォーマンスに影響します。その場合、読み取り専用インデックスで強制マージを使用することをお勧めします。ユースケースが許せば、アクティブなインデックスの内部更新の頻度を増やします。詳細については、Elasticsearch ウェブサイトの Lucene's handling of delete documents を参照してください。
  • クラスターが VPC 内にある場合は、同じ VPC 内でアプリケーションを実行することを検討してください。
  • 読み取り専用データには UltraWarm ノードまたはホットデータノードの使用を検討してください。ホットストレージは、新しいデータのインデックス作成および検索において、可能な限り高速のパフォーマンスを提供します。ただし、クラスターに大量の読み取り専用データを保存するための方法としては、UltraWarm ノードが費用対効果の高い方法です。アクティブに書き込みを行っていない、同じパフォーマンスを必要としないインデックスについては、UltraWarm は、データの GiB あたりのコストを大幅に削減します。
  • ワークロードをテストして、検索するデータをすべてのノードで利用可能にすることでメリットがあるかどうかを確認します。アプリケーションによっては、特にクラスターにインデックスが少ない場合に、このアプローチの利点があります。これを行うには、レプリカシャードの数を増やします。その場合、インデックス作成のレイテンシ―が増える可能性があることに注意してください。また、追加するレプリカを収容するために、追加の Amazon EBS ストレージが必要になる場合があります。その場合、EBS ボリュームコストが増加します。
  • 検索するフィールドの数をできる限り減らし、スクリプトやワイルドカードを使用したクエリを回避します。詳細については、Elasticsearch ウェブサイトの Tune for search speed を参照してください。
  • 多数のシャードがあるインデックスでは、カスタムルーティングを使用して検索を高速化できます。カスタムルーティングでは、リクエストをインデックスのすべてのシャードにブロードキャストするのではなく、データを保持しているシャードのみがクエリされるようにします。詳細については、Elasticsearch ウェブサイトの Customizing your document routing を参照してください。

この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?