개요
회사의 분석계 ES 클러스터를 5.5.0으로 운영중이다. 버전이 5.5.0인 이유는 여러가지 실험적인 키바나 플러그인의 설치 및 호환성을 맞추는 과정에서 이버전이 되었다.
하지만 현시점 기준 벌써 ES가 6.3.1까지 나온 상황이고 굳이 5.5.0을 반드시 고집할 이유도 없기에 가급적 새로운 기능 및 버그패치 그리고 최신 버전 사용경험을 얻기 위해 회사의 분석계 ES 클러스터를 6.3.1로 업그레이드 하기로 한다.
현재 본인이 가진 ES 버전에서 Elasticsearch 6.3.1로 업그레이드 하기 위해서는 호환성 가이드 를 참고하면 된다.
업그레이드 전략
위의 가이드에 따르면 필자는 아래와 같은 과정으로 ES 6.3.1로 업그레이드 할 수 있다.
중간에 5.6.10(5.x의 마지막 버전) 을 거치는 이유는 ES 6부터 lucene 7버전 포멧을 사용하는데 Index구조가 대폭 바뀌었기 때문에 5.6버전 보다 하위버전에서는 바로 6.x로 업그레이드를 할 수 없기 때문이다.
- 5.5.0 -> 5.6.10 Rolling Upgrade
- 5.6.10 -> 6.3.1 Rolling Upgrade
필자는 위의 업그레이드를 시간을 두고(1~2주) 두차례에 걸쳐 진행하고자 한다. 이유는 아래의 2가지 이다.
- 기술적으로는 한 차례의 Rolling Upgrade에 대해 방법을 테스트 및 경험을 쌓고자 한다. 이 과정에서 롤백이 메이저 업그레이드 대비 손쉽다.
- 회사에서 ES 클러스터와 관련된 어플리케이션들이 유기적으로 돌기 때문에 급진적인 메이저 업그레이드를 한번에 수행하는 것보다 마이너 업그레이드를 먼저 수행해 안정성과 경험치를 확보하기 위해서이다.
업그레이드 순서
필자는 회사에서 분석계 클러스터를 아래의 3개의 노드 종류로 구분해서 운영하고 있다. 인터넷에 롤링 업그레이드에 대한 글은 여러 개 있지만 정작 이 장비의 Rolling 순서에 대해 자세히 기술된 내용은 없었다.
- Master
- Data
- Client
하지만 조금 더 구글링 한 후 ES 개발자가 직접 얘기한 내용에서 힌트를 얻어 필자는 Master -> Data -> Client 순서로 업그레이드를 진행하기로 한다.
호환성 테스트
업그레이드를 섣불리 진행하기 보다 미리 Risk에 대해 확인 하고 내용을 해결 한 뒤 업그레이드를 진행하는것이 좋은 전략이라고 생각했다.
현황 파악
- ES 5.5.0 클러스터
- Kibana 5.5.0
- 사내 Analytics Application
- Apache Nifi(ES로 색인)
- Metricbeat
호환성 테스트 방법
위의 조합을 모두 로컬에서 설치 해 본 경험이 있으므로 로컬 환경에서 위의 생태계를 재현하여 실제로 동작을 시켜보는 것으로 호환성 테스트를 진행할 수 있다고 판단했다.
이부분을 자세히 설명하면 글이 길어질 수 있으니 자세한 내용은 생략한다. 순서만 언급하자면 아래와 같다.
- 분석계 ES 클러스터에서 샘플 Index를 스냅샷으로 추출
- 로컬의 ES standalone 장비에 스냡샷 복원
이를 통해 확인한 호환성은 아래와 같다.
- Apache Nifi(ES로 색인) -> 테스트 완료
- 사내 Analytics Application -> 테스트 완료
- Metricbeat -> 기존 5.5.0버전 정상 동작
- kibana 5.5.0 -> 기존 5.5.0버전 정상 동작
Rolling Upgrade 수행
업그레이드를 수행 하기 위해서는 아래와 같이 진행했다.
롤링 업그레이드를 진행할 떄 필지가 작성해둔 아래의 글을 참고하자.
Rolling Upgrade #1 : 색인 중지
ES 클러스터를 노드 1대 씩 롤링한다고 하더라도 색인은 가급적 멈추는게 안정성 측면에서 좋다.(5.x에서는 Recovery 모드에서 replica가 1이상 설정되어 있더라도 cluster가 red 뜨는 경우가 발생하기 때문이다.)
Rolling Upgrade #1 : Master
필자는 마스터 장비 3대를 운영중인다. 기존 리더 장비가 다시 리더가 될 수 있게끔 Rolling Upgrade를 진행하였다. 이부분은 자동화 할 수도 있지만 로그 모니터링 및 즉각적인 롤백을 하기위해 수동으로 로그를 보며 진행하였다.
정상적으로 마스터가 모두 5.6.10으로 업그레이드 된 이후에도 클러스터는 정상동작함을 확인 할 수 있었다.
Rolling Upgrade #2 : Data
데이터 노드는 위의 – Ansible을 이용하여 엘라스틱서치 Rolling 재시작 자동화하기
에서 만든 스크립트를 통해서 자동화 하여서 수행하였다.
다만 자동화 스크립트를 수행하기 전 데이터 노드 1대만 테스트로 업그레이드 해서 기존 클러스터와 어우러져 샤드가 정상적으로 모두 복구가 되는지 확인을 하였다.
Rolling Upgrade #3 : Client
클라이언트 노드 업그레이드는 데이터 복구가 없기 때문에 순식간에 완료하였다.
Rolling Upgrade #4 : Kibana
키바나도 5.5.0으로 정상동작을 확인했지만 차후에 .kibana 색인을 6.x로 마이그레이션 하는 과정에서 키바나 5.6.x가 필요하기 때문에 업그레이드를 진행하였고 별 이슈는 없었다.
검증하기
클러스터 업그레이드를 완료 한 뒤 로컬에서 수행했던 호환성 테스트를 다시 직접 실 환경에서 테스트해보았다.
다행히 기대했던대로 모두 다 정상동작했고 끝으로 NIFI 색인을 재개하는 것으로 업그레이드 작업을 마무리 하였다.