Elasticsearch 장애 발생 시 대응 절차 (자주쓰는 api 목록)

Elasticsearch 클러스터에 장애가 발생했다!

 

인프라 개발자의 Elasticsearch 장애 발생 시 대응 절차 정리.

 

1. 상황 파악

1-1. 알림 및 대시보드 진입

• 일반적으로 cluster status yellow / red 알림을 통해 장애 인지
• Kibana Monitoring(또는 Stack Monitoring)에서 다음 항목 우선 확인
  • 클러스터 상태
  • 노드 수 변화
  • 미할당 샤드(unassigned shards) 발생 여부

 

1-2. 기본 진단 API

GET _cat/health?pretty

cluster status (green / yellow / red), 
미할당 샤드 수, 
현재 클러스터에 참여 중인 노드 수를 주로 확인 합니다.

GET _cat/nodes?v

마스터 노드 선출 여부, 
노드별 CPU 사용률, Heap 사용량, 메모리 사용량, 평균 부하(load)를 주로 확인 합니다.

GET /_cat/indices?v

 

인덱스 상태 확인.

 

# 모든 샤드 상태 확인
_cat/shards

# 특정 인덱스의 샤드 상태확인
_cat/shards/{index_name}?v

 

샤드 상태 확인.

 

GET _nodes/stats/fs

노드별 디스크 사용량 확인, 
디스크 full / watermark 문제 여부 판단를 확인 합니다.

 

 

GET _cat/allocation?v

 

클러스터 디스크 현황 확인.

이와 관련해서 하나 더..

 

_cluster/allocation/explain

 

미할당 샤드 원인 분석해주는 api.
node left, replica 부족 등 정확한 원인 확인이 가능합니다.

 

 

 

2. 샤드 할당 비활성화

샤드 할당 비활성화 해야하는 이유

 

_cat/health나 _cat/nodes의 수행 결과,

클러스터에서 Node가 하나라도 이탈하면 

그 노드가 가지고 있던 primary / replica 샤드가 사라진다.

 

그러면 Elasticsearch는 number_of_replicas를 맞추기 위해

새 replica를 다른 노드에 생성하려고 하는데 

이 과정에서 네트워크 I/O, I/O가 증가하고 CPU/Heap 사용량이 급증 하는 등 부하 발생.

장애 상황에서 이 복구 작업이 연쇄 장애를 유발할 수 있다.

 

비활성화 시 none, primaries, new_primaries 중 하나 선택하면 되는데 

나의 경우 항상 none 으로 했었고, 장애 조치가 끝나면 all로 바꾼다.

 

 

간혹 클러스터 상태가 좋지 않으면 샤드 할당 비활성화 요청이 실패하는 경우도 있다.

마스터 노드가 선출되지 못했거나,

일부 노드가 클러스터에 합류되어 있지만 GC로 인해 Stop-the-world 상태가 길어질 경우 실패할 수 있다.

샤드 비활성화가 실패했다면 클라이언트 트래픽을 차단 해야함.

 

 

3. 서버 로그 확인

위의 _cat/health, _cat/nodes 요청이 아예 실패한다면 

서버 문제 혹은 Elasticsearch 프로세스 자체가 내려갔을 가능성이 있다.

 

서버에서 systemctl status로 Elasticsearch 상태 확인 하고 서버 로그를 확인해야 한다.