Amazon ES 도메인 크기 조정 - Amazon Elasticsearch Service

문서의 영문과 번역 사이에 충돌이 있는 경우에는 영문 버전을 따릅니다. 번역 버전은 기계 번역을 사용하여 제공합니다.

Amazon ES 도메인 크기 조정

Amazon ES 도메인 크기를 조정하는 완벽한 방법은 존재하지 않지만 스토리지 요구 사항, 서비스 및 Elasticsearch 자체에 대해 이해한 다음 시작하면 하드웨어 요구 사항에 빈틈 없이 대응하는 초기 예상치를 수립할 수 있습니다. 이러한 예상치는 도메인 크기 조정의 가장 중요한 측면인 주요 워크로드로 도메인 크기 조정 테스트와 해당 성능 모니터링을 위한 유용한 시작점을 제공할 수 있습니다.

스토리지 요구 사항 계산

대부분의 Elasticsearch 워크로드는 두 가지 범주 중 하나로 분류됩니다.

  • 오래 지속되는 지수: 데이터를 하나 이상 처리하는 코드를 작성합니다. Elasticsearch 지수를 확인한 후 소스 데이터가 변경됨에 따라 주기적으로 해당 인덱스를 업데이트합니다. 몇 가지 일반적인 예로 웹 사이트, 문서 및 전자 상거래 검색이 있습니다.

  • 롤링 지수: 데이터는 2주 동안 유지되는 일일 지수 집합과 같은 인덱싱 기간과 보존 기간으로 임시 지수의 집합으로 지속적으로 흐릅니다. 몇 가지 일반적인 예로 로그 분석, 시계열 처리 및 클릭스트림 분석이 있습니다.

장기 인덱스 워크로드의 경우 디스크에 있는 소스 데이터를 검사하여 스토리지 공간이 어느 정도 소비되었는지 쉽게 확인할 수 있습니다. 데이터를 여러 소스에서 가져온 경우 소스를 모두 추가하면 됩니다.

롤링 인덱스의 경우 주요 기간 동안 생성된 데이터의 양에 보존 기간을 곱할 수 있습니다. 예를 들어, 시간당 200MiB의 로그 데이터를 생성하면 하루에 4.7GiB가 생성되고 보존 기간이 2주이면 이 기간 동안 66GiB의 데이터가 생성됩니다.

그러나 소스 데이터의 크기는 스토리지 요구 사항의 한 측면일 뿐입니다. 다음 사항도 고려해야 합니다.

  1. 복제본 개수 각 복제본은 인덱스의 전체 복제본이며 동일한 양의 디스크 공간이 필요합니다. 기본적으로 각 Elasticsearch 인덱스에는 한 개의 복제본이 포함됩니다. 데이터 손실을 방지하기 위해 하나 이상을 포함하는 것이 좋습니다. 또한 복제본은 검색 성능을 향상시켜 주므로 읽기 워크로드가 과중한 경우 여러 개를 사용할 수 있습니다.

  2. Elasticsearch 인덱싱 오버헤드: 인덱스의 디스크 크기는 다양하지만 소스 데이터보다 10% 더 큽니다. 데이터 인덱싱 후 _cat/indices?v API 및 pri.store.size 값을 사용하여 정확한 오버헤드를 계산할 수 있습니다. _cat/allocation?v 유용한 요약도 제공합니다.

  3. 운영 체제 예약 공간: 기본적으로 Linux는 root 중요 프로세스, 시스템 복구 및 디스크 조각화 문제에 대한 보호를 위한 사용자.

  4. Amazon ES 오버헤드: Amazon ES는 세그먼트 병합, 로그 및 기타 내부 작업을 위해 각 인스턴스마다 스토리지 공간 20%(최대 20GiB)를 예약해 둡니다.

    이 20GiB의 최대값 때문에 예약된 총 공간은 도메인의 인스턴스 수에 따라 크게 달라질 수 있습니다. 예를 들어, 도메인에 3개의 m4.xlarge.elasticsearch 인스턴스가 포함될 수 있으며 각 스토리지 공간이 500GiB인 경우 총 공간은 1.46TiB입니다. 이 경우 예약된 총 공간은 60GiB에 불과합니다. 다른 도메인에 10개의 m3.medium.elasticsearch 인스턴스가 포함될 수 있으며 각 스토리지 공간이 100GiB인 경우 총 공간은 0.98TiB입니다. 이 경우 첫 번째 도메인의 전체 스토리지 공간이 50% 더 크더라도, 두 번째 도메인의 예약된 총 공간은 200GiB입니다.

    다음 공식에서는 노드 장애 및 가용 영역 중단의 영향을 최소화하는 데 도움이 되는 추가 여유 공간이 포함된 오버헤드에 대해 “최악의 경우” 추정치를 적용합니다.

요약하면 지정된 기간에 66GiB의 데이터가 있고 한 개의 복제본이 필요한 경우 최소 스토리지 요구 사항은 66 * 2 * 1.1 / 0.95 / 0.8 = 191GiB에 근사합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.

소스 데이터 * (1 + 복제본 수) * (1 + 인덱싱 오버헤드) / (1 - Linux 예약된 공간) / (1 - Amazon ES 오버헤드) = 최소 스토리지 요구 사항

또는 아래와 같이 약식 버전을 사용할 수도 있습니다.

소스 데이터 * (1 + 복제본 수) * 1.45 = 최소 스토리지 요구 사항

부족한 스토리지 공간은 클러스터를 불안정하게 만드는 가장 일반적인 원인 중 하나이므로 인스턴스 유형, 인스턴스 수 및 스토리지 볼륨을 선택할 때 개수를 대조 확인해야 합니다.

기타 스토리지 고려 사항은 다음과 같습니다.

샤드 수 선택

스토리지 요구 사항을 이해했으면 인덱싱 전략을 조사할 수 있습니다. 각 Elasticsearch 인덱스는 몇 개의 샤드로 분할됩니다. 기존 인덱스에 대한 기본 샤드 수는 쉽게 변경할 수 없으므로, 첫 번째 문서를 인덱싱하기 전에 샤드 수를 결정해야 합니다.

샤드 수를 선택하는 가장 중요한 목적은 클러스터의 모든 데이터 노드에서 인덱스를 균등하게 분산시키는 것입니다. 하지만 이러한 샤드는 너무 크거나 너무 많아서는 안 됩니다. 경험상 샤드 크기는 10–50GiB 사이로 유지하는 것이 좋습니다. 크기가 큰 샤드는 Elasticsearch 오류 발생 시 복구가 어렵기는 합니다. 하지만 각 샤드는 일정량의 CPU와 메모리를 사용하기 때문에 크기가 작은 샤드가 너무 많이 있으면 성능 문제와 메모리 부족 오류가 발생할 수 있습니다. 즉, 샤드는 기본 Amazon ES 인스턴스가 처리할 수 있을 정도로 작아야 하지만 너무 작아 하드웨어에 불필요한 부담을 주어서도 안 됩니다.

예를 들어, 66GiB의 데이터가 있다고 가정해 봅니다. 시간이 지남에 따라 그 수가 늘어날 것으로 예상하지 않으며 샤드를 각각 30GiB 정도로 유지하려고 합니다. 따라서 샤드 수는 약 66 * 1.1/30 = 3개가 되어야 합니다. 이 계산은 다음과 같이 일반화할 수 있습니다.

(소스 데이터 + 늘어날 공간) * (1 + 인덱싱 오버헤드) / 원하는 샤드 크기 = 대략적인 기본 샤드 수

이 수식은 시간이 지남에 따라 성장 보정에 유용합니다. 동일한 67GiB의 데이터가 내년에 4배가 될 것으로 예상한다면 대략적인 샤드 수는 (66 + 198) * 1.1/30 = 10개가 됩니다. 하지만 아직 추가로 198GiB의 데이터가 필요하지는 않습니다. 향후 이 준비 작업을 통해 현재 엄청난 양의 CPU와 메모리를 소비하는 너무 작은 크기의 샤드를 생성하지 않는지 확인하십시오. 이 경우 샤드당 66 * 1.1/10개 샤드 = 7.26GiB가 필요해 추가 리소스를 소비하지만 거의 권장 크기 범위에 미치지 못합니다. 샤드가 6개인 중간 정도의 접근 방식을 고려할 수 있으며, 이 경우 현재 12GiB 샤드, 향후 48GiB 샤드가 남게 됩니다. 그런 다음 다시 샤드 3개로 시작하여 샤드가 50GiB를 초과하면 데이터를 다시 인덱싱하는 것이 좋습니다.

훨씬 덜 일반적인 문제는 노드당 샤드 수 제한과 관련이 있습니다. 샤드의 크기를 적절하게 지정하면 일반적으로 디스크 공간이 먼저 소진되어 이 제한이 발생하는 경우가 거의 없습니다. 예를 들어 m5.large.elasticsearch 인스턴스의 최대 디스크 크기는 512GiB입니다. 디스크 사용량 80% 미만으로 유지되고 20gib에서 원하는 크기의 shards를 사용하면 약 20개의 shards를 수용할 수 있습니다. Elasticsearch 7.x 그 이상의 한계는 1,000 노드당 덮개, 조절 가능 cluster.max_shards_per_node 설정.

샤드의 크기를 적절하게 지정하면 이 제한을 초과하는 경우가 거의 없지만, Java 힙의 각 GiB에 대한 샤드 수를 고려해 볼 수도 있습니다. 주어진 노드에서 Java 힙의 GiB당 샤드 수는 20개 이하입니다. 예를 들어 m5.large.elasticsearch 인스턴스의 힙은 4GiB이므로 각 노드의 샤드 수는 80개 이하여야 합니다. 샤드 수가 이와 같을 때 각 샤드의 크기는 대략 5GiB로 권장 사항보다 훨씬 작습니다.

인스턴스 유형 선택 및 테스트

스토리지 요구 사항을 계산하고 필요한 샤드 수를 선택한 후에는 하드웨어 결정을 시작할 수 있습니다. 하드웨어 요구 사항은 워크로드에 따라 크게 달라지기는 하지만 몇 가지 기본적인 권장 사항을 제공하겠습니다.

일반적으로 각 인스턴스 유형에 대한 스토리지 한도는 가벼운 워크로드에 필요한 CPU와 메모리 양에 매핑됩니다. 예를 들어, m4.large.elasticsearch 인스턴스는 최대 512GiB의 EBS 볼륨 크기, 2개의 vCPU 코어 및 8GiB의 메모리를 사용합니다. 클러스터에 샤드가 많이 있거나, 집계를 과도하게 수행하거나, 문서를 자주 업데이트하거나, 쿼리를 많이 처리하는 경우 해당 리소스가 충분하지 않을 수 있습니다. 클러스터가 이러한 범주 중 하나에 속한다고 생각되면 각 100GiB의 스토리지 요구 사항에 맞게 2개의 vCPU 코어와 8GiB의 메모리에 근접한 구성으로 시작해 보십시오.

작은 정보

각 인스턴스 유형에 할당되는 하드웨어 리소스 요약은 Amazon Elasticsearch Service 요금을 참조하십시오.

하지만 이러한 리소스도 부족할 수 있습니다. 일부 Elasticsearch 사용자는 자신의 요구 사항을 충족시키기 위해 이와 같은 리소스가 여러 번 필요했다고 보고했습니다. 워크로드에 적합한 올바른 하드웨어를 찾는다는 것은 초기 예상치를 치밀하게 작성하고, 주요 워크로드를 통해 테스트한 후 조정하고, 다시 테스트하는 것을 의미합니다.

  1. 시작할 때 브레인 분할 등 잠재적인 Elasticsearch 문제를 피하기 위해 최소 3개의 노드를 선택하는 것이 좋습니다. 3개의 전용 마스터 노드가 있는 경우 복제를 위해 최소 2개의 데이터 노드를 사용하는 것이 좋습니다.

  2. 스토리지 요구 사항이 184GiB이고 권장되는 최소 노드 수가 3개인 경우 184/3 = 61GiB 수식을 사용하여 각 노드에 필요한 스토리지 양을 찾으십시오. 이 예제에서는3개의 m5.large.elasticsearch 인스턴스를 선택했고 각 인스턴스는 90GiB의 EBS 스토리지 볼륨을 사용하므로 시간이 지나면서 늘어나는 요구 사항에 대한 안전망과 공간을 확보할 수 있습니다. 이 구성은 6개의 vCPU 코어와 24GiB의 메모리를 제공하므로 더 가벼운 워크로드에 적합합니다.

    보다 실질적인 예로 14TiB(14,336GiB)의 스토리지 요구 사항과 과도한 워크로드를 고려해 보겠습니다. 이 경우 2 * 144 = 288개의 vCPU 코어 및 8 * 144 = 1152GiB의 메모리로 시작하도록 선택할 수 있습니다. 이러한 수치는 약 18개의 i3.4xlarge.elasticsearch 인스턴스에 해당합니다. 이렇게 빠른 로컬 스토리지가 필요 없는 경우에는 각각 1TiB의 EBS 스토리지 볼륨을 사용하여 r5.4xlarge.elasticsearch 인스턴스 18개로 테스트할 수도 있습니다.

    귀하의 클러스터가 수백 테라바이트의 데이터를 포함한다면 Amazon Elasticsearch Service를 위한 페타바이트 규모 단원을 참조하십시오.

  3. 클러스터를 구성한 후에는 앞서 계산한 샤드 수를 사용하여 인덱스를 추가하고, 실제 데이터 세트를 사용하여 주요 클라이언트 테스트를 수행하고, CloudWatch 지표를 모니터링하여 클러스터가 워크로드를 처리하는 방식을 확인할 수 있습니다.

  4. 성능이 요구 사항을 충족하고 테스트에 성공했으며 CloudWatch 지표가 정상이면 클러스터 사용 준비를 마친 것입니다. 반드시 CloudWatch 경보를 설정하여 비정상적인 리소스가 사용되는지를 검사하십시오.

    성능이 기대 이하이고 테스트에 실패했거나 CPUUtilization 또는 JVMMemoryPressure가 높은 경우 다른 인스턴스 유형을 선택(또는 인스턴스 추가)하여 계속 테스트해 보십시오. 인스턴스를 추가함에 따라 Elasticsearch에서는 자동으로 클러스터 전체에 샤드 배포를 다시 조정합니다.

    성능이 떨어진 클러스터에서 부족 용량을 측정하는 것보다 성능이 높은 클러스터에서 초과 용량을 측정하는 것이 더 쉬우므로 필요한 것보다 더 큰 클러스터로 시작하는 것이 좋습니다. 그런 다음, 추가 리소스가 있는 효율적인 클러스터를 테스트하고 축소하여 활동이 늘어난 기간 동안 안정적인 운영을 보장하십시오.

프로덕션 클러스터나 상태가 복잡한 클러스터는 전용 마스터 노드의 이점을 활용하여 성능과 클러스터의 안정성을 향상시킵니다.