Amazon Elasticsearch Service의 Kibana에서 "Courier fetch: n of m shards failed" 오류를 해결하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2019년 8월 23일

Amazon Elasticsearch Service(Amazon ES) 도메인의 Kibana에 대시보드를 로드하려고 하면 "Error: Courier Fetch: 5 of 60 shards failed"와 같은 오류가 반환됩니다.

참고: 이 오류의 원인은 다양합니다. 이 문서에서는 몇 가지 일반적인 근본 원인과 해결 방법을 설명합니다.

간략한 설명

Kibana에 대시보드를 로드하면 Kibana가 Amazon ES 도메인으로 검색 요청을 전송합니다. 검색 요청은 해당 요청에 대한 조정 노드 역할을 하는 클러스터 노드로 라우팅됩니다. 조정 노드가 검색 요청의 가져오기 단계를 완료하지 못하면 "Courier fetch: n of m shards failed" 오류가 발생합니다. 일반적으로 이 오류를 유발하는 두 가지 유형의 문제가 있습니다.

  • 지속적 문제: 매핑 충돌 또는 할당되지 않은 샤드. 인덱스 패턴에 여러 인덱스가 있고 그 인덱스 중 일부에 이름이 같지만 매핑 유형이 서로 다른 필드가 있는 경우 courier fetch 오류가 발생할 수 있습니다. 클러스터가 빨간색 상태인 경우 하나 이상의 샤드가 할당되지 않았음을 의미합니다. Elasticsearch는 할당되지 않은 샤드에서 문서를 가져올 수 없기 때문에 빨간색 상태의 클러스터에서는 courier fetch 오류가 발생합니다. courier fetch 오류가 계속 발생하고 오류 메시지("Courier fetch: n of m shards failed")에서 "n" 값이 항상 동일하면 지속적인 문제가 원인일 수 있습니다. 더 많은 클러스터 리소스로 재시도하거나 프로비저닝해도 지속적인 문제는 해결되지 않습니다. 애플리케이션 오류 로그에서 문제 해결 제안 사항을 확인하십시오.
  • 일시적인 문제: threadpool 거부, 검색 시간 초과, 트립된 필드 데이터 회로 차단기 등. 이러한 문제는 클러스터에 컴퓨팅 리소스가 부족할 때 발생합니다. 오류가 간헐적으로 발생하고 오류 메시지의 "n" 값이 오류가 발생할 때마다 다른 경우 일시적인 문제가 원인일 수 있습니다. CPUUtilization, JVMMemoryPressure 및 ThreadpoolSearchRejected 같은 Amazon Cloudwatch 지표를 모니터링하여 일시적인 문제로 인해 courier Fetch 오류가 발생했는지 확인할 수도 있습니다.

​해결 방법

도메인에 대해 애플리케이션 오류 로그를 활성화합니다. 로그는 일시적 문제 및 지속적 문제 모두에 대한 근본 원인과 해결 방법을 찾는 데 도움이 될 수 있습니다.

지속적 문제

다음은 지속적인 문제로 인해 발생하는 courier Fetch 오류에 대한 로그 항목의 예입니다.

참고: 로그 항목이 항상 이와 같지는 않습니다. 사용자의 로그 항목은 다를 수 있습니다.

[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를 설정하거나 키워드 필드를 사용하여 이 문제를 해결할 수 있음을 보여 줍니다.

일시적 문제

다음은 일시적인 문제로 인해 발생한 courier fetch 오류에 대한 로그 항목의 예입니다.

참고: 로그 항목이 항상 이와 같지는 않습니다. 사용자의 로그 항목은 다를 수 있습니다.

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]]

이 예제에서는 search threadpool 대기열 거부로 인해 문제가 발생합니다. 이 문제를 해결하려면 크기가 더 큰 인스턴스 유형을 선택하여 도메인을 확장하십시오.

대부분의 일시적 문제는 다음 방법 중 하나를 사용하여 해결할 수 있습니다.

더 많은 컴퓨팅 리소스 프로비저닝

  • 크기가 더 큰 인스턴스 유형으로 전환하여 도메인을 확장하거나, 클러스터에 더 많은 노드를 추가하여 확장합니다. 자세한 내용은 Amazon ES 도메인 구성을 참조하십시오.
  • 사용 사례에 적합한 인스턴스 유형을 사용하고 있는지 확인합니다. 자세한 내용은 인스턴스 유형 선택 및 테스트를 참조하십시오.

쿼리의 리소스 사용률 감소

  • 샤드 및 클러스터 아키텍처에 대한 모범 사례를 따르고 있는지 확인합니다. 클러스터가 잘못 설계되어 사용 가능한 리소스를 모두 사용하지 못합니다. 일부 노드는 다른 노드가 유휴 상태로 있는 동안 오버로드될 수 있습니다. Elasticsearch는 오버로드된 노드에서 문서를 가져올 수 없습니다.
  • 쿼리 범위를 줄입니다. 예를 들어 시간 프레임을 쿼리하는 경우 날짜 범위를 줄이거나 Kibana에서 인덱스 패턴을 구성하여 결과를 필터링합니다.
  • 크기가 큰 인덱스에서 select* 쿼리를 실행하지 마십시오. 대신 필터를 사용하여 인덱스의 일부를 쿼리하고 가능한 한 적은 수의 필드를 검색합니다.
  • 샤드 수를 다시 인덱싱하고 줄입니다. Elasticsearch 클러스터에 샤드가 많을수록 courier fetch 오류가 발생할 가능성이 높습니다. 각 샤드에는 자체 리소스 할당 및 오버헤드가 있으므로 샤드 수가 많으면 클러스터에 과도한 부담이 발생합니다. 클러스터의 샤드 수를 줄이려면 내 Amazon Elasticsearch Service 도메인이 한참 동안 처리 상태에서 멈춰 있습니다. 항목을 참조하십시오.

이 문서가 도움이 되었습니까?

AWS에서 개선해야 할 부분이 있습니까?


도움이 필요하십니까?