이번 장에서는 시나리오를 통해 실제 클러스터를 구성할 때 고려해야 할 항목들을 살펴볼 것이다.
ElasticSearch는 로그를 장기간 모아 데이터를 분석/집계하는 **분석 엔진
**으로 사용하거나,
검색에 쓰일 데이터를 저장하여 사용자의 검색 요청에 데이터를 제공하는 형태의
검색 엔진
으로 서비스하는 것이 일반적이다.
분석 엔진
으로 ElasticSearch 클러스터 구성할 경우에는 **하루에 적재되는 문서의 전체 용량과
보관 기간을 사전에 산정하는 것이 필수**다.
반면에, 검색 엔진
으로 구성할 경우에는 여러 개의 인덱스를 사용하지 않는 것이 일반적이다.
이처럼 클러스터의 용도에 따라 구성이 달라지게 되는데, 몇 가지 시나리오를 통해 자세히 살펴보자.
항목 | 내용 |
---|---|
요구사항 | 하루에 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%
가 넘으면 더 이상 샤드를 할당하지 않습니다.