[Elastic Stack] Elasticsearch 기본 개념

• 검색 엔진
• 분산처리
• 고가용성 제공
• 수평적 확장성
• JSON 기반의 REST API 제공
• 데이터 안정성
• 다양한 플러그인을 통한 확장 지원
• 준실시간 검색
• 트랜잭션이 지원되지 않음
• 사실상 조인을 지원하지 않음

엘라스틱서치 기본 동작 빠르게 둘러보기

[문서 색인]

_id를 지정하여 색인

_id 값은 이 문서를 인덱스 내에서 고유하게 식별하기 위한 값. 엘라스틱서치에 저장된 모든 문서가 _id 값을 가지고 있다.

PUT [인덱스 이름]/_doc/[_id값]
{
	[문서 내용]
}

 

 

_id를 지정하지 않고 색인

자동으로 _id 값을 생성해준다.

PUT [인덱스 이름]/_doc
{
	[문서 내용]
}

[문서 조회]

GET [인덱스 이름]/_doc/[_id값]

[문서 업데이트]

POST [인덱스 이름]/_update/[_id값]
{
	"doc":{
    	[문서 내용]
    }
}

POST [인덱스 이름]/_update/[_id값]
{
	"doc":{
    	"title" : "This is Test title"
    }
}

[문서 검색]

GET [인덱스 이름]/_search

GET my_index/_search
{
	"query":{
            "match": {
                "title" : "test title"
      	}
    }
}

[문서 삭제]

DELETE [인덱스 이름]/_doc/[_id값]

 

엘라스틱서치 구조 

문서 : 샤드안에 존재하며 엘라스틱서치가 저장하고 색인을 생성하는 JSON 문서를 뜻한다

인덱스 : 문서를 모아놓은 단위가 인덱스이다. 클라이언트는 이인덱스 단위로 엘라스틱서치에 검색을 요청하게 된다.

샤드 : 인덱스는 그 내용을 여러 샤드로 분리하여 분산 저장한다. 또한 엘라스틱서치는 고가용성(High Availability)을 제공하기 위해 샤드의 내용을 복제해둔다. 주 샤드(Primary Shard), 복제본 샤드(replication shard)라고 한다.

노드 : 엘라스틱서치 프로세스 하나가 노드 하나를 구성한다. 엘라스틱서치 노드 하나는 여러 개의 샤드를 가진다. 엘라스틱서치는 고가용성을 제공하기 위해 같은 종류의 샤드를 같은 노드에 배치하지 않는다. 

클러스터 : 노드 여러 개가 모여 하나의 클러스터를 구성한다.

 

노드의 역할

데이터 노드 : 샤드를 보유하고 샤드에 실제 읽기와 쓰기 작업을 수행하는 노드를 라고 한다.
마스터 노드 : 클러스터를 관리하는 중요한 역할을 하는 노드를 라고 한다. 마스터 노드는 마스터 후보 노드 중에서 1대가 선출된다.
조정노드 : 클라이언트의 요청을받아서 데이터 노드에 요청을 분배하고 클라이언트에게 응답을 돌려주는 노드는 

 

 

클러스터 구성

Elasticsearch의 노드들은 클라이언트와의 통신을 위한 http 포트(9200 ~ 9299), 노드 간의 데이터 교환을 위한 tcp 포트

(9300 ~ 9399) 총 2개의 네트워크 통신을 열어두고 있다. 일반적으로 1개의 물리 서버마다 하나의 노드를 실행하는 것을 권장하고 있다. 

3개의 다른 물리 서버에서 각각 1개 씩의 노드를 실행 / 1개의 서버에서 여러개의 노드 실행

 

마스터 노드(Master Node)

Elasticsearch 클러스터는 하나 이상의 노드들로 이루어진다. 이 중 하나의 노드는 인덱스의 메타 데이터, 샤드의 위치와 같은 클러스터 상태 정보를 관리하는 마스터 노드의 역할을 수행한다. 클러스터마다 하나의 마스터 노드가 존재하며 마스터노드의 역할을 수행할 수 있는 노드가 없다면 클러스터는 작동이 정지된다.

 

데이터 노드(Data Node)

데이터 노드는 실제로 색인된 데이터를 저장하고 있는 노드.

Hot data node - 엘라스틱서치의 시계열 데이터를 저장 / 자주 사용되는 데이터 / 읽기 쓰기 모두 빠름

cold data node - 자주 사용되지 않는 데이터(읽기 전용 인덱스)를 저장 / 성능이 낮은 하드웨어 사용 가능

 

Index

Document를 저장하는 논리적 구분자(RDB의 Table 느낌)

하나의 인덱스의 다수의 Document가 포함 

Document

ES에서 실제 데이터를 저장하는 단위(RDB의 ROW 느낌)

Document CRUD

PUT test_index2/_doc/1
{
    "name" : "test",
    "text" : "This is text"
}

test_index2 : index 이름
_doc : 엔드포인트 구분을 위한 예약어, 
1 : 인덱싱할 도규먼트 고유 아이디

 

REST API 구조와 같으며 나머지 명령도 쉽게 구현 가능하다.

 

Data Stream

 

여러개의 인덱스들이 모인 집합체?라고 보면 될듯.

아니면 하나의 인덱스를 계속해서 사용할 수 없으니(용량이나 관리차원에서) 이걸 사용해서 관리하는거 아닐까라는 생각

 

Elasticsearch REST API 응답코드

코드	상태	해결방법
200, 201	정상적으로 수행
4XX	클라이언트 오류	클라이언트에서 문제점 수정
404	요청한 리소스가 없음	인덱스 OR 도큐먼트 존재 확인
405	요청 메소드를 지원하지 않음	API 사용법 다시 확인
429	요청 과부화(busy)	재전송, 노드 추가 같은 조치
5xx	서버 오류	엘라스틱서치 로그 확인 후 조치

 

Mapping

RDB에서 테이블을 만들 떄 반드시 스키마 설계가 필요하다. 여기서 말하는 스키마는 테이블을 구성하는 구성요소 간의 논리적인 관계와 정의를 의미하는데 엘라스틱서치에서도 RDB의 스키마와 비슷한 형태로 제공하는 것이 바로 Mapping

엘라스틱서치가 검색 엔진으로 전문 검색과 대용량 데이터를 빠르게 실시간 검색할 수 있는 이유

** Dynamic Mapping vs Explicit Mapping

예시로 Ingest Pipeline에서 Key Value 프로세서를 이용해서 다양한 필드를 파싱했다.

이를 인덱스에 자동으로 매핑이 되려면 Mapping : true로 하여 동적 매핑을 설정해야하지만 이는 성능부화가 올 수 있기에 보통 false로 해놓고 Index Management에서 Mapping을 명시해주는 것이 좋다.

 

Index Templete

인덱스 템플릿은 주로 설정이 동일한 복수의 인덱스를 만들 때 사용한다. 관리 편의성, 성능 등을 위해 인덱스를 파티셔닝하는 일이 많은데 이때 파티셔닝되는 인덱스들은 설정이 같아야 한다. 설정이 동일한 인덱스를 매번 일일이 작성하는 것은 비효율적일 뿐만 아니라 실수를 유발할 수 있다. 

 

** 템플릿에서 mapping 필드를 수정했는데 Discover에서 수정한 필드가 아직 unmapped field인 경우

인덱스 템플릿으로 설정한 Index나 Data Streams 같은 경우 지금 현재도 계속해서 로그를 받고 있기 때문에 운용중인 것에 수정했다고 바로 적용되진 않는다. 새롭게 인덱스를 만들어야 가능한데 Data Streams 같은 경우

POST 데이터스트림이름/_rollover

 

를 이용해서 새로운 인덱스를 만들면 그때부터 mapped field에 매핑한 필드가 보일 것이다.

 

Index settings에서 

{
	"index" : {
    	"number_of_replicas" : "1",
        "default_pipeline" : "logs-test-pipeline"
    }
}

을 해주면 Ingest pipeline까지 적용할 수 있다.