Webアプリケーション負荷試験実践入門

もうアラートなんて怖くない！
WEBアプリケーション負荷試験実践入門
株式会社ゆめみ仲川樽八

樽八って誰？
株式会社ゆめみ2001年度入社エンジニア
2000年頃から主にLAMP構成のWeb系ア
プリケーションの開発を行う。
近年はクラウドを前提としたシステムを中
心に高負荷アプリケーションの設計、開発を
手がけている。
プライベートでは4人の娘の父親。

• 負荷試験の重要性を認識して頂く
• 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く
このセミナーの目的

今回の負荷試験対象システム

負荷試験対象システム全体像
クラウド上でスケール可能なシステムを構成
Elastic Load
Balancing
Availability Zone Availability Zone
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
• LAMP構成のシステム
• WEBアプリケーションサーバはLBの後ろに設
置されている
• 全てAZ（データセンター）をまたいだ形で設置
し、単一障害点はない
• キャッシュを利用
• DBはスケールアップで対応
ElastiCache
ElastiCache

2. 負荷試験の目的と必要性

負荷試験の目的は何でしょうか？

特定の条件下でのシステム
全体のスループットを担保すること。
例：「一時間で○○万人の応募を受け付けます！！」
という数字を担保すること。
負荷試験の目的

…ではありません。
負荷試験で担保できるのは、
「○○以上の性能は出ません。」
という上限の数字です。
※実際の外部要因は全て
性能を落とす方向に動かします。
負荷試験の目的

実装されたアプリケーションが設計通りにス
ケール可能かどうかはわかりません！！
それを確認し、設計通りに動作することを担保
するのが負荷試験の目的です。
負荷試験の真の目的

高負荷の時はスケールアウトする
Elastic Load
Balancing
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
お金で解決する！

若干のメンテナンス時間さえ取れれば
スケールアップ出来る
RDS DB instance
xlarge
RDS DB instance
8xlarge
お金で解決する！

そう考えて負荷試験をしなかった、、、

WEBサーバを追加したのに、
DBサーバをスケールアップしたのに、
スループットは改善しない！！！
ということは往々にしてあります。

CPU負荷 100%張り付き
LOCK WAIT TIMEOUT
鳴
り
止
ま
な
い
電
話
Load Ave. 900??
既に8XLARGE使ってます！！
終
電
っ
て
何
？
媒体告知打っちゃったよ！！！

システムの性能担保ではなく、
実装が設計通りに動作することの担保
ですので、
開発者を守るために行うのが負荷試験です。

大前提として、
負荷試験の時間と予算は必ず確保する。
ただし、それに失敗した時も、時間、予算が無
いなりの負荷試験を行ないましょう。

やってはいけない
いきなり全体の負荷試験を行う

例えば、最初にシステム全体に対して負荷試験を行って
しまった場合において、システムが性能要件を満たさな
かったら、、、。

• 試験内容、方法に問題がある
• インフラに問題がある
• LBに問題がある
• ネットワークに問題がある
• ミドルウエア設定、カーネルパラメータ設定に問題がある
• アプリケーションに問題がある
• フレームワークに問題がある
• キャッシュ設計に問題がある
• ロジックに問題がある
• DBに問題がある
• 参照に問題がある
• 更新に問題がある
負荷試験結果が芳しくない原因（例）

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
Stress Test
☠

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
☠ ☠ ☠ ☠
☠
Stress Test

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
☠ ☠ ☠ ☠
☠
EC2 instance
ElastiCache
Stress Test
☠

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
☠ ☠ ☠ ☠
Stress Test

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
☠ ☠ ☠ ☠
Stress Test
☠ ☠

考えられる要因が複数ありすぎて一つづつ潰すのは大変。
【重要】切り分けして原因を潰していける順序で負荷試験を
行う。

4. 段取りに沿った負荷試験勇者編
Webサーバ1台から

負荷試験勇者編
単体の敵を直接攻撃する。（弱い敵から）
静的ファイル HelloWorld 参照ページ更新ページ

LV.1 負荷試験ツールの試験を行う
LV.2 フレームワークの最速値を計測する
LV.3 参照系を単体で負荷試験を行う
LV.4 更新系を単体で負荷試験を行う
入門レベル目標

勇者LV.1 負荷試験ツールの試験を行う
静的ファイルがあらわれた。
たるはちはちょくせつこうげきをした。

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
勇者LV.1負荷試験ツールの試験を行う
攻撃サーバ = 攻撃されるサーバ
Webサーバ1台だけ
静的リソースファイルへのアクセス
※この時Localhostへの攻撃をするようにしま
す。
EC2 instance
web app
server
Index.html
.html

勇者LV.1 負荷試験ツールの試験を行う
静的ファイルに対する負荷試験をかける
リソースも逼迫していないのに結果が遅い時には負荷をかける方法がおかしいので、十分なスルー
プットが出るまで調整する。
（※攻撃サーバがネットワーク的に遠い場合や攻撃ツールが最適化されえいない場合などがありま
す。また、攻撃サーバのローカルポートが不足した時もエラーとして観測されます。）

たるはちはただしい負荷のかけ方をおぼえた！
2ポイントの経験値をかくとく！
たるはちはレベル2になった！

勇者LV.2 フレームワークを通したHelloWorldの負荷試験を行う
HelloWorldがあらわれた。

Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
EC2 instance
web app
server
フレームワークの機能を利用した上で最低
限のHellowWorldでの試験を行う
この時にまだ外部のリソースを利用しない
HellowWorld.php
.php

• 理論上の最速値が得られます
• 例えば
• LV1静的ファイルで1000REQ/SEC、HELLOWORLDで300REQ/SEC とかになります
• 今後DBに接続した処理などが 400REQ/SECとかには絶対にならないです。
• 200REQ/SECとか出てればOK！というような目安にします。
• この時点でスループットが遅かったらフレームワークやミドルウエア、利用
ライブラリ等の見直しが必要になります。

たるはちはフレームワークの問題をきりわけた！

勇者LV.3 参照系のページやAPIを単体で負荷試験を行う
参照ページがあらわれた。

DBに対して参照のみ行われるケースの試験
Elastic Load
Balancing
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
.php
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
参照.php

更新系のページの計測を行う前にこの計測を行うことで、更新ロックによるリソース競合が発生し
にくい状況での負荷試験を行えます。
このため、遅かった場合でも純粋なSlowQuery等の調査が行い易いです。
ここで参照系SQLの最適化やDBインデクスの見直し、キャッシュ利用ポリシーの見直しなどが行
うことができます。

たるはちはキャッシュ設計をみなおした！
たるはちはDB接続をみなおした！
たるはちはDB参照をみなおした！

勇者LV.4 更新系のページやAPIを単体で負荷試験を行う
更新ページがあらわれた。

DBに対して
参照、更新の両方が行われるケースの試験
Elastic Load
Balancing
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
.php
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
更新.php

参照系ページでは発生しなかったリソース競合などが新たに発生す
る可能性がありますが、それらを切り分けて調査しやすくなります。

たるはちはDB更新をみなおした！
たるはちは賢者に転職した！

5. 段取りに沿った負荷試験賢者編

負荷試験賢者編
俺達の本当の戦いはこれからだ
攻撃シナリオを組む大量の敵と戦う
Webサーバは
なかまを呼んだ！
たるはち
B 105
W 85
H 95
攻撃する仲間を増やす
たるはちは
たるはち
B 105
W 85
H 95
たるはち
B 105
W 85
H 95
たるはち
B 105
W 85
H 95

LV.1 ユーザの導線を想定した試験を行う
LV.2 スケールアップ・スケールアウト可能なシステムである
ことを確認する
LV.99 複数の攻撃サーバから同時攻撃をする
勇者レベル目標
【目的】
【時間があれば】

勇者LV.1 ユーザの導線を想定した試験を行う
Jmeter等のシナリオ記述可能なツールで実際のユーザーの行動を想定したシナリオを
組んで試験を行ないます。
シナリオを組むことで、Session的なアクセスなども出来るようになります。

シナリオの組み方1
シナリオを組むためにproxyを立てて実際のリクエストをキャプチャする方法も有ります
が、多くの場合必要ありません。
典型的なユーザーの導線を“適当に”考えて“適当に”組んでいきます。
特定のページのシナリオの組み方がよくわからない場合は、Chromeの要素を検証-
>Networkから確認出来るパラメータを入れるだけでもなんとかなります。
実際のページリクエストに近いものを知りたい場合は、アクセスログから抽出するなどし
てもいいでしょう。

シナリオの組み方2
• ユーザーの導線の完璧なモデルケースは作れない
• より“重要そう”で、“負荷が高そう”で“問題になりそう”なシナリオで十分
負荷試験の目的は、システムのスケール性能を担保すること！！

予め記載されたシナリオに沿った試験を行う
入会シナリオ・投稿シナリオなど
賢者LV.1ユーザの導線を想定した試験を行う
Elastic Load
Balancing
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache

たるはちはシナリオに沿った試験をした！
たるはちは賢者レベル2になった！

• ロジックに問題がある（シナリオが流れる範囲で新たに担保できる）

賢者LV.2 スケールアップ・スケールアウト
可能なシステムであることを確認する
Webサーバは
たるはち
B 105
W 85
H 95

リソースが逼迫したサーバに関してスケールアップやスケールアウトを行ない、
ボトルネックが解消されて、実際にスループットが改善することを確認する。

Availability Zone
Availability Zone
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
軽い☺
重い(*_*) 負荷のかかっているリソースを増強する
軽い☺
スループット
500req/sec
Elastic Load
Balancing

Availability Zone
Availability Zone
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
負荷のかかっているリソースを増強する
軽い☺
スループット
1000req/sec
Elastic Load
Balancing
EC2 instance
web app
server
普通☺
重い(*_*)

EC2 instance
Availability Zone
Availability Zone
web app
server
EC2 instance
web app
server
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
負荷のかかっているリソースを増強する
軽い☺
スループット
1200req/sec
Elastic Load
Balancing
EC2 instance
web app
server
web app
server
EC2 instance
重い(*_*)
1500req/secにならないぞ？
普通☺

EC2 instance
Availability Zone
Availability Zone
web app
server
EC2 instance
web app
server
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
普通☺
DBをスケールアップ
軽い☺
スループット
1500req/sec
Elastic Load
Balancing
EC2 instance
web app
server
web app
server
EC2 instance
重い(*_*)

リソースを増強する度に、スループットが上昇するとともに、逼迫するリソース
が移動していけばOK
リファクタリングを逼迫したリソース部分を中心に行うことが出来る。
どこにもリソース逼迫が観測されないのにスループットが上昇しない場合は
負荷試験のかけ方がおかしいまたはシステムの限界性能がそこまでというこ
と。

スケールアウトやスケールアップをしてもシステムが追従しないことは良くあ
る。
スケールアップで性能が実際に追従するかどうかはやってみないとわからな
い。
特に、RDSで既に十分大きめのインスタンスを使っていた場合にスケール
アップでスループットが改善しないことも多いことに注意する。

たるはちは構築したシステムがスケール可能なシス
テムであることを確認した！
エンジニアに安らかな日々が訪れた。。。

賢者LV.99 複数の攻撃サーバから同時攻撃をする
たるはちは
たるはち
B 105
W 85
H 95
たるはち
B 105
W 85
H 95
たるはち
B 105
W 85
H 95

賢者LV.99 複数の攻撃サーバから同時攻撃をする
クラウドを使えば比較的簡単にJmeter攻撃サーバクラスタを組んだ上でDDOS
攻撃をかけることが出来ます。必要に応じて検討して下さい。
http://dev.classmethod.jp/cloud/apache-jmeter-master-slave-100mil-req-
min/
※この時、全てのサーバから同一のシナリオを流すことに注意して下さい。
攻撃側が1台で負荷を十分にかけることが出来ない場合は、攻撃サーバを複数
起動してから攻撃をかけます。

ツール
• 負荷試験ツール
• Apachebench
• Jemeter
• Gatling
• Etc…
• プロファイリングツール
• XHProf
• New Relic
• Etc…

ApacheBench
• 簡単にかけることが出来る、POST/PUTの試験も可能
• リクエストごとにパラメータを変更する事ができない
• DELETEはできない
• シナリオ記載ができない
時間がなかったら、これでもいいから負荷試験をかける。
多くの場合はカバーできる

Apache Jmeter
• 各種のmethodが利用可能
• シナリオの記載が可能
• リクエストごとにパラメータの変更が可能
• 攻撃サーバを増やして高負荷をかけることが可能
• 結果の可視化が可能
Jmeterは何回かシナリオを書いたら慣れてくるので意外と簡単になります。
怖くない。
シナリオ記載可能な高機能負荷試験ツールとしては他にもGatlingなどがあります。

参考：Jmeterで負荷をかけられなくなるリスナーの例
【結果をツリーで表示】
リクエスト結果がわかり便利だが、
これが有効になっていると恐らくネットワーク遅
延が原因でまともな負荷をかけられなくなる。
ログエラーのみにチェックを入れていても同じな
ので、試験の前に無効化する必要あり

XHProf
HTTP://PHP.NET/MANUAL/JA/BOOK.XHPROF.PHP
インストール・利用が非常に簡単なプロファイリングツール
Graphvizをインストールすることで実行時間が長い箇所を可視化してくれる
※全てのプロファイリングツールに共通の問題として、利用後は機能をOFFにしておくこと

XHProf (wordpress index.php)
この例では、リクエストパラメータのuse_xhprofを見て、プロ
ファイリングを行うかどうかを決定している。
負荷がかかった状態でのプロファイル結果をみるべきだが、
負荷をかけるための攻撃ではプロファイリングを無効にして、
同時に別のリクエストでプロファイリングを行うことが重要。

XHProfサンプル2
Graphvizをインストールすると
プロビジョニング結果の可視化も可能

XHProfサンプル3
実行時間のかかっているメソッドや、
実行回数が多すぎるメソッドなどを追うことが出来る。

7. 負荷試験でやってはいけない集

開発工程の一番最後に負荷試験する。
製造
単体試験
結合試験
商用環境構築負荷試験
リリース日

全部が揃ってなくても、環境が整ってなくても試験をし
ておかないと、修正期間が取れません。
製造
単体試験
結合試験
負荷試験
リリース日
修正期間
商用環境構築

間違った方法で負荷をかける

自作シェルスクリプトで負荷試験
#!/bin/bash
date
php /var/www/html/pc/login2c.php test_mm_1@yumemi.co.jp > /dev/null &
...
中略
...
php /var/www/html/pc/login2c.php test_mm_1000@yumemi.co.jp > /dev/null
date
1000行並んでました。。。。

遠くのネットワークから攻撃する

EC2 instance
web app
server
EC2 instance
web app
server
攻撃元が遠いとダメ（失敗例）
Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
ElastiCache
ElastiCache
攻撃されるサーバ
EC2 instance
web app
server
EC2 instance
web app
server
攻撃サーバ
AZをまたいでの負荷試験はほぼ無意味
スループットは上がらないのに、リソースが
余るという状況が発生する。
ネットワークの試験になるだけでなく、一部
の遅いプロセスが全部終わるまで試験が終
わらないために、攻撃対象サーバに負荷が
かからない。

ちなみに、あまりにも時間がなさすぎて、
社内ネットワークから負荷試験をかけてみた

「2時間後に芸能人呼んでプレスリリース打つんだけど、
このサイトの負荷試験しておいてよ。」
「負荷試験シナリオ？ないよ。TOPページから適当にお願
い。」

Webアプリケーション負荷試験実践入門

社内にウイルス感染したPCがあるとの疑惑で怒られた。

ELB配下のインスタンス群を
Multi-AZ構成にして攻撃する

ELBを利用したスケールアウトの試験（失敗例）
Elastic Load
Balancing
RDS DB
instance
RDS DB
instance standby
(Multi-AZ)
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
EC2 instance
web app
server
ElastiCache
ElastiCache
AZをまたいでいるので無意味
ELBがDNSキャッシュしてしまって、どち
らかのZoneにしか負荷がかからない

なんか負荷試験やりにくかったので
今回はパス！！

負荷試験実施が難しいケース１
• 外部システムとの結合がある
• スタブを用意する
• パラメータを動的に変更しなければならないケース
• シナリオ記述できる負荷試験ツールを使う
• プログラムの一部改変をする
• 最悪、一部の機能を殺してでも試験は行う

負荷試験実施が難しいケース２
• 負荷試験環境が存在しない
• クラウドだったら頑張って構築する
• オンプレミスで稼働中のシステムだったら、クラウドに類似システムを構築す
る
• 同規模の環境の構築が難しければ、小さなインスタンスと台数で構築して、N
倍して考える

ELBやCloudfrontなどのベンダーの提供す
る既存サービスに対して負荷試験を行う
やってもいみない

静的コンテンツはサービス利用前提とすると
負荷試験も行わないでよい。
S3での配信＋リバースプロクシを立てる
リバースプロクシとしてnginxやsquidと
かいろいろ有りますが、、、
冗長化やスケール性を考えるとAkamai
やCloudFrontなどのCDN立てるのが
一番エンジニアが楽できます。
Amazon S3
CloudFront

システムが遅い時のあたりの付け方
• （既存/自作）FWが重い(CPU負荷が高い、メモリ使用量が多い)
• DBの応答が遅い(Slow query logを見る)
• SQLが悪い(ORMのせいかも)
• INDEXが不適切
• ロックが発生している（INNODB_LOCKSやログ監視など）
• 無駄なSQLが発行されている
• DB設計が悪い
• リソース不足
• コネクションプーリングしていない（DB/Memcached）
• 不要なループ・冗長なコード・内部リソースの使い回しがされていない
• Cacheが適切に設定されていない

攻撃サーバの設定を変更する
Cent OSの場合
sysctl -p
/etc/sysctl.conf
net.ipv4.ip_local_port_range = 32768 65000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 10
※アプリケーションがコネクションプーリングを利用していなかっ
た場合にもこの設定を変える必要がある。
TCP関連の設定を変えないと、単位時間あたりのリクエスト量が増えた時
に攻撃サーバのソケットが枯渇して新規に接続を行うことができなくなる。

負荷試験が必要ないケースもあります
• 既存システムの少改修
• トラフィックが“絶対に”増えないケース
• トラフィックが増えた時に落ちても良いケース
• ELBやCloudFrontなどの外部ベンダーの提供する既存サービスに対する負
荷試験
（静的コンテンツをCDN使って配信しているケースなど）

負荷試験結果事例の紹介

ご静聴ありがとうございました。

Webアプリケーション負荷試験実践入門

More Related Content

Webアプリケーション負荷試験実践入門

Editor's Notes