Elasticsearch 인덱싱 성능 가이드: 모범 사례 공개

Elasticsearch는 속도와 확장성으로 유명한 강력한 분산 검색 및 분석 엔진입니다. 하지만 특히 인덱싱 단계에서 최적의 성능을 달성하려면 다양한 설정과 전략을 신중하게 고려해야 합니다. 인덱싱은 Elasticsearch에 문서를 추가하는 프로세스인데, 제대로 관리되지 않으면 병목 현상이 발생하여 클러스터의 전반적인 응답성과 처리량에 영향을 미칠 수 있습니다. 이 가이드에서는 Elasticsearch 인덱싱 성능의 핵심 측면을 자세히 살펴보고 데이터 수집 속도를 획기적으로 높일 수 있는 모범 사례를 공개합니다.

이러한 기술을 이해하고 구현하는 것은 실시간 데이터 분석이나 검색을 위해 Elasticsearch에 의존하는 모든 애플리케이션에 매우 중요합니다. 대규모 데이터 세트를 다루든 고주파 업데이트를 처리하든, 인덱싱 최적화를 마스터하면 Elasticsearch 클러스터가 고성능 자산으로 유지되도록 보장할 수 있습니다. 주요 구성 설정, 효율적인 벌크 인덱싱 전략, 매핑 선택이 인덱싱 처리량에 미치는 영향에 대해 살펴보겠습니다.

인덱싱 프로세스 이해하기

최적화에 들어가기 전에 Elasticsearch가 인덱싱을 처리하는 방식을 이해하는 것이 필수적입니다. 문서를 인덱싱할 때 Elasticsearch는 문서 구문 분석, 필드 분석(토큰화, 어간 추출 등) 및 역 인덱스 및 기타 데이터 구조 저장과 같은 여러 작업을 수행합니다. 이러한 작업, 특히 분석 및 디스크 I/O는 CPU 및 I/O 집약적입니다. 분산 환경에서는 이러한 작업이 개별 노드에서 처리되므로 클러스터 전체 구성 및 노드 리소스가 중요합니다.

인덱싱 속도에 영향을 미치는 주요 요인

Elasticsearch가 문서를 인덱싱하는 속도에 큰 영향을 미칠 수 있는 몇 가지 요인은 다음과 같습니다.

하드웨어 리소스: CPU, RAM, 특히 디스크 I/O 속도가 가장 중요합니다. 뛰어난 읽기/쓰기 성능을 위해 HDD보다 SSD가 강력히 권장됩니다.
클러스터 구성: 샤드 할당, 복제 설정 및 노드 역할이 영향을 미칩니다.
인덱싱 전략: 데이터를 보내는 데 사용되는 방법(예: 단일 문서 요청 대 벌크 API).
매핑 및 데이터 유형: 필드가 정의되는 방식과 해당 데이터 유형.
새로 고침 간격(Refresh Interval): 검색을 위해 데이터가 표시되는 빈도.
트랜스로그 설정(Translog Settings): Lucene 세그먼트에 대한 내구성 설정.

인덱싱 성능 최적화: 모범 사례

이 섹션에서는 Elasticsearch 인덱싱 처리량을 향상시키기 위한 실행 가능한 전략을 다룹니다.

1. 벌크 API 활용

인덱싱을 위한 가장 기본적인 최적화는 벌크 API를 사용하는 것입니다. 네트워크 오버헤드와 요청당 처리 비용이 발생하는 개별 인덱싱 요청을 보내는 대신, 벌크 API를 사용하면 단일 HTTP 요청으로 작업 목록(인덱싱, 생성, 업데이트, 삭제)을 보낼 수 있습니다. 이는 네트워크 지연 시간을 크게 줄이고 전반적인 처리량을 향상시킵니다.

벌크 API 모범 사례:

배치 크기: 배치 크기를 실험해 보십시오. 일반적인 시작점은 배치당 1,000~5,000개의 문서 또는 페이로드 크기 5~15MB입니다. 배치가 너무 작으면 비효율적이고, 너무 크면 클라이언트나 서버에서 메모리 문제가 발생할 수 있습니다.
동시성: 여러 스레드 또는 비동기 클라이언트를 사용하여 벌크 요청을 동시에 보냅니다. 단, 클러스터에 과부하가 걸리지 않도록 주의하십시오. 최적의 지점을 찾기 위해 CPU 및 I/O 사용량을 모니터링하십시오.
오류 처리: 강력한 오류 처리를 구현하십시오. 벌크 API는 응답 배열을 반환하며, 각 작업의 상태를 확인해야 합니다.

벌크 요청 예시:

POST /_bulk
{
  "index" : { "_index" : "my-index", "_id" : "1" }
}
{
  "field1" : "value1", 
  "field2" : "value2"
}
{
  "index" : { "_index" : "my-index", "_id" : "2" }
}
{
  "field1" : "value3", 
  "field2" : "value4"
}

2. 인덱싱 설정 조정

Elasticsearch는 인덱싱 프로세스를 최적화하기 위해 조정할 수 있는 몇 가지 설정을 제공합니다. 이러한 설정은 일반적으로 인덱스별로 설정됩니다.

새로 고침 간격(`index.refresh_interval`)

새로 고침 간격은 데이터가 검색 가능해지는 빈도를 제어합니다. 기본값은 1s로 설정됩니다. 대량 인덱싱 작업 중에는 세그먼트 생성(I/O 집약적인 작업) 빈도를 줄이기 위해 이 간격을 늘릴 수 있습니다. -1로 설정하면 자동 새로 고침이 비활성화되어 수동으로 새로 고침하거나 인덱스가 닫힐 때까지 데이터가 검색되지 않습니다.

권장 사항: 벌크 인덱싱 작업의 경우 index.refresh_interval을 30s 또는 60s(또는 그 이상)로 설정하십시오. 벌크 작업이 완료되면 근 실시간 검색 가능성을 위해 다시 낮은 값(예: 1s)으로 재설정하는 것을 잊지 마십시오.

인덱스 설정 API를 사용하는 예시:

# 새로 고침 일시 중지
PUT /my-index/_settings
{
  "index" : {
    "refresh_interval" : "-1"
  }
}

# ... 벌크 인덱싱 수행 ...

# 새로 고침 재개
PUT /my-index/_settings
{
  "index" : {
    "refresh_interval" : "1s"
  }
}

트랜스로그 내구성(`index.translog.durability`)

트랜스로그는 데이터 내구성을 보장하는 쓰기 전 로그입니다. request(기본값) 또는 async로 설정할 수 있습니다. async로 설정하면 트랜스로그를 비동기적으로 플러시하여 인덱싱 속도를 향상시킬 수 있지만, 노드가 디스크에 트랜스로그를 기록하기 전에 실패하면 데이터 손실의 약간의 위험이 따릅니다.

권장 사항: 속도보다 내구성이 덜 중요한 벌크 가져오기 시나리오의 경우 async가 유용할 수 있습니다. 항상 데이터 손실에 대한 애플리케이션의 허용 범위를 고려하십시오.

복제본 수(`index.number_of_replicas`)

복제본은 기본 샤드의 복사본으로, 고가용성 및 읽기 확장에 사용됩니다. 그러나 각 복제본은 모든 인덱싱 작업을 처리해야 합니다. 초기 대용량 데이터 로드 중에는 index.number_of_replicas를 0으로 설정하면 인덱싱 속도가 크게 빨라질 수 있습니다. 데이터 로드가 완료된 후 복제본 수를 늘릴 수 있습니다.

벌크 로드 중 예시:

# 복제본 수를 0으로 일시적으로 설정
PUT /my-index/_settings
{
  "index" : {
    "number_of_replicas" : "0"
  }
}

# ... 벌크 인덱싱 수행 ...

# 복제본 복원(예: 1로)
PUT /my-index/_settings
{
  "index" : {
    "number_of_replicas" : "1"
  }
}

3. 매핑 최적화

매핑은 문서와 해당 필드가 저장되고 인덱싱되는 방식을 정의합니다. 잘못 설계된 매핑은 성능 문제를 일으킬 수 있습니다.

대용량 데이터 세트에 대해 동적 매핑 피하기: 편리하지만, 동적 매핑은 매핑 폭발(mapping explosion) 및 예상치 못한 필드 유형으로 이어질 수 있습니다. 특히 대용량 데이터의 경우 인덱스에 대해 명시적인 매핑을 정의하십시오.
적절한 데이터 유형 선택: 가장 효율적인 데이터 유형을 사용하십시오. 예를 들어, 전문 검색이 필요하지 않은 경우 정확한 값 일치에는 text보다 keyword가 더 효율적입니다.
불필요한 기능 비활성화: 특정 필드에 대해 norms(예: 정확한 일치 또는 집계용)와 같은 기능이 필요하지 않은 경우 비활성화하면 공간을 절약하고 인덱싱 속도를 향상시킬 수 있습니다(norms: false). 마찬가지로, 필드에서 정렬 또는 집계에 필요하지 않은 경우 doc_values를 비활성화하십시오. 그러나 doc_values는 일반적으로 집계 및 정렬에 유용하므로 이는 미묘한 결정입니다.
_source 필드: 원본 JSON 문서를 저장할 필요가 없다면 _source를 비활성화하면 디스크 공간과 일부 I/O를 절약할 수 있지만, 인덱스 다시 작성(reindexing)이 불가능해지고 디버깅이 어려워집니다. 활성화 상태를 유지하는 경우 _source 압축을 고려하십시오.

예시 매핑(명시적 유형 및 비활성화된 norms 포함):

PUT /my-index
{
  "mappings": {
    "properties": {
      "timestamp": {"type": "date"},
      "message": {"type": "text", "norms": false},
      "user_id": {"type": "keyword"}
    }
  }
}

4. 하드웨어 및 인프라 고려 사항

완벽한 소프트웨어 구성이라도 부적절한 하드웨어는 인덱싱 속도를 제한합니다.

디스크 I/O: 빠른 SSD를 사용하십시오. NVMe SSD가 최고의 성능을 제공합니다. 가능하다면 인덱싱 노드에 네트워크 연결 스토리지(NAS) 사용을 피하십시오.
CPU 및 RAM: 분석을 위해 충분한 CPU 코어가 필요하며, 넉넉한 RAM은 캐싱 및 전반적인 JVM 성능에 도움이 됩니다.
전용 인덱싱 노드: 매우 높은 수집 속도의 경우 클러스터에서 인덱싱 전용으로만 사용되는 특정 노드를 고려하십시오. 이렇게 하면 인덱싱 작업과 검색 작업이 분리되어 한 작업이 다른 작업에 영향을 미치는 것을 방지할 수 있습니다.
네트워크: 클라이언트와 Elasticsearch 노드 간, 그리고 클러스터 내 노드 간에 충분한 대역폭과 낮은 지연 시간을 확보하십시오.

5. 샤드 크기 및 개수

직접적인 인덱싱 설정은 아니지만 샤드의 개수와 크기는 성능에 영향을 미칩니다. 너무 많은 작은 샤드는 오버헤드를 증가시킬 수 있습니다. 반대로, 단일의 거대한 샤드는 관리하기 어렵고 확장성이 좋지 않을 수 있습니다. 최적의 성능을 위해 샤드 크기를 10GB에서 50GB 사이로 유지하는 것을 목표로 하지만, 이는 달라질 수 있습니다.

권장 사항: 대량의 데이터를 인덱싱하기 전에 기본 샤드 수를 계획하십시오. 일반적으로 기존 인덱스의 기본 샤드 수는 다시 인덱싱하지 않고 변경하는 것은 권장되지 않습니다.

6. 인덱스 수명 주기 관리 (ILM)

시계열 데이터의 경우 인덱스 수명 주기 관리(ILM)를 사용하는 것이 중요합니다. ILM은 주로 시간 경과에 따라 인덱스를 관리(롤오버, 축소, 삭제)하지만, 롤오버 작업은 크기 또는 기간을 기준으로 새 인덱스를 생성하도록 구성할 수 있습니다. 이렇게 하면 인덱스가 최적의 크기 범위를 유지하게 되어 간접적으로 인덱싱 성능에 도움이 됩니다.

롤오버: 인덱스가 특정 크기나 기간에 도달하면 ILM은 자동으로 새 비어 있는 인덱스를 생성하고 데이터 스트림 별칭을 해당 인덱스로 전환할 수 있습니다. 이를 통해 새 인덱스에 대한 설정을 최적화하고(예: 초기 벌크 로드 중 복제본 수 감소) 활성 인덱스를 관리하기 쉬운 상태로 유지할 수 있습니다.

결론

Elasticsearch 인덱싱 성능 최적화는 클러스터 설정을 신중하게 조정하고, 벌크 API를 스마트하게 사용하며, 매핑을 신중하게 설계하고, 적절한 하드웨어를 갖추는 다면적인 작업입니다. 이 가이드에 설명된 모범 사례(벌크 API 활용, 새로 고침 간격 및 복제본 수 조정, 매핑 최적화, 강력한 인프라 보장)를 구현하면 데이터 수집 속도를 크게 향상시키고 Elasticsearch 클러스터가 데이터 요구 사항에 따라 효과적으로 확장되도록 보장할 수 있습니다.

최적의 설정은 종종 특정 사용 사례, 데이터 볼륨 및 하드웨어에 따라 달라진다는 점을 기억하십시오. 지속적인 모니터링과 반복적인 테스트가 환경에 가장 적합한 구성을 찾는 열쇠입니다. 특히 대용량 데이터 또는 까다로운 실시간 수집 요구 사항을 처리할 때 이러한 최적화에 우선순위를 두십시오.