Elasticsearch 재인덱싱 이해: 재인덱싱 시기, 모범 사례 및 대안

Elasticsearch 는 효율적이고 확장 가능한 데이터 저장 및 검색을 위해 널리 사용되는 기술입니다. 그러나 성능과 데이터 무결성을 유지하려면 재인덱싱이라는 중요한 방법이 필요합니다. 인덱싱은 Elasticsearch에 데이터를 추가하는 초기 프로세스인 반면, 재인덱싱은 데이터 정확성을 유지하고 검색 성능을 최적화하는 데 필수적입니다.

숙련된 Elasticsearch 사용자이든 이제 막 시작하는 사용자이든 관계없이 효율적인 Elasticsearch 클러스터를 유지하려면 재인덱싱을 이해하는 것이 중요합니다. 이 글에서는 Elasticsearch 재인덱싱의 필수 사항, 필요할 때 답변, 이를 트리거하는 방법, Elasticsearch 클러스터를 최대한 활용하기 위한 모범 사례를 자세히 살펴보겠습니다.

Elasticsearch 재인덱싱 이해

Elasticsearch에서 재인덱싱은 데이터 무결성을 유지하고 성능을 높이는 데 도움이 됩니다. 간단히 말해서 한 인덱스에서 다른 인덱스로 데이터를 복사하는 프로세스입니다. 이것이 간단해 보일 수도 있지만 올바르게 수행하지 않으면 데이터 검색 속도가 느려지거나 결과가 부정확해지는 등의 문제가 발생할 수 있습니다.

Elasticsearch 인덱스를 잘 구성된 라이브러리로 상상해 보세요. 시간이 지남에 따라 책을 업데이트하거나 재배치하거나 교체해야 할 수도 있습니다. 색인 재작성은 도서관 서가를 재배치하거나 책을 업데이트하여 모든 것을 정리하는 것과 비슷합니다. 그렇지 않으면 라이브러리가 정리되지 않아 검색 속도가 느려지고 데이터가 부정확해질 수 있습니다.

이 비유는 Elasticsearch에서 재인덱싱을 이해하는 것이 중요함을 강조합니다. 이는 단지 데이터 복사에 관한 것이 아닙니다. 효율적인 검색을 위해 "라이브러리"의 무결성을 유지하는 것이 중요합니다. 재인덱싱이 필요한 시기 와 이를 유지하는 방법을 살펴보겠습니다.

재인덱싱은 언제 필요합니까?

Elasticsearch 데이터 모델이나 매핑에 변경 사항이 발생하거나 성능 향상을 원하는 경우 재인덱싱이 필수적입니다. 이 섹션에서는 재인덱싱이 필요한 이유에 대한 미묘한 차이를 이해하기 위해 이러한 시나리오를 더 자세히 살펴보겠습니다.

데이터 모델의 구조적 변화

데이터 모델의 구조적 변화는 Elasticsearch 내에서 데이터가 구조화되는 방식의 수정을 의미합니다. 이러한 변경에는 새 필드 추가 또는 제거, 기존 필드의 데이터 유형 변경 등이 포함될 수 있습니다.

새로운 필드를 도입하려면 Elasticsearch가 해당 필드에 저장된 데이터를 효율적으로 검색하는 방법을 알 수 있도록 재색인이 필요한 경우가 많습니다. 데이터 유형을 내부에서 변경할 수 없으므로 데이터 유형을 수정하려면 완전히 새로운 인덱스가 필요합니다. 수정된 데이터 유형에 대해 새 매핑이 생성되면 데이터를 다시 인덱싱해야 합니다.

이러한 구조적 변경에는 Elasticsearch의 쓰기 스키마 접근 방식으로 인해 재인덱싱이 필요합니다. Elasticsearch는 데이터가 수집되는 대로 데이터를 인덱싱하며, 데이터 구조가 변경되면 기존 데이터와 새 스키마로 작성된 데이터 간에 불일치가 발생할 수 있습니다. 결과적으로 색인을 다시 작성하지 않으면 데이터 항목의 스키마 불일치로 인해 검색 쿼리에서 예상치 못한 결과나 부정확한 결과가 나올 수 있습니다. 이는 데이터 정확성과 검색 성능 모두에 영향을 미칠 수 있습니다.

매핑 업데이트 또는 변경 사항

매핑은 Elasticsearch에서 데이터를 인덱싱하고 쿼리하는 방법에 대한 청사진 역할을 합니다. 이러한 매핑이 수정되면 일반적으로 재인덱싱이 필요합니다.

매핑은 Elasticsearch 내 필드의 데이터 유형과 속성을 정의합니다. 이러한 매핑을 변경하면 데이터가 인덱싱, 저장 및 검색되는 방식에 영향을 줍니다. 예를 들어 텍스트 필드를 날짜 필드로 변경하면 데이터 처리 및 쿼리 방식이 근본적으로 변경됩니다. Elasticsearch는 매핑 정의를 기반으로 데이터 일관성을 강화합니다. 데이터가 다시 인덱싱되지 않으면 매핑을 변경하면 기존 데이터와 업데이트된 스키마 간에 불일치가 발생할 수 있습니다.

매핑이 수정될 때, 특히 데이터 유형이나 필드 속성 변경과 관련된 경우 백필도 중요해집니다. 백필은 기존 데이터를 소급하여 새로운 스키마나 데이터 구조에 맞춰 채우거나 업데이트하는 프로세스입니다. 이는 매핑이 변경된 후에도 기존 데이터를 효율적이고 정확하게 쿼리할 수 있음을 의미합니다.

성능 향상 및 인덱스 최적화

재인덱싱은 단순한 일상적인 유지 관리 작업이 아니라 Elasticsearch 내에서 검색 성능을 최적화하기 위한 강력한 도구입니다. 예를 들어 재인덱싱을 사용하면 인덱스의 샤드 수를 수정할 수 있습니다. 샤드 수를 조정하거나 리샤딩하면 데이터를 더욱 균등하게 분산하여 특정 노드에서 고르지 않은 작업 부하를 방지하여 검색 성능을 향상시킬 수 있습니다.

재인덱싱을 사용하여 인덱스를 함께 통합할 수도 있습니다. 동일한 데이터 구조를 공유하고 자주 함께 쿼리되는 여러 개의 작은 인덱스가 있다고 가정해 보겠습니다. 재색인을 사용하면 이를 더 큰 단일 인덱스로 통합할 수 있습니다. 이는 수많은 작은 인덱스를 관리하는 오버헤드를 줄여 결과적으로 검색 속도를 향상시킬 수 있습니다.

마지막으로, 재인덱싱을 사용하여 라우팅을 개선할 수 있습니다. 라우팅 전략을 효과적으로 재인덱싱하고 적용하면 쿼리를 특정 샤드로 라우팅하여 검색해야 하는 샤드 수를 최소화할 수 있습니다. 이러한 타겟 접근 방식은 사용자 ID와 같은 특정 키로 데이터를 자주 검색하는 경우 검색 쿼리 속도를 크게 높일 수 있습니다.

클러스터 업그레이드

Elasticsearch 버전 6.X에서 8.0(현재 주요 버전) 이상으로 업그레이드할 때 버전 6에서 생성된 모든 인덱스를 다시 색인화해야 할 수 있습니다. Elasticsearch의 데이터 구조와 기본 메커니즘은 이러한 버전 간에 크게 변경되었으므로 호환성과 최적의 성능을 위해 재색인이 필요합니다. .

재인덱싱 프로세스를 통해 데이터가 업데이트된 구조 및 새로운 기능과 일치하는지 확인하여 이전 항목에서 새 항목으로 원활하게 마이그레이션할 수 있습니다. Elasticsearch는 이 프로세스를 돕기 위해 업그레이드 도우미를 사용할 것을 권장합니다.

재인덱싱 작업을 트리거하는 방법

Elasticsearch에서 재인덱싱은 Elasticsearch Reindex API를 통해 가능합니다. Reindex API는 기존 인덱스와 생성하거나 수정하려는 새 인덱스 사이의 브리지 역할을 합니다. 주요 목적은 한 인덱스에서 다른 인덱스로 데이터를 효율적으로 전송하는 것입니다. 또한 다음을 수행할 수도 있습니다.

• 소스 인덱스에서 대상 인덱스로 문서를 선택적으로 복사합니다.

• 필드 이름 바꾸기 또는 유형 변환과 같은 복잡한 데이터 변환을 적용합니다.

• 특정 기준에 따라 데이터를 필터링합니다.

• 조절 및 새로 고침 간격과 같은 옵션을 사용하여 인덱싱 프로세스를 제어하세요.

  
  

Reindex API를 사용하기 전에 데이터를 이동하거나 변환하려는 대상 인덱스가 생성되고 올바르게 구성되었는지 확인하세요.

재인덱싱을 트리거하려면 _reindex 엔드포인트에 대한 POST 요청을 공식화하여 소스 및 대상 인덱스는 물론 원하는 변환 또는 필터를 지정해야 합니다. 재색인 POST 요청의 예는 다음과 같습니다.

 POST /_reindex { "source": { "index": "source_index" }, "dest": { "index": "target_index" }, "script": { "source": "ctx._source.new_field = 'transformed value'" }, "query": { "term": { "category.keyword": "example" } } }

요청이 작성되면 요청을 Elasticsearch로 보내 재인덱싱 프로세스를 시작할 수 있습니다. Elasticsearch는 정의된 지침에 따라 소스 인덱스에서 대상 인덱스로 데이터 복사를 시작합니다.

재인덱싱이 완료되면 대상 인덱스의 데이터를 철저하게 테스트하여 예상과 일치하는지 확인하세요. 예를 들어 소스 인덱스와 대상 인덱스 간의 필드 매핑을 비교하여 재인덱싱 중에 필드가 올바르게 매핑되었는지 확인할 수 있습니다. 또한 소스 및 대상 인덱스 모두에서 문서 샘플을 검색하고 이를 비교하여 데이터가 정확하게 재인덱싱되었는지 확인할 수도 있습니다.

재색인화 모범 사례

Elasticsearch 내에서 재인덱싱을 수행할 때 재인덱싱 절차가 데이터 손실 없이 원활하고 기존 클러스터 작업에 거의 영향을 미치지 않도록 하기 위해 다음 모범 사례를 따라야 합니다.

데이터 백업 우선순위

재인덱싱 활동을 시작하기 전에 클러스터를 백업하는 것이 중요합니다. 이 예방 조치는 안전망 역할을 하여 재색인 프로세스 중에 예상치 못한 문제가 발생할 경우 원래 상태로 되돌릴 수 있는 방법을 제공합니다.

원본 인덱스는 다시 인덱싱한 후에도 여전히 존재해야 하지만 중요한 변경을 하기 전에 항상 신뢰할 수 있는 데이터 복사본을 보유하는 것이 기본 원칙입니다.

먼저 통제된 환경에서 재인덱싱을 수행하세요.

재인덱싱 중 잠재적인 위험과 문제를 완화하려면 먼저 사전 프로덕션 환경에서 작업을 수행하는 것이 좋습니다. 이렇게 하면 생산 시스템에 영향을 주지 않고 예상치 못한 문제를 식별하고 해결할 수 있습니다. 사전 프로덕션 환경에서 절차가 완료되고 검증되면 프로덕션 환경에서 안전하게 실행할 수 있습니다.

리소스 사용량 모니터링

인프라에 부담을 주지 않도록 재인덱싱 중에 시스템 리소스를 모니터링하는 것이 중요합니다. 재인덱싱은 특히 대규모 데이터 세트의 경우 리소스 집약적일 수 있습니다. CPU, 메모리, 디스크 사용량 및 네트워크 활동을 면밀히 관찰하면 리소스 할당을 최적화하여 성능 병목 현상 없이 프로세스가 효율적으로 실행되도록 할 수 있습니다. 리소스 사용량을 확인하려면 노드 통계 API를 사용할 수 있습니다.

GET /_nodes/stats

그러면 다음과 같은 응답이 반환됩니다.

 { "_nodes": { "total": 2, "successful": 2, "failed": 0 }, "cluster_name": "my_cluster", "nodes": { "node_id1": { "name": "node_name1", "process": { "cpu": { "percent": 30, } }, "jvm": { "mem": { "heap_used_percent": 40.3, "heap_used_in_bytes": 123456789, "heap_max_in_bytes": 256000000 } } }, "node_id2": { "name": "node_name2", "process": { "cpu": { "percent": 50, } }, "jvm": { "mem": { "heap_used_percent": 60.8, "heap_used_in_bytes": 210987654, "heap_max_in_bytes": 256000000 } } } } }

재인덱싱이 너무 집중적이라면 재인덱싱 요청을 제출할 때 requests_per_second 매개변수를 설정하여 프로세스를 조절할 수 있습니다. 그러면 매개변수로 설정된 초 동안 배치 사이에 대기 시간이 추가되어 배치 사이에 휴지 기간이 제공됩니다.

결과 확인 및 검증

재인덱싱이 완료되면 대상 인덱스의 데이터가 예상대로 나타나는지 확인해야 합니다. 이 유효성 검사 프로세스에는 문서 수, 필드 매핑, 검색어 등 다양한 테스트가 포함되어야 합니다.

대체 솔루션

Elasticsearch는 의심할 여지 없이 NoSQL 검색 및 분석 분야에서 탁월한 솔루션으로 자리매김했습니다. 그러나 데이터 인덱싱 및 쿼리에 대한 고유한 접근 방식을 제공하는 대체 솔루션, 특히 Rockset과 같은 솔루션을 살펴보는 것은 가치가 있습니다.

Rockset은 Elasticsearch의 클라우드 기반 대안 이며 데이터 인덱싱 및 쿼리에 대한 다양한 관점을 제공합니다. Elasticsearch의 쓰기 스키마 접근 방식과 달리 Rockset은 스키마 없는 수집을 허용합니다. 사전 스키마 정의 없이 데이터를 수집하고 쿼리할 수 있으므로 다시 인덱싱할 필요 없이 끊임없이 진화하는 데이터 세트를 처리하는 데 더 많은 유연성을 제공합니다.

인덱스 관리 영역에서 Rockset은 데이터가 수집될 때 행 인덱스, 열 인덱스 및 검색 인덱스가 모두 자동으로 생성되는 통합 인덱싱 모델의 이점을 활용합니다. 이는 사용자가 인덱스를 생성하고 구조적 변경으로 인해 종종 시간이 많이 걸리는 재인덱싱 절차가 필요한 Elasticsearch와 대조됩니다.

Elasticsearch는 다양한 사용 사례에 대한 강력한 솔루션으로 남아 있지만 Rockset과 같은 대안을 탐색하는 것이 유용할 수 있습니다. 특히 Elasticsearch에서 재인덱싱이 빈번한 활동이 되는 경우에는 더욱 그렇습니다.

결론

재인덱싱은 Elasticsearch의 기본 프로세스이며 데이터 구조가 발전함에 따라 검색 결과의 효율성과 정확성을 유지하는 데 중요합니다.

재인덱싱이 팀에 지속적인 시간 부담이 되고 있다고 판단되면 Rockset과 같은 대체 솔루션을 고려해 볼 가치가 있습니다. Rockset은 개발자가 더 많은 부가가치 활동에 집중할 수 있도록 보다 간소화된 지수 관리 프로세스를 제공합니다.