ElasticSearch status 바로 알기
ElasticSearch
오늘은 ElasticSearch (이하 ES)의 status 에 대한 이야기를 해볼까 합니다. ES의 status는 무엇을 의미하는지, 그리고 어떤 값들이 있으며 어떻게 확인할 수 있는지 살펴보겠습니다.
ES status 확인하기
ES는 status라는 것으로 현재 클러스터의 상태를 표시합니다. 아래와 같이 cat API를 사용하면 손쉽게 클러스터의 상태를 볼 수 있습니다. (https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-health.html)
cat API 로 status 확인하기결과 내용을 한 번 살펴볼까요?
현재 클러스터의 이름은 elasticsearch이고 status는 green, 전체 노드 수는 2개, 그중에서도 data 노드는 2개 임을 알 수 있습니다. 또한 전체 샤드의 개수는 5개, 그중에서도 primary는 3개이며, 현재는 relocation, initilizing 인 샤드는 없으며 어떤 노드에도 배치되지 않은 unassigned 샤드는 없음을 알 수 있습니다. 이렇게 cat API 중에서도 health를 이용하면 클러스터의 현재 상태에 대해서 간략하지만, 중요한 정보들을 확인할 수 있습니다.
cat API는 뒤에 ?format=json이라는 파라미터를 붙여서 JSON 형태의 포맷으로 출력을 받을 수 있습니다.
이번 글에서는 이 중에서도 status에 대해 조금 더 이야기해 보겠습니다.
status의 종류
ES는 아래 3가지 값으로 status를 표현하고 있습니다. 각각이 의미하는 바는 아래와 같습니다.
green : 모든 샤드가 정상적으로 동작하고 있는 상태, 모든 인덱스에 쓰기/읽기가 정상적으로 동작한다.
yellow : 일부 혹은 모든 인덱스의 replicas 샤드가 정상적으로 동작하고 있지 않은 상태, 모든 인덱스에 쓰기/읽기가 정상적으로 동작하지만, 일부 인덱스의 경우 replicas가 없어서 primary 샤드에 문제가 생기면 데이터 유실이 발생할 가능성이 있다.
red : 일부 혹은 모든 인덱스의 primary와 replicas 샤드가 정상적으로 동작하고 있지 않은 상태, 일부 혹은 모든 인덱스에 쓰기/읽기가 정상적으로 동작하지 않으며, 데이터의 유실이 발생할 가능성이 있다.
green과 yellow는 모든 인덱스의 쓰기/읽기에는 이상이 없는 상태입니다.
클러스터의 성능에는 영향이 있겠지만, 기능적인 문제는 없습니다.
replica shard가 없기 때문에 검색 성능에 영향이 있을 수 있습니다.
하지만 red의 경우 일부 혹은 전체 인덱스의 primary shard가 존재하지 않기 때문에 일부 데이터에 대해서는 쓸 수도, 읽을 수도 없습니다. 그래서 클러스터가 red 상태가 되면 클러스터의 장애라고 볼 수 있습니다. 그럼 장애의 영향과 범위를 어떻게 알 수 있을까요? red 상태에 대해서 조금 더 살펴보겠습니다.
red의 영향 확인하기
클러스터가 red가 되었다고 당황하지 말고 우선 장애의 현황을 정확하게 파악하는 것이 중요합니다. 어떤 인덱스들이 영향을 받고 있고, 어느 정도의 로그 유실이 예상되는지에 대해서 말입니다.
먼저 어떤 인덱스들이 영향을 받고 있는지 확인해 보겠습니다. 이 때는 cat API 중 indices API를 활용합니다.
cat API로 인덱스 상태 확인하기보이는 것처럼 클러스터의 상태가 red라고 해서 모든 인덱스의 상태가 red는 아닙니다. 클러스터 상태는 red 지만 test_2 인덱스는 yellow 상태 이기 때문에 문서의 쓰기/읽기의 기능적인 문제에는 전혀 영향이 없습니다. 하지만 test 인덱스는 red 이기 때문에 문서의 쓰기/읽기에 문제가 있을 수 있습니다. 그럼 어떤 샤드들이 문제가 있을까요? 이번에도 cat API를 사용해서 살펴보겠습니다.
cat API로 샤드 상태 확인하기보이시나요? test 인덱스의 샤드들 중에서도 1번과 3번 샤드들이 unassigned 상태입니다. 이 두 개의 primary shard가 어떤 노드에도 배치되지 않아서 클러스터의 상태가 red가 된 것입니다. 그렇다면 이 상태에서 문서의 쓰기/읽기는 어떻게 될까요? 5개의 primary shard들 중에서 3개는 동작하기 때문에 60% 정도의 쓰기 작업은 성공할 것이며, 읽기 시에도 장애 발생 전에 들어있던 데이터들의 60% 정도만 조회가 됩니다.
기능적으로도 완전히 멈춘 상태는 아니고 샤드의 unassigned 상태에 따라서 일부는 동작할 수 있습니다.
그래서 이 클러스터의 경우는 test 인덱스에 대해서 40%의 문서 유실이 발생할 수 있는 장애 상태라고 말할 수 있습니다. 이렇게 cat API를 통해서 현재의 상태를 정확하게 확인하면 현재 클러스터가 겪고 있는 문제의 범위를 정확하게 정의할 수 있습니다. 만약 primary shard를 잃어버린, red 상태의 인덱스가 오늘자 로그를 수집하고 있는 인덱스가 아니고 어제자 로그를 가지고 있는 인덱스라고 한다면, 해당 노드만 정상적으로 복구할 경우 로그 유실은 없다고 생각할 수 있습니다.
마치며
이번 글을 통해서 ElasticSearch의 status가 어떤 의미인지, 특히 red 상태가 되었을 때 어떻게 장애의 범위를 확인할 수 있는지에 대해서 다뤄봤습니다. 클러스터가 red 상태가 된다면 먼저 _cat/indices API를 통해서 red 상태에 빠진 인덱스들을 확인하고, _cat/shards API를 통해서 해당 인덱스들에서 어떤 primary shard들이 unassigned 상태인지를 확인해야 합니다. 그렇게 해서 먼저 클러스터가 겪고 있는 장애 현황을 정확하게 확인해야 합니다.
ES에는 이 외에도 cat API를 통해 빠르게 주요 정보들을 확인할 수 있는 많은 방법을 제공해 주고 있습니다. 이에 대해서는 앞으로의 글을 통해서 천천히 확인해 보겠습니다.
