Amazon Elasticsearch Service 노드가 작동하지 않는 이유는 무엇입니까?

최종 업데이트 날짜: 2020년 9월 10일

내 Amazon Elasticsearch Service(Amazon ES) 클러스터에 있는 노드 중 하나가 작동 중지되었습니다. 노드가 실패하는 이유는 무엇이며 이런 문제를 방지하려면 어떻게 해야 합니까?

간략한 설명

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

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

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

​해결 방법

실패한 노드 확인

1.    Amazon ES 콘솔을 엽니다.

2.    Elasticsearch 도메인의 이름을 선택합니다.

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

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

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

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

JVM 메모리 압력은 다음 요소로 결정됩니다.

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

JVM 메모리 압력이 증가했을 때 다음과 같은 일이 발생합니다.

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

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

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

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

장애로 인해 Elasticsearch 클러스터의 노드 가용성이 영향을 받을 수 있습니다. 잠재적 하드웨어 장애가 미치는 영향을 제한하려면 다음을 확인합니다.

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