Elasticsearch 클러스터 상태가 Red일 때의 해결 방법

증상 및 에러 메시지

Elasticsearch 클러스터의 상태가 Red로 표시되는 경우, 이는 클러스터 내에서 할당되지 않은 primary shard가 존재함을 의미합니다. 이 상태에서는 일부 데이터에 접근할 수 없으며, 클러스터의 안정성이 저하될 수 있습니다. 클러스터 상태를 확인하기 위해 다음과 같은 명령어를 사용할 수 있습니다.

$ curl -X GET "localhost:9200/_cluster/health?pretty"

이 명령어를 실행했을 때 반환되는 JSON 응답에서 status가 red로 표시된다면, 문제가 발생한 것입니다. 예를 들어:

{
  "cluster_name" : "my_cluster",
  "status" : "red",
  "active_primary_shards" : 10,
  "active_shards" : 10,
  "unassigned_shards" : 128
}

이 경우, unassigned_shards가 128로 표시되는 것처럼, 할당되지 않은 샤드가 존재하는 것을 확인할 수 있습니다.

원인 분석

Elasticsearch 클러스터의 상태가 Red가 되는 이유는 여러 가지가 있습니다. 대표적인 원인은 다음과 같습니다:

샤드 할당 실패: 노드 수에 비해 너무 많은 인덱스가 생성된 경우, 할당할 수 있는 자원이 부족해질 수 있습니다.
디스크 공간 부족: 샤드가 저장될 디스크 공간이 부족할 경우에도 이 문제가 발생할 수 있습니다.
노드 간의 버전 불일치: 클러스터 내의 Elasticsearch 버전이 서로 다를 경우, 샤드 할당에 문제가 생길 수 있습니다.
샤드 데이터 유실: 특정 노드에서 데이터가 유실되면 해당 샤드가 할당되지 않을 수 있습니다.

이러한 원인을 확인하기 위해 다음과 같은 명령어를 사용할 수 있습니다:

$ curl -X GET "localhost:9200/_cat/shards?v=true&s=i&pretty"

이 명령어를 통해 각 샤드의 상태를 확인하고, 어떤 샤드가 unassigned 상태인지 파악할 수 있습니다.

해결 절차

상태가 Red인 클러스터를 해결하기 위해서는 다음과 같은 절차를 따릅니다:

불필요한 인덱스 삭제: 사용하지 않는 인덱스를 삭제하여 샤드 할당에 필요한 공간을 확보합니다.
```
$ curl -XDELETE "http://localhost:9200/unnecessary_index"
```
샤드 수 조정: replica shard의 수를 줄이거나, 단일 노드에서 실행 중인 경우 replica 수를 0으로 설정합니다.
노드 추가: 필요한 경우 새로운 노드를 클러스터에 추가하여 샤드 할당을 원활하게 합니다.
샤드 재할당: 특정 샤드가 unassigned 상태인 경우, 수동으로 샤드를 특정 노드에 할당할 수 있습니다. 이를 위해 다음 명령어를 사용할 수 있습니다:
```
$ curl -X POST "localhost:9200/_cluster/reroute" -H 'Content-Type: application/json' -d '{"commands":[{"allocate":{"index":"index_name","shard":0,"node":"node_name"}}]}'
```

재발 방지 체크리스트

문제가 재발하지 않도록 하기 위해 다음과 같은 점들을 체크해야 합니다:

모니터링 설정: 클러스터의 상태를 지속적으로 모니터링할 수 있는 시스템을 구축합니다. 예를 들어, Kibana를 통해 시각적으로 상태를 확인할 수 있습니다.
적절한 리소스 할당: 클러스터의 용량을 주기적으로 점검하고, 필요에 따라 노드를 추가하거나 인덱스를 조정합니다.
정기적인 백업: 데이터 유실에 대비하여 정기적으로 클러스터의 데이터를 백업합니다.
버전 관리: 모든 노드에서 동일한 Elasticsearch 버전을 사용하도록 관리합니다.

이러한 절차를 통해 Elasticsearch 클러스터의 Red 상태를 해결하고, 향후 문제가 발생하지 않도록 예방할 수 있습니다.

실무 적용 체크리스트

Elasticsearch cluster red status 해결을 적용하기 전에 현재 운영 환경의 기준값과 예외 상황을 먼저 정리합니다.
변경 전후로 확인할 지표를 정하고, 문제가 생겼을 때 되돌릴 수 있는 절차를 문서화합니다.
한 번에 모든 서버나 서비스에 적용하기보다 작은 범위에서 검증한 뒤 점진적으로 확대합니다.
담당자, 확인 시간, 장애 판단 기준을 명확히 남겨 같은 문제가 반복될 때 빠르게 대응할 수 있게 합니다.

참고 이미지

이미지 출처: https://dorito-dev.tistory.com/92

참고한 자료

트러블슈팅: APM 서버가 Health Status Red 인 문제 해결