Amazon Elasticsearch Service
개발자 가이드 (API 버전 2015-01-01)

Amazon ES 도메인 크기 조정

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

스토리지 요구 사항 계산

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

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

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

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

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

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

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

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

  3. 운영 체제 예약 공간: 기본적으로 Linux는 중요한 프로세스와 시스템 복구를 위해, 그리고 디스크 단편화 문제를 방지할 목적으로 root 사용자가 사용할 수 있도록 파일 시스템의 5%를 예약합니다.

  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입니다.

    다음 수식에서 인스턴스당 100GiB 미만의 스토리지 공간을 사용하는 도메인에 대해 정확한 오버헤드를 측정하는 "최악의 경우" 예상치를 적용하여 더 큰 인스턴스에 대해 초과 할당합니다.

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

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

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

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

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

참고

최소 스토리지 요구 사항이 1PB를 초과하는 경우 Amazon Elasticsearch Service를 위한 페타바이트 규모 단원을 참조하십시오.

샤드 수 선택

스토리지 요구 사항을 이해했으면 인덱싱 전략을 조사할 수 있습니다. 각 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를 초과하면 데이터를 다시 인덱싱하는 것이 좋습니다.

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

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

일반적으로 각 인스턴스 유형에 대한 스토리지 한도는 가벼운 워크로드에 필요한 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개의 m4.large.elasticsearch 인스턴스를 선택했고 각 인스턴스는 90GiB의 EBS 스토리지 볼륨을 사용하므로 시간이 지나면서 늘어나는 요구 사항에 대한 안전망과 공간을 확보할 수 있습니다. 이 구성은 6개의 vCPU 코어와 24GiB의 메모리를 제공하므로 더 가벼운 워크로드에 적합합니다.

    보다 실질적인 예로 14TiB의 스토리지 요구 사항과 과도한 워크로드를 고려해 보겠습니다. 이 경우 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에서는 자동으로 클러스터 전체에 샤드 배포를 다시 조정합니다.

    성능이 떨어진 클러스터에서 부족 용량을 측정하는 것보다 성능이 높은 클러스터에서 초과 용량을 측정하는 것이 더 쉬우므로, 필요한 것보다 더 큰 클러스터에서 테스트하면서 크기를 작게 조정하면 활동량이 많은 기간에는 추가 리소스로 안정적인 작동을 보장하는 효율적인 클러스터를 얻을 수 있습니다.

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