負荷試験入門公開資料 201611

クラウドファーストにおけるWEBアプリケーション負荷試験実践入門

株式会社ゆめみ仲川樽八

1. スライドの目的

• リリース前に負荷試験を行うことを当たり前にする

• 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く

スライドの目的

2. 負荷試験の目的と心得

クラウドファーストの本質とは

スケールラブルなシステムが

容易かつ安価に構築できること

高負荷の時はスケールアウトする

Elastic Load Balancing

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

お金で解決する！

若干のメンテナンス時間さえ取れれば

スケールアップ出来る

RDS DB instancexlarge

RDS DB instance8xlarge

お金で解決する！

サービスの稼働状況に応じた

適切なリソースを金で買う時代！！

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

CPU負荷 100%張り付き

LOCK WAIT TIMEOUT鳴り止まない電話

Load Ave. 900??

既に8XLARGE使ってます！！

終電って何？

媒体告知打っちゃったよ！！！

クラウドファーストにおける

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

与えられた特定の条件下でのシステム

全体のスループットを最低保証すること。

例：「一時間で○○万人の応募を受け付けます！！」

という数字を保証すること。

クラウドファーストな負荷試験の目的

…ではありません。

最終的に必要であることはありますが、

最初にこれを目的にしようとするとまず失敗します。


負荷試験で最低限担保できるのは、

・特定条件のベストエフォート時における処理能力

・対象システムがスケール対応しているかどうか

の2つです。


クラウド時代における負荷試験とは、

システムの性能を担保する試験ではなく、

システムの機能を担保する試験

です。

負荷試験の心得

の前に、製品試験といえば、、、。

“よい数字が出るまで測定した”・・・

いいんです！

ここで、良い負荷試験の指標

良い負荷試験

•対象に充分な負荷がかかっている

•対象システムのリソースのいずれかが逼迫していること

•結果としてより高い性能が観測される

•結果のスループットがより高いこと

•結果のレイテンシが小さいこと(数十~数百Msec)

対象システムのリソースのいずれかが逼迫していること

負荷試験対象システムに対して充分な負荷がかかり、

対象システムのどこかのリソースが悲鳴を上げているのが良い負荷試験

です。

今何処に負荷がかかっているのかを

常に意識して下さい。ここだよ！

（その結果として、）対象システムのスループットがより高いこと

スループット：単位時間あたりに処理可能なリクエスト数

これがユーザーの流入数より少なければレイテンシはどんどん増え

ていき、最終的にサービス提供が出来ない状態となります。

対象システムのレイテンシが小さいこと

レイテンシ：システム応答時間

負荷試験では、攻撃クライアント数を調整しながら、スループットが最

大で、レイテンシが充分小さい場所を探ります。

負荷試験とは、文字通り、

対象に負荷をかける試験です。

適切な負荷をかけ、その結果として、より高いスループットが計測されるように、負荷をかける事を邪魔する要因を排除

する事を繰り返します。

遠慮なく条件を変えながら、

“良い数字が出るまで測定”

を繰り返して下さい。

悪い負荷試験の例

悪い負荷試験の例

・SSL対応サイトなので、SSLを利用した負荷試験を行うべきだ

・ユーザーのユースケースを考慮して、海外のサーバから負荷試験を行おう

・完璧なユーザーシナリオを作り上げて試験を行おう（※複雑な判定の追加や、

実際に近いSleep処理の追加など）

・etc…

理由は後述します。

3. 負荷試験の段取り

やってはいけない

いきなり全体の負荷試験を行う

※「おおたるはち！しんでしまうとはふがいない！

なぜしんだのかはわかってるのか？

負荷試験結果が芳しくない原因（例）

• 試験内容、方法に問題がある

• インフラに問題がある

• LBに問題がある

• ネットワークに問題がある

• ミドルウエア設定、カーネルパラメータ設定に問題がある

• アプリケーションに問題がある

• フレームワークに問題がある

• キャッシュ設計に問題がある

• ロジックに問題がある

• DBに問題がある

• 参照に問題がある

• 更新に問題がある

試験結果を元にあたりをつけてリファクタリングをしても、

その部分がボトルネックではなかった場合、そのリファクタリング結果

は負荷試験結果に反映されない。

リファクタリング前リファクタリング後

部品A 部品B 部品C Total 部品A 部品B 部品C Total

部品Cにバグが有ったので、リファクタリングで部品Cの能力を3倍に！

全体のスループットは変わらない

例え最初の試験で目標値をクリアしていたとしても、その計測結果が

妥当かどうかがわからない。

部品A 部品B 部品C Total

目標スループット

試験結果スループット

攻撃サーバ能力

負荷試験

考えられる要因が沢山ありすぎて一つづつ潰すのは大変。

切り分けして原因を潰していける順序で負荷試験を行う。

→段取りが重要

4. 段取りに沿った負荷試験1ウォーミングアップ編

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

負荷試験対象システム全体像

クラウド上でスケール可能なシステムを構成


Availability Zone Availability Zone

RDS DB instance

RDS DB instance standby

(Multi-AZ)

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

• LAMP構成のシステム

• WEBアプリケーションサーバはLBの後ろに設

置されている

• 全てAZ（データセンター）をまたいだ形で設置

し、単一障害点はない

• キャッシュを利用

• DBはスケールアップで対応

ElastiCache

ElastiCache

Step.1 負荷試験ツールの試験を行う

Step.2 フレームワークに負荷をかける

Step.3 参照系システムに負荷をかける

Step.4 更新系システムに負荷をかける

段取りに沿った負荷試験

ウオーミングアップ編

つまり、負荷をかける対象を意識する

まず、どこまでの負荷をかける事ができるツールなのかを検証します。



RDS DB instance


(Multi-AZ)

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

ElastiCache

ElastiCache

Step1 負荷試験ツールの試験を行う

攻撃サーバ = 攻撃されるサーバ

Webサーバ1台だけ静的リソースファイルへのアクセス

※この時Localhostへの攻撃をするようにします。

EC2 instance

web appserver

Index.html

.html

Step.1 負荷試験ツールの試験を行う

静的ファイルに対する負荷試験をかける

リソースも逼迫していないのに結果が遅い時には負荷をかける方法がおかしいので、十分なスルー

プット（数千~数万rps）が出るまで調整する。

（※攻撃サーバがネットワーク的に遠い場合や攻撃ツールが最適化されていない場合などがありま

す。また、攻撃サーバのローカルポートが不足した時もエラーとして観測されます。）




RDS DB instance


(Multi-AZ)

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

ElastiCache

ElastiCache


EC2 instance

web appserver Webサーバ1台だけ

フレームワークの機能を利用した上で最低限のHellowWorldでの試験を行う

この時にまだ外部のリソースを利用しない

HellowWorld.php

.php

• 理論上の最速値が得られます

• 例えば

• LV1静的ファイルで10000RPS、HELLOWORLDで300RPS とかになった場合、

• 今後DBに接続した処理などが 400RPSとかには絶対にならないです。

• この時点でスループットが遅かったらフレームワークやミドルウエア、利用

ライブラリ等の見直しが必要になります。


Step.3 参照系のシステムに負荷をかける



EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver


EC2 instance

web appserver

.php

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

参照.php

Webサーバ1台だけ

DBに対して参照のみ行われるケースの試験

更新系のページの計測を行う前にこの計測を行うことで、更新ロックによるリソース競合が発生しにく

い状況での負荷試験を行えます。

このため、遅かった場合でも純粋なSlowQuery等の調査が行い易いです。

ここで参照系SQLの最適化やDBインデクスの見直し、キャッシュ利用ポリシーの見直しなどが行うこと

ができます。

※ここではまだDBに十分な負荷をかける事はできないかもしれませんが、この段階では大丈夫です。

後にまた充分な負荷がかかった状態の試験を行ないます。

Step.3 参照系のシステムに負荷をかける


DBに対して参照、更新の両方が行われるケースの試験



EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver


EC2 instance

web appserver

.php

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

更新.php

Step.4 更新系のシステムに負荷をかける

参照系ページでは発生しなかった、ロック競合などのリソース競合などが新たに

発生する可能性がありますが、それらを切り分けて調査しやすくなります。

Step.4 更新系のシステムに負荷をかける

5. 段取りに沿った負荷試験実践編

Step.1 負荷試験シナリオを利用する

Step.2 スケールアップ・スケールアウト可能なシステムであることを確認する

Step.3 (必要に応じて)複数の攻撃サーバから同時攻撃をする

実践編


Jmeter等のシナリオ記述可能なツールで実際のユーザーの行動を想定したシナ

リオを組んで試験を行ないます。

シナリオの組み方

• 典型的なユーザーの導線を“適当に”考えて“適当に”組んでいきます。

• ユーザーの導線の完璧なモデルケースは作れない

※作り上げた結果、攻撃ツール側がボトルネックとなることもあります。

• より“重要そう”で、“負荷が高そう”で“問題になりそう”なシナリオで十分

負荷試験の目的は、システムのスケール性能を担保すること！！


予め記載されたシナリオに沿った試験を行う

入会シナリオ・投稿シナリオなど



EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver


EC2 instance

web appserver

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache










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





リソースが逼迫したサーバに関して

・スケールアップ・スケールアウト

を行うことでスループットが改善することを確認することを繰り返します。

この試験では、負荷が集中するボトルネックが次々と移動しますので、今までは現れなかった挙動が出てきます。

そのため、今まで行った試験をPDCAで回して修正を加えます。

※先ほど試験できなかった、DBへの高負荷試験などが可能になります。


Availability Zone

Availability Zone

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

軽い☺

重い(*_*) 負荷のかかっているリソースを増強する※殆どの場合WebサーバCPUリソース

軽い☺

スループット500req/sec



Availability Zone

Availability Zone

EC2 instance

web appserver

EC2 instance

web appserver

EC2 instance

web appserver

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

負荷のかかっているリソースを増強する

軽い☺



EC2 instance

web appserver

普通☺

重い(*_*)


Availability Zone

Availability Zone

EC2 instance

web appserver

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

負荷のかかっているリソースを増強する2倍づつが良い。

軽い☺



EC2 instance

web appserver

重い(*_*)

2000req/secにならないぞ？

EC2 instance

web appserver

web appserver

EC2 instance

普通☺


Availability Zone

Availability Zone

EC2 instance

web appserver

RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

普通☺

DBをスケールアップ

軽い☺



EC2 instance

web appserver

EC2 instance EC2 instance

web appserver

web appserver

重い(*_*)

リソースを増強する度に、スループットが上昇するとともに、逼迫するリソースが移動していけばOK

リファクタリングを逼迫したリソース部分を中心に行うことが出来る。

どこにもリソース逼迫が観測されないのにスループットが上昇しない場合は負荷試験のかけ方がおかしいまたはシステムの限界性能がそこまでということ。


スケールアウトやスケールアップをしてもシステムが追従しないことは良くある。

スケールアップで性能が実際に追従するかどうかはやってみないとわからない。

特に、RDSで既に十分大きめのインスタンスを使っていた場合にスケールアップでスループットが改善しないことも多いことに注意する。


Step.3 複数の攻撃サーバから同時攻撃をする

クラウドを使えば比較的簡単にJmeter攻撃サーバクラスタを組んだ上でDDOS攻

撃をかけることが出来ます。必要に応じて検討して下さい。

http://dev.classmethod.jp/cloud/apache-jmeter-master-slave-100mil-req-min/

攻撃側が1台で負荷を十分にかけることが出来ない場合は、攻撃サーバを複数起動し

てから攻撃をかけます。

経験上、Jmeterの場合、スケールアップより、スケールアウトが効果的です。

Step.3 複数の攻撃サーバから同時攻撃をする

c4.large(2コア8ECU)の攻撃サーバも、

時給14円(※1)で1時間から利用できる時代。

→100台構成でも1,400円!!

※1 AWS 2016/10/21現在の価格、レート

6. ツールの紹介

ツール

•負荷試験ツール

• Apachebench

• Jemeter

• Locust / tsung / Gatling / Etc…

• その他、Webサービス

色々有りますが、複数のツールを使えるようになっておく

と良いです。

ツール

• モニタリングツール・プロファイリングツール

• Cloud watch

• XHProf

• New Relic

• Etc…

ApacheBench

ApacheBench

• 簡単にかけることが出来る、POST/PUTの試験も可能

• リクエストごとにパラメータを変更する事ができない

• DELETEはできない

• シナリオ記載ができない

時間がなかったら、これでもいいから負荷試験をかける。

多くの場合はカバーできる

Apache Jmeter

Apache Jmeter• GUIで利用

• 各種のmethodが利用可能

• シナリオの記載が可能

• リクエストごとにパラメータの変更が可能

• 攻撃サーバを増やして高負荷をかけることが可能

• 結果の可視化が可能

Jmeterは何回かシナリオを書いたら慣れてくるので意外と簡単になります。

怖くない。

シナリオ記載可能な高機能負荷試験ツールとしては他にもLocust/Tsung/Gatlingなどがあります。

参考：Jmeterで負荷をかけられなくなるリスナーの例

【結果をツリーで表示】リクエスト結果がわかり便利だが、

これが有効になっていると恐らくネットワーク遅延が原因でまともな負荷をかけられなくなる。

ログエラーのみにチェックを入れていても同じなので、試験の前に無効化する必要あり

その他、IFコントローラーで攻撃負荷が激減するなど、注意が必要

Cloud watch

多くの場合、Cloud Watchで充分。

ただし、EC2のモニタリングはデフォルトだと、5分間隔でしか出来ない(※)ことに注意が必要。オ

プションで1分間隔にしておいて下さい。

例えば、ELBのメトリクス監視でこれを使うことにより、複数のサーバから連動して攻撃できない

ツールでも結果を残しておくことが出来るので意外と便利。

※5分間隔だと、一回の試験を15分以上続けないと正確なグラフの値がプロットされない。

XHProf

XHProf

HTTP://PHP.NET/MANUAL/JA/BOOK.XHPROF.PHP

インストール・利用が非常に簡単なプロファイリングツール

Graphvizをインストールすることで実行時間が長い箇所を可視化してくれる

※全てのプロファイリングツールに共通の問題として、利用後は機能をOFFにしておくこと

http://php.net/manual/ja/book.xhprof.php

XHProf (wordpress index.php)

この例では、リクエストパラメータのuse_xhprofを見て、プロファイリングを行うかどうかを決定している。

負荷がかかった状態でのプロファイル結果をみるべきだが、負荷をかけるための攻撃ではプロファイリングを無効にして、同時に別のリクエストでプロファイリングを行うことが重要。

XHProfサンプル1

XHProfサンプル2

Graphvizをインストールするとプロファイリング結果の可視化も可能

XHProfサンプル3

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

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

開発工程の一番最後に負荷試験する。


製造

単体試験

結合試験

商用環境構築負荷試験

リリース日

全部が揃ってなくても、環境が整ってなくても試験をしておかないと、修正期間が取れません。

製造

単体試験

結合試験

負荷試験

リリース日

修正期間

商用環境構築

一つのツールにこだわる


ツール毎に特性があります。より高負荷をかけた試験を行いたい場合は

それに適したツールを利用します。

また、複数のツールを使うことで、そのツールで計測した値が適切なものであることの担保も出来ます。

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


EC2 instance

web appserver

EC2 instance

web appserver

攻撃元が遠いとダメ（失敗例）


RDS DB instance


(Multi-AZ)

ElastiCache

ElastiCache

攻撃されるサーバ

EC2 instance

web appserver

EC2 instance

web appserver

攻撃サーバ

AZをまたいでの負荷試験はほぼ無意味

スループットは上がらないのに、リソースが余るという状況が発生する。

ネットワークの試験になるだけでなく、一部の遅いプロセスが全部終わるまで試験が終わらないために、攻撃対象サーバに負荷が

かからない。


負荷試験をかけることが出来るWEBサービスも同じ理由で使わないほうが良いです。

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

「2時間後に芸能人呼んでプレスリリース打つんだけど、このサイトの負荷試験しておいてよ。」

「負荷試験シナリオ？ないよ。TOPページから適当にお願い。」

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

SSLを利用した負荷試験


SSLアクセラレータ(※)を利用して、システムに負荷がかかっていない場合であってもスループットは激減する

これは負荷試験環境だからこそ発生する問題

(※ELBで終端させた場合など)

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


負荷試験実施が難しいケース１

•外部システムとの結合がある

• スタブを用意する

•パラメータを動的に変更しなければならないケース

• シナリオ記述できる負荷試験ツールを使う

• プログラムの一部改変をする

• 最悪、一部の機能を殺してでも試験は行う

負荷試験実施が難しいケース２

•負荷試験環境が存在しない

• クラウドだったら頑張って構築する

• オンプレミスで稼働中のシステムだったら、クラウドに類似システムを構築す

る

• 同規模の環境の構築が難しければ、小さなインスタンスと台数で構築して、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設計が悪い

• リソース不足

• 不要なループ・冗長なコード・内部リソースの使い回しがされていない

• Cacheが適切に設定されていない

システムがスケールしない時のあたりの付け方

Webサーバの外の外部リソースとの接続部分を中心に調査をします。

• DBボトルネックである場合

• 外部リソースとの接続オーバーヘッドが大きい

• 各種コネクションプーリングしていない（DB/Memcached/Http session）

• 外部サーバへのログ転送を非同期にしていない

• NAT能力不足

負荷試験入門公開資料 201611

Engineering