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.    NodeStats 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에서 검색 또는 쓰기 거부를 해결하려면 어떻게 해야 합니까?의 단계를 따르세요.

느린 로그 검색을 사용하여 장기 실행 쿼리 식별

느린 로그를 사용하여 장기 실행 쿼리와 쿼리가 특정 샤드에 소요된 시간을 모두 식별합니다. 쿼리 단계에 대한 임계값을 설정한 다음 각 인덱스의 단계를 가져올 수 있습니다. 느린 로그 설정에 대한 자세한 내용은 Amazon OpenSearch Service 느린 로그 보기를 참조하세요. 쿼리 단계에서 쿼리에 소요된 시간을 자세히 분석하려면 검색 쿼리에 대해 "profile":true를 설정해야 합니다.

참고: 로깅에 대한 임계값을 매우 낮은 값으로 설정하면 JVM 메모리 압력이 증가할 수 있습니다. 이로 인해 가비지 수집이 더 자주 발생하여 CPU 사용률을 높이고 클러스터의 대기 시간이 늘어납니다. 더 많은 쿼리를 로깅하면 비용도 증가할 수 있습니다. profile API의 출력은 길어질 수 있으므로 검색 쿼리에 상당한 오버헤드가 추가됩니다.

504 게이트웨이 시간 초과 오류 해결

OpenSearch Service 클러스터의 애플리케이션 로그에서 개별 요청에 대한 특정 HTTP 오류 코드를 확인할 수 있습니다. HTTP 504 게이트웨이 시간 초과 오류를 해결하는 방법에 대한 자세한 내용은 Amazon OpenSearch Service에서 HTTP 504 게이트웨이 제한 시간 오류를 방지하려면 어떻게 해야 합니까?를 참조하세요.

참고: 특정 HTTP 오류 코드를 식별하려면 오류 로그를 활성화해야 합니다. HTTP 오류 코드에 대한 자세한 내용은 Amazon OpenSearch Service 오류 로그 보기를 참조하세요.

검색 대기 시간이 길어질 수 있는 기타 요인

검색 대기 시간이 길어질 수 있는 여러 가지 요인이 있습니다. 다음 팁을 사용하여 검색 지연 시간이 길어지는 문제를 추가로 해결하세요.

  • 자주 또는 장기 실행 가비지 수집 활동으로 인해 검색 성능 문제가 발생할 수 있습니다. 가비지 수집 활동은 스레드를 일시 중지하고 검색 대기 시간을 늘릴 수 있습니다. 자세한 내용은 Elasticsearch 웹 사이트에서 Elasticsearch의 관리형 힙 관리를 참조하세요.
  • 프로비저닝된 IOPS(또는 i3 인스턴스)는 Amazon Elastic Block Store(Amazon EBS) 병목 현상을 제거하는 데 도움이 될 수 있습니다. 대부분의 경우에는 필요하지 않습니다. 모범 사례로서 i3으로 직접 이동하기 전에 i3 노드와 r5 노드 간의 성능을 테스트하는 것이 좋습니다.
  • 샤드가 너무 많은 클러스터는 클러스터가 비활성 상태인 경우에도 리소스 사용률을 증가시킬 수 있습니다. 샤드가 너무 많으면 쿼리 성능이 저하됩니다. 복제본 샤드 수를 늘리면 검색 속도가 빨라질 수 있지만 지정된 노드에서 샤드가 1,000개를 넘지 않도록 해야 합니다. 또한 샤드 크기가 10GiB에서 50GiB 사이인지 확인합니다. 이상적으로 노드의 최대 샤드 수는 힙 * 20이어야 합니다.
  • 세그먼트가 너무 많거나 삭제된 문서가 너무 많으면 검색 성능에 영향을 줄 수 있습니다. 읽기 전용 인덱스에 강제 병합을 사용하면 이 경우 도움이 될 수 있습니다. 사용 사례가 허용하는 경우 활성 인덱스에서 내부 새로 고침을 늘립니다. 자세한 내용은 Elasticsearch 웹사이트에서 Lucene의 삭제된 문서 처리를 참조하세요.
  • 클러스터가 VPC에 있는 경우 동일한 VPC 내에서 애플리케이션을 실행하는 것이 좋습니다.
  • 읽기 전용 데이터에는 UltraWarm 노드 또는 핫 데이터 노드를 사용하는 것이 좋습니다. 핫 스토리지는 새로운 데이터의 인덱싱 및 검색 시에 가장 빠른 성능을 제공합니다. 하지만 UltraWarm 노드는 클러스터에 대량의 읽기 전용 데이터를 저장하는 경제적인 방법입니다. 데이터를 많이 쓰지 않고 동일한 성능을 필요로 하지 않는 인덱스의 경우, UltraWarm을 사용하면 데이터 GiB당 비용을 크게 절감할 수 있습니다.
  • 워크로드를 테스트하여 검색 중인 데이터를 모든 노드에서 사용할 수 있는지 확인합니다. 일부 애플리케이션은 특히 클러스터에 인덱스가 거의 없는 경우 이 접근 방식의 이점을 누릴 수 있습니다. 이렇게 하려면 복제 샤드 수를 늘립니다. 이렇게 하면 인덱싱 대기 시간이 추가될 수 있습니다. 또한 추가 중인 복제본을 수용하기 위해 Amazon EBS 스토리지가 추가로 필요할 수 있습니다. 이러면 EBS 볼륨 비용이 증가합니다.
  • 가능한 한 적은 수의 필드를 검색하고 스크립트 및 와일드카드 쿼리를 피합니다. 자세한 내용은 Elasticsearch 웹 사이트의 검색 속도 조정을 참조하세요.
  • 샤드가 많은 인덱스의 경우 사용자 지정 라우팅을 사용하여 검색 속도를 높일 수 있습니다. 사용자 지정 라우팅을 사용하면 인덱스의 모든 샤드에 요청을 브로드캐스팅하는 대신 데이터를 보유하는 샤드만 쿼리됩니다. 자세한 내용은 Elasticsearch 웹 사이트에서 문서 라우팅 사용자 정의를 참조하세요.

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


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