Elastic Search Cluster 에서 노드교체 하기

1. 개요

현재 12대 구성의 Elastic Search Cluster 를 운영 중이고, 그중 한대 노드의 이상이 감지되어 장애처리를 하였다.

일반적인 경우 ES 장애처리 수순은 아래와 같다.

1. ES 클러스터에서 장애 노드 제거

2. 장애 노드 로컬에서 Hardware Fault 확인

3. 부품(Disk 등) 교체 후 ES 클러스터에서 장애 노드 신규 추가

ES 에서 해줘야 할일은 노드 제거 및 추가가 전부이기에 Hadoop Slave 교체 처럼 성능에서는 별 영향이 없을 것이라고 예상했으나 

예상과 다르게 전체 성능 저하 및 부하 급증을 겪어야 했다.

---

2. 시스템 현황

작업 전 curl 명령어를 활용해 ES cluster status 를 확인해보자

curl -XGET 'http://hostname:9200/_cluster/health?pretty=true'

현재 운영 중인 ES 클러스터의 규모는 아래와 같다.

indices 갯수	38개
indieces 용량	800G * 12
총 데이터 건수	7억8천만건

현재 운영 중인 ES 클러스터의 status는 아래와 같다.

number_of_data_nodes	12
active_primary_shards	228
active_shards	456
relocating_shards	0
initializing_shards	0
unassigned_shards	0

---

3. 노드 제거와 Shard Initializing

ES 클러스터에서 1개 노드를 제거하고 나서 ES 의 구동을 살펴보면, 우선 shard initializing 을 시작한다.

제거된 노드에서 가지고 있던 indices 는 기존 3 copy 에서 2 copy 가 되므로 

나머지 노드들은 2 copy 의 indices 들을 3 copy 로 만들기 위해 자기복제를 시작한다.

제거된 노드에서 37개 indices 를 가지고 있었기 때문에 initializing_shards 값은 37 부터 시작해서 0 까지 서서히 줄어들다.

그리고 이 작업이 완료될때까지 아래 현상이 발생하였다.

. indices 직접 복사 중인 노드들의  load avg 20까지 치솟음

. 검색속도 검색속도 평소 대비 10 ~ 100 배 이상 느려짐

  (기존 데이터 검색에 0.3 초 이하로 소요 되었다면 initializing 중 검색하면 60초 ~ 180 초 정도 소요 됨)

. initializing 완료까지 총 80분이 소요됨

. 특정조건의 검색시 primary shard 가 사라졌기때문에 active shard 를 통해 같은 결과값이 두번 return 된다.

  ex) uniq key 인 id 가 k001 일때 file path 를 찾으려고 하면, 동일 file path 를 두번 return 해준다.

       return 받은 file path 가 두개이기때문에 사용자 조회 시스템에서는 duplicated exception 이 일어날 수 있다.

  결국 검색엔진을 활용한 조회시스템에선 치명적인 오류를 발생시킬 수 있다.

. 마찬가지로 검색 정합성도 중복오류 처리에 따라 달라진다고 봐야함

initializing 과정이 종료되고 status 가 green 으로 돌아오고, 검색속도가 정상으로 돌아온다면 노드제거는 완료된 것이다. 

---

4. 노드 추가시 전체 부하

금번 작업의 경우 로컬 디스크나 메인보드에서 특별한 이상을 찾을 수 없었기에 제거된 노드를 그대로 다시 추가시켰다.

결국 신규 추가되는 노드의 로컬디스크에는 기존 indices 데이터를 그대로 가지고 있는 채로 ES 클러스터에 추가된 셈이다.

일단 신규 노드를 추가시키면 shard relocating 이 발생하고, 이 값은 2를 유지하고 있다.

ES UI Plugin 인 BigDesk 에서 확인해보면 shard 들의 이동(보라색) 이 2개씩 한정되어 이동하는 것이 보인다.

ES 클러스터 전체 입장에선 이미 3 copy 를 확보해 두었기 때문에 

신규 추가된 1개 노드에는 자신이 받아들일 수 있는 만큼만 ( 위 시스템의 경우엔 2 shard ) 복제하고 전체 밸런스를 관리하는 것으로 보인다.

-> 이에 관련된 설정이 있을 것이다. 찾아보자

위 상황을 고려하여 가정해보면 아래와 같은 결론을 얻을 수 있다.

ES 에서 노드 1개가 제거되면 다른 11개의 노드들은 각자의 indices 정보를 참고하여 전체 밸런스를 맞출 것이다.

이때 11개 노드 각각은 2 shard 만 처리를 하더라도 여러 노드에서 동시다발적으로 진행되기 때문에 전체 부하가 급증한다.

반대로 ES 에서 노드 1개가 추가되면 추가된 1개의 신규 노드는 본인이 처리할 수 있는 만큼만 일을 하기 때문에 전체 부하가 급증하지 않는다.

---

5. Shard Relocating

ES에서 신규노드를 추가하면 발생하는 shard relocationg 에 관해 부연하자면, 

Hadoop 에서 신규 노드 추가할 때와는 다르다는 점이다.

Hadoop 에서 신규노드를 추가하면 기존 데이터의 밸런싱은 거의 이루어지지 않고, 

새로 들어오는 데이터에 대해서 가용공간이 많은 신규 노드 위주로 저장이 이루어 진다.

이를 해결하고 전체 디스크 사용률을 어느정도 맞추기 위해선 별도로 하둡 밸런서를 구동시켜줘야 한다.

그러나 ES 에서는 relocating shard 과정이 곧 밸런서이다.

위 같은 경우 신규로 추가된 노드(= 방금 제거시킨 장애노드) 에는 기존 indices 정보를 가지고 있었다.

relocating 과정을 거치면서 기존의 indices 는 삭제되고 새로 전달받은 indices 만 저장하고 관리하게 된다.

신규노드로 진입하는 순간  기존 37개 indices 가 모두 삭제되고 새 indices 를 2개씩 전달받는지,

순차적으로 기존 indices 를 지우고 새 indices 를 받는지까지 모니터링 하진 않았다.

하지만 나중에 disk 사용량 로그를 확인해보니

노드추가 시점에서 기존 inidices 용량만큼 삭제되고 나서 다시 서서히 증가하는 것을 확인할 수 있었다.

결국 신규노드가 추가되면 기존의 indices 데이터는 전부 삭제된 후 새 indices 를 순차적으로 받아오는 방식임을 알 수 있다.

그리고 위와 같은 방식에서는 relocating 작업은 어떤 상황이던지 비슷한 부하정도가 나타날 것이다.

. shard relocating 시 검색속도는 거의 영향을 받지 않는다.

. shard 를 복사해주는 노드 쪽은 load avg 2~5 수준을 유지한다.

  CPU 사용률은 평소 2~3% 수준이었던 사용률이 10% 수준까지 치솟은 걸 확인할 수 있었다. 

. shard 를 받아오는 신규 노드 쪽은 load avg 를 측정하지 못했다.

  CPU 사용률은 평소 2~3% 수준이었던 사용률이 20% 수준까지 치솟은 걸 확인할 수 있었다.

. CPU 사용률을 기준으로 relocating 완료까지 총 4시간 30분이 소요되었음을 확인하였다.

---

6. 시사점

결론적으로 ES 노드 교체 작업은 사용자 서비스에 영향을 미치게 되고,

Hadoop Slave 노드 교체 처럼 일과시간 중 처리하기에는 무리가 따른다.

그리고 중요한건 차후 동일 작업이 발생할 경우 보다 수월한 진행을 위해서

노드교체 작업시간에만 2 copy 가 허용되어 노드 제거가 진행할 수 있도록 옵션 적용 및 테스트를 해봐야한다는 것이다.

-> 찾아보자

그리고 initializing 과 relocating 이 발생하는 원리와 기준은 무엇인가?

-> 이것도 공부해야할 것