Elasticsearch 시스템 구조
🙈

Elasticsearch 시스템 구조

Created
May 8, 2024 07:38 AM
Last edited time
Last updated June 1, 2024
Tags
ElasticSearch
Language
URL

Intro::

Elasticsearch 시스템 구조에 대해 알아봅시다.
 

클러스터의 구성

여러 서버에 하나의 클러스터로 실행

Elasticsearch의 노드들은 클라이언트와의 통신을 위한 http(9200~9299), 노드 간의 데이터 교환을 위한 tcp(9300~9399) 총 2개의 네트워크 통신을 열어둔다.
💡
일반적으로 1개의 물리 서버마다 하나의 노드를 실행하는 것을 권장하고 있다.
 
도큐먼트 → 인덱스 (샤드)
 
notion image
물론 한 서버에 여러 노드도 가능하다.
 
물리적인 구성과 상관 없이 여러 노드가 하나의 클러스터로 묶이기 위해서는 클러스터명 cluster.name 설정이 묶여질 노드들 모두 동일해야 합니다. 같은 서버나 네트워크망 내부에 있다 하더라도 cluster.name이 동일하지 않으면 논리적으로 서로 다른 클러스터로 실행이 되고, 각각 별개의 시스템으로 인식이 됩니다.

디스커버리

💡
노드가 처음 실행 될 때 같은 서버, 또는 discovery.seed_hosts: [ ] 에 설정된 네트워크 상의 다른 노드들을 찾아 하나의 클러스터로 바인딩 하는 과정을 디스커버리 라고 합니다. 디스커버리는 다음과 같은 순서로 이루어집니다.
 
notion image
 
 

인덱스와 샤드

💡
Elasticsearch 에서는 단일 데이터 단위를 도큐먼트(document) 라고 하며 이 도큐먼트를 모아놓은 집합을 인덱스(Index) 라고 합니다. 인덱스라는 단어가 여러 뜻으로 사용되기 때문에 데이터 저장 단위인 인덱스는 인디시즈(indices) 라고 표현하기도 합니다. 인덱스는 기본적으로 샤드(shard)라는 단위로 분리되고 각 노드에 분산되어 저장이 됩니다. 샤드는 루씬의 단일 검색 인스턴스 입니다.
 
notion image
 

프라이머리 샤드(Primary Shard)와 복제본(Replica)

인덱스를 생성할 때 별도의 설정을 하지 않으면 7.0 버전부터는 디폴트로 1개의 샤드로 인덱스가 구성되며 6.x 이하 버전에서는 5개로 구성됩니다. 클러스터에 노드를 추가하게 되면 샤드들이 각 노드들로 분산되고 디폴트로 1개의 복제본을 생성합니다. 처음 생성된 샤드를 프라이머리 샤드(Primary Shard), 복제본은 리플리카(Replica) 라고 부릅니다. 예를 들어 한 인덱스가 5개의 샤드로 구성어 있고, 클러스터가 4개의 노드로 구성되어 있다고 가정하면 각각 5개의 프라이머리 샤드와 복제본, 총 10개의 샤드들이 전체 노드에 골고루 분배되어 저장됩니다.
notion image
 
💡
노드가 1개만 있는 경우 프라이머리 샤드만 존재하고 복제본은 생성되지 않습니다. Elasticsearch 는 아무리 작은 클러스터라도 데이터 가용성과 무결성을 위해 최소 3개의 노드로 구성 할 것을 권장하고 있습니다.
 
같은 샤드와 복제본은 동일한 데이터를 담고 있으며 반드시 서로 다른 노드에 저장이 됩니다. 만약에 한 노드가 시스템 다운이나 네트워크 단절등으로 사라진다면 샤드가 유실되게 됩니다. 하지만 다른 노드에 다른 샤드가 존재하기 때문에 전체 데이터는 유실이 없이 사용 가능합니다.
 
처음에 클러스터는 유실된 노드가 복구되기를 기다립니다. 하지만 타임아웃이 지나 더 유실된 노드가 복구되지 않는다고 판단하게 된다면 Elasticsearch는 유실된 샤드와 동일한 샤드(다른 노드에 존재했던)를 통해 다시 replica를 만들어서 각 노드에 재배치합니다.
 
프라이머리 샤드와 레플리카를 통해 운영 중 노드가 유실되어도 데이터의 가용성과 무결성을 보장합니다.
 

샤드 개수 설정

샤드의 개수는 인덱스를 처음 생성할 때 지정할 수 있습니다. 프라이머리 샤드 수는 인덱스를 처음 생성할 때 지정하며, 인덱스를 재색인 하지 않는 이상 바꿀 수 없습니다. 복제본의 개수는 나중에 변경이 가능합니다.
 
$ curl -XPUT "http://localhost:9200/books" -H 'Content-Type: application/json' -d' { "settings": { "number_of_shards": 5, "number_of_replicas": 1 } }
 

마스터 노드와 데이터 노드

마스터 노드

  • 마스터 노드는 클러스터의 관리를 담당합니다. 클러스터란 서로 연결된 엘라스틱서치 노드들의 집합을 말하며, 이를 통해 데이터를 저장하고 처리합니다.
  • 마스터 노드의 주요 역할은 클러스터의 상태를 관리하고, 클러스터에 새로운 노드를 추가하거나 제거할 때 필요한 구성 변경을 조정하는 것입니다.
  • 또한, 데이터를 어디에 저장할지, 데이터 노드 간에 샤드(데이터 조각)를 어떻게 분배할지 결정합니다.
  • 클러스터 내에서 단 하나의 마스터 노드가 활성화되며, 나머지는 대기 상태로 있어 언제든지 활성 마스터 노드에 문제가 생길 경우 대체할 수 있습니다.

데이터 노드

  • 데이터 노드는 실제로 데이터를 저장하고, 검색 쿼리를 처리하는 노드입니다.
  • 사용자의 검색 요청을 받아 데이터를 조회하고, 결과를 반환하는 역할을 합니다.
  • 데이터 노드는 데이터를 샤드 형태로 저장하며, 이 샤드들은 다른 데이터 노드와 중복해서 저장될 수 있어서 데이터의 안정성과 빠른 검색 성능을 보장합니다.
 

Split Brain

클러스터 내의 노드들이 네트워크 장애 등으로 인해 서로 통신할 수 없게 되면, 각 분리된 그룹이 자신들만의 클러스터로 동작을 시작하며 자체 마스터 노드를 선출할 수 있습니다. 이렇게 되면 각각의 분리된 클러스터가 동일한 데이터에 대해 서로 다른 결정을 내릴 수 있어 데이터의 일관성과 정확성이 손상될 위험이 있습니다.

스플릿 브레인의 영향

  • 데이터 무결성 손실: 서로 다른 클러스터가 같은 데이터를 다르게 수정할 수 있으므로, 네트워크가 회복된 후 데이터의 일관성을 맞추기 어렵습니다.
  • 리소스 중복 사용: 동일한 작업이 여러 클러스터에서 중복 실행될 수 있어 시스템 리소스가 낭비됩니다.
  • 성능 저하: 데이터의 중복 관리와 일관성 문제 해결을 위한 추가적인 작업이 필요해집니다.

스플릿 브레인 방지 방법

엘라스틱서치에서는 스플릿 브레인 문제를 방지하기 위해 몇 가지 기술적 대책을 사용합니다:
  • 최소 마스터 노드 설정: 클러스터의 마스터 가능 노드 수의 과반수 이상이 동의해야 새로운 마스터 노드가 선출될 수 있습니다. 이 설정을 통해 네트워크 분할 상황에서 마스터 노드가 중복으로 선출되는 것을 방지할 수 있습니다.
  • 마스터 노드 선출 절차: 엘라스틱서치 클러스터는 마스터 노드가 갑자기 실패할 경우를 대비하여 항상 후보 마스터 노드 목록을 유지하며, 이 중에서 정상적인 통신이 가능한 노드만이 마스터 노드로 선출될 수 있습니다.
💡
엘라스틱서치 7.0 버전 이후로는 사용자가 최소 마스터 노드 수를 직접 설정할 필요가 없으며, 클러스터가 더 간단하고 효율적으로 초기 구성과 관리를 할 수 있게 되었습니다. cluster.initial_master_nodes 로 마스터 노드 가능성이 있는 초기 집합을 지정할 수 있습니다.

References::

Loading Comments...