[Elasticsearch] Shard

Elasticsearch는 수평 확장을 위한 샤딩 기능을 기본적으로 제공한다.

하나의 인덱스는 여러개의 노드에 분산 배치될 수 있으며, 그 각각의 복제나 파티션을 샤드(Shard)라고 부른다. 조금 혼란스러울 수 있는데, Elasticsearch의 샤드는 복제와 파티션이 혼재된 개념이다.
이를 통해서 큰 데이터를 분할 저장함과 동시에 내구성을 유지한다.

Shard의 종류

Shard에는 2가지 종류가 있다.

하나는 Primary Shard고, 두번째는 Replica Shard다. 보통 샤드라고 하면 Primary 샤드를 말하는데, 용어가 좀 애매해가지고 문맥을 잘 읽어야 할 수 있다.

- Primary 샤드
Primary 샤드는 원본 데이터를 가지고 있는 파티션 단위라고 보면 된다.

만약 idx_items라는 인덱스를 만들고, Primary 샤드 수를 2개로 정한다면 이런 식이 될 것이다.

그리고 각각의 Primary 샤드는 서로 다른 데이터를 저장한다.
그러니까 저 인덱스에 100개의 데이터가 있다면, 각각의 샤드가 약 50개씩을 분할해서 저장하는 것이다.

이를 통해서 데이터가 매우 커지더라도 분할해서 저장하는 것이 가능하다.

인덱스 생성시 Shard의 기본값은 7 이전에서는 5개, 7 버전부터는 1개다.
샤드 구성은 생성 시점에만 가능하다.

- Replica 샤드
Replica 샤드는 Primary 샤드의 데이터 유실을 막기 위한 예방책이자, 읽기 성능을 향상시키기 위한 read-only replica다.

각 Primary 샤드의 데이터를 동일하게 복제하는 복제본이며, 손실을 방지하기 위해 원본 데이터와 다른 노드에 저장한다. 구조는 대충 아래 그림과 같다.

그래서 만약 primary 샤드가 5개에 레플리카가 1개라면, 각 primary 샤드에 레플리카가 하나씩 붙어서 총 샤드는 10개가 된다.

노드에 장애가 나서 원본 Primary 샤드가 실패한다면 Replica가 Primary로 승격되고, 다른 노드에 또다른 Replica를 생성한다.
애초에 장애 대응을 위한 것이기 때문에 노드가 1개인 단일 노드 클러스터라면, replica를 만들지 않는다.

그리고 replica는 장애복구용으로만 쓰이는건 아니고, 읽기에도 활용된다.

Replica는 Primary 샤드와는 다르게 인덱스 생성 이후에도 동적으로 조정이 가능하다.

샤드와 검색

Primary 샤드는 단일 데이터를 쪼개서 저장하는 개념이라고 했었다.
그러면 당연히 검색할 때도 쪼개진 데이터를 병합하는 작업이 추가될 것이다.

만약 이렇게 3개의 샤드가 있다면

사용자는 일단 노드 하나를 골라서 query를 날리게 될 것이다.

그럼 요청을 받은 노드가 이 시점에서 coordinating node가 된다.
최종 쿼리의 완료를 모두 책임지는 것이다.

coordinating node가 된 Node 1 샤드는 데이터가 분할 저장된 모든 샤드를 찾아서 쿼리를 또 때린다.

쿼리를 때리는 대상은 Primary Shard, Replica 둘다 될 수 있다.
아무튼 coordinator는 그 부분 검색 결과들을 모두 받아다가 최종 병합까지 거치고, 최종 검색 결과를 클라이언트에게 돌려주는 행위까지를 전부 책임져서 행한다.

그리고 당연히 이 부분에는 오버헤드가 존재한다.
이런 부하를 원하지 않는다면 파티션마다 인덱스를 만들고 관리해야 한다.

샤딩 전략: 샤드의 개수와 크기

샤드를 과하게 쪼개는 것은 좋지 않다. 근데 그렇다고 해서 샤드를 너무 적게 잡아서 개별 샤드들이 커진다면 그 또한 심각한 문제가 될 수 있다. 이것도 결국 상황을 보고 조정해야 하는 문제다.

예를 들어, 50GB 단일샤드를 검색하는 것이 50MB 1000샤드를 검색하는 것보다 전체적인 컴퓨팅 비용이 적게 들지만, 병렬처리에 한계가 있어서 최종 처리 속도 자체는 더 느릴 수도 있다.
이게 참 복잡한 문제다. 개별 샤드 크기를 너무 크게 유지하면 전반적인 검색 성능을 떨어뜨릴 수 있는데다 장애대응이 어려워지고, 너무 작고 많게 유지해도 검색 성능이 떨어질 수 있다.

일반적으로 권장되는 샤드당 크기는 최대 10GB~50GB 정도다. 경험적으로는 20GB~40GB 정도가 적절하다는게 중론이다.

그리고 메모리 크기도 고려해야 한다.
일반적으로 힙 1GB당 최대 샤드는 20개 정도를 권장한다.

샤딩 전략: Replica

Replica는 장애대응용으로 사용되기도 하지만, 읽기 성능을 병렬적으로 늘리는 데에도 굉장히 유용하다.
하지만 Replica가 많다는건 그만큼 write에 따른 복제 연산이 많아진다는 것이니, write 부하를 증가시킨다는 말이기도 하다.

그래서 일반적으로 replica 수는 1개를 사용하되, 쓰기에 비해서 읽기가 많은 경우에 대해서는 2~3 정도를 주기도 한다.

참조
https://esbook.kimjmin.net/03-cluster/3.2-index-and-shards
https://j.blaszyk.me/tech-blog/exploring-apache-lucene-scale/
https://danawalab.github.io/elastic/2020/07/21/Elasticsearch-Index-Shard-How.html
https://stackoverflow.com/questions/15694724/shards-and-replicas-in-elasticsearch
https://opster.com/guides/elasticsearch/capacity-planning/elasticsearch-number-of-shards/
https://discuss.elastic.co/t/too-big-a-shard-vs-too-many-shards/75889/6