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

크기 조정

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

스토리지

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

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

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

이러한 오버헤드와 예약 방식을 모두 고려하면 소스의 실제 원시 데이터를 기반으로 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 볼륨을 사용하는 것이 좋습니다. Amazon EBS gp3 볼륨을 사용하면 스토리지 용량과 관계없이 성능을 프로비저닝할 수 있습니다. 또한 Amazon EBS gp3 볼륨은 OpenSearch Service에서 기존 gp2 볼륨보다 GB당 9.6% 저렴한 비용으로 더 나은 기준 성능을 제공합니다. gp3를 사용하면 R5, R6g, M5 및 M6g 인스턴스 패밀리에서 더 밀도 높은 스토리지를 얻을 수 있으므로 비용을 추가로 최적화하는 데 도움이 될 수 있습니다. 지원되는 할당량까지 EBS 볼륨을 생성할 수 있습니다. 자세한 내용은 Amazon OpenSearch Service quotas를 참조하세요.

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

노드 및 인스턴스 유형 수

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

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

인덱싱 전략 및 샤드 수 결정

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

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

CPU 사용률

다음 단계는 워크로드에 필요한 CPU 수를 식별하는 것입니다. 처음에는 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 이상 세대는 이전 세대 인스턴스에 비해 저렴한 비용으로 향상된 성능을 제공하도록 빌드되었으므로 해당 버전을 권장합니다.

로그 분석 및 검색 사용 사례에 대해 수행된 다양한 테스트를 기반으로 다음을 권장합니다.

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

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

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