[ELK Stack] Elasticsearch cluster 롤링 업그레이드 관련(7.2 -> 7.17.2)

회사에서 Elasticksearch cluster 버전 rolling upgrade를 진행했던것을 기록차 정리합니다. ELK Stack rolling upgrade 가이드를 참조해서 진행했습니다. 참고로 7.2버전에서 7.17.2 버전으로 upgrade 하였습니다.

https://www.elastic.co/guide/en/elasticsearch/reference/7.17/rolling-upgrades.html

Rolling upgrades | Elasticsearch Guide [7.17] | Elastic

1. ELK Stack cluster 구조

저희 팀에서는 Elasticsearch로 cluster를(물리서버 5대) 구성해서 사용하고 있습니다. cluster는 하기와 같이 한개 master-eligible node와 4개 master-ineligible(sub) node로 구성되어 있습니다. 그림에서 보다시피 저희는 logstash는 없습니다(logstash는 별도로 따로 동작하고 있습니다).

• master node에 cerebro와 kibana가 붙어 있음.
• 외부 한글 tokenizer lib(사내 project)을 사용하고 있음. 해당 tokenizer를 elasticsearch에서 사용할 수 있도록 구현한 plugin을 사용하고 있음.
• elasticsearch, kibana config파일 / data 등은 workspace라는 폴더에 저장되어 있음(workspace 폴더는 elasticsearch, kibana 폴더 상위에 존재함).
• master-ineligible node는 총 4개 존재 함.

2. ELK Stack cluster rolling upgrade

2.1 Elasticserach, kibana 버전 upgrade 방법

Elasticsearch, kibana 버전 upgrade는 단순합니다. 

• upgrade할 elasticsearch, kibana를 다운받아 설치. 저희는 zip 파일을 다운받아 새로운 폴더에 압축을 품(기존 elasticsearch는 elasticsearch_7.2 폴더에 존재하고 새로운 elasticsearch는 elasticsearch_7.17.2폴더에 존재함).
• 기존 elasticsearch, kibana stop
• 환경변수 ES_PATH_CONF(elasticsearch/kibana data, conf 파일이 존재하는 폴더위치)를 workspace 폴더로 지정
• (Optional). 저는 tokenizer lib upgrade와 plugin upgrade가 필요해서 그 부분도 진행하였음.
• elasticsearch / kibana 7.17.2 start

만약 cluster가 아니라 ELK stack 한개만 운영한다면 이것만 진행하면 upgrade가 완료됩니다. 기존 서비스가 멈추고 싶지 않으면 workspace를 복사해서 새롭게 생성하고 새로운 elasticsearch / kibana를 실행 후 기존 서비스를 멈추면 되겠죠. 당연히 port가 달라지기 때문에 서비스 코드도 수정해서 배포하면 서비스 중단 없이 가능할것 같습니다.

2.2 Cluster upgrade 하기전 주의할 점

• 먼저 master-ineligible node들을 upgrade한 후 master-eligible node들을 upgrade 해야 함.
• cluster에 단 한개 node라도 upgrade되었으면 해당 cluster의 모든 node들을 upgrade 해야 함. 즉 cluster upgrade가 시작되면 rollback이나 멈출수가 없음. rollback을 하는 방법은 새로운 cluster를 생성하는 방법밖에 없음. 
• 2번과 연결되는 내용인데, 높은 버전 elasticksearch node에서 생성된 data들은 낮은 버전 elasticsearch node에서 replica가 생성되지 않음.

2.3 ELK Stack cluster 환경에서 rolling upgrade 방법

Cluster 환경에서는 각 노드에서 추가로 몇개 작업만 더 해주면 됩니다. master-ineligible node를 모두 upgrade 후 마지막에 master node를 upgrade 하는 순서로 진행합니다. 각 노드별로 진행하기 때문에 upgrade기간 cluster는 그대로 동작하기 때문에 서비스는 멈추지 않습니다.

• Disable shard allocation. cluster에 현재 노드는 잠시 stop 된다고 알려주는 작업을 해야 합니다. cluster에서 replicate 작업을 진행할 때 연결되지 않는 노드가 있으면 설정한 timeout 시간동안 멈추게 됩니다. 때문에 replicate할 때 현재 노드는 무시해달라고 요청을 보내야 합니다.

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}
'

• (Optional) synced_flush 작업을 해야 합니다. synced_flush 작업을 하면 elasticsearch를 다시 실행할 때 shard recovery가 더 빨리 진행될수 있다고 합니다. synced_flush: https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-synced-flush-api.html

curl -X POST "localhost:9200/_flush/synced?pretty"

• 위에서 설명한 elasticsearch / kibana upgrade 작업을 진행.
• 새로운 elasticsearch를 start 한 후 cluster에 정상적으로 추가됬는지 확인. 저는 cerebro에서 확인을 했는데 하기 명령으로도 확인할수 있음.

curl -X GET "localhost:9200/_cat/nodes?pretty"

• Reenable shard allocation. cluster에 해당 노드가 다시 replica sharding을 할수 있다고 알려줘야 함.

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}
'

• 이제부터 해당 노드가 recovery 하는것을 기다리면 됨. 저는 cerebro에서 해당 노드가 replica sharding이 완료되는지 확인을 했음. status가 green이 되면 해당 노드는 upgrade 완료 되었음.

하기 명령을 쳤을 때 status가 green이 되면 recovery가 완료되었다는 뜻임.
GET _cat/health?v=true

하기 명령으로 sharding 진행상황을 %로 볼수 있음.
GET _cat/recovery

• 지금까지 한 작업을 master 노드까지 똑같게 반복하면 됨. kibana는 한개 노드에만 존재하니(보통 master노드) 한번만 진행하면 됨.

저는 upgrade 작업들을 shell script를 만들어서 진행했습니다. 하기와 같이 5개 명령을 만들어서 진행했는데 참고하시면 되겠습니다. elasticsearch와 kibana는 각각 따로 script를 만들었습니다.

• prejob: disable shared allocation과 sync flush 진행
• install: elasticsearch / kibana 다운로드, 압축풀기, tokenizer plugin / lib upgrade, ES_PATH_CONF 설정
• stop: 기존 elasticsearch / kibana stop
• start: 새로운 elasticsearch / kibana start
• postjob: Reenable shard allocation

3. Troubleshooting

1. 저희 project는 정기적으로 1시간에 한번 job이 돌면서 새로운 data를 elasticsearch에 indexing 합니다. upgrade 도중에 indexing이 발생했는데 마침 upgrade 완료한 노드에 해당 index 원본이 생성되었습니다. 이렇게 되면 upgrade 되지 않은 노드에는 해당 index의 replica가 생성되지 않습니다. 위에서 말씀드렸듯이 높은 버전 elasticsearch에 생성된 data는 낮은 버전에 replica가 생성되지 않습니다.  당황하지 말고 upgrade를 계속 진행하면 순차적으로 replica가 생성되는 것을 확인할 수 있습니다.

2. 저희 elasticsearch와 kibana는 security 설정을 하지 않고 사용하고 있었습니다(당연히 문제지만 내부망으로만 접근하는 서비스라 그냥 그대로 사용하고 있음. 앞으로 8점대 upgrade 시 security 설정을 할 예정......) 7.15이상부터 security 설정이 안되어 있으면 kibana에서 index 볼때 warning이 계속 발생합니다. 

https://www.elastic.co/guide/en/elasticsearch/reference/current/migrating-7.13.html#breaking_713_security_deprecations

각 노드의 elasticsearch.yml 에 하기 값을 추가하면 warning을 없앨 수 있습니다.

xpack.security.enabled: false

3. master node를 stop하면 cerebro도 같이 stop 되었습니다. 저희가 설정할 때 cerebro를 master와 연동되게 해서 그런것 같은데 일단 master를 살리면 cerebro도 다시 볼수 있어서 그냥 그대로 뒀네요. ㅠㅠ. 뭔가 누군가 불편하면 개선할것 같네요......

4. 마지막으로 7점대에서 8점대로 올라갈 때는 뭔가 많이 변경되는것으로 보입니다. 

https://www.elastic.co/guide/en/elasticsearch/reference/current/migrating-8.0.html

Migrating to 8.0 | Elasticsearch Guide [8.4] | Elastic

그냥 data가 많지 않으면 8점대로 새로운 cluster를 만들고 data를 옮겨가는게 더 편할 수 있겠다는 생각이 드네요. 언제 진행할 지 모르지만 만약 진행하게 되면 다시 후기를 공유드리겠습니다.