VisasQ Dev Blog

ビザスク開発ブログ

GCE での Elasticsearch サーバスペック見積もり検証 1

明けましておめでとうございます!ビザスクの検索エンジニア tanker です。

前職ではUGC サイトの検索周りなどをやっており、「ビジネス知見のデータベース」を作るというミッションに惹かれて昨年ビザスクにジョインしました。

ビザスク、AIにより最適なマッチングを実現  ~過去データを解析し最適なアドバイザーをスピーディーに提案~ (宣伝!) のリリースが無事できて少し時間ができたので、Elasticsearch の サーバ増強を行うにあたり、増強計画を立てるための検証を行いました。今回は、そのレポートをお送りします。

Elasticsearch の JVM 周りの検証は以前 ぴよたろうさんが行った 性能改善入門 をご覧ください。

ビザスクでの Elasticsearch 利用特性

ビザスクでは、Elasticsearch クラスタをユーザが利用する側と社内スタッフが利用する側の2系統運用しており、今回は社内スタッフが利用する側の話になります。

RM の北林さん (知見データベースのプロでグローバル事業にも全力投球な、RM北林の1日) らは検索のスペシャリストで、 Elasticsearch の query_string の書式を使って AND や OR や括弧などを自在に操って検索クエリーを作り 効率的に検索を活用してくれています。ただ一方で、大量にORでつながれた重いクエリーなどを使うことも多く、検索ページのレイテンシーが高くなってしまっています。まとめると、以下のような特性があります。

  • アクセス量は スタッフのみの利用のため 2~3QPS 程度と小さい
  • 検索クエリー自体は複雑で重いものが一定数ある

検証概要

検証の観点としては、現状のパフォーマンス(レイテンシー)改善及び将来のデータ数やアクセス数 (スタッフ数) 増加を考慮した 増設計画になります。具体的には、以下の通りです。

  • データ数、アクセス数が現状の状態で、コスパの良いサーバスペック構成は何か
  • データ数3倍、アクセス数3倍の状況になった場合にどのようなサーバ構成が必要か
    • さらに、フィールドが 2倍、3倍になったケースはどうか
    • さらに、index が 2個、3個になったケースはどうか

検証結果

  • 現行(current) のドキュメント数 (data) は 約10万、index サイズ (pri.store.size) は 1.9 GB
  • 検証時のアクセス量は 10 QPS
    • 負荷ツールからのアクセスは nginx 経由で upstream に サーバリストを追加しラウンドロビンで各 node にアクセスを分散
    • 検証は独立した環境で行っており、検証中ドキュメントの追加・更新は行われない
  • replica 数は、色々変えながら実施してその構成の中で最もよかったものを採用
  • shard 数は 5 固定 (検証項目が増えてしまうので)
  • 表は、左から サーバスペック、概算コスト (https://cloud.google.com/compute/all-pricing)、残りはテストケース毎にレイテンシー(sec) の 50% Tile(青)、95% Tile(緑) です。
    • サーバスペックの std-16 は GCP のマシンタイプで n1-standard-16 を示し、x1 は 1台構成という意味になります。(hic-32 は n1-highcpu-32)

コストとレイテンシー

現行のリクエスト量に合わせた結果

一部例外もありますが、大体コストと比例してレイテンシーも改善することが分かりました。ただ、やはり頭打ちな部分もあるので、そのあたりの見極めは大事かなと思います。

また、field を増やす場合と index を分ける場合だと、後者は増えても 1 index に対する レイテンシーはほとんど変わらないようですね。やはり 1 index のデータサイズ (field数、ドキュメント数) によるところが大きいようです。

メトリックも監視したのであわせてみてみます。

  • JVM のヒープサイズは 搭載メモリの 半分
  • New 領域は 5GB 固定
machine typespec
n1-standard-8Memory 30 GB CPU 8 core
n1-standard-16Memory 60 GB CPU 16 core
n1-highmemory-8Memory 52 GB CPU 8 core
n1-highcpu-32Memory 28.80 GB CPU 32 core

n1-highmemory-8 (data x3)

n1-standard-16 (data x3)

n1-highcpu-32 (data x3)

レイテンシーに一番影響が大きかったのが CPU の張り付き(左上のグラフ)で、core 数が増えるにしたがって張り付き時間が少なくなっていますね。逆にメモリー (右上のグラフ) はかなり持て余しているようです。ただ、 n1-highcpu-32 のグラフの後半は 次の検証用の reindex 時のものなのですが、メモリーが少ないと DISK IO が増えているのが確認できます (左下のグラフ)

n1-standard-8 (data x3, field x3)

n1-standard-16 (data x3, field x3)

n1-highcpu-32 (data x3, field x3)

field 数 3倍 (pri.store.size: 12.9 GB) なので、一番負荷が高かった時のものになります。各スペックで 3台、5台、7台構成の順でそれぞれ実施しているのですが、 CPU の張り付く時間が短くなっていることからも 負荷が分散されていることが分かります。また、index サイズが大きくなると メモリー不足で n1-standard-8, n1-highcpu-32 の DISK IO が増えていますね。とはいえ、レイテンシーを見る限りだと
n1-standard-16 より n1-highcpu-32 の方が小さいので、CPU を増やしたほうが効くという印象です。

今回の検証の結論としては、 n1-standard-8 をアクセス数、データ数増加に合わせて 3台、5台、7台と徐々にスケールアウトしていけばよさそうということになりました。

次回予告

具体的に検証でどのようなことを行ったのかを準備段階から分析段階まで書こうと思います。

  • オリジナルの index のみで data を増やしたり、field 増やしたり index を増やしたりする方法
  • 検証用の検索クエリーの抽出方法
  • 負荷ツールとして vegeta を使う方法
  • 監視用の agent を常駐させずにメトリックス監視をする方法

追記: 書きました GCE での Elasticsearch サーバスペック見積もり検証 2

謝辞

この場を借りて、この記事を書くためだけにアイコンを描いてくれた デザイナーの ながおかさん (LOLとビザスクとオタク) に感謝を。

一緒に働くエンジニアを募集中!

ビザスクではエンジニアを大募集中です! ビザスクに少しでも興味のあるWebエンジニアの方がいましたら、ぜひお話を聞かせてください!詳しい募集要項は下記リンクからアクセスしてください。