primary shard는 데이터와 작업을 나누기 위해, replica는 추가 사본과 검색 용량을 제공하기 위해 선택합니다. 보편적인 shard 수 대신 워크로드와 복구 요구사항에서 출발합니다.
첫 추정 계산하기
primary 인덱스 데이터가 120 GB이고 테스트 결과 워크로드에 primary shard당 약 30 GB가 적합하다고 가정합니다.
text
120 GB / 30 GB = 4 primary shards
1 replica per primary = 4 additional shard copies
Total = 8 shard copies, roughly 240 GB of shard data
이는 가상의 용량 산정 입력입니다. 저장 공간 추정에는 증가분과, 백그라운드에서 인덱스 파일을 합치는 segment merge 같은 작업을 위한 공간이 빠져 있습니다.
shard를 계속 늘리면 안 되는 이유
shard를 늘리면 노드 사이에 작업을 분산할 수 있지만 각 shard마다 관리 비용이 생기고 검색이 더 많은 곳으로 퍼질 수 있습니다. 큰 shard는 그 비용을 줄이지만 복구나 이동이 오래 걸릴 수 있습니다. replica는 중복성을 더하면서 저장 공간과 쓰기 작업도 늘리며 백업은 아닙니다.
장애 상황도 테스트하기
최대 읽기와 쓰기를 함께 측정한 뒤 노드 손실을 테스트합니다. 남은 노드는 목표 시간 안에 복구할 수 있는 디스크, 메모리, 처리 용량이 필요합니다. 증가하는 시간 기반 데이터에는 선택한 조건을 만족하면 새 인덱스를 만드는 rollover가 인덱스 크기를 제한하는 데 도움이 됩니다. 이 결정은 사용자가 shard 설정을 관리하는 배포에 적용됩니다.
