[ElasticSearch] Rolling Restart 방법

 

ElasticSearch를 운영하다보면 Rolling Restart를 해야 될 상황이 발생한다.

Rolling Restart란 클러스터를 구성하는 노드 중 하나씩 리스타트를 해나가는 것이다.

최근에 클러스터 디스크 사이즈가 부족하여 증설을 해야하는 케이스가 발생하였는데, 노드가 추가되는 것이 아닌 data path만 늘려주는 것이라서 rolling restart를 해야했다.

 

rolling restart 방법은 다음과 같다.

 

1. rebalancing 기능 disable

 rebalancing이란 노드가 삭제되거나 추가되었을때 클러스터를 균형적으로 유지하기 위해 구현되어 있는 기능인데, 노드를 삭제하거나 추가하면 자동으로 rebalancing을 했을 때와 안했을 때의 효율성 지표를 계산하여 rebalancing 하는 것이 클러스터에 더 효율적이라고 판단되면 진행한다.

 하지만 이 rebalancing 기능의 단점은, 노드가 삭제되었을때 restart 때문에 삭제된 것인지 아니면 정말 장애상황이 발생해서 삭제된 것인지 알지 못한다는 것이다. 따라서 운영자는 elasticsearch cluster에 노드가 삭제되는 것이 restart 작업 때문이라는 것을 알려줘야 하는데 이것이 바로 rebalacing 기능 disable이다. 명령어는 아래와 같다.

PUT _cluster/settings { "persistent": { "cluster.routing.allocation.enable": "primaries" } }

 

여기서 내가 알기로는 primaries와 none 옵션이 있는 것으로 알고 있는데 만약 none옵션으로 주게 되면 노드 하나가 내려갔을때 cluster의 상태는 red로, primaries 옵션을 주게되면 yellow로 변할 것이다. cluster 상태가 red라는 것은 cluster 내에 있는 index 중 primary shard에 장애상황이 발생한 것이며 yellow는 primary shard는 모두 정상이지만 replica shard 중에 배치되지 않은 shard가 있다는 뜻이다. yellow 상태에서는 모든 쿼리가 정상적으로 작동하며, red 상태에서는 문제가 발생한 primary shard에 대한 index 쿼리는 작동하지 않는다. 따라서 무중단 rolling update 철학에 맞는 옵션은 무조건 primaries이다. (삭제되는 노드에 위치한 primary shard에 대응하는 replica가 전부 primary로 승격할 것임 그리고 다시 노드가 올라오면 정상화될 것이라고 생각 -> 테스트해 볼 것.)

 

 

2. flush 작업

 elasticsearch는 모든 read/write을 하는 서비스와 마찬가지로 flush 작업이 필요하다. 보통 트랜잭션이 발생하면 transaction.log가 발생하고 이를 쌓아두었다가 적정 기준에 도달하면(시간이나 사이즈 정확한 것은 확인이 필요. 공식 문서에는 5분간 data input이 없을때라고 나와있다.) 이를 flush하여 루씬 index에 저장을 하는데 이 작업을 수동으로 진행하여 노드가 restart 되었을때 시간을 최소화 시키려는 것이다. 당연히 이 작업은 안해도 문제는 없다. (리스타트하고나서 다시 transaction.log 읽으면서 flush 작업 진행하면 됨. 그러나 조금 느릴 것이다.)

POST _flush/synced

 

3. elasticsearch stop

내리고자 하는 노드에서 elasticsearch를 stop한다.

 

4. 작업

하고자 하는 작업을 실행한다. 나는 data path를 추가해야되는 작업이기 때문에 elasticsearch.yml 파일만 수정하였다.

 

5. elasticsearch start

 

6. rebalancing 기능 enable

 rebalancing 기능을 enable 시켜준다. 이것을 disable해 놓으면 replica 설정하는 의미가 전혀 없다. 그리고 노드가 새로 추가되었을때도 균형이 맞지 않게 데이터가 쌓일 것이다.