エンジニアリング

Rally登場:Elasticsearchのベンチマークツール

本日、これまでElasticsearchの社内開発チームが数か月使用してきたベンチマーキングツール、Rallyを一般公開することになりましたので、お知らせいたします。

Elasticsearch社内の環境で実現されたパフォーマンス値をコミュニティのユーザーにも再現してもらえるように、そして細かいことを気にせずにベンチマークを書けるように、ここでみなさまと共有したいと思います。

Rallyの生い立ち

Rallyは、Elasticsearchの夜間ベンチマークLuceneの夜間ベンチマークを駆動するPythonスクリプトから誕生しました。

Elasticsearch Classic Benchmarks

ベンチマーキングインフラは、茹でガエル現象(つまり、 知らぬ間に低下していくパフォーマンス) を回避するのに大変有効です。Elasticsearchのさまざまな面の改良を進める中で、Elasticsearchではパフォーマンスについても大きな関心を持っています。開発者が自分でベンチマークを実行できれば、マスターブランチに機能を統合するまで待つのではなく、早期の段階で変更の影響がどれほどかを調べることができます。

開発者はそもそもクリエイティブな人間が多いので、得意な言語でにわか仕立てのスクリプトを書いて、それぞれのユースケースに実行することはいつでもできます。ただし、計測された数値をきちんと確認している人はいるでしょうか?

そこで、次善の策として、既存のベンチマークスクリプトをローカルで使用してみましたが、セットアップに必要な手作業が多くて大変でした。それでインストールと使用法を簡略化することにしました。 Rallyの誕生です。

Rallyでできること

この数か月でRallyでサポートされる機能が徐々に増えていきました:

ベンチマーク測定の対象動作の詳細な解析用に、いわゆるテレメトリーデバイスを接続できます。たとえば、Java flight recorderでさまざまな問題を発見することができました。RallyとJava flight recorderでできることの一部をご紹介します。

割り当てのプロファイル作成

Allocation Profiling with Java Mission Control

Elasticsearchのホットなクラスを特定する

Inspecting hot classes in Elasticsearch with Java Mission Control

JITコンパイラーテレメトリーデバイスも追加されました。このデバイスにより、たとえばベンチマーク測定中のウォームアップ時間の解析など、JITコンパイラーの動作を調べることができます。以下の図は、ベンチマーク測定中のJITコンパイラーイベントの数を示します。

JIT compilations over time

Elasticsearchのような複雑なシステムのパフォーマンス評価にも非常に多面的な問題が伴います。たとえば、ログデータの検索などの1つのシナリオではパフォーマンスが向上しても、フルテキスト検索ではパフォーマンスが低下する、ということもありえます。したがって、複数のベンチマーク(Rallyでは「トラック」と呼ばれます)を定義することができます。このベンチマークはRallyのコードベースに直接実装されていますが、APIの方が安定性があるため、トラックを分けて自分のベンチマークを定義しやすくしたいと思っています。

RallyはすべてのメトリックをElasticsearchに保存するため、ベンチマーク中のCPUの使用量の分布など、簡単にKibanaでデータを視覚化できます。

CPU usage during a benchmark

最初はインデックスにベンチマークデータセットを追加します。その後、検索のベンチマークを実行します。インデキシングが完了する時点が明確に分かります。

また、今では夜間ベンチマークを並行して実行するようになり、結果をKibanaダッシュボードとして提供しています。

ロードマップ

まだ仕事はたくさん残っています:

大きな課題の1つが制限の撤廃です。ベンチマーク定義(「トラック」)をRally自体から分離して、ベンチマーク中にRallyが実行する手順にもっと柔軟性を持たせたいと思っています。現在、サポートされているシナリオはごく限られています。まず、すべてのドキュメントを一括でインデキシングし、クエリを何回か(回数はトラックによって異なります)実行します。デフォルトでは、geonames.orgのデータに基づいてベンチマークを実行しますが、他のトラックも使用できます( esrally list tracksを発行するだけです)。

2番目の大きな課題は、測定の精度を高めることです。精度については特に重視しており、すでにいくつかのトピックで改善が必要なことが分かっています。大きな問題の1つがCO(Coordinated Omission)によりレイテンシー測定の精度が低下する. ことです。これは、処理に時間がかかるリクエストによってベンチマークドライバーがその間にそれ以上のリクエストを送信できなくなり、測定サンプルが失われることを意味します。つまり、報告されるレイテンシーパーセンタイルの分布は実際より良く見えるのです。 3つ目の課題:現時点では、Rallyは1台のマシンのベンチマークのみに制限されています。

ただし、今後は複数台のマシンのベンチマークにも対応できるようにする予定です

最初のベンチマークの実行

上記のような課題を考慮した上で、自分のマシンでいかに簡単にベンチマークを実行できるかを説明しましょう。

前提条件がすべて整った状態でRallyのメトリックストアを起動 したとすると、次の3つの手順で最初のベンチマーク結果を得ることができます:

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

Rallyについてもっと知りたい場合は、 Rallyのプロジェクトページにアクセスして issuesを参照してください。またはトラックを提供するか、Rally自体の修正案を送って いただくことも歓迎いたします

記事のトップにある画像は Andrew Basterfieldから/CC BY-SAライセンス の下で (原典)ご提供いただきました。配色は変更されていますが、その他は原典画像から変更されていません。