Elastic Stack 알아보기

노드와 클러스터

• 노드: elasticsearch가 설치되는 물리적 또는 논리적 단위
• 클러스터: 여러 노드의 집합

전송 모듈과 HTTP 모듈

elasticsearch의 클러스터는 여러 개의 노드로 이루어져있고, 노드들은 서로 통신하면서 클러스터를 구성함

종류	내용
전송모듈	- 클러스터 내부에서 사용하는 모듈 - 클러스터 내부에서 노드와 노드 간의 통신에 사용됨 - 기본 포트: 9300 ~ 9399
HTTP 모듈	- 외부와 통신에 사용되는 모듈 - REST API를 통해 주로 노드와 외부 클라이언트 통신을 위해 사용됨 - 기본 포트: 9200 ~ 9299

노드

마스터 노드

• 클러스터의 모든 상태 정보를 관리하고, 각 노드들과 통신하면서 클러스터의 변화를 모니터링함
• 마스터 노드가 없으면 클러스터가 멈춤
• 사용자가 정할 수 없고 다수의 마스터 후보가 투표를 통해 결정함
• 사용자는 마스터 후보 노드만 지정할 수 있음

데이터 노드

• 인덱싱한 도큐먼트를 샤드 형태로 저장하여 데이터의 CRUD 작업과 검색, 집계 작업을 함
• 데이터 노드는 컴퓨터 리소스 사용량에 민감하기 때문에 모니터링하면서 부하 상태를 체크하고, 상황에 맞춰 명시적으로 샤드를 재분배하거나 데이터 노드를 추가, 변경하는 작업을 해야함

인제스트 노드

• 도큐먼트의 가공과 정제를 위해 인제스트 파이프라인이 실행되는 노드
• 인제스트 노드를 활용하면 로그스태시 설치 없이 비츠만 설치해 데이터를 수집하고, 인제스트 파이프라인을 이용해 이를 가공할 수 있음
• 모든 노드는 기본적으로 인제스트 노드 역할을 수행할 수 있음

머신러닝 노드

• 엘라스틱서치가 제공하는 머신러닝 기능을 이용할 수 있는 노드
• 베이직 라이센스로는 이용할 수 없음

코디네이터 노드

• REST API 요청을 처리하는 역할을 하는 노드
• 모든 노드가 코디네이터 노드 역할을 수행할 수 있음

전용 노드

• 기본적으로 노드에 엘라스틱서치를 설치하고 설정 파일을 수정하지 않으면 그 노드는 모든 역할을 수행하게 됨
• 노드별로 하나의 역할을 수행하는 전용 노드로 클러스터를 구성하면 시스템의 성능, 안정성, 비용면에서 효율적으로 활용할 수 있음
• 전용 노드는 성격에 따라 권장되는 하드웨어 사양도 다름
• 전용 노드를 사용하면 노드 역할에 따라 하드웨어를 달리 구성할 수 있고, 역할에 맞춰 최적화가 가능하기 때문에 대규모 시스템의 경우 전용 노드를 활용해 시스템을 구성하는 것이 좋음
  • 마스터 후보 전용 노드 : 클러스터의 상태 관리가 주된 역할이기 때문에 하드웨어 성능이 중요하지 않음
  • 데이터 전용 노드 : 클라이언트 요청을 처리하기 위해 빈번한 I/O 작업과 연산 작업이 필요하기 때문에 고사양의 하드웨어로 구성하고, 가능하면 전용 노드로 사용하는 것을 권장함
  • 인제스트 전용 노드 : 데이터 수집이 목적이기 때문에 연산 작업에 비해 저장장치는 크게 중요하지 않음
  • 코디네이터 전용 노드 : API 요청의 부하를 분산하는 역할이기 때문에 일반적으로 특별히 고사양의 하드웨어가 필요하지 않지만, 요청량이 많을 경우에는 메모리를, 무거운 집계 요청이 잦은 경우에는 CPU를 더 많이 할당하면 도움이 됨

노드 구성과 시스템 구성

• 시스템 규모가 커지면 노드들의 성격에 따라 전용 노드를 구성하고 그에 맞는 하드웨어와 운영 방식이 필요함
• 마스터 후보 전용 노드는 가능하면 1, 3, 5, 7, … 홀수 배열로 구성하며 나머지 노드들은 하트비트 같은 도구를 통해 주기적으로 상태 검사를 수행해 문제 여부를 판단하고 빠르게 복구할 수 있는 구조로 시스템을 구성하는 것이 좋음

소규모 클러스터

• 싱글 노드
  • 노드가 하나인 시스템
  • 노드에 이상이 발생하면 서비스가 중단되기 때문에 운영 시에는 거의 사용하지 않음
• 소규모 클러스터
  • 하나의 노드가 아닌 적어도 3 ~ 5대 정도의 노드가 있는 경우를 말함

대규모 클러스터

• 대규모 클러스터
  • 대규모 클러스터를 구성할 때는 마스터 후보 전용 노드와 데이터 전용 노드를 나누는 것이 중요함
  • 마스터 노드의 불안정은 클러스터 전체의 불안정으로 이어지므로 마스터 노드와 데이터 노드는 되도록 역할을 분리하고, 마스터 노드는 클라이언트의 요청이나 데이터 작업에 참여하지 않고 클러스터 관리에 집중시키는 것이 좋음
• 마스터 후보 노드
  • 하드웨어 성능은 비교적 중요하지 않지만 최소 3대를 준비하고 가능한 한 클러스터의 요청을 받지 않도록 구성함
• 데이터 전용 노드
  • 완전히 데이터 작업만 진행하고, 클러스터에 가장 많이 배치해야 함
  • 가능하면 고사양의 하드웨어를 구성하고 사양은 통일하는 것이 좋음
• 인제스트 전용 노드
  • 데이터 수집의 엔트리 포인트 역할로서, 특히 파이프라인을 이용한 데이터 정제 작업에 집중함
• 코디네이터 전용 노드
  • 검색, 집계 작업을 담당하는데, 서비스 성격에 따라 도입 유무를 결정해야 함

핫/웜/콜드 노드 구성

• 데이터 노드는 저장하는 데이터의 성격에 따라 핫/웜/콜드 노드로 구분할 수 있음
• 노드를 구분하는 이유는 데이터 노드를 효율적으로 사용하여 전반적인 클러스터 효율을 높이기 위함
• 핫 노드
  • 활발하게 인덱싱과 검색이 일어나는 인덱스들을 위치시키고 충분한 리소스의 하드웨어를 할당해주어야 함
  • HDD보다 SSD가 좋음
• 웜 노드
  • 자주 사용하지 않는 데이터를 저장함
  • 핫 노드에 비해 성능 좋은 디스크나 큰 메모리는 필요 없지만, 많은 데이터를 저장하기 위해 대용량 디스크를 사용함
• 콜드 노드
  • 프리즈 모드의 인덱스들을 저장함
  • 프리즈 모드의 인덱스는 평상시에는 메모리에 띄워놓지 않으므로 인덱스를 유지하기 위한 메모리 공간이 필요하지 않지만, 검색 요청이 올 때 인덱스 파일을 오픈하기 때문에 검색 시간이 많이 소요됨
  • 하드웨어는 시스템 내에서 지원하는 최소한의 사양으로 구성하되 디스크의 용량만 필요한 만큼 갖추면 되고 가용성을 위한 시스템 구성은 굳이 필요하지 않음

클러스터 백업

• 엘라스틱서치는 데이터 백업을 위해 스냅샷을 지원함
• 스냅샷을 찍기 전에 먼저 레포지토리부터 지정해야 함
• 레포지토리 : 스냅샷을 위한 저장공간
• 스냅샷을 최초에 한번 찍고 나서 이후에 다시 찍으면 이전에 마지막으로 저장된 스냅샷과 비교해 변경된 부분만 스냅샷에 기록함
• 변경사항만 반영되는 구조이기 때문에 스냅샷을 자주 찍는다고 해서 가끔씩 찍는 것에 비해 특별히 용량이 크게 늘어나지 않으므로 가능하면 자주 스냅샷을 찍어주는 방식을 권장함
• 실제 운영 과정에서는 스냅샷 수명주기를 관리하는 기능인 SLM(Snapshot Lifecycle Management)이 스냅샷 빈도나 관리를 자동화해줄 수 있음

샤드

• 여러대의 노드를 효율적으로 활용하기 위해 데이터를 샤드라는 단위로 나눠 분산 저장함
• 인덱스는 가상의 논리적 단위이며, 실제 도큐먼트의 인덱싱과 검색은 샤드에서 일어나게 됨
• 인덱스를 만들 때 샤드 개수를 정할 수 있음
• 프라이머리 샤드와 레플리카 샤드
  • 엘라스틱서치는 데이터의 원본을 프라이머리 샤드에 저장하고, 유실 방지와 가용성을 확보하기 위해 데이터 복제본인 레플리카 샤드를 만들어 사용함
  • 프라이머리 샤드 개수와 레플리카 샤드 개수는 사용자가 인덱스를 생성할 때 결정할 수 있음
  • 프라이머리 샤드의 개수를 3, 레플리카 샤드의 개수를 2로 지정하면, 원본 도큐먼트가 인덱싱 되는 3개의 프라이머리 샤드가 있고, 이 3개의 샤드가 각각 2개씩 복제되어 6개의 레플리카 샤드가 만들어짐
• 레플리카 샤드의 필요성 : 레플리카 샤드는 검색 처리 부하를 분산시켜 성능을 향상하는 효과를 줄 수 있음
• 레플리카 샤드는 프라이머리 샤드와 같은 노드에 위치해 있으면 고가용성이나 성능적 이점을 전혀 보지 못하고 단순히 저장공간만 2배를 사용하기 때문에 이런 경우에는 레플리카 샤드를 만들지 않음

운영 클러스터 구축

노드 구성 계획

• 노드 구성시 가장 먼저 확보해야하는 것은 최소 3개의 마스터 노드로, 하나의 마스터 노드가 다운되었을 때 스플릿 브레인 없이 서비스가 지속되게 하기 위한 최소한의 구성
• 데이터 노드가 하나일 경우, 복제본인 레플리카를 활용할 수 없으므로 장애 발생시 정상적인 서비스가 불가능하고 일반적인 상황에서도 성능을 충분히 발휘할 수 없음 따라서 데이터 노드를 최소 2대 이상 확보해야함

하드웨어 선정

• 하드웨어 선택이 사용자의 환경이나 용도에 따라 달라질 수는 있겠지만 일반적으로 너무 크지도 작지도 않은 중간 크기를 권장함
• 메모리
  • 가장 이상적인 메모리는 64GB로 단일 노드에 대해 충분한 힙 크기를 활용할 수 있는 수준임
• CPU
  • 단일 코어의 성능이 높은 CPU와 코어의 수가 많은 CPU 중 하나를 고르자면 더 많은 코어를 권장함
• 디스크
  • SSD를 권장, HDD를 사용할 경우 RPM이 빠른 제품을 권장
  • 네트워크 저장소는 피해야 함
  • 최대한 빠른 디스크 성능을 선택해야 함
• 하드웨어 통일
  • 각 노드들의 하드웨어 성능을 통일하는 것이 중요함
• 스냅샷 처리
  • S3와 같이 용량 제한이 없는 클라우드 저장소를 사용한다면 추가적으로 하드웨어에 대해 고민할 필요가 없음
• 엘라스틱서치 버전 선정
  • 엘라스틱서치는 특별히 안정화된 버전이나 장기간 지원하는 버전을 제공하지 않으므로 특별한 상황이 아니라면 가장 최신 버전을 사용하는 것이 좋음
  • 버전의 마지막 자리인 패치 버전이 0인 경우(x.x.0) 다음 패치 버전을 기다리는 것이 좋음
  • 메이저나 마이너 버전이 올라간 직후의 버전이기 때문에 새로 추가된 기능들에 버그가 포함될 가능성이 높음