OpenSearch 안정적 운영을 위한 모범 사례 가이드

8분 분량

콘텐츠 수준: 중급

해당 기사에서는 OpenSearch 공식 문서에서 제시하는 모범 사례들을 소개하고, 이러한 권장 사항을 따르지 않았을 때 발생할 수 있는 잠재적 문제점들을 상세히 설명합니다.

Opensearch 사용 모범사례

OpenSearch에서 성능과 안정성을 최적화하기 위한 주요 모범 사례는 다음과 같습니다:

인스턴스 유형: 워크로드에 적합한 인스턴스 유형을 선택하여 리소스 활용도를 최적화합니다.
샤드 전략: 데이터 크기와 쿼리 패턴에 맞는 적절한 샤드 수와 크기를 설정하여 성능을 향상시킵니다.
전용 마스터 노드: 클러스터 관리 작업을 위한 전용 마스터 노드를 구성하여 안정성을 높입니다.
다중 가용 영역 배포: 여러 가용 영역에 노드를 분산 배치하여 고가용성과 내결함성을 확보합니다.
하드웨어 리소스 : CPU, 메모리, 디스크 사용량을 지속적으로 모니터링하고 최적화하여 성능을 유지합니다.

인스턴스 유형

모범사례

일반적으로 적절한 인스턴스 유형 선택은 예상 스토리지 사용량과 필요한 샤드 개수를 결정한 뒤에 데이터 노드의 인스턴스 타입을 선택 해야합니다. 이 때도 고가용성을 위해 최소 2개, 권장 3개 이상 구성하는 것을 추천합니다. 아래의 단계를 거쳐서 스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어를 결정합니다.

[+] 인스턴스 유형 선택 및 테스트 https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/bp-instances.html

1단계 초기예상치 수립: 최소 3개 노드로 시작, split brain 상태 방지. 전용 프라이머리 노드 3개와 데이터 노드 2개 권장.
2단계 노드 별 스토리지 요구 사항 계산: 총 스토리지 요구사항을 노드 수로 나누어 노드별 스토리지 계산. (예: 184GiB/3 = 61GiB/node)
3단계 대표 테스트 수행: 계산된 샤드 수로 인덱스 추가, 실제 데이터로 테스트 수행, CloudWatch 지표 모니터링.
4단계 성공 또는 반복 : 성능 요구사항 충족 시 사용 준비. 미충족 시 인스턴스 유형 변경 또는 추가하여 재 테스트.

문제 사례

T 타입 인스턴스로 인한 프로덕션 클러스터 불안정 : 일반적으로 Opensearch 클러스터에 과부하가 지속되면 불안정해질 수 있으므로 프로덕션 클러스터에서는 T2 또는 t3.small 인스턴스를 사용하면 안 됩니다. 다만 트래픽이 작은 경우 T3.medium 이상을 사용하실 수 있습니다. [1]

[+]내 OpenSearch Service 노드가 충돌하는 이유는 무엇인가요?

https://repost.aws/ko/knowledge-center/opensearch-node-crash

샤드 전략

모범사례

OpenSearch 서비스에서 샤드는 도메인의 데이터 노드에 워크로드를 분산시키는 중요한 역할을 합니다. 인덱스는 기본 샤드와 복제본 샤드로 구성되며, 이를 적절히 구성하면 전반적인 도메인 성능을 향상시킬 수 있습니다. OpenSearch 서비스는 이러한 샤드를 데이터 노드에 자동으로 분산시키며, 기본 샤드와 복제본 샤드가 서로 다른 노드에 위치하도록 보장합니다. 복제본 샤드는 데이터 중복성과 추가적인 읽기 용량을 제공하므로, 최소 하나 이상의 복제본을 사용하는 것이 권장됩니다. 인덱싱 요청은 모든 샤드에 전송되는 반면, 검색 요청은 코디네이터 노드에 의해 기본 또는 복제본 샤드로 라우팅됩니다. 샤드의 수와 복제본 설정에 따라 인덱싱 및 검색 요청의 처리 방식이 달라지므로, 이를 고려하여 인덱스를 설계하는 것이 중요합니다.

[+] 샤드 및 데이터 노드 수 결정 https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/bp.html#bp-shard-count

샤드 크기

검색은 10-30GiB, 로그는 30-50GiB가 권장되며 최대 50GiB를 넘지 않아야 합니다.
소스-인덱스 비율은 보통 1:1.10이며 향후 성장을 고려 필요합니다.

샤드 수

데이터 노드 수의 짝수 배수로 설정하여 균등 분배가 되도록 하여 핫노드를 방지해야 합니다.
작은 데이터(5GiB 이하)는 단일 샤드를 사용해야 합니다.
대략적인 기본 샤드 수 = (소스 데이터 + 늘어날 공간) * (1 + 인덱싱 오버헤드)/원하는 샤드 크기

데이터 노드당 샤드

JVM 힙 메모리 GiB당 25개 이하의 샤드를 권장합니다.
노드당 최대 1,000개로 제한되며 32GiB 힙의 경우 800개가 한도 입니다.

샤드 대 CPU 비율

샤드당 1.5vCPU를 권장하며 8vCPUs의 경우 노드당 6개 이하가 적절합니다.
실제 워크로드 테스트 후 필요에 따라 조정이 필요합니다.

문제 사례

클러스터의 가용성 및 안정성: 샤드가 너무 크면 장애 복구가 어려워지고, 반대로 너무 많은 작은 샤드는 각각 CPU와 메모리 리소스를 소비하여 성능 저하와 메모리 부족 현상을 초래할 수 있습니다. 따라서 효율적인 운영을 위해서는 하드웨어에 과도한 부담을 주지 않으면서도 OpenSearch 서비스 인스턴스가 적절히 처리할 수 있는 최적의 샤드 크기를 유지해야 합니다.

[+] 샤드 수 선택

https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/bp-sharding.html

블루/그린 배포의 중단 : 클러스터에 샤드가 너무 많거나 샤드 크기가 모범사례를 벗어나는 경우 블루/그린 배포 중단의 원인이 될 수 있습니다. 샤드 크기를 10GiB에서 50GiB 사이로 유지하는 것이 가장 좋습니다.

GET _cat/shards?v #샤드의 크기를 확인

[+] Amazon OpenSearch Service 클러스터를 위한 블루/그린 배포란 무엇인가요?

https://repost.aws/ko/knowledge-center/opensearch-configuration-change

복제본 샤드의 전략으로 인한 Yellow 상태 발생 : Opensearch의 Replica 샤드는 Primary 샤드에 문제가 생기는 경우 사용 가능해야 하는 상황이기 떄문에 기본적으로 Primary 샤드와 같은 노드에 할당될 수 없습니다. 또한, 하나의 Primary 샤드에서 생성된 Replica 샤드들의 경우에도 같은 노드에 할당될 수 없습니다. 만일 노드의 수보다 많은 복제본 샤드를 설정한 경우 할당되지 못한 복제본 샤드로 인해 Yellow상태가 발생할 수 있습니다. 노드를 추가하거나 복제본 샤드 전략을 바꿔서 해결할수 있습니다.

[+] OpenSearch Service 클러스터에서 할당되지 않은 샤드 문제를 해결하려면 어떻게 해야 합니까? - 잘못 구성된 복제본 수

https://repost.aws/ko/knowledge-center/opensearch-unassigned-shards

마스터 노드 사용

모범사례

[+] Amazon OpenSearch Service의 전용 마스터 노드

https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/managedomains-dedicatedmasternodes.html

Amazon OpenSearch Service는 클러스터 안정성 향상을 위해 전용 마스터 노드를 제공하며, 이는 데이터 처리 없이 순수하게 클러스터 관리 작업만을 수행합니다. 프로덕션 환경에서는 3개의 전용 마스터 노드를 사용하는 것이 권장되며, 이는 다중 AZ 구성(대기 모드 포함)뿐만 아니라 단일 AZ 또는 대기 모드가 없는 다중 AZ 환경에서도 동일하게 적용됩니다. 전용 마스터 노드는 시간당 비용이 발생하지만, 클러스터의 안정적인 운영을 위해서는 필수적인 요소입니다.

전용 프라이머리 노드 지표를 모니터링하여 대규모 인스턴스 유형을 사용해야 하는지를 확인합니다.

인스턴스 수	마스터 노드 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

문제 사례

마스터 노드 미사용시 노드 충돌 문제 발생 가능 : 전용 마스터 노드의 사용은 클러스터의 안정성을 크게 향상시킵니다. 이는 노드 간 작업 부하를 효과적으로 분산시켜 전체 시스템의 균형을 유지하고, 결과적으로 노드 충돌의 위험을 현저히 감소시킵니다. 따라서 마스터 노드를 활용함으로써 전반적인 클러스터 운영의 안정성과 신뢰성을 높일 수 있습니다.

[+]내 OpenSearch Service 노드가 충돌하는 이유는 무엇인가요?

https://repost.aws/ko/knowledge-center/opensearch-node-crash

여러 가용영역에 배포

모범사례

Amazon OpenSearch Service는 데이터 손실 방지와 가동 중지 시간 최소화를 위해 다중 가용 영역(Multi-AZ) 배포를 제공합니다. 특히 'Multi-AZ with Standby' 구성이 권장되며, 이는 2개의 활성 영역과 1개의 대기 영역으로 구성되어 인덱스당 2개의 복제 샤드를 포함합니다. 이러한 3개의 가용 영역 구성은 단일 가용 영역 장애 시의 영향을 최소화할 수 있으며, 2개 가용 영역 구성에서 발생할 수 있는 50% 용량 손실 위험을 크게 줄일 수 있습니다. 또한 잠재적인 데이터 손실을 방지하려면 각 인덱스에 복제본이 하나 이상 있어야 합니다.[2]

문제 사례

복제본 샤드가 구성 설정이 되어있지 않은 경우 : 복제본 샤드가 구성되어있지 않은 경우 기본적으로 Yellow 상태가됩니다. 또한 노드 충돌 에는 해당 노드에 있던 프라이머리 샤드의 데이터에 접근이 불가능해지고 데이터 손실이 발생할 수 있습니다. 또한 손상된 샤드를 복구할수있는 복제본 샤드가 없기 때문에 RED 클러스터 상태가 발생할수있습니다. 만일 복제본 노드가 있는 경우, 노드 충돌이 발생하더라도 복제본 샤드가 기본 샤드로 복구되어 클러스터가 복구됩니다.[3]

[+] Amazon OpenSearch Service 클러스터가 빨간색 또는 노란색 상태인 이유는 무엇입니까?

https://repost.aws/ko/knowledge-center/opensearch-red-yellow-status

Split Brain 발생 ( 클러스터 내 통신이 중단되어 마스터 노드가 두 개 이상 존재하게 되는 상황 ): 해당 문제를 OpenSearch 문제를 방지하기 위해 최소 세 개의 노드를 사용하는 것이 좋습니다.

[+] 아마존 OpenSearch 서비스 문제 해결 - 읽기 전용 상태의 클러스터

https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/handling-errors.html#troubleshooting-read-only-cluster

하드웨어 사용량

OpenSearch Service의 효율적인 운영을 위해서는 적절한 CPU 사용률 관리가 중요합니다. 지속적으로 높은 CPU 사용률은 클러스터 성능 저하와 타임아웃 요청을 초래할 수 있습니다. 또한, 클러스터 노드의 Java 힙 메모리 사용량을 주의 깊게 모니터링해야 합니다. JVM 메모리 사용량이 75%에 도달하면 가비지 콜렉션이 시작되며, 100%에 도달하면 JVM이 종료되고 OutOfMemory 오류로 재시작됩니다. 따라서, 안정적인 서비스 운영을 위해 CPU와 JVM 메모리 리소스를 적절히 관리하고 모니터링하는 것이 필수적입니다.

모범사례

[+] 아마존 OpenSearch 서비스 문제 해결- 지속해서 과도한 처리 로드에서 복구

https://docs.aws.amazon.com/ko_kr/opensearch-service/latest/developerguide/handling-errors.html#handling-errors-red-cluster-status-heavy-processing-load

CPUUtilization : 도메인의 CPU를 사용하여 워크로드를 실행합니다. 일반적으로 데이터 노드의 평균 CPU 사용률을 60%로 목표로 하고, 최고치는 80%이며, 100%로 약간의 급증을 견뎌야 합니다. 가용성 영역이 두 개인 경우 각 영역에서 트래픽의 50%를 처리합니다. 한개의 가용 영역을 사용할 수 없게 되면 다른 영역에서 해당 트래픽을 모두 가져가서 CPU 사용률이 두 배로 증가합니다.
JVM MemoryPressure : 클러스터의 모든 데이터 노드에 사용되는 Java 힙의 비율을 지정합니다. 어느 경우든 전체 가비지 컬렉션 중에 가비지 컬렉터가 회수할 수 있는 양보다 메모리 사용량이 계속 증가하면 메모리 부족 오류와 함께 OpenSearch 충돌이 발생합니다. 모든 인스턴스 유형에서 사용량을 80% 미만으로 유지하는 것이 좋습니다.

문제 사례

높은 CPU 사용률로 인한 타임아웃 발생 : OpenSearch Service가 작업을 수행할 수 있는 충분한 리소스를 확보하도록 CPU 사용률을 유지하는 것이 가장 좋습니다. 높은 CPU 사용률로 일관되게 작동하는 클러스터는 클러스터 성능을 저하시킬 수 있습니다. 클러스터에 과부하가 걸리면 OpenSearch Service가 응답을 중지하여 타임아웃 요청이 발생합니다.

[+] Amazon OpenSearch Service 클러스터의 높은 CPU 사용률 문제를 해결하려면 어떻게 해야 합니까?

https://repost.aws/ko/knowledge-center/opensearch-troubleshoot-high-cpu