내 OpenSearch Service 노드가 충돌하는 이유는 무엇인가요?

4분 분량

Amazon OpenSearch Service 클러스터의 노드 중 하나가 다운되었습니다. 이 문제가 발생하지 않도록 하고 싶습니다.

간략한 설명

각 OpenSearch Service 노드는 별도의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에서 실행됩니다. 실패한 노드란 다른 노드의 하트비트 신호에 응답하지 않은 인스턴스를 말합니다. 하트비트 신호는 클러스터에서 데이터 노드의 가용성을 모니터링하는 주기적인 신호입니다.

클러스터 노드 실패의 일반적인 원인은 다음과 같습니다.

높은 Java 가상 머신(JVM) 메모리 압박
하드웨어 장애

해결 방법

실패한 노드 확인

1. OpenSearch Service 콘솔에 로그인합니다.

2. 탐색 창의 Managed clusters(관리형 클러스터)에서 Domains(도메인)을 선택합니다.

3. OpenSearch Service 도메인의 이름을 선택합니다.

4. Cluster health(클러스터 상태) 탭을 선택한 후 Nodes(노드) 지표를 선택합니다. 노드 수가 클러스터에 대해 구성한 노드 수보다 적으면 노드 가동이 중단된 것입니다.

참고: 클러스터 구성 변경 또는 서비스에 대한 정기적인 유지 관리 도중에는 노드 지표가 정확하지 않을 수 있습니다. 이는 예상된 동작입니다.

높은 JVM 메모리 압박 파악 및 문제 해결

JVM 메모리 압박은 OpenSearch Service 클러스터에서 모든 데이터 노드에 사용되는 Java 힙의 백분율을 말합니다. 높은 JVM 메모리 압박은 높은 CPU 사용률 및 기타 클러스터 성능 문제의 원인이 될 수 있습니다.

JVM 메모리 압박은 다음 조건으로 결정됩니다.

리소스 양에 비례하여 클러스터에 있는 데이터 양.
클러스터의 쿼리 로드.

JVM 메모리 부담이 증가하면 다음과 같은 상황이 발생합니다.

75%: OpenSearch Service가 Concurrent Mark Sweep(CMS) 가비지 수집기를 시작합니다. CMS 수집기는 다른 프로세스와 함께 실행되면서 일시 정지 및 중단을 최소한으로 유지합니다.
참고: OpenSearch Service에서 여러 가비지 수집 지표를 Amazon CloudWatch에 게시합니다. 이 지표는 JVM 메모리 사용량을 모니터링하는 데 도움이 됩니다. 자세한 내용은 Amazon CloudWatch를 사용하여 OpenSearch 클러스터 지표 모니터링을 참조하세요.
75% 초과: CMS 수집기가 메모리를 충분하게 회수하지 못해 사용량이 75%를 초과하면 OpenSearch Service JVM은 메모리 확보를 시도합니다. 또한 OpenSearch Service JVM은 프로세스 속도를 낮추거나 프로세스를 중지하여 JVM OutOfMemoryError(OOM) 예외를 방지합니다.
JVM이 계속 증가하고 공간이 회수되지 않으면 OpenSearch Service JVM은 메모리 할당을 시도하는 프로세스를 중지합니다. 중요한 프로세스가 중지된 경우, 하나 이상의 클러스터 노드가 실패할 수 있습니다. CPU 사용량을 80% 미만으로 유지하는 것이 좋습니다.

높은 JVM 메모리 압력 문제를 방지하려면 다음 모범 사례를 따르십시오.

와일드카드 쿼리와 같은 범위가 넓은 쿼리를 실행하지 않습니다.
동시에 많은 수의 요청을 보내지 않습니다.
필요한 샤드 수를 확보했는지 확인합니다. 인덱싱 전략에 대한 자세한 내용은 샤드 수 선택을 참조하세요.
샤드가 노드 간에 균등하게 분산되었는지 확인합니다.
텍스트 필드에서 집계 작업을 수행하지 않습니다. 이를 통해 필드 데이터의 증가를 방지할 수 있습니다. 필드 데이터를 많을수록 힙 공간을 더 많이 차지하게 됩니다. GET _cluster/stats API 작업을 사용하여 필드 데이터를 확인합니다. 자세한 정보는 Elasticsearch 문서에서 fielddata를 참조하세요.
텍스트 필드를 집계해야 하는 경우 매핑 유형을 keyword(키워드)로 변경합니다. JVM 메모리 압박이 너무 높은 경우 POST /index_name/_cache/clear(인덱스 수준 캐시) 및 POST /_cache/clear(클러스터 수준 캐시)와 같은 API 작업을 사용하여 필드 데이터 캐시를 지웁니다.
참고: 캐시를 지우면 진행 중인 쿼리가 중단될 수 있습니다.

하드웨어 장애 문제 파악 및 해결

때로는 하드웨어 오류가 클러스터 노드 가용성에 영향을 줄 수 있습니다. 잠재적 하드웨어 장애가 미치는 영향을 제한하려면 다음 요소를 확인합니다.

클러스터에 노드가 2개 이상 있는지 확인합니다. 단일 노드 클러스터는 단일 장애 지점입니다. 기본 샤드와 복제본 샤드를 동일한 노드에 할당할 수 없기 때문에 복제본 샤드를 사용하여 데이터를 백업할 수 없습니다. 노드 가동이 중단된 경우 스냅샷에서 데이터를 복구할 수 있습니다. 스냅샷에 대한 자세한 내용은 OpenSearch Service에서 인덱스 스냅샷 생성 섹션을 참조하세요. 또한 마지막 스냅샷에서 아직 캡처되지 않은 데이터는 복구할 수 없습니다. 자세한 내용은 OpenSearch Service 도메인 크기 조정 및 OpenSearch Service 도메인 생성 및 관리를 참조하세요.
복제본이 하나 이상 있는지 확인합니다. 복제본 샤드가 없는 경우 다중 노드 클러스터에서도 데이터 손실이 발생할 수 있습니다.
영역 인지를 켭니다. 영역 인지를 켜면 OpenSearch Service가 여러 가용 영역에서 데이터 노드를 시작합니다. OpenSearch Service는 기본 샤드와 해당 복제본 샤드를 서로 다른 가용 영역에 배포하려고 시도합니다. 한 노드나 영역에서 장애가 발생해도 데이터를 계속 사용할 수 있습니다. 자세한 정보는 OpenSearch Service에서 다중 AZ 도메인 구성을 참조하세요.