엘라스틱서치:: Important Elasticsearch Configuration

Intro::

Important Elasticsearch configuration

엘라스틱서치는 시작하기 위해서 적은 구성을 필요로 하지만 클러스터 운영을 위해서는 많은 수의 설정들을 고려해야 합니다.

Path settings

Elasticsearch는 인덱스와 데이터 스트림에 색인한 데이터를 데이터 디렉터리에 기록합니다. Elasticsearch는 클러스터 상태 및 작업에 대한 정보가 포함된 자체 애플리케이션 로그를 로그 디렉터리에 기록합니다.

프로덕션 환경에서는 elasticsearch.yml의 path.data 및 path.log를 $ES_HOME 외부의 위치로 설정하는 것이 좋습니다. Docker, Debian 및 RPM 설치는 기본적으로 데이터와 로그를 $ES_HOME 외부 위치에 기록합니다. 지원되는 path.data 및 path.logs 값은 플랫폼에 따라 다릅니다.

Multiple data paths

7.13.0. 버전 부터 중지

필요한 경우, path.data에 여러 경로를 지정할 수 있습니다. Elasticsearch는 제공된 모든 경로에 걸쳐 노드의 데이터를 저장하지만 각 샤드의 데이터는 동일한 경로에 유지합니다.

Elasticsearch는 노드의 데이터 경로에 걸쳐 샤드의 균형을 조정하지 않습니다. 단일 경로에서 디스크 사용량이 높으면 전체 노드에 대해 높은 디스크 사용량 워터마크가 트리거될 수 있습니다. 트리거되면 노드의 다른 경로에 사용 가능한 디스크 공간이 있더라도 Elasticsearch는 해당 노드에 샤드를 추가하지 않습니다. 추가 디스크 공간이 필요한 경우, 데이터 경로를 추가하는 대신 새 노드를 추가하는 것이 좋습니다.

Migrate from multiple data paths

다중 데이터 경로에 대한 지원은 7.13에서 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다.

다중 데이터 경로의 대안으로 RAID와 같은 하드웨어 가상화 계층 또는 Linux의 LVM(논리 볼륨 관리자) 또는 Windows의 스토리지 공간과 같은 소프트웨어 가상화 계층을 사용하여 여러 디스크에 걸쳐 있는 파일 시스템을 만들 수 있습니다. 단일 컴퓨터에서 여러 데이터 경로를 사용하려면 각 데이터 경로에 대해 하나의 노드를 실행해야 합니다.

현재 고가용성 클러스터에서 여러 데이터 경로를 사용하는 경우 롤링 재시작과 유사한 프로세스를 사용하여 각 노드를 차례로 종료하고 각각 단일 데이터 경로를 사용하도록 구성된 하나 이상의 노드로 교체하는 방식으로 다운타임 없이 각 노드에 단일 경로를 사용하는 설정으로 마이그레이션할 수 있습니다. 좀 더 자세히 설명하자면, 현재 여러 데이터 경로를 가지고 있는 각 노드에 대해 다음 프로세스를 따라야 합니다. 원칙적으로 8.0으로 롤링 업그레이드하는 동안 이 마이그레이션을 수행할 수 있지만 업그레이드를 시작하기 전에 단일 데이터 경로 설정으로 마이그레이션하는 것이 좋습니다.

데이터를 보호하기 위해 스냅샷을 생성하세요.

원하는 경우 할당 필터를 사용하여 대상 노드에서 데이터를 마이그레이션합니다.


PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": "대상 노드 이름"
  }
}

cat 할당 API를 사용하여 이 데이터 마이그레이션의 진행 상황을 추적할 수 있습니다. 일부 샤드가 마이그레이션되지 않는 경우 클러스터 할당 설명 API가 그 이유를 파악하는 데 도움이 됩니다.

대상 노드 종료까지 롤링 재시작 프로세스의 단계를 따르세요.

클러스터 상태가 노란색 또는 녹색인지 확인하여 클러스터의 다른 노드 중 하나 이상에 할당된 모든 샤드의 사본이 있는지 확인합니다.

해당되는 경우, 이전 단계에서 적용된 할당 필터를 제거합니다.


PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.exclude._name": null
  }
}

데이터 경로의 내용을 삭제하여 중지된 노드가 보유한 데이터를 폐기합니다.

스토리지를 재구성합니다. 예를 들어, LVM 또는 저장 공간을 사용하여 디스크를 단일 파일 시스템으로 결합합니다. 재구성한 스토리지에 저장할 데이터를 위한 충분한 공간이 있는지 확인하세요.

elasticsearch.yml 파일에서 path.data 설정을 조정하여 노드를 재구성합니다. 필요한 경우, 각각 별도의 데이터 경로를 가리키는 자체 path.data 설정을 사용하여 노드를 더 설치하세요.

새 노드를 시작하고 나머지 롤링 재시작 프로세스를 따릅니다.

클러스터 상태가 녹색으로 표시되어 모든 샤드가 할당되었는지 확인합니다.

Cluster name setting

노드는 클러스터의 다른 모든 노드와 cluster.name을 공유하는 경우에만 클러스터에 참여할 수 있습니다. 기본 이름은 elasticsearch이지만 클러스터의 목적을 설명하는 적절한 이름으로 변경해야 합니다.


cluster.name: logging-prod

Node name setting

Elasticsearch는 node.name을 사람이 읽을 수 있는 식별자로 Elasticsearch의 특정 인스턴스에 대해 사용합니다. 이 이름은 많은 API의 응답에 포함되어 있습니다. 노드 이름은 Elasticsearch가 시작될 때 기본적으로 머신의 호스트 이름으로 설정되지만, elasticsearch.yml에서 명시적으로 구성할 수 있습니다.


node.name: prod-data-2

Node host setting

기본적으로 Elasticsearch는 127.0.0.1 및 [::1]과 같은 루프백 주소에만 바인딩합니다. 이는 개발 및 테스트를 위해 단일 서버에서 하나 이상의 노드로 구성된 클러스터를 실행하는 데 충분하지만, 탄력적인 운영 클러스터는 다른 서버의 노드를 포함해야 합니다. 네트워크 설정에는 여러 가지가 있지만 일반적으로는 network.host만 구성하면 됩니다:


network.host: 192.168.1.10

Distcovery ansd cluster formation settings

프로덕션으로 전환하기 전에 클러스터의 노드가 서로를 검색하고 마스터 노드를 선출할 수 있도록 두 가지 중요한 검색 및 클러스터 형성 설정을 구성해야합니다.

discovery.seed_hosts

네트워크 구성 없이 바로 사용 가능하며, Elasticsearch는 사용 가능한 루프백 주소에 바인딩하고 로컬 포트 9300~9305를 스캔하여 동일한 서버에서 실행 중인 다른 노드와 연결합니다. 이 동작은 어떤 구성도 하지 않아도 자동 클러스터링 환경을 제공합니다.

다른 호스트에 있는 노드로 클러스터를 구성하려면 정적 discovery.seed_hosts 설정을 사용하세요. 이 설정은 클러스터에서 마스터 자격이 있고 라이브 상태이며 검색 프로세스를 시드하기 위해 연결할 수 있는 다른 노드 목록을 제공합니다. 이 설정은 클러스터에 있는 모든 마스터 적격 노드의 주소의 YAML 시퀀스 또는 배열을 허용합니다. 각 주소는 IP 주소이거나 DNS를 통해 하나 이상의 IP 주소로 확인되는 호스트 이름일 수 있습니다.


discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11 
   - seeds.mydomain.com 
   - [0:0:0:0:0:ffff:c0a8:10c]:9301

cluster.initial_master_nodes

Elasticsearch 클러스터를 처음 시작할 때 클러스터 부트스트랩 단계는 첫 번째 선거에서 투표가 집계되는 마스터 적격 노드 집합을 결정합니다. 개발 모드에서는 검색 설정이 구성되지 않은 상태에서 이 단계는 노드 자체에 의해 자동으로 수행됩니다.

자동 부트스트랩은 본질적으로 안전하지 않으므로 프로덕션 모드에서 새 클러스터를 시작할 때는 첫 번째 선거에서 투표를 집계해야 하는 마스터 적격 노드를 명시적으로 나열해야 합니다. 이 목록은 cluster.initial_master_nodes 설정을 사용하여 설정합니다.

클러스터가 처음으로 성공적으로 형성된 후에는 각 노드의 구성에서 cluster.initial_master_nodes 설정을 제거합니다. 클러스터를 다시 시작하거나 기존 클러스터에 새 노드를 추가할 때는 이 설정을 사용하지 마세요.


discovery.seed_hosts:
   - 192.168.1.10:9300
   - 192.168.1.11
   - seeds.mydomain.com
   - [0:0:0:0:0:ffff:c0a8:10c]:9301
cluster.initial_master_nodes: 
   - master-node-a
   - master-node-b
   - master-node-c

Heap size settings

기본적으로 Elasticsearch는 노드의 역할과 총 메모리를 기반으로 JVM 힙 크기를 자동으로 설정합니다. 대부분의 프로덕션 환경에서는 기본 사이징을 권장합니다.

필요한 경우, JVM 힙 크기를 수동으로 설정하여 기본 사이징을 재정의할 수 있습니다.

JVM heap dump

기본적으로 Elasticsearch는 메모리 부족 예외에 대한 힙을 기본 데이터 디렉터리에 덤프하도록 JVM을 구성합니다. RPM 및 Debian 패키지에서 데이터 디렉터리는 /var/lib/elasticsearch입니다. Linux와 MacOS 및 Windows 배포판에서 데이터 디렉터리는 Elasticsearch 설치의 루트 아래에 있습니다.

이 경로가 힙 덤프를 수신하기에 적합하지 않은 경우, jvm.options에서 -XX:HeapDumpPath=... 항목을 수정하세요:

디렉터리를 지정하는 경우, JVM은 실행 중인 인스턴스의 PID를 기반으로 힙 덤프의 파일 이름을 생성합니다.

디렉터리 대신 고정 파일 이름을 지정하는 경우, 메모리 부족 예외로 인해 JVM이 힙 덤프를 수행해야 할 때 파일이 존재하지 않아야 합니다. 그렇지 않으면 힙 덤프가 실패합니다.

GC logging settings

기본적으로 Elasticsearch는 가비지 수집(GC) 로그를 활성화합니다. 이는 jvm.options에서 구성되며 Elasticsearch 로그와 동일한 기본 위치로 출력됩니다. 기본 구성은 64MB마다 로그를 순환하며 최대 2GB의 디스크 공간을 소비할 수 있습니다.

JEP 158(통합 JVM 로깅)에 설명된 명령줄 옵션을 사용하여 JVM 로깅을 재구성할 수 있습니다. 기본 jvm.options 파일을 직접 변경하지 않는 한, 사용자 설정과 함께 Elasticsearch 기본 구성이 적용됩니다. 기본 구성을 사용하지 않으려면 먼저 -Xlog:disable 옵션을 제공하여 로깅을 사용하지 않도록 설정한 다음 고유한 명령줄 옵션을 제공하세요. 이렇게 하면 모든 JVM 로깅이 비활성화되므로 사용 가능한 옵션을 검토하여 필요한 모든 옵션을 사용 설정해야 합니다.

원래 JEP에 포함되지 않은 추가 옵션을 보려면 JVM 통합 로깅 프레임워크로 로깅 활성화하기를 참조하세요.

Examples

몇 가지 샘플 옵션과 함께 $ES_HOME/config/jvm.options.d/gc.options를 생성하여 기본 GC 로그 출력 위치를 /opt/my-app/gc.log로 변경합니다:


# Turn off all previous logging configuratons
-Xlog:disable

# Default settings from JEP 158, but with `utctime` instead of `uptime` to match the next line
-Xlog:all=warning:stderr:utctime,level,tags

# Enable GC logging to a custom location with a variety of options
-Xlog:gc*,gc+age=trace,safepoint:file=/opt/my-app/gc.log:utctime,level,pid,tags:filecount=32,filesize=64m

GC 디버그 로그를 표준 오류(stderr)로 전송하도록 Elasticsearch Docker 컨테이너를 구성합니다. 이렇게 하면 컨테이너 오케스트레이터가 출력을 처리할 수 있습니다. ES_JAVA_OPTS 환경 변수를 사용하는 경우 지정하세요


MY_OPTS="-Xlog:disable -Xlog:all=warning:stderr:utctime,level,tags -Xlog:gc=debug:stderr:utctime"
docker run -e ES_JAVA_OPTS="$MY_OPTS" # etc

Temporary directory settings

기본적으로 Elasticsearch는 시작 스크립트가 시스템 임시 디렉터리 바로 아래에 생성하는 비공개 임시 디렉터리를 사용합니다.

일부 Linux 배포판에서는 시스템 유틸리티가 /tmp에서 최근에 액세스한 적이 없는 파일과 디렉터리를 정리합니다. 이 동작으로 인해 임시 디렉터리를 필요로 하는 기능을 오랫동안 사용하지 않는 경우 Elasticsearch가 실행되는 동안 개인 임시 디렉터리가 제거될 수 있습니다. 비공개 임시 디렉터리를 제거하면 나중에 이 디렉터리가 필요한 기능을 사용하는 경우 문제가 발생합니다.

.deb 또는 .rpm 패키지를 사용하여 Elasticsearch를 설치하고 systemd에서 실행하는 경우, Elasticsearch가 사용하는 전용 임시 디렉터리는 정기적인 정리에서 제외됩니다.

Linux 또는 MacOS에서 .tar.gz 배포를 장기간 실행하려는 경우, 이전 파일과 디렉터리를 정리할 경로 아래에 있지 않은 Elasticsearch 전용 임시 디렉터리를 생성하는 것이 좋습니다. 이 디렉터리에는 Elasticsearch를 실행하는 사용자만 액세스할 수 있도록 권한이 설정되어 있어야 합니다. 그런 다음 Elasticsearch를 시작하기 전에 $ES_TMPDIR 환경 변수가 이 디렉터리를 가리키도록 설정하세요.

Cluster backups

재해가 발생하면 스냅샷을 통해 영구적인 데이터 손실을 방지할 수 있습니다. 스냅샷 수명 주기 관리는 클러스터를 정기적으로 백업하는 가장 쉬운 방법입니다. 자세한 내용은 스냅샷 만들기를 참조하세요.

스냅샷 생성은 클러스터를 백업하는 안정적이고 지원되는 유일한 방법입니다. 노드의 데이터 디렉터리 사본을 만들어서 Elasticsearch 클러스터를 백업할 수는 없습니다. 파일 시스템 수준 백업에서 데이터를 복원하는 방법은 지원되지 않습니다. 이러한 백업에서 클러스터를 복원하려고 하면 파일 손상이나 누락 또는 기타 데이터 불일치에 대한 보고와 함께 실패하거나 일부 데이터가 조용히 손실된 채로 성공한 것처럼 보일 수 있습니다.

References::

Important Elasticsearch configuration | Elasticsearch Guide [8.14] | Elastic

Elasticsearch requires very little configuration to get started, but there are a number of items which must be considered before using your cluster in production:

https://www.elastic.co/guide/en/elasticsearch/reference/current/important-settings.html