失敗事例で学ぶ負荷試験

失敗事例で学ぶ負荷試験

1. 1. 失敗事例で学ぶ負荷試験 @Security-JAWS 第7回 (株) ゆめみ 仲川樽八
2. 2. 負荷試験って、 セキュリティーの話じゃないじゃん。
3. 3. 負荷試験は、情報セキュリティーのCIA ・機密性 ・完全性 ・可用性 のうちの、可用性を担保するための重要な手段 です。
4. 4. ということで、 セキュリティーの一部として お話させて下さい。
5. 5. 自己紹介 ベンチャー企業でガラケーからずっとWebシステムの開発をしていまし た。 最近はほぼAWS上でのシステム構築をしています。 負荷試験本を書きました。
6. 6. 業務内容 Web系システムの請負開発案件における  ご要望の整理  開発コスト見積もり  詳細な要件定義  設計・ソリューション選定  実装・単体試験  結合試験・負荷試験  デプロイプロセスの構築・デプロイ  保守・運用(誰かに引き継ぐまで) だいたい全部やってます。 今日はここの話
7. 7. クラウドで構築されたシステムの 可用性に関する3つの派閥 ク ラ ウ ド 使 っ て る ん だ か ら 落 ち な い で し ょ 。 ク ラ ウ ド な ん て す ぐ に 落 ち る も の だ よ 。 ク ラ ウ ド 使 っ て 落 ち な い シ ス テ ム を 作 る の が 仕 事 で し ょ ？
8. 8. 当然ですが、この人が正しいです。 単体のインスタンスは故障する。 ただし、正しく冗長化をすることで可用性を上げる。 また、高負荷に対しても、スケール対応させる。 そのためのクラウドデザインパターンが沢山あります。 ク ラ ウ ド 使 っ て 落 ち な い シ ス テ ム を 作 る の が 仕 事 で し ょ ？
9. 9. ス ケ ー ル 対 応 も さ せ た し 、 余 裕 っ し ょ 。
10. 10. 失敗事例 1
11. 11. 夢であってくれ
12. 12. 案件の詳細
13. 13. 割 愛 ・ ・ ・ ・ ！ 案 件 の 詳 細 を お 見 せ す る こ と が ・ ・ ・ で き な い ・ ・ ・ ・ ！ 無 論 ・ ・ ・ ・ 見 せ た い ・ ・ ・ ・ ！ 我 々 は そ の 一 部 始 終 を ・・・・ 見 て い た だ き た い ・・・・！ が ・ ・ ・ ・ 駄 目 ・ ・ ！
14. 14. リリース当日
15. 15. なんですぐに死んでしまうん？
16. 16. 緊急負荷対策チーム結成
17. 17. 実際に取られた負荷対策 キャンペーンサイトにユーザーが流入する為のリンクを全て 落として、お問い合わせベースでURLをご案内する。
18. 18. 影響範囲
19. 19. 圧 倒 的 コ ン プ ラ イ ア ン ス に よ っ て ・ ・ ・ ・ お 見 せ す る こ と が で き な い ・ ・ ・ ・ ！
20. 20. 負 荷 試 験 を 実 施 し て い な い の で あ る 。 誰 も ！
21. 21. 失敗事例 2
22. 22. スケールアップの限界
23. 23. 社 長 の た め に 、 最 初 か ら を 契 約 し て お い て あ げ た ね ん 。 db.m4.16xlarge
24. 24. 負荷試験していないシステムでスケールアップをしても、実際に処理 性能が上がる保証は全くありません。 DBのスケールアップでシステムの処理性能がどこまで追従するかは アプリケーション依存ですが、multi-AZ環境で最初から上位のインス タンスを利用しているケースにおいてはスケールアップによる性能向 上は限定的です。 ※メモリが潤沢になることにより、データや各種Indexがオンメモリに なる恩恵は有ります。
25. 25. 失敗事例 3
26. 26. 「それさぁ。先に言ってよ~」
27. 27. 業務内容 他案件のヘルプで負荷試験だけを依頼されることがある。  ご要望の整理  開発コスト見積もり  詳細な要件定義  設計・ソリューション選定  実装・単体試験  結合試験・負荷試験  デプロイプロセスの構築・デプロイ  保守・運用(誰かに引き継ぐまで) ここまで 全部終わってる
28. 28. Q. 利用ユーザー数の想定は？ A. わかりません。 Q. スパイク時のリクエスト量の想定は？ A. わかりません。 Q. データ総ボリューム数の想定は？ A. わかりません。
29. 29. ・一番最初のご要望の整理の時点で、負荷試験を見据えたヒアリン グを行って下さい。 ・負荷試験をスケジュール上の最後に持ってきてはいけません。 負荷試験においては大抵何らかのシステムの不具合が検出されま すので、その後に改修をする時間を予め見込んでおく必要がありま す。
30. 30. 失敗事例 4
31. 31. 商用環境と構成が違う
32. 32. こ ん な こ と も あ ろ う か と 、 オ レ の ロ ー カ ル 開 発 環 境 で 負 荷 試 験 は 実 施 済 み だ 。
33. 33. 商用環境がAWSなら、AWS上に商用環境と同等の負荷試験環境を 構築して下さい。 今なら秒単位の課金なので、コスト的には非常にやりやすくなってい ます。 ローカルのマシンのプロファイリング結果と実際の環境上では全く異 なる結果となることが多く、むしろこの負荷試験結果は邪魔になるこ とすらあります。
34. 34. 失敗事例 5
35. 35. 商用環境をそのまま使う その1
36. 36. そ ん な の は 理 論 値 の 証 明 に 過 ぎ な い だ ろ ？ そ の エ ン ジ ン テ ス ト で 私 が 知 り た い の は 運 転 限 界 な ん だ よ そ の 二 号 エ ン ジ ン は 実 測 値 採 り の た め に 用 意 し た ん だ う ん か ま わ な い い っ そ 壊 す つ も り で ギ リ ギ リ ま で 出 力 を 上 げ て み て く れ
37. 37. やっぱり壊れる。
38. 38. 爆 発 し た 二 号 エ ン ジ ン の 残 し た デ ー タ の 内 容 に は 満 足 し て い ま す 次 は 失 敗 し ま せ ん 御 期 待 下 さ い
39. 39. ・負荷試験は対象のシステムを負荷で落とすつもりでかけるものです。 ただし、その時に負荷試験対象のシステムにつなぎこまれたシステムや稼 働中の共有リソースが有るとそちらのシステムに迷惑をかけてしまいます。 ・外部連携先がある場合は、適宜スタブを準備して下さい。 ※外部連携先のシステムの性能に引きづられて実際には低い性能しか発 揮できない場合であっても、そちらのシステムが改善した前提で負荷試験 を行ったほうが良いです。 ・また、負荷試験では大量のゴミデータを生成する事がありますので、他 の検証環境や受け入れテスト環境とも分離しておいた方が良いです。
40. 40. 商用環境をそのまま使う その2
41. 41. 例えば商用環境では https://でアクセスするSSLサイトの 試験をどう実施するか？
42. 42. オ イ オ イ オ イ死 ぬ わ ア イ ツ ほ う SSL 抜 き 負 荷 試 験 で す か ・・・ た い し た も の で す ね
43. 43. 「SSLを利用しない負荷試験は、対象のサーバに対し て100％の負荷をかけることができるため、愛用する エンジニアも多いと聞きます。」 ※逆にSSL経由の試験を行った場合には、攻撃力不足となるため、非SSLにおける試験の1/10以 下のスループットにしかならない程度のぬるい負荷しか与えることができないこともあります。
44. 44. 失敗事例 6
45. 45. 攻撃力が不十分
46. 46.  攻撃ツールが良くない  攻撃サーバ-アプリケーション間の Keep-Aliveが出来ていない  攻撃サーバがネットワーク的に遠すぎ る  攻撃サーバの能力不足  攻撃サーバ起動パラメータ不正  攻撃用同時クライアント数が少なすぎ る/多すぎる  その他 き ・ ・ ・ き か ぬ き か ぬ の だ ！
47. 47. ちなみに、あまりにも時間がなさすぎて、社内ネッ トワークから負荷試験をかけてみた
48. 48. 会社のメンバー全員のブラウザにこの表示が出るようになった。
49. 49. 失敗事例 7
50. 50. とにかく実施してから考えよう。
51. 51. シナリオのスループット：100 rps APIスループット：1000 rps 平均レイテンシ：200msec
52. 52. な ん か 結 果 で た よ 。 試 験 お わ り ！
53. 53. ELB Availability Zone Availability Zone EC2 instance web app server Amazon Route 53 攻撃サーバ RDS DB instance RDS standby (Multi-AZ) ElastiCache ElastiCache EC2 instance web app server web app server web app server EC2 instance EC2 instance 外部サービス S3/Dynamodb 他Restful APIサービスなど http/https 通信 ×攻撃シナリオ ×キャッシュ設計 ×更新クエリ ×参照クエリ ×接続方法 ×接続方法 ×フレームワーク ×ネットワークリソース ×アプリロジック ×接続方法 ×CPUリソース ×Memリソース ×CPUリソース ×Memリソース ×Disk帯域 ×CPUリソース ×Memリソース ×ネットワークリソース ×接続方法 ×CPUリソース ×Memリソース ×ミドルウエア設定 ×index設計 ×データ肥大化 ×ツール設定
54. 54. 俺 達 は 雰 囲 気 で 負 荷 試 験 を や っ て い る ぜ ん ぜ ん わ か ら な い
55. 55. ・雰囲気でやった負荷試験において、何らかの数字が取れた時に、 その数字が正しいのかどうかもわからない状態となります。 ※そして大抵の場合は正しくないです。 ・さらに、どこが間違っていたのかもわかりません。
56. 56. 雰囲気に頼らない負荷試験 数学の定理の証明のように、少しづつ正しいで あろうと考えられる範囲を増やしていく
57. 57. 雰囲気に頼らない負荷試験 単体のWebサーバに対する試験 1. 負荷試験攻撃サーバが正しく攻撃できていることを確認 2. 静的なファイルであれば高速に応答出来ることを確認 3. 単純なhelloworldであれば高速に応答できることの確認 4. 参照系であれば高速に応答できることの確認 5. 更新系が高速に応答できることの確認 6. 外部システムへの連携が正常に出来る確認 7. シナリオが通ることの確認 WebサーバをELB配下に設置して行う試験 1. スケールアップ、スケールアウトに追従することの確認 2. 攻撃サーバをスケールアウトさせる限界試験
58. 58. 詳しくは
59. 59. おまけ
60. 60. システムがスケールしない時 スケールしない原因は、スケールさせていない部分。 つまり、共有の外部リソースへのアクセス部分であることが多い。 特に、コネクションプーリングの有無で パフォーマンスは大きく変わる。
61. 61. なにはともあれ、 コネクションプーリング と言っただろ！！
62. 62. 岡崎市中央図書館事件
63. 63. ある図書館の新刊検索システムがまともに機能しないため、 1秒間に1回のリクエストを投げてスクレイピングをする システムを稼働させた男性の不幸な物語。
64. 64. コネクションプーリングのせいで 400リクエスト/時間 以上のアクセスでサイトが落ちるシステムだった。 ↓ 結果：偽計業務妨害容疑で男性を逮捕、 実名報道の上20日間の勾留と取り調べ 名誉回復まで1年間かかる
65. 65. ちゃんと計測しましょう。 結論