Amazon OpenSearch Service の OpenSearch Dashboards で発生する「クーリエ取得: m 個のうち n 個のシャードが失敗しました」エラーを解決するにはどうすればよいですか?

簡単な説明

OpenSearch Dashboards でダッシュボードをロードすると、検索リクエストが OpenSearch Service ドメインに送信されます。この検索リクエストは、 コーディネーティングノードとして機能するクラスターノードにルーティングされます。「 Courier fetch: n of m shards failed」(クーリエの取得: m 個中 n 個のシャードが失敗しました) エラーは、 コーディネーティングノードが検索リクエストの 取得フェーズを完了できない場合に発生します 。通常、このエラーを引き起こす原因としては 2 つが考えられます。

• 持続的な問題: マッピングが競合しているか、シャードが未割り当て。インデックスパターンの中に、同じ名前だが異なるマッピングタイプを使用する複数のインデックスが存在する場合、「Courier fetch」(クーリエ取得) エラーが発生することがあります。クラスターのクラスターステータスが赤になっている場合は、割り当てられていないシャードが少なくとも 1 つ存在します。OpenSearch Service は未割り当てのシャードからドキュメントを取得できないため、ステータスが赤になっているクラスターは、「Courier fetch」(クーリエ取得) エラーをスローします。「Courier fetch」(クーリエ取得) エラーメッセージの「n」の値が、エラーを受け取るたびに同じである場合は、持続的な問題である可能性があります。アプリケーションエラーログで、トラブルシューティングに関する提案を確認します。
  注: 持続的な問題は、クラスターリソースを再試行したり、さらにプロビジョニングしたりしても解決できません。
• 一時的な問題: 一時的な問題には、スレッドプールの拒否、検索タイムアウト、およびフィールドデータサーキットブレーカーの失敗が含まれます。これらの問題は、クラスターに十分なコンピューティングリソースがない場合に発生します。毎回「n」値が異なるエラーメッセージを断続的に受け取っている場合、一時的な問題が原因である可能性があります。CPUUtilization、JVMMemoryPressure、ThreadpoolSearchRejected などの Amazon CloudWatch メトリクスを監視することで、クーリエフェッチエラーの原因が一時的な問題なのかを確認することもできます。

解決方法

ドメインのアプリケーションエラーログを有効にします 。ログは、根本原因を特定し、一時的な問題および持続的な問題の両方に対する解決方法を見つけるのに役立ちます。詳細については、「Viewing OpenSearch Service error logs」(OpenSearch Service エラーログの表示) を参照してください。

持続的な問題

次に示すのは、持続的な問題が原因のクーリエ取得****エラーのログエントリの一例です。

[2019-07-01T12:54:02,791][DEBUG][o.e.a.s.TransportSearchAction] [ip-xx-xx-xx-xxx] [1909731] Failed to execute fetch phase
org.elasticsearch.transport.RemoteTransportException: [ip-xx-xx-xx-xx][xx.xx.xx.xx:9300][indices:data/read/search[phase/fetch/id]]
Caused by: java.lang.IllegalArgumentException: Fielddata is disabled on text fields by default. 
Set fielddata=true on [request_departure_date] in order to load fielddata in memory by uninverting the inverted index.
Note that this can however use significant memory. Alternatively use a keyword field instead.

この例は、問題が request_departure_date フィールドにより引き起こされたことを示しています。このログエントリからは、インデックス設定に fielddata=true を設定するか、キーワードフィールドを使用することで、問題を解決できることが読み取れます。

一時的な問題

一時的な問題のほとんどは、より多くのコンピューティングリソースをプロビジョニングするか、クエリのリソース使用率を下げることによって解決できます。

より多くのコンピューティングリソースをプロビジョニングする

• インスタンスタイプをより大きなものに変更してドメインをスケールアップするか、クラスターにさらにノードを追加してスケールアウトします。詳細については、「OpenSearch Service ドメインの作成と管理」を参照してください。
• ユースケースに適したインスタンスタイプを使用していることを確認します。詳細については、インスタンスタイプとテストの選択を参照してください。

クエリのリソース使用率を下げる

• シャードとクラスターのアーキテクチャに関するベストプラクティスに従っていることを確認します 。クラスターの設計に不備がある場合など、可能なすべてのリソースを使用できないことがあります。一部のノードがアイドル状態になってしまうと、他のノードが過負荷になり得ます。OpenSearch Service は、過負荷になったノードからドキュメントを取得できません。
• また、クエリの範囲を縮小することもできます。例えば、フレームに関してクエリする場合は、Kibana でインデックスパターンを設定して、日付範囲を狭めるか結果をフィルタリングします。
• 大きいインデックスで選択 * クエリを実行しないようにします。代わりに、フィルターを使用してインデックスの一部をクエリし、できる限り少ないフィールドを検索します。詳細については、Elasticsearch ウェブサイトの「検索速度を調整する」と「クエリとフィルターのコンテキスト」を参照してください。
• インデックスを再作成し、シャードの数を減らします。クラスター内のシャードが多いほど、クーリエ取得****エラーが発生する可能性が高くなります。各シャードにリソース割り当てとオーバーヘッドがあるため、多数のシャードはクラスターに過剰な負荷をかけます。詳細については、「OpenSearch Service ドメインが「処理中」状態のまま変わらないのはなぜですか」を参照してください。

一時的な問題によって発生する「Courier fetch error」(クーリエ取得エラー) のログエントリの一例を次に示します。

Caused by: org.elasticsearch.common.util.concurrent.EsRejectedExecutionException: rejected execution of org.elasticsearch.common.util.concurrent.TimedRunnable@26fdeb6f on QueueResizingEsThreadPoolExecutor
[name = __PATH__ queue capacity = 1000, min queue capacity = 1000, max queue capacity = 1000, frame size = 2000, targeted response rate = 1s, task execution EWMA = 2.9ms, adjustment amount = 50,
org.elasticsearch.common.util.concurrent.QueueResizingEsThreadPoolExecutor@1968ac53[Running, pool size = 2, active threads = 2, queued tasks = 1015, completed tasks = 96587627]]

この例では、問題の原因はスレッドプールの検索キューが拒否されたことにあります。この問題を解決するには、より大きいインスタンスタイプを選択してドメインのスケールアップを行います。詳細については、Elasticsearch ウェブサイトの「スレッドプール」を参照してください。

---

関連情報

Amazon OpenSearch Service のベストプラクティス

Amazon OpenSearch Service のトラブルシューティング