Elasticsearch (8) - Elasticsearch Shard 최적화

Elasticsearch Shard 최적화

 

 

운영 중에 shard의 개수를 수정하지 못하는 이유

 

-        ES Shard는 Lucene index의 확장. 

-        각 shard는 내부에 독립적인 Lucene 라이브러리를 가지고 있고, Lucene은 단일 머신 위에서만 동작(Stand Alone)하는 검색엔진임.

-        shard 내부의 Lucene 입장에서는 함께 인덱스를 구성하는 다른 shard의 존재를 모름!

-        프라이머리 shard의 개수를 변경한다는 것 == 독립적인 Lucene이 가지고 있는 데이터를 모두 재조정 한다는 뜻.

o    이는 세그먼트를 재조정 해야 하는데, 세그먼트의 불변성 때문에 불가능함.

 

 

1.      Index를 생성할 때 한 번 설정된 shard의 개수는 절대!! 변경이 불가능하므로 데이터의 크기가 최대 얼마까지 증가할 것인지 잘 계산해 최초index를 생성할 때 shard 개수를 신중하게 결정해야함.

 

-        number_of_shards: 전체 데이터를 몇 개의 shard로 나눠서 보관할 것인지

-        number_of_replicas: 몇 개의 복사본 세트를 만들 것인지

 

Ex) number_of_shards: 5, 

    number_of_replicas: 1

    -> 5개의 프라이머리 shard, 5개의 레플리카 shard가 생성되어 총 10개의 shard가 존재.

 

2.      Primary shard 개수 변경하는 법

a.       새로운 index를 생성하고 재색인 진행

b.      ES에서 ReIndex API 제공.      

 

 

 

Replica shard의 복제본 수는 얼마가 적당?

 

• 일반적으로 장애가 발생했을 때 빠른 복구를 위해 복제본 1세트 이상 사용 권장
• Replica 세트 수를 결정할 땐 충분한 테스트 필요.
  • 너무 많은 복제본이 존재하면 전체적인 색인 성능이 저하될 수 있음.
    • 이유: 데이터가 추가되면 프라이머리 shard와 레플리카 shard 모두 동일한 세그먼트 생성 과정을 거침. 이러한 일관성을 바탕으로 읽기 분산이 이루어짐.
    • 읽기 분산이 중요한 경우
      • 색인 성능을 일부 포기하고 레플리카 세트의 수를 늘리기
    • 빠른 색인이 중요한 경우
      • 읽기 분산을 일부 포기하고 레플리카 세트의 수를 최소화 하기
  • 복제본 수는 언제든지 변경 가능하므로 최초 서비스 오픈 시에는 최소화하여 서비스 운영하는 것이 좋음

 

 

cluster에서 운영 가능한 최대 shard 수는?

 

-        전체 shard 수에 대한 제한은 없음 -> 이론 상 cluster에는 index가 무한대로 생성 가능

-        하지만, 개별 index를 생성할 때 설정 가능한 shard의 수는 1024개로 제한되어 있음.

 

1. cluster에 많은 수의 shard가 존재할 경우
   1. 모든 shard는 마스터 노드가 관리하므로 shard 수가 많아지면 마스터 노드의 부하도 증가함.
   2. 마스터 노드 부하가 증가하면 색인/검색도 느려질 수 있음
2. shard의 물리적인 크기와 복구 시간
   1. shard가 가지고 있는 데이터 건수 보다, 데이터의 물리적인 크기가 더 중요함.
3. 적절한 shard의 크기
   1. ES에서는 shard 1개가 물리적으로 50GB를 넘지 않도록 권장함.

 

 

하나의 인덱스에 생성 가능한 최대 문서 수는?

-        인덱스 당 생성할 수 있는 최대 샤드의 수 : 1024개

-        샤드 당 가질 수 있는 최대 문서 수: 20억개

-        결론: 20억개 * 1024개 = 2조 (이론적 수치)

 -> 거의 무한대이지만, 안정적인 운영을 위해 충분한 테스트 진행 후 설계하기.