크기 조정

크기를 조정하면 대상 환경에 적합한 인스턴스 유형, 데이터 노드 수 및 스토리지 요구 사항을 결정하는 데 도움이 됩니다. 먼저 스토리지별로 크기를 조정한 다음 CPUs 것이 좋습니다. 이미 Elasticsearch 또는 OpenSearch를 사용하고 있는 경우 크기 조정은 일반적으로 동일하게 유지됩니다. 그러나 현재 환경과 동일한 인스턴스 유형을 식별해야 합니다. 적절한 크기를 결정하는 데 도움이 되도록 다음 지침을 사용하는 것이 좋습니다.

스토리지

클러스터 크기 조정은 스토리지 요구 사항을 정의하는 것부터 시작합니다. 클러스터에 필요한 원시 스토리지를 식별합니다. 이는 소스 시스템에서 생성된 데이터(예: 로그를 생성하는 서버 또는 제품 카탈로그 원시 크기)를 평가하여 결정됩니다. 원시 데이터의 양을 식별한 후 다음 공식을 사용하여 스토리지 요구 사항을 계산합니다. 그런 다음 결과를 PoC의 시작점으로 사용할 수 있습니다.

storage needed = (daily source data in bytes × 1.45) (number_of_replicas + 1) × number of days retained

공식은 다음을 고려합니다.

• 인덱스의 온디스크 크기는 다양하지만 소스 데이터보다 10% 더 큰 경우가 많습니다.

• Linux는 시스템 복구와 디스크 조각 모음 문제를 방지하기 위해 운영 체제 오버헤드 5%를 예약합니다.

• OpenSearch는 세그먼트 병합, 로그 및 기타 내부 작업을 위해 각 인스턴스의 스토리지 공간의 20%를 예약합니다.

• 노드 장애 및 가용 영역 중단의 영향을 최소화하려면 10% 추가 스토리지를 유지하는 것이 좋습니다.

이러한 오버헤드와 예약을 결합하려면 소스의 실제 원시 데이터를 기반으로 45%의 추가 공간이 필요합니다. 따라서 소스 데이터에 1.45를 곱합니다. 그런 다음이 값에 데이터 복사본 수를 곱합니다(예: 기본 복제본 1개와 사용할 복제본 수). 복제본 수는 복원력 및 처리량 요구 사항에 따라 달라집니다. 평균 사용 사례의 경우 기본 복제본 하나와 복제본 하나로 시작합니다. 마지막으로 핫 스토리지 계층에 데이터를 보존하려는 일수를 곱합니다.

Amazon OpenSearch Service는 핫, 웜 및 콜드 스토리지 계층을 제공합니다. 웜 스토리지 계층은 UltraWarm 스토리지를 사용합니다. UltraWarm은 대량의 읽기 전용 데이터를 Amazon OpenSearch Service에 저장하는 비용 효율적인 방법을 제공합니다. 표준 데이터 노드는 각 노드에 연결된 인스턴스 스토어 또는 Amazon Elastic Block Store(Amazon EBS) 볼륨의 형태를 취하는 핫 스토리지를 사용합니다. 핫 스토리지의 새로운 데이터 인덱싱 및 검색 성능이 가장 빠릅니다. UltraWarm 노드는 Amazon Simple Storage Service(Amazon S3)를 스토리지 및 정교한 캐싱 솔루션으로 사용하여 성능을 개선합니다. 적극적으로 쓰지 않거나 쿼리 빈도가 낮고 성능 요구 사항이 동일하지 않은 인덱스의 경우 UltraWarm은 데이터 GiB당 비용을 크게 절감합니다. UltraWarm에 대한 자세한 내용은 AWS 설명서를 참조하십시오.

OpenSearch Service 도메인을 생성하고 핫 스토리지를 사용하는 경우 EBS 볼륨 크기를 정의해야 할 수 있습니다. 데이터 노드에 대한 인스턴스 유형 선택에 따라 달라집니다. 동일한 스토리지 요구 사항 공식을 사용하여 Amazon EBS 지원 인스턴스의 볼륨 크기를 결정할 수 있습니다. 최신 세대 T3, R5, R6G, M5, M5g, C5 및 C6g 인스턴스 패밀리에는 gp3 볼륨을 사용하는 것이 좋습니다. C6g Amazon EBS gp3 볼륨을 사용하면 스토리지 용량과 관계없이 성능을 프로비저닝할 수 있습니다. 또한 Amazon EBS gp3 볼륨은 OpenSearch Service의 기존 gp2 볼륨보다 GB당 9.6% 저렴한 비용으로 더 나은 기준 성능을 제공합니다. gp3를 사용하면 R5, R6g, M5 및 M6g 인스턴스 패밀리에서 더 밀집된 스토리지를 얻을 수 있으므로 비용을 추가로 최적화하는 데 도움이 될 수 있습니다. 지원되는 할당량까지 EBS 볼륨을 생성할 수 있습니다. 할당량에 대한 자세한 내용은 Amazon OpenSearch Service 할당량을 참조하세요.

i3 및 r6gd 인스턴스와 같이 NVM Express(NVMe) 드라이브가 있는 데이터 노드의 경우 볼륨 크기가 고정되므로 EBS 볼륨은 옵션이 아닙니다.

노드 및 인스턴스 유형 수

노드 수는 워크로드를 운영하는 데 필요한 CPUs 수를 기반으로 합니다. CPUs 합니다. OpenSearch의 인덱스는 여러 샤드로 구성됩니다. 인덱스를 생성할 때 인덱스의 샤드 수를 지정합니다. 따라서 다음을 수행해야 합니다.

1. 도메인에 저장하려는 총 샤드 수를 계산합니다.

2. CPU를 결정합니다.

3. 필요한 수의 CPUs과 개수를 찾습니다.

이는 일반적으로 시작점입니다. 테스트를 실행하여 예상 크기가 기능 및 비기능 요구 사항을 충족하는지 확인합니다.

인덱싱 전략 및 샤드 수 결정

스토리지 요구 사항을 파악한 후 필요한 인덱스 수를 결정하고 각 인덱스의 샤드 수를 식별할 수 있습니다. 일반적으로 검색 사용 사례에는 하나 이상의 인덱스가 있으며, 각 인덱스는 검색 가능한 개체 또는 카탈로그를 나타냅니다. 로그 분석 사용 사례의 경우 인덱스는 일별 또는 주별 로그 파일을 나타낼 수 있습니다. 인덱스 수를 결정한 후 다음 스케일 지침으로 시작하여 적절한 샤드 수를 결정합니다.

• 검색 사용 사례 - 샤드당 10~30GB

• 로그 분석 사용 사례 - 샤드당 50GB

단일 인덱스의 총 데이터 볼륨을 사용 사례에서 목표로 하는 샤드 크기로 나눌 수 있습니다. 이렇게 하면 인덱스의 샤드 수가 제공됩니다. 총 샤드 수를 식별하면 워크로드에 적합한 인스턴스 유형을 찾는 데 도움이 됩니다. 샤드가 너무 크거나 너무 많으면 안 됩니다. 큰 샤드는 OpenSearch가 장애로부터 복구하는 것을 어렵게 만들 수 있지만, 각 샤드는 일정량의 CPU와 메모리를 사용하기 때문에 작은 샤드가 너무 많으면 성능 문제와 out-of-memory 오류가 발생할 수 있습니다. 또한 데이터 노드에 대한 샤드 할당의 불균형으로 인해 왜곡이 발생할 수 있습니다. 여러 샤드가 있는 인덱스가 있는 경우, 샤드 수를 데이터 노드 수의 짝수 배수로 설정합니다. 이렇게 하면 샤드가 데이터 노드 간에 고르게 분산되며, 핫 노드를 방지할 수 있습니다. 예를 들어, 12개의 기본 샤드가 있는 경우 데이터 노드 수는 2, 3, 4, 6 또는 12여야 합니다. 단, 샤드 수는 샤드 크기에 부차적입니다. 5GiB의 데이터가 있는 경우에도 단일 샤드를 사용해야 합니다. 가용 영역에서 복제본 샤드 수를 균등하게 분산하면 복원력을 개선하는 데도 도움이 됩니다.

CPU 사용률

다음 단계는 워크로드에 필요한 CPUs 수를 식별하는 것입니다. CPU 수를 활성 샤드의 1.5배로 시작하는 것이 좋습니다. 활성 샤드는 상당한 쓰기를 수신하는 인덱스의 샤드입니다. 기본 샤드 수를 사용하여 상당한 읽기 또는 쓰기 요청을 수신하는 인덱스의 활성 샤드를 결정합니다. 로그 분석의 경우 현재 인덱스만 일반적으로 활성화됩니다. 검색 사용 사례의 경우 모든 기본 샤드는 활성 샤드로 간주됩니다. 활성 샤드당 1.5 CPU를 권장하지만 워크로드에 따라 크게 다릅니다. CPU 사용률을 테스트 및 모니터링하고 그에 따라 조정해야 합니다.

CPU 사용률을 유지하는 모범 사례는 OpenSearch 서비스 도메인에 작업을 수행하기에 충분한 리소스가 있는지 확인하는 것입니다. CPU 사용률이 지속적으로 높은 클러스터는 클러스터 안정성을 저하시킬 수 있습니다. 클러스터가 오버로드되면 OpenSearch Service는 수신 요청을 차단하여 요청 거부를 초래합니다. 이는 도메인이 실패하지 않도록 보호하기 위한 것입니다. CPU 사용량에 대한 일반 지침은 평균 약 60%, 최대 CPU 사용률 80%입니다. 100%의 간헐적 스파이크는 여전히 허용 가능하며 조정이나 재구성이 필요하지 않을 수 있습니다.

인스턴스 타입

Amazon OpenSearch Service는 다양한 인스턴스 유형을 제공합니다. 사용 사례에 가장 적합한 인스턴스 유형을 선택할 수 있습니다. Amazon OpenSearch Service는 R, C, M, T 및 I 인스턴스 패밀리를 지원합니다. 메모리 최적화, 컴퓨팅 최적화 또는 혼합 등 워크로드를 기반으로 인스턴스 패밀리를 선택합니다. 인스턴스 패밀리를 식별한 후 최신 세대 인스턴스 유형을 선택합니다. 일반적으로 Graviton 이상 세대를 사용하는 것이 좋습니다. 이전 세대 인스턴스에 비해 저렴한 비용으로 향상된 성능을 제공하도록 구축되었기 때문입니다.

로그 분석 및 검색 사용 사례에 대해 수행된 다양한 테스트를 기반으로 다음을 수행하는 것이 좋습니다.

• 로그 분석 사용 사례의 경우 일반적인 지침은 데이터 노드용 Graviton 인스턴스의 R 패밀리로 시작하는 것입니다. 테스트를 실행하고, 요구 사항에 대한 벤치마크를 설정하고, 워크로드에 적합한 인스턴스 크기를 식별하는 것이 좋습니다.

• 검색 사용 사례의 경우 데이터 노드에 R 및 C 패밀리 Graviton 인스턴스를 사용하는 것이 좋습니다. 검색 사용 사례에는 로그 분석 사용 사례에 비해 더 많은 CPU가 필요하기 때문입니다. 소규모 워크로드의 경우 검색 및 로그 모두에 M 패밀리 Graviton 인스턴스를 사용할 수 있습니다. I 패밀리 인스턴스는 NVMe 드라이브를 제공하며 빠른 인덱싱 및 지연 시간이 짧은 검색 요구 사항이 있는 고객이 사용합니다.

클러스터는 데이터 노드와 클러스터 관리자 노드로 구성됩니다. 전용 프라이머리 노드가 검색 및 쿼리 요청을 처리하지 않더라도 전용 프라이머리 노드의 크기는 자신이 관리할 수 있는 인스턴스, 인덱스 및 샤드의 수와 밀접한 관련이 있습니다. AWS 설명서는 최소 전용 클러스터 관리자 인스턴스 유형을 권장하는 매트릭스를 제공합니다.

AWS는 AWS Graviton2 프로세서로 구동되는 Amazon OpenSearch Service 버전 7.9 이상에 범용(M6g), 컴퓨팅 최적화(C6g) 및 메모리 최적화(R6g 및 R6gd)를 제공합니다. 이러한 인스턴스는 Amazon에서 설계한 사용자 지정 실리콘을 사용하여 빌드됩니다. Amazon에서 설계한 하드웨어 및 소프트웨어 혁신으로, 격리된 멀티 테넌시, 프라이빗 네트워킹 및 빠른 로컬 스토리지를 통해 효율적이고 유연하며 안전한 클라우드 서비스를 제공할 수 있습니다.

Graviton2 인스턴스 패밀리는 OpenSearch Service(M5, C5, R5)에서 사용 가능한 이전 세대 Intel 기반 인스턴스에 비해 인덱싱 지연 시간을 최대 50% 줄이고 쿼리 성능을 최대 30% 개선합니다.