인덱스 기본

원본 보기

인덱스 기본

인덱스는 Elasticsearch의 기본 저장 단위이며, 데이터를 다루는 기준이 되는 계층입니다. 서로 독립적인 여러 데이터셋을 나란히 저장할 수 있습니다.

문서를 저장하려면 특정 인덱스에 추가합니다. 검색할 때는 하나 이상의 인덱스를 대상으로 지정합니다. Elasticsearch는 해당 인덱스 안의 모든 데이터를 검색해 일치하는 문서를 반환합니다. 인덱스 이름으로 직접 대상을 지정할 수도 있고, 하나 이상의 인덱스를 가리키는 별칭을 사용하거나, 요청을 적절한 백업 인덱스로 라우팅하는 데이터 스트림을 사용할 수도 있습니다.

내부적으로 Elasticsearch는 각 인덱스를 샤드로 나누어 클러스터의 노드들에 분산합니다. 샤드를 다른 노드의 복제본 샤드로 수평 확장하면 인덱스가 대량의 트래픽을 효율적으로 처리할 수 있습니다. 복제본 샤드는 내결함성을 제공해 개별 노드의 응답이 실패하더라도 데이터를 계속 사용할 수 있게 합니다.

이 페이지에서는 인덱스의 핵심 구성 요소(문서, 매핑, 설정)를 설명하고, Elasticsearch가 샤드를 사용해 인덱스 데이터를 물리적으로 저장하는 방식을 다루며, 자주 마주치는 설계 결정 사항을 짚어 봅니다.

Elastic Cloud Serverless의 인덱스

Elastic Cloud Serverless에서는:

  • 샤드, 복제본, 노드가 모두 자동으로 관리됩니다. 플랫폼이 워크로드에 맞춰 리소스를 자동으로 확장하므로 이러한 세부 사항을 직접 구성하거나 모니터링할 필요가 없습니다. 이 페이지의 샤드 관련 내용은 Elasticsearch가 내부적으로 어떻게 동작하는지 설명하는 것입니다.
  • 각 프로젝트는 최대 15,000개의 인덱스를 지원합니다. 이 제한은 안정적인 성능과 안정성을 보장하는 데 도움이 됩니다. 더 높은 제한이 필요하면 상향을 요청할 수 있습니다. 인덱스 크기 관련 권장 사항은 인덱스 크기 가이드라인을 참조하세요.

인덱스는 다음 구성 요소로 이루어집니다:

  • 문서: 데이터를 담는 JSON 객체로, _index, _id와 같이 시스템이 관리하는 메타데이터 필드도 포함합니다.
  • 매핑: 필드의 데이터 타입을 지정하고 데이터가 색인되고 조회되는 방식을 제어하는 정의입니다. 필드 데이터 타입을 이해하면 효과적인 쿼리를 작성하고 색인 문제를 피하는 데 도움이 됩니다.
  • 설정: 샤드 수, 복제본 수, 새로 고침 간격 등 저장 및 성능 동작을 제어하는 인덱스 수준 구성입니다.

Elasticsearch는 데이터를 JSON 문서 형태로 직렬화해 저장합니다. 문서는 데이터를 담는 키-값 쌍인 필드의 집합입니다. 각 문서에는 고유한 ID가 있으며, 직접 지정하거나 Elasticsearch가 자동 생성하도록 할 수 있습니다. 색인된 문서에는 사용자가 정의한 문서 필드와 시스템이 관리하는 메타데이터가 함께 포함됩니다.

간단한 Elasticsearch 문서의 예는 다음과 같습니다:

{
  "_index": "my-first-elasticsearch-index",
  "_id": "DyFpo5EBxE8fzbb95DOa",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "found": true,
  "_source": {
    "email": "john@smith.com",
    "first_name": "John",
    "last_name": "Smith",
    "info": {
      "bio": "Eco-warrior and defender of the weak",
      "age": 25,
      "interests": [
        "dolphins",
        "whales"
      ]
    },
    "join_date": "2024/05/01"
  }
}
		
  1. 메타데이터 필드는 밑줄로 시작하는, 시스템이 관리하는 필드입니다. _index는 문서를 저장하는 인덱스를 식별하고 _id는 해당 인덱스 내에서 문서의 고유 식별자입니다.
  2. _source 필드는 제출된 그대로의 원본 문서 본문을 담습니다. _source 안의 필드는 매핑을 통해 제어하는 대상입니다. 이러한 매핑은 명시적으로 정의하거나, 데이터가 수집될 때 Elasticsearch가 동적으로 생성하도록 할 수 있습니다. columnar와 같은 일부 인덱스 모드는 동일한 문서 및 쿼리 API를 유지하면서 _source와 필드 인덱스가 저장되는 방식을 변경합니다.

각 인덱스에는 필드마다 데이터 타입, 색인 방식, 저장 방식을 정의하는 매핑이 있습니다.

예를 들어, 다음 매핑은 몇 가지 일반적인 데이터 타입에 대한 필드 타입을 정의합니다:

{
  "properties": {
    "email":      { "type": "keyword" },
    "first_name": { "type": "text" },
    "age":        { "type": "integer" },
    "join_date":  { "type": "date" }
  }
}
		

각 인덱스에는 저장 및 성능 동작을 제어하는 설정이 있습니다. 설정은 인덱스를 생성할 때 인덱스 생성 요청에서 직접 지정하거나 인덱스 템플릿을 통해 구성합니다. 일부 인덱스 설정은 운영 중인 인덱스에서 동적으로 업데이트할 수 있습니다.

일반적인 설정은 다음과 같습니다:

  • index.number_of_shards: 주 샤드의 개수입니다. 생성 시점에 고정됩니다.
  • index.number_of_replicas: 주 샤드당 복제본 개수입니다. 언제든지 변경할 수 있습니다.
  • index.refresh_interval: 새 데이터가 검색 가능해지는 주기입니다. 기본값은 1s입니다.

사용 가능한 설정의 전체 목록은 인덱스 설정을 참조하세요.

인덱스를 생성할 때 Elasticsearch는 모든 문서를 한 곳에 저장하지 않습니다. 대신 인덱스를 하나 이상의 샤드로 나누고 그 샤드들을 클러스터의 노드에 분산합니다. 각 샤드는 그 자체로 완결된 Apache Lucene 인덱스이며 효율적으로 관리할 수 있는 데이터 양에 현실적인 한계가 있으므로, 데이터를 여러 샤드로 분할하면 개별 샤드의 성능을 유지할 수 있습니다. 이 샤드들을 클러스터 노드에 분산하면 수평 확장성과 중복성이 더해집니다. 적절한 샤드 개수는 데이터 볼륨, 쿼리 패턴, 클러스터 토폴로지에 따라 달라지며 — 정답이 하나로 정해져 있지는 않습니다. 자세한 정보와 모범 사례는 샤드 크기 및 분산 권장 사항을 참조하세요.

색인하거나 검색할 때 샤드를 직접 다루지는 않습니다. 대신 인덱스를 이름으로 지정하면 Elasticsearch가 해당 작업을 적절한 샤드로 라우팅합니다. 다만 구성한 샤드의 개수와 크기는 성능과 안정성에 영향을 미칩니다. 자세한 내용은 일반적인 인덱스 설계 결정을 참조하세요.

샤드는 인덱스 문서의 일부를 보관하며 색인 및 검색 작업을 독립적으로 처리할 수 있습니다. 각 샤드 내부에서 데이터는 문서가 색인될 때 기록되는 불변 세그먼트로 구성됩니다. 세그먼트가 검색 가용성에 미치는 영향을 알아보려면 준실시간 검색을 참조하세요.

샤드에는 두 가지 유형이 있습니다:

  • 주 샤드: 모든 문서는 정확히 하나의 주 샤드에 속합니다. 주 샤드의 개수는 인덱스 템플릿이나 인덱스 생성 요청의 index.number_of_shards 설정을 통해 인덱스 생성 시점에 고정됩니다.
  • 복제본 샤드: 중복성을 제공하고 읽기 요청을 처리하는 주 샤드의 사본입니다. index.number_of_replicas 설정으로 복제본 개수를 언제든지 조정할 수 있습니다.

샤드를 여러 노드에 분산함으로써 Elasticsearch는 수평으로 확장할 수 있고 개별 노드에 장애가 발생해도 계속 동작할 수 있습니다. 이 분산 모델에 대한 자세한 설명은 분산 아키텍처를 참조하세요. Elasticsearch가 주 샤드와 복제본 샤드 전반에서 읽기와 쓰기를 조율하는 방식은 문서 읽기 및 쓰기를 참조하세요.

Elasticsearch 인덱스를 구성할 때는 인덱스 구성 요소에 대한 몇 가지 설계 결정이 필요합니다. 매핑은 다양한 데이터 타입에 대해 인덱스 필드가 생성되는 방식을 제어하고, 템플릿은 여러 인덱스에 걸쳐 설정 구성을 표준화하며, 별칭은 쿼리를 인덱스 이름과 분리하고, 수명 주기 정책은 시간이 지남에 따라 데이터가 저장되는 방식을 자동화합니다.

인덱스를 다룰 때는 일반적으로 다음 사항에 초점을 맞춰 결정합니다:

  • 이름 지정과 별칭: 인덱스와 별칭에 명확한 이름 규칙을 사용해 쿼리 대상을 단순화하고 인덱스 변경 시 영향을 최소화하세요.
  • 매핑 전략: 데이터를 탐색할 때는 속도를 위해 동적 매핑을, 프로덕션 사용 사례에는 명시적 매핑을 사용하세요. 처음부터 올바른 필드 타입을 고르는 것이 중요한데, 필드 타입이 사용 가능한 쿼리와 집계를 결정하며 나중에 필드 타입을 변경하려면 재색인이 필요하기 때문입니다.
  • 인덱스 또는 데이터 스트림: 업데이트나 삭제가 잦다면 일반 인덱스를 사용하세요. 로그, 이벤트, 메트릭처럼 추가만 이루어지는 시계열 데이터에는 데이터 스트림을 사용하세요. 데이터 스트림은 롤링 인덱스를 자동으로 관리합니다.
  • 샤드 크기 조정: 프로덕션 워크로드에서는 샤드의 개수와 크기가 쿼리 속도와 클러스터 안정성에 영향을 미칩니다. 가이드라인은 샤드 크기 조정을 참조하세요.
  • 데이터 수명 주기: 데이터를 얼마나 오래 보관할지, 언제 더 저렴한 티어로 옮길지, 언제 삭제할지 결정하세요. 자세한 내용은 데이터 수명 주기를 참조하세요.

인덱스 기본을 이해했다면, 실습 작업은 다음 페이지에서 살펴보세요:

  • Kibana에서 인덱스 관리: Kibana에서 인덱스, 데이터 스트림, enrich 정책을 조회하고 살펴보며 작업을 수행합니다.
  • 템플릿: 인덱스 템플릿과 컴포넌트 템플릿을 생성하고 관리합니다.
  • Kibana에서 데이터 스트림 관리: 데이터 스트림과 그 백업 인덱스를 생성하고 모니터링하며 관리합니다.
  • 데이터 보강: enrich 정책을 설정해 기존 인덱스의 데이터를 수신 문서에 추가합니다.
  • API로 데이터 관리: Elasticsearch REST API로 문서를 색인, 업데이트, 조회, 검색, 삭제합니다.