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

6분 분량

데이터 노드가 Amazon OpenSearch Service 클러스터에서 높은 CPU 사용량을 보이고 있습니다.

간략한 설명

OpenSearch Service가 작업을 수행할 수 있는 충분한 리소스를 확보하도록 CPU 사용률을 유지하는 것이 가장 좋습니다. 높은 CPU 사용률로 일관되게 작동하는 클러스터는 클러스터 성능을 저하시킬 수 있습니다. 클러스터에 과부하가 걸리면 OpenSearch Service가 응답을 중지하여 타임아웃 요청이 발생합니다.

클러스터의 높은 CPU 사용률 문제를 해결하려면 다음 접근 방식을 고려하세요.

노드 핫 스레드 API를 사용합니다.
쓰기 작업 또는 대량 API 스레드 풀을 확인합니다.
검색 스레드 풀을 확인합니다.
Apache Lucene 병합 스레드 풀을 확인합니다.
JVM 메모리 사용량을 확인합니다.
샤딩 전략을 검토합니다.
쿼리를 최적화합니다.

해결 방법

노드 핫 스레드 API 사용

OpenSearch 서비스 클러스터에서 CPU 사용률 급상승이 지속적으로 발생하는 경우 노드 핫 스레드 API를 사용하세요. 노드 핫 스레드 API는 클러스터에서 실행 중인 모든 리소스 집약적 스레드의 분류를 보여주는 작업 관리자 역할을 합니다.

노드 핫 스레드 API의 출력 예:

GET _nodes/hot_threads

100.0% (131ms out of 500ms) cpu usage by thread 'opensearch[xxx][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)

**참고:**노드 핫 스레드 출력에는 각 노드에 대한 정보가 나열됩니다. 출력 길이는 OpenSearch Service 클러스터에서 실행 중인 노드 수에 따라 달라집니다.

또한 캣 노드 API를 사용하여 리소스 사용률의 현재 분석을 볼 수 있습니다. 다음 명령을 사용하여 CPU 사용률이 가장 높은 노드의 하위 집합을 좁힐 수 있습니다.

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

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

그런 다음 관련 노드 이름을 핫 스레드 API에 전달합니다.

GET _nodes/<node-name>/hot_threads

자세한 내용은 Elasticsearch 웹 사이트의 핫 스레드 API를 참조하세요.

노드 핫 스레드 출력 예제:

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

스레드 이름은 어떤 OpenSearch Service 프로세스가 높은 CPU를 소비하는지 나타냅니다.

자세한 내용은 Elasticsearch 웹 사이트의 노드 핫 스레드 API를 참조하세요.

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

OpenSearch Service의 429 오류는 클러스터가 너무 많은 대량 인덱싱 요청을 처리하고 있음을 나타낼 수 있습니다. 클러스터에서 CPU 스파이크가 계속 발생하면 OpenSearch Service는 대량 인덱싱 요청을 거부합니다.

쓰기 스레드 풀은 대량 API 작업을 포함하는 인덱싱 요청을 처리합니다. 클러스터가 너무 많은 대량 인덱싱 요청을 처리하고 있는지 확인하려면 Amazon CloudWatch의 IndexingRate 지표를 확인하세요.

클러스터가 너무 많은 대량 인덱싱 요청을 처리하는 경우 다음 접근 방식을 고려해 보세요.

클러스터의 대량 요청 수를 줄입니다.
각 대량 요청의 크기를 줄이면 노드에서 더 효율적으로 처리할 수 있습니다.
Logstash를 사용하여 데이터를 OpenSearch Service 클러스터로 푸시하는 경우 배치 크기 또는 작업자 수를 줄입니다.
클러스터의 수집 속도가 느려지면 클러스터를 수평 또는 수직으로 확장합니다. 클러스터를 확장하려면 OpenSearch Service가 들어오는 요청을 처리할 수 있도록 노드 수와 인스턴스 유형을 늘리세요.

자세한 내용은 Elasticsearch 웹사이트의 대량 API를 참조하세요.

검색 스레드 풀 확인

높은 CPU를 소비하는 검색 스레드 풀은 검색 쿼리가 OpenSearch Service 클러스터를 압도하고 있음을 나타냅니다. 하나의 장기 실행 쿼리로 인해 클러스터가 압도될 수 있습니다. 클러스터에서 수행되는 쿼리의 증가는 검색 스레드 풀에도 영향을 미칠 수 있습니다.

단일 쿼리로 CPU 사용량이 증가하는지 확인하려면 작업 관리 API를 사용하세요. 예를 들면 다음과 같습니다.

GET _tasks?actions=*search&detailed

작업 관리 API는 클러스터에서 실행 중인 모든 활성 검색 쿼리를 가져옵니다. 자세한 내용은 Elasticsearch 웹 사이트의 작업 관리 API를 참조하세요.

참고: 작업 관리 API에 검색 작업이 나열되어 있는 경우 출력에는 설명 필드만 포함됩니다.

예제 출력:

{
    "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": {}
                }
            }
        }
    }
}

설명 필드를 확인하여 어떤 쿼리가 실행되고 있는지 확인하세요. running_time_in_nanos 필드는 쿼리가 실행된 시간을 나타냅니다. CPU 사용량을 줄이려면 높은 CPU를 소비하는 검색 쿼리를 취소하세요. 작업 관리 API는 _cancel 호출도 지원합니다.

**참고:**특정 작업을 취소하려면 출력의 작업 ID를 기록해야 합니다. 이 예제에서 작업 ID는 “U4M_p_x2Rg6YqLujeInPOw:53506997"입니다.

작업 관리 POST 호출 예제:

POST _tasks/U4M_p_x2Rg6YqLujeInPOw:53506997/_cancel

작업 관리 POST 호출은 작업을 “취소됨”으로 표시하여 종속 AWS 리소스를 모두 릴리스합니다. 클러스터에서 여러 쿼리를 실행 중인 경우 POST 호출을 사용하여 한 번에 하나씩 쿼리를 취소하세요. 클러스터가 정상 상태로 돌아올 때까지 각 쿼리를 취소합니다. 또한 높은 CPU 스파이크를 방지하기 위해 쿼리 본문에 타임아웃 값을 설정하는 것이 좋습니다. 자세한 내용은 Elasticsearch 웹 사이트에서 본문 검색 매개 변수 요청을 참조하세요. 활성 쿼리 수가 감소했는지 확인하려면 Amazon CloudWatch의 SearchRate 지표를 확인하세요.

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

자세한 내용은 Elasticsearch 웹 사이트의 스레드 풀을 참조하세요.

Apache Lucene 병합 스레드 풀 확인

OpenSearch Service는 Apache Lucene을 사용하여 클러스터에서 문서를 인덱싱하고 검색합니다. Apache Lucene은 병합 작업을 실행하여 각 샤드에 필요한 유효 세그먼트 수를 줄이고 삭제된 문서를 제거합니다. 이 프로세스는 샤드에 새 세그먼트가 생성될 때마다 실행됩니다.

Apache Lucene 병합 스레드 작업이 CPU 사용에 영향을 미치는 것으로 확인되면 OpenSearch Service 클러스터 인덱스의 refresh_interval 설정을 늘리세요. refresh_interval 설정을 늘리면 클러스터의 세그먼트 생성 속도가 느려집니다.

참고: 인덱스를 UltraWarm 스토리지로 마이그레이션하는 클러스터는 CPU 사용률을 높일 수 있습니다. UltraWarm 마이그레이션에는 일반적으로 CPU 사용량이 많은 강제 병합 API 작업이 포함됩니다.

UltraWarm 마이그레이션을 확인하려면 다음 명령을 사용하세요.

GET _ultrawarm/migration/_status?v

자세한 내용은 Elasticsearch 웹 사이트의 병합을 참조하세요.

JVM 메모리 사용량 확인

클러스터 노드에 있는 Java 힙의 JVM 메모리 사용량 비율을 검토하세요. JVM 메모리 사용량이 75%에 도달하면 Amazon OpenSearch Service가 CMS(동시 마크 스윕) 가비지 콜렉터를 트리거합니다. JVM 메모리 사용량이 100%에 도달하면 OpenSearch Service JVM이 종료되고 결국에는 OutOfMemory(OOM)에서 다시 시작되도록 구성됩니다.

다음 예제 로그에서 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]

자세한 내용은 Amazon OpenSearch Service 클러스터의 높은 JVM 메모리 사용량 문제를 해결하려면 어떻게 해야 합니까?를 참조하세요.

샤딩 전략 검토

클러스터 크기에 따라 샤드가 너무 많으면 클러스터의 성능이 저하될 수 있습니다. 가장 좋은 방법은 Java 힙의 GiB당 샤드를 25개이하로 유지하는 것입니다.

기본적으로 Amazon OpenSearch Service는 각 인덱스를 5개의 기본 샤드로 나누는 5:1의 샤딩 전략을 사용합니다. 각 인덱스 내에는 각 기본 샤드에도 자체 복제본이 있습니다. OpenSearch Service는 자동으로 기본 샤드와 복제본 샤드를 별도의 데이터 노드에 할당하고 장애 발생 시 백업이 있는지 확인합니다.

자세한 내용은 Amazon OpenSearch Service 클러스터의 고르지 않은 샤드 분포를 재조정하려면 어떻게 해야 합니까?를 참조하세요.

쿼리 최적화

집계, 와일드카드 쿼리(특히 선행 와일드카드) 및 정규식 쿼리는 계산 비용이 많이 들고 CPU 사용률이 급증할 수 있습니다. 느린 로그를 검색하고 느린 로그를 인덱싱하면 비용이 많이 들고 문제가 있는 쿼리를 진단하는 데 도움이 됩니다.

자세한 내용은 Amazon CloudWatch Logs를 사용한 OpenSearch 로그 모니터링을 참조하세요.