Elasticsearch 2.0 인덱싱 성능 고려사항
1년 전쯤에 Elasticsearch로 인덱싱 처리량을 최대화하는 방법을 설명했습니다. 그 후에 많은 사항이 변경되었기에 여기서는 Elasticsearch 2.0.0에서는 인덱싱 성능에 영향을 주는 변경 사항에 대해 설명합니다.
이제 자동으로 저장 속도 조절
2.0.0 이전에는 Elasticsearch가 고정 속도(기본적으로 20 MB/sec)로 진행 중인 merge를 조절했지만 종종 속도가 지나치게 느렸고 merge 지연과 후속 인덱싱 조절로 이어지기 쉬웠습니다.
2.0.0, Elasticsearch에서는 이제 적응형 merge IO 조절을 사용합니다. merge 속도가 느려지기 시작하면 허용된 IO 속도가 증가하고, merge 속도가 정상으로 유지되면 IO 속도가 감소합니다. 이는 처리량이 적은 인덱싱 사용 사례에서 갑작스럽지만 드문 대규모 merge는 노드에서 사용 가능한 모든 IO를 포화시키지 않으므로 진행 중인 검색과 인덱싱 작업에 대한 영향이 최소화됨을 의미합니다.
하지만 부하가 심한 인덱싱의 경우, 진행 중인 인덱싱에 부합되도록 허용된 merge IO가 증가합니다.
이것은 희소식입니다! 즉, 어떤 조정 설정도 변경할 필요 없이 기본값을 그대로 사용하면 된다는 의미입니다.
여러 path.data
Elasticsearch 사용에서 병목 현상의 요인이 되는 경우, 노드에 여러 샤드를 보유하기 위해 여러 IO 장치를 사용(여러 path.data경로 지정)하는 것은 전체 저장 공간을 증가와 IO 성능 개선에 유용합니다.
Elasticsearch가 여러 경로에 걸쳐 IO 부하를 확산하는 방법에 중대한 변화가 있습니다. 과거에는 최하위 레벨의 index 파일을 개별적으로 최적의 경로(기본값: 가장 비어있는 경로)로 전송했는데, 이제는 샤드 단위로 전환됩니다. 샤드가 노드에 할당되면, 노드가 해당 샤드의 모든 파일을 보유하고 있을 경로를 선택합니다.
그 결과 IO 장치 오류에 대한 복원력이 향상됩니다. 사용 중인 IO 장치 중 하나가 충돌하는 경우, 해당 장치에 있던 샤드만 잃게 됩니다. 2.0.0 이전 버전에서는 해당 장치에 파일(샤드의 일부)을 가지고 있던 모든 샤드가 사라졌습니다(즉, 해당 노드에 있던 거의 모든 샤드를 잃음).
장치에서 결함이 발생할 때 해당 노드의 모든 샤드가 상실되므로 OS 레벨 RAID 0 장치도 좋은 선택은 아닙니다. 따라서 여러 path.data 의 사용을 권장합니다.
그래도 index 복제본이 1개 이상 있어야 데이터 손실 없이 유실된 샤드를 복구할 수 있습니다.
Auto-ID 최적화 제거
이전에는 append-only Lucene APIs under-the-hood를 사용하기 위해 Elasticsearch가 auto-id 케이스를 최적화했는데(사용자가 인덱스된 도큐먼트별로 고유 id를 지정하지 않을 경우), 이 방식이 오류 케이스로 판명되어 삭제하였습니다.
또한ID 조회 성능을 크게 개선하였으므로 최적화는 더 이상 그렇게 중요하지 않을 뿐만 아니라 최적화 제거를 통해 적지 않은 힙을 소모하지만 ID 조회 성능 향상에 크게 기여하지 못하던 엄청난 필터를 완전히 제거할 수 있었습니다.
마지막으로, 1.4.0 버전부터 Elasticsearch는 Flake ID를 사용하여 ID를 생성함으로써 이전 UUID보다 향상된 조회 성능을 제공합니다.
즉, 현재 제거된 auto-id 처리 기능으로 인해 성능이 저하되는 문제없이 자체 id 필드를 자유롭게 사용할 수 있게 되었습니다. 하지만 id 필드 값의 선택이 인덱싱 성능에 영향을 미친다는는 점을 잊지마십시오.
추가적인 인덱싱 변경사항...
이러한 변경사항 외에, 추가적인 2.0 인덱싱 변경사항은 다음과 같습니다: 기본적으로 도큐먼트 값 활성화 (검색 시 CPU와 힙 부하가 심한 필드 데이터를 사용하는 대신), 위험한 delete-by-query를 코어 API에서 벌크 인덱싱 API 상단의 안전한 plugin으로 이동,인덱싱 중 증가된 저장 필드 압축에 대한 제어 개방, 분산된 도큐먼트 값 및 규칙의 압축률 향상, 통합할 때 필요한 힙 감소, 그리고 기타 복원력 측면에서 많은 점이 개선되었습니다. 예를 들어, 통합할 때 기존 index 손상 검출기능의 등의 개선사항이 있습니다.
인덱싱하는 동안 low-level Lucene 동작에 관한 의문 사항이 있으면index.engine.lucene.iw: TRACE를 사용자의logging.yml에 추가하십시오. 단, 아주 방대한 출력이 생성된다는 점을 유념하십시오!
당사의 야간 인덱싱 성능 차트에서 시간이 지남에 따라 올바른 방향으로 나아가고 있음이 확인되고 있습니다. 초당 문서 수(docs/sec)와 세그먼트 수 기본값(4 GB) 힙이 고속 성능 라인을 따라 잡았습니다.