Amazon OpenSearch Service 클러스터에서 검색 대기 시간 갑자기 늘어났는데, 이 문제를 해결하려면 어떻게 해야 하나요?

6분 분량

Amazon OpenSearch Service 클러스터에서 검색 대기 시간이 갑자기 늘어났습니다.

간략한 설명

검색 요청의 경우 OpenSearch Service는 왕복 시간을 다음과 같이 계산합니다.

왕복 = 쿼리가 쿼리 단계에서 소비한 시간 + 가져오기 단계에서 보낸 시간 + 대기열에서 보낸 시간 + 네트워크 대기 시간

Amazon CloudWatch의 SearchLatency 지표는 쿼리가 쿼리 단계에서 소비한 시간을 알려 줍니다.

OpenSearch Service 클러스터의 검색 대기 시간 급증 문제를 해결하려면 다음과 같은 여러 단계를 수행해야 합니다.

클러스터에 프로비저닝된 리소스가 부족한지 확인
CloudWatch의 ThreadpoolSearchRejected 지표를 사용하여 검색 거부를 확인
검색 느린 로그 API 및 프로파일 API 사용
504 게이트웨이 시간 초과 오류 해결

해결 방법

클러스터에 프로비저닝된 리소스가 부족한지 확인

클러스터에 프로비저닝된 리소스가 충분하지 않으면 검색 대기 시간이 급증할 수 있습니다. 다음 모범 사례를 사용하여 프로비저닝된 리소스가 충분하도록 만드세요.

1. CloudWatch를 사용하여 CPUUtilization 지표 및 클러스터의 JVMMemory 사용량을 검토하세요. 권장 임계값 이내인지 확인하세요. 자세한 내용은 Amazon OpenSearch Service를 위한 권장 CloudWatch 경보를 참조하세요.

2. 노드 통계 API를 사용하여 클러스터의 노드 수준 통계를 가져오십시오.

GET /_nodes/stats

출력에서 caches, fielddata 및 jvm 섹션을 확인합니다. 출력을 비교하려면 각 출력 간에 약간의 지연을 두고 이 API를 여러 번 실행합니다.

3. OpenSearch Service는 다음과 같이 여러 캐시를 사용하여 성능과 요청 응답 시간을 개선합니다.

운영 체제 수준에 존재하는 파일 시스템 캐시 또는 페이지 캐시
모두 OpenSearch Service 수준에 존재하는 샤드 수준 요청 캐시 및 쿼리 캐시

캐시 제거에 대한 노드 통계 API 출력을 검토하십시오. 출력의 캐시 제거 수가 많다는 것은 캐시 크기가 해당 요청을 처리하기에 부적절하다는 것을 의미합니다. 제거를 줄이려면 메모리가 더 많은 메모리의 더 큰 노드를 사용하세요.

노드 통계 API로 특정 캐시 정보를 보려면 다음 요청을 사용하세요. 두 번째 요청은 샤드 수준 요청 캐시에 대한 것입니다.

GET /_nodes/stats/indices/request_cache?human

GET /_nodes/stats/indices/query_cache?human

OpenSearch 캐시에 대한 자세한 내용은 다음과 같이 Elasticsearch 캐싱 심층 분석을 참조하세요. Elastic 웹 사이트에서 한 번에 한 캐시씩 쿼리 속도를 높입니다.

다양한 캐시를 지우는 단계는 OpenSearch 웹 사이트에서 인덱스 또는 데이터 스트림 캐시 지우기를 참조하세요.

4. 매우 고유한 값이 포함된 필드에서 집계를 수행하면 힙 사용량이 증가할 수 있습니다. 집계 쿼리를 이미 사용 중인 경우 검색 작업에서는 필드 데이터를 사용합니다. 필드 데이터는 또한 스크립트의 필드 값을 정렬하고 이에 액세스합니다. 필드 데이터 제거는 indices.fielddata.cache.size 파일의 크기에 따라 달라지며 이는 JVM 힙 공간의 20%를 차지합니다. 캐시가 초과되면 제거가 시작됩니다.

필드 데이터 캐시를 보려면 다음 요청을 사용하세요.

GET /_nodes/stats/indices/fielddata?human

높은 JVM 메모리 문제를 해결하려면 Amazon OpenSearch Service 클러스터의 높은 JVM 메모리 사용량 문제를 해결하려면 어떻게 해야 하나요? 를 참조하세요. 높은 CPU 사용률 문제를 해결하려면 Amazon OpenSearch Service 클러스터의 높은 CPU 사용률 문제를 해결하려면 어떻게 해야 하나요?를 참조하세요.

CloudWatch의 ThreadpoolSearchRejected 지표를 사용하여 검색 거부를 확인

CloudWatch를 사용하여 검색 거부를 확인하려면 Amazon OpenSearch Service에서 검색 또는 쓰기 거부를 해결하려면 어떻게 해야 하나요?의 단계를 따르세요.

검색 느린 로그를 사용하여 오래 실행되는 쿼리를 식별

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

참고: 로깅 임계값을 너무 낮은 값으로 설정하면 JVM 메모리 사용량이 증가할 수 있습니다. 이로 인해 가비지 수집이 더 자주 발생하여 CPU 사용률이 증가하고 클러스터 대기 시간이 늘어날 수 있습니다. 더 많은 쿼리를 로깅하면 비용도 증가할 수 있습니다. 프로파일 API의 긴 출력 역시 모든 검색 쿼리에 상당한 오버헤드를 더합니다.

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

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

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

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

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

빈번한 또는 오래 실행되는 가비지 수집 활동으로 검색 성능 문제가 발생할 수 있습니다. 가비지 수집 활동은 스레드를 일시 중지하고 검색 대기 시간을 늘릴 수 있습니다. 자세한 내용은 Elastic 웹 사이트에서 문제 더미: Amazon OpenSearch Service의 관리형 힙 관리를 참조하세요.
프로비저닝된 IOPS(또는 i3 인스턴스)는 Amazon Elastic Block Store(Amazon EBS) 병목 현상을 제거하는 데 도움이 될 수 있습니다. 대부분의 경우에는 필요하지 않습니다. 인스턴스를 i3로 이동하기 전에 i3 노드와 r5 노드 간의 성능을 테스트하는 것이 가장 좋습니다.
샤드가 너무 많은 클러스터는 클러스터가 비활성 상태인 경우에도 리소스 사용률을 높일 수 있습니다. 샤드가 너무 많으면 쿼리 성능이 느려집니다. 복제본 샤드 수를 늘리면 검색 속도를 높이는 데 도움이 될 수 있지만 특정 노드에서 샤드 수가 1000개를 초과해서는 안 됩니다. 또한 샤드 크기가 10GiB에서 50GiB 사이인지 확인하세요. 이상적인 노드의 최대 샤드 수는 힙 * 20입니다.
세그먼트가 너무 많거나 삭제된 문서가 너무 많으면 검색 성능에 영향을 미칠 수 있습니다. 성능을 개선하려면 읽기 전용 인덱스에 강제 병합을 사용하세요. 또한 가능하면 활성 인덱스의 내부 새로 고침을 늘립니다. 자세한 내용은 Elastic 웹 사이트에서 Lucene의 삭제된 문서 처리를 참조하세요.
클러스터가 Virtual Private Cloud(VPC)에 있는 경우 동일한 VPC 내에서 애플리케이션을 실행하는 것이 가장 좋습니다.
읽기 전용 데이터에는 UltraWarm 노드 또는 핫 데이터 노드를 사용합니다. 핫 스토리지는 새 데이터를 인덱싱하고 검색할 때 가능한 가장 빠른 성능을 제공합니다. 하지만 UltraWarm 노드가 클러스터에서 대량의 읽기 전용 데이터를 저장하는 비용 효율적인 방법입니다. 쓸 필요가 없고 고성능이 필요하지 않은 인덱스의 경우 UltraWarm은 데이터 GiB당 비용을 크게 낮춥니다.
검색하려는 데이터를 모든 노드에서 사용할 수 있게 되면 워크로드에 이점이 있는지 확인하세요. 일부 애플리케이션에서, 특히 클러스터에 인덱스가 적은 경우 이 접근 방식의 이점을 누릴 수 있습니다. 이렇게 하려면 복제본 샤드의 수를 늘리세요.
참고: 이로 인해 인덱싱 대기 시간이 늘어날 수 있습니다. 또한 추가한 복제본을 수용하기 위해 추가 Amazon EBS 스토리지가 필요할 수 있습니다. 이로 인해 EBS 볼륨 비용이 증가합니다.
가능한 한 적은 수의 필드를 검색하고 스크립트와 와일드카드 쿼리를 피하세요. 자세한 내용은 Elastic 웹 사이트에서 검색 속도를 위한 튜닝을 참조하세요.
샤드가 많은 인덱스의 경우 사용자 지정 라우팅을 사용하면 검색 속도를 높일 수 있습니다. 사용자 지정 라우팅을 사용하면 요청을 모든 샤드에 브로드캐스트하는 대신, 데이터를 보유한 샤드만 쿼리할 수 있습니다. 자세한 내용은 Elastic 웹 사이트에서 문서 라우팅 사용자 지정을 참조하세요.