엘라스틱서치 - 장애 복구 작업 도중 새 인덱스 생성될 때

추석 연휴 동안 서버 3대중 한대가 죽어서 2대로 테스트 데이터를 받고있었습니다. 

오늘 회사 서버를 살려서 연결 해 보니, 새로 생성된 데이터의 샤드가 제대로 분배가 되지 않는것을 파악했습니다.

 

그 해결책으로 밑에 구문을 보시면 될거같습니다.

 

 

장애 대응으로 한참 샤드 복구와 샤드 할당 작업 등이 수행 중인 바쁜 상황에서 새 인덱스가 생성 될 때를 조심해야 한다. 

엘라스틱서치에 새 샤드가 할당될 때 엘라스틱서치는 해당 노드에 총 몇개의 샤드가 있는지 체크한 뒤 적은 수의 샤드를 들고 있는 노드에 새 샤드를 할당한다. 

 

문제는 장애 복구 작업 중 방금 재시작된 노드는 샤드 복구가 제대로 끝난 상태가 아니라는 것이다. 이 노드는 겉으로 보기에는 적은 샤드를 들고 있는 것으로 판정된다. 이때 새 인덱스가 생성되면 이 인덱스의 모든 샤드를 한 노드가 몰아서 할당받는다. 그렇게 해야 전체적인 샤드 수의 균형이 맞다고 엘라스틱서치가 판단하기 때문이다. 

여기에 데이터까지 들어오면 원래는 수십 대의 노드가 분산해서 색인해야 할 데이터를 한 노드가 전부 받아서 처리하다가 다시 죽는 문제가 발생한다. 

cluster.routing.allocation.balance.shard 설정은 샤드 할당의 균형을 맞추는 경향성을 지정한다. 이 값이 낮을수록 균형을 신경 쓰지 않는다. 기본값은 0.45다. 장애 복구 작업 도중 새 인덱스가 생성될 것으로 예상되면 이 값을 임시로 0으로 낮춘다.

 

# 가중치: 노드마다 샤드 개수 밸런싱 < 인덱스마다 샤드 개수 밸런싱
cluster.routing.allocation.balance.shard: 0
cluster.routing.allocation.balance.index: 1
cluster.routing.allocation.balance.threshold: 1.0

쿼리
PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.balance.shard": 0.0,
    "cluster.routing.allocation.balance.index": 1.0
  }
}

공식 문서 :  https://www.elastic.co/guide/en/elasticsearch/reference/7.2/shards-allocation.html

Cluster level shard allocation | Elasticsearch Guide [7.2] | Elastic

비상 상황 처리가 끝나면 이 값을 다시 원래대로 돌려야한다. 계속 0으로 놓고 운영을 하면 특정 노드에 특정 샤드의 배분이 우선된다. 균형을 고려하지 않고 순서대로 단순하게 샤드를 배정하기 때문에 시간이 지날수록 어떤 노드는 특정한 샤드를 많이 할당받고, 어떤 노드는 샤드를 잘 할당 받지 않는 현상이 심화된다. 

 

당장 큰 문제는 생기지 않겠지만 인덱스당 샤드의 수 대비 노드의 수가 크면 클수록, 인덱스의 수가 많을수록, 인덱스마다 데이터의 성질이 다를수록 쏠림 경항이 심해지며 점점 문제의 소지가 된다.

 

이미 특정 노드에 샤드가 몰린 경우 수동으로 reroute API를 호출해서 다른 노드에 샤드를 옮길 수 있다. 다만 이 reroute 작업이 수행되는 동안은 클러스터 부하가 커지기 때문에 전후 상황을 봐서 수행해야 한다. reroute API 는 다음과 같이 호출한다. commands에  하나 이상의 명령을 지정할 수도 있다. 

POST _cluster/rerout
{
	"commands":[
    {
      "move":{
        "index": "test-index-5",
        "shard" : 0,
        "from_node": "es02",
        "to_node": "es01"
      }
    }
  ]
}

 

직업 REST API를 호출하는 방법 외에도 cerebro 같은 관리 도구를 사용하면 UI상에서 샤드 분포를 눈으로 확인하며 쉽고 편리하게 샤드를 옮길 수 있다.