RESOURCES

Elasticsearch와 Amazon Elasticsearch Service(Amazon ES)에 대한 소개 시리즈에 오신 것을 환영합니다. 향후 블로그 포스트에서는 AWS의 Elasticsearch를 시작하는 데 필요한 기본 정보를 제공합니다.

 

도입

첫번째 Amazon Elasticsearch Service 도메인을 스핀 업 할 때 인스턴스 유형과 개수를 구성하고 전용 마스터를 사용할지 여부를 결정하며 영역 인식을 사용하도록 설정하고 스토리지를 구성해야 합니다. 이 시리즈에서는 인스턴스 수를 결정하는 가이드라인으로 스토리지를 사용하는 방법에 대해 설명했지만 다른 매개 변수는 살펴보지 않았습니다. 이 글에서는 로그 분석 워크로드에 대한 티셔츠 크기를 기준으로 몇가지 권장사항을 제공합니다.

 

로그 분석 및 스트리밍 워크로드 특성

스트리밍 작업부하에 Amazon ES를 사용하는 경우 하나 이상의 소스에서 Amazon ES로 데이터를 전송합니다. Amazon ES는 사용자가 정의한 인덱스에 데이터(또는 더 적절한 데이터 인덱스)를 저장합니다. 데이터가 도메인에서 라이프사이클을 관리할 수 있도록 타임 슬라이싱 및 보존 기간을 추가로 정의합니다.

다음 그림에서는 데이터 스트림을 생성하는 하나의 데이터 소스가 있습니다.

 

 

데이터 스트림을 Amazon ES로 보내면 Stream1_2018.05.21, Stream1_2018.05.22 등의 일별 인덱스가 생성됩니다. Stream1_인덱스 패턴 이라고 부르겠습니다. 이 다이어그램은 각 인덱스에 대한 세가지 주요 샤드를 보여 줍니다. 세개의 Amazon ES 데이터 인스턴스와 각 기본 데이터에 대한 복제본 하나가 배포됩니다. (간단하게 설명하자면 다이어그램에 표시되지 않지만, 샤드가 배포되어 기본 및 복제본이 서로 다른 인스턴스에 있습니다.)

Amazon Elasticsearch Service에서 업데이트를 처리하면 해당 업데이트가 새 문서 또는 업데이트된 문서를 수신하는 모든 기본 및 복제본으로 전송됩니다.

 

 

Elasticsearch가 업데이트를 처리하는 방법에는 몇가지 중요한 특성이 있습니다. 첫째, 각 인덱스 패턴은 기본* 복제본 수* 전체 샤드 보존 기간(일)을 배포합니다. 둘째, 이 인덱스 패턴에 인덱스가 3개 있더라도 타임 슬라이싱은 새 문서가 이러한 인덱스 중 하나(해당 인덱스 패턴에 대한 활성 인덱스)에만 적용됨을 의미합니다. 셋째, _벌크 데이터를 전송하고 임의로 배포된다고 가정하면 해당 인덱스의 모든 샤드는 업데이트를 수신하고 기록합니다. 따라서 이러한 인덱스 패턴의 경우 단일 _벌크 요청을 처리하려면 vCPU 6개가 필요합니다.

마찬가지로, Elasticsearch는 관련된 인덱스에 대한 조회를 전체적으로 배포합니다. 3일에 걸쳐 이 인덱스 패턴을 쿼리할 경우 18개의 샤드가 사용되며 요청을 처리하는 데 18개의 vCPU가 필요합니다.

 

 

더 많은 데이터 스트림과 인덱스 패턴을 추가하면 사진이 훨씬 복잡해집니다. 앞의 다이어그램과 같이 각 추가 데이터 스트림/인덱스 패턴에 대해 각 일별 인덱스에 대한 샤드와 배포된 조각에 비례하여 요청을 처리하기 위해 vCPU를 사용합니다. 하나 이상의 인덱스에 대해 동시 요청을 하는 경우 관련된 모든 인덱스에 대한 샤드가 이러한 요청을 처리해야 합니다.

 

 

클러스터 용량

인덱스 패턴 및 동시 요청 수가 증가함에 따라 클러스터 리소스가 빠르게 부족해 질 수 있습니다. Elasticsearch는 요청을 버퍼링하고 동시성 요구를 완화하는 내부 대기 열을 포함합니다. _cat/thread_pool API를 사용하여 이러한 대기 열을 보고 그 깊이를 모니터링할 수 있습니다.

또 다른 복잡한 차원은 업데이트 및 쿼리의 내용에 따라 업데이트와 쿼리를 처리하는 시간입니다. 요청이 들어오면 대기 열이 사용자가 보내는 속도로 채워집니다. 또한 사용 가능한 vCPU, 각 요청에 소요되는 시간, 그리고 해당 요청의 처리 시간에 의해 좌우되는 속도로 배수됩니다. 이러한 요청이 1초 만에 해결되는 경우보다 1밀리 초 내에 명확하게 처리되는 경우 더 많은 요청을 삽입할 수 있습니다. 이 주제에 대한 전체적인 대화는 이 게시물의 범위를 벗어납니다. _nodes/stats Elasticsearch API를 사용하여 CPU의 평균 로드를 모니터링할 수 있습니다.

대기 열 크기가 증가하면 클러스터에서 로드를 처리하는 “경고” 영역으로 이동합니다. 하지만 계속할 경우 사용 가능한 대기 열을 초과하기 시작하여 CPU를 더 추가하기 위해 확장해야 할 수 있습니다. 대기 열 크기 증가와 상관 관계가 있는 로드 증가가 표시되기 시작하면 “경고” 영역도 확장을 고려해야 합니다.

 

추천 사항

다음 표에서는 소스 데이터의 양, 필요한 스토리지, 활성 및 총 샤드를 기반으로 한 인스턴스를 권장합니다. 모든 크기 권장 사항과 마찬가지로 이러한 가이드라인도 시작점을 나타냅니다. 시험해 보고, Amazon ES 도메인을 모니터링하고, 필요에 따라 조정하세요.

 

T-shirt 사이즈	데이터 (하루마다)	필요 스토리지	Active shards (maximum)	Total shards (maximum)	인스턴스
XSmall	10 GB	177 GB	4 @ 50 GB	300	2x M4/R4.large data 3x m3.medium masters
Small	100 GB	1.7 TB	8 @ 50 GB	600	4x M4/R4.xlarge data 3x m3.medium masters
Medium	500 GB	8.5 TB	30 @ 50 GB	3000	6x I3.2xlarge data 3x C4.large masters
Large	1 TB	17.7 TB	60 @ 50 GB	3000	6x I3.4xlarge data 3x C4.large masters
XLarge	10 TB	177.1 TB	600 @ 50 GB	5,000	30x I3.8xlarge data 3x C4.2xlarge masters
Huge	80 TB	1.288 PB	3400 @ 50 GB	25,000	85x I3.16xlarge data 3x C4.4xlarge masters

 

참고: 이 표에는 여러 가정에 기초한 가이드라인이 제시되어 있습니다. 워크로드가 다르므로 실제 요구 사항은 이러한 권장 사항과 다릅니다. 배포, 모니터링 및 조정을 확인하십시오!

 

낮은 수준에서, 초소형 유스 케이스는 단일 데이터 스트림에서 단일 인덱스 패턴에 이르기까지 매일 10GB이하의 데이터를 포함합니다. 작은 유스 케이스는 데이터 하루에 10~100GB사이이고, 중간 유스 케이스는 100~500GB 사이입니다. Amazon Elasticsearch Service는 대규모로 하나 이상의 인덱스 패턴에 걸쳐 매일 최대 80TB의 데이터를 지원하므로 총 1페타바이트 이상의 저장된 데이터를 처리할 수 있습니다. 대규모 워크로드의 경우 도메인별 기본 데이터 인스턴스 20개를 초과하여 제한 증액을 요청해야 합니다.

필요한 스토리지 용량을 파악하기 위해, 저는 소스: 인덱스*비율 1.1, 복제본의 경우 2배이며 데이터 보존 기간을 7일로 추정하면 7배로 하여 일일 데이터를 곱합니다.

필요한 스토리지=소스 바이트*1.1*2*7*1.15

(이 권장 사항에는 Elasticsearch의 cluster.routing.allocation.disk.watermark.low 를 방지하기 위해 이전 가이드라인을 벗어나 오버헤드용 15%의 스토리지가 포함된 것을 참고하십시오.)

CPU의 필요성을 고려하여 최대 활성화된 샤드의 수를 목표로 하는 열과 최대 총 샤드의 수를 나타내는 열을 추가했습니다. 처리량과 지연 시간은 워크로드에 따라 크게 달라지지만 활성 샤드(최대)열의 값을 초기 스케일 포인트로 사용해야 합니다. 이 열의 값은 권장되는 인스턴스 전체에 배포되는 vCPU의 수에 따라 달라집니다. 하단에서 활성 샤드와 CPU의 비율은 1:1입니다. 더 큰 규모에서는 점점 더  많은 클러스터 작업을 수행할 수 있도록 인스턴스별로 더 적은 수의 샤드를 권장했습니다.

축적을 계획할 때 인덱스 패턴의 수를 최대 활성 샤드에 매핑하고 그에 따라 축척할 수 있습니다. 단일 인덱스 패턴을 실행하는 경우 업데이트 처리를 위한 활성 샤드 수는 기본 값과 복제본 수를 더한 값입니다. 둘 이상의 인덱스 패턴을 실행하면 활성 인덱스에 있는 활성 샤드의 합계가 됩니다.

활성 샤드 열에는 샤드 크기 조정 권장 사항도 포함되어 있습니다. 디스크에 있는 인덱스의 크기에 따라 인덱스의 주 샤드 개수를 설정하여 샤드 크기를 제어할 수 있습니다. ‘나에게 필요한 샤드는 몇 개일까요?’라는 글에서 상세하게 살펴보세요. 우리는 최대 샤드 크기 50GB에 대한 Elastic의 권장 사항에 동의합니다.

총 샤드 열은 활성 인덱스와 이전 인덱스를 포함하여 클러스터에 저장된 모든 인덱스의 주 및 복제본 샤드의 합계에 대한 가이드라인을 제공합니다. 보존 시간과 전체 스토리지 전략을 계획하는 데 사용합니다. 총 샤드 열의 값은 JVM(Java 가상 시스템)에 할당된 기본 RAM 크기에 따라 결정됩니다. Elastic의 가이드라인에 따라 JVM에 할당된 RAM의 GB당 최대 25개의 샤드를 사용하는 것이 좋습니다.

마지막 열에서는 Amazon Elasticsearch Service 도메인의 데이터 및 마스터 인스턴스에 대한 인스턴스 수와 인스턴스 유형을 권장합니다. 가장 작은 유스 케이스를 제외하고는 모두 I3인스턴스를 권장합니다. GB시간당 스토리지 비용이 0.39달러(use-east-1)이면 이러한 인스턴스를 비용 면에서 이기기가 어렵습니다. NVMeSSD, Disk 및 네트워크 대역 폭, RAM 크기, CPU 개수로 인해 성능 면에서 이러한 인스턴스를 능가하기가 어렵습니다. 낮은 쪽에서는 EBS 볼륨을 더 작게 사용하고 스토리지 요구 사항을 최적화하여 비용을 절감할 수 있습니다.

 

결론

이 글의 가이드라인을 시작점으로 사용하십시오. 워크로드는 고유한 방식으로 동작하며 개별적으로 확장됩니다. 항상 모니터링하고 적절히 확장하십시오. 동시에, 여러분은 제가 설명한 이 권장 사항을 적용하기 위해 설명한 기술을 사용할 수 있고 올바른 시작을 위해 몇가지를 기대할 수 있습니다.

 

원문 URL: https://aws.amazon.com/ko/blogs/database/get-started-with-amazon-elasticsearch-service-t-shirt-size-your-domain/

** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.