[Elasticsearch] Elasticsearch 구성할 때 유의할 점

Elasticsearch 주요 구성 요소 설정

• Elasticsearch를 시작하기 위해서 별도로 추가 구성이 거의 필요하지 않지만 상용 환경에서 Elasticsearch를 시작하기 전에 고려해야 될 또는 한 번 더 확인해야 될 설정들이 있음

 

1. Path Settings

• Elasticsearch가 데이터, 로그, 임시 파일 등을 저장할 경로를 설정하는 구성 요소
• 권한 설정을 통해 elasticsearch user가 접근 가능하도록 설정해야 함

 

1.1 path.data

• 데이터 노드가 데이터 파일을 저장하는 경로
• default 값은 Elasticsearch 홈 디렉토리의 data 하위 디렉토리
• Elasticsearch를 업그레이드하면 삭제가 될 수 있으므로 상용 환경에서는 홈 디렉토리 외 다른 경로를 설정하는 것을 권장
  • 볼륨 마운트 등을 통해 데이터를 지킬 수 있음
  • 데이터 디렉토리를 직접 수정할 경우 클러스터에 문제가 발생할 수 있으므로 직접 수정 X

 

1.2 path.logs

• Elasticsearch 로그 파일을 저장하는 경로
• Elasticsearch 홈 디렉토리의 logs 하위 디렉토리
• 마찬가지로 상용 환경에서는 홈 디렉토리 외 다른 경로를 설정하는 것을 권장

 

2. Network Host Settings

• Elasticsearch 클러스터의 노드가 통신을 위해 사용할 네트워크 인터페이스와 포트를 설정하는 구성 요소
• 해당 설정은 클러스터의 안정성과 보안에 중요한 영향을 미침

 

2.1 network.host

• 기본적으로 아무 값도 설정하지 않으면 127.0.0.1과 같은 푸르백 주소에 바인딩되며 개발 모드로 실행
• 특정 주소를 할당하면 운영 모드로 실행

 

2.2 network.bind_host

• Elasticsearch가 요청을 수신할 때 바인딩할 네트워크 인터페이스를 설정
• network.host의 구체적인 형태
• 별도 설정 없을 경우 network.host 값을 사용

 

2.3 network.publish_host

• Elasticsearch 클러스터 내 다른 노드에 자신을 알릴 때 사용할 주소를 설정
• 클러스터 내 통신을 위한 주소
• 별도 설정 없을 경우 network.host 값을 사용

 

3. Discovery Settings

• 클러스터의 노드들이 서로를 발견하고 통신할 수 있도록 설정하는 중요한 구성 요소
• 해당 설정을 통해 클러스터의 노드가 서로를 인식하고 조정할 수 있음

 

3.1 discovery.seed_hosts

• 초기 클러스터 형성을 위해 사용될 노드들의 호스트 이름 또는 IP 주소를 지정
• 새로운 노드가 클러스터에 합류할 때 참조할 초기 노드 목록

 

3.2 file-based seed host provider

• 클러스터의 노드들이 서로를 발견할 수 있도록 초기 호스트 목록을 파일 기반으로 설정하는 방법
• 클러스터 노드가 동적으로 추가되거나 제거될 수 있는 환경에서 유용하게 사용 (파일 내용이 변경될 때마다 동적으로 업데이트)
• 일 기반 시드 호스트 설정을 통해 Elasticsearch가 시작될 때 참고할 수 있는 호스트 목록을 지정할 수 있음

 

파일 예시

 

192.168.1.100
192.168.1.101
192.168.1.102

 

3.3 cluster.initial_master_nodes

• 초기 클러스터 형성 시 마스터 노드로 선택될 후보 노드들의 목록 (node.name으로 설정)
• 클러스터가 처음 시작될 때 초기 마스터 노드를 선택하는 데 사용
• 클러스터 구성 후에는 각 노드의 설정에서 해당 옵션을 제거해야 함
  • 재기동할 때 해당 설정 때문에 클러스터에 문제가 발생할 수 있음

 

3.4 elasticsearch.yml 설정 예시

 

discovery.seed_hosts: ["192.168.1.100", "192.168.1.101", "192.168.1.102"]
discovery.seed_providers: <파일 경로>

cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]

 

클러스터 샤드 할당 설정

• 노드에 샤드를 할당하는 일련의 과정
• 마스터 노드가 어떤 샤드를 어떤 노드에 할당할지 결정

 

1. 클러스터 레벨 샤드 할당 설정

• Elasticsearch의 클러스터 레벨 샤드 할당 설정은 클러스터 내에서 인덱스의 샤드가 어떻게 분배되고 재배치될지 결정하는 중요한 설정
• 이를 통해 샤드의 고가용성, 성능 최적화, 장애 복구 등을 관리할 수 있음

 

1.1 cluster.routing.allocation.enable

• 클러스터 내 샤드 할당을 전역적으로 활성화하거나 비활성화
  • all: 기본값. 모든 샤드 할당을 허용
  • primaries: 기본 샤드(프라이머리 샤드)의 할당만 허용
  • new_primaries: 새로운 인덱스 생성 시에만 기본 샤드 할당을 허용
  • none: 모든 샤드 할당을 비활성화

 

2. 클러스터 레벨 샤드 리밸런싱 설정

• 샤드의 리밸런싱을 어떻게 허용하고 제어할지를 결정
• 블루-그린 배포(blue-green deployment) 전략에서 사용할 수 있는 설정

 

2.1 cluster.routing.allocation.allow_rebalance

• 클러스터 내에서 샤드의 리밸런싱을 언제 허용할지를 결정
• 샤드 리밸런싱은 기존 샤드가 클러스터 내 다른 노드로 이동하는 작업을 의미
• 클러스터의 균형을 유지하고 성능을 최적화하는 데 필수적
  • always: 항상 재조정을 허용
  • indices_primaries_active: 모든 인덱스의 프라이머리 샤드가 활성 상태일 때만 재조정을 허용
  • indices_all_active: 디폴트 값으로 모든 인덱스의 모든 샤드가 활성 상태일 때만 재조정을 허용

 

2.2 cluster.routing.rebalance.enable

• 클러스 내에서 어떤 샤드가 리밸런싱 될 수 있는지에 대한 제어를 제공
• 특정 조건에서 샤드 리밸런싱을 활성화하거나 비활성화할 수 있음
  • all: 모든 종류의 샤드 재조정을 허용
  • primaries: 프라이머리 샤드의 재조정만 허용
  • replicas: 레플리카 샤드의 재조정만 허용
  • none: 샤드 재조정을 비활성화

 

3. 디스크 기반 샤드 할당 설정

• 클러스터 내 각 노드의 디스크 사용량에 따라 샤드 할당을 제어하는 중요한 설정
• 해당 설정은 디스크 공간이 부족한 노드에 더 이상 샤드를 할당하지 않도록 하여 클러스터의 안정성을 유지하고, 노드의 과부하를 방지함

 

3.1 cluster.routing.allocation.disk.watermark.low

• 노드의 디스크 사용량이 임계값을 초과할 경우, 새로운 샤드의 할당을 방지
• 디스크 사용률의 백분율 또는 절대적인 바이트 수로 설정 가능하며 기본값은 85%

 

3.2 cluster.routing.allocation.disk.watermark.high

• 노드의 디스크 사용량이 임계값을 초과할 경우, 이미 할당된 샤드가 재배치됨
• 디스크 사용률의 백분율 또는 절대적인 바이트 수로 설정 가능하며 기본값은 90%

 

3.3 cluster.routing.allocation.disk.watermark.flood_stage

• 노드의 디스크 사용량이 임계값을 초과할 경우, 해당 노드에 있는 인덱스는 읽기 전용으로 설정
• 디스크 사용률의 백분율 또는 절대적인 바이트 수로 설정 가능하며 기본값은 95%

 

4. 샤드 할당 awareness 설정

• 클러스터 내에서 샤드를 특정 속성에 따라 균형 있게 분배하기 위한 기능
• 특히 데이터 센터, 랙, 가용 영역 등 물리적 위치나 환경에 따라 샤드를 분산시켜 클러스터의 안정성과 고가용성을 확보하는 데 유용

 

4.1 cluster.routing.allocation.awareness.attributes

• 샤드 할당 시 고려할 속성(attribute)을 지정하며 지정된 속성에 따라 샤드를 분산

 

4.2 cluster.routing.allocation.awareness.force.<attributes>.values

• 특정 속성(attribute)에 대한 값을 명시적으로 지정하여 샤드 할당을 강제
• 지정된 값 중 하나라도 사용되지 않으면 샤드 할당 실패

 

4.3 cluster.routing.allocation.awareness.attributes 실습

 

4.3.1 초기 설정

• es01, es02, es03 모두 cluster.routing.allocation.awareness.attributes=country
• es01은 node.attr.country=Korea, es02는 node.attr.country=Japan
• es03은 node.attr.country가 설정되어 있지 않은 상태
  • GET _cat/nodeattrs?v&s=attr&pretty API를 통해 es01, es02만 할당된 것을 확인 가능
  • GET _cat/shards?v API를 통해 샤드 또한 es01, es02만 할당된 것을 확인 가능

 

 

4.3.2 새로운 인덱스 추가

 

test-index-1 추가

 

 

test-index-2 추가

 

 

 

부연 설명

• 같은 샤드는 같은 노드에 존재할 수 없음
• es03번 노드가 존재하는데도 불구하고 awareness 설정을 es01, es02에만 적용했기 때문에 세 번째 샤드는 UNASSIGNED 상태인 것을 확인 가능

 

 

4.3.3 UNASSIGNED 샤드를 복구하고 싶다면?

• es03에도 node.attr.country 값을 설정
• 해당 예제에서는 Korea로 설정

 

 

4.3.4 es02 노드를 내리면?

• 1분 정도 기다리고 난 후 es02로 할당되지 않는 것을 확인하고 같은 country 속성인 es01에 샤드 할당

 

 

같은 country 속성에 몰리는 것을 방직하기 위해서는 force_awareness 속성 es01 노드에 추가

• - cluster.routing.allocation.awareness.force.country.values=Korea,Japan

 

서킷 브레이커 설정

• 네트워크나 시스템에서 발생하는 과부하나 장애를 감지하고 해당 부분을 격리하여 전체 시스템이 다운되는 것을 방지하는 장치
• 서킷 브레이커는 메모리 사용량이나 CPU 사용량 등의 리소스가 임계치에 도달했을 때 요청을 차단하여 시스템이 과부하에 걸리지 않도록 지원
• Elasticsearch는 Out of Memory 방지를 위해 자체적인 서킷 브레이커 설정을 가지고 있음

 

1. Parent Circuit Breaker

• 모든 자식 서킷 브레이커의 총합 메모리 사용량을 감시
• 자식 서킷 브레이커의 메모리 사용량이 부모 서킷 브레이커의 임계치를 초과할 경우 요청을 차단
• 기본값
  • indices.breaker.total.limit: 95%
  • indices.breaker.total.use_real_memory: true
  • indices.breaker.total.overhead: 1.0

 

2. Field Data Circuit Breaker

• 필드 데이터 캐시(Field Data Cache)의 메모리 사용량을 감시
• 필드 데이터 캐시는 집계 및 정렬과 같은 작업에 사용되며, 필드 데이터를 메모리에 로드할 때 사용
• 기본값
  • indices.breaker.fielddata.limit: 40%
  • indices.breaker.fielddata.overhead: 1.03

 

3. Request Circuit Breaker

• 각 요청(Request) 중 메모리 사용량을 감시
• 특히 복잡한 쿼리나 대규모의 검색 요청이 들어올 때 중요한 역할
• 기본값
  • indices.breaker.request.limit: 60%
  • indices.breaker.request.overhead: 1.0

 

4. In-flight Requests Circuit Breaker

• 현재 처리 중인 요청의 메모리 사용량을 감시
• 네트워크를 통해 이동 중인 데이터나 처리 중인 요청의 상태를 관리하는 데 사용
• 기본값
  • network.breaker.inflight_requests.limit: 100%
  • network.breaker.inflight_requests.overhead: 2.0

 

크로스 클러스터 검색 설정

• 사용자가 여러 Elasticsearch 클러스터에 분산된 데이터를 단일 쿼리로 검색할 수 있게 해주는 기능
• 대규모 분산 환경에서 데이터를 물리적 위치나 클러스터 경계에 구애받지 않고 유연하게 검색할 수 있도록 지원
• 고가용성 검색엔진 구축한다는 점에서 유용하지만 추가 설정에 따른 오버헤드 및 네트워크 지연 시간이 발생할 수 있음
• 지원 가능한 버전 확인 필요

 

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cross-cluster-search.html

 

 

부연 설명

• cluster_one, cluster_two, cluster_three: 원격 클러스터의 식별자
• seeds: 원격 클러스터의 네트워크 주소를 정의하는 항목
• skip_unavailable: 원격 클러스터가 사용할 수 없을 때의 동작을 정의하는 설정.
  • true: 원격 클러스터가 사용할 수 없을 때, 해당 클러스터를 무시하고 다른 클러스터의 데이터만 검색하고 검색 요청이 실패하지 않고 가능한 클러스터에서의 데이터만 반환
  • false: 원격 클러스터가 사용할 수 없을 때, 검색 요청이 실패하며 모든 정의된 클러스터가 사용할 수 있어야 함

 

1. ccs_minimize_roundtrips

• 크로스 클러스터 검색 쿼리를 로컬 클러스터와 원격 클러스터 간의 통신 횟수를 줄이기 위해 사용
• 기본적으로 Elasticsearch는 각 원격 클러스터에 대한 쿼리와 메타데이터 요청을 별도로 처리
• ccs_minimize_roundtrips 설정이 활성화되면, 쿼리와 메타데이터 요청을 결합하여 한 번의 왕복으로 처리 가능
• 디폴트 값은 true

 

마스터 후보 노드를 구성할 때 주의해야 할 점

 

1. 마스터 후보 노드

• 마스터 노드 선출하는 역할
• 후보 노드 자신이 마스터 노드로 선출될 수도 있음

 

2. Quorum-based decision making

• 마스터 노드를 선출하는 방법 중 하나
• Quorum: 투표를 위해 필요한 마스터 노드의 최소 개수
• 선출을 위해 필요한 마스터 후보 노드 최소 개수는 다음과 같음
  • (마스터 후보 노드 갯수 / 2) + 1
  • 7 버전 이상부터는 Elasticsearch가 Quorum을 직접 관리하므로 크게 설정할 부분은 없음

 

3. 마스터 후보 노드 구성 시 주의사항

• split brain 현상을 방지하기 위해 3개 이상의 홀수로 구성
• Quorum을 충족하기 위해 한 번에 절반 이상의 노드 제거 금지
• initial_master_nodes와의 관계
  • 최초에 클러스터를 생성할 때 마스터 후보 역할을 갖는 노드는 모두 initial_master_nodes에 포함되어야 함
  • 하지만 클러스터가 생성된 이후에 추가되는 마스터 후보 노드는 모두 initial_master_nodes에 포함되지 않아야 함 (이럴 경우 오히려 별도 클러스터를 생성하는 케이스가 발생할 수 있음)

 

Elasticsearch 캐시

• Elasticsearch는 자체적인 캐시 기능 제공
• 캐시 데이터는 힙 메모리 영역에 저장됨

 

1. Field Data Cache

• 특정 필드에 대한 집계에 사용되는 필드 데이터와 global ordinal을 캐싱
  
  • 필드 데이터: 런타임에 집계/정렬/스크립팅을 위해 계산되어 메모리에 저장되는 text type 필드와 데이터 (성능 부하 때문에 운영 측면에서 좋지 않기 때문에 doc values가 주로 쓰임)
  • global ordinal: doc values String 값을 숫자로 매핑시켜 놓은 값

 

1.1 필드 데이터

• Elasticsearch가 텍스트 분석을 위해 역색인에 포함되지 않은 데이터를 메모리에 로드하는 방식
• 주로 문자열 필드와 같이 텍스트 기반 필드에 적용
• 필드 데이터를 메모리에 로드하면 집계나 정렬과 같은 연산이 빠르게 이루어질 수 있음
• 문제점
  • 메모리 사용량: 필드 데이터를 메모리에 로드하면 JVM 힙 메모리를 많이 소비하며 대규모 데이터셋의 경우, 메모리 부족 문제를 일으킬 수 있음
  • GC 부하: 메모리 사용량이 많아지면 JVM의 가비지 컬렉션이 빈번하게 발생하여 성능 저하를 초래할 수 있음
  • 성능 부하: 필드 데이터가 메모리에 로드되는 동안, CPU와 메모리 리소스가 많이 소모

 

1.2 doc values

• 필드 데이터를 디스크에 저장하는 열 지향 데이터 구조
• 주로 숫자형, 날짜형, boolean 타입 등의 필드에 사용되며, 정렬, 집계, 스크립트 연산 시 효율적으로 데이터를 접근할 수 있게 지원
• 장점
  • 메모리 효율성: doc values는 디스크에 저장되므로, 메모리 사용량을 크게 줄일 수 있으며 필요한 데이터만 메모리에 매핑하여 사용하므로 JVM 힙 메모리 부하가 적음
  • 성능 최적화: 디스크 기반 구조로, 많은 양의 데이터를 처리할 때도 안정적인 성능을 유지할 수 있음
  • 가비지 컬렉션 부담 감소: 메모리 사용량이 줄어들어 JVM의 가비지 컬렉션 빈도가 감소

 

2. Page Cache

• 검색 요청이 들어왔을 때 디스크에서 읽은 데이터를 메모리에 넣어두고 유사한 요청이 들어왔을 때 디스크가 아닌 메모리에서 결과 반환
• Elasticsearch에서 기본적으로 채택하는 캐시
• LRU 방식 사용
• OS 레벨의 캐시이며 Off heap 공간을 사용
  • Heap 메모리를 전체 메모리의 50% 이하, 32GB까지 권장하는 이유
  • 나머지 50%는 디스크 접근을 최소화하기 위해 파일 시스템 캐시에 쓰기 위해

 

3. Query Cache

• 쿼리 내 필터 컨텍스트에서 사용되는 쿼리 결과를 캐시 영역에 저장
• 서로 다른 쿼리 간 재사용되는 데이터를 캐싱
• 필터 쿼리와 각 문서 간 매칭 여부를 true/false로 bitset 형태로 저장

 

4. Shard Request Cache

• 집계 쿼리의 결과를 캐시 영역에 저장 (샤드 레벨)
• size=0인 요청만 캐싱하기 때문에 Hit를 직접 캐싱하지는 않음
• Aggregation, Suggestion 결과를 캐싱
• 별도 설정 없었을 경우 사용되며 기본으로 힙 메모리의 1% 정도 할당
• 가장 최근 데이터만 적극적으로 업데이트하는 시계열 데이터 케이스에 매우 유용
  • ex) 로그 데이터

 

참고

• 패스트 캠퍼스 -  고성능 검색 엔진 구축으로 한 번에 끝내는 Elasticsearch