Elasticsearch의 용도 및 알아야 할 점

서문

Found에서는, Elasticsearch의 수많은 다양한 사용 사례를 볼 수 있습니다. "Elastic의 일반적인 고객은 누구인가요?"라는 질문을 자주 받지만, "여러 클러스터를 운영하기보다는 무엇인가를 구축하는 데 시간을 보내려고 하는 사람들입니다!"라는 말 외에는 명확한 답이 없습니다. 우리는 Elasticsearch가 수많은 다양한 멋진 작업들과 아울러 몇 가지 엄청나게 특별한 작업들을 위해 사용되는 것을 볼 수 있습니다!

Elasticsearch는 아직도 비교적 새로운 도구이며, 고객은 특정 프로젝트를 위해 Elasticsearch를 시작한 다음 나중에 로깅 및 분석을 위해서도 신속하게 더 많은 클러스터를 구축하는 경향이 있습니다.

일반적인 개발의 진화는 웹사이트 또는 문서 모음에 대한 간단한 검색을 구축하는 것으로 시작됩니다. 그런 다음 아마도 패싯 내비게이션이 추가되고, 맞춤법 검사나 "다음 항목을 찾으려고 하셨나요?"(검색어 추천) 응답을 추가하게 됩니다. 아마도 퍼지 검색이 보장되고, 자동 완성이 되며, 심지어 "입력과 동시에 검색(search as you type)"할 수도 있습니다. 정확도가 중요하기 때문에, 아마도 사용자가 누구인지, 어디에 있는지, 또는 그 사용자가 알고 있는 사람이 누구인지에 따라 궁극적으로 더 고급 순위 체계가 추가될 가능성이 높습니다. 물론, 사용자가 실제로 무엇을 하는지 알기 위해서는 사용이 기록되어야 하고, 메트릭이 저장되어야 합니다. 그래야 모든 작업이 잘 수행되는지 알게 됩니다.

이 모든 것과 더불어 다양한 추가 작업을 위해 Elasticsearch를 사용할 수 있지만, 다양한 사용에는 엄청나게 다른 수준의 복잡성 및 리소스 요건이 따릅니다.

모두가 아는 검색! (계속 증가 중!)

당연하게도 Elasticsearch는 "검색"을 구현하는 데 자주 사용되는데, 일반적으로 확대경 아이콘과 함께 입력 상자가 있다는 것을 의미합니다. 이 경우 "검색"이 의미하는 바가 모호할 수 있으므로, "단순 검색", "퍼지 검색", "집계" 등과 같이 다른 종류의 검색을 언급하려고 합니다. 단순이라는 말은 match 쿼리로 얻을 수 있는 것을 의미합니다.

단순 검색이 Elasticsearch에 요청할 수 있는 리소스 집약도가 가장 낮은 작업 중 하나라는 것은 많은 사람들을 놀라게 합니다. 퍼지가 아닌 일반적인 match 쿼리에 대한 상위 10개의 결과만 있으면, 저렴한 하드웨어에서 수천만 개의 문서 모음에 대한 초당 수백 개의 검색을 유지할 수 있습니다. 그러나 요구 사항 목록에 퍼지 검색이나 패싯 내비게이션을 추가하면, 필요한 CPU와 메모리가 많이 늘어납니다.

최신 검색 인터페이스는 일반적으로 사용자가 검색 결과의 분포를 빠르게 이해할 수 있는 일종의 패싯 내비게이션을 가질 것으로 예상됩니다. 특정 평가를 받은, 특정 가격대의, 특정 저자의 책은 몇 권인가? 이러한 것들은 Elasticsearch의 집계를 사용하여 구현되며 다양한 형태로 제공됩니다. 용어, 숫자 범위, 날짜 범위, 지리적 거리 등 수많은 것을 기준으로 집계할 수 있습니다.

일치 항목을 찾기 위해 수백만 개의 문서를 살펴보는 것이 다양한 방법으로 일치 항목을 세어서 집계하는 것보다 다소 노력이 덜 든다는 것은 많은 사람들에게 있어 그리 직관적이지 않습니다. 그럼에도 불구하고, "어떤 10개의 문서가 이 조건과 일치하는가?"라는 정보 검색 문제에 비해, 집계는 비용이 많이 듭니다. 가장 적합한 문서를 찾기 위해 점수를 매길 때, Lucene은 "이 문서 집합은 이러한 다른 문서들이 일치하는 모든 것과 일치하지 않으므로 가능한 가장 적합한 문서가 될 수 없으니 생략하자"는 것 같은 트릭을 사용합니다. 필터링할 때, Elasticsearch는 필터 캐시를 많이 활용하게 됩니다. Elasticsearch와 Lucene은 가능할 때 작업을 피하는 데는 아주 좋지만, 집계의 경우 항상 일치하는 모든 것을 세어야 합니다.

상향식 관점에서 본 Elasticsearch에서는 역 인덱스가 어떻게 작동하는지, 단순 검색을 수행하기 위해 사전 및 게시 목록이 어떻게 사용되는지를 다룹니다. 이 글과 텍스트 분석에 대한 다른 글에서는 검색 작업을 할 때 텍스트를 올바르게 처리하는 것이 왜 매우 중요한지를 확실히 알려드립니다. Sizing Elasticsearch(Elasticsearch 크기 조정)와 Elasticsearch in Production(프로덕션의 Elasticsearch)에서는 어떤 종류의 메모리 사용을 기대할 수 있는지 상세하게 설명합니다.

분석

분석 워크로드는 여러 가지를 세고 데이터를 요약하는 경향이 있습니다. 많은 데이터, 심지어 빅 데이터일 수도 있습니다! 이는 Elasticsearch의 집계에 의존하며, 집계는 종종 Kibana와 같은 도구를 통해 생성됩니다.

우리는 이미 이러한 집계가 CPU와 메모리 양쪽 모두에서 상당히 비용이 많이 들 수 있다고 언급했습니다. Elasticsearch는 "필드 캐시"에서 문서에 주어진 값을 빠르게 찾아야 하며, 여기에는 모든 문서에 대한 모든 데이터를 메모리에 로드하는 것을 포함하기 때문에 메모리에 대한 요구가 큽니다. 문서를 색인하기 전에 매핑에서 활성화해야 하는 "문서 값"을 사용하여 그 부담을 덜 수 있습니다.

또한, 분석 검색은 타임스탬프가 지정된 데이터에서 실행되는 경우가 많은데, 이는 일별 또는 월별 인덱스로 분할하는 것이 합리적일 수 있습니다. 시간 단위당 하나의 인덱스를 사용하면 손쉽게 검색 공간을 줄이고 오래된 데이터를 정리하여 보관할 수 있습니다.

퍼지 검색

퍼지 검색은 철자 오류에 관대한 검색입니다. 예를 들어, Levenstein을 검색할 때 Levenshtein을 찾을 수 있습니다. 퍼지 검색에 대한 글에서는 퍼지 검색을 사용하는 방법과 그 작동 방식에 대한 더 자세한 내용을 알려드립니다.

퍼지 검색은 활성화하기 쉽고 "재현율"을 많이 향상시킬 수 있지만, 또한 수행하는 데 매우 비용이 많이 들 수 있습니다. 기본적으로, 입력의 용어는 필드당 50개 용어의 OR로 다시 작성될 수 있으며, 이는 multi_field와 결합되어 결과적으로 다시 작성된 쿼리에서 용어의 조합적 폭발을 일으킬 수 있습니다.

프로덕션으로 전송하기 전에 현실적인 양의 데이터를 사용하여 검색에 대한 변경 및 개선 사항을 테스트하는 것이 항상 중요합니다. 이는 fuzziness 매개 변수를 추가할 때 특히 그렇습니다. 활성화하기 쉬운 옵션이지만, 검색이 몇 배 더 비싸게 됩니다.

퍼지 검색은 CPU 집약적입니다. 주의해서 추가하세요. 아마도 모든 필드에 추가할 수는 없을 것입니다.

자동 완성 및 순간 검색

사용자 유형이 다양한 형태로 나타나는 동안 검색합니다. 기존 태그에 대한 간단한 제안일 수 있고, 검색 기록을 기반으로 검색을 예측하려고 시도하거나 모든 (제한된) 키 입력에 대해 완전히 새로운 검색을 수행할 수 있습니다.

Elasticsearch에는 prefix 쿼리, match_phrase_prefix, N그램 색인 및 다양한 제안기 제품군 등 이러한 기능을 구축하는 데 도움이 되는 다양한 기능이 있습니다.

이와 같은 검색은 대기 시간에 매우 민감합니다. 더 이상 "순간적"으로 느껴지지 않는 임계값은 일반적으로 100밀리초로 간주됩니다. 거의 모든 키 입력을 검색하는 것은 또한 검색 처리량이 훨씬 더 높다는 것을 의미합니다. 따라서 검색이 저렴하고 이러한 인덱스가 메모리에 맞는 것이 필수적입니다.

검색을 자동 완성하는 동시에 Google이 수행하는 방법과 마찬가지로 가장 완성되었을 가능성이 높은 검색에 대한 결과를 표시하는 것은 두 가지 별개의 검색 문제로 간주되어야 합니다. 이전 검색을 자동 완성할 때 검색할 데이터 양이 검색되는 콘텐츠보다 아마도 훨씬 적기 때문에, 모든 것을 메모리에 저장하고 퍼지 검색을 제공하는 것이 더 가능해집니다. 자동 완성 검색은 전체 검색보다 훨씬 높은 검색 로드를 보게 되므로, 두 가지를 분리해서 유지하면 완전히 분리된 Elasticsearch 클러스터에서도 두 가지를 개별적으로 확장할 수 있습니다.

Soundcloud가 검색 경험을 개선했을 때, 검색 제안에 많은 노력을 기울였습니다. 이를 잘 구현함으로써, 검색 정밀도가 증가했을 뿐만 아니라 전체 검색을 지원하는 인프라의 로드가 눈에 띄게 감소했습니다. 사람들이 검색하는 것은 종종 Zipf 분포를 따르며, 일반적으로 고유 검색의 10%가 검색 볼륨의 90%를 차지합니다. 따라서, 최고의 검색 제안을 위한 전체 결과가 (애플리케이션 레이어에) 이미 캐시되어 "순간적으로" 표시될 수 있는 가능성이 높습니다.

Soundcloud의 검색 제안기 이면에 있는 수많은 엔지니어링은 Elasticsearch의 제안기 기능으로 이어집니다. Muir와 Willauer가 Query Suggestions with Lucene(Lucene을 이용한 쿼리 제안)에 대해 발표한 훌륭한 프레젠테이션도 더 자세히 살펴볼 가치가 있습니다.

멀티 테넌시

별개의 문서 모음이 있는 여러 고객 또는 사용자가 있으며, 사용자는 자신의 것이 아닌 문서를 검색할 수 없는 경우가 종종 있습니다. 이로 인해 모든 사용자가 자신만의 인덱스를 갖는 설계가 종종 발생합니다.

대부분의 경우, 이것은 너무 많은 인덱스로 이어집니다. 사용자당 인덱스를 구현하는 거의 모든 경우에, 하나의 더 큰 Elasticsearch 인덱스가 실제로 더 나을 것입니다. 작은 인덱스가 엄청나게 많이 있는 것에는 상당한 단점이 있습니다.

• 메모리 오버헤드를 무시할 수 없습니다. 수천 개의 작은 인덱스는 힙 공간을 많이 사용하게 됩니다. 파일 디스크립터의 수도 폭발적으로 증가할 수 있습니다.
• 많은 중복이 있을 수 있습니다. 역 인덱스가 어떻게 작동하는지, 그리고 Lucene이 어떻게 항목들을 세그먼트로 쓰고 압축하는지를 고려해 보세요.
• 스냅샷/복구는 현재 일련의 프로세스로, 인덱스당 오버헤드가 발생합니다. 수천 개의 아주 작은 인덱스를 스냅샷하는 것은 몇 개의 큰 인덱스를 스냅샷하는 것보다 훨씬 오래 걸립니다.

Sizing Elasticsearch(Elasticsearch 크기 조정)에는 샤딩 및 파티셔닝 전략에 대한 자세한 정보가 있으며, 참고 문헌도 훨씬 더 많이 있습니다. 차선책인 인덱스 설계로 애플리케이션을 수정하는 것은 상당한 노력이 필요하므로, 다른 접근 방식을 이해하는 것이 시간적으로 해볼 만한 가치가 있습니다.

멀티 테넌트 애플리케이션에 대해 사용자당 하나의 인덱스를 만들지 않는 편이 좋습니다.

스키마 프리/사용자 정의 스키마

여러 개별 고객이 있는 것과 관련하여, 서로 다른 사용자가 완전히 다른 문서를 가질 수 있는 사용 사례도 많이 볼 수 있습니다. 예를 들어, 사용자 설문 조사/질문지를 서비스로 제공하는 경우, 서로 다른 설문조사는 완전히 다른 필드를 가질 가능성이 있습니다.

종종, 이는 Elasticsearch의 "동적 매핑"을 사용하는 것으로 이어지는데, 때로는 Elasticsearch가 스키마리스라고 광고되기도 합니다. 그러나 Elasticsearch는 이면에서 여러분을 위해 매핑을 생성하게 되며, 이것이 너무 커지면 "매핑 폭발"로 이어져 문제가 될 수 있습니다. 대신, 문서의 값도 별개의 필드가 아니라 값이 되도록 하는 것이 중요합니다. 이에 대해서는 “Key/Value Woes(키/값 문제).

Elasticsearch는 인덱스 템플릿, 동적 템플릿, 다중 필드 등의 다양한 매핑 기능을 갖추고 있습니다. 사용해 보세요!

매핑을 사용하지 않더라도, Elasticsearch에서 여러분을 위해 어떤 매핑을 생성하는지 알아두세요.

사용자 정의 검색

사용자 정의 스키마와 관련되어, 최종 사용자가 사용자 정의 필터, 스코어링 및 집계를 사용하여 자신의 검색을 정의할 필요가 있는 경우가 종종 있습니다. 하나의 일반적인 접근법은 검색 요청을 특정 인덱스로 제한하고 그리고/또는 사용자 쿼리를 필터로 래핑하는 것입니다.

그렇게 할 때도, 사용자 정의 검색 요청을 정의할 때 CPU 집약적인 검색 표현, 메모리 호깅 또는 Elasticsearch 충돌을 유발하는 검색 표현과 같이 사용자가 큰 피해를 볼 수 있는 여러 가지 방법이 있습니다. 이러한 항목은 Six Ways to Crash Elasticsearch(Elasticsearch를 중단시키는 6가지 방법)와 Securing Your Elasticsearch Cluster(Elasticsearch 클러스터 보안)에서 다루고 있습니다.

사용자 정의 검색 요청에 주의하세요.

크롤링 및 문서 처리

데이터를 Elasticsearch로 가져오는 방법에는 여러 가지가 있습니다.

강은 Elasticsearch가 데이터베이스와 같은 소스에서 JDBC, 메시지 큐, Twitter 스트림 또는 크롤링 웹사이트를 통해 데이터를 가져오는 Elasticsearch 개념입니다. 시작하기는 매우 간단하지만, 이 접근 방식은 확장하고 프로덕션에서 운영하기에 어려움이 있다는 것이 금방 드러납니다. 이와 같이, 강은 더 이상 사용되지 않으며 Elasticsearch 외부에서 이러한 문제를 해결할 수 있는 방법을 찾아야 합니다. Logstash는 더 많은 시스템에 대한 지원을 계속 얻고 있으며 많은 강을 대체할 수 있습니다. 사용자 정의 애플리케이션의 경우, Elasticsearch에 데이터를 동기화하고 Elasticsearch 문서를 준비할 때 강과 같은 단순하고 일반적인 것으로는 충분하지 않을 것으로 예상되는 수많은 문제가 있습니다. 크롤링의 경우, 사람들은 Scrapy와 Nutch를 Elasticsearch와 함께 사용하고 있습니다.

이와 관련되어, Word 문서나 PDF와 같은 문서를 Elasticsearch가 색인할 수 있는 플레인 텍스트로 처리하고 변환합니다. Elasticsearch 내에서 이 변환을 수행하는 데 사용할 수 있는 “mapper-attachments” 플러그인이 있습니다. 그러나, 첨부 파일 플러그인이 편리하기는 하지만, 문서를 Elasticsearch로 보내기 전에 문서 변환을 수행하는 것이 좋습니다. 이를 통해 문서 변환 및 정제 방법을 가장 잘 제어할 수 있습니다. 이와 같은 문서 변환은 일반적으로 "내용 정제"의 "문서/텍스트 처리 파이프라인" 동안 첫 번째 단계 중 하나입니다. Elasticsearch로 보내는 문서는 이러한 "내용 정제/준비"의 결과여야 합니다. 즉, Elasticsearch가 최종 텍스트 처리 및 색인을 수행하도록 하는 것입니다. 문서 변환은 CPU 집약적이지만 쉽게 병렬화할 수 있습니다. Elasticsearch가 색인 및 검색에 시간을 할애하고 "업스트림" 클라이언트가 문서 변환을 수행하도록 하는 것이 좋습니다.

처리된 데이터를 Elasticsearch에 푸시하세요. 가져와서 Elasticsearch 내에서 처리하지 마세요.

요약

Elasticsearch에는 알아야 것이 많습니다. 때로는 무엇을 알 필요가 있는지 파악하기 어려울 수 있습니다.

이 글에서는, 몇 가지 일반적인 사용 사례와 그 모든 것에 대해 알아야 할 몇 가지 중요한 사항을 다루었습니다. 부디 여러분의 필요와 관련하여 새롭게 알아야 것을 찾으셨기를, Elasticsearch 애플리케이션을 프로덕션으로 전송하는 데 더 가까와지셨기를 바랍니다.