OpenSearch Service 클러스터의 검색 대기 시간 급증 문제를 해결

OpenSearch Service 클러스터의 검색 대기 시간 급증 문제를 해결 방법

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

• 검색 요청 시, OpenSearch Service는 왕복 시간
• 왕복 = 쿼리가 쿼리 단계에서 소비한 시간 + 가져오기 단계에서 보낸 시간 + 대기열에서 보낸 시간 + 네트워크 대기 시간
• 쿼리 단계에서의 소비시간 : Amazon CloudWatch 의 SearchLatency 지표에서 확인

---

1. 클러스터에 프로비저닝된 리소스가 부족한지 확인
   • 클러스터에 프로비저닝된 리소스가 충분하지 않으면 검색 대기 시간이 급증 가능성 있음
   • CloudWatch를 사용하여 CPUUtilization 지표 및 클러스터의 JVMMemory 사용량 검토 (권장 임계값 이내인지 확인)
   • 노드 통계 API를 사용하여 클러스터의 노드 수준 통계(GET /_nodes/stats)에서 caches, fielddata 및 jvm 섹션을 확인
   • 캐시 제거에 대한 노드 통계 API 출력을 검토해 볼 필요가 있음. 출력의 캐시 제거 수가 많다는 것은 캐시 크기가 해당 요청을 처리하기에 부적절하다는 것을 의미함. 제거를 줄이려면 메모리가 더 많은 메모리의 더 큰 노드를 사용해야 함 ( GET /_nodes/stats/indices/request_cache?human, GET /_nodes/stats/indices/query_cache?human )
   • 매우 고유한 값이 포함된 필드에서 집계를 수행하면 힙 사용량이 증가할 수 있음. 집계 쿼리를 이미 사용 중인 경우 검색 작업에서는 필드 데이터를 사용함. 필드 데이터는 또한 스크립트의 필드 값을 정렬하고 이에 액세스하는데 필드 데이터 제거는 indices.fielddata.cache.size 파일의 크기에 따라 달라지며 이는 JVM 힙 공간의 20%를 차지함. 캐시가 초과되면 제거가 시작됨. (필드데이터 캐시를 보려면 다음과 같이 요청 : GET /_nodes/stats/indices/fielddata?human)
2. CloudWatch의 ThreadpoolSearchRejected 지표를 사용하여 검색 거부를 확인
   • CloudWatch를 사용하여 검색 거부를 확인
     • PrimaryWriteRejected: 기본 샤드에서 발생한 총 거부 횟수
     • ThreadpoolWriteRejected: 쓰기 스레드 풀에 대기 중인 작업의 수
     • ThreadpoolSearchRejected: 검색 스레드 풀에서 거부된 작업의 수
     • JVMMemoryPressure: JVM 메모리 압력은 클러스터 노드에서 Java 힙의 비율을 지정함. JVM 메모리 압력이 75%에 도달하면 OpenSearch Service는 동시 마크 스윕(CMS) 가비지 수집기를 시작함. 가비지 수집은 CPU를 많이 사용하는 프로세스인데 JVM 메모리 압력이 몇 분 동안 이 비율로 유지되면 클러스터 성능 문제가 발생할 수 있음
     • 활성 및 대기열 스레드에서 검색 거부가 있는지 확인하는 요청명령은 GET /_cat/thread_pool/search?v&h=id,name,active,queue,rejected,completed
3. 검색 느린 로그를 사용하여 오래 실행되는 쿼리를 식별
   • 오래 실행되는 쿼리와 쿼리가 특정 샤드에 소비한 시간을 모두 식별하려면 느린 로그를 사용. 쿼리 단계에서 쿼리에 소요된 시간을 자세히 분석하려면 검색 쿼리에 "profile":true로 설정
   • 참고: 로깅 임계값을 너무 낮은 값으로 설정하면 JVM 메모리 사용량이 증가할 수 있음. 이로 인해 가비지 수집이 더 자주 발생하여 CPU 사용률이 증가하고 클러스터 대기 시간이 늘어날 수 있음. 더 많은 쿼리를 로깅하면 비용도 증가할 수 있음. 프로파일 API의 긴 출력 역시 모든 검색 쿼리에 상당한 오버헤드를 더함.

4. 504 게이트웨이 시간 초과 오류 해결
   • OpenSearch Service 클러스터의 애플리케이션 로그에서 개별 요청에 대한 특정 HTTP 오류 코드를 볼 수 있음
   • 참고: 특정 HTTP 오류 코드를 식별하려면 오류 로그를 활성화해야 함
5. 검색 대기시간이 길어지는 기타 요인
   • 빈번한 또는 오래 실행되는 가비지 수집 활동으로 검색 성능 문제가 발생할 수 있음. 가비지 수집 활동은 스레드를 일시 중지하고 검색 대기 시간을 늘릴 수 있음
   • 프로비저닝된 IOPS(또는 i3 인스턴스)는 Amazon Elastic Block Store(Amazon EBS) 병목 현상을 제거하는 데 도움이 될 수 있음
   • 샤드가 너무 많은 클러스터는 클러스터가 비활성 상태인 경우에도 리소스 사용률을 높일 수 있음. 샤드가 너무 많으면 쿼리 성능이 느려짐. 복제본 샤드 수를 늘리면 검색 속도를 높이는 데 도움이 될 수 있지만 특정 노드에서 샤드 수가 1000개를 초과해서는 안 됨. 또한 샤드 크기가 10GiB에서 50GiB 사이인지 확인하기. 이상적인 노드의 최대 샤드 수는 힙 * 20 임
   • 세그먼트가 너무 많거나 삭제된 문서가 너무 많으면 검색 성능에 영향을 미칠 수 있음. 성능을 개선하려면 읽기 전용 인덱스에 강제 병합을 사용. 또한 가능하면 활성 인덱스의 내부 새로 고침을 늘림
   • 클러스터가 Virtual Private Cloud(VPC)에 있는 경우 동일한 VPC 내에서 애플리케이션을 실행하는 것이 가장 좋음
   • 검색하려는 데이터를 모든 노드에서 사용할 수 있게 되면 워크로드에 이점이 있는지 확인해야 함. 일부 애플리케이션에서, 특히 클러스터에 인덱스가 적은 경우 이 접근 방식의 이점을 누릴 수 있음. 이렇게 하려면 복제본 샤드의 수를 늘려야 함.
     • 참고: 이로 인해 인덱싱 대기 시간이 늘어날 수 있음. 또한 추가한 복제본을 수용하기 위해 추가 Amazon EBS 스토리지가 필요할 수 있음. 이로 인해 EBS 볼륨 비용은 증가하게 됨.
   • 가능한 한 적은 수의 필드를 검색하고 스크립트와 와일드카드 쿼리를 피하기. 자세한 내용은 Elastic 웹 사이트에서 검색 속도를 위한 튜닝을 참조하기.
   • 샤드가 많은 인덱스의 경우 사용자 지정 라우팅을 사용하면 검색 속도를 높일 수 있음. 사용자 지정 라우팅을 사용하면 요청을 모든 샤드에 브로드캐스트하는 대신, 데이터를 보유한 샤드만 쿼리할 수 있음. 자세한 내용은 Elastic 웹 사이트에서 문서 라우팅 사용자 지정을 참조하기.