Elastic Stack 아주 조금만 알아보자 - ElasticSearch 구조

구조 알아보기

앞선 포스팅에서 API 문서를 보려고 했더니, Shard, Node라는 단어들이 나왔다.

이번 포스팅은 이러한 단어까지 하나씩 알아가 보도록 할 것이다.

 

첫 포스팅에서 간단히 Elastic Search가 무엇인지 알아 보았는데, 좀더 세부적으로 알아가자.

 

Elastic Search 특징

Elastic Search의 내부에는 루씬(Lucene) 이라는 핵심 모듈이 들어있다.

 

루씬은 안정적이고 무료로 사용할 수 있는 오픈 소스 프로젝트로 만들어진 고성능 정보 검색(IR, Information retrieval) 라이브러리다.

IR (Information Retrieval)
문서를 검색하거나, 문서의 내용을 검색하거나, 문서와 연관된 메타 정보를 검색해 가는 과정.

루씬은 자바로 구현되었으며, API를 활용한 색인 / 검색 기능이 가능하다.

또한, 사용자 위치 정보 이용 / 다국어 검색 / 자동 완성 / 미리 보기 / 철자 수정 기능 등을 지원한다.

 

여기서 Elastic Search는 루씬이 제공하는 대부분의 기능을 지원한다.

루씬은 검색/색인에 필요한 API를 제공하지만 라이브러리 형태라 대부분 직접 개발을 해야 하지만,

Elastic Search는 설치 / 구성이 간편하며, 루씬의 기능을 제공하면서도 분산처리를 비롯해 대용량 데이터를 처리하기 위한 기능을 가지고 있다.

 

참고로, 루씬은 Solr / Tica 등의 기술에도 기반이 된다.

 

클러스터/노드

Elastic Search는 여러 개의 노드로 구성되는 분산 시스템이다.

 

노드란, 데이터를 색인하고 검색을 수행하는 단위 프로세스이며, 다시 말해 물리적으로 실행된 런타임 상태의 Elastic Search 이다. 

이는 실제 데이터를 물리적으로 가지고 있는 단일 서버이기도 하다.

 

클러스터는, 위 노드들의 모임으로, Elastic Search에서는 관련된 모든 노드들을 논리적으로 묶어 클러스터라고 한다.

즉, Elastic Search에서 가장 큰 시스템 단위이며, 노드들은 같은 클러스터 내부의 데이터만 서로 공유 가능하다. 반대로, 같은 클러스터를 구성하는 노드들은(같은 클러스터 이름으로 설정된 노드들) 데이터 색인이나 검색작업을 함께 수행하며, 장애 시 복구등 서로 협력하게 되어(복사본 유지) 보호하며, 이를 통해 자동 확장이 된다.

 

여러 대의 서버가 하나의 클러스터를 구성할 수도 있으며, 반대로 하나의 서버가 여러 클러스터를 구성할 수도 있다.

 

위의 노드는 클러스터에 의해 UUID가 할당되며, 클러스터 내에서의 식별 코드(기본 값)이다. 물론 이름은 직접 입력 가능하며, 이는 유일해야 한다.

 

앞선 포스팅에서 가장 큰 개념으로 Index를 배웠었는데, Node는 이러한 Index를 여러개 가질 수 있게 되며, Index는 아는 것과 같이 여러개의 Document를 가질 수 있다.

 

즉, 데이터는 여러 개로 분리된 인덱스들에 그룹으로 저장됨을 실습을 통해 보았었는데, 서로 다른 인덱스의 데이터를 하나의 질의로 검색하여 하나의 출력으로 도출하는 과정은 멀티 테넌시(Multi Tenancy) 구조라고 할 수 있다.

멀티 테넌시 (Multi Tenacy)
하나의 소프트웨어 인스턴스가 한 대의 서버 위에서 동작하면서 여러 개의 테넌트(여러 소프트웨어 인스턴스가 소프트웨어 인스턴스에 대해 공통이 되는 특정 접근 권한을 공유하는 사용자들의 그룹)를 서비스하는 아키텍처

일반적인 멀티 테넌시란 하나의 소프트웨어 인스턴스로 여러 고객에게 서비스를 제공하기 위한 아키텍쳐 그 자체를 말한다. 
이 개념이 클라우드 컴퓨팅에 적용되면서 제공하는 서비스가 가상머신이라면, 서비스 Provider 는 하나의 컴퓨터에 여러 개의 독립된 가상 머신을 만들어 다수의 테넌트에게 이 컴퓨팅 리소스를 서비스 할 수 있게 된다. 그리고 이게 클라우드 서비스 개념의 출발이다.

출처: https://jins-dev.tistory.com/entry/Software-Multi-Tenancy-와-Cloud-에서의-Multi-Tenancy [Jins' Dev Inside]

 

Node의 종류는 다음과 같다.

1. 마스터 노드 (Master Node)
2. 데이터 노드 (Data Node)
3. 인제스트 노드 (Ingest Node)
4. 코디네이팅 노드 (Coordinating Node)

 

마스터 노드는 클러스터의 제어를 담당하여, 전체 클러스터 상태의 메타 정보를 관리한다.

데이터 노드는 데이터를 보유하며 CRUD, 검색, 집계 등 데이터 관련 작업을 담당한다.

인제스트 노드는 색인 전 전처리 작업을 담당하며,

코디네이팅 노드는 검색이나 집계 시 분산 처리만을 목적으로 설정된 노드이고, 대량의 데이터를 처리할 때 효율적이다.

 

좀 더 자세히..

앞서, 클러스터와 노드라는 중요한 개념을 보았다.

Index와 Document는 알고 있으니, 샤드, 레플리카 등 좀 더 다양하게 알아보자.

 

인덱스는 매우 많은 양의 Document가 저장될 수 있다. 보통 하나의 하드웨어에서 제공되는 리소스 이상의 데이터를 저장할 수는 없는데, 물리적 한계를 뛰어 넘기 위해 샤드(Shard)라는 개념이 나왔다.

 

데이터를 분산 저장하는 기능으로, ES에서는 인덱스를 생성할 때 기본적으로 5개의 샤드로 데이터가 분산되도록 생성되고, 설정에 의해 샤드의 갯수를 원하는 만큼 변경할 수도 있다.

 

하나의 샤드는 인덱스의 부분 집합이며, 해당 부분 집합만으로도 독립적인 검색 서비스가 가능하다.

 

실제로 인덱스에 질의를 하게 되면, 인덱스가 가지고 있는 모든 샤드로 검색 요청을 보내고 각 샤드의 결과를 취합해 하나의 결과로 제공한다.

 

레플리카는 샤드의 복제본이다. ES는 인덱스를 생성할 때 기본적으로 1개의 레플리카를 생성한다. 이는 장애 복구를 위한 것도 있지만 검색에도 활용되어 읽기 분산에 유리해진다.

 

ES는 노드 장애 시 FailOver 메커니즘을 레플리카를 이용해 제공한다. (High Availability: 높은 가용성) 인덱스가 생성될 때 샤드 갯수와 레플리카 갯수를 자유롭게 설정할 수 있지만, 인덱스 생성 후에는 샤드 갯수 변경이 불가능하다.

만약 늘리고 싶다면 새롭게 인덱스를 만들고 기존 인덱스에서 새로 생성한 인덱스로 re-index해야 한다.

이는 리소스를 매우 많이 소비할 수 있으니, 처음부터 최적의 shard 갯수를 정하는 것이 중요하다. 다만, 레플리카는 자유롭게 변경 가능하다.

Failover(시스템 대체 작동)
평소 사용하는 서버와 그 서버의 클론 서버를 가지고 있다가 사용 서버가 장애로 사용이 어렵게 되었을 경우 클론 서버로 그 일을 대신 처리하게 해서 무정지 시스템을 구축하게 해 주는 것을 의미

 

이후에 조금 더 나아가자면 세그먼트라는 내용을 배울 수 있다.

 

다만, 이번 포스팅은 여기까지만 진행하고 추가적으로 세그먼트를 알아야 하는 상황에 조금 더 진행해보도록 하겠다.

 

[참고 사이트 : https://coding-start.tistory.com/176]

[참고 사이트 : https://www.slideshare.net/seunghyuneom/elastic-search-52724188]

---

※ Inflearn 강의, Naver D2 블로그 등을 참고해 정리한 내용입니다.

 

1편 > Elastic Stack 아주 조금만 알아보자 - Elastic Stack 이란?

2편 > Elastic Stack 아주 조금만 알아보자 - ElasticSearch 기본 실습

3편 > Elastic Stack 아주 조금만 알아보자 - ElasticSearch Mapping/Search

4편 > 현재 Post

5편 > Elastic Stack 아주 조금만 알아보자 - Aggregation

6편 > Elastic Stack 아주 조금만 알아보자 - Kibana

7편 > Elastic Stack 아주 조금만 알아보자 - LogStash

8편 > Elastic Stack 아주 조금만 알아보자 - LogStash 실습 1