본문 바로가기
OpenSearch (ElasticSearch)

[2] Opensearch와 클러스터 설정

by parkjp 2022. 2. 14.

Opensearch 구성은 cluster setting API에서 설정할 수 있다.

특정 부분은 opensearch.yml 파일을 수정하고 다시 시작해야되는 부분이 있는데, 이 특정 부분을 제외하고는 가능하면 cluster setting API를 사용하는 것이 좋다. cluster setting API는 클러스터 내 전체 노드의 설정을 적용하지만 opensearch.yml파일을 수정하는 것은 각각의 노드 설정을 변경하는 것이 된다.

opensearch.yml 파일을 수정해야되는 특정부분은 네트워킹, 클러스터 구성, 로컬 파일 시스템에 대한 수정 작업이 이루어질 때이다.

 

Opensearch에서 데이터를 검색 및 집계하기 전에 클러스터 생성부터 이루어져야 한다.

단일 노드 또는 다중 노드 클러스터로 작동할 수 있는데, 아래에는 다중 노드 클러스터의 기본 아키텍처 예시이다.

 

기본적인 다중 노드 클러스터 아키텍처 예시 (전용 마스터 노드 1개,  coordinating node 1개, 마스터 자격이 있고 데이터 수집에도 사용되는 노드가 2개 있는 4노드를 가진 클러스터.)

 

:: 노드 유형

Node Type Description Best Practices for Production
Master 전체적인 클러스터 상태의 유지관리 및 운영을 관장하는 노드.
인덱스를 생성, 삭제, 노드의 추가 및 삭제 추적, 각 노드의 health check, 노드의 샤드 할당 등을 담당한다.
3개의 영역의 3개의 전용 마스터 노드는 거의 모든 프로덕션 사용 사례에 적합하다.
이 구성은 클러스터가 쿼리 요청을 잃지 않도록 한다.
두 개의 노드는 한 노드가 다운되거나 유지 관리가 필요한 경우를 제외하고 대부분의 시간 동안 유휴 상태 로 지속된다.
Master-Eligible Master-eligible 노드들 중 투표를 통해 하나를 Master 노드로 선출한다.  
Data 데이터를 저장하고 검색한다. 로컬 샤드에서 모든 데이터 관련 작업 ( 인덱싱, 검색, 집계 )을 수행한다.
클러스터의 작업자 노드로서 다른 노드 유형보다 많은 디스크 공간을 필요로 한다.
데이터 노드를 추가할 때 각 노드들의 균형을 유지해야 한다.
예를 들어, 세 개의 영역이 있는 경우 각 영역에 하나씩 데이터 노드를 추가해야 한다.
스토리지 및 RAM이 많이 사용되는 노드를 사용하는 것이 좋다.
Ingest 데이터를 클러스터에 저장하기 전에 전처리를 한다. 인덱스에 데이터를 추가하기 전에 데이터를 변환(가공)하는 수집 파이프라인을 실행한다. 많은 데이터를 수집하고 복잡한 수집 파이프라인을 실행할 계획이라면 이 노드를 쓰는 것이 좋다.
선택적으로 데이터 노드에서 인덱싱을 off하여 데이터 노드가 검색 및 집계에만 사용되도록 할 수도 있다.
Coordinating 클라이언트 요청을 데이터 노드의 샤드에 위임하고 결과를 수집하여 하나의 최종 결과로 집계한 다음 이 결과를 클라이언트에 다시 보내는 작업을 한다. 검색이 많은 워크로드에 대한 병목 현상을 방지하려면 몇 개의 전용 coordinating 노드가 적합하다.
가능한 많은 코어가 있는 CPU를 사용하는 것이 좋다.

 

이러한 모든 노드 유형은 벤치마크 테스트 도구인 Rally를 통해 소규모 샘플 클러스터를 provisioning하고 다양한 워크로드 및 구성으로 테스트를 해보는 것이 좋다.

** Rally : https://esrally.readthedocs.io/en/stable/

 

Rally 2.3.1 — Rally 2.3.1 documentation

You want to benchmark Elasticsearch? Then Rally is for you. It can help you with the following tasks: We have also put considerable effort in Rally to ensure that benchmarking data are reproducible. License This software is licensed under the Apache Licens

esrally.readthedocs.io

 

 

:: 클러스터 기본 설정

 

클러스터 기본설정은 config/opensearch.yml 파일 수정을 통해 진행한다.

 

1. 클러스터의 이름 설정

 

opensearch.yml에 cluster.name 부분 변경.

 

2. 클러스터의 각 노드에 대한 노드 속성 설정

 

// 마스터 노드
node.name: <node-name>
node.roles: [ master ]
 
 
// 2개의 데이터 노드 설정
node.name: opensearch-d1 (이름 예시)
node.name: opensearch-d2

// 데이터 수집에도 사용할 master-eligible노드로 만들 수 있습니다.
node.roles: [ data, ingest ]
 
 
// coordinating 노드
node.name: <node-name>
node.roles: [] // 기본이 coordinating 노드이므로 빈 값으로 설정

 

3. 클러스터를 특정 IP 주소에 binding

 

network_host는 노드를 바인드하는데 사용되는 IP 주소를 정의한다.

default로 Opensearch는 클러스터를 단일 노드로 제한하는 localhost를 수신한다.

IPv4나 IPv6 여부와 상관없이 `_local_`이나 `_site_`를 loopback(127.0.0.1)이나 site-local 주소에 바인드하기 위해 사용할 수 있다.

 

network.host: [_local_, _site_]
 
 
// 다중 노드 클러스터 구성 시
network.host: <IP address of the node>

 

4. 클러스터에 대한 discovery 호스트 구성

 

// 일반적으로 모든 master-eligible 노드를 해당 어레이에 추가할 수 있다.
discovery.seed_hosts: ["<private IP of opensearch-d1>", "<private IP of opensearch-d2>", "<private IP of opensearch-c1>"]

 

// 여기까지 구성을 마쳤다면 opensearch 서비스 시작 후 아래 커맨드로 구성한 모든 노드 상태를 볼 수 있다.
curl -XGET https://<private-ip>:9200/_cat/nodes?v -u 'admin:admin' --insecure

 

5. 샤드 할당 인식 및 강제 인식 구성

 

노드가 여러 지리적 영역에 분산되어 있는 경우 모든 복제본 샤드를 기본 샤드와 다른 영역에 할당하도록 샤드 할당 인식을 구성할 수 있습니다.

샤드 할당 인식을 사용하면 한 영역의 노드들이 장애가 발생해도 복제본의 샤드들이 다른 영역에도 있다는 걸 보증할 수 있습니다.

이것은 데이터가 개별 노드 오류를 넘어 영역 오류에서도 살아 남을 수 있도록 합니다.

 

// opensearch-d1의 영역 설정
node.attr.zone: zoneA
 
// opensearch-d2의 영역 설정
node.attr.zone: zoneB
 
// 클러스터 설정 업데이트
PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone"
  }
}

 

persistent 또는 transient 설정 을 사용할 수 있습니다 . persistent는  클러스터 재부팅 후에도 설정이 그대로 유지됩니다 . transient 설정은 클러스터 재부팅을 하게 되면 유지되지 않습니다.

샤드 할당 인식은 여러 영역에서 기본 샤드와 복제본 샤드를 분리하려고 시도합니다. 그러나 하나의 영역만 사용할 수 있는 경우, OpenSearch는 복제본 샤드를 남아 있는 유일한 영역에 할당하게 됩니다.

 

 

또 다른 옵션은 기본 및 복제본 샤드가 동일한 영역에 할당되지 않도록 하는 것입니다. 이것을 강제 인식이라고 합니다.

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.awareness.attributes": "zone",
    "cluster.routing.allocation.awareness.force.zone.values":["zoneA", "zoneB"]
  }
}

이 경우 데이터 노드에 장애가 발생하면 강제 인식이 동일한 영역의 노드에 복제본을 할당하지 않습니다. 대신 클러스터는 노란색 상태가 되고 다른 영역의 노드가 온라인 상태가 될 때만 복제본을 할당합니다.

 

 

6. hot-warm 아키텍처 설정

 

먼저 데이터를 빠르고 비용이 많이 드는 핫 노드에 인덱싱하고 일정 기간 후에 데이터를 느리고 저렴한 warm 노드로 이동하는 hot-warm 아키텍처를 설계할 수 있습니다.

거의 업데이트하지 않는 시계열 데이터를 분석하고 더 오래된 데이터를 더 저렴한 스토리지에 저장하려는 경우 이 아키텍처가 적합할 수 있습니다.

이 아키텍처는 스토리지 비용을 절약하는 데 도움이 됩니다. 핫 노드 수를 늘리고 빠르고 값비싼 스토리지를 사용하는 대신 자주 액세스하지 않는 데이터에 대해 웜 노드를 추가할 수 있습니다.

 

 

hot-warm 스토리지 아키텍처를 구성하려면 temp 속성을 opensearch-d1 및 opensearch-d2에 각각 추가합니다.

node.attr.temp: hot
node.attr.temp: warm
// 핫 노드에 인덱스 추가
PUT newindex
{
  "settings": {
    "index.routing.allocation.require.temp": "hot"
  }
}
// 인덱스에 대한 샤드 할당 상태
GET _cat/shards/newindex?v
index     shard prirep state      docs store ip         node
new_index 2     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 2     r      UNASSIGNED
new_index 3     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 3     r      UNASSIGNED
new_index 4     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 4     r      UNASSIGNED
new_index 1     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 1     r      UNASSIGNED
new_index 0     p      STARTED       0  230b 10.0.0.225 opensearch-d1
new_index 0     r      UNASSIGNED

 

위 예제에서 모든 primary 샤드들은 핫 노드인 opensearch-d1에 할당됩니다. 그러나 모든 복제본 샤드는 할당이 되지 않는데, 그 이유는 우리가 오직 핫 노드에게만 할당되도록 강제했기 때문입니다.

 

// warm 노드에 인덱스 추가
PUT oldindex
{
  "settings": {
    "index.routing.allocation.require.temp": "warm"
  }
}
// 인덱스에 대한 샤드 할당 상태
GET _cat/shards/oldindex?v
index     shard prirep state      docs store ip        node
old_index 2     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 2     r      UNASSIGNED
old_index 3     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 3     r      UNASSIGNED
old_index 4     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 4     r      UNASSIGNED
old_index 1     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 1     r      UNASSIGNED
old_index 0     p      STARTED       0  230b 10.0.0.74 opensearch-d2
old_index 0     r      UNASSIGNED

 

이 경우 모든 기본 샤드는 opensearch-d2에 할당됩니다. 다시 말하지만, 하나의 웜 노드만 있기 때문에 모든 복제본 샤드가 할당되지 않게 됩니다.

 

index.routing.allocation.require.temp 값을 hot으로 설정하는 인덱스 템플릿을 이용할 수도 있습니다. 이 방법은 가장 최근의 데이터를 hot 노드에 저장하도록 합니다.

또한, 인덱스 상태 관리 플러스인(Index State Management (ISM))을 사용하여 인덱스의 주기를 관리할 수 있고, 특정 주기가 되면 warm 노드 상태로 변경하도록 할 수 있습니다.

 

반응형

'OpenSearch (ElasticSearch)' 카테고리의 다른 글

[6] 데이터 스트림  (0) 2022.02.25
[5] 인덱스 별칭 (aliases)  (0) 2022.02.22
[4] 인덱스 데이터  (0) 2022.02.18
[3] 인덱스 생성과 설정 예제  (0) 2022.02.17
[1] OpenSearch란? Opensearch와 일반 RDB 비교  (0) 2022.02.12