Ch7. 일래스틱 서치 클러스
터 세부사항
아꿈사 스터디
2015.09.12
정민철
노드탐색
● 탐색
○ 노드 시작
○ 클러스터 이름이 동일한 마스터 노드 탐색
○ 찾으면 => 클러스터에 합류
○ 못찾으면 => 마스터로 선택됨
● 탐색 타입
○ Zen 탐색모듈 사용
○ 멀티캐스트
■ 멀티캐스트 메세지에 응답하는 모든 노드 탐색
■ 사용하기 손쉽지만 네트워크가 멀티캐스트 지원해야 함
○ 유니캐스트
■ 호스트 명시적 제시, 각 호스트에 접속 시도
■ 보안이 장점, 여러 클러스터 운영 시 사용
● 마스터 노드
○ 주요 기능
■ 모든 노드가 응답하는지 점검
■ 새로운 노드 추가
○ 마스터 연결이 끊어지면 남은 노드 중 새로운 마스터 노드 선출
○ 마스터 노드 / 자료노드 둘 중 하나로만 동작 가능
■ node.master : true / false (true)
■ node.data : false / true (true)
○ 분할 뇌(split-brain): 네트워크 문제로 떨어진 노드들이 각각 마스터를 선출하는 상황
○ discovery.zen.minimum_master_nodes
■ 마스터를 선출하기 위해 연결되어야 하는 최소 노드 갯수 설정
■ 연결된 노드가 이 숫자 이하일 경우 대기
● 클러스터 이름 설정
○ cluster.name 이 동일한 노드끼리 묶임
○ 기본값에서 변경하는 것을 권장 (기본값: elasticsearch)
● 멀티캐스트 구성
○ discovery.zen.ping.multicast.group: 멀티캐스트 그룹 주소(224.2.2.4)
○ discovery.zen.ping.multicast.port: 멀티캐스트 포트(54328)
○ discovery.zen.ping.multicast.ttl: 멀티캐스트 요청 유효시간(3s)
○ discovery.zen.ping.multicast.address: 바인드할 주소(null - 머신의 모든 네트워크 주소)
● 유니캐스트 구성
○ discovery.zen.ping.unicast.hosts: 유니캐스트를 시도할 호스트 IP 목록
● 노드를 위한 핑 설정
○ 핑: 노드가 동작하고 응답하는지 점검하기 위한 시그널
○ 마스터노드: 모든 노드에 핑을 날림
○ 다른 노드: 마스터 노드에 핑을 날림
○ discovery.zen.fd.ping_interval: 핑을 날리는 주기(1s)
○ discovery.zen.fd.ping_timeout: 응답하지 않는다고 판단하기 위한 시간(30s)
○ discovery.zen.fd.ping_retries: 응답하지 않는다고 판단하기 전 재시도 횟수(3회)
게이트웨이와 복구 모듈
● 게이트웨이 모듈: 클러스터 자료와 메타데이터를 영속적으로 저장
● 클러스터 복구 과정에서 게이트웨이 모듈로 부터 정보를 읽어옴
● gateway.type: 게이트웨이 타입 설정(local - 로컬 디스크에 저장)
● 복구제어
○ 복구: 모든 샤드와 레플리카를 초기화하는 과정. 트랜잭션 로그에서 모든 자료를 읽어 샤드에
적용
○ gateway.expected_nodes: 구성된 노드 수를 알려줌. 여기에 지정된 숫자만큼의 노드가 연결
되면 복구프로세스 시작
○ gateway.recover_after_nodes: 복구 프로세스를 시작할 노드 갯수
○ gateway.recover_after_time: recover_after_nodes 만큼의 노드가 모여 복구 프로세스를 시작
할 딜레이
○
● 추가 게이트웨이 복구 옵션
○ gateway.recover_after_master_nodes: 복구 시작 전 마스터 가능 노드가 얼마나 존재해야 하
는지 명세
○ gateway.recover_after_data_nodes: 자료 노드가 얼마나 존재해야 하는지를 명세
○ gateway.expected_master_nodes:
○ gateway.expected_data_nodes
질의와 색인의 고가용성을 위한 일래스틱서치 클러스
터 준비
● 필터캐시
○ 정보를 빠르게 인출할 수 있도록 질의에서 사용된 필터를 캐싱함
○ 노드필터 캐시: 단일 노드에 할당된 모든 색인을 대상으로 공유, 특정 비율이나 특정 양을 사
용하게 구성(indices.cache.filter.size)
○ 색인필터 캐시: 자세한 설명은 생략한다. (크기 예측이 어려워 일반적으로 노드필터 캐시 사
용)
● 필드 자료 캐시와 회로 차단기
○ 필드자료캐시 : 특정 필드에 대해 정렬이나 패싯 작업을 수행할 때 빠른 접근을 위해 메모리에
올리는 자료구조, 캐싱은 비싼 연산이므로 충분한 메모리 확보 필요
○ indices.fielddata.cache.size: 필드자료캐시에 할당된 메모리양 설정, 노드별 프로퍼티
○ 필드자료캐시의 크기에는 한계가 없으므로 메모리를 초과하지않게 주의해야 함
○ indices.fielddata.cache.expire: 캐시 만료시간 (일반적으로 설정해서는 안됨)
● 회로차단기
○ 필드가 소모하는 메모리를 추정하여 많은 메모리를 소모하는 필드를 메모리에 올리지 않도록
막는 역할
○ indices.fielddata.breaker.limit : 메모리에 올라올 자료가 할당된 값을 초과할 경우 예외처리
(80%)
○ indices.fielddata.breaker.overhead : 추정한 값에 보정을 위해 곱해야할 상수값 (1.03)
● 저장소
○ 색인 자료를 기록하는 방법 제어
○ index.store.type : 저장소 타입 명세
■ simplefs: 디스크 기반 임의접근 파일 사용
■ niofs: 자바 NIO 클래스를 사용하는 디스크기반 색인 저장소, 병렬환경에서 좋은 성능
■ mmapfs: 메모리에 색인 파일을 매핑하는 디스크기반 저장소, 색인을 효율적으로 읽음
(64-bit system 기본 저장소)
■ memory: 메모리에 저장, 충분한 메모리가 없을 경우 동작하지 않음
● 색인 버퍼와 새로고침 주기
○ indices.memory.index_buffer_size: 색인에 소비가능한 메모리 총량 설정
○ indices.memory_min_shard_index_buffer_size: 샤드별 최소 색인버퍼값
○ index.refrash_interval(1s)
■ 색인 검색기를 얼마나 자주 새로고침하는지 설정
■ 짧을수록 다쿠먼트가 검색결과에 빨리 등장
■ 대량 색인의 경우 -1 설정 권장
● 스레드 풀 구성
○ 스레드 처리 방법과 사용자 요청에 대한 메모리 소비량을 제어하기 위해 여러 스레드풀 사용
○ 종류: cache, fixed, index, search, suggest, get, bulk, percolate
○ 설정 예시
■ threadpool.index.type: fixed
■ threadpool.index.size: 100
■ threadpool.index.queue_size: 500
몇 가지 일반적인 조언
● JVM 프로세스 메모리
○ 가용 메모리의 50~60% 이상을 할당하지 않는다
○ OS 및 OS의 I/O cache에 충분한 메모리를 남겨둬야 함
○ 힙크기 재조정을 피하기 위해 Xmx와 Xms를 동일하게 설정
● 올바른 저장소 선택
○ mmap(64-bit), niofs(unix), simplefs(windows), memory(speed)
● 색인 새로 고침 주기: 질의속도 v.s. 색인처리량
● 스레드 풀 조율: 클러스터가 질의에 압도당하는 시점으로설정
● 병합과정 조율
○ 질의속도 v.s. 색인속도
○ 너무 자주 병합이 일어나지 않게
○ 너무 많이 세그먼트 분할이 일어나지 않게
● 필드 자료 캐시와 회로 차단: 메모리가 부족해지지 않게
● 색인을 위한 RAM 버퍼
● 트랜잭션 로깅 조율
● 조율은 1회성이 아닌 상황이 변함에 따라 지속적으로 해야 함
템플릿과 동적 템플릿
● 색인 템플릿
○ 색인 구성과 매핑을 패턴과 일치하는 모든 색인을 위해 사용 할 수 있게 지정하는 기능
○ 색인에 적용 가능한 동적 매핑
● 예제 1
○ curl -XPUT http://localhost:9200/_template/main_template -d ‘{
“template”: “*”,
“order”: 1,
“settings”: { “index.number_of_replicas”: 0 },
“mappings”: { “_default_”: { “_source”: { “enabled”: false } } }
}’
○ 모든 색인에 적용, 레플리카가 없음, 원본 저장하지 않음,
○ _default: 모든 다큐먼트 타입에 일치시킴
○ order: order이 낮은 템플릿부터 적용됨, 뒤에 적용되는 템플릿이 설정을 덮어씀
● 예제 2
○ curl -XPUT http://localhost:9200/_template/ha_template -d ‘{
“template”: “ha_*”,
“order”: 10,
“settings”: { “index.number_of_replicas”: 5 },
}’
○ ha_로 시작하는 색인에 적용, 레플리카를 5개로 지정
● 파일에 템플릿 저장
○ config/template 폴더 아래에 저장
○ 내용: { “ha_template”: {
“template”: “ha_*”,
“order”: 10,
“settings”: { “index.number_of_replicas”: 5 }
● 동적 템플릿
○ 필드 이름과 타입에 의존적인 타입을 정의할 때 사용
○ 필드 이름과 패턴이 일치하면 해당되는 템플릿 사용
○ 예제
PUT /my_index
{ "mappings": {
"my_type": {
"dynamic_templates": [
{ "es": { "match": "*_es", "match_mapping_type": "string",
"mapping": { "type": "string", "analyzer": "spanish" } }},
{ "en": { "match": "*", "match_mapping_type": "string",
"mapping": { "type": "string", "analyzer": "english" } }}
] }}}

일래스틱 서치 ch7. 일래스틱 서치 클러스터 세부사항

  • 1.
    Ch7. 일래스틱 서치클러스 터 세부사항 아꿈사 스터디 2015.09.12 정민철
  • 2.
    노드탐색 ● 탐색 ○ 노드시작 ○ 클러스터 이름이 동일한 마스터 노드 탐색 ○ 찾으면 => 클러스터에 합류 ○ 못찾으면 => 마스터로 선택됨 ● 탐색 타입 ○ Zen 탐색모듈 사용 ○ 멀티캐스트 ■ 멀티캐스트 메세지에 응답하는 모든 노드 탐색 ■ 사용하기 손쉽지만 네트워크가 멀티캐스트 지원해야 함 ○ 유니캐스트 ■ 호스트 명시적 제시, 각 호스트에 접속 시도 ■ 보안이 장점, 여러 클러스터 운영 시 사용
  • 3.
    ● 마스터 노드 ○주요 기능 ■ 모든 노드가 응답하는지 점검 ■ 새로운 노드 추가 ○ 마스터 연결이 끊어지면 남은 노드 중 새로운 마스터 노드 선출 ○ 마스터 노드 / 자료노드 둘 중 하나로만 동작 가능 ■ node.master : true / false (true) ■ node.data : false / true (true) ○ 분할 뇌(split-brain): 네트워크 문제로 떨어진 노드들이 각각 마스터를 선출하는 상황 ○ discovery.zen.minimum_master_nodes ■ 마스터를 선출하기 위해 연결되어야 하는 최소 노드 갯수 설정 ■ 연결된 노드가 이 숫자 이하일 경우 대기
  • 4.
    ● 클러스터 이름설정 ○ cluster.name 이 동일한 노드끼리 묶임 ○ 기본값에서 변경하는 것을 권장 (기본값: elasticsearch) ● 멀티캐스트 구성 ○ discovery.zen.ping.multicast.group: 멀티캐스트 그룹 주소(224.2.2.4) ○ discovery.zen.ping.multicast.port: 멀티캐스트 포트(54328) ○ discovery.zen.ping.multicast.ttl: 멀티캐스트 요청 유효시간(3s) ○ discovery.zen.ping.multicast.address: 바인드할 주소(null - 머신의 모든 네트워크 주소) ● 유니캐스트 구성 ○ discovery.zen.ping.unicast.hosts: 유니캐스트를 시도할 호스트 IP 목록
  • 5.
    ● 노드를 위한핑 설정 ○ 핑: 노드가 동작하고 응답하는지 점검하기 위한 시그널 ○ 마스터노드: 모든 노드에 핑을 날림 ○ 다른 노드: 마스터 노드에 핑을 날림 ○ discovery.zen.fd.ping_interval: 핑을 날리는 주기(1s) ○ discovery.zen.fd.ping_timeout: 응답하지 않는다고 판단하기 위한 시간(30s) ○ discovery.zen.fd.ping_retries: 응답하지 않는다고 판단하기 전 재시도 횟수(3회)
  • 6.
    게이트웨이와 복구 모듈 ●게이트웨이 모듈: 클러스터 자료와 메타데이터를 영속적으로 저장 ● 클러스터 복구 과정에서 게이트웨이 모듈로 부터 정보를 읽어옴 ● gateway.type: 게이트웨이 타입 설정(local - 로컬 디스크에 저장) ● 복구제어 ○ 복구: 모든 샤드와 레플리카를 초기화하는 과정. 트랜잭션 로그에서 모든 자료를 읽어 샤드에 적용 ○ gateway.expected_nodes: 구성된 노드 수를 알려줌. 여기에 지정된 숫자만큼의 노드가 연결 되면 복구프로세스 시작 ○ gateway.recover_after_nodes: 복구 프로세스를 시작할 노드 갯수 ○ gateway.recover_after_time: recover_after_nodes 만큼의 노드가 모여 복구 프로세스를 시작 할 딜레이 ○
  • 7.
    ● 추가 게이트웨이복구 옵션 ○ gateway.recover_after_master_nodes: 복구 시작 전 마스터 가능 노드가 얼마나 존재해야 하 는지 명세 ○ gateway.recover_after_data_nodes: 자료 노드가 얼마나 존재해야 하는지를 명세 ○ gateway.expected_master_nodes: ○ gateway.expected_data_nodes
  • 8.
    질의와 색인의 고가용성을위한 일래스틱서치 클러스 터 준비 ● 필터캐시 ○ 정보를 빠르게 인출할 수 있도록 질의에서 사용된 필터를 캐싱함 ○ 노드필터 캐시: 단일 노드에 할당된 모든 색인을 대상으로 공유, 특정 비율이나 특정 양을 사 용하게 구성(indices.cache.filter.size) ○ 색인필터 캐시: 자세한 설명은 생략한다. (크기 예측이 어려워 일반적으로 노드필터 캐시 사 용) ● 필드 자료 캐시와 회로 차단기 ○ 필드자료캐시 : 특정 필드에 대해 정렬이나 패싯 작업을 수행할 때 빠른 접근을 위해 메모리에 올리는 자료구조, 캐싱은 비싼 연산이므로 충분한 메모리 확보 필요 ○ indices.fielddata.cache.size: 필드자료캐시에 할당된 메모리양 설정, 노드별 프로퍼티 ○ 필드자료캐시의 크기에는 한계가 없으므로 메모리를 초과하지않게 주의해야 함 ○ indices.fielddata.cache.expire: 캐시 만료시간 (일반적으로 설정해서는 안됨)
  • 9.
    ● 회로차단기 ○ 필드가소모하는 메모리를 추정하여 많은 메모리를 소모하는 필드를 메모리에 올리지 않도록 막는 역할 ○ indices.fielddata.breaker.limit : 메모리에 올라올 자료가 할당된 값을 초과할 경우 예외처리 (80%) ○ indices.fielddata.breaker.overhead : 추정한 값에 보정을 위해 곱해야할 상수값 (1.03) ● 저장소 ○ 색인 자료를 기록하는 방법 제어 ○ index.store.type : 저장소 타입 명세 ■ simplefs: 디스크 기반 임의접근 파일 사용 ■ niofs: 자바 NIO 클래스를 사용하는 디스크기반 색인 저장소, 병렬환경에서 좋은 성능 ■ mmapfs: 메모리에 색인 파일을 매핑하는 디스크기반 저장소, 색인을 효율적으로 읽음 (64-bit system 기본 저장소) ■ memory: 메모리에 저장, 충분한 메모리가 없을 경우 동작하지 않음
  • 10.
    ● 색인 버퍼와새로고침 주기 ○ indices.memory.index_buffer_size: 색인에 소비가능한 메모리 총량 설정 ○ indices.memory_min_shard_index_buffer_size: 샤드별 최소 색인버퍼값 ○ index.refrash_interval(1s) ■ 색인 검색기를 얼마나 자주 새로고침하는지 설정 ■ 짧을수록 다쿠먼트가 검색결과에 빨리 등장 ■ 대량 색인의 경우 -1 설정 권장 ● 스레드 풀 구성 ○ 스레드 처리 방법과 사용자 요청에 대한 메모리 소비량을 제어하기 위해 여러 스레드풀 사용 ○ 종류: cache, fixed, index, search, suggest, get, bulk, percolate ○ 설정 예시 ■ threadpool.index.type: fixed ■ threadpool.index.size: 100 ■ threadpool.index.queue_size: 500
  • 11.
    몇 가지 일반적인조언 ● JVM 프로세스 메모리 ○ 가용 메모리의 50~60% 이상을 할당하지 않는다 ○ OS 및 OS의 I/O cache에 충분한 메모리를 남겨둬야 함 ○ 힙크기 재조정을 피하기 위해 Xmx와 Xms를 동일하게 설정 ● 올바른 저장소 선택 ○ mmap(64-bit), niofs(unix), simplefs(windows), memory(speed) ● 색인 새로 고침 주기: 질의속도 v.s. 색인처리량 ● 스레드 풀 조율: 클러스터가 질의에 압도당하는 시점으로설정 ● 병합과정 조율 ○ 질의속도 v.s. 색인속도 ○ 너무 자주 병합이 일어나지 않게 ○ 너무 많이 세그먼트 분할이 일어나지 않게
  • 12.
    ● 필드 자료캐시와 회로 차단: 메모리가 부족해지지 않게 ● 색인을 위한 RAM 버퍼 ● 트랜잭션 로깅 조율 ● 조율은 1회성이 아닌 상황이 변함에 따라 지속적으로 해야 함
  • 13.
    템플릿과 동적 템플릿 ●색인 템플릿 ○ 색인 구성과 매핑을 패턴과 일치하는 모든 색인을 위해 사용 할 수 있게 지정하는 기능 ○ 색인에 적용 가능한 동적 매핑 ● 예제 1 ○ curl -XPUT http://localhost:9200/_template/main_template -d ‘{ “template”: “*”, “order”: 1, “settings”: { “index.number_of_replicas”: 0 }, “mappings”: { “_default_”: { “_source”: { “enabled”: false } } } }’ ○ 모든 색인에 적용, 레플리카가 없음, 원본 저장하지 않음, ○ _default: 모든 다큐먼트 타입에 일치시킴 ○ order: order이 낮은 템플릿부터 적용됨, 뒤에 적용되는 템플릿이 설정을 덮어씀
  • 14.
    ● 예제 2 ○curl -XPUT http://localhost:9200/_template/ha_template -d ‘{ “template”: “ha_*”, “order”: 10, “settings”: { “index.number_of_replicas”: 5 }, }’ ○ ha_로 시작하는 색인에 적용, 레플리카를 5개로 지정 ● 파일에 템플릿 저장 ○ config/template 폴더 아래에 저장 ○ 내용: { “ha_template”: { “template”: “ha_*”, “order”: 10, “settings”: { “index.number_of_replicas”: 5 }
  • 15.
    ● 동적 템플릿 ○필드 이름과 타입에 의존적인 타입을 정의할 때 사용 ○ 필드 이름과 패턴이 일치하면 해당되는 템플릿 사용 ○ 예제 PUT /my_index { "mappings": { "my_type": { "dynamic_templates": [ { "es": { "match": "*_es", "match_mapping_type": "string", "mapping": { "type": "string", "analyzer": "spanish" } }}, { "en": { "match": "*", "match_mapping_type": "string", "mapping": { "type": "string", "analyzer": "english" } }} ] }}}