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

Elasticsearch 색인 성능은 수집 파이프라인이 백업되기 시작하거나, 대량 요청이 거부되거나, 쓰기가 많은 동안 검색 속도가 느려질 때 눈에 띄게 됩니다. 해결책은 단 하나의 마법 같은 설정이 아닙니다. 요청 크기, 새로고침 동작, 매핑, 샤드 레이아웃, 하드웨어를 함께 튜닝해야 합니다.

이 가이드는 대규모 수집 작업 전과 중에 적용할 수 있는 실용적인 Elasticsearch 색인 성능 점검에 초점을 맞춥니다. 문서 크기, 분석기, 스토리지, 복제본 수에 따라 결과가 달라질 수 있으므로 자체 클러스터의 메트릭과 함께 사용하세요.

색인 프로세스 이해

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

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

여러 요인이 Elasticsearch가 문서를 색인하는 속도에 큰 영향을 미칠 수 있습니다.

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

색인 성능 최적화: 모범 사례

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

1. 벌크 API 활용

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

벌크 API 모범 사례:

• 배치 크기: 배치 크기를 실험해 보세요. 작은 페이로드로 시작한 다음 색인 지연 시간, 메모리 압력, 429 거부를 관찰하면서 늘리세요. 문서 수만으로는 충분하지 않습니다. 한 문서는 매우 작을 수 있고 다른 문서는 수 메가바이트일 수 있기 때문입니다.
• 동시성: 여러 스레드 또는 비동기 클라이언트를 사용하여 벌크 요청을 동시에 보내세요. 그러나 클러스터에 과부하가 걸리지 않도록 주의하세요. CPU 및 I/O 사용량을 모니터링하여 최적의 지점을 찾으세요.
• 오류 처리: 강력한 오류 처리를 구현하세요. 벌크 API는 응답 배열을 반환하며 각 작업의 상태를 확인해야 합니다.

벌크 요청 예시:

{ "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)

새로고침 간격은 데이터가 검색에 표시되는 빈도를 제어합니다. 일반적으로 활성 인덱스는 검색 중일 때 약 1초에 한 번씩 새로고침되지만 기본값은 버전과 인덱스 유형에 따라 다를 수 있습니다. 색인이 많이 발생하는 동안 이 간격을 늘려 새로고침 작업을 줄일 수 있습니다. -1로 설정하면 자동 새로고침이 비활성화되어 수동으로 새로고침하거나 자동 새로고침을 복원할 때까지 데이터를 검색할 수 없습니다.

• 권장 사항: 대량 색인 작업의 경우 검색 최신성이 필요하지 않을 때 index.refresh_interval을 일시적으로 늘리거나 -1로 설정하세요. 대량 작업이 완료된 후 일반 검색 동작에 사용하는 설정을 복원하고 필요한 경우 수동 새로고침을 실행하세요.

인덱스 설정 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. 매핑 최적화

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

• 대규모 데이터 세트에 동적 매핑 사용 피하기: 편리하지만 동적 매핑은 매핑 폭발과 예상치 못한 필드 유형으로 이어질 수 있습니다. 특히 대용량 데이터의 경우 인덱스에 대한 명시적 매핑을 정의하세요.
• 적절한 데이터 유형 선택: 가장 효율적인 데이터 유형을 사용하세요. 예를 들어, 전문 검색이 필요하지 않은 경우 text보다 keyword가 정확한 값 일치에 더 효율적입니다.
• 불필요한 기능 비활성화: 특정 필드에 대해 norms와 같은 기능이 필요하지 않은 경우(예: 정확한 일치 또는 집계), 비활성화하면 공간을 절약하고 색인 속도를 향상시킬 수 있습니다(norms: false). 마찬가지로 필드에 대한 정렬 또는 집계에 필요하지 않은 경우 doc_values를 비활성화하세요. 그러나 doc_values는 일반적으로 집계 및 정렬에 유용하므로 미묘한 결정이 필요합니다.
• _source 필드: 원본 JSON 문서가 필요하지 않은 경우 _source를 비활성화하면 디스크 공간과 일부 I/O를 절약할 수 있지만, 재색인이 불가능해지고 디버깅이 어려워집니다. 활성화된 상태로 유지하는 경우 _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 성능에 도움이 됩니다.
• 수집 및 조정 용량: 매우 높은 수집 속도의 경우 파이프라인 전용 수집 노드 또는 클라이언트 벌크 트래픽 전용 조정 노드를 고려하세요. 데이터 노드는 여전히 실제 색인 작업을 수행하므로 CPU, 메모리 또는 디스크 I/O가 부족하지 않도록 하세요.
• 네트워크: 클라이언트와 Elasticsearch 노드 간, 그리고 클러스터 내 노드 간에 충분한 대역폭과 낮은 지연 시간을 보장하세요.

5. 샤드 크기 및 개수

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

• 권장 사항: 대량의 데이터를 색인하기 전에 기본 샤드 수를 계획하세요. 일반적으로 재색인 없이 기존 인덱스의 기본 샤드 수를 변경하는 것은 권장되지 않습니다.

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

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

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

실용적인 핵심 사항

벌크 색인, 명시적 매핑, 충분한 디스크 I/O로 시작하세요. 일회성 로드의 경우 검색 최신성 또는 중복성이 감소된 상태를 감당할 수 있는 동안에만 새로고침 및 복제본을 완화한 다음, 정상 설정을 복원하고 클러스터 상태를 확인하세요. 실제 문서로 계속 테스트하세요. 일반적인 배치 크기와 샤드 수는 시작점일 뿐입니다.