4가지 Elasticsearch 성능 과제 및 해결 방법

Elasticsearch 확장

Elasticsearch는 로그 분석, 텍스트 검색, 실시간 분석 등에 사용하기 쉽게 시작할 수 있는 NoSQL 검색 및 분석 엔진입니다. 즉, Elasticsearch의 내부에는 최적의 성능을 달성하기 위해 활용해야 할 수단이 많은 복잡한 분산 시스템이 있습니다.

이 블로그에서는 느린 인덱싱, 검색 속도, 샤드 및 인덱스 크기 조정, 멀티 테넌시를 포함하여 규모에 따른 일반적인 Elasticsearch 성능 문제에 대한 솔루션을 안내합니다. 많은 솔루션은 대규모 시스템 운영 경험이 있는 엔지니어링 리더 및 설계자와의 인터뷰 및 토론에서 비롯됩니다.

Elasticsearch에서 인덱싱 성능을 어떻게 향상시킬 수 있나요?

쓰기 처리량이 높은 워크로드를 처리할 때 Elasticsearch를 조정하여 인덱싱 성능을 높여야 할 수도 있습니다. 작업이 애플리케이션의 검색 성능에 영향을 미치지 않도록 인덱싱을 위한 적절한 리소스를 확보하기 위한 몇 가지 모범 사례를 제공합니다.

• 새로 고침 간격 늘리기: Elasticsearch는 인덱스를 새로 고쳐서 새 데이터를 검색할 수 있게 만듭니다. 인덱스가 지난 30초 동안 쿼리를 수신하면 새로 고침이 1초마다 자동으로 발생하도록 설정됩니다. 새로 고침 간격을 늘려 인덱싱을 위해 더 많은 리소스를 예약할 수 있습니다.

  
  

• Bulk API 사용: 대규모 데이터를 수집할 때 Update API를 사용하여 인덱싱하는 데 몇 주가 걸리는 것으로 알려져 있습니다. 이러한 시나리오에서는 대량 API를 사용하여 보다 리소스 효율적인 방식으로 데이터 인덱싱 속도를 높일 수 있습니다. 대량 API를 사용하더라도 클러스터 성능을 방해하지 않도록 인덱싱된 문서 수와 대량 요청의 전체 크기를 알고 싶을 것입니다. Elastic에서는 대량 크기를 벤치마킹할 것을 권장하며 일반적으로 5~15MB/대량 요청 입니다.

  
  

• 인덱스 버퍼 크기 늘리기: 처리되지 않은 인덱싱 요청에 대한 메모리 제한을 기본값인 힙의 10% 이상으로 늘릴 수 있습니다. 이는 인덱싱이 많은 워크로드에 권장될 수 있지만 메모리를 많이 사용하는 다른 작업에 영향을 미칠 수 있습니다.

  
  

• 복제 비활성화: 인덱싱 속도를 높이기 위해 복제를 0으로 설정할 수 있지만 Elasticsearch가 워크로드에 대한 기록 시스템인 경우에는 권장되지 않습니다.

  
  

• 내부 upsert 및 데이터 변형 제한 : 삽입, 업데이트 및 삭제를 수행하려면 전체 문서를 다시 인덱싱해야 합니다. CDC 또는 트랜잭션 데이터를 Elasticsearch로 스트리밍하는 경우 다시 색인화할 데이터가 적기 때문에 더 적은 양의 데이터를 저장하는 것이 좋습니다.

  
  

• 데이터 구조 단순화: 중첩된 개체 와 같은 데이터 구조를 사용하면 쓰기 및 인덱스가 증가한다는 점을 명심하세요. 필드 수와 데이터 모델의 복잡성을 단순화하여 인덱싱 속도를 높일 수 있습니다.

Elasticsearch에서 검색 속도를 높이려면 어떻게 해야 합니까?

쿼리를 실행하는 데 너무 오랜 시간이 걸린다면 이는 데이터 모델을 단순화하거나 쿼리 복잡성을 제거해야 함을 의미할 수 있습니다. 고려해야 할 몇 가지 영역은 다음과 같습니다.

• 복합 인덱스 생성 : 두 개의 낮은 카디널리티 필드 값을 병합하여 쉽게 검색할 수 있는 높은 카디널리티 필드를 만듭니다. 예를 들어, 쿼리에 대해 일반적으로 필터링하는 두 개의 필드인 경우 우편번호 및 월이 포함된 필드를 병합할 수 있습니다.

  
  

• 문서의 사용자 정의 라우팅 활성화: Elasticsearch는 결과를 반환하기 위해 모든 샤드에 쿼리를 브로드캐스트합니다. 사용자 지정 라우팅을 사용하면 데이터가 어느 샤드에 있는지 확인하여 쿼리 실행 속도를 높일 수 있습니다. 즉, 사용자 지정 라우팅을 채택할 때 핫스팟을 주의 깊게 살펴보고 싶을 것입니다.

  
  

• 구조화된 검색을 위해 키워드 필드 유형 사용: ID, 우편번호 등 콘텐츠를 기준으로 필터링하려는 경우 더 빠른 검색을 위해 정수 유형이나 기타 숫자 필드 유형보다는 키워드 필드 유형을 사용하는 것이 좋습니다.

  
  

• 상위-하위 및 중첩 개체 에서 벗어나기: 상위-하위 관계는 Elasticsearch의 조인 지원 부족에 대한 좋은 해결 방법이며 수집 속도를 높이고 재인덱싱을 제한하는 데 도움이 되었습니다. 결국 조직은 이 접근 방식으로 인해 메모리 제한에 도달하게 됩니다. 이러한 경우 데이터 비정규화를 수행하여 쿼리 성능을 가속화할 수 있습니다.

규모에 맞게 Elasticsearch 샤드와 인덱스의 크기를 어떻게 조정해야 합니까?

Elasticsearch의 많은 확장 문제는 결국 샤딩 및 인덱싱 전략으로 귀결됩니다. 보유해야 하는 샤드 수 또는 샤드의 크기에 대한 모든 전략에 맞는 하나의 크기는 없습니다. 전략을 결정하는 가장 좋은 방법은 균일한 프로덕션 워크로드에서 테스트와 벤치마크를 실행하는 것입니다. 고려해야 할 몇 가지 추가 조언은 다음과 같습니다.

• 강제 병합 API 사용: 강제 병합 API를 사용하여 각 샤드의 세그먼트 수를 줄입니다. 세그먼트 병합은 백그라운드에서 자동으로 이루어지며 삭제된 문서는 모두 제거됩니다. 강제 병합을 사용하면 오래된 문서를 수동으로 제거하고 성능을 높일 수 있습니다. 이는 리소스 집약적일 수 있으므로 사용량이 가장 많은 동안에는 발생하지 않아야 합니다.

  
  

• 로드 불균형 주의: Elasticsearch에는 샤드별 리소스 활용도를 이해하고 샤드 배치를 결정할 때 이를 고려하는 좋은 방법이 없습니다. 결과적으로 핫 샤드가 발생할 수 있습니다. 이러한 상황을 방지하려면 데이터 노트보다 더 많은 샤드를 갖고 데이터 노드보다 작은 샤드를 갖는 것을 고려할 수 있습니다.

  
  

• 시간 기반 인덱스 사용: 시간 기반 인덱스는 보존 기간에 따라 클러스터의 인덱스 및 샤드 수를 줄일 수 있습니다. Elasticsearch는 또한 롤오버 인덱스 API를 제공하므로 연령이나 문서 크기에 따라 새 인덱스로 롤오버하여 리소스를 확보할 수 있습니다.

멀티 테넌시를 어떻게 설계해야 합니까?

다중 테넌트에 대한 가장 일반적인 전략은 고객 또는 테넌트당 하나의 인덱스를 보유하거나 사용자 지정 라우팅을 사용하는 것입니다. 워크로드에 대한 전략을 평가하는 방법은 다음과 같습니다.

• 고객 또는 테넌트별 인덱스: 고객별로 별도의 인덱스를 구성하는 것은 사용자 기반이 수백에서 수천 명에 이르는 소규모 회사 및 고객이 데이터를 공유하지 않는 경우에 적합합니다. 각 고객이 자신만의 스키마를 갖고 있고 더 큰 유연성이 필요한 경우 고객별로 인덱스를 갖는 것도 도움이 됩니다.

  
  

• 사용자 정의 라우팅: 사용자 정의 라우팅을 사용하면 문서가 상주하는 샤드(예: 고객 ID 또는 테넌트 ID)를 지정하여 문서를 인덱싱할 때 라우팅을 지정할 수 있습니다. 특정 고객을 기반으로 쿼리하는 경우 더 빠른 응답 시간을 위해 쿼리가 고객 데이터가 포함된 샤드로 직접 이동됩니다. 사용자 지정 라우팅은 고객 전체에 일관된 스키마가 있고 고객이 많을 때 좋은 접근 방식입니다. 이는 부분 유료화 모델을 제공할 때 일반적입니다.

Elasticsearch를 확장하거나 확장하지 않으려면!

Elasticsearch는 로그 분석 및 텍스트 검색 사용 사례를 위해 설계되었습니다. 대규모 실시간 분석을 위해 Elasticsearch를 사용하는 많은 조직은 쿼리 복잡성 및 데이터 수집 대기 시간 제한을 포함하여 성능 또는 비용 효율성을 유지하기 위해 절충을 해야 합니다. 사용 패턴을 제한하기 시작하거나 새로 고침 간격이 SLA를 초과하거나 함께 결합해야 하는 데이터 세트를 더 추가하는 경우 Elasticsearch에 대한 대안을 찾는 것이 합리적일 수 있습니다.

Rockset은 대안 중 하나이며 대규모 실시간 스트리밍 데이터 수집 및 대기 시간이 짧은 쿼리를 위해 특별히 제작되었습니다. Elasticsearch에서 마이그레이션하는 방법을 알아보고 두 시스템 간의 아키텍처 차이점을 살펴보세요.