Elasticsearch는 빠릅니다. Elasticsearch는 Lucene을 기반으로 구축되기 때문에, 풀텍스트 검색에 뛰어납니다. Elasticsearch는 또한 거의 실시간 검색 플랫폼입니다. 이것은 문서가 색인될 때부터 검색 가능해질 때까지의 대기 시간이 아주 짧다는 뜻입니다. 이 대기 시간은 보통 1초입니다. 결과적으로, Elasticsearch는 보안 분석, 인프라 모니터링 같은 시간이 중요한 사용 사례에 이상적입니다.
Elasticsearch는 본질상 분산적입니다. Elasticsearch에 저장된 문서는 샤드라고 하는 여러 다른 컨테이너에 걸쳐 분산되며, 이 샤드는 복제되어 하드웨어 장애 시에 중복되는 데이터 사본을 제공합니다. Elasticsearch의 분산적인 특징은 수백 개(심지어 수천 개)의 서버까지 확장하고 페타바이트의 데이터를 처리할 수 있게 해줍니다.
<aside> 💡 Elasticsearch 샤드는 Lucene 색인이다. 단일 Lucene 색인이 포함할 수 있는 문서 수의 최대 한도가 있다. LUCENE-5843에 따르면 2,147,483,519개(= Integer.MAX_VALUE - 128)이다. {ref}/cat-shards.html[_cat/shards] API를 사용하여 샤드 크기를 모니터링할 수 있다.
</aside>
Elasticsearch는 광범위한 기능 세트와 함께 제공됩니다. 속도, 확장성, 복원력뿐 아니라, Elasticsearch에는 데이터 롤업, 인덱스 수명 주기 관리 등과 같이 데이터를 훨씬 더 효율적으로 저장하고 검색할 수 있게 해주는 강력한 기본 기능이 다수 탑재되어 있습니다.
Elastic Stack은 데이터 수집, 시각화, 보고를 간소화합니다. Beats와 Logstash의 통합은 Elasticsearch로 색인하기 전에 데이터를 훨씬 더 쉽게 처리할 수 있게 해줍니다. Kibana는 Elasticsearch 데이터의 실시간 시각화를 제공하며, UI를 통해 애플리케이션 성능 모니터링(APM), 로그, 인프라 메트릭 데이터에 신속하게 접근할 수 있습니다.
AWS Elasticsearch Service? Open Search?
Elastic의 라이선스 정책으로 변경됨 ELv2 이슈로 더이상의 Managed Service가 불가능 해졌기에 ALv2 기반의 마지막 버전을 기반으로 별도로 개발된 서비스 입니다. Elasticsearch 및 Apache Solr와 마찬가지로 OpenSearch는 Apache Lucene 검색 라이브러리를 기반으로 합니다. OpenSearch 및 OpenSearch 대시보드는 원래 Elasticsearch 7.10.2 및 Kibana 7.10.2에서 파생되었습니다.
💡 현재까지 Elasticsearch가 제공하는 모든 기능과 동일한 기능을 제공하지만 버전이 올라감에 따라 변경 될 수 있다.
데이터가 색인되면 만들어 지는 Inverted Index, Doc Value, Origin Doc을 저장 하고 있는 파일 단위를 말한다.
Inverted Index : ex) {token: name, doc id :1, 2}
Inverted Index는 하나의 거대한 파일이 아닌 여러개의 작은 파일 단위로 저장됨
생성된 세그먼트는 immutable함
문서가 업데이트 된다면?
검색엔진에 Update는 존재하지 않음 : Delete & Insert로 진행
삭제의 경우 Filter 값을 주어 변경해주는 형태로 처리
문서 업데이트시 세그먼트는 병합과정을 거친다.
이때 디스크 I/O와 CPU 사용량이 매우 높음
오래된 세그먼트는 크기가 크고, 최근에 생성된 세그먼트를 상대적으로 크기가 작다.
오래된 문서를 삭제하는 것은 더욱 비용이 크다
날짜별로 저장 영역(인덱스)를 구분하는 것이 바람직하다.
여러 인덱스를 묶어서 검색할수 있는 멀티 테넌시를 지원함.(물론 Index간 조인은 매우 지양한다)
Elasticsearch의 Node는 크게 5가지로 구분됩니다.
마스터(master)
쿼리 해석
데이터 집계
데이터 저장
캐시 저장 관리
데이터 병합
저장 삭제 병합
클러스터 관리
데이터(data)
데이터 저장 및 병합
캐시 저장
인제스트(Ingest)
쿼리 해석
데이터 전처리
코디네이팅(Coordinating)
Get 쿼리 해석
데이터 집계
Coordinating Node
Elasticsearch는 기본적으로 Query에 대한 해석과 행동을 Master Node가 진행 한다. 따라서 Indexing 및 Searching 동작이 많은경우 Data Node보다 Master Node의 부하가 상당히 크다. 이때 GET Method에 대한 처리를 진행합에 있어 찾아야 하는 데이터가 어떤 Shard에 있는지 확인하고 보다 빠르게 찾을 수 있게 하며 찾은 데이터를 병합 처리해주는 노드가 Coordinating노드 이다. Coordinating Node가 하는 역할은 아래와 같다.
검색 요청과 Bulk Indexing과 같이 흩어져 있는 데이터를 찾아야 할때 해당 노드로 향하게끔 조정한다.
각각 데이터 노드는 요청을 자체적으로 처리후 Coordinating Node에 전달하고 Coordinating Node가 해당 데이터를 하나의 데이터로 정제하여 반환한다.
Coordinating Node는 Master나 Data가 될 수 없다
데이터를 모으고 조작하는 작업이 많기 때문에 CPU 사용량이 많다
본질적으로 Load Balancer와 하는 역할이 같다
Ingest Node
Elasticsearch에 Query DSL이 실행 되면(Post, Put) Master에서 색인을 위한 전처리와 Indexing에 필요한 추가적인 데이터를 생성하여 넣는데 이러한 부하를 줄이기 위하여 Ingest노드가 생겼다. Ingest 노드가 하는 역할은 아래와 같다.
Pre Processing 파이프라인을 실행하고 하나 또는 하나 이상의 Processor들을 모으는 작업을 한다.
Document가 Indexing 되기 전에 변형 하는 별도의 Pipeline으로 생성이 가능하다.
Ingest 노드가 별도로 없을 경우 Master에서 해당 작업을 진행 하는데 실제 많은 리소스를 잡아 먹는다. 이때 Master의 부하를 상당부분 줄여준다.
인제스트 노드(Ingest Node)는 엘라스틱서치에 데이터를 인덱싱하기 전에 다양한 전처리를 할 수 있는 메커니즘을 제공하기 때문에 실운영 환경에서 아주 중요한 노드 타입입니다.
색인 파이프 라인
보통 Elasticsearch에 데이터를 색인 하기 위하여 Logstah나 Beat를 많이 사용한다. 일반적인 로그를 수집하여 색인 하는 경우 위와 같은 형태로 각 App Server에서 발생한 로그를 Beat 또는 Logastash를 활용하여 Queue(Kafka, MQ, Redis etc...)에 넣고 데이터를 Subscription 하고 있는 Consumer가 가져와 Elasticsearch에 색인한다. 따라서, 아래와 같은 개념이 생긴다.
Metadata
검색을 위한 원천 데이터(비정형 또는 정형)
RDBMS 또는 NoSQL(MongoDB, DynamoDB...)
Publisher
검색을 위한 데이터 전처리
Queue
부하 절감
다양한 Consumer을 활용한 DW 파이프라인
Consumer
Search Engine에 색인을 위한 Indexer
Search Engine
검색엔진(Cloud Search, Elasticsearch, Open Search...)
온프레미스라면 Solr와 Elasticsearch
형태소 분석기란?
형태소란 의미를 가지는 최소 단위를 뜻한다. 검색 엔진에 있어서 사용자의 질의 분석이 매우 중요한데 이를 도와주는 분석기로 색인된 데이터에서 의미있는 Terms을 추출하여 별도의 Score를 부여하고 사용자의 질의 의도를 파악하는데 도움을 준다. 대표적으로 Nori와 은전한닢이 있으며 사전은 Mecab을 사용한다.
