소개
ES를 효과적으로 사용하려면 먼저 설계와 그 동작을 이해하는 것이 가자 중요하다. 1장에서 살펴볼 주요 개념은 노드, 색인, 샤드, 타입/매핑, 도큐먼트, 필드다. ES는 다음과 같은 여러 분야에 사용할 수 있다.
ES가 주로 사용되는 검색 엔진
ES의 강력한 집계 시스템을 바탕으로 하는 분석 프레임워크
로그를 주로 다루는 데이터 저장소 ES는 성능, 검색 품질을 향상시키고 확장성과 가용성을 향상 시키기 위한 인프라를 최적화할 시기와 방법을 결정하는데 도움을 준다.
노드와 클러스터 이해
모든 ES의 인스턴스는 노드이다. 여러 노드는 클러스터로 그룹을 짓는다. 이것이 ES의 클러스터 구성방법의 기초이다.
분석
RAM, CPU, 디스크 공간처럼 가용한 리소스에 따라 물리 서버나 가상 서버에 하나 또는 그 이상의 ES 노드를 설치할 수 있다. 기본 노드에 데이터를 저장하고 요청과 응답을 처리한다. 노드를 시작하는 동안 여러 절차를 수행하게 된다. 예를 들면 다음과 같다.
구성 정보를 환경 변수와 elasticsearch.yml 구성 파일에서 읽어온다.
노드 이름은 설정 파일에 설정하거나 그렇지 않다면 내장된 램덤 이름 목록에서 자동으로 선택한다.
내부적으로 ES 엔진은 현재 설치된 가용한 모든 모듈과 플러그인을 초기화한다.
노드 시작 후 노드는 다른 클러스터 맴버를 검색하고 색인과 샤드 상태를 점검한다. 클러스터에서 두개 혹은 그 이상의 노드를 결합하려면 다음 규칙을 만족해야 한다.
ES 버전이 동일해야 한다. 그렇지 않으면 거부된다.
클러스터 이름이 동일해야 한다. 네트워크는 브로드 캐스트 검색을 지원하게 구성해야 하는데 이를 통해 서로 통신 할 수 있다.
클러스터 관리에 있어서 일반적인 접근 방법은, 클러스터 수준의 액션이 주로 조회하는 하나 또는 그 이상의 마스터 노드를 두는 것이다. 마스터 노드의 상대 개념은 마스터 데이터와 행위를 복제하는 보조 노드다. 쓰기 작업은 일관성을 위해 모든 변경 행위를 마스터 노드에 먼저 커밋하고 이후 보조 노드에 복제한다. 다중 노드가 있는 클러스터에서 마스터 노드가 죽으면 마스터 자격을 소유할 수 있는 후보 노드중에 새로운 마스터를 선출한다. 이 접근 방법으로 failover를 자동으로 하도록 ES 클러스터를 설정할 수 있다.
보충 설명
일래스틱서치에는 다음과 같은 네 종류의 노드가 있다.
마스터 노드 REST응답과 검색에 관한 모든 작업을 처리할 수 있다. 매번 작업이 실행되는 동안 MapReduce 방식으로 작업을 실행한다. 비 데이터 노드는 기본 샤드에 작업을 분배하고 샤드의 결과를 수집/집계하는 역활을 담당한다. 최종적으로 응답을 클라이언트로 전송하게 된다. 이는 집계, 조회, 수집, 캐싱, 작업이 발생하여 많은 메모리를 필요로 하게 된다.
데이터 노드 데이터를 내부에 저장한다. 루씬 색인처럼 색인된 도큐먼트를 저장하는 색인 노드가 포함된다.
수집 노드 수집 파이프라인을 처리 할 수 있다. logstash의 일부 역활을 ES로 이전하였다.
클라이언트 노드 어떤 방식이든 무언가 처리하는데 사용한다. 메모리 부족이나 잘못된 쿼리 같은 문제가 발생하면 데이터 손실, 클러스터 안정성 저하 없이 강제로 종료 재시작이 가능하다.
표준 구성을 사용하면 노드는 마스터이며 데이터 컨테이너고 수집노드가 된다. 대규모 클러스터 아키텍처에서 일부 노드를 데이터가 없고 다량의 메모리를 가지니 단순 클라이언트 노드로 두면 데이터 노드가 요구하는 자원을 줄이면서 로컬 메모리 캐시로 사용할 수 있기 때문에 전체적인 검색 성능을 향상 시킬 수 있다.
노드 서비스 이해
노드가 실행 중일 때 인스턴스 자신은 많은 서비스를 관리한다. 서비스는 노드에 추가적인 기능을 제공하고, 네트워킹,색인, 분석 등과 같은 다양한 기능을 제공한다.
분석
ES는 기본적으로 추가 플러그인을 통해 많은 확장 기능을 제공한다. 노드가 시작하면서 다음과 같은 필수 서비스가 자동으로 시작한다. 실제로는 이보다도 더 많은 서비스가 시작된다.
클러스터 서비스 클러스터 상태를 관리하고 인트라 노드와 통신하며 동기화에 도움을 준다.
색인 서비스 모든 색인 작업, 모든 활성 색인과 샤드 초기화를 관리한다.
매핑 서비스 클러스터에 저장된 도큐먼트 타입을 관리하는 데 도움을 준다.
네트워크 서비스 HTTP REST(9200포트), 내부 ES 프로토콜(9300포트), 그리고 thrift 플러그인을 설치했다면 thrift와 같은 서비스가 있다.
플러그인 서비스 12장에서 추가로 설명한다.
집계 서비스 통계, 히스토그램, 도큐먼트 그룹화 처럼 ES 도큐먼트를 바탕으로 고급 분석을 제공한다.
Ingest 서비스 필드 enrichment, NLP 처리, 타입 변환, 자동 필드 채우기 같은 도큐먼트 전처리 기능을 제공한다.
언어 스크립팅 서비스 ES에 새로운 언어 스크립팅 지원을 추가 할 수 있다.
데이터 관리
ES를 검색 엔진이나 분산 데이터 저장소로 사용할 계획이라면 ES 데이터를 저장하고 관리하는 방법에 대한 개념적 이해가 필요하다.
분석
주요 데이터 컨테이너를 색인(index)라 부르는데 이는 전통적인 SQL의 데이터베이스와 비슷하다. 색인에서 데이터는 Mapping이라 부르는 데이터 타입으로 그룹화 된다. Mapping은 레코드 작성 방법을 기술한 것이다. ES에 저장해야 하는 모든 레코드는 JSON을 따라야 한다. ES는 기본적으로 스키마가 없는 데이터 저장소이다. 따라서 레코드를 입력하면 데코드를 처리하고 여러 필드로 나누며, 입력된 데이터 를 관리하는 스키마를 업데이트 하게된다. ES는 대량의 레코드를 관리하기 위해 색인을 여러 샤드로 분할 하여 여러 노드에 분산 저장한다. ES 어플리케이션 계층이 모든 일반 레코드 작업을 자동으로 관리하므로 샤드 관리는 사용자가 지정할 필요는 없다. 모든 레코드는 레코드 ID 기반의 샤딩 알고리즘으로 단일 샤드에 저장된다. 로딩 및 레코드/객체 변경에 필요한 대부분 작업은 전체 샤드를 조회하지 않아도 객체를 포함하는 단일 샤드에서 수행 가능하다. 다음은 ES와 SQL, MongoDB를 비교한 표다.
보충 설명
ES는 색인/매핑/객체 작업의 안정성을 보장하기 위해 내부적으로 작업을 실행하는 방법에 관한 엄격한 규칙을 갖고 있다.
클러스터/색인 작업 모든 쓰기 작업은 잠긴 상태이며, 먼저 마스터 노드에 반영하면 보조 노드에 반영된다. 읽기 작업은 모든 노드가 실행한다.
도큐먼트 작업 모든 쓰기 작업은 조회 샤드에서만 잠긴다. 읽기 작업은 모든 레플리카 샤드에 전달된다.
레코드를 ES에 저장할 때 다음에 의해 목적 샤드를 선택한다.
레코드의 고유 식별자 ID가 없다면 ES가 자동으로 생성한다.
라우팅이나 부모 파라미터를 지정했다면 이들 파라미터 해시 값으로 적합한 샤드를 선택한다. ES는 가용 가능한 모든 노드에 샤드를 균형적으로 분포시키려 노력하므로 샤드 색인을 분할 하여 여러 노드에 데이터를 저장한다. 모든 샤드는 232 레코드(약 49억건)까지 저장 할 수 있으므로 저장 공간은 결국 물리적인 저장 공간이 제약상이 된다. 샤드가 데이터를 갖고 있기 때문에 검색 과정에서 계산하고 결과를 조회할 때 샤드를 사용한다. 그래서 대규모 데이터에서 ES 성능은 샤드 개수에 따라 수평적으로 확장된다. 모든 네이티브 레코드 작업(CRUD)는 샤드가 관리한다. 사용자는 샤드가 투명하지만 고급 사용자들은 사용자 지정 시나리오를 위하여 기본 샤드 라우팅을 변경하고 관리하려 한다. 보통은 검색/색인/분석 작업의 성능을 높이기 위하여 고객 데이터를 동일한 샤드에 입력하려는 등의 요구 사항이 존재 하는 경우가 발생한다.
모범사례
색인 세그먼트를 지속적으로 병합하고 크기를 조정하는 색인 작업으로 인한 성능 저하를 피하기 위해서 샤드의 크기는 아주 크지는 않아야 한다. 보통 10GBytes를 넘지 말아야 한다. 루씬 색인 작업이 진행되는 동안 ES는 쓰기 적업 성능을 높이기 위하여 색인된 도큐먼트를 블록 단위로 작성한다. 시간이 지나 작은 세그먼트들을 모아 새로운 fragment에 쓰고 삭제한다. 많은 데이터를 가진 큰 샤드로 인해 단편화가 발생하면 색인 성능이 크게 감소하게 된다. ES는 분산 검색이기 때문에 MapReduce로 동작하므로 검색 성능의 저하를 피하기 위해서 샤드 개수를 지나치게 많이 할당하는 것도 좋지 않다. 샤드는 색인/검색 작업을 하는 워커로 구성되고, 마스터/클라이언트 노드는 Redux역활을 한다. 빈 샤드가 많은 색인은 메모리를 소모하고 네트워크와 결과 집계 단계의 오버헤드로 인해 검색 시간만 증가 시키게 된다.
클러스터, 복제, 샤딩의 이해
샤드 관리와 관련해서 복제와 클러스터 상태의 주요 개념이 있다.
분석
색인은 한 개 이상의 레플리카를 가진다. 쓰기 작업의 일관성을 유지하기 위하여 다음의 절차로 복제가 일어난다.
쓰기 작업은 주 샤드에서 먼저 실행한다.
주 샤드에 쓰기가 성공하면 모든 보조 샤드로 쓰기가 동시에 전파된다.
주 샤드를 사용할 수 없게 되면 보조 샤드중 기본 샤드가 선출되고 위의 절차가 다시 실행된다.
검색 작업에서는 성능 향상을 위하여 모든 샤드중 무작위로 유효한 샤드 집합으로 선택한다. ES는 샤드에 노드를 더 잘 분산하는 다양한 할당 알고리즘을 제공하고 있다. 레플리카는 데이터 노드의 동기화 때문에 색인 시간의 증가와 보조 샤드에 메시지 전파로 인하여 성능 저하를 가져오지만 시뢰성을 높이는 역활과 검색시 속도 향상을 제공한다.
모범 사례
데이터 손실을 막고 HA를 위해 최소한 한 개의 레플리카를 가져야 한다. 시스템은 노드 실패에도 downtime과 데이터 손실 없이 동작 할 수 있게 된다. 검색에서 확장 가능한 성능을 위해 곡객 수에 따라 레플리카의 수를 늘리는 방법도 고려할 수 있다.
보충 설명
클러스터는 3가지 상태를 가지게 된다.
그린(Green) 모든것이 정상인 상태이다.
옐로(Yellow) 일부 샤드가 누락됐으나 색인 및 검색은 정상이다.
레드(Red) 색인이 불가능하며 누락된 샤드 때문에 모든 작업이 실패한다. 누락된 샤드를 다시 연결하지 않는다면 데이터 손실이 발생한다.
옐로 상태 해결법
할당되지 않은 샤드가 클러스터에 존재하면 옐로 상태가 된다. 클러스터가 복구상태에 있다면 샤드 시작 절차가 마칠 때까지 기다리면 된다. 혹은 레플리카 개수를 줄이도록 한다. 하지만 최소 1개의 레플리카를 유지해야 HA가 가능한 점을 잊지 말도록 한다.
레드 상태 해결법
데이터를 백업, 스냅샷으로 복구한다.
ES와 통신
ES는 HTTP와 네이티브 프로토콜 두가지 방법을 제공한다.
분석
ES는 RESTful 서버처럼 동작하게 설계 되어 있다. 모든 프로토콜에는 다음과 같은 장단점이 존재한다.
HTTP 프로토콜
분석
모든 클라이언트는 서버 색인으로 연결을 만들고 응답을 가져온다. 응답의 대부분은 JSON이다. 선호하는 어떤 프로그래밍 언어로든 ES기능을 호출 할 수 있다. 다음의 장점을 가진다.
이식성 웹 표준을 사용하므로 모든 개발 언어를 지원한다고 봐도 된다.
내구성 REST API의 변경은 적다. 네이티브와 차이점이다.
쉬운 사용 JSON 으로 호출하고 응답한다.
다른 프로토콜 보다 많은 지원 ES의 플러그인은 일반적으로 HTTP REST 엔드포인트를 제공한다.
클러스터 확장 클러스터 노드를 단순히 HTTP 로드 밸런서 뒤에 두기만 하면 HAProxy나 NGINX등의 요청 밸런스 기능을 사용할 수 있다.
보충설명
ES 커뮤니티는 사용자가 많은 개발언어에 대해 클라이언트 SDK를 제공하고 있다.
네이티브 프로토콜
분석
네이티브 클라이언트를 초기화 하기 위해 이를 적절히 구성하는 설정이 필요하다.
cluster.name 클러스터의 이름이다.
client.transprot.sniff 나머지 클러스터 토폴리지를 스니핑해서 발견한 노드를 사용하는 머신의 클라이언트 목록으로 추가한다.
위 설정을 사용하여 새 클라이언트를 초기화 할 수 있다.
보충 설명
ES 내부 프로토콜이다. ES와 통신하는 가장 빠른 프로토콜이다. 네이티브 프로토콜은 최적화된 바이너리 프로토콜이며 JVM 언어에서만 동작한다. elasticsearch.jar를 포함한 구현으로 응용 프로그램을 만들 수 있다. 이 프로토콜은 HTTP와 달리 ES의 내부 구조를 알아야 사용 가능하므로 난이도가 매우 높다. 네이티브 프로토콜은 대규모 데이터를 입력하는데 매우 유용하지만 플러그인등의 엔드 포인트가 제공되지 않아서 특정 기능을 이용 불가능 하다.
참고 사항
네이티브 프로토콜은 자바 세계에서 가장 많이 사용된다. 14장, 15장, 17장에서 해당 내용을 다룬다.
Last updated