ElasitcSearch 정리

개요

---

 

• 운영 시 고려해야할 사항 정리
• Data 사이즈, 검색 성능 별 상세 설정 변경이 이뤄짐 (Max 값)

 

ElasticSearch 특징

• Lucene 기반 오픈 소스 - 검색 엔진
• 실시간 분석 시스템
• Cluster 설정이 간단하며, RESTful API 방식
  • 노드 추가 용이성
• Scale Out - 샤드를 통하여 규모 확장 용이성

AWS-Elastic 기능 비교

---

 

기능	OpenDistro(AWS)	Elastic(elastic)	X-pack 유/무
RBAC	O	O(basic)	O
SSL	O	O(basic)	O
LDAP	O	O(Platinum)	O
Hot-Cold		O(basic)	O
Monitoring		O(basic)	O
Alert		O(basic) - Watcher(Gold)	O

 

Node 

---

 

Node Type	역할	분리 시 기대 효과	부정적인 요소
master	인덱스 생성/삭제, Data 인입시 shard 배치 등	master Node에 높은 하드웨어 자원 필요 x (1개의 master 3개의 data로 진행 가능)	H/W 리소스는 많이 필요하지 않으나 여러대의 host 필요
data	Data CRUD(검색, 색인)	data의 색인, 검색에만 H/W 사용으로 인한 (검색, 색인)성능 상승 기대	Disk I/O, CPU, RAM의 높은 성능이 필요
ingest	데이터의 변환 등 사전 처리 파이프라인	logstash, REST API와 같은 전처리가 부담이 클 경우 분리로 인한 성능 상승 기대	Network, RAM 등 H/W 리소스 높은 편
Coordinating	(인덱싱 배포)로드 밸런서	대량 데이터의 처리 속도, 성능 상승 기대	-
Cluster Monitoring	모니터링	Kibana DashBoard를 통하여 쉽게 모니터링 가능 (X-pack 기능이며 MetricBeat를 활용하여 H/W 및 GC, 검색속도 등 여러 지표 수집)	master,data,ingest Node 와 분리 필요

 

 

master	data	ingest	Node Type
true	false	false	Master Node
false	true	false	Data Node
false	false	true	Ingest Node
false	false	false	Coordinating Node

 

*GC: Garbage Collector

 

Node 추가 시 확인 사항

---

 

Shard unassigned - 노드 추가 시 index Shard unassigned 발생 → reallocation(On/Off) 기능으로 복구 혹은 index 삭제로 문제 해결

 

 

 

샤드 재분재 - primary shard reallocation 발생 → data node disk I/O 발생, 데이터 무결성, Allocation Deciders 통하여 node 리소스 중가

disk watermark ( disk 총 사용량 확인 )  - 관련 설정: cluster.routing.allocation.disk.watermark.high, cluster.routing.allocation.disk.watermark.low

 

Watermark High 설정 값보다 높게 Disk 사용시 Index Only Read로 발생 

관련 설정: 

위 설정으로 Only Read False 가능

 

서버 교체 시 Index-ReAllocation off 로 서버 교체 필요(샤드 재 분배로 인하여 다른 Node H/W 리소스 상승)

Modeling

---

Data 흐름

• 물리적
  • cluster → node → index → shard
• 논리적 (e.x. RESTFull API)
  
  • index → type → document → filed:value

 

1. cluster node 구성
2. Shard Design
   1. shard 개수
      • Replica, Primary shard 개수 지정
   2. shard 사이즈
      
      

Log Level 조정

---

sudo sed -i's/rootLogger.level= info/rootLogger.level= debug/g' /etc/elasticsearch/log4j2.properties
curl -XPUT -H 'Content-Type: application/json' localhost:9200/_cluster/settings -d '{ \
 "transient": { \
   "logger.org.xbib.elasticsearch.jdbc.strategy": \
   "trace" \
  } \
 }'

JVM Heap & File Discript

---

JVM Heap – aggregation, analyzed string(tag, SigTerms ...)

Lucene ( System Cache Memory ) - Search

  - Lucene의 경우 Disk I/O를 발생하며 자주 사용하는 data의 경우 RAM을 이용하므로, JVM Heap 메모리 설정 값이 중요    ( Heap Memory가 아닌 system memory)

  - Hot / Warm / Cold 별 Disk NvME, SSD, HDD 분리 필요(대용량 인프라) (Hot-Cold Architecture)

 

JVM Heap Size가 Query에 비하여 낮을 경우 Data 유실 발생(Out of Memory)

 

JVM OOP-32bit를 권장하며 JVM Heap Size 32Gb이상이 될 경우 64bit 사용 → 64bit OOP 사용 시 성능 매우 저하

관련 내용:  Link

 

OOP(Zero Based Compressed 및 OOP - shift 연산으로 Object 관리) - Zero Based OOP 사용 가능하도록 Heap Size 설정 필요

관련 설정 및 내용: Link

GC(Garbage Collector) & Thread 

---

Search ThreadPool ( ((CPU Cores *3) / 2) +1 ) 

DISK I/O → Lucene Thread ( JVM HEAP 관련)

ElasticSearch Thread == CPU Cores

 

GC는 JVM Heap 과 관련이 깊으며 GC 오류 시 data 유실 문제 발생 Out of Memory

 

Index Management (Hot-Cold Architecture)

---

Index Auto Delete ( cold ) -- 수정

Tokenizer & Analyzer

---

한글 형태소 nori ( 6.4 version 이상에서 사용 가능)

 

type: none, discard, mixed

user_dictionary: 우선순위 및 단어 추가

 

type	개요
Multi Fields	elastic 6 버젼 이후 불가(version >= 6) 1Fields + analyzer 가능 2개의 원자 추가 불가 1개의 원자 추가 가능
Re-Indexing
Alias	서비스 시 발생하는 error (색인(index) 검색 Fail over로 활용 가능) 코드 내부 2개의 alias 색인(index)으로 서비스 장애 시 대응 가능

Search

---

 

검색 방식

---

 

	정확도	범위	Join	TS
Query DSL	높음	type data 를 비교 (≒ RDBMS select)	가능	불가
Search API	중간	tokenizer → tokenizer → analyzer를 통하여 구문 분석 비교	불가	가능

 

Query DSL > Search API

검색 속도

---

 

bulk Max size Limit → NIO 저하 및 속도 증가 

Shard Size, Nums → 검색 속도(대용량 쿼리, 단일 쿼리)

  size, nums 높아지면 단일 쿼리 성능 저하 (검색 성향에 맞게 지정 필요)

 

Backup & Recovery

---

Snapshot 기능 이용 (OSS도 사용 가능) (상향식 복구만 가능)

 

Scroll API로 full Scan 가능 (index create bulk API BackUP) - 오픈 소스 활용으로 진행 / 완료

 

Directory Full Backup 가능( repository 사용)

repo의 경우 NFS와 같은 Shared File System 필요 ( 모든 data node에서 접근 가능 필요)

##### BackUP ######

elasticsearch.yml
path.repo 지정 필요

$cat << EOF > */elasticsearch.yml
path.repo = /backup/elasticsearch
EOF

$systemctl restart elasticsearch
PUT /_snapshot/{repoName} #PUT /_snapshot/{test_backup_01}
{
 "type": "fs",
 "settings": {
   "location":   "path",	#"{/backup/elasticsearch (/backup/elasticsearch/test_index_01_YYYY-mm-dd 도 가능}"
   "compress": true
  }
}

PUT /_snapshot/{repoName}/{snapshotName}?wait_for_completion=true #PUT /_snapshot/{test_backup_01}/{test-20.06.25}?wait_for_completion=true
{
 "indices" : "indexname",	#"{indexName*} or {indexName,indexName,indexName}"
 "ignore_unavailable": true,	
 "include_global_state": true	#shard 등 설정 가져옴 #(true: mapping 값도 같이 백업, false: mapping 값 없이 백업)
}
##### Recovery #####
#snapshot 확인
GET /_snapshot/{repoName}/{snapshotName}	#GET /_snapshot/test_backup_01/test-20.06.25
#1 index close 후 복구
#복구 전 index close
POST /{indexName}/_close	#POST /test-restore/_close

#복구 진행
POST /_snapshot/{repoName}/{snapshotName}/_restore	#POST /_snapshot/test_backup_01/test-20.06.25/_restore

#2 index 삭제 후 복구
#복구 전 인덱스 삭제 DELETE /{indexName}	#DELETE /test-restore

#복구 진행 POST /_snapshot/{repoName}/{snapshotName}/_restore	#POST /_snapshot/test_backup_01/test-20.06.25/_restore

참고 용도 복구 완료 시간:

 

용량	docs.count	백업 시간	복구 시간
약 900Mb	19000	약 21초	약 0.118 초

 

Search Across Clusters

---

ElasticSearch 버젼이 다르더라도 search 가능 기능

확인 필요 

 

기대효과: master node 부하 감소 

 

Elasticsearch - Grafana 대쉬보드

---

https://community.grafana.com/t/grafana-table-w-text-data/14747

https://grafana.com/docs/grafana/latest/features/datasources/elasticsearch/

https://github.com/grafana/grafana/issues/18339

 

참고문헌

---

Nori ElasticSearch DOCS

Search Performance ElasticSearch Blog

Index Management ElasticSearch Blog (hot-cold policy)

Search Across Clusters ElasticSearch DOCS

Shard Allocation ElasticSearch DOCS

Node ElasticSearch DOCS

ElasticSearch multi match query DOCS