Elasticsearch Essential 트러블 슈팅 사례

---

인프런 Elasticsearch Essential 트러블 슈팅 사례 강의를 참조하여 작성했습니다.

 

 

#1 클러스터 상태가 Green이 아닌 상태

 

Green

- 프라이머리 샤드, 레플리카 샤드 모두 정상적으로 각 노드에 배치되어 동작하고 있는 상태.

 

Yellow

- 프라이머리 샤드는 정상적으로 동작하지만 일부 레플리카 샤드가 정상적으로 배치되지 않은 상태.

- 색인 성능에는 이상 없지만 검색 성능에는 영향을 줄 수 있음.

 

Red

- 일부 프라이머리 샤드와 레플리카 샤드가 정상적으로 배치되지 않은 상태.

- 색인 성능, 검색 성능에 모든 영향을 주며 문서 유실이 발생할 수 있음.

 

Yellow 혹은 Red 상태에 따른 영향도

어떤 인덱스에 따라 장애가 아닐 수 있기 때문에 정확한 장애 범위를 파악해야 함.

GET /_cat/indices?v&health=red
GET /_cat/indices?v&health=yellow

health status index         uuid                   pri rep ....
red  open   my_index_new  WiiVyhfQTKK3f7Xgw-ETQw   1   1 ....

 

#2 Disk Used가 꽉 찼을 때

- 클러스터에 갑자기 문서가 색인되지 않을 경우.

- 클라이언트에서 403 Forbidden Error을 반환받을 경우

 

노드의 디스크 사용량이 100%가 되면 노드의 운영 체제도 정상적으로 동작하지 않기 때문에 ElasticSearch에는 디스크 사용량이 일정 수준 이상되면 더 이상 색인하지 않도록 보호하는 장치가 있음.

 

cluster.routing.allocation.disk.threshold_enabled

- 보호장치를 사용할 것인지 아닌지를 설정

 

cluster.routing.allocation.disk.watermark.low

- 기본값은 85%이고, 이 값보다 높아지면 더이상 샤드를 배치하지 않음.

 

cluster.routing.allocation.disk.watermark.high

- 기본값은 90%이고, 이 값보다 높아지면 샤드들을 다른 데이터 노드로 옮기기 시작.

 

cluster.routing.allocation.disk.watermark.flood_stage

- 기본값은 95%이고, 이 값보다 높아지면 더이상 색인을 하지 않음.

 

 

디스크 공간 확보 후 Read-Only 상태의 인덱스들을 명시적으로 풀어줘야 조회가 가능함.

 PUT /*/settings
 {
 	"index.blocks.read_only_allow_delete": null
 }

 

#3 간헐적으로 색인 과정에서 일부 문서가 누락됨. (Reject)

 

Elasticsearch에는 검색/색인 요청을 처리하기 위한 스레드가 존재하고 각 스레드 별로 큐가 존재함.

큐가 가득 찰 정도로 많은 양의 요청이 인입되면 Rejected 에러가 발생함.

 

Rejected 스레드가 발생하고 있는지를 모니터링을 통해서 감지할 수 있음.

 

클러스터의 처리량이 부족한 것이 근본 원인이기 때문에 데이터 노드 증설이 가장 좋은 방법이지만 간헐적으로 많은 양의 요청(스파이크성 트래픽)이 인입되는 경우라면 큐 증설을 통해서도 대응할 수 있음.

 

아래 API를 통해 각 노드별 reject의 현황을 볼 수 있음.

_cat/thread_pool/search?s=node_name&format=json

 

#4 샤드 배치가 되지 않음.

cluster.max_shards_per_nodes //DEFAULT 1,000

Elaistcsearch에는 노드 당 가질 수 있는 샤드의 개수에 제한이 있음.

cluster.max_shards_per_node를 통해 설정할 수 있으며 기본값은 1,000.

이 값을 초과할 경우 더 이상 샤드가 배치되지 않음. (인덱스 생성도 안됨)

데이터 노드를 증설하거나 생성되는 샤드의 개수를 조절함으로써 대응할 수 있음.

cluster.max_shards_per_node 값을 변경할 수 있으나 권고하진 않음.

 

 

#5 CMS GC 환경에서 너무 잦은 Old GC가 발생함.

ElasticSearch Essential

CMS GC를 사용할 경우 Old GC에 의해 성능에 영향을 받을 수 있음.

Survivor 영억이 작아서 Eden 영역의 객체들이 이동하지 못하고 Old 영역으로 바로 이동할 수 있고 이로 인해 불필요하게 Old 영역에 객체들이 많이 생성될 수 있음.

 

NewRatio와 SurvivorRatio 튜닝을 통해 Eden과 Survivor 영역을 늘려주고 이를 통해 문제를 해결 할 수 있음.