반응형
'기초부터 다지는 ElasticSearch 운영 노하우' 책을 읽고 정리한 내용입니다.
클러스터
클러스터란? 여러 개의 노드를 하나의 ElasticSearch처럼 동작하게 하는 것
- 클러스터 내의 노드들은 하나의 ElasticSearch처럼 동작하기 때문에 클러스터를 구성하는 어느 노드에 API요청을 해도 동일한 응답과 동작을 보장한다.
- 대부분 하나 이상의 노드로 클러스터를 구성하고 사용자 요청을 클러스터 단위로 처리
- 여러 개의 노드로 클러스터를 구성했을 때 장애 발생 시 대처가 가능하다. 즉 안정적으로 클러스터 유지가 가능
- 고유의 이름과 UUID를 갖는다.
- 두 가지의 고유 속성으로 인해 클러스터 내에 속한 노드가 서로 동일한 클러스터 안에 있음을 인지하고 클러스터링 한다.
> 클러스터 정보 확인하기
curl localhost:9200
{
"name" : "Yk_vIBB",
"cluster_name" : "786957060261:yoil-v1",
"cluster_uuid" : "iRLtHRo3Swqu8Oe3xvSipg",
"version" : {
"number" : "5.1.1",
"build_hash" : "73fcae5",
"build_date" : "2022-01-18T17:55:25.378Z",
"build_snapshot" : false,
"lucene_version" : "6.3.0"
},
"tagline" : "You Know, for Search"
}
name : 현재 요청에 응답한 노드 이름. 노드가 여러개면 노드별로 이름이 달라질 수 있다.
cluster_name : 클러스터 이름
cluster_uuid : 클러스터가 최초 생성될 때 자동으로 생성된다.
cluster_name, cluster_uuid는 클러스터의 모든 노드들이 동일한 값을 갖는다.
노드
노드란? 클러스터를 구성하는 논리적인 ElasticSearch 프로세스 하나를 의미. 클러스터와 마찬가지로 각각의 고유한 노드 이름과 UUID를 갖는다.
노드 역할
- 마스터 노드 : 클러스터 구성의 중심 노드. 클러스터 상태, 메타데이터 관리
- 한 대 이상으로 관리해야함
- 노드들 → 노드의 상태, 성능 정보, 샤드 정보를 마스터 노드에게 알린다.
- 마스터 → 정보를 수집하고 관리하면서 클러스터 안정성을 확보하기 위한 작업들 진행
- 데이터 노드 : 사용자 문서를 저장
- 사용자가 색인한 문서를 저장하고 검색 요청을 처리해서 결과를 돌려줌
- 요청받은 것 중에 자신이 처리할 수 있는 것과 없는 것을 구분해서 다른 데이터 노드들이 처리해야 하는 요청은 해당 데이터 노드로 전달한다. (어떤 데이터 노드로 요청하는지는 마스터 노드에서 받은 클러스터 전체 상태 정보를 바탕으로 한다.)
- 인제스트 노드 : 문서가 저장되기 전 문서 내용을 사전 처리하는 노드
- 데이터를 저장하기 전에 특정 필드의 값을 가공해야 할 경우에 동작한다.
- 코디네이트 : 사용자 요청을 데이터 노드로 전달 → 데이터 노드로부터 결과를 취합하는 노드
- 실제 데이터를 저장하거나 처리하진 않는다.
- 사용자 색인이나 검색 등의 모든 요청을 데이터 노드에 전달하는 역할
- 문서를 저장하지 않는 데이터 노드
< 참고 >
- 클러스터 내에서 메타데이터 관리 노드는 한 대이다. → 한 대의 마스터 노드와 마스터 후보 노드들로 구분된다.
- 마스터 후보 노드들은 마스터 노드에서 장애가 났을 때 새로운 마스터가 될 수 있다.
- 마스터 후보 노드들은 마스터 노드로부터 지속적으로 데이터를 전달받기 때문에 같은 메타데이터를 갖고 있다.
- 노드는 여러 개의 역할을 동시에 가질 수 있다.
- 클러스터 구성 시 역할에 따른 노드의 개수 설정으로 클러스터를 설정해야 한다.
인덱스와 타입
인덱스 : DataBase
타입 : Table
인덱스
- 인덱스의 이름은 클러스터 내에서 유일해야 한다.
- 인덱스에 저장된 문서들은 데이터 노드들에 분산 저장된다.
- 6.x 이후의 버전은 하나의 인덱스에 하나의 타입만 사용해야 한다.
- 멀티타입 허용 안 하는 이유 → 인덱스에 존재하는 서로 다른 타입(테이블)에서 동일한 이름의 Json 문서 필드를 만들 수 있어서 의도치 않은 검색 결과가 나타나는 문제가 발생할 수 있다.
- 5.x 까지는 하나의 인덱스에 여러 개의 타입을 사용할 수 있다.
샤드와 세그먼트
- ElasticSearch는 인덱스를 샤드로 나누고 데이터 노드에 샤드를 할당한다.
- 각각의 샤드에 문서를 저장하는 방식으로 데이터를 저장한다.
- 샤드 : 인덱스에 색인되는 문서들이 저장되는 논리적인 공간
- 세그먼트 : 샤드의 데이터들을 가지고 있는 물리적인 파일
- 샤드는 장애 대응을 위해서 원본인 프라이머리 샤드와 복제본인 레플리카 샤드를 구성하여 데이터의 안정성을 보장한다.
- 프라이머리 샤드 : 최초 인덱스를 생성할 때 개수를 결정하며 인덱스 생성 후 변경할 수 없음 (→ 클러스터 시나리오 파트. 중요)
- 인덱스에 저장되는 문서들은 해시 알고리즘에 의해 샤드들에 분산 저장 → 세그먼트라는 물리적 파일에 저장
- 문서 색인 → 시스템 메모리 버퍼 캐시에 저장 (검색 안 되는 상태) → ES refresh( → 성능 최적화) → 세그먼트 저장 (검색 가능)
- 세그먼트는 불변의 특성을 가진다 → 기존에 기록한 데이터를 업데이트하지 않는다.
- 최초 색인된 문서를 update 하는 경우 → 기존 데이터를 변경하는 것이 아님. 세그먼트는 불변이기 때문
- 기존의 version 1 문서는 disconnected 하고 version 2의 문서를 새로 색인하는 것이다.
- delete도 마찬가지로 disconnected 처리만 한다. → 데이터의 일관성 유지
- 단점)
- 시간이 지나면 작은 단위의 세그먼트들이 늘어나고 이는 사용자가 검색할 때마다 많은 수의 세그먼트들이 응답해야 한다는 단점이 생긴다.
- 불용 처리한 데이터들로 인해 세그먼트가 커진다.
- 단점 해결)
- ES는 백그라운드에서 여러 개의 작은 세그먼트들을 하나의 큰 세그먼트로 병합하는 작업이 이루어짐.
- 병합하면서 discennect 처리된 데이터들은 실제로 디스크에서 삭제된다.
- ID가 1,2,3인 문서가 각각 1,2,3번 세그먼트에 저장
- ID가 3인 문서를 삭제 → 삭제 플래그 기록 후 disconnect
- ID가 4번인 문서가 4번 세그먼트에 저장
- 1,2,3번 세그먼트가 병합되면서 삭제 플래그가 있는 3번을 제외한 1,2번 세그먼트로 병합된다.
프라이머리 샤드와 레플리카 샤드
엘라스틱 서치는 인덱스를 샤드로 나누고 샤드에 세그먼트 단위로 문서를 저장함
→ 장애 상황에 데이터 유실을 막을 수 있음. 데이터의 안정성 확보.
엘라스틱 서치 클러스터 서비스의 연속성을 유지하기 위해 프라이머리 샤드와 레플리카 샤드로 나눠서 관리함
프라이머리 샤드
- 6.x 버전까지는 5개의 프라이머리 샤드가 기본으로 설정됨. 그 이후는 1개
- 사용자의 문서는 각각의 프라이머리 샤드에 분산 저장된다.
- 프라이머리 샤드들은 구성될 때 샤드 번호를 부여 받음. 0부터 시작된다.
- 문서 색인 시 어떤 번호의 프라이머리 샤드에 문서를 저장할지 결정하는 알고리즘
- 프라이머리 샤드 번호 = Hash(문서의 id) % 프라이머리 샤드 개수
- 샤드 할당 해시함수를 이용해서 샤드 번호를 문서가 배정받기 때문에 인덱스 생성 후에는 프라이머리 샤드 개수를 변경할 수가 없다.
레플리카 샤드
- 프라이머리 샤드의 복제본
- 프라이머리 샤드와 동일한 문서를 가지고 있어서 사용자 요청에 응답 가능함
- 레플리카 샤드를 늘리면 응답 속도를 높을 수 있다.
- 프라미 어리 샤드가 저장된 노드와 다른 노드에 저장된다 → 동일한 노드에 원본 샤드오 복제 샤드가 존재하면 해당 노드가 장애가 나면 둘 다 죽게 되므로 다른 노드에 위치시켜야 한다.
매핑
- RDBMS의 스키마 개념
curl -X GET "localhost:9200/firstindex/_mapping?pretty"
- 정적 매핑(static mapping) : 매핑을 미리 정의해놓는
- 동적 매핑(dynamic mapping) : 미리 정의하지 않고 사용하는 것
- 미리 정의 안 한 상태에서 최초 색인된 문서 바탕으로 자동 매핑
- 매핑이 한번 생성되고 나면 이후부터는 기존 매핑 정보에 따라 문서가 생성되어야 한다.
반응형
'Dev > ElasticSearch' 카테고리의 다른 글
[ElasticSearch] 엘라스틱서치(3) - inverted index, analyzer (0) | 2022.11.15 |
---|---|
[ElasticSearch] 엘라스틱 서치 (1) - 기본 개념 훑어보기 (0) | 2022.09.29 |
댓글