뒤로가기

Elastic

[ElasticSearch] 색인 테스트

김준우 2020.03.11.

소개

다나와에선 검색엔진을 패스트캣(http://www.fastcat.co/)을 사용하고 있습니다. 다나와는 차세대 검색엔진을 엘라스틱서치를 고려하고 있습니다. 엘라스틱은 다양한 서비스를 제공하고 있고, 검색/색인 성능도 좋게 평가되고 있기 때문입니다. 이번에 포스팅 내용은 엘라스틱으로 색인성능을 테스트 해보도록 하겠습니다.

테스트방법

500만건의 문서가 있는 파일을 로그스태시로 엘라스틱서치에 문서를 등록합니다. 엘라스틱 서치의 인덱스 설정을 조정하며 시스템 자원 소모및 소요시간등을 기록하였습니다. 그리고 엘라스틱서치를 싱글노드일때와 클러스터 노드일때 각각 환경에서 테스트를 진행하였습니다.

테스트 조건

문서

  • 갯수 : 5011608건
  • 문서 크기: 약 5.27GB

엘라스틱서치

  • 노드: 1(싱글), 3(클러스터)
  • 힙메모리: 1GB (싱글), 16GB(클러스터)

시스템 자원

  • core: 48
  • memory: 94G

클러스터 환경에서 테스트 진행시 시스템 자원을 동일하게 구성하였습니다.

테스트 결과

싱글모드

CASE 1: 샤드 1, 레플리카 0 으로 색인을 진행했을때 소요시간은 23분이 걸렸고, 문서의 크기가 내부적으로 압축이되어 1.6G로 측정되는걸 볼 수 있습니다.

구성: shards: 1, replicas: 0
소요시간:  0:23:33
문서 크기: 1.6GB
CPU 사용률: 최소: 12 %, 최대: 260 %, 평균: 75%, 최빈수: 66 %
메모리 평균 수치: 1.5GB

CASE 2: 샤드1, 레플리카 1로 구성하고 색인을 진행했을때 소요시간은 26분이 걸렸으나 약간의 오차로 보면 샤드1, 레플리카 0으로 진행한 케이스와 유사하다고 볼 수 있습니다. 그리고 문서의 크기가 1.6G로 측정이되는지 인덱스의 상태가 노랑으로 표시되는걸 보아 노드가 한개여서 primary가 있는곳에 레플리카를 중복하여 만들지 못하는 형상을 보였습니다.

구성: shards: 1, replicas: 1
소요시간:  0:26:28
문서 크기: 1.6GB
CPU: 최소: 6.7 %, 최대: 233.3 %, 평균: 66.2 %, 최빈수: 60.0 %
메모리 평균 수치: 1.6GB
특이사항: 인덱스 상태가 yellow

CASE 3: 샤드 5, 레플리카 0 구성으로 테스트를 해보았을땐 CASE 1과 비교했을때 보다 소요시간이 많이 늘어난걸 볼 수 있습니다. 문서의 크기 또한 증가하였습니다.

구성: shards: 5, replicas: 0
소요시간: 1:13:34
문서 크기: 2.2GB
CPU: 최소 6.2%, 최대: 246.7%, 평균: 28.2%, 최빈수: 20%
메모리 평균 수치: 1.5GB

CASE 4: 이번에 테스는 샤드1, 레플리카 0으로 색이된 인덱스를 새로운 재인덱스를 진행해보았습니다. CASE1과 비교했을때 보다 소요시간은 줄었습니다. 대신 CPU, 메모리 사용량이 증가한걸 볼 수 있습니다.

구성: reindex 진행 (shards: 1, replicas: 0)
소요시간: 0:17:32
문서 크기: 1.6GB
CPU: 최소 46.7%, 최대 231.2%, 평균 105.3% 최빈수 86.7% 
메모리 평균 수치:  1.8GB

CASE 5: 인덱스를 스냅샷을 진행해보았습니다. 인덱스를 색인 후 백업 및 복원이 필요하여 테스트해보았습니다. 스냅샷은 1분이내로 끝나는 모습을 보였고, 데이터는 작성하지 않았지만 복원 시 1초 이내로 빠르게 끝나는 모습을 보여줬습니다.

snapshot (shards: 1, replicas: 0)
소요시간: 59s
문서 크기: 1.7GB
CPU: 최소 6.7%, 최대 93.3%, 평균 20%, 최빈수: 6.7%
메모리 평균 수치: 1.4GB
특이사항: restore는 1초 이내 완료됨.

CASE 6: 인덱스를 삭제하지 않고 모든 데이터를 삭제하는 테스트를 진행해보았습니다. 문서를 삭제하는 소요시간이 CASE1 등록하는 시간과 유사하다는걸 보았을때 엘라스틱서치 내부에선 일괄 삭제를 하지 못하고, 건건히 삭제를 진행하는 모습을 보였습니다.

문서 전체 삭제 (shards: 1, replicas: 0)
소요시간: 0:21:47
CPU: 최소 6.7%, 최대 306.7%, 평균 97.8%, 최빈수 100%
메모리 평균수치: 1.98GB
특이사항: 전체삭제는 인덱스를 지우는게 빠름

클러스터 모드

공통: 전체 노드 메모리 평균수치: 18.4G

CASE 7: 멀티 노드에선 샤드 1, 레플리카 0으로 구성했을땐 싱글에 비해 월등히 좋은 성능을 보여줬습니다. 소요시간은 5분정도로 나왔습니다.

구성: shards: 1, replicas: 0
소요시간:  0:05:30
문서 크기: 1.8G
CPU: 최소 6.7%, 최대 60%, 평균 29.2%, 최빈수 33.3%

CASE 8: 싱글모드에선 샤드가 증가하면 소요시간도 같이 증가하는 모습을 보였으나, 멀티 노드로 진행했을땐 소요시간이 단축되는 모습을 보여주었습니다.

구성: shards: 2, replicas: 0
소요시간:  0:05:10
문서 크기: 1.9GB
3. CPU: 최소 75%, 최대 1347%, 평균 249.4%, 최빈수 140%

CASE 9: 샤드를 증가할수록 소요시간의 단축은 보이지 않으나 시스템의 자원 소모가 일정하게 낮아지는 모습을 보였습니다.

구성: shards: 3, replicas: 0
소요시간:  0:05:41
문서 크기: 1.9GB
CPU: 최소 6.7%, 최대 646.7%, 평균 169.3%, 최빈수 140%

CASE 10: 엘라스틱에서 권한장하는 샤드 5개를 구성하고 테스트를 진행해보았습니다. 자원 효율은 더욱 좋아지는 모습을 보였습니다. 소요시간 또한 CASE8과 유사한 모습을 보였습니다.

구성: shards: 5, replicas: 0
소요시간: 0:05:10
문서 크기: 1.9G
CPU: 최소 6.7%, 최대 186.7%, 평균 111.3%, 최빈수 120%

CASE 11: 샤드1, 레플리카 1 구성일땐 복사본이 1개 추가되어 색인 소요시간이 증가하였습니다. CPU 사용율이 일시적으로 튀는 현상이 있었습니다.

구성: shards: 1, replicas: 1
소요시간: 0:07:13
문서 크기: 3.8G
CPU: 최소 6.7%, 최대 1687%, 평균 496.5%, 최빈수 346.7%

CASE 12: 샤드 5, 레플리카 1로 구성했을땐 소요시간도 CASE 11 보다 줄었고, CPU 사용율또한 안정된 모습을 보였습니다.

구성: shards: 5, replicas: 1
소요시간: 0:06:42
문서 크기: 3.8G
CPU: 최소 6.7%, 최대 620%, 평균 216%, 최빈수 6.7%

CASE 13: 샤드 1, 레플리카는 0에서 1로 변경하는 테스트를 진행하였습니다. 문서의 크기는 레플리카에 따라 증가하는 모습을 보여줬습니다.

replicas 변경 (shards: 1, replicas: 0 → 1)
소요시간: 0:01:44
문서 크기: 1.8G → 3.6G
CPU: 최소 6.7%, 최대 46%, 평균 24.3%

CASE 14: 샤드 5, 레플리카는 0에서 1로 변경하는 테스트를 진행했을때 CASE 13과 비교하여 문서의 크기는 조금더 커졌지만 CPU 사용율은 낮아 졌습니다.

replicas 변경 (shards: 5, replicas: 0 → 1)
소요시간: 0:01:02
문서 크기: 1.8G → 3.7G
CPU: 최소 6.7%, 최대 26.7%, 평균 14.5%, 최빈수 13.3%

정리

색인과 스냅샷등의 성능 테스트를 진행해보았습니다. 싱글모드일때는 replicas를 1이상으로 지정해도 데이터크기가 변하지 않는 현상이 었었습니다. 노드가 1개일때 primary가 이미 저장되어 있어서 replicas가 적용 안되는 현상같았습니다. 그리고 샤드의 갯수에 따라 색인 성능 차이가 있고, 데이터의 크기도 차이가 있었습니다. 클러스터 환경에서는 월등히 빠른 색인 성능을 보여주었고, replicas에 따른 문서 크기도 달라졌습니다. 엘라스틱서치를 사용을 고려할때 이번 포스트이 도움이 되었으면 합니다.