엘라스틱서치 고충 - 1부

Elasticsearch는 신뢰할 수 있고 성숙한 라이브러리인 Apache Lucene을 기반으로 하는 검색 엔진입니다. git에서의 엄청난 활동 프로젝트 리포지토리와 GitHub, SoundCloud, Stack Overflow, LinkedIn과 같은 프로젝트에서의 구현이 그 인기를 증명합니다. "Elastic"이라는 부분은 소규모의 간단한 파일 검색부터 지식 검색, 실시간 빅 데이터 분석에 이르기까지 엄청난 기능을 갖춘 시스템의 특성에 대해 모든 것을 말해줍니다.Elastic을 경쟁사보다 더 강력하게 만드는 것은 클러스터를 생성하고 몇 분 안에 색인에 문서를 추가할 수 있는 기본 구성 및 동작 세트입니다. Elastic은 사용자를 위해 클러스터를 구성하고, 인덱스를 정의하고, 처음 얻은 문서의 필드 유형을 정의하며, 다른 서버를 추가하면 서버 간에 인덱스 데이터를 자동으로 분할 처리합니다.하지만 위에서 언급한 자동화는 기본 설정이 무엇을 의미하는지를 불분명하게 만들고 종종 오해의 소지가 있는 것으로 판명되기도 합니다. 이 글에서는 Elastic 기반 앱을 생성하는 과정에서 발생할 수 있는 가장 일반적인 문제를 다루는 시리즈를 시작하겠습니다.

샤드 개수는 변경할 수 없습니다.

다음을 사용하여 첫 번째 문서를 색인화해 보겠습니다. 인덱스 API:

 $ curl -XPUT 'http://localhost:9200/myindex/employee/1' -d '{'
     "first_name" : "Jane",
     "last_name" : "Smith",
     "steet_number":  12
   }'

이 순간, Elastic은 myindex라는 제목의 인덱스를 생성합니다. 여기서 보이지 않는 것은 인덱스에 할당된 샤드 수입니다. 샤드는 전체 인덱스의 일부 문서에 대한 색인, 저장 및 검색을 담당하는 개별 프로세스로 이해할 수 있습니다. 문서 색인 과정에서 Elastic은 문서를 어느 샤드에서 찾아야 할지 결정합니다. 이는 다음 공식을 기반으로 합니다:

shard = hash(document_id) % number_of_primary_shards

이제 문서가 포함된 인덱스의 기본 샤드 수는 변경할 수 없다는 것이 분명해졌습니다. 따라서 첫 번째 문서를 색인하기 전에 항상 수동으로 색인을 생성하여 색인된 데이터의 양에 충분하다고 생각되는 샤드 수를 지정하세요:

 $ curl -XPUT 'http://localhost:9200/myindex/' -d '{'
     "settings" : {
       "number_of_shards" : 10
     }
   }'

기본값 number_of_shards 는 5입니다. 즉, 인덱싱 중에 데이터를 수집하는 서버를 최대 5개까지 확장할 수 있습니다. 프로덕션 환경의 경우, 샤드 값은 예상되는 인덱싱 빈도와 문서 크기에 따라 설정해야 합니다. 개발 및 테스트 환경의 경우 이 값을 1로 설정하는 것이 좋습니다. 이 글의 다음 단락에서 그 이유를 설명하겠습니다.

상대적으로 적은 수의 문서로 텍스트 검색 결과 정렬하기

문구가 포함된 문서를 검색할 때입니다:

$ curl -XGET 'http://localhost:9200/myindex/my_type/_search' -d
   '{
     "query": {
       "match": {
         "title": "빠른 갈색 여우"
       }
     }
   }'

Elastic은 간단히 말해서 몇 단계만으로 텍스트 검색을 처리합니다:

1. 요청의 구문은 문서가 색인된 것과 동일한 형태로 변환되며, 이 경우 용어 집합이 됩니다: ["quick", "brown", "fox"] ("the"는 중요하지 않으므로 제거됨),
2. 검색된 단어 중 하나 이상이 포함된 문서를 검색하기 위해 색인을 탐색하고 있습니다,
3. 일치하는 모든 문서는 검색 구문과 관련성이 있는지를 기준으로 평가됩니다,
4. 를 사용하면 결과가 계산된 관련성별로 정렬되고 첫 번째 결과 페이지가 사용자에게 반환됩니다.

세 번째 단계에서는 다음 값을 고려합니다:

1. 문서에 포함된 검색 구문의 단어 수
2. 문서에서 특정 단어가 얼마나 자주 나타나는지(TF - 용어 빈도)
3. 일치하는 단어가 다른 문서에서 나타나는지 여부 및 빈도(IDF - 역 문서 빈도) - 다른 문서에서 더 많이 사용되는 단어일수록 중요도가 떨어집니다.
4. 문서의 길이

IDF의 기능은 우리에게 중요합니다. 성능상의 이유로 Elastic은 인덱스의 모든 문서에 대해 이 값을 계산하지 않고 대신 모든 샤드(인덱스 작업자)가 해당 로컬 IDF를 계산하여 정렬에 사용합니다. 따라서 문서 수가 적은 색인을 검색하는 동안 색인의 샤드 수와 문서 분포에 따라 상당히 다른 결과를 얻을 수 있습니다.

인덱스에 2개의 샤드가 있고 첫 번째 샤드에는 "fox"라는 단어로 색인된 문서 8개가 있고 두 번째 샤드에는 같은 단어로 색인된 문서 2개만 있다고 가정해 보겠습니다. 결과적으로, "fox"라는 단어는 두 샤드에서 크게 달라져 잘못된 결과를 생성할 수 있습니다. 따라서 개발 목적으로는 하나의 기본 샤드로만 구성된 인덱스를 만들어야 합니다:

 $ curl -XPUT 'http://localhost:9200/myindex/' -d
   '{"settings" : { "number_of_shards" : 1 }' }'

"멀리" 검색 페이지의 결과를 보면 클러스터가 죽습니다.

이전 단락에서 설명했듯이 인덱스의 문서는 완전히 개별적인 인덱스 프로세스, 즉 샤드 간에 공유됩니다. 모든 프로세스는 완전히 독립적이며 할당된 문서만 처리합니다.

수백만 개의 문서가 있는 인덱스를 검색하고 상위 10개 결과를 얻기 위해 기다릴 때, 모든 샤드는 가장 잘 일치하는 10개 결과를 클러스터의 노드를 클릭해 검색을 시작합니다. 그런 다음 모든 샤드의 응답이 합쳐지고 상위 10개 검색 결과(전체 인덱스 내에서)가 선택됩니다. 이러한 접근 방식을 사용하면 검색 프로세스를 여러 서버에 효율적으로 분산할 수 있습니다.

사용자가 볼 수 있는 페이지 수에 대한 제한 없이 페이지당 50개의 결과를 볼 수 있는 앱이 있다고 가정해 보겠습니다. 인덱스는 10개의 기본 샤드(서버당 1개)로 구성되어 있다는 점을 기억하세요.

첫 번째 페이지와 100번째 페이지의 검색 결과 획득이 어떻게 되는지 살펴봅시다:

검색 결과 1페이지:

1. 쿼리를 수신한 노드(컨트롤러)는 이를 10개의 샤드로 전달합니다.
2. 모든 샤드는 관련성별로 정렬된 가장 잘 일치하는 50개의 문서를 반환합니다.
3. 모든 샤드에서 응답을 받은 후 컨트롤러는 결과(500개 문서)를 병합합니다.
4. 결과는 이전 단계의 상위 50개 문서입니다.

검색 결과 100번 페이지:

1. 쿼리를 수신한 노드(컨트롤러)는 이를 10개의 샤드로 전달합니다.
2. 모든 샤드는 관련성별로 정렬된 가장 잘 일치하는 문서 5000개를 반환합니다.
3. 모든 샤드로부터 응답을 받은 후 컨트롤러는 결과(50000개 문서)를 병합합니다.
4. 결과는 이전 단계의 문서가 4901 - 5000에 배치된 것입니다.

문서 한 개의 크기가 1KB라고 가정할 때, 두 번째 경우에는 한 명의 사용자가 100개의 결과를 보기 위해 약 50MB의 데이터를 클러스터로 전송하고 처리해야 한다는 뜻입니다.

결과 페이지가 연속적으로 표시될 때마다 네트워크 트래픽과 인덱스 부하가 크게 증가한다는 사실은 어렵지 않게 알 수 있습니다. 그렇기 때문에 사용자가 "멀리" 검색 페이지를 사용할 수 있도록 하지 않는 것이 좋습니다. 인덱스가 잘 구성되어 있으면 사용자는 첫 번째 검색 페이지에서 관심 있는 결과를 찾을 수 있으며, 클러스터의 불필요한 부하로부터 자신을 보호할 수 있습니다. 이 규칙을 증명하려면 가장 인기 있는 웹 검색 엔진이 몇 개의 검색 결과 페이지까지 볼 수 있도록 허용하는지 확인하세요.

또한 흥미로운 점은 연속된 검색 결과 페이지에 대한 브라우저 응답 시간을 관찰한 것입니다. 예를 들어 아래에서 Google 검색의 개별 검색 결과 페이지에 대한 응답 시간을 확인할 수 있습니다(검색어는 "검색 엔진"):

| 검색 결과 페이지(페이지당 문서 10개) | 응답 시간 | 검색 시간
|——————————————–|—————|
| 1 | 250ms |
| 10 | 290ms |
| 20 | 350ms |
| 30 | 380ms |
| 38(마지막 사용 가능) | |

다음 파트에서는 문서 인덱싱과 관련된 문제를 자세히 살펴보겠습니다.