참고한 링크 및 문헌

참고한 도서📚 : 시작하세요! 엘라스틱 서치

클러스터와 노드

엘라스틱서치의 가장 큰 시스템 단위는 클러스터(Cluster)다.
하나의 클러스터는 다시 여러 개의 노드(Node)로 이루어지며 서로 다른 클러스터는 데이터의 접근이나 교환을 할 수 없는 독립적인 시스템으로 유지된다.

클러스터는 반드시 한 개 이상의 노드로 구성되며 각 노드는 하나의 엘라스틱 서치 프로세스로써 실행된다.
엘라스틱서치는 클러스터명을 같게 유지하는 것만으로 여러 노드를 손쉽게 하나의 시스템으로 묶을 수 있다.
기존의 RDBMS와 같은 시스템은 시스템을 확장하려면 여러 복잡한 설정이 필요하지만 엘라스틱서치는 클러스터명만 같게 유지하고 프로세스만 실행하면 시스템 확장이 끝! 완전 간편하다👍👍

노드 바인딩

⭐💖노드 바인딩의 핵심은 같은 클러스터명을 갖는다는 것이다!⭐💖

노드 바인딩을 위해서는 먼저 헤드 플러그인이 설치되어 있어야 한다.

bin/plugin --install mobz/elasticsearch-head

다음으로 config/elasticsearch.yml 파일을 열고 클러스터명을 설정한다.
cluster.name = es_test

해당 명령프롬프트에서 elasticsearch 프로세스를 실행시키고 다른 cmd 창을 열어서 elasticsearch 프로세스를 다시 실행시키면 두 프로세스는 아까 지정한 클러스터 하에 바인딩된다.

하나의 서버에서 여러 개의 엘라스틱서치 노드가 실행될 때 노드 사이의 바인딩을 위한 통신 포트는 9300부터 차례대로 생성되고, REST API를 위한 http 통신 포트는 9200부터 차례대로 생성된다. 앞의 노드들은 데이터 통신을 위해 각각 9300, 9301 포트로 연결됐고, REST API 통신을 위해 9200, 9201 포트로 http 통신을 하도록 생성된다.

두 개의 노드는 서로 바인딩 돼 하나의 시스템을 이루고 있으므로 어떤 경로로도 입력하거나 조회할 수 있다.
예를 들어 9200 포트에서 통신을 받는 노드에 PUT으로 도큐먼트를 집어넣으면 9201포트에서 통신하는 노드에서 해당 도큐먼트를 조회할 수 있다.

만약 여기서 config/elasticsearch.yml 파일에 새 클러스터명을 설정한 후 새로 elasticsearch 프로세스를 실행시켜 노드를 새로 만들어내면 , 해당 노드는 위의 노드들과 같은 클러스터에 위치하고 있지 않고 따라서 서로 바인딩되어 있지 않다.

마스터 노드와 데이터 노드

엘라스틱서치에는 다음과 같은 종류의 노드가 있다.

• 마스터 노드
  전체 클러스터의 상태에 대한 메타 정보를 관리. 기존의 마스터노드가 종료되는 경우 새로운 마스터 노드가 선출된다.

• 데이터 노드
  색인된 데이터를 실제로 저장하는 노드

마스터노드와 데이터 노드가 반드시 상호 배타적인 관계는 아니다. 마스터 노드가 false 이면서 동시에 데이터 노드도 false 인 노드도 존재할 수 있다. 이러한 노드는 색인과 검색을 위한 명령과 결과를 전달하는 역할로만 존재한다.
엘라스틱서치 시스템을 구성할 때 보통 마스터 노드는 명령 수행을 전담하는 창구 기능을 하며
데이터 노드는 http 통신 기능을 막아 놓아 REST API 접근을 차단하고 데이터를 저장하는 역할만을 전담하도록 설정한다.

샤드와 복사본

샤드(Shard)는 아파치 루씬에서 사용되는 메커니즘으로 데이터 검색을 위해 구분되는 최소의 단위 인스턴스이다.
엘라스틱서치에 색인된 데이터는 여러 개의 샤드로 분할돼 저장되는데,
기본적으로 인덱스 당 5개의 샤드와 5개의 복사본으로 분리된다.
예를 들어 하나의 인덱스에 도큐먼트가 5개 있다면 각 도큐먼트는 하나씩 5개의 샤드로, 5개의 복사본으로 흩어져 서로 다른 노드에 저장된다.

처음 데이터가 색인돼 저장되는 공간을 최초 샤드라고 한다.
최초 샤드에 데이터가 색인되고 나면 다시 동일한 최소 샤드 수만큼 복사본을 생성한다.

복사본을 만드는 이유?

1. 데이터 손실을 방지하려는 목적.
   최초 샤드가 유실되는 경우 복사본을 최초 샤드로 승격시켜 시스템 무결성을 보장
2. 성능 향상
   최초 샤드와 복사본에 동시에 검색해서 더 빠르게 데이터 찾기 가능

기본적으로 같은 데이터 블록의 최초 샤드와 복사본은 서로 다른 노드에 저장됨 -> 데이터 무결성 보장

네트워크 바인딩과 디스커버리

하나의 서버가 가지는 CPU, 메모리, 디스크 등의 자원은 유한하므로 하나의 서버에서 계속 엘라스틱서치 노드를 증가시키는 것은 바람직하지 않다.
효율적인 스케일아웃을 위해 엘라스틱서치는 네트워크에 있는 다른 서버의 노드와도 바인딩할 수 있게 되어있다.

엘라스틱 서치는 하둡과 같은 빅데이터 분산 시스템과 달리 노드 사이의 데이터 통신을 위한 9300~ 대의 포트에 접근할 수 있게 열려있기만 하면 바로 네트워크에서도 바인딩할 수 있다.
네트워크에 바인딩할 수 있는 노드를 찾기 위해 엘라스틱서치는 디스커버리라는 기능을 제공한다.

젠 디스커버리

네트워크 바인딩을 위해 엘라스틱서치에서는 젠 디스커버리(Zen Discovery) 기능을 내장하고 있다.
멀티캐스트와 유니캐스트 방식이 있으며 기본적으로 멀티캐스트방식으로 활성화돼 있다.

멀티캐스트와 유니캐스트

• 멀티캐스트 : 접근할 수 있는 모든 네트워크의 노드를 자동으로 검색하고 같은 클러스터명을 가진 노드끼리 바로 바인딩하는 기능

멀티캐스트 방식은 참 단순하다. 그저 같은 네트워크에만 있다면 해당 서버의 config/elasticsearch.yml 파일에서 클러스터명을 바인딩할 노드들이 있는 클러스터명과 일치되도록 변경하기만 하면 된다.

같은 네트워크에서 클러스터명만 동일하게 유지하면 별다른 설정 없이 다른 서버에서 실행되고 있는 노드들이 젠 디스커버리를 통해 바인딩된다.
그러나 멀티캐스트는 의도하지 않는 노드 바인딩이 일어날 가능성이 있고 네트워킹의 불안정감 때문에 공식 엘라스틱서치 운영 그룹에서도 멀티캐스트보다는 유니캐스트의 사용을 권장한다.

• 유니캐스트: 접근할 네트워크 주소를 지정해서 지정한 노드 사이에만 바인딩

유니캐스트 방식의 바인딩은 바인딩 할 각 서버의 config/elasticsearch.yml 파일에서 아래와 같이 설정해야 한다.

discovery.zen.ping.multicast.enabled : false
discovery.zen.ping.unicast.hosts: ["각 서버 IP주소:바인딩포트넘버", "각 서버 IP주소:바인딩포트넘버"]

만약 각 서버의 바인딩 포트 넘버가 기본값인 9300으로 설정되어있다면 바인딩 포트 넘버는 생략할 수 있다.

아마존 EC2 디스커버리

AWS의 가상 서버인 EC2 인스턴스로 엘라스틱서치 시스템을 구성할 때는 젠 디스커버리 외에 아마존 EC2 디스커버리를 사용해서 편리하게 노드를 바인딩할 수 있다.

1. t1.micro EC2 인스턴스 2대 생성하기
2. 각 인스턴스에 접속해서 엘라스틱서치를 설치하기
🚩 설치 방법
putty 접속 후

wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-X.X.X.tar.gz

3. 엘라스틱서치 설치 경로로 가서 각 인스턴스에 elasticsearch-cloud-aws 플러그인 설치하기
깃허브에서 현재 설치된 엘라스틱서치와 호환되는 버전을 확인하고 설치한다.

bin/plugin -install elasticsearch/elasticsearch/elasticsearch-cloud-aws/X.X.X (위에서 확인한 버전)

4. aws의 access key와 secret key를 config/elasticsearch.yml 파일에 추가하기
각 인스턴스의 config/elasticsearch.yml 파일에서 아래와 같이 설정한다.

cluster.name : 동일한 클러스터명
cloud:	
	aws:
    	access_key: accesskey 내용
        secret_key: secretkey 내용
        region: ec2 region
 discovery:
 	type: ec2

5. 마지막으로 각 인스턴스의 보안그룹에서 9300 포트로 통신할 수 있게 포트를 열어준다.