infra/Kubernetes

kubernetes ELK 설치 - Elasticsearch Node, Cluster 설계

jjuni_96 2025. 4. 12. 20:31
728x90

Elasticsearch node 역할

elasticsearch의 node들은 아래와같은 역학들을 가지고있다.

 

Master Node

Elasticsearch Cluster 구성을 관리, 제어(인덱스 생성/삭제)를 담당한다.

 

Elasticsearch Cluster는 최소 1개의 마스터노드를 가지고 있어야하며, 데이터 무결성을 위해서 최소 3개(split-brain 방지)의 마스터노드를 권장한다고한다.

 

 

Data  Node

data를 실제로 저장하고 검색 로직을 처리하는 노드
데이터를 처리하기 때문에 cpu, mem 사용량이 많다.

 

 

Ingest  Node

data를 Elasticsearch 에 저장하기 전에 전처리 하는 노드
Ingest Pipeline을 이용해서 데이터 필터링, 전환, 정규화 등의 작업을 수행한다.

 

 

 

 

 

Elasticsearch Cluster 구성

사실 이 구성이 가장 고민을 많이 했던 부분이다. 우선 방식은 아래와같은 방식들을 생각 하였다.

 

1. Elasticsearch 1 (All-In-One)

테스트 및 저사양 서비스에서 사용하기 위한 구축 방법

장점

단일 노드에서 master + data + ingest 모든 역할을 가지고 있기때문에 셋팅이 간편하다.

 

단점

1. Data Backup이 없기 때문에 replica shard 생성 불가
    -> 데이터 유실 가능성 존재
2. master 선출 불가
    -> 클러스터 전체 중지
3. 롤링 업데이트 불가능
    -> 단일 노드이기 때문에 무중단 서비스 배포 불가능
4. 확장성/성능 한계
    -> cpu, mem, disk 모두 하나의 노드에 의존하므로 성능 병목이 발생할 수 있다

 

 

 

2-1. Elasticsearch 3 (master, data, ingest)

각 노드별 역할 분리를 통한 구축. 아래와같은 이유들로 인해서 분산처리 환경에서 테스트 용도로 적합한 듯 하다.

장점

1. 각 노드별 역할이 분리되어 있기 때문에, 전체가 아닌 일부분의 장애만 발생
2. 각 노드별 모니터링을 기능별로 확인할 수 있다
3. 향후 수평 확장이 용이
    노드별 역할일 분리되어 있어서 부족한 서비스만 scale up/out 할 수 있다.

 

단점

1. master node 장애 발생 시 All Stop (SPOF)
    master node가 죽어버리면 선출 과정이 일어나지 않기 때문에 클러스터 전체가 멈춰버림
2. data node 가 1개여서 replica shard  생성 불가
    -> 데이터 복제본이 없기 때문에 유실 가능성 존재
3. 보여주기식 분산환경 구성
    각 역할별로 노드가 구축되기 때문에 실제로는 싱글 마스터 + 싱글 데이터 구조

 

 

 

2-2. Elsaticsearch 3 (master+data+ingest)

각 서비스별 역할 분리를 하지 않고 master + data + ingest를 설치하는 경우이다. 

소규모 운영 및 poc 단계에서 적합한 서비스 구성인 것 같다.

장점

1. 고가용성 확보 가능
    -> 각 노드에 master가 있기 때문에 Qurom(장애 시 선출) 가능
2. replica shard 가능
    -> 특정 노드가 죽어도 replica shard가 있어서 데이터 보존이 가능, 검색 성능 향상
3. 트래픽 분산 가능
    -> 각 서비스들이 분산처리를 하기때문에 로드밸런싱 효과가 있다
4. 설정 단순
    -> 각 노드들이 모든 역할을 가지고있기 때문에 동일한 설정으로 적용하면 된다.

 

단점

1. 장애 격리 불가능
    -> 각 노드들이 모든 역할을 가지고있다보니, 특정 서비스(ingest)에 몰리면 master, data 노드가 제 역할을 못할 수 있다
2. 운영 환경에서 역할 분리 불가능
    -> 서비스 규모가 커지면 ingest, search 가 자원을 많이 잡아먹음
3. 모니터링 복잡도 증가
    -> 역할이 겹치기 때문에 특정 리소스(CPU/MEM)증가가 어떤 역할때문인지 확인 어려움

 

 

3. 고가용성 구성(HA)

이 구성은 대규모 구성이 되어있거나 실제 운영중인 서비스에서 확장해서 구축해야하는 서비스같다.

각 역할별로 노드를 나눠서 구축하는 방법이다.

 

이 부분은 너무 복잡하니 대략적으로만 작성하면 아래와 같다.

master 3 이상 홀수
data 3
ingest 2
기타 서비스들 +a

 

 

 

 

마치며

분산처리 환경에서 Elasticsearch Cluster 설계는 현재 상황에 맞게 구성을 해야하고, 역할분리/안정성 과 같은 고려를 많이 해야하다보니 복잡한 것 같다. 

당장은 테스트 용도로 진행할 예정이라 단일 Node로 각 연동 과정을 진행해볼 예정이다.

 

 

 

 

Refs

Elasticsearch Node 설명: https://esbook.kimjmin.net/03-cluster/3.3-master-and-data-nodes

 

3.3 마스터 노드와 데이터 노드 - Master & Data Nodes | Elastic 가이드북

이 문서의 허가되지 않은 무단 복제나 배포 및 출판을 금지합니다. 본 문서의 내용 및 도표 등을 인용하고자 하는 경우 출처를 명시하고 김종민(kimjmin@gmail.com)에게 사용 내용을 알려주시기 바랍

esbook.kimjmin.net

 

Elasticsearch cluster 구성 : https://esbook.kimjmin.net/03-cluster/3.1-cluster-settings\

 

3.1 클러스터 구성 | Elastic 가이드북

이 문서의 허가되지 않은 무단 복제나 배포 및 출판을 금지합니다. 본 문서의 내용 및 도표 등을 인용하고자 하는 경우 출처를 명시하고 김종민(kimjmin@gmail.com)에게 사용 내용을 알려주시기 바랍

esbook.kimjmin.net

elasticsearch node

 

728x90
반응형
LIST