OpenSearch Service 클러스터에서 검색 대기 시간 급증 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

검색 요청의 경우 OpenSearch Service는 다음 공식을 사용하여 왕복 시간을 계산합니다.

왕복 = 쿼리가 쿼리 단계에서 소요한 시간 + 가져오기 단계의 시간 + 대기열에 있는 시간 + 네트워크 지연 시간

SearchLatency Amazon CloudWatch 지표는 쿼리가 쿼리 단계에서 소요한 시간을 제공합니다.

OpenSearch Service 클러스터의 검색 지연 시간 급증 문제를 해결하려면 다음 작업을 수행하십시오.

• Java 가상 머신(JVM) 메모리 압력 및 폐영역 회수에 대한 CPU 사용량, 디스크 사용량 및 메모리와 같은 인프라 지표를 확인합니다.
• SearchRate CloudWatch 지표에서 스파이크가 있는지 확인합니다.
• ThreadpoolSearchRejected CloudWatch 지표를 사용하여 검색 거부를 확인합니다.
• 느린 로그를 사용하여 오래 실행되는 쿼리를 식별합니다.
• ‘504 gateway timeout’ 오류를 해결합니다.
• 구성을 최적화하여 지연 시간을 줄입니다.

해결 방법

인프라 지표 확인

리소스 사용량이 높을 때 운영 체제(OS) 데이터 노드에서 폐영역 회수가 자주 발생하고 시간이 오래 걸립니다. 클러스터에 충분한 리소스를 프로비저닝하지 않으면 검색 지연 시간이 급증할 수 있습니다.

높은 리소스 사용량 문제 해결

클러스터의 CPUUtilization 및 JVMMemoryPressure CloudWatch 지표가 80% 미만인지 확인하십시오. 지표 값이 80%보다 크면 높은 CPU 사용량 또는 높은 JVM 메모리 압력 문제를 해결하십시오.

리소스 사용량을 사전에 모니터링하려면 OpenSearch Service의 CloudWatch 경보를 설정하십시오.

클러스터에 대한 노드 수준 통계를 가져오려면 다음 쿼리를 5분마다 여러 번 실행합니다.

GET /_nodes/stats

출력에서 실행 사이에 캐시 사용량, 필드 데이터 메모리 및 JVM 힙 값의 중요한 변화를 찾아보십시오. 값이 일정하면 정상적인 작동을 나타냅니다. 문제가 있으면 갑작스러운 급증 또는 하락이 발생할 수 있습니다.

캐시 설정 확인

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

• OS 수준에 존재하는 파일 시스템 캐시 또는 페이지 캐시
• 모두 OpenSearch Service 수준에 존재하는 샤드 수준 요청 캐시와 쿼리 캐시

파일 시스템 캐시 정보를 보려면 다음 쿼리를 실행합니다.

GET /_nodes/stats/indices/request_cache?human

샤드 수준 요청 캐시 정보를 보려면 다음 쿼리를 실행합니다.

GET /_nodes/stats/indices/query_cache?human

출력에서 캐시 제거를 확인합니다. 캐시 제거 횟수가 많으면 캐시가 너무 작아서 요청을 처리할 수 없습니다. 제거를 줄이려면 더 많은 메모리가 있는 더 큰 노드를 사용하십시오. 노드 크기 요금에 대한 자세한 내용은 OpenSearch Service 요금을 참조하십시오. OpenSearch 캐시에 대한 자세한 내용은 Elastic 웹 사이트에서 Elasticsearch 캐싱 심층 분석: 한 번에 캐시 하나씩 쿼리 속도 향상을 참조하십시오.

캐시를 지우려면 OpenSearch 웹 사이트의 캐시 지우기 API를 참조하십시오.

매우 고유한 값을 포함하는 필드에 대한 집계는 힙 사용량을 높일 수 있습니다. 집계 쿼리에 대한 검색 작업은 필드 데이터를 사용합니다. 또한 필드 데이터는 스크립트의 필드 값을 정렬하고 액세스합니다. 필드 데이터 제거는 JVM 힙의 20%를 차지하는 indices.fielddata.cache.size 파일 크기에 따라 달라집니다.

클러스터의 모든 노드에서 필드 데이터가 사용하는 메모리 양을 확인하려면 다음 쿼리를 실행합니다.

GET /_nodes/stats/indices/fielddata?human

SearchRate 지표에서 스파이크가 있는지 확인

단기간에 검색 요청이 여러 번 발생하면 클러스터 리소스에 부담을 주어 쿼리 처리가 지연되고 개별 검색의 응답 시간이 느려질 수 있습니다. OpenSearch Service의 검색 속도가 높으면 검색 지연 시간이 길어질 수 있습니다. SearchRate 지표가 급증하는 경우 검색 지연 시간 급증과 동시에 스파이크가 발생하는지 확인하십시오. 동시에 스파이크가 발생하면 클러스터에 리소스를 더 추가하거나 쿼리를 최적화하여 검색 로드를 관리해야 합니다.

검색 거부 확인

ThreadpoolSearchRejected 지표를 사용하여 검색 거부를 식별하고 해결할 수 있습니다.

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

오래 실행되는 쿼리와 특정 샤드에서 쿼리가 소요된 시간을 파악하려면 느린 로그를 사용하십시오. 쿼리 단계에 대한 임계값을 설정한 다음, 각 인덱스의 단계를 가져올 수 있습니다.

쿼리 단계에서 쿼리가 소요된 시간을 자세히 요약하려면 검색 쿼리에서 profile을 true로 설정하십시오.

쿼리 예시:

GET /my_index/_search
{
  "profile": true,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

참고: 로깅 임계값을 너무 낮게 설정하면 JVM 메모리 압력 및 클러스터 지연 시간이 증가할 수 있습니다. 더 많은 쿼리를 기록하면 비용도 증가합니다. profile을 true로 설정한 쿼리의 출력이 크면 다른 검색 쿼리에 오버헤드가 추가됩니다. 따라서 다른 검색 속도가 일시적으로 느려집니다.

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

사전 요구 사항: 오류 로그를 활성화하여 특정 HTTP 오류 코드를 식별합니다.

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

구성 최적화

폐영역 회수 활동 관리

폐영역 회수 활동을 자주 또는 오래 실행하면 검색 성능 문제가 발생하고 스레드가 일시 중지되며, 검색 지연 시간이 길어질 수 있습니다. 폐영역 회수 시간을 줄이는 모범 사례는 Elastic 웹 사이트에서 많은 문제: Elasticsearch의 관리형 힙 관리를 참조하십시오.

인스턴스 스토리지 최적화

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 유형은 Amazon Elastic Block Store(Amazon EBS) 최적화 스토리지 또는 인스턴스 저장소 볼륨을 사용할 수 있습니다. 인스턴스 저장소 볼륨은 직접 연결된 스토리지와 더 높은 IOPS 기능을 제공하므로 I/O 병목 현상을 해결하는 데 도움이 될 수 있습니다. 그러나 Amazon EBS 최적화 인스턴스는 일관된 성능의 영구 스토리지를 제공합니다. I/O, 데이터 지속성 및 비용을 기반으로 구성 요구 사항에 맞는 스토리지 유형을 선택합니다.

인스턴스 유형을 변경하기 전에 여러 인스턴스 유형 간의 성능을 테스트하여 워크로드 요구 사항을 충족하는지 확인하는 것이 좋습니다. 사용 가능한 OpenSearch Service 인스턴스 유형 목록은 OpenSearch Service 요금의 프리 티어 및 온디맨드 인스턴스 요금을 참조하십시오.

참고: 클러스터가 가상 프라이빗 클라우드(VPC)에 있는 경우 동일한 VPC 내에서 애플리케이션을 실행하는 것이 좋습니다.

샤드 및 세그먼트 구성 간소화

샤드가 너무 많은 클러스터는 클러스터가 비활성 상태인 경우에도 리소스 사용량을 높일 수 있습니다. 샤드가 너무 많으면 쿼리 성능도 느려집니다. 복제본 샤드 수가 많을수록 검색 속도가 빨라지지만 단일 노드에서 1,000개 이상의 샤드를 사용하지 마십시오. 또한 샤드 크기가 10GiB에서 50GiB 사이인지 확인하십시오. 노드의 최대 샤드 수를 힙 크기의 20배로 설정하는 것이 좋습니다. 샤드 전략을 재인덱싱하고 변경하는 방법에 대한 자세한 내용은 OpenSearch 웹 사이트에서 OpenSearch 인덱스 샤드 크기 최적화를 참조하십시오.

세그먼트가 너무 많거나 삭제된 문서가 너무 많으면 검색 성능에 영향을 미칠 수도 있습니다. 성능을 향상하려면 읽기 전용 인덱스에서는 강제 병합을 사용하고 활성 인덱스에서는 새로 고침 간격을 늘리십시오. 자세한 내용은 OpenSearch 웹 사이트에서 강제 병합 API 및 OpenSearch 새로 고침 간격 최적화를 참조하십시오.

모든 노드에 복제본 샤드를 추가하기 전에 애플리케이션의 요구 사항을 평가하십시오. 애플리케이션이 모든 노드의 데이터를 모두 검색해야 하는 경우 복제본 샤드 수를 늘려 데이터 가용성을 높이십시오. 그렇지 않으면 모든 노드에 복제본 샤드가 필요하지 않을 수 있습니다.

참고: 복제본 샤드를 통해 클러스터가 병렬 처리를 사용하고 데이터의 여러 복사본에 검색 요청을 분산할 수 있습니다. 그에 따라 검색 성능이 향상됩니다. 그러나 인덱싱 작업은 느려지고 전체 데이터 복사본마다 추가 스토리지가 필요합니다.

샤드가 많은 인덱스의 경우 사용자 지정 라우팅을 사용하면 검색 성능을 향상할 수 있습니다. 사용자 지정 라우팅을 통해 모든 샤드 대신 데이터를 보유한 샤드만 쿼리합니다. 사용자 지정 라우팅을 구성하려면 Elastic 웹 사이트에서 문서 라우팅 사용자 지정을 참조하십시오.

읽기 전용 데이터에 Ultrawarm 스토리지 사용

핫 스토리지는 새 데이터를 인덱싱하고 검색할 수 있는 가장 빠른 성능을 제공합니다. 그러나 UltraWarm 노드는 클러스터에서 대량의 읽기 전용 데이터를 저장하는 비용 효율적인 방법을 제공합니다. 고성능이 필요하지 않은 읽기 전용 인덱스의 경우 핫 데이터 스토리지 대신 UltraWarm을 사용하십시오.

검색 속도 높이기

가능한 한 적은 필드를 검색하고 스크립트와 와일드카드 쿼리는 사용하지 마십시오. 자세한 내용은 Elastic 웹 사이트에서 검색 속도 조정을 참조하십시오.