[엘라스틱서치 실무가이드] 엘라스틱서치 샤드 vs. 루씬 인덱스

Posted by 김흥래 on April 15, 2019

다음은 엘라스틱서치 실무가이드의 일부 부분을 발췌한 내용입니다.

이미지01

9.2 엘라스틱서치 샤드 vs. 루씬 인덱스

앞 절에서 엘라스틱서치를 구성하는 다양한 개념과 용어를 살펴봤다. 이를 통해 클러스터는 다수의 노드로 분산돼 있으며 고가용성을 보장하기 위해 노드 내부에 다수의 샤드를 가지고 있다는 사실도 알게 됐다. 엘라스틱서치에서 실제 데이터를 가지고 있는 최소 단위의 검색 모듈을 샤드라고 볼 수 있는데 그렇다면 샤드의 정체는 무엇일까?

앞에서 엘라스틱서치는 루씬 라이브러리를 샤드 내부에 가지고 있으며, 이 루씬 라이브러리가 핵심 모듈이라고 설명한 바 있다. 루씬은 다수의 클래스로 구성돼 있는 검색 라이브러리이고, 이 중에서 가장 중요한 클래스가 바로 IndexWriter와 IndexSearcher이다. 간단히 설명하자면 IndexWriter는 데이터를 색인하는 클래스이고, IndexSearcher는 색인된 데이터를 검색 결과로 제공하는 클래스다. 사실상 이 두 개의 클래스가 루씬의 핵심이라고 해도 과언이 아니다.

IndexWriter와 IndexSearcher를 가지고 색인과 검색을 동시에 제공하는 루씬 인스턴스를 루씬 인덱스라고 하는데, 사실 하나의 엘라스틱서치 샤드는 하나의 루씬 인덱스라고 설명할 수 있다. 우리가 알고 있는엘라스틱서치 인덱스는 물리적으로 분산된 엘라스틱서치 샤드를 논리적인 관점에서 하나의 거대한 데이터로 바라보는 것이다.

이미지01

그림 9.1 엘라스틱서치의 인덱스 구조

루씬 인덱스 내부에는 세그먼트라는 특수한 자료구조가 다수 존재한다. 루씬 인덱스는 세그먼트를 이용해 검색을 수행하는데, 세그먼트는 내부적으로 역색인 구조이기 때문에 이를 통해 빠른 검색 결과를 얻을 수 있다. 물론 샤드가 단순히 루씬 그 자체만은 아니다. 샤드 내부적으로 엘라스틱서치에서 추가한 다양한 기능을 포함하고 있기 때문이다. 하지만 그 본질이 루씬 인덱스라는 사실에는 변함이 없다. 그러므로 하나의 샤드는 자체적으로 데이터를 색인하고 검색할 수 있는 가장 작은 크기의 단일 검색엔진이라고도 할 수 있는 것이다.

엘라스틱서치는 독립적인 루씬 인덱스를 엘라스틱서치 샤드라는 형태로 확장해서 제공한다. 루씬 인덱스가 자기 자신이 가지고 있는 세그먼트 내에서만 검색이 가능하다는 것과 달리 샤드는 모든 샤드가 가지고 있는 세그먼트들을 논리적으로 통합해서 검색할 수 있다. 이는 다수의 인스턴스 간에 데이터를 분산 저장할 수 있는 근간이 되고, 이를 통해 분산 클러스터를 구축하는 것이 가능해진다.

분산 시스템의 특성상 시스템의 고가용성을 보장하기 위해 다수의 샤드와 레플리카를 하나로 묶어서 클러스터를 구성하고 이러한 일련의 과정은 사용자에게 철저하게 블랙박스로 숨겨진다.


세그먼트

  • 루씬 내부에 존재하는 자료구조다.
  • 역색인 구조로 생성되어 읽기에 최적화돼 있다.
  • 하나의 루씬 내부에서만 존재할 수 있고 확장이 불가능하다.

루씬 인덱스

  • 검색과 색인 기능을 가진 최소한의 검색엔진이다.
  • IndexWriter로 색인 과정을 통해 세그먼트를 생성한다.
  • IndexSearcher를 이용해 세그먼트를 검색한다.
  • 자신이 가진 세그먼트 내에서만 검색이 가능하다.

엘라스틱서치 샤드

  • 엘라스틱서치에서 제공하는 가장 작은 단위의 검색엔진이다.
  • 내부적으로 루씬을 확장해서 검색엔진 역할을 수행한다.
  • 다수의 샤드가 협력해서 존재하는 모든 세그먼트를 검색할 수 있다.

루씬 인덱스의 경우 데이터를 저장할 때 물리 머신이 제공하는 리소스의 한계를 뛰어넘을 수 없다는 치명적인 문제가 있었다. 하지만 엘라스틱서치 샤드는 이러한 한계를 뛰어넘어 데이터를 무한으로 확장할수 있는 계기를 마련하게 된 것이다. 엘라스틱서치는 이러한 샤드를 바탕으로 클러스터를 구축하고, 대용량 데이터의 색인 및 다양한 검색 작업을 지원할 수 있게 됐다. 엘라스틱서치는 기본적으로 분산 처리되도록 설계됐기 때문에 대용량 데이터를 비교적 손쉽게 다루고 서비스할 수 있다.

서비스를 운영하다 보면 시간이 지남에 따라 데이터 크기는 점점 더 커지고 그에 비례해서 성능상의 문제가 발생할 가능성 또한 커진다. 클러스터에 저장된 데이터가 많아질수록 문제가 발생했을 때 이를 해결하는 것도 어려워진다. 클러스터의 성능 문제가 발생하면 샤드 수에 대한 고민을 다시 하게 되는데 앞에서 설명했다시피 샤드의 수는 운영 중에 변경이 불가능하다. 그러므로 맨 처음으로 인덱스를 설계할때 데이터 크기에 대한 충분한 고민이 필요하게 되고 그에 따라 샤드의 수를 신중하게 결정해야 한다.




Always with you.
책관련 페이스북 Q&A : http://facebook.com/엘라스틱서치-실무-가이드-343249896296014
책관련 유튜브 채널 : https://www.youtube.com/channel/UCcAi2EzWdEobxRsJ14Zo6vg
책관련 문의 메일 : elasticsearch.guide@gmail.com
연관도서  
이미지02 엘라스틱서치를 이용하여 검색사이트 구축 및 운영을 분들을 위한 책입니다.

엘라스틱 실무가이드 (한글 검색 시스템 구축부터 대용량 클러스터 운영까지)
YES24 : http://www.yes24.com/Product/Goods/71893929
이미지03 검색 데이터가 내부적으로 어떻게 색인되는지에 대한 원리를 설명한 책입니다.

실전비급 아파치 루씬7 (엘라스틱서치 검색엔진을 향한 첫걸음)
YES24 : http://www.yes24.com/Product/Goods/66544696
이미지04 Logstash와 Kibana를 이용하여 데이터 시각화를 어떻게 하는지 설명한 책입니다.

실전비급 엘라스틱 스택6.4 (엘라스틱서치, 로그스태시, 비츠, 키바나로 데이터 수집부터 분석, 시각화까지)
YES24 : http://www.yes24.com/Product/Goods/67466481