OpenSearch Service 클러스터의 높은 CPU 사용률 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

클러스터의 높은 CPU 사용률 문제를 해결하려면 다음 작업을 수행하십시오.

• 자동화된 런북을 사용하여 높은 CPU 사용량의 원인을 식별합니다.
• 이상 탐지를 사용하여 패턴을 식별합니다.
• 노드 핫 스레드 API를 사용하여 리소스 사용량을 파악합니다.
• 쓰기 작업 또는 대량 API 스레드 풀을 확인합니다.
• 검색 스레드 풀을 확인합니다.
• Apache Lucene 병합 스레드 풀을 확인합니다.
• Java 가상 머신(JVM) 메모리 압력을 확인합니다.
• 샤드 전략을 검토합니다.
• 클러스터의 규모를 조정합니다.
• 쿼리를 최적화합니다.

OpenSearch Service가 작업을 수행할 수 있을 만큼 CPU 사용량을 낮게 유지하는 것이 가장 좋습니다. 지속적으로 CPU 사용량이 높은 클러스터에서는 성능 문제가 발생할 수 있습니다. OpenSearch Service는 오버로드된 클러스터에 응답하지 않으므로 시간 제한 요청을 받습니다.

해결 방법

자동화된 런북 사용

전제 조건: 런북을 실행하는 데 필요한 AWS Identity and Access Management(IAM) 권한이 있는지 확인하십시오. 자세한 내용은 AWSSupport-TroubleshootOpenSearchHighCPU의 필수 IAM 권한을 참조하십시오.

AWSSupport-TroubleshootOpenSearchHighCPU AWS Systems Manager 자동화 런북을 실행하여 OpenSearch Service의 높은 CPU 사용량 문제를 해결하십시오.

출력에는 다음 정보가 표시됩니다.

• 핫 스레드
• 실행 중인 작업
• 도메인의 각 노드에 대한 스레드 풀 통계
• CPU 사용량을 기준으로 정렬된 도메인의 노드에 대한 정보
• 각 데이터 노드 및 해당 디스크 공간에 대한 샤드 할당
• OpenSearch 서비스 도메인의 상태 및 상태 관련 정보

런북 출력을 사용하여 높은 CPU 사용량의 원인을 식별할 수 있습니다.

이상 탐지를 사용하여 패턴 식별

운영 중단이 발생하기 전에 잠재적 문제를 식별하려면 OpenSearch Service의 이상 탐지를 사용하여 CPU 사용량과 같은 지표의 비정상적 패턴을 자동으로 감지합니다. 자세한 내용은 자습서: 이상 탐지로 높은 CPU 사용량 감지를 참조하십시오.

노드 핫 스레드 API 사용

OpenSearch Service 클러스터에서 CPU 스파이크가 계속 발행하는 경우 다음 명령을 실행하여 클러스터의 모든 노드에 대한 정보를 확인합니다.

GET/_nodes/hot_threads

출력 길이는 OpenSearch Service 클러스터에서 실행 중인 노드 수에 따라 달라집니다. 노드 핫 스레드 API에 대한 자세한 내용은 OpenSearch 웹 사이트의 노드 핫 스레드 API를 참조하십시오.

출력 예시:

GET _nodes/hot_threads
100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[abc][search][T#62]'
10/10 snapshots sharing following 10
elements sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.LinkedTransferQueue.awaitMatch(LinkedTransferQueue.java:737)

java.util.concurrent.LinkedTransferQueue.xfer(LinkedTransferQueue.java:647)

java.util.concurrent.LinkedTransferQueue.take(LinkedTransferQueue.java:1269)

org.opensearch.common.util.concurrent.SizeBlockingQueue.take(SizeBlockingQueue.java:162)

java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
java.lang.Thread.run(Thread.java:745)

또한 캣 노드 API를 사용하여 리소스 사용량의 현재 분석을 볼 수 있습니다. CPU 사용량이 가장 높은 노드를 보려면 다음 명령을 실행합니다.

GET _cat/nodes?v&s=cpu:desc

출력의 마지막 열에는 노드 이름이 표시됩니다. 캣 노드 API에 대한 자세한 내용은 OpenSearch 웹 사이트의 CAT 노드 API를 참조하십시오.

그런 다음, CPU 사용량이 많은 노드에 대해 다음 명령을 실행합니다.

GET _nodes/node_id/hot_threads

참고: node_id를 노드 ID로 바꾸십시오.

출력은 CPU를 가장 많이 사용하는 노드의 OpenSearch Service 프로세스를 보여줍니다. 출력에 Apache Lucene 병합 스레드가 표시되는 경우 문제 해결을 위한 Apache Lucene 병합 스레드 풀 확인을 참조하십시오.

출력 예시:

percentage of cpu usage by thread 'opensearch[nodeName][thread-name]'

쓰기 작업 또는 대량 API 스레드 풀 확인

‘429’ 오류 메시지가 표시되면 클러스터에 대량 인덱스 요청이 너무 많을 수 있습니다. 클러스터에서 CPU 스파이크가 계속 발생하면 OpenSearch Service는 대량 인덱스 요청을 거부합니다.

쓰기 스레드 풀은 인덱스 요청을 관리하고 대량 API 작업을 포함합니다. 대량 인덱스 요청이 너무 많아 도메인에 부하가 걸리고 있는지 확인하려면 IndexingRate Amazon CloudWatch 지표를 확인하십시오.

클러스터에 대량 인덱스 요청이 너무 많으면 다음 작업을 수행하십시오.

• 클러스터의 대량 요청 수를 줄입니다.
• 노드에서 더 효율적으로 처리할 수 있도록 각 대량 요청의 크기를 줄입니다.
• Logstash를 사용하여 데이터를 OpenSearch Service 클러스터로 업로드하는 경우 배치 크기 또는 워커 수를 줄입니다.
• 클러스터의 수집 속도가 느려지면 클러스터의 규모를 수평 또는 수직으로 조정합니다.

검색 스레드 풀 확인

높은 CPU를 사용하는 검색 스레드 풀은 검색 쿼리가 OpenSearch Service 클러스터를 압도한다는 것을 나타냅니다. 단일 장기 실행 쿼리는 클러스터를 압도할 수 있습니다. 클러스터에서 수행하는 쿼리가 증가하면 검색 스레드 풀에도 영향을 미칠 수 있습니다.

단일 쿼리로 인해 CPU 사용량이 증가하는지 확인하려면 다음 명령을 실행합니다.

GET _tasks?actions=*search&detailed

작업 관리 API는 클러스터에서 실행되는 모든 활성 검색 쿼리를 표시합니다. 자세한 내용은 OpenSearch 웹사이트의 작업 목록 API를 참조하십시오.

출력에서 설명 필드를 확인하여 실행 중인 쿼리를 식별합니다. running_time_in_nanos 필드는 쿼리가 실행되는 시간을 나타냅니다.

출력 예시:

{    "nodes": {
        "U4M_p_x2Rg6YqLujeInPOw": {
            "name": "U4M_p_x",
            "roles": [
                "data",
                "ingest"
            ],
            "tasks": {
                "U4M_p_x2Rg6YqLujeInPOw:53506997": {
                    "node": "U4M_p_x2Rg6YqLujeInPOw",
                    "id": 53506997,
                    "type": "transport",
                    "action": "indices:data/read/search",
                    "description": """indices[*], types[], search_type[QUERY_THEN_FETCH], source[{"size":10000,"query":{"match_all":{"boost":1.0}}}]""",
                    "start_time_in_millis": 1541423217801,
                    "running_time_in_nanos": 1549433628,
                    "cancellable": true,
                    "headers": {}
                }
            }
        }
    }
}

참고: 검색 작업의 경우 작업 관리 API 출력에는 설명 필드만 포함됩니다.

CPU 사용량을 줄이려면 다음 명령을 실행하여 CPU가 높은 검색 쿼리를 취소하십시오.

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

참고: U4M_p_x2Rg6YqLujeInPOw:53506997을 작업 ID로 바꾸십시오.

위 쿼리는 작업을 최소됨으로 표시한 다음, 종속 AWS 리소스를 릴리스합니다. 클러스터에서 쿼리가 여러 개 실행되는 경우 클러스터가 정상 상태로 돌아올 때까지 POST 명령을 사용하여 각 쿼리를 취소합니다.

CPU 스파이크를 방지하려면 쿼리 본문에 제한 시간 값을 설정하는 것이 좋습니다. 자세한 내용은 OpenSearch 웹 사이트의 검색 설정을 참조하십시오. 활성 쿼리 수가 감소했는지 확인하려면 SearchRate CloudWatch 지표를 확인하십시오.

참고: OpenSearch Service 클러스터에서 모든 활성 검색 쿼리를 동시에 취소하면 클라이언트 애플리케이션 측에서 오류가 발생할 수 있습니다.

Apache Lucene 병합 스레드 풀 확인

OpenSearch Service는 Apache Lucene을 사용하여 클러스터의 문서를 인덱싱하고 검색합니다. 새 샤드 세그먼트를 만들 때 Apache Lucene은 병합 작업을 실행하여 각 샤드의 유효 세그먼트 수를 줄이고 삭제된 문서를 제거합니다. 자세한 내용은 Elastic 웹사이트의 병합 설정을 참조하십시오.

Apache Lucene 병합 스레드가 CPU 사용량에 영향을 미치는 경우 다음 명령을 실행하여 인덱스의 refresh_interval 설정을 늘리십시오.

PUT /your-index-name/_settings
{
  "index": {
    "refresh_interval": "value"
  }
}

참고: value를 새 요청 간격으로 바꾸십시오. 이 업데이트는 클러스터 세그먼트 만들기 속도를 늦춥니다. 자세한 내용은 OpenSearch 웹 사이트에서 인덱스 새로 고침 API를 참조하십시오.

클러스터가 UltraWarm 스토리지로 인덱스를 마이그레이션하면 CPU 사용량이 증가할 수 있습니다. UltraWarm 마이그레이션은 일반적으로 CPU 사용량이 많은 강제 병합 API 작업을 사용합니다. 자세한 내용은 OpenSearch 웹사이트의 강제 병합 API를 참조하십시오.

UltraWarm 마이그레이션을 확인하려면 다음 명령을 실행합니다.

GET _ultrawarm/migration/_status?v

JVM 메모리 압력 확인

클러스터 노드에 있는 Java 힙의 JVM 메모리 압력 비율을 확인하십시오. 다음 예제 로그에서 JVM은 권장 범위 내에 있지만 장기 실행 폐영역 회수가 클러스터에 영향을 미칩니다.

[2022-06-28T10:08:12,066][WARN ][o.o.m.j.JvmGcMonitorService] [515f8f06f23327e6df3aad7b2863bb1f] [gc][6447732] overhead, spent [9.3s]collecting in the last [10.2s]

높은 JVM 메모리 압력 문제를 해결하려면 OpenSearch Service 클러스터의 높은 JVM 메모리 압력 문제를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

샤드 전략 검토

클러스터 크기에 따라 샤드가 너무 많아서 클러스터 성능이 저하될 수 있습니다. Java 힙의 GiB마다 샤드를 최대 25개까지 보유하는 것이 가장 좋습니다.

기본적으로 OpenSearch Service의 샤드 전략은 5:1이며, 각 인덱스에는 5개의 기본 샤드가 있습니다. 각 인덱스 내에서 모든 기본 샤드에는 자체 복제본이 있습니다. OpenSearch Service는 자동으로 기본 샤드와 복제본 샤드를 별도의 데이터 노드에 할당하고 장애 발생 시 백업이 있는지 확인합니다.

샤드를 재분배하려면 OpenSearch Service 클러스터에서 고르지 않은 샤드 분포를 재조정하려면 어떻게 해야 합니까?를 참조하십시오.

클러스터 규모 조정

클러스터에 요구 사항에 맞는 충분한 CPU, 메모리 및 디스크 공간이 있는지 확인하십시오. 애플리케이션에서 대규모 쿼리나 빈번한 쓰기를 수행하는 경우 성능 요구에 맞게 클러스터 또는 노드의 크기를 조정하십시오.

또한 전용 마스터 노드를 사용하여 특히 대규모 배포에서 클러스터 안정성과 복원력을 개선하십시오. 이 구성은 데이터 노드에서 클러스터 관리 책임을 제거합니다.

쿼리 최적화

대규모 집계, 와일드카드 쿼리(예: 선행 와일드카드) 및 정규 표현식(regex) 쿼리로 인해 CPU 사용량이 급증할 수 있습니다. 이러한 쿼리를 진단하려면 OpenSearch의 느린 로그를 확인하십시오.

관련 정보

OpenSearch Service 클러스터에서 인덱싱 성능을 향상하려면 어떻게 해야 합니까?

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

OpenSearch Service 도메인 크기 조정