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

최종 업데이트 날짜: 2020년 12월 16일

Amazon Elasticsearch Service(Amazon ES) 도메인에서 Kibana에 대시보드를 로드할 때 Courier fetch 오류가 반환됩니다. 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

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

  • 지속적 문제: 매핑 충돌 또는 할당되지 않은 샤드. 인덱스 패턴에 여러 인덱스가 있고 이름이 같지만 매핑 유형이 서로 다른 경우 courier fetch 오류가 발생할 수 있습니다. 클러스터가 빨간색 클러스터 상태인 경우 하나 이상의 샤드가 할당되지 않았음을 의미합니다. Elasticsearch는 할당되지 않은 샤드에서 문서를 가져올 수 없기 때문에 빨간색 상태의 클러스터에서 courier fetch 오류가 발생합니다. Courier fetch 오류 메시지의 “n”값이 오류를 받을 때마다 동일하면 지속적 문제일 수 있습니다. 애플리케이션 오류 로그에서 문제 해결 제안 사항을 확인하세요.
    참고: 더 많은 클러스터 리소스를 다시 시도하거나 프로비저닝하면 지속적 문제를 해결할 수 없습니다.
  • 일시적 문제: 일시적 문제에는 스레드 풀 거부, 검색 시간 초과및 트립된 필드 데이터 회로 차단기가 포함됩니다. 이러한 문제는 클러스터에 컴퓨팅 리소스가 충분하지 않을 때 발생합니다. 일시적 문제는 매번 “n”의 다른 값과 함께 간헐적으로 오류 메시지가 나타날 때 발생할 수 있습니다. CPUUtilization, JVMMemoryPressureThreadpoolSearchRejected 같은 Amazon CloudWatch 지표를 모니터링하여 일시적 문제로 인해 Courier Fetch 오류가 발생했는지 확인할 수도 있습니다.

해결 방법

도메인에 대해 애플리케이션 오류 로그를 활성화합니다. 로그는 일시적 문제 및 지속적 문제 모두에 대한 근본 원인과 해결 방법을 찾는 데 도움이 될 수 있습니다. 자세한 내용은 Amazon Elasticsearch Service 오류 로그 보기를 참조하세요.

지속적 문제

다음 예제는 지속적 문제로 인해 발생하는 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를 설정하거나 키워드 필드를 사용하여 이 문제를 해결할 수 있음을 보여 줍니다.

일시적 문제

대부분의 일시적 문제는 더 많은 컴퓨팅 리소스를 프로비저닝하거나 쿼리에 대한 리소스 사용률을 줄이면 해결할 수 있습니다.

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

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

쿼리의 리소스 사용률을 줄임

  • 샤드 및 클러스터 아키텍처에 대한 모범 사례를 따르고 있는지 확인합니다. 클러스터가 잘못 설계되어 사용 가능한 리소스를 모두 사용하지 못합니다. 일부 노드는 다른 노드가 유휴 상태로 있는 동안 오버로드될 수 있습니다. Elasticsearch는 오버로드된 노드에서 문서를 가져올 수 없습니다.
  • 쿼리 범위를 줄일 수도 있습니다. 예를 들어 시간 프레임을 쿼리하는 경우, 날짜 범위를 좁히거나, Kibana에서 인덱스 패턴을 구성하여 결과를 필터링합니다.
  • 대량의 인덱스에 대해 select * 쿼리를 실행하지 않습니다. 대신, 필터를 사용하여 인덱스 일부를 쿼리하고 가능한 한 적은 수의 필드를 검색합니다. 자세한 내용은 Elasticsearch 웹 사이트의 검색 속도 조정 그리고 쿼리 및 필터 컨텍스트를 참조하세요.
  • 샤드 수를 다시 인덱싱하고 줄입니다. Elasticsearch 클러스터에 샤드가 많을수록 Courier fetch 오류가 발생할 가능성이 높습니다. 각 샤드에는 자체 리소스 할당과 오버헤드가 있기 때문에 많은 수의 샤드는 Elasticsearch 클러스터에 과도한 부담을 줍니다. 자세한 내용은 Amazon Elasticsearch Service(Amazon ES) 도메인이 ‘진행 중’ 상태에서 멈춘 이유는 무엇입니까?를 참조하세요.

다음은 일시적 문제로 인해 발생한 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 대기열 거부로 인해 문제가 발생합니다. 이 문제를 해결하려면 크기가 더 큰 인스턴스 유형을 선택하여 도메인을 확장합니다. 자세한 내용은 Elasticsearch 웹 사이트의 쓰레드 풀을 참조하세요.


이 문서가 도움이 되었나요?


결제 또는 기술 지원이 필요합니까?