Elasticsearch

[kanteluv]

💡 Elasticsearch란 아파치 루씬(Lucene) 기반의 오픈소스 실시간 분산 검색 엔진

• JSON 기반의 비정형 데이터 분산 검색 및 분석을 지원
• 설치와 서버 확장이 매우 편리
• 실시간 검색 서비스 지원, 분산 및 병렬처리, 멀티테넌시 기능을 제공
• 다양한 기능을 플러그인 형태로 구현하여 적용가능
• 클러스터로 구성할 수 있음
• 검색 대상의 용량이 증가했을 때 대응하기가 수월

특징

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

• 구성 시 보통 3개 이상의 노드(Elasticsearch 서버)를 클러스터로 구성
• 데이터를 샤드(shard)로 저장 시 클러스터 내 다른 호스트에 복사본(replica)을 저장함
  → 하나의 노드가 죽거나 샤드가 깨져도 복제되어 있는 다른 샤드를 활용하므로 데이터 안정성 보장
• 데이터의 분산과 병렬처리가 되므로 실시간 검색 및 분석 가능
• 노드(Elasticsearch 서버)를 수평적으로 늘릴 수 있게 설계됨
  → 더 많은 용량이 필요한 경우 노드를 클러스터에 추가가능

2) 고가용성

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

3) 멀티 테넌시

• 클러스터는 여러개의 인덱스(RDBMS의 데이터베이스와 비슷)들을 저장하고 관리
  → 하나의 쿼리나 그룹 쿼리로 여러 인덱스의 데이터를 검색가능

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

• 복잡한 현실 세계의 요소들을 구조화된 JSON 문서 형식으로 저장
• 모든 필드는 기본적으로 인덱싱
  → 모든 인덱스들은 단일 쿼리로 빠르게 검색 및 활용할 수 있음
• NoSQL나 RDBMS와 같은 스키마 개념이 없음
• 사용자의 데이터가 어떻게 인덱싱 될 것인지를 사용자가 커스터마이징 가능

5) 플러그인 형태로 구현

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

2. Elasticsearch 구조

2-1. 논리적 구조

1) 도큐먼트(Document)

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

2) 타입(Type)

• 여러개의 Document가 모여서 한개의 Type(RDBMS의 Table)
• Elasticsearch 7.0부터 Type이 완전히 사라짐
• 현재 Index가 RDBMS의 Table과 Database 역할을 한다고 생각하면 됨

3) 필드(Field)

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

4) 매핑(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)

• 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개의 샤드로 나누어서 저장함(변경 가능)
  1. 인덱스를 여러 샤드로 나누어 저장함
  2. 콘텐츠 볼륨의 수평 분할/확장이 가능
  3. 작업을 여러 샤드에서 수행함(병렬화)
  4. 성능/처리량을 늘릴 수 있음
• 프라이머리 샤드(Primary Shard)와 레플리카 샤드(Replica Shard)로 구분

1. 프라이머리 샤드(Primary Shard)

• 데이터의 원본
• 엘라스틱서치에서 데이터 업데이트 요청을 날리면 반드시 프라이머리 샤드에 요청
  → 해당 내용은 레플리카에 복제
• 검색 성능 향상을 위해 클러스터의 샤드 갯수를 조정하는 튜닝을 함

2. 레플리카 샤드(Replica Shard)

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

3) 세그먼트(Segment)

• 엘라스틱서치에서 문서의 빠른 검색을 위해 설계된 자료구조
• 각 샤드는 다수의 세그먼트로 구성
• 엘라스틱서치에서 데이터(Document)를 저장하면, 엘라스틱서치는 이것을 메모리에 모아두고
  새로운 세그먼트를 디스크에 기록하여 검색을 리프레쉬(refresh)함
  → 이로 인해 새로운 검색 가능한 세그먼트가 생성
• 샤드에서 검색 시, 먼저 각 세그먼트를 검색하여 결과를 조합한 후 최종 결과를 해당 샤드의 결과로 리턴
• 세그먼트는 불변의 성질을 가짐
  → 데이터가 업데이트되면 삭제되었다고 마크만 하고 실제로는 새로운 데이터를 가르킴
  → 그리고 삭제되었다고 마크된 데이터는 디스크에 남아있다가 백그라운드에서 주기적으로 또는
  특정 임계치를 넘기면 더이상 필요없어진 데이터들을 정리하고 새로운 세그먼트로 병합 한 후
  세그먼트를 삭제하며 이때 비로소 디스크에서 완전히 삭제됨 → 이게 세그먼트 병합(Segment Merge)
• 세그먼트 병합 시에는 새로운 세그먼트를 만들 공간이 있어야 함
  → 디스크가 꽉 찬 상태에서는 수행할 수 없음
  → 세그먼트 병합은 시스템 자원을 많이 쓰는 부담스러운 작업
  → 시스템 자원이 여유로울 때 시스템에 영향을 주지 않는 선에서 진행함