簡単に負荷テストを実施したい！Hedgehogを利用した負荷テスト方法を実例で紹介！

WebサイトやWebサービスを運営していると、
・サイトがよく重くなる原因を知りたい
・現状のサーバーでどれだけのアクセスに耐えられるかを検証したい
と感じられることがあると思います。

そこで今回は、当サービス『Hedgehog』を利用した負荷テストのシナリオ作成および実行手順、結果の確認方法について詳しく解説します。

国産の負荷テストサービス『Hedgehog』とは？

HedgehogはWebサイトやシステムの性能や限界値を見極めるための負荷テストを実行できるサービスです。
Hedgehogは試験の工数を大幅に削減することができ、秒間10,000リクエストを超えるような大規模テストにも対応しています。

『Hedgehog』による概要試験テスト対象

試験対象用のサンプルとしてWordPressのサイトを用意しました。以下が環境情報です。

AWS EC2 t2.smallインスタンス
Amazon Linux2
PHP&php-fpm 7.4.12 / nginx 1.16.1 / MariaDB 5.5.68 / WordPress5.7.2

シナリオの作成

設定シナリオ

設定シナリオはシンプルなものとしました。対象サイトのトップ / を取得するだけです。WordPressで準備したサイトのトップページが表示されます。また、タイムアウト値はローダー（クライアント）側でリクエストに対するレスポンスを待つ上限時間です。この時間を超えても応答が得られない場合、タイムアウトとみなして接続を切ります。今回は応答性能の実測値を確認したいため、長めに30秒としています。

テストの多重度

設定内容

テスト実行時の仮想ユーザー数もシンプルな設定としました。
300秒かけて仮想ユーザー数を100仮想ユーザーに向けて徐々に増やしていきます。「繰り返し実行」モードの場合、秒間のリクエスト数制限はありませんので、各ユーザーはシナリオに定義されたリクエストを上から順番に実行する仕様です。
最後まで実行し終えたら、もう一度上からシナリオを繰り返します。
サーバーからのレスポンスを受け取り次第、次のリクエストを実行します。
従ってリクエストの頻度、回数はWebサーバー側の応答性能に依存して変化します。
上記の仮想ユーザー遷移の設定ですと、試験開始150秒後には50仮想ユーザーがリクエストを実行しています。
リクエストに対するサーバからの応答がちょうど1秒だと仮定した場合、その時点の秒間リクエストは50回が期待できます。
リクエストに対するサーバーからの応答が5秒だった場合は、10リクエスト/秒が期待できるということになります。

実行結果

上記実行結果から読み取れることはたくさんあります。以下に列挙します。

1. 5分間で合計2,155回リクエストを実行し、正常にレスポンスを取得できた回数が1,355回、エラーが800回だった
2. 仮想ユーザー数が徐々に増えるに従い、レスポンスタイムが伸びていくことがわかる。また、毎秒のリクエスト回数は1回〜15回程度の間で推移しており、仮想ユーザー数が増えても変化はない
3. 試験開始時から断続的に一部のリクエストがタイムアウト（30秒以内にレスポンスがなかった）し、15:36:00辺り（仮想ユーザーが最大の100名達した近辺）でHTTPステータス：502が返却されている。当該時間はデータ転送量グラフでも受信バイトがない状態が続いていることがわかる
4. レスポンスタイムの平均が9.2秒〜11.5秒だった

一般的にWebサーバーが同時に処理できるリクエスト数には上限があります。これはCPU、メモリ、WebサーバーやFastCGI実装のプロセス数、データベースの性能およびI/O性能、アプリケーション自体のオーバーヘッドなど様々な要因によります。
この試験結果より、仮想ユーザー数を増やしても処理できる秒間リクエスト数はほぼ一定であることがわかります。処理量を超えたリクエストを受け付けても、レスポンスまでの時間が伸びるだけです。Hedgehogを利用して徐々に多重度を増やす試験を行うことで、Webサーバーが一度に処理できるリクエスト数を計測することが可能です。

負荷リクエスト実行時のサーバーの状況

ボトルネックとなっている箇所を探るべく、topコマンドを実行すると以下のような状態であることがわかりました。

CPUをほぼ100%使い切っており、load average が40近い値になっています。
この結果から、同WebサーバーのCPU性能が本試験のリクエスト数を処理するには不足していることがわかります。
php-fpmおよびMariaDBが消費するCPU時間が多いことも特定できました。ページの参照アクセスでデータベースの負荷が上がるのはWordPressの設計上の仕様とも言えます。
また、502エラーが発生したタイミングでWebサーバーのerror.logに以下が出力されていました。

12021/05/20 16:19:59 [error] 3141#0: *3155 connect() to unix:/var/run/php-fpm/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 54.95.130.235, server: ec2-52-68-139-169.ap-northeast-1.compute.amazonaws.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/php-fpm.sock:", host: "ec2-3-114-18-151.ap-northeast-1.compute.amazonaws.com:80"

OSのリソースに余裕があるならphp-fpmの子プロセス数を増やすとか、backlogの設定でチューニングの余地がありますが、topコマンドの結果を見る限りでは難しそうです。

負荷試験(テスト)に基づく検証：インスタンスを上げて計測する

次にインスタンスサイズをt2.largeにアップして同じシナリオを同じ多重度で実行しました。前回と同じテストを実行する場合は、以下のようにテスト結果一覧の右メニューより、「再実行」ができます。多重度も同じように設定されます。

以下がt2.largeインスタンスでの結果です。

今度は100ユーザーまで仮想ユーザーが増えてもエラーは発生しませんでした。
同じ実行時間でテストを行ったにも関わらず、リクエストの合計数は3,180回となっています。これはレスポンス速度が上がったため、前回よりも大量のリクエストを実行することができた、ということです。
秒間のリクエスト数も5回〜15回程度の間を推移しています。
レスポンスタイムも平均5.3秒〜6.4秒と実用には多少不足しそうな結果ですが、t2.smallインスタンスよりは大幅に性能がアップしていることがわかります。

負荷テストに基づく改善策

このように特定のURLに対するアクセスが多いPHPのサイトではOPCacheが有効です。PHPのコードを事前コンパイル、最適化することで実行時のオーバーヘッドを減らす機構です。設定して計測してみました。

PHP 7.4.12 (cli) (built: Oct 27 2020 15:01:52) ( NTS )
2Copyright (c) The PHP Group
3Zend Engine v3.4.0, Copyright (c) Zend Technologies
4    with Zend OPcache v7.4.12, Copyright (c), by Zend Technologies

以下がPHPにOPCacheを組み込んだt2.smallインスタンスでの結果です。大幅にレスポンス性能が上がっていることがわかります。

リクエスト合計が12,124回ですので、t2.largeインスタンスの4倍ほどの性能を発揮できています。
一方で秒間リクエス数は35回〜40回程度の間を推移しており、Webサーバーが同時にリクエストを処理する性能が一定で頭打ちになる傾向は同じであることもわかります。
仮想ユーザーの数が増加するに従い、レスポンスタイムも合わせて伸びており、性能こそ異なるものの処理の傾向は同一の結果となっています。

まとめ

上記がHedgehogで負荷テストを実施する際の流れとなります。負荷テストは机上のシミュレーションや計算ではなく、実際に大量ユーザーからのアクセスが発生しているときと同じ状況を再現することができます。
システムの開発段階、リリース前に何度も大量アクセスを行ってサーバーのリソース状況やエラーの有無をモニタリングし、ボトルネックとなる箇所を特定することで、想定外のアクセスを考慮したアプリケーション、サーバーの設計を行うことができます。
ただしWebサーバーに大量のリクエストを実行するのはなかなか難しいものです。Hedgehogはそんな難題をクリアすべくクラウドに展開された負荷試験システムであり、サーバーやインフラの準備なしにいつでも大量のアクセスを発生させることができ、結果を視覚的にグラフ表示することで、実行→検証→改善までを一気通貫で行えます。
無料デモアカウントのお試しも可能ですので、ぜひこの機会にお試しください。