Amazon Elasticsearch Service에서 검색 또는 쓰기 거부를 해결하려면 어떻게 해야 합니까?

최종 업데이트 날짜: 2021년 3월 25일

Amazon ES(Amazon Elasticsearch Service) 클러스터에 검색 또는 쓰기 요청을 제출하면 요청이 거부되고 오류가 발생합니다. 이유가 무엇입니까?

간략한 설명

Elasticsearch 클러스터에서 데이터를 쓰거나 검색할 때 다음과 같은 HTTP 429 오류 또는 es_rejected_execution_exception이 발생할 수 있습니다.

error":"elastic: Error 429 (Too Many Requests): rejected execution of org.elasticsearch.transport.TransportService$7@b25fff4 on 
EsThreadPoolExecutor[bulk, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@768d4a66[Running, 
pool size = 2, active threads = 2, queued tasks = 200, completed tasks = 820898]] [type=es_rejected_execution_exception]"

Reason={"type":"es_rejected_execution_exception","reason":"rejected execution of org.elasticsearch.transport.TcpTransport$RequestHandler@3ad6b683 on EsThreadPoolExecutor[search, queue capacity = 1000, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@bef81a5[Running, pool size = 25, active threads = 23, queued tasks = 1000, completed tasks = 440066695]]"

HTTP 429 오류 또는 es_rejected_execution_exception의 원인이 될 수 있는 변수는 다음과 같습니다.

  • 데이터 노드 인스턴스 유형 및 검색 또는 쓰기 제한
  • 인스턴스 지표의 높은 값
  • 활성 스레드 및 대기열 스레드

HTTP 429 오류는 Elasticsearch 클러스터에 대한 검색쓰기 요청으로 인해 발생할 수 있습니다. 또한 거부는 클러스터의 단일 노드 또는 여러 노드에서 발생할 수 있습니다.

중요: Amazon ES의 버전에 따라 _index API에 대한 호출을 처리할 때 사용되는 스레드 풀이 다릅니다. Elasticsearch 버전 1.5 및 2.3은 인덱스 스레드 풀을 사용합니다. Elasticsearch 버전 5.x, 6.0 및 6.2는 대량 스레드 풀을 사용합니다. Elasticsearch 버전 6.3 이상은 쓰기 스레드 풀을 사용합니다. 자세한 내용은 Elasticsearch 웹 사이트의 Thread pool을 참조하세요.

해결 방법

데이터 노드 인스턴스 유형 및 검색 또는 쓰기 제한

데이터 노드 인스턴스 유형의 경우 가상 CPU(vCPU) 수가 고정되어 있습니다. vCPU 수를 수식에 연결하면 노드가 대기열에 들어가기 전에 수행할 수 있는 동시 검색 또는 쓰기 작업을 검색할 수 있습니다. 활성 스레드가 가득 차면 스레드가 대기열로 이동하고 결국 거부됩니다. vCPU와 노드 유형 간의 관계에 대한 자세한 내용은 Amazon Elasticsearch Service 요금을 참조하세요.

또한 수행할 수 있는 노드당 검색 수 또는 노드당 쓰기 수에도 제한이 있습니다. 이 제한은 스레드 풀 정의 및 Elasticsearch 버전 번호를 기준으로 합니다. 자세한 내용은 Elasticsearch 웹 사이트의 Thread pool을 참조하세요.

예를 들어 Elasticsearch 클러스터(버전 7.4)의 5개 노드에 대해 R5.2xlarge 노드 유형을 선택한 경우 vCPU 수는 8개입니다.

검색 요청에 대한 최대 활성 스레드를 계산하려면 다음 수식을 사용합니다.

int ((# of available_processors * 3) / 2) + 1

쓰기 요청에 대한 최대 활성 스레드를 계산하려면 다음 수식을 사용합니다.

int (# of available_processors) + 1

따라서 R5.2xlarge 노드의 경우 최대 13개의 검색 작업을 수행할 수 있습니다.

(8 VCPUs * 3) / 2 + 1 = 13 operations

R5.x2large 노드의 경우 최대 9개의 쓰기 작업을 수행할 수 있습니다.

8 VCPUs + 1 = 9 operations

노드가 5개인 Elasticsearch 클러스터의 경우 최대 65개의 검색 작업을 수행할 수 있습니다.

5 nodes * 13 = 65 operations

노드가 5개인 Elasticsearch 클러스터의 경우 최대 45개의 쓰기 작업을 수행할 수 있습니다.

5 nodes * 9 = 45 operations

인스턴스 지표의 높은 값

429 예외를 해결하려면 Elasticsearch 클러스터에 대한 다음 Amazon CloudWatch 지표를 확인합니다.

  • IndexingRate: 분당 인덱싱 작업 수입니다. 문서 2개를 추가하고 2건을 4개의 작업으로 업데이트하는 _bulk API에 대한 단일 호출이며 하나 이상의 노드에 분산될 수 있습니다. 인덱스에 복제본이 하나 이상 있는 경우 클러스터의 다른 노드도 총 4개의 인덱싱 작업을 기록합니다. 문서 삭제는 IndexingRate 지표 계산에 포함되지 않습니다.
  • SearchRate: 데이터 노드의 모든 샤드에 대한 분당 검색 요청의 총 수입니다. _search API에 대한 단일 호출에서 여러 샤드의 결과가 반환될 수 있습니다. 한 노드에 5개의 다른 샤드가 있는 경우 클라이언트에서 요청을 한 건만 수행하더라도 노드는 이 지표를 "5"로 보고합니다.
  • ThreadpoolWriteQueue: 쓰기 스레드 풀의 대기열에 있는 작업 수입니다. 이 지표는 높은 CPU 사용량 또는 인덱싱 동시성으로 인해 요청이 거부되는지 여부를 알려줍니다.
  • ThreadpoolWriteRejected: 쓰기 스레드 풀의 거부된 작업 수입니다.
  • ThreadpoolSearchQueue: 검색 스레드 풀의 대기열에 있는 작업 수입니다. 대기열 크기가 일관되게 높으면 클러스터를 확장하는 것이 좋습니다. 최대 검색 대기열 크기는 1,000입니다.
  • ThreadpoolSearchRejected: 검색 스레드 풀의 거부된 작업 수입니다. 이 숫자가 계속 증가하면 클러스터를 확장하는 것이 좋습니다.

참고: 나열된 스레드 풀 지표는 IndexingRateSearchRate에 대한 정보를 제공합니다.

Amazon CloudWatch를 사용하여 Elasticsearch 클러스터를 모니터링하는 방법에 대한 자세한 내용은 인스턴스 지표를 참조하세요.

활성 스레드 및 대기열 스레드

CPU가 부족하거나 요청 동시성이 높으면 대기열이 빨리 채워져 HTTP 429 오류가 발생할 수 있습니다. 대기열 스레드를 모니터링하려면 Amazon CloudWatch에서 ThreadpoolSearchQueueThreadpoolWriteQueue 지표를 확인하세요.

활성 대기열 및 대기열 스레드의 검색 거부를 확인하려면 다음 명령을 사용합니다.

GET /_cat/thread_pool/search?v&h=id,name,active,queue,rejected,completed

활성 대기열 및 대기열 스레드의 쓰기 거부를 확인하려면 "search"를 "write"로 바꿉니다. 출력의 rejectedcompleted 값은 누적 노드 수를 나타내며 새 노드가 시작될 때 재설정됩니다. 자세한 내용은 Elasticsearch 웹 사이트에서 cat thread pool APIExample with explicit columns 섹션을 참조하세요.

참고: 각 노드의 대량 대기열은 사용하는 Elasticsearch 버전에 따라 50~200개의 요청을 보유할 수 있습니다. 대기열이 꽉 찬 경우 추가 요청이 거부됩니다. 자세한 내용은 Elasticsearch 웹 사이트의 Thread pool을 참조하세요.

검색 및 쓰기 거부에 대한 샘플 오류

검색 거부

검색 거부 오류는 활성 스레드가 사용 중이고 대기열이 최대 작업 수까지 채워졌음을 나타냅니다. 그 결과 검색 요청이 거부될 수 있습니다. 이러한 오류 메시지가 느린 검색 로그에 표시되도록 Elasticsearch 로그를 구성할 수 있습니다.

참고: 추가 오버헤드를 방지하려면 느린 로그 임계값을 충분한 양으로 설정합니다. 예를 들어 대부분의 쿼리에 11초가 걸리는데 임계값이 "10"이면 Amazon ES에서 로그를 작성하는 데 추가 시간이 걸립니다. 느린 로그 임계값을 20초로 설정하면 이 오버헤드를 방지할 수 있습니다. 이렇게 하면 11초 넘게 걸리는 느린 쿼리의 일부만 기록됩니다.

느린 검색 로그를 Amazon CloudWatch로 푸시하도록 Elasticsearch 클러스터를 구성한 후 느린 로그 생성을 위한 특정 임계값을 설정합니다. 다음 HTTP POST 호출을 사용하여 느린 로그 생성에 대한 특정 임계값을 설정할 수 있습니다.

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.search.slowlog.threshold.query.<level>":"10s"}'

쓰기 거부

쓰기거부의 429 오류 메시지는 대량 대기열 오류를 나타냅니다. es_rejected_execution_exception[bulk]는 대기열이 가득 찼으므로 새 쿼리가 거부되는 것을 나타냅니다. Elasticsearch 클러스터에 대한 요청 수가 대량 대기열 크기(threadpool.bulk.queue_size)를 초과하는 경우 이 대량 대기열 오류가 발생합니다. 각 노드의 대량 대기열은 사용하는 Elasticsearch 버전에 따라 50~200개의 요청을 보유할 수 있습니다.

이러한 오류 메시지가 느린 인덱스 로그에 표시되도록 Elasticsearch 로그를 구성할 수 있습니다.

참고: 추가 오버헤드를 방지하려면 느린 로그 임계값을 충분한 양으로 설정합니다. 예를 들어 대부분의 쿼리에 11초가 걸리는데 임계값이 "10"이면 Amazon ES에서 로그를 작성하는 데 추가 시간이 걸립니다. 느린 로그 임계값을 20초로 설정하면 이 오버헤드를 방지할 수 있습니다. 이렇게 하면 11초 넘게 걸리는 느린 쿼리의 일부만 기록됩니다.

느린 검색 로그를 Amazon CloudWatch로 푸시하도록 Elasticsearch 클러스터를 구성한 후 느린 로그 생성을 위한 특정 임계값을 설정합니다. 다음 HTTP POST 호출을 사용하여 느린 로그 생성에 대한 특정 임계값을 설정할 수 있습니다.

curl -XPUT http://<your domain’s endpoint>/index/_settings -d '{"index.indexing.slowlog.threshold.query.<level>":"10s"}'

쓰기 거부 모범 사례

다음은 쓰기 거부를 완화하는 몇 가지 모범 사례입니다.

  • 문서가 더 빨리 인덱싱되면 쓰기 대기열이 용량에 도달할 가능성이 적습니다.
  • 워크로드 및 원하는 성능에 따라 대량 크기를 튜닝합니다. 자세한 내용은 Elasticsearch 웹 사이트의 Tune for indexing speed를 참조하세요.
  • 애플리케이션 로직에 지수 재시도 로직을 추가합니다. 지수 재시도 로직을 사용하면 실패한 요청이 자동으로 다시 시도됩니다.
    참고: Elasticsearch 클러스터가 지속적으로 높은 동시 요청을 경험하는 경우 지수 재시도 로직은 429 오류를 해결하는 데 도움이 되지 않습니다. 트래픽이 갑자기 또는 수시로 급증하는 경우 이 모범 사례를 포함하세요.
  • Logstash에서 데이터를 수집하는 경우 작업자 수와 대량 크기를 튜닝합니다. 대량 크기를 3~5MB 사이로 설정하는 것이 가장 좋습니다.

인덱싱 성능 튜닝에 대한 자세한 내용은 Amazon Elasticsearch Service 클러스터에서 인덱싱 성능을 개선하려면 어떻게 해야 합니까?를 참조하세요.

검색 거부 모범 사례

다음은 검색 거부를 완화하는 몇 가지 모범 사례입니다.

  • 더 큰 인스턴스 유형으로 전환합니다. Elasticsearch는 빠른 검색 결과를 위해 파일 시스템 캐시에 크게 의존합니다. 검색 요청에 대한 각 노드의 스레드 풀에 있는 스레드 수는 int((사용 가능한 프로세서 수 * 3) / 2) + 1입니다. 검색 요청을 처리할 스레드를 늘리려면 더 많은 vCPU가 있는 인스턴스로 전환합니다.
  • 지정된 인덱스 또는 적절한 임계값을 가진 모든 인덱스에 대해 느린 로그 검색을 활성화합니다. 실행하는 데 시간이 오래 걸리는 쿼리를 확인하고 쿼리에 대한 검색 성능 전략을 구현합니다. 자세한 내용은 Elasticsearch 웹 사이트의 Troubleshooting Elasticsearch searches, for beginners 또는 Advanced tuning: Finding and fixing slow Elasticsearch queries를 참조하세요.

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


결제 또는 기술 지원이 필요하세요?