고정 헤더 영역
상세 컨텐츠
본문
[Elastic Stack] Elasticsearch 노드 역할
Elasticsearch 노드 종류
Elasticsearch 클러스터에서 노드 역할을 분리하는 이유
Elasticsearch는 여러 노드를 클러스터로 구성하여 사용할 수 있다. 클러스터를 구성한다는 뜻은 클러스터와 클러스터에 참여하는 노드들에 대한 관리가 필요하다는 의미이다. 또한 Elasticsearch는 단순히 데이터를 저장하는 데 그치지 않고 심화된 통계처리를 통한 분석작업 또는 유료 라이센스의 경우 Machine Learning 등의 작업을 할 수 있다. 작은 규모의 클러스터에서는 각각의 Elasticsearch 노드가 모든 작업을 처리해도 괜찮지만 대규모의 클러스터에서는 각각의 역할을 수행하는 노드를 설정하여 작업을 하도록 하는게 관리 측면이나 하드웨어 스펙 관련 비용 등을 고려했을 때에 더 효율적이다.
Elasticsearch 노드 역할(roles)
공식문서 기준으로 Elasticsearch의 노드 역할은 다음과 같다.
masterdatadata_contentdata_hotdata_warmdata_colddata_frozeningestmlremote_cluster_clienttransform
위 노드 역할은 elasticsearch.yml 파일에서 node.roles 옵션을 통해 지정할 수 있으며, 따로 node.roles를 지정하지 않을 경우 해당 노드는 모든 역할을 다 한다.
마스터(Master) 노드
다른 빅데이터 플랫폼은 클러스터를 구성했을 때, 클러스터에 대한 관리를 하는 목적으로 Zookeeper를 설치해야 하는 경우들이 있다(e.g. 하둡, Kafka, NiFi 등). 하지만 Elasticsearch의 경우는 마스터(master) 노드가 그 역할을 하므로 Zookeeper와 같은 별도의 소프트웨어를 설치할 필요가 없다.
마스터 노드의 역할은 다음과 같다.
- 클러스터 내 노드 추가 및 삭제
- 인덱스 생성, 수정, 삭제
- 샤드 할당
- 클러스터 상태 관리
Elasticsearch 클러스터에는 반드시 하나의 마스터 노드 역할을 하는 노드가 있어야 한다. 클러스터 내 복수의 노드에 마스터 노드 역할을 하도록 설정할 수 있지만, 단 1개의 노드만 마스터 역할을 한다. 하지만 보통 고가용성을 위해 마스터 역할을 할 수 있는 마스터 후보 노드(master-eligible)를 최소 3대 정도 두는 것을 권장한다. 다른 노드의 경우 노드의 장애가 발생해도 클러스터의 서비스 자체에는 문제가 발생하지 않겠지만 마스터 노드에 장애가 발생하면 클러스터의 서비스가 동작하지 않는다. 마스터 후보 노드를 설정할 경우에는 마스터 후보 노드들이 마스터 노드가 갖고 있는 클러스터의 메타 정보 등을 같이 저장하고 있다가 마스터 노드가 장애가 나면 바로 마스터 역할을 대신 하므로 클러스터는 계속해서 서비스를 할 수 있다.
데이터(Data) 노드
데이터 노드는 물리적으로 데이터를 저장하는 노드이다. 즉, 인덱싱된 문서(document)를 샤드(shard) 단위의 세그먼트(segment)로 저장하는 노드이다. 뿐만 아니라 CRUD 작업, 검색 및 집계와 같은 데이터 관련 작업을 처리하므로 일반적으로 여러 노드 역할 중 가장 많은 부하를 받는 노드이다.
데이터도 일종의 라이프사이클(lifecycle)이 있다. 계속 쌓이는 데이터를 모두 저장할 수도 있겠지만 빅데이터를 계속 저장하는 것은 여러 이유로 매우 큰 부담이 될 것이다. 업무 요건에 따라서 빈번하게 검색하거나 분석하는 시기를 지나게 되면 데이터를 삭제하기 전까지 법령 또는 사내 규정에 의해 보관기간까지 데이터를 저장해야 할 수도 있다. 데이터의 크기가 크지 않다면 별 문제가 되지 않겠지만, 매일 일정 규모 이상으로 발생되는 빅데이터의 경우라면 데이터 라이프사이클 관리에 따라 보관 비용이 달라질 수도 있다. 데이터의 검색이나 분석이 필요한 시기에는 SSD 디스크에 저장하여 사용하다가 데이터를 사용하는 시기를 지나 단순히 보관만 하는 시기라면 HDD로 옮겨 더 저렴한 비용으로 저장하는 것이 효율적이다. 이것을 도와주는 기능이 Elasticsearch의 ILM(Index Lifecycle Management)기능 이고 물리적으로 데이터 노드를 data_hot, data_warm, data_cold로 나누어 사용을 한다(data_frozen은 유료 기능).
일반적으로 데이터를 처음 인덱스로 만들어 저장을 하게 되면 data_hot노드에 저장이 된다. 그러므로 data_hot 노드는 SSD 디스크를 사용하도록 권장한다. 이후 데이터에 대한 검색이나 분석이 빈번하지 않지만 가끔씩 필요한 시기가 되면 data_warm 노드로 이동을 하게 하며 data_warm 노드는 경우에 따라 SSD 또는 HDD 디스크를 사용하도록 권장한다. 검색 또는 분석 시기를 지나 단순히 보관해야 하는 시기가 온다면 data_cold 노드로 데이터를 이동하게 하며 data_cold 노드는 비용이 저렴한 HDD 또는 S3와 같은 Object Storage를 권장한다.
인제스트(Ingest) 노드
문서(document)의 가공과 정제를 위한 인제스트 파이프라인(Ingest Pipeline)이 실행되는 노드이다. 모든 노드는 기본적으로 인제스트 노드 역할을 수행할 수 있지만, 데이터 처리를 많이 해야 하는 클러스터의 경우에는 별도의 인제스트 전용 노드를 구성하는 것을 추천한다.
작은 규모의 클러스터인 경우 최적화를 보통 위해 마스터 노드와 데이터 노드만 고려한다. 인제스트 파이프라인을 따로 사용하지 않기 때문에 노드 역할에 인제스트 역할을 부여하지 않는 경우가 많다. 그런데 별도로 인제스트 파이프라인을 사용하지 않는다고 해도 시스템 인덱스가 사용하는 경우가 있으므로 왠만하면 같이 설정 하는 것이 좋다.
인제스트 노드는 수집되는 데이터를 가공하고 정제한다는 의미에서 Logstash와 비슷할 수 있다. 실제로 Elasticsearch에 데이터를 저장한다는 관점에서 Logstash의 Filter Plugin과 인제스트 파이프라인의 processors의 상당 부분 기능이 동일하다. 인제스트 노드를 별도로 가져감으로써 얻을 수 있는 이점은 Elasticsearch는 클러스터링으로 분산할 수 있다는 점이다. Logstash의 경우에는 단일 노드에서만 실행되므로 분산처리가 불가하다. 그래서 데이터 수집 양이나 각각의 노드 스펙 등을 고려하여 인제스트 노드 또는 Logstash 중에서 결정하면 좋을것 같다.
코디네이팅(Coordinating) 노드
기본적으로 모든 노드가 REST API 요청을 처리한다. 하지만 대규모의 클러스터의 경우 마스터 노드 또는 데이터 노드가 각자의 일을 하기도 바쁜데 많은 REST API까지 처리하게 될 경우 과부하가 될 수 있으므로 REST API 요청만 따로 처리하는 코디네이팅(Coordinating) 노드를 지정하여 처리하게 할 수 있다. 이 경우 코디네이팅 노드가 사용자 요청을 받아서 각 노드들에 전달하고 취합해 결과를 제공한다. 코디네이팅 전용 노드를 두게 되면 로드밸런싱(load balancing), 요청 라우팅, 요청 캐싱, 각 노드에서 계산된 결과에 대한 취합에 집중한다. 따라서 코디네이팅 전용 노드를 따로 세팅할 경우 데이터 노드의 부하를 줄이고 검색효율을 높일 수 있다.
그 외의 노드
Elasticsearch의 Machine Learning job을 위한 ml 노드, 통계 작업과 같은 Transform 기능을 위한 transform 노드, 원격으로 다른 클러스터를 컨트롤 하기 위한 remote_cluster_client 노드 등이 있지만 유료 라이센스가 필요한 기능이므로 본 포스팅에서 다루지는 않겠다.
Elastic Arthitecture Sample
만약 유료 라이센스를 사용한다면 노드 단위로 과금이 되기 때문에 노드를 추가하는 것에 대해 부담이 있을 수 있다. 위에서 살펴본 ingest only node 와 coordinating only node의 경우에는 별도로 과금을 하지 않기 때문에 서버비용만 추가하면 되므로 별도의 노드를 세팅할 것을 권장하기도 한다. 또한 클러스터의 고가용성을 위해 마스터 후보 노드들을 대략 3대정도 분리해 혹시라도 마스터 노드가 장애가 발생하더라도 곧바로 후보 노드가 마스터 노드가 될 수 있도록 세팅한다. 특히 운영 모드에서는 이중화에 대한 고려를 하여 노드를 계산해야 서비스에 대한 이슈 없이 운영할 수 있다. 특히 데이터 노드의 경우에는 디스크의 80% 이상 사용할 경우 Elasticsearch의 퍼포먼스가 저하되고 일부 기능을 사용할 수 없게 되는데, 데이터 노드의 장애로 인해 데이터가 이동될것 까지 고려해 실제로는 50%~60%의 데이터만 저장하는 것을 권장한다. 물론 이 사이즈는 프로젝트의 목적과 클러스터 내 서버들의 스펙에 따라 달라질 수는 있다.
대규모 프로젝트의 경우 최소 위와 같이 클러스터를 설정하는 것을 권장하지만 어디까지나 프로젝트의 규모와 요구사항에 따라 충분히 달라질 수 있다는 것을 고려해야 한다. 또한 위에서도 설명했듯이 Ingest 역할이나 Coordinating 역할은 따로 전용 노드를 두지 않아도 모든 노드들이 역할을 하기 때문에 오히려 한대 또는 두대의 전용 노드가 병목현상을 유발할 수 있으므로 모든 노드가 역할을 하게 두는 것이 좋을 수도 있다는 의견이 있다. 여러 가능성에 대해 잘 판단하고 테스트해보고 결정해야 하는 부분이다. 최적화의 길이 이렇게 멀고도 험하다.
마무리
이번 포스팅에서는 Elasticsearch 노드의 역할에 대해 다뤄봤다. 이 부분도 끝없이 파고들면 복잡할 수 있는 부분이다. 가장 중요한 것은 프로젝트의 목적이 어떻게 되는지 요구사항을 잘 파악하여 서버의 스펙을 잘 결정하고 거기에 따라 노드의 역할을 나눠야 할 것이다.
참고 자료
'Data Platform > Elastic Stack' 카테고리의 다른 글
| [Elastic Stack] Index vs Index Patterns(Data Views) (0) | 2022.06.25 |
|---|---|
| Windwos 10에서 Docker Compose로 TLS가 적용된 Elastic Cluster 구성 - Logstash 연결 (7.16.3 버전) (0) | 2022.06.12 |
| [Elastic Stack] Filebeat multiple output 에러 (0) | 2022.03.16 |
| [Elastic Stack] Elasticsearch Index와 Shard 개념 (0) | 2022.03.03 |
| [Elastic Stack] Elasticsearch 주요 용어 (0) | 2022.02.24 |
댓글 영역