giftee Tech Blog

ギフティの開発を支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信しています。

負荷試験ツールのお引越しを検討しました

こんにちは、エンジニアの toki です。個人向けの eGift サービスの開発をしています。ギフティでは今のところインフラのお仕事が多いですが、フロントエンドエンジニアを自称しています。

今回は負荷試験ツールのお引越しを迫られたので、それについてお話しします。

「負荷試験ツール」って?

個人的な感想ですが、「負荷試験ツール」というワードについて語られる際、以下の2つの文脈があいまいなまま語られていることが多いように感じています。この記事ではまず言葉の定義についてはっきりさせておきます。

1: 負荷試験のリクエストシナリオを記述できるツール
これは実際に試験する内容(リクエストの内容や負荷の程度など)を設定できるツールを指しています。具体的なプロダクト例をあげると Apache JMeterk6, Gatling などが該当します。

2: 負荷シナリオを実行してくれるクラウドサービス
1 のシナリオツールを使えば、自分で用意したサーバから負荷をかけて試験することはできます。

ただ、ひとくちに「負荷試験」といっても奥が深く、「負荷シナリオを実行し、測定する側」がうまく動いていないと、対象のシステムのボトルネックを正しく測定出来ません。またこういったインフラを負荷試験のたびに用意するのは非常に大変です。

なのでシナリオファイルをアップロードするだけでリソースを用意し、正しくシナリオを実行してくれるクラウドサービスを利用することには大きなメリットがあります。さらに、測定結果をいい感じに集計してわかりやすく表示してくれるのもありがたいです。

具体的なプロダクト例をあげると Tricentis FloodGrafana Cloud k6, BlazeMeter などがあります。

今回話すことは?

私の所属するチームではこれまで以下のツールを使って負荷試験を定期的にやっていました。

  • シナリオ記述ツール: Apache JMeter
  • クラウド負荷 SaaS: Tricentis Flood

しかし、Tricentis Flood が 2024/06/30 に end of life (EOL) となることが発表されました。

Tricentis 社は後継として Tricentis NeoLoad というサービスをリリースしており、こちらに乗り換えることを推奨しているようです。

ただ、調べてみたところ利用開始価格が 20,000 USD で詳細は要相談と、それなりの規模の顧客を想定しているようでした。そのため、この機会に開発チームでは移行先を探すこととなりました。

ですので話の主軸としては「2: 負荷シナリオを実行してくれるクラウドサービス」になりますが、これらのサービスはユーザーが用意したシナリオファイルを解釈して負荷をかけるという仕組み上、サポートされているシナリオファイル次第では「1: 負荷試験のリクエストシナリオを記述できるツール」も変わる可能性があります。

今回は移行のハードルも考慮して、「1: Apache JMeter を引き続き利用するケース」「2: Apache JMeter 以外を利用するケース」の2ケースで検討しました。

移行先に求める条件

移行にあたって、開発チームが負荷試験ツールたちに求める条件を整理しました。

Must have なもの

  • アウトバウンド IP を固定できること
    • 試験対象が非公開のシステムなので IP 制限をかけたいが、クラウドサービスからの通信だけは受け付けたいため

Nice to have なもの

  • シナリオの記載、管理が楽
  • ドキュメントが豊富
  • 結果がグラフで見やすい
  • 6月末の Flood EOL までに移行が完了すること
    • 開発スケジュールによっては調整できるかも

選択肢の調査

負荷シナリオ記述ツール + クラウド負荷実行サービスの組み合わせで検討してみます。選択肢の調査には以下の記事を参考にさせていただきました。

【2024年版】おすすめパフォーマンステストツール26選
【負荷テスト入門編】6つの負荷テストツール(サービス)を解説!

非常に多くの選択肢があるため、そのすべてを検討するのはなかなか難しいところです。ですので今回は「サポートされているプログラミング言語」、「クラウドサービスでのサポート状況」などである程度絞り込み、その後詳細な比較検討をすることとしました。

なお、今回は「クラウド負荷実行サービスを使う」という前提で検討しているのですが、自前で負荷環境を用意する場合はシナリオ記述ツールの制約がなくなるため、より多くのシナリオ記述ツールの選択肢が生まれると思います。ツールとしては以下のようなものがありますので、興味のある方は調べてみてください!(Vegeta は名前がとてもイカしていますね)

勤め人の性でこれ以上は怒られてしまいますので、ご自身の目で確かめてみてください

1: k6 + Grafana Cloud k6

k6、Grafana Cloud k6 はともに Grafana Labs が提供している負荷試験のためのツールで、k6 が JavaScript ベースのシナリオ記述 OSS、Grafana Cloud k6 が k6 サポートのクラウド負荷実行 SaaS になります。

アウトバウンド IP を固定できること: ◯
static IP を購入することで実現できそうです。

シナリオの記載、管理が楽: ◎
k6 の書き味は JavaScript でアプリケーションの HTTP リクエストコードとほぼ同じように見えます。何が書かれているか非常にわかりやすいです。Method や Function も書けるので、管理がしやすそうです。一方で GUI などはないので、非エンジニアの方だとツラいかもしれません。

また、JavaScript のコードであれば GitHub などでシナリオを管理するのも問題なさそうです。

k6 の 公式 Document より抜粋

ドキュメントが豊富: ◎
公式ドキュメント(k6, Grafana Cloud k6)が豊富に感じます。コードサンプルが書いてあるのはありがたいですね。また多くのやってみた系記事もあり助かります。

結果がグラフで見やすい: ◯
レポート機能については、k6 単体では非常にシンプルなレポーティングになっていますが、Grafana Cloud k6 では非常に高機能なレポートダッシュボードが用意されています。開発元の Grafana Labs は Grafana や Kibana などのデータ可視化ツールを多く提供しており、そのノウハウはここにも活かされているようです。

k6 の 公式 Document より抜粋

Grafana Cloud k6 の 公式 Document より抜粋

6月末の Flood EOL までに移行が完了すること: △
Apache JMeter から k6 へのシナリオ移行が必要になりますが、今回はここのコスト感を正確に見積もれていません。とはいえ全く間に合わないという温度感でもないので △ としています。

その他
料金を見てみると、VUH に応じた従量課金のようです。VUH (Virtual-User Hours)とは、直訳すると「仮想ユーザー時間」なのですが、おおむね負荷シナリオをリクエストするスレッド数 x 時間によって計算されます。つまり「大量のリクエストを長時間投げると多くのコンピュータリソースを必要とするため、その分料金が高くなる」と認識いただければ分かりやすいかと思います。

2: Apache JMeter + BlazeMeter

Apache JMeter は長く負荷試験のシナリオツールとして使われており、JMeter 単体での機能が豊富なことが特徴です。

BlazeMeter は JMeter のシナリオをクラウドで実行してくれるサービスです。同社が提供しているTaurusを利用することで、JMeter 以外にも Gatling や Locust, k6 などの多彩なシナリオツールを利用できるのが特徴です。

アウトバウンド IP を固定できること: ◯
専用 IP を購入することで実現できそうです。

シナリオの記載、管理が楽: ◯
Apache JMeter は GUI で手軽にシナリオが書けるのが大きな特徴です。

また非常に多彩なシナリオを書くことができます。GUI にない複雑なことをしたい場合は、JMeter のベースになっている Java のコードを記載することができます。

ただし、ファイルが XML 形式のため、GUI を使わずにファイルを読むのはかなり難しいです。シナリオファイルを Git 管理したりする場合、ファイル差分を見ても直感的に理解するのは難しいかもしれません。

Apache JMeter の GitHub Repository README より抜粋

ドキュメントが豊富: ◯
JMeter は公式ドキュメント の他、GUI の操作に関しては Youtube などの動画も多く上がっています。ただ、テキストに比べると時間がかかったり、目当ての情報にたどり着くのに時間がかかるかもしれません。

BlazeMeter も公式ドキュメントがあり、内容も充実していそうです。

結果がグラフで見やすい: ◯
JMeterBlazeMeterともにレポート機能は強力です。

Apache JMeter のユーザーマニュアルより抜粋

BlazeMeter の公式ドキュメントより抜粋

6月末の Flood EOL までに移行が完了すること: ◯
Apache JMeter シナリオをそのまま使うため、移行のハードルは高くないと予想しています。

その他
BlazeMeter の料金はプランごとに固定のようです。プランごとに VUH の上限が決まっており、それを超えるとプランがグレードアップされる、といったところでしょうか。ある程度以上の VUH を超えるとプランが Unleashed になり、応相談といった形になるようです。

3: Apache JMeter + Distributed Load Testing on AWS

Distributed Load Testing on AWS は AWS が負荷試験というユースケースのために用意してくれている CloudFormation Template のことです。そのため正確には「SaaS」ではなく「自前の AWS 環境にサーバを簡単に立てられるツール」だと思っていただければいいと思います。

アーキテクチャとしては Amazon API Gateway, AWS Lambda, AWS Fargate などオーソドックスな構成のようです。よく見ると BlazeMeter 社の Taurus も利用しているようですね。

Distributed Load Testing on AWS の実装ガイドより抜粋

アウトバウンド IP を固定できること: △
負荷シナリオリクエストを実行する AWS Fargate の IP を指定すれば実現できそうです。ただし、そのままの構成ではアーキテクチャを構築するたびに IP が変わってしまうため、CloudFormation Template をカスタマイズするか、負荷を受けるサービスインフラ側で都度許可する IP を変更する必要がありそうです。

シナリオの記載、管理が楽: ◯
シナリオツールとしては Apache JMeter を前提にして組まれているようです。

Apache JMeter については 2 に記載していますので割愛します。

とはいえ中身は Cloud Formation Template なので、これをベースにカスタマイズするのもできそうです。

ドキュメントが豊富: △
Apache JMeter については 2 に記載していますので割愛します。

Distributed Load Testing on AWS については実装ガイドや実際の利用方法などの解説もあり、始めるハードルは低そうです。

大規模な負荷テストを実行可能。「Distributed Load Testing on AWS」 を試してみる

ただ、それ以上のトラブルシュートなどをしようとすると AWS の各リソースのドキュメントなどを参照する必要があり、ある程度 AWS に慣れている方を前提にしているように思います。

結果がグラフで見やすい: ◯
Web ベースのシンプルなレポートダッシュボードが用意されているようです。

Distributed Load Testing on AWS の公式ドキュメントより抜粋

またこのレポートは Taurus のものを利用しているようで、Taurus の設定を変更することである程度カスタマイズができそうです。

6月末の Flood EOL までに移行が完了すること: ◯
Apache JMeter シナリオをそのまま使えるところは有利なのですが、構築がすんなりいくかが心配ではあります。

その他
料金は当然ですが AWS リソースの従量課金のみです。

自前で全部作るのは大変、かといって SaaS は高い... というバランスを取りたい方向けでしょうか。

結局どうした?

実は今回はまだ意思決定まで進めていません。というのも今回の検討では「移行コスト」について見積もれていないためです。

とはいえすべての選択肢に対して見積もりを出すというのは非常にコストのかかることなので、今回はその前段の絞り込みを行いました。

結果として、以下二択までは絞り込めました。

1: Apache JMeter を引き続き利用するケース
=> Apache JMeter + BlazeMeter

2: Apache JMeter 以外を利用するケース
=> k6 + Grafana Cloud k6

個人的にはシナリオのメンテナンスを長期的にしていくことを考えると k6 + Grafana Cloud k6 がいいなと思っており、移行コストも加味したうえでできればそちらに倒したいと思っています。がんばります。

実際の移行については今後の記事でお話しできればいいなと思っていますので、気長にお待ち下さい。

おわりに

今回は負荷試験ツールの技術選定についてお話ししました。

負荷試験というもの自体、サービスが小さいうちはあまり意識することは少ないかもしれません。(特に近年はインフラをクラウドで構築するのが主流になってきており、何も考えなくてもある程度の負荷に耐えられるインフラが手軽に作れるようになってきています。)ギフティの中でも負荷試験の頻度や規模はチーム、プロダクトによってまちまちです。

しかしサービスがある程度大きくなってくると、「サービスを安定して動かしながら新しい価値を提供する」ハードルはどんどん上がっていきます。負荷試験はそれをやりやすくするためのソリューションの一つであり、長くサービスを続けているといずれ必要になってくるものです。

今回の記事は「負荷試験というものはなんとなく知っているけれど実際どうすればいいのかわからない」というレベル感の方に対して、その先に進む足がかりになればと思い書いています。もし負荷試験の必要性を感じている方がいれば、これを機に負荷試験を始めてみるとよいと思います。

ギフティでは負荷試験をやる方もやったことがない方も大募集しています。カジュアル面談でぜひお話ししましょう。