Elasticsearch 개념 및 구조

이번 글에서는 그동안 사용해왔던 Elasticsearch의 개념 및 구조에 대한 정리를 해보고자 한다.

 

1. Elasticsearch 개념

1-1. 소개

Elasticsearch란 아파치 루씬(Lucene) 기반의 오픈소스 실시간 분산 검색 엔진으로 JSON 기반의 비정형 데이터 분산 검색 및 분석을 지원한다. 설치와 서버 확장이 매우 편리하며, 실시간 검색 서비스 지원, 분산 및 병렬처리, 그리고 멀티테넌시 기능을 제공하고 다양한 기능을 플러그인 형태로 구현하여 적용할 수 있는 것이 큰 특징이다. 또한 클러스터로 구성할 수 있기 때문에 검색 대상의 용량이 증가했을 때 대응하기가 매우 수월하다. 

Elasticsearch는 현재 웹 문서 검색, 소셜 데이터 분석, 쇼핑몰 검색 등에 활용되고 있으며, 빅데이터 분석/처리 및 MSA 환경의 로그 모니터링 등에도 활용되고 있다. 

 

1-2. 특징

1) 분산/확장성/병렬처리

Elasticsearch 구성 시 보통 3개 이상의 노드(Elasticsearch 서버)를 클러스터로 구성하며, 데이터를 샤드(shard)로 저장 시 클러스터 내 다른 호스트에 복사본(replica)을 저장해 놓기 때문에 하나의 노드가 죽거나 샤드가 깨져도 복제되어 있는 다른 샤드를 활용하기 때문에 데이터의 안정성을 보장한다. 

또한 데이터의 분산과 병렬처리가 되므로 실시간 검색 및 분석을 할 수 있고, 노드(Elasticsearch 서버)를 수평적으로 늘릴 수 있게 설계되어 있기 때문에 더 많은 용량이 필요한 경우 노드를 클러스터에 추가할 수 있다. 

 

2) 고가용성

Elasticsearch는 동작중에 죽은 노드를 감지하고 삭제하며 사용자의 데이터를 안전하고 접근 가능하도록 유지하기 때문에, 동작중에 일부 노드에 문제가 생기더라도 문제 없이 서비스를 제공한다.

 

3) 멀티 테넌시

클러스터는 여러개의 인덱스(RDBMS의 데이터베이스와 비슷)들을 저장하고 관리하며, 하나의 쿼리나 그룹 쿼리로 여러 인덱스의 데이터를 검색할 수 있다. 

 

4) 문서(Document) 중심 & 스키마(Schema) 미존재

복잡한 현실 세계의 요소들을 구조화된 JSON 문서 형식으로 저장한다. 모든 필드는 기본적으로 인덱싱되며, 모든 인덱스들은 단일 쿼리로 빠르게 검색 및 활용할 수 있다. 

또한 NoSQL나 RDBMS와 같은 스키마 개념이 없으며, 사용자의 데이터가 어떻게 인덱싱 될 것인지를 사용자가 커스터마이징 할 수 있다. 

 

5) 플러그인 형태로 구현

검색엔진을 직접 수행하지 않고, 필요한 기능에 대한 플러그인을 적용하여 기능을 확장할 수 있다. 예를 들면 외부에서 제공하는 형태소 분석기나 REST API를 구현하여 적용할 수 있다.

 

---

2. Elasticsearch 구조

2-1. 논리적 구조

1) 도큐먼트(Document)

Elasticsearch 데이터 최소 단위(RDBMS의 Row와 비슷). JSON 오브젝트 하나. 하나의 Document는 다양한 필드로 구성되어 있으며, 이 필드에는 데이터 필드에 해당하는 데이터 타입이 들어감. 중첩구조를 지원하기 때문에 Document 내부에 Document가 들어가는 것도 가능함.

 

2) 타입(Type)

여러개의 Document가 모여서 한개의 Type을 이룸(RDBMS의 Table과 비슷). 하지만 Elasticsearch 7.0부터 Type이 완전히 사라졌으며, 현재 Index가 RDBMS의 Table과 Database 역할을 한다고 생각하면 됨.

 

3) 필드(Field)

필드(Field)는 Document에 들어가는 데이터 타입으로 RDBMS의 열(Column)과 비슷하다. 하지만 Elasticsearch의 필드는 RDBMS보다 동적이다. RDBMS에서는 하나의 열(Column)이 하나의 데이터 타입만 가질 수 있지만, Elasticsearch에서는 하나의 필드(Field)가 여러개의 데이터 타입을 가질 수 있다. 

 

4) 매핑(Mapping)

매핑(Mapping)은 필드와 필드의 속성을 정의하고 색인 방법을 정의한다. 매핑 정보에 여러가지 데이터 타입 지정이 가능하지만 필드명 자체는 중복이 불가능하다.

 

4) 인덱스(Index)

여러개의 Type이 모여 한개의 Index를 이룸(RDBMS의 Database와 비슷). Elasticsearch 6.1부터는 하나의 Index는 하나의 Type만 가질 수 있기 때문에 Database + Table의 역할.

RDBMS는 쿼리 하나로 여러 데이터베이스의 데이터를 동시에 조회할 수 없지만, Elasticsearch는 가능함(멀티테넌시)

Elasticsearch를 클러스터(분산환경)으로 구성했을 경우 Index는 여러 노드에 분산 저장/관리된다. 기본설정은 5개의 프라이머리 샤드(Prmiary Shard)와 1개의 레플리카 샤드(Replica Shard)를 생성한다. 샤드 수는 인덱스 생성 시 옵션 값을 이용하여 변경 가능함.

 

 

2-2. 물리적 구조

1) 노드(Node)

노드(Node)는 Elasticsearch 클러스터에 포함된 단일 서버로서 데이터를 저장하고 클러스터의 색인화 및 검색 기능에 참여한다. 노드는 클러스터처럼 이름으로 식별되며, 원한다면 특정 노드 이름으로 정의할 수 있으며 관리의 목적에 맞게 정의한다. 

RDBMS와는 다르게 여러개의 노드로 구성된 엘라스틱서치 클러스터는 관리하는 데이터가 커져도 노드를 추가시켜서 대용량 처리를 가능하게 해준다. 

개발 및 테스트 환경에서는 Elasticsearch의 단일노드 구성으로도 충분하며, Elasticsearch는 기본적으로 싱글노드에서 모든 역할을 수행할 수 있게 설정이 가능하다. 하지만 실제 운영환경에서는 대부분 다수의 노드를 클러스터링해서 구성하기 때문에 각각의 목적에 맞는 노드를 적절히 설정해 운영하는 것이 좋다.

엘라스틱 서치에서 제공해주는 노드는 다음과 같다.

 

1. 마스터 노드(Master Node) : 클러스터 관리 노드. 노드 추가/제거, 인덱스 생성/삭제 등 클러스터의 전반적 관리 담당. 여러 개의 마스터 노드를 설정하면 하나의 마스터 노드로 작동됨. 설정하려면 elasticsearch.yml 의 node.master: true로 설정

2. 데이터 노드(Data Node) : 데이터(Document)가 저장되는 노드. 데이터가 분산 저장되는 물리적인 공간인 샤드가 배치되는 노드. 색인/검색/통계 등 데이터 작업 수행(리소스가 많이 필요함. 모니터링 필수). 마스터와는 분리 필요. 설정하려면 elasticsearch.yml의 node.data : true로 설정

3. 코디네이팅 노드(Coordinating Node) : 사용자의 요청을 받고 라운드로빈(Round Robin)방식으로 분산시켜주는 노드. 클러스터에 관련된 것은 마스터 노드로 넘기고 데이터 관련된 것은 데이터 노드로 넘김. 설정하려면 elasticsearch.yml 내부의 노드 종류 관련 옵션 전부 false

4. 인제스트 노드(Ingest Node) : 문서 전처리 작업 수행. 인덱스 생성 전 문서의 형식 변경을 다양하게 할 수 있음(스크립트로 전처리 파이프라인 구성). 설정하려면 elasticsearch.yml의 node.ingest: true로 설정

 

 

2) 샤드(Shard)

인덱스(index) 내부에는 색인된 데이터들이 존재하는데 이 데이터들은 하나로 뭉쳐서 존재하지 않고 물리적 공간에 여러개의 부분들로 나뉘어서 존재한다. 이러한 부분들을 샤드(Shard)라고 한다. 

엘라스틱서치는 기본적으로 인덱스를 5개의 샤드로 나누어서 저장한다(변경 가능). 인덱스를 여러 샤드로 나누어 저장하기 때문에 콘텐츠 볼륨의 수평 분할/확장이 가능하고, 작업을 여러 샤드에서 수행하기 때문에(병렬화) 성능/처리량을 늘릴 수 있다. 

샤드는 프라이머리 샤드(Primary Shard)와 레플리카 샤드(Replica Shard)로 구분된다. 

 

1. 프라이머리 샤드(Primary Shard) : 데이터의 원본. 엘라스틱서치에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청을 하게 되고 해당 내용은 레플리카에 복제된다. 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정하는 튜닝을 한다.

2. 레플리카 샤드(Replica Shard) : 프라이머리 샤드의 복제본. 기존 원본 데이터가 무너졌을 때 그 대신 쓰면서 장애 극복 역할을 수행함. 기본적으로 원본인 프라이머리 샤드와 동일한 노드에 배정되지 않음. 

 

3) 세그먼트(Segment)

세그먼트(Segment)란 엘라스틱서치에서 문서의 빠른 검색을 위해 설계된 자료구조이다. 각 샤드는 다수의 세그먼트로 구성되어 있다.
엘라스틱서치에서 데이터(Document)를 저장하면, 엘라스틱서치는 이것을 메모리에 모아두고 새로운 세그먼트를 디스크에 기록하여 검색을 리프레쉬(refresh)한다. 이로 인해 새로운 검색 가능한 세그먼트가 만들어지게 된다.

샤드에서 검색 시, 먼저 각 세그먼트를 검색하여 결과를 조합한 후 최종 결과를 해당 샤드의 결과로 리턴하게 된다. 

세그먼트는 불변의 성질을 가지고 있기 때문에 데이터가 업데이트되면 실제로는 삭제되었다고 마크만 하고 새로운 데이터를 가르킨다. 그리고 삭제되었다고 마크된 데이터는 디스크에 남아있다가 백그라운드에서 주기적으로 또는 특정 임계치를 넘기면 더이상 필요없어진 데이터들을 정리하고 새로운 세그먼트로 병합 한 후 세그먼트를 삭제하며 이때 비로소 디스크에서 완전히 삭제되는데 이를 세그먼트 병합(Segment Merge)라고 한다. 세그먼트 병합 시에는 새로운 세그먼트를 만들 공간이 있어야 하기 때문에 디스크가 꽉 찬 상태에서는 수행할 수 없으며, 세그먼트 병합은 시스템 자원을 많이 쓰는 부담스러운 작업이므로 시스템 자원이 여유로울 때 시스템에 영향을 주지 않는 선에서 진행한다. 

 

 

 

 

---

참고

https://www.elastic.co/guide/kr/elasticsearch/reference/current/gs-basic-concepts.html

기본 개념 | Elasticsearch 설명서 [5.4] | Elastic

 

https://brownbears.tistory.com/3

Elastic search란?

https://victorydntmd.tistory.com/308

[Elasticsearch] 기본 개념잡기

https://nesoy.github.io/articles/2019-01/ElasticSearch-Document

Elastic Search 데이터 처리

https://velog.io/@jakeseo_me/%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-3-%EC%97%98%EB%9D%BC%EC%8A%A4%ED%8B%B1%EC%84%9C%EC%B9%98-%EC%9A%A9%EC%96%B4-%EB%B0%8F-%EA%B0%9C%EB%85%90-%EA%B0%84%EB%8B%A8%ED%9E%88-%EC%82%B4%ED%8E%B4%EB%B3%B4%EA%B8%B0

[엘라스틱서치 알아보기 #3] 엘라스틱서치 용어 및 개념 간단히 살펴보기

https://rudecamel.tistory.com/17

ElasticSearch index 적정 샤드 결정하기

https://www.elastic.co/kr/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

How many shards should I have in my Elasticsearch cluster?

http://blog.naver.com/PostView.nhn?blogId=takane7&logNo=221438265860&parentCategoryNo=&categoryNo=6&viewDate=&isShowPopularPosts=true&from=search

엘라스틱서치 (Elasticsearch) 기본개념 이해하기

https://www.ridicorp.com/blog/2018/11/20/index-aliases/

Elasticsearch의 색인 별명 활용 팁