이번 장에서는 시나리오를 통해 실제 클러스터를 구성할 때 고려해야 할 항목들을 살펴볼 것이다.

ElasticSearch는 로그를 장기간 모아 데이터를 분석/집계하는 **분석 엔진**으로 사용하거나,

검색에 쓰일 데이터를 저장하여 사용자의 검색 요청에 데이터를 제공하는 형태의

검색 엔진 으로 서비스하는 것이 일반적이다.

분석 엔진 으로 ElasticSearch 클러스터 구성할 경우에는 **하루에 적재되는 문서의 전체 용량과

보관 기간을 사전에 산정하는 것이 필수**다.

반면에, 검색 엔진 으로 구성할 경우에는 여러 개의 인덱스를 사용하지 않는 것이 일반적이다.

이처럼 클러스터의 용도에 따라 구성이 달라지게 되는데, 몇 가지 시나리오를 통해 자세히 살펴보자.

1. 시나리오 #1 - 일 100GB 데이터 분석용 클러스터

항목 내용
요구사항 하루에 100GB 정도의 데이터를 저장하면서 보관 기간이 한 달인 분석 엔진 클러스터
인덱스 이름 패턴 elasticsearch-YYYY.MM.dd
프라이머리 샤드 기준
하루에 색인되는
인덱스의 용량 100GB x 1(일) = 100GB
인덱스 보관 기간 30일
레플리카 샤드 개수 1개
클러스터에 저장되는
전체 예상 용량 100GB x 30(일) x 2(프라이리 샤드 1개 + 레플리카 샤드 1개) = 6TB
데이터 노드 한 대에
저장할 수 있는 용량 SSD 2TB
클러스터에 저장될
인덱스의 총 개수 30개

먼저 시나리오를 바탕으로 클러스터에 저장되는 전체 용량을 산정할 수 있다.

클러스터의 전체 용량을 산정하고 나면 데이터 노드로 사용할 노드의 용량을 기준으로 최소 몇 대의 데이터 노드가 필요한지 산정할 수 있다.

이 시나리오에서는 2TB의 SSD 디스크를 사용하는 데이터 노드로 가정하였다.

인덱스는 30일만 보관할 예정이기 때문에 인덱스의 이름을 일별 패턴으로 생성하면 클러스터는 총 30개의 인덱스가 생성된다.

지금까지 데이터를 살펴보면 클러스터 전체 데이터 사이즈를 6TB로 산정해서 노드 3대만으로 구성하면 될 것 같지만 클러스터 전체 용량은 이보다 더 크게 할당해야 한다.

ElasticSearch는 디스크 사용률을 기준으로 샤드를 배치하기 때문에 디스크 사용률이 85% 가 넘으면 더 이상 샤드를 할당하지 않습니다.