Amazon OpenSearch Service의 전용 코디네이터 노드 - Amazon OpenSearch Service
전용 코디네이터 노드를 사용해야 하는 경우아키텍처 및 동작요구 사항 및 제한 사항전용 코디네이터 노드 프로비저닝모범 사례

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

Amazon OpenSearch Service의 전용 코디네이터 노드

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

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

전용 코디네이터 노드를 사용해야 하는 경우

전용 코디네이터 노드는 다음 시나리오에서 가장 유용합니다.

  • 대규모 클러스터 - 대량의 데이터 또는 복잡한 쿼리가 있는 환경에서 조정 작업을 전용 노드로 오프로드하면 클러스터 성능이 향상될 수 있습니다.

  • 빈번한 쿼리 - 빈번한 검색 쿼리 또는 집계, 특히 복잡한 날짜 히스토그램 또는 여러 집계가 있는 워크로드의 경우 더 빠른 쿼리 처리의 이점을 누릴 수 있습니다.

  • Heavy Dashboards 사용 - OpenSearch Dashboards는 리소스 집약적일 수 있습니다. 이를 전용 코디네이터 노드로 오프로드하면 데이터 노드의 부담이 줄어듭니다.

아키텍처 및 동작

OpenSearch 클러스터에서 전용 코디네이터 노드는 두 가지 주요 작업을 처리합니다.

  • 요청 처리 - 이들 노드는 수신되는 검색 요청을 수신하여 관련 데이터를 저장할 적절한 데이터 노드로 전달합니다. 그런 다음 여러 데이터 노드의 결과를 단일 글로벌 결과 세트로 통합하여 클라이언트에 반환합니다.

  • Dashboards 호스팅 - 코디네이터 노드가 OpenSearch Dashboards를 관리하므로 OpenSearch Dashboards를 호스팅하고 데이터 노드에서 관련 트래픽을 처리하는 데 따르는 추가적인 로드를 덜 수 있습니다.

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

요구 사항 및 제한 사항

전용 코디네이터 노드에는 다음과 같은 요구 사항과 제한 사항이 있습니다.

  • 전용 코디네이터 노드는 모든 OpenSearch 버전 및 ElasticSearch 버전 6.8~7.10에서 지원됩니다.

  • 전용 코디네이터 노드를 활성화하려면 도메인에 전용 마스터 노드가 활성화되어 있어야 합니다. 자세한 내용은 Amazon OpenSearch Service의 전용 프라이머리 노드 섹션을 참조하세요.

  • 전용 코디네이터 노드를 프로비저닝하면 추가 비용이 발생할 수 있습니다. 하지만 향상된 리소스 효율성과 향상된 성능은 특히 대규모 또는 복잡한 클러스터에서 대한 이 투자를 정당화합니다.

전용 코디네이터 노드 프로비저닝

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

AWS Management 콘솔에서 전용 코디네이터 노드를 프로비저닝하려면

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

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

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

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

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

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

AWS CLI를 사용하여 전용 코디네이터 노드를 프로비저닝하려면 update-domain-config 명령을 사용합니다. 다음 예에서는 도메인에 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

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

모범 사례

전용 코디네이터 노드를 사용할 때는 다음 모범 사례를 고려합니다.

  • 대부분의 사용 사례에서는 범용 인스턴스를 사용합니다. 이 인스턴스는 비용과 성능 간에 균형 잡힌 접근 방식을 제공합니다. 메모리 최적화 인스턴스는 복잡한 집계 또는 대규모 검색과 관련한 리소스처럼 상당한 메모리 리소스가 필요한 워크로드에 적합합니다.

  • 데이터 노드의 5%~10%를 전용 코디네이터 노드로 프로비저닝하는 것이 좋은 출발점이 됩니다. 예를 들어 도메인에 특정 인스턴스 유형의 데이터 노드가 90개 있는 경우 동일한 인스턴스 유형의 코디네이터 노드를 5~9개 프로비저닝하는 것이 좋습니다.

    참고

    인스턴스 유형 가용성은 리전별로 다릅니다. 코디네이터 노드의 인스턴스 유형을 선택할 때 선택한 인스턴스 유형을 대상 리전에서 사용할 수 있는지 확인합니다. 도메인을 생성하거나 수정할 때 OpenSearch Service 콘솔에서 인스턴스 유형 가용성을 확인할 수 있습니다.

  • 단일 장애 지점의 위험을 최소화하려면 2개 이상의 전용 코디네이터 노드를 프로비저닝합니다. 이렇게 하면 노드 중 하나가 실패하더라도 클러스터가 계속 작동합니다.

  • 교차 리전 검색을 사용하는 경우 대상 도메인에 전용 코디네이터 노드를 프로비저닝하는 것이 좋습니다. 소스 도메인은 일반적으로 조정 작업을 처리하지 않습니다.

  • 인덱싱이 많은 환경의 경우 최적의 성능을 위해 데이터 노드의 인스턴스 크기와 일치하는 CPU 최적화 인스턴스를 고려합니다.

  • 메모리 집약적인 워크로드의 경우 전용 코디네이터 노드에 약간 더 큰 인스턴스 유형을 사용하여 증가하는 메모리 수요를 관리할 수 있습니다.

  • CoordinatorCPUUtilization Amazon CloudWatch 지표를 추적합니다. 지속적으로 80%를 초과하는 경우, 로드를 처리하는 데 더 큰 코디네이터 노드 또는 추가 코디네이터 노드가 필요할 수 있습니다.

  • 데이터 노드와 일치하도록 전용 코디네이터 노드의 크기를 조정합니다. 예를 들어 4xlarge 데이터 노드를 사용할 때는 4xlarge 범용 코디네이터 노드로 시작합니다.

  • 개별 요청 또는 응답에 매우 큰 용량의 메모리(GB 단위)가 필요하지 않은 한 코디네이터 노드에는 더 적은 수의 큰 인스턴스 대신 작은 인스턴스를 여러 개 사용합니다. 예를 들어 8xlarge 범용 인스턴스 6개가 아닌 4xl 인스턴스 12개를 선택합니다.

클러스터 크기별 노드 권장 사항

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

클러스터 크기 권장 코디네이터 노드 인스턴스 유형

스몰(최대 50개의 노드)

 노드 3~5개 범용

미디엄(50~100개 노드)

 노드 5~9개 메모리 최적화

라지(100개 이상의 노드)

 노드 10~15개 메모리 최적화