AWS 기술 블로그

전용 코디네이터 노드를 사용한 Amazon OpenSearch Service 클러스터 복원력과 성능 향상

이 글은 Akshay Zade 님이 직성하신 “Improve OpenSearch Service cluster resiliency and performance with dedicated coordinator nodes” 포스팅을 한글로 번역 한 Posting입니다.

Amazon OpenSearch Service에서 OpenSearch 도메인을 생성할 때, 기존에는 데이터 노드가 여러 역할을 동시에 수행했습니다. 데이터 노드는 색인 요청 및 검색 요청을 조정할 뿐만 아니라, 색인 문서를 처리하고 검색 쿼리에 응답하는 작업까지 담당했습니다. 또한, OpenSearch Dashboards도 데이터 노드가 제공해야 했습니다. 이처럼 여러 가지 역할이 한꺼번에 부여되면, 데이터 노드가 리소스 병목 현상을 일으킬 가능성이 커지고, 심한 경우 노드 장애로 이어질 수도 있습니다. 이를 해결하기 위해 전용 코디네이터 노드를 도입했습니다. 코디네이터 노드는 요청 조정 및 Dashboards 제공을 전담하고, 데이터 노드는 요청을 처리하는 역할에 집중하도록 분리할 수 있습니다. 이를 통해 OpenSearch 도메인이 더욱 안정적이고 확장 가능한 구조를 갖출 수 있습니다.

Amazon OpenSearch Service는 아마존 웹 서비스(AWS) 클라우드에서 OpenSearch 클러스터를 대규모로 보호, 배치, 운영할 수 있는 관리형 서비스입니다. 이 서비스를 이용하면 데이터 노드(Data Node), 전용 관리자 노드(Dedicated Manager Node), UltraWarm 노드 등 다양한 유형의 노드를 구성하여 클러스터를 최적화할 수 있도록 합니다. OpenSearch Service 도메인으로 요청을 보내면, 해당 요청은 샤드(Shard)를 보유한 노드로 브로드캐스트되어 처리됩니다. 이때, 전용 관리자 노드와 같은 전용 노드를 배포하여 특정 역할을 분리하면 해당 요청의 처리를 특정 노드에서 집중적으로 수행할 수 있습니다. 이를 통해 다른 역할을 담당하는 노드의 부담을 줄이고, 클러스터의 성능과 안정성을 향상시킬 수 있습니다.

OpenSearch 서비스는 데이터 노드, 전용 관리자 노드, UltraWarm 노드와 함께 전용 코디네이터 노드를 포함하도록 노드 유형 옵션을 확장했습니다. 이러한 전용 코디네이터 노드는 데이터 노드에서 조정 작업과 대시보드 호스팅을 오프로드하여 CPU와 메모리 자원을 확보합니다. 전용 코디네이터 노드를 프로비저닝하면 클러스터의 전반적인 성능과 복원력을 향상시킬 수 있습니다. 전용 코디네이터 노드를 사용하면 데이터 저장 용량과 관계없이 클러스터의 조정 용량을 확장할 수 있습니다. 전용 코디네이터 노드는 모든 OpenSearch 엔진 버전에 대해 Amazon OpenSearch Service에서 사용할 수 있습니다. 엔진 및 버전 지원에 대한 문서를 참조하십시오.

조정 작업에 대한 이해

OpenSearch는 분산 시스템으로 작동하며, 데이터는 다양한 노드에 걸쳐 여러 개의 샤드로 저장됩니다. 따라서 요청을 처리하는 노드는 데이터를 저장하거나 검색하기 위해 여러 다른 노드와 협력해야 합니다.

다음은 다양한 사용자 요청을 성공적으로 처리하기 위해 수행되는 조정 작업의 몇 가지 예입니다.

  • 대량 인덱싱 요청에는 여러 샤드에 속하는 데이터가 포함될 수 있습니다. 조정 작업은 이러한 요청을 여러 샤드별 하위 요청으로 분할하고 인덱싱을 위해 해당 샤드로 라우팅합니다.
  • 검색 요청은 다른 노드에 존재하는 다양한 샤드를 쿼리해야 할 수 있습니다. 조정 작업은 요청을 여러 샤드 수준의 검색 요청으로 분할하고, 해당 데이터를 보유한 해당 데이터 노드로 그 요청을 보냅니다. 각 데이터 노드는 로컬에서 데이터를 처리하고 샤드 수준의 응답을 반환합니다. 조정 작업은 이러한 응답을 수집하고 조합하여 최종 응답을 만듭니다.
  • 집계(Aggregations)가 포함된 쿼리의 경우, 조정 작업은 데이터 노드에서 반환된 집계 응답을 다시 집계하는 추가 연산을 수행합니다.

OpenSearch Service에서는 각 데이터 노드가 기본적으로 요청 조정 기능을 수행할 수 있습니다. 전용 코디네이터 노드가 없을 경우, 요청을 받은 데이터 노드가 해당 역할을 담당하지만, 해당 요청과 관련된 샤드를 보유하지 않을 수도 있습니다. 클러스터에 전용 코디네이터 노드를 추가하면 데이터 노드의 부담을 줄일 수 있습니다. 다음 섹션에서는 이러한 개선 사항에 대해 설명합니다.

더 높은 색인 및 검색 처리량

OpenSearch 클러스터에서는 색인 요청이 조정, 기본(Primary), 복제(Replica)라는 세 가지 주요 단계를 거칩니다. 전용 코디네이터 노드가 조정 작업을 전담하면, 데이터 노드는 기본 및 복제 단계에서 더 많은 리소스를 사용할 수 있습니다. 코디네이터 노드를 추가한 결과, Stack OverflowBig5와 같은 워크로드에서 색인 처리량이 최대 15% 증가하는 것을 확인했습니다.

검색 요청은 단순히 특정 문서를 ID로 조회하는 것부터 대량의 데이터를 버킷으로 분류하고 각 버킷에서 집계를 수행하는 복잡한 작업까지 다양합니다. 전용 코디네이터 노드를 추가한 효과는 쿼리 유형에 따라 달라질 수 있습니다. 날짜 히스토그램과 평균, p50, p99 등 여러 집계를 포함하는 쿼리 워크로드에서는 약 20%의 처리량 향상을 달성했으며, 단일 용어 및 다중 용어 집계에서도 키 구성에 따라 15~20%의 처리량 향상이 관찰되었습니다.

보다 탄력적인 클러스터

전용 코디네이터 노드는 클러스터의 조정에 필요한 리소스를 데이터 저장에 필요한 리소스와 분리하여 운영할 수 있도록 합니다. 이를 통해 저장된 데이터에 영향을 주지 않으면서도 워크로드에 필요한 메모리와 CPU를 적절히 선택할 수 있습니다. 예를 들어, 높은 처리량이 필요한 클러스터는 가벼운 노드를 다수 배포하는 것이 유리하며, 복잡한 집계 작업이 많은 클러스터는 적은 수의 대형 노드를 구성하는 것이 더 효과적입니다.

또한, 전용 코디네이터 노드를 활용하면 예상되는 트래픽 패턴에 따라 노드 수를 변경할 수 있습니다. 예를 들어, 트래픽이 많은 시간대에는 코디네이터 노드 수를 증가시키고, 트래픽이 적은 시간대에는 축소하여 운영 효율성을 극대화할 수 있습니다.

OpenSearch VPC Access 도메인에 대한 더 적은 IP 예약

전용 코디네이터 노드를 사용하면 VPC에서 서비스가 예약하는 IP 주소 수를 최대 90%까지 줄일 수 있습니다. 이를 통해, 리소스 제한으로 인해 배포가 어려웠던 대규모 클러스터를 보다 쉽게 운영할 수 있습니다.

전용 코디네이터 노드 없이 VPC 도메인을 생성하면 OpenSearch Service는 VPC 내 각 데이터 노드에 대해 탄력적 네트워크 인터페이스(ENI)를 생성하고, 각 ENI에는 IP 주소가 할당됩니다. 이때, 도메인 생성 시 서비스는 데이터 노드당 세 개의 IP 주소를 예약합니다(이에 대한 자세한 내용은 아키텍처 문서를 참고하세요). 반면, 전용 코디네이터 노드를 사용하면 ENI가 데이터 노드가 아닌 코디네이터 노드에 연결됩니다. 일반적으로 데이터 노드보다 코디네이터 노드의 수가 적기 때문에 예약되는 IP 주소의 개수도 줄어들게 됩니다.

올바른 구성 선택하기

OpenSearch Service는 전용 코디네이터 노드를 관리하기 위한 두 가지 핵심 매개 변수를 제공합니다.

  • 인스턴스 유형 : 각 전용 코디네이터 노드의 메모리 및 컴퓨팅 용량을 결정합니다.
  • 인스턴스 수 : 전용 코디네이터 노드의 수를 지정합니다.

사용 사례 식별

코디네이터 노드의 성능을 극대화하려면 적절한 유형과 개수를 선택하는 것이 중요합니다. 일반적으로 데이터 노드 수의 10%를 코디네이터 노드로 설정하고, 데이터 노드와 유사한 크기의 인스턴스를 선택하는 것이 권장됩니다. 전용 코디네이터 노드가 지원되는 인스턴스 유형에 대한 자세한 내용은 문서를 참고하세요. 다음 지침은 특정 작업 부하에 맞게 구성 하는 데 도움이 될 것입니다.

  • 색인(Indexing) : 색인 작업의 경우, 대량 업로드 요청을 샤드별 청크로 분할하는 데 많은 연산 자원이 필요하므로, 데이터 노드와 유사한 크기의 CPU 최적화 인스턴스를 사용하는 것이 좋습니다. 목표 처리량에 따라 노드 개수를 변경할 수 있지만, 데이터 노드 수의 10%가 적절한 시작점입니다.
  • 높은 검색 처리량 : 높은 검색 처리량을 요구하는 경우, 충분한 네트워크 용량이 필요합니다. 코디네이터 노드 수를 늘리면 트래픽 부하를 효과적으로 처리하면서도 고가용성을 유지할 수 있습니다. 이 경우 데이터 노드 수의 10~15% 정도의 코디네이터 노드를 설정하는 것이 권장됩니다.
  • 복잡한 집계 쿼리 : 복잡한 집계 작업은 많은 메모리를 요구합니다. 예를 들어, p50 값을 계산하려면 코디네이터 노드가 전체 데이터셋을 메모리에 로드해야 하며, 추가적인 연산이 필요합니다. 따라서 데이터 노드보다 한 단계 큰 일반 목적의 코디네이터 노드를 사용하는 것이 좋으며, 노드 수는 8~10% 수준에서 시작하는 것이 적절합니다.

전용 코디네이터 노드 지표

위의 가이드는 기본적인 설정을 위한 좋은 출발점이지만, 각 사용 사례마다 최적의 구성이 다를 수 있습니다. 최상의 성능을 얻으려면 실제 워크로드를 기반으로 실험하고, 성능을 모니터링하며 병목 지점을 식별하는 과정이 필요합니다. OpenSearch Service는 코디네이터 노드의 상태를 확인할 수 있는 주요 지표와 API를 제공하므로, 이를 활용하여 성능을 최적화할 수 있습니다.

  • CoordinatorCPUUtilization 지표: 이 지표는 코디네이터 노드에서 사용되는 CPU 비율을 보여주며, 노드 및 클러스터 수준에서 확인할 수 있습니다. CPU 사용률이 지속적으로 80%를 초과하면, 더 큰 코디네이터 노드를 고려해야 할 시점일 수 있습니다.
  • CoordinatorJVMMemoryPressure, CoordinatorJVMGCOldCollectionCount, CoordinatorJVMGCOldCollectionTime 지표 : JVM 메모리 사용량과 가비지 컬렉션(GC) 동작을 분석하는 데 유용합니다. CoordinatorJVMMemoryPressure는 OpenSearch 프로세스에서 사용하는 JVM 메모리 비율을 나타내며, 클러스터 및 노드 수준에서 확인할 수 있습니다. JVM 메모리 압력이 지속적으로 높다면, 조정 작업이 메모리를 효율적으로 사용하고 있는지를 평가해야 합니다. 또한, JVM GC 관련 지표를 함께 살펴보는 것이 중요합니다. 오래된 객체를 정리하는 GC 실행 횟수와 지속 시간이 과도하게 증가하면, CPU 성능에도 부정적인 영향을 줄 수 있습니다. 적절하게 설정된 클러스터에서는 GC 실행이 드물고 짧아야 합니다.
  • CoordinatingWriteRejected 지표 : 이 지표는 PrimaryWriteRejectedReplicaWriteRejected와 함께 분석해야 합니다. 기본(primary) 또는 복제(replica) 쓰기 거부율이 증가하면 데이터 노드의 용량이 부족하여 요청을 빠르게 처리하지 못하고 있음을 의미합니다. 그러나 CoordinatingWriteRejected 값이 단독으로 증가하면, 코디네이터 노드가 색인 조정 작업을 처리하는 데 어려움을 겪고 있음을 나타냅니다. 색인 작업은 CPU, 메모리, 네트워크 등 여러 리소스를 필요로 하므로, 병목이 발생한 지점을 정확히 파악해야 합니다. 만약 CPU가 주요 병목이라면, 더 크거나 vCPU 수가 많은 인스턴스를 추가하면 문제를 완화할 수 있습니다.
  • 회로 차단기(Circuit Breaker) 통계 API : 회로 차단기는 OpenSearch가 Java OutOfMemoryError를 방지하기 위해 사용하는 메커니즘을 제공합니다. 코디네이터 노드의 회로 차단기 통계를 확인하려면 다음 API를 사용할 수 있습니다.
    _nodes/coordinating_only:true/stats/breaker
    요청이 회로 차단기에 의해 차단되면, 클라이언트는 429 error와 함께 circuit_breaking_exception 메시지를 받게 됩니다. 이러한 오류는 요청의 결과 크기가 코디네이터 노드의 메모리 한계를 초과했음을 의미합니다. 이를 방지하려면 더 많은 메모리를 가진 인스턴스를 사용하는 것이 권장됩니다.

전용 코디네이터 노드 구성

전용 코디네이터 노드를 추가하려면 도메인 설정을 업데이트하여 적절한 옵션을 지정하면 됩니다. 이를 수행하면 블루/그린 배포가 트리거되며, 배포가 완료된 후 도메인에 전용 코디네이터 노드가 적용됩니다. 또는, 처음부터 전용 코디네이터 노드를 포함한 새 도메인을 생성할 수도 있습니다.

어떤 방법을 선택하든, 설정 이후 전용 코디네이터 노드의 개수를 블루/그린 배포 없이 변경할 수 있으므로 유연하게 실험하고 최적의 구성을 찾을 수 있습니다.

결론

상용 환경에서 Amazon OpenSearch Service의 전용 코디네이터 노드는 조정 작업을 데이터 노드로부터 분리하여 운영 효율성을 높이는 효과적인 방법을 제공합니다. 이를 통해 리소스를 보다 효율적으로 활용할 수 있으며, 워크로드에 따라 색인 처리량이 최대 15% 증가하고 쿼리 성능이 20% 향상되는 결과를 얻을 수 있습니다. 조정 작업을 전용 노드로 분리하면 노드 과부하 위험을 줄이고 시스템 안정성을 개선할 수 있으며, 조정 및 데이터 처리 작업을 개별적으로 확장하여 비용을 보다 효과적으로 관리할 수 있습니다.

복잡한 쿼리와 높은 트래픽을 처리해야 하는 워크로드에서는 전용 코디네이터 노드를 활용하면 클러스터 성능을 최적화할 수 있으며, 향후 확장에도 더욱 탄력적으로 대응할 수 있습니다. OpenSearch 클러스터에서 더욱 효율적인 리소스 관리와 성능 향상을 경험하기 위해 지금 바로 전용 코디네이터 노드를 도입해 보세요.

Sewoong Kim

Sewoong Kim

김세웅 Solutions Architect는 MFG SA팀의 일원으로서 컨테이너와 서버리스를 중심으로 AWS 기반 서비스를 구성하는 고객들에게 최적화된 아키텍처를 제공하고, GenAI Application Architect를 보다 고도화 하기 위한 여러 기술적인 도움을 드리고 있습니다.