본문 바로가기

Back-End

Elasticsearch 설명서와 함께하는 Elasticsearch 기본 개념 살펴보기

반응형

Elasticsearch 가이드북을 읽으면서 공부하던 와중, 클러스터, 노드, 샤드 등 모르는 용어들이 등장했다. 그래서 개념을 먼저 익히고 넘어가려고 검색하던 와중에 Elasticsearch 설명서를 발견하였다. 이 설명서를 읽으면서 기본 개념을 먼저 공부하기로 했다.

 

NRT (Near RealTime)

Elasticsearch는 NRT 검색 플랫폼이다.

즉, 도큐먼트를 색인화(indexing)하는 시점부터 도큐먼트 검색이 가능해지는 시점까지 약간의 대기 시간(대개 1초)이 있다. 이는 Elasticsearch 가이드북의 Elasticsearch 특징 중 실시간 분석 부분에서도 서술되어 있다. 

 

클러스터

  • 하나 이상의 노드(서버)가 모인 것
  • 전체 데이터를 저장하고, 모든 노드를 포괄하는 통합 색인화(indexing) 및 검색 기능을 제공한다.
  • 클러스터에 하나의 노드만 있어도 문제 없다.
  • 각자 고유한 클러스터 이름을 가진 독립적인 클러스터를 여러 개 있어도 문제 없다.

 

 클러스터 이름

  • 고유한 이름으로 식별된다.
  • 기본 이름(default)은 "elasticsearch"이다.
  • 어떤 노드가 어느 클러스터에 포함되려면 클러스터 이름에 의해 클러스터의 구성원이 되도록 설정된다. (따라서 클러스터 이름은 중요하다!)
    • 동일한 클러스터 이름을 다른 환경에서 재사용해선 안된다. 노드가 잘못된 클러스터에 포함될 수도 있기 때문이다.
    • 예를 들면 개발, 스테이징, 프로덕션 클러스터에 'logging-dev', 'logging-stage', 'logging-prod' 라고 이름을 지을 수 있다.

 

클러스터 구성

Elasticsearch에서 클러스터는 '서버 클러스터'이지 않을까 싶다.

Elasticsearch의 노드들은 두 개의 네트워크 통신을 열어둔다.

  1. http 포트(9200~9299) : 클라이언트와 통신하기 위함
  2. tcp 포트(9300~9399) : 동일한 서버 내에 있는 노드 간에 데이터를 교환하기 위함

일반적으로 1개의 서버마다 하나의 노드를 실행하기를 권장하고 있다.

(ex 1) 3개의 다른 서버에서 각각 1개의 노드를 실행했을 때 클러스터의 구성 모습

(ex 2) 하나의 서버에 두 개의 노드를 실행했을 때 클러스터의 구성 모습

하나의 서버 내에서 여러 개의 노드를 실행하는 것도 가능하다. 이 경우에는 각 노드들이 9200, 9201, ... 순으로 차례대로 포트를 사용한다. 따라서 서버1의 두 번째 노드에서 실행되는 http, tcp 포트는 각각 9201, 9301이다.

이렇게 되면 클라이언트는 9200, 9201 등의 포트를 통해서 원하는 노드와 통신할 수 있다.

또한 여러 노드가 하나의 클러스터 내로 묶이기 위해서는 반드시 클러스터 이름이 동일해야 한다! 물리적으로 같은 서버나 네트워크망 내부에 있다고 하더라도 클러스터 이름이 동일하지 않으면 논리적으로 서로 다른 클러스터로 실행이 되고, 각각 별개 시스템으로 인식이 된다.

 

 

노드

  • 클러스터에 포함된 단일 서버
  • 데이터를 저장하고, 클러스터의 색인화 및 검색 기능에 참여한다.
  • 클러스터 이름으로 해당 노드가 어떤 클러스터의 일부를 구성하게 설정할 수 있다.
    • 기본적으로 각 노드는 'elasticsearch'라는 이름의 클러스터에 포함되도록 설정된다.
    • 만약 네트워크에서 다수의 노드를 시작할 경우, 이 노드가 모두 자동으로 'elasticsearch'라는 단일 클러스터를 형성하고 모든 노드가 이 클러스터의 일부가 된다.
    • 따라서 네트워크에서 실행 중인 Elasticsearch 노드가 없는 상태에서 단일 노드를 시작하면 기본적으로 'elasticsearch' 라는 이름의 새로운 단일 노드 클러스터(하나의 노드를 가진 클러스터)가 생성된다.
  • 하나의 클러스터에 노드를 원하는 개수만큼 포함시킬 수 있다.

 

노드 이름

  • 고유한 노드 이름으로 식별된다.
  • 기본 이름(default)은 시작 시 노드에 지정되는 임의 UUID(Universally Unique Identifier)이다.
  • 기본 이름 대신 노드 이름을 정의할 수도 있다.
  • 네트워크의 어떤 서버가 Elasticsearch 클러스터의 어떤 노드에 해당하는지 식별해야 하기 때문에, 노드 이름은 관리 목적에서 중요하다.

 

 

인덱스

  • 비슷한 특성을 가진 도큐먼트의 모음
  • 예로 들면 고객 데이터에 대한 인덱스, 제품 카탈로그에 대한 인덱스, 주문 데이터에 대한 인덱스를 각각 둘 수 있다.

 

인덱스 이름

  • 고유한 인덱스 이름으로 식별된다.
  • 모두 소문자여야 한다.
  • 인덱스에 포함된 도큐먼트에 대한 인덱싱, 검색, 업데이트, 삭제 작업에서 해당 인덱스를 가리킬 때 사용된다.
  • 단일 클러스터에서 원하는 개수만큼 인덱스를 정의할 수 있다.

 

 

타입

  • 인덱스를 논리적으로 분류/구분한 것. 그 의미 체계는 모두 사용자가 결정한다.
  • 하나의 인덱스에서 하나 이상의 타입을 정의할 수 있다.
  • 여러 가지 동일한 필드를 갖는 도큐먼트에 유형을 정의하여 사용한다.
    • ex) 블로그 플랫폼을 운영하고 있는데 모든 데이터를 하나의 인덱스에 저장한다고 가정하자. 이 인덱스에서 사용자 데이터, 블로그 데이터, 댓글 데이터에 각각 유형을 정의할 수 있다.

 

 

도큐먼트 (문서)

  • 인덱싱할 수 있는 기본 정보 단위
    • ex) 어떤 단일 고객, 단일 제품, 단일 주문에 대한 도큐먼트가 각각 존재할 수 있다.
  • JSON 형식
  • 하나의 인덱스/유형에 원하는 개수의 도큐먼트를 저장할 수 있다.
  • 도큐먼트는 인덱싱 된 상태에서 인덱스에 포함된 어떤 유형으로 지정되어 인덱스 내에 있어야 한다.

 

 

샤드 & 리플리카

- 샤드

인덱스는 엄청난 양의 데이터를 저장할 수 있는데, 이 데이터가 단일 노드의 하드웨어 한도를 초과할 수도 있다. 예를 들면 10억 개의 도큐먼트로 구성된 하나의 인덱스에 1TB의 디스크 공간이 필요한 경우, 단일 노드의 디스크에서 수용하지 못하거나 혹은 단일 노드에서 검색 요청을 처리할 때 속도가 너무 느려질 수도 있다.

Elasticsearch는 이 문제를 해결하기 위해 인덱스를 샤드(shard)라는 조각으로 분할하는 기능을 제공한다. 인덱스를 생성할 때 원하는 샤드 수를 정의할 수 있고, 각 샤드는 독립적인 인덱스이며 클러스터의 어떤 노드에서도 호스팅할 수 있다.

 

 ❗ 주의할 점

  • 샤드는 인덱스를 쪼갠 것이다! (도큐먼트를 쪼갠게 아니라)
  • 샤드는 같은 클러스터 내 여러 노드에 흩뿌려진다! (인덱스에 뿌려지는게 아니라)

 

샤딩이 중요한 이유

  1. 콘텐츠 크기를 수평적으로 분할/확장할 수 있다.
  2. 작업을 여러 샤드에 분산하여 두고, 병렬화하여 성능과 처리량을 늘릴 수 있다.

 

샤드가 분산하여 배치되는 방식과 그 도큐먼트가 다시 검색 요청으로 집계되는 방식, 두 방식의 메커니즘은 모두 Elasticsearch가 알아서 관리해주므로 사용자가 따로 신경쓰지 않아도 된다.

 

- 리플리카

네트워크와 클라우드 환경에서는 언제든 오류가 일어날 수도 있는데, 이러한 경우에 샤드와 노드가 오프라인 상태가 되거나 사라지게 될 수도 있다. 이러한 경우를 대비하여 페일오버 메커니즘을 마련해야 한다.

이러한 취지에서 Elasticsearch는 인덱스의 샤드의 복사본을 하나 이상 만들 수 있는데, 이를 리플리카 샤드(replica shard) 줄여서 리플리카라고 한다.

 

리플리카가 중요한 이유

  1. 샤드/노드에 오류가 발생해도 다시 정상적으로 사용할 수 있다. 
  2. 모든 리플리카는 병렬적으로 검색될 수 있으므로 검색의 크기와 처리량을 늘릴 수 있다.

 

요약

  • 각 인덱스는 여러 개의 샤드로 분할할 수 있고, 하나의 인덱스는 리플리카가 없거나(복제하지 않음) 리플리카가 있을 수 있다(1개 이상 복사본이 있음).
  • 복제되면 각 인덱스는 기본 샤드(원본)와 리플리카 샤드(복사본)을 갖는다.
  • 리플리카는 그 원본인 샤드가 속한 노드와 다른 노드에 배정된다.
  • 샤드와 리플리카의 수는 인덱스가 생성될 때 인덱스 별로 정의할 수 있다.
  • 인덱스가 생성된 후에 리플리카 수는 변경할 수 있지만 샤드 수는 변경할 수 없다.
  • 기본적으로 Elasticsearch의 각 인덱스는 샤드 5개(6.x 이하 버전의 경우 / 7.0 버전이라면 1개임), 리플리카 1개를 가진다.
    • 따라서 클러스터에 2개의 노드가 있다면 인덱스는 샤드 5개와 리플리카 샤드 5개(샤드 1개씩 1개의 복제본을 가지기 때문. 1x5=5개)를 가지므로 기본적으로 총 10개의 샤드를 가진다.

 

🔹 전체 포함관계

서버 > 클러스터 > 노드 > 인덱스 > 도큐먼트

🔹 샤드 & 리플리카 관점의 포함 관계

서버 > 클러스터 > 노드 > 샤드 & 리플리카 (클러스터 내 존재하는 여러 노드에 흩뿌려짐)

 

 

 

 

반응형

'Back-End' 카테고리의 다른 글

logger  (0) 2022.03.07
[작성중]elasticsearch putty  (0) 2021.10.29
Elastic 가이드북과 함께 Elasticsearch 공부하기  (0) 2021.10.19
JavaScript TDD  (0) 2021.09.29
SQA, CI/CD, TDD  (0) 2021.09.27