Elasticsearch 공부 정리 - 1

개념 정리

1. Index

• 모든 document들은 인덱스 내 저장됨
• 인덱스는 모든 document들을 논리적으로 그룹화시키며 확장성(scalability)과 가용성(availability)과 관련된 설정 옵션들을 제공
• 정리를 하자면, 인덱스는 유사한 특성을 가지며 논리적으로 관련이 있는 document들의 모음
• 인덱스가 저장할 수 있는 document들의 개수 제한이 없는 편
• 인덱스는 검색 쿼리(search query)가 실행되는 주체

 

2. Document

• 데이터는 document 형태로 저장되어 있으며 이는 JSON 형태로 생각하면 됨
• document들은 인덱스를 통해 그룹화
• 사용자가 elastic search 내 저장한 JSON 데이터는 "_source"라는 필드 내 저장
• document를 색인할 때, 사용자가 Elastic Search 내 저장한 JSON 데이터와 함께 메타데이터가 저장됨

 

3. Node

• elastic search 내 데이터를 저장하고 있는 객체
• 각각의 노드는 데이터의 일부를 저장하고 있음
• 노드가 하나 밖에 없더라도 노드는 항상 클러스터를 형성해야 함

 

4. Cluster

• 유사한 특성을 가지며 논리적으로 관련된 노드들의 집합체
• 클러스터를 통해 노드들에 데이터를 분산시키고 노드들과 데이터들을 매핑할 수 있음
• 클러스터 덕분에 각 시스템의 디스크 용량이 수백 기가바이트에 불과하더라도 테라바이트의 데이터를 저장 가능
• 클러스터끼리는 기본적으로 서로 독립적이며 정말 가끔 cross-cluster 검색을 진행하는데 이런 경우는 정말 드물다고 함
• 노드는 언제나 클러스터를 형성하기 때문에 새로운 노드가 생겼을 때 설정에 따라 기존에 생성된 클러스터의 일부분이 되거나 새로운 클러스터를 형성함

 

5. Sharding

• 인덱스를 작은 조각들로 나누는 방법이며 각각의 조각을 shard라고 부름
• 각각의 shard들은 독립적인 인덱스라고 봐도 됨
• sharding은 노드, 클러스터 레벨이 아닌 인덱스 레벨에서 시행되는데 이는 각각의 인덱스가 포함하는 document들의 개수가 다르기 때문
• The main purpose of sharding is to horizontally scale the data volume
• sharding을 통해 수많은 데이터를 하나의 인덱스 내 저장 가능
• shard는 최대 20억 개의 document들을 저장 가능
• sharding이 query parallelization을 해주는 덕분에 검색 쿼리를 여러 샤드에서 동시에 실행할 수 있으며 성능 및 처리량을 향상함
• 7.0.0 버전 이후부터는 인덱스가 기본적으로 하나의 shard를 가지며 이전 버전에는 5개의 shard를 가지는 것이 디폴트였음 (over-sharding 문제로 하나의 shard를 가지는 것이 디폴트로 변함)

 

5.1 Sharding 예시 #1

상황: 1TB의 데이터를 저장하고 싶지만 현재로서는 500GB의 저장공간을 가진 단일 노드만 존재

해결방법: 충분한 저장공간을 지닌 노드를 추가할 경우, elastic search는 1TB의 데이터를 두 개의 노드 내 저장할 수 있음. 즉, 노드를 추가할 경우 클러스터 내 충분한 저장공간이 생김

 

5.2 Sharding 예시 #2

상황: 500GB 저장공간을 가진 노드가 두 개 존재하고 600GB의 데이터를 지닌 인덱스가 존재하는 상황 (단일 샤드의 크기가 600GB이므로 두 노드 모두에 저장될 수 없음)

해결방법: 인덱스를 두 개의 300GB shard로 나누어 디스크 공간 부족 없이 두 노드 내 각각의 shard를 저장 가능 (각각의 shard들을 저장하더라도 여유공간이 있으므로 다른 인덱스의 shard도 저장 가능)

 

Sharding 예시 #2

 

* shard는 아무 노드에 저장 가능하기 때문에, 하나의 인덱스가 5개의 shard로 나뉘어있고 5개의 노드가 있다고 해서 반드시 각각의 shard가 각각의 node에 저장될 필요는 없음. 저장공간만 허용된다면 5개의 shard가 하나의 노드에도 저장 가능

 

6. Replication

• 단일 노드 환경에서는 노드의 하드 드라이브가 뻑이 날 경우 한순간에 모든 데이터를 잃음
• 따라서, replication 즉 노드를 복사하여 저장하고 있으면 위 현상을 방지 가능
• Elastic Search는 진작에 위 문제를 인지하고 디폴트로 config에서 replication을 지원하기 때문에 설정하기 쉬움
• Replication는 인덱스 레벨에서 설정이 되고 복습을 하자면 인덱스는 여러 노드에 걸쳐 저장될 수 있는 데이터들을 여러 개의 샤드 내에 저장하도록 구성되어있음
• Replication은 샤드를 완전히 복사하면서 진행이 되고, 복사된 샤드를 replica shard 기존 샤드를 primary shard라고 부름
• primary 샤드와 replica 샤드는 완벽히 똑같이 동작하고 이들을 통틀어서 replication group이라고 부름
• replica 샤드는 primary 샤드와 반드시 다른 노드에 저장이 돼야 함 (같은 노드에 저장이 될 경우 해당 노드가 뻑 나는 순간 둘 다 데이터를 보존 못하는 불상사가 벌어짐)
• 따라서, replication을 적용하기 위해서는 클러스터가 두 개 이상의 노드들로 구성이 돼야 함
• DB 이중화를 생각하면 이해하기 쉬움
• 또한, replication은 인덱스의 처리량(throughput)을 높이는 역할도 함

 

6.1 Replication이 처리량(throughput)을 높이는 원리

상황: 두 개의 노드가 존재하고 하나의 노드에는 primary shard가 다른 노드에는 두 개의 replica shard가 존재하고 검색 요청이 들어온 상황

원리: 노드는 두 개이지만 CPU는 멀티코어이므로 쓰레드를 사용하여 각 코어에서 동시에 작업을 진행 가능

두 개의 replica shard를 호스팅 하는 노드가 각 샤드에 대해 search query를 병렬로 실행할 수 있어 인덱스의 처리량이 증가함

 

* Elastic Search는 최적의 샤드로 요청을 라우팅 하는 기능을 지원 (이에 대한 원리는 추후에 정리할 예정)

 

7. Snapshots

• DB처럼 백업 용도를 위해 snapshot 기능 지원
• Snapshot을 통해 지정된 시점으로 Elastic Search 복원 가능
• Snapshot은 인덱스 레벨 혹은 전체 클러스터를 대상으로 생성 가능
• Snapshot은 백업 용도, replication은 가용성과 성능 향상 용도로 사용

 

7.1 Snapshot vs Replication

• Snapshot을 통해 현재 클러스터의 상태를 파일로 내보낼 수 있으며, 이 파일을 사용하여 클러스터 혹은 인덱스를 원하는 시점으로 복원 가능
• Replication 또한 snapshot처럼 데이터 손실을 방지하는 방법이지만 replication의 경우 "실시간 데이터"에 한해서만 작동 즉, replication을 수행하면 특정 인덱스가 현재 시점에서 저장하는 데이터가 손실되지 않음 (snapshot처럼 특정 시점으로 원복 기능은 지원하지 않음)

 

API 규격

[HTTP 메서드] [인덱스]/[API]/[command]

• HTTP 메서드: GET/POST/PUT/DELETE
• 인덱스: 설정하기 나름
• API: 컨벤션을 따르자면 _ 로 시작 ex) _search
• command: 여러 커맨드가 존재하는데 보통 노드들 혹은 클러스터들의 상태를 체크할 때 쓰임

 

ex) POST current_index_2021_07_12/_search => 커맨드 생략

ex) GET /_cluster/health => 인덱스 생략

 

Node의 역할

1. Master-eligible

• 마스터 노드는 인덱스 생성 및 삭제를 담당
• 투표 시스템(Voting system)으로 인해 선정되므로 master 역할이 있는 노드라고 해서 반드시 master node가 되는 것은 아님
• 마스터 노드는 클러스터가 안정적(stable)인지 확인하는데 중요한 역할을 하므로 크기가 비교적 큰 클러스터에 유용함 -> 데이터 검색 및 수정은 하드웨어 리소스 측면에서 비용이 비싼 편이므로 마스터 노드에 높은 CPU, 메모리 혹은 I/O 사용량이 표시되는 경우 마스터 노드를 추가하는 것을 고려해야 함

 

2. Data

• 노드가 데이터를 저장할 수 있도록 해주는 역할 (검색 쿼리와 같은 쿼리 수행 포함)
• 주된 역할은 마스터 노드와 데이터 노드를 분리하는 것
• 비교적 작은 클러스터의 경우 이 역할은 항상 사용하도록 설정해야 함 (이 역할이 설정이 안 되어있다면 노드는 어떠한 샤드도 저장하지 않을 것)

 

3. Ingest

• Ingesting의 사전적 정의: 인덱스에 document를 저장
• 노드 내 ingest pipeline 실행 가능하도록 하는 역할
• ingest pipeline는 document들을 색인할 대 수행되는 일련의 단계

 

4. Machine Learning

• node.ml는 노드를 머신 러닝 노드로 식별
• xpack.ml.enabled 설정은 노드를 위한 머신 러닝 API를 활성화/비활성화시키는 설정
• 위 설정들은 다른 작업에 영향을 주지 않도록 백그라운드에서 머신 러닝 작업을 수행하는데 중요한 설정 

 

5. Coordination

• Coordination은 쿼리 배포 및 결과 집계를 의미
• 해당 노드는 단독적으로 데이터를 검색하지 않음 (단독적으로 데이터를 검색하는 노드는 data 노드)
• 크기가 상대적으로 큰 클러스터에서 Load-balancer 역할하는 노드

 

6. Voting-only

• 거의 사용되지 않는 노드 (알 필요 없음)

 

출처

Udemy (elasticsearch-complete-guide)