Amazon OpenSearch Service의 전용 프라이머리 노드 - Amazon OpenSearch Service
전용 프라이머리 노드 수 선택전용 프라이머리 노드에 대한 인스턴스 유형 선택

Amazon OpenSearch Service의 전용 프라이머리 노드

Amazon OpenSearch Service는 전용 프라이머리 노드를 사용하여 클러스터 안정성을 증가합니다. 전용 프라이머리 노드는 클러스터 관리 작업을 수행하지만 데이터를 보유하지 않거나 데이터 업로드 요청에 응답하지 않습니다. 클러스터 관리 작업을 오프로드하면 도메인의 안정성이 높아집니다. 다른 모든 노드 유형과 마찬가지로, 각 전용 프라이머리 노드에 대한 시간당 요금을 지불합니다.

전용 프라이머리 노드는 다음 클러스터 관리 작업을 수행합니다.

  • 클러스터의 모든 노드를 추적합니다.

  • 클러스터에 있는 인덱스 수를 추적합니다.

  • 각 인덱스에 속한 샤드 수를 추적합니다.

  • 클러스터에 있는 노드에 대한 라우팅 정보를 유지합니다.

  • 인덱스 생성, 클러스터에서 노드 추가 또는 제거와 같은 상태 변경 후 클러스터 상태를 업데이트합니다.

  • 클러스터의 모든 노드 간에 클러스터 상태 변경 사항을 복제합니다.

  • 클러스터에서 데이터 노드의 가용성을 모니터링하는 주기적인 신호인 하트비트 신호를 전송하여 모든 클러스터 노드의 상태를 모니터링합니다.

다음 그림은 10개의 인스턴스가 있는 OpenSearch Service 도메인을 보여줍니다. 인스턴스 중 7개는 데이터 노드이고 3개는 전용 프라이머리 노드입니다. 전용 프라이머리 노드 중 하나만 활성화됩니다. 회색으로 표시된 전용 프라이머리 노드 2개는 활성 상태인 전용 프라이머리 노드에서 장애가 발생한 경우 백업으로 사용하기 위해 대기 중입니다. 모든 데이터 업로드 요청은 데이터 노드 7개에서 처리하고 모든 클러스터 관리 작업은 활성 상태인 전용 프라이머리 노드로 오프로드됩니다.

OpenSearch Service domain with data nodes and dedicated master nodes, illustrating 클러스터 management.

전용 프라이머리 노드 수 선택

각 프로덕션 OpenSearch Service 도메인에 3개의 전용 프라이머리 노드를 추가하는 것이 좋습니다. Multi-AZ without Standby 또는 단일 AZ로 배포하는 경우에도 전용 프라이머리 노드 3개를 사용하는 것이 좋습니다. 짝수의 전용 프라이머리 노드를 선택하지 않습니다. 전용 프라이머리 노드 수를 선택할 때 다음 사항을 고려합니다.

  • 오류 발생 시 백업이 없기 때문에 OpenSearch Service에서 1개의 전용 프라이머리 노드를 명시적으로 금지합니다. 전용 프라이머리 노드가 하나만 있는 도메인을 생성하려고 시도하는 경우 유효성 검사 예외가 나타납니다.

  • 2개의 전용 프라이머리 노드가 있는 경우, 오류 발생 시 클러스터에 새 프라이머리 노드를 선택하는 데 필요한 노드 쿼럼이 없습니다.

    쿼럼은 전용 프라이머리 노드 수/2 + 1(가장 가까운 정수로 반올림)입니다. 이 경우 2/2 + 1 = 2입니다. 전용 프라이머리 노드 1개에 오류가 발생했고 백업이 1개만 존재하기 때문에, 클러스터에 쿼럼이 없어 새 마스터를 선택할 수 없습니다.

  • 권장되는 3개의 전용 프라이머리 노드는 프라이머리 노드에 오류가 발생했을 때 2개의 백업 노드와 새 마스터를 선택할 수 있는 필수 쿼럼(2)을 제공합니다.

  • 네 개의 전용 프라이머리 노드는 세 개일 때보다 나은 점이 없으며 다중 가용 영역을 사용하는 경우 문제가 발생할 수 있습니다.

    • 1개의 프라이머리 노드에서 오류가 발생하면 쿼럼(3)이 있어 새 마스터를 선택합니다. 2개의 프라이머리 노드에서 오류가 발생하면 3개의 전용 프라이머리 노드와 마찬가지로 해당 쿼럼이 손실됩니다.

    • 세 개의 가용 영역 구성에서 2개의 AZ에는 하나의 전용 프라이머리 노드가 있고 한 AZ에는 두 개의 전용 프라이머리 노드가 있습니다. 해당 AZ가 중단되면 나머지 두 개의 AZ에는 새 마스터를 선택하는 데 필요한 쿼럼(3)이 없습니다.

  • 5개의 전용 프라이머리 노드가 3개처럼 잘 작동하므로, 쿼럼을 유지 관리하는 동안 2개의 노드를 잃을 수 있습니다. 그러나 지정된 시간에 전용 프라이머리 노드 하나만 활성화되기 때문에 이 구성은 4개의 유휴 노드에 대한 비용을 지불하게 됩니다. 많은 사용자가 이 수준의 장애 조치 보호를 과하게 사용하고 있습니다.

클러스터에 마스터로 적합한 노드가 짝수 개 있는 경우 OpenSearch 및 Elasticsearch 버전 7.x 이상에서는 투표 구성이 항상 홀수가 되도록 하나의 노드를 무시합니다. 이 경우 4개의 전용 프라이머리 노드는 기본적으로 3개(2 대 1)와 동일합니다.

참고

귀하의 클러스터에 새 프라이머리 노드를 선택하는 데 필요한 쿼럼이 없는 경우, 클러스터에 대한 읽기 및 쓰기 요청이 모두 실패로 끝납니다. 이 동작은 OpenSearch의 기본값과 다릅니다.

전용 프라이머리 노드에 대한 인스턴스 유형 선택

전용 프라이머리 노드가 검색 및 쿼리 요청을 처리하지 않더라도 전용 프라이머리 노드의 크기는 자신이 관리할 수 있는 인스턴스, 인덱스 및 샤드의 수와 밀접한 관련이 있습니다. 프로덕션 클러스터의 경우 전용 프라이머리 노드에 대해 다음과 같은 인스턴스 유형이 권장됩니다.

다음 권장 사항은 일반적인 워크로드를 기반으로 한 것이며 필요에 따라 달라질 수 있습니다. 샤드나 필드 매핑이 여러 개인 클러스터는 대규모 인스턴스 유형을 활용할 수 있습니다. 전용 프라이머리 노드 지표를 모니터링하여 대규모 인스턴스 유형을 사용해야 하는지를 확인합니다.

인스턴스 수

 프라이머리 노드 RAM 크기 지원되는 최대 샤드 수

권장되는 최소 전용 마스터 인스턴스 유형

1~10

 8GiB 10K

m5.large.search 또는 m6g.large.search

11~30

 16GiB 30K

c5.2xlarge.search 또는 c6g.2xlarge.search
31~75 32GiB 40K

r5.xlarge.search 또는 r6g.xlarge.search
76~125 64GiB 75K

r5.2xlarge.search 또는 r6g.2xlarge.search

126~200

 128GiB 75K

r5.4xlarge.search 또는 r6g.4xlarge.search