Ch09. 엘라스틱서치와 루씬 이야기 - 클러스터 관점에서 구성요소 살펴보기

엘라스틱 서치는 기본적으로 클러스터라는 단위로 데이터를 제공한다. 클러스터는 하나 이상의 물리적인 노드로 이뤄지며, 각 노드는 모두 데이터를 색인 및 검색 기능을 제공하는 물리적인 서버이다. 내부에는 루씬 라이브러리가 자리 잡고 있다.

클러스터

• 클러스터는 데이터를 실제로 가지고 있는 노드의 모음이다.(엘라스틱서치에서는 관련된 모든 노드들을 논리적으로 확장해 클러스터라고 부른다.)
• 같은 클러스터 내부의 데이터만 서로 공유가 가능하기 때문에, 연관된 모든 노드는 하나의 클러스터에서 구성원으로 연결되어야 한다.
• 같은 클러스터를 구성하는 노드들은 같은 클러스터 이름으로 설정해야 한다(클러스터 이름을 통해 구성원 인식)
  • 같은 클러스터 내부 노드는 데이터 색인, 검색 작업을 함께 수행하며, 장애 시, 데이터 복구 작업도 서로 협력한다.

Cross Cluster Search
실무에서는 데이터 성격에 따라 다수의 클러스터를 운영하게 되지만, 시간이 흐르고 비즈니스가 복잡해지면 다수의 클러스터를 함께 검색해야 하는 일이 빈번해진다.
엘라스틱서치에서는 다수의 클러스터를 한 번에 검색할 수 있게 Cross Cluster Search라는 새로운 기능을 제공하며, 이를 통해 다수의 클러스터 데이터를 한 번에 검색하는 것이 가능해진다.
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cross-cluster-search.html

노드

• 물리적으로 실행된 런타임 상태의 엘라스틱서치를 노드라고 부른다.
• 노드는 논리적인 클러스터를 이루는 구성원의 일부이며 실제 데이터를 물리적으로 가지고 있는 단일 서버이다.
• 실행 시, 노드는 클러스터에 의해 UUID가 할당되며, 클러스터 내에서 할당된 UUID로 서로 식별한다.(다른 이름으로 할당할 수 있다.)
  • 노드의 이름은 같은 클러스터 내부에서 각각의 노드를 식별하는 유일한 이름이기에 신중하게 변경해야한다.
• 노드는 내부에 다수의 인덱스를 가지고 있다.
• 같은 클러스터 내부에 존재하는 모든 노드는 서로 다른 노드와 수시로 정보를 주고받는다.
• 기본적으로 모든 노드는 마스터 노드와 데이터 노드의 역할을 동시에 수행할 수 있도록 설정되어 있는데 실제 운영 시에는 분리하는 것이 좋다.(노드를 역할에 따라 분리해서 운영하는 것을 권장하며 특히 마스터 노드는 물리적으로 분리해서 독립적 운영하는 것을 권장)
  • 마스터 노드: 클러스터의 제어를 담당한다.(node.master = true)
  • 데이터 노드: 데이터를 보유하고, CRUD, 검색, 집계 등 데이터 관련 작업을 담당(node.data = true)
  • 인제스트 노드: 색인 전 전처리 작업을 담당(node.ingest = true)
  • 트라이브 노드: 여러 클러스터를 제한적으로 연결해서 동시에 검색을 수행할 수 있도록 제공하는 특수한 목적을 노드(Deprecated, Cross Cluster Search로 대체)
  • 코디네이팅 노드: 검색이나, 집계 시 분산 처리만을 목적으로 설정된 노드. 대량의 데이터를 처리할 경우 효율적으로 사용할 수 있는 노드이다.

인덱스

• 유사한 특성을 가지고 있는 문서를 모아둔 문서들의 컬렉션이다. 
• 클러스터 내부에 생성되는 모든 인덱스는 클러스터 내에서 유일한 인덱스 명을 가져야 하며, 인덱스 명을 통해 데이터 생성/수정/삭제/검색이 이뤄진다.
  • 인덱스 명은 모두 소문자로 설정해야 하며, 엘라스틱서치에서 강제하는 사항이다.
• 과거 인덱스 내부에 여러 타입을 생성하는 것이 가능했지만 현재는 하나의 타입만 생성해야 하며, 논리적으로 분리할 필요가 있다면 인덱스를 물리적으로 분리해서 생성해야 한다.

참고
루씬 인덱스: 루씬에서는 전문을 분석하고 분석된 결과를 물리적인 디스크로 저장한다.(색인) 이 과정에 의해 생성된 데이터를 루씬에서는 인덱스라고 부른다.

인덱스와 타입의 관계
과거에는 여러 유형의 문서를 동일한 인덱스에 저장할 수 있도록 타입이라는 개념을 제공했으나, 다양한 문제로 현재는 폐기(Deprecated)되었다.

 

문서

• 검색 대상이 되는 실제 물리적인 데이터
• 문서는 인덱스를 생성할 수 있는 기본적인 정보 단위로, 엘라스틱서치에서는 JSON 형식으로 표현된다.
• 인덱스에는 원하는 만큼의 많은 문서를 저장할 수 있으며, 실제로는 물리적인 샤드 형대로 나눠져 다수의 노드로 분산 저장된다.

샤드

• 인덱스에 많은 양의 문서가 저장이 될 수 있으나, 하나의 하드웨어에서는 리소스 이상을 데이터를 저장할 수 없기에 샤드라는 개념이 나왔다.(데이터를 분산 저장하여 수평 확장이 가능)
• 샤드는 인덱스의 전체 데이터를 분산해서 가지고 있는 부분집합니다.(각 샤드는 자신이 가지고 있는 데이터만으로 독립적인 검색 서비스가 가능해야 한다)
• 엘라스틱서치는 인덱스 생성 시 기본적으로 5개의 샤드로 데이터가 분산되도록 생성되고 설정에 따라 변경할 수 있다.
• 실제 인덱스에 쿼리 요청 시, 인덱스가 가지고 있는 모든 샤드로 검색 요청이 전달되고 각 샤드에서 검색 후, 그 결과를 취합하여 최종 결과로 제공한다.
  • 색인 데이터가 샤드로 분산되는 과정이나, 검색 시 각 샤드로 분산 처리되는 프로세스는 사용자는 몰라도 된다.
• 샤딩이 중요한 점
  • 지속적으로 증가하는 컨텐츠가 수평적으로 분할되어 하드웨어 한계를 극복할 수 있다
  • 여러 노드에서 샤드를 통해 분산 처리되므로 성능이나 처리량을 향상할 수 있다

레플리카

• 샤드의 복제본을 레플리카라고 한다.
• 엘라스틱서치는 인덱스를 생성 시, 1개의 레플리카 세트를 생성한다.(검색 시 레플리카가 활용되기 때문에 잘 활용하면 읽기 분산에 유리)
• 네트워크 특성상 특정 노드가 오프라인 상태로 변경될 경우 엘라스틱서치는 레플리카를 이용한 페일오버 메커니즘을 통해 안정적인 클러스터 운영을 보장한다.
• 인덱스가 생성될 때 샤드 개수와 레플리카 개수를 자유롭게 설정 할 수 있다.
  • 단, 인덱스가 생성된 이후에는 샤드 갯수를 변경하는 것이 불가능하다.
  • 레플리카는 인덱스가 생성된 이후에도 변경 가능하며, 트래픽에 따라 유연한 대응이 가능해진다.

엘라스틱서치와 가용성
엘라스틱서치에서는 샤드나 노드에 장애가 발생할 경우 즉각 복구가 가능하기 때문에 안정적인 클러스터 운영이 가능해진다. 페일오버 메커니즘을 성공적으로 구현하기 위해 레플리카는 기본적으로 원본 샤드가 존재하지 않는 노드에서 생성되며, 검색 시 샤드와 레플리카에서 병렬로 실행되기 때문에 검색 성능이 좋아지는 결과를 가져온다.

세그먼트

• 루씬에 데이터가 색인되면, 데이터는 최소한의 단위인 토큰으로 분리되고 특수한 형태의 자료구조(세그먼트)로 저장이 된다.
• 세그먼트는 읽기 최적화된 자료구조로 역색인이라는 특수한 형태로 변환되어 물리적인 디스크에 저장된다.
• 검색엔진 특성상 읽기 비중이 높기 때문에 효율적으로 검색될 수 있도록 고안된 구조가 역색인 구조이다.