기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon OpenSearch Service의 전용 코디네이터 노드
<a name="Dedicated-coordinator-nodes"></a>

Amazon OpenSearch Service의 전용 코디네이터 노드는 데이터 노드에서 조정 작업을 오프로드하는 특수 노드입니다. 이러한 작업에는 검색 요청 관리 및 OpenSearch Dashboards 호스팅이 포함됩니다. 이 함수를 분리하면 전용 코디네이터 노드가 데이터 노드의 로드를 줄여 데이터 스토리지, 인덱싱 및 검색 작업에 집중할 수 있습니다. 이렇게 하면 전체 클러스터 성능과 리소스 사용률이 향상됩니다.

또한 전용 코디네이터 노드는 VPC 구성에 필요한 프라이빗 IP 주소 수를 줄이는 데 도움이 되므로 더 효율적으로 네트워크를 관리할 수 있습니다. 이 설정은 워크로드 특성에 따라 인덱싱 처리량을 최대 15% 개선하고 쿼리 성능을 20% 개선할 수 있습니다.

## 전용 코디네이터 노드를 사용해야 하는 경우
<a name="dedicated-coordinator-nodes-uses"></a>

전용 코디네이터 노드는 다음 시나리오에서 가장 유용합니다.
+ **대규모 클러스터** - 대량의 데이터 또는 복잡한 쿼리가 있는 환경에서 조정 작업을 전용 노드로 오프로드하면 클러스터 성능이 향상될 수 있습니다.
+ **빈번한 쿼리** - 빈번한 검색 쿼리 또는 집계, 특히 복잡한 날짜 히스토그램 또는 여러 집계가 있는 워크로드의 경우 더 빠른 쿼리 처리의 이점을 누릴 수 있습니다.
+ **Heavy Dashboards 사용** - OpenSearch Dashboards는 리소스 집약적일 수 있습니다. 이를 전용 코디네이터 노드로 오프로드하면 데이터 노드의 부담이 줄어듭니다.

## 아키텍처 및 동작
<a name="dedicated-coordinator-nodes-architecture"></a>

OpenSearch 클러스터에서 전용 코디네이터 노드는 두 가지 주요 작업을 처리합니다.
+ **요청 처리** - 이들 노드는 수신되는 검색 요청을 수신하여 관련 데이터를 저장할 적절한 데이터 노드로 전달합니다. 그런 다음 여러 데이터 노드의 결과를 단일 글로벌 결과 세트로 통합하여 클라이언트에 반환합니다.
+ **Dashboards 호스팅** - 코디네이터 노드가 OpenSearch Dashboards를 관리하므로 OpenSearch Dashboards를 호스팅하고 데이터 노드에서 관련 트래픽을 처리하는 데 따르는 추가적인 로드를 덜 수 있습니다.

VPC 도메인에서는 전용 코디네이터 노드에 데이터 노드가 아닌 탄력적 네트워크 인터페이스(ENI)가 할당됩니다. 이 배열은 VPC에 필요한 프라이빗 IP 주소 수를 줄이는 데 도움이 되므로 네트워크 효율성이 향상됩니다. 일반적으로 전용 코디네이터 노드는 일반적으로 총 데이터 노드의 약 10%를 차지합니다.

## 요구 사항 및 제한 사항
<a name="dedicated-coordinator-nodes-requirements"></a>

전용 코디네이터 노드에는 다음과 같은 요구 사항과 제한 사항이 있습니다.
+ 전용 코디네이터 노드는 모든 OpenSearch 버전 및 ElasticSearch 버전 6.8\$17.10에서 지원됩니다.
+ 전용 코디네이터 노드를 활성화하려면 도메인에 전용 마스터 노드가 활성화되어 있어야 합니다. 자세한 내용은 [Amazon OpenSearch Service의 전용 프라이머리 노드](managedomains-dedicatedmasternodes.md) 단원을 참조하십시오.
+ 전용 코디네이터 노드를 프로비저닝하면 추가 비용이 발생할 수 있습니다. 하지만 향상된 리소스 효율성과 향상된 성능은 특히 대규모 또는 복잡한 클러스터에서 대한 이 투자를 정당화합니다.

## 전용 코디네이터 노드 프로비저닝
<a name="dedicated-coordinator-nodes-provisioning"></a>

다음 단계를 수행하여 기존 도메인에서 전용 코디네이터 노드를 프로비저닝합니다. 코디네이터 노드를 프로비저닝하기 전에 도메인에 전용 *마스터* 노드가 활성화되어 있는지 확인합니다.

### 콘솔
<a name="dedicated-coordinator-nodes-provisioning-console"></a>

**에서 전용 조정자 노드를 프로비저닝하려면 AWS Management Console**

1. [https://console.aws.amazon.com/aos/home](https://console.aws.amazon.com/aos/home) Amazon OpenSearch Service 콘솔에 로그인합니다.

1. **도메인**을 선택한 다음 수정할 도메인을 선택합니다.

1. **클러스터 구성** 섹션에서 **편집**을 선택합니다.

1. **전용 코디네이터 노드 활성화**를 선택합니다.

1. 프로비저닝할 인스턴스 유형과 코디네이터 노드 수를 선택합니다.

1. **변경 사항 저장**을 선택합니다. 도메인이 업데이트되는 데 몇 분 정도 걸릴 수 있습니다.

### AWS CLI
<a name="dedicated-coordinator-nodes-provisioning-cli"></a>

를 사용하여 전용 조정자 노드를 프로비저닝하려면 [update-domain-config](https://docs.aws.amazon.com/cli/latest/reference/opensearch/update-domain-config.html) 명령을 AWS CLI사용합니다. 다음 예에서는 도메인에 3개의 `r6g.large.search` 코디네이터 노드를 프로비저닝합니다.

```
aws opensearch update-domain-config \
  --domain-name my-opensearch-domain \
  --cluster-config InstanceCount=3,InstanceType=r6g.large.search,DedicatedCoordinatorCount=3,ZoneAwarenessEnabled=true,DedicatedCoordinatorEnabled=true
```

이 명령은 전용 코디네이터 노드를 활성화하고, 코디네이터 노드의 인스턴스 유형 및 수를 설정하고, 고가용성을 위한 영역 인지를 활성화합니다.

## 모범 사례
<a name="best-practices-dedicated-coordinator-nodes"></a>

전용 코디네이터 노드를 사용할 때는 다음 모범 사례를 고려합니다.
+ 대부분의 사용 사례에서는 범용 인스턴스를 사용합니다. 이 인스턴스는 비용과 성능 간에 균형 잡힌 접근 방식을 제공합니다. 메모리 최적화 인스턴스는 복잡한 집계 또는 대규모 검색과 관련한 리소스처럼 상당한 메모리 리소스가 필요한 워크로드에 적합합니다.
+ 데이터 노드의 5%\$110%를 전용 코디네이터 노드로 프로비저닝하는 것이 좋은 출발점이 됩니다. 예를 들어 도메인에 특정 인스턴스 유형의 데이터 노드가 90개 있는 경우 동일한 인스턴스 유형의 코디네이터 노드를 5\$19개 프로비저닝하는 것이 좋습니다.
**참고**  
인스턴스 유형 가용성은 리전별로 다릅니다. 코디네이터 노드의 인스턴스 유형을 선택할 때 선택한 인스턴스 유형을 대상 리전에서 사용할 수 있는지 확인합니다. 도메인을 생성하거나 수정할 때 OpenSearch Service 콘솔에서 인스턴스 유형 가용성을 확인할 수 있습니다.
+ 단일 장애 지점의 위험을 최소화하려면 2개 이상의 전용 코디네이터 노드를 프로비저닝합니다. 이렇게 하면 노드 중 하나가 실패하더라도 클러스터가 계속 작동합니다.
+ 교차 리전 검색을 사용하는 경우 대상 도메인에 전용 코디네이터 노드를 프로비저닝하는 것이 좋습니다. 소스 도메인은 일반적으로 조정 작업을 처리하지 않습니다.
+ 인덱싱이 많은 환경의 경우 최적의 성능을 위해 데이터 노드의 인스턴스 크기와 일치하는 CPU 최적화 인스턴스를 고려합니다.
+ 메모리 집약적인 워크로드의 경우 전용 코디네이터 노드에 약간 더 큰 인스턴스 유형을 사용하여 증가하는 메모리 수요를 관리할 수 있습니다.
+ `CoordinatorCPUUtilization` Amazon CloudWatch 지표를 추적합니다. 지속적으로 80%를 초과하는 경우, 로드를 처리하는 데 더 큰 코디네이터 노드 또는 추가 코디네이터 노드가 필요할 수 있습니다.
+ 데이터 노드와 일치하도록 전용 코디네이터 노드의 크기를 조정합니다. 예를 들어 4xlarge 데이터 노드를 사용할 때는 4xlarge 범용 코디네이터 노드로 시작합니다.
+ 개별 요청 또는 응답에 매우 큰 용량의 메모리(GB 단위)가 필요하지 않은 한 코디네이터 노드에는 더 적은 수의 큰 인스턴스 대신 작은 인스턴스를 여러 개 사용합니다. 예를 들어 8xlarge 범용 인스턴스 6개가 아닌 4xl 인스턴스 12개를 선택합니다.

### 클러스터 크기별 노드 권장 사항
<a name="dedicated-coordinator-nodes-recs"></a>

클러스터 크기에 따라 전용 코디네이터 노드를 프로비저닝하기 위한 시작점으로 다음 지침을 사용합니다. 워크로드 특성과 성능 지표에 따라 노드의 수와 유형을 조정합니다.


| 클러스터 크기 | 권장 코디네이터 노드 | 인스턴스 유형 | 
| --- | --- | --- | 
|  스몰(최대 50개의 노드)  | 노드 3\$15개 | 범용 | 
|  미디엄(50\$1100개 노드)  | 노드 5\$19개 | 메모리 최적화 | 
|  라지(100개 이상의 노드)  | 노드 10\$115개 | 메모리 최적화 |