この記事は ただの集団 Advent Calendar 2020 の14日目です。
いま流行りのMacbookのM1チップとか、AWSのGraviton2とか、ARMアーキテクチャの話題が豊富な今日このごろ、 ふと「ElasticSearchってARM(aarch64)アーキテクチャで動作すること保証してるのかしら」ってのが気になり、 調べてみたら今年の初夏に出た7.8.0からサポートし始めたようなので、 これはいいということで試しに性能を測りつつx86版のものと比較してみる。
あとこれまでElasticSearchを触る機会がなかったので、 設定項目とかも全然わからないからそういうのを眺めたり手馴しをしたい的な意味合いでもある。
検証内容
Elastic社が公式にベンチマークツールを提供しており、、
その中にPMC(※)という論文データのインデクシングと全文検索を実行するものがあるのでこれを利用。
rally-tracks/default.json at master · elastic/rally-tracks · GitHub
※ PMC : 米国国立生物工学情報センター
この試験をCPUのコア数やRAMを揃えたx86_64とaarch64のマシンを3台用意し、 それぞれでシングルノードでElasticSearchが動くようにし、 PMCベンチマークを3回ずつ実行する。 つまりCPUアーキテクチャごとに9件の結果が得られるのでその平均を取る。
なおRallyのデフォルトだとベンチマークとElasticSearchは同居する想定のようだが、 今回は条件を揃えるために別途Rally用のベンチマークサーバを建ててそこからElasticSearchを呼び出す形とする。
項目としては主に処理のスループットとレイテンシでまとめていく。
検証環境
環境の構築手順は予め別の記事にしておいたのでそちらを参照 jsoizo.hatenablog.com
結論
場合によってx86のほうが良いケースもあるが、総合してaarch64版のほうがパフォーマンスは良い。
インデックス時はaarch64がx86比でレイテンシ70%スループット140%と極めて良好。 検索クエリの投下時はスループットにほぼ差がないが、 レイテンシが条件によっては80~90%ほど低くなるという結果だった。
インデックスの速度が極めて早いのはデータの投入/更新頻度が高かったり量が多いケースを想定するととても有用。 また、クエリに対するレイテンシの向上はユーザ体験を良くするし、 スループット据え置きでサーバ代がm6g(aarch64)はm5比で80%程度となるためクエリあたり費用が80%となる。 (※ m6g.xlarge: $0.198/h m5.xlarge $0.248/h) コストカットとユーザ体験向上の両方得られるというのは素晴らしい。
ここからは仮説だが、インデックスのパフォーマンスからもわかるように、 比較的CPU負荷の高いようなクエリの場合(たとえば日本語の形態素解析があるとか)、 aarch64版のほうがパフォーマンスが良いという可能性があるかもしれない。と予想している。
結果(青: aarch64, 橙: x86-64)
インデックス
スループットは約1.4倍ほどaarch64インスタンスのほうが高い。
レイテンシは99%tileでaarch64が72%ほど速い。
クエリ(単語検索)
termとphraseのクエリ実行でそれぞれスループットとレイテンシが計測されている。 - term: 1単語のみ - phrase: 複数の単語
スループットはほぼ差なし。
レイテンシは99%tileでは極端な差は出ていない。 termではaarch64のほうが7,8%ほど高速ではある一方でphraseになると18%くらいになる。 想像だが、構文解析とかにかかるCPU時間の差だろうか。
集計クエリ
PMCの月間論文数集計のクエリ。 キャッシュあり&なしそれぞれでの結果。
スループットはまったく差なし。
レイテンシはこれまでと違ってややx86のほうが良いという評価。 キャッシュありの90%tile以下はaarch64のほうが速いがそれ以外はx86のほうが良い。 aarch64の方で99%tile, 100%tileでの結果が悪いということを考えると極端に遅いときがあったのかもしれない。
スクロール(全件取得)
スループットはほぼ差なし。 0.001%程度aarch64のほうが速いという結果ではあったが誤差だと思う。
レイテンシはaarch64が90%程度速いという結果になった。
感想
インストールしたり起動するときの体感速度でaarch64版のほうが早かったのだが、 それを裏付けるかのようにベンチマークもaarch64版のほうが レイテンシも低くスループットも出そうだという結果が得られた。
日本語の処理に関してどうなのとかそもそも動くのかとか、 気になる点はいくつかあるが、ワクワクはするよね。とても。
事前の調べが足りなかったのがちょっと悔しいのでオレオレ負荷試験項目を作るのとかやりたいね。 それはそれでブログのネタにしましょう。
あと、書いてから気づいたが99%tileとかで出しているものに対して平均を取るのは微妙かもな。。。
余談
事前の調査が足りてなくて、、、、、、 これを書いたあとでARM社のサイトにほぼ同じ内容がまとまってた。 つかってるインスタンスタイプとかまで一緒だったかなしい。
ほぼトレースだったとしても自分でやれたことに意味があったと思いたい。
余談その2
サーバを建てるときにスポットリクエストをなぜか永続で出していて、 使い終わったインスタンスをteminateしたことに満足し スポットリクエストをキャンセルし忘れました。
余談その3
m6g.xlargeとm5.xlargeは料金表上においては前者のほうが20%程度お安くなっているのだが、 スポットインスタンスの履歴を見る限りだとほぼ変わらずむしろ後者のほうが高い。 下図は時間幅を1ヶ月にしているが、3ヶ月とかの単位でみてもこの傾向っぽいので長期トレンドっぽい。
データ
置いておいた docs.google.com
