Engineering/Elastic Search
-
[Elastic Search] vm.max_map_count 설정Engineering/Elastic Search 2020. 7. 20. 17:34
엘라스틱서치 서버를 가동시키면 아래와 같은 에러 메시지와 함께 서버가 실행되지 않는 문제를 겪는 경우가 있습니다. ERROR: [1] bootstrap checks failed [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144] 위 에러는 운영체제에서 기본으로 설정되어 있는 mmap 수가 너무 작게 설정되어 있기 때문에 발생하는 것입니다. 엘라스틱서치에서는 bootstrap 과정에서 mmap 수가 262,144 이하이면 실행되지 않도록 되어 있습니다. 이를 해결하기 위해서는 vm.max_map_count 값을 엘라스틱서치가 동작할 수 있는 최소 값인 262,144로 수정해야 합니다. ..
-
[Elastic Search] 엘라스틱서치의 힙 크기Engineering/Elastic Search 2020. 7. 15. 23:51
엘라스틱서치는 Java 언어로 개발되어 JVM 위에서 동작합니다. JVM 기반의 애플리케이션은 개발자가 직접 메모리 관리를 하지 않아도 된다는 큰 장점이 있습니다. 메모리 관리의 책임은 전적으로 JVM이 맡고, GC(Garbage Collection)라는 메커니즘을 이용하여 일정 주기로 사용하지 않는 메모리를 자동으로 회수합니다. 엘라스틱서치 상에서는 JVM 옵션을 수정할 수 있도록 config 디렉토리에 jvm.option 파일이 존재합니다. jvm.option 파일에는 기본으로 제공하는 JVM 힙 크기가 1GB로 설정되어 있습니다. 이는 엘라스틱서치를 실행할 수 있는 최소한의 힙 크기가 1GB이기 때문입니다. 이 기본 설정은 테스트 용도이며, 실제 운영환경에서의 힙 크기는 1GB보다 반드시 커야합니다..
-
[Elastic Search] 엘라스틱서치와 루씬의 인덱스 최적화 방법Engineering/Elastic Search 2020. 7. 13. 22:06
루씬은 효율적인 색인 작업을 위해 내부적으로 일정 크기의 버퍼를 가지고 있습니다. 이러한 내부 버퍼를 인메모리 버퍼(In-memory buffer)라고 합니다. 만약 내부 버퍼가 없다면 데이터가 들어올 때마다 동기적으로 작업을 수행해야 하기 때문에 요청할 때마다 색인하여 매번 세그먼트를 만들어야 할 것입니다. 순간적으로 요청이 많아질 경우 세그먼트의 개수가 너무 많아져서 서비스 장애로 이어질 위험이 있습니다. 루씬에 색인 작업이 요청되면 전달된 데이터는 인메모리 버퍼에 순서대로 쌓이고, 정책에 따라 내부 버퍼에 일정 크기 이상의 데이터가 쌓이거나 일정 시간이 흐를 경우 버퍼에 쌓은 데이터를 한꺼번에 모아 처리합니다. 버퍼를 일종의 큐(Queue)로 활용하는 것입니다. 인메모리 버퍼의 데이터를 처리하기 전..
-
[Elastic Search] 세그먼트에 대한 정리Engineering/Elastic Search 2020. 7. 11. 23:11
색인 작업 시 세그먼트의 기본 동작 방식 하나의 루씬 인덱스는 내부적으로 다수의 세그먼트로 구성되어 있습니다. 다수의 세그먼트로 나누어져 있기 때문에 검색 요청을 분산 처리하여 훨씬 효율적인 검색이 가능해집니다. 루씬은 검색 요청을 받으면 다수의 작은 세그먼트 조각들이 각각 검색 결과 조각을 만들어 내고 이를 통합해서 하나의 결과로 응답하도록 설계되어 있습니다. 이러한 검색 방식을 세그먼트 단위 검색(Per-Segment Search)라고 합니다. 세그먼트는 내부에 색인된 데이터가 역색인 구조로 저장되어 있습니다. 루씬은 세그먼트들을 관리하기 위한 용도로 커밋 포인트(Commit Point)라는 자료구조를 제공합니다. 커밋 포인트는 여러 세그먼트의 목록 정보를 가지고 있으며, 검색 요청 시 이를 활용합니..