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

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

1. 1. もうアラートなんて怖くない！ WEBアプリケーション負荷試験実践入門 株式会社ゆめみ 仲川樽八
2. 2. 0. 講師紹介
3. 3. 樽八って誰？ 株式会社ゆめみ2001年度入社エンジニア 2000年頃から主にLAMP構成のWeb系ア プリケーションの開発を行う。 近年はクラウドを前提としたシステムを中 心に高負荷アプリケーションの設計、開発を 手がけている。 プライベートでは4人の娘の父親。
4. 4. 1. セミナーの目的
5. 5. • 負荷試験の重要性を認識して頂く • 意味のある負荷試験を最短距離で行うための“段取り”を持ち帰って頂く このセミナーの目的
6. 6. 今回の負荷試験対象システム
7. 7. 負荷試験対象システム全体像 クラウド上でスケール可能なシステムを構成 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
8. 8. 2. 負荷試験の目的と必要性
9. 9. 負荷試験の目的は何でしょうか？
10. 10. 特定の条件下でのシステム 全体のスループットを担保すること。 例：「一時間で○○万人の応募を受け付けます！！」 という数字を担保すること。 負荷試験の目的
11. 11. …ではありません。 負荷試験で担保できるのは、 「○○以上の性能は出ません。」 という上限の数字です。 ※実際の外部要因は全て 性能を落とす方向に動かします。 負荷試験の目的
12. 12. 実装されたアプリケーションが設計通りにス ケール可能かどうかはわかりません！！ それを確認し、設計通りに動作することを担保 するのが負荷試験の目的です。 負荷試験の真の目的
13. 13. スケール可能な設計
14. 14. 高負荷の時はスケールアウトする 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 お金で解決する！
15. 15. 若干のメンテナンス時間さえ取れれば スケールアップ出来る RDS DB instance xlarge RDS DB instance 8xlarge お金で解決する！
16. 16. そう考えて負荷試験をしなかった、、、
17. 17. WEBサーバを追加したのに、 DBサーバをスケールアップしたのに、 スループットは改善しない！！！ ということは往々にしてあります。
18. 18. CPU負荷 100%張り付き LOCK WAIT TIMEOUT 鳴 り 止 ま な い 電 話 Load Ave. 900?? 既に8XLARGE使ってます！！ 終 電 っ て 何 ？ 媒体告知打っちゃったよ！！！
19. 19. システムの性能担保ではなく、 実装が設計通りに動作することの担保 ですので、 開発者を守るために行うのが負荷試験です。
20. 20. 大前提として、 負荷試験の時間と予算は必ず確保する。 ただし、それに失敗した時も、時間、予算が無 いなりの負荷試験を行ないましょう。
21. 21. 3. 負荷試験の段取り
22. 22. やってはいけない いきなり全体の負荷試験を行う
23. 23. 例えば、最初にシステム全体に対して負荷試験を行って しまった場合において、システムが性能要件を満たさな かったら、、、。
24. 24. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例）
25. 25. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 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 ElastiCache ElastiCache Stress Test ☠
26. 26. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例） 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 ElastiCache ElastiCache ☠ ☠ ☠ ☠ ☠ Stress Test
27. 27. 負荷試験結果が芳しくない原因（例） Elastic Load Balancing Availability Zone Availability Zone 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 ☠ ☠ ☠ ☠ ☠ • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある EC2 instance ElastiCache Stress Test ☠
28. 28. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例） 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 ElastiCache ElastiCache ☠ ☠ ☠ ☠ Stress Test
29. 29. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例） 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 ElastiCache ElastiCache ☠ ☠ ☠ ☠ Stress Test ☠ ☠
30. 30. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例） 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 ElastiCache ElastiCache ☠ ☠ ☠ ☠ Stress Test
31. 31. • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある 負荷試験結果が芳しくない原因（例） 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 ElastiCache ElastiCache ☠ ☠ ☠ ☠ Stress Test ☠ ☠
32. 32. 考えられる要因が複数ありすぎて一つづつ潰すのは大変。 【重要】切り分けして原因を潰していける順序で負荷試験を 行う。
33. 33. 4. 段取りに沿った負荷試験勇者編 Webサーバ1台から
34. 34. 負荷試験勇者編 単体の敵を直接攻撃する。（弱い敵から） 静的ファイル HelloWorld 参照ページ 更新ページ
35. 35. LV.1 負荷試験ツールの試験を行う LV.2 フレームワークの最速値を計測する LV.3 参照系を単体で負荷試験を行う LV.4 更新系を単体で負荷試験を行う 負荷試験勇者編 入門レベル目標
36. 36. 勇者LV.1 負荷試験ツールの試験を行う 静的ファイルがあらわれた。 たるはちはちょくせつこうげきをした。
37. 37. 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 ElastiCache ElastiCache 勇者LV.1負荷試験ツールの試験を行う 攻撃サーバ = 攻撃されるサーバ Webサーバ1台だけ 静的リソースファイルへのアクセス ※この時Localhostへの攻撃をするようにしま す。 EC2 instance web app server Index.html .html
38. 38. 勇者LV.1 負荷試験ツールの試験を行う 静的ファイルに対する負荷試験をかける リソースも逼迫していないのに結果が遅い時には負荷をかける方法がおかしいので、十分なスルー プットが出るまで調整する。 （※攻撃サーバがネットワーク的に遠い場合や攻撃ツールが最適化されえいない場合などがありま す。また、攻撃サーバのローカルポートが不足した時もエラーとして観測されます。）
39. 39. たるはちはただしい負荷のかけ方をおぼえた！ 2ポイントの経験値をかくとく！ たるはちはレベル2になった！
40. 40. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある
41. 41. 勇者LV.2 フレームワークを通したHelloWorldの負荷試験を行う HelloWorldがあらわれた。 たるはちはちょくせつこうげきをした。
42. 42. 勇者LV.2 フレームワークを通したHelloWorldの負荷試験を行う 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 ElastiCache ElastiCache 攻撃サーバ = 攻撃されるサーバ EC2 instance web app server Webサーバ1台だけ フレームワークの機能を利用した上で最低 限のHellowWorldでの試験を行う この時にまだ外部のリソースを利用しない HellowWorld.php .php
43. 43. 勇者LV.2 フレームワークを通したHelloWorldの負荷試験を行う • 理論上の最速値が得られます • 例えば • LV1静的ファイルで1000REQ/SEC、HELLOWORLDで300REQ/SEC とかになります • 今後DBに接続した処理などが 400REQ/SECとかには絶対にならないです。 • 200REQ/SECとか出てればOK！ というような目安にします。 • この時点でスループットが遅かったらフレームワークやミドルウエア、利用 ライブラリ等の見直しが必要になります。
44. 44. たるはちはフレームワークの問題をきりわけた！ 10ポイントの経験値をかくとく！ たるはちはレベル3になった！
45. 45. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • キャッシュ設計に問題がある • ロジックに問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある
46. 46. 勇者LV.3 参照系のページやAPIを単体で負荷試験を行う 参照ページがあらわれた。 たるはちはちょくせつこうげきをした。
47. 47. Webサーバ1台だけ DBに対して参照のみ行われるケースの試験 勇者LV.3 参照系のページやAPIを単体で負荷試験を行う Elastic Load Balancing Availability Zone Availability Zone 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
48. 48. 勇者LV.3 参照系のページやAPIを単体で負荷試験を行う 更新系のページの計測を行う前にこの計測を行うことで、更新ロックによるリソース競合が発生し にくい状況での負荷試験を行えます。 このため、遅かった場合でも純粋なSlowQuery等の調査が行い易いです。 ここで参照系SQLの最適化やDBインデクスの見直し、キャッシュ利用ポリシーの見直しなどが行 うことができます。
49. 49. たるはちはキャッシュ設計をみなおした！ たるはちはDB接続をみなおした！ たるはちはDB参照をみなおした！ 30ポイントの経験値をかくとく！ たるはちはレベル4になった！
50. 50. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • ロジックに問題がある • キャッシュ設計に問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある
51. 51. 勇者LV.4 更新系のページやAPIを単体で負荷試験を行う 更新ページがあらわれた。 たるはちはちょくせつこうげきをした。
52. 52. Webサーバ1台だけ DBに対して 参照、更新の両方が行われるケースの試験 勇者LV.4 更新系のページやAPIを単体で負荷試験を行う Elastic Load Balancing Availability Zone Availability Zone 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
53. 53. 勇者LV.4 更新系のページやAPIを単体で負荷試験を行う 参照系ページでは発生しなかったリソース競合などが新たに発生す る可能性がありますが、それらを切り分けて調査しやすくなります。
54. 54. 100ポイントの経験値をかくとく！ たるはちはDB更新をみなおした！ たるはちは賢者に転職した！
55. 55. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • ロジックに問題がある • キャッシュ設計に問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある
56. 56. 5. 段取りに沿った負荷試験賢者編
57. 57. 負荷試験賢者編 俺達の本当の戦いはこれからだ 攻撃シナリオを組む 大量の敵と戦う 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
58. 58. LV.1 ユーザの導線を想定した試験を行う LV.2 スケールアップ・スケールアウト可能なシステムである ことを確認する LV.99 複数の攻撃サーバから同時攻撃をする 負荷試験勇者編 勇者レベル目標 【目的】 【時間があれば】
59. 59. 勇者LV.1 ユーザの導線を想定した試験を行う Jmeter等のシナリオ記述可能なツールで実際のユーザーの行動を想定したシナリオを 組んで試験を行ないます。 シナリオを組むことで、Session的なアクセスなども出来るようになります。
60. 60. シナリオの組み方1 シナリオを組むためにproxyを立てて実際のリクエストをキャプチャする方法も有ります が、多くの場合必要ありません。 典型的なユーザーの導線を“適当に”考えて“適当に”組んでいきます。 特定のページのシナリオの組み方がよくわからない場合は、Chromeの要素を検証- >Networkから確認出来るパラメータを入れるだけでもなんとかなります。 実際のページリクエストに近いものを知りたい場合は、アクセスログから抽出するなどし てもいいでしょう。
61. 61. シナリオの組み方2 • ユーザーの導線の完璧なモデルケースは作れない • より“重要そう”で、“負荷が高そう”で“問題になりそう”なシナリオで十分 負荷試験の目的は、システムのスケール性能を担保すること！！
62. 62. Webサーバ1台だけ 予め記載されたシナリオに沿った試験を行う 入会シナリオ・投稿シナリオなど 賢者LV.1ユーザの導線を想定した試験を行う Elastic Load Balancing 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
63. 63. 200ポイントの経験値をかくとく！ たるはちはシナリオに沿った試験をした！ たるはちは賢者レベル2になった！
64. 64. 負荷試験結果が芳しくない原因（例） • 試験内容、方法に問題がある • インフラに問題がある • LBに問題がある • ネットワークに問題がある • ミドルウエア設定、カーネルパラメータ設定に問題がある • アプリケーションに問題がある • フレームワークに問題がある • ロジックに問題がある（シナリオが流れる範囲で新たに担保できる） • キャッシュ設計に問題がある • DBに問題がある • 参照に問題がある • 更新に問題がある
65. 65. 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する Webサーバは なかまを呼んだ！ たるはち B 105 W 85 H 95
66. 66. リソースが逼迫したサーバに関してスケールアップやスケールアウトを行ない、 ボトルネックが解消されて、実際にスループットが改善することを確認する。
67. 67. 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する 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
68. 68. 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する 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 普通☺ 重い(*_*)
69. 69. EC2 instance 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する 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にならないぞ？ 普通☺
70. 70. EC2 instance 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する 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 重い(*_*)
71. 71. リソースを増強する度に、スループットが上昇するとともに、逼迫するリソース が移動していけばOK リファクタリングを逼迫したリソース部分を中心に行うことが出来る。 どこにもリソース逼迫が観測されないのにスループットが上昇しない場合は 負荷試験のかけ方がおかしいまたはシステムの限界性能がそこまでというこ と。 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する
72. 72. スケールアウトやスケールアップをしてもシステムが追従しないことは良くあ る。 スケールアップで性能が実際に追従するかどうかはやってみないとわからな い。 特に、RDSで既に十分大きめのインスタンスを使っていた場合にスケール アップでスループットが改善しないことも多いことに注意する。 賢者LV.2 スケールアップ・スケールアウト 可能なシステムであることを確認する
73. 73. たるはちは構築したシステムがスケール可能なシス テムであることを確認した！ 1000ポイントの経験値をかくとく！ エンジニアに安らかな日々が訪れた。。。
74. 74. 賢者LV.99 複数の攻撃サーバから同時攻撃をする たるはちは なかまを呼んだ！ たるはち B 105 W 85 H 95 たるはち B 105 W 85 H 95 たるはち B 105 W 85 H 95
75. 75. 賢者LV.99 複数の攻撃サーバから同時攻撃をする クラウドを使えば比較的簡単にJmeter攻撃サーバクラスタを組んだ上でDDOS 攻撃をかけることが出来ます。必要に応じて検討して下さい。 http://dev.classmethod.jp/cloud/apache-jmeter-master-slave-100mil-req- min/ ※この時、全てのサーバから同一のシナリオを流すことに注意して下さい。 攻撃側が1台で負荷を十分にかけることが出来ない場合は、攻撃サーバを複数 起動してから攻撃をかけます。
76. 76. 6. ツールの紹介
77. 77. ツール • 負荷試験ツール • Apachebench • Jemeter • Gatling • Etc… • プロファイリングツール • XHProf • New Relic • Etc…
78. 78. ApacheBench
79. 79. ApacheBench • 簡単にかけることが出来る、POST/PUTの試験も可能 • リクエストごとにパラメータを変更する事ができない • DELETEはできない • シナリオ記載ができない 時間がなかったら、これでもいいから負荷試験をかける。 多くの場合はカバーできる
80. 80. Apache Jmeter
81. 81. インストール方法
82. 82. Jmeter install
83. 83. Apache Jmeter • 各種のmethodが利用可能 • シナリオの記載が可能 • リクエストごとにパラメータの変更が可能 • 攻撃サーバを増やして高負荷をかけることが可能 • 結果の可視化が可能 Jmeterは何回かシナリオを書いたら慣れてくるので意外と簡単になります。 怖くない。 シナリオ記載可能な高機能負荷試験ツールとしては他にもGatlingなどがあります。
84. 84. 参考：Jmeterで負荷をかけられなくなるリスナーの例 【結果をツリーで表示】 リクエスト結果がわかり便利だが、 これが有効になっていると恐らくネットワーク遅 延が原因でまともな負荷をかけられなくなる。 ログエラーのみにチェックを入れていても同じな ので、試験の前に無効化する必要あり
85. 85. XHProf
86. 86. インストール方法
87. 87. xhprof install
88. 88. XHProf HTTP://PHP.NET/MANUAL/JA/BOOK.XHPROF.PHP インストール・利用が非常に簡単なプロファイリングツール Graphvizをインストールすることで実行時間が長い箇所を可視化してくれる ※全てのプロファイリングツールに共通の問題として、利用後は機能をOFFにしておくこと
89. 89. XHProf (wordpress index.php) この例では、リクエストパラメータのuse_xhprofを見て、プロ ファイリングを行うかどうかを決定している。 負荷がかかった状態でのプロファイル結果をみるべきだが、 負荷をかけるための攻撃ではプロファイリングを無効にして、 同時に別のリクエストでプロファイリングを行うことが重要。
90. 90. XHProfサンプル1
91. 91. XHProfサンプル2 Graphvizをインストールすると プロビジョニング結果の可視化も可能
92. 92. XHProfサンプル3 実行時間のかかっているメソッドや、 実行回数が多すぎるメソッドなどを追うことが出来る。
93. 93. 7. 負荷試験でやってはいけない集
94. 94. 開発工程の一番最後に負荷試験する。 やってはいけない 製造 単体試験 結合試験 商用環境構築 負荷試験 リリース日
95. 95. 全部が揃ってなくても、環境が整ってなくても試験をし ておかないと、修正期間が取れません。 製造 単体試験 結合試験 負荷試験 リリース日 修正期間 商用環境構築
96. 96. 間違った方法で負荷をかける やってはいけない
97. 97. 自作シェルスクリプトで負荷試験 #!/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_2@yumemi.co.jp > /dev/null & php /var/www/html/pc/login2c.php test_mm_3@yumemi.co.jp > /dev/null & ... 中略 ... php /var/www/html/pc/login2c.php test_mm_999@yumemi.co.jp > /dev/null & php /var/www/html/pc/login2c.php test_mm_1000@yumemi.co.jp > /dev/null date 1000行並んでました。。。。
98. 98. 遠くのネットワークから攻撃する やってはいけない
99. 99. 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をまたいでの負荷試験はほぼ無意味 スループットは上がらないのに、リソースが 余るという状況が発生する。 ネットワークの試験になるだけでなく、一部 の遅いプロセスが全部終わるまで試験が終 わらないために、攻撃対象サーバに負荷が かからない。 Availability Zone Availability Zone
100. 100. ちなみに、あまりにも時間がなさすぎて、 社内ネットワークから負荷試験をかけてみた
101. 101. 「2時間後に芸能人呼んでプレスリリース打つんだけど、 このサイトの負荷試験しておいてよ。」 「負荷試験シナリオ？ないよ。TOPページから適当にお願 い。」
102. 102. 社内にウイルス感染したPCがあるとの疑惑で怒られた。
103. 103. ELB配下のインスタンス群を Multi-AZ構成にして攻撃する やってはいけない
104. 104. ELBを利用したスケールアウトの試験（失敗例） 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 ElastiCache ElastiCache AZをまたいでいるので無意味 ELBがDNSキャッシュしてしまって、どち らかのZoneにしか負荷がかからない
105. 105. なんか負荷試験やりにくかったので 今回はパス！！ やってはいけない
106. 106. 負荷試験実施が難しいケース１ • 外部システムとの結合がある • スタブを用意する • パラメータを動的に変更しなければならないケース • シナリオ記述できる負荷試験ツールを使う • プログラムの一部改変をする • 最悪、一部の機能を殺してでも試験は行う
107. 107. 負荷試験実施が難しいケース２ • 負荷試験環境が存在しない • クラウドだったら頑張って構築する • オンプレミスで稼働中のシステムだったら、クラウドに類似システムを構築す る • 同規模の環境の構築が難しければ、小さなインスタンスと台数で構築して、N 倍して考える
108. 108. ELBやCloudfrontなどのベンダーの提供す る既存サービスに対して負荷試験を行う やってもいみない
109. 109. 静的コンテンツはサービス利用前提とすると 負荷試験も行わないでよい。 S3での配信＋リバースプロクシを立てる リバースプロクシとしてnginxやsquidと かいろいろ有りますが、、、 冗長化やスケール性を考えるとAkamai やCloudFrontなどのCDN立てるのが 一番エンジニアが楽できます。 Amazon S3 CloudFront
110. 110. 補足
111. 111. システムが遅い時のあたりの付け方 • （既存/自作）FWが重い(CPU負荷が高い、メモリ使用量が多い) • DBの応答が遅い(Slow query logを見る) • SQLが悪い(ORMのせいかも) • INDEXが不適切 • ロックが発生している（INNODB_LOCKSやログ監視など） • 無駄なSQLが発行されている • DB設計が悪い • リソース不足 • コネクションプーリングしていない（DB/Memcached） • 不要なループ・冗長なコード・内部リソースの使い回しがされていない • Cacheが適切に設定されていない
112. 112. 攻撃サーバの設定を変更する 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関連の設定を変えないと、単位時間あたりのリクエスト量が増えた時 に攻撃サーバのソケットが枯渇して新規に接続を行うことができなくなる。
113. 113. 負荷試験が必要ないケースもあります • 既存システムの少改修 • トラフィックが“絶対に”増えないケース • トラフィックが増えた時に落ちても良いケース • ELBやCloudFrontなどの外部ベンダーの提供する既存サービスに対する負 荷試験 （静的コンテンツをCDN使って配信しているケースなど）
114. 114. 負荷試験結果事例の紹介
115. 115. 質疑応答(10分)
116. 116. ご静聴ありがとうございました。