[es] 엘라스틱서치 샤드 최적화

검색 과정

• Elasticsearch 의 검색은 1 Query, 1 Shard, 1 Thread를 바탕으로 이루어짐
  • 3개의 노드를 가지고 있다.
  • 노드는 샤드를 1개씩 가지고 있다 
  • 각각의 노드는 4개의 코어를 가지고 있다
  • 4개의 쿼리가 인입된다. 

이 경우 검색 쓰레드 풀에 4개의  검색 Thread를 가지고 있게 된다. 

 

단일 쿼리의 유입인 경우 검색 Thread 풀에서 1개의 검색 Thread를 사용하게됨 나머지 3개는 노는 상황

언뜻보면 3개가 놀고 있으니 리소스의 낭비같지만 이런경우 4개의 쿼리가 인입될때 Thread를 하나씩 사용하게되어  거의 동시에 종료된다

 

 그럼 아래의 경우를 보자 

• 3개의 노드를 가지고 있다.
• 노드는 샤드를 4개씩 가지고 있다 
• 각각의 노드는 4개의 코어를 가지고 있다
• 4개의 쿼리가 인입된다. 

 이 경우는 노드별로 쿼리를 날려야 할 샤드가 4개 이므로 4개의 Thread 풀에서 4개를 모두 사용하게된다. 

그 뒤에 인입된 쿼리는 첫번째 쿼리가 완료될때까지 실행되지 못하고 Thread 큐에 쌓이게 됨 그 후에 인입된 2번째, 3번째 쿼리는 응답결과가 느려지면서 속도차가 점점 벌어지게 된다.

 

너무 많은 쿼리가 인입될 경우 큐가 꽉 차서 rejected 현상이 발생할 수 도 있습니다. 

 

고려사항 

• cluster 전체 데이터 크기
• 최대 동시 인입 쿼리 수
• 검색 응답시간
• 하드웨어 스팩

 

5.1. 운영 중에 샤드 개수 수정이 불가능한 이유

• ES엔 2가지 종류의 샤드 존재
  • Primary shard: 클러스터에서 실질적인 CRUD 를 제공하는 샤드
  • Replica shard: 주로 장애 복구로 사용되며, 읽기 분산에도 활용됨

• ES는 한번 생성된 primary shards 개수 변경이 불가능함
  • Shard 는 내부에 독립적인 루씬 라이브러리를 포함하며, 루씬은 단일 머신 위에서만 동작하는 (Stand Alone) 검색엔진
  • 이런 특성상 샤드 내부의 루씬 입장에선 함께 인덱스를 구성하는 다른 샤드의 존재를 알 수 없음
  • Primary shards 개수를 바꾼다는 말은 결국 각각의 독립적인 루씬이 갖고 있는 모든 데이터를 재조정 한다는 뜻
    • 만약 루씬 개수가 5 -> 10으로 늘어나면, 루씬 내부의 세그먼트를 잘개 쪼개 새롭게 추가될 루씬쪽으로 보내야 함
    • 새로 추가된 루씬에선 여기저기에서 받은 세그먼트 조각들을 다시 재결합 해야 함
    • 이렇게 리소스가 많이 소모되는 특성으로 인해 현재로선 Primary shards 개수 조정 불가

5.2. 적당한 Replica shards 의 복제본 수는?

• Replica shards 의 복제본 수는 기존 Primary shards 를 단순히 복사만 하면 되기에 자유롭게 변경 가능
• 장애 복구를 위해 최소 1개 이상의 복제본을 갖는게 좋으나, 너무 많은 복제본은 생성에 과도한 리소스가 소모되서 전체 색인 성능 저하 우려도 있음
• Replica shards도 Primary 와 완전 똑같이 내부에 Lucene 지님
• ES에 데이터 추가 시 Master node 가 적절히 라우팅해 특정 Primary shards로 데이터 전송
  • 해당 Primary shards 내부에선 루씬에 의해 세그먼트가 생성되고, 이 세그먼트를 Replica shards 에도 전송함
  • 이 덕분에 replicas 에서도 읽기를 수행할 수 있어서 읽기 분산이 이뤄질 수 있음
• Replicas 가 많아질 수록 대체로 읽기 성능은 올라가지만, 색인 성능은 떨어짐

​

5.3. 클러스터에서 운영 가능한 최대 샤드 수는?

• 클러스터 내 전체 샤드 수에 대한 특별한 제한은 없으나, 개별 인덱스 생성 시 설정 가능한 샤드 수는 1024 개로 제한된 상태

​

5.3.1. 클러스터 내 너무 많은 수의 샤드가 있는 경우

• 클러스터에 존재하는 모든 샤드는 마스터 노드에서 관리하며, 샤드가 많아질수록 마스터 노드의 부하도 같이 증가
• 이로 인해 마스터 노드의 부하가 증가하면 검색이나 색인도 같이 느려질 수 있음
• 또한 마스터 노드의 메모리 사용량도 비례해서 증가
  • 마스터 노드는 빠른 처리를 위해 샤드 정보와 같은 관리 데이터를 모두 메모리에 올려놓기 때문
• 마스터 노드에 장애 발생 시 클러스터 전체가 마비될 수 있음

마스터 노드의 역할
1. 모든 노드와 샤드를 관리
2. 평소 노드 상태 모니터링 하며, 색인 요청에 대한 라우팅 처리 및 검색 요청에 대한 부하 분산 수행
3. 장애 발생 시 레플리카를 이용해 샤드 복구 수행

​

​

5.3.2. 인덱스가 다수의 샤드로 분산될 경우

• 단순 검색 성능만 놓고 보면 인덱스 생성 시 Primary shards 개수가 많을수록 읽기 성능이 좋아짐
• 검색은 각 샤드가 독립적으로 검색 수행 후 최종적으로 1개의 결과로 합쳐서 제공되기에, 다수의 샤드로 분산될수록 검색 속도도 비례해서 증가

​

5.3.3. 샤드의 물리적인 크기와 복구 시간

• 마스터 노드 입장에선 샤드에 포함된 데이터 건수보다 물리적인 크기가 더 중요
  • 마스터 노드는 장애 발생 시 샤드 단위로 복구를 수행하기 때문
• 노드에 장애 발생 시 장애가 발생한 Primary shards와 동일한 데이터를 지닌 Replica shards가 순간적으로 Primary shards로 승격되어 서비스됨
  • 동시에 Primary shards로 승격된 샤드와 동일한 샤드가 물리적으로 다른 노드에서 레플리카 샤드로 새로 복제됨
  • 시간이 지나 장애난 노드가 복구되면 복구된 노드로 일부 샤드들이 네트워크 통해 이동함 (Rebalancing)
  • 이처럼 복구 시 Shards 단위로 데이터가 오고가기 때문에 샤드의 크기가 클 수록 복구 작업에 부정적

​

5.3.4. 적절한 샤드의 크기

• 정해진 공식은 없으나 책에선 샤드 1개가 물리적으로 50GB 를 넘지 않도록 권장
• 8.3버전 기준 ES 공식 문서에선 10 ~ 50GB 를 권장함 
• 결국 운영하면서 use case 에 맞는 적절한 매직 넘버를 찾아야 함

​

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

• 세그먼트가 저장할 수 있는 최대 문서의 개수와 깊게 연관됨
  • Lucene은 Java로 개발되었으며, Java의 Integer.MAX_VALUE - 128 만큼이 최대로 가질 수 있는 문서 개수 (= 2,147,483,519 개)
• 결국 하나의 샤드에서 색인 가능한 문서 수가 대략 20억개, 인덱스는 최대 1024개 샤드를 가질 수 있음
  • 20억 * 1024 = 2조
• 당연히 이 최대치를 채워서 사용하기 보단 적절히 나누는게 더 권장되는 방식