[13장] 클러스터와 노드 구성

• 클러스터 구성 방법
• 노드
• 클러스터 동작 원리
• http계층, 전송계층
• 마스터 노드, 데이터 노드, 인제스터 노드
• 클러스터 백업 방법
• 샤드, 샤드 할당 과정, 모니터링, 샤드의 크기와 갯수 구성
• 클러스터, 노드, 인덱스 설정방법

개념 설명

• 클러스터: 여러 대의 컴퓨터를 병렬로 연결해 하나의 시스템을 구성하는 것
  • 고가용성, 시스템 성능 향상
  • 분산처리
  • 여러 노드의 집합
• 노드: 클러스터를 구성하는 요소
  • 엘라스틱서치 클러스터를 구성하는 하나의 인스턴스
  • 데이터 저장 및 인덱싱과 검색에 사용
  • 노드 이름이 중복되면 안 됨
  • 하나의 노드가 여러 역할 가능
  • 하드웨어의 영향을 많이 받음
• http 모듈
  • api 형태로 제공, 외부 클라이언트 앱과 통신시 사용
  • 9200번대 포트 사용
• 전송 모듈
  • 클러스터 내부 모듈 간의 통신에 사용
  • 노드간 분산처리
  • 9300번대 포트 사용

용어정리

• 마스터 노드: 클러스터의 상태 관리
• 데이터 노드: 데이터 처리
• 인제스트 노드: 파이프라인을 통해 도큐먼트를 인덱싱 하기 전 원하는 형태로 변형
• 도큐먼트: 데이터가 저장되는 기본 단위. json
• 인덱스: 도큐먼트 저장하는 논리적 단위. db table과 유사
• 샤드: 도큐먼트를 저장하는 기본 단위

노드

마스터 노드

• 클러스터는 반드시 하나의 마스터 노드를 가져야 함
• 인덱스 설정, 매핑정보, 물리적 위치, 클러스터 설정정보, 인덱스 템플릿 정보 등 클러스터의 모든 상태 정보를 관리
• 클러스터의 변화를 모니터링
• 마스터 노드가 없으면 클러스터가 멈춤
• 다수의 마스터 후보 노드가 투표를 통해 결정

마스터 노드 선출 과정

• 마스터 노드는 마스터 후보 노드 중 과반수가 넘는 표를 받은 노드가 됨
• 자신에게 투표 가능
• 마스터 후보 노드들은 마스터 노드의 정보를 궁유하고 있음
• 따라서 마스터 노드로 선출되는 즉시 마스터 노드로 역할을 할 수 있음

스플릿 브레인(split brain)

• 네트워크 장애 등으로 클러스터가 분리 되었을 때, 나누어진 각각의 서브 클러스터가 서로 마스터 노드를 선출하고 독립적인 클러스터로 동작하는 상태
• 스플릿 브레인이 발생하면 2개의 독립적인 클러스터에게 각각 요청 => 상태나 데이터 등에 차이가 생겨 추후 동기화 문제 발생
• 7.0 이후 버전 부터는 마스터 노드 선출 알고리즘이 변경(minimum_master_node를 직접 지정하지 않음) => 스플릿 브레인이 발생하지 않음

투표 전용 노드

• 7.3 버전부터 투표에는 참여하지만 실제 마스터 노드가 되지 않는 노드들이 추가됨
• 최소 마스터 후보 노드들이 부족한 경우 선출가능
• 마스터 후보 노드들이 대량으로 장애 발생시 시스템이 멈추지 않고 동작할 수 있게 함

데이터 노드

• 인덱싱한 도큐먼트를 샤드 형태로 저장하여 데이터의 CRUD, 집계 작업을 함
• 일반적으로 노드 중 가장 많은 부하를 받음
• 마스터 노드와 데이터 노드를 분리하는 것이 좋음
• 상황에 맞춰 샤드를 재분배하거나 데이터 노드들을 추가/변경 작업이 필요

인제스트 노드

• 가공과 정제를 위한 인제스트 파이프라인 실행
• 도큐먼트를 인덱싱하기 전 원하는 형태로 변형가능
• 로그스태시의 필터와 기능적으로 유사하나 실행주체가 엘라스틱서치
• 모든 노드는 기본적으로 인제스트 노드의 역할 수행이 가능 -> 데이터 가공이 많다면 인제스트 노드를 따로 구성하는 것이 좋음
• 프로세서, 파이프라인
  • 프로세서: 도큐먼트를 변경할 수 있는 기능적으로 구분되는 모듈
    • date, drop, grok, set, split ...
    • 조건문을 통해 분기처리 가능
  • 파이프라인: 프로세서의 집합
• on_failure: 예외 처리 방식. 프로세서 내에 있다면 프로세서 동작 중의 예외를, 파이프라인 내에 있다면 파이프라인 동작 중의 예외를 처리

그 외 노드

• 머신러닝 노드
• 코디네이터 노드
  • rest api 요청을 처리하는 역할
  • 모든 노드가 코디네이터 노드 역할 수행 가능
  • 요청 작업을 받아서 각 노드들에 전달하고 취합해 결과를 제공하는 역할
  • 무거운 집계의 경우 리소스가 많이 필요 => 코디네이터 작업이 많다면 별도로 구헝하여 데이터 노드의 부하를 줄이고 검색 효율을 높이자
  • 로드밸런싱, 요청 라우팅, 요청 캐싱, 취합
• 전용 노드
  • elasticsearch.yml의 node.roles에서 설정 가능
  • 여러가지의 노드 역할 또는 전용으로 설정도 가능

-	cpu	메모리	저장장치
마스터 후보 전용 노드	저사양	저사양	저사양
데이터 전용 노드	고사양	고사양	고사양
인제스트 전용 노드	고사양	중간사양	저사양
코디네이터 전용 노드	저사양	중간사양	저사양

노드 구성과 시스템 구성

• 마스터 후보 전용 노드는 홀수 배열로 구성 (과반수에 의해 선출되므로 짝수로 지정될 경우 문제 발생할 수 있음)핫, 웜, 콜드 노드 구성
• 데이터의 성격에 따라 hot/warn/cold로 구분
• 핫노드: 활발하게 인덱싱과 검색이 일어나는 인덱스 위치
  • 리소스 충분히 할당
  • SSD, 가용성 높이는 방법 고려
• 웜노드: 자주 사용하지 않는 데이터 저장
  • 쿼리의 빈도가 낮고 인덱싱은 일어나지 않는 인덱스
  • 좋은 디스크나 큰 메모리보다는 대용량 디스크 사용
• 콜드노드: 프리즈(freeze)모드의 인덱스 저장
  • 평상시에는 메모리에 올리지 않으므로 메모리 공간이 필요하지 않음
  • 검색 요청이 올 때 인덱스 파일을 오픈 => 검색 시간이 많이 소요
  • 정책상 장기간 보관해야하는 데이터
• 구성에 샤드 할당 필터링 기술이나 데이터 티어 사용
  • 샤드 할당 필터링: 샤드를 조건에 따르 특정 노드에 저장
  • 데이터 티어: 하드웨어가 동일한 노드들을 묶는 방법

샤드 할당 필터링

• 특정 노드에 소성을 달아 구분
• 노드에 속성을 달고 (elasticsearch.yml)
• 인덱스 설정에 샤드 필터링 추가

클러스터 백업

• 스냅샷은 클러스터 전체 혹은 특정 인덱스만 찍을 수 있음
• 리포지토리: 스냅샷을 위한 저장소
• 스냅샷: 특정 시각의 모든 데이터를 복사하여 데이터를 저장
  • 다시 찍으면 이전에 마지막으로 저장된 스냅샷과 비교하여 변경된 부분만 스냅샷에 기록
  • 스냅샷을 찍기 전에 리포지토리가 필요
• 스냅샷은 기존 데이터 대비 변경사항만 저장하기 때문에 특별히 용량이 크게 늘어나지 않음 => 자주 찍는 방식을 권장

샤드

• 여러개의 노드를 효율적으로 활용하기 위해 데이터를 샤드라는 단위로 나눠 분산저장
• 수평적 확장 가능 및 분산처리 가능
• 인덱스는 가상의 논리적 단위이며 실제 도큐먼트의 인덱싱과 검색은 샤드에서 일어남
• 세그먼트
  • 샤드 내에 세그먼트가 존재. 도큐먼트가 저장될 때, 샤드 내의 세그먼트로 저장됨
  • 인덱스가 물리적으로 저장되는 가장 작은 단위
  • 읽기에 최적화. 수정 불가
  • refresh 될 때마다 생성. 기본적으로 모든 샤드에서 1초마다 발생
  • refresh 되어야 새로 추가된 도큐먼트 검색이 가능
  • 샤드 안에 여러개의 세그먼트를 포함할 수 있음

프라이머리 샤드와 레플리카 샤드

• 원본: 프라이머리
• 복제본: 레플리카
  • 안정성 향상 및 성능 향상
  • 고가용성
  • 처리 속도 향상
• 할당과정: 미할당(UNASSIGNED), 초기화(INITIALIZING), 동작(STARTED), 재할당(RELOCATING)
  • UNASSIGNED: 샤드는 있지만 아직 노드에 할당되지 않은 상태
  • INITIALIZING: 샤드를 노드에 로딩중인 상태
    • 잠시 초기회를 위한 상태로 모니터링으로 발견하기는 쉽지 않음
    • 세그먼트들을 바로 검색 가능한 상태로 메모리에 올려두는 과정
    • 샤드를 사용할 수는 없다
    • 노드에 샤드는 추가된 상태이나 메모리에 온전히 적재된 것은 아닌 상태
  • STARTED: 샤드가 메모리에 올라간 상태
    • 샤드 접근 가능
    • 반드시 initializing 상태를 거침
  • RELOCATING: 샤드가 재배치 되는 단계
    • 노드의 고장이나 네트워크 문제로 노드가 추가 혹은 삭제 되는데, 샤드 재배치가 필요함
• 모니터링

health	설명
red	하나 이상의 프라이머리 샤드가 클러스터에 정상 적재되지 않음. 읽기/쓰기 정상동작 불가
yellow	프라이머리 샤드는 모두 적재. 하나 이상의 레플리카 샤드가 클러스터에 정상 적재되지 않음. 읽기/쓰기 동작 가능하나 장애시 문제 발생
red	프라이머리 샤드와 레플리카 샤드가 클러스터에 정상 적재되지 않음.

샤드 개수와 크기 구성

오버샤딩

• 문제
  1. 각 샤드는 개별적으로 리소스를 소비 => 성능에 좋지 않음
  2. 인덱스 검색시, 인덱스가 저장된 모든 샤드에 접근
• 샤드 수가 많으면 분산 및 병렬 처리에는 좋음

샤드 크기 관리

• 일반적으로 특정 조건을 기준으로 인덱스를 나눔
• rollover api 와 shrink api 를 이용하여 인덱스 샤드 크기를 관리하는 방법이 있다.
• rollover API
  • 인덱스가 특정 조건에 도달 했을 때, 새로운 인덱스를 생성하는 api
  • 요청이 있을 경우에만 발생하므로 요청 전까지는 샤드 크기가 커져도 새로운 인덱스를 생성하지 않음
  • 롤 오버 별칭을 사용하는 인덱스 이름은 반드시 -숫자로 끝나야 함
  • 롤 오버 조건 3가지: max_age, max_docs, max_size
  • 쓰기의 경우 롤 오버가 되면 새로운 인덱스가 맡게 되고, 읽기는 별칭이 같은 모든 인덱스가 참여함
• shrink API
  • 기존 인덱스의 프라이머리 샤드 개수를 줄이는 데 사용
  • 핫 노드에서 웜 노드로 이동하는 인덱스에 사용
  • 샤드 하나하나 모두 시스템 리소스를 사용하기 때문에 자주 사용하지 않는 인덱스의 샤드는 필요가 없음
  • 자주 사용하지 않는 기존 인덱스를 롤오버 하면서 샤드 갯수를 줄이기도 함
  • 필요한 설정
    1. 인덱스 내의 모든 샤드를 특정 하나의 노드로 옮긴다
    2. 레플리카 샤드를 비활성화 한다

설정

• 클러스터 > 노드 > 인덱스 레벨로 시스템 영향도가 높음

설정	설명
클러스터	로그 레벨이나 클러스터 전반에 관한 설정. rest api로 동적으로 변경 가능
노드	네트워크 인터페이스, 보안 설정등에 관한 설정. elasticsearch.yml에 정적으로 수정
인덱스	인덱스와 관련된 설정. 프라이머리 샤드나 레플리카 개수 등. 정적, 동적 설정 가능.

• 클러스터 설정
  • persistent(재시작 해도 존재), transient(재시작 하면 사라짐)
• 노드 설정
  • 자주 사용하는 노드 설정: node.roles, path.data
• 인덱스 설정
  • 대표적인 index 설정: number_of_shards, number_of_replicas, refresh_interval, blocks.read_only
  • 일부 설정(index.number_of_shards, shard.check_on_startup, index.codec)은 인덱스를 생성하거나 인덱스가 잠시 닫혀 있을 때만 변경 가능
  • 인덱스가 닫힌 상태
    • 인덱스가 파일 수준에서 저장되지만 힙 메모리에 로드되지 않아 읽기/쓰기가 되지 않는 상태. 검색도 불가.
    • 샤드 수가 너무 많아 클러스터 동작이 불안정하거나 오래된 인덱스를 저장하되 작업은 하지 않는 상태로 만들기 위한 용도

정리

• 클러스터 구성 방법, 노드, 샤드, 설정
• 마스터노드, 데이터노드, 인제스트노드, 기타노드
• 노드 구성 방법
• 핫/웜 노드, 스냅샷
• 샤드(프라이머리, 레플리카)
• rollover, shrink api
• 클러스터, 노드, 인덱스 설정 방법