오늘, Elasticsearch 개발 팀에서 지난 몇 달 동안 내부적으로 사용해온 벤치마킹 도구인 Rally의 퍼블릭 릴리즈를 최초로 발표하게 되어 기쁘게 생각합니다.

이제 커뮤니티와 Rally를 공유함으로써 귀사가 자체 환경에서 Elasticsearch가 제시한 성능 수치를 재현하고 수많은 사소한 세부 사항에 대한 걱정 없이 자체 벤치마크를 마련하는 데 도움을 줄 수 있을 것으로 기대합니다.

Rally의 기원

Rally는 야간 Elasticsearch 벤치마크 및 Lucene의 야간 벤치마크를 구동시키는 Python 스크립트에서 시작되었습니다.

벤치마킹 인프라는 끓는 물 속의 개구리 문제(즉, 천천히 저하되는 성능)를 피하는 데 큰 도움이 됩니다. Elasticsearch는 모든 분야에서 계속 개선되고 있으며 성능에 대해서도 심도 깊은 주의를 기울이고 있습니다. 개발자가 마스터 분기에 특정 기능이 통합될 때까지 기다리지 않고 직접 벤치마크를 실행하여 개발 단계에서 변화의 영향을 초기에 파악할 수 있다면 큰 성과를 기대할 수 있을 것입니다.

개발자는 일반적으로 창의적인 사고를 갖고 있으므로 언제라도 원하는 언어로 간단한 스크립트를 작성한 후 특정 용도에 맞게 실행해보고 이후에는 스크립트에 대해 잊어버릴 수 있습니다. 그렇다면 이들 수치를 실제로 검증해보는 빈도는 어느 정도일까요?

기존 벤치마크 스크립트를 로컬로 사용하는 차선책을 시도해봤지만 셋업 과정에서 여러 수동 단계가 포함되었습니다. 이에 설치 및 사용 방법을 간소화하기로 결정했으며 그 결과로 Rally가 탄생했습니다.

Rally는 어떤 기능을 갖고 있습니까?

지난 몇 달 동안 Rally는 점점 더 많은 기능을 지원해 오도록 발전해 왔습니다.

벤치마크 후보 행동에 대한 세부 분석을 위해 소위 말하는 원격 측정 기기를 연결할 수 있습니다. 예를 들어 Java flight recorder로 다양한 문제를 파악할 수 있었습니다. 다음은 Rally와 Java flight recorder 원격 측정 장치로 수행할 수 있는 작업의 몇 가지 예입니다.

할당 프로파일링 (Allocation Profiling)

Elasticsearch로 핫 클래스 조사

또한 예를 들어 벤치마크 도중 준비 시간을 분석하기 위해 JIT 컴파일러 작동을 조사할 수 있는 JIT 컴파일러 원격 측정 장치를 추가했습니다. 아래 그래픽은 벤치마크 도중 JIT 컴파일러의 수를 보여줍니다.

Elasticsearch와 같은 복잡한 시스템의 성능을 평가하는 것은 매우 다차원적인 문제이기도 합니다. 특정 시나리오(예를 들어 로그 데이터 분석)에서는 성능이 향상될 수 있더라도 전문 검색에는 부정적인 영향을 미칠 수 있습니다. 따라서 여러 벤치마크를 정의할 수 있으며 Rally에서는 이를 "트랙"이라고 합니다. 이들 벤치마크는 현재 Rally 코드 베이스에서 직접적으로 구현되지만 API가 안정화될수록 트랙의 구분이 더 수월해지며 트랙을 직접 정의하는 것이 더 쉬워질 것입니다.

Rally는 모든 메트릭 데이터를 Elasticsearch에 저장하므로 벤치마크 도중 CPU 사용량 분산과 같이 Kibana로 데이터를 쉽게 시각화할 수 있습니다.

먼저 벤치마크 데이터 세트를 index에 추가합니다. 그 다음 검색 벤치마크를 실행합니다. 인덱싱이 완료되는 시점을 명확하게 확인할 수 있습니다.

또한 이제 야간 벤치마크를 동시에 실행하고 그 결과를 Kibana 대시보드로 제공하기 시작했습니다.

로드맵

그러나 아직도 해야 할 일은 많습니다.

한 가지 중요한 주제는 제한 사항을 제거하는 것입니다. Rally와 벤치마크 정의("트랙")를 구분해야 하며 벤치마크 도중 Rally가 수행하는 단계에도 보다 많은 유연성을 허용해야 합니다. 현재까지는 먼저 모든 문서를 벌크로 인덱싱한 다음 트랙에 따라 다른 횟수의 쿼리를 실행하는 아주 제한적인 시나리오만 지원됩니다. 기본적으로는 geonames.org의 데이터를 기반으로 벤치마크를 실행하지만 트랙을 더 사용할 수도 있습니다(esrally list tracks 발행).

두 번째 중요한 주제는 측정의 정확성을 향상시키는 것입니다. 정확성이 중요한 만큼 개선이 필요한 몇 가지 주제를 이미 파악하고 있습니다. 주요 문제 중 하나는 조율된 누락(coordinated omission)에 따른 지연 시간 측정입니다. 이는 기본적으로 요청을 처리하는 데 시간이 오래 소요되는 경우, 벤치마크 드라이브가 도중에 추가 요청을 보내지 못하므로 측정 샘플을 잃게 됨을 의미합니다. 이 경우 보고된 지연 백분위수 분포가 실제보다 좋게 나타납니다.

세 번째로, Rally는 현재 단일 머신 벤치마크로 제한되지만 향후 다중 머신 벤치마크가 허용될 예정입니다.

첫 번째 벤치마크 실행

이제 실제 머신에서 벤치마크를 실행하기가 얼마나 쉬운지 알아보도록 하겠습니다.

모든 필수 소프트웨어를 설치하고 Rally의 메트릭 저장소를 시작한 것으로 가정할 때 다음과 같은 3단계 프로세스를 통해 첫 번째 벤치마크 결과를 얻을 수 있습니다.

pip3 install esrally
esrally configure
esrally --pipeline=from-distribution --distribution-version=5.0.0-alpha1

Rally에 대해 좀 더 자세히 알고 싶으시면 Rally 프로젝트 페이지로 이동하여 몇 가지 사안을 확인하거나 Rally에 트랙 또는 변경 사항을 제공하여 도움을 주십시오.

포스팅 상단의 이미지는 Andrew Basterfield 가 CC BY-SA 라이센스(출처) 허가를 받아 제공한 것입니다. 이 이미지는 원본과 색상은 다르지만 형태는 변경되지 않았습니다.