OperationsElasticSearch

ElasticSearch_Version_Up

, , ,

# Overview

2.3.X 버전으로 운영되고 있는 클러스터를 6.4.X 클러스터로 버전업 했던 경험을 포스팅 해 보겠습니다.

  • 제약사항
  1. 기존 2.3.X 클러스터에 ES 뿐 아니라 다른 어플리케이션들도 동작하고 있음
  2. 운영중인 시스템 이므로 ES 클러스터의 다운타임은 존재하면 안됨
  3. 제약사항 1 때문에 임시 서버를 받고, 임시 서버에 6.4.X 클러스터를 구성 하였음

# 작업 계획

  1. 임시서버에 6.4.X 클러스터 구성
  2. 기존 2.3.X 클러스터의 데이터를 6.4.X 클러스터로 이관 (_reindex api 활용)
  3. 이관이 완료되고 나면 ES에 indexing을 하거나 searching을 하는 모든 어플리케이션들이 6.4.X 클러스터(임시서버)를 바라보도록 설정.
  4. 2.3.X 클러스터는 더이상 사용되지 않으므로 종료 시키고, 로그 디렉토리 및 데이터 디렉토리 삭제.
  5. 2.3.X 클러스터를 삭제한 노드에 6.4.X 설치. 이때, 임시서버에 만든 클러스터에 join 될 수 있도록 설정. 여기까지 완료 되면 6.4.X 클러스터는 기존 대비 두배 많은 노드 수를 가지게 됨 (기존 노드 + 임시 서버)
  6. 어플리케이션들이 6.4.X (기존서버)를 바라보도록 설정. (임시서버 제거 준비작업)
  7. 임시서버 노드들을 한대씩 내리면서 기존 서버로만 구성된 클러스터 생성. (사용량이 많다면 shards re-allocate가 완료된 후 한대씩 내리면서 작업)

# 주요 작업 상세

2.3.X의 데이터는 DB에서 직접 인덱싱 하는 인덱스와, ES to ES 로 인덱싱 하는 데이터가 있는데, DB to ES는 마이그레이션 용도로 만든 프로그램을 사용하였고 ES to ES는 _reindex api 를 이용하여 색인 하였습니다.

migration

DB to ES 색인, ES to ES 색인 할때 성능 향상을 위해서는 아래 설정을 조정해 가면서 가장 빠르고 안정적으로 마이그레이션 할 수 있는 값을 찾아야 합니다. (다수의 테스트 마이그레이션 필요)

※ 아래 설정들은 모두 6.4.X 클러스터에 적용되어야 하는 값들 임
index.number_of_replicas: “0” 으로 설정 (동적 변경 가능)
index.refresh_interval: “-1” 로 설정 (동적 변경 가능)
indices.memory.index_buffer_size: 40% 로 설정 (동적 변경 불가능 하므로 elasticsearch.yml 에 추가 하고 클러스터 재시작 필요. default는 10%)

※ 실제 마이그레이션이 완료 된 이후에는 위 세 값들은 모두 원복 하는것이 좋습니다.

마이그레이션이 완료 되고 난 후 ES를 사용하는 모든 어플리케이션들이 임시 서버로 인덱싱/서칭 하도록 설정하고 (api가 변경되었으므로 프로그램 수정 & 배포 필요)

아래 그림과 같이 기존 2.3.X 노드가 설치되어 있던 서버들에서 2.3.X를 제거하고 6.4.X를 설치 하여 임시서버에 구성되어 있는 클러스터에 join 시킵니다.

cluster joining

위 그림과 같이 기존노드3, 임시노드3 인 경우 기존서버에 새로 설치한 6.4.X의 elasticsearch.yml 중 Discovery 일부

1
2
3
4
5
6
7
8
9
10
11
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when new node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
discovery.zen.ping.unicast.hosts: ["node1", "node2", "node3", "temp1","temp2","temp3"]

#
# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
#
discovery.zen.minimum_master_nodes: 4

안정적인 운영을 위해 discovery.zen.minimum_master_nodes를 4로 설정하고 join 시켰습니다.

여기 까지 완료 되면 기존 노드가 3대로 운영되고 있었다고 할때 6.4.X 클러스터는 6노드로 운영되고 있는 형상을 가지게 됩니다.

이제 임시 서버에 설치되어 있는 6.4.X를 제거 하기 위해 ES를 바라보는 모든 어플리케이션이 기존 서버 (아래 그림의 node1~3)을 바라보도록 설정 하고
임시 서버의 노드를 한대씩 순차적으로 제거 합니다.

※ 주의사항
node 1~3 에 discovery.zen.minimum_master_nodes 가 현재 4로 셋팅되어 있는데

임시 서버의 노드들을 탈락 시키기 전에 이 값을 2(최종 노드 갯수인3을 2로 나눈값 +1) 로 변경하고 클러스터 재시작을 한 이후 노드들을 제거 해야 함.

혹은 discovery.zen.minimum_master_nodes 는 dynamically 변경할 수 있는 설정이므로 온라인으로 변경 가능.

1
2
3
4
5
6
PUT _cluster/settings
{
  "transient": {
    "discovery.zen.minimum_master_nodes": 2
  }
}

그런데 어짜피 unicast hosts 에서 임시서버를 제거 해야 하므로 (이 셋팅은 dynamic 이 아님…..) elasticsearch.yml 수정 후 클러스터 재시작 추천.

elasticsearch.yml

1
2
3
4
5
6
7
8
9
10
11
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when new node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
discovery.zen.ping.unicast.hosts: ["node1", "node2", "node3"]

#
# Prevent the "split brain" by configuring the majority of nodes (total number of master-eligible nodes / 2 + 1):
#
discovery.zen.minimum_master_nodes: 2

minimum_master_nodes의 값을 4로 유지한채로 임시서버의 노드를 내리기 시작하면, 노드 갯수가 세개가 되는 순간 마스터 노드를 선출하지 못하게 되고 클러스터가 사용 불가능한 상태가 될 수 있습니다. (실제로 해당 작업중 직접 경험 ㄷㄷㄷ)

완료된모습

# 정리

ElasticSearch의 엄청난 EOL 스케쥴 - 2019년 3월이면 ES 5.6.X (5X의 최신버전)이 EOL 되는 무시무시함 - 과
6.4.0 이후부터 공식적으로 사용 가능한 한국어 형태소 분석기인 nori 를 사용하기 위해서는 버전업은 꼭 하는 것을 추천 하고
여유가 된다면 임시 서버를 받아서 클러스터의 중단 없이 버전업 하는 방법을 조심스레 추천 드려 봅니다.
사실상 버전업에서 가장 중요한 작업은 데이터 마이그레이션 이고 시간도 가장 많이 소요 됐습니다. 충분한 테스트와 검증 기간을 거친 후 버전 업그레이드를 진행하시길 바랍니다.

Share