1. _mapping API를 사용하여 필드 정보 검색하기

2. API를 사용하여 필드 값 표시_search

3. 매개 변수를 사용하여 필드 필터링 fields

4. 중첩된 필드 표시

1. 맵핑 API를 사용하여 필드 정보 검색하기

_mapping API를 사용하면 인덱스 또는 여러 인덱스에 대한 매핑 정의를 검색할 수 있습니다. 여기에는 필드, 데이터 유형 및 기타 속성에 대한 정보가 포함됩니다. 특정 인덱스에 대한 매핑을 검색하려면 다음 요청을 사용하세요:

예를 들어 my_index 이라는 인덱스가 있는 경우 다음 요청으로 해당 인덱스의 매핑을 검색할 수 있습니다:

응답에는 필드 및 해당 속성에 대한 정보가 포함된 인덱스에 대한 매핑 정의가 포함됩니다.

특정 필드에 대한 매핑을 검색할 수도 있습니다. 매핑이 상당히 크고 특정 필드에만 집중하려는 경우 유용할 수 있습니다. 특정 필드의 매핑을 검색하려면 다음 요청을 사용하세요:

다음 요청에서와 같이 쉼표로 이름을 구분하여 여러 필드의 매핑을 검색할 수도 있습니다:

2. search API를 사용하여 필드 값 표시하기

Elasticsearch 인덱스의 필드 값을 표시하려면 _search API를 사용하면 됩니다. 기본적으로 _search API는 색인된 원본 JSON 문서가 포함된 _source 필드를 반환합니다. 특정 필드만 표시하려면 검색 요청에 _source 매개변수를 사용하면 됩니다.

다음은 my_index 인덱스에 있는 문서에 대한 title 및 author 필드 값을 반환하는 검색 요청의 예입니다:

이 예제에서 _source 매개변수는 반환할 필드를 지정합니다.

3. fields 매개변수를 사용하여 필드 필터링하기

fields 매개변수를 사용하여 검색 응답에 반환되는 필드를 필터링할 수도 있습니다. 특정 필드만 필요하고 응답의 크기를 줄이려는 경우 유용할 수 있습니다. fields 매개변수는 필드 이름 또는 와일드카드 패턴의 배열을 허용합니다.

예를 들어 my_index 색인에 있는 문서에 대해 title 및 author 필드만 반환하려면 다음 검색 요청을 사용할 수 있습니다:

소스 문서를 반환하지 않으려면 _source 매개 변수를 false로 설정해야 합니다.

text 데이터 유형이 있는 모든 필드를 반환하려면 다음과 같은 와일드카드 패턴을 사용할 수 있습니다:

4. 중첩된 필드 표시

인덱스에 중첩 필드가 포함된 경우, 점 표기법을 사용하여 fields 매개변수에서 중첩 필드 경로를 지정할 수 있습니다. 예를 들어 address.city 이라는 이름의 중첩 필드가 있는 경우 다음과 같이 검색 응답에 포함할 수 있습니다:

이 예제에서는 검색 응답에 title, author, address.city 필드의 값이 포함됩니다.

결론

결론적으로, Elasticsearch 인덱스에서 필드를 표시하려면 _mapping API를 사용하여 필드 정보를 검색하고 _search API를 사용하여 필드 값을 표시할 수 있습니다. _source 또는 fields 매개변수를 사용하여 검색 응답에 반환된 필드를 필터링하고 점 표기법을 사용하여 중첩된 필드를 표시할 수 있습니다. 이러한 기술은 데이터의 구조를 이해하고, 특정 필드를 식별하고, 문제를 해결하는 데 도움이 될 수 있습니다.

워터마크의 배경

Elasticsearch 클러스터에는 사용 가능한 디스크 공간을 추적하는 데 도움이 되는 다양한 "워터마크" 임계값이 있습니다. 노드에서 디스크가 가득 차면 가장 먼저 통과해야 하는 임계값은 '디스크 부족 워터마크'입니다. 그러면 두 번째 임계값은 "높은 디스크 워터마크 임계값"이 됩니다. 마지막으로 '디스크 홍수 단계'에 도달하게 됩니다. 이 임계값을 통과하면 클러스터는 워터마크를 통과한 노드에 하나의 샤드(기본 또는 복제본)가 있는 모든 인덱스에 대한 쓰기를 차단합니다. 읽기(검색)는 계속 가능합니다.

디스크가 너무 꽉 찬 경우(사용량 초과)를 방지하고 처리하는 방법

Elasticsearch 디스크가 너무 꽉 찬 경우를 처리하는 방법에는 여러 가지가 있습니다:

1. 오래된 데이터를 삭제합니다 : 일반적으로 데이터는 무기한 보관해서는 안 됩니다. 디스크가 너무 꽉 차는 것을 방지하고 해결하는 한 가지 방법은 데이터가 특정 수명에 도달하면 안정적으로 보관 및 삭제되도록 하는 것입니다. 이를 위한 한 가지 방법은 ILM을 사용하는 것입니다.

2. 스토리지 용량을 추가합니다: 데이터를 삭제할 수 없는 경우, 성능에 부정적인 영향을 주지 않으면서 모든 데이터를 유지하기 위해 데이터 노드를 더 추가하거나 디스크 크기를 늘릴 수 있습니다. 클러스터에 스토리지 용량을 추가해야 하는 경우 스토리지 용량만 추가해야 하는지, 아니면 스토리지 용량과 RAM 및 CPU 리소스를 비례적으로 추가해야 하는지 고려해야 합니다(아래 디스크 크기, RAM 및 CPU 비율 섹션 참조).

Elasticsearch 클러스터에 스토리지 용량을 추가하는 방법

1. 데이터 노드 수를 늘립니다: 새 노드는 기존 노드와 크기가 같아야 하며 동일한 Elasticsearch 버전이어야 합니다.

2. 기존 노드의 크기를 늘립니다: 클라우드 기반 환경에서는 일반적으로 기존 노드에서 디스크 크기와 RAM/CPU를 쉽게 늘릴 수 있습니다.

3. 디스크 크기만 늘리기: 클라우드 기반 환경에서는 디스크 크기를 늘리는 것이 비교적 쉬운 경우가 많습니다.

4. 스냅샷 및 복원: 백업에서 자동화된 프로세스를 통해 요청 시 이전 데이터를 검색할 수 있도록 허용하려는 경우, 이전 인덱스를 스냅샷하고, 삭제하고, 스냅샷에서 요청 시 데이터를 임시로 복원할 수 있습니다. 

5. 샤드당 복제본 수 줄이기: 데이터를 줄이는 또 다른 옵션은 각 샤드의 복제본 수를 줄이는 것입니다. 고가용성을 위해서는 샤드당 하나의 복제본을 사용하는 것이 좋지만, 데이터가 오래되면 복제본 없이도 작업할 수 있습니다. 일반적으로 데이터가 영구적이거나 필요한 경우 복원할 백업이 있는 경우 이 방법을 사용할 수 있습니다.

6. 알림 만들기: 향후 디스크가 가득 차는 것을 방지하고 선제적으로 대응하려면 디스크 사용량에 따라 디스크가 가득 차기 시작할 때 알려주는 알림을 만들어야 합니다. 

디스크 용량이 제대로 활용되지 않는 경우를 방지하고 처리하는 방법

디스크 용량을 제대로 활용하지 못하는 경우 클러스터의 스토리지 볼륨을 줄일 수 있는 다양한 옵션이 있습니다.

Elasticsearch 클러스터의 스토리지 볼륨을 줄이는 방법

클러스터의 스토리지 용량을 줄이는 방법에는 여러 가지가 있습니다.

1. 데이터 노드 수 줄이기

데이터 저장 공간을 줄이면서 RAM과 CPU 리소스도 같은 비율로 줄이려면 이 방법이 가장 쉬운 전략입니다. 불필요한 노드를 폐기하면 비용을 가장 크게 절감할 수 있습니다.

노드를 폐기하기 전에 노드를 폐기해야 합니다:

• 해제할 노드가 마스터 노드로서 필요하지 않은지 확인합니다. 항상 마스터 노드 역할이 있는 노드가 3개 이상 있어야 합니다.

• 폐기할 노드에서 데이터 샤드를 마이그레이션합니다.

2. 기존 노드를 더 작은 노드로 교체

노드 수를 더 줄일 수 없는 경우(일반적으로 3개가 최소 구성) 기존 노드의 크기를 줄일 수 있습니다. 샤드는 노드당 샤드 수에 따라 균형을 맞추기 때문에 모든 데이터 노드의 RAM 메모리와 디스크 크기가 동일한지 확인하는 것이 좋습니다.

그 과정은 다음과 같습니다:

• 클러스터에 새롭고 작은 노드 추가하기

• 폐기할 노드에서 샤드를 멀리 마이그레이션합니다.

• 기존 노드 종료

3. 노드에서 디스크 크기 줄이기

클러스터의 전체 RAM이나 CPU를 변경하지 않고 노드의 디스크 크기만 줄이려는 경우 각 노드의 디스크 크기를 줄일 수 있습니다. Elasticsearch 노드에서 디스크 크기를 줄이는 것은 결코 간단한 과정이 아닙니다.

가장 쉬운 방법은 일반적으로 다음과 같이 하는 것입니다:

• 노드에서 샤드 마이그레이션

• 노드 중지

• 적절한 크기의 새 데이터 볼륨을 노드에 마운트합니다.

• 이전 디스크 볼륨의 모든 데이터를 새 볼륨으로 복사합니다.

• 이전 볼륨 A 분리

• 노드 시작 및 샤드를 다시 노드로 마이그레이션하기

이 과정에서 노드의 여분의 샤드를 임시로 저장할 수 있는 충분한 용량이 다른 노드에 있어야 합니다. 많은 경우, 이 프로세스를 관리하는 데 드는 비용이 디스크 사용량의 잠재적 절감 효과를 초과할 수 있습니다. 따라서 노드를 원하는 디스크 크기의 새 노드로 완전히 교체하는 것이 더 간단할 수 있습니다(위의 "기존 노드를 더 작은 노드로 교체하기" 참조).

불필요한 리소스에 대한 비용을 지불할 때 리소스 활용을 최적화하면 비용을 확실히 줄일 수 있습니다.

디스크 크기, RAM 및 CPU의 관계

클러스터의 디스크 용량과 RAM의 이상적인 비율은 특정 사용 사례에 따라 달라집니다. 따라서 스토리지 용량 변경을 고려할 때는 현재 디스크/RAM/CPU 비율이 적절하게 균형을 이루고 있는지, 결과적으로 RAM/CPU도 같은 비율로 추가/축소해야 하는지 여부도 고려해야 합니다.

RAM 및 CPU 요구 사항은 인덱싱 활동의 양, 쿼리의 수와 유형, 검색 및 집계되는 데이터의 양에 따라 달라집니다. 이는 클러스터에 저장되는 데이터의 양에 비례하는 경우가 많으므로 디스크 크기와도 관련이 있어야 합니다.

디스크 용량과 RAM의 비율은 사용 사례에 따라 변경될 수 있습니다. 여기에서 몇 가지 예를 확인하세요:

인덱스 활동

보존

검색 활동

디스크 용량

RAM

엔터프라이즈 검색 앱

중간 수준의 로그 수집

Long

빛

2TB

32GB

앱 모니터링

집중적인 로그 수집

짧은

빛

1TB

32GB

전자상거래

라이트 데이터 인덱싱

무기한

무거운

500GB

32GB

노드 머신의 구성을 수정하면 노드 다운타임이 발생할 수 있고 이미 과도하게 확장된 다른 노드로 샤드가 마이그레이션되지 않도록 해야 하므로 신중하게 수행해야 한다는 점을 기억하세요.

Elasticsearch에서 복제본의 역할

Elasticsearch에서 인덱스는 여러 기본 샤드에 걸쳐 분할된 문서의 모음입니다. 각 기본 샤드는 독립적인 Apache Lucene 인덱스이며, 인덱스 내의 문서는 모든 기본 샤드에 분산되어 있습니다. 고가용성과 데이터 이중화를 보장하기 위해 Elasticsearch는 각 샤드에 복제본이라고 하는 하나 이상의 복사본을 가질 수 있도록 합니다. number_of_replicas 설정은 인덱스의 각 기본 샤드에 대해 Elasticsearch가 생성하는 복제 샤드(복사본)의 수를 제어합니다. 기본적으로 Elasticsearch는 각 기본 샤드에 대해 하나의 복제본을 생성하지만 시스템의 요구 사항에 따라 변경할 수 있습니다.

수_오브_복제본 구성하기

number_of_replicas 설정은 인덱스 생성 시 구성하거나 나중에 업데이트할 수 있습니다. 인덱스 생성 중에 설정하는 방법은 다음과 같습니다:

이 예제에서 Elasticsearch는 my_index 인덱스의 각 기본 샤드에 대해 두 개의 복제본을 생성합니다.

기존 인덱스에 대한 number_of_replicas 설정을 업데이트하려면 _settings API를 사용하면 됩니다:

이 명령은 my_index 인덱스를 업데이트하여 각 기본 샤드에 대해 3개의 복제본을 갖도록 합니다.

number_of_replicas 설정의 의미

number_of_replicas 설정은 Elasticsearch 클러스터의 성능과 복원력에 상당한 영향을 미칩니다. 다음은 고려해야 할 몇 가지 핵심 사항입니다:

1. 데이터 중복성 및 가용성: number_of_replicas 을 늘리면 각 샤드의 복사본을 더 많이 생성하여 데이터의 가용성이 향상됩니다. 노드에 장애가 발생해도 Elasticsearch는 나머지 노드에 있는 복제본 샤드의 데이터를 계속 제공할 수 있습니다.

2. 검색 성능: 복제본 샤드는 읽기 요청을 처리할 수 있으므로 복제본이 많으면 더 많은 샤드에 부하를 분산하여 검색 성능을 향상시킬 수 있습니다.

3. 쓰기 성능: 그러나 각 쓰기 작업은 샤드의 모든 복사본에서 수행해야 합니다. 따라서 number_of_replicas 이 높을수록 각 쓰기마다 수행해야 하는 작업 수가 증가하므로 인덱싱 성능이 느려질 수 있습니다.

4. 스토리지 요구 사항: 복제본이 많을수록 더 많은 저장 공간이 필요합니다. 클러스터에 추가 복제본을 저장할 수 있는 충분한 용량이 있는지 확인해야 합니다.

5. 노드 장애에 대한 복원력: number_of_replicas 은 클러스터의 노드 수를 고려하여 설정해야 합니다. number_of_replicas 이 노드 수보다 크면 클러스터는 데이터 손실 없이 여러 노드의 장애를 견딜 수 있습니다.

number_of_replicas 설정 모범 사례

최적의 number_of_replicas 설정은 시스템의 특정 요구 사항에 따라 다릅니다. 그러나 다음은 몇 가지 일반적인 모범 사례입니다:

• 단일 노드 클러스터의 경우, 복제본을 보관할 다른 노드가 없으므로 number_of_replicas 을 0으로 설정해야 합니다.

• 멀티노드 클러스터의 경우 데이터 중복성과 고가용성을 보장하려면 number_of_replicas 을 최소 1로 설정해야 합니다.

• 검색 성능이 우선순위라면 number_of_replicas 을 늘리는 것이 좋습니다. 하지만 쓰기 성능 및 스토리지 요구 사항과의 절충점을 염두에 두어야 합니다.

• 항상 클러스터에 추가 복제본을 저장할 수 있는 충분한 용량이 있는지 확인하세요.

이 문서에서는 색인에서 필드를 제외하는 이유, 특정 필드를 제외하도록 Elasticsearch를 구성하는 방법, 그리고 그렇게 할 때 따라야 할 몇 가지 모범 사례에 대해 설명합니다.

인덱싱에서 필드를 제외하는 이유

1. 성능: 문서의 모든 필드를 색인하면 색인 시간이 길어지고 검색 성능이 저하될 수 있습니다. 검색이나 집계에 필요하지 않은 필드를 제외하면 Elasticsearch 클러스터의 전반적인 성능을 개선할 수 있습니다.

2. 저장소: 필드 인덱싱은 저장 공간을 소모합니다. 검색이나 집계에 필요하지 않은 필드를 제외하면 Elasticsearch 클러스터의 저장 공간 요구 사항을 줄이는 데 도움이 될 수 있습니다.

3. 인덱스 크기: Elasticsearch 인덱스의 크기는 색인되는 필드의 수와 직접적으로 관련이 있습니다. 불필요한 필드를 제외하면 색인 크기를 최소화할 수 있어 검색 및 색인 성능이 향상될 수 있습니다.

필드를 제외하도록 Elasticsearch 구성하기

Elasticsearch에서 필드를 색인되지 않도록 제외하려면 필드 매핑에서 "index" 속성을 사용하면 됩니다. "index" 속성을 "false"로 설정하면 Elasticsearch는 필드를 색인하지 않으며, 검색하거나 집계에 사용할 수 없게 됩니다.

다음은 Elasticsearch 매핑을 사용하여 필드를 색인에서 제외하는 방법의 예입니다:

이 예에서는 "field_to_exclude"라는 단일 필드를 사용하여 "my_index"라는 새 인덱스를 생성합니다. "index" 속성을 "false"로 설정하면, 이 필드를 색인하지 않도록 Elasticsearch에 지시하는 것입니다. 하지만 이 필드는 소스 문서에서 계속 사용할 수 있습니다.

인덱싱에서 필드를 제외하는 모범 사례

1. 데이터 분석하기: 인덱싱에서 필드를 제외하기 전에 데이터를 분석하고 검색 및 집계에 필요한 필드를 파악하는 것이 중요합니다. 이를 통해 제외할 필드에 대해 정보에 입각한 결정을 내릴 수 있습니다.

2. 변경 사항을 테스트합니다: 인덱싱에서 필드를 제외할 때는 변경 사항을 테스트하여 검색 및 집계 기능이 여전히 예상대로 작동하는지 확인하는 것이 중요합니다. 이렇게 하면 예기치 않은 문제나 성능 문제를 방지하는 데 도움이 됩니다.

3. 성능 모니터링: 색인에서 필드를 제외시킨 후, Elasticsearch 클러스터의 성능을 모니터링하여 변경 사항이 원하는 효과를 가져왔는지 확인합니다. 이를 통해 필요한 추가 최적화를 파악하는 데 도움이 될 수 있습니다.

4. 소스 필터링 사용: Elasticsearch에 필드를 저장해야 하지만 검색 가능하거나 집계에 사용할 수 없도록 하려면 소스 필터링을 사용하는 것을 고려하세요. 이렇게 하면 _source 필드에 필드를 저장하되 인덱스에서 제외할 수 있습니다.

결론

Elasticsearch에서 색인에서 필드를 제외하면 성능을 개선하고, 저장 비용을 절감하며, 전체 색인 크기를 최소화하는 데 도움이 될 수 있습니다. 데이터를 신중하게 분석하고 검색 및 집계에 필요한 필드를 이해하면 어떤 필드를 제외할지 정보에 입각한 결정을 내릴 수 있습니다. 항상 변경 사항을 테스트하고 Elasticsearch 클러스터의 성능을 모니터링하여 최적화가 원하는 효과를 가져오는지 확인하세요.

방법 1: 업데이트 API 사용

업데이트 API를 사용하면 문서의 소스를 수정하는 스크립트를 제공하여 문서를 업데이트할 수 있습니다. 이 API를 사용하면 필드를 null로 설정하여 문서에서 필드를 삭제하실 수 있습니다. 다음은 이 작업을 수행하는 방법에 대한 단계별 안내입니다.

1. 업데이트하려는 문서의 인덱스, 문서 유형(Elasticsearch 6.x 이하를 사용하는 경우), 문서 ID를 식별합니다.

2. 필드를 null로 설정하거나 더 나아가 소스 문서에서 필드를 제거하는 스크립트와 함께 업데이트 API를 사용합니다. 다음 예는 "my_index" 인덱스에서 ID가 "1"인 문서에서 "field_to_delete" 필드를 삭제하는 방법을 보여 줍니다:

3. 요청을 실행합니다. 성공하면 Elasticsearch는 문서가 업데이트되었음을 나타내는 응답을 반환합니다.

참고: 이 메서드는 지정된 문서에서 필드만 제거합니다. 이 필드는 인덱스의 매핑 및 기타 문서에 계속 존재합니다.

방법 2: 수정된 소스를 사용하여 재색인

인덱스의 모든 문서에서 필드를 삭제하려면, 재색인 API를 사용하여 수정된 소스로 새 인덱스를 생성하면 됩니다. 이를 수행하는 방법은 다음과 같습니다.

1. 원래 인덱스와 동일한 설정 및 매핑을 사용하여 새 인덱스를 만듭니다. 인덱스 가져오기 API를 사용하여 원본 인덱스의 설정과 매핑을 검색할 수 있습니다.

2. 재색인 API를 사용하여 원본 인덱스에서 새 인덱스로 문서를 복사하는 동시에 소스에서 필드를 제거합니다. 다음 예는 "my_index" 인덱스의 모든 문서에서 "field_to_delete" 필드를 삭제하는 방법을 보여 줍니다:

3. 새 인덱스에 필드가 제거된 올바른 문서가 포함되어 있는지 확인합니다.

4. 모든 것이 정상으로 보이면 원래 인덱스를 삭제하고 필요한 경우 원래 인덱스 이름의 별칭을 새 인덱스에 추가할 수 있습니다.

방법 3: 매핑을 업데이트하고 재색인

매핑에서 필드를 삭제하고 인덱스의 모든 문서를 삭제하려면 매핑을 업데이트한 다음 문서를 다시 색인하면 됩니다. 방법은 다음과 같습니다:

1. 원래 인덱스와 동일한 설정으로 새 인덱스를 만듭니다.

2. 매핑 가져오기 API를 사용하여 원본 인덱스의 매핑을 검색합니다.

3. 삭제하려는 필드를 제거하여 매핑을 수정합니다.

4. 매핑 넣기 API를 사용하여 수정된 매핑을 새 인덱스에 적용합니다.

5. 방법 2에 설명된 대로 재색인 API를 사용하여 원래 색인에서 새 색인으로 문서를 복사합니다.

6. 새 인덱스에 필드가 제거된 올바른 문서가 포함되어 있고 해당 필드가 매핑에 없는지 확인합니다.

7. 모든 것이 정상으로 보이면 원본 인덱스를 삭제할 수 있으며, 필요한 경우 새 인덱스에 원본 인덱스 이름의 별칭을 추가할 수 있습니다.

결론

이 문서에서는 업데이트 API 사용, 수정된 소스로 재색인, 매핑 업데이트 및 재색인이라는 세 가지 방법으로 Elasticsearch의 문서에서 필드를 삭제하는 방법에 대해 설명했습니다. 각 방법에는 고유한 사용 사례와 장단점이 있으므로 요구 사항에 가장 적합한 방법을 선택하세요. 변경 사항을 프로덕션 환경에 적용하기 전에 항상 테스트하고 결과를 확인하는 것을 잊지 마세요.

Elasticsearch의 점수 매기기

Elasticsearch는 기본적으로 BM25(실용적 채점 함수)라는 채점 모델을 사용합니다. 이 모델은 확률적 정보 검색 이론을 기반으로 하며 용어 빈도, 역 문서 빈도, 필드 길이 정규화 등의 요소를 고려합니다. 이러한 요소에 대해 간략히 살펴보겠습니다:

1. 용어 빈도(TF): 문서에서 용어가 나타나는 횟수를 나타냅니다. 용어 빈도가 높을수록 용어와 문서 간의 관계가 더 강하다는 것을 나타냅니다.

2. 역 문서 빈도(IDF): 이 요소는 전체 문서 컬렉션에서 한 용어의 중요도를 측정합니다. 많은 문서에 등장하는 용어는 덜 중요한 것으로 간주하고, 적은 문서에 등장하는 용어는 더 중요한 것으로 간주합니다.

3. 필드 길이 정규화: 이 요소는 용어가 표시되는 필드의 길이를 설명합니다. 짧은 필드에서는 용어가 더 중요한 것으로 간주되므로 짧은 필드에 더 많은 가중치가 부여됩니다.

설명 API 사용

Elasticsearch의 설명 API는 채점 프로세스를 이해하는 데 유용한 도구입니다. 특정 문서의 점수가 어떻게 계산되었는지에 대한 자세한 설명을 제공합니다. 설명 API를 사용하려면 다음 엔드포인트로 GET 요청을 보내야 합니다:

요청 본문에는 점수를 이해하고자 하는 쿼리를 입력해야 합니다. 다음은 한 가지 예입니다:

설명 API의 응답에는 개별 요소(TF, IDF 및 필드 길이 정규화)와 최종 점수에 대한 기여도를 포함하여 채점 프로세스에 대한 자세한 분석이 포함됩니다. 다음은 샘플 응답입니다:

이 예에서 응답은 점수 1.2가 IDF 값(2.2)과 tfNorm 값(0.5)의 곱이라는 것을 보여줍니다. 자세한 설명은 점수에 기여하는 요소를 이해하는 데 도움이 되며 검색 연관성을 미세 조정하는 데 유용할 수 있습니다.

결론

Elasticsearch 점수는 관련성 높은 검색 결과를 제공하는 데 있어 매우 중요한 요소입니다. 채점 메커니즘을 이해하고 설명 API를 사용하면 검색 결과에 영향을 미치는 요인에 대한 인사이트를 얻고 검색어를 최적화하여 관련성과 성능을 개선할 수 있습니다.

• 매핑 정의는 데이터 스키마를 지정합니다.

• 설정에서 샤드 크기와 새로 고침 빈도를 설정합니다. 

• 별칭은 인덱스에 대체 이름을 지정하는 데 사용됩니다.

문서를 처음 색인하거나 색인 생성 API를 사용하여 빈 색인을 만들면 데이터 스키마 및 별칭 없이 기본 설정으로 색인이 생성됩니다. 이러한 기본값은 개발 및 테스트 환경에서는 잘 작동하지만 프로덕션 환경에 맞게 인덱스를 사용자 지정해야 할 수도 있습니다.

프로덕션 환경에서 기본 매핑 및 설정으로 작업하면 색인 및 검색 성능이 저하될 수 있습니다. 인덱스를 수동으로 인스턴스화하는 작업은 지루하고 시간이 많이 걸리는 과정입니다. 정교한 매핑 스키마와 사용자 정의 설정 및 별칭이 있는 경우 모든 환경에서 이러한 인덱스를 다시 생성하는 것은 특히 비현실적입니다.

다행히도 Elasticsearch는 인덱스 템플릿형태로 인덱스를 생성할 때 미리 정의된 구성을 자동으로 적용할 수 있는 도구를 제공합니다.

색인 템플릿

인덱스 템플릿을 사용하면 사용자 정의 구성으로 인덱스를 만들 수 있습니다. 인덱스는 인스턴스화 중에 이러한 템플릿에서 설정된 수의 샤드 및 복제본 또는 필드 매핑과 같은 구성을 가져올 수 있습니다. 템플릿은 이름 패턴과 일부 구성으로 정의됩니다. 인덱스의 이름이 템플릿의 명명 패턴과 일치하면 템플릿에 정의된 구성으로 새 인덱스가 생성됩니다.

Elasticsearch는 버전 7.8에서 구성 가능한 템플릿으로 템플릿 기능을 업그레이드했습니다. 이 최신 버전은 이 문서에서 설명한 대로 훨씬 더 많은 재사용 가능한 인덱스 템플릿을 제공합니다.

인덱스 템플릿의 종류

색인 템플릿은 두 가지 범주로 분류할 수 있습니다:

• 색인 템플릿(또는 컴포저블 색인 템플릿): 구성 가능한 인덱스 템플릿은 단독으로 존재하거나 하나 이상의 구성 요소 템플릿으로 구성될 수 있습니다(두 번째 범주 참조).

• 컴포넌트 템플릿: 컴포넌트 템플릿은 필요한 구성을 정의하는 자체적으로 재사용 가능한 템플릿입니다. 일반적으로 컴포넌트 템플릿은 인덱스 템플릿과 연결될 것으로 예상됩니다. 각 컴포넌트 템플릿에는 하나 또는 여러 개의 인덱스 템플릿을 첨부할 수 있습니다. 

아래 이미지에서 볼 수 있듯이 인덱스 템플릿 A와 B는 서로 구성 요소 템플릿(이 경우 템플릿 3 하나만)을 공유합니다. 인덱스 템플릿은 하나 또는 여러 개의 구성 요소 템플릿으로 구성될 수 있으며, 각 구성 요소 템플릿은 하나 또는 여러 개의 인덱스 템플릿과 연결될 수 있습니다. 두 가지 유형의 템플릿은 모두 단독으로 존재할 수 있지만 컴포넌트 템플릿은 인덱스 템플릿에 첨부하지 않으면 아무 소용이 없습니다.

일반적인 아이디어는 조직이 다양한 필요에 따라 사용할 수 있도록 구성 요소 템플릿 카탈로그를 개발하고(예: 개별 환경에 맞는 다양한 구성 요소 템플릿 지정), 구성 가능한 인덱스 템플릿을 통해 다양한 인덱스에 이를 첨부하는 것입니다.

작성 가능한(색인) 템플릿을 만드는 방법

Elasticsearch는 인덱스 템플릿을 관리하기 위한 _index_template 엔드포인트를 제공합니다. 사용자는 이 템플릿에서 인덱스 이름 패턴과 함께 필요한 모든 매핑, 설정 및 별칭을 제공합니다. 주문 생성 로직을 담당하는 마이크로서비스 애플리케이션 고객 주문 서비스에 대한 템플릿을 만드는 예제를 살펴보겠습니다. 

와일드카드가 있는 패턴으로 표시되는 고객 주문에 대한 템플릿을 만들어야 한다고 가정해 보겠습니다: *orders. 이 템플릿에는 주문_날짜 필드, 샤드 및 복제본 번호와 같은 특정 매핑 및 설정이 있을 것으로 예상됩니다.

인덱스를 생성하는 동안 이 템플릿과 일치하는 모든 인덱스는 이 템플릿에 정의된 구성을 상속합니다. 예를 들어 검은_금요일_주문 인덱스에는 order_date 필드가 있고, 샤드는 5로 설정되며 복제본은 2로 설정됩니다. 이 외에도 이 템플릿에서 생성된 모든 인덱스는 단일 별칭 이름을 상속받습니다! 주문으로 정의된 인덱스 패턴과 미리 정의된 날짜 형식 dd-MM-yyyy를 가진 단일 oder_date 필드로 구성된 매핑 스키마를 사용하여 이 orders_template을 만들어 보겠습니다. 아래 코드는 이 인덱스 템플릿을 만드는 방법을 보여줍니다.

Kibana의 개발자 도구에서 이 쿼리를 실행하면 미리 정의된 매핑, 설정 및 별칭과 함께 *orders 인덱스 패턴으로 템플릿이 생성됩니다. index_patterns는 일치 패턴의 배열로, 이 패턴과 일치하는 인덱스는 템플릿 구성을 도출합니다. 다음을 실행하여 우리가 수행한 작업을 반복해야 하는 지속된 템플릿을 검색할 수 있습니다:

템플릿에 정의된 템플릿 속성을 만들 때 양수인 우선순위를 정의할 수도 있습니다. 모든 템플릿에는 우선순위가 정의되어 있으므로 다른 템플릿에서 충돌하는 변경 사항이 있을 경우 우선순위가 높은 값을 우선하여 이 값을 사용하여 해결됩니다. 아래에서 템플릿 우선 순위에 대해 자세히 알아보겠습니다.

템플릿으로 색인 만들기

이제 인덱스를 만들기 위한 청사진인 템플릿이 생겼으니 다음 단계는 인덱스를 만드는 것입니다. 인덱스 이름이 지정된 패턴과 일치하면 템플릿 구성이 자동으로 적용됩니다. 이를 증명하기 위해 아래 코드에서 볼 수 있듯이 검은 금요일_주문이라는 새로운 인덱스를 만들어 보겠습니다:

인덱스 이름(blackfriday_orders)이 템플릿에 정의된 명명 패턴과 일치하므로(예를 들어 *주문), 인덱스는 템플릿에서 파생된 모든 구성을 가져와야 합니다. 새로 생성된 인덱스를 검색하고 다음 코드를 실행하여 이것이 실제로 사실인지 확인해 보겠습니다:

반환됩니다:

응답에서 알 수 있듯이 검은 금요일 주문의 구성은 템플릿에서 상속되었습니다. 템플릿 구성을 성공적으로 상속할 수 있는 다양한 인덱스 조합을 시도해 볼 수 있습니다:

그러나 다음 인덱스는 이름이 패턴과 일치하지 않으므로 구성을 상속하지 않습니다:

기억해야 할 한 가지 중요한 점은 템플릿에서 파생된 모든 인덱스는 동일한 별칭(이 경우 all_orders)을 사용한다는 것입니다. 이러한 별칭을 사용하면 여러 인덱스가 아닌 이 단일 별칭으로 간단히 쿼리할 수 있다는 이점이 있습니다.

주문에 대한 템플릿을 생성하는 동안 일치하는 인덱스는 모두 템플릿 구성을 채택할 것으로 예상됩니다. 일반적으로 팀에서는 자의든 타의든 여러 가지 이유로 템플릿을 몇 개 더 만들 수 있습니다. 즉, 인덱스 이름이 두 개의 다른 템플릿 패턴과 일치하는 경우가 있습니다! Elasticsearch는 이러한 템플릿에서 어떤 구성을 적용해야 할지 결정해야 합니다. 다행히도 템플릿 우선순위를 사용하면 이 딜레마를 해결할 수 있습니다.

구성 요소 템플릿을 생성하는 방법

이 글의 앞부분에서 인덱스 템플릿에 대해 알아보았습니다. 구성이 내장된 템플릿을 만들면 몇 가지 단점이 있는데, 그 중 하나는 다른 템플릿으로 구성을 내보낼 수 없다는 점입니다. 고객 관련 템플릿(*고객)과 같이 유사한 구성을 원할 경우 전체 템플릿을 다시 만들어야 할 수도 있습니다. 즉, 일반적인 조직에서는 수십 개를 만들 수 있습니다(환경에 따라 몇 개 더 만들 수도 있습니다).

항상 재사용 가능성을 염두에 두고 템플릿을 재설계하기 때문에 Elasticsearch는 재사용 가능성을 염두에 두고 템플릿을 재설계했습니다. 컴포넌트 템플릿이 이에 적합합니다. DevOps 출신이라면 각 환경에 대해 미리 설정된 구성으로 인덱스를 만들어야 하는 요구 사항이 있을 것입니다. 이러한 각 구성을 수동으로 적용하는 번거로움 대신 각 환경에 대한 컴포넌트 템플릿을 만들 수 있습니다.

구성 요소 템플릿은 더 많은 인덱스 템플릿을 구성하는 데 사용할 수 있는 재사용 가능한 구성 블록에 불과합니다. 컴포넌트 템플릿은 인덱스 템플릿과 클럽화하지 않으면 아무런 가치가 없습니다. 구성 요소 템플릿 엔드포인트를 통해 노출됩니다. 이 모든 것이 어떻게 결합되는지 살펴봅시다.

인덱스 템플릿의 설정

앞서 인덱스 템플릿에서 정의한 설정을 추출하여 컴포넌트 템플릿을 만들어 보겠습니다. 설정_컴포넌트_템플릿에는 기본 샤드당 2개의 복제본이 있는 5개의 기본 샤드가 있어야 합니다. 아래 코드 목록에서 볼 수 있듯이 첫 번째 단계는 이 구성으로 컴포넌트 템플릿을 선언하고 실행하는 것입니다.

위의 코드에서 볼 수 있듯이 _component_template 엔드포인트를 사용하여 컴포넌트 템플릿을 생성합니다. 요청 본문에는 템플릿 객체에 템플릿 정보가 들어 있습니다. 이제 색인 템플릿의 다른 곳에서 settings_component_template을 사용할 수 있습니다. 한 가지 주목할 만한 차이점은 이 템플릿은 인덱스 패턴을 정의하지 않고 일부 속성을 구성하는 코드 블록에 불과하다는 점입니다.

매핑 템플릿

같은 방법으로 다른 템플릿을 만들어 보겠습니다. 이번에는 앞서 독립형 인덱스 템플릿에서 정의했던 매핑 스키마를 추출해 보겠습니다. 아래 코드는 스크립트를 보여줍니다:

별칭 템플릿

동일한 흐름에 따라 별칭이 있는 컴포넌트 템플릿(두 개의 별칭(all_orders 및 sales_orders))을 가질 수도 있습니다:

작성 가능한 색인 템플릿

이제 세 가지 컴포넌트 템플릿을 준비했으니 다음 단계는 이를 사용하는 것입니다. 예를 들어 christmas_orders에 대한 인덱스 템플릿을 사용하도록 허용하면 이 작업을 수행할 수 있습니다:

composed_of 태그는 이 템플릿을 구성하는 모든 컴포넌트 템플릿의 모음입니다. 이 경우 설정, 매핑 및 별칭 컴포넌트 템플릿을 선택합니다. 또한 이 템플릿이 다른 템플릿보다 우선하도록 우선순위를 높이고 있습니다. 템플릿이 준비되면 *주문 패턴과 일치하는 모든 인덱스는 이 세 가지 구성 요소 템플릿의 구성을 상속받게 됩니다.

하지만 고객과 같은 새 템플릿을 만들려면 기존 템플릿(settings_component_template)과 새로 만든 별칭(aliases_component_template - 아래 참조) 템플릿 중 하나만 사용하여 만들 수 있습니다:

인덱스 템플릿은 다음과 같습니다:

설정_컴포넌트_템플릿이 두 개의 다른 템플릿에서 (재)사용된 것을 보셨나요? 이것이 바로 컴포넌트 템플릿의 힘입니다.

인덱스 템플릿 우선순위

개발자가 기존 종목을 보지 않고 여러 개의 인덱스 템플릿을 만들 수 있습니다. 이러한 템플릿 각각에 우선순위를 설정하여 우선순위가 높은 템플릿이 사용되도록 하는 것이 중요합니다. 예를 들어, 다음 코드 스니펫에서 my_orders_template_1이 my_orders_template_2를 재정의합니다:

생성 중인 인덱스와 일치하는 템플릿이 여러 개 있는 경우, Elasticsearch는 일치하는 모든 템플릿의 모든 구성을 적용하지만 우선순위가 더 높은 모든 구성을 재정의합니다.

템플릿의 우선 순위

마지막으로 템플릿의 우선순위에 대해 궁금하실 텐데요, 구성 요소 템플릿에 정의된 구성이 기본 인덱스 템플릿 자체에 정의된 구성보다 우선하나요? 아니면 그 반대일까요? 몇 가지 규칙이 있습니다:

• 즉, 명시적으로 구성하여 만든 인덱스는 모든 항목보다 우선합니다. 즉, 명시적으로 구성하여 인덱스를 만들면 템플릿에 의해 재정의되지 않을 것으로 기대하지 마세요.

• 레거시 템플릿(버전 7.8 이전에 만든 템플릿)은 작성 가능한 템플릿보다 우선 순위가 낮습니다.

요약

• 인덱스에는 매핑, 설정 및 별칭이 포함됩니다. 매핑은 필드 스키마를 정의하고, 설정은 샤드 및 복제본 수와 같은 인덱스 파라미터를 설정하며, 별칭은 인덱스에 대체 이름을 부여합니다.

• 템플릿을 사용하면 미리 정의된 구성으로 인덱스를 만들 수 있습니다. 특정 템플릿에 정의된 인덱스 패턴과 일치하는 이름으로 인덱스 이름을 지정하면 템플릿에 따라 해당 인덱스가 자동으로 구성됩니다.

• Elasticsearch는 버전 7.8에서 구성 가능한 인덱스 템플릿을 도입했습니다. 구성 가능한 인덱스 템플릿을 사용하면 템플릿을 모듈화하고 버전을 관리할 수 있습니다.

• 컴포저블 템플릿은 하나 이상의 컴포넌트 템플릿으로 구성됩니다.

• 인덱스 템플릿에는 자체 구성도 정의할 수 있습니다.

• 컴포넌트 템플릿은 작성 가능한 인덱스 템플릿과 마찬가지로 미리 정의된 구성이 있는 재사용 가능한 템플릿입니다.

• 그러나 구성 요소 템플릿은 인덱스 템플릿의 일부가 되어야 하며, 인덱스 템플릿으로 '구성'되지 않으면 쓸모가 없습니다.

• 구성 요소 템플릿에는 인덱스 패턴이 정의되어 있지 않으므로 인덱스 템플릿의 일부가 될 것으로 '예상'되는 또 다른 이유입니다.

• 각 템플릿에는 양수인 우선순위가 있습니다. 숫자가 높을수록 해당 템플릿이 적용되는 우선 순위가 높아집니다.

두 개의 필드로 검색을 수행하는 고급 기술

1. 멀티매치 쿼리

다중 일치 쿼리를 사용하면 여러 필드에서 단일 쿼리 문자열을 검색할 수 있습니다. 이 기능은 두 필드 중 하나에 지정된 쿼리 문자열이 포함된 문서를 찾으려는 경우에 유용합니다. 다음은 '제목' 또는 '설명' 필드에서 'example'라는 용어를 검색하는 다중 검색 쿼리의 예입니다:

2. 부울 쿼리

부울 쿼리를 사용하면 부울 논리를 사용하여 여러 쿼리를 결합할 수 있습니다. "should" 절을 사용하여 두 필드 중 하나에서 쿼리와 일치하는 문서를 검색할 수 있습니다. 다음은 'title' 및 'description' 필드에서 'example'라는 용어를 검색하는 부울 쿼리의 예입니다:

3. 쿼리 시간 필드 부스팅

때로는 검색 중에 한 필드를 다른 필드보다 더 중요하게 생각하고 싶을 수도 있습니다. 쿼리 시점에 필드에 부스트 인자를 적용하여 이를 달성할 수 있습니다. 부스트 값이 높을수록 해당 필드에 더 많은 가중치가 부여되므로 최종 검색 점수에 영향을 미칠 가능성이 높아집니다. 다음은 'title' 필드에 부스트 팩터가 적용된 멀티매치 쿼리의 예입니다:

이 예에서 '제목' 필드의 부스트 계수는 3으로, 검색 점수를 결정하는 데 있어 '설명' 필드보다 3배 더 중요합니다.

4. 다양한 부스트 인자를 가진 쿼리 결합

부울 쿼리를 사용하여 서로 다른 부스트 인자를 가진 여러 쿼리를 결합할 수도 있습니다. 이를 통해 검색 결과에서 각 필드의 중요도를 미세 조정할 수 있습니다. 다음은 'title' 및 'description' 필드에 서로 다른 부스트 인자를 적용한 부울 쿼리의 예입니다:

이 예에서 '제목' 필드의 부스트 계수는 3이고 '설명' 필드의 부스트 계수는 1입니다.

결론

다중 일치 쿼리, 부울 쿼리, 쿼리 시간 필드 부스팅과 같은 고급 기술을 사용하여 Elasticsearch에서 두 필드를 기준으로 검색할 수 있습니다. 이러한 기술을 결합하면 사용자에게 더 정확하고 관련성 높은 검색 결과를 제공할 수 있습니다. 다양한 쿼리 조합과 부스트 인자를 실험하여 특정 사용 사례에 맞는 최적의 검색 구성을 찾아보세요.

버전 7.11부터 Elasticsearch는 기본적으로 노드의 역할과 총 메모리를 기반으로 JVM 힙 크기를 자동으로 설정합니다. 대부분의 프로덕션 환경에서는 기본 사이징을 사용하는 것이 좋습니다. 그러나 JVM 힙 크기를 수동으로 설정하려면 일반적으로 -Xms 및 -Xmx를 동일한 값으로 설정해야 하며, 최대 (대략) 31GB를 기준으로 총 사용 가능한 RAM의 50% 이 되어야 합니다.

힙 크기가 클수록 노드에 인덱싱 및 검색 작업을 위한 더 많은 메모리를 확보할 수 있습니다. 그러나 노드에는 캐싱을 위한 메모리도 필요하므로 50% 을 사용하면 둘 사이의 균형이 잘 유지됩니다. 프로덕션 환경에서도 이와 같은 이유로 Elasticsearch와 동일한 노드에서 다른 메모리 집약적인 프로세스를 사용하지 않아야 합니다.

일반적으로 힙 사용량은 톱니 모양 패턴을 따르며, 사용 중인 최대 힙의 약 30~70%(% ) 사이에서 진동합니다. 이는 가비지 수집 프로세스가 메모리를 다시 확보할 때까지 JVM이 힙 사용률을 꾸준히 증가시키기 때문입니다. 높은 힙 사용량은 가비지 수집 프로세스가 따라잡지 못할 때 발생합니다. 힙 사용량이 많다는 지표는 가비지 컬렉션이 힙 사용량을 약 30개% 로 줄일 수 없는 경우입니다.

위 이미지에서 JVM 힙의 일반적인 톱니 모양을 볼 수 있습니다.

또한 가비지 컬렉션에는 젊은 가비지 컬렉션과 오래된 가비지 컬렉션의 두 가지 유형이 있음을 알 수 있습니다.

정상적인 JVM에서 가비지 컬렉션은 다음 조건을 이상적으로 충족해야 합니다:

• 젊은 GC는 빠르게 처리됩니다(50ms 이내).

• 젊은 GC는 자주 실행되지 않습니다(약 10초).

• 이전 GC는 빠르게 처리됩니다(1초 이내).

• 이전 GC는 자주 실행되지 않습니다(10분에 한 번 이상).

힙 메모리 사용량이 너무 많거나 JVM 성능이 최적이 아닌 경우 해결하는 방법

힙 메모리 사용량이 증가하는 데에는 여러 가지 이유가 있을 수 있습니다:

오버하딩

오버하딩에 대한 문서는 여기를 참조하세요.

대규모 집계 크기

집계 크기가 커지는 것을 방지하려면 쿼리의 집계 버킷 수(크기)를 최소한으로 유지하세요.

느린 쿼리 로깅(느린 로그)을 사용하고 다음을 사용하여 특정 인덱스에 구현할 수 있습니다.

결과를 반환하는 데 시간이 오래 걸리는 쿼리는 리소스 집약적인 쿼리일 가능성이 높습니다.

과도한 벌크 인덱스 크기

대량의 요청을 전송하는 경우 힙 사용량이 많은 원인이 될 수 있습니다. 대량 인덱스 요청의 크기를 줄이세요.

매핑 문제

특히 "fielddata: true"를 사용하는 경우, 이는 JVM 힙의 주요 사용자가 될 수 있습니다.

힙 크기가 잘못 설정됨

힙 크기는 수동으로 정의할 수 있습니다:

환경 변수 설정하기:

Elasticsearch 구성 디렉터리에서 jvm.options 파일을 편집합니다:

환경 변수 설정은 파일 설정보다 우선합니다.

설정을 적용하려면 노드를 다시 시작해야 합니다.

JVM 새 비율이 잘못 설정됨

Elasticsearch는 기본적으로 이 값을 설정하므로 일반적으로 이 값을 설정할 필요가 없습니다. 이 매개변수는 JVM에서 "신세대" 및 "구세대" 오브젝트에 사용할 수 있는 공간의 비율을 정의합니다.

오래된 GC가 매우 자주 발생하는 경우, Elasticsearch 구성 디렉터리의 jvm.options 파일에서 이 값을 구체적으로 설정해 볼 수 있습니다.

대규모 Elasticsearch 클러스터에서 힙 크기 사용량과 JVM 가비지 수집을 관리하기 위한 모범 사례는 무엇인가요?

대규모 Elasticsearch 클러스터에서 힙 크기 사용량과 JVM 가비지 수집을 관리하기 위한 모범 사례는 힙 크기를 사용 가능한 RAM의 최대 50% 로 설정하고 JVM 가비지 수집 설정이 특정 사용 사례에 최적화되도록 하는 것입니다. 클러스터가 최적으로 실행되고 있는지 확인하기 위해 힙 크기와 가비지 수집 메트릭을 모니터링하는 것이 중요합니다. 특히 JVM 힙 크기, 가비지 수집 시간, 가비지 수집 일시 중지를 모니터링하는 것이 중요합니다. 또한 쓰레기 수거 횟수와 쓰레기 수거에 소요되는 시간을 모니터링하는 것도 중요합니다. 이러한 메트릭을 모니터링하면 힙 크기나 가비지 수집 설정에 잠재적인 문제가 있는지 파악하고 필요한 경우 수정 조치를 취할 수 있습니다.

split API는 _reindex API보다 더 빠른 방법인 경우가 많습니다. 두 작업 전에 인덱싱을 중지해야 하며, 그렇지 않으면 source_index와 target_index 문서 수가 달라집니다.

방법 1 - 분할 API 사용

분할 API는 설정을 복사하고 기존 인덱스를 매핑하여 원하는 기본 샤드 수로 새 인덱스를 생성하는 데 사용됩니다. 생성 시 원하는 기본 샤드 수를 설정할 수 있습니다. 분할 API를 구현하기 전에 다음 설정을 확인해야 합니다:

1. 소스 인덱스는 읽기 전용이어야 합니다. 즉, 인덱싱 프로세스를 중지해야 합니다.

2. 대상 인덱스의 기본 샤드 수는 소스 인덱스의 기본 샤드 수의 배수여야 합니다. 예를 들어, 소스 인덱스에 기본 샤드가 5개인 경우, 대상 인덱스 기본 샤드를 10,15,20 등으로 설정할 수 있습니다.

참고: 기본 샤드 번호만 변경해야 하는 경우, 재인덱스 API보다 훨씬 빠른 분할 API를 사용하는 것이 좋습니다.

분할 API 구현하기

테스트 인덱스를 만듭니다:

소스 인덱스는 읽기 전용이어야 분할할 수 있습니다:

설정 및 매핑은 소스 인덱스에서 자동으로 복사됩니다:

진행 상황을 확인할 수 있습니다:

설정과 매핑은 소스 인덱스에서 복사되므로 대상 인덱스는 읽기 전용입니다. 대상 인덱스에 대한 쓰기 작업을 활성화해 보겠습니다:

원본 인덱스를 삭제하기 전에 소스 및 대상 인덱스 docs.count를 확인하세요:

인덱스 이름과 별칭 이름은 같을 수 없습니다. 소스 인덱스를 삭제하고 소스 인덱스 이름을 대상 인덱스에 별칭으로 추가해야 합니다:

test_split_source 별칭을 test_split_target 인덱스에 추가한 후 이를 테스트해야 합니다:

방법 2 - 재인덱스 API 사용

리인덱스 API로 새 인덱스를 생성하면 기본 샤드 개수를 얼마든지 지정할 수 있습니다. 원하는 수의 기본 샤드로 새 인덱스를 생성한 후, 소스 인덱스의 모든 데이터를 이 새 인덱스로 다시 색인할 수 있습니다.

분할 API 기능 외에도, 재인덱스 AP의 ingest_pipeline을 사용하여 데이터를 조작할 수 있습니다. 수집 파이프라인을 사용하면 필터에 맞는 지정된 필드만 쿼리를 사용하여 대상 인덱스로 색인됩니다. 간편한 스크립트를 사용하여 데이터 콘텐츠를 변경할 수 있으며, 여러 인덱스를 단일 인덱스로 병합할 수 있습니다.

재색인 API 구현하기

테스트 재인덱스를 만듭니다:

소스 인덱스에서 설정 및 매핑을 복사합니다:

설정, 매핑, 원하는 샤드 수로 대상 인덱스를 생성합니다:

*주: number_of_replicas: 0, refresh_interval: -1로 설정하면 재인덱싱 속도가 빨라집니다.

재색인 프로세스를 시작합니다. requests_per_second=-1 및 slices=auto를 설정하면 재인덱스 속도가 조정됩니다.

재인덱스 API를 실행하면 task_id를 볼 수 있습니다. 이를 복사하여 _tasks API로 확인합니다:

재색인 작업이 완료된 후 설정을 업데이트합니다:

원본 인덱스를 삭제하기 전에 소스 인덱스와 대상 인덱스 docs.count를 확인하면 동일해야 합니다:

인덱스 이름과 별칭 이름은 같을 수 없습니다. 소스 인덱스를 삭제하고 소스 인덱스 이름을 대상 인덱스에 별칭으로 추가합니다:

test_split_source 별칭을 test_split_target 인덱스에 추가한 후 다음을 사용하여 테스트합니다:

요약

기존 인덱스의 기본 샤드 수를 늘리려면 새 인덱스에 대한 설정과 매핑을 다시 만들어야 합니다. 이를 위한 두 가지 주요 방법은 재색인 API와 분할 API입니다. 두 방법 중 하나를 사용하기 전에 활성 인덱싱을 중지해야 합니다.

이 접근 방식의 단점은 하드웨어를 일부 복제해야 하고 모든 데이터를 원활하게 전송하고 동기화하려고 할 때 문제가 발생할 수 있다는 점입니다.

한 데이터 센터에서 다른 데이터 센터로 애플리케이션을 마이그레이션해야 하는 경우에도 유사한 절차를 수행해야 할 수 있습니다.

이 문서에서는 Elasticsearch 클러스터 간에 데이터를 전송하는 세 가지 방법에 대해 자세히 설명합니다.

Elasticsearch 클러스터 간에 데이터를 마이그레이션하는 방법은 무엇인가요?

Elasticsearch 클러스터 간에 데이터를 전송하는 방법에는 3가지가 있습니다:

1. 원격 클러스터에서 재색인

2. 스냅샷을 사용하여 데이터 전송

3. Logstash를 사용하여 데이터 전송

일반적으로 스냅샷을 사용하는 것이 데이터를 전송하는 가장 빠르고 안정적인 방법입니다. 그러나 스냅샷은 동일하거나 상위 버전의 클러스터로만 복원할 수 있으며, 주 버전과 차이가 한 개 이상 나는 경우에는 복원할 수 없습니다. 즉, 6.x 스냅샷을 7.x 클러스터로 복원할 수는 있지만 8.x 클러스터로 복원할 수는 없습니다.

하나 이상의 주요 버전으로 늘려야 하는 경우, 색인을 다시 생성하거나 Logstash를 사용해야 합니다.

이제 Elasticsearch 클러스터 간에 데이터를 전송하는 세 가지 옵션 각각에 대해 자세히 살펴보겠습니다.

1. 원격 클러스터에서 데이터 재색인하기

재색인을 시작하기 전에 새 클러스터의 모든 인덱스에 대해 적절한 매핑을 설정해야 한다는 점을 기억하세요. 이렇게 하려면 적절한 매핑을 사용하여 직접 인덱스를 만들거나 인덱스 템플릿을 사용해야 합니다.

원격에서 재색인 - 구성 필요

원격에서 재색인하려면 데이터를 수신하는 클러스터의 elasticseearch.yml 파일에 아래 구성을 추가해야 하며, Linux 시스템에서는 일반적으로 여기에 위치합니다: /etc/elasticsearch/elasticsearch.yml. 추가할 구성은 다음과 같습니다:

SSL을 사용하는 경우, 각 노드에 CA 인증서를 추가하고 elasticsearch.yml의 각 노드에 대한 명령에 다음을 포함해야 합니다:

또는 모든 Elasticsearch 노드에 아래 줄을 추가하여 SSL 확인을 사용하지 않도록 설정할 수 있습니다. 그러나 이 방법은 이전 옵션만큼 안전하지 않으므로 권장하지 않습니다:

모든 노드에서 이러한 수정 사항을 적용하고 롤링 재시작을 수행해야 합니다. 방법에 대한 자세한 내용은 가이드를 참조하세요.

재색인 명령

elasticsearch.yml 파일에서 원격 호스트를 정의하고 필요한 경우 SSL 인증서를 추가한 후, 아래 명령으로 데이터 재색인을 시작할 수 있습니다:

이 과정에서 시간 초과 오류가 발생할 수 있으므로 기본값에 의존하기보다는 시간 초과에 대한 넉넉한 값을 설정하는 것이 유용할 수 있습니다.

이제 원격에서 재색인할 때 발생할 수 있는 몇 가지 일반적인 오류를 살펴보겠습니다.

원격에서 재색인할 때 흔히 발생하는 오류

1. 화이트리스트에 등재되지 않은 재인덱싱

이 오류가 발생하면 위에서 설명한 대로 Elasticsearch에서 원격 호스트 IP 주소 또는 노드 이름 DNS를 정의하지 않았거나 Elasticsearch 서비스를 다시 시작하는 것을 잊었다는 뜻입니다.

Elasticsearch 클러스터에 대해 이 문제를 해결하려면 모든 Elasticsearch 노드에 원격 호스트를 추가하고 Elasticsearch 서비스를 다시 시작해야 합니다.

2. SSL 핸드셰이크 예외

이 오류는 위에서 설명한 대로 elasticsearch.yml에 reindex.ssl.certificate_authorities를 추가하는 것을 잊었음을 의미합니다. 추가하려면:

2. 스냅샷을 사용하여 데이터 전송

위에서 언급했듯이 스냅샷은 동일하거나 상위 버전의 클러스터로만 복원할 수 있으며, 주요 버전이 하나 이상 차이 나는 경우에는 절대로 복원할 수 없습니다.

하나 이상의 주요 버전으로 늘려야 하는 경우, 색인을 다시 생성하거나 Logstash를 사용해야 합니다.

스냅샷을 통해 데이터를 전송하려면 다음 단계가 필요합니다:

1단계. 첫 번째 Elasticsearch 클러스터에 리포지토리 플러그인 추가 - 스냅샷을 통해 클러스터 간에 데이터를 전송하려면 새 클러스터와 이전 클러스터 모두에서 리포지토리에 액세스할 수 있는지 확인해야 합니다. 일반적으로 AWS, Google, Azure와 같은 클라우드 스토리지 리포지토리가 가장 이상적입니다. 스냅샷을 찍으려면 가이드를 참조하여 설명된 단계를 따르세요.

2단계. Elasticsearch 서비스를 다시 시작합니다(롤링 재시작).

3단계. 첫 번째 Elasticsearch 클러스터를 위한 리포지토리를 생성합니다.

4단계- 두 번째 Elasticsearch 클러스터에 리포지토리 플러그인을 추가합니다.

5단계- 두 번째 Elasticsearch 클러스터에 리포지토리를 읽기 전용으로 추가하기 - 첫 번째 Elasticsearch 클러스터를 생성할 때와 동일한 단계를 반복하여 리포지토리를 추가해야 합니다.

중요 참고: 두 번째 Elasticsearch 클러스터를 동일한 AWS S3 리포지토리에 연결할 때는 리포지토리를 읽기 전용 리포지토리로 정의해야 합니다:

이는 동일한 스냅샷 리포지토리 내에서 Elasticsearch 버전이 혼합되는 위험을 방지하고자 하기 때문에 중요합니다.

6단계- 두 번째 Elasticsearch 클러스터로 데이터 복원 - 위의 단계를 수행한 후 데이터를 복원하여 새 클러스터로 전송할 수 있습니다. 이 문서에 설명된 단계에 따라 새 클러스터로 데이터를 복원하세요. 

3. Logstash를 사용하여 데이터 전송

로그스태시로 데이터 전송을 시작하기 전에, 새 클러스터의 모든 인덱스에 대해 적절한 매핑을 설정해야 한다는 것을 기억하세요. 이렇게 하려면 인덱스를 직접 만들거나 인덱스 템플릿을 사용해야 합니다.

두 개의 Elasticsearch 클러스터 간에 데이터를 전송하려면 임시 Logstash 서버를 설정하고 이를 사용하여 두 클러스터 간에 데이터를 전송할 수 있습니다. 소규모 클러스터의 경우 2GB 램 인스턴스로 충분합니다. 대규모 클러스터의 경우 8GB RAM이 장착된 4코어 CPU를 사용할 수 있습니다.

Logstash 설치에 대한 안내는 여기를 참조하세요.

한 클러스터에서 다른 클러스터로 데이터를 전송하기 위한 Logstash 구성

클러스터 A에서 클러스터 B로 단일 인덱스를 복사하는 기본 구성은 다음과 같습니다:

보안된 Elasticsearch의 경우, 아래 구성을 사용할 수 있습니다:

인덱스 메타데이터

위의 명령은 하나의 명명된 인덱스에 기록합니다. 여러 인덱스를 전송하고 인덱스 이름을 유지하려면 Logstash 출력에 다음 줄을 추가해야 합니다:

또한 문서의 원래 ID를 유지하려면 추가해야 합니다:

문서 ID를 설정하면 데이터 전송 속도가 상당히 느려지므로 필요한 경우에만 원본 ID를 보존하세요.

업데이트 동기화

위에서 설명한 모든 방법은 비교적 오랜 시간이 걸리며 프로세스가 완료될 때까지 기다리는 동안 원본 클러스터의 데이터가 업데이트될 수 있습니다.

데이터 전송 프로세스 중에 발생한 업데이트를 동기화할 수 있는 다양한 전략이 있으며, 이 프로세스를 시작하기 전에 이러한 문제에 대해 생각해 보아야 합니다. 특히 다음 사항을 고려해야 합니다:

• 데이터 전송 프로세스 시작 이후 업데이트/추가된 데이터를 식별할 수 있는 방법(예: 데이터의 'last_update_time' 필드)은 무엇인가요?

• 마지막 데이터를 전송하는 데 어떤 방법을 사용할 수 있나요?

• 기록이 중복될 위험이 있나요? 사용 중인 메서드가 재색인 중에 문서 ID를 알려진 값으로 설정하지 않는 한 일반적으로 있습니다).

업데이트 동기화를 활성화하는 다양한 방법은 아래에 설명되어 있습니다.

1. 대기열 시스템 사용

일부 수집/업데이트 시스템에서는 지난 x일 동안 수신한 데이터 수정 사항을 '재생'할 수 있는 대기열을 사용합니다. 이는 수행된 모든 변경 사항을 동기화할 수 있는 수단을 제공할 수 있습니다.

2. 원격에서 재색인

"last_update_time" > x 일 전인 모든 항목에 대해 재색인 프로세스를 반복합니다. 재색인 요청에 '쿼리' 매개변수를 추가하여 이 작업을 수행할 수 있습니다.

3. Logstash

Logstash 입력에 쿼리를 추가하여 "last_update_time" > x일 전인 모든 항목을 필터링할 수 있습니다. 그러나 이 프로세스는 문서_id를 설정하지 않은 경우 시계열이 아닌 데이터에 중복을 발생시킵니다.

4. 스냅샷

인덱스의 일부만 복원할 수는 없으므로 위에서 설명한 다른 데이터 전송 방법 중 하나(또는 스크립트)를 사용하여 데이터 전송 프로세스가 수행된 이후 발생한 변경 사항을 업데이트해야 합니다.

그러나 스냅샷 복원은 재색인/로그스토시보다 훨씬 빠른 프로세스이므로 스냅샷을 전송하는 동안 잠시 동안 업데이트를 일시 중단하여 문제를 완전히 피할 수 있습니다.