[OpenSearch 클러스터 운영] OpenSearch 클러스터 구성 실습

3.4 OpenSearch 클러스터 구성 실습

3.4.1 OpenSearch 클러스터 시각화 클라이언트

Elasticvue는 다음과 같은 기능을 제공하는 OpenSearch 클라이언트다.

• 클러스터, 노드, 샤드 상태 확인
• 인덱스 관리
• REST API 인터페이스
• 스냅샵 관리

크롬 확장 프로그램으로 쉽게 설치할 수 있고, 복잡한 환경 설정이 필요 없다는 장점이 있다. 다음 링크를 클릭해서 크롬 확장 프로그램에 추가하고, 실행해보자.

https://chrome.google.com/webstore/detail/elasticvue/hkedbapjpblbodpgbajblpnlpenaebaa

Elasticvue를 실행하면 다음과 같은 Setup 화면이 뜬다. Uri에 OpenSearch REST API 주소를 입력하고 CONNECT를 누르자.

다음과 같은 화면이 뜨면 연결에 성공한 것이다.

클러스터, 노드, 샤드 모니터링이 필요한 경우 Elasticvue를 활용해보자.

3.4.2 멀티 노드 클러스터 구성

챕터 1.1에서는 EC2 인스턴스 한 대로 싱글 노드 클러스터를 구성했었다. 챕터 3.4에서는 EC2 인스턴스 여러 대에 OpenSearch 인스턴스를 한 개씩 설치하여 멀티 노드 클러스터를 구성해 볼 것이다. EC2 인스턴스 한 대에 여러 개의 OpenSearch 인스턴스를 설치할 수도 있지만, OpenSearch에서 권장하는 방법은 아니다.

지금부터 다음과 같은 4노드 클러스터를 구성할 것이다.

출처: https://opensearch.org/docs/latest/opensearch/cluster/

• 클러스터 매니저 노드 1개 (전용 노드)
• 코디네이터 노드 1개 (전용 노드)
• 데이터 & 인제스트 노드 2개

4노드 클러스터를 구성하려면 EC2 인스턴스 4대가 필요하다. EC2 인스턴스 4개를 띄우고, 모든 인스턴스에 한 번씩 접속해서 OpenSearch를 설치하는 것은 번거로운 일이다. 반면 AMI를 활용하면 클릭 몇 번으로 OpenSearch가 미리 설치된 EC2 인스턴스를 시작할 수 있다. AMI는 EC2 인스턴스의 소프트웨어 구성이 정의된 템플릿이며, 기본적으로 EC2 인스턴스에 연결된 모든 EBS 볼륨의 상태도 같이 복제된다. 즉 AMI를 사용하면 특정 EC2 인스턴스와 똑같은 환경의 인스턴스를 시작할 수 있다.

• AMI 를 사용하기위한 베이스는
• EFK로 서버 로그 수집하기 강의자료의 4.1.1~4.1.3 과 4.1.9 를 따라한다.
  • opensearch를 실행은 시키지 않는다.

⚠️ AMI 생성 전 EC2 인스턴스에서 $ sysctl vm.max_map_count로 vm.max_map_count가 262144 이상인지 확인하자. 만약 262144보다 작다면 <EFK로 서버 로그 수집하기>의 4.1.1-4.1.3를 참고해서 vm.max_map_count를 262144 이상으로 설정해줘야 한다. 챕터 1.1에서는 싱글 노드 클러스터로 실습했기 때문에 선택 사항이었지만, 멀티 노드 클러스터의 경우 vm.max_map_count를 262144 이상으로 설정해주지 않으면 다음과 같은 에러 메시지를 띄우면서 bootstrap check가 실패하게 된다. (멀티 노드 클러스터 기능을 사용할 경우 프로덕션 레벨의 OpenSearch 인스턴스로 간주되기 때문)

ERROR: [2] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

⚠️ AMI 생성 전 EC2 인스턴스에서 $ rm -rf $OPENSEARCH_HOME/data/nodes/*를 실행해서 OpenSearch 데이터를 초기화해야 한다. 해당 경로에는 같은 EC2 인스턴스 안에서 클러스터링된 모든 노드의 정보가 저장되어 있으며, OpenSearch는 데이터 경로를 지정하지 않는 이상 기본적으로 $OPENSEARCH_HOME/data/nodes/0에 노드 정보를 저장한다. 데이터 경로에는 노드 ID 정보가 저장되어 있기 때문에 서로 다른 노드가 같은 데이터 경로를 바라볼 경우 ID 충돌이 발생한다.

EC2 콘솔에서 OpenSearch가 설치된 EC2 인스턴스를 선택하고 (한국어 콘솔의 경우) 우측 상단의 작업 → 이미지 및 템플릿 → 이미지 생성 버튼을 눌러 AMI를 생성하자. AMI는 생성 요청 후 사용 가능 상태로 바뀌기까지 약 5~10분 가량의 시간이 걸린다.

AMI를 사용하여 인스턴스 4대를 시작하자.

헷갈리지 않도록 인스턴스 이름에 노드 타입을 추가해주자.

모든 인스턴스 대상으로 OpenSearch config를 수정해줘야 한다. config 파일 경로는 다음과 같다.

$OPENSEARCH_HOME/config/opensearch.yml

config에는 다음 속성 값을 수정해주면 된다.

• cluster.name: 클러스터 이름
  • 클러스터 이름을 지정하지 않을 경우 opensearch라는 이름으로 클러스터가 생성된다. 프로덕션 환경에서는 클러스터 이름을 지정해주는 것이 좋다. 프로덕션과 동일한 네트워크에서 노드를 개발하다 실수로 프로덕션 클러스터에 해당 노드를 가입시킬 수 있기 때문이다. 네트워크를 분리해서 개발하는 것이 가장 좋겠지만, 혹시 모를 상황에 대비하는 것이 좋다.
• node.name: 노드 이름
• node.roles: 노드 타입
• network.host: 노드의 IP 주소
• discovery.seed_hosts: 클러스터에 속한 클러스터 매니저 또는 후보 노드의 IP 주소 목록
  • 노드가 처음 실행될 때 discovery.seed_hosts에 설정된 IP 주소로 클러스터 매니저 또는 후보 노드를 찾고, 해당 노드를 클러스터로 바인딩하는 과정을 디스커버리라고 한다.
  • IP 주소로 노드를 찾았을 때 클러스터 이름이 일치하지 않거나 찾은 노드가 클러스터 매니저 또는 후보 노드가 아닐 경우 다른 IP 주소로 디스커버리 과정을 반복한다.
• cluster.initial_cluster_manager_nodes : 클러스터를 맨 처음 실행할 때, 최초로 뜨는 node.name 최초로 기동하는 cluster_manager 서버가 자기 자신의 node.name 을 입력하면 된다.

de-opensearch-cluster-practice_manager EC2 인스턴스에 접속해서 다음과 같이 OpenSearch config를 수정하고 $ sudo systemctl restart opensearch.service로 OpenSearch 노드를 재시작하자.

plugins.security.disabled: true
cluster.name: opensearch-cluster
node.name: opensearch-cluster_manager
node.roles: [ cluster_manager ]
network.host: 0.0.0.0
discovery.seed_hosts: [0.0.0.0]
cluster.initial_cluster_manager_nodes: ["opensearch-cluster_manager"]

Elasticvue에 클러스터 매니저 노드를 연결하고 NODES 탭을 클릭해보자. 클러스터에 opensearch-cluster_manager 노드가 바인딩된 것을 확인할 수 있다.

de-opensearch-cluster-practice_data1 EC2 인스턴스에 접속해서 다음과 같이 OpenSearch config를 수정하고 $ sudo systemctl restart opensearch.service로 OpenSearch 노드를 재시작하자.

plugins.security.disabled: true
cluster.name: opensearch-cluster
node.name: opensearch-d1
node.roles: [ data, ingest ]
network.host: 0.0.0.0
discovery.seed_hosts: ["<CLUSTER_MANAGER_NODE_PUBLIC_IP>"]

Elasticvue의 NODES 탭을 새로고침하면, 클러스터에 opensearch-d1 노드가 추가 바인딩된 것을 확인할 수 있다.

de-opensearch-cluster-practice_data2 EC2 인스턴스에 접속해서 다음과 같이 OpenSearch config를 수정하고 $ sudo systemctl restart opensearch.service로 OpenSearch 노드를 재시작하자.

plugins.security.disabled: true
cluster.name: opensearch-cluster
node.name: opensearch-d2
node.roles: [ data, ingest ]
network.host: 0.0.0.0
discovery.seed_hosts: ["<CLUSTER_MANAGER_NODE_PUBLIC_IP>"]

Elasticvue의 NODES 탭을 새로고침하면, 클러스터에 opensearch-d2 노드가 추가 바인딩된 것을 확인할 수 있다.

de-opensearch-cluster-practice_coordinator EC2 인스턴스에 접속해서 다음과 같이 OpenSearch config를 수정하고 $ sudo systemctl restart opensearch.service로 OpenSearch 노드를 재시작하자.

모든 노드는 코디네이터 노드 역할을 수행하므로, node.roles를 빈 배열로 설정하면 해당 노드는 코디네이터 역할만 수행하는 코디네이터 전용 노드가 된다.

plugins.security.disabled: true
cluster.name: opensearch-cluster
node.name: opensearch-c1
node.roles: []
network.host: 0.0.0.0
discovery.seed_hosts: ["<CLUSTER_MANAGER_NODE_PUBLIC_IP>"]

Elasticvue의 NODES 탭을 새로고침하면, 클러스터에 opensearch-c1 노드가 추가 바인딩된 것을 확인할 수 있다.

3.4.3 클러스터 매니저 노드 재선출

opensearch-cluster_manager 노드가 실행중인 EC2 인스턴스에 접속해서 다음 명령어로 클러스터 매니저 노드를 중지시켜보자.

$ sudo systemctl stop opensearch.service

Elasticvue의 NODES 탭을 새로고침하면, 노드를 찾을 수 없다는 화면이 보일 것이다.

Elasticvue를 opensearch-c1 노드의 public IP로 연결할 경우 코디네이터 노드와 해당 노드에 포함된 샤드의 정보는 확인할 수 있지만, 클러스터, 노드, 인덱스의 정보는 확인할 수 없다. 클러스터 매니저 노드는 클러스터 설정, 인덱스 설정, 노드 상태를 관리하는 역할을 담당하기 때문에 매니저 노드가 없는 상황에서는 Elasticvue도 해당 정보를 읽어올 수 없다.

{
  "error": {
    "root_cause": [
      {
        "type": "cluster_manager_not_discovered_exception",
        "reason": null
      }
    ],
    "type": "cluster_manager_not_discovered_exception",
    "reason": null
  },
  "status": 503
}

클러스터 매니저 노드에 장애가 발생하는 상황에 대비하기 위해서는 클러스터 매니저 후보 노드를 설정해둬야 한다. node.roles에 cluster_manager를 포함하는 경우 클러스터 매니저 후보 역할을 수행하게 된다.

opensearch-d2 노드의 node.roles를 다음과 같이 수정하고 노드를 재시작하자.

node.roles: [ data, ingest, cluster_manager ]

모든 노드의 discovery.seed_hosts에 opensearch-d2 노드의 IP 주소가 등록되어 있지 않기 때문에 discovery에 실패하게 된다. 따라서 Elasticvue에서는 여전히 클러스터 정보를 읽어올 수 없을 것이다. (Elasticvue는 코디네이터 노드에 연결된 상태) 이 경우 opensearch-cluster_manager 노드를 재시작해야 클러스터를 활성화시킬 수 있다. 이후 Elasticvue를 확인해보면 opensearch-d2 노드에 클러스터 매니저 후보(master eligile) 역할이 추가된 것을 확인할 수 있을 것이다.

opensearch-cluster_manager 노드를 다시 중지시켜보자. opensearch-d2가 새로운 클러스터 매니저 노드로 선출되고 클러스터가 정상화될 것이라는 예상과는 달리 클러스터는 여전히 작동을 멈춘 상태다. 이유는 에러 로그를 통해 알 수 있는데, 클러스터 매니저 노드 선출에 필요한 최소 후보 노드 수를 충족하지 못했기 때문이다.

• message: which is not a quorum;

[2022-12-25T09:51:57,621][WARN ][o.o.c.c.ClusterFormationFailureHelper] [opensearch-d2] cluster-manager not discovered or elected yet, an election requires a node with id [k3y5PllfSzCZQKACMQN4tg], have discovered [{opensearch-d2}{OpwmNmeiQSCd19yKmZfKfQ}{Q-z5SfsoSB2-U4o5GLVVwg}{172.31.100.141}{172.31.100.141:9300}{dim}{shard_indexing_pressure_enabled=true}] which is not a quorum; discovery will continue using [13.125.209.78:9300] from hosts providers and [{opensearch-d2}{OpwmNmeiQSCd19yKmZfKfQ}{Q-z5SfsoSB2-U4o5GLVVwg}{172.31.100.141}{172.31.100.141:9300}{dim}{shard_indexing_pressure_enabled=true}, {opensearch-cluster_manager}{k3y5PllfSzCZQKACMQN4tg}{mTQPHU7tTNOV8YfUONlEuQ}{172.31.100.191}{172.31.100.191:9300}{m}{shard_indexing_pressure_enabled=true}] from last-known cluster state; node term 10, last-accepted version 84 in term 10

최소 후보 노드 수를 충족하기 위해 opensearch-d1 노드의 node.roles를 다음과 같이 수정하고, opensearch-cluster_manager 노드와 opensearch-d1 노드를 모두 재시작하자.

node.roles: [ data, ingest, cluster_manager ]

모든 노드가 클러스터링된 것을 확인한 다음 opensearch-cluster_manager 노드를 다시 중지시켜보자. Elasticvue의 NODES 탭을 새로고침하면 다음과 같이 opensearch-d1 (또는 opensearch-d2 ) 노드가 매니저 노드로 선출된 것을 확인할 수 있다.

이 상태에서 opensearch-cluster_manager 노드를 다시 클러스터에 참여시키려면 discovery.seed_hosts를 다음과 같이 수정하고 노드를 재시작해줘야 한다.

discovery.seed_hosts: ["<DATA2_NODE_PUBLIC_IP>"]

opensearch-cluster_manager 노드가 다시 클러스터에 참여해도 이미 선출된 매니저 노드는 바뀌지 않고, 그대로 opensearch-d1 노드인 것을 확인할 수 있다.

안전한 클러스터 운영을 위해 클러스터 매니저 후보 노드는 최소 3개 이상(클러스터 매니저 노드 포함)으로 설정하는 것이 좋다. 또한 discovery.seed_hosts에는 모든 클러스터 매니저 후보 노드를 포함시키는 것이 좋다.

OpenSearch와 달리 ElasticSearch의 경우 7.3 버전부터 투표 전용 노드 타입을 지원한다. 클러스터 매니저 후보 노드 중에서 매니저 선출 투표에는 참여할 수 있지만, 본인은 매니저 노드가 될 수 없는 노드를 투표 전용 노드라고 한다. 투표 전용 노드는 매니저 노드가 될 수 없기 때문에 매니저 후보 노드보다 부담없이 사용할 수 있으며, 대다수의 매니저 후보 노드들에 장애가 발생했을 때도 매니저 후보 선출 과정이 정상적으로 진행될 수 있도록 돕는다.

ElasticSearch에서 투표 전용 노드를 만들고 싶다면 node.roles를 다음과 같이 설정해주면 된다.

node.roles: [ cluster_manager, voting_only ]

3.4.4 인제스트 노드 파이프라인 설정

PUT /_ingest/pipeline/test-pipeline API로 인제스트 파이프라인을 생성할 수 있다. Elasticvue의 REST 클라이언트를 사용해서 요청해보자.

요청 본문에서 processors 필드는 리스트 타입으로, 여러 개의 프로세서를 정의할 수 있고, 해당 프로세서들은 리스트에 정의된 순서대로 실행된다. set 프로세서는 특정 필드의 값을 추가 또는 수정하는 작업을 수행하고, lowercase 프로세서는 string을 소문자로 변환하는 작업을 수행한다.

$ curl -XPUT "$OPENSEARCH_REST_API/_ingest/pipeline/test-pipeline?pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
  "processors": [
    {
      "set": {
        "field": "field1",
        "value": 10
      }
    },
    {
      "lowercase": {
        "field": "field2"
      }
    }
  ]
}
'

test-pipeline 파이프라인을 사용해서 도큐먼트를 test1 인덱스에 인덱싱해보자.

$ curl -XPUT "$OPENSEARCH_REST_API/test1/_doc/1?pipeline=test-pipeline&pretty=true" \
	-H "Content-Type: application/json" \
	-d '
{
	"field1": "test",
	"field2": "Hello, OpenSearch!"
}
'

인덱싱한 도큐먼트의 field1은 10으로, field2는 모두 소문자로 변경된 것을 확인할 수 있다.