샤드
https://thoughts.t37.net/designing-the-perfect-elasticsearch-cluster-the-almost-definitive-guide-e614eabc1a87
- 인덱스 내부에 색인된 데이터들이 물리적 공간 즉 여러 노드에 여러개의 부분들로 존재하는 데이터
- 인덱스는 기본적으로 샤드 단위로 분리됨
- 샤드는 한마디로 인덱스에 색인되는 도큐먼트를 저장하는 공간
- 하나의 샤드는 독립적인 Lucene 인덱스로 동작하여, 데이터 검색 및 저장을 함
- 엘라스틱 서치는 분산 저장 및 검색 성능 향상을 위해 샤딩이라는 개념을 사용함
샤드의 종류
- 샤드는 프라이머리 샤드와 레플리카 샤드로 구분이 됨
| 샤드 종류 |
설명 |
| 프라이머리 샤드 |
원본 데이터를 저장하는 기본 샤드, 데이터 원본 |
| 레플리카 샤드 |
프라이머리 샤드의 복제본, 백업 역할 |
프라이머리 샤드
- 원본 데이터를 저장하는 샤드
- 데이터가 처음 저장될 때 프라이머리 샤드에 기록됨
- 기본적으로 샤드 개수는 색인 생성시 설정되고 이후 변경이 불가능함
레플리카 샤드
- 프라이머리 샤드 복제본
- 레플리카 샤드 같은 경우 변경이 가능함
- 레플리카 샤드가 복제본이므로 기존 프라이머리 샤드의 데이터가 무너졌을 때, 대신 사용되어 Fail-over 역할을 하여 데이터의 가용성과 무결성을 보장함
- 프라이머리 샤드가 유실될 경우 남아있는 레플리카 샤드가 프라이머리 샤드로 승격됨
- 검색 쿼리를 분산 처리하여 검색 성능을 향상
샤드 개수 설정 예시
PUT my_index
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}
- 프라이머리 샤드: 3 (number_of_shards 갯수)
- 레플리카 샤드: 3개의 프라이머리 샤드 (number_of_shards 갯수) × 1개의 복제본 (number_of_replicas) = 총 3개
- 총 샤드 개수: 3 (프라이머리) + 3 (레플리카) = 6개
샤드의 역할 및 데이터 분산
- 샤드는 노드에 분산 저장이 됨
- 아래 예제 : 3개의 노드가 있을 때, number_of_shards: 3 & number_of_replicas: 1 설정 시 데이터 배포 방식
| 노드1 |
노드2 |
노드3 |
| 프라이머리 샤드1 |
프라이머리 샤드2 |
프라이머리 샤드3 |
| 레플리카 샤드2 |
레플리카 샤드3 |
레플리카 샤드1 |
- 프라이머리 샤드와 동일한 노드에 해당 프라미어리 샤드의 레플리카 샤드가 배치가 되지 않음
- 장애 발생하는 경우 레플리카 샤드가 프라이머리 샤드로 승격
샤드가 많으면 많을 수록 좋다 ?
- 검색 부하가 높은 경우 number_of_replicas를 통하여 레플리카 샤드를 늘려서 검색요청을 분산하면 성능이 최적화되나 무조건 많다고 좋지는 않다.
- 쿼리 수행시 샤드의 개수만큼 cpu의 스레드를 사용하기 때문에 샤드의 개수가 많아질 수록 리소스를 많이 사용하게 되기 때문에, 데이터가 많지 않은데 샤드 개수가 많으면 리소스가 낭비가 된다.
참고
