제퍼넷 로고

고가용성을 위해 Amazon OpenSearch 서비스 구성 | 아마존 웹 서비스

시간

아마존 오픈서치 서비스 추천 엔진, 전자 상거래 사이트 및 카탈로그 검색과 같은 사용 사례에 대한 비즈니스 및 운영 데이터의 실시간 검색, 모니터링 및 분석을 안전하게 잠금 해제하는 완전한 오픈 소스 검색 및 분석 엔진입니다. 비즈니스에서 성공하려면 가동 중지 시간을 최소화하고 장애를 방지하면서 가용성과 성능이 뛰어난 시스템이 필요합니다. 인프라를 모니터링하는 기본 수단으로 OpenSearch Service를 사용하는 경우 가용성도 보장해야 합니다. OpenSearch 서비스의 다운타임은 수익 손실, 생산성 손실, 브랜드 가치 손실 등과 같은 비즈니스 결과에 상당한 영향을 미칠 수 있습니다.

최대 XNUMXW 출력을 제공하는 가용성 측정을 위한 업계 표준 나인 클래스입니다. OpenSearch 서비스는 팔로우할 때 3의 가용성을 제공합니다. 모범 사례즉, 한 달에 43.83분 미만의 다운타임을 보장합니다. 이 게시물에서는 도메인을 설정하는 동안 모범 사례 및 권장 사항을 따라 고가용성 및 성능을 위해 OpenSearch 서비스 도메인을 구성하는 방법을 알아봅니다.

도메인의 가용성에 영향을 미치는 두 가지 필수 요소는 주로 워크로드에 의해 결정되는 도메인의 리소스 활용과 인프라 오류와 같은 외부 이벤트입니다. 전자는 도메인의 성능 및 상태를 지속적으로 모니터링하고 그에 따라 도메인을 확장하여 제어할 수 있지만 후자는 그렇지 않습니다. 가용 영역 중단, 인스턴스 또는 디스크 장애 또는 도메인의 네트워킹 문제와 같은 외부 이벤트의 영향을 완화하려면 여러 가용 영역에 분산된 추가 용량을 프로비저닝하고 여러 데이터 복사본을 유지해야 합니다. 그렇게 하지 않으면 성능이 저하되고 사용할 수 없으며 최악의 경우 데이터 손실이 발생할 수 있습니다.

도메인을 사용할 수 있고 성능이 좋은지 확인하기 위해 사용할 수 있는 옵션을 살펴보겠습니다.

클러스터 구성

이 섹션에서는 배포를 위한 AZ 수 지정, 마스터 및 데이터 노드 설정, 인덱스 및 샤드 설정을 포함하여 클러스터를 올바르게 설정해야 하는 다양한 구성 옵션에 대해 설명합니다.

다중 AZ 배포

데이터 노드는 도메인에서 인덱싱 및 검색 요청 처리를 담당합니다. 여러 가용 영역에 데이터 노드를 배포하면 중복 영역별 데이터 스토리지 및 처리를 추가하여 도메인의 가용성이 향상됩니다. 다중 AZ 배포를 사용하면 전체 가용 영역을 사용할 수 없게 되더라도 도메인을 계속 사용할 수 있습니다. 프로덕션 워크로드의 경우 AWS는 도메인에 XNUMX개의 가용 영역을 사용할 것을 권장합니다.. 가용성 향상을 위해 XNUMX개만 지원하는 리전에 대해 XNUMX개의 가용 영역을 사용합니다. 이렇게 하면 단일 AZ 장애 발생 시 도메인을 사용할 수 있습니다.

전용 클러스터 관리자(마스터 노드)

AWS는 XNUMX개의 전용 클러스터 관리자(CM) 노드 사용을 권장합니다. 모든 프로덕션 워크로드에 적합합니다. CM 노드는 클러스터의 상태, 인덱스 및 샤드의 상태 및 위치, 모든 인덱스에 대한 매핑, 데이터 노드의 가용성을 추적하고 진행 중인 클러스터 수준 작업 목록을 유지 관리합니다. 전용 CM 노드가 없으면 클러스터는 데이터 노드를 사용하므로 클러스터가 워크로드 수요에 취약해집니다. 작업 크기(주로 데이터 노드 수, 인덱스 수 및 샤드 수)에 따라 CM 노드의 크기를 조정해야 합니다. OpenSearch 서비스는 리전에서 지원하는 경우 항상 XNUMX개의 가용 영역에 걸쳐 CM 노드를 배포합니다(지역에 XNUMX개의 가용 영역만 있는 경우 한 가용 영역에 XNUMX개, 다른 가용 영역에 XNUMX개). 실행 중인 도메인의 경우 세 개의 CM 노드 중 하나만 선출된 리더로 작동합니다. 다른 두 CM 노드는 선출된 CM 노드가 실패하면 선출에 참여합니다.

다음 표는 CM 크기 조정에 대한 AWS의 권장 사항을 보여줍니다. CM 노드는 노드, 인덱스, 샤드 및 매핑의 수를 기반으로 작동합니다. 작업이 많을수록 클러스터 상태를 유지하고 작업하는 데 더 많은 컴퓨팅 및 메모리가 필요합니다.

인스턴스 수 클러스터 관리자 노드 RAM 크기 지원되는 최대 샤드 수 권장되는 최소 전용 클러스터 관리자 인스턴스 유형
1-10 8 GiB 10,000 m5.large.search 또는 m6g.large.search
11-30 16 GiB 30,000 c5.2xlarge.search 또는 c6g.2xlarge.search
31-75 32 GiB 40,000 c5.4xlarge.search 또는 c6g.4xlarge.search
76 – 125 64 GiB 75,000 r5.2xlarge.search 또는 r6g.2xlarge.search
126 – 200 128 GiB 75,000 r5.4xlarge.search 또는 r6g.4xlarge.search

인덱스 및 샤드

인덱스는 문서 모음을 수용하는 논리적 구조입니다. 기본 샤드 수를 지정하여 병렬 처리를 위해 인덱스를 분할합니다. 여기서 샤드는 데이터 저장 및 처리를 위한 물리적 단위를 나타냅니다. OpenSearch Service에서 샤드는 기본 샤드 또는 복제본 샤드일 수 있습니다. 기본 샤드가 손실된 경우 OpenSearch Service는 복제본 중 하나를 기본으로 승격하고 검색 처리량을 개선하기 위해 내구성을 위해 복제본을 사용합니다. OpenSearch 서비스는 기본 및 복제 샤드가 둘 이상의 가용 영역에 배포된 경우 서로 다른 노드 및 서로 다른 가용 영역에 배치되도록 합니다. 고가용성을 위해 AWS는 성능 및 가용성의 중단을 방지하기 위해 XNUMX개 영역 설정에서 각 인덱스에 대해 최소 XNUMX개의 복제본을 구성할 것을 권장합니다. 다중 AZ 설정에서 노드에 장애가 발생하거나 드물게 최악의 경우 가용 영역에 장애가 발생해도 데이터 사본이 남아 있습니다.

클러스터 모니터링 및 관리

앞에서 설명한 것처럼 모범 사례를 기반으로 구성을 선택하는 것은 작업의 절반에 불과합니다. 또한 리소스 사용률과 성능을 지속적으로 모니터링하여 도메인을 확장해야 하는지 결정해야 합니다. 프로비저닝이 부족하거나 과도하게 사용되는 도메인은 성능 저하 및 결국 사용 불가능으로 이어질 수 있습니다.

CPU 사용률

도메인의 CPU를 사용하여 워크로드를 실행합니다. 일반적으로 모든 데이터 노드에 대해 평균 CPU 사용률을 60%로 목표로 설정해야 합니다(최대 80%). 작은 급증은 100%까지 허용해야 합니다. 가용성, 특히 전체 영역의 가용성을 고려할 때 두 가지 시나리오가 있습니다. 두 개의 가용 영역이 있는 경우 각 영역이 트래픽의 50%를 처리합니다. 영역을 사용할 수 없게 되면 다른 영역이 해당 트래픽을 모두 처리하여 CPU 사용률을 두 배로 늘립니다. 이 경우 가용성을 유지하려면 각 영역에서 평균 CPU 사용률이 약 30~40%여야 합니다. 세 개의 가용 영역을 실행 중인 경우 각 영역이 트래픽의 33%를 차지합니다. 영역을 사용할 수 없게 되면 각 영역에서 약 17%의 트래픽을 얻습니다. 이 경우 50–60% 평균 CPU 사용률을 목표로 해야 합니다.

메모리 활용도

OpenSearch Service는 두 가지 유형의 가비지 수집을 지원합니다. 첫 번째는 G1 가비지 컬렉션(G1GC)으로 OpenSearch 서비스 노드에서 사용되며 AWS 그래비톤 2. 두 번째는 CMS(Concurrent Mark Sweep)로, 다른 프로세서로 구동되는 모든 노드에서 사용됩니다. 노드에 할당된 모든 메모리 중에서 메모리의 절반(최대 32GB)이 Java 힙에 할당되고 나머지 메모리는 다른 운영 체제 작업, 파일 시스템 캐시 등에 사용됩니다. 도메인의 가용성을 유지하려면 최대 JVM 사용률을 CMS에서 약 80%, G95GC에서 1%로 유지하는 것이 좋습니다. 그 이상은 도메인의 가용성에 영향을 미치고 클러스터를 비정상적으로 만듭니다. 또한 메모리 사용률을 능동적으로 모니터링하고 가비지 수집기를 트리거하는 자동 조정을 활성화하는 것이 좋습니다.

스토리지 활용도

OpenSearch Service는 다음을 위한 몇 가지 지침을 게시합니다. 도메인 크기 조정. 요구 사항에 필요한 스토리지의 적절한 양을 결정할 수 있도록 경험적 공식을 제공합니다. 그러나 시간 경과에 따른 스토리지 고갈과 워크로드 특성의 변화에 ​​주의를 기울이는 것이 중요합니다. 도메인의 스토리지가 부족하지 않고 데이터를 계속 인덱싱할 수 있도록 하려면 다음을 구성해야 합니다. 아마존 클라우드 워치 경보를 울리고 무료 저장 공간을 모니터링합니다.

또한 AWS는 각 샤드가 최적의 크기 범위 내에 있도록 기본 샤드 수를 선택할 것을 권장합니다. 데이터 및 트래픽에 대한 개념 증명 테스트를 통해 최적의 샤드 크기를 결정할 수 있습니다. 검색 사용 사례에는 10~30GB의 기본 샤드 크기를, 로그 분석 사용 사례에는 45~50GB의 기본 샤드 크기를 지침으로 사용합니다. 샤드는 도메인의 작업자이므로 데이터 노드 전체의 워크로드 분산을 직접 담당합니다. 샤드가 너무 크면 대규모 집계로 인한 Java 힙의 스트레스, 쿼리 성능 저하, 샤드 재조정, 스냅샷, hot-to-warm 마이그레이션과 같은 클러스터 수준 작업의 성능 저하를 볼 수 있습니다. 샤드가 너무 작으면 도메인의 Java 힙 공간을 압도하고 과도한 내부 네트워킹을 통해 쿼리 성능을 저하시키며 클러스터 수준 작업을 느리게 만들 수 있습니다. 또한 사용 가능한 힙(인스턴스 RAM의 절반은 최대 32GB)에 비례하여 노드당 샤드 수를 유지하는 것이 좋습니다(Java 힙 GB당 25개 샤드). 이렇게 하면 도메인의 모든 데이터 노드에서 실제로 1,000개의 샤드가 제한됩니다.

결론

이 게시물에서는 OpenSearch Service를 사용하여 고가용성 도메인을 설정하는 다양한 팁과 요령을 배웠습니다. OpenSearch Service는 XNUMX개의 가용 영역에서 실행하여 OpenSearch Service의 성능과 가용성을 유지하는 데 도움이 됩니다.

OpenSearch 서비스의 다양한 특징과 기능에 초점을 맞춘 일련의 게시물을 기대해 주십시오. 이 게시물에 대한 피드백이 있으면 댓글 섹션에 제출하십시오. 이 게시물에 대해 질문이 있는 경우 다음에서 새 스레드를 시작하십시오. OpenSearch 서비스 포럼 또는 접촉 AWS 지원.


저자 소개

로힌 바르가바 Amazon OpenSearch Service 팀의 수석 제품 관리자입니다. AWS에서 그의 열정은 고객이 비즈니스 목표를 달성하기 위해 AWS 서비스의 올바른 조합을 찾도록 돕는 것입니다.

프라 샨트 아그라 왈 Amazon OpenSearch Service의 수석 검색 전문가 솔루션 아키텍트입니다. 그는 고객과 긴밀히 협력하여 워크로드를 클라우드로 마이그레이션하도록 돕고 기존 고객이 클러스터를 미세 조정하여 더 나은 성능을 달성하고 비용을 절감하도록 돕습니다. AWS에 합류하기 전에는 다양한 고객이 검색 및 로그 분석 사용 사례에 OpenSearch 및 Elasticsearch를 사용하도록 도왔습니다. 일하지 않을 때는 그가 여행하고 새로운 장소를 탐험하는 것을 볼 수 있습니다. 요컨대 먹기→여행→반복하는 것을 좋아한다.

spot_img

최신 인텔리전스

spot_img